Définition et déploiement d'un protocole PPP à liaisons multiples sur Frame Relay et ATM

Introduction

Multilink PPP sur ATM et Multilink PPP sur Frame Relay (MLPoATM et MLPoFR) ont été introduits dans le logiciel Cisco IOS® version 12.1(5)T. Cette fonctionnalité s'adresse aux clients disposant d'une interconnexion Frame Relay/ATM (FR/ATM IW) qui déploient la voix sur IP (VoIP) sur des liaisons WAN de moyenne à basse vitesse. Avant cette fonctionnalité, aucun schéma de fragmentation de couche 2 commun pris en charge par Cisco IOS sur les clients ATM et Frame Relay avec FR/ATM IW n’était contraint de procéder à la fragmentation de couche 3.

Conditions préalables

Conditions requises

Ce document est destiné au personnel réseau impliqué dans la conception et le déploiement de réseaux VoIP impliquant des réseaux MLPoATM et Frame Relay. Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Relais de trames

• ATM

• PPP

• MLP

• Interopérabilité Frame Relay/ATM

• Configuration de la qualité de service (QoS) de la voix

Le présent document n'a pas pour objet de fournir une formation technologique sur ces sujets. Une liste des documents de référence figure à la fin du présent document. Cisco vous recommande de consulter et de comprendre ces documents avant de lire ce document :

• VoIP sur relais de trame avec qualité de service (fragmentation, formatage du trafic, LLQ / IP RTP Priority)

• QoS (Qualité de service) VoIP pour interopérabilité Frame Relay et ATM avec LLQ, PPP LFI et cRTP

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Logiciel Cisco IOS Version 12.1(5)T ou ultérieure pour MLP sur FR/ATM IW

• Logiciel Cisco IOS Version 12.2(2)T ou ultérieure pour protocole cRTP (Compressed Real Time Transport Protocol) sur ATM

• Logiciel Cisco IOS Version 12.0(7)T pour la mise en file d’attente à faible latence (LLQ) sur Frame Relay et ATM sur l’interface physique

• Logiciel Cisco IOS Version 12.1(2)T pour LLQ sur Frame Relay et ATM par circuit virtuel permanent (PVC)

L'étude de cas incluse dans ce document est basée sur un réseau de production qui utilise les versions logicielles et matérielles suivantes :

• Les routeurs Cisco 3660 principaux exécutent le logiciel Cisco IOS Version 12.2(5.8)T. La configuration requise pour cRTP sur ATM dicte l'utilisation du logiciel Cisco IOS Version 12.2T. Ce problème connu est résolu dans le logiciel Cisco IOS Version 12.2(8)T1 :

  ID de bogue Cisco CSCdw44216 (clients enregistrés uniquement) - cRTP provoque un CPU élevé lorsque la liaison CBWFQ/LLQ (class-based Weighted Fair Queueing) atteint un encombrement.

• Les routeurs Cisco 2620 de la filiale sont en cours de mise à niveau du logiciel Cisco IOS Version 12.2(3) vers une version 2.2(6a). Les routeurs Cisco 2620 servent également de passerelles H.323 de filiale. La mise à niveau est déclenchée par un problème lié à la passerelle. En ce qui concerne les fonctionnalités WAN et QoS, la version 12.2(3) du logiciel Cisco IOS ne présente aucun problème important.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Conception

Cette section traite de plusieurs concepts de conception liés à la conception et au déploiement du protocole PPP multiliaison sur Frame Relay et ATM.

Frais généraux de liaison de données

Lorsque vous concevez des réseaux ATM et Frame Relay avec MLP, vous devez comprendre la surcharge de liaison de données. Overhead influence la quantité de bande passante consommée par chaque appel VoIP. Il permet également de déterminer la taille de fragment MLP optimale. Il est essentiel d'optimiser la taille des fragments pour qu'ils s'adaptent à un nombre intégral de cellules ATM, en particulier sur les circuits virtuels permanents à faible vitesse où une quantité importante de bande passante est gaspillée sur le remplissage des cellules. La surcharge de liaison de données sur les circuits virtuels permanents MLP sur Frame Relay et ATM dépend de ces facteurs :

• Mode de fonctionnement du périphérique IW FRF.8 (transparent ou translationnel).

• Direction du trafic (ATM vers Frame Relay ou Frame Relay vers ATM).

• La jambe PVC. La surcharge est différente sur les pieds ATM et Frame Relay du circuit virtuel permanent.

• Type de trafic. Les paquets de données ont un en-tête MLP ; Les paquets VoIP ne le sont pas.

Ce tableau indique la surcharge de liaison de données pour un paquet de données. Il détaille le nombre d'octets dans les différents en-têtes Frame Relay, ATM, LLC, PPP et MLP pour toutes les permutations du mode de fonctionnement FRF.8, de la direction du trafic et de la branche PVC.

¹ DSAP/SSAP ^{: point d'accès du service de destination/point d'accès du service source.}

² NLPID ^{- Identification du protocole de couche réseau.}

Le PVC de traduction est le plus facile à comprendre, car la surcharge est la même dans les deux sens. En effet, le périphérique FRF.8 se traduit entre les formats MLPoATM et MLPoFR. Par conséquent, le format de trame est MLPoFR sur le tronçon Frame Relay dans les deux directions. Le format de la jambe ATM est MLPoATM dans les deux directions.

Le circuit virtuel permanent transparent est légèrement plus faible car la surcharge varie dans les deux directions. Cette complexité survient parce que le routeur Frame Relay envoie des paquets au format MLPoFR. Ce format est transporté par le périphérique IW côté ATM. De même, le routeur ATM envoie des paquets au format MLPoATM. Ce format est transporté par le périphérique IW du côté Frame Relay. Par conséquent, le résultat est différents formats de trame dans les deux directions sur chaque jambe.

En comparaison, la surcharge sur un circuit virtuel permanent Frame Relay de bout en bout qui utilise FRF.12 est de 11 octets. Par conséquent, sur une liaison Frame Relay de bout en bout, FRF.12 est un choix plus efficace pour la fragmentation et l’entrelacement des liaisons (LFI) que MLP. Sur les circuits virtuels ATM de bout en bout, le MLP est le seul choix car il n’existe aucune fragmentation normalisée. Cependant, les circuits virtuels ATM de bout en bout sont de moyenne à haute vitesse. Par conséquent, l'IF n'est pas nécessaire. L'exception à cette règle est la lenteur des circuits virtuels ATM sur ligne d'abonné numérique (DSL).

L'ID PPP est présent uniquement dans le premier fragment MLP. Par conséquent, la surcharge dans le premier fragment est toujours de deux octets de plus que dans les fragments suivants.

Le tableau ci-dessous indique la surcharge de liaison de données pour un paquet VoIP. Il détaille le nombre d’octets dans les différents en-têtes Frame Relay, ATM, LLC et PPP pour toutes les permutations du mode de fonctionnement FRF.8, de la direction du trafic et de la branche PVC. La principale différence entre un paquet de données et un paquet VoIP est que les paquets VoIP sont envoyés en tant que paquets PPP et non en tant que paquets MLP. Tous les autres aspects sont identiques au scénario de données.

En comparaison, la surcharge de liaison de données pour un paquet VoIP sur un circuit virtuel permanent Frame Relay de bout en bout est indiquée dans la colonne de droite.

Bande passante VoIP requise

Lorsque vous provisionnez la bande passante pour VoIP, la surcharge de liaison de données doit être incluse dans les calculs de bande passante. Ce tableau présente les besoins en bande passante par appel pour les différentes saveurs de VoIP. Il est basé sur les caractéristiques du circuit virtuel permanent. Les calculs de ce tableau supposent un scénario de référence pour cRTP (par exemple, aucune somme de contrôle UDP et aucune erreur de transmission). Les en-têtes sont ensuite compressés de 40 à 2 octets.

Comme la surcharge varie selon les différentes parties du circuit virtuel permanent, il est nécessaire de concevoir le scénario le plus défavorable. Par exemple, considérez G.729 avec échantillonnage de 20 millisecondes (ms) et cRTP sur un circuit virtuel permanent transparent. La bande passante requise pour ce scénario sur le tronçon Frame Relay est de 12,4 Kbits/s dans une direction et de 13,2 Kbits/s dans l’autre. Le provisionnement doit être effectué avec l'hypothèse de 13,2 Kbits/s par appel.

En comparaison, la bande passante VoIP requise sur un circuit virtuel permanent Frame Relay de bout en bout est également indiquée dans la colonne de droite du tableau ci-dessus. La surcharge supplémentaire du protocole PPP par rapport à l’encapsulation Frame Relay native entraîne une consommation de bande passante supplémentaire comprise entre 0,5 et 0,8 Kbits/s par appel. Par conséquent, l’encapsulation Frame Relay avec FRF.12 est plus logique que MLP sur un circuit virtuel Frame Relay de bout en bout.

Remarque : cRTP sur ATM nécessite le logiciel Cisco IOS version 12.2(2)T ou ultérieure.

Optimiser la taille de fragmentation

La raison d’utiliser MLP sur un circuit virtuel permanent Frame Relay/ATM est de permettre la fragmentation de paquets de données volumineux en petits blocs. Le routeur accélère ensuite les paquets VoIP en les entrelacant entre les fragments de données. Dans Cisco IOS, la taille de fragmentation n'est pas configurée directement. Au lieu de cela, le délai souhaité est configuré à l'aide de la commande ppp multilink fragment-delay. Cisco IOS utilise ensuite cette formule pour calculer la taille de fragment appropriée :

fragment size = delay x bandwidth/8

Lorsque vous effectuez des opérations MLP sur ATM, la taille des fragments doit être optimisée pour qu'elle s'insère dans un nombre intégral de cellules. Si cette optimisation n'est pas effectuée, la bande passante requise peut presque doubler en raison du remplissage. Par exemple, si chaque fragment a une longueur de 49 octets, deux cellules ATM sont nécessaires pour transporter chaque fragment. Par conséquent, 106 octets sont utilisés pour transporter une charge utile de seulement 49 octets.

Cisco IOS optimise automatiquement la taille des fragments pour utiliser un nombre intégral de cellules ATM lorsqu'il exécute MLPoATM et MLPoFR. Cisco IOS arrondit automatiquement la taille de fragment calculée au nombre intégral suivant de cellules ATM. Aucune nouvelle commande CLI n'est ajoutée. Cisco IOS effectue cette optimisation sur les extrémités Frame Relay et ATM d'un circuit virtuel permanent MLPoFR/ATM. Il est possible qu’un circuit virtuel permanent MLP soit un relais de trames de bout en bout. Dans ce cas, il n'est pas nécessaire de l'optimiser pour ATM. Cependant, Cisco IOS optimise ce scénario pour ATM, car il n’a aucun moyen de détecter si l’extrémité distante est ATM ou Frame Relay.

Remarque : en raison de l'arrondi, le délai de résultat peut être légèrement supérieur à celui configuré. Cette erreur d'arrondi est plus significative sur les circuits virtuels permanents à faible vitesse.

Vous pouvez également configurer l'optimisation manuellement. Comme la taille du fragment ne peut pas être spécifiée directement dans Cisco IOS, calculez la taille de fragment optimale et convertissez-la en délai. Lorsque vous calculez la taille du fragment, ajustez la surcharge de la liaison de données, car le code MLP suppose que chaque liaison est HDLC (High-Level Data Link Control) et comporte 2 octets de surcharge de liaison de données. Outre la surcharge de liaison de données HDLC, le code MLP inclut dans ses calculs les 8 octets composés de l'ID MLP, du numéro de séquence MLP et de l'ID PPP, comme indiqué dans le premier tableau ci-dessus.

Utilisez cette procédure afin de calculer le délai à configurer dans Cisco IOS :

1. Calculez la taille de fragment théorique en fonction du délai souhaité et de la bande passante du circuit virtuel permanent :

   fragment = bandwidth * delay / 8

2. Assurez-vous que le fragment est un multiple de 48 octets, de sorte qu'il s'insère dans un nombre intégral de cellules ATM.

   La formule de calcul de la taille de fragment aligné sur la cellule est la suivante :

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

3. Ajustez la surcharge de liaison de données qui n'est pas prise en compte par MLP.

   Comme nous l’avons vu précédemment, cette surcharge diffère selon les caractéristiques du circuit virtuel permanent. Considérez le côté ATM du circuit virtuel permanent, car il s'agit du côté pour lequel vous optimisez. Ce tableau indique le nombre d’octets de surcharge de liaison de données côté ATM.

   Mode FRF.8	Transparence		Traduction
   Direction du trafic	Frame Relay à ATM	ATM vers Frame Relay	Frame Relay à ATM	ATM vers Frame Relay
   Frame Relay ou segment ATM du circuit virtuel permanent	ATM	ATM	ATM	ATM
   LLC DSAP/SSAP (0xfefe)	0	2	2	2
   Contrôle LLC (0x03)	1	1	1	1
   NLPID (0xcf pour PPP)	1	1	1	1
   AAL5	8	8	8	8
   Frais généraux non MLP (octets)	10	12	12	12

   Pour obtenir la taille de fragment sur laquelle MLP base ses calculs, soustrayez la surcharge de liaison de données de la taille de fragment aligné sur la cellule souhaitée. Ajoutez 2 octets en arrière afin de compenser l'encapsulation HDLC que MLP assume toujours.

   Formule de calcul de la taille de fragment que le code MLP cible :

   fragment_mlp = fragment_aligned - datalink_overhead + 2

4. Convertissez la taille de fragment qui résulte en délai correspondant avec cette formule :

   delay = fragment_mlp/bandwidth x 8bits/byte

5. Dans la plupart des cas, le délai calculé n'est pas un nombre intégral de millisecondes. Puisque Cisco IOS accepte uniquement une valeur entière, vous devez arrondir. Par conséquent, la valeur de délai que vous configurez dans Cisco IOS à l'aide de la commande ppp multilink fragment-delay est la suivante :

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

6. Afin de compenser l'erreur d'arrondi ci-dessus, évitez la bande passante utilisée par MLP pour convertir le délai en fragment. La bande passante brouillée que vous configurez dans Cisco IOS à l'aide de la commande bandwidth est la suivante :

   bandwidth = fragment_mlp/fragment_delay * 8

Ce tableau montre les valeurs optimales de ppp multilink fragment-delay et de bande passante pour les vitesses de circuit virtuel permanent les plus courantes. Un délai cible de 10 ms est supposé. Afin de simplifier la table, les calculs ne différencient pas entre les circuits virtuels permanents transparents et les circuits virtuels de traduction, ni entre les directions de trafic. La différence maximale dans la surcharge de liaison de données est de seulement 2 octets. Par conséquent, la pénalité pour la conception pour le pire cas de 12 octets est faible. Le tableau montre également le délai « réel » rencontré en raison du fait que vous augmentez la taille du fragment de sorte que les fragments s'intègrent dans un nombre intégral de cellules.

Considérations relatives à la mise en forme et à la réglementation du trafic

Une attention particulière est accordée au formatage et à la réglementation du trafic dans un environnement IW Frame Relay/ATM. Les problèmes de la direction Frame Relay vers ATM sont différents des problèmes de la direction ATM vers Frame Relay. Par conséquent, chaque sujet est décrit séparément.

Le problème principal dans la direction Frame Relay vers ATM est l’augmentation potentielle de la consommation de bande passante lors du passage d’une trame à une autre. Par exemple, une trame de 49 octets du côté Frame Relay consomme deux cellules, ou 106 octets, du côté ATM. Par conséquent, on ne peut pas présumer que le taux de cellules durables (SCR) est égal au taux d'information garanti (CIR). Le pire scénario se produit lorsque chaque trame Frame Relay contient 1 octet de charge utile. Chacun de ces octets consomme une cellule complète de 53 octets côté ATM. À titre d'exemple de ce concept, ce scénario extrême et irréaliste impose un SCR 53 fois supérieur au CIR. Voici deux exemples plus réalistes :

• Un paquet VoIP G.729 mesure 60 octets ou 69 octets (lorsque la surcharge MLP et Frame Relay est incluse). Sur le tronçon ATM, il consomme deux cellules ou 106 octets. Par conséquent, si tout le trafic transporté est VoIP, un mappage approprié est SCR = 106/69 = 1,5 x CIR.

• Un paquet Telnet qui transporte un seul trait de clé contient 40 octets d’en-tête TCP/IP et 1 octet de données. Sur le côté Frame Relay, ce total est de 56 octets, y compris la surcharge. Cependant, du côté ATM, ce paquet s’étend à deux cellules. Dans ce cas, SCR = 106/56 = 1,9 x CIR.

L’annexe A de la norme ATM Forum, Spécification BISDN Inter Carrier Interface (B-ICI) Version 2.0, décrit deux méthodes de mappage entre SCR et CIR. Bien que les deux fournissent un moyen scientifique de déduire les SCR du CIR, aucune n'est plus précise que les données auxquelles elles sont appliquées. L’un des nombres requis par les formules est la taille de trame standard, un nombre difficile à déterminer dans un réseau réel. En outre, un numéro qui peut changer à mesure que de nouvelles applications sont déployées sur un réseau ATM/Frame Relay existant. La meilleure recommandation pour résoudre ce problème est de travailler en étroite collaboration avec votre transporteur puisque sa politique de police sera d'une importance cruciale. Avec l'aide du transporteur, cette approche sans échec est possible :

• Direction Frame Relay vers ATM - Dans la direction Frame Relay vers ATM, le transporteur doit contrôler le trafic entrant au point d’entrée Frame Relay uniquement. Par exemple, sur le commutateur Frame Relay connecté au périphérique CPE (Frame Relay Attached Customer Premises Equipment), le transporteur règle le trafic conformément au CIR contracté. Cette politique de police est illustrée dans la figure ci-contre. Aucune autre surveillance ne doit avoir lieu une fois que le trafic est autorisé sur le réseau au point d'entrée. Cette politique de réglementation implique que les données reçues du côté Frame Relay sont autorisées à se développer et à consommer toute bande passante nécessaire pour permettre la taxe sur les cellules, la surcharge AAL et le remplissage afin de les transporter sur le tronçon ATM du réseau. Dans la plupart des cas, la bande passante ATM requise est inférieure à deux fois la bande passante Frame Relay utilisée.

  

• Direction ATM-Frame Relay - Dans la direction ATM-Frame Relay, c’est le contraire qui se produit. L'utilisation de la bande passante est réduite lorsque vous passez d'ATM à la trame sous forme de taxe de cellule, de surcharge AAL et lorsque le remplissage est supprimé. Cependant, comme le débit de transmission potentiel du côté ATM est beaucoup plus élevé que celui de la liaison Frame Relay, la configuration correcte du formatage du trafic sur le routeur ATM est essentielle pour l’intégrité de la voix. Si la mise en forme est trop souple, le routeur ATM alimente les données à un débit supérieur à la vitesse physique de la liaison Frame Relay à l’autre extrémité. En conséquence, les paquets commencent à mettre en file d'attente sur le commutateur FRF.8. À un moment donné, les paquets commencent à tomber . et comme les réseaux ATM/Frame Relay ne font pas de distinction entre la voix et les données, les paquets VoIP sont également abandonnés.

  En même temps, si le formatage est trop restrictif, le débit en pâtit. En raison de la taxe sur les cellules ATM, la surcharge et le remplissage AAL sont supprimés par le périphérique FRF.8. Il ne consomme pas de bande passante sur la liaison Frame Relay. Par conséquent, vous pouvez surinscrire légèrement le côté ATM du circuit virtuel permanent. La quantité de remplissage et de surcharge AAL varie en fonction de la taille moyenne des trames et de l'agressivité de la fragmentation. Parce que vous ne pouvez pas qualifier correctement cette surcharge, il vaut mieux ne pas essayer d'optimiser pour elle. D'un autre côté, l'impôt sur les cellules est complètement déterministe. Elle est de 5 octets pour chaque 48 octets de données utiles. Vous pouvez optimiser la taxe sur les cellules en définissant la cible de mise en forme sur le routeur ATM sur 53/48 x SCR. La réglementation du côté transporteur doit être définie pour permettre cette légère sursouscription.

Conseils et astuces

• Actuellement, MLPoATM/Frame Relay est uniquement testé et pris en charge par une stratégie de service associée aux interfaces de modèle virtuel ou de numérotation. Si vous omettez la stratégie de service, la fonctionnalité peut ne pas fonctionner. Un exemple de ceci est documenté dans l'ID de bogue Cisco CSCdu19313 (clients enregistrés uniquement).

• MLPoATM/Frame Relay clone deux interfaces d’accès virtuel pour chaque circuit virtuel permanent. L’une d’elles représente la liaison PPP. L'autre représente le bundle MLP. La commande show ppp multilink permet de déterminer laquelle est. Plusieurs liaisons PPPoFR par offre groupée ne sont pas prises en charge. Le fait de placer deux circuits PPPOFR dans un seul trafic ne sera pas bien équilibré en charge sur les circuits, puisque le pilote PPPOFR ne fournit pas la signalisation de contrôle de flux que les vrais pilotes série font. L’équilibrage de charge MLPPP sur ATM ou Frame Relay peut présenter une efficacité nettement moindre que le même équilibrage de charge sur l’interface physique.

• Chaque circuit virtuel permanent est associé à quatre interfaces différentes, à savoir l’interface physique, la sous-interface et deux interfaces d’accès virtuel. Seule l'interface d'accès virtuel MLP a la mise en file d'attente sophistiquée activée. Les trois autres interfaces doivent avoir une mise en file d’attente FIFO (First In, First Out).

• Lorsque vous appliquez une commande service-policy à un modèle virtuel, Cisco IOS affiche ce message d'avertissement normal :

  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.
  

  Ces messages sont normaux. Le premier message indique qu'une stratégie de service n'est pas prise en charge sur l'interface d'accès virtuel PPP. Le deuxième message confirme que la stratégie de service a pris effet sur l'interface d'accès virtuel du bundle MLP. Ce fait est vérifié à l'aide des commandes show interfaces virtual-access, show queue et show policy-map interface pour vérifier le mécanisme de mise en file d'attente.

• L’authentification PPP n’est pas strictement requise car un circuit virtuel permanent est comme une ligne louée. Cependant, l'authentification PPP est pratique car la commande show ppp multilink est ensuite utilisée pour déterminer le nom du routeur à l'autre extrémité du circuit virtuel permanent.

• Le formatage du trafic Frame Relay doit être activé pour les circuits virtuels permanents MLPoFR sur le routeur Frame Relay.

• La version 12.2 du logiciel Cisco IOS prenait initialement en charge un maximum de vingt-cinq modèles virtuels par routeur. Cette limitation peut avoir un impact sur l’échelle d’un routeur de distribution ATM si chaque circuit virtuel permanent doit avoir une adresse IP unique. La solution de contournement pour les versions affectées consiste à utiliser IP non numéroté ou à utiliser des interfaces de numérotation au lieu de modèles virtuels. Dans le logiciel Cisco IOS Version 12.2(8)T, la prise en charge est augmentée à 200 modèles virtuels.

• Certains fournisseurs de services ne prennent pas encore en charge la traduction PPP sur leurs périphériques FRF.8. Chaque fois que cette limitation est en place, les fournisseurs doivent configurer leurs circuits virtuels permanents pour le mode transparent.

• La plupart des exemples de la documentation Cisco IOS montrent des configurations qui incluent une sous-interface Frame Relay ou ATM. Cette sous-interface ne sert à rien. Le modèle virtuel doit être simplement attaché à l'interface physique. Il en résulte une configuration plus compacte et plus facile à gérer. Ceci est particulièrement important s'il y a un grand nombre de circuits virtuels permanents.

• Utilisez la commande show ppp multilink comme une méthode infaillible pour déterminer s'il y a des pertes de cellules/trames du côté porteuse. La seule perte de fragment acceptable est une perte causée par des erreurs CRC (Cycles Redundancy Check).

• Bien que MLPoATM/Frame Relay ait été introduit dans la version 12.1(5)T du logiciel Cisco IOS, les bogues de cette version et des versions ultérieures imposent de prendre soin de vous lorsque vous sélectionnez la version du logiciel Cisco IOS. Cisco recommande d'utiliser la dernière version de maintenance de la plate-forme logicielle Cisco IOS 12.2. Cependant, d'autres exigences de fonctionnalités VoIP peuvent dicter l'utilisation d'une autre version du logiciel Cisco IOS, telle que 12.2(2)XT si Survivable Remote Site Telephony (SRST) est nécessaire. Ce tableau répertorie certains des problèmes connus. Lorsque vous sélectionnez Cisco IOS, chaque ID de bogue Cisco doit être évalué par rapport à l'IOS choisi.

Étude de cas

Introduction

Cette section décrit l'un des premiers déploiements client de la fonctionnalité MLPoATM/Frame Relay. Le client est référencé par le nom fictif XYZ Ltd. En 2001, XYZ Ltd a remplacé ses PBX par une solution de téléphonie IP. Dans le cadre de ce projet, un nouveau réseau IP a été créé. et l’interconnexion Frame Relay/ATM a été choisie pour le WAN. L’opérateur qui fournit le service WAN utilise des commutateurs Newbridge pour fournir les services ATM et Frame Relay.

Présentation du réseau

Le réseau XYZ Ltd est un réseau en étoile qui relie vingt-six filiales à deux sites principaux. Chacun des sites principaux est desservi par un routeur ATM E3 connecté au Cisco 3660. Dix-huit des vingt-six succursales sont de taille moyenne. Ils disposent de deux circuits virtuels permanents Frame Relay qui se connectent aux modèles 3660 sur les deux sites principaux via ATM/Frame Relay IW. Les huit autres branches sont très petites. Ils se connectent à la filiale de taille moyenne la plus proche via un seul circuit virtuel permanent Frame Relay. Tous les routeurs des filiales sont Cisco 2620. Un circuit virtuel permanent ATM de bout en bout connecte les deux routeurs 3660 aux deux sites concentrateurs. Cette figure illustre la topologie.

Ce tableau présente les vitesses d’accès Frame Relay et le débit de données garanti (CIR). Le débit de données garanti varie de 32 kbits/s à 256 kbits/s. Le tableau indique également le nombre maximal d'appels VoIP simultanés transportés par chaque circuit virtuel permanent.

Le formatage du trafic Frame Relay est effectué par les routeurs de filiale. La rafale au-delà du débit de données garanti est autorisée. Le formatage du trafic Cisco IOS est défini sur la forme de la vitesse d'accès, avec un minimum égal à CIR. Si des notifications d'encombrement explicites (BECN) en amont sont reçues du transporteur, le routeur revient au minimum. Cette approche est contraire aux recommandations de Cisco lors de la VoIP sur Frame Relay. La voix est déjà en panne au moment où le routeur a répondu aux notifications d’encombrement. Toutefois, dans ce cas, le transporteur estime que son réseau est suffisamment surdimensionné pour ne jamais abandonner aucune trame ou cellule. Par conséquent, les BECN ne doivent jamais être vus.

La mise en forme du trafic ATM est définie sur la vitesse d’accès aux trames à l’extrémité distante, plus la taxe sur les cellules. Par exemple, si la vitesse d'accès est de 512 Kbits/s, SCR est défini sur 512x53/48 = 565 Kbits/s. Ce débit de mise en forme est utilisé pour optimiser le débit. C'est sûr, car l'impôt sur les cellules est supprimé au point IW. La réglementation du côté opérateur est généreusement configurée de sorte que le léger surabonnement soit autorisé.

cRTP est utilisé sur le WAN. En ce qui concerne le CPU, le point chaud est le routeur de distribution Cisco 3660 sur le site principal 1. En ajoutant les numéros dans le tableau ci-dessus, il est déterminé que le nombre maximal théorique d'appels VoIP qui traversent ce routeur est de 102 appels. Les chiffres de performances de ce graphique indiquent que la charge CPU du Cisco 3660 pour les sessions 100 cRTP (commutées rapidement) est d'environ 50 %.

Les modèles virtuels sont utilisés avec des liaisons WAN numérotées IP. Un modèle virtuel est requis par circuit virtuel permanent, ce qui est possible car le nombre total de circuits virtuels permanents qui se terminent sur chaque Cisco 3660 est inférieur à vingt-cinq.

Configurations

Ce document utilise les configurations suivantes :

• Routeur ATM principal

• Routeur Frame Relay Branch

!--- 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

Informations connexes

• VoIP sur relais de trame avec qualité de service (fragmentation, formatage du trafic, LLQ / IP RTP Priority)
• QoS (Qualité de service) VoIP pour interopérabilité Frame Relay et ATM avec LLQ, PPP LFI et cRTP
• Configuration de la fragmentation et de l’entrelacement des liaisons pour les circuits virtuels Frame Relay et ATM
• PPP Over AAL5, RFC 2364, juillet 1998
• PPP dans Frame Relay, RFC1973, juin 1996
• Protocole PPP multiliaison (MP), RFC 1717, novembre 1994
• Compression des en-têtes IP/UDP/RTP pour les liaisons série à faible débit, RFC 2508, février 1999
• Accord de mise en oeuvre de l’interconnexion de services PVC Frame Relay/ATM FRF.8.2
• Accord FRF (1Frame Relay Fragmentation Implementation Agreement2)
• Assistance technique concernant la technologie vocale
• Support produit pour Voix et Communications IP
• Dépannage des problèmes de téléphonie IP Cisco
• Support et documentation techniques - Cisco Systems