Groupe de travail Réseau	J. Polk, Cisco Systems
Request for Comments : 5432	S. Dhesikan, Cisco Systems
Catégorie : Sur la voie de la normalisation	G. Camarillo, Ericsson
Traduction Claude Brière de L'Isle	mars 2009

Choix du mécanisme de qualité de service (QS) dans le protocole de description de session (SDP)

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.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le modèle d'offre/réponse pour le protocole de description de session (SDP, description de session Protocol ) suppose que les points d'extrémité établissent d'une façon ou d'une autre la qualité de service (QS) requise pour les flux de supports qu'ils établissent. Les points d'extrémité dans des environnements clos s'accordent normalement hors bande (par exemple, en utilisant des informations de configuration) sur quel mécanisme de QS utiliser. Cependant, sur l'Internet, il y a plus d'un service de QS disponible. Par conséquent, il y a besoin d'un mécanisme pour négocier quel mécanisme de QS utiliser pour un flux de supports particulier. Le présent document définit un tel mécanisme.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Définition des attributs SDP	2
4. Comportement d'offre/réponse	3
4.1 Comportement de l'offreur	3
4.2 Comportement du répondeur	3
4.3 Réservation de ressources	3
4.4 Échanges d'offre/réponse suivants	3
5. Exemple	3
6. Considérations relatives à l’IANA	4
6.1 Enregistrement de l'attribut SDP "qos-mech-send"	4
6.2 Enregistrement de l'attribut SDP "qos-mech-recv"	4
6.3 Registre des jetons de mécanisme de QS	4
7. Considérations sur la sécurité	4
8. Remerciements	5
9. Références	5
9.1 Références normatives	5
9.2 Références pour information	5
Adresse des auteurs	5

 	1.	Introduction

Le modèle d'offre/réponse [RFC3264] pour SDP [RFC4566] ne fournit pas de mécanisme pour que les points d'extrémité négocient le mécanisme de QS à utiliser pour un flux de supports particulier. Même quand des préconditions de QS [RFC3312] sont utilisées, le choix du mécanisme de QS reste non spécifié et appartient aux points d'extrémité.

Les points d'extrémité qui prennent en charge plus d'un mécanisme de QS ont besoin d'un moyen de négocier lequel utiliser pour un flux de supports particulier. Des exemples de mécanismes de QS sont le protocole de réservation de ressources (RSVP, Resource Reservation Protocol) [RFC2205] et prochaines étapes de la signalisation (NSIS, Next Steps in Signaling) [RFC5974].

Le présent document définir un mécanisme qui permet aux points d'extrémité de négocier le mécanisme de QS à utiliser pour un flux de supports particulier. Cependant, le fait que les points d'extrémité s'accordent sur un mécanisme de QS particulier n'implique pas que ce mécanisme particulier soit pris en charge par le réseau. Découvrir quels mécanismes de QS sont pris en charge à la couche réseau sort du domaine d'application du présent document. En tous cas, les informations que les points d'extrémité échangent pour négocier les mécanismes de QS, comme définies dans le présent document, peuvent être utiles pour qu'un opérateur de réseau résolve un sous ensemble du problème de l'interopérabilité de QS -- à savoir, s'assurer qu'un mécanisme communément acceptable par les points d'extrémité est choisi et rende possible de déboguer de potentielles situations de mauvaise configuration.

 	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.	Définition des attributs SDP

Le présent document définit les attributs de session "qos-mech-send" et "qos-mech-recv" et de niveau support SDP [RFC4566]. Voici la syntaxe de leur forme en Backus-Naur augmenté (ABNF) [RFC5234], qui se fonde sur la grammaire SDP [RFC4566] :

attribute =/ qos-mech-send-attr
attribute =/ qos-mech-recv-attr

qos-mech-send-attr = "qos-mech-send" ":" [[SP] qos-mech *(SP qos-mech)]
qos-mech-recv-attr = "qos-mech-recv" ":" [[SP] qos-mech *(SP qos-mech)]

qos-mech = "rsvp" / "nsis" / extension-mech
extension-mech  = jeton

Le jeton "qos-mech" identifie un mécanisme de QS qui est pris en charge par l'entité qui génère la description de session. Un jeton qui apparaît dans un attribut "qos-mech-send" identifie un mécanisme de QS qui peut être utilisé pour réserver des ressources pour le trafic envoyé par l'entité qui génère la description de session. Un jeton qui apparaît dans un attribut "qos-mech-recv" identifie un mécanisme de QS qui peut être utilisé pour réserver des ressources pour le trafic reçu par l'entité qui génère la description de session.

Les attributs "qos-mech-send" et "qos-mech-recv" ne sont pas inter dépendants ; un peut être utilisé sans l'autre.

Voici un exemple d'une ligne "m' avec les attributs "qos-mech-send" et "qos-mech-recv" :

m=audio 50000 RTP/AVP 0
a=qos-mech-send: rsvp nsis
a=qos-mech-recv: rsvp nsis

 	4.	Comportement d'offre/réponse

Grâce à l'utilisation des attributs "qos-mech-send" et "qos-mech-recv", un échange d'offre/réponse permet aux points d'extrémité d'avoir une liste de mécanismes de QS communs triés par préférence. Cependant, on notera que les points d'extrémité négocient dans quelle direction la QS est nécessaire en utilisant d'autres mécanismes, comme des préconditions [RFC3312]. Les points d'extrémité peuvent aussi utiliser d'autres mécanismes pour négocier, si nécessaire, les paramètres à utiliser avec un mécanisme de QS donné (par exemple, la bande passante à réserver).

 	4.1	Comportement de l'offreur
Les offreurs incluent un attribut "qos-mech-send" avec les jetons correspondants aux mécanismes de QS (dans l'ordre de préférence) qui sont pris en charge dans la direction d'envoi. De même, les offreurs incluent un attribut "qos-mech-recv" avec les jetons correspondants aux mécanismes de QS (dans l'ordre de préférence) qui sont pris en charge dans la direction de réception.

 	4.2	Comportement du répondeur
À réception d'une offre avec un ensemble de jetons dans un attribut "qos-mech-send", le répondeur prend les jetons correspondants aux mécanismes de QS qu'il prend en charge dans la direction de réception et les inclut, dans l'ordre de préférence, dans un attribut "qos-mech-recv" dans la réponse. À réception d'une offre avec un ensemble de jetons dans un attribut "qos-mech-recv", le répondeur prend les jetons correspondants aux mécanismes de QS qu'il prend en charge dans la direction d'envoi et les inclut, dans l'ordre de préférence, dans un attribut "qos-mech-send" dans la réponse.

Quand il ordonne les jetons dans un attribut "qos-mech-send" ou "qos-mech-recv" par préférence, le répondeur peut prendre en compte ses propres préférences et celles exprimées dans l'offre. Cependant, l'algorithme exact à utiliser pour ordonner une telle liste de jetons sort du domaine d'application de la présente spécification.

Noter que si le répondeur n'a aucun mécanisme de QS en commun avec l'offreur, il va retourner des attributs "qos-mech-send" et "qos-mech-recv" vides.

 	4.3	Réservation de ressources
Une fois l'échange d'offre/réponse achevé, l'offreur et le répondeur utilisent la liste de jetons dans les attributs "qos-mech-send" et "qos-mech-recv" de la réponse pour effectuer les réservations de ressources. Les offreurs et les répondeurs DEVRAIENT tenter en premier d'utiliser le mécanisme de QS avec la plus haute priorité dans chaque direction. Si un point d'extrémité (l'offreur ou le répondeur) ne réussit pas à utiliser le mécanisme de plus haute priorité dans une direction, il DEVRAIT tenter d'utiliser le prochain mécanisme de QS dans l'ordre de priorité de cette direction, et ainsi de suite.

Si un point d'extrémité essaye sans succès tous les mécanismes de QS communs pour une direction donnée, il PEUT tenter d'utiliser des mécanismes de QS supplémentaires non pris en charge par le point d'extrémité distant. C'est parce que il peut y avoir des entités de réseau hors du contrôle du point d'extrémité (par exemple, un mandataire RSVP) qui va faire fonctionner ces mécanismes.

 	4.4	Échanges d'offre/réponse suivants
Si, durant une session établie pour laquelle le mécanisme de QS à utiliser pour une direction donnée a été accepté en commun en utilisant le mécanisme défini dans cette spécification, un point d'extrémité reçoit une offre suivante qui ne contient pas l'attribut de choix de QS correspondant à cette direction (c'est-à-dire, si l'attribut "qos-mech-send" ou "qos-mech-recv" manque) les points d'extrémité DEVRAIENT continuer d'utiliser le même mécanisme de QS qu'utilisé jusqu'à ce moment.

 	5.	Exemple

Voici un échange d'offre/réponse entre deux points d'extrémité qui utilise les attributs "qos-mech-send" et "qos-mech-recv". Des parties de la description de sessions sont omises dans un souci de clarté.

L'offreur génère la description de session suivante, mentionnant les RSVP et NSIS pour les deux directions. L'offreur préférerait utiliser RSVP et, donc, l'inclut avant NSIS.

m=audio 50000 RTP/AVP 0
a=qos-mech-send: rsvp nsis
a=qos-mech-recv: rsvp nsis

La réponse prend en charge NSIS dans les deux directions, mais pas RSVP. Par conséquent, il retourne la description de session suivante :

m=audio 55000 RTP/AVP 0
a=qos-mech-send: nsis
a=qos-mech-recv: nsis

 	6.	Considérations relatives à l’IANA

La présente spécification enregistre deux nouveaux attributs SDP et crée un nouveau registre pour les mécanismes de QS.

 	6.1	Enregistrement de l'attribut SDP "qos-mech-send"
L'IANA a enregistré le att-field SDP suivant sous le registre des paramètres du protocole de description de session (SDP) :

Nom du contact : Gonzalo.Camarillo@ericsson.com
Nom d'attribut : qos-mech-send
Forme longue du nom d'attribut : mécanisme de QS pour la direction d'envoi
Type d'attribut : niveaux session et supports
Soumis au jeu de caractères : non
Objet de l'attribut : faire la liste des mécanismes de QS pris en charge dans la direction d'envoi.
Valeurs d'attribut permises : jetons enregistrés par l'IANA.

 	6.2	Enregistrement de l'attribut SDP 'qos-mech-recv'
L'IANA a enregistré le att-field SDP suivant sous le registre des paramètres du protocole de description de session (SDP) :

Nom du contact : Gonzalo.Camarillo@ericsson.com
Nom d'attribut : qos-mech-recv
Forme longue du nom d'attribut : mécanisme de QS pour la direction de réception
Type d'attribut :  niveaux session et supports
Soumis au jeu de caractères : non
Objet de l'attribut : faire la liste des mécanismes de QS pris en charge dans la direction de réception
Valeurs d'attribut permises : jetons enregistrés par l'IANA.

 	6.3	Registre des jetons de mécanisme de QS
L'IANA a créé un sous registre pour les valeurs de jeton de mécanisme de QS à utiliser dans les attributs "qos-mech-send" et "qos-mech-recv" sous le registre des paramètres du protocole de description de session (SDP). Les valeurs initiales pour le sous registre sont comme suit :

Mécanisme de QS	Référence
      rsvp	RFC 5432
      nsis	RFC 5432

Selon la terminologie de la [RFC5226], la politique d'enregistrement pour les nouvelles valeurs de jeton de mécanisme de QS devra être 'Spécification exigée'.

 	7.	Considérations sur la sécurité

Un attaquant peut tenter d'ajouter, modifier, ou supprimer les attributs "qos-mech-send" et "qos-mech-recv" d'une description de session. Il pourrait en résulter qu'une application se comporte d'une façon indésirable. Par exemple, les points d'extrémité attaqués peuvent ne pas être capables de trouver un mécanisme de QS commun à utiliser.

Par conséquent, il est fortement RECOMMANDÉ que la protection de l'intégrité et de l'authenticité soit appliquée aux descriptions de session SDP qui portent ces attributs. Pour les descriptions de session portées dans SIP [RFC3261], S/MIME [RFC3851] est le choix naturel pour fournir une telle protection de l'intégrité de bout en bout, comme décrit dans la [RFC3261]. Les autres applications PEUVENT utiliser une forme différente de protection de l'intégrité.

 	8.	Remerciements

Dave Oran a aidé à la formation de ce travail. Flemming Andreasen et Magnus Westerlund ont fourni d'utiles commentaires sur cette spécification.

 	9.	Références
 	9.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. (MàJ par RFC8174)

[RFC3264]	J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002. (P.S.  ; MàJ par RFC8843, 9143)

[RFC3851]	B. Ramsdell, "Spécification du message d'extensions de messagerie Internet multi-objets/sécurisé (S/MIME) version  3.1", juillet 2004. (Obsolète, voir RFC5751)

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006. (P.S.  ; remplacée par RFC8866)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

 	9.2	Références pour information

[RFC2205]	R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ par RFC2750, RFC3936, RFC4495, RFC6780)) (P.S.)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002, DOI 10.17487/RFC3261. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3312]	G. Camarillo, éd., "Intégration de la gestion de ressource et du protocole d'initialisation de session (SIP)", octobre 2002. (MàJ par RFC4032, RFC5027) (P.S.)

[RFC5974]	J. Manner, G. Karagiannis, A. McDonald, "Protocole de la couche de signalisation NSIS (NSLP) pour la signalisation de la qualité de service", octobre 2010. (Expérimentale) 

 	Adresse des auteurs

James Polk	Subha Dhesikan	Gonzalo Camarillo	
Cisco Systems	Cisco Systems	Ericsson	
3913 Treemont Circle	170 W. Tasman Drive	Hirsalantie 11	
Colleyville, Texas  76034	San Jose, CA  95134	Jorvas  02420	
USA	USA	Finland	
mél : jmpolk@cisco.com	mél : sdhesika@cisco.com	mél : Gonzalo.Camarillo@ericsson.com