Groupe de travail Réseau	L-E. Jonsson, Ericsson	
Request for Comments : 3843	G. Pelletier, Ericsson	
Catégorie : Sur la voie de la normalisation	juin 2004	
Traduction Claude Brière de L'Isle		

Compression d'en-tête robuste (ROHC) :
un profil de compression pour IP

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The Internet Society (2004).

Résumé
La RFC de compression d'en-tête robuste (ROHC, RObust Header Compression) originale (RFC 3095) définit un cadre pour la compression d'en-tête, ainsi que les protocoles de compression (profils) pour IP/UDP/RTP, IP/ESP (Encapsulation de charge utile de sécurité), IP/UDP, et aussi un profil pour les flux de paquets non compressés. Cependant, aucun profil n'a été défini pour la compression de IP seulement, qui a été identifiée comme pièce manquante dans la RFC 3095. Le présent document définit un profil de compression ROHC pour IP, similaire au profil IP/UDP défini dans la RFC 3095, mais simplifié pour exclure UDP, et amélioré pour comprimer les chaînes d'en-têtes IP de longueur arbitraire.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Compression IP ROHC (profil 0x0004)	2
3.1 Terminaison de chaîne statique	2
3.2 Traitement de plusieurs niveaux d'en-tête IP	2
3.3 IP-ID constant 	3
3.4 Logique de transition de mode supplémentaire	4
3.5 Initialisation	5
3.6 Types de paquets	5
3.7 Option de rétroaction CONTEXT_MEMORY	6
4. Considérations sur la sécurité	6
5. Considérations relatives à l'IANA	6
6. Remerciements	6
9. Références normatives	6
Appendice A. Procédures détaillées pour annuler les transitions de mode	7
A.1 Transition du mode optimiste au mode fiable	7
A.2 Transition du mode unidirectionnel au mode fiable	7
A.3 Transition du mode fiable au mode optimiste	7
A.4 Transition de retour au mode unidirectionnel	8
Adresse des auteurs	8
Déclaration complète de droits de reproduction	9

 	1.	Introduction

La RFC de compression d'en-tête robuste (ROHC, RObust Header Compression) originale [RFC3095] définit un cadre pour la compression d'en-tête, ainsi que des protocoles de compression (profils) pour IP/UDP/RTP, IP/ESP (Encapsulation de charge utile de sécurité) IP/UDP, et aussi un profil pour les flux de paquets non compressés. Le profil pour les données non compressées a été défini pour fournir un moyen d'encapsuler tout le trafic sur une liaison au sein de paquets ROHC.  Avec ce profil, les couches inférieures n'ont pas à fournir de multiplexage pour les différents types de paquets, mais ROHC peut traiter tout flux de paquets, même si les profils de compression pour tous les types de flux de paquets n'ont pas encore été définis ou mis en œuvre sur la liaison.

Bien que le profil sans compression soit simple et puisse tunneler des paquets arbitraires, il a bien sûr une faiblesse majeure en ce qu'il ne compresse pas du tout les en-têtes. Quand on considère que normalement tous les paquets sont supposés être des paquets IP [RFC07910], [RFC2460], et que l'en-tête IP représente souvent la majeure partie de l'en-tête total, une solution de remplacement utile à pas de compression serait pour la plupart des paquets la compression de seulement l'en-tête IP. Malheureusement, un tel profil n'a pas été défini dans la [RFC3095], et cela a donc été identifié comme une importante pièce manquante dans la boîte à outils de ROHC.

Le présent document prend en charge cette compression manquante et définit un profil de compression ROHC pour IP [RFC0791], [RFC2460] seulement, similaire au profil IP/UDP défini par la [RFC3095], mais simplifié pour exclure UDP. Du fait des similarités avec le profil IP/UDP, le profil de compression IP est décrit sur la base du profil IP/UDP, couvrant principalement les différences. Les plus importantes différences sont une façon différente de terminer la chaîne d'en-tête statique, et la capacité de compresser les chaînes d'en-tête IP de longueur arbitraire.

 	2.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

ROHC UDP : "ROHC UDP" dans ce document se réfère au profil IP/UDP (profil 0x0002) défini dans la [RFC3095].

 	3.	Compression IP ROHC (profil 0x0004)

En général, il n'y a pas de différences majeures entre le profil ROHC UDP et le profil IP (ROHC IP) défini dans le présent document, car le retrait de UDP n'a pas d'impact en principe sur les mécanismes de compression. Comme pour ROHC UDP, le compresseur génère un numéro de séquence (SN, Sequence Number) de 16 bits qui augmente de un à chaque paquet compressé dans le flux de paquets. La plus importante différence entre ce profil et ROHC UDP est sur la terminaison de chaîne statique et le traitement d'en-têtes IP multiples. Sauf mention contraire explicite, les mécanismes et formats sont les mêmes que pour ROHC UDP.

 	3.1	Terminaison de chaîne statique
Une différence de la compression IP seulement, comparée à la compression IP/UDP, est relative à la terminaison de la chaîne statique dans les en-têtes d'état d’initialisation et de rafraîchissement (IR, Initiation and Refresh). Pour le profil UDP, la chaîne se termine toujours avec une partie d'en-tête UDP, qui par définition donne les limites de la chaîne. L'en-tête UDP est aussi le dernier en-tête dans le paquet non compressé (excepté pour un en-tête potentiel d'application). Pour le profil seulement IP, il n'y a pas un seul dernier en-tête qui par définition de profil termine la chaîne. Au lieu de cela, la chaîne statique est terminée si le champ "Prochain en-tête/protocole" d'une partie d'en-tête IP statique indique autre chose que IP (IP dans IP ou IPv6). Autrement, le compresseur peut choisir de terminer la chaîne statique à tout en-tête IP, et l'indiquer en réglant le bit de poids fort (MSB) du champ Version IP à 1 (0xC pour IPv4 ou 0xE pour IPv6). Le décompresseur doit mémoriser cette indication dans le contexte pour une décompression correcte des en-têtes suivants. Noter que le champ Version IP dans les en-têtes décompressés doit être restauré à sa valeur originale.

 	3.2	Traitement de plusieurs niveaux d'en-tête IP
Les paquets ROHC IR et IR-DYN définis dans la [RFC3095] sont utilisés pour communiquer les parties statiques et/ou dynamiques d'un contexte. Pour chacun des profils de compression définis dans la [RFC3095], il y a un seul dernier en-tête dans la chaîne d'en-têtes qui marque clairement la terminaison de la chaîne statique. La longueur de la chaîne dynamique est alors déduite de la chaîne statique dans l'en-tête IR lui-même, ou de la chaîne statique dans le contexte pour l'en-tête IR-DYN. La longueur des deux chaînes statique et dynamique peut donc être arbitraire et peut, en théorie, initialiser un contexte avec un nombre arbitraire de niveaux IP.

Cependant, les formats généraux d'en-tête compressé définis au paragraphe 5.7 de la [RFC3095] spécifient qu'au plus deux niveaux d'en-têtes IP (le niveau 'interne' et le niveau 'externe' des en-têtes IP) peuvent être inclus dans un en-tête compressé. Spécifiquement, le format défini pour l'extension 3 au paragraphe 5.7.5 de la [RFC3095] peut seulement porter un en-tête IP 'externe'. De plus, alors que la compression de liste peut être utilisée pour compresser d'autres types d'en-têtes, elle ne peut pas être utilisée pour compresser des en-têtes IP supplémentaires, car les en-têtes IP ne peuvent pas faire partie d'une chaîne d'en-tête d'extension dans des en-têtes compressés (paragraphe 5.8 de la [RFC3095]).

Pour les profils de compression définis dans la [RFC3095], la conséquence est qu'au plus deux niveaux d'en-têtes IP peuvent être compressés. En d'autres termes, la présence d'en-têtes IP supplémentaires désactive au mieux partiellement la compression d'en-tête, car il sera seulement permis au compresseur d'envoyer des paquets IR et IR-DYN dans ce cas.

Pour la compression d'en-têtes seulement IP, les en-têtes IP supplémentaires n'auraient cependant pas à causer de désactivation de la compression d'en-tête parce que il n'y a pas un seul type de paquet qui termine la chaîne compressée. Les en-têtes IP excédentaires pourraient simplement rester non compressés en terminant implicitement les chaînes statiques et dynamiques après au plus deux niveaux d'en-têtes IP.

Le profil IP seulement défini dans le présent document va un pas plus loin et prend en charge la compression d'un nombre arbitraire de niveaux IP. Cela est fait en ajoutant une chaîne dynamique au format général des en-têtes compressés, pour inclure la partie en-tête de chaque niveau IP en plus des deux premiers.

Comme expliqué précédemment, la chaîne statique au sein des paquets IR peut être de longueur arbitraire, et la chaîne est terminée par la présence d'un en-tête non IP (non IP dans IP ni IPv6). Autrement, la chaîne peut être explicitement terminée par une valeur de code spéciale dans le champ Version IP, comme décrit au paragraphe 3.1. La chaîne dynamique est structurée de façon analogue.

Pour les en-têtes compressés, les informations relatives aux deux en-têtes IP initiaux sont portées comme pour le profil IP/UDP, et une chaîne d'informations d'en-tête dynamiques est ajoutée à la fin de l'en-tête compressé pour chacun des en-têtes IP supplémentaires. Donc, cette structure de données supplémentaire est exactement la même que celle utilisée dans les paquets IR et IR-DYN. La longueur de la chaîne est déduite de la chaîne des paramètres statiques dans le contexte. Alors qu'une chaîne dynamique porte de façon dynamique tous les paramètres qui changent en utilisant une représentation non compressée, cela assure que des flux avec des niveaux arbitraires d'en-têtes IP ne vont pas entraver l'efficacité de la compression.

 	3.3	IP-ID constant
La plupart des piles IPv4 allouent un identifiant IP (IP-ID) selon la valeur d'un compteur, augmenté de un pour chaque paquet sortant. UDP ROHC compresse le champ IP-ID en utilisant un codage de décalage de l'IP-ID fondé sur le numéro de séquence UDP [RFC3095]. Pour les piles qui génèrent des valeurs d'IP-ID en utilisant un générateur de nombres pseudo aléatoires, le champ n'est pas compressé et est envoyé en entier comme octets supplémentaires après l'en-tête compressé.

Il y a aussi des cas où une pile IPv4 utilise une valeur constante pour l'identifiant IP. Quand le champ IP-ID est constant, il ne peut pas être compressé en utilisant le codage de décalage d'IP-ID et le champ doit être envoyé en entier. Ces frais généraux peuvent être évités par l'ajout d'un fanion au sein de la partie dynamique de la chaîne utilisée pour initialiser l'en-tête IPv4, comme suit :

Partie dynamique :

+---+---+---+---+---+---+---+---+
|        Type de service        |
+---+---+---+---+---+---+---+---+
|        Durée de vie           |
+---+---+---+---+---+---+---+---+
/        Identification         /   2 octets
+---+---+---+---+---+---+---+---+
| DF|RND|NBO|SID|       0       |
+---+---+---+---+---+---+---+---+
/ Liste générique d'en-têtes    /
/        d'extension            / longueur variable
+---+---+---+---+---+---+---+---+

SID (Static IP Identifier) : identifiant IP statique. Pour les paquets IR et IR-DYN, la logique est la même que pour ROHC UDP avec l'ajout que le champ (SID) doit être gardé dans le contexte. Pour les en-têtes compressés autres que IR et IR-DYN :
-	Si la valeur (RND) = 0 et si le contexte (SID) = 0, l'en-tête (IP-ID) est compressé en utilisant le codage de décalage d'IP-ID (voir le paragraphe 4.5.5 de la [RFC3095]) en utilisant p = 0 et le décalage de pente par défaut (IP-ID) = 0.
-	Si la valeur (RND) = 0 et contexte (SID) = 1, l'en-tête (IP-ID) est constant et est compressé ; l'en-tête (IP-ID) est la valeur de contexte (IP-ID).
-	Si la valeur (RND) = 1, IP-ID est l'en-tête non compressé (IP-ID). IP-ID est alors passé comme octets supplémentaires à la fin de l'en-tête compressé, après toutes les extensions.

Note : seuls les paquets IR et IR-DYN peuvent mettre à jour le contexte (SID). Tous les autres champs sont les mêmes que pour ROHC UDP [RFC3095].

 	3.4	Logique de transition de mode supplémentaire
Les profils définis dans la [RFC3095] opèrent en utilisant différents modes de compression. Une transition de mode peut être nécessaire une fois qu'un paquet a atteint le décompresseur en envoyant une rétroaction indiquant le mode désiré. Comme selon les spécifications de la [RFC3095], le compresseur est obligé d'honorer de telles demandes.

Pour le profil IP défini dans le présent document, le paramètre Mode pour le mode de valeur = 0 (types de paquets UOR-2, IR et IR-DYN) est redéfini pour permettre au compresseur de refuser une transition de mode demandé par le décompresseur:

Mode : mode de compression.  0 = (C) annuler la transition de mode

À réception du paramètre Mode réglé à '0', le décompresseur DOIT rester dans son mode de fonctionnement actuel et DEVRAIT s'interdire d'envoyer d'autres demandes de transition de mode pour le mode refusé pendant un certain temps.

Plus précisément, par référence aux paramètres C_TRANS, C_MODE, D_TRANS, et D_MODE définis au paragraphe 5.6.1 de la [RFC3095], les modifications suivantes s'appliquent quand le compresseur annule une transition de mode :

Paramètres pour le côté compresseur :

-  C_MODE : cette valeur ne doit pas être changée lors de l'envoi d'informations de mode au sein de paquets si le paramètre Mode est réglé à '0' (en réponse à une demande de transition de mode du décompresseur).

-  C_TRANS : C_TRANS est dans l'état (P) (en cours) quand il reçoit une demande de transition de mode du décompresseur. C_TRANS est réglé à (D) (fait) quand le compresseur reçoit an ACK pour un paquet UOR-2, IR-DYN, ou IR envoyé avec le paramètre Mode réglé au mode utilisé au moment où la demande de transition de mode a été initiée.

Paramètres pour le côté décompresseur :

-	D_MODE : D_MODE DOIT rester inchangé à réception d'un paquet UOR-2, IR-DYN, ou IR envoyé avec le paramètre mode réglé à '0'.

-	D_TRANS : D_TRANS est (P) (en cours) quand est reçu un paquet UOR-2, IR-DYN, ou IR envoyé avec le paramètre mode réglé à '0'. Il est réglé à (D) (fait) quand est reçu un paquet de type 1 ou 0 correspondant au mode inchangé.

La procédure résultante de transition de mode est décrite ci-dessous :

              Compresseur                     Décompresseur
             ----------------------------------------------
   C_MODE = X      |                               |  D_MODE = X
                   |   Demande de mode (Y) +-<-<-<-|  D_TRANS = I
                   |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = P     |-<-<-<-+                       |
   C_MODE = X      |                               |
                   |->->->-+ IR/IR-DYN/UOR-2(SN,C) |
                   |       +->->->->->->->-+       |
                   |->-..                  +->->->-|  D_TRANS = P
                   |->-..                          |  D_MODE = X
                   |           ACK(SN,X)   +-<-<-<-|
                   |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = D     |-<-<-<-+                       |
                   |                               |
                   |->->->-+   X-0, X-1*           |
                   |       +->->->->->->->-+       |
                   |                       +->->->-|  D_TRANS = D
                   |                               |

où X : mode utilisé avant le début de la transition de mode
     Y : mode demandé par le décompresseur
     C : annuler la transition de mode

 	3.5	Initialisation
Le contexte statique pour la compression IP ROHC peut être initialisé d'une des deux façons suivantes :

1)	En utilisant un paquet IR comme dans ROHC UDP, où le profil est 0x0004, et la chaîne statique se termine avec la partie statique d'un en-tête IP, où le champ Prochain en-tête/protocole a toute valeur sauf IP dans IP (4) ou IPv6 (41) [PROTOCOL], ou où le champ Version IP indique la terminaison (voir le paragraphe 3.1). Au compresseur, SN est initialisé à une valeur aléatoire quand le premier paquet IR est envoyé.

2)	En réutilisant un contexte existant. Ceci est fait avec un paquet IR-DYN, identifiant de profil 0x0004, où la chaîne dynamique correspond au préfixe de la chaîne statique existante, se terminant par un en-tête IP où le champ Prochain en-tête/protocole a toute valeur sauf IP dans IP (4) ou IPv6 (41) [PROTOCOL], ou où le champ Version IP indique la terminaison (voir le paragraphe 3.1). Au compresseur, SN est initialisé à une valeur aléatoire quand le premier paquet IR-DYN est envoyé.

Pour ROHC IP, la partie dynamique d'un paquet IR ou IR-DYN est similaire à celle pour ROHC UDP, avec un champ de deux octets contenant le SN présent à la fin de la chaîne dynamique dans les paquets IR et IR-DYN. On notera que les chaînes statiques et dynamiques ont une longueur arbitraire, et que le SN n'est ajouté qu'une seule fois, à la fin de la chaîne dynamique dans les paquets IR et IR-DYN.

 	3.6	Types de paquets
Sauf pour une nouvelle option de rétroaction (paragraphe 6.7) le seul format de paquet qui diffère de ROHC UDP est le format général pour les paquets compressés, qui n'a pas de somme de contrôle UDP à la fin. À la place, il se termine par une liste de portions d'en-tête dynamique, une pour chaque en-tête IP au dessus des deux initiales (si il en est, comme indiqué par la présence de portions d'en-tête correspondantes dans la chaîne statique).

Le format général pour un en-tête compressé est donc comme suit :

  0   1   2   3   4   5   6   7
 --- --- --- --- --- --- --- ---
:        Octet Add-CID          :                    |
+---+---+---+---+---+---+---+---+                    |
|Premier octet d'en-tête de base|                    |
+---+---+---+---+---+---+---+---+                    |
:                               :                    |
/   0, 1, ou 2 octets de CID    /                    |
:                               :                    |
+---+---+---+---+---+---+---+---+                    |
/ Reste de l'en-tête de base    /                    |
+---+---+---+---+---+---+---+---+                    |
:                               :                    |
/           Extension           /                    |
:                               :                    |
 --- --- --- --- --- --- --- ---                     |
:                               :                    |
+  IP-ID d'en-tête IPv4 externe +
:                               : (voir paragraphe 5.7 de la [RFC3095])
 --- --- --- --- --- --- --- ---
/ Données AH pour liste externe /                    |
 --- --- --- --- --- --- --- ---                     |
:                               :                    |
+  Somme de contrôle GRE        +                    |
:                               :                    |
 --- --- --- --- --- --- --- ---                     |
:                               :                    |
+  IP-ID d'en-tête IPv4 interne +                    |
:                               :                    |
 --- --- --- --- --- --- --- ---                     |
/ Données AH pour liste interne /                    |
 --- --- --- --- --- --- --- ---                     |
:                               :                    |
+  Somme de contrôle GRE        +                    |
:                               :                    |
 --- --- --- --- --- --- --- ---
:  Liste de chaînes dynamiques  :
/       pour en-têtes IP        /    variable, donné par la chaîne statique
:        supplémentaires        :           (ne comporte pas de SN)
 --- --- --- --- --- --- --- ---

Noter que la liste des chaînes dynamiques pour les en-têtes IP supplémentaires dans les paquets compressés n'a pas de numéro de séquence à la fin de la chaîne, car le SN est présent dans les en-têtes compressés de base.

 	3.7	Option de rétroaction CONTEXT_MEMORY
L'option CONTEXT_MEMORY informe le compresseur que le décompresseur n'a pas des ressources de mémoire suffisantes pour traiter le contexte du flux de paquets, car le flux est actuellement compressé.

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| Type d'opt = 9| Long. opt = 0 |
+---+---+---+---+---+---+---+---+

Quand il reçoit une option CONTEXT_MEMORY, le compresseur DEVRAIT prendre des mesures pour compresser le flux de paquets d'une façon qui exige moins de ressources de mémoire du décompresseur, ou arrêter de compresser le flux de paquets.

 	4.	Considérations sur la sécurité

Les considérations sur la sécurité de la [RFC3095] s'appliquent également au présent document, sans exceptions ni ajouts.

 	5.	Considérations relatives à l'IANA

L'identifiant de profil ROHC de 0x0004 a été réservé par l'IANA pour le profil défini dans le présent document.

 	6.	Remerciements

Les auteurs remercient Carsten Bormann, Fredrik Lindstrom, Tommy Lundemo, et en particulier les relecteurs désignés du document Kristofer Sandlund et Mark West, pour leurs précieuses révisions et apports.

 	9.	Références normatives

[RFC0791]	J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2460]	S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", décembre 1998. (MàJ par 5095, 6564 ; D.S ; Remplacée par RFC8200, STD 86)

[RFC3095]	C. Bormann et autres, "Compression d'en-tête robuste (ROHC) : cadre et quatre profils", juillet 2001. (MàJ par RFC3759, RFC4815) (P.S.)

[PROTOCOL]	"Assigned Internet Protocol Numbers", registre IANA à : http://www.iana.org/assignments/protocol-numbers 

 	Appendice A.	Procédures détaillées pour annuler les transitions de mode

Les profils définis dans la [RFC3095] opèrent en utilisant des modes de compression différents : unidirectionnel (U-Mode), bidirectionnel optimiste (O-Mode), et bidirectionnel fiable (R-Mode). La compression commence toujours en U-Mode, et les transitions de mode peuvent seulement être initiées par le décompresseur, paragraphe 5.6 de la [RFC3095]. Une transition de mode peut être demandée une fois qu'un paquet a atteint le décompresseur, par l'envoi d'une rétroaction indiquant le mode désiré.

En se référent aux paramètres C_TRANS, C_MODE, D_TRANS, et D_MODE définis au paragraphe 5.6.1 de la [RFC3095], les paragraphes qui suivent décrivent les procédures résultantes quand un compresseur refuse une demande de transition de mode du décompresseur comme décrit au paragraphe 3.4.

 	A.1	Transition du mode optimiste au mode fiable
Quand le décompresseur initie une transition de mode du mode optimiste (O) au mode fiable (R), l'annulation de la procédure de transition est la suivante :

             Compresseur                     Décompresseur
             ----------------------------------------------
                   |                               |
                   |        ACK(R)/NACK(R) +-<-<-<-|  D_TRANS = I
                   |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = P     |-<-<-<-+                       |
   C_MODE = O      |                               |
                   |->->->-+ IR/IR-DYN/UOR-2(SN,C) |
                   |       +->->->->->->->-+       |
                   |->-..                  +->->->-|  D_TRANS = P
                   |->-..                          |  D_MODE = O
                   |           ACK(SN,O)   +-<-<-<-|
                   |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = D     |-<-<-<-+                       |
                   |                               |
                   |->->->-+  UO-0, UO-1*          |
                   |       +->->->->->->->-+       |
                   |                       +->->->-|  D_TRANS = D

Le compresseur ne doit pas envoyer de types de paquets 1 ou 0 quand C_TRANS est P, c'est-à-dire, tant qu'il n'a pas reçu un ACK pour un paquet UOR-2, IR-DYN, ou IR envoyé avec le paramètre de transition de mode réglé à C. Quand le décompresseur reçoit un paquet UOR-2, IR-DYN, ou IR envoyé avec le paramètre de transition de mode réglé à C, il doit conserver la valeur D_MODE à O et régler D_TRANS à P. Quand le décompresseur reçoit des types de paquets 0 ou 1, après avoir accusé réception d'un paquet UOR-2, IR-DYN, ou IR, il règle D_TRANS à D.

 	A.2	Transition du mode unidirectionnel au mode fiable
L'annulation d'une transition du mode unidirectionnel au mode fiable suit la même procédure que définie au paragraphe 4.2.

 	A.3	Transition du mode fiable au mode optimiste
Quand le décompresseur initie une transition de mode de fiable à optimiste, l'annulation de la procédure de transition est décrite comme suit :

               Compresseur                     Décompresseur
             ----------------------------------------------
                   |                               |
                   |        ACK(O)/NACK(O) +-<-<-<-|  D_TRANS = I
                   |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = P     |-<-<-<-+                       |
   C_MODE = R      |                               |
                   |->->->-+ IR/IR-DYN/UOR-2(SN,C) |
                   |       +->->->->->->->-+       |
                   |->-..                  +->->->-|  D_MODE = R
                   |->-..                          |
                   |           ACK(SN,R)   +-<-<-<-|
                   |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = D     |-<-<-<-+                       |
                   |                               |
                   |->->->-+   R-0, R-1*           |
                   |       +->->->->->->->-+       |
                   |                       +->->->-|  D_TRANS = D
                   |                               |

Le compresseur ne doit pas envoyer de types de paquets 1 ou 0 quand C_TRANS est P, c'est-à-dire, tant qu'il n'a pas reçu un ACK pour un paquet UOR-2, IR-DYN, ou IR envoyé avec le paramètre de transition de mode réglé à C. Quand le décompresseur reçoit un paquet UOR-2, IR-DYN, ou IR envoyé avec le paramètre de transition de mode réglé à C, il doit garder la valeur D_MODE de R. Quand le décompresseur reçoit des types de paquets 0 ou 1, après avoir accusé réception d'un paquet UOR-2, IR-DYN, ou IR, il règle D_TRANS à D.

 	A.4	Transition de retour au mode unidirectionnel
Quand le décompresseur initie une transition de mode de fiable ou optimiste au mode unidirectionnel, l'annulation de la procédure de transition est la suivante :

              Compresseur                     Décompresseur
             ----------------------------------------------
               |                               |
               |        ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
               |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = P |-<-<-<-+                       |
   C_MODE = O/R|                               |
               |->->->-+ IR/IR-DYN/UOR-2(SN,C) |
               |       +->->->->->->->-+       |
               |->-..                  +->->->-|
               |->-..                          |
               |          ACK(SN,O/R)  +-<-<-<-|
               |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = D |-<-<-<-+                       |
               |          R-0, R-1* ou         |
               |->->->-+  UO-0, UO-1*          |
               |       +->->->->->->->-+       |
               |                       +->->->-| D_TRANS = D
                                                 D_MODE = O/R

Quand le décompresseur reçoit un paquet UOR-2, IR-DYN, ou IR envoyé avec le paramètre de transition de mode réglé à C, il doit garder la valeur de D_MODE au mode bidirectionnel déjà utilisé (soit le mode O, soit le mode R). Après avoir accusé réception du premier paquet UOR-2(C), IR-DYN(C), ou IR(C), le décompresseur DOIT continuer d'envoyer des rétroactions avec le paramètre Mode réglé au mode bidirectionnel en usage (soit O, soit R) jusqu'à ce qu'il reçoive des types de paquets 0 ou 1. Quand le décompresseur reçoit des types de paquets 0 ou 1, après avoir accusé réception d'un paquet UOR-2, IR-DYN, ou IR, il règle D_TRANS à D.

 	Adresse des auteurs

Lars-Erik Jonsson	Ghyslain Pelletier	
Ericsson AB	Ericsson AB	
Box 920	Box 920	
SE-971 28 Lulea, 	SE-971 28 Lulea, 	
Sweden	Sweden	
téléphone : +46 8 404 29 61	téléphone : +46 8 404 29 43	
mél : lars-erik.jonsson@ericsson.com 	mél : ghyslain.pelletier@ericsson.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2004).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administratif (IASA) de l'IETF.