Ontwerpen en implementeren van multilink PPP via Frame Relay en ATM

Inleiding

Multilink PPP over ATM en Multilink PPP via Frame Relay (MLPoATM en MLPoFR) is geïntroduceerd in Cisco IOS® softwarerelease 12.1(5)T. Deze optie is gericht op klanten met Frame Relay/ATM Interworking (FR/ATM IW) die Voice-over-IP (VoIP) over middelgrote tot snelle WAN-koppelingen implementeren. Vóór deze optie was er geen gemeenschappelijk Layer 2-fragmentatieregeling die door Cisco IOS werd ondersteund op zowel ATM als Frame Relay-klanten met FR/ATM IW gedwongen om Layer 3-fragmentatie te doen.

Voorwaarden

Vereisten

Dit document is bedoeld voor netwerkpersoneel dat betrokken is bij het ontwerp en de implementatie van VoIP-netwerken waaraan MLPoATM- en Frame Relay-netwerken zijn gekoppeld. Cisco raadt kennis van de volgende onderwerpen aan:

• Frame Relay

• ATM

• PPP

• MLP

• Frame Relay/ATM-interactie

• QoS-configuratie (Voice Quality of Service)

Dit document is niet bedoeld om op deze gebieden een technologische opleiding te geven. Aan het einde van dit document is een lijst van referentiematerialen opgenomen. Cisco raadt u aan deze documenten te bekijken en te begrijpen voordat u dit document leest:

• VoIP via Frame Relay met Quality-of-Service (fragmentatie, traffic shaping, LLQ/IP RTP-prioriteit)

• VoIP QoS voor Frame Relay naar ATM Interworking met LLQ, PPP LFI en cRTP

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Cisco IOS-softwarerelease 12.1(5)T of hoger voor MLP over FR/ATM IW

• Cisco IOS-softwarerelease 12.2(2)T of hoger voor Compressed Real Time Transport Protocol (cRTP) over ATM

• Cisco IOS-softwarerelease 12.0(7)T voor Low Latency Queueing (LLQ) via Frame Relay en ATM op de fysieke interface

• Cisco IOS-softwarerelease 12.1(2)T voor LLQ via Frame Relay en ATM per permanent virtueel circuit (PVC)

De casestudy die in dit document is opgenomen, is gebaseerd op een productienetwerk dat deze software- en hardwareversies gebruikt:

• Cisco IOS-softwarerelease 12.2(5.8)T, de kern van Cisco 3660 routers. Het vereiste voor cRTP over ATM dicteert het gebruik van Cisco IOS-softwarerelease 12.2T. Dit bekende probleem wordt opgelost in Cisco IOS-softwarerelease 12.2(8)T1:

  Cisco bug-ID CSCdw4216 (alleen geregistreerde klanten) - cRTP veroorzaakt een hoge CPU wanneer de op klasse gebaseerde weging in de wachtrij (CBWFQ)/LLQ-link congestie bereikt.

• De Cisco 2620-routers worden momenteel bijgewerkt van Cisco IOS-softwarerelease 12.2(3)T naar één 2.2(6a). Cisco 2620s treedt ook op als tak H.323 gateways. De upgrade wordt geactiveerd door een probleem dat te maken heeft met de poort. Wat betreft de WAN- en QoS-functies heeft Cisco IOS-softwarerelease 12.2(3)geen belangrijke problemen.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Ontwerpen

In deze sectie worden verschillende ontwerpconcepten besproken die te maken hebben met het ontwerp en de implementatie van Multilink PPP via Frame Relay en ATM.

Data Link Overhead

Wanneer u ATM en Frame Relay-netwerken met MLP ontwerpt, moet u de datalink-overhead begrijpen. Overhead beïnvloedt de hoeveelheid bandbreedte die door elke VoIP-oproep wordt verbruikt. Het helpt ook het optimale MLP-fragment te bepalen. Het is van cruciaal belang om de grootte van het fragment te optimaliseren om een integraal aantal ATM-cellen in te passen, vooral bij lage snelheid PVC’s waar een aanzienlijke hoeveelheid bandbreedte wordt verspild aan celopvulling. De datalink-overhead op MLP via Frame Relay en ATM PVC’s is afhankelijk van deze factoren:

• De werking van het FRF.8 IW-toestel (transparant of vertaalbaar).

• De richting van het verkeer (ATM naar Frame Relay of Frame Relay naar ATM).

• Het PVC been. Overhead is anders op de ATM- en Frame Relay-poten van het PVC.

• Het type verkeer. Gegevenspakketten hebben een MLP header; VoIP-pakketten zijn niet beschikbaar.

Deze tabel toont de datalink-overhead voor een gegevenspakket. Het specificeert het aantal bytes in de verschillende Frame Relay-, ATM-, LLC-, PPP- en MLP-headers voor alle versies van de FRF.8-modus van de bewerking, de verkeersrichting en het PVC-been.

¹DSAP/SAP—access point voor de doelservice/bronservice

²NLPID—Identificatie van netwerklaag.

Het vertaalde PVC is het makkelijkst te begrijpen aangezien de overhead in beide richtingen hetzelfde is. Dit komt doordat het FRF.8 apparaat zich vertaalt tussen de MLPoATM en MLPoFR formaten. Als resultaat hiervan is het frame formaat MLPoFR op het Frame Relay-been in beide richtingen. Het formaat op de ATM-poot is MLPoATM in beide richtingen.

Het transparante PVC is iets eenvoudiger omdat de overhead in de twee richtingen verschilt. Deze complexiteit doet zich voor omdat de Frame Relay-router pakketten in het MLPoFR-formaat verstuurt. Dit formaat wordt door het IW-apparaat op de ATM-kant overgedragen. Op dezelfde manier stuurt de ATM-router pakketten in het MLPoATM-formaat. Dit formaat wordt door het IW-apparaat aan de kant van Frame Relay gedragen. Daarom is het resultaat verschillende frame formaten in de twee richtingen op elk been.

In vergelijking, is de overhead op een end-to-end Frame Relay PVC dat FRF.12 gebruikt 11 bytes. Daarom is FRF.12 op een end-to-end Frame Relay-link een efficiëntere keuze voor link-fragmentatie en -interleaving (LFI) dan MLP. Op end-to-end ATM virtuele circuits (VC’s) is MLP de enige keuze omdat er geen op standaarden gebaseerde fragmentatie beschikbaar is. End-to-end ATM VC’s zijn echter middelgroot tot hoog. Daarom is LFI niet vereist. De uitzondering op deze regel is ATM VC’s met lage snelheid via Digital Subscriber Line (DSL).

PPP ID is alleen aanwezig in het eerste MLP-fragment. Daarom is de overhead in het eerste fragment altijd twee bytes meer dan in daaropvolgende fragmenten.

De tabel hier toont de datalink-overhead voor een VoIP-pakket. Het specificeert het aantal bytes in de verschillende Frame Relay-, ATM-, LLC- en PPP-headers voor alle versies van de FRF.8-modus van de bewerking, de verkeersrichting en het PVC-been. Het belangrijkste verschil tussen een gegevens en een VoIP-pakket is dat VoIP-pakketten als PPP-pakketten en niet als MLP-pakketten worden verzonden. Alle andere aspecten zijn identiek aan het gegevensscenario.

Ter vergelijking wordt de datalink-overhead voor een VoIP-pakket op een end-to-end Frame Relay PVC in de rechterkolom weergegeven.

VoIP-bandbreedtevereisten

Wanneer u bandbreedte voor VoIP aanbiedt, moet de datalink-overhead in de bandbreedteberekeningen worden opgenomen. Deze tabel toont de vereisten voor de bandbreedte per oproep voor de verschillende kleuren van VoIP. Het is gebaseerd op de kenmerken van het PVC. De berekeningen in deze tabel veronderstellen een best-case scenario voor cRTP (bijvoorbeeld geen UDP-checksum en geen transmissiefouten). De Koppen worden dan consequent gecomprimeerd van 40 bytes naar 2 bytes.

Omdat de overhead varieert op de verschillende poten van het PVC, is het nodig om voor het slechtst denkbare scenario te ontwerpen. Neem bijvoorbeeld G.729 met 20 milliseconde (msec) bemonstering en cRTP via een transparant PVC. De bandbreedte-vereisten voor dit scenario op het Frame Relay-traject zijn 12,4 Kbps in de ene richting en 13,2 Kbps in de andere. Provisioning moet worden uitgevoerd met de veronderstelling van 13,2 Kbps per gesprek.

Bij vergelijking wordt het bandbreedte-vereiste van VoIP op een end-to-end Frame Relay PVC ook weergegeven in de rechterkolom van de bovenstaande tabel. De extra overhead van PPP in vergelijking met native Frame Relay-insluiting resulteert in een extra bandbreedte-consumptie tussen 0,5 Kbps en 0,8 Kbps per oproep. Daarom is Frame Relay-insluiting met FRF.12 zinnig dan MLP op een end-to-end Frame Relay VC.

Opmerking: cRTP over ATM vereist Cisco IOS-softwarerelease 12.2(2)T of hoger.

Fragmentatiegrootte optimaliseren

De reden om MLP op een Frame Relay/ATM PVC te gebruiken is om toe te staan dat grote gegevenspakketten in kleinere stukjes worden gefragmenteerd. De router versnelt vervolgens VoIP-pakketten door ze tussen de gegevensfragmenten te laten doorlopen. In Cisco IOS wordt de fragmentatiegrootte niet rechtstreeks geconfigureerd. In plaats daarvan wordt de gewenste vertraging ingesteld met de opdracht voor de MPP-multilink-fragment. Cisco IOS gebruikt vervolgens deze formule om de juiste fragmentatiegrootte te berekenen:

fragment size = delay x bandwidth/8

Wanneer u MLP over ATM doet, moet de grootte van het fragment worden geoptimaliseerd zodat het in een integraal aantal cellen past. Als deze optimalisatie niet gedaan wordt, kan de benodigde bandbreedte bijna verdubbelen door het toevoegen. Als elk fragment bijvoorbeeld 49 bytes lang is, moeten twee ATM-cellen elk fragment dragen. Daarom worden 106 bytes gebruikt om een lading van slechts 49 bytes te dragen.

Cisco IOS optimaliseert automatisch de fragmentgrootte om een integraal aantal ATM-cellen te gebruiken wanneer het MLPoATM en MLPoFR uitvoert. Cisco IOS rondt automatisch de berekende fragmentatiegrootte aan het volgende integrale aantal ATM-cellen. Er worden geen nieuwe CLI-opdrachten toegevoegd. Cisco IOS voert deze optimalisatie uit op zowel Frame Relay als ATM-eindpunten van een MLPoFR/ATM PVC. Het is mogelijk dat een MLP PVC end-to-end Frame Relay kan zijn. In dit geval is het optimaliseren voor ATM niet vereist. Echter, Cisco IOS optimaliseert dit scenario voor ATM aangezien het geen manier heeft om te ontdekken of het verre eind ATM of Frame Relay is.

Opmerking: door afronding kan de vertraging die het resultaat oplevert iets hoger zijn dan de ingestelde vertraging. Deze afrondingsfout is belangrijker bij lage PVC’s.

U kunt optimalisatie ook handmatig configureren. Aangezien de grootte van het fragment niet rechtstreeks in Cisco IOS kan worden gespecificeerd, moet u de optimale grootte van het fragment berekenen en het naar een vertraging converteren. Wanneer u het fragment-formaat berekent, pas het bestand aan voor de datalink-overhead, omdat de MLP-code ervan uitgaat dat elke link HDLC-beheer (High-Level Data Link Control) is en 2 bytes van datalink-overhead heeft. Naast de HDLC-datalink-overhead bevat de MLP-code in zijn berekeningen de 8 bytes die uit de MLP-ID zijn samengesteld, het MLP-sequentienummer en de PPP-ID zoals in de eerste tabel hierboven wordt aangegeven.

Gebruik deze procedure om de vertraging te berekenen die in Cisco IOS moet worden ingesteld:

1. Bereken het theoretische fragment-formaat op basis van de gewenste vertraging en de bandbreedte van het PVC:

   fragment = bandwidth * delay / 8

2. Zorg ervoor dat het fragment een veelvoud van 48 bytes is, zodat het past in een integraal aantal ATM-cellen.

   De formule om de grootte van het celgelijnde fragment te berekenen is:

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

3. Pas de datalink-overhead aan die niet in aanmerking wordt genomen door MLP.

   Zoals eerder gezien, verschilt deze overhead op basis van de PVC-kenmerken. Neem de ATM-kant van het PVC in overweging, aangezien dit de kant is waarvoor u optimaliseert. In deze tabel wordt het aantal bytes van datalink-overhead aan de ATM-zijde weergegeven.

   FRF.8-modus	Doorzichtig		Vertaling
   Verkeersrichting	Frame Relay naar ATM	ATM en Frame Relay	Frame Relay naar ATM	ATM en Frame Relay
   Frame Relay of ATM-traject van PVC	ATM	ATM	ATM	ATM
   LLC DSAP/SSAP (0XEFE)	0	2	2	2
   LLC-regeling (0x03)	1	1	1	1
   NLPID (0xcf voor PPP)	1	1	1	1
   AAL5	8	8	8	8
   Non-MLP overhead (bytes)	10	12	12	12

   Om bij de grootte van het fragment te komen waarop MLP zijn berekeningen baseert, trekt u de datalink over van de gewenste cel-uitgelijnde fragment af. Voeg terug 2 bytes toe om de HDLC insluiting te compenseren die MLP altijd veronderstelt.

   De formule om de grootte van het fragment te berekenen dat de MLP-codedoelstellingen zijn:

   fragment_mlp = fragment_aligned - datalink_overhead + 2

4. Converteer het fragment dat resulteert in de corresponderende vertraging met deze formule:

   delay = fragment_mlp/bandwidth x 8bits/byte

5. In de meeste gevallen is de berekende vertraging geen integraal aantal milliseconden. Aangezien Cisco IOS slechts een integerwaarde accepteert, moet u omlaag draaien. Daarom is de vertragingswaarde die u in Cisco IOS met de hulp van de ppp multilink fragment-vertraging opdracht vormt:

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

6. Om de bovenstaande afrondingsfout te compenseren, dient u de bandbreedte te maximaliseren die door MLP wordt gebruikt om van vertraging naar fragment om te zetten. De lege bandbreedte die u in Cisco IOS met de hulp van het bandbreedtebevel vormt is:

   bandwidth = fragment_mlp/fragment_delay * 8

Deze tabel toont de optimale waarden van ppp multilink fragment-vertraging en bandbreedte voor de meest gebruikelijke PVC-snelheden. Er wordt een startvertraging van 10 msec aangenomen. Om de tabel te vereenvoudigen maken de berekeningen geen onderscheid tussen doorzichtig en vertaald PVC of tussen verkeersrichtingen. Het maximale verschil in data link overhead is slechts 2 bytes. Daarom is de straf voor het ontwerpen voor het ergste geval van 12 bytes klein. In de tabel wordt ook de "reëel" vertraging getoond die optreedt vanwege het feit dat u het fragment groter maakt, zodat fragmenten in een integraal aantal cellen passen.

traffic shaping en policing

Speciale aandacht wordt besteed aan traffic shaping en policing in een Frame Relay/ATM IW-omgeving. De kwesties in de Frame Relay-richting naar ATM zijn verschillend van de kwesties in de richting ATM en Frame Relay. Daarom wordt elk onderwerp afzonderlijk beschreven.

Het belangrijkste probleem in Frame Relay naar ATM-richting is de potentiële uitbreiding in bandbreedteverbruik wanneer u van frame naar cel gaat. Een 49 bytes frame aan de kant Frame Relay verbruikt bijvoorbeeld twee cellen, of 106 bytes, aan de ATM-zijde. Daarom kan niet worden aangenomen dat het duurzame celtarief (solvabiliteitskapitaalvereiste) gelijk is aan het vastgelegde informatietarief (CIR). Het slechtst denkbare scenario treedt op wanneer elk Frame Relay-frame 1 bytes bevat. Elk van deze bytes verbruikt een volledige 53 bytes cel aan de ATM-zijde. Dit extreme en onrealistische scenario stelt een solvabiliteitskapitaalvereiste van 53 maal de CIR voor. Twee meer realistische voorbeelden zijn:

• Een G.729 VoIP-pakket is 60 bytes lang, of 69 bytes (wanneer MLP en Frame Relay-overhead zijn meegeleverd). Op het ATM-gedeelte neemt het twee cellen of 106 bytes in. Als al het overgebrachte verkeer derhalve VoIP is, is een geschikte mapping een solvabiliteitscategorie = 106/69 = 1,5 x CIR.

• Een Telnet-pakket met één toetsenbord bevat 40 bytes van de TCP/IP-header en 1 bytes aan gegevens. Aan de kant Frame Relay bedraagt dit 56 bytes, inclusief overhead. Aan de ATM-zijde wordt dit pakket echter uitgebreid naar twee cellen. In dit geval, solvabiliteitskapitaalvereiste = 106/56 = 1,9 x CIR.

In Bijlage A van de ATM Forum-norm, BISDN Inter Carrier Interface (B-ICI) Specification, versie 2.0, worden twee methoden beschreven om de solvabiliteitseisen en de CIR in kaart te brengen. Hoewel beide een wetenschappelijke manier bieden om het solvabiliteitskapitaalvereiste uit het CIR af te leiden, is geen van beide nauwkeuriger dan de gegevens waarop zij worden toegepast. Een van de getallen die door de formules worden vereist is de typische frame-grootte, een getal dat moeilijk in een echt netwerk te bepalen is. Ook een getal dat kan veranderen omdat nieuwe toepassingen worden uitgevoerd op een bestaand ATM/Frame Relay-netwerk. De beste aanbeveling om dit probleem op te lossen is om nauw samen te werken met uw luchtvaartmaatschappij, aangezien hun politiebeleid van cruciaal belang zal zijn. Met de hulp van de vervoerder is een dergelijke faalveilige benadering mogelijk:

• Frame Relay naar ATM-richting - In Frame Relay naar ATM-richting moet de vervoerder alleen verkeer naar binnen controleren op het Frame Relay-inbraakpunt. Op de Frame Relay-switch die is aangesloten op het Frame Relay-aangesloten CPE-apparaat (Frame Relay Atlay), controleert de luchtvaartmaatschappij bijvoorbeeld het verkeer volgens de gecontracteerde CIR. Dit politiebeleid wordt in deze cijfers geïllustreerd. Vanaf het moment dat er verkeer in het netwerk is toegestaan, mag er geen toezicht meer plaatsvinden. De implicatie van dit controlebeleid is dat de gegevens die aan de kant Frame Relay worden ontvangen, mogen uitbreiden en gebruiken om alle bandbreedte die nodig is om celbelasting, AAL-overhead en opvulling toe te staan, om deze over het ATM-gedeelte van het netwerk te dragen. In de meeste gevallen is de vereiste ATM-bandbreedte minder dan tweemaal de gebruikte Frame Relay-bandbreedte.

  

• Richting ATM aan Frame Relay - In de richting van ATM aan Frame Relay wordt het tegenovergestelde ervaren. Bandbreedtegebruik wordt verminderd wanneer van ATM naar frame wordt gegaan als celbelasting, AAL-overhead en wanneer padding wordt verwijderd. Omdat het potentiële transmissietarief van de ATM-zijde echter veel hoger is dan dat van de Frame Relay-link is het correct instellen van de traffic shaping op de ATM-router essentieel voor de integriteit van de spraak. Als het vormgeven te los is, dan voedt de ATM router gegevens sneller dan de fysieke snelheid van de Frame Relay-link aan het andere einde. Als resultaat hiervan beginnen pakketten zich in de wachtrij op de FRF.8-switch te plaatsen. Op een gegeven moment, beginnen pakketten te vallen. en omdat de ATM/Frame Relay-netwerken geen onderscheid maken tussen spraak en gegevens, worden VoIP-pakketten ook verzonden.

  Als de vormgeving echter te restrictief is, lijdt de doorvoersnelheid ook. Vanwege de celbelasting van ATM wordt AAL overhead en padding verwijderd door het FRF.8 apparaat. Het verbruikt geen bandbreedte op de Frame Relay-link. Daarom kunt u de ATM-kant van het PVC enigszins oversubscripen. De hoeveelheid toegevoegde waarde en AAL - overhead varieert afhankelijk van de gemiddelde frame grootte en hoe agressief de fragmentatie is. Omdat je deze overhead niet nauwkeurig kunt kwalificeren, ben je er beter vanaf om het niet te optimaliseren. Aan de andere kant is de celbelasting volledig deterministisch. Het is 5 bytes voor elke 48 bytes van payload. U kunt optimaliseren voor celbelasting door het vormende doel op de ATM router in te stellen op 53/48 x solvabiliteitskapitaalvereiste. Het toezicht aan de kant van de luchtvaartmaatschappij moet worden ingesteld om deze lichte overinschrijving mogelijk te maken.

Hints en Caveats

• MLPoATM/Frame Relay wordt op dit moment alleen getest en ondersteund door een servicebeleid dat is aangesloten op de virtuele sjabloon of dialer-interfaces. Wanneer het servicebeleid wordt overschreden, kan dit ertoe leiden dat de functie niet werkt. Een voorbeeld hiervan is gedocumenteerd in Cisco bug ID CSCdu19313 (alleen geregistreerde klanten).

• MLPoATM/Frame Relay klonen twee virtuele toegangsinterfaces voor elk PVC. Eén daarvan vertegenwoordigt de PPP-link. De andere staat voor de MLP bundel. De opdracht Show ppp multilink wordt gebruikt om te vertellen welke is. Meerdere PPPoFR-koppelingen per bundel worden niet ondersteund. Het in één bundelverkeer plaatsen van twee PPPOFR-circuits zal niet goed over de stroomkringen worden verdeeld, aangezien de PPPOFR-bestuurder niet de stroomregelaar levert die de echte seriemensen wel hebben. MLPPP-taakverdeling over ATM of frame-relais kan aanzienlijk minder effectiviteit aantonen dan dezelfde taakverdeling over fysieke interface.

• Elk PVC wordt geassocieerd met vier verschillende interfaces, namelijk de fysieke interface, de subinterface en twee virtuele toegangsinterfaces. Alleen de MLP virtuele-toegangsinterface heeft de wachtrij in de wachtrij geplaatst. De andere drie interfaces moeten eerst in, first out (FIFO) wachtrijen hebben.

• Wanneer u een opdracht service-beleid op een virtuele sjabloon toepast, geeft Cisco IOS dit normale waarschuwingsbericht weer:

  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.
  

  Deze berichten zijn normaal. Het eerste bericht adviseert dat een service-beleid niet wordt ondersteund op de PPP virtuele-toegangsinterface. Het tweede bericht bevestigt dat het service-beleid van invloed is geweest op de MLP bundel virtuele toegang interface. Dit feit wordt geverifieerd met de hulp van de show interfaces virtuele toegang , toont de rij en toont de opdrachten van de beleid-kaart om het een rij vormmechanisme te controleren.

• PPP-verificatie is niet strikt vereist, aangezien een PVC is als een huurlijn. Echter, PPP de authenticatie is handig omdat het opdracht pop multilink weergeven dan wordt gebruikt om de naam van de router aan het andere einde van het PVC te bepalen.

• Frame Relay Traffic Shaping moet voor MLPoFR PVC’s op de Frame Relay-router worden ingeschakeld.

• Cisco IOS-softwarerelease 12.2 heeft eerst een maximum van 25 virtuele sjablonen per router ondersteund. Deze beperking kan van invloed zijn op de schaal van een ATM distributieruter als elk PVC van een uniek IP adres vereist is. De tijdelijke oplossing voor getroffen versies is om IP ongenummerd te gebruiken of dialerinterfaces te gebruiken in plaats van virtuele sjablonen. In Cisco IOS-softwarerelease 12.2(8)T wordt de ondersteuning verhoogd naar 200 virtuele sjablonen.

• Sommige serviceproviders ondersteunen nog geen PPP-vertaling op hun FRF.8-apparaten. Wanneer deze beperking van kracht is, moeten de aanbieders hun PVC’s voor een transparante modus configureren.

• De meeste voorbeelden in de Cisco IOS documentatie tonen configuraties die een Frame Relay of ATM subinterface omvatten. Deze subinterface heeft geen zin. De virtuele sjabloon moet alleen aan de fysieke interface worden toegevoegd. Het resultaat is een compacte en hanteerbare configuratie. Dit is met name belangrijk als er een groot aantal PVC’s is.

• Gebruik de opdracht voor multilink van het show ppp als een dwaas-bestendige manier om te bepalen of er een cel/frame-druppels op de drager zijn. Het enige acceptabele fragmentatieverlies is een veroorzaakt door CRC-fouten (Cyclic redundantie).

• Hoewel MLPoATM/Frame Relay is geïntroduceerd in Cisco IOS-softwarerelease 12.1(5)T, dicteren fouten in deze en latere releases dat zorg wordt genomen wanneer u de Cisco IOS-softwarerelease selecteert. Cisco raadt het gebruik van de nieuwste onderhoudsrelease van de Cisco IOS 12.2-mainstream aan. Andere VoIP-functies kunnen echter het gebruik van een andere Cisco IOS-softwarerelease bepalen, zoals 12.2(2)XT, indien Survivable Remote Site telefonie (SRST) nodig is. Deze tabel bevat een aantal bekende problemen. Wanneer u Cisco IOS selecteert, moet elke Cisco bug-ID tegen de gekozen IOS worden geëvalueerd.

casestudy

Inleiding

In deze sectie wordt een van de eerste klantimplementaties van de MLPoATM/Frame Relay-functie beschreven. De klant wordt aangeduid met de denkbeeldige naam XYZ Ltd. In 2001 verving XYZ Ltd hun PBX-systemen door een IP-telefonieoplossing. Als deel van dit project werd een nieuw IP-netwerk gebouwd. en Frame Relay/ATM interworking is geselecteerd voor WAN. De drager die de WAN-service biedt gebruikt Newbridge-switches om de ATM- en Frame Relay-services te leveren.

Netwerkoverzicht

Het XYZ Ltd-netwerk is een hub en een zogenaamd netwerk dat zesentwintig takken met twee kernsites verbindt. Elk van de kernsites wordt bediend door een E3 ATM verbonden Cisco 3660 router. Achttien van de zesentwintig takken zijn van middelgrote omvang. Ze hebben dubbele Frame Relay PVC’s die terug verbinden met de 3660s op de twee kernsites via ATM/Frame Relay IW. De overige acht bijkantoren zijn zeer klein. Zij verbinden zich terug aan de dichtstbijzijnde middelgrote tak door één Frame Relay PVC. Alle filiaalrouters zijn Cisco 2620. Een end-to-end ATM PVC sluit de twee 3660 routers aan op de twee hubsites. Dit getal illustreert de topologie.

Deze tabel toont de Frame Relay-toegangssnelheden en de CIR-waarde. De CIR varieert van 32 kbps tot 256 kbps. In de tabel wordt ook het maximale aantal gelijktijdige VoIP-oproepen weergegeven dat door elk PVC wordt gedragen.

Frame Relay Traffic Shaping wordt uitgevoerd door de sectorale routers. Boven de CIR is toegestaan. Cisco IOS traffic shaping is ingesteld om de toegangssnelheid in te stellen, met MINDER gelijk aan CIR. Als omgekeerde expliciete congestiemeldingen (BECN’s) van de drager worden ontvangen, dan gooit de router terug naar de mijnwerker. Deze benadering is tegen de aanbevelingen van Cisco wanneer VoIP via Frame Relay wordt uitgevoerd. Spraak is al in problemen gebracht tegen de tijd dat de router op congestiemeldingen heeft gereageerd. In dit geval is de vervoerder echter van mening dat zijn netwerk voldoende is om geen frames of cellen te laten vallen, en daarom mogen BECN’s nooit worden gezien.

ATM traffic shaping is ingesteld op de frame-toegangssnelheid aan het einde van de verbinding, plus celbelasting. Bijvoorbeeld, als de toegangssnelheid 512 Kbps is, dan is het solvabiliteitskapitaalvereiste ingesteld op 512x53/48 = 565 Kbps. Deze vormsnelheid wordt gebruikt om de doorvoersnelheid te maximaliseren. Dit is veilig omdat de celbelasting op het IW-punt wordt gestript. Het toezicht aan de kant van de drager is genereus, zodat de lichte overabonnement is toegestaan.

cRTP wordt over het WAN gebruikt. De hot spot wat CPU’s betreft, is Cisco 3660 distributierouter op kernlocatie 1. Door de getallen in de bovenstaande tabel toe te voegen, wordt bepaald dat het theoretische maximale aantal VoIP-oproepen dat deze router doorkruist, 102 oproepen is. De getallen van deze grafiek geven aan dat de lading van Cisco 3660 CPU voor 100 cRTP sessies (die snel geschakeld worden) ongeveer 50% is.

Virtuele sjablonen worden gebruikt met IP-genummerde WAN-koppelingen. Er is één virtuele sjabloon vereist per PVC dat mogelijk is aangezien het totale aantal PVC’s dat op elke Cisco 3660 is afgesloten, kleiner is dan 25.

Configuraties

Dit document gebruikt deze configuraties:

• Core ATM-router

• Vestigingsrouter voor 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

Gerelateerde informatie

• VoIP via Frame Relay met Quality-of-Service (fragmentatie, traffic shaping, LLQ/IP RTP-prioriteit)
• VoIP QoS voor Frame Relay naar ATM Interworking met LLQ, PPP LFI en cRTP
• Configuratie van Link Fragmentation en Interleaving voor Frame Relay en virtuele ATM-circuits
• PPP over AAL5, RFC 2364, juli 1998
• PPP in Frame Relay, RFC1973, juni 1996
• Het PPP Multilink Protocol (MP), RFC 1717, nov. 1994
• IP/UDP/RTP-koppen voor snelle seriële links, RFC 2508, februari 1999
• Frame Relay/ATM PVC Service Interworking-implementatieovereenkomst FRF.8.2
• Frame Relay Fragmentation Implementation Agreement voor FRF.12
• Ondersteuning voor spraaktechnologie
• Productondersteuning voor spraak- en IP-communicatie
• Probleemoplossing voor Cisco IP-telefonie
• Technische ondersteuning en documentatie – Cisco Systems