Compression d’en-tête robuste (ROHC) sur PPP

Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître 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 (2002). Tous droits réservés

Résumé

Le présent document décrit une option pour négocier l’utilisation de la compression d’en-tête robuste (ROHC, robust header compression) sur les datagrammes IP transmis sur le protocole point à point (PPP). Il définit les extensions aux protocoles de commande de PPP pour IPv4 et IPv6.

Table des Matières

1. Introduction 1

2. Option Configuration 2

2.1 Format de l’option Configuration 2

2.2 Sous option PROFILES 3

3. Protocoles de commande de réseau multiples 4

3.1 Partage de l’espace d’identifiant de contexte 4

4. Démultiplexage des datagrammes 4

5. Considérations sur l’utilisation de ROHC 5

5.1 Profil non compressé 5

5.2 Choix de paramètre 5

6. Considérations sur la sécurité 5

7. Considérations relatives à l’IANA 6

8. Remerciements 6

9. Références 6

9.1 Références normatives 6

9.2 Références pour information 6

10. Adresse de l’auteur 7

11. Déclaration complète de droits de reproduction 7

1. Introduction

La compression d’en-tête robuste (ROHC, Robust Header Compression) telle que définie dans la [RFC3095] peut être utilisée pour la compression de datagrammes IPv4 et IPv6 ou de paquets encapsulés avec plusieurs en-têtes IP. La version initiale de ROHC se concentre sur la compression des en-têtes de paquet dans les flux RTP, tout en prenant en charge la compression d’autres flux UDP ; cependant, elle définit aussi un cadre dans lequel d’autres mécanismes de compression d’en-tête peuvent être insérés comme nouveaux profils. Les ajouts prévus à l’ensemble des profils acceptés par ROHC seront capables de compresser aussi les en-têtes de protocole de transport TCP.

Afin d’établir la compression des datagrammes IP envoyés sur une liaison PPP, chaque extrémité de la liaison doit se mettre d’accord sur un ensemble de paramètres de configuration pour la compression. Le processus de négociation des paramètres de liaison pour les protocoles de la couche réseau est traité dans PPP par une famille de protocoles de commande réseau (NCP, Network Control Protocol). Comme il y a des NCP distincts pour IPv4 et IPv6, le présent document définit les options de configuration à utiliser dans les deux NCP pour négocier les paramètres pour le schéma de compression.

ROHC n’exige pas que la couche liaison soit capable d’indiquer les types de datagrammes portés dans les trames de couche liaison. Cependant, il y a deux types de base d’en-têtes ROHC qui sont définis dans le cadre ROHC : des en-têtes à petit CID (zéro ou un octet est utilisé pour identifier le contexte de compression) et des en-têtes à grand CID (un ou deux octets sont utilisés à cette fin). Pour conserver des paquets PPP auto descriptifs, le présent document définit deux nouveaux types de champ Protocole de couche liaison des données PPP, un pour les paquets ROHC à petit CID, et un pour les paquets ROHC à grand CID. (Cela évite aussi un problème qui se produirait si PPP devait négocier les formats à utiliser dans IPCP et IPV6CP et si les deux processus de négociation devaient arriver à des résultats différents.) Un envoyeur ROHC en PPP peut envoyer des paquets dans l’un ou l’autres format de petit ou de grand CID à tout moment, c’est-à-dire que le paramètre LARGE_CIDS de la [RFC3095] n’est pas utilisé. Tout receveur ROHC en PPP DOIT être capable de traiter les deux paquets ROHC à petit et à grand CID, et donc aucune négociation de cette fonction n’est nécessaire.

ROHC suppose que la couche liaison livre les paquets en séquence. PPP ne réarrange normalement pas les paquets. Lorsque on utilise des mécanismes de réarrangement tels que PPP multiclasses multiliaisons [RFC2686], il faut veiller à ce que les paquets qui partagent le même contexte de compression ne soient pas réarrangés. (Noter que dans certains cas, le réarrangement peut être acceptable pour ROHC, comme au sein d’une séquence de paquets dont aucun ne change le contexte de décompression.)

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMETE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].

2. Option Configuration

Le présent document spécifie une nouvelle valeur de protocole de compression pour l’option Protocole de compression IP (IPCP, IP-Compression-Protocol) telle que spécifiée dans la [RFC1332]. La nouvelle valeur et le format d’option associé sont décrits au paragraphe 2.1.

Le format de l’option est structuré de façon à permettre de futures extensions au schéma ROHC.

Il peut valoir la peine de répéter ce que dit la section 4 de la [RFC1332] : "L’option Configuration de protocole de compression IP est utilisée pour indique la capacité à recevoir des paquets compressés. Chaque extrémité de la liaison doit demander séparément cette option si la compression bidirectionnelle est désirée". C’est-à-dire que l’option décrit les capacités du décompresseur (côté receveur) de l’homologue qui envoie la Demande de configuration.

Note : La spécification de la négociation de paramètre de couches liaison et réseau pour PPP [RFC1661], [RFC1331], [RFC1332] n’interdit pas plusieurs instances d’une option de configuration mais déclare que la spécification d’une option de configuration doit explicitement permettre plusieurs instances. D’après la spécification actuelle de l’option de configuration IPCP de protocole de compression IP [RFC1332] on peut déduire qu’elle ne peut être utilisée que pour choisir un seul protocole de compression à un moment donné.

Ceci était approprié à une époque où existait seulement un schéma de compression d’en-tête. Avec l’arrivée de la compression d’en-tête IP [RFC2507], [RFC2509], cela n’a pas réellement changé, car la RFC 2507 s’est essentiellement substituée à la RFC 1144. Cependant, avec ROHC, il peut très bien être maintenant souhaitable d’utiliser la compression TCP de la RFC 2507 TCP en conjonction avec la compression RTP/UDP de la RFC 3095.

Le présent document met maintenant à jour la RFC 1332 en permettant explicitement l’envoi de plusieurs instances de l’option de configuration Protocole de compression IP, chacune ayant une valeur différente pour le protocole de compression IP. Chaque type de protocole de compression peut établir indépendamment ses propre paramètres.

On pense que ce changement ne devrait pas causer de dommage significatif aux mises en œuvres existantes de PPP, car elles vont très probablement faire un Configure-Nak ou Configure-Reject en réponse à l’option dupliquée, ou simplement accepter la seule option qu’elles comprennent. Pour faciliter l’interopérabilité, l’homologue qui met en œuvre la présente spécification DEVRAIT réagir à un Configure-Nak ou Configure-Reject en réduisant le nombre d’options offertes à une.

2.1 Format de l’option Configuration

Le protocole de commande réseau pour IPv4, IPCP [RFC1332] et le NCP IPv6, IPV6CP [RFC2472] peuvent tous deux être utilisés pour négocier les paramètres de compression d’en-tête IP pour leurs protocoles respectifs. Le format de l’option de configuration est le même pour IPCP et IPV6CP.

Description : Cette option de configuration NCP est utilisée pour négocier les paramètres pour la compression d’en-tête robuste. Le format de l’option est résumé ci-dessous. Les champs sont transmis de gauche à droite.

Figure 1 : Option Compression d’en-tête robuste (ROHC)

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Longueur | Protocole de compression IP |

+---------------+---------------+---------------+---------------+

| MAX_CID | MRRU |

+---------------+---------------+---------------+---------------+

| MAX_HEADER | sous options...

+---------------+---------------+---------------+---------------+

Type : 2

Longueur : ≥ 10

La longueur peut être augmentée si la présence de paramètres supplémentaires est indiquée par des sous options supplémentaires.

Protocole de compression IP  : 0003 (hex)

MAX_CID : le champ MAX_CID fait deux octets et indique la valeur maximum d’un identifiant de contexte.

Valeur suggérée : 15

MAX_CID doit être d’au moins 0 et d’au plus 16383 (La valeur 0 implique d’avoir un contexte).

MRRU : le champ MRRU fait deux octets et indique l’unité maximum de réception reconstruite (voir le paragraphe 5.1.1 de la [RFC3095]).

Valeur suggérée : 0

MAX_HEADER : plus grande taille d’en-tête en octets qui peut être compressée.

Valeur suggérée : 168 octets

La valeur de MAX_HEADER devrait être assez grande pour qu’au moins l’en-tête extérieur de couche réseau puisse être compressé. Pour augmenter l’efficacité de compression, MAX_HEADER devrait être réglé à une valeur assez grande pour couvrir les combinaisons courantes d’en-têtes de couche réseau et transport.

Note : Les quatre profils ROHC définis dans la RFC 3095 ne fournissent pas de paramètre MAX_HEADER. Le paramètre MAX_HEADER défini par le présent document est donc sans conséquence sur ces profils. D’autres profils (par exemple, ceux fondés sur la RFC2507) peuvent faire usage du paramètre en y faisant explicitement référence.

sous options

Le champ sous options consiste en zéro, une ou plusieurs sous options. Chaque sous option consiste en un champ Type, un champ Longueur, et zéro, un ou plusieurs autres octets de paramètre, comme défini par le type de sous option. La valeur du champ Longueur indique la longueur de la sous option dans sa totalité, incluant les longueurs des champs Type et Longueur.

Figure 2 : Sous option

0 1 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Longueur | Paramètres...

+---------------+---------------+---------------+

2.2 Sous option PROFILES

L’ensemble de profils à activer est soumis à négociation. La plupart des mises en œuvre initiales de ROHC mettent en œuvre les profils 0x0000 à 0x0003. Cette option DOIT être fournie.

Description : Définit l’ensemble des profils pris en charge par le décompresseur.

Figure 3 : sous option PROFILES

0 1 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Longueur | Profils ...

+---------------+---------------+---------------+

Type : 1

Longueur : 2n+2

Profils : paires de n octets en ordre ascendant, chaque paire d’octets spécifiant un profil ROHC pris en charge.

3. Protocoles de commande de réseau multiples

Le protocole ROHC est capable de compresser les datagrammes IPv6 aussi bien que IPv4. IPCP et IPV6CP sont tous deux capables de négocier les valeurs de paramètres d’option pour ROHC. La capacité ROHC négociée comme un tout s’applique à la compression des paquets où l’en-tête extérieur est respectivement un en-tête IPv4 et un en-tête IPv6 ; par exemple, un en-tête IPv6 externe NE DOIT PAS être envoyé si l’option Protocole de compression IP de ROHC n’a pas été négociée pour IPV6CP.

Offrir une capacité ROHC spécifique dans une demande de configuration dans IPCP ou IPV6CP indique que la capacité est fournie pour le canal ROHC entier formé par la liaison PPP. Lorsque l’option a été négociée avec des valeurs différentes dans IPCP et IPV6CP, le résultat est que l’ensemble des valeurs de paramètres pour le canal ROHC entier est l’union logique des deux valeurs, c’est-à-dire, le maximum de MAX_CID, MRRU ou MAX_HEADER, et l’union logique des sous options. Pour la sous option PROFILES, l’union logique est l’union des deux ensembles de profils. Les valeurs unifiées sont conservées comme des valeurs de paramètre valides pour le canal ROHC même quand l’un ou l’autre des NCP est arrêté.

Noter que chaque nouvelle sous option pour cette option doit définir la signification de "union logique", si le concept s’applique.

3.1 Partage de l’espace d’identifiant de contexte

Pour la compression et la décompression des en-têtes de datagrammes IPv4 et IPv6, l’espace des identifiants de contexte est partagé. Lorsque les valeurs de paramètres sont négociées de façon indépendante, le partage des espaces d’identifiant de contexte devient plus complexe lorsque les valeurs de paramètre diffèrent. Comme les paquets compressés partagent l’espace d’identifiant de contexte, le moteur de compression doit allouer les identifiants de contexte à partir d’un réservoir commun ; pour les paquets compressés, le décompresseur doit examiner l’état du contexte pour déterminer quels paramètres utiliser pour la décompression.

En particulier, l’espace d’identifiant de contexte est partagé entre les paquets ROHC à petit CID et les paquets ROHC à grand CID. Du point de vue du cadre ROHC, les instances NCP de PPP pour IPCP et IPV6CP constituent ensemble exactement un canal ROHC ; son retour est destiné au canal ROHC défini par les instances de NCP pour IPCP et IPV6CP dans la direction inverse sur la même liaison PPP.

En particulier, cela signifie que fermer l’un ou l’autre des NCP lorsque l’autre est encore ouvert implique que les contextes du canal restent actifs. Pour éviter des conditions de compétition, la même chose est vraie si les deux NCP sont arrêtés et qu’ensuite un ou plusieurs sont rouverts. Arrêter un LCP détruit cependant le canal ; rouvrir le LCP et ensuite un ou plusieurs de IPCP et IPV6CP redémarre ROHC avec tous les contextes dans l’état no-context.

4. Démultiplexage des datagrammes

La spécification ROHC [RFC3095] définit un seul format d’en-tête pour tous les différents types d’en-têtes compressés, avec une variante pour les petits CID et une variante pour les grands CID. Deux valeurs de champ Protocole de couche Liaison de données PPP sont spécifiées ci-dessous.

Petits CID ROHC : La trame contient un paquet ROHC avec de petits CID comme défini dans la [RFC3095].

Valeur : 0003 (hex)

Grands CID ROHC  : la trame contient un paquet ROHC avec de grands CID comme défini dans la [RFC3095].

Valeur : 0005 (hex)

Noter que cela implique que tous les CID au sein d’un paquet ROHC DOIVENT être de la même taille qu’indiqué par le champ Protocole de couche liaison des données, qu’il soit petit ou grand. En particulier, le retour incorporé DOIT avoir un CID de la même taille qu’indiqué par la valeur du champ Protocole. Pour un retour porté, un compresseur doit être capable de contrôler la taille du CID du retour utilisé par le décompresseur associé, de s’assurer que tous les CID sont de la même taille, et d’indiquer cette taille avec la valeur de champ Protocole appropriée.

Pour rendre l’interprétation du CID non ambiguë lorsque la segmentation ROHC est utilisée, tous les paquets qui contribuent à un segment DOIVENT être envoyés avec la même valeur de champ Protocole de couche liaison de données, soit 0003, soit 0005, qui s’applique alors aussi à la taille de CID dans l’unité reconstruite. Une unité reconstruite à partir de valeurs de champ Protocole qui diffèrent DOIT être éliminée.

5. Considérations sur l’utilisation de ROHC

Certaines considérations sont requises pour tout protocole ROHC-sur-X. La présente section décrit comment certaines d’entre elles sont traitées pour ROHC sur PPP.

5.1 Profil non compressé

Il n’y a pas besoin de profil ROHC non compressé dans ROHC sur PPP, car les paquets non compressés peuvent toujours être envoyés en utilisant la méthode de démultiplexage du protocole PPP. Donc, aucune considération n’a été apportée à garder un des numéros de contexte pour le profil non compressé (voir le paragraphe 5.1.2 de la [RFC3095]). Noter cependant que selon la spécification ROHC, le profil 0x0000 ne doit pas être rejeté [RFC3095], donc il DOIT être mis en œuvre par tous les receveurs.

5.2 Choix de paramètre

Pour chacun des paramètres de canal ROHC MAX_CID et MRRU, la valeur est le maximum des valeurs respectives négociées pour les instances IPCP et IPv6CP, si il en est. Le paramètre de canal ROHC FEEDBACK_FOR est réglé implicitement à la direction inverse sur la même liaison PPP (voir ci-dessus le paragraphe "Partage de l’espace d’identifiant de contexte"). Le paramètre de canal ROHC LARGE_CIDS n’est pas utilisé ; on utilise à la place l’identifiant de protocole PPP sur le paquet (voir le paragraphe "Démultiplexage de datagrammes" ci-dessus).

Un certain nombre de paramètres pour ROHC doivent être réglés correctement pour une bonne compression sur une liaison spécifique. Par exemple, les paramètres k_1, n_1, k_2, n_2 du paragraphe 5.3.2.2.3 de la [RFC3095] doivent être réglés sur la base des caractéristiques d’erreur des liaisons sous-jacentes. Comme les liaisons PPP fonctionnent généralement avec un fort schéma de détection d’erreur [RFC1662], k_1 = n_1 = k_2 = n_2 = 1 est généralement un bon ensemble de valeurs. (Noter que dans tous les cas, k valeurs doivent être réglées assez bas par rapport à n valeurs pour permettre aux capacités limitées de CRC de détecter les erreurs, c’est-à-dire que le CRC va réussir pour environ 1/8 des paquets même dans le cas de contexte endommagé, de sorte que k/n devrait être significativement inférieur à 7/8.)

6. Considérations sur la sécurité

La négociation de l’option qu’on définit ici n’impose pas de considérations de sécurité supplémentaires au delà ce celles qui s’appliquent par ailleurs à PPP [RFC1661].

Les considérations de sécurité de ROHC [RFC3095] s’appliquent.

L’utilisation de la compression d’en-tête peut, dans de rares occasions, causer une mauvaise livraison de paquets. Si nécessaire, la confidentialité des contenus de paquet devrait être assurée par le chiffrement.

Le chiffrement appliqué à la couche IP (par exemple, en utilisant les mécanismes IPsec) empêche la compression des en-têtes chiffrés, bien que la compression de l’en-tête IP externe et des en-têtes d’authentification/sécurité soit toujours possible comme décrit dans la [RFC3095]. Pour les paquets RTP, la pleine compression d’en-tête est possible si la charge utile RTP est chiffrée par elle-même sans chiffrer les en-têtes UDP ou RTP, comme décrit dans la [RFC1889]. Cette méthode est appropriée lorsque les informations de l’en-tête UDP et RTP n’ont pas besoin de rester confidentielles.

7. Considérations relatives à l’IANA

L’identifiant de sous option ROHC est un entier non négatif. Suivant les politiques mentionnées dans la [RFC2434], la politique de l’IANA pour allouer de nouvelles valeurs à l’identifiant de sous option devra être "Spécification exigée" : les valeurs et leur signification doivent être documentées dans une RFC ou dans quelque autre référence permanente et directement disponible, en détail suffisant pour rendre possible l’interopérabilité entre des mises en œuvre indépendantes. La gamme de 0 à 127 est réservée pour les spécifications de l’IETF en cours de normalisation ; la gamme de 128 à 254 est disponible pour les autres spécifications qui satisfont cette exigence (comme les RFC pour information). La valeur 255 est réservée pour la future extensibilité de la présente spécification.

Les identifiants de sous option suivants sont déjà alloués :

Identifiant de sous option Document Usage

1 RFC3241 Profils

Le conseil de compressibilité de la [RFC3006] pour ROHC est 0x0003pppp, où 0xpppp est le profil supposé.

(Noter que les valeurs d’identifiant de protocole PPP 0003 et 0005 ont été prises d’un espace précédemment réservé qui présente une transparence inefficace en présence d’échappement de caractère de contrôle asynchrone, car il est considéré comme peu probable que ROHC soit utilisé sur des liaisons avec des tables de caractères de commande asynchrone (ACCM, Async-Control-Character-Map) très remplies.)

8. Remerciements

Le présent document emprunte beaucoup à la [RFC2509].

L’auteur tient à remercier Pete McCann et James Carlson qui ont précisé la question des instances d’option multiples, Craig Fox de son aide sur les arcanes de PPP, et Lars-Erik Jonsson qui a donné quelques précisions supplémentaires.

9. Références

9.1 Références normatives

[RFC1332] G. McGregor, "Protocole de contrôle de protocole Internet point à point (IPCP)", mai 1992. (MàJ 3241)

[RFC1661] W. Simpson, éditeur, "Protocole point à point (PPP)", STD 51, juillet 1994. (MàJ par la RFC2153)

[RFC2472] D. Haskin, E. Allen, "IP version 6 sur PPP", décembre 1998. (Obsolète, voir RFC5072, RFC5172) (P.S.)

[RFC3006] B. Davie et autres, "Services intégrés en présence de flux compressibles", novembre 2000. (P.S.)

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

9.2 Références pour information

[RFC1144] V. Jacobson, "Compression des en-têtes TCP/IP pour les liaisons série à faible débit", février 1990.

[RFC1889] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", janvier 1996. (Obsolète, voir RFC3550 STD64)

[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)

[RFC2507] M. Degermark, B. Nordgren, S. Pink, "Compression d'en-tête IP", février 1999. (P.S.)

[RFC2509] M. Engan, S. Casner, C. Bormann, "Compression d'en-tête IP sur PPP", février 1999. (Obsolète, voir RFC3544) (P.S.)

[RFC2686] C. Bormann, "Extension Multi-classe à PPP multi-liaison", septembre 1999. (P.S.)

10. Adresse de l’auteur

Carsten Bormann

Universitaet Bremen FB3 TZI

Postfach 330440

D-28334 Bremen, GERMANY

téléphone : +49.421.218-7024

Fax : +49.421.218-7000

mél : cabo@tzi.org

11. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2002). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant 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 violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.