Mode de transfert asynchrone (ATM) : Gestion de trafic ATM

Présentation du formatage de trafic avec AIP

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


Contenu


Introduction

Ce document introduit le trafic formant utilisant des cartes du processeur d'interface ATM (AIP) et décrit l'architecture et les limites de ces cartes.

Remarque: Vous ne devez pas manuellement assigner les circuits virtuels permanents (PVCs) et le circuit virtuel commuté (SVC) pour évaluer des files d'attente, puisque des versions plus récentes du logiciel de Cisco IOSÝ font ceci automatiquement et dynamiquement. Toutes les références que vous voyez à assigner ces derniers s'appliquent manuellement seulement à des versions plus anciennes du logiciel.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations dans ce document sont basées sur le matériel AIP détaillé dans le guide d'installation et de configuration AIP. La version de logiciel n'est pas appropriée à moins qu'une fois indiquée autrement.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Formation du trafic de base

Des circuits virtuels (vbr-nrt) de débit variable non en temps réel (VCs) sont normalement configurés avec du débit de crête, le débit moyen et la taille de rafale. Chaque circuit virtuel spécifie un pourcentage du débit de crête en tant que son débit moyen. Le débit moyen peut être 100% du débit de crête ou d'un pourcentage qui est moins de 50%. Ce qui suit est un exemple :

atm pvc 6 8 69 aal5snap 512 128 3

L'exemple ci-dessus est un PVC avec du débit de cellules maximal de 512 Kbps, et un débit de cellules soutenable de 128 Kbps. Dans ce cas, le débit moyen est 25% du débit de crête.

Les formes AIP trafiquent basé sur deux algorithme "leaky bucket". Ceci octroie un crédit de cellules au circuit virtuel à chaque intervalle de service correspondant au débit moyen.

Remarque: Tout le crédit de cellules ne peut pas dépasser la taille de rafale spécifiée.

Le débit de crête d'une file d'attente de débit détermine la période de service de cette file d'attente. Avant de transmettre des paquets, le logiciel système premier les incorpore dans la structure correspondante de circuit virtuel. Il incorpore alors cette structure de circuit virtuel dans la file d'attente appropriée de débit. La section suivante explore ceci plus en détail.

Le trafic formant avec l'AIP

Les ordres de puce de segmentation et de réassemblage atmosphère (SAR) trafiquent la formation sur l'AIP. Cette puce SAR base son trafic formant sur la notion des files d'attente de débit, comme décrit ci-dessous :

  1. Chaque circuit virtuel peut être alloué un débit de crête. C'est le débit maximum auquel des cellules peuvent être transmises sur ce circuit quand il y a du trafic à envoyer. Le logiciel système examine le débit de crête du circuit virtuel et l'assigne à la file d'attente de débit qui apparie le plus étroitement le débit demandé.

  2. Le trafic formant dans l'AIP se conforme au contrôle de trafic et à la gestion des ressources ITU-T dans B-ISDN. I.371 Recommendation, 1992. I.371 qui décrit l'algorithme "leaky bucket". La puce SAR fournit huit files d'attente de débit pour le Formatage du trafic ATM. Il groupe ces files d'attente de huit débits dans deux banques :

    • Banque zéro : le débit aligne zéro à trois (0 - 3). Ceci a une haute priorité que la banque une.

    • Banque une : le débit aligne quatre à sept (4 - 7).

  3. La puce SAR trace chaque circuit virtuel à une file d'attente de débit quand elle est créée. Le premier circuit virtuel a créé des utilisations évaluent la file d'attente zéro, les deuxièmes utilisations évaluent la file d'attente une, et ainsi de suite. Vous pouvez vérifier ceci utilisant la commande de nombre d'interface de show atm interface atm. Veuillez se référer à la section de problèmes de sursouscription plus tard dans ce document.

  4. Quand vous utilisez vbr-nrt, si le teneur maximal en débit de cellules (PCR) est égal au teneur en débit de cellules soutenable (SCR), ceci est traité comme UBR débit-limité. Cette caractéristique est documentée dans l'ID de bogue Cisco CSCdm64510 (clients enregistrés seulement).

    Cette configuration n'est pas prise en charge dans la nouvelle interface de ligne de commande (CLI). Pour plus d'informations sur ceci, a cliquez ici.

    http://www.cisco.com/c/dam/en/us/support/docs/asynchronous-transfer-mode-atm/atm-traffic-management/10400-aip-traffic.gif

Les paquets joints pour évaluer des files d'attente à la banque non prioritaire (banque une) ne peuvent pas transmettre alors que les files d'attente de débit à la banque prioritaire (banque zéro) ne sont pas vides.

Bien que nous utilisions la file d'attente à priorité déterminée entre les deux banques, des files d'attente de débit au sein de chaque banque sont entretenues manière séquentielle ou d'une de « recherche séquentielle ». Chaque circuit virtuel envoie une cellule quand la file d'attente de débit est servie. Quand une file d'attente de débit demande le service, le circuit virtuel actuellement-sélectionné envoie une cellule et les incréments de pointeur de recherche séquentielle au prochain circuit virtuel lié à ce débit s'alignent. Si deux temporisateurs de file d'attente de débit expirent en même temps, ils sont entretenus de la mode de recherche séquentielle, à partir de la file d'attente de débit avec le nombre plus peu élevé. Dès qu'une file d'attente de débit enverra une cellule, le service pour cette file d'attente est complet. Il n'y a aucune Réglementation du trafic pendant le réassemblage.

Exemple

Si une file d'attente de débit est configurée en tant que 10 Mbits/s, quand une opportunité de service est livré, une cellule de chaque VCI dans cette file d'attente de débit est envoyée tant que il y a un jeton dans sa position. La fréquence de service de la file d'attente de débit demeure constante une fois configurée. Tant que le module d'interface de couche physique (PLIM) peut manipuler la vitesse, chaque VCI relié à cette file d'attente de débit est dans le débit de crête.

Ceci signifie que s'il y a seulement dix indentifiants de canal virtuel (VCIs) sur 10 Mbits/s évaluent la file d'attente, ils peut transmettre des paquets à 10 Mbits/s simultanément, se montant à des 100 Mbits/s.

Problèmes de sursouscription

Si le système sur-est abonné, ceci peut bloquer la banque de priorité plus basse. Cependant, tous évaluent des files d'attente à une banque plus prioritaire sont toujours entretenus.

La sursouscription a également d'autres inconvénients. Si nous relions 100 VCs à l'5 Mbits/s alignez, ceci tient la file d'attente pendant longtemps et peut, par exemple, priver des 100 Mbits/s s'alignent qui a seulement un circuit virtuel. En outre, des 100 que VCs relié au ce 5 Mbits/s évaluent la file d'attente, chacun peut avoir un débit moyen différent. Par conséquent, quand les temps d'attente du débit 5Mbps et les besoins d'être entretenu, non tout le VCs ont un jeton dans la position. Ceci signifie que moins de 100 VCIs peuvent être entretenus à ce moment.

Puisque la fréquence de service de demande des 100 Mbits/s est beaucoup de supérieur à 5 Mbits/s, le paquet peut encore être envoyé. Cependant, c'est très lent parce que la bande passante est déjà oversubscribed. Dans le pire des cas le scénario, l'autre file d'attente peut être totalement privé.

Caractéristiques AIP

Il y a trois paramètres utilisés pour gérer la circulation AIP :

  • Débit de crête

  • Débit moyen

  • Rafale

Le PCR détermine quelle débit-file d'attente le VCD sera relié à et détermine la période de service de cette débit-file d'attente. Le PCR sera mis à jour tant que la position de la SCR du VC a des crédits. Le débit moyen détermine le délai prévu pour qu'un jeton mette dans la position. Le débit moyen détermine la SCR. Les crédits s'accumulent à un débit égal à la SCR.

Le jeu de puces AIP SAT exige la SCR et le PCR à joindre par la formule suivante :

SCR = 1/n * PCR (n=1….64)

La taille de rafale détermine le nombre maximal de jeton à mettre dans la position. Tout le crédit ne peut pas dépasser la taille de rafale spécifiée. La taille de rafale s'étend de 0 -63. La file d'attente de débit est entretenue au débit égal au PCR. Par conséquent si un circuit virtuel a des constantes à envoyer il enverra seulement au débit égal à la SCR et n'éclatera pas. Si la quantité de données tombe au-dessous de la SCR puis les crédits commenceront l'accumulation jusqu'à la taille de rafale. Si la quantité de données pour envoyer le circuit virtuel augmentait, une rafale égale à la taille de rafale peut être envoyée par circuit virtuel. Après qu'éclaté les données puisse de nouveau être envoyé au débit de SCR.

Voici les fonctionnalités principales de l'AIP :

  • Chaîne de débit de crête : 155 Mbits/s vers le bas à 130 Kbps.

  • Débit soutenu : SCR = 1/n * PCR (où n est un entier et un n=1….64)

    Remarque: Vous pouvez également placer la SCR pour être le même que le PCR.

  • Avec le vieux CLI, vous ne pouvez pas fixer la taille de rafale à zéro, puisque c'est un multiple de 32 cellules.

    Par exemple, PVC 6 atmosphère 8 69 aal5snap 256 128 3 signifie que vous utilisez 3 x 32 cellules comme taille de rafale (96 cellules).

  • La plage VCI peut être placée de zéro à 65535.

Taille de rafale contre la taille de rafale maximale

Selon la manière nous avons configuré le PVC avec vbr-nrt, le paramètre utilisé pour configurer la quantité de cellules envoyées aux modifications de PCR.

Utilisant le vieux CLI

Si vous utilisez le vieux CLI, le paramètre configuré n'est pas la taille de rafale maximale (mis-bande) mais la taille de rafale. Cette taille de rafale est un multiple de 32 cellules.

router(config-subif)#atm pvc 6 8 69 aal5snap 256 128 ?
  <1-63>  Burst size in number of 32 cell bursts
  inarp   Inverse ARP enable
  oam     OAM loopback enable
  <cr>

Par exemple, la commande affichée ici (PVC 6 atmosphère 8 69 aal5snap 256 128 3) signifie que vous utilisez 3 x 32 cellules comme taille de rafale (96 cellules). Cette taille de rafale est le paramètre que l'AIP l'utilise dans son algorithme de formation. Il ne représente pas la quantité de cellules qui sont vraiment envoyées au PCR.

Regardons les relations entre la taille de rafale configurée et les mis-bande fondez dans vbr-nrt. Ces deux paramètres sont joints par la formule suivante :

Mis-bande = nombre de cellules au PCR = [(TAILLE DE RAFALE) de X 32 x 424/(PCR - SCR)] * [PCR/424]

Le PCR et la SCR que nous utilisons dans la formule ci-dessus ne sommes pas les valeurs configurées, mais les valeurs qui les utilisations AIP de faire la formation du trafic. Ce problème est dû à la finesse de modélisateur AIP. Regardons un exemple pour illustrer ceci :

interface ATM1/0.5 point-to-point
 atm pvc 7 10 500 aal5snap 5000 2500 52

router#show atm vc
            VCD /                                      Peak  Avg/Min Burst
Interface   Name       VPI   VCI  Type   Encaps   SC   Kbps   Kbps   Cells  Sts
1/0.5      7           10   500   PVC    SNAP     VBR    5000   2500 3264    UP

Comme nous pouvons voir ici, la taille de rafale configurée est égale à 1664 cellules (52 x 32) mais les mis-bande d'effectif est égale à 3264 cellules.

Utilisant le nouveau CLI

En utilisant le nouveau CLI (dans des versions du logiciel Cisco IOS 12.0 et ci-dessus), le paramètre configuré est les mis-bande et pas la taille de rafale comme nous avons vu dans la section précédente. Le routeur convertit toujours intérieurement les mis-bande configurées en taille de rafale utilisée dans son algorithme de formation. Puisque les mis-bande est encore liées à la taille de rafale par la formule affichée dans la section précédente, les mis-bande ce qui pourraient être mesurées sur le trafic sortant pourraient encore différer légèrement de la valeur configurée.

La différence est que cette exécution est maintenant transparente à l'utilisateur qui configure de ce qu'il a besoin (en d'autres termes, les mis-bande).

Voici un exemple montrant ce comportement avec le nouveau CLI :

router(config)#interface ATM1/0.3 point-to-point
router(config-subif)#pvc 10/300
router(config-if-atm-vc)#vbr-nrt 5000 2500 ?
  <64-4032>  Maximum Burst Size(MBS) in Cells
  <cr>
 
router(config-if-atm-vc)#vbr-nrt 5000 2500 1000
router(config-if-atm-vc)#^Z
router#sh atm vc
            VCD /                                      Peak  Avg/Min Burst
Interface   Name       VPI   VCI  Type   Encaps   SC   Kbps   Kbps   Cells  Sts
1/0.3      5           10   300   PVC    SNAP     VBR    5000   2500  960    UP

Comme vous pouvez voir dans la sortie ci-dessus, l'utilisateur peut maintenant directement configurer les mis-bande désirées mais en raison de la finesse AIP, les vraies mis-bande pourraient être légèrement différentes des mis-bande configurées.

Comportement par défaut AIP

Si vous laissez la taille de rafale éliminée, l'AIP prend trois comme valeur par défaut. Exemple :

atm pvc 6 8 69 aal5snap 256 128

est équivalent à :

atm pvc 6 8 69 aal5snap 256 128 3

Vous pouvez placer la SCR pour être la valeur de PCR divisée par n (SCR = 1/n * PCR (où n est un entier et un n=1….64).

Si vous placez SCR=PCR/n où n n'est pas un entier, l'AIP arrondit la valeur sans afficher une erreur. L'AIP vous permet également de spécifier des valeurs sous PCR/2, les arrondit alors sans vous informer. Par exemple, si vous tapez :

atm pvc 6 8 69 aal5snap 512 200 1 (where the SCR is equal to PCR divided by 2.56)

l'AIP interprète ceci en tant que :

atm pvc 6 8 69 aal5snap 512 256 1 (where the SCR is rounded up to PCR divided by 2)

L'AIP arrondit cette figure jusqu'à une valeur supérieure. Dans des tous les cas, vous êtes recommandé pour utiliser un entier pour le N.

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: 10400