Groupe de travail Réseau	D. Black	
Request for Comments : 3140	S. Brim	
RFC rendue obsolète : 2836	B. Carpenter	
Catégorie : En cours de normalisation	F. Le Faucheur	
Traduction Claude Brière de L'Isle	juin 2001	

Codes d'identification des comportements par bond

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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la 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 (2001). Tous droits réservés.

Résumé
Le présent document définit un mécanisme de codage sur 16 bits pour l'identification des comportements par bond des services différenciés dans les messages de protocole. Il remplace la RFC 2836.

Table des Matières
1. Introduction	1
1.1 Scénarios d'utilisation	2
2. Codage	2
3. Signalisation des codets de sélecteur de classe	3
4. Considérations relatives à l'IANA	3
5. Considérations pour la sécurité	3
Changements par rapport à la RFC 2836	4
Remerciements	4
Références	4
Adresse des auteurs	4

1.	Introduction

Les services différenciés [RFC 2474, RFC 2475] introduisent la notion de comportement par bond (PHB, Per Hop Behavior) qui définit comment le trafic appartenant à un agrégat de comportement particulier est traité à un nœud réseau individuel. Dans les en-têtes de paquet IP, les PHB ne sont pas indiqués comme tels, et des valeurs de codet de service différencié (DSCP, Differentiated Services Codepoint) sont utilisés. Il y a seulement 64 valeurs de DSCP possibles, mais il n'y a pas une telle limite au nombre des PHB. Dans un domaine réseau donné, il y a une transposition définie localement entre les valeurs de DSCP et les PHB. Les PHB normalisés recommandent une transposition en DSCP, mais les opérateurs de réseau peuvent choisir d'autres transpositions.

Dans certains cas, il est nécessaire ou désirable d'identifier un PHB particulier dans un message de protocole, tel qu'un message de négociation de gestion de bande passante ou de choix de chemin, en particulier lorsque de tels messages passent entre des domaines de gestion. Des exemples sur lesquels des travaux sont en cours portent sur la communication entre des courtiers de bande passante, et sur la prise en charge de diffserv par MPLS.

Dans certains cas, ce qui doit être identifié n'est pas un PHB individuel, mais un ensemble de PHB. Par exemple, un ensemble de PHB qui doivent suivre le même chemin physique pour empêcher un réarrangement. Une instance en est l'ensemble des trois PHB qui appartiennent à une seule classe de transmission assurée, tels que les PHB AF11, AF12 et AF13 [RFC 2597].

Le présent document définit un codage binaire pour identifier de façon univoque les PHB et/ou les ensembles de PHB dans les messages de protocole. Ce codage NE DOIT PAS être utilisé lorsque une telle identification est requise.

Le présent document remplace la RFC 2836, qui omettait la prise en compte des codets de sélecteur de classe.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

1.1	Scénarios d'utilisation

Il est prévu que les services Diffserv soient pris en charge par des technologies sous-jacentes diverses qu'on appelle de façon générique "couche de liaison" pour les besoins de l'exposé. Pour le transport des paquets IP, certaines de ces couches de liaison utilisent des connexions ou connexions logiques où le comportement de transmission pris en charge par chaque appareil de couche de liaison est une propriété de la connexion. En particulier, au sein du domaine de la couche de liaison, chaque nœud de couche de liaison va programmer le trafic selon la connexion sur laquelle le trafic est transporté. Des exemples de telles "couches de liaison" incluent ATM et MPLS.

Pour une prise en charge efficace de diffserv sur ces couches de liaison, un modèle est que différents agrégats de comportement (BA, Behavior Aggregate) (ou ensembles d'agrégats de comportement) soient transportés sur différentes connexions de sorte qu'il leur soit alloué des comportements de transmission différents (et appropriés) à l'intérieur du nuage de la couche de liaison. Lorsque ces connexions sont établies de façon dynamique pour le transport de trafic diffserv, il est très utile de communiquer au moment de l'établissement de la connexion quel ou quels comportements de transmission sont à allouer à chaque connexion par l'appareil de couche de liaison, de façon à ce que les BA transportés rencontrent un comportement de transmission cohérent à l'intérieur du nuage de la couche de liaison. Cela peut être réalisé en incluant dans les messages de signalisation de l'établissement de la connexion le codage du PHB ou de l'ensemble de PHB correspondant, comme défini dans le présent document. Les détails de l'utilisation proposée des codages de PHB par des protocoles de distribution d'étiquettes MPLS (RSVP et LDP) pour la prise en charge de Diff-Serv sur MPLS, se trouvent dans [RFC3270].

Dans une autre approche, le forum ATM a une exigence pour indiquer les traitements de qualité de service IP désirée dans la signalisation ATM, de sorte que les commutateurs ATM puissent aussi bien prendre en charge le service désiré que le sont les transmetteurs IP. Pour ce faire le forum ATM a défini un nouvel élément d'information d'établissement d'appel de circuit virtuel qui va porter les codes d'identification de PHB (bien qu'il puisse être généralisé pour faire plus si nécessaire).

2.	Codage

Les PHB et les ensembles de PHB sont codés dans un champ binaire non signé de 16 bits.

Le champ de 16 bits est arrangé comme suit :

Cas 1 : les PHB définis par action de normalisation, conformément à la [RFC 2474].

Le codage pour un seul PHB est la valeur de DSCP recommandée pour ce PHB, justifié à gauche dans le champ de 16 bits, avec les bits 6 à 15 mis à zéro. Noter que la valeur de DSCP recommandée DOIT être utilisée, même si le réseau en question a choisi une transposition différente.

Le codage pour un ensemble de PHB est celui qui est le plus petit numériquement dans l'ensemble des codages pour les divers PHB de l'ensemble, avec le bit 14 mis à 1. (Donc pour les PHB AF1x, le codage est celui du PHB AF11, avec le bit 14 mis à 1.)

         0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |         DSCP          | 0   0   0   0   0   0   0   0   X   0 |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Cas 2 : les PHB qui ne sont pas définis par action de normalisation, c'est-à-dire, expérimentaux ou d'utilisation locale, comme permis par la [RFC 2474]. Dans ce cas, un code arbitraire d'identification de PHB de 11 bits, alloué par l'IANA, est placé justifié à gauche dans le champ de 16 bits. Le bit 15 est mis à 1, et le bit 14 est à zéro pour un seul PHB ou à 1 pour un ensemble de PHB. Les bits 12 et 13 sont à zéro.

         0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |      code d'identification de PHB             | 0   0   X   1 |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Les bits 12 et 13 sont réservés pour l'expansion des codes d'identification de PHB, ou pour d'autres utilisations, dans un futur encore indéterminé.

Dans les deux cas, lorsque un seul PHBID est utilisé pour identifier un ensemble de PHB (c'est-à-dire que le bit 14 est mis à 1) cet ensemble de PHB DOIT constituer une classe de programmation de PHB (c'est-à-dire, utiliser les PHB de cet ensemble NE DOIT PAS causer de réarrangement de trafic intra microflux lorsque des PHB différents de l'ensemble sont appliqués au trafic dans le même microflux). L'ensemble des PHB AF1x [RFC 2597] est un exemple de classe de programmation de PHB. Les ensembles de PHB qui ne constituent pas une classe de programmation de PHB peuvent être identifiés en utilisant plus d'un PHBID.

3.	Signalisation des codets de sélecteur de classe

La [RFC 2474] définit les huit valeurs de codets DS de la forme "xxx000" (où x peut être '0' ou '1') des codets de sélecteur de classe. Le codet 000000 est la valeur de DSCP recommandée pour le PHB par défaut, et donc le cas 1 de PHBID construit à partir de ce codet est utilisé pour signaler le PHB par défaut (voir la Section 2 ci-dessus).

Pour des raisons pratiques et de cohérence avec le fonctionnement des réseaux qui emploient la préséance IP de la [RFC  1812], le format des PHBID du cas 1 construits à partir des sept autres codets de sélecteur de classe peut aussi être utilisé pour signaler des PHB. Dans chaque cas, le PHB signalé par un tel PHBID est le PHB en lequel est transposé le codé de sélecteur de classe incorporé (ou la valeur de préséance IP qui lui correspond dans les domaines non diffserv) dans le réseau du receveur. Noter que des réseaux différents vont employer des transpositions différentes ; voir à la Section 4 de la [RFC 2474] un exposé plus complet de cette question.

Toute utilisation spécifiée de PHBID DEVRAIT permettre l'utilisation des huit PHBID du cas 1 construits à partir des codets de sélecteur de classe.

4.	Considérations relatives à l'IANA

Il est demandé à l'IANA de créer un nouveau registre d'allocation pour les "codes d'identification de comportements par bond", allouant initialement des valeurs dans la gamme de 0 à 4095 en décimal.

L'allocation des valeurs dans ce champ exige :
-	l'identité de l'allocataire,
-	une brève description du nouveau PHB, avec suffisamment de précisions pour le distinguer des PHB existants normalisés et non normalisés. Dans le cas d'un ensemble de PHB, cette description devrait couvrir tous les PHB de l'ensemble.
-	une référence à un document stable qui décrit le PHB en détails.

Durant la première année d'existence de ce registre, il est demandé à l'IANA de communiquer toutes les demandes au groupe de travail diffserv de l'IETF pour examen. Ensuite, les demandes devraient être revues par les directeurs de la zone Transport de l'IETF ou par un expert désigné par eux.

Si le nombre d'allocations commence à approcher 4096, les directeurs de la zone Transport devraient être alertés.

5.	Considérations pour la sécurité

Ce codage ne soulève par lui-même pas de problème de sécurité. Cependant, les utilisateurs de ce codage devraient considérer que la modification d'un code d'identification de PHB peut constituer un vol ou déni de service, de sorte que les protocoles qui utilisent ce codage doivent être adéquatement protégés.

La simple signalisation d'un PHBID NE DEVRAIT PAS être suffisante pour assurer à l'envoyeur l'accès à un PHB qu'il ne serait pas par ailleurs capable d'utiliser. Dans les cas où cela poserait un problème, les receveurs DEVRAIENT traiter les PHBID reçus comme des demandes de service, et utiliser la politique locale pour déterminer s'il faut accorder ou refuser de telles demandes.

Changements par rapport à la RFC 2836

La [RFC 2836] ne prenait pas en compte les codets de sélecteur de classe, qui sont couverts par la section 3 du présent document. Un éclaircissement a été ajouté à la fin de la section 2 pour le cas des classes de programmation de PHB. Le second paragraphe de la section 5 a été ajouté.

Remerciements

Des commentaires utiles ont été faits par les membres du groupe de travail Diffserv de l'IETF.

Références

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

[RFC2474]	K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS Field) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ par RFC3168, RFC3260) (P.S.)

[RFC2475]	S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang et W. Weiss, "Architecture pour services différenciés", décembre  1998. (MàJ par RFC3260)

[RFC2597]	J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Groupe PHB Transmission assurée", juin 1999. (MàJ par RFC3260) (P.S.)

[RFC2836]	S. Brim, B. Carpenter, F. Le Faucheur, "Codes d'identification de comportement par bond", mai 2000. (Obsolète, voir RFC3140) (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.)

Adresse des auteurs

David L. Black	Scott W. Brim	
EMC Corporation	146 Honness Lane	
42 South St.	Ithaca, NY 14850	
Hopkinton, MA   01748	USA	
mél : black_david@emc.com	mél : sbrim@cisco.com	

Brian E. Carpenter	Francois Le Faucheur	
IBM	Cisco Systems	
c/o iCAIR	Petra B - Les Lucioles	
Suite 150	291 rue Albert Caquot	
1890 Maple Avenue	06560 Valbonne	
Evanston, IL 60201	France	
USA	mél : flefauch@cisco.com	
mél : brian@icair.org		

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 pourrait ê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 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.

Déclaration complète de droits de reproduction

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

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs 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'éditeur des RFC est actuellement fourni par la Internet Society.