Voix : Voix sur relais de trame (VOFR)

Fragmentation de relais de trame pour la voix

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document discute deux des normes du Forum Frame Relay (FRF) (FRF.11 et FRF.12) des paquets de ce fragment dans de plus petites trames. Pour plus d'informations sur la façon concevoir et configurer le VoIP au-dessus d'un réseau de Relais de trames, référez-vous au VoIP sur frame relay de document avec la qualité de service (fragmentation, trafic formant, IP RTP Priority).

Conditions préalables

Conditions requises

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

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

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

Théorie générale

Un défi important avec l'intégration voix-données est de contrôler le retard de bout en bout unidirectionnel nom maximum pour le trafic sensible à la durée tel que la Voix. Pour la bonne qualité vocale, ce retard est moins de 150 millisecondes (ms). Une partie importante de ce retard est le retard de fabrication en série sur l'interface, qui ne devrait pas dépasser Mme 20 que retard de fabrication en série est le temps il prend pour placer réellement les bits sur une interface.

Serialization Delay = frame size (bits) / link bandwidth (bits per second [bps]) 

Par exemple, un paquet 1500-byte (b) prend 187 ms pour laisser au routeur au-dessus de l'des 64 Kbits/s pour joindre. Si vous envoyez un paquet de données de temps machine de 1500 B, les paquets de données en temps réel (de Voix) s'alignent jusqu'à ce que la transmission du grand paquet de données. Ce retard est inacceptable pour le trafic vocal. Si des paquets de données de temps machine sont fragmentés dans de plus petites trames, les trames sont intercalées avec les trames en temps réel (de Voix). De cette façon, les deux trames voix et de données peuvent être portés ensemble sur des liaisons à bas débit sans retard excessif au trafic vocal en temps réel.

Fragmentation de FRF.12

Le FRF.12 est un accord d'implémentation qui prend en charge la Voix et d'autres données sensibles au délai en temps réel sur des liaisons à bas débit. La norme facilite des variations des tailles de trame en quelque sorte qui permet une combinaison de données en temps réel et de temps machine.

Le FRF.12 stipule que, quand la fragmentation est allumée pour un identificateur de connexion de liaison de données (DLCI), il y a de fragmentation des trames de données seulement qui dépassent la taille de fragmentation spécifiée. Cette organisation permet les petits paquets VoIP, qui ne sont pas dus fragmenté à la taille, à intercaler comme trames entre les grands paquets de données qui ont été fragmentés dans de plus petites trames. Ceci améliore le retard de fabrication en série pour les paquets qui laissent le routeur. En conséquence, les paquets vocaux n'attendent pas le processus de grands paquets de données.

Dans une implémentation VoIP, le Relais de trames (protocole de couche 2) ne peut pas distinguer le VoIP et les trames de données. Le FRF.12 fragmente tous les paquets qui sont plus grands que la configuration de taille de fragment. Configurez la taille de fragmentation sur le DLCI tels que des trames voix ne sont pas fragmentées. Vous pouvez configurer la taille de fragment sous la commande de map-class frame-relay de logiciel de ½ du ¿  de Cisco IOSï avec la question du frame-relay fragment fragment_size la commande. La taille de fragment est dans les octets, et le par défaut est 53 B. Beaucoup de variables déterminent la taille des paquets vocaux. Pour plus d'informations sur la taille de paquet voix, référez-vous à la voix sur ip de document - consommation de bande passante par appel.

Norme de FRF.11

Une implémentation de voix sur relais de trame (VOFR) emploie le FRF.11 pour définir comment la Voix et les données sont encapsulées sur le DLCI en relais de trame. Ainsi, données, signalisation de télécopie, et encapsulation de FRF.11 d'utilisation de Voix pour la transmission sur un DLCI qui porte la Voix. Pour mélanger ces types de trafic sur un DLCI, le FRF.11 définit des sous-canaux (identifiables par des id de canal) dans le DLCI. Chaque sous-canal a un champ d'en-tête qui décrit le type de charge utile de trame. Le FRF.11 peut spécifier jusqu'à 255 sous-canaux par DLCI.

Remarque: Si vous n'avez pas configuré des DLCI pour le vofr, les DLCI utilisent l'encapsulation standard de données de relais de trame, car FRF.3.1 spécifie.

Fragmentation d'annexe-C de FRF.11

La fragmentation d'annexe-C de FRF.11 décrit la manière qu'un FRF.11 DLCI (configuré pour le vofr) porte des données. L'annexe-C de FRF.11 inclut une spécification de fragmentation pour les sous-canaux de données.

Seulement des trames avec le type de charge utile de données sont fragmentées. Le Relais de trames distingue des trames voix des trames de données de temps machine parce que la charge utile de FRF.11 spécifie le type de trafic. Par conséquent, indépendamment de la taille de trame voix, la trame voix saute l'engine de fragmentation.

FRF.12 de Relais de trames contre la fragmentation de FRF.11

Il y a plusieurs formes identifiées de fragmentation de relais de trame :

  • Fragmentation d'annexe-C de FRF.11 — Utilisé sur des DLCI configurés pour le vofr.

  • Fragmentation de FRF.12 — Utilisé sur les DLCI qui portent le trafic des données (FRF.3.1), qui inclut le VoIP. Le protocole de relais de trame de la couche 2 considère comme étant les paquets VoIP des données.

Il y a une fausse idée commune que la fragmentation de FRF.12 prend en charge le vofr et une ignorance générale que le FRF.11 spécifie également une structure de fragmentation. Cette confusion a comme conséquence le malentendu au sujet de la fragmentation pour le vofr et le VoIP sur frame relay. Cette liste clarifie quelques différences principales :

  • Un DLCI en relais de trame exécute le FRF.12 ou le FRF.11, mais jamais chacun des deux. Le FRF.12 et le FRF.11 sont mutuellement - exclusivité.

    • Si vous avez configuré le DLCI pour le vofr, le DLCI utilise le FRF.11. Si la fragmentation est allumée pour ce DLCI, le DLCI utilise l'annexe-C de FRF.11 (ou le dérivé de Cisco) pour les en-têtes de fragmentation.

    • Si vous n'avez pas configuré le DLCI pour le vofr, le DLCI utilise l'emballage des données FRF.3.1. Si la fragmentation est allumée pour ce DLCI, le DLCI utilise le FRF.12 pour les en-têtes de fragmentation. DLCI qui portent la fragmentation de FRF.12 d'utilisation VoIP parce que le VoIP est une technologie de la couche 3 qui est transparente pour poser le Relais de trames 2.

  • Vous pouvez prendre en charge le VoIP et le vofr sur différents DLCI sur la même interface, mais pas sur le même DLCI.

  • Le FRF.12 fragmente des paquets vocaux si vous avez placé le paramètre de taille de fragmentation à une valeur plus petit que la taille de paquet voix. L'annexe-C de FRF.11 (vofr) ne fragmente pas des paquets vocaux indépendamment de la taille de fragmentation que vous avez configurée.

  • Support des besoins d'annexe-C de FRF.11 seulement dans des Plateformes qui prennent en charge le vofr. Puisque l'utilisation du FRF.12 est principalement pour le VoIP, il est important de prendre en charge le FRF.12 comme caractéristique générale sur les plates-formes logicielles de Cisco IOS qui transportent le VoIP au-dessus des liens WAN à basse vitesse (plus lentement que 1.5 Mbits/s). Pour cette raison, il y a soutien de FRF.12, dans la version du logiciel Cisco IOS 12.1.2T et plus tard, sur des Plateformes de non vocal-passerelle telles que les 805, les 1600, les 1700, les 2500, les 4500, et les 4700.


Informations connexes


Document ID: 9232