Groupe de travail Réseau	D. Grossman	
Request for Comments : 3260	Motorola, Inc.	
RFC mises à jour : 2474, 2475, 2597	avril 2002	
Catégorie : Information	Traduction Claude Brière de L’Isle	

Nouvelle terminologie et précisions pour Diffserv

Statut du présent mémoire

Le présent mémoire fournit des informations pour la communauté de l’Internet. Il ne spécifie aucune sorte de norme de l’Internet. 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 mémoire rassemble les accords des groupes de travail Diffserv concernant une nouvelle terminologie améliorée, et apporte quelques éclaircissements techniques mineurs. Il est destiné à mettre à jour les RFC 2474, 2475 et 2597. Lorsque les RFC 2474 et 2597 avanceront sur la voie de la normalisation, et que la RFC 2475 sera mise à jour, il est prévu que les révisions du présent mémoire y seront incorporées et que le présent mémoire sera rendu obsolète par les nouvelles RFC.

1.	Introduction

Avec l’évolution du travail sur Diffserv, plusieurs cas se sont trouvés où il a été nécessaire de créer une terminologie ou de redéfinir des notions de RFC Diffserv en cours de normalisation. Quelques éclaircissements techniques mineurs ont également été trouvés nécessaires. Le présent mémoire a été élaboré pour fixer un consensus de groupe, plutôt que d’essayer de réviser les RFC de base et de les recycler comme proposition de norme. Il met à jour des parties des RFC 2474, RFC 2475 et RFC 2597. La RFC 2598 a été rendue obsolète par la RFC 3246, et les éclaircissements approuvés par le groupe ont été incorporés dans cette révision.

2.	Terminologie en rapport avec les accords de niveau de service

L’architecture Diffserv [2] utilise le terme de "accord de niveau de service" (SLA, Service Level Agreement) pour décrire le "contrat de service ... qui spécifie le service de transmission que devrait recevoir un consommateur". Le SLA peut inclure des règles de conditionnement de trafic qui constituent (au moins en partie) un accord de conditionnement de trafic (TCA, Traffic Conditioning Agreement). Un TCA est "un accord qui spécifie des règles de classement et  toutes les règles correspondantes de profils et mesures de trafic, de marquage, d’élimination et/ou formatage qui sont à appliquer...."

Avec l’évolution des travaux dans Diffserv (aussi bien que dans le groupe de travail Policy [6]), on en est venu à penser que la notion d’un "accord" impliquait des considérations de tarification, de contractualisation, ou autre de nature commerciale, autant que celles strictement techniques. Il pourrait aussi y avoir d’autres considérations techniques dans un tel accord (par exemple, la disponibilité de service) qui ne sont pas traitées par Diffserv. Il a donc été convenu que les notions de SLA et de TCA seraient prises dans le sens le plus large, et qu’une nouvelle terminologie serait utilisée pour décrire les éléments de service et de conditionnement du trafic qui sont traités par Diffserv.

-	Une spécification de niveau de service (SLS, Service Level Specification) est un ensemble de paramètres et de leurs valeurs qui définissent le service offert à un flux de trafic par un domaine DS.

-	Une spécification de conditionnement de service (TCS, Traffic Conditioning Specification) est un ensemble de paramètres et de leurs valeurs qui spécifient un ensemble de règles de classement et un profil de trafic. Un TCS est un élément constitutif d’un SLS.

Noter que la définition de "flux de trafic" est inchangée par rapport à la RFC 2475. Un flux de trafic peut être un microflux individuel ou un groupe de microflux (c’est-à-dire, dans un domaine DS de source ou de destination) ou il peut être un BA. Et donc, un SLS peut s’appliquer dans le domaine DS de source ou de destination à un seul microflux ou à un groupe de microflux, aussi bien qu’à un BA dans tout domaine DS.

Noter aussi que la définition d’une "politique d’approvisionnement de service" est inchangé depuis la RFC 2475. La RFC 2475 définit une "politique d’approvisionnement de service comme une politique qui définit comment les conditionneurs de trafic sont configurés sur les nœuds frontières DS et comment les flux de trafic sont transposés en agrégats de comportement DS pour accomplir une gamme de services." Conformément à une définition donnée dans la RFC 3198 [6], une politique est "...un ensemble de règles pour administrer, gérer, et contrôler l’accès aux ressources du réseau". Donc, la relation entre un SLS et une politique d’approvisionnement de service est que cette dernière est, en partie, l’ensemble des règles qui expriment les paramètres et la gamme des valeurs qui peuvent être dans la première.

Noter de plus que cette définition est plus restrictive que celle de la RFC 3198.

3.	Usage de groupe PHB

La RFC 2475 définit un groupe de comportement par bond (PHB, Per-hop behavior) comme étant :

"un ensemble de un ou plusieurs PHB qui ne peut être spécifié et mis en œuvre de façon significative que simultanément, du fait d’une contrainte commune s’appliquant à tous les PHB dans l’ensemble tel qu’un service de file d’attente ou une politique de gestion de file d’attente. Un groupe de PHB fournit un bloc de construction de service qui permet de spécifier ensemble un ensemble de comportements de transmission (par exemple, quatre priorités d’abandon). Un seul PHB est un cas particulier de groupe de PHB."

Un groupe de PHB en cours de normalisation est défini dans la RFC 2597 [3], "Groupe PHB de transmission assurée". Transmission assurée (AF) est un type de comportement de transmission avec un certain niveau alloué de ressources de mise en file d’attente et trois priorités d’abandon. Un groupe de PHB AF consiste en trois PHB, et utilise trois codets Diffserv (DSCP, Diffserv Codepoint).

La RFC 2597 définit douze DSCP, correspondant à quatre classes AF indépendantes. Les classes AF classes sont désignées comme AF1x, AF2x, AF3x, etF4x (où x' est 1, 2, ou 3 pour représenter la priorité d’abandon). Chaque classe AF est une instance d’un groupe de PHB AF.

Une certaine confusion s’est exprimée dans la RFC 2597 qui se réfère aux quatre classes AF avec leurs trois priorités d’abandon comme faisant partie d’un seul groupe de PHB. Cependant, comme chaque classe AF fonctionne entièrement indépendamment des autres, (et donc qu’il n’y a pas de contrainte commune parmi les classes AF comme il y en a entre les priorités d’abandon au sein d’une classe AF) cette utilisation n’est pas cohérente avec la RFC 2475. L’incohérence existe pour des raisons historiques et sera supprimée dans de futures révisions de la spécification AF. On devrait maintenant comprendre que AF est un _type_ de groupe de PHB, et que chaque classe AF est une _instance_ du type AF.

Les auteurs de nouvelles spécifications de PHB devraient veiller à suivre la définition de la RFC 2475 de groupe de PHB. La RFC 2475 n’interdit pas aux nouvelles spécifications de PHB d’allouer suffisamment de DSCP pour représenter plusieurs instances indépendantes de leur groupe de PHB. Cependant, un tel ensemble de DSCP ne doit pas être désigné comme un seul groupe de PHB.

4.	Définition du champ DS

Diffserv utilise six bits de l’en-tête IPV4 ou IPV6 pour convoyer le codet Diffserv (DSCP), qui sélectionne un PHB. La RFC 2474 tente de renommer l’octet de TOS de l’en-tête IPV4, et l’octet de classe de trafic de l’en-tête IPV6, respectivement, dans le champ DS. Le champ DS a six bits de codet Diffserv et deux bits "actuellement inutilisés".

Il a été souligné que cela conduit à des incohérences et des ambiguïtés. En particulier, les bits "actuellement inutilisés" (CU, Currently Unused) du champ DS n’ont pas été alloués à Diffserv, et à la suite de la publication de la RFC 2474, ils ont été alloués à la notification explicite d’encombrement, comme défini dans la RFC 3168 [4]. Dans le texte actuel, un DSCP est, selon le contexte, soit un codage qui choisit un PHB soit un sous-champ dans le champ DS qui contient ce codage.

Le présent texte est aussi non conforme au BCP 37, Lignes directrices de l’IANA pour l’allocation de valeurs dans le protocole Internet et les en-têtes qui s’y rapportent [5]. Le champ Type-of-Service (TOS) de IPV4 et le champ classe de trafic IPV6 sont subrogés par le champ DS de 6 bits et un champ CU de 2 bits. L’IANA alloue des valeurs dans le champ DS suivant la section Considérations relatives à l’IANA dans la RFC 2474, comme précisé à la section 8 du présent mémoire.

Le consensus du groupe de travail DiffServ est que le BCP 37 réaffirme correctement la structure des anciens champs TOS et classe de trafic.

Donc, pour l’utilisation des documents futurs, y compris la prochaine mise à jour de la RFC 2474, les définitions suivantes devraient s’appliquer :

-	Le champ Differentiated Services Field (DSField) est les six bits de plus fort poids de l’octet (ancien) TOS IPV4 ou l’octet (ancien) de classe de trafic IPV6.

-	Le codet Differentiated Services Codepoint (DSCP) est une valeur qui est codée dans le champ DS, et que chaque nœud DS DOIT utiliser pour choisir le PHB qui est à appliquer par chaque paquet qu’il transmet.

Les deux bits de moindre poids de l’octet TOS IPV4 et de l’octet Classe de trafic IPV6 ne sont pas utilisés par Diffserv.

Lorsque la RFC 2474 sera mise à jour, il faudra prendre en considération le changement de désignation de "actuellement inutilisé (CU)" en "notification explicite d’encombrement (ECN)" et faire référence à la RFC 3168 (ou son successeur).

La mise à jour devrait aussi faire référence au BCP 37.

5.	Agrégats ordonnés et classes de planification de PHB

Les travaux sur la prise en charge de Diffserv par les routeurs à commutation d’étiquette (LSR, Label Switched Router) MPLS ont conduit à la réalisation qu’un concept était nécessaire dans Difffserv pour rendre la notion d’un ensemble de BA avec une contrainte commune d’ordre. Cela s’applique actuellement aux agrégats de comportement AF, car un nœud DS peut ne pas réordonner les paquets du même microflux si ils appartiennent à la même classe AF. Cela empêcherait, par exemple, un LSR MPLS, qui serait aussi un nœud DS, de faire la discrimination entre des paquets d’un agrégat de comportement (BA, Behavior Aggregate) AF sur la base de la priorité d’abandon et de transmettre des paquets de la même classe AF mais de priorité d’abandon différente sur des LSP différents. Les nouveaux termes suivants sont définis.

Classe de planification PHB (PHB Scheduling Class) : Un groupe de PHB pour lequel une contrainte commune est que l’ordre des paquets qui appartiennent au même microflux doit au moins être préservé.

Agrégat ordonné (OA, Ordered Aggregate) : Ensemble d’agrégats de comportement qui partagent une contrainte d’ordre. L’ensemble des PHB qui sont appliqués à cet ensemble d’agrégats de comportement constitue une classe de planification de PHB.

6.	DSCP inconnus/incorrectement transposés

Plusieurs développeurs ont souligné des ambiguïtés ou des conflits dans les RFC Diffserv concernant le comportement d’un nœud DS qui reçoit un paquet avec un DSCP qu’il ne comprend pas.

La RFC 2475 dit :
"Les nœuds d’entrée doivent conditionner tout le trafic entrant autre de façon à s’assurer que les codets DS sont acceptables ; les paquets qui se trouvent avoir des codets inacceptables doivent soit être éliminés soit avoir leurs codets DS modifiés à des valeurs acceptables avant d’être transmis. Par exemple, un nœud d’entrés qui reçoit du trafic d’un domaine avec lequel n’existe aucun accord de service amélioré peut régler le codet DS au codet de PHB par défaut [DSFIELD]."

D’un autre côté, la RFC 2474 dit :
"Les paquets reçus avec un codet non reconnu DEVRAIENT être transmis comme si ils étaient marqués pour le comportement par défaut (voir la Section 4), et leurs codets ne devraient pas être changés."

La RFC 2474 est principalement concernée par les nœuds intérieurs à DS. Cependant, ce comportement pourrait aussi être adopté par des nœuds d’entrée de DS APRÈS le conditionnement de trafic exigé par la RFC 2475 (auquel cas, un DSCP non reconnu ne surviendrait que dans le cas d’une mauvaise configuration). Si un paquet arrives avec un DSCP qui n’avait pas été explicitement transposé en une PHB particulier, il devrait être traité de la même façon qu’un paquet marqué pour la comportement par défaut. Les solutions de remplacement étaient de lui allouer un autre PHB, ce qui pourrait résulter en une mauvaise allocation des ressources provisionnées, ou de l’abandonner. Ce sont les seules solutions de remplacement dans le cadre de la RFC 2474. Aucune de ces solutions n’a été considérée comme souhaitable. Il y a eu des discussions sur un PHB qui recevrait une plus mauvais service que celui par défaut ; cela pourrait être une meilleure solution. Et donc l’exigence a été "DEVRAIT" plutôt que "DEVRA".

L’intention de la RFC 2475 concernait clairement les nœuds d’entrée DS, ou plus précisément, la fonction de conditionnement du trafic entrant. C’est un autre contexte dans lequel le "DEVRAIT" de la RFC 2474 donne la souplesse de faire ce qui était l’intention du groupe. Il n’est pas souhaitable de torturer ainsi le sens des mots.

Donc, la déclaration de la RFC 2474 sera précisée pour indiquer qu’il n’est pas prévu d’appliquer la fonction de conditionnement du trafic entrant à un nœud d’entrée DS, et faire une référence croisée à la RFC 2475 pour ce cas.

Il y avait une question similaire, qui s’est manifestée avec la première incarnation de la transmission expédiée (EF, Expedited Forwarding). La RFC 2598 déclare :

Pour se protéger contre les attaques de déni de service, la bordure d’un domaine DS DOIT strictement réguler tous les paquets marqués EF à un débit négocié avec le domaine amont adjacent. (Ce débit doit être ≤ au débit de PHB EF configuré.) Les paquets en excès du débit négocié DOIVENT être abandonnés. Si deux domaines adjacents n’ont pas négocié un débit d’EF, le domaine aval DOIT utiliser le débit 0 (c’est-à-dire, abandonner tous les paquets marqués EF).

Le problème est soulevé dans le cas d’une mauvaise configuration ou de problèmes d’acheminement. Un nœud DS de sortie à la bordure d’un domaine DS transmet des paquets à un nœud DS d’entrée à la bordure d’un autre domaine DS. Ces paquets sont marqués avec un DSCP que le nœud de sortie comprend comme se transposant en EF, mais que le nœud d’entrée ne reconnaît pas. La déclaration de la RFC 2475 semblerait s’appliquer à ce cas. La RFC 3246 [7] éclaircit ce point.

7.	Pas de rétro-compatibilité avec la RFC 1349
Au moins un développeur a exprimé sa confusion quant à la relation entre le champ DS, tel que défini dans la RFC 2474, et l’utilisation des bits de TOS, tels que décrits dans la RFC 1349. L’utilisation de la RFC 1349 était destinée à interagir avec les extensions d’OSPF dans la RFC 1247. Celles-ci n’ont jamais été largement développées et donc retirées de la norme lors de la publication du STD 54, RFC 2328. Le traitement des bits de TOS est décrit comme une exigence dans les RFC 1812 [8], RFC 1122 [9] et RFC 1123 [10]. La RFC 2474 déclare :

"Il n’est fait aucune tentative pour maintenir la rétrocompatibilité avec les bits de "DTR" ou de TOS de l’octet de TOS IPv4, comme défini dans la [RFC791]."

De plus, la RFC 2474 rend obsolète la RFC 1349 par décision de l’IESG. Pour être complet, lorsque la RFC 2474 sera mise à jour, la phrase devrait se lire :

"Il n’est fait aucune tentative pour maintenir la rétrocompatibilité avec les bits "DTR/MBZ" ou TOS de l’octet de TOS IPv4, comme défini dans les [RFC791] et [RFC1349]. Cela implique que le traitement du bit de TOS comme décrit dans les [RFC1812], [RFC1122] et [RFC1123] est aussi rendu obsolète par le présent mémoire. Voir aussi la [RFC2780]."

8.	Considérations relatives à l’IANA

L’IANA a demandé des éclaircissements sur un point de la RFC 2474, concernant l’enregistrement des DSCP d’utilisation expérimentale/locale. Lorsque la RFC 2474 sera révisée, on devrait ajouter ce qui suit à la Section 6:

Il est demandé à l’IANA d’entretenir un registre des valeurs de DSCP RECOMMANDÉES allouées par des actions de normalisation. Les valeurs EXP/LU ne sont pas à enregistrer.

9.	Résumé des changements en cours

Les RFC en cours de normalisation et pour information suivantes seront mises à jour pour refléter les points d’accord rassemblés dans le présent mémoire. Il est prévu que ces mises à jour surviennent lorsque chaque RFC en cours de normalisation progressera vers le statut de projet de norme (ou si quelque question survient qui force le recyclage en proposition de norme). La mise à jour de la RFC 2475 est prévue à peu près au même moment que celle de la RFC 2474. Ces mises à jour rendront le présent mémoire aussi obsolète.

RFC 2474 : révise la définition du champ DS. Précise que la transmission par défaut suggérée dans le cas d’un DSCP non reconnu n’est pas destinée à s’appliquer au conditionnement d’entrée dans les nœuds d’entrée DS. Précise les effets sur les RFC 1349 et RFC 1812. Précise que seuls les DSCP RECOMMANDÉS alloués par action de normalisation sont à enregistrer par IANA.

RFC 2475 : révise la définition du champ DS. Ajoute les définitions de SLS et TCS. Met à jour le corps du document pour une utilisation appropriée de SLS et TCS. Ajout des définitions de classe de planification de PHB et d’agrégat ordonné.

RFC 2497 : révisée pour refléter l’interprétation selon laquelle les classes AF sont des instances du groupe de PHB AF, et ne sont pas collectivement un groupe de PHB.

De plus, la RFC 3246 [7] a été ajoutée en référence à la RFC 2475 dans la section des considérations pour la sécurité pour couvrir le cas d’un nœud DS en sortie qui reçoit un DSCP non reconnu qui se transpose en EF dans le nœud DS d’entrée.

10.	Considérations pour la sécurité

Les considérations pour la sécurité sont traitées dans la RFC 2475.

Remerciements

Le présent mémoire a reçu l’agrément du groupe de travail Diffserv. De nombreux individus ont contribué aux discussions sur la liste de diffusion Diffserv et dans les réunions. Les présidents de Diffserv étaient Brian Carpenter et Kathie Nichols. Ceux qui ont le plus activement participé à ces discussions étaient Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim, Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John Schnizlein, Francois Le Faucheur, et Fred Baker. Mike Ayers, Mike Heard et Andrea Westerinen ont fourni de précieux commentaires rédactionnels.

Références normatives

[1]	K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Differentiated Services (DS Field) dans les en-têtes IPv4 et IPv6", RFC 2474, décembre 1998.

[2]	S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang et W. Weiss, "Architecture pour Services différenciés", RFC 2475, décembre 1998.

[3]	J. Heinanen, F. Baker, W. Weiss et J. Wrocklawski, "Groupe de PHB à transmission assurée", RFC 2597, juin 1999.

[4]	K. Ramakrishnan, S. Floyd et D. Black "Ajout de la Notification explicite d’encombrement (ECN) à IP", RFC 3168, septembre 2001.

[5]	S. Bradner et V. Paxon, "Lignes directrices de l’IANA pour l’allocation de valeurs dans le protocole Internet et les en-têtes qui s’y rapportent", BCP 37, RFC2780, mars 2000.

[6]	A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry et S. Waldbusser, "Terminologie pour la gestion fondée sur une politique", RFC 3198, novembre 2001.

[7]	B. Davie, A. Charny, F. Baker, J.C.R. Bennett, K. Benson, J. Le Boudec, A. Chiu, W. Courtney, S. Cavari, V. Firoiu, C. Kalmanek, K. Ramakrishnam et D. Stiliadis, "PHB de transmission expédiée (comportement par bond)", RFC 3246, mars 2002.

[8]	F. Baker, "Exigences pour les routeurs IP version 4", RFC 1812, juin 1995.

[9]	R. Braden, "Exigences pour les hôtes Internet – Couches de communications", STD 3, RFC 1122, octobre 1989.

[10]	R. Braden, "Exigences pour les hôtes Internet  -- Application et prise en charge", STD 3, RFC 1123, octobre 1989.

Adresse de l’auteur

Dan Grossman
Motorola, Inc.
20 Cabot Blvd.
Mansfield, MA 02048
mèl : dan@dma.isg.mot.com

Déclaration complète de copyright

Copyright (C) The Internet Society (2002). 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.

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.

Remerciement

Le financement de la fonction d’édition des RFC est fourni par l’IETF