Groupe de travail Réseau	J. Korhonen, éditeur, Nokia Siemens Networks	
Request for Comments: 5624	H. Tschofenig, Nokia Siemens Networks	
Catégorie : Sur la voie de la normalisation	E. Davies, Folly Consulting	
Traduction Claude Brière de L'Isle	août 2009	

Paramètres de qualité de service à utiliser avec Diameter

Résumé
Le présent document définit un certain nombre de paramètres de qualité de service (QS) qui peuvent être réutilisés pour porter les informations de QS au sein de Diameter.

Les informations de QS définies incluent des paramètres de trafic de données pour décrire un filtre de baquet de jetons, un paramètre de bande passante, et un objet de classe de comportement par bond.

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

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 
Table des matières
1. Introduction	1
2. Terminologie	2
3. Codage des paramètres de QS	2
3.1 AVP TMOD-1	2
3.2 AVP TMOD-2	3
3.3 AVP Bandwidth	3
3.4 AVP PHB-Class	3
4. Extensibilité	4
5. Considérations relatives à l'IANA	4
5.1 Codes d'AVP	4
5.2 Profil de QS	5
6. Considérations sur la sécurité	5
7. Remerciements	5
8. Références	6
8.1 Références normatives	6
8.2 Références pour information	6
Appendice A. Fragment de Code ABNF	6
Adresse des auteurs	7

 	1.	Introduction

Le présent document définit un certain nombre de paramètres de qualité de service (QS) qui peuvent être réutilisés pour porter des informations de QS au sein du protocole Diameter [RFC3588]. L'ensemble actuel de paramètres de QS défini dans le présent document est un sous ensemble central déterminé comme étant utile pour une large gamme d'applications. Des paramètres supplémentaires pourront être définis dans de futurs documents lorsque le besoin s'en fera sentir et feront l'objet d'études ultérieures. Les paramètres sont définis comme des paires d'attribut-valeur (AVP) codées de Diameter, qui sont décrits en utilisant une version modifiée du format Backus-Naur augmenté (ABNF) voir la [RFC3588]. Les types de données sont aussi tirés de la [RFC3588].

Les AVP de modèle de trafic (TMOD) sont des contenants consistant en quatre AVP et donnent un moyen pour décrire la source de trafic :
o	débit de jetons (r)
o	profondeur de baquet (b)
o	débit de trafic de pointe (p)
o	unité minimum régulée (m)
o	taille maximum de paquet (M)

Le codage des AVP <TMOD-1> et <TMOD-2> se trouve dans les paragraphes 3.1 et 3.2. La sémantique de ces deux AVP est décrite au paragraphe 3.1 de la [RFC2210] et au paragraphe 3.6 de la [RFC2215].

L'AVP <TMOD-2> est, par exemple, nécessaire pour certaines applications DiffServ.

On suppose normalement que le trafic DiffServ à transmission accélérée (EF, expedited forwarding) est formaté à la sortie par un seul débit de baquet de jetons. Donc, un seul paramètre TMOD est suffisant pour signaler le trafic EF DiffServ. Cependant, pour le trafic DiffServ en transmission assurée (AF, assured forwarding) deux ensembles de paramètres de baquet de jetons sont nécessaires : un baquet de jetons pour le trafic moyen et un baquet de jetons pour le trafic de salve. La [RFC2697] définit un marqueur à trois couleurs d'un seul taux (srTCM, Single Rate Three Color Marker) qui mesure un flux de trafic et marque ses paquets selon trois paramètres de trafic -- taux d'informations engagé (CIR, Committed Information Rate) taille de salve engagée (CBS, Committed Burst Size) et taille de salve en excès (EBS, Excess Burst Size) -- comme étant vert, jaune, ou rouge. Un paquet est marqué vert si il n'excède pas la CBS, jaune si il excède la CBS mais pas l'EBS, et rouge autrement. La [RFC2697] définit des procédures spécifiques utilisant deux baquets de jetons qui s'écoulent au même taux. Donc, deux AVP TMOD sont suffisantes pour distinguer trois niveaux de préséance d'élimination. Un exemple est aussi décrit dans l'appendice de la [RFC2597].

Les réservations de ressources pourraient se référer à un processeur de paquet avec un comportement par bond (PHB, per hop behaviour) DiffServ particulier (en utilisant l'AVP <PHB-Class>). Une description générique de l'architecture DiffServ se trouve dans la [RFC2475], et le champ Services différenciés est décrit à la Section 3 de la [RFC2474]. Une mise à jour de la terminologie se trouve dans la [RFC3260]. Le comportement par bond normalisé est, par exemple, décrit dans la [RFC2597] ("Groupe de PHB Transmission assurée") et dans la [RFC3246] ("Comportement par bond de transmission accélérée").

Les paramètres susmentionnés sont destinés à prendre en charge les fonctions de base de services intégrés et différenciés dans le réseau. Des paramètres supplémentaires pourront être définis et normalisés si c'est exigé pour prendre en charge des services spécifiques à l'avenir.

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

 	3.	Codage des paramètres de QS
 	3.1	AVP TMOD-1
L'AVP TMOD-1 est obtenue des [RFC2210] et [RFC2215]. La structure de l'AVP est comme suit :

TMOD-1  ::= <En-tête d'AVP : 495 >
            { Token-Rate }
            { Bucket-Depth }
            { Peak-Traffic-Rate }
            { Minimum-Policed-Unit }
            { Maximum-Packet-Size }

 	3.1.1	AVP Token-Rate
L'AVP Token-Rate (code d'AVP 496) est du type Float32.

 	3.1.2	AVP Bucket-Depth
L'AVP Bucket-Depth (code d'AVP 497) est du type Float32.

 	3.1.3	AVP Peak-Traffic-Rate
L'AVP Peak-Traffic-Rate (code d'AVP 498) est du type Float32.

 	3.1.4	AVP Minimum-Policed-Unit
L'AVP Minimum-Policed-Unit (code d'AVP 499) est du type Unsigned32.

 	3.1.5	AVP Maximum-Packet-Size
L'AVP Maximum-Packet-Size (code d'AVP 500) est du type Unsigned32.

 	3.2	AVP TMOD-2
Une description de la sémantique des valeurs de paramètre se trouve dans la [RFC2215]. Le codage de l'AVP TMOD-2 est comme suit :
TMOD-2  ::= <En-tête d'AVP : 501 >
                 { Token-Rate }
                 { Bucket-Depth }
                 { Peak-Traffic-Rate }
                 { Minimum-Policed-Unit }
                 { Maximum-Packet-Size }

 	3.3	AVP Bandwidth
L'AVP Bandwidth (bande passante) (code d'AVP 502) est du type Float32 et est mesurée en octets de datagrammes IP par seconde. L'AVP Bandwidth représente une description simplifiée du réglage de TMOD suivant par lequel le débit de jetons (r) = taux de trafic de pointe (p), la profondeur de baquet (b) = large, et l'unité minimum régulée (m) = large, quand seule la bande passante doit être exprimée.

 	3.4	AVP PHB-Class
L'AVP PHB-Class (classe de comportement par bond) (code d'AVP 503) est du type Unsigned32.

Une description de la sémantique des valeurs de paramètre se trouve dans la [RFC3140]. Les registres nécessaires pour l'usage de la [RFC3140] existent déjà et donc un nouveau registre n'est pas exigé pour cela. Le codage exige que trois cas soient différenciés. Tous les bits indiqués comme "réservé" DOIVENT être réglés à zero (0).

 	3.4.1	Cas 1 : un seul PHB
Comme prescrit par la [RFC3140], le codage pour un seul PHB est la valeur de codet de services différenciés (DSCP, Differentiated Services Code Point) recommandée pour ce PHB, justifiée à gauche dans le champ de 16 bits avec les bits 6 à 15 réglés à zero.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP      |0 0 0 0 0 0 0 0 0 0|            (Réservé)          |
+-----------+---+---------------+---------------+---------------+

 	3.4.2	Cas 2 : ensemble de PHB
Le codage pour un ensemble de PHB est le plus petit numériquement de l'ensemble des codages des divers PHB de l'ensemble, avec le bit 14 réglé à 1. (Donc, pour les PHB AF1x, le codage est celui du PHB AF11, avec le bit 14 réglé à 1.)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP      |0 0 0 0 0 0 0 0 1 0|            (Réservé)          |
+-----------+---+---------------+---------------+---------------+

 	3.4.3	Cas 3 : utilisation expérimentale ou locale de PHB
Des PHB ne peuvent pas être définis par des actions de normalisation c'est-à-dire, PHB expérimentaux ou d'utilisation locale comme permis par la [RFC2474]. Dans ce cas, un code arbitraire d'identification de PHB de 12 bits, alloué par l'IANA, est justifié à gauche dans le champ de 16 bits. Le bit 15 est réglé à 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.

Les bits 12 et 13 sont réservés pour l'expansion des codes d'identification de PHB ou pour d'autres utilisations futures.

Dans les deux cas, quand un seul PHBID est utilisé pour identifier un ensemble de PHB (c'est-à-dire, quand le bit 14 est réglé à 1) cet ensemble de PHB DOIT constituer une classe de programmation de PHB (c'est-à-dire, l'utilisation de PHB de l'ensemble NE DOIT PAS causer de réorganisation de trafic intra micro flux quand différents PHB de l'ensemble sont appliqués au trafic dans le même micro flux). L'ensemble des PHB AF1x [RFC2597] 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.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code identifiant PHB  |0 0 1 0|            (Réservé)          |
+---------------+-------+-------+---------------+---------------+

 	4.	Extensibilité

Le présent document est conçu en vue de l'extensibilité, étant donné que différentes organisations et groupes sont utilisés pour définir leurs propres paramètres de qualité de service. Le présent document fournit un profil initial de QS avec un ensemble commun de paramètres. Idéalement, ces paramètres devraient être utilisés chaque fois que possible, mais il y a des cas où des paramètres supplémentaires pourraient être nécessaires ou où les paramètres spécifiés dans le présent document sont utilisés avec un sens différent. Dans ce cas, il est conseillé de définir un nouveau profil de QS qui peut consister en nouveaux paramètres en plus des paramètres définis dans ce document ou un ensemble complètement différent de paramètres. Finalement, il est aussi possible d'enregistrer un profil de QS spécifique qui définisse un ensemble spécifique de valeurs de QS plutôt que des paramètres qui devraient être remplis avec des valeurs afin d'être utilisés.

Pour permettre la définition de nouveaux profils de QS, un registre de 8 octets est défini comme un champ qui est représenté par des champs de 4 octets de fabricant et de 4 octets de spécificateur. Le champ de fabricant contient un numéro d'entreprise comme défini dans la [RFC2578], tiré des valeurs tenues par l'IANA dans le registre des numéros d'entreprise.  Si les quatre octets du champ de fabricant sont 0x00000000 (valeur réservée pour l'IANA) alors la valeur dans le champ spécificateur DOIT être enregistrée auprès de l'IANA (voir le paragraphe 5.2). Si le champ de fabricant est autre chose que 0x00000000, la valeur du champ Spécificateur représente une valeur spécifique du fabricant, où l'allocation est de la responsabilité de l'entreprise indiquée dans le champ Fabricant.

 	5.	Considérations relatives à l'IANA
 	5.1	Codes d'AVP
L'IANA a alloué des codes d'AVP dans le registre d'espace de noms contrôlé par l'IANA spécifié au paragraphe 11.1.1 de la [RFC3588] pour les AVP suivantes qui sont définies dans le présent document.

Nom d'AVP	Code d'AVP	Paragraphe	Type de données
TMOD-1	495	3.1	Grouped
Token-Rate	496	3.1.1	Float32
Bucket-Depth	497	3.1.2	Float32
Peak-Traffic-Rate	498	3.1.3	Float32
Minimum-Policed-Unit	499	3.1.4	Unsigned32
Maximum-Packet-Size	500	3.1.5	Unsigned32
TMOD-2	501	3.2	Grouped
Bandwidth	502	3.3	Float32
PHB-Class	503	3.4	Unsigned32

 	5.2	Profil de QS
Le profil de QS se réfère à un champ de 64 bits qui est représenté par un champ de fabricant de 4 octets et un spécificateur de 4 octets. Le champ Fabricant indique le type soit comme spécifié par la norme soit comme spécifique du fabricant.

Si les quatre octets du champ Fabricant sont 0x00000000, alors la valeur est spécifiée par la norme et un registre sera créé pour tenir les valeurs de spécificateur de profil de QS. Le champ Spécificateur indique le profil actuel de QS. Selon la valeur demandée, l'action nécessaire pour demander une nouvelle valeur est :
0 à 511 : Action de normalisation
512 à 32767 : Spécification exigée
32768 à 4294967295 : Réservé

L'action de normalisation est exigée pour ajouter, déconseiller, supprimer, ou modifier des valeurs de profil de QS dans la gamme de 0 à 511, et une spécification est exigée pour ajouter, déconseiller, supprimer, ou modifier des valeurs de profil de QS existantes dans la gamme de 512 à 32767.

L'IANA a créé un tel registre et alloué la valeur zéro (0) pour le profil de QS défini dans le présent document.

D'autres profils de QS spécifiques du fabricant peuvent être créés et identifiés avec un numéro d'entreprise tiré du registre de l'IANA créé par la [RFC2578] dans le champ Fabricant, combiné avec une valeur spécifique du fabricant dans le champ Spécificateur. L'allocation des valeurs de spécificateur est de la responsabilité du fabricant.

 	6.	Considérations sur la sécurité

Le présent document ne soulève aucun problème de sécurité car il définit seulement des paramètres de qualité de service et ne décrit pas comment ils sont échangés dans un protocole d'authentification, autorisation, et comptabilité (AAA). Les considérations sur la sécurité sont décrites dans les documents qui utilisent la présente spécification.

 	7.	Remerciements

Les auteurs tiennent à remercier les membres du groupe de travail NSIS Cornelia Kappler, Jerry Ash, Attila Bader, et Dave Oran, les anciens présidents du groupe de travail NSIS John Loughney et Martin Stiemerling, et les anciens directeurs de la zone Transport Allison Mankin et Jon Peterson de leur aide.

Nous tenons à remercier Ken Carlberg, Lars Eggert, Jan Engelhardt, François Le Faucheur, John Loughney, An Nguyen, Dave Oran, James Polk, Martin Dolly, Martin Stiemerling, et Magnus Westerlund de leurs retours concernant certains des paramètres du présent document.

Jerry Ash, Al Morton, Mayutan Arumaithurai, et Xiaoming Fu ont apporté leur aide sur la sémantique de certains paramètres QSPEC.

Nous tenons à remercier Dan Romascanu pour ses commentaires détaillés de relecture de Directeur de zone et Scott Bradner pour sa relecture de directeur de zone Transport. Chris Newman, Adrian Farrel, et Pasi Eronen ont fourni des retours durant la revue de l'IESG.

 	8.	Références
 	8.1	Références normatives

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

[RFC2210]	J. Wroclawski, "Utilisation de RSVP avec les services intégrés de l'IETF", septembre 1997, DOI 10.17487/RFC2210. (P.S.)

[RFC2215]	S. Shenker, J. Wroclawski, "Paramètres généraux de caractérisation pour éléments de réseau à intégration de service", septembre 1997, DOI 10.17487/RFC2215. (P.S.)

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

[RFC2578]	K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure des informations de gestion, version 2 (SMIv2)", avril 1999, DOI 10.17487/RFC2578. (STD0058)

[RFC3140]	D. Black et autres, "Codes d'identification de comportement par bond", juin 2001, DOI 10.17487/RFC3140. (P.S.)

[RFC3588]	P. Calhoun et autres, "Protocole fondé sur Diameter", septembre 2003. (Remplacée par la RFC6733) (P.S.)

 	8.2	Références pour information

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

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

[RFC2697]	J. Heinanen, R. Guerin, "Marqueur de trafic à débit unique à trois couleurs", septembre 1999, DOI 10.17487/RFC2697. (Information)

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

[RFC3260]	D. Grossman, "Nouvelle terminologie et précisions pour Diffserv", avril 2002, DOI 10.17487/RFC3260. (Information)

 	Appendice A. Fragment de Code ABNF

Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du code. Tous droits réservés.

La redistribution et l'utilisation en forme source et binaire, avec ou sans modification, sont permises pourvu que les conditions suivantes soient satisfaites :
o	Les redistributions de code source doivent conserver la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit.
o	Les redistributions en forme binaire doivent reproduire la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit dans la documentation et/ou autres matériaux fournis avec la distribution.
o	Ni le nom de la Internet Society, de l'IETF ou de l'IETF Trust, ni les noms des contributeurs spécifiques, ne peuvent être utilisés pour avaliser ou promouvoir des produits dérivés de ce logiciel sans permission écrite spécifique préalable.

Ce logiciel est fourni par les détenteurs du droit de reproduction et les contributeurs "TEL QUEL" et toutes garanties expresses ou implicites, incluant, sans s'y limiter, les garanties implicites de commercialisabilité et de convenance à un objet particulier sont déclinées. En aucun cas les détenteurs du droit de reproduction et les contributeurs ne seront responsables de dommages directs, indirects, incidents, spéciaux, exemplaires, ou consécutifs (incluant, sans s'y limiter, la fourniture de biens ou services de substitution, perte d'usage, données, ou profits, ou interruption d'affaires) cependant causés, et aucune théorie de responsabilité, contractuelle, stricte, ou pour tort (incluant la négligence ou autrement) survenant d'une façon quelconque de l'utilisation de ce logiciel, même si on est avisé de la possibilité de tels dommages.

TMOD-1  ::= < AVP Header: 495 >
                 { Token-Rate }
                 { Bucket-Depth }
                 { Peak-Traffic-Rate }
                 { Minimum-Policed-Unit }
                 { Maximum-Packet-Size }

TMOD-2  ::= < AVP Header: 501 >
                 { Token-Rate }
                 { Bucket-Depth }
                 { Peak-Traffic-Rate }
                 { Minimum-Policed-Unit }
                 { Maximum-Packet-Size }

 	Adresse des auteurs

Jouni Korhonen (editor)	Hannes Tschofenig	Elwyn Davies	
Nokia Siemens Networks	Nokia Siemens Networks	Folly Consulting	
Linnoitustie 6	Linnoitustie 6	Soham	
Espoo  02600	Espoo  02600	UK	
Finland	Finland	mél : elwynd@dial.pipex.com	
mél : jouni.korhonen@nsn.com	mél : Hannes.Tschofenig@gmx.net