Progettazione e distribuzione di Multilink PPP su Frame Relay e ATM

Introduzione

MLPoATM e MLPoFR (Multilink PPP over Frame Relay) sono stati introdotti nel software Cisco IOS® versione 12.1(5)T. Questa funzione è destinata ai clienti con Frame Relay/ATM Interworking (FR/ATM IW) che implementano Voice over IP (VoIP) su collegamenti WAN a media o bassa velocità. Prima di questa funzione, non esisteva uno schema di frammentazione di layer 2 comune supportato da Cisco IOS su entrambi i clienti ATM e Frame Relay con FR/ATM IW, che erano costretti a eseguire la frammentazione di layer 3.

Prerequisiti

Requisiti

Questo documento è destinato al personale di rete coinvolto nella progettazione e nell'implementazione di reti VoIP che coinvolgono le reti MLPoATM e Frame Relay. Cisco raccomanda la conoscenza dei seguenti argomenti:

• Frame Relay

• ATM

• PPP

• MLP

• Frame Relay/ATM Interworking

• Configurazione QoS (Voice Quality of Service)

Il presente documento non è inteso a fornire una formazione tecnologica su queste materie. Alla fine del presente documento è incluso un elenco di materiali di riferimento. Cisco consiglia di esaminare e comprendere questi documenti prima di leggerli:

• VoIP over Frame Relay con qualità del servizio (frammentazione, Traffic Shaping, priorità LLQ / IP RTP)

• QoS VoIP per Frame Relay su ATM Interworking con LLQ, PPP LFI e cRTP

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Software Cisco IOS release 12.1(5)T o successive per MLP over FR/ATM IW

• Software Cisco IOS versione 12.2(2)T o successive per Compressed Real Time Transport Protocol (cRTP) over ATM

• Software Cisco IOS release 12.0(7)T per LLQ (Low Latency Queueing) su Frame Relay e ATM sull'interfaccia fisica

• Software Cisco IOS release 12.1(2)T per LLQ su Frame Relay e ATM per PVC (Permanent Virtual Circuit)

Il case study incluso in questo documento si basa su una rete di produzione che utilizza le seguenti versioni software e hardware:

• I router Cisco 3660 principali eseguono il software Cisco IOS versione 12.2(5.8)T. Il requisito per il protocollo cRTP su ATM impone l'uso del software Cisco IOS versione 12.2T. Questo problema noto viene risolto nel software Cisco IOS versione 12.2(8)T1:

  ID bug Cisco CSCdw44216 (solo utenti registrati) - Il protocollo cRTP provoca un utilizzo elevato della CPU quando il collegamento CBWFQ (Weighted Fair Queueing)/LLQ basato su classi raggiunge la congestione.

• I router Cisco 2620 per filiali sono in fase di aggiornamento dal software Cisco IOS versione 12.2(3) a una versione 2.2(6a). Cisco 2620 funge anche da gateway H.323. L'aggiornamento è attivato da un problema relativo al gateway. Per quanto riguarda le funzionalità WAN e QoS, il software Cisco IOS versione 12.2(3) non presenta problemi significativi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Progettazione

In questa sezione vengono illustrati diversi concetti di progettazione relativi alla progettazione e alla distribuzione di Multilink PPP su Frame Relay e ATM.

Sovraccarico collegamento dati

Quando si progettano reti ATM e Frame Relay con MLP, è necessario comprendere il sovraccarico del collegamento dati. Il sovraccarico influenza la quantità di larghezza di banda utilizzata da ciascuna chiamata VoIP. Consente inoltre di determinare le dimensioni ottimali del frammento MLP. È fondamentale ottimizzare le dimensioni del frammento per adattarlo a un numero integrale di celle ATM, in particolare su PVC a bassa velocità dove una quantità significativa di larghezza di banda viene sprecata nella spaziatura interna delle celle. Il sovraccarico del collegamento dati su MLP su Frame Relay e PVC ATM dipende da questi fattori:

• Modalità di funzionamento del dispositivo FRF.8 IW (trasparente o traslazionale).

• La direzione del traffico (ATM - Frame Relay o Frame Relay - ATM).

• La gamba in PVC. L'overhead è diverso sulle gambe ATM e Frame Relay del PVC.

• Tipo di traffico. i pacchetti dati hanno un'intestazione MLP; I pacchetti VoIP no.

Nella tabella viene mostrato il sovraccarico del collegamento dati per un pacchetto di dati. Descrive il numero di byte nelle varie intestazioni Frame Relay, ATM, LLC, PPP e MLP per tutte le permutazioni della modalità di funzionamento FRF.8, direzione del traffico e gamba PVC.

¹DSAP/SSAP: punto di accesso al servizio di destinazione/punto di accesso al servizio di origine.

²NLPID - Identificazione protocollo a livello di rete.

Il PVC traslazionale è il più facile da comprendere perché il sovraccarico è lo stesso in entrambe le direzioni. Questo perché il dispositivo FRF.8 converte i formati MLPoATM e MLPoFR. Di conseguenza, il formato del frame è MLPoFR sul segmento Frame Relay in entrambe le direzioni. Il formato sulla gamba ATM è MLPoATM in entrambe le direzioni.

Il PVC trasparente è leggermente più confuso perché il sovraccarico differisce nelle due direzioni. Questa complessità deriva dal fatto che il router Frame Relay invia pacchetti in formato MLPoFR. Questo formato viene trasferito dal dispositivo IW al lato ATM. Analogamente, il router ATM invia i pacchetti nel formato MLPoATM. Questo formato viene trasferito dal dispositivo IW al lato Frame Relay. Pertanto, il risultato è un formato di fotogramma diverso nelle due direzioni su ciascuna gamba.

A confronto, il sovraccarico su un PVC Frame Relay end-to-end che usa FRF.12 è di 11 byte. Pertanto, su un collegamento Frame Relay end-to-end, FRF.12 è una scelta più efficiente per la frammentazione dei collegamenti e l'interfoliazione (LFI) di MLP. Sui circuiti virtuali ATM (VC) end-to-end, MLP è l'unica scelta poichè non è disponibile la frammentazione basata su standard. Tuttavia, le VC ATM end-to-end sono da media ad alta velocità. Pertanto, LFI non è richiesto. L'eccezione a questa regola è rappresentata dai VC ATM a bassa velocità su DSL (Digital Subscriber Line).

L'ID PPP è presente solo nel primo frammento MLP. Pertanto, il sovraccarico nel primo frammento è sempre due byte in più rispetto ai frammenti successivi.

La tabella mostra il sovraccarico del collegamento dati per un pacchetto VoIP. Descrive il numero di byte nelle varie intestazioni Frame Relay, ATM, LLC e PPP per tutte le permutazioni della modalità di funzionamento FRF.8, direzione del traffico e gamba PVC. La differenza principale tra un pacchetto dati e uno VoIP è che i pacchetti VoIP vengono inviati come pacchetti PPP e non come pacchetti MLP. Tutti gli altri aspetti sono identici allo scenario dei dati.

A confronto, il sovraccarico del collegamento dati per un pacchetto VoIP su un PVC Frame Relay end-to-end è mostrato nella colonna all'estrema destra.

Requisiti di larghezza di banda VoIP

Quando si fornisce larghezza di banda per il VoIP, il sovraccarico del collegamento dati deve essere incluso nei calcoli della larghezza di banda. Questa tabella mostra i requisiti di larghezza di banda per chiamata per le diverse caratteristiche del VoIP. Si basa sulle caratteristiche del PVC. I calcoli riportati in questa tabella presuppongono uno scenario ottimistico per cRTP (ad esempio, nessun checksum UDP e nessun errore di trasmissione). Le intestazioni vengono quindi compresse in modo coerente da 40 byte a 2 byte.

Poiché il sovraccarico varia in base alle diverse gambe del PVC, è necessario progettare per lo scenario peggiore. Si consideri, ad esempio, G.729 con campionamento di 20 millisecondi (msec) e cRTP su PVC trasparente. In questo scenario, i requisiti di larghezza di banda per il segmento Frame Relay sono 12,4 Kbps in una direzione e 13,2 Kbps nell'altra. Il provisioning deve essere eseguito presupponendo 13,2 Kbps per chiamata.

A confronto, i requisiti di larghezza di banda VoIP su un PVC Frame Relay end-to-end sono mostrati anche nella colonna all'estrema destra della tabella sopra. Il sovraccarico aggiuntivo del protocollo PPP rispetto all'incapsulamento Frame Relay nativo determina un consumo di larghezza di banda aggiuntivo compreso tra 0,5 e 0,8 Kbps per chiamata. Pertanto, l'incapsulamento Frame Relay con FRF.12 ha più senso di MLP su un Frame Relay VC end-to-end.

Nota: cRTP over ATM richiede il software Cisco IOS versione 12.2(2)T o successive.

Ottimizza dimensioni frammentazione

Il motivo per cui si usa MLP su Frame Relay/PVC ATM è consentire la frammentazione di pacchetti di dati di grandi dimensioni in blocchi più piccoli. Il router accelera quindi i pacchetti VoIP interfoliandoli tra i frammenti di dati. In Cisco IOS, le dimensioni della frammentazione non sono configurate direttamente. Per configurare il ritardo desiderato, usare il comando ppp multilink fragment-delay. Cisco IOS utilizza quindi questa formula per calcolare le dimensioni appropriate del frammento:

fragment size = delay x bandwidth/8

Quando si esegue la prevenzione della perdita dei dati in ATM, è necessario ottimizzare le dimensioni del frammento in modo che si adatti a un numero intero di celle. Se questa ottimizzazione non viene eseguita, la larghezza di banda richiesta può quasi raddoppiare a causa della spaziatura interna. Ad esempio, se ciascun frammento è lungo 49 byte, sono necessarie due celle ATM per trasportare ciascun frammento. Pertanto, 106 byte vengono utilizzati per trasportare un payload di solo 49 byte.

Cisco IOS ottimizza automaticamente le dimensioni del frammento in modo da usare un numero integrale di celle ATM quando esegue MLPoATM e MLPoFR. Cisco IOS arrotonda automaticamente le dimensioni calcolate del frammento al successivo numero integrale di celle ATM. Non vengono aggiunti nuovi comandi CLI. Cisco IOS esegue questa ottimizzazione su entrambe le estremità Frame Relay e ATM di un PVC MLPoFR/ATM. È possibile che un PVC MLP sia un Frame Relay end-to-end. In questo caso, non è necessario ottimizzarlo per ATM. Cisco IOS ottimizza tuttavia questo scenario per ATM perché non ha modo di rilevare se l'estremità remota è ATM o Frame Relay.

Nota: a causa dell'arrotondamento, il ritardo risultante può essere leggermente superiore a quello configurato. Questo errore di arrotondamento è più significativo nei PVC a bassa velocità.

È inoltre possibile configurare manualmente l'ottimizzazione. Poiché le dimensioni del frammento non possono essere specificate direttamente in Cisco IOS, calcolare le dimensioni ottimali del frammento e convertirlo in un ritardo. Quando si calcolano le dimensioni del frammento, tenere conto del sovraccarico del collegamento dati, in quanto il codice MLP presuppone che ogni collegamento sia di tipo HDLC (High-Level Data Link Control) e abbia un sovraccarico di 2 byte. Oltre al sovraccarico del collegamento dati HDLC, il codice MLP include nei suoi calcoli gli 8 byte costituiti dall'ID MLP, dal numero di sequenza MLP e dall'ID PPP come indicato nella prima tabella precedente.

Per calcolare il ritardo da configurare in Cisco IOS, utilizzare la seguente procedura:

1. Calcolare le dimensioni teoriche del frammento in base al ritardo desiderato e alla larghezza di banda del PVC:

   fragment = bandwidth * delay / 8

2. Verificare che il frammento sia un multiplo di 48 byte, in modo che possa essere inserito in un numero integrale di celle ATM.

   La formula per calcolare le dimensioni del frammento allineate alla cella è:

   fragment_aligned = (int(fragment/48)+1)*48

3. Effettuare una rettifica per tenere conto del sovraccarico del collegamento dati che non è stato preso in considerazione da MLP.

   Come visto in precedenza, questo sovraccarico differisce in base alle caratteristiche del PVC. Considerare il lato ATM del PVC in quanto si tratta del lato per il quale si esegue l'ottimizzazione. Questa tabella mostra il numero di byte di sovraccarico del collegamento dati sul lato ATM.

   Modalità FRF.8	Trasparente		Traduzione
   Direzione traffico	Frame Relay su ATM	ATM su Frame Relay	Frame Relay su ATM	ATM su Frame Relay
   Frame Relay o gamba ATM di PVC	ATM	ATM	ATM	ATM
   LLC DSAP/SSAP (0xfefe)	0	2	2	2
   Controllo LLC (0x03)	1	1	1	1
   NLPID (0xcf per PPP)	1	1	1	1
   AAL5	8	8	8	8
   Sovraccarico non MLP (byte)	10	12	12	12

   Per ottenere le dimensioni del frammento su cui MLP basa i propri calcoli, sottrarre il sovraccarico del collegamento dati dalle dimensioni del frammento allineate alla cella desiderate. Aggiungete nuovamente 2 byte per compensare l'incapsulamento HDLC che MLP assume sempre.

   La formula per calcolare la dimensione del frammento di destinazione del codice MLP è la seguente:

   fragment_mlp = fragment_aligned - datalink_overhead + 2

4. Convertire le dimensioni del frammento che risulta nel ritardo corrispondente con questa formula:

   delay = fragment_mlp/bandwidth x 8bits/byte

5. Nella maggior parte dei casi, il ritardo calcolato non è un numero intero di millisecondi. Poiché Cisco IOS accetta solo valori interi, è necessario eseguire l'arrotondamento per difetto. Di conseguenza, il valore di ritardo configurato in Cisco IOS con l'ausilio del comando ppp multilink fragment-delay è:

   fragment_delay = int(fragment_mlp/bandwidth x 8bits/byte)

6. Per compensare l'errore di arrotondamento di cui sopra, svuotare la larghezza di banda utilizzata da MLP per convertire il ritardo in un frammento. La larghezza di banda con buffer configurata in Cisco IOS con il comando bandwidth è:

   bandwidth = fragment_mlp/fragment_delay * 8

Nella tabella vengono mostrati i valori ottimali di ritardo dei frammenti di connessione multipla ppp e larghezza di banda per le velocità più comuni del PVC. Si presuppone un ritardo target di 10 msec. Per semplificare la tabella, i calcoli non distinguono tra PVC trasparente e traslazionale o tra le direzioni del traffico. La differenza massima di sovraccarico del collegamento dati è di soli 2 byte. Pertanto, la penale per la progettazione per il caso peggiore di 12 byte è minima. Nella tabella viene inoltre mostrato il ritardo "reale" verificatosi in seguito all'aumento delle dimensioni del frammento, in modo che i frammenti vengano inseriti in un numero intero di celle.

Considerazioni su Traffic Shaping e Policing

Particolare attenzione viene data al traffic shaping e alla gestione delle policy in un ambiente Frame Relay/ATM IW. I problemi nella direzione Frame Relay - ATM sono diversi dai problemi nella direzione ATM - Frame Relay. Pertanto, ciascun argomento viene descritto separatamente.

Il problema principale nella direzione Frame Relay - ATM è la potenziale espansione nel consumo di larghezza di banda quando si va da un frame all'altro. Ad esempio, un frame di 49 byte sul lato Frame Relay consuma due celle, o 106 byte, sul lato ATM. Non si può pertanto presumere che il tasso di celle sostenibili sia uguale al tasso di informazioni impegnate (CIR). Lo scenario peggiore si verifica quando ogni frame Frame Relay contiene 1 byte di payload. Ognuno di questi byte consuma una cella completa da 53 byte sul lato ATM. A titolo di esempio, questo scenario estremo e irrealistico impone un SCR pari a 53 volte il CIR. Altri due esempi realistici sono:

• Un pacchetto VoIP G.729 è lungo 60 byte, o 69 byte (quando sono inclusi il sovraccarico MLP e Frame Relay). Sulla gamba ATM, consuma due celle o 106 byte. Pertanto, se tutto il traffico trasportato è VoIP, una mappatura appropriata è SCR = 106/69 = 1,5 x CIR.

• Un pacchetto Telnet che trasporta una singola sequenza di tasti contiene 40 byte di intestazione TCP/IP e 1 byte di dati. Sul lato Frame Relay, questo totale è di 56 byte, incluso il sovraccarico. Tuttavia, sul lato ATM, il pacchetto si espande a due celle. In questo caso, SCR = 106/56 = 1,9 x CIR.

L'Appendice A dello standard ATM Forum, BISDN Inter Carrier Interface (B-ICI) Specification Version 2.0, descrive due metodi di mappatura tra SCR e CIR. Sebbene entrambi i metodi forniscano un modo scientifico per derivare l'SCR dal CIR, nessuno dei due è più accurato dei dati a cui sono applicati. Uno dei numeri richiesti dalle formule è la dimensione tipica dei fotogrammi, un numero difficile da determinare in una rete reale. Inoltre, un numero che può potenzialmente cambiare quando nuove applicazioni vengono implementate su una rete ATM/Frame Relay esistente. La migliore raccomandazione per risolvere questo problema è di lavorare a stretto contatto con il tuo vettore in quanto la loro politica di polizia sarà di importanza critica. Con l'assistenza del vettore, questo approccio fail-safe è possibile:

• Frame Relay su direzione ATM: nella direzione Frame Relay su ATM, la portante deve controllare il traffico in entrata solo sul punto di ingresso Frame Relay. Ad esempio, sullo switch Frame Relay collegato al dispositivo CPE (Customer Premise Equipment) Frame Relay, il vettore regola il traffico in base al CIR contrattuale. Questo criterio di controllo è illustrato nella figura qui. Non è necessario eseguire altre operazioni di monitoraggio quando il traffico viene immesso nella rete nel punto di ingresso. Questa policy di policing implica che i dati ricevuti sul lato Frame Relay possono espandersi e usare tutta la larghezza di banda necessaria per permettere la tassa sulle celle, il sovraccarico AAL e il padding per trasportarli sul lato ATM della rete. Nella maggior parte dei casi, la larghezza di banda ATM richiesta è inferiore al doppio della larghezza di banda Frame Relay utilizzata.

  

• ATM - direzione Frame Relay: in direzione ATM - Frame Relay, si verifica l'opposto. L'utilizzo della larghezza di banda viene ridotto quando si passa da ATM a frame come imposta sulla cella, sovraccarico AAL e quando si rimuove la spaziatura interna. Tuttavia, poiché la velocità di trasmissione potenziale del lato ATM è molto più alta di quella del collegamento Frame Relay, configurare correttamente il traffic shaping sul router ATM è fondamentale per l'integrità della voce. Se la forma è troppo libera, il router ATM invia i dati a una velocità superiore alla velocità fisica del collegamento Frame Relay sull'altra estremità. Di conseguenza, i pacchetti iniziano ad essere accodati sullo switch FRF.8. A un certo punto, i pacchetti iniziano a scendere . e poiché le reti ATM/Frame Relay non fanno distinzione tra voce e dati, i pacchetti VoIP vengono scartati.

  Allo stesso tempo, se il shaping è troppo restrittivo, il throughput ne risente. A causa dell'imposta sulle celle ATM, il sovraccarico e la spaziatura interna AAL vengono rimossi dal dispositivo FRF.8. Non utilizza la larghezza di banda sul collegamento Frame Relay. Pertanto, è possibile sovrascrivere leggermente il lato ATM del PVC. La quantità di spaziatura interna e il sovraccarico AAL variano a seconda delle dimensioni medie dei frame e della aggressività della frammentazione. Poiché non è possibile qualificare con precisione questo sovraccarico, è meglio non cercare di ottimizzarlo. D'altra parte, l'imposta sulle celle è completamente deterministica. È di 5 byte per ogni 48 byte di payload. È possibile ottimizzare l'imposta sulla cella impostando il target di shaping sul router ATM su 53/48 x SCR. È necessario impostare il criterio sul lato vettore per consentire questa lieve sovrassegnazione.

Suggerimenti e avvertenze

• MLPoATM/Frame Relay è attualmente testato e supportato solo con una policy di servizio associata al modello virtuale o alle interfacce dialer. Se si omette la regola del servizio, la funzionalità potrebbe non funzionare. Un esempio è documentato nell'ID bug Cisco CSCdu19313 (solo utenti registrati).

• MLPoATM/Frame Relay duplica due interfacce di accesso virtuale per ciascun PVC. Una di queste rappresenta il collegamento PPP. L'altro rappresenta il pacchetto MLP. Il comando show ppp multilink viene usato per indicare il collegamento. Non sono supportati più collegamenti PPPoFR per bundle. L'inserimento di due circuiti PPPOFR in un unico pacchetto di traffico non sarà ben bilanciato in termini di carico tra i circuiti, poiché il driver PPPOFR non fornisce la segnalazione di controllo del flusso fornita dai veri driver seriali. Il bilanciamento del carico MLPPP su ATM o Frame Relay potrebbe mostrare un'efficacia notevolmente inferiore rispetto al bilanciamento dello stesso carico su interfaccia fisica.

• Ciascun PVC è associato a quattro interfacce diverse, ovvero l'interfaccia fisica, l'interfaccia secondaria e due interfacce di accesso virtuale. Solo l'interfaccia di accesso virtuale MLP ha l'accodamento di struttura abilitato. Le altre tre interfacce devono avere una coda FIFO (First In, First Out).

• Quando si applica un comando service-policy a un modello virtuale, Cisco IOS visualizza questo normale messaggio di avviso:

  cr7200(config)#interface virtual-template 1
  cr7200(config-if)#service-policy output Gromit
  Class Based Weighted Fair Queueing (CBWFQ) not supported on interface Virtual-Access1
  Note CBWFQ supported on MLP bundle interface only.
  

  Questi messaggi sono normali. Nel primo messaggio viene indicato che i criteri di servizio non sono supportati nell'interfaccia di accesso virtuale PPP. Il secondo messaggio conferma che la policy sui servizi è stata applicata all'interfaccia di accesso virtuale del bundle MLP. Questo fatto viene verificato con l'aiuto dei comandi show interfaces virtual-access, show queue e show policy-map interface per controllare il meccanismo di coda.

• L'autenticazione PPP non è strettamente richiesta in quanto un PVC è come una linea in leasing. Tuttavia, l'autenticazione PPP è utile perché il comando show ppp multilink viene usato per determinare il nome del router sull'altra estremità del PVC.

• Il traffic shaping Frame Relay deve essere abilitato per i PVC MLPoFR sul router Frame Relay.

• Il software Cisco IOS versione 12.2 inizialmente supportava un massimo di venticinque modelli virtuali per router. Questa limitazione può influire sulla scala di un router di distribuzione ATM se è necessario che ogni PVC abbia un indirizzo IP univoco. Per risolvere il problema, nelle versioni interessate è possibile usare indirizzi IP senza numero o interfacce di connessione invece di modelli virtuali. Nel software Cisco IOS versione 12.2(8)T, il supporto è aumentato a 200 modelli virtuali.

• Alcuni provider di servizi non supportano ancora la traduzione PPP sui dispositivi FRF.8. Quando questa limitazione è presente, i provider devono configurare i PVC per la modalità trasparente.

• La maggior parte degli esempi nella documentazione di Cisco IOS mostra configurazioni che includono una sottointerfaccia Frame Relay o ATM. Questa sottointerfaccia non ha scopo. Il modello virtuale deve essere associato solo all'interfaccia fisica. Il risultato è una configurazione più compatta e gestibile. Ciò è particolarmente importante se il numero di PVC è elevato.

• Usate il comando show ppp multilink per verificare se ci sono cadute di celle o fotogrammi sul lato vettore. L'unica perdita accettabile è causata da errori CRC (Cyclic Redundancy Check).

• Sebbene MLPoATM/Frame Relay sia stato introdotto nel software Cisco IOS versione 12.1(5)T, i bug di questa e delle versioni successive richiedono attenzione quando si seleziona la versione del software Cisco IOS. Cisco consiglia di utilizzare l'ultima versione di manutenzione di Cisco IOS 12.2 mainstream. Tuttavia, altri requisiti delle funzionalità VoIP possono imporre l'uso di una versione diversa del software Cisco IOS, ad esempio 12.2(2)XT se è richiesta la tecnologia SRST (Survivable Remote Site Telephony). In questa tabella vengono elencati alcuni problemi noti. Quando si seleziona Cisco IOS, ciascun ID bug Cisco deve essere valutato rispetto al sistema operativo IOS scelto.

Case study

Introduzione

In questa sezione viene descritta una delle prime implementazioni della funzionalità MLPoATM/Frame Relay da parte dei clienti. Il nome del cliente è XYZ Ltd. Nel 2001, XYZ Ltd ha sostituito i propri PBX con una soluzione di telefonia IP. Nell'ambito di questo progetto, è stata costruita una nuova rete IP. e Frame Relay/ATM interworking. Il vettore che fornisce il servizio WAN utilizza gli switch Newbridge per fornire i servizi ATM e Frame Relay.

Panoramica della rete

La rete XYZ Ltd è una rete hub and spoke che collega ventisei filiali con due siti principali. Ogni sito principale è servito da un router Cisco 3660 collegato a E3 ATM. Diciotto dei ventisei rami sono di medie dimensioni. Sono dotati di PVC Dual Frame Relay che si connettono agli switch 3660 nei due siti principali tramite ATM/Frame Relay IW. Gli altri otto rami sono molto piccoli. Si connettono al ramo di medie dimensioni più vicino tramite un PVC Frame Relay singolo. Tutti i router delle filiali sono Cisco 2620. Un PVC ATM end-to-end connette i due router 3660 nei due siti hub. Nella figura viene illustrata la topologia.

La tabella mostra le velocità di accesso a Frame Relay e CIR. Il CIR varia da 32 kbps a 256 kbps. Nella tabella viene inoltre mostrato il numero massimo di chiamate VoIP simultanee trasportate da ogni PVC.

Il traffic shaping Frame Relay viene eseguito dai router delle diramazioni. È consentita la frammentazione oltre il CIR. Il traffic shaping di Cisco IOS è impostato sulla velocità di accesso, con mincir uguale a CIR. Se il vettore riceve notifiche di congestione esplicita (BECN) all'indietro, il router torna al mini-cir. Questo approccio è contrario alle raccomandazioni Cisco quando si esegue il VoIP su Frame Relay. La voce è già nei problemi quando il router risponde alle notifiche di congestione. Tuttavia, in questo caso, l'operatore ritiene che la rete sia sufficientemente sovradimensionata da non perdere mai i frame o le celle, e quindi i BECN non devono mai essere visti.

Il traffic shaping ATM è impostato sulla forma alla velocità di accesso al frame all'estremità remota, più imposta sulla cella. Ad esempio, se la velocità di accesso è 512 Kbps, SCR è impostato su 512x53/48 = 565 Kbps. Questa velocità di modellazione viene utilizzata per massimizzare il throughput. Questo metodo è sicuro perché l'imposta sulle celle viene eliminata in corrispondenza del punto IW. Il controllo da parte dell'operatore è configurato in modo generoso, per consentire una leggera sovrascrittura.

il protocollo cRTP viene usato sulla WAN. Per quanto riguarda la CPU, l'area sensibile è il router di distribuzione Cisco 3660 sul sito principale 1. Aggiungendo i numeri nella tabella precedente, si determina che il numero massimo teorico di chiamate VoIP che attraversano il router è 102. I numeri delle prestazioni riportati in questo grafico indicano che il carico della CPU Cisco 3660 per 100 sessioni cRTP (a commutazione rapida) è circa del 50%.

I modelli virtuali vengono utilizzati con i collegamenti WAN con numero IP. È necessario un modello virtuale per PVC, il che è possibile poiché il numero totale di PVC che terminano su ciascun Cisco 3660 è inferiore a venticinque.

Configurazioni

Nel documento vengono usate queste configurazioni:

• Core ATM Router

• Router Branch Frame Relay

!--- Note: This section shows the parts of a core Cisco 3660 router !--- configuration that is relevant to MLPoATM.

        
class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map toortr01
  class Voice_Stream
    priority 175
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.105 255.255.255.252

interface ATM2/0
 description To Carrier E3 ATM Service
 no ip address

interface ATM2/0.15 point-to-point
 pvc toortr01 0/58 
  vbr-nrt 406 406
  tx-ring-limit 8
  protocol ppp Virtual-Template15

interface Virtual-Template15
 bandwidth 320
 ip unnumbered loopback0
 ip tcp header-compression iphc-format
 service-policy output toortr01
 ppp multilink
 ppp multilink fragment-delay 14
 ppp multilink interleave
 ip rtp header-compression iphc-format


!--- Note: Do not configure !--- IP addresses directly on any configuration source, !--- such as a virtual template, whenever the possibility !--- exists that this information is cloned to multiple !--- active interfaces. The exception to this rule is the !--- rare case where the intent is to define multiple parallel !--- IP routes and have IP do load balancing between them. !--- If an IP address is present on the configuration source, !--- this IP address is copied to all the cloned interfaces. !--- IP installs a route to each of these interfaces.
 

!--- Note: This section shows the parts of a branch Cisco 2600 router !--- configurations that is relevant to MLPoFR.


class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map dhartr21
  class Voice_Stream
    priority 240
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.106 255.255.255.252

interface Serial0/0
 description To Carrier Frame Relay Service
 encapsulation frame-relay IETF
 frame-relay traffic-shaping

interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 38 ppp Virtual-Template1
  class dhartr21

interface Virtual-Template1
 bandwidth 320
 ip unnumbered loopback0
 max-reserved-bandwidth 85
 service-policy output dhartr21
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave

map-class frame-relay dhartr21
 frame-relay adaptive-shaping becn
 frame-relay cir 320000
 frame-relay bc 3200
 frame-relay mincir 320000

Informazioni correlate

• VoIP over Frame Relay con qualità del servizio (frammentazione, Traffic Shaping, priorità LLQ / IP RTP)
• QoS VoIP per Frame Relay su ATM Interworking con LLQ, PPP LFI e cRTP
• Configurazione della frammentazione e dell'interfoliazione del collegamento per Frame Relay e circuiti virtuali ATM
• PPP over AAL5, RFC 2364, luglio 1998
• PPP in Frame Relay, RFC1973, giugno 1996
• Protocollo MP (PPP Multilink Protocol), RFC 1717, novembre 1994
• Compressione delle intestazioni IP/UDP/RTP per i collegamenti seriali a bassa velocità, RFC 2508, febbraio 1999
• Accordo di implementazione per l'interoperabilità dei servizi Frame Relay / ATM PVC FRF.8.2
• Accordo per l'implementazione della frammentazione Frame Relay FRF.12
• Supporto alla tecnologia vocale
• Supporto dei prodotti per le comunicazioni voce e IP
• Risoluzione dei problemi di Cisco IP Telephony
• Documentazione e supporto tecnico – Cisco Systems