Groupe de travail Réseau	L-E. Jonsson, Ericsson
Request for Comments : 4362	K. Sandlund, Ericsson
RFC rendue obsolète : 3242	G. Pelletier, Ericsson
Catégorie : Sur la voie de la normalisation	janvier 2006
Traduction Claude Brière de L'Isle	

Compression d'en-tête robuste (ROHC) : profil assisté de couche de liaison pour IP/UDP/RTP

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

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

Résumé
Le présent document définit un profil de compresssion d'en-tête robuste (ROHC, Robust Header Compression) pour la compression de paquets IP/UDP/RTP (protocole Internet/protocole de datagramme d'utilisateur/protocole de transport en temps réel) en utilisant les fonctions fournies par les couches inférieures pour accroître l'efficacité de compression en éliminant complètement l'en-tête de la plupart des paquets durant un fonctionnement optimal. Le profil est construit comme une extension du profil ROHC RTP. Il définit les mécanismes supplémentaires nécessaires dans ROHC, les exigences d'état sur la couche d'assistance pour garantir la transparence, et spécifie la logique générale de la compression et décompression relative à l'usage du format de paquet sans en-tête. Le présent document remplace la RFC 3242, qu'il rend obsolète.
Table des matières
1. Introduction	2
1.1 Différences avec la RFC 3242	3
2. Terminologie	3
3. Vue d'ensemble du profil assisté de couche de liaison	3
3.1 Fourniture de l'identification de type de paquet	4
3.2 Remplacement du numéro de séquence	4
3.3 Remplacement du CRC	4
3.4 Applicabilité du profil	5
4. Ajouts et exceptions par rapport à ROHC RTP	5
4.1 Types de paquets supplémentaires	5
4.2 Interfaces avec la couche d'assistance	7
4.3 Accord d'approche optimiste	8
4.4 Initialisation rapide de contexte, redéfinition de IR	8
4.5 Option de retour, CV-REQUEST	9
4.6 Vérification périodique de contexte	9
4.7 Utilisation d'identifiant de contexte	9
5. Questions de mise en œuvre	10
5.1 Paramètres et signaux de mise en œuvre	10
5.2 Mise en œuvre sur diverses technologies de liaison	11
6. Considérations relatives à l'IANA	11
7. Considérations sur la sécurité	11
8. Remerciements	11
9. Références	11
9.1 Références normatives	11
9.2 Références pour information	12
Adresse des auteurs	12
Déclaration complète de droits de reproduction	13

 	1.	Introduction
La compression d'en-tête est une technique utilisée pour compresser et décompresser de façon transparente les informations d'en-tête d'un paquet sur la base du bond, en utilisant les redondances au sein des paquets individuels et entre paquets consécutifs au sein d'un flux de paquets. Au fil des ans, plusieurs protocoles [RFC1144], [RFC2507] ont été développés pour comprimer les en-têtes de protocole réseau et transport [RFC0791], [RFC2460], [RFC0768], [RFC0793], et ces schémas ont réussi à améliorer l'efficacité sur de nombreuses liaisons filaires encombrées, comme les connexions par modem sur les réseaux téléphoniques. En plus de la compression pour IP, UDP, et TCP, un schéma de compression supplémentaire appelé RTP compressé [RFC2508] a été développé pour améliorer encore l'efficacité de compression pour le trafic en temps réel utilisant le protocole de transport en temps réel [RFC3550].

Les schémas mentionnés ci-dessus ont tous été conçus en prenant en compte les hypothèses normales sur les caractéristiques de liaisons, qui ont traditionnellement été fondées sur les seules liaisons filaires. Cependant, avec un nombre croissant de liaisons sans fil dans les chemins de l'Internet, ces hypothèses ne sont généralement plus valides. Dans les environnements sans fil, en particulier les environnements cellulaires de couverture large, des taux d'erreur relativement élevés sont tolérés afin de permettre un usage efficace des ressources radio. Pour le trafic en temps réel, qui est plus sensible aux délais qu'aux erreurs, de telles conditions de fonctionnement vont être la norme sur, par exemple, les liaisons cellulaires de 3ème génération, et la compression d'en-tête doit donc tolérer la perte de paquet. Cependant, avec les schémas mentionnés précédemment, en particulier pour le trafic en temps réel compressé par CRTP, des taux d'erreur élevés se sont révélés dégrader de façon significative les performances de la compression d'en-tête [CRTPC]. Ce problème a conduit à la création du groupe de travail Compression d'en-tête robuste (ROHC) à l'IETF.

Le groupe de travail ROHC a développé un cadre de compression d'en-tête par dessus lequel des profils peuvent être définis pour différents ensembles de protocoles, ou pour différentes stratégies de compression. Du fait de la robustesse limitée à la perte de paquet de CRTP et de la demande de l'industrie du cellulaire d'un moyen efficace de transporter la voix sur IP sur les réseaux sans fil, ROHC s'est jusqu'à présent principalement concentré sur la compression des en-têtes IP/UDP/RTP, qui sont de taille généreuse, en particulier comparés aux charges utiles souvent portées par les paquets avec ces en-têtes.

ROHC RTP est devenu un schéma de compression très efficace, robuste, et capable de comprimer les en-têtes jusqu'à une taille totale d'un seul octet. Aussi, la transparence est garantie dans une mesure extrêmement grande, même quand des erreurs binaires résiduelles sont présentes dans les en-têtes compressés livrés au décompresseur. Les exigences de la compression RTP [RFC3096], définies par le groupe de travail avant et durant le processus de développemen, ont donc été satisfaites.

Comme mentionné ci-dessus, les systèmes cellulaire de 3ème génération, où IP va être utilisé de bout en bout, ont été une des forces conductrices de ROHC RTP, et le schéma a aussi été conçu pour convenir aux nouvelles interfaces radio cellulaires, comme WCDMA, rendant possible de faire fonctionner même des services de parole avec une efficacité spectrale à peine inférieure à celle des solutions existantes de service à commutation de circuits [VTC2000]. Cependant, d'autres interfaces radio (comme celles fondées sur le GSM et IS-95) vont aussi être utilisées dans tous les  réseaux IP, avec plus d'implications pour la question de la compression d'en-tête. Ces plus anciennes interfaces radio sont moins souples, avec des supports radio optimisés pour des tailles de charge utile spécifiques. Cela signifie que pas un seul octet d'en-tête ne peut être ajouté sans utiliser la taille de paquet supérieure suivante fixée prise en charge par la liaison, ce qui est évidemment très coûteux. Pour les codeurs de parole déjà déployés, l'efficacité spectrale sur ces liaisons va donc être faible comparée aux solutions existantes de commutation de circuit. Pour réaliser une haute efficacité spectrale globale avec toute application, des interfaces radio plus souples doivent être déployées, et alors le schéma ROHC RTP va avoir d' excellentes performences, comme montré pour WCDMA [MOMUC01]. Cependant, pour des raisons de déploiement, il est important de fournir aussi une stragégie convenable de compression d'en-tête pour les codeurs vocaux et interfaces radio déjà existants, comme pour GERAN et CDMA2000, avec des effets minimaux sur l'efficacité spectrale.

Le présent document décrit un profil de ROHC RTP à assistance de la couche de liaison, défini à l'origine par la [RFC3242], qui étend ROHC RTP (profil 0x0001) [RFC3095], et conforme aux exigences de ROHC 0 octet [RFC3243]. L'objet de ce profil est de fournir un format de paquet sans en-tête qui, pour un certain comportement d'application, peut remplacer la majorité des paquets ROHC RTP à en-tête d'un octet durant le fonctionnement normal en mode U/O, tout en étant encore pleinement transparent et conforme à toutes les exigences de ROHC RTP [RFC3096]. Pour les autres applications, la compression va être effectuée comme avec le ROHC RTP normal.

Pour éliminer complètement l'en-tête compressé, toutes les fonctions normalement fournies par l'en-tête à un octet doivent être fournies pas d'autres moyens, normalement en utilisant les fonctions fournies par les couches inférieures et en sacrifiant l'efficacité pour les en-têtes compressés plus grands qui se produisent moins fréquemment. Ceci n'est pas une contradiction, car l'argument pour éliminer le dernier octet pour la plupart des paquets n'est pas globalement efficace en général. Il est important de se rappeler que l'objet de ce profil est de fournir une correspondance efficace des applications existantes avec les technologies de liaisons existantes, pas une efficacité en général. La complexité supplémentaire introduite par ce profil, bien que minimisée par une intégration étroite avec les fonctions déjà existantes de ROHC, implique qu'elle ne devrait donc être utilisée que pour optimiser les performances d'applications spécifiques sur des liaisons spécifiques.

Quand on met en œuvre ce profil sur diverses technologies de liaisons, il faut faire attention à garantir que toutes les fonctions nécessaires sont fournies ensemble par ROHC et les couches inférieures. Donc, des documents supplémentaires devraient spécifier comment incorporer ce profil par dessus les diverses technologies de liaison.

Le profil défini dans ce document a été à l'origine spécifié par la [RFC3242], mais pour viser un flux technique et préciser un problème de mise en œuvre, le présent document a été produit pour remplacer la RFC 3242, qui devient obsolète.

 	1.1	Différences avec la RFC 3242
Ce paragraphe résume les différences de ce document avec la RFC 3242. Les acronymes et la terminologie se trouvent à la Section 2.

Le format du paquet CSP, tel que défini dans la [RFC3242], était identifié comme non interopérable quand il portait un en-tête RHP avec un CRC de 3 ou 7 bits. Ce problème se pose parce que la charge utile a été éliminée par le compresseur, et que le décompresseur est supposé utiliser la longueur de la charge utile pour déduire certains champs dans l'en-tête non compressé. Ces champs sont la longueur totale IPv4, la longueur de charge utile IPv6, la longueur UDP, et le champ de somme de contrôle d'en-tête IPv4 (tous les champs INFERRED dans la [RFC3095]). Pour corriger cette faute, le paquet CSP doit porter les informations sur la longueur de la charge utile du paquet RHP. Donc, la longueur de la charge utile RTP a été incluse dans le paquet CSP.

Le présent document précise aussi une référence qui n'est pas claire dans la RFC 3242, où le paragraphe 4.1.3 déclare qu'en cas d'échec du CRC, les actions du paragraphe 5.3.2.2.3 de la [RFC3095] DOIVENT être entreprises. Ce paragraphe spécifie que la détection d'un retour à zéro du numéro de séquence et la réparation locale doivent être effectuées, mais aucune de ces étapes ne s'applique quand le paquet défaillant est un CCP. Donc, sur un échec de CRC, les actions à entreprendre sont celles spécifiées au paragraphe 5.3.2.2.3, mais seulement les étapes a à d.

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

CCP (Context Check Packet) paquet de vérification de contexte
CRC (Cyclic Redundancy Check) vérification de redondance cyclique
CSP (Context Synchronization Packet) paquet de synchronisation de contexte
LLA (Link Layer Assisted ROHC RTP profile) profil ROHC RTP à assistance de la couche de liaison
NHP (No Header Packet) paquet sans en-tête
ROHC (RObust Header Compression) compression d'en-tête robuste
RHP (ROHC Header Packet) paquet d'en-tête ROHC (un paquet non NHP; c'est-à-dire, RRP, CSP, ou CCP)
RRP (ROHC RTP Packet) paquet RTP ROHC, comme défini dans la [RFC3095], profil 0x0001

Couche d'assistance : se réfère à toute entité qui met en œuvre l'interface à ROHC (paragraphe 4.2). Elle peut, par exemple, se référer à une sous couche utilisée pour adapter la mise en œuvre de ROHC et la couche de liaison physique. Cette couche est supposée avoir connaissance de la synchronisation de la couche physique.

Côté compresseur : se réfère à la combinaison du compresseur d'en-têtes, opérant avec le profil LLA, et sa couche d'assistance associée.

Couches inférieures : se réfère, dans le présent document, aux entités situées en dessous de ROHC dans la pile de protocoles, incluant la couche d'assistance.

ROHC RTP : "ROHC RTP" se réfère au profil IP/UDP/RTP comme défini dans la [RFC3095].

 	3.	Vue d'ensemble du profil assisté de couche de liaison

Le profil ROHC IP/UDP/RTP défini dans la [RFC3242] et mis à jour par le présent document, profil 0x0005 (en hexadécimal) est conçu pour être utilisé sur des canaux qui ont été optimisés pour des tailles de charge utile spécifiques et ne peuvent donc pas s'accomoder efficacement des informations d'en-tête lorsque ils sont transmis avec des charges utilies qui correspondent à ces tailles optimales.

Le profil LLA étend, et donc hérite aussi de toutes les fonctionnalités du profil ROCH RTP en définissant des fonctions supplémentaires et une interface provenant du composant ROHC vers une couche inférieure d'assistance.

                   +---------------------------------------+
                   |                                       |
   Profil LLA      |   Profil ROHC RTP n° 1                |
                   |                     +-----------------+
                   |                     | Ajouts à LLA    |
                   +---------------------+-----------------+

En imposant des exigences supplémentaires aux couches inférieures par rapport à la [RFC3095], il est possible de déduire les informations nécessaires pour maintenir une compression d'en-tête robuste et transparente, même si les en-têtes sont complètement éliminés durant la plus grande partie du temps de fonctionnement.

Fondamentalement, ce profil remplace les plus petits et fréquents en-têtes en mode U/O ROHCpar un format sans en-tête, pour lequel la fonction d'en-tête doit être fournie par d'autres moyens.

    Plus petit en-tête dans              Plus petit en-tête dans
     ROHC RTP (profil n° 1)              LLA (profil n° 5)
   +--+--+--+--+--+--+--+--+              ++
   |        1 octet        |  ----->      ||  Pas d'en-tête
   +--+--+--+--+--+--+--+--+              ++
               |
               |                        Fonction de champ d'en-tête
               +------------------->    fournie pas d'autres moyens

Les champs présents dans les en-têtes ROHC RTP pour le mode U/O PT0 sont l'identifiant de type de paquet, le numéro de séquence, et le CRC. Les paragraphes qui suivent développent comment la fonction de ces champ est remplacée pour NHP.

 	3.1	Fourniture de l'identification de type de paquet
Tous les en-têtes ROHC portent un identifiant de type de paquet, qui indique au décompresseur comment l'en-tête devrait être interprété. C'est une fonction qui doit être fournie par un moyen quelconque dans la compression d'en-tête 0 octet. Il va être possible de distinguer les paquets ROHC RTP avec des en-têtes compressés grâce à l'identifiant de type de paquet, mais un mécanisme est nécessaire pour séparer les paquets avec un en-tête des paquets sans en-tête. Cette fonction DOIT donc être fournie par la couche d'assistance d'une façon ou d'une autre.

 	3.2	Remplacement du numéro de séquence
À partir de l'application envoyeuse, le numéro de séquence RTP est augmenté de un pour chaque paquet envoyé. L'objet du numéro de séquence est de faire face au changement d'ordre des paquets et à la perte de paquets. Si un changement d'ordre ou une perte survient avant le point de transmission, le côté qui compresse peut, si nécessaire, facilement éviter les problèmes en ne permettant pas l'utilisation d'un paquet sans en-tête.

Cependant, au point de transmission, la perte ou le changement d'ordre qui peut survenir sur la liaison ne peut pas être anticipé et protégé. Donc, pour NHP, la couche d'assistance DOIT garantir une livraison dans l'ordre sur la liaison (déjà supposée par la [RFC3095]) et du côté du receveur, elle DOIT fournir une indication pour chaque perte de paquet sur la liaison. C'est fondamentalement le même principe que celui sur lequel repose la compression d'en-tête VJ [RFC1144].

Noter que garantir la livraison dans l'ordre et l'indication de perte de paquet sur la liaison rend non seulement possible de déduire les informations de numéro de séquence, mais aussi supplante la principale fonction du CRC, qui prend normalement soin des erreurs dues aux pertes sur la liaison et des erreurs de bits dans le numéro de séquence compressé.

 	3.3	Remplacement du CRC
Tous les paquets RRP qui mettent à jour le contexte portent un CRC calculé sur l'en-tête non compressé. Le CRC est utilisé par le décompresseur pour vérifier que le contexte mis à jour est correct. Cette vérification sert trois objets dans le mode U/O :
1) Détection de pertes plus longues que ce qui peut être couvert par les LSB de numéro de séquence.
2) Protection contre les défaillances causées par des erreurs de bit résiduelles dans les en-têtes compressés.
3) Protection contre les mises en œuvre fautives et les autres causes d'erreur.

Comme ce profil définit un paquet NHP sans ce CRC, il faut faire attention à satisfaire ces trois objectifs par d'autres moyens quand un NHP est utilisé comme remplacement d'un paquet de mise à jour de contexte. La détection de longues pertes (1) est déjà couverte, car la couche d'assistance DOIT fournir une indication de toutes les pertes de paquet. De plus, le paquet NHP a un avantage important sur les paquets RHP en ce que les erreurs de bit résiduelles (2) ne peuvent pas endommager un en-tête qui n'est même pas envoyé.

Il est donc raisonnable de supposer que la transparence de la compression et de la décompression peut être assurée avec une confiance élevée, même sans CRC dans les paquets sans en-tête. Cependant, pour fournir une protection supplémentaire contre la propagation de dommages due à des erreurs de bit résiduelles non détectées dans les paquets de mise à jour de contexte (2) ou autres erreurs inattendues (3), des vérifications périodiques de contexte DEVRAIENT être effectuées (paragraphe 4.6).

 	3.4	Applicabilité du profil
Le profil LLA peut être utilisé avec toute technologie de liaison capable de fournir la fonction requise décrite dans les paragraphes précédents. Donc, si LLA ou ROHC RTP devrait être mis en œuvre dépend des caractéristiques de la liaison elle-même. Pour la plupart des flux de paquets RTP, LLA va fonctionner exactement comme ROHC RTP, et il va avoir une efficacité de compression supérieure pour les flux de paquets avec certaines caractéristiques. LLA ne va jamais avoir une efficacité de compression inférieure à celle de ROHC RTP.

Noter aussi que LLA, comme tous les autres profils ROHC, est pleinement transparent à tout flux de paquets atteignant le compresseur. LLA ne fait aucune hypothèse sur le flux de paquets mais va fonctionner de façon optimale pour les flux de paquets avec certaines caractéristiques, par exemple, des flux synchronisés exactement rythmés sur la liaison d'assistance sur laquelle le profil LLA est mis en œuvre.

Le profil LLA n'est évidemment pas applicable si la somme de contrôle UDP (2 octets) est activée, ce qui est toujours le cas pour IPv6/UDP. Pour IPv4/UDP, l'envoyeur peut choisir de désactiver la somme de contrôle UDP.

 	4.	Ajouts et exceptions par rapport à ROHC RTP
 	4.1	Types de paquets supplémentaires
Le profil LLA définit trois nouveaux types de paquet à utiliser en plus des types de paquet RRP définis par la [RFC3095]. Les paragraphes qui suivent décrivent en détail ces types de paquet et leur objet.

 	4.1.1	Paquet sans en-tête (NHP)
Un paquet sans en-tête (NHP, No-Header Packet) est un paquet qui consiste seulement en la charge utile du paquet d'origine. Les NHP PEUVENT être utilisés quand seules les informations de séquence ont besoin d'être convoyées au décompresseur. En d'autres termes, le NHP peut être utilisé quand tous les champs d'en-tête sont soit inchangés, soit suivent le schéma de changement actuellement établi. De plus, il y a des éléments à considérer pour l'utilisation du NHP (voir les paragraphes 4.3, 4.5, et 4.6). Il n'est pas permis à un compresseur LLA de livrer des paquets NHP quand il fonctionne en mode R.

La couche d'assistance PEUT envoyer le NHP pour RTP SN = X seulement si un NHP a été livré par le compresseur LLA ET que la couche d'assistance peut garantir que le décompresseur va déduire la séquence appropriée pour ce NHP. Cette garantie se fonde sur la confiance que le décompresseur :
a) a le moyen de déduire le séquençage appropriée pour le paquet correspondant à SN = X-1, ET
b) a soit reçu une indication de perte, soit le paquet lui-même pour le paquet correspondant à SN = X-1.
Propriétés de mise à jour : les paquets NHP mettent à jour le contexte (numéro de séquence RTP).

 	4.1.2	Paquet de synchronisation de contexte (CSP)
Le cas où le flux de paquets dépasse la bande passante du canal peut conduire à éliminer des données, dont peut résulter une invalidation du contexte au décompresseur. Il pourrait donc être avantageux d'envoyer un paquet avec seulement les informations d'en-tête et d'éliminer la charge utile. Cela aiderait à maintenir la synchronisation du contexte au décompresseur tout en utilisant efficacement la bande passante disponible.
Ce cas peut être traité avec le paquet de synchronisation de contexte (CSP, Context Synchronization Packet ) qui a le format suivant :

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   1   1   1   0   1   0 | Identifiant de type de paquet
+===+===+===+===+===+===+===+===+
/ Longueur de charge utile RTP  / 2 octets
+---+---+---+---+---+---+---+---+
: En-tête ROHC sans bourrage    :
: voir [RFC3095] paragraphe 5.7 :
+---+---+---+---+---+---+---+---+

Longueur de charge utile RTP : ce champ est la longueur de la charge utile portée à l'intérieur de l'en-tête RTP, mémorisée dans l'ordre des octets du réseau. C'est-à-dire que ce champ va être réglé par le compresseur à (longueur UDP - taille de l'en-tête UDP - taille de l'en-tête RTP incluant les identifiants de CSRC).

Propriétés de mise à jour : CSP conserve les propriétés de mise à jour de l'en-tête ROHC qu'il porte.

Le CSP est défini par un des identifiants inutilisés de type de paquet de ROHC RTP, porté dans l'en-tête de base de un octet. Comme pour tout paquet ROHC, sauf le NHP, le paquet peut commencer par un bourrage ROHC et/ou un retour. Il peut aussi porter une identification de contexte après l'identifiant de type de paquet. Il est possible d'avoir deux champs CID présents, un après l'identifiant de type de paquet et un au sein de l'en-tête ROHC encapsulé. Si un décompresseur reçoit un CSP incluant deux valeurs de CID non égales, le paquet DOIT être éliminé. La segmentation ROHC peut aussi être appliquée au CSP.

Dans le paquet CSP, la charge utile a été abandonnée par le compresseur. Cependant, le décompresseur est supposé utiliser la longueur de la charge utile pour déduire certains champs dans l'en-tête non compressé (longueur totale IPv4, longueur de charge utile IPv6, longueur UDP, et somme de contrôle d'en-tête IPv4). Quand il abandonne la charge utile, le CSP doit contenir des informations sur la longueur de la charge utile portée dans le paquet RHP. Donc, la longueur de la charge utile RTP est portée dans le CSP. Quand le décompresseur reçoit un CSP, il peut utiliser la longueur de la charge utile RTP pour calculer la valeur des champs classés comme INFERRED dans la [RFC3095] quand il tente de vérifier un CRC de 3 ou 7 bits porté dans l'en-tête RHP inclus dans le CSP.

Noter que quand le décompresseur a reçu et traité un CSP, le paquet (incluant toutes les données qui peuvent suivre l'en-tête compressé encapsulées dans le CSP) DOIT être éliminé.

 	4.1.3	Paquet de vérification de contexte (CCP)
On définit un paquet de vérification de contexte (CCP, Context Check Packet) qui ne porte aucune charge utile mais seulement une valeur facultative de CRC en plus de l'identifiant de type de paquet. L'objet du CCP est de fournir un paquet utile qui PEUT être envoyé par une couche de liaison synchronisée physiquement dans le cas où les données doivent être envoyées à des intervalles fixes, même si aucun paquet compressé n'est disponible. La couche d'assistance décide si le CCP est envoyé sur la liaison et livré au décompresseur. Le CCP a le format suivant :

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   1   1   1   0   1   1 | identifiant de type de paquet
+===+===+===+===+===+===+===+===+
| C |          CRC              |
+---+---+---+---+---+---+---+---+

C : C = 0 indique que le champ CRC n'est pas utilisé.
      C = 1 indique qu'un CRC valide est présent.

Propriétés de mise à jour : les paquets CCP ne mettent pas à jour le contexte.

Le CCP est défini par un des identifiants de type de paquet inutilisés dans ROHC RTP, porté dans le premier octet de l'en-tête de base. Le premier bit du second octet, bit C, indique si le champ CRC est utilisé. Si C=1, le champ CRC DOIT être réglé au CRC de 7 bits calculé sur l'en-tête original non compressé défini au paragaphe 5.9.2 de la [RFC3095]. Comme pour tout paquet ROHC sauf NHP, le paquet PEUT commencer par du bourrage ROHC et/ou porter une identification de contexte.

L'utilisation du champ CRC pour effectuer la vérification du contexte au décompresseur est facultative et est donc un problème de mise en œuvre du compresseur. Cependant, un CCP DOIT toujours être rendu disponible à la couche d'assistance.

Si la couche d'assistance reçoit du compresseur des CCP avec le bit C établi (C=1) elle DOIT utiliser le dernier CCP reçu si un CCP est à envoyer, c'est-à-dire, le CCP qui correspond au dernier paquet non CCP envoyé (NHP, RRP ou CSP). Une couche d'assistance PEUT utiliser le CCP à d'autres fins, comme de signaler une perte de paquet avant la liaison.

Il est EXIGÉ du décompresseur qu'il traite un CCP reçu avec le bit C établi (C=1) ce qui indique un champ CRC valide, et qu'il effectue la vérification du contexte. Le CRC reçu DOIT alors être appliqué au dernier paquet décompressé, sauf si une indication de perte de paquet a été reçue précédemment. En cas d'échec du CRC, les actions DOIVENT être décidées comme spécifié au paragraphe 5.3.2.2.3 de la [RFC3095], étapes a à d seulement. Un CCP reçu avec C=0 DOIT être ignoré par le décompresseur. Il n'est pas permis au décompresseur de faire plus d'interprétation du CCP.

Quand il utilise le CRC de 7 bits dans le paquet CCP pour vérifier le contexte, le décompresseur a besoin d'avoir accès à l'en-tête non compressé entier du dernier paquet décompressé. Certaines mises en œuvre de la [RFC3095] pourraient ne pas sauvegarder les valeurs des champs INFERRED. Une mise en œuvre de ROHC LLA DOIT sauvegarder ces champs dans le contexte du décompresseur pour être capable de réussir à vérifier les paquets CCP.
L'utilisation de CCP par une couche d'assistance est facultative et dépend des caractéristiques réelles de la liaison. Les spécifications de mise en œuvre de couche de liaison pour ce profil DOIVENT donc dire si il est utilisé.

 	4.2	Interfaces avec la couche d'assistance
Ce profil s'appuie sur les couches inférieures pour fournir les fonctions nécessaires permettant d'envoyer les paquets NHP. Cette interaction entre LLA et la couche d'assistance est définie comme interfaces entre le compresseur/décompresseur LLA et la technologie de liaison applicable à LLA.

                |                              |
                +                              +
   +-------------------------+    +-------------------------+
   |    En-tête ROHC RTP     |    |    En-tête ROHC RTP     |
   +-------------------------+    +-------------------------+
   |       Profil LLA        |    |     Profil LLA          |
   +=========================+    +=========================+
   |    Interface ROHC       |    |  Interface de couche    |
   | à couche d'assistance   |    |   d'assistance à ROHC   |
   +=========================+    +=========================+
   |  Technologie de liaison |    |  Technologie de liaison |
   |   applicable            |    |     applicable          |
   +=========================+    +=========================+
                |                              |
                +------>---- CANAL ------>-----+

La figure ci-dessus montre les divers niveaux, comme définis dans la [RFC3095] et le présent document, constituant une mise en œuvre complète du profil LLA. La figure souligne aussi le besoin de documents supplémentaires pour spécifier comment mettre en œuvre ces interfaces pour une technologie de liaison pour laquelle ce profil est pertinent.

Ce paragraphe définit les informations à échanger entre le compresseur LLA et la couche d'assistance pour que ce profil fonctionne correctement. Bien qu'il définisse la sémantique, il ne spécifie pas comment ces interfaces sont à mettre en œuvre.

 	4.2.1	Interface, entre compresseur et couche d'assistance
Ce paragraphe définit la sémantique de l'interface entre le compresseur et la couche d'assistance, donnant les règles de livraison de paquet à partir du compresseur.

L'interface définit les paramètres suivants : RRP, fanion de segmentation RRP, CSP, fanion de segmentation CSP, NHP, et numéro de séquence RTP. Tous les paramètres, sauf NHP, DOIVENT toujours être livrés à la couche d'assistance. Cela conduit aux deux scénarios de livraison possibles :

a.	RRP, CSP, CCP, NHP, et numéro de séquence RTP sont livrés, avec les fanions de segmentation correspondants, réglés en conséquence. Cela correspond au cas où le compresseur permet l'envoi d'un paquet NHP, avec ou sans segmentation appliquée aux paquets RRP/CSP correspondants. On rappelle que la livraison d'un paquet NHP se produit quand le compresseur ROHC RTP aurait utilisé un ROHC UO-0.

b.	RRP, CSP, CCP, et numéro de séquence RTP sont livrés, avec les fanions de segmentation correspondants, réglés en conséquence. Cela correspond au cas où le compresseur ne permet pas l'envoi d'un paquet NHP. La segmentation pourrait être appliquée aux paquets RRP et CSP correspondants.

La segmentation peut être appliquée indépendamment au paquet RRP ou CSP si sa taille excède la plus grande valeur fournie dans la liste PREFERRED_PACKET_SIZES et si le paramètre LARGE_PACKET_ALLOWED est réglé à faux. Les fanions de segmentation sont explicitement établis dans la définition de l'interface pour souligner que le RRP et le CSP peuvent être livrés par le compresseur comme paquets segmentés.

Le SN RTP DOIT être livré pour chaque paquet par le compresseur pour permettre à la couche d'assistance de tenir les informations de séquençage nécessaires.

 	4.2.2	Interface de couche d'assistance à décompresseur
On définit ici la sémantique de l'interface entre la couche d'assistance et le décompresseur, en donnant des règles simples pour la livraison des paquets reçus au décompresseur. Le décompresseur a besoin d'un moyen pour distinguer les NHP des paquets RHP. Aussi, quand il reçoit des paquets sans en-tête, le décompresseur a nesoin d'un moyen pour déduire les informations de séquençage pour garder la synchronisation entre la charge utile reçue et les informations de séquence des en-têtes décompressées. Pour réaliser cela, le décompresseur DOIT recevoir ce qui suit de la couche d'assistance :
-	une indication pour chaque perte de paquet sur la liaison entre le côté compresseur et le côté décompresseur pour CID=0.
-	le paquet reçu avec une indication de si le paquet reçu est un NHP.

Noter que le contexte est mis à jour à partir d'une indication de perte de paquet.

 	4.3	Accord d'approche optimiste
ROHC définit une approche optimiste pour les mises à jour pour réduire les frais généraux d'en-tête. Cette approche est pleinement exploitée dans les modes de fonctionnement optimiste et unidirectionnel. Du fait de la présence d'un CRC dans tous les en-têtes compressés, l'approche optimiste est définie comme un problème de compresseur parce que le décompresseur va toujours être capable de détecter un contexte invalide par la vérification du CRC.

Cependant, aucun CRC n'est présent dans le NHP défini par le profil LLA. Donc, la perte d'un paquet RHP qui met à jour le contexte ne peut pas toujours être détectée. Pour éviter ce problème, le côté compresseur et le côté décompresseur doivent s'accorder sur les principes de l'approche optimiste, et les principes acceptés DOIVENT être appliqués non seulement par le compresseur mais aussi par la couche d'assistance qui transmet. Si, par exemple, trois mises à jour consécutives sont envoyées pour porter un changement de champ d'en-tête, le décompresseur doit le savoir et invalider le contexte si trois paquets physiques consécutifs ou plus sont perdus. Noter que le mécanisme utilisé pour appliquer l'approche optimiste doit être réinitialisé si un nouveau changement de champ doit être porté alors que le côté compresseur est déjà en train d'envoyer des paquets pour porter des mises à jour de contexte non linéaires.

Un décompresseur LLA DOIT utiliser sa connaissance de l'approche optimiste pour détecter de possibles événements de perte de contexte. Si il suspecte une perte de contexte, il DOIT invalider le contexte et ne plus transmettre de paquets avant que le contexte ait été synchronisé.

Il est EXIGÉ que tous les documents qui décrivent comment le profil LLA est mis en œuvre sur une certaine technologie de liaison définissent comment l'accord d'approche optimiste est réalisé entre le côté compresseur et le côté décompresseur. Cela pourrait être traité avec un principe fixé, avec une négociation au démarrage, ou par d'autres moyens, mais la méthode doit être définie sans ambiguïté.

 	4.4	Initialisation rapide de contexte, redéfinition de IR
Comme les paquets IR initiaux pourraient dépasser la bande pasante du canal et retarder significativement le délai d'établissement du contexte au décompresseur, il pourrait être avantageux d'éliminer initialement la charge utile. Cela permet que les transitions d'état et une meilleure efficacité de compression soient réalisées avec un délai minimal.

À cette fin, le bit D de la structure de base du paquet IR ROHC RTP du paragraphe 5.7.7.1 de la [RFC3095] est redéfini pour le profil LLA. Pour D=0 (pas de chaîne dynamique) la signification du bit D est étendue pour indiquer que la charge utile a été éliminée lors de l'assemblage du paquet IR. Tous les autres champs conservent leur signification comme défini pour ROHC RTP.

La structure résultante, en utilisant de petits CID et CID=0, devient :

   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 1 | 1 | 0 | D |
+---+---+---+---+---+---+---+---+
|            Profil             | 1 octet
+---+---+---+---+---+---+---+---+
|              CRC              | 1 octet
+---+---+---+---+---+---+---+---+
|       Chaîne statique         | longueur variable
 - - - - - - - - - - - - - - - -
|       Chaîne dynamique        | pas présente si D = 0
|                               | présente si D = 1, longueur variable
 - - - - - - - - - - - - - - - -
|       Charge utile            | pas présente si D = 0
|                               | présente si D = 1, longueur variable
 - - - - - - - - - - - - - - - -

D : D = 0 indique que la chaîne dynamique n'est pas présente et que la charge utile a été éliminée.

Après qu'un paquet IR avec D=0 a été traité par le décompresseur, le paquet DOIT être éliminé.

 	4.5	Option de retour, CV-REQUEST
L'option CV-REQUEST PEUT être utilisée par le décompresseur pour demander un RRP ou CSP pour la vérification du contexte. Cette option devrait n'être utilisé que si des NHP n'ont pas été reçus depuis longtemps et donc que le contexte n'a pas été vérifié récemment.

+----+----+----+----+----+----+----+----+
| Type d'option = 8 |Longueur d'option 0|
+----+----+----+----+----+----+----+----+

Si le compresseur reçoit un paquet de retour avec cette option, le prochain paquet compressé NE DEVRAIT PAS être livré à la couche d'assistance comme NHP.

 	4.6	Vérification périodique de contexte
Comme décrit au paragraphe 3.3, la transparence est supposée être garantie par la fonction fournie par les couches inférieures. Ce profil ROHC va donc être au moins aussi fiable que les plus anciens schémas de compression d'en-tête [RFC1144], [RFC2507], [RFC2508], qui n'utilisent pas le CRC de compression d'en-tête. Cependant, comme ROHC RTP est normalement extrêmement sûr d'utilisation du point de vue de la transparence, il va être souhaitable qu'il soit capable de faire aussi cela avec LLA.

Pour donner une garantie supplémentaire de transparence et aussi saisir des erreurs inattendues, comme des erreurs dues à des mises en œuvre fautives, il est RECOMMANDÉ que les paquets de mise à jour de contexte soient envoyés périodiquement, même quand la logique du compresseur permet que les paquets sans en-tête soient utilisés.

 	4.7	Utilisation d'identifiant de contexte
Comme un NHP ne peut pas porter d'identifiant de contexte (CID) il y a une restriction sur la façon dont ce profil peut être utilisé, relative à l'identification du contexte. Indépendamment de la taille de CID qui a été négociée, les paquets NHP peuvent seulement être utilisés pour CID=0. Si le décompresseur reçoit un NHP, il peut seulement avoir un CID=0.

Noter que si plusieurs flux de paquets sont traités par un compresseur qui fonctionnne en utilisant LLA, la couche d'assistance doit, en cas de perte de paquet physique, être capable de dire pour quel CID la perte s'est produite, ou au moins, il DOIT être capable de dire si des paquets avec CID=0 (flux de paquets avec des NHP) ont été perdus.

 	5.	Questions de mise en œuvre

Le présent document spécifie des mécanismes pour le protocole et laisse les détails de l'utilisation de ces mécanismes aux mises en œuvre. La présente Section donne des directives, des idées, et suggestions pour la mise en œuvre de LLA.

 	5.1	Paramètres et signaux de mise en œuvre
Comme décrit au paragraphe 6.3 de la [RFC3095], les mises en œuvre utilisent des paramètres pour établir les informations de configuration et stipuler comment la mise en œuvre de ROHC doit fonctionner. Les paramètres suivant sont des ajouts, utiles pour LLA, à l'ensemble de paramètres défini pour les mises en œuvre de ROHC RTP. Noter que si les paramètres PREFERRED_PACKET_SIZES définis ici sont utilisés, ils rendent obsolètes tous les paramètres PACKET_SIZE (taille de paquet) et PAYLOAD_SIZE (taille de charge utile) de ROHC RTP.

 	5.1.1	Paramètres de mise en œuvre au compresseur
ALWAYS_PAD (toujours bourrage) -- valeur : booléen. Ce paramètre peut être réglé par une entité externe pour spécifier au compresseur que chaque paquet RHP DOIT être bourré avec le bourrage ROHC de un octet minimum. La couche d'assistance DOIT fournir un identifiant de type de paquet. Si aucun champ n'est disponible pour cela du protocole à la couche de liaison, alors une séquence en tête peut être utilisée pour distinguer les paquets RHP des paquets NHP. Bien que l'utilisation d'une séquence en tête ne soit évidemment pas efficace, car elle sacrifice l'efficacité pour les paquets RHP, la perte d'efficacité devrait être insignifiante parce que la séquence en tête s'applique seulement aux paquets avec en-têtes afin de favoriser l'utilisation de paquets sans en-tête. Si une séquence en tête est désirée pour l'identification des RHP, la couche inférieure PEUT utiliser le bourrage ROHC pour la séquence de tête en établissant le paramètre ALWAYS_PAD (toujours bourrer). Noter que dans ce cas, de possibles collisions du bourrage avec la charge utile du NHP doivent être évitées. Par défaut, ce paramètre est réglé à FAUX.

PREFERRED_PACKET_SIZES (tailles de paquet préférées) -- liste de : 
SIZE (taille)  -- valeur : entier (octets)
RESTRICTED_TYPE (type interdit) -- valeurs : [NHP_SEUL, RHP_SEUL, PAS_DE_RESTRICTION]
Cet ensemble de paramètres dit quelles tailles de paquet sont préférées par la couche d'assistance. Si cet ensemble de paramètres est utilisé, tous les paquets RHP DOIVENT être bourrés pour tenir dans la plus petite taille préférée possible. Si la taille du paquet non bourré (ou, dans le cas de ALWAYS_PAD établi, le paquet avec le bourrage minimal de un octet) est plus grande que la taille maximale de paquet préférée, le compresseur a deux options. Soit il peut livrer le paquet plus grand avec une taille arbitraire, soit il peut partager le paquet en plusieurs segments en utilisant la segmentation ROHC et en bourrant chaque segment à une des tailles préférées. La méthode à utiliser dépend de la valeur du paramètre LARGE_PACKETS_ALLOWED (grands paquets permis) ci-dessous.

Les paquets NHP ne peuvent être livrés à la couche inférieure que si la taille de charge fait partie de l'ensemble de tailles de paquet préférées. De plus, si RESTRICTED_TYPE est réglé à NHP_SEUL ou RHP_SEUL pour une des tailles de paquet préférées, cette taille n'est permise que pour les paquets du type spécifié.

Par défaut, aucune taille de paquet préférée n'est spécifiée. Quand des tailles sont spécifiées, la valeur par défaut pour RESTRICTED_TYPE est NO_RESTRICTION.

LARGE_PACKETS_ALLOWED -- valeur : booléen
Ce paramètre peut être réglé par une entité externe pour spécifier comment traiter les paquets qui ne tiennent dans aucune des tailles de paquet préférées spécifiées. Si il est réglé à VRAI, le compresseur DOIT livrer le plus grand paquet tel quel et NE DOIT PAS utiliser la segmentation. Si il est réglé à FAUX, le schéma de segmentation ROHC DOIT être utilisé pour partager le paquet en deux segments ou plus, et chaque segment DOIT de plus être bourré pour tenir dans une des tailles de paquet préférée. Par défaut, ce paramètre est réglé à VRAI, ce qui signifie que la segmentation est désactivée.

VERIFICATION_PERIOD (période de vérification) -- valeur : entier
Ce paramètre peut être établi par une entité externe pour spécifier au compresseur la fréquence minimum à laquelle un paquet validant le contexte doit être envoyé. Cela dit au compresseur qu'un paquet contenant un champ CRC DOIT être envoyé au moins une fois tous les N paquets, où N=VERIFICATION_PERIOD (paragraphe 4.6).
Par défaut, ce paramètre est réglé à 0, ce qui indique que les vérifications périodiques sont désactivées.

 	5.1.2	Paramètres de mise en œuvre au décompresseur
NHP_PACKET -- valeur : booléen
Ce paramètre informe le décompresseur que le paquet livré est un NHP. Le décompresseur DOIT accepter cet indicateur de type de paquet provenant de la couche inférieure. Une couche d'assistance DOIT régler cet indicateur à vrai pour chaque NHP livré, et à faux pour tout autre paquet.

PHYSICAL_PACKET_LOSS (perte de paquet physique) -- signal
Ce signal indique au décompresseur qu'un paquet a été perdu sur la liaison entre le côté compresseur et le côté décompresseur, du fait d'une erreur de la liaison physique. Le signal est donné une fois pour chaque paquet perdu, et un décompresseur doit augmenter le numéro de séquence en conséquence quand ce signal est reçu.

PRE_LINK_PACKET_LOSS -- signal
Ce signal dit au décompresseur d'augmenter le numéro de séquence à cause d'un trou dans le séquençage sans relation avec une erreur de liaison physique. Une couche d'assistance receveuse peut, par exemple, utiliser ce signal pour indiquer au décompresseur qu'un paquet a été perdu avant le compresseur, ou qu'un paquet a été éliminé par la couche d'assistance transmetteuse.

 	5.2	Mise en œuvre sur diverses technologies de liaison
Ce document donne la sémantique et les exigences de l'interface nécessaire du compresszur et décompresseur ROHC vers la couche d'assistance pour effectuer la compression d'en-tête avec assistance de la couche de liaison.

Cependant, le présent document ne donne aucune information de fonctionnement spécifique de la couche de liaison, sauf pour certaines suggestions de mise en œuvre. Plus de détails sur la façon dont ce profil est à mettre en œuvre sur les diverses technologies de liaison doivent être décrits dans d'autres documents, où les caractéristiques spécifiques de chaque couche de liaison peuvent être prises en compte pour fournir l'usage optimal de ce profil.

Ces spécifications PEUVENT utiliser un schéma de bit de type de paquet non utilisé par ce profil pour mettre en œuvre la signalisation sur la couche inférieure. Le schéma disponible aux mises en œuvre de couche inférieure est [11111001].

 	6.	Considérations relatives à l'IANA

L'identifiant de profil ROHC 0x0005 a été réservé par l'IANA pour le profil IP/UDP/RTP défini dans ce document.

 	7.	Considérations sur la sécurité

Les considérations sur la sécurité de ROHC RTP, Section 7 de la [RFC3095] s'appliquent aussi à ce document, avec un ajout : dans le cas d'un scénario d'attaque de déni de service où un intrus injecte des paquets CCP bogués en utilisant des valeurs aléatoires de CRC sur la liaison, la vérification de CRC va échouer pour des raisons incorrectes du côté du décompresseur. Cela va évidemment réduire considérablement les avantages de ROHC et toute l'efficacité supplémentaire fournie par ce profil à cause des invalidations de contexte inutiles, des messages de retour, et des paquets de rafraîchissement. Cependant, la même remarque s'applique à la présence d'un tel intrus.

 	8.	Remerciements

Les auteurs tiennent à remercier Lila Madour, Ulises Olvera-Hernandez, et Francis Lupien de leurs apports concernant les liaisons typiques où LLA peut être appliqué. Merci aussi à Mikael Degermark pour les discussions fructueuses qui ont conduit à des amélioration de ce profil, et à Zhigang Liu pour ses nombreux commentaires pertinents.

 	9.	Références
 	9.1	Références normatives

[RFC0768]	J. Postel, "Protocole de datagramme d’utilisateur (UDP)", (STD 6), 28 août 1980.

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

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

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

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

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

 	9.2	Références pour information

[RFC0793]	J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", STD 7, septembre 1981.

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

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

[RFC3096]	M. Degermark, éd., "Exigences pour la compression d'en-tête robuste IP/UDP/RTP", juillet 2001. (Information)

[RFC3242]	L-E. Jonsson, G. Pelletier, "Compression d'en-tête robuste (ROHC) : profil assisté de couche liaison pour IP/UDP/RTP", avril 2002. (Obsolète, voir RFC4362) (P.S.)

[RFC3243]	L-E. Jonsson, "Compression d'en-tête robuste (ROHC) : exigences et hypothèses pour la compression IP/UDP/RTP sur 0 octet", avril 2002. (Information)

[CRTPC]	Degermark, M., Hannu, H., Jonsson, L-E. et K. Svanbro, "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communications Magazine, Volume 7, number 4, pp. 20-25, août 2000.

[VTC2000]	Svanbro, K., Hannu, H., Jonsson, L-E. et M. Degermark, "Wireless real time IP-services enabled by header compression", proceedings of IEEE VTC2000, mai 2000.

[MOMUC01]	Liu, G., et al., "Experimental field trials results of Voice-over IP over WCDMA links", MoMuC'01 - The International Workshop on Mobile Multimedia Communications, Conference proceedings, février 2001.

 	Adresse des auteurs

Lars-Erik Jonsson	Kristofer Sandlund	Ghyslain Pelletier	
Optand 737	Ericsson AB	Ericsson AB	
SE-831 92 Ostersund, Sweden	Box 920	Box 920	
téléphone : +46 70 365 20 58	SE-971 28 Lulea, Sweden	SE-971 28 Lulea, Sweden	
mél : lars-erik@lejonsson.com 	téléphone : +46 8 404 41 58	téléphone : +46 8 404 29 43	
	mél : kristofer.sandlund@ericsson.com 	mél : ghyslain.pelletier@ericsson.com	

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

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

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

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

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

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

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