Groupe de travail Réseau	J. Ash, éditeur, AT&T	
Request for Comments : 4901	J. Hand, éditeur, AT&T	
Catégorie : Sur la voie de la normalisation	A. Malis, éditeur, Verizon Communications	
Traduction Claude Brière de L'Isle	juin 2007	

Extensions de protocole pour compression d'en-tête sur MPLS

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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 (2007). Tous droits réservés.

Résumé
La présente spécification définit comment utiliser la commutation d'étiquettes multi protocoles (MPLS, Multi-Protocol Label Switching) pour acheminer les paquets à en-tête compressé (HC, Header-Compressed) sur un chemin d'étiquettes MPLS commutées. HC peut significativement réduire les frais généraux d'en-tête de paquet et, combiné avec MPLS, peut aussi augmenter l'efficacité de la bande passante et l'adaptabilité du traitement en termes de nombre maximum de flux compressés simultanément qui utilisent HC à chaque routeur). On définit ici comment les pseudo filaires MPLS sont utilisés pour transporter les messages de contexte et contrôle HC entre les routeurs de commutation d'étiquettes MPLS d'entrée et de sortie. Ceci est défini pour un ensemble spécifique de mécanismes de HC existants qui pourraient être utilisés, par exemple, pour prendre en charge la voix sur IP. La présente spécification décrit aussi des mécanismes d'extension pour permettre la prise en charge future, à définir, de protocoles de HC. Dans cette spécification, chaque protocole de HC opère indépendamment sur une seule instance de pseudo filaire, de façon très semblable à ce qui se ferait sur une seule liaison en point à point.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Vue d'ensemble de la compression d'en-tête sur le protocole MPLS	3
4. Spécifications du protocole	6
4.1 Établissement et signalisation de pseudo-filaire MPLS	7
4.2 Établissement, négociation, et signalisation de schéma de compression d'en-tête	8
4.3 Encapsulation de paquets à en-tête compressé	12
4.4 Réarrangement de l'ordre des paquets	13
5. Exemple d'établissement de pseudo-filaire HC	13
6. Considérations sur la sécurité	16
7. Remerciements	16
8. Considérations relatives à l'IANA	17
9. Références normatives	17
10. Références pour information	17
11. Contributeurs	18
Adresse des éditeurs	19
Déclaration complète de droits de reproduction	19

 	1.	Introduction

La voix sur IP (VoIP, Voice over IP) utilise normalement l'encapsulation voix/RTP/UDP/IP. Quand des étiquettes MPLS [RFC3031] sont ajoutées, cela devient voix/RTP/UDP/IP/étiquettes MPLS. Les VPN MPLS (par exemple, de la [RFC4364]) utilisent la mise en pile d'étiquettes, et dans le plus simple cas de IPv4 l'en-tête de paquet total est d'au moins 48 octets, tandis que la charge utile de voix est souvent de pas plus de 30 octets, par exemple. Quand IPv6 est utilisé, la taille relative de l'en-tête comparée à la charge utile est encore plus grande. L'intérêt de la compression d'en-tête (HC) est d'exploiter la possibilité de réduire de façon significative les frais généraux par divers mécanismes de compression, comme avec RTP à compression améliorée (ECRTP, Enhanced Compressed RTP) [RFC3545] et la compression d'en-tête robuste (ROHC, Robust Header Compression) [RFC3095], [RFC4815], [RFC5795], et aussi d'augmenter l'adaptabilité de HC. MPLS est utilisé pour acheminer les paquets HC sur un chemin commuté par étiquettes (LSP, Label Switched Path) MPLS sans cycle de compression/décompression à chaque routeur. Une telle capacité de HC sur MPLS peut augmenter l'efficacité de la bande passante ainsi que l'adaptabilité du traitement d'un nombre maximum de flux compressés simultanément qui utilisent HC à chaque routeur. Les buts et exigences pour HC sur MPLS sont discutés dans la [RFC4247]. La solution d'utiliser la technologie de pseudo filaire (PW, pseudowire) MPLS mise en avant dans le présent document a été conçue pour répondre à ces buts et exigences.

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

Contexte : état associé à un flux soumis à la compression d'en-tête IP. Bien que la nature exacte du contexte soit spécifique du protocole de HC particulier (CRTP, ECRTP, ROHC, etc.) cet état inclut normalement :
-	Les valeurs de tous les champs dans tous les en-têtes (IP, UDP, TCP, RTP, encapsulation de charge utile de sécurité (ESP, Encapsulating Security Payload) etc.) que le protocole particulier de compression d'en-tête traite pour le dernier paquet du flux envoyé (par le compresseur) ou reçu (par le décompresseur).
-	le changement de la valeur de certains des champs des en-têtes IP, UDP, TCP, etc. entre les deux derniers paquets consécutifs envoyés (compresseur) ou reçus (décompresseur) du flux. Certains des champs dans l'en-tête changent la plupart du temps d'une quantité constante entre les paquets successifs du flux. Sauvegarder les changements dans ces champs d'un paquet à l'autre permet de vérifiet qu'un taux constant de changement a lieu, et de prendre les mesures appropriées quand une divergence par rapport au changement normal se rencontre. Pour la plupart des protocoles HC, une copie du contexte de chaque flux compressé est conservée chez le compresseur et le décompresseur.

Protocole de transport en temps réel compressé (CRTP, Compressed Real-time Transport Protocol) : protocole particulier de HC décrit dans la [RFC2508].

Identifiant de contexte (CID, Context ID) : petit nombre, normalement 8 ou 16 bits, utilisé pour identifier un flux particulier, et le contexte associé au flux. La plupart des protocoles de HC fonctionnent en envoyant le CID à travers la liaison à la place de l'en-tête complet, ainsi que tous les changements de valeur inattendus dans les divers champs des en-têtes.

Protocole de transport en temps réel compressé amélioré (ECRTP, Enhanced Compressed Real-time Protocol) : protocole de HC particulier décrit dans la [RFC3545].

Classe d'équivalence de transmission (FEC, Forwarding Equivalence Class) : groupe de paquets qui sont transmis de la même manière (par exemple, sur le même LSP, avec le même traitement de transmission).

Schéma de compression d'en-tête (schéma HC) : méthode particulière d'effectuer la HC et son protocole associé. Plusieurs méthodes de HC ont été définies, incluant la compression d'en-tête robuste (ROHC [RFC3095], [RFC5795]), RTP compressé (CRTP, [RFC2508]), CRTP amélioré (ECRTP, [RFC3545]), et Compression d'en-tête IP (IPHC, [RFC2507]). Le présent document prend explicitement en charge tous les schémas de HC mentionnés ci-dessus, et est destiné à être extensible aux autres qui pourront être développés.

Canal de compression d'en-tête (canal HC) : session établie entre un compresseur d'en-tête et un décompresseur d'en-tête en utilisant un seul schéma d'HC, sur lequel plusieurs flux individuels peuvent être compressés. De ce point de vue, chaque liaison PPP sur laquelle HC fonctionne définit un seul canal HC, et sur la base de la présente spécification, chaque PW HC définit un seul canal HC. Les PW HC sont bidirectionnels, ce qui signifie qu'une branche unidirectionnelle du PW est établie dans chaque direction. Une branche du PW bidirectionnel peut être établie pour porter seulement des retours de compression, et non du trafic d'en-têtes compressés. Un canal HC ne devrait pas être confondu avec les flux de trafic individuels qui peuvent être compressés en utilisant un seul identifiant de contexte. Chaque canal HC gère un ensemble de CID uniques.

Compression d'en-tête IP (IPHC, IP Header Compression) : protocole de HC particulier décrit dans la [RFC2507]

Étiquette : court identifiant de longueur fixe physiquement contigu qui est utilisé pour identifier une FEC, généralement de signification locale.

Pile d'étiquettes : ensemble ordonné d'étiquettes.

Chemin commuté par étiquettes (LSP, Label Switched Path ) : chemin à travers un ou plusieurs LSR à un niveau de la hiérarchie suivi par un paquet dans une classe d'équivalence de transmission (FEC) particulière.

Routeur de commutation d'étiquettes (LSR, Label Switching Router) : nœud MPLS qui est capable de transmettre des paquets natifs de couche 3.

Domaine MPLS : ensemble contigu de nœuds qui effectuent l'acheminement et la transmission MPLS et qui sont aussi dans un domaine d'acheminement ou administratif.

Étiquette MPLS : étiquette qui est portée dans un en-tête de paquet, et qui représente la FEC du paquet.

Nœud MPLS : nœud qui fonctionne avec MPLS. Un nœud MPLS va connaître les protocoles de contrôle MPLS, va faire fonctionner un ou plusieurs protocoles d'acheminement de couche 3, et va être capable de transmettre des paquets sur la base des étiquettes. Un nœud MPLS peut aussi facultativement être capable de transmettre des paquets natifs de couche  3.

Commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching) : un groupe de travail de l'IETF et l'effort associé au groupe de travail, incluant la technologie (signalisation, encapsulation, etc.) elle-même.

Réseau à commutation de paquets (PSN, Packet Switched Network) : dans le contexte des pseudo-filaires PWE3, c'est un réseau qui utilise IP ou MPLS comme mécanisme de transmission de paquets.

Unité de données de protocole (PDU, Protocol Data Unit) : unité de données émises, ou reçues du réseau par une couche de protocole.

Pseudo-filaire (PW, Pseudowire) : mécanisme qui porte les éléments essentiels d'un service émulé d'un routeur côté fournisseur à un ou plusieurs autres routeurs côté fournisseur sur un PSN.

Émulation de pseudo-filaire de bord à bord (PWE3, Pseudowire Emulation Edge to Edge) : mécanisme qui émule les attributs essentiels du service (comme une ligne louée T1 ou un relais de trame) sur un PSN.

PDU de pseudo-filaire (PW-PDU) : PDU envoyée sur le PW qui contient toutes les données et les informations de contrôle nécessaires pour émuler le service désiré.

Tunnel PSN : tunnel à travers un PSN, à l'intérieur duquel un ou plusieurs PW peuvent être portés.

Signalisation de tunnel PSN : protocole utilisé pour établir, maintenir, et supprimer le tunnel PSN sous-jacent.

Démultiplexeur de PW : méthode du plan des données pour identifier un PW se terminant à un routeur côté fournisseur.

Protocole de transport en temps réel (RTP, Real Time Transport Protocol) : protocole pour le transport sur le réseau de bout en bout pour les applications qui transmettent des données en temps réel, comme de l'audio ou de la vidéo [RFC3550].

Compression d'en-tête robuste (ROHC, Robust Header Compression) : protocole HC particulier consistant en un cadre [RFC5795] et un certain nombre de profils pour différents protocoles, par exemple, RTP, UDP, ESP [RFC3095], et IP [RFC3843].

Tunnel : méthode de transport transparent d'informations sur un réseau.

 	3.	Vue d'ensemble de la compression d'en-tête sur le protocole MPLS

Pour mettre en œuvre HC sur MPLS, après que le routeur d'entrée applique l'algorithme de HC au paquet IP, le paquet compressé est transmis sur un LSP MPLS en utilisant des étiquettes MPLS, et ensuite le routeur de sortie restaure l'en-tête non compressé. Tout algorithme/protocole de HC peut être utilisé. Ces algorithmes ont généralement été conçus pour fonctionner sur un seul bond de couche de liaison point à point. Les PW MPLS [RFC3985] qui sont utilisés pour fournir une émulation de nombreux services de couche de liaison point à point (comme des circuits virtuels permanents (PVC, Permanent Virtual Circuit) en relais de trame et ATM) sont utilisé ici pour fournir l'émulation d'un seul bond, point à point de couche de liaison sur laquelle le trafic HC peut être transporté.

La Figure 1 illustre un HC sur un canal MPLS établi sur un LSP qui traverse plusieurs LSR, de R1/HC --> R2 --> R3 --> R4/HD, où R1/HC est le routeur d'entrée qui effectue la compression d'en-tête, et R4/HD est le routeur de sortie qui effectue la décompression d'en-tête (HD, Header Decompression). Cet exemple suppose que le flux de paquets qui est compressé a des en-têtes RTP/UDP/IP et utilise un schéma de HC comme ROHC, CRTP, ou ECRTP. La compression de l'en-tête RTP/UDP/IP est effectuée à R1/HC, et les paquets compressés sont acheminés en utilisant les étiquettes MPLS de R1/HC à R2, à R3, et finalement à R4/HD, sans autre cycle de décompression/recompression. L'en-tête RTP/UDP/IP est décompressé à R4/HD et peut être transmis aux autres routeurs, comme nécessaire. Cet exemple suppose que l'application est VoIP et que l'algorithme de HC opère sur les en-têtes RTP, UDP, et IP des flux VoIP. C'est une application extrêmement courante de HC, mais ce n'est pas la seule. Les algorithmes de HC pris en charge par les extensions de protocole spécifiées dans le présent document peuvent opérer aussi sur les en-têtes TCP ou IPsec ESP.

                 |
                 | données (par exemple, voix)/RTP/UDP/IP/couche de liaison
                 V
               _____
              |     |
              |R1/HC| Compression d'en-tête (HC) effectuée
              |_____|
                 |
                 | données (par exemple, voix)/en-tête compressé/étiquettes MPLS
                 V
               _____
              |     |
              | R2  | Commutation d'étiquette
              |_____| (pas de compression/décompression)
                 |
                 | données (par exemple, voix)/en-tête compressé/étiquettes MPLS
                 V
               _____
              |     |
              | R3  | Commutation d'étiquette
              |_____| (pas de compression/décompression)
                 |
                 | données (par exemple, voix)/en-tête compressé/étiquettes MPLS
                 V
               _____
              |     |
              |R4/HD| Décompression d'en-tête (HD) effectuée
              |_____|
                 |
                 | données (par exemple, voix)/RTP/UDP/IP/couche de liaison
                 V

Figure 1 : Exemple de HC sur MPLS sur les routeurs R1 --> R4

Dans cet exemple de scénario, la HC a donc lieu entre R1 et R4, et le LSP MPLS transporte les données/en-têtes compressés/étiquettes MPLS au lieu des données/RTP/UDP/IP/étiquettes MPLS, économisant souvent plus de 90 % des frais généraux de RTP/UDP/IP. Normalement, il y a deux étiquettes MPLS (8 octets) et un paramètre de contrôle de HC de couche de liaison (2 octets). La pile d'étiquettes MPLS et les en-têtes de couche de liaison ne sont pas compressés. Donc, HC sur MPLS peut significativement réduire les frais généraux d'en-tête par les mécanismes de compression.

HC réduit les en-têtes IP/UDP/RTP à de 2 à 4 octets pour la plupart des paquets. La moitié de la réduction de la taille d'en-tête vient de l'observation que la moitié des octets dans les en-têtes IP/UDP/RTP restent constants pendant toute la vie du flux. Après l'envoi une fois d'un gabarit d'en-tête non compressé, ces champs peuvent être retirés des en-têtes compressés qui suivent. Le reste de compression vient de l'observation qui bien que plusieurs champs changent dans chaque paquet, la différence d'un paquet à l'autre est souvent constante ou au moins limitée, et donc la différence de second ordre est zéro.

Le compresseur et le décompresseur maintiennent tous deux un contexte pour chaque flux compressé. Le contexte est l'état de session partagé entre le compresseur et le décompresseur. Les détails de ce qui est inclus dans le contexte peuvent varier entre les schémas de HC. Le contexte au compresseur va normalement inclure les en-têtes non compressés du dernier paquet envoyé sur le flux, et des mesures de la différences dans les valeurs de champ d'en-tête choisies entre le dernier paquet transmis et le ou les paquets transmis juste avant lui. Le contexte au décompresseur va inclure des informations similaires sur les paquets reçus. Avec ces informations, tout ce qui doit être communiqué sur le réseau est une indication du flux auquel un paquet est associé (le CID) et un codage compact des différences de second ordre (c'est-à-dire, les différences les plus difficiles à prédire) entre les paquets.

Les PW MPLS [RFC3985] sont utilisés pour transporter les paquets HC entre les LSR MPLS d'entrée et de sortie. Chaque PW agit comme une liaison logique en point à point entre le compresseur et le décompresseur. Chaque PW prend en charge un seul canal HC, qui, du point de vue du fonctionnement du schéma de HC, est similaire à une seule liaison PPPou un seul PVC en relais de trame. Une exception à ce modèle général est que les PW portent seulement des paquets avec des en-têtes compressés, et ne partagent pas le PW avec des paquets non compressés.

L'architecture de PW spécifie l'utilisation d'une pile d'étiquettes avec au moins deux niveaux. L'étiquette au bas de la pile est appelée l'étiquette de PW. L'étiquette de PW agit comme un identifiant pour un PW particulier. Avec les PW HC, le compresseur ajoute l'étiquette au bas de la pile et le décompresseur retire cette étiquette. Aucun LSR entre le compresseur et le décompresseur n'inspecte ou ne modifie cette étiquette. Les étiquettes plus haut dans la pile sont appelées les étiquettes de réseau de commutation de paquet (PSN, Packet Switched Network) et sont utilisées pour transmettre le paquet à travers le réseau MPLS comme décrit dans la [RFC3031]. Le décompresseur utilise l'étiquette de PW MPLS entrante (l'étiquette du bas de la pile) avec le CID pour localiser le contexte de décompression approprié. Les méthodes HC standard (par exemple, ECRTP, ROHC, etc.) sont utilisées pour déterminer les contextes. Les CID sont alloués normalement par le HC, et il n'y aurait pas de problème si des CID dupliqués sont reçus au HD pour des PW différents, qui prennent en charge des canaux compressés différents. Par exemple, si deux compresseurs différents, HCa et HCb, allouent tous deux le même CID à deux flux séparés chacune destinés au décompresseur HDc, HDc peut encore différencier les flux et localiser le contexte de décompression approprié pour chacun, parce que les couples <PWlabel-HCa, CID> et <PWlabel-HCb, CID> sont univoques.

En plus de l'étiquette de PW et de la ou des étiquettes de PSN, les paquets HC sur MPLS portent aussi un paramètre de contrôle HC. Le paramètre de contrôle HC contient un champ Type de paquet et un champ Longueur de paquet. Le champ Type de paquet est nécessaire parce que chaque schéma de HC pris en charge par la présente spécification définit plusieurs types de paquet, par exemple, des paquets "à en-tête complet", qui sont utilisés pour initialiser et/ou resynchroniser le contexte entre le compresseur et le décompresseur, par rapport aux paquets HC normaux. Et la plupart des schémas de HC exigent que les protocoles de couche de liaison sous-jacents fournissent la différenciation entre les types de paquets. De même, une des hypothèses de la plupart des schémas de HC est que les champs Longueur de paquet dans les en-têtes RTP/UDP/IP, etc. n'ont pas besoin d'être explicitement envoyés à travers le réseau, parce que la longueur des datagrammes IP peut être implicitement déterminée des couches inférieures. La présente spécification suppose que, à une exception près, la longueur d'un datagramme IP HC peut être déterminée à partir de la couche de liaison des paquets transmis à travers le réseau MPLS. L'exception est pour les paquets qui traversent une liaison Ethernet. Ethernet exige un bourrage pour les paquets dont la taille de charge utile fait moins de 46 octets. De sorte que le paramètre de contrôle HC contient un champ Longueur de 6 bits pour coder les longueurs de tout paquet HC de moins de 64 octets.

Les PW HC sont établis par le protocole de signalisation de PW [RFC4447]. La [RFC4447] définit en fait un ensemble d'extensions au protocole de distribution d'étiquettes MPLS (LDP) [RFC3036]. Comme défini dans la [RFC4447], la signalisation de LDP qui établit, supprime, et gère les PW est effectuée directement entre les points d'extrémité de PW, dans ce cas, le compresseur et le décompresseur. La signalisation de PW n'est utilisée que pour établir l'étiquette de PW au bas de la pile, et est utilisée indépendamment de toute autre signalisation qui peut être utilisée pour établir les étiquettes de PSN. Ainsi, par exemple, dans la Figure 1, la signalisation de PW de LDP serait effectuée directement entre R1/HC et R4/HD. Les routeurs R2 et R3 ne participeraient pas à la signalisation de PW.

La [RFC4447] fournit des extensions à LDP pour les PW, et le présent document donne des nouvelles extensions spécifiques de HC. Comme les PW fournissent une connexion logique point à point sur laquelle HC peut fonctionner, les extensions spécifiées dans le présent document réutilisent les éléments des protocoles utilisés pour négocier HC sur le  protocole point à point [RFC1661]. La [RFC3241] spécifie comment ROHC est utilisé sur PPP et la [RFC3544] spécifie comment plusieurs autres schémas de HC (CRTP, ECRTP, IPHC) sont utilisés sur PPP. Ces deux RFC donnent des options de configuration pour négocier HC sur PPP. Les formats de ces options de configuration sont réutilisés ici pour établir HC sur des PW. Quand elles sont utilisées dans l'environnement PPP, ces options de configuration sont utilisées comme des extensions au protocole de contrôle IP [RFC1332] de PPP et au processus détaillé des négociations d'options de PPP décrit dans la [RFC1661]. Ceci est nécessaire parce que une liaison PPP peut prendre en charge plusieurs protocoles, chacun avec ses propres schéma et options d'adressage. Réaliser l'interopérabilité exige un processus de négociation afin que les nœuds à chaque extrémité de la liaison puisse s'accorder sur un ensemble de protocoles et options que les deux prennent en charge. Cependant, un seul PW HC prend seulement en charge le trafic de HC en utilisant un seul schéma de HC. Donc, alors que les formats des options de configuration des [RFC3241] et [RFC3544] sont réutilisés ici, le processus détaillé de négociation de PPP ne l'est pas. À la place, ces options ne sont réutilisées ici que comme descripteurs (des TLV dans la terminologie spécifique de LDP et de la [RFC4447]) des paramètres de base d'un PW HC. Ces paramètres sont décrits plus en détails à la Section 4. Les paramètres de configuration de HC sont initialement générés par le décompresseur et décrivent ce que le décompresseur est prêt à recevoir.

La plupart des schémas de HC utilisent un mécanisme de rétroaction qui exige des flux bidirectionnels de paquets HC, même si le flux de paquets IP compressés est seulement dans une direction. Le processus de signalisation de base de la [RFC4447] établit des PW unidirectionnels, et doit être répété dans chaque direction afin d'établir le flux bidirectionnel nécessaire pour HC.

La Figure 1 illustre un exemple de flux de données établi de R1/HC --> R2 --> R3 --> R4/HD, où R1/HC est le routeur d'entrée où la compression d'en-tête est effectuée, et R4/HD est le routeur de sortie où la décompression d'en-tête est faite. Chaque routeur fonctionne comme un LSR et prend en charge la signalisation des LSP/PW. Voir à la Section 5 un exemple détaillé de la façon dont le flux décrit à la Figure 1 est établi.

Tous les schémas de HC utilisés ici sont construits de telle façon que si un paquet incompressible est rencontré, il devrait juste être envoyé non compressé. Pour certains types de compression (par exemple, IPHC-TCP) un chemin non compressé est nécesaire. Pour la compression IPHC-TCP,des paquets incompressibles se produisent pour chaque flux TCP. Une autre façon dont cette sorte de problème peut survenir est si MAX_HEADER est configuré inférieur à l'en-tête le plus long, et dans ce cas, la compression pourrait n'être pas toujours possible.

Les paquets non compressés associés aux flux HC (par exemple, des paquets IPHC-TCP non compressés) peuvent être envoyés à travers le même tunnel MPLS avec tous les autres paquets IP non HC (non PW). Les tunnels MPLS peuvent transporter de nombreux types de paquets simultanément, incluant des paquets IP non PW, des paquets de VPN de couche  3, et des paquets de PW (par exemple, un flux HC). Dans cette spécification, on suppose qu'il y a un chemin pour le trafic non compressé, et c'est le compresseur qui décide de ce qui va ou non dans le HC-PW.

 	4.	Spécifications du protocole

La Figure 2 illustre le modèle de référence de pile de PW pour prendre en charge les services de PW émulés.

   +--------------+                                +--------------+
   |  Services    |                                |  Services    |
   |  émulés de   |                                |  émulés de   |
   |  couche 2    |         Service émulé          |  couche 2    |
   |              |<==============================>|              |
   +--------------+                                +--------------+
   |Démultiplexeur|         Pseudo filaire         |Démultiplexeur|
   |     HC       |<==============================>|    HC        |
   +--------------+                                +--------------+
   |    PSN       |            Tunnel PSN          |    PSN       |
   |   MPLS       |<==============================>|   MPLS       |
   +--------------+                                +--------------+
   |  Physique    |                                |  Physique    |
   +------------ -+                                +--------------+

Figure 2 : Modèle de référence de pile de protocole de pseudo filaire

Chaque canal HC-HD compressé est transposé en un seul PW et associé à deux étiquettes de PW, une dans chaque direction. Une seule étiquette de PW DOIT être utilisée pour de nombreux flux HC (pourraient être des centaines ou des milliers) plutôt que d'allouer une étiquette de PW différente à chaque flux. Cette dernière approche impliquerait un mécanisme complexe pour l'allocation d'étiquette de PW, libérant les étiquettes après la fin d'un flux, etc., pour potentiellement des milliers de flux HC simultanés. Par ailleurs, le mécanisme d'allocation, de libération, de CID, etc., est en place et il n'est pas besoin de le dupliquer avec l'allocation/désallocation de PW pour les flux HC individuels.

Plusieurs PW DEVRAIENT être établis dans le cas où des exigences différentes de qualité de service (QS) sont nécessaires pour des flux compressés différents. La QS reçue par le flux va être déterminée par le marquage du bit EXP dans l'étiquette de PW. Normalement, tous les paquets RTP vont avoir le même marquage EXP [RFC3270], équivalent au traitement de la transmission expédiée (EF, Expedited Forwarding) [RFC3246] dans Diffserv. Cependant, le protocole spécifié dans le présent document s'applique à plusieurs types de flux différents, pas juste les flux RTP, et un traitement de la QS autre que EF peut être exigé pour ces flux.

La Figure 3 montre la pile de protocole HC sur MPLS (avec un en-tête non compressé) :
Flux de supports
RTP
UDP
IP
Paramètre de contrôle HC
Pile d'étiquettes MPLS (au moins 2 éiquettes pour cette application)
Couche de liaison en dessous de MPLS (PPP, PoS, Ethernet)
Couche physique (SONET/SDH, fibre, cuivre)

                                                      +----------------+
                                                      |Flux de supports|
                                                      +----------------+
                                                      \_______ ________/
                                                2-4 octets    V
                                                 +------ +-------------+
                          Compressé /RTP/UDP/IP/ |en-tête|             |
                                                 +----- -+-------------+
                                                 \__________ __________/
                                          2 octets          V
                                          +-------+--------------------+
                 Paramètre de contrôle HC |en-tête|                    |
                                          +-------+--------------------+
                                          \______________ _____________/
                                   8 octets              V
                                   +-------+---------------------------+
                   Étiquettes MPLS |en-tête|                           |
                                   +-------+---------------------------+
                                   \_________________ _________________/
                                                     V
                            +------------------------------------------+
 Couche de liaison sous MPLS|                                          |
                            +------------------------------------------+
                            \____________________ _____________________/
                                                 V
                     +-------------------------------------------------+
    Couche physique  |                                                 |
                     +-------------------------------------------------+

Figure 3 : Compression d'en-tête sur transport de flux de supports MPLS

Le paramètre de contrôle HC DOIT être utilisé pour identifier les types de paquet pour le schéma de HC utilisé. Les étiquettes MPLS définissent techniquement deux couches : l'identifiant de PW et l'identifiant de tunnel MPLS. L'étiquette de PW DOIT être utilisée comme champ de démultiplexeur par le HD, où l'étiquette de PW apparaît comme étiquette du bas d'une pile d'étiquettes MPLS. Le LSR qui va effectuer la décompression DOIT s'assurer que l'étiquette qu'il distribue (par exemple, via LDP) pour un canal est unique. Il peut aussi y avoir d'autres étiquettes MPLS, par exemple, pour identifier un VPN MPLS. Les en-têtes IP/UDP/RTP sont compressés avant la transmission, laissant le reste de la pile seule, comme le montre la Figure 3.

 	4.1	Établissement et signalisation de pseudo-filaire MPLS
Les PW DOIVENT être établis à l'avance pour le transport de flux de supports en utilisant les messages de contrôle de la [RFC4447] échangés par les points d'extrémité HC-HD. De plus, un type de PW DOIT être utilisé pour indiquer le schéma de HC utilisé sur le PW. La [RFC4447] spécifie les extensions de protocole de distribution d'étiquettes MPLS (LDP) [RFC3036] pour établir et maintenir les PW, et définit de nouveaux objets LDP pour identifier et signaler les attributs des PW. Toute méthode acceptable de distribution d'étiquettes MPLS PEUT être utilisée pour distribuer l'étiquette de tunnel MPLS [RFC3031]. Ces méthodes incluent LDP [RFC3036], RSVP-TE [RFC3209], ou la configuration.

Pour allouer et distribuer les étiquettes de PW, une session LDP DOIT être établie entre les points d'extrémité du PW en utilisant le mécanisme étendu de découvete décrit dans la [RFC3036]. Les liens d'étiquette de PW sont distribués en utilisant le mode non sollicité de LDP vers l'aval décrit dans la [RFC3036]. Un message de transposition d'étiquette de LDP contient un objet FEC, un objet étiquette et d'autres objets facultatifs possibles. L'objet FEC indique la signification de l'étiquette, identifie le type de PW, et identifie le PW auquel l'étiquette de PW est liée. Voir dans la [RFC4447] d'autres explications de la signalisation de PW.

La présente spécification définit de nouvelles valeurs de type de PW à porter dans l'objet FEC pour identifier les PW HC pour chaque schéma de HC. Le type de PW est un paramètre de 15 bits alloué par l'IANA, comme spécifié dans le registre de la [RFC4446], et DOIT être utilisé pour indiquer le schéma de HC utilisé sur le PW. L'IANA a mis à part les valeurs suivantes de type de PW pour être allouées en accord avec le registre spécifié au paragraphe 3.2 de la RFC4446 :

Type de PW	Description	Référence
0x001A	Paquets d'en-tête compressé de transport ROHC	[RFC5795]
0x001B	Paquets d'en-tête compressé de transport ECRTP	[RFC3545]
0x001C	Paquets d'en-tête compressé de transport IPHC	[RFC2507]
0x001D	Paquets d'en-tête compressé de transport CRTP 	[RFC2508]

Le paramètre de contrôle HC permet de distinguer les divers types de paquets (par exemple, non compressé, compressé UDP, compressé RTP, état de contexte, etc.). Cependant, les indications de paramètre de contrôle HC ne sont pas uniques sur les schémas HC, et donc la valeur de type de PW permet d'identifier le schéma de HC.

 	4.2	Établissement, négociation, et signalisation de schéma de compression d'en-tête
Comme décrit dans le paragraphe précédent, le PW HC, qui est configuré à l'établissement de PW, DOIT être utilisé pour les seuls paquets compressés. Si un flux n'est pas compressé, il NE DOIT PAS être placé dans le PW HC. Les PW HC DOIVENT être bidirectionnels, ce qui signifie qu'une branche unidirectionnelle du PW DOIT être établie dans chaque direction. Une branche du PW bidirectionnel PEUT être établie pour porter seulement des rétroactions de compression, et non le trafic d'en-têtes compressés. Le même type de PW DOIT être utilisé pour la signalisation de PW dans les deux directions.

Les paramètres de schéma HC PEUVENT être configurés manuellement, mais dans ce cas, la configuration manuelle DOIT être faite dans les deux directions. Si des paramètres de schéma HC sont signalés, la sous TLV Paramètres d'interface DOIT être utilisée sur toute branche unidirectionnelle d'un PW qui va porter du trafic HC. Pour une branche unidirectionnelle d'un PW qui va porter seulement des rétroactions de compression, les composants de la sous TLV Paramètres d'interface décrits ci-dessous ne sont pas pertinents et NE DOIVENT PAS être utilisés.

L'approche de PW HC s'appuie sur la couche PW/MPLS pour porter les informations de configuration de canal HC. La sous TLV Paramètres d'interface [RFC4447] doit être utilisée pour signaler l'établissement du canal HC et spécifier les paramètres de HC. C'est-à-dire, les options de configuration spécifiées dans les [RFC3241], [RFC3544] sont réutilisées dans cette spécification pour spécifier les paramètres spécifiques de PW, et pour configurer les accès de HC et HD aux bords du PW afin qu'ils aient les capacités nécessaires pour interopérer l'un avec l'autre.

Les valeurs de type de sous TLV Paramètres d'interface de pseudo filaire sont spécifiées dans la [RFC4446]. L'IANA a mis à part les valeurs suivantes de type de sous TLV Paramètres d'interface en accord avec le registre spécifié au paragraphe 3.3 de la RFC 4446 :

Paramètre	Longueur d'ID	Description	Référence
 0x0D	jusqu'à 256 octets	ROHC sur configuration MPLS RFC 3241	RFC 4901
 0x0F	jusqu'à 256 octets	compression d'en-tête CRTP/ECRTP/IPHC sur config. MPLS RFC 3544	RFC 4901

Les TLV identifiées dans les [RFC3241] et [RFC3544] DOIVENT être encapsulées dans la sous TLV Paramètres d'interface de pseudo-filaire et utilisées pour négocier l'établissement de la session de compression d'en-tête et la négociation de paramètre pour leurs protocoles respectifs. Les TLV prises en charge de cette manière DOIVENT inclure ce qui suit :

o	Format d'option de configuration, sous option Compression RTP, sous option Compression RTP améliorée, sous options de compression TCP/non TCP, comme spécifié dans la [RFC3544]

o	Format d'option de configuration, sous option PROFILS, comme spécifié dans la [RFC3241]

Ces TLV sont maintenant spécifiées dans les paragraphes qui suivent.

 	4.2.1	Format d'option de configuration [RFC3544]
Les deux protocoles de contrôle réseau pour IPv4, IPCP [RFC1332] et de contrôle réseau IPv6 (NCP), IPV6CP [RFC2472] peuvent être utilisés pour négocier les paramètres IP HC pour leurs protocoles de contrôle respectifs. Le format de l'option de configuration est le même pour IPCP et IPV6CP. Cette option de configuration DOIT être incluse pour les types de PW ECRTP, CRTP et IPHC et NE DOIT PAS être incluse pour les types de PW ROHC. Un décompresseur DOIT rejeter cette option (si par mauvaise configuration) pour les types de PW ROHC et envoyer un message d'erreur explicite au compresseur [RFC3544].

Description : cette option de configuration NCP est utilisée pour négocier les paramètres pour IP HC. La négociation réussie des paramètres permet l'utilisation des identifiants de protocole FULL_HEADER, COMPRESSED_TCP, COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP, et CONTEXT_STATE comme spécifié au paragraphe  3.1 de la [RFC2507]. Le format d'option est résumé ci-dessous. Les champs sont transmis de gauche à droite.

 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 |
+---------------+---------------+---------------+---------------+
|          ESPACE TCP           |        ESPACE NON TCP         |
+---------------+---------------+---------------+---------------+
|         F_MAX_PERIOD          |          F_MAX_TIME           |
+---------------+---------------+---------------+---------------+
|           MAX_HEADER          |          sous options...      |
+---------------+---------------+---------------+---------------+

Type : 2

Longueur : ≥ 14. 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 : 0061 (hex)

ESPACE TCP : le champ ESPACE TCP est de deux octets et indique la valeur maximum d'un identifiant de contexte dans l'espace des identifiants de contexte alloué pour TCP. Valeur suggérée : 15. ESPACE TCP doit être d'au moins 0 et au plus 255 (la valeur 0 implique d'avoir un contexte). Ce champ n'est pas utilisé pour les PW CRTP (type de PW 0x001B) et ECRTP (type de PW 0x001B). Pour ces types de PW, il devrait être réglé à sa valeur suggérée par l'envoyeur et ignoré par le receveur.

ESPACE NON TCP : le champ ESPACE NON TCP est de deux octets et indique la valeur maximum d'un identifiant de contexte dans l'espace des identifiants de contexte alloué pour le non TCP. Ces identifiants de contexte sont portés dans les en-têtes de paquet COMPRESSED_NON_TCP, COMPRESSED_UDP et COMPRESSED_RTP. Valeur suggérée : 15. ESPACE NON TCP doit être d'au moins 0 et d'au plus 65535 (la valeur 0 implique d'avoir un contexte).

F_MAX_PERIOD : intervalle maximum entre en-têtes complets. Pas plus de F_MAX_PERIOD en-têtes COMPRESSED_NON_TCP peuvent être envoyés entre des en-têtes FULL_HEADER. Valeur suggérée : 256. Une valeur de zéro implique l'infini, c'est-à-dire, il n'y a pas de limite au nombre d'en-têtes COMPRESSED_NON_TCP  consécutifs. Ce champ n'est pas utilisé pour les PW CRTP (type de PW 0x001B) et ECRTP (type de PW 0x001B). Pour ces types de PW, il devrait être réglé à sa valeur suggérée par l'envoyeur et ignoré par le receveur.

F_MAX_TIME : intervalle maximum entre en-têtes complets. Les en-têtes COMPRESSED_NON_TCP ne peuvent pas être envoyés plus de F_MAX_TIME secondes après l'envoi du dernier en-tête FULL_HEADER. Valeur suggérée : 5  secondes. Une valeur de zéro implique l'infini. Ce champ n'est pas utilisé pour les PW CRTP (type de PW 0x001B) et ECRTP (type de PW 0x001B). Pour ces types de PW, il devrait être réglé à sa valeur suggérée par l'envoyeur et ignoré par le receveur.

MAX_HEADER : la 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 de couche réseau externe 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.

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 octets de paramètres, comme défini par le type de sous option. La valeur du champ Longueur indique la longueur de la sous option dans son intégralité, incluant la longueur de champs Type et Longueur.

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

 	4.2.2	Sous option Compression RTP [RFC3544]
La sous option Compression RTP est incluse dans l'option Protocole de compression IP de protocole de commande réseau pour IPHC si la compression IP/UDP/RTP est à activer. Cette sous option DOIT être incluse pour les PW CRTP (0x001C) et NE DOIT PAS être incluse pour les autres types de PW.

L'inclusion de la sous option Compression RTP permet l'utilisation d'identifiants de protocole COMPRESSED_RTP et COMPRESSED_UDP supplémentaires avec d'autres formes de CONTEXT_STATE comme spécifié dans la [RFC2508].

Description : permet l'utilisation des identifiants de protocole COMPRESSED_RTP, COMPRESSED_UDP, et CONTEXT_STATE comme spécifié dans la [RFC2508].

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Longueur    |
+---------------+---------------+

Type : 1

Longueur : 2

 	4.2.3	Sous option Compression RTP améliorée
Pour utiliser le HC RTP amélioré défini dans la [RFC3545], une nouvelle sous option 2 est ajoutée. La sous option 2 est négociée à la place de, pas en plus de, la sous option 1. Cette sous option DOIT être incluse pour les PW ECRTP (0x001B) et NE DOIT PAS être incluse pour d'autres types de PW.

Noter que la sous option 1 se réfère à la sous option Compression RTP, comme spécifié au paragraphe 4.2.2, et la sous option 2 se réfère à la sous option Compression RTP améliorée, comme spécifié au paragraphe 4.2.3. Ces sous options NE DOIVENT PAS apparaître ensemble. Si elles le font (par exemple, si elles sont mal configurées) un décompresseur DOIT rejeter cette option et envoyer un message d'erreur explicite au compresseur [RFC3544].

Description : permet l'utilisation des identifiants de protocole COMPRESSED_RTP et CONTEXT_STATE comme spécifié dans la [RFC2508]. De plus, elle permet l'utilisation de la compression conforme à la [RFC3545] incluant l'utilisation de l'identifiant de protocole COMPRESSED_UDP avec des fanions supplémentaires et l'utilisation du fanion C avec l'identifiant de protocole FULL_HEADER pour indiquer l'utilisation des paquets HDRCKSUM avec RTP compressé et UDP compressé.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Longueur   |
+---------------+---------------+

Type : 2

Longueur : 2

 	4.2.4	Négociation de compression d'en-tête pour paquets TCP seulement ou non TCP
Dans la [RFC3544] il n'était pas possible de négocier seulement HC TCP ou seulement HC non TCP parce que une valeur de 0 dans les champs ESPACE TCP ou ESPACE NON TCP signifie en fait qu'un contexte est négocié.

Une nouvelle sous option 3 est ajoutée pour permettre de spécifier que le nombre de contextes pour ESPACE TCP ou ESPACE NON TC _est zéro, désactivant l'utilisation de la compression correspondante. Cette sous option DOIT être incluse pour les PW IPHC (0x001C) et NE DOIT PAS être incluse pour d'autres types de PW.

Description : permet HC pour les paquets seulement TCP ou seulement non TCP.

 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ètre   |
+---------------+---------------+---------------+

Type : 3

Longueur : 3

Paramètre : le paramètre fait un octet avec une des valeurs suivantes :
1 = le nombre de contextes pour ESPACE TCP est 0.
2 = le nombre de contextes pour ESPACE NON TCP est 0.

Cette sous option outrepasse les valeurs précédement allouées à ESPACE TCP et ESPACE NON TCP dans l'option HC IP.

Si la sous option 3 est incluse plusieurs fois avec le paramètre 1 et 2, la compression est désactivée pour tous les paquets.

 	4.2.5	Format d'option Configuration [RFC3241]
Les deux protocoles de contrôle réseau pour IPv4, IPCP [RFC1332] et IPv6 NCP, IPV6CP [RFC2472] peuvent être utilisés pour négocier les paramètres IP HC pour leurs protocoles contrôlés respectifs. Le format de l'option de configuration est le même pour IPCP et IPV6CP. Cette option de configuration DOIT être incluse pour les types de PW ROHC et NE DOIT PAS être incluse pour les types de PW ECRTP, CRTP, et IPHC. Un décompresseur DOIT rejeter cette option (si elle est mal configurée) pour les types de PW ECRTP, CRTP, et IPHC, et envoyer un message d'erreur explicite au compresseur [RFC3544].

Description : cette option de configuration NCP est utilisée pour négocier des paramètres pour ROHC. Le format de l'option est résumé ci-dessous. Les champs sont transmis de gauche à droite.

  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.2 de la [RFC5795]). 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 de couche réseau externe puisse être compressé. Pour augmenter l'efficacité de la 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 dans ce document est donc sans conséquence dans ces profils parce que la taille maximum d'en-tête compressible n'est pas spécifiée. D'autres profils (par exemple, ceux fondés sur la RFC 2507) peuvent utiliser le 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 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.

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

 	4.2.6	Sous option PROFILS [RFC3241]
L'ensemble de profils à activer est soumis à négociation. La plupart des mises en œuvre initiales de ROHC utilisent les profils 0x0000 à 0x0003. Cette option DOIT être fournie.

Description : Définit l'ensemble de profils pris en chare par le décompresseur.

 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

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

L'identification du flux de HC est faite maintenant de nombreuses façons. Comme il y a plusieurs approches possibles du problème, aucune méthode spécifique n'est spécifiée dans le présent document.

 	4.3	Encapsulation de paquets à en-tête compressé
Le paramètre de contrôle HC est utilisé pour identifier les types de paquet pour IPHC [RFC2507], CRTP [RFC2508], et ECRTP [RFC3545], comme le montre la Figure 4 :

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|Type pq|  Longueur |Res|
+-------+-------+-----------+---+

Figure 4 : Paramètre de contrôle HC

où :

Codage de type de paquet :
0 : petits CID ROHC
1 : grands CID ROHC
2 : en-tête complet
3 : TCP compressé
4 : TCP compressé sans delta
5 : Non TCP compressé
6 : RTP 8 compressé
7 : RTP 16 compressé
8 : UDP 8 compressé
9 : UDP 16 compressé
10 : état de contexte
11-15 : non encore alloué. (Voir la Section 8, "Considérations relatives à l'IANA", pour la discussion des règles d'enregistrement.)

Comme discuté dans la [RFC4928], comme ce type de charge utile MPLS n'est pas IP, le premier quartet est réglé à 0000 pour éviter d'être pris par erreur pour IP. Ceci est aussi cohérent avec le codage du mot de contrôle de PW MPLS (PWMCW) décrit dans la [RFC4385] ; cependant, le paramètre de contrôle HC n'est pas destiné à être un PWMCW.

Noter que ROHC [RFC3095], [RFC5795] fournit son propre type de paquet au sein du protocole ; cependant, le paramètre de contrôle HC DOIT quand même être utilisé pour éviter les problèmes identifiés ci-dessus. Comme le "Type de paquet" va être là de toutes façons, il est utilisé pour indiquer la taille du CID ROHC, de la même façon qu'avec PPP.

Le champ Longueur du paramètre de contrôle HC est SEULEMENT utilisé pour les paquets courts parce que du bourrage peut être ajouté par la couche de liaison des données Ethernet. Si la longueur est supérieure ou égale à 64 octets, le champ Longueur DOIT être réglé à zéro. Si la charge utile MPLS fait moins de 64 octets, alors le champ Longueur DOIT être réglé à la longueur de la charge utile du PW plus la longueur du paramètre de contrôle HC. Noter que les deux derniers bits dans le paramètre de contrôle HC sont réservés.

 	4.4	Réarrangement de l'ordre des paquets
Le réarrangement de l'ordre des paquets pour ROHC est discuté dans la [RFC4224], qui est une source d'informations utile.  En cas de liaison encline à la perte et autres raisons de réarrangement, des adaptations de mise en œuvre sont nécessaires pour permettre que tous les schémas soient utilisés dans ce cas. Bien que CRTP soit vu comme présentant des risques pour un certain nombre d'environnements de PW à cause du réarrangement et des pertes, il est quand même le protocole choisi dans de nombreux cas. CRTP a été conçu pour des liaisons fiables en point à point avec des délais courts. Il ne fonctionne pas bien sur des liaisons avec un fort taux de perte de paquet, de réarrangement de paquet, et de longs délais. Dans de tels cas, ECRTP [RFC3545] peut être considéré comme augmentant la robustesse à la perte de paquet et au mauvais ordre entre le compresseur et le décompresseur. Ceci est réalisé en répétant les mises à jour et en envoyant des valeurs absolues (non compressées) en plus des valeurs de delta pour les paramètres de contexte choisis. IPHC devrait utiliser TCP_NODELTA, ECRTP devrait envoyer des valeurs absolues, ROHC devrait être adapté comme discuté dans la [RFC4224]. Une évaluation et simulation du réarrangement de l'ordre dans ECRTP et ROHC est donnée dans [REORDER].

 	5.	Exemple d'établissement de pseudo-filaire HC

Cet exemple retrace l'établissement d'un PW MPLS qui prend en charge le trafic ECRTP bidirectionnel [RFC3545]. L'exemple suppose la topologie montrée à la Figure 1. Le PW va être établi entre les LSR R1/HC et R4/HD. Les LSR R2 et R3 n'ont pas d'implication directe dans la signalisation pour ce PW, autre que de transporter le trafic de signalisation.

Pour cet exemple, on suppose que R1/HC ont déjà obtenu l'adresse IP de R4/HD utilisée pour la signalisation de LDP, et vice versa, que les deux R1/HC et R4/HD ont été configurés avec le même identifiant de PW de 32 bits, comme décrit au paragraphe 5.2 de la [RFC4447], et que R1/HC a été configuré pour initier le processus de découverte de LDP. De plus, on suppose que R1/HC a été configuré pour recevoir un maximum de 200 flux ECRTP simultanés de R4/HD, et que R4/HD a été configuré pour recevoir un maximum de 255 flux ECRTP provenant de R1/HC.

En supposant qu'il n'existe pas de session LDP entre R1/HC et R4/HD, la signalisation de PW doit commencer à établir une session LDP entre eux. Comme décrit précédemment dans ce document, la découverte étendue de LDP est utilisée entre HC sur les LSR MPLS. Comme R1/HC a été configuré pour initialiser la découverte étendue, il va envoyer des messages Hello ciblés sur LDP à l'adresse IP de R4/HD à l'accès UDP 646. Les messages Hello ciblés envoyés par R1/HC vont avoir le bit "R" établi dans la TLV Paramètres Hello communs, demandant à R4/HD de renvoyer des messages Hello ciblés à R1/HC. Comme R4/HD a été configuré pour établir un PW HC avec R1/HD, R4/HD va faire comme demandé et envoyer des messages Hello ciblés LDP comme paquets UDP en envoi individuel à l'accès UDP 646 de l'adresse IP de R1/HC.

Quand R1/HC reçoit un message Hello ciblé de R4/HD, il peut commencer à établir une session LDP pour R4/HD. Il commence cela en initiant une connexion TCP sur l'accès 646 à l'adresse IP de signalisation de R4/HD. Après la réussite de l'établissement de la connexion TCP, R1/HC envoie un message d'initialisation de LDP à R4/HD avec les caractéristiques suivantes :

Quand R1/HC reçoit un message Hello ciblé de R4/HD, il peut commencer l'établissement d'une session LDP pour R4/HD.  La procédure décrite au paragraphe 2.5.2 de la [RFC3036] est utilisée pour déterminer quel LSR est le LSR actif et quel est le LSR passif. En supposant que R1/HC a l'adresse IP numériquement supérieure et donc prend le rôle actif. R1/HC commence par initier une connexion TCP sur l'accès 646 à l'adresse IP de signalisation de R4/HD. Après la réussite de l'établissement de la connexion TCP, R1/HC envoie un message Initialisation LDP à R4/HD avec les caractéristiques suivantes :
o TLV Paramètres de session communs :
- bit A = 0 (Mode non sollicité vers l'aval)
- bit D = 0 (Détection de boucle désactivée)
- PVLim = 0 (exigé quand le bit D = 0)
- identifiant de LDP de réception (pris dans le message Hello de R4/HD)
       > 4 octets d'identifiant de LSR (normalement une adresse IP avec IPv4)
       > 2 octets d'identifiant d'espace d'étiquette (normalement 0)
o Pas de TLV Paramètres facultatifs

Suivant l'automate à états d'initialisation de session LDP du paragraphe 2.5.4 de la [RFC3036], R4/HD va envoyer un message Initialisation similaire à R1/HD. La principale différence va être que R4/HD utiliserait l'identifiant LDP qu'il a reçu dans le ou les messages Hello de R1/HC comme l'identifiant de LDP de réception. En supposant que tous les autres champs dans la TLV Paramètres de session communs étaient acceptables aux deux parties, R1/HC va envoyer un message Garder en vie de LDP à R4/HD, R4/HD va envoyer un message Garder en vie de LDP à R1/HC, et la session de LDP va devenir opérationnelle.

À ce point, R1/HC ou R4/HD peut envoyer des messages Transposition d'étiquette de LDP pour configurer le PW. Le message Transposition d'étiquette envoyé par un routeur particulier annonce l'étiquette qui devrait être utilisée au bas de la pile d'étiquettes MPLS pour tous les paquets envoyés à ce routeur et associés à ce PW particulier. Le message Transposition d'étiquette envoyé de R1/HC à R4/HD va avoir les caractéristiques suivantes :

o TLV FEC :
- type d'élément de FEC 0x80 (élément de FEC PWid, comme défini dans la [RFC4447])
- bit Paramètre de contrôle = 1 (Paramètre de contrôle présent)
- type de PW = 0x001B (ECRTP [RFC3545])
- identifiant de groupe comme choisi par R1/HC
- PW ID = valeur configurée pour ce PW, qui doit être la même que celle envoyée dans le message Transposition d'étiquette par R4/HD
- Sous TLV Paramètre d'interface :
       >Sous TLV MTU d'interface (Type 0x01)
       > Sous TLV HC CRTP/ECRTP/IPHC sur configuration MPLS (type 0x0F)
         + Type = 2 (d'après la RFC 3544)
         + Longueur = 16
         + ESPACE TCP = ne pas s'en soucier (laisser à la valeur suggérée = 15)
         + ESPACE NON TCP = 200 (configuré sur R1)
         + F_MAX_PERIOD = ne pas s'en soucier ( laisser à la valeur suggérée = 256)
         + F_MAX_TIME = ne pas s'en soucier ( laisser à la valeur suggérée = 5 seconds)
         + MAX_HEADER = 168 (valeur suggérée)
         + Sous option Compression RTP améliorée
           - Type = 2
           - Longueur = 2
o TLV Étiquette - contient l'étiquette choisie par R1, Lr1
o Pas de paramètre facultatif

Le message Transposition d'étiquette envoyé de R4/HD à R1/HC va être presque identique à celui envoyé dans la direction opposée, avec les exceptions suivantes :
o R4/HD pourrait choisir un identifiant de groupe différent.
o La valeur de ESPACE NON TCP dans le HC CRTP/ECRTP/IPHC sur la sous TLV Configuration MPLS serait 255 au lieu de 200, comme configurée dans R4/HD.
o R4/HD choisirait sa propre valeur pour la TLV Étiquette, Lr4.

Aussitôt que R1/HC ou R4/HD ont tous deux transmis et reçu les messages Transposition d'étiquette avec le même Type de PW et Identifiant de PW, ce point d'extrémité de HC considère le PW comme établi. R1/HC pourrait envoyer des paquets ECRTP en utilisant l'étiquette qu'il a reçue dans le message Transposition d'étiquette de R4/HD, Lr4, et pourrait identifier les paquets ECRTP reçus par l'étiquette qu'il a envoyée à R4/HD, Lr1, et vice versa.

Dans ce cas, on suppose que R1/HC a un flux RTP IPv4 à envoyer à R4/HD qu'il souhaite compresser en utilisant le PW ECRTP juste établi. Le flux RTP est de supports G.729 avec 20 octets de charge utile dans chaque paquet RTP. Dans ce cas particulier, l'identifiant IPv4 change d'une petite valeur constante entre les paquets consécutifs du flux. Dans la couche RTP du flux, le compte d'identifiants de source contributive est 0. R1/HC décide d'utiliser des identifiants de contexte de 8 bits pour le flux compressé. Aussi, R1/HC détermine que la compression dans ce flux particulier devrait être capable de récupérer de la perte de deux paquets consécutifs sans exiger de resynchronisation du contexte (c'est-à-dire, la valeur "N" de la [RFC3545] est 2).

Les 3 (N + 1) premiers paquets de ce flux vont être envoyés comme des paquets FULL_HEADER. Les en-têtes MPLS et PW au début de ces paquets vont être formatés comme suit :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Étiquette              | Exp |S|       TTL     |
|                  XX                   |  XX |0|        XX     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Étiquette              | Exp |S|       TTL     |
|                 Lr4                   |  XX |1|        >0     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       |Pkt Typ| Longueur  |Res|
|0 0 0 0|   2   |     62    |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ^
            |
             -- 2 == FULL_HEADER

où XX signifie soit :
a. valeur déterminée par la couche d'acheminement MPLS 
b. ne pas s'en soucier.

Suivant immédiatement l'en-tête ci-dessus viendrait le paquet FULL_HEADER comme défini dans la [RFC3545], qui consiste en l'en-tête IP/UDP/RTP, avec le champ Longueur IP et UDP remplacé par les valeurs de codage de CID, le numéro de séquence, et "génération", comme défini dans la [RFC3545]. La valeur du champ Longueur de 62 comprend :
o 2 octets de paramètre de contrôle HC (inclus dans le diagramme ci-dessus)
o 20 octets de la portion d'en-tête IP FULL_HEADER de la RFC 3545 
o 8 octets de la portion d'en-tête UDP FULL_HEADER de la RFC 3545
o 12 octets de la portion d'en-tête RTP FULL_HEADER de la RFC 3545
o 20 octets de charge utile G.729.

Les trois paquets RTP suivants de ce flux vont être envoyés comme UDP 8 compressé, pour établir les valeurs absolues et de delta des champs Identifiant IPv4 et Horodatage RTP. Ces paquets vont utiliser le même CID ECRTP que les trois précédents paquets FULL_HEADER. Les en-têtes MPLS et PW au début de ces paquets vont être formatés comme suit :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Étiquette               | Exp |S|       TTL     |
|                  XX                   |  XX |0|        XX     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Étiquette               | Exp |S|       TTL     |
|                 Lr4                   |  XX |1|        >0     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       |Pkt Typ| Longueur  |Res|
|0 0 0 0|   8   |     36    |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ^
            |
             -- 8 == COMPRESSED_UDP_8

Il n'y a pas de changement dans la pile d'étiquettes MPLS entre les paquets FULL_HEADER et les paquets UDP compressé. Le paramètre de contrôle HC change pour refléter un autre type de paquet ECRTP qui suit le paramètre de contrôle, et un changement de longueur de paquet. La longueur change parce que le nouveau type de paquet code les en-têtes de façon plus compacte. La valeur du champ Longueur de 36 comprend :
o 2 octets de paramètre de contrôle HC (inclus dans le diagramme ci-dessus)
o 1 octet de CID
o 2 octets de champs UDP compressé qui ne sont pas alignés sur l'octet :
- 4 bits de fanions UDP compressé
- 4 bits de numéro de séquence
- 5 bits de fanions d'extension UDP compressé
- 3 bits de zéros
o 2 octets de somme de contrôle UDP ou HDRCKSUM
o 1 octet de delta d'identifiant IPv4
o 2 octets de delta d'horodatage RTP (change de 160 dans ce cas, le codage différentiel va le coder comme deux octets)
o 2 octets de Identifiant IPv4 absolu
o 4 octets de Horodatage RTP absolu
o 20 octets de charge utile G.729

Après l'initialisation du contexte pour l'identifiant IPv4 et l'horodatage RTP, les paquets suivants sur ce flux, au moins jusqu'à la fin de la salve de parole ou jusqu'à ce qu'il y ait quelque autre changement inattendu des en-têtes IP/UDP/RTP, peuvent être envoyés comme des paquets RTP_8 compressés. Là encore, la même pile MPLS va être utilisée pour ces paquets, et la même valeur de CID va être utilisée dans ce cas comme pour les paquets décrits précédemment. Les en-têtes MPLS et PW au début de ces paquets vont être formatés comme suit :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Étiquette               | Exp |S|       TTL     |
|                  XX                   |  XX |0|        XX     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Étiquette               | Exp |S|       TTL     |
|                 Lr4                   |  XX |1|        >0     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       |Pkt Typ| Longueur  |Res|
|0 0 0 0|   6   |     26    |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ^
            |
             -- 6 == COMPRESSED_RTP_8

Le paramètre de contrôle HC change à nouveau pour refléter un autre type de paquet ECRTP qui suit le paramètre de contrôle, et une plus courte longueur associée à un codage encore plus compact des en-têtes. La valeur du champ Longueur de 26 comprend :
o 2 octets de paramètre de contrôle HC (incluse dans le diagramme ci-dessus)
o 1 octet de CID
o 1 octet de champs UDP compressé qui ne sont pas alignés sur l'octet :
- 4 bits de fanions RTP compressé
- 4 bits de numéro de séquence
o 2 octets de somme de contrôle UDP ou HDRCKSUM
o 20 octets de charge utile G.729

Les flux supplémentaires dans la même direction peuvent être compressés en utilisant la même encapsulation de base, incluant la même étiquette de PW. Le CID qui fait partie du protocole HC est utilisé pour différencier les flux. Pour le trafic dans la direction opposée, le principal changement va être l'étiquette de PW, Lr4, utilisée dans l'exemple ci-dessus serait remplacée par l'étiquette Lr1 que R1/HC fournit à R4/HD.

 	6.	Considérations sur la sécurité

Les considérations sur la sécurité des PW MPLS en général sont discutées dans les [RFC3985] et [RFC4447], et ces considérations s'appliquent aussi au présent document. Ce document spécifie une encapsulation et non les protocoles qui peuvent être utilisés pour porter les paquets encapsulés à travers le PSN, ou les protocoles encapsulés. Chacun de ces protocoles peut avoir son propre ensemble de problèmes de sécurité, mais ces problèmes ne sont pas affectés par les encapsulations spécifiées ici.

Les considérations sur la sécurité des protocoles de HC pris en charge, [RFC2507], [RFC2508], [RFC3095], [RFC3545], [RFC5795] s'appliquent toutes aussi au présent document.

 	7.	Remerciements

Les auteurs remercient de leurs précieux apports et suggestions Loa Andersson, Scott Brim, Stewart Bryant, Spencer Dawkins, Adrian Farrel, Victoria Fineberg, Eric Gray, Allison Mankin, Luca Martini, Colin Perkins, Kristofer Sandlund, Yaakov Stein, George Swallow, Mark Townsley, Curtis Villamizar, et Magnus Westerlund.

 	8.	Considérations relatives à l'IANA

Comme discuté au paragraphe 4.1, les valeurs de type de PW ont été allouées par l'IANA, comme suit :
0x001A	paquets d'en-tête de transport ROHC compressés	[RFC5795]
0x001B	paquets d'en-tête de transport ECRTP compressés	[RFC3545]
0x001C	paquets d'en-tête de transport IPHC compressés	[RFC2507]
0x001D	paquets d'en-tête de transport CRTP compressés	[RFC2508]

Les procédures pour enregistrer de nouvelles valeurs de type de PW sont données dans la [RFC4446].

Comme discuté au paragraphe 4.2, les valeurs de type de sous TLV de paramètre d'interface de pseudo-filaire ont été spécifiées par l'IANA, comme suit :

Paramètre	Longueur d'ID	Description	Référence
 0x0D	jusqu'à 256 octets	ROHC sur configuration MPLS RFC 3241	RFC 4901
 0x0F	jusqu'à 256 octets	compression d'en-tête CRTP/ECRTP/IPHC sur config. MPLS RFC 3544	RFC 4901

Comme discuté au paragraphe 4.3, l'IANA a défini un nouveau registre, "Compression d'en-tête sur type de paquet de paramètre de contrôle d'en-tête MPLS". C'est une valeur de quatre bits. Les types de paquet de 0 à 10 sont définis au paragraphe 4.3 de ce document. Les types de paquet de 11 à 15 sont à allouer par l'IANA sous la politique de "revue par expert" définie dans la [RFC2434].

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

[RFC3031]	E. Rosen, A. Viswanathan, R. Callon, "Architecture de commutation d'étiquettes multi protocoles", janvier 2001. (P.S.) (MàJ par la RFC6790)

[RFC3036]	L. Andersson et autres, "Spécification de LDP", janvier 2001. (Obsolète, voir la RFC5036)

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

[RFC3544]	T. Koren, S. Casner, C. Bormann, "Compression d'en-tête IP sur PPP", juillet 2003. (Remplace RFC2509) (P.S.)

[RFC4447]	L. Martini et autres, "Établissement et maintenance de pseudo filaires avec le protocole de distribution d'étiquettes", avril  2006. (MàJ par la RFC6723) (P.S. ; Remplacé par RFC8077 STD 84)

 	10.	Références pour information

[REORDER]	Knutsson, C., "Evaluation and Implementation of Header Compression Algorithm ECRTP", http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf 

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

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

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

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

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

[RFC2508]	S. Casner, V. Jacobson, "Compression d'en-têtes IP/UDP/RTP pour liaisons séries à bas débit", février 1999. (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.)

[RFC3209]	D. Awduche, et autres, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (Mise à jour par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC6790)

[RFC3246]	B. Davie et autres, "Comportement par bond de transmission accélérée", mars 2002. (P.S.)

[RFC3270]	F. Le Faucheur et autres, "Prise en charge des services différenciés par la commutation d'étiquettes multi-protocoles (MPLS)", mai 2002. (P.S.)

[RFC3544]	T. Koren, S. Casner, C. Bormann, "Compression d'en-tête IP sur PPP", juillet 2003. (Remplace RFC2509) (P.S.)

[RFC3545]	T. Koren et autres, "RTP compressé amélioré (CRTP) pour liaisons avec retard élevé, perte de paquet et réarrangement", juillet 2003. (P.S.)

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

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

[RFC3985]	S. Bryant et autres, "Architecture d'émulation bord à bord pseudo-filaire (PWE3)", mars 2005. (Information)

[RFC4224]	G. Pelletier et autres, "Compression d'en-tête robuste (ROHC) : ROHC sur des canaux qui peuvent réordonner les paquets", janvier 2006. (Information)

[RFC4247]	J. Ash et autres, "Exigences pour la compression d'en-tête sur MPLS", novembre 2005. (Information)

[RFC4364]	E. Rosen et Y. Rekhter, "Réseaux privés virtuels IP BGP/MPLS", février 2006. (P.S., MàJ par RFC4577, RFC4684)

[RFC4385]	S. Bryant et autres, "Mot de contrôle d'émulation bord à bord pseudo filaire (PWE3) à utiliser sur un PSN MPLS", février 2006. (P.S.)

[RFC4446]	L. Martini, "Allocations de l'IANA pour l'émulation de bord à bord pseudo filaire (PWE3)", avril 2006. (BCP0116)

[RFC4815]	L-E. Jonsson et autres, "Compression d'en-tête robuste (ROHC) : Corrections et précisions à la RFC 3095", février  2007. (MàJ RFC3095, RFC3241, RFC3843, RFC4019, RFC4362) (P.S.)

[RFC4928]	G. Swallow et autres, "Éviter le traitement de chemins multiples à coût égal dans les réseaux MPLS", juin 2007. (BCP0128)

[RFC5795]	K. Sandlund, G. Pelletier, L-E. Jonsson, "Cadre de la compression d'en-tête RObust (ROHC)", mars 2010. (Remplace RFC4995). (P. S.)

 	11.	Contributeurs
En plus des éditeurs mentionnés ci-dessous, les personnes suivantes ont contribué à ce document :

Lars-Erik Jonsson	Bur Goode	Raymond Zhang	
Optand 737	AT&T	Infonet Services Corporation	
SE-831 92 Ostersund, Sweden	téléphone : +1 203-341-8705	2160 E. Grand Ave. El Segundo, 	
téléphone : +46 70 365 20 58	mél : bgoode@att.com 	CA 90025 USA	
mél : lars-erik@lejonsson.com 		mél : zhangr@bt.infonet.com 	

 	Adresse des éditeurs
Jim Hand	Jerry Ash	Andrew G. Malis	
AT&T	AT&T	Verizon Communications	
Room MT A2-1A03	mél : gash5107@yahoo.com 	40 Sylvan Road	
200 Laurel Avenue		Waltham, MA  02451 	
Middletown, NJ 07748, USA		USA	
téléphone : +1 732-420-3017		mél : andrew.g.malis@verizon.com 	
mél : jameshand@att.com 			

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2007). Tous droits réservés.

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.

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