Robust Header Compression

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 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.

Afin 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), 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 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.

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 & Rafraîchissement » (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 successifs.
• 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 régé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.

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 :

• 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 reconstruits sont corrects.

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.
• La RFC 6846 définit une profil de compression pour les entêtes IP/TCP.