RFC3408 Octets à zéro pour R-mode dans ROHC Liu & Le

Groupe de travail Réseau

Z. Liu & K. Le, Nokia

Request for Comments : 3408


Catégorie : En cours de normalisation


Traduction Claude Brière de L’Isle

décembre 2002



Prise en charge des octets à zéro pour le mode bidirectionnel fiable (R-mode) dans le profil de compression d'en-tête robuste (ROHC) de couche liaison étendue


Statut du présent mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.


Notice de copyright

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


Résumé

Le présent document définit un mode supplémentaire du profil de compression d’en-tête robuste (ROHC, RObust Header Compression) de la couche liaison étendue, aussi appelé le profil d’octet zéro, en plus des deux définis dans la RFC 3242. La compression d’en-tête de zéro octet existe afin d’empêcher que l’en-tête ROHC d’un seul octet ne pousse un flux de paquets de voix dans le prochain paquet de taille fixe supérieure pour la radio. Il est utilisable dans certaines anciennes interfaces radio largement déployées. Le présent document ajoute l’opération zéro octet pour le mode ROHC bidirectionnel fiable (mode R) à ceux qui sont spécifiés pour les modes Unidirectionnel (mode U) et Bidirectionnel optimiste (mode O) de compression d’en-tête de la RFC 3242.


1. Introduction


La [RFC3242] définit une solution à zéro octet pour la compression des paquets IP/UDP/RTP pour les seuls modes unidirectionnel (U-) et bidirectionnel optimiste (O-) [RFC3095]. La présente spécification étend le profil défini dans la [RFC3242] pour fournir la prise en charge du zéro octet pour le mode bidirectionnel fiable (R, Reliable). La présente spécification et la [RFC3242] permettent qu’un format de paquet libre d’en-tête soit utilisé dans tous les modes pour remplacer la majorité des en-têtes de un octet des paquet RTP ROHC envoyés en fonctionnement normal. Précisément, le compresseur qui fonctionne en mode R a la permission de livrer un paquet sans en-tête (NHP, No-Header Packet) alors que la [RFC3242] aurait exigé qu’il livre un paquet ROHC fiable de type zéro (R-0) de la [RFC3095].


Pour simplifier, ce profil est défini sous la forme d’ajouts et d’exceptions à la [RFC3242] dont il est exigé qu’ils étendent le profil de la RFC3242 avec la prise en charge du zéro octet pour le mode R. Toute la terminologie utilisée dans le présent document est la même que celle de la [RFC3242].


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


2. Extensions à l’interface de la couche d’assistance (AL)


La présente section décrit les ajouts (dont certains sont facultatifs) à l’interface de la couche d’assistance (AL, Assistance Layer) telle que définie au paragraphe 4.2 de la [RFC3242].


2.1 Paramètres supplémentaires à l’interface compresseur/AL


- Mode, indiquant le mode dans lequel fonctionne le compresseur. La AL a une logique légèrement différente selon la valeur du mode.

- SN_ACKed, indiquant le dernier numéro de séquence (SN, Sequence Number) RTP qui a été acquitté. Il n’est utilisé que lorsque la valeur Mode = mode R.


Noter que ces deux paramètres DOIVENT toujours être attachés à chaque paquet livré à l’AL.


2.2 Interface supplémentaire, couche d’assistance à compresseur


Pour améliorer l’efficacité de la compression de ce profil dans certains cas spécifiques, par exemple, lorsque l’AL fonctionne d’une façon telle qu’il devient souvent peu sûr d’envoyer des NHP, il est RECOMMANDÉ de mettre en œuvre une interface supplémentaire. Ici, le mot "peu sûr" signifie que le compresseur permet à l’AL d’envoyer des NHP mais que l’AL ne peut pas garantir que le SN RTP du NHP sera correctement décompressé du côté receveur . L’interface est utilisée pour porter une demande de mise à jour (update_request) comme décrit à la Section 3. Noter que cet interface n’est pas exigée dans le sens que l’impossibilité de mettre en œuvre une telle interface ne devrait pas être un obstacle à la mise en œuvre de ce profil sur une liaison spécifique.


3. Fonctionnement du mode R


Pour le mode R, ce profil étend RTP ROHC en effectuant une transposition du paquet R-0 en paquet NHP. Noter que R-0 est le seul type de paquets en mode R qui puisse être remplacé par un NHP.


Du côté receveur, le SN RTP d’un NHP est déterminé par le décompresseur comme = SN_Ref_D + Offset_D, où SN_Ref_D est le SN RTP du dernier paquet de mise à jour reçu par le décompresseur, et Offset_D est le décalage de numéro de séquence entre le NHP et le dernier paquet de mise à jour. Comment déduire Offset_D dépend de la mise en œuvre de ce profil sur une technologie spécifique de liaison et doit être spécifié dans le ou les documents de mise en œuvre. Par exemple, il peut être calculé en comptant le nombre total de paquets qui ne sont pas de mise à jour de contexte (incluant les NHP) et les indications de perte de paquet reçues depuis la dernière mise à jour de contexte réussie. Autrement, il peut être déduit en utilisant le rythme de la liaison dans le cas où la transposition linéaire entre SN RTP et rythme de liaison est conservé.


Du côté émetteur, l’AL suit la règle définie au paragraphe 4.1.1 de la [RFC3242] pour déterminer si il peut envoyer ou non un NHP, avec une modification. C’est que lorsque l’AL détermine qu’il est devenu non sûr (voir au paragraphe 2.2) d’envoyer des NHP, l’AL enregistre le SN RTP correspondant comme SN_break. Il attend ensuite que la règle soit à nouveau satisfaite et que SN_ACKed > SN_break avant de reprendre l’envoi des NHP. La dernière condition est essentiellement la contrepartie de l’accord de l’approche optimiste (paragraphe 4.3 de la [RFC3242]) de mode U/O qui déclare que lorsque l’AL en mode U/O détermine qu’il n’est pas sûr d’envoyer le NHP, il doit envoyer des en-têtes dans les X paquets suivants, où X est un nombre sur lequel il y a eu accord. Il y a deux raisons à la différence : a) le mode R s’appuie sur des accusés de réception pour synchroniser les contextes, au lieu du principe de l’approche optimiste comme dans le mode U/O; et b) les paquets R-0 ne mettent pas à jour le contexte du décompresseur alors que les paquets UO-0 le font. Pour satisfaire la condition SN_ACKed > SN_break, l’AL peut soit attendre passivement que le compresseur envoie un paquet de mise à jour de contexte (par exemple, R-0-CRC déclanché par le retour à zéro du SN de 6 bits) ou envoyer une demande de mise à jour via l’interface de AL au compresseur (paragraphe 2.2) pour demander au compresseur d’envoyer un paquet mettant à jour le contexte. Le update_request porte le dernier SN_break. À réception d’une update_request, le compresseur DEVRAIT utiliser un paquet de mise à jour de contexte (par exemple, R-0-CRC) lorsque il envoie le prochain paquet. Les paquets de mise à jour de contexte sont traités comme dans la [RFC3095].


Note : l’attente passive décrite ci-dessus peut durer longtemps dans le pire cas, durant lequel les NHP ne peuvent pas être envoyés. Donc, l’envoi de update_request via l’AL facultatif à l’interface de compresseur est RECOMMANDÉ pour améliorer les performances dans le plus mauvais cas.


Note : la demande de mise à jour peut être perdue si l’AL et le compresseur sont situés à des endroits différents et si le canal entre eux n’est pas fiable, mais une telle perte retarde seulement la reprise de l’envoi de NHP par l’AL. Donc, la question de la fréquence de l’envoi des demandes de mise à jour par l’AL dépend de la mise en œuvre. Par exemple, l’AL peut envoyer des demandes de mise à jour pour chaque paquet qu’il reçoit du compresseur jusqu’à ce que soient satisfaites les conditions pour l’envoi de NHP.


Note : comme il n’y a pas de champ CRC dans les paquets R-0, seule la fonction relative au SN RTP et à l’identifiant de type de paquet doit être remplacée. De plus, les paquets NHP et les indications de perte de paquet en mode R ne mettent à jour le contexte ni au compresseur ni au décompresseur (à l’opposé du mode U/O). Par conséquent, le principe de référence sûre du paragraphe 5.3 de la [RFC3095] n’est affecté en aucune façon et il n’y a pas de perte de robustesse dans ce profil par rapport à RTP ROHC.


4. Différences entre mode R et mode U/O


Cette section précise certaines différences entre le mode R et le mode U/O dans ce profil.


a) Remplacement du CRC

À la différence du mode U/O, le remplacement du CRC du paragraphe 3.3 de la [RFC3242] n’est pas un problème pour le mode R car les paquets R-0 ne portent pas de champ CRC.


b) Vérification périodique du contexte

Pour le mode U/O la vérification périodique du contexte du paragraphe 4.6 de la [RFC3242] est RECOMMANDÉ pour fournir une protection supplémentaire contre la propagation de dommages après le remplacement de CRC. Pour le mode R, comme il n’y a pas de remplacement de CRC (voir ci-dessus) aucun changement n’est nécessaire à cet égard à RTP ROHC. En particulier, le mode R a cette caractéristique naturellement incorporée, car l’envoi de CRC R-0 lorsque le numéro de séquence de 6 bits revient à zéro fournit implicitement une vérification périodique de contexte pour le mode R.


c) Option CV-REQUEST

Pour les mêmes raisons que ci-dessus le décompresseur fonctionnant en mode R NE DEVRAIT PAS envoyer de CV-REQUEST du paragraphe 4.5 de la [RFC3242] au compresseur. Ceci pour éviter une surcharge inutile sur le canal de retour.


d) Paquet de vérification de contexte (CCP)

Lorsque un CCP du paragraphe 4.1 de la [RFC3242] est utilisé, un compresseur fonctionnant en mode R DEVRAIT régler le bit C à 0 (zéro) et ne pas générer de CRC de 7 bits si le coût de calcul au compresseur et au décompresseur pose problème. L’utilisation du champ CRC dans un CCP pour effectuer une vérification du contexte du décompresseur n’est pas critique en mode R (voir la dernière note de la Section 3 et le point b) ci-dessus).


e) Traitement des accusés de réception (ACK)

Une attention particulière devrait être apportée à la réalisation des accusés de réception pour les mises en œuvre de mode R. Il est RECOMMANDÉ d’éviter l’utilisation de paquets de retour éparpillés du paragraphe 5.2.1 de la [RFC3095] pour porter les informations d’accusé de réception. La raison en est que des paquets de retour éparpillés interrompraient le séquençage des SN RTP, désactivant donc temporairement l’envoi de NHP.


5. Considérations relatives à l’IANA


Un identifiant de profil ROHC a été réservé par l’IANA pour le profil défini dans le présent document (0x0105), où 0x0005 est l’identifiant de profil alloué pour LLA [RFC3242].


6. Considérations sur la sécurité


Les considérations pour la sécurité de RTP ROHC à la section 7 de la [RFC3095] s’appliquent aussi au présent 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 sur la liaison en utilisant des valeurs aléatoires de CRC, la vérification de CRC va échouer pour des raisons incorrectes du côté du décompresseur. Cela va évidemment considérablement réduire les avantages de ROHC et toute l’efficacité supplémentaire apportée par ce profil à cause de l’invalidation de contexte inutile, des messages de retours et des paquets de rafraîchissement. Cependant, les mêmes remarques s’appliquent au sujet de la présence d’un tel intrus.


7. Remerciements


Les auteurs tiennent à remercier Lars-Erik Jonsson et Ghyslain Pelletier pour les passionnantes discussions sur LLA qui ont aidé à mettre au point le fonctionnement du R-mode. Les auteurs remercient aussi de leurs précieux apports Carsten Bormann, Christopher Clanton, Mark Cheng, et Thinh Nguyenphu.


8. Références


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


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


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


9. Adresse des auteurs


Zhigang Liu

Khiem Le

Nokia Research Center

Nokia Research Center

6000 Connection Drive

6000 Connection Drive

Irving, TX 75039

Irving, TX 75039

USA

USA

téléphone : +1 972 894-5935

téléphone : +1 972 894-4882

Fax : +1 972 894-4589

Fax : +1 972 894-4589

mél zhigang.c.liu@nokia.com

mél : khiem.le@nokia.com


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


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


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


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.


Le présent document et les informations y 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 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 ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.


Remerciement

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

page - 4 -