ROHC

Robust Header Compression (ROHC) est une méthode normalisée dans la RFC 3095 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 comme ceux décrits dans les RFC 1144 et RFC 2508 de l'IETF par le fait qu'il donne de bons résultats sur des liens à fortes pertes comme les liens sans fil.

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 VoIP, ce surcoût équivaut à environ 60% du total des données envoyées. De tel 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 sans fil pour lesquels la bande passante est rare.

ROHC compresse typiquement les 40 ou 60 octets d'entêtes en seulement 1 ou 3 octets en disposant un compresseur avant le lien dont la capacité est limitée et un décompresseur après ce lien. Le compresseur convertit les entêtes volumineuses en quelques octets seulement tandis que le décompresseur réalise l'opération inverse.

Sommaire 1 Modes opératoires 2 Classification des champs des entêtes 3 États de fonctionnement 4 Entête ROHC du Second Ordre (1 octet) 5 Nouvelles RFCs ROHC 6 Liens externes

Modes opératoires

Le système de compression ROHC possède trois modes opératoires :

• le mode « unidirectionnel » (Unidirectional ou U-Mode en anglais),
• le mode « bidirectionnel optimiste » (Bidirectional Optimistic ou O-Mode en anglais),
• le « mode bidirectionnel fiable » (Bidirectional Reliable ou R-Mode en anglais).

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 compressseur 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êtes

Afin de ne transférer que le minimum de données nécessaires, les différents champs des entêtes sont classées 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), la qualité 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 sucessives. 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 successives. 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 fonctionnement

L'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 :

• Dans l'état « Initialisation & Rafraichissement » (Initialization and Refresh ou IR en anglais), le compresseur vient juste d'être créé ou ré-initialisé et les entêtes complètes sont envoyées au décompresseur afin qu'il les mémorise.
• Dans l'état « Premier Ordre » (First-Order ou FO en anglais), le compresseur et le décompresseur ont mémorisé les champs statiques et dynamiques des entêtes et le compresseur envoie uniquement au décompresseur les champs dynamiques qui ont changé entre deux entêtes successives.
• Dans l'état « Second Ordre » (Second-Order ou SO en anglais), le compresseur ne transmet plus les champs dynamiques comme l'identifiant IP (IP-ID) ou le numéro de séquence RTP mais uniquement un numéro de séquence logique à partir duquel les champs dynamiques peuvent être regénérés. Par exemple, si le champ identification IP (IP-ID) est incrémenté d'une unité à chaque paquet, il évolue au même rythme que le numéro de séquence logique et il devient alors superflu de le transmettre une fois cette règle établie. Une somme de contrôle permet au décompresseur de vérifier que la reconstruction de l'entête est correcte.

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) une entête de 1 octet seulement. Dans cet état de fonctionnement, les 8 bits de l'entête ROHC forment trois champs :

• 1 bit  : un drapeau indiquant le type de paquet ROHC (0 dans ce cas),
• 4 bits : le numéro de séquence (offset entre -1 et +14 par rapport à la trame de base),
• 3 bits : un CRC pour vérifier que les entêtes recontruites sont correctes.

Nouvelles RFCs ROHC

Deux nouvelles RFCs apportant des précisions ou améliorations ont été publiées :

• La RFC 4995 apporte des précisions aux mécanismes définis dans la RFC 3095.
• La RFC 5225 définit des nouvelles versions des profils de compression.

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 :

• La RFC 3843 définit un profil de compression pour les entêtes IP ou les tunnels IP.
• La RFC 4019 définit une profil de compression pour les entêtes IP/UDP-Lite.

Liens externes

• La charte officielle du groupe de travail ROHC au sein de l'IETF
• RFC 3095 - "ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed"
• RFC 3096 - "Requirements for robust IP/UDP/RTP header compression"
• RFC 4815 - "Corrections and Clarifications to RFC 3095"
• RFC 3843 - "RObust Header Compression (ROHC): A Compression Profile for IP"
• RFC 4019 - "RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite"
• RFC 4995 - "The RObust Header Compression (ROHC) Framework"
• RFC 5225 - "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite"
• Une implémentation libre de ROHC pour PPP sur sourceforge.net
• Une implémentation libre et efficace de ROHC sous forme de bibliothèque