|
Robust Header CompressionRobust Header Compression (ROHC) est une méthode normalisée dans la RFC 3095[1] pour compresser les entêtes IP, UDP, RTP et TCP des paquets réseau. Ce système de compression diffère des autres systèmes de compression tels que ceux décrits dans les RFC 1144[2] et RFC 2508[3] de l'IETF par le fait qu'il donne de bons résultats sur des liens à taux d'erreurs élevés ou à fortes pertes comme les liens sans fil (radio). Pour les applications de diffusion (streaming en anglais), le surcoût (overhead en anglais) engendré par les entêtes IP, UDP et RTP est de 40 octets pour IPv4 et de 60 octets pour IPv6. Dans le cas de la voix sur IP, ce surcoût équivaut à environ 60 % du total des données envoyées. De tels surcoûts peuvent être tolérés sur des liens filaires pour lesquels la capacité n'est souvent pas un problème, mais ils sont excessifs dans le cas de systèmes de transmission sans fil pour lesquels la bande passante est faible. RoHC est notamment utilisée pour la transmission radio dans les réseaux mobiles 4G LTE et LTE Advanced. Cette méthode participe à l'optimisation du transfert de la voix (VoLTE) et à l'optimisation des transferts de données sur les réseaux mobiles, en complément de l'optimisation des pages web destinées aux smartphones. ROHC compresse typiquement les 40 ou 60 octets d'entêtes en seulement 1 ou 3 octets en utilisant l’algorithme de compression avant l'émission sur le lien dont le débit est limité et un décompresseur après réception sur ce lien. Le compresseur convertit les entêtes volumineux en quelques octets seulement tandis que le décompresseur réalise l'opération inverse. Modes opératoiresLe système de compression ROHC possède trois modes opératoires :
Dans le mode opératoire « unidirectionnel », les paquets sont envoyés uniquement dans un seul sens : du compresseur vers le décompresseur. Ce mode permet d'utiliser ROHC sur des liens pour lesquels le lien retour du décompresseur vers le compresseur n'est pas disponible ou est peu souhaitable (le satellite par exemple). Le mode « bidirectionnel optimiste » est similaire au mode « unidirectionnel » à l'exception toutefois de l'existence d'une voie retour (feedback channel en anglais). Cette voie retour est utilisée pour transmettre du décompresseur au compresseur des requêtes de récupération d'erreur et (de manière optionnelle) des acquittements lors de mises à jour de contextes. Ce mode opératoire vise à maximiser l'efficacité de compression et à limiter l'utilisation de la voie retour. Le mode « bidirectionnel fiable » diffère par bien des façons des deux précédents. Les plus importantes différences sont l'utilisation intensive de la voie retour et une logique de compression/décompression plus stricte qui empêche la perte de synchronisation entre le compresseur et le décompresseur excepté pour des taux d'erreurs bit résiduels très importants. Classification des champs des entêtesAfin de ne transférer que le minimum de données nécessaires, les différents champs des entêtes sont classés en trois catégories : les champs statiques, les champs induits et les champs dynamiques. Les champs statiques sont des champs comme les adresses IP ou les ports UDP dont la valeur n'évolue pas entre deux paquets d'un même flux. Les champs induits sont des champs comme la longueur ou la somme de contrôle du paquet dont la valeur peut être déduite d'après les valeurs des autres champs. Enfin, les champs dynamiques sont des champs comme l'identifiant IP (IP-ID), le type de service (ToS) ou la durée de vie (TTL) dont la valeur évolue entre deux paquets d'un même flux. Une fois les valeurs des champs statiques transmises et stockées, il n'est pas nécessaire de systématiquement les transmettre avec chaque paquet. Les valeurs des champs induits n'ont quant à eux jamais besoin d'être transmises. Enfin, les valeurs des champs dynamiques doivent être systématiquement transmises. Le fait que le compresseur doive systématiquement transmettre les valeurs des champs dynamiques ne signifie pas qu'il soit obligé de les transmettre tels quels. L'évolution de certains champs dynamiques est en effet prévisible et permet au compresseur de ne transmettre au décompresseur que la différence entre deux valeurs successives. Par exemple, la valeur de l'identifiant IP (IP-ID) est souvent incrémentée par les piles IP (c'est notamment le cas de Linux) d'une unité à chaque nouveau paquet IP. Comme exposé ci-dessus, ROHC met à profit la redondance d'information au sein des entêtes elles-mêmes et entre les entêtes des paquets successifs. Il est donc important que le compresseur sépare bien les paquets IP en flux distincts afin que la compression puisse être optimale. États de fonctionnementL'algorithme ROHC fonctionne de manière similaire à la compression vidéo. Une trame de base puis plusieurs trames différentielles sont envoyées pour représenter un flux IP. Ce mécanisme permet à ROHC de survivre à un grand nombre de pertes au niveau de compression le plus fort à condition que les trames de base ne soient pas perdues. Un compresseur ROHC peut fonctionner dans 3 états différents :
La taille du champ contenant le numéro de séquence détermine le nombre de paquets que ROHC peut perdre avant que le compresseur et le décompresseur ne soient désynchronisés. La taille du champ contenant le numéro de séquence dans les entêtes ROHC de 1 et 2 octets est respectivement de 4 bits (offset entre -1 et +14 par rapport à la trame de base) et 6 bits (offset entre -1 et +62 par rapport à la trame de base). ROHC peut donc tolérer au plus 62 trames perdues avec une trame de 1 ou 2 octets. Entête ROHC du Second Ordre (1 octet)Une implémentation ROHC classique souhaitera amener le compresseur et le décompresseur dans l'état de fonctionnement « Second Ordre » afin de substituer aux 40 octets d'entêtes IP/UDP/RTP (cas classique de la VoIP) un entête de 1 octet seulement. Dans cet état de fonctionnement, les 8 bits de l'entête ROHC forment trois champs :
Nouvelles RFCs ROHCDeux nouvelles RFCs apportant des précisions ou améliorations ont été publiées :
La RFC 3095 définit un mécanisme de compression générique qui peut être complété par des profils adaptés à la compression de certaines entêtes. De nouvelles RFCs définissant de nouveaux profils de compression pour d'autres protocoles ont été publiées :
Notes et références
Voir aussiArticles connexesLiens externes
|
