Ce document traite de deux des normes FRF (Frame Relay Forum) (FRF.11 et FRF.12) qui fragmentent les paquets en trames plus petites. Pour plus d'informations sur la conception et la configuration de la VoIP sur un réseau Frame Relay, référez-vous au document VoIP sur Frame Relay avec qualité de service (fragmentation, formatage du trafic, priorité IP RTP).
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
L'intégration des données vocales pose un grand défi : contrôler le délai maximal de bout en bout unidirectionnel pour le trafic sensible au temps, tel que la voix. Pour une bonne qualité vocale, ce délai est inférieur à 150 millisecondes (ms). Une partie importante de ce délai est le délai de sérialisation sur l'interface, qui ne doit pas dépasser 20 ms. Le délai de sérialisation est le temps nécessaire pour placer les bits sur une interface.
Serialization Delay = frame size (bits) / link bandwidth (bits per second [bps])
Par exemple, un paquet de 1 500 octets (B) prend 187 ms pour quitter le routeur sur une liaison de 64 kbits/s. Si vous envoyez un paquet de données en temps non réel de 1500 B, les paquets de données en temps réel (voix) sont mis en file d'attente jusqu'à la transmission du paquet de données volumineux. Ce délai est inacceptable pour le trafic vocal. Si les paquets de données non en temps réel sont fragmentés en trames plus petites, les trames sont entrelacées avec des trames en temps réel (voix). De cette manière, les trames voix et données peuvent être transportées ensemble sur des liaisons à faible vitesse sans délai excessif vers le trafic vocal en temps réel.
FRF.12 est un accord de mise en oeuvre qui prend en charge la voix et d'autres données sensibles au délai en temps réel sur les liaisons à faible vitesse. La norme prend en charge les variations de taille des trames de manière à permettre un mélange de données en temps réel et de données non en temps réel.
FRF.12 stipule que, lorsque la fragmentation est activée pour un identificateur de connexion de liaison de données (DLCI), il y a fragmentation de seules trames de données qui dépassent la taille de fragmentation spécifiée. Cette disposition permet aux petits paquets VoIP, qui ne sont pas fragmentés en raison de leur taille, d'être entrelacés en tant que trames entre des paquets de données volumineux qui ont été fragmentés en trames plus petites. Cela améliore le délai de sérialisation des paquets qui quittent le routeur. Par conséquent, les paquets vocaux n’attendent pas le processus des paquets de données volumineux.
Dans une implémentation VoIP, Frame Relay (protocole de couche 2) ne peut pas distinguer les trames VoIP des trames de données. FRF.12 fragmente tous les paquets qui sont plus grands que le paramètre de taille de fragment. Configurez la taille de fragmentation sur le DLCI de sorte que les trames vocales ne soient pas fragmentées. Vous pouvez configurer la taille de fragment sous la commande frame-relay du logiciel Cisco IOS® avec le problème de la commande frame-relay fragment fragment_size. La taille du fragment est en octets et la valeur par défaut est 53 B. De nombreuses variables déterminent la taille des paquets vocaux. Pour plus d'informations sur la taille des paquets voix, référez-vous au document Voix sur IP - Consommation de bande passante par appel.
Une implémentation VoFR (Voice over Frame Relay) utilise le FRF.11 pour définir comment la voix et les données sont encapsulées sur le DLCI Frame Relay. Ainsi, les données, la signalisation fax et la voix utilisent l’encapsulation FRF.11 pour la transmission sur un DLCI transportant la voix. Pour mélanger ces types de trafic sur un DLCI, FRF.11 définit des sous-canaux (identifiables par des ID de canal) au sein de l’identificateur DLCI. Chaque sous-canal possède un champ d'en-tête qui décrit le type de charge utile de trame. FRF.11 peut spécifier jusqu'à 255 sous-canaux par DLCI.
Remarque : si vous n'avez pas configuré les DLCI pour VoFR, les DLCI utilisent l'encapsulation de données Frame Relay standard, comme le spécifie FRF.3.1.
La fragmentation de l'annexe C FRF.11 décrit la manière dont un DLCI FRF.11 (configuré pour VoFR) transporte les données. FRF.11 L'annexe C comprend une spécification de fragmentation pour les sous-canaux de données.
Seules les trames avec un type de données utiles sont fragmentées. Frame Relay distingue les trames vocales des trames de données non en temps réel, car la charge utile FRF.11 spécifie le type de trafic. Par conséquent, quelle que soit la taille de la trame vocale, la trame vocale contourne le moteur de fragmentation.
Il existe plusieurs formes reconnues de fragmentation Frame Relay :
FRF.11 Annexe-C fragmentation : utilisée sur les DLCI configurés pour VoFR.
Fragmentation FRF.12 : utilisée sur les DLCI qui transportent le trafic de données (FRF.3.1), qui inclut la VoIP. Le protocole Frame Relay de couche 2 considère les paquets VoIP comme des données.
Il est communément admis à tort que la fragmentation FRF.12 prend en charge la VoFR et qu'il n'est pas généralement reconnu que FRF.11 spécifie également un schéma de fragmentation. Cette confusion entraîne un malentendu sur la fragmentation des VoFR et VoIP sur Frame Relay. Cette liste clarifie certaines différences clés :
Un DLCI Frame Relay exécute FRF.12 ou FRF.11, mais jamais les deux. Les FRF.12 et FRF.11 s'excluent mutuellement.
Si vous avez configuré le DLCI pour VoFR, le DLCI utilise FRF.11. Si la fragmentation est activée pour ce DLCI, le DLCI utilise FRF.11 Annex-C (ou le dérivé Cisco) pour les en-têtes de fragmentation.
Si vous n'avez pas configuré le DLCI pour VoFR, le DLCI utilise l'encapsulation de données FRF.3.1. Si la fragmentation est activée pour ce DLCI, le DLCI utilise FRF.12 pour les en-têtes de fragmentation. Les DLCI qui transportent la VoIP utilisent la fragmentation FRF.12 parce que la VoIP est une technologie de couche 3 transparente pour le relais de trames de couche 2.
Vous pouvez prendre en charge VoIP et VoFR sur différents DLCI sur la même interface, mais pas sur le même DLCI.
FRF.12 fragmente les paquets vocaux si vous avez défini le paramètre de taille de fragmentation sur une valeur inférieure à la taille de paquet vocal. FRF.11 Annex-C (VoFR) ne fragmente pas les paquets vocaux quelle que soit la taille de fragmentation que vous avez configurée.
FRF.11 L'annexe C n'a besoin que d'une prise en charge sur les plates-formes prenant en charge la VoFR. Étant donné que l'utilisation de FRF.12 concerne principalement la VoIP, il est important de prendre en charge FRF.12 en tant que fonctionnalité générale sur les plates-formes du logiciel Cisco IOS qui transportent la VoIP sur des liaisons WAN à faible débit (plus lentes que 1,5 Mbits/s). Pour cette raison, il existe une prise en charge de FRF.12, dans le logiciel Cisco IOS Version 12.1.2T et ultérieure, sur les plates-formes de passerelle non vocale telles que 805, 1600, 1700, 2500, 4500 et 4700.