Groupe de travail Réseau	G. Pelletier, Ericsson AB
Request for Comments : 4019	avril 2005
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Compression d'en-tête robuste (ROHC) : profils pour le protocole léger de datagramme d'utilisateur (UDP)

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 (2005).

Résumé
Le présent document définit les profils de compression d'en-tête robuste (ROHC, Robust Header Compression) pour la compression de paquets du protocole de transport en temps réel (RTP, Real-Time Transport Protocol) du protocole léger de datagramme d'utilisateur (UDP léger, User Datagram Protocol-Lite) et du protocole Internet (IP, Internet Protocol). Ces profils sont définis sur la base de leurs différences avec les profils pour UDP spécifiés dans la RFC 3095.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Fondements	2
3.1 Généralités sur le protocole UDP léger	2
3.2 Comportements attendus des flux UDP léger	3
3.3 Classification des champs d'en-tête	4
4. Raisons de la conception des profils ROHC pour UDP léger	4
4.1 Motivations de la conception	4
4.2 Considérations sur ROHC	4
5. Profils ROHC pour UDP léger	4
5.1 Paramètres de contexte	4
5.2 Initialisation	5
5.3 Formats de paquet	6
5.4 Logique du compresseur	7
5.5 Logique du décompresseur	8
5.6 Logique de transition de mode supplémentaire	8
5.7 Option de retour CONTEXT_MEMORY	8
5.8 IP-ID constant	8
6. Considérations sur la sécurité	9
12. Considérations relatives à l'IANA	9
8. Remerciements	9
9. Références	9
9.1 Références normatives	9
14.2 Références pour information	10
Appendice A. Classification détaillée des champs den-tête	10
A.1 Champs d'en-tête UDP léger	10
A.2 Stratégies de compression d'en-tête pour UDP léger	11
Appendice B Format détaillé du type de paquet CCE	12
Adresse de l'auteur	13
Déclaration complète de droits de reproduction	13

 	1.	Introduction

Le groupe de travail ROHC a développé un cadre de compression d'en-tête par dessus lequel divers profils peuvent être définis pour différents ensembles de protocoles ou stratégies de compression. Du fait des demandes de l'industrie du cellulaire d'un moyen efficace de transporter la voix sur IP sur les réseaux sans fil, ROHC [RFC3095] s'est principalement concentré sur la compression des en-têtes IP/UDP/RTP, qui sont de taille généreuse, en particulier par rapport aux charges utiles souvent portées par les paquets avec ces en-têtes.

ROHC RTP est devenu un schéma de compression très efficace, robuste, et capable de compresser les en-têtes jusqu'à une taille totale de seulement un octet. Aussi, la transparence est garantie dans une mesure extrêmement élevée, même quand des erreurs binaires résiduelles sont présentes dans les en-têtes compressés livrés au décompresseur.

UDP léger [RFC3828] est un protocole de transport similaire au protocole UDP [RFC0768]. UDP léger est utile pour les applications conçues avec la capacité de tolérer des erreurs dans la charge utile, pour lesquelles la réception de données endommagées vaut mieux que de traiter la perte de paquets entiers. Cela peut être particulièrement convenable quand les paquets sont transportés sur des technologies de liaisons dans lesquelles les données peuvent être partiellement endommagées, comme les liaisons sans fil.

Bien que ces protocoles de transport soient très similaires, les profils ROHC doivent être définis séparémena pour une compression robuste des en-têtes UDP léger parce que UDP léger ne partage pas le même identifiant de protocole que UDP. Aussi, le champ Couverture de somme de contrôle de UDP léger n'a pas la même sémantique que le champ Longueur correspondant de UDP, et par conséquent ne peut pas toujours en être déduit.

Le présent document définit deux profils ROHC pour une compression efficace des en-têtes UDP léger. L'objectif du présent document est de fournir de simples modifications aux profils ROHC correspondants pour UDP, spécifiés dans la [RFC3095]. De plus, les profils ROHC pour la prise en charge de UDP léger acceptent cerains des mécanismes définis dans le profil pour la compression des en-têtes IP [RFC3843] (ROHC IP seul). La présente spécification inclut la prise en charge de la compression de plusieurs en-têtes IP et de la compression des champs IP-ID avec comportement constant, ainsi qu'une logique de transition de mode améliorée et une option de retours pour les décompresseurs avec des ressources de mémoire limitées.

 	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 RTP : profil RTP/UDP/IP 0x0001 défini dans la [RFC3095].
ROHC UDP : profil UDP/IP 0x0002 défini dans la [RFC3095].
ROHC UDP-léger : profil UDP léger défini dans le présent document.
ROHC RTP/UDP-léger : profil RTP/UDP-léger/IP défini dans le présent document.

 	3.	Fondements
 	3.1	Généralités sur le protocole UDP léger
UDP léger est un protocole de transport défini comme une variante indépendante du protocole de transport UDP. UDP léger est très similaire à UDP, et il permet des applications qui peuvent tolérer des erreurs de la charge utile pour utiliser une somme de contrôle avec une couverture partielle facultative. Ceci est particulièrement utile avec IPv6 [RFC2460], dans lequel l'utilisation de la somme de contrôle de couche de transport est obligatoire.

UDP léger remplace le champ Longueur de l'en-tête UDP par un champ Couverture de somme de contrôle. Ce champ indique le nombre d'octets couverts par la somme de contrôle de 16 bits, qui est appliquée paquet par paquet. La zone de couverture inclut toujours l'en-tête UDP léger et peut couvrir le paquet entier, et dans ce cas UDP léger devient sémantiquement identique à UDP. UDP léger et UDP ne partagent pas le même identifiant de protocole.

Format d'en-tête UDP léger :

 0              15 16                 31
+--------+--------+----   ----+-- ------+
| Accès de source | Accès de destination|
+--------+--------+   --------+--- -----+
|Couverture de SC | Somme de contrôle   |
+--------+--------+---   -----+-- ------+
|                                       |
:           Charge utile                :
|                                       |
+-----------------+----    -------------+

Comme la somme de contrôle UDP, la somme de contrôle UDP léger est un mécanisme de bout en bout contre la livraison erronée de données sensibles à l'erreur. Cette somme de contrôle est obligatoire avec IPv6 [RFC2460] pour les deux protocoles. Cependant, à la différence de sa contrepartie UDP, la somme de contrôle UDP léger ne peut pas être transmise comme toute de zéros et ne peut pas être désactivée pour IPv4 [RFC0791]. Pour UDP, si la somme de contrôle est désactivée (IPv4 seul) le champ Somme de contrôle conserve une valeur constante et n'est normalement pas envoyé par le schéma de compression d'en-tête. Si la somme de contrôle UDP est activée (obligatoire pour IPv6) un tel champ imprévisible ne peut pas être compressé et est envoyé non compressé. Le champ Longueur UDP, est cependant toujours redondant et peut être fourni par le module IP. Les schémas de compression d'en-tête ne transmettent normalement pas de bits d'informations pour ce champ, car sa valeur peut être déduite de la couche de liaison.

Pour UDP léger, la somme de contrôle a aussi des valeurs imprévisibles, et ce champ doit toujours être inclus tel quel dans l'en-tête compressé pour IPv4 et IPv6. De plus, comme le champ Longueur UDP est redéfini comme champ Couverture de somme de contrôle par UDP léger, cela conduit à des propriétés différentes pour ce champ du point de vue de la compression d'en-tête.

On résume ci-dessous les relations entre UDP et UDP léger :
- UDP léger et UDP ont des identifiants de protocole différents.
- La somme de contrôle UDP léger ne peut pas être désactivée pour IPv4.
- UDP léger redéfinit le champ Longueur UDP comme champ Couverture de somme de contrôle, avec une sémantique différente.
- UDP léger est sémantiquement équivalent à UDP quand le champ Couverture de somme de contrôle indique la longueur totale du paquet.

Le paragraphe suivant donne une discussion plus détaillée du comportement du champ Couverture de somme de contrôle de UDP léger en relation avec la compression d'en-tête.

 	3.2	Comportements attendus des flux UDP léger
 	3.2.1	Comportement par paquet
Comme mentionné au paragraphe précédent, la valeur de la couverture de la somme de contrôle est appliquée indépendamment des autres paquets qui peuvent appartenir au même flux. Précisément, la valeur de la couverture de la somme de contrôle peut indiquer que le paquet UDP léger est soit entièrement couvert par la somme de contrôle, soit couvert jusqu'à une certaine limite inférieure à la taille du paquet mais incluant l'en-tête UDP léger.

 	3.2.2	Comportement inter paquets
En relation les uns avec chaque autre, les paquets UDP léger peuvent présenter un des trois schémas de changement possibles, où dans une séquence de paquets la valeur du champ Couverture de somme de contrôle est :
1. changeante, tout en couvrant le paquet entier ;
2. inchangée, couvrant jusqu'à une limite fixée dans le paquet; ou
3. changeante, mais ne suit aucun shéma spécifique.

Le premier schéma ci-dessus correspond à la sémantique de UDP, quand la somme de contrôle UDP est activée. Pour ce cas, le champ Couverture de somme de contrôle varie selon la longueur du paquet et peut être déduite de l'en-tête IP, comme l'est la valeur du champ Longueur UDP.

Le second schéma correspond au cas où la couverture est la même d'un paquet à l'autre au sein d'une séquence particulière. Dans ce cas, le champ Couverture de somme de contrôle peut être une valeur statique définie dans le contexte, et il n'a pas à être envoyé dans l'en-tête compressé. Pour le troisième cas, aucun schéma de changement utile ne peut être identifié d'un paquet à l'autre pour la valeur du champ Couverture de la somme de contrôle, et il doit être inclus dans l'en-tête compressé.

 	3.2.3	Comportement par-flux
On peut s'attendre à ce que l'un ou l'autre des schémas de changement ci-dessus pour les séquences de paquets puisse être prédominant à tout moement durant la durée de vie du flux UDP léger. Un flux qui suit de façon prédominante les deux premiers schémas de changement décrits ci-dessus peut donner des opportunités pour compresser le champ Couverture de somme de contrôle pour la plupart des paquets.

 	3.3	Classification des champs d'en-tête
En relation avec la classification des champs d'en-tête de la [RFC3095], les deux premiers schémas représentent le cas où la valeur du comportement du champ Couverture de somme de contrôle est fixé et peut être soit INFERRED (schéma 1) soit STATIC (schéma 2). Le schéma 3 est pour le cas où la valeur varie de façon imprévisible, le champ est CHANGING, et la valeur doit être envoyée avec chaque paquet.

Des informations supplémentaires concernant l'analyse du comportement des champs de UDP léger se trouvent à l'Appendice A.

 	4.	Raisons de la conception des profils ROHC pour UDP léger
 	4.1	Motivations de la conception
La simplicité est une motivation forte de la conception des profils de compression d'en-tête de UDP léger. Les profils définis pour UDP léger devraient n'entraîner que peu de modifications simples aux profils correspondants définis pour UDP dans la [RFC3095]. De plus, il est souhaitable d'inclure certaines des améliorations qui se trouvent dans le profil ROHC IP seul [RFC3843]. Finalement, chaque fois que UDP léger est utilisé d'une manière sémantiquement identique à UDP, l'efficacité de compression devrait être similaire.

 	4.2	Considérations sur ROHC
La plus simple approche de la définition des profils ROHC pour UDP léger est de traiter le champ Couverture de somme de contrôle comme une valeur irrégulière, et de l'envoyer non compressé pour chaque paquet. Cela peut être réalisé simplement en ajoutant le champ à la définition du format général de paquet [RFC3095]. Cependant, l'efficacité de la compression sera alors toujours inférieure à celle pour UDP.

Un certain soin devrait être apporté à réaliser une efficacité de compression similaire pour UDP léger à celle pour UDP quand le champ Couverture de somme de contrôle se comporte comme le champ Longueur UDP. Cela exige la possibilité de déduire le champ Couverture de somme de contrôle quand il est égal à la longueur du paquet. Autrement, cela donnerait au protocole UDP léger un désavantage sur les liaisons où la compression d'en-tête est utilisée, quand son comportement est rendu similaire à la sémantique de UDP.

Un mécanisme pour détecter la présence du champ Couverture de somme de contrôle dans les en-têtes compressés est donc nécessaire. Cela est réalisé en définissant un nouveau type de paquet avec les identifiants inutilisés dans la [RFC3095].

 	5.	Profils ROHC pour UDP léger

Cette Section définit deux profils ROHC :
- compression RTP/UDP léger/IP (profil 0x0007)
- compression UDP léger/IP (profil 0x0008)
Ces profils s'appuient sur les spécifications de la [RFC3095], avec aussi peu de modifications que possible. Sauf mention explicite contraire, les profils définis ici suivent les spécifications de, respectivement, ROHC UDP et ROHC RTP.
Noter aussi que le présent document réutilise la notation de la [RFC3095].

 	5.1	Paramètres de contexte
Comme décrit dans la [RFC3095], les informations sur les paquets précédents sont tenues dans un contexte. Cela inclut des informations décrivant les flux de paquets et les paramètres de compression. Bien que les protocoles UDP et UDP léger partagent de nombreuses caractéristiques, les différences de sémantique décrites antérieurement rendent le paramètre suivant inapplicable :

Paramètre contexte(Somme de contrôle UDP) : la somme de contrôle UDP léger ne peut pas être désactivée, à l'opposé de UDP. Le paramètre contexte(Somme de contrôle UDP) défini au paragraphe 5.7 de la [RFC3095] n'est donc pas utilisé pour la compression de UDP léger.

De plus, la somme de contrôle UDP léger est toujours envoyée telle quelle dans tous les paquets compressés. Cependant, le champ Couverture de somme de contrôle ne peut pas toujours être envoyé dans chaque paquet compressé, et le paramètre de contexte suivant est utilisé pour indiquer si le champ est envoyé :

Paramètre contexte(Champ Couverture UDP léger présent) : si le champ Couverture de somme de contrôle UDP léger est présent ou non dans le format général de paquet (paragraphe 5.3.1) est contrôlé par la valeur du fanion Champ de couverture présent (CFP) dans le contexte. Si contexte(CFP) n'est pas zéro, le champ Couverture de somme de contrôle n'est pas compressé, et il est présent dans les paquets compressés. Si contexte(CFP) est zéro, le champ Couverture de somme de contrôle est compressé, et il n'est pas envoyé. C'est le cas quand la valeur du champ Couverture de somme de contrôle suit un schéma stable de changement inter-paquets ; le champ a soit une valeur constante, soit il a une valeur égale à la longueur du paquet pour la plupart des paquets dans une séquence (paragraphe 3.2).

Finalement, le paramètre de contexte suivant est nécessaire pour indiquer si le champ devrait être déduit ou pris d'une valeur précédemment sauvegardée dans le contexte :

Paramètre contexte(Champ Couverture UDP léger déduit) : quand le champ Couverture de somme de contrôle UDP léger n'est pas présent dans l'en-tête compressé (CFP=0), si il est déduit est contrôlé par la valeur du fanion Champ Couverture déduit (CFI) dans le contexte. Si contexte(CFI) n'est pas zéro, le champ Couverture de somme de contrôle est déduit de la longueur du paquet, comme pour le champ Longueur UDP dans ROHC RTP. Si contexte(CFI) est zéro, le champ Couverture de somme de contrôle est décompressé en utilisant contexte(Couverture de somme de contrôle UDP léger). Donc, quand contexte(CFI) est mis à jour à une valeur non zéro, la valeur du champ Couverture de somme de contrôle mémorisée dans le contexte doit aussi être mise à jour.

 	5.2	Initialisation
Sauf mention contraire, les mécanismes de ROHC RTP et ROHC UDP de la [RFC3095] sont utilisés aussi pour les profils, respectivement, de ROHC RTP/UDP léger et ROHC UDP léger.

En particulier, les considérations de ROHC UDP concernant le numéro de séquence (SN) UDP qui tient le rôle du numéro de séquence RTP s'appliquent à ROHC UDP léger. Aussi, le contexte statique pour ROHC UDP léger peut être initialisé en réutilisant un contexte existant appartenant à un flux compressé en utilisant ROHC RTP/UDP léger (profil 0x0007), comme pour ROHC UDP.

 	5.2.1	Initialisation de l'en-tête UDP léger [1]
La structure des paquets IR et IR-DYN et les procédures d'initialisation sont les mêmes que pour les profils ROHC pour UDP [RFC3095], à l'exception de la partie dynamique comme spécifié pour UDP. Un champ de 2 octets contenant la couverture de la somme de contrôle est ajouté avant le champ Somme de contrôle. Cela affecte le format des chaînes dynamiques dans les paquets IR et IR-DYN.

Partie dynamique :
+---+---+---+---+---+---+---+----+
/ Couverture de somme de contrôle/   2 octets
+---+---+---+---+---+---+---+----+
/       Somme de contrôle        /   2 octets
+---+---+---+---+---+---+---+----+

CRC-DYNAMIC : champ Couverture de somme de contrôle, champ Somme de contrôle (octets 5 à 8).

CRC-STATIC : tous les autres champs (octets 1 à 4).

 	5.2.2	Logique du compresseur et du décompresseur
La logique suivante doit être utilisée par le compresseur et le décompresseur pour allouer des valeurs aux paramètres contexte(CFP) et contexte(CFI) durant l'initialisation:

Contexte(CFP) : durant l'initialisation du contexte, la valeur de contexte(CFP) DOIT être réglée à une valeur non zéro si le champ Couverture de somme de contrôle diffère de la longueur du paquet UDP léger, pour tout paquet IR ou IR-DYN envoyé (compresseur) ou reçu (décompresseur) ; autrement, la valeur DOIT être réglée à zéro.

Contexte(CFI) : durant l'initialisation du contexte, la valeur de contexte(CFI) DOIT être réglée à une valeur non zéro si le champ Couverture de somme de contrôle est égal à la longueur du paquet UDP léger au sein d'un paquet IR ou IR-DYN  envoyé (compresseur) ou reçu (décompresseur) ; autrement, la valeur DOIT être réglée à zéro.

 	5.3	Formats de paquet
Le format général de paquet, comme défini dans la [RFC3095], est modifié pour inclure un champ supplémentaire pour la couverture de la somme de contrôle UDP léger. Un type de paquet est aussi défini pour traiter la sémantique et les caractéristiques spécifiques de ce champ.

 	5.3.1	Format général de paquet
Le format général de paquet d'un en-tête UDP léger compressé par ROHC est similaire à l'en-tête RTP compressé par ROHC ([RFC3095], paragraphe 5.7) avec les modifications du champ Somme de contrôle, ainsi que des champs supplémentaires pour traiter plusieurs en-têtes IP et pour la couverture de la somme de contrôle UDP léger :

--- --- --- --- --- --- --- ---
:            Liste des         :  variable, donné par chaîne statique
/    chaines dynamiques pour   /  (n'inclut pas de SN)
: en-têtes IP supplémentaires  :  voir aussi [RFC3843], paragraphe 3.2.
--- --- --- --- --- --- --- ---
:      Couverture de la        :  2 octets,
+  somme de contrôle UDP léger +  si contexte(CFP) = 1 ou
:                              :  si type de paquet = CCE (voir 5.3.2)
--- --- --- --- --- --- --- ---
:                              :
+  Somme de contrôle UDP léger +  2 octets
:                              :
--- --- --- --- --- --- --- ---

La liste des chaînes d'en-têtes dynamiques porte la partie en-tête dynamique de chaque en-tête IP en plus des deux initiaux, si il en est (comme indiqué par la présence des parties d'en-tête correspondantes dans la chaîne statique). Noter qu'il n'y a pas de numéro de séquence à la fin de la chaîne, car SN est présent dans les en-têtes de base compressés.

L'ordre des champs suivant l'extension facultative du format général de paquet ROHC est le même que l'ordre entre les champs dans l'en-tête non compressé.

Quand le CRC est calculé, le champ Couverture de somme de contrôle est CRC-DYNAMIC.

 	5.3.2	Type de paquet CCE : CCE(), CCE(ON), et CCE(OFF)
Les profils ROHC pour UDP léger définissent un type de paquet pour traiter les divers schémas de changement possibles de la couverture de la somme de contrôle. Ce type de paquet peut être utilisé pour manipuler les valeurs de contexte qui contrôlent la présence du champ Couverture de somme de contrôle au sein du format général de paquet (c'est-à-dire, contexte(CFP)) et comment le champ est décompressé (c'est-à-dire, contexte(CFI)). Les deux octets du champ Couverture de somme de contrôle sont toujours présents dans le format de ce paquet (paragraphe 5.3.1).

Ce type de paquet est appelé Extension de couverture de somme de contrôle (CCE, Checksum Coverage Extension) et ses propriétés de mise à jour dépendent des deux bits finaux de l'octet Type de paquet (voir le format ci-dessous). Un schéma de désignation de la forme CCE(<une_propriété>) est utilisé pour identifier de façon univoque les propriétés d'un paquet CCE particulier.

Bien que ce type de paquet définisse son propre format, il peut être considéré comme un mécanisme d'extension pour les paquets de type 2, 1, ou 0 [RFC3095]. Ceci est réalisé en substituant l'identifiant de type de paquet du premier octet de l'en-tête de base (l'identifiant "externe") à un des types de paquet inutilisés de la [RFC3095]. L'identifiant substitué est alors déplacé au premier octet du reste de l'en-tête de base (l'identifiant "interne").

Le format du type de paquet CCE ROHC UDP léger est comme suit :

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   1   1   1   0 | F | K |  identifiant de type de paquet externe
+===+===+===+===+===+===+===+===+
:                               :  (avec identifiant de type interne)
/    En-tête de base interne    /  nombre de bits variable, donné par
:                               :  l'identifiant de type de paquet interne
+---+---+---+---+---+---+---+---+

F,K : F,K = 00 est réservé au niveau du cadre (IR-DYN) ;
          F,K = 01 indique CCE() ;
          F,K = 10 indique CCE(ON) ;
          F,K = 11 indique CCE(OFF).

Propriétés de mise à jour : les propriétés de mise à jour du type de paquet interne portées dans tout paquet CCE sont toujours maintenues. CCE(ON) et CCE(OFF) NE DOIT PAS être utilisé pour étendre les en-têtes R-0 et R-1*. De plus, CCE(ON) met toujours à jour contexte(CFP) ; CCE(OFF) met toujours à jour contexte(CFP), contexte(CFI), et contexte(Couverture de somme de contrôle UDP léger).

L'Appendice B donne des précisions sur le format résultant du type de paquet CCE.

 	5.3.2.1	Propriétés de CCE()
À côté des propriétés de mise à jour du type de paquet interne porté dans CCE(), ce paquet ne met pas à jour d'autres valeurs de contexte. CCE() est donc ignorant du mode ; par exemple, il peut étendre tous types de paquet 2, 1, et 0, sans considération du mode de fonctionnement courant [RFC3095].

CCE() peut être utilisé quand la couverture de la somme de contrôle dévie du schéma de changement supposé par le compresseur, où le champ pouvait précédemment être compressé. Ce paquet est utile si l'occurrence de telles déviations est rare.

 	5.3.2.2	Propriétés de CCE(ON)
En plus des propriétés de mise à jour du type de paquet interne, CCE(ON) met à jour contexte(CFP) à une valeur non zéro ; c'est-à-dire, il active effectivement la présence du champ Couverture de somme de contrôle au sein du format général de paquet. Ceci est utile quand le schéma de changement prédominant de la couverture de la somme de contrôle empêche sa compression.

CCE(ON) peut étendre tout paquet de mise à jour de contexte de type 2, 1, et 0 ; c'est-à-dire, les paquets avec un en-tête compressé contenant un CRC [RFC3095]. Spécifiquement, les en-têtes R-0 et R-1* NE DOIVENT PAS être étendus en utilisant CCE(ON).

 	5.3.2.3	Propriétés de CCE(OFF)
En plus des propriétés de mise à jour du type de paquet interne, CCE(OFF) met à jour contexte(CFP) à une valeur de zéro ; c'est-à-dire, il désactive effectivement la présence du champ Couverture de somme de contrôle au sein du format général de paquet. Ceci est utile quand le schéma de changement de la couverture de la somme de contrôle dévie rarement du schéma supposé par le compresseur.

CCE(OFF) met aussi à jour contexte(CFI) à une valeur non zéro, si champ(Couverture de somme de contrôle UDP léger) est égal à la longueur de paquet ; autrement, il doit être réglé à zéro. Noter que quand contexte(CFI) est mis à jour en utilisant le type de paquet CCE(OFF), une correspondance de champ(Couverture de somme de contrôle) avec la longueur de paquet a toujours la préséance sur une correspondance avec contexte(Couverture de somme de contrôle). Finalement, contexte(Couverture de somme de contrôle UDP léger) est aussi mis à jour par CCE(OFF).

Comme CCE(ON), CCE(OFF) peut étendre tous les paquets de mise à jour de contexte de type 2, 1, et 0 [RFC3095].

 	5.4	Logique du compresseur
Si en-tête(Couverture de somme de contrôle UDP léger) est différent de contexte(Couverture de somme de contrôle UDP léger) et différent de la longueur de paquet quand contexte(CFP) est zéro, le champ Couverture de somme de contrôle ne peut pas être compressé. De plus, si en-tête(Couverture de somme de contrôle UDP léger) est différent de la longueur de paquet quand contexte(CFP) est zéro et contexte(CFI) est non zéro, le champ Couverture de somme de contrôle ne peut pas être compressé non plus. Dans les deux cas, le champ doit être envoyé non compressé en utilisant un paquet CCE, ou le contexte doit être réinitialisé en utilisant un paquet IR.

 	5.5	Logique du décompresseur
Pour les types de paquets autres que IR, IR-DYN, et CCE qui sont reçus quand la valeur de contexte(CFP) est zéro, le champ Couverture de somme de contrôle doit être décompressé en utilisant la valeur mémorisée dans le contexte si la valeur de contexte(CFI) est zéro ; autrement, le champ est déduit de la longueur du paquet UDP léger dérivé du module IP.

 	5.6	Logique de transition de mode supplémentaire
Les profils définis dans le présent document permettent au compresseur de décliner une transition de mode demandée par le décompresseur. Ceci est réalisé en redéfinissant le paramètre Mode à la valeur mode = 0 (dans les types de paquets UOR-2, IR, et IR-DYN) comme suit (voir aussi le paragraphe 3.4 de la [RFC3843]) :

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'abstenir d'envoyer d'autres demandes de transition de mode pour le mode refusé.

 	5.7	Option de retour CONTEXT_MEMORY
Cette option de retour informe le compresseur que le décompresseur n'a pas de ressources de mémoire suffisantes pour traiter le contexte du flux de paquets requis par la structure compressée courante.

   0    1    2    3    4    5    6   7
+----+----+----+----+----+----+----+----+
| Type d'option = 9 |Longueur option = 0|
+----+----+----+----+----+----+----+----+

À réception d'une option CONTEXT_MEMORY, le compresseur DEVRAIT agir 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.

 	5.8	IP-ID constant
Les profils pour la prise en charge de la compression UDP léger du champ IP-ID avec comportement constant, avec l'ajout du fanion Identifiant IP statique (SID, Static IP Identifier) dans la partie dynamique de la chaîne utilisée pour initialiser l'en-tête IPv4, sont comme suit (voir aussi le paragraphe 3.3 de la [RFC3843]) :

Partie dynamique :

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

SID : Identifiant IP statique.

Pour les paquets IR et IR-DYN : la logique est la même que pour les profils ROHC respectifs pour 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 valeur(RND) = 0 et contexte(SID) = 0, en-tête(IP-ID) est compressé en utilisant le codage de décalage IP-ID (voir le paragraphe 4.5.5 de la [RFC3095]) en utilisant p = 0 et pente par défaut(décalage IP-ID) = 0.

Si valeur(RND) = 0 et contexte(SID) = 1, en-tête(IP-ID) est constant et compressé ; en-tête(IP-ID) est la valeur de contexte(IP-ID).

Si valeur(RND) = 1, IP-ID est l'en-tête(IP-ID) non compressé. 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 contexte(SID).

Note : tous les autres champs sont les mêmes que pour les profils ROHC respectifs pour UDP [RFC3095].

 	6.	Considérations sur la sécurité

Les considérations sur la sécurité de la [RFC3095] s'appliquent intégralement au présent document, sans modification.

 	12.	Considérations relatives à l'IANA

Les identifiants de profil ROHC 0x0007 (ROHC RTP/UDP léger) et 0x0008 (ROHC UDP léger) ont été réservés par l'IANA pour les profils définis dans le présent document (RFC 4019).

Deux identifiants de profil ROHC doivent être réservés par l'IANA pour les profils définis dans le présent document. Comme le numéro de profil 0x0006 est gardé pour le profil TCP/IP (ROHC-TCP) les numéros de profil 0x0007 et 0x0008 sont les identifiants disponibles non utilisés les plus convenables, et devraient donc être utilisés. Comme pour les profils ROHC précédents, les numéros de profil 0xnn07 et 0xnn08 doivent aussi être réservés pour de futures variantes de ces profils. L'enregistrement suggéré pour l'espace de noms "Identifiants de profil de compression d'en-tête robuste (ROHC)" est :

ANCIEN : 0x0006-0xnn7F	à allouer par l'IANA

NOUVEAU : 0xnn06	à allouer par l'IANA
                       0x0007	ROHC RTP/UDP léger        [RFC4019]             0xnn07            Réservé
                       0x0008	ROHC UDP léger                [RFC4019]
                       0xnn08	Réservé
                       0x0009 à 0xnn7F	à allouer par l'IANA

 	8.	Remerciements

L'auteur tient à remercier Lars-Erik Jonsson, Kristofer Sandlund, Mark West, Richard Price, Gorry Fairhurst, Fredrik Linstroem et Mats Nordberg pour leurs relectures et discussions utiles du présent document.

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

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

[RFC3241]	C. Bormann, "Compression d'en-tête robuste (ROHC) sur PPP", avril 2002. (MàJ par RFC4815) (P.S.)

[RFC3828]	L-A. Larzon et autres, "Protocole léger de datagramme d'utilisateur (UDP léger)", juillet 2004. (P.S, MàJ par RFC6335)

[RFC3843]	L-E. Jonsson, G. Pelletier, "Compression d'en-tête robuste (ROHC) : un profil de compression pour IP", juin  2004. (MàJ par RFC4815) (P.S.)

 	14.2	Références pour information
[RFC0768]	J. Postel, "Protocole de datagramme d’utilisateur (UDP)", (STD 6), 28 août 1980.

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

[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)

[RFC3550]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003. (MàJ par RFC7164, RFC7160, RFC8083, RFC8108, RFC8860)

 	Appendice A. Classification détaillée des champs den-tête

Cet Appendice résume les différences entre la classification qui se trouve dans l'appendice correspondant de la [RFC3095] et donne des conclusions sur les divers champs d'en-tête qui devraient être traités par le schéma de compression d'en-tête pour optimiser la compression et les fonctionnalités. Ces conclusions sont séparées sur la base du comportement du champ Couverture de la somme de contrôle UDP léger et de l'utilisation des schémas attendus de changement décrits au paragraphe 3.2 du présent document.

 	A.1	Champs d'en-tête UDP léger
Le tableau suivant résume la classification possible pour les champs d'en-tête UDP léger comparés à la classification pour UDP, en utilisant les mêmes classes que dans la [RFC3095].

Champs d'en-tête de UDP léger et UDP :
Champ d'en-tête	Taille (bits)	Classe UDP léger	Classe UDP	
Accès de source	16	STATIC-DEF	STATIC-DEF	
Accès de destination	16	STATIC-DEF	STATIC-DEF	
Couverture de somme de contrôle	16	INFERRED STATIC CHANGING		
Longueur	16	INFERRED		
Somme de contrôle	16	CHANGING	CHANGING	

Accès de source et de destination : le même que pour UDP. Précisément, ces champs font partie de la définition d'un flux et doivent donc être constants pour tous les paquets du flux. Les champs sont donc classés comme STATIC-DEF.

Couverture de somme de contrôle : ce champ spécifie quelle partie du datagramme UDP léger est couverte par la somme de contrôle. Il peut avoir une valeur de zéro ou être égal à la longueur du datagramme si la somme de contrôle couvre le datagramme entier, ou il peut avoir toute valeur entre huit octets et la longueur du datagramme pour spécifier le nombre d'octets protégés par la somme de contrôle, calculée depuis le premier octet de l'en-tête UDP léger. La valeur de ce champ peut varier pour chaque paquet, et cela rend la valeur imprévisible du point de vue de la compression d'en-tête.

Somme de contrôle : les informations utilisées pour le calcul de la somme de contrôle UDP léger sont gouvernées par la valeur de la couverture de la somme de contrôle et inclut au minimum l'en-tête UDP léger. La somme de contrôle est un champ changeant qui doit toujours être envoyé tel quel.

La taille totale des champs dans chaque classe, pour chaque schéma de changement attendu (paragraphe 3.2), est résumée dans les tableaux ci-dessous :

Schéma 1 :
Classe	Taille (octets)
INFERRED	2	Couverture de somme de contrôle
STATIC-DEF	4	Accès de source / accès de destination
CHANGING	2	Somme de contrôle

Schéma 2 :
Classe	Taille (octets)
STATIC-DEF	4	Accès de source / accès de destination
STATIC	2	Couverture de somme de contrôle
CHANGING	2	Somme de contrôle

Schéma 3 :
Classe	Taille (octets)
STATIC-DEF	4	Accès de source / accès de destination
CHANGING	4	Couverture de somme de contrôle / Somme de contrôle

 	A.2	Stratégies de compression d'en-tête pour UDP léger
Le tableau suivant revisite le tableau correspondant (tableau A.1) pour UDP du paragraphe A.2 de la [RFC3095] et classe les champs changeants sur la base des schémas de changement identifiés précédemment au paragraphe 3.2.

Stratégies de compression d'en-tête pour UDP léger :
Champ	Schéma	Valeur/Delta	Classe	Connaissance
	n° 1	Valeur	CHANGING	INFERRED
Couv. somme de contrôle	n° 2	Valeur 	RC	INCONNU
	n° 3	Valeur	IRREGULIER	INCONNU
Somme de contrôle 	Tous	Valeur	IRREGULIER	 INCONNU

 	A.2.1	Transmission initiale mais prêt à mettre à jour
Couverture de somme de contrôle UDP léger (Schémas n° 1 et n° 2)

 	A.2.2	Transmission telle qu'elle dans tous les paquets
Somme de contrôle UDP léger
Couverture de somme de contrôle UDP léger (schéma n° 3)

 	Appendice B	Format détaillé du type de paquet CCE

Cet Appendice donne une vue étendue du format du paquet CCE, sur la base du format général d'en-tête compressé ROHC RTP [RFC3095] et du format général d'un en-tête compressé du profil ROHC IP-seul [RFC3843]. Les modifications nécessaires pour porter l'en-tête de base d'un paquet de type 2, 1 ou 0 [RFC3095] au sein du format de paquet CCE, avec les champs supplémentaires pour traiter de façon appropriée la compression de plusieurs en-têtes IP, résultent en la structure suivante pour le type de paquet CCE :

  0   1   2   3   4   5   6   7
 --- --- --- --- --- --- --- ---
:         octet Add-CID         :  Si ce sont de petits CID et les CID 1 à 15
+---+---+---+---+---+---+---+---+
| 1   1   1   1   1   0   F | K |  Identifiant de type de paquet externe
+---+---+---+---+---+---+---+---+
:                               :
/   0, 1, ou 2 octets de CID    /  1 - 2 octets si ce sont de grands CID
:                               :
+---+---+---+---+---+---+---+---+
|Premier octet d'en-tête de base|  (avec l'indication de type "interne")
+---+---+---+---+---+---+---+---+
/    Reste de l'en-tête de base /  Nombre de bits variable
+---+---+---+---+---+---+---+---+

  0   1   2   3   4   5   6   7
--- --- --- --- --- --- --- ---
:                              :
/         Extension            /  Voir [RFC3095], paragraphe 5.7.
:                              :
--- --- --- --- --- --- --- ---
:                              :
+ IP-ID d'en-tête IPv4 externe +  Voir [RFC3095], paragraphe 5.7.
:                              :
--- --- --- --- --- --- --- ---
/Données AH pour liste externe /  Voir [RFC3095], paragraphe 5.7.
--- --- --- --- --- --- --- ---
:                              :
+  Somme de contrôle GRE       +  Voir [RFC3095], paragraphe 5.7.
:                              :
--- --- --- --- --- --- --- ---
:                              :
+ IP-ID d'en-tête IPv4 interne +  Voir [RFC3095], paragraphe 5.7.
:                              :
--- --- --- --- --- --- --- ---
/Données AH pour liste interne /  Voir [RFC3095], paragraphe 5.7.
--- --- --- --- --- --- --- ---
:                              :
+  Somme de contrôle GRE       +  Voir [RFC3095], paragraphe 5.7.
:                              :
--- --- --- --- --- --- --- ----
:   Liste de chaînes            :  Variable, donné par la chaîne statique
/    dynamiques pour            /  (n'inclut pas de SN).
:  en-têtes IP supplémentaires  :  Voir [RFC3843], paragraphe 3.2.
--- --- --- --- --- --- --- ----
:        Couverture de la       :
+  somme de contrôle UDP léger  +  2 octets
:                               :
+---+---+---+---+---+---+---+---+
:                               :
+  Somme de contrôle UDP léger  +  2 octets
:                               :
+---+---+---+---+---+---+---+---+

F,K : F,K = 00 est réservé au niveau cadre (IR-DYN) ;
          F,K = 01 indique CCE() ;
         F,K = 10 indique CCE(ON) ;
         F,K = 11 indique CCE(OFF).

Noter que le présent document ne définit pas (F,K) = 00, car cela entrerait en collision avec le type de paquet IR-DYN déjà réservé au niveau du cadre ROHC.

 	Adresse de l'auteur

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

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2005)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, 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 fournies 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, le IETF TRUST 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 pourraient ê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 le 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 de l'IETF (IASA).