Voix : Voix sur relais de trame (VOFR)

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

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Le PPP à liaisons multiples au-dessus de l'atmosphère et le PPP à liaisons multiples au-dessus du Relais de trames (MLPoATM et MLPoFR) ont été introduits dans la version de logiciel 12.1(5)T de Cisco IOSÝ. Cette caractéristique est destiné aux clients avec l'interworking de la vue Relay/ATM (FR/ATM IW) qui déploient la voix sur ip (VoIP) à travers le support vers les liens WAN à vitesse réduite. Avant cette caractéristique, il n'y avait aucune structure de fragmentation commune de la couche 2 qui a été prise en charge par Cisco IOS sur l'atmosphère et les clients de Relais de trames avec FR/ATM IW ont été forcées à faire la fragmentation de la couche 3.

Conditions préalables

Conditions requises

Ce document est destiné pour le personnel de réseau impliqué dans la conception et le déploiement des réseaux VoIP qui impliquent des réseaux de MLPoATM et de Relais de trames. Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • Relais de trames

  • Atmosphère

  • PPP

  • MLP

  • Interworking de la vue Relay/ATM

  • Qualité vocale de configuration de service (QoS)

Ce document n'est pas destiné pour fournir la formation en technologie sur ces sujets. Une liste de manuels de référence est incluse à la fin de ce document. Cisco recommande que vous examiniez et comprenniez ces documents avant de lire ce document :

Composants utilisés

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 plus tard pour MLP au-dessus de FR/ATM IW

  • Logiciel Cisco IOS version 12.2(2)T ou plus tard pour le protocole de transport en temps réel comprimé (cRTP) au-dessus de l'atmosphère

  • Logiciel Cisco IOS version 12.0(7)T pour le bas temps d'attente s'alignant (LLQ) au-dessus du Relais de trames et de l'atmosphère sur l'interface physique

  • Logiciel Cisco IOS version 12.1(2)T pour LLQ au-dessus de Relais de trames et d'atmosphère par circuit virtuel permanent (PVC)

L'étude de cas incluse dans ce document est basée sur un réseau de production qui utilise ces le logiciel et les versions de matériel :

  • La principale version du logiciel Cisco IOS 12.2(5.8)T de passage de Routeurs de Cisco 3660. La condition requise pour le cRTP au-dessus de l'atmosphère dicte l'utilisation de la version du logiciel Cisco IOS 12.2T. Ce problème connu est résolu dans le Logiciel Cisco IOS version 12.2(8)T1 :

    Le cRTP de l'ID de bogue Cisco CSCdw44216 (clients enregistrés seulement) - entraîne la CPU de haute quand le lien du Mise en file d'attente pondérée basée sur les classes (CBWFQ) /LLQ atteint l'encombrement.

  • Le branchement Cisco 2620 Routeurs sont en cours d'être améliorée du Logiciel Cisco IOS version 12.2(3) à un 2.2(6a). Cisco 2620s agissent également en tant que Passerelles H.323 de branchement. La mise à jour est déclenchée par une question liée à la passerelle. En ce qui concerne le WAN et le QoS des caractéristiques, Logiciel Cisco IOS version 12.2(3) ne montre aucune question significative.

Conventions

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

Conception

Cette section discute plusieurs concepts de construction liés à la conception et au déploiement du PPP à liaisons multiples au-dessus du Relais de trames et de l'atmosphère.

Liaison de données supplémentaire

Quand vous concevez l'atmosphère et les réseaux de Relais de trames avec MLP, vous devez comprendre le temps système de liaison de données. Supplémentaire influence la quantité de bande passante consommée par chaque appel VoIP. Il aide également à déterminer la taille de fragment de l'optimum MLP. Il est essentiel d'optimiser la taille de fragment pour adapter un nombre entier de cellules atmosphère, particulièrement sur PVCs à basse vitesse où une importante quantité de bande passante est gaspillée sur la remplissage de cellules. La liaison de données supplémentaire sur MLP au-dessus de Relais de trames et d'ATM PVC dépend de ces facteurs :

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

  • La direction du trafic (atmosphère au Relais de trames ou au Relais de trames à l'atmosphère).

  • Le tronçon PVC. Le temps système est différent sur l'atmosphère et les tronçons de Relais de trames du PVC.

  • Le type de trafic. Les paquets de données ont une en-tête MLP ; Les paquets VoIP ne font pas.

Cette table affiche le temps système de liaison de données pour un paquet de données. Il détaille le nombre d'octets dans les diverses en-têtes de Relais de trames, atmosphère, LLC, de PPP, et MLP pour toutes les permutations du mode de fonctionnement FRF.8, de la direction du trafic, et du tronçon PVC.

Mode FRF.8 Transparent Traduction
Direction du trafic Relais de trames à l'atmosphère Atmosphère au Relais de trames Relais de trames à l'atmosphère Atmosphère au Relais de trames
Relais de trames ou tronçon atmosphère de PVC Relais de trames Atmosphère Atmosphère Relais de trames Relais de trames Atmosphère Atmosphère Relais de trames
                 
Indicateur de trame (0x7e) 1 0 0 1 1 0 0 1
En-tête de relais de trame 2 0 0 2 2 0 0 2
LLC DSAP/SSAP1 (0xfefe) 0 0 2 2 0 2 2 0
Le LLC contrôlent (0x03) 1 1 1 1 1 1 1 1
NLPID2 (0xcf pour le PPP) 1 1 1 1 1 1 1 1
ID MLP Protocol (0x003d) 2 2 2 2 2 2 2 2
Numéro de séquence MLP 4 4 4 4 4 4 4 4
ID de protocole PPP (premier fragment seulement) 2 2 2 2 2 2 2 2
Charge utile (couche 3+) 0 0 0 0 0 0 0 0
Couche d'adaptation atmosphère (AAL) 5 0 8 8 0 0 8 8 0
Frame Check Sequence (FCS) 2 0 0 2 2 0 0 2
Temps système total (octets) 15 18 20 17 15 20 20 15

1DSAP/SSAP — Point d'accès de destination de service/point d'accès de source de service.

2NLPID — Identification de Protocol de couche réseau.

Il est le plus facile comprendre Le PVC translationnel car le temps système est identique dans les deux directions. C'est parce que le périphérique FRF.8 se traduit entre les formats de MLPoATM et de MLPoFR. En conséquence, le format de trame est MLPoFR sur le tronçon de Relais de trames dans les deux directions. Le format sur le tronçon atmosphère est MLPoATM dans les deux directions.

Le PVC transparent est légèrement plus malpropre parce que le temps système diffère dans les deux directions. Cette complexité surgit parce que le routeur Frame Relay envoie des paquets dans le format de MLPoFR. Ce format est porté à travers par le périphérique IW sur le côté atmosphère. De même, le routeur atmosphère envoie des paquets dans le format de MLPoATM. Ce format est porté à travers par le périphérique IW sur le côté relais de trame. Par conséquent, le résultat est différents formats de trame dans les deux directions sur chaque tronçon.

En comparaison, le temps système sur un PVC de bout en bout de Relais de trames qui utilise le FRF.12 est de 11 octets. Par conséquent, sur un lien de Relais de trames de bout en bout, le FRF.12 est un choix plus efficace pour le Fonction Link Fragmentation and Interleaving (LFI) que MLP. Sur les circuits virtuels ATM de bout en bout (VCs), MLP est le seul choix puisqu'il n'y a aucune fragmentation basée sur des standards disponible. Cependant, les atmosphères de bout en bout VCs sont moyennes à la grande vitesse. Par conséquent, LFI n'est pas exigé. L'exception à la règle est atmosphère VCs de vitesse lente au-dessus de la ligne d'abonné numérique (DSL).

L'ID de PPP est présent dans le premier fragment MLP seulement. Par conséquent, le temps système dans le premier fragment est toujours deux octets davantage que dans les fragments ultérieurs.

La table ici affiche le temps système de liaison de données pour un paquet VoIP. Il détaille le nombre d'octets dans les diverses en-têtes de Relais de trames, atmosphère, LLC, et de PPP pour toutes les permutations du mode de fonctionnement FRF.8, de la direction du trafic, et du tronçon PVC. La principale différence entre des données et un paquet VoIP est que des paquets VoIP sont envoyés comme paquets PPP et pas comme paquets MLP. Tous autres aspects sont identiques au scénario de données.

Mode FRF.8 Transparent Traduction Relais de trames au Relais de trames
Direction du trafic Relais de trames à l'atmosphère Atmosphère au Relais de trames Relais de trames à l'atmosphère Atmosphère au Relais de trames  
Relais de trames ou tronçon atmosphère de PVC Relais de trames Atmosphère Atmosphère Relais de trames Relais de trames Atmosphère Atmosphère Relais de trames  
                   
Indicateur de trame (0x7e) 1 0 0 1 1 0 0 1 1
En-tête de relais de trame 2 0 0 2 2 0 0 2 2
LLC DSAP/SSAP (0xfefe) 0 0 2 2 0 2 2 0 0
Le LLC contrôlent (0x03) 1 1 1 1 1 1 1 1 1
NLPID (0xcf pour le PPP) 1 1 1 1 1 1 1 1 1
ID DE PPP 2 2 2 2 2 2 2 2 0
Charge utile (Protocole UDP (User Datagram Protocol) +RTP+Voice IP+) 0 0 0 0 0 0 0 0 0
AAL5 0 8 8 0 0 8 8 0 0
FCS 2 0 0 2 2 0 0 2 2
Temps système total (octets) 9 12 14 11 9 14 14 9 7

En comparaison, la liaison de données supplémentaire pour un paquet VoIP sur un PVC de bout en bout de Relais de trames est affichée dans la colonne d'extrême droite.

Bandes passantes nécessaires VoIP

Quand vous provision la bande passante pour le VoIP, le temps système de liaison de données doit être inclus dans les calculs de bande passante. Cette table affiche par bandes passantes nécessaires d'appel pour les diverses saveurs du VoIP. Il est basé sur les caractéristiques du PVC. Les calculs dans cette table assument un scénario le plus optimiste pour le cRTP (par exemple, aucune somme de contrôle d'UDP et aucune erreur de transmission.) Des en-têtes alors sont uniformément compressées de 40 octets à 2 octets.

Mode FRF.8 Transparent Traduction Relais de trames au Relais de trames
Direction du trafic Relais de trames à l'atmosphère Atmosphère au Relais de trames Relais de trames à l'atmosphère Atmosphère au Relais de trames  
Relais de trames ou tronçon atmosphère de PVC Relais de trames Atmosphère Atmosphère Relais de trames Relais de trames Atmosphère Atmosphère Relais de trames  
                   
G.729 - 20 échantillons de ms - aucun cRTP 27.6 42.4 42.4 28.4 27.6 42.4 42.4 27.6 26.8
G.729 - 20 échantillons de ms - cRTP 12.4 21.2 21.2 13.2 12.4 21.2 21.2 12.4 11.6
G.729 - 30 échantillons de ms - aucun cRTP 20.9 28.0 28.0 21.4 20.9 28.0 28.0 20.9 20.3
G.729 - 30 échantillons de ms - cRTP 10.8 14.0 14.0 11.4 10.8 14.0 14.0 10.8 10.3
G.711 - 20 échantillons de ms - aucun cRTP 83.6 106.0 106.0 84.4 83.6 106.0 106.0 83.6 82.8
G.711 - 20 échantillons de ms - cRTP 68.4 84.8 84.8 69.2 68.4 84.8 84.8 68.4 67.6
G.711 - 30 échantillons de ms - aucun cRTP 76.3 97.9 97.9 76.8 76.3 97.9 97.9 76.3 75.8
G.711 - 30 échantillons de ms - cRTP 66.3 84.0 84.0 66.8 66.3 84.0 84.0 66.3 65.7

Puisque le temps système varie sur les différents tronçons du PVC, il est nécessaire de concevoir pour le pire scénario. Par exemple, considérez G.729 avec l'échantillonnage et le cRTP de 20 millisecondes (milliseconde) à travers un PVC transparent. Les bandes passantes nécessaires pour ce scénario sur le tronçon de Relais de trames est de 12.4 Kbps dans une direction et de 13.2 Kbps dans l'autre. Le ravitaillement doit être fait avec l'hypothèse de 13.2 Kbps par appel.

En comparaison, la bande passante nécessaire VoIP sur un PVC de bout en bout de Relais de trames est également affichée dans la colonne d'extrême droite de la table ci-dessus. Le temps système supplémentaire du PPP a comparé aux résultats indigènes d'Encapsulation de relais de trames dans une consommation de bande passante supplémentaire entre 0.5 Kbps et 0.8 Kbps par appel. Par conséquent, l'Encapsulation de relais de trames avec le FRF.12 semble plus de raisonnable que MLP sur un circuit virtuel à relais de trame de bout en bout.

Remarque: le cRTP au-dessus de l'atmosphère exige le Logiciel Cisco IOS version 12.2(2)T ou plus tard.

Optimisez la taille de fragmentation

La raison d'utiliser MLP sur un PVC de la vue Relay/ATM est de tenir compte pour que les grands paquets de données soient fragmentés dans de plus petits blocs. Le routeur expédie alors des paquets VoIP en les intercalant entre les fragments de données. Dans le Cisco IOS, la taille de fragmentation n'est pas configurée directement. Au lieu de cela, le retard désiré est configuré avec l'aide de la commande de ppp multilink fragment delay. Le Cisco IOS emploie alors cette formule pour calculer la taille de fragment appropriée :

fragment size = delay x bandwidth/8

Quand vous faites MLP à travers l'atmosphère, la taille de fragment doit être optimisée de sorte qu'elle s'insère dans un nombre entier de cellules. Si cette optimisation n'est pas faite, la bande passante exigée peut presque doubler en raison de compléter. Par exemple, si chaque fragment est de 49 octets de long, deux cellules atmosphère sont exigées pour porter chaque fragment. Par conséquent, 106 octets sont utilisés pour porter une charge utile de seulement 49 octets.

Le Cisco IOS optimise automatiquement la taille de fragment pour utiliser un nombre entier de cellules atmosphère quand elle exécute MLPoATM et MLPoFR. Le Cisco IOS arrondit automatiquement la taille de fragment calculée au prochain nombre intégral de cellules atmosphère. Aucune nouvelle commande CLI n'est ajoutée. Le Cisco IOS exécute cette optimisation sur le Relais de trames et des extrémités atmosphère d'un PVC MLPoFR/ATM. Il est possible qu'un PVC MLP puisse être Relais de trames de bout en bout. Dans ce cas, l'optimiser pour l'atmosphère n'est pas exigé. Cependant, le Cisco IOS optimise ce scénario pour l'atmosphère puisqu'elle n'a aucune manière de détecter si l'extrémité distante est atmosphère ou Relais de trames.

Remarque: En raison de l'arrondissage, le retard qui résulte peut être légèrement le supérieur à qui a configuré. Cette erreur d'arrondissage est plus significative sur PVCs à vitesse réduite.

Vous pouvez également configurer l'optimisation manuellement. Puisque la taille de fragment ne peut pas être spécifiée directement dans le Cisco IOS, calculer la taille de fragment optimale et la convertir en retard. Quand vous calculez la taille de fragment, ajustez pour le temps système de liaison de données, comme le code MLP suppose que chaque lien est High-Level Data Link Control (HDLC) et a 2 octets de temps système de liaison de données. En plus de la liaison de données HDLC supplémentaire, le code MLP inclut dans ses calculs que les 8 octets ont composé de l'ID MLP, le numéro de séquence MLP, et l'ID de PPP conformément à la première table ci-dessus.

Employez cette procédure afin de calculer le retard à configurer dans le Cisco IOS :

  1. Calculez la taille de fragment théorique basée sur le retard désiré et la bande passante du PVC :

    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 entier de cellules atmosphère.

    La formule pour calculer la taille de fragment alignée par cellule est :

    fragment_aligned = (int(fragment/48)+1)*48
  3. Ajustez pour le temps système de liaison de données qui n'est pas pris en considération par MLP.

    Comme vu plus tôt, ce temps système diffère basé sur les caractéristiques PVC. Considérez le côté atmosphère du PVC car c'est le côté pour lequel vous optimisez. Cette table affiche le nombre d'octets de liaison de données supplémentaires du côté atmosphère.

    Mode FRF.8 Transparent Traduction
    Direction du trafic Relais de trames à l'atmosphère Atmosphère au Relais de trames Relais de trames à l'atmosphère Atmosphère au Relais de trames
    Relais de trames ou tronçon atmosphère de PVC Atmosphère Atmosphère Atmosphère Atmosphère
             
    LLC DSAP/SSAP (0xfefe) 0 2 2 2
    Le LLC contrôlent (0x03) 1 1 1 1
    NLPID (0xcf pour le PPP) 1 1 1 1
    AAL5 8 8 8 8
             
    Non MLP supplémentaire (octets) 10 12 12 12

    Pour arriver à la taille de fragment sur laquelle MLP base ses calculs, soustrayez le temps système de liaison de données de la taille de fragment cellule-alignée désirée. Ajoutez de retour 2 octets afin de compenser l'encapsulation HDLC que MLP assume toujours.

    La formule pour calculer la taille de fragment que les cibles de code MLP est :

    fragment_mlp = fragment_aligned - datalink_overhead + 2
  4. Convertissez la taille de fragment qui des résultats dans le retard correspondant avec cette formule :

    delay = fragment_mlp/bandwidth x 8bits/byte
  5. Dans la plupart des cas, le retard calculé n'est pas un nombre entier de millisecondes. Puisque le Cisco IOS reçoit seulement une valeur entière, vous devez arrondir vers le bas. Par conséquent, la valeur de retard que vous configurez dans le Cisco IOS avec l'aide de la commande de ppp multilink fragment delay est :

    fragment_delay = int(fragment_mlp/bandwidth x 8bits/byte)
  6. Afin de compenser l'erreur d'arrondissage ci-dessus, esquivez la bande passante utilisée par MLP pour convertir du retard pour fragmenter. La bande passante esquivée que vous configurez dans le Cisco IOS avec l'aide de la commande bandwidth est :

    bandwidth = fragment_mlp/fragment_delay * 8

Cette table affiche les valeurs optimales du ppp multilink fragment delay et de la bande passante pour les vitesses PVC les plus communes. Un retard de cible de 10 millisecondes est assumé. Afin de simplifier la table, les calculs ne différencient pas entre le PVC transparent et translationnel, ou entre les directions du trafic. La différence maximum dans le temps système de liaison de données est seulement 2 octets. Par conséquent, la pénalité pour concevoir pour le le pire des cas de 12 octets est petite. Également affiché dans la table est le « vrai » retard qui est dû produit au fait que vous augmentez la taille de fragment de sorte que les fragments s'insèrent dans un nombre entier de cellules.

Vitesse PVC Taille de fragment fragment-retard de multi-lien de ppp Bande passante Vrai retard
(Kbps) (cellules) (milliseconde) (Kbps) (milliseconde)
56 2 12 57 13.7
64 2 10 68 12.0
128 4 11 132 12.0
192 6 11 202 12.0
256 7 10 260 10.5
320 9 10 337 10.8
384 11 10 414 11.0
448 12 10 452 10.3
512 14 10 529 10.5
576 16 10 606 10.7
640 17 10 644 10.2
704 19 10 721 10.4
768 21 10 798 10.5

Le trafic formant et maintenant l'ordre des considérations

L'attention spéciale pour trafiquer la formation et le maintien de l'ordre d'un environnement de la vue Relay/ATM IW. Les questions dans le Relais de trames à la direction atmosphère sont différentes aux questions en atmosphère à la direction de Relais de trames. Par conséquent, chaque thème est décrit séparément.

Le problème principal dans le Relais de trames à la direction atmosphère est l'extension potentielle dans la consommation de bande passante en allant de la trame à la cellule. Par exemple, une trame de 49 octets du côté relais de trame consomme deux cellules, ou 106 octets, du côté atmosphère. Par conséquent, il ne peut pas supposer que le débit de cellules soutenable (SCR) égale le débit de données garanti (CIR). Le scénario de le pire des cas se produit quand chaque trame de Relais de trames contient 1 octet de la charge utile. Chacun de ces octets consomme une pleine cellule de 53 octets du côté atmosphère. Comme un exemple de ce concept, ce scénario extrême et irréaliste dicte une SCR qui est 53 fois le CIR. Deux exemples plus réalistes sont :

  • G.729 un paquet VoIP est de 60 octets de long, ou de 69 octets (quand MLP et temps système de Relais de trames sont inclus). Sur le tronçon atmosphère, il consomme deux cellules ou 106 octets. Par conséquent, si tout le trafic porté est VoIP, puis un mappage approprié est SCR = 106/69 = 1.5 x CIR.

  • Un paquet de telnet qui porte une touche simple contient 40 octets d'en-tête TCP/IP et de 1 octet de données. Du côté relais de trame, ceci se monte à 56 octets, y compris le temps système. Cependant, du côté atmosphère ce paquet développe à deux cellules. Dans ce cas, SCR = 106/56 = 1.9 x CIR.

L'annexe A de la norme du forum ATM, version 2.0 inter de spécification de l'interface de transporteur BISDN (B-ICI), décrit deux méthodes de cartographie entre la SCR et le CIR. Tandis que chacun des deux fournissent une manière scientifique de dériver la SCR du CIR, ni l'un ni l'autre est plus précis que les données auxquelles elles sont appliquées. Un des nombres exigés par les formules est la taille de trame typique, un nombre il est difficile de déterminer que dans un réseau réel. En outre, un nombre qui peut potentiellement changer pendant que de nouvelles applications sont déroulées sur un réseau existant de relais ATM/Frame. La meilleure recommandation de résoudre ce problème est de fonctionner étroitement avec votre transporteur puisque leur stratégie de maintien de l'ordre sera d'importance essentielle. Avec l'assistance du transporteur, cette approche de sécurité est possible :

  • Relais de trames à la direction atmosphère - Dans le Relais de trames à la direction atmosphère, le transporteur doit maintenir l'ordre le trafic d'arrivée au point d'entrée de Relais de trames seulement. Par exemple, sur le commutateur connecté de Relais de trames au périphérique de la CPE relié par Relais de trames (CPE), le transporteur maintient l'ordre le trafic selon le CIR contracté. Cette stratégie de maintien de l'ordre est illustrée dans la figure ici. Aucun autre maintien de l'ordre ne devrait se produire une fois le trafic est autorisé dans le réseau au point d'entrée. L'implication de cette stratégie de maintien de l'ordre est que des données reçues du côté relais de trame sont permises pour développer et consommer Qu'est ce que bande passante est exigée pour tenir compte de la taxe de cellules, du temps système AAL, et de la remplissage afin de la porter à travers le tronçon atmosphère du réseau. Dans la plupart des cas, la bande passante atmosphère exigée est moins de deux fois la bande passante de Relais de trames utilisée.

    http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-ingress-policing.gif

  • Atmosphères à la direction de Relais de trames - En atmosphère à la direction de Relais de trames, l'opposé est expérimenté. L'utilisation de la bande passante est réduite en allant de l'atmosphère encadrer comme taxe de cellules, temps système AAL, et quand compléter est retiré. Cependant, parce que le potentiel transmettent le débit du côté atmosphère est beaucoup de supérieur à qui le lien de Relais de trames, installant le trafic formant correctement sur le routeur atmosphère critique pour l'intégrité de la Voix. Si la formation est trop lâche, alors le routeur atmosphère alimente des données un débit plus rapide que la vitesse physique du lien de Relais de trames à l'autre extrémité. En conséquence, les paquets commencent la queue sur le commutateur FRF.8. À un certain point, début de paquets à relâcher. et puisque les réseaux de relais ATM/Frame ne distinguent pas la Voix et les données, des paquets VoIP sont également lâchés.

    En même temps, si la formation est trop restrictive, puis le débit souffre. En raison de la taxe de cellule ATM, le temps système et la remplissage AAL est enlevé par le périphérique FRF.8. Il ne consomme pas la bande passante sur le lien de Relais de trames. Par conséquent, vous pouvez oversubscribe le côté atmosphère du PVC légèrement. La quantité de remplissage et de temps système AAL varie dépendre des tailles de trame moyennes et combien agressif la fragmentation est. Puisque vous ne pouvez pas exactement qualifier ce temps système, vous êtes ne pas essayer plus aisé à optimiser pour lui. D'autre part, la taxe de cellules est complètement déterministe. C'est de 5 octets pour chaque 48 octets de la charge utile. Vous pouvez optimiser pour la taxe de cellules en fixant l'objectif de formation sur le routeur atmosphère à 53/48 SCR x. Le maintien de l'ordre du côté porteuse doit être placé pour tenir compte de ce léger surabonnement.

Signes et mises en garde

  • MLPoATM/Relais de trames est actuellement seulement testé et pris en charge avec une service-stratégie reliée au virtual-template ou aux interfaces de numérotation. Omettre la service-stratégie peut faire ne pas fonctionner la caractéristique. Un exemple de ceci est documenté dans l'ID de bogue Cisco CSCdu19313 (clients enregistrés seulement).

  • MLPoATM/Relais de trames copie deux interfaces d'accès virtuel pour chaque PVC. Un de ces derniers représente le lien de PPP. L'autre représente le paquet MLP. La commande de show ppp multilink est utilisée de dire ce qui est quel. De plusieurs liens de PPPoFR par paquet n'est pas pris en charge. La mise de deux circuits PPPOFR dans l'un trafic de paquet ne sera pas chargement équilibré bien à travers les circuits, puisque le gestionnaire PPPOFR ne fournit pas la signalisation de contrôle de flux que les vrais gestionnaires séquentiels font. L'Équilibrage de charge MLPPP au-dessus de l'atmosphère ou du Relais de trames pourrait afficher sensiblement moins d'efficacité que le même Équilibrage de charge au-dessus de l'interface physique.

  • Chaque PVC est associé avec quatre interfaces différentes, à savoir l'interface physique, la sous-interface, et deux interfaces d'accès virtuel. Seulement l'interface d'accès virtuel MLP a la Mise en file d'attente de fantaisie activée. Les trois autres interfaces doivent avoir d'abord dedans, d'abord (FIFO) queue.

  • Quand vous appliquez une commande de service-stratégie à un virtual-template, le 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 informe qu'une service-stratégie n'est pas prise en charge sur l'interface d'accès virtuel de PPP. Le deuxième message confirme que la service-stratégie l'a pris effet sur l'interface d'accès virtuel de paquet MLP. Ce fait est vérifié avec l'aide des commandes de show interfaces virtual-access, de show queue et de show policy-map interface de vérifier le mécanisme de mise en file d'attente.

  • L'authentification de PPP n'est pas strictement exigée puisqu'un PVC est comme une ligne louée. Cependant, l'authentification de PPP est pratique car la commande de show ppp multilink est alors utilisée de déterminer le nom du routeur à l'autre bout du PVC.

  • Le Formatage du trafic de relais de trames doit être activé pour MLPoFR PVCs sur le routeur Frame Relay.

  • Le Logiciel Cisco IOS version 12.2 a au commencement pris en charge un maximum de vingt-cinq modèles virtuels par routeur. Cette limite peut affecter l'échelle d'un routeur de distribution atmosphère si chaque PVC est exigé pour avoir une adresse IP unique. Le contournement pour des versions affectées est d'utiliser l'ip unnumbered ou d'utiliser des interfaces de numérotation au lieu des modèles virtuels. Dans le Logiciel Cisco IOS version 2.2(8)T, le support est grimpé jusqu'à 200 modèles virtuels.

  • Quelques fournisseurs de services ne prennent en charge pas encore la traduction de PPP sur leurs périphériques FRF.8. Toutes les fois que cette limite est en place, les fournisseurs doivent configurer leur PVCs pour le mode transparent.

  • La plupart des exemples dans la documentation Cisco IOS affichent les configurations qui incluent un Relais de trames ou une sous-interface ATM. Cette sous-interface n'atteint aucun objectif. Le modèle virtuel devrait juste être relié à l'interface physique. Le résultat est une configuration plus compacte et plus maniable. C'est particulièrement important s'il y a un grand nombre de PVCs.

  • Utilisez la commande de show ppp multilink comme manière indéréglable de déterminer s'il y a des baisses de cellules/trame du côté porteuse. La seule perte acceptable de fragment est une provoquée par des erreurs de contrôle de redondance cyclique (CRC).

  • Bien que MLPoATM/Relais de trames ait été introduit dans le Logiciel Cisco IOS version 12.1(5)T, les bogues en cela et les versions suivantes dictent que le soin soit pris quand vous sélectionnez la version du logiciel Cisco IOS. Cisco recommande d'utiliser la dernière release de maintenance du courant principal du Cisco IOS 12.2. Cependant, d'autres exigences de fonctionnalité VoIP peuvent dicter l'utilisation d'une version du logiciel Cisco IOS différente, telle que 12.2(2)XT si Survivable Remote Site Telephony (SRST) est exigé. Ce tableau présente certains des problèmes connus. Quand vous sélectionnez le Cisco IOS, chaque ID de bogue Cisco devrait être évalué contre l'IOS choisi.

ID de bogue Cisco Description
CSCdt09293 (clients enregistrés seulement) LFI- commutation rapide sur 7200 communications voix de manière des causes une.
CSCdt25586 (clients enregistrés seulement) Lien instable d'accès de PPPoA ou circuit virtuel commuté (SVC) non démoli sur le délai d'attente de veille.
CSCdt29661 (clients enregistrés seulement) MLP- l'arrêt de l'interface ATM pendant la commutation rapide tombe en panne le routeur.
CSCdt53065 (clients enregistrés seulement) Amélioration des performances en code d'atm_lfi pour la caractéristique atmosphère LFI.
CSCdt59038 (clients enregistrés seulement) MLPoATM : Ping avec le grand échouer de paquets sur PA-A3.
CSCdu18344 (clients enregistrés seulement) Le débit PVC de MLPoATM/Relais de trames est moins que la moitié de SCR/CIR.
CSCdu19297 (clients enregistrés seulement) Le PVC de MLPoATM sans stratégie de service génère des erreurs.
CSCdu41056 (clients enregistrés seulement) MLPoATM : Obtenir de routine de vc_soutput de gestionnaire appelé deux fois.
CSCdu44491 (clients enregistrés seulement) VirtualAccess pare incorrect dans MLPoFR.
CSCdu51306 (clients enregistrés seulement) Keepalives cassé sur PPPoX.
CSCdu57004 (clients enregistrés seulement) Le CEF ne fonctionne pas avec MLP.
CSCdu84437 (clients enregistrés seulement) L'implémentation de contrôle de flux entre MLP et tx-sonnerie a accordé des gestionnaires.
CSCdv03443 (clients enregistrés seulement) Difficulté de validation pour u76585 sur la version de logiciel 12.2 de Cisco IOSÝ - les paquets entrants MLP sont commutés par processus.
CSCdv10629 (clients enregistrés seulement) MLPoATM : Des paquets vocaux ne sont pas alignés à LLQ.
CSCdv20977 (clients enregistrés seulement) Les paquets entrants MLP sont obtenir commuté par processus.
CSCdw44216 (clients enregistrés seulement) le cRTP entraîne la CPU de haute quand le lien CBWFQ/LLQ atteint l'encombrement.
CSCdy70337 (clients enregistrés seulement) Quand un MLP empaquette avec la stratégie de service QoS est en service.
CSCdx71203 (clients enregistrés seulement) Un paquet MLP pourrait de temps en temps avoir quelques liens inactifs.

Étude de cas

Introduction

Cette section décrit un des premiers déploiements de client du MLPoATM/de fonctionnalité de relais de trame. Le client est mentionné par le nom factice XYZ Ltd. en 2001, XYZ Ltd a remplacé leurs PBX par une solution de Téléphonie sur IP. En tant qu'élément de ce projet, un nouveau réseau IP a été construit. et l'interworking de la vue Relay/ATM a été choisi pour le WAN. Le transporteur qui fournit le service WAN utilise des Commutateurs de Newbridge pour fournir l'atmosphère et des services de Relais de trames.

Aperçu de réseau

Le réseau de XYZ Ltd est un réseau de hub and spoke qui connecte vingt-six branchements à deux sites centraux. Chacun des sites centraux est servi par un routeur de Cisco 3660 relié par atmosphère d'E3. Dix-huit des vingt-six branchements sont moyens. Ils ont un double PVC en relais de trame qui se connectent de nouveau au 3660s aux deux sites centraux par le relais IW ATM/Frame. Les huit branchements demeurants sont très petits. Ils se connectent de nouveau au branchement moyen le plus étroit par un PVC simple de Relais de trames. Tous les Routeurs secondaires sont Cisco 2620. Un PVC atmosphère de bout en bout connecte les deux 3660 Routeurs aux deux sites du concentrateur. Cette figure montre la topologie.

http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-network.gif

Cette table affiche les vitesses d'accès frame relay et le CIR. Le CIR varie de 32 Kbps à 256 Kbps. Également affiché dans la table est le nombre maximal d'appels simultanés VoIP porté par chaque PVC.

Site Site distant Access (Kbps) CIR (Kbps) Nombre d'appels
Branchement 1 Noyau 1 320 192 6
Branchement 2 Branchement 22 128 64 2.0
Branchement 3 Noyau 1 576 256 8.0
Branchement 4 Branchement 16 64 32 2.0
Branchement 5 Noyau 1 128 64 2.0
Branchement 6 Branchement 3 64 32 2.0
Branchement 7 Noyau 1 512 256 8.0
Branchement 8 Noyau 1 512 256 8.0
Branchement 9 Branchement 13 128 256 2.0
Branchement 10 Noyau 1 256 128 4.0
Branchement 11 Noyau 2 128 96 2.0
Branchement 12 Noyau 1 128 64 2.0
Branchement 13 Noyau 1 768 256 12.0
Branchement 14 Noyau 1 192 96 4.0
Branchement 15 Noyau 1 192 96 4.0
Branchement 16 Noyau 1 448 192 8.0
Branchement 17 Branchement 13 128 64 2.0
Branchement 18 Noyau 1 128 96 2.0
Branchement 19 Branchement 16 128 64 2.0
Branchement 20 Noyau 1 64 32 2.0
Noyau 2 Noyau 1 34000 256 12.0
Branchement 21 Branchement 13 128 64 2.0
Branchement 22 Noyau 1 384 192 6.0
Branchement 23 Noyau 1 512 256 8.0
Branchement 24 Noyau 1 192 96 2.0
Branchement 25 Noyau 1 128 96 4.0
Branchement 26 Branchement 1 64 32 2.0

Le Formatage du trafic de relais de trames est exécuté par les Routeurs secondaires. On permet l'éclatement au delà du CIR. La formation du trafic de Cisco IOS est placée pour former à la vitesse d'accès, avec le mincir égal au CIR. Si des notifications d'encombrement explicites arrière (BECNs) sont reçues du transporteur, alors le routeur étrangle de nouveau au mincir. Cette approche est contre des recommandations de Cisco en faire le VoIP sur frame relay. La Voix est déjà dedans problème avant que le routeur ait répondu aux notifications d'encombrement. Cependant, dans ce cas le transporteur croit que son réseau provisioned suffisamment plus de pour ne jamais relâcher aucunes trames ou cellule, et par conséquent, BECNs devrait ne jamais être vu.

Le Formatage du trafic ATM est placé pour former à la vitesse d'accès de trame à l'extrémité distante, plus la taxe de cellules. Par exemple, si la vitesse d'accès est de 512 Kbps, puis la SCR est placée à 512x53/48 = 565 Kbps. Ce taux de mise en forme est utilisé pour maximiser le débit. C'est sûr parce que la taxe de cellules est éliminée au point IW. Le maintien de l'ordre du côté porteuse est configuré généreusement de sorte qu'on permette le léger surabonnement.

le cRTP est utilisé à travers le WAN. Le hotspot en ce qui concerne la CPU est le routeur de distribution de Cisco 3660 au site central 1. En ajoutant les nombres dans la table ci-dessus, on le détermine que le nombre maximal théorique d'appels VoIP qui traversent ce routeur est 102 appels. Les nombres de représentation de ce graphique indiquent que le chargement CPU de Cisco 3660 pour 100 sessions de cRTP (qui sont rapides commutées) est approximativement 50 pour cent.

http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-3660-performance.gif

Des modèles virtuels sont utilisés avec les liens WAN numérotés par IP. Un modèle virtuel est exigé par PVC qui est possible puisque le nombre total de PVCs qui se terminent sur chaque Cisco 3660 est moins de vingt-cinq.

Configurations

Ce document utilise les configurations suivantes :

Principal routeur atmosphère

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

Routeur Frame Relay de branchement

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

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 25084