Groupe de travail Réseau	J.P. Vasseur, éd., Cisco Systems, Inc.	
Request for Comments : 5073	J.L. Le Roux, éd., France Telecom	
Catégorie : Sur la voie de la normalisation	décembre 2007	
Traduction Claude Brière de L’Isle

Extensions au protocole d’acheminement IGP pour la découverte des capacités d’ingénierie du trafic d’un nœud

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

Résumé
Il est très souhaitable dans certains cas, de tenir compte des capacités d’ingénierie du trafic (TE, Traffic Engineering) d’un nœud durant la sélection de chemin commuté à étiquette avec ingénierie de trafic en commutation d’étiquette multi protocole (MPLS) et MPLS généralisé (GMPLS), comme par exemple, la capacité à agir comme routeur de commutation d’étiquette (LSR, Label Switching Router) de branche d’un LSP point à multipoint (PàMP). Cela requiert de publier ces capacités au moyen du protocole de passerelle intérieure (IGP). À cette fin, le présent document spécifie les extensions d’ingénierie du trafic de plus court chemin ouvert en premier (OSPF, Open Shortest Path First) et de système intermédiaire à système intermédiaire (IS-IS, Intermediate System-Intermediate System) pour la publication des capacités d’ingénierie de trafic de plan de contrôle et de plan de données d’un nœud.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Descripteur de capacité TE d’un nœud	2
3.1 Description	2
3.2 Informations requises	2
4. Formats de TLV de descripteur de capacité TE de nœud	3
4.1 Format de TLV de descripteur de capacité TE d’OSPF	3
4.2 Format de sous TLV de descripteur de capacité TE d’IS-IS de nœud	3
5. Éléments de procédure	4
5.1 OSPF	4
5.2 IS-IS	5
6. Rétro-compatibilité	5
7. Considérations pour la sécurité	5
8. Considérations relatives à l’IANA	5
8.1 TLV OSPF	5
8.2 Sous TLV IS-IS	6
8.3 Registre des capacités	6
9. Remerciements	6
10 Références	6
10.1 Références normatives	6
10.2 Références pour information	7
Adresse des éditeurs	8
Déclaration complète de droits de reproduction	8

1.	Introduction

L’acheminement en commutation multiprotocole avec étiquetage des flux et ingénierie du trafic (MPLS-TE, Multi Protocol Label Switching-Traffic Engineering) ([RFC3784], [RFC3630], [RFC5329]) s’appuie sur des extensions aux protocoles de passerelle intérieure (IGP, Interior Gateway Protocol) d’état de liaison ([IS-IS], [RFC1195], [RFC2328], [RFC2740]) afin de publier les informations d’ingénierie du trafic (TE, Traffic Engineering) de la liaison pour les acheminements à contrainte. D’autres extensions d’acheminement en rapport avec MPLS généralisé (GMPLS) sont définies dans les [RFC4205] et [RFC4203].

Il a été souhaité compléter ces extensions d’acheminement afin de publier les capacités TE du nœud, en plus des informations TE de liaison. Ces capacités TE du nœud seront prises en compte comme contrainte durant le choix de chemin.

Bien sûr, il est utile de publier les capacités TE de plan de données du nœud, telles que la capacité pour un routeur de commutation d’étiquettes (LSR, Label Switching Router) d’être un LSR de branche ou un LSR bourgeon d’un chemin commuté à étiquettes (LSP) en point à multipoint (PàMP). Ces capacités peuvent être prises en compte comme contraintes lors du calcul de l’acheminement des LSP de TE.

Il est aussi utile de publier les capacités d’ingénierie du trafic de plan de contrôle du nœud telles que la capacité à prendre en charge la signalisation GMPLS pour un LSR par paquet, ou la capacité à prendre en charge la signalisation LSP de TE en point à multipoint. Cela permet le choix d’un chemin qui évite les nœuds qui ne prennent pas en charge une caractéristique donnée de plan de contrôle, ou de déclencher un mécanisme pour prendre en charge de tels nœuds sur un chemin. Et donc, cela facilite la rétro-compatibilité.

À cette fin, le présent document spécifie les extensions IGP (OSPF et IS-IS) afin de publier les capacités de plan de données et de plan de contrôle d’un nœud.

Un nouveau TLV est défini pour OSPF, le TLV de descripteur de capacité TE de nœud, porté au sein de l’avis d’état de liaison (LSA, Link State Advertisement) d’informations sur les routeurs ([RFC4970]). Un nouveau sous-TLV est défini pour IS-IS, le sous TLV de descripteur de capacité TE de nœud, porté au sein du TLV de capacité IS-IS ([RFC4971]).

2.	Terminologie

Le présent document utilise les terminologies définies dans les [RFC3031], [RFC3209], et [RFC4461].

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

3.	Descripteur de capacité TE d’un nœud
3.1	Description
Les LSR dans un réseau peuvent avoir des capacités distinctes d’ingénierie du trafic de plan de contrôle et de plan des données. Les informations de descripteur de capacité TE de nœud définies dans le présent document décrivent les capacités de plan de données et de contrôle d’un LSR. De telles informations peuvent être utilisées durant le calcul du chemin de façon à éviter les nœuds qui ne prennent pas en charge une caractéristique donnée de TE dans le plan de contrôle ou le plan de données, ou pour déclencher des procédures pour traiter ces nœuds le long du chemin (par exemple, déclencher la prise en charge d’un LSR de transit ordinaire sur un LSP PàMP par la hiérarchie de LSP (voir la [RFC4875])).

3.2	Informations requises
Le descripteur de capacité TE de nœud contient un ensemble de longueur variable de bits fanions, où chaque bit correspond à une capacité TE de nœud donnée.

Cinq capacités TE de nœud sont définies dans le présent document :
-	Bit B : lorsqu’il est établi (à 1), ce fanion indique que le LSR peut agir comme nœud de branche sur un LSP P2MP (voir la [RFC4461]) ;
-	Bit E : lorsqu’il est établi, ce fanion indique que le LSR peut agir comme LSR bourgeon sur un LSP P2MP, c’est-à-dire, un LSR qui est à la fois de transit et de sortie (voir la [RFC4461]) ;
-	Bit M : lorsqu’il est établi, ce fanion indique que le LSR prend en charge la signalisation MPLS-TE [RFC3209] ;
-	Bit G : lorsqu’il est établi, ce fanion indique que le LSR prend en charge la signalisation GMPLS [RFC3473] ;
-	Bit P : lorsqu’il est établi, ce fanion indique que le LSR prend en charge la signalisation PàMP MPLS-TE [RFC4875].

Noter que de nouveaux bits de capacité pourront être ajoutés en tant que de besoin à l’avenir.

4.	Formats de TLV de descripteur de capacité TE de nœud
4.1	Format de TLV de descripteur de capacité TE d’OSPF
Le TLV de descripteur de capacité TE d’OSPF de nœud est un TLV de longueur variable qui contient une série de bits fanions, où chaque bit correspond à une capacité TE de nœud. Le champ binaire PEUT être étendu par des mots supplémentaires de 32 bits si il est nécessaire d’allouer plus de bits fanions. Tout bit fanion inconnu DEVRA être traité comme un bit réservé.

Le TLV de descripteur de capacité TE d’OSPF est porté au sein d’un LSA d’informations de routeur OSPF, qui est défini dans la [RFC4970].

Le format du TLV de descripteur de capacité de TE d’OSPF est le même que le format de TLV utilisé par les extensions d’ingénierie de trafic à OSPF [RFC3630]. C’est à dire que le TLV est composé de deux octets pour le type, de deux octets qui spécifient la longueur du champ de valeur, et d’un champ de valeur.

Le TLV de descripteur de capacité de TE d’OSPF a le format suivant :

TYPE :	5 (voir le paragraphe 8.1)
LONGUEUR :	Variable (multiple de 4).
VALEUR :	Collection d’unités de 32 fanions numérotés à partir du bit de plus fort poids comme bit zéro, où chaque bit représente une capacité TE de nœud.

Les bits suivants sont définis :

Bit	Capacités	
0	Bit B : Capacité de nœud de branche PàMP. Lorsqu’il est établi, il indique que le LSR peut agir comme nœud de branche sur un LSP en PàMP [RFC4461].	
1	Bit E : Capacité de LSR bourgeon en PàMP. Lorsque il est établi, cela indique que le LSR peut agir comme LSR bourgeon sur un LSP en PàMP, c’est-à-dire, un LSR qui est à la fois de transit et de sortie [RFC4461].	
2	Bit M : S’il est établi, cela indique que le LSR prend en charge la signalisation MPLS-TE [RFC3209].	
3	Bit G : S’il est établi, cela indique que le LSR prend en charge la signalisation GMPLS [RFC3473].	
4	Bit P : S’il est établi, cela indique que le LSR prend en charge la signalisation MPLS-TE en PàMP [RFC4875].	
5 à 31	Réservés pour de futures allocations par IANA.	

Les bits réservés DOIVENT être mis à zéro à la transmission, et DOIVENT être ignorés à réception. Si le champ de longueur est supérieur à 4, impliquant qu’il y a plus de 32 bits dans le champ de valeur, tous les bits supplémentaires (c’est à dire, non encore alloués) sont réservés.

4.2	Format de sous TLV de descripteur de capacité TE d’IS-IS de nœud
Le sous-TLV de descripteur de capacité TE de nœud en IS-IS est un sous-TLV de longueur variable qui contient une série de bits fanions, dont chaque bit correspond à une capacité TE de nœud. Le champ des bits PEUT être étendu par des octets supplémentaires si il faut allouer plus de bits fanions. Tout bit fanion inconnu DEVRA être traité comme bit réservé.

Le sous-TLV de descripteur de capacité TE de nœud en IS-IS est porté au sein d’un TLV IS-IS CAPABILITY, qui est défini dans la [RFC4971].

Le format du sous-TLV de descripteur de capacité TE de nœud en IS-IS est le même que le format de sous-TLV utilisé par les extensions d’ingénierie de trafic en IS-IS [RFC3784]. C’est-à-dire que le sous-TLV est composé de un octet pour le type, un octet spécifiant la longueur du champ de valeur.

Le sous-TLV de descripteur de capacité TE de nœud en IS-IS a le format suivant :

TYPE :	1 (voir au paragraphe 8.2)
LONGUEUR :	Variable
VALEUR :	Collection d’unités de 8 fanions numérotés à partir du bit de plus fort poids comme bit zéro, où chaque bit représente une capacité TE de nœud.

Les bits suivants sont définis :

Bit	Capacités	
0	Bit B : Capacité de nœud de branche PàMP. Lorsqu’il est établi, il indique que le LSR peut agir comme nœud de branche sur un LSP en PàMP [RFC4461].	
1	Bit E : Capacité de LSR bourgeon en PàMP. Lorsque il est établi, cela indique que le LSR peut agir comme LSR bourgeon sur un LSP en PàMP, c’est-à-dire, un LSR qui est à la fois de transit et de sortie [RFC4461].	
2	Bit M : S’il est établi, cela indique que le LSR prend en charge la signalisation MPLS-TE [RFC3209].	
3	Bit G : S’il est établi, cela indique que le LSR prend en charge la signalisation GMPLS [RFC3473].	
4	Bit P : S’il est établi, cela indique que le LSR prend en charge la signalisation MPLS-TE en PàMP [RFC4875].	
5 à 7	Réservés pour de futures allocations par l’IANA.	

Les bits réservés DOIVENT être mis à zéro à la transmission, et DOIVENT être ignorés à réception. Si le champ de longueur est supérieur à 1, impliquant qu’il y a plus de 8 bits dans le champ de valeur, tous les bits supplémentaires (c’est à dire, non encore alloués) sont réservés.

5.	Éléments de procédure
5.1	OSPF
Le TLV de descripteur de capacité TE de nœud est publié au sein d’un LSA d’information de routeur OSPFv2 (type opaque de 4 et identifiant opaque de 0) ou d’un LSA d’information de routeur OSPFv3 (code de fonction de 12), qui sont définis dans la [RFC4970]. Comme tels, les éléments de procédure sont hérités de ceux définis dans les [RFC2328], [RFC2740], et [RFC4970].

Le TLV de descripteur de capacité TE de nœud publie les capacités qui peuvent être prises en compte comme contraintes durant le choix du chemin. Et donc son domaine d’application est la zone locale, et il DOIT être porté au sein d’un LSA d’information de routeur OSPFv2 de type 10 (comme défini dans la [RFC2370]) ou un LSA d’information de routeur OSPFv3 avec le bit S1 établi (à 1) et le bit S2 ôté (à 0) (comme défini dans la [RFC2740]).

Un routeur DOIT générer un nouvel LSA d’information de routeur OSPF chaque fois que change le contenu du TLV de descripteur de capacité TE de nœud, ou chaque fois qu’exigé par la procédure OSPF normale (rafraîchissement de LSA (tous les LSRefreshTime)).

Le TLV de descripteur de capacité TE de nœud est FACULTATIF et NE DOIT PAS apparaître plus d’une fois dans un LSA d’information de routeur OSPF. Si un TLV de descripteur de capacité TE de nœud apparaît plus d’une fois dans un LSA d’information de routeur OSPF, seule la première occurrence DOIT être traitée et les autres DOIVENT être ignorées.

Lorsque un LSA d’information de routeur OSPF ne contient aucun TLV de descripteur de capacité TE de nœud, cela signifie que les capacités TE de nœud de ce LSR sont inconnues.

Noter qu’un changement d’une quelconque de ces capacités PEUT déclencher le calcul du chemin le plus court en premier obligé (CSPF), mais NE DOIT PAS déclencher le calcul normal du SPF.

Noter aussi que les capacités TE de nœud sont supposées être assez statiques. Elles peuvent changer par suite d’un changement de configuration ou de mise à jour de logiciel. On suppose que cela ne devrait pas se produire plus d’une fois par jour.

5.2	IS-IS
Le sous-TLV de capacité TE de nœud est porté au sein d’un TLV IS-IS CAPABILITY défini dans la [RFC4971]. Comme tels, les éléments de procédure sont hérités de ceux définis dans la [RFC4971].

Le sous-TLV de descripteur de capacité TE de nœud publie les capacités qui peuvent être prises en compte comme contraintes durant le choix du chemin. Et donc, son domaine de couverture est la zone locale, et il DOIT être porté au sein d’un TLV IS-IS CAPABILITY dont le fanion S est ôté (à 0).

Un routeur IS-IS DOIT générer un nouveau LSP IS-IS chaque fois que le contenu de tout sous-TLV de capacité TE de nœud change ou chaque fois que c’est exigé par la procédure IS-IS normale (rafraîchissement de LSP).

Le sous-TLV de descripteur de capacité TE de nœud est FACULTATIF et NE DOIT PAS apparaître plus d’une fois dans un TLV de capacité de routeur IS-IS.

Lorsque un LSP IS-IS ne contient aucun sous-TLV de descripteur de capacité TE de nœud, cela signifie que les capacités TE de nœud de ce LSR sont inconnues.

Noter qu’un changement d’une quelconque de ces capacités PEUT déclencher le calcul de CSPF, mais NE DOIT PAS déclencher le calcul SPF normal.

Noter aussi que les capacités TE de nœud sont supposées être assez statiques. Elles peuvent changer par suite d’un changement de configuration ou de mise à jour de logiciel. On suppose que cela ne devrait pas se produire plus d’une fois par jour.

6.	Rétro-compatibilité

Les TLV de descripteur de capacité TE de nœud définis dans le présent document n’introduisent aucun problème d’interopérabilité. Pour OSPF, un routeur qui ne prend pas en charge le TLV de descripteur de capacité TE de nœud va seulement ignorer en silence le TLV, comme spécifié dans la [RFC4970]. Pour IS-IS, un routeur qui ne prend pas en charge le sous-TLV de descripteur de capacité TE de nœud va simplement ignorer en silence le sous-TLV, comme spécifié dans la [RFC4971].

Lorsque le TLV de descripteur de capacité TE de nœud est absent, cela signifie que les capacités TE de ce LSR sont inconnues.

L’absence d’un mot de fanion de capacités dans OSPF ou d’un octet de fanion de capacités dans IS-IS signifie que ces capacités sont inconnues.

7.	Considérations pour la sécurité

Le présent document spécifie le contenu du TLV de descripteur de capacité TE de nœud dans IS-IS et OSPF à utiliser pour le calcul du chemin (G)MPLS-TE. Comme ce TLV n’est pas utilisé pour le calcul SPF ou pour l’acheminement normal, les extensions spécifiées ici n’ont pas d’effet direct sur l’acheminement IP. L’altération de ce TLV peut avoir un effet sur le calcul de l’ingénierie de trafic. Les mécanismes définis pour sécuriser les PDU d’état de liaison IS-IS [RFC3567], les LSA OSPF [RFC2154], et leurs TLV peuvent être utilisés pour sécuriser aussi ce TLV.

8.	Considérations relatives à l’IANA
8.1	TLV OSPF
La [RFC4970] définit un nouveau registre des codets pour les TLV portés dans le LSA d’information de routeur défini dans la [RFC4970].

L’IANA a fait une nouvelle allocation de codet dans ce registre pour le TLV de descripteur de capacité TE de nœud défini dans le présent document et porté au sein du LSA d’information de routeur. Sa valeur est de 5. Voir le paragraphe 4.1 du présent document.

8.2	Sous TLV IS-IS
L’IANA a défini un registre pour les sous-TLV de TLV IS-IS CAPABILITY définis dans la [RFC4971].

L’IANA a fait une nouvelle allocation de codet dans ce registre pour le sous-TLV de descripteur de capacité TE de nœud défini dans le présent document et porté au sein du TLV IS-IS CAPABILITY. Sa valeur est de 1. Voir le paragraphe 4.2 du présent document.

8.3	Registre des capacités
L’IANA a créé un nouveau registre pour gérer l’espace de bits fanions de capacité portés au sein du descripteur de capacité TE OSPF et ISIS de nœud.

Un seul registre doit être défini pour les deux protocoles. Un nouveau registre de base a été créé pour couvrir les registres IGP-TE qui s’appliquent à la fois à OSPF et IS-IS, et le nouveau registre exigé par le présent document est un sous-registre de ce nouveau registre de base.

Dans ce nouveau registre, les bits devraient être numérotés selon la notation IETF usuelle, commençant par le bit de plus fort poids à zéro.

Les nouveaux numéros de bit ne peuvent être alloués que par une action de consensus IETF.

Chaque bit devrait être retracé avec les qualités suivantes :
- Numéro de bit 
- RFC de définition
- Nom du bit

L’IANA a fait les allocations des cinq capacités TE de nœud définies dans le présent document (voir les paragraphes 8.1 et 8.2) en utilisant les valeurs suivantes :

Bit n°	Nom	Référence	
0	Bit B : Capacité de LSR de branche en PàMP	[RFC5073]	
1	Bit E : Capacité de LSR bourgeon en PàMP	[RFC5073]	
2	Bit M : Prise en charge de MPLS-TE	[RFC5073]	
3	Bit G : Prise en charge de GMPLS	[RFC5073]	
4	Bit P : Prise en charge de RSVP-TE en PàMP	[RFC5073]	
5-7	Non alloués	[RFC5073]	

9.	Remerciements

Nous tenons à remercier Benoit Fondeviole, Adrian Farrel, Dimitri Papadimitriou, Acee Lindem, et David Ward pour leurs utiles commentaires et suggestions.

Nous remercions aussi les auteurs des [RFC4420] et [RFC4970] dont s’inspire une partie du texte du présent document.

Adrian Farrel a préparé la version finale du présent document pour sa soumission à l’IESG.

10.	Références
10.1	Références normatives

[IS-IS]	Norme ISO/CEI 10589, "Protocole d'échange d'acheminement de système intermédiaire à système intermédiaire à utiliser en conjonction avec le protocole de fourniture de service réseau en mode sans connexion" seconde édition, 2002.

[RFC1195]	R. Callon, "Utilisation de l'IS-IS OSI pour l'acheminement dans les environnements TCP/IP et duels", décembre 1990. (Mise à jour par les RFC 1349, 5302, 5304)

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

[RFC2328]	J. Moy, "OSPF version 2", STD 54, avril 1998. (MàJ par la RFC6549, RFC8042, 9355)

[RFC2370]	R. Coltun, "Option OSPF LSA opaque", juillet 1998. (Obsolète, voir RFC5250) (P.S.)

[RFC2740]	R. Coltun, D. Ferguson, J. Moy, "OSPF pour IPv6", décembre 1999. (Obsolète, voir RFC5340) (P.S.)

[RFC3031]	E. Rosen, A. Viswanathan, R. Callon, "Architecture de commutation d'étiquettes multi protocoles", janvier 2001. (P.S.) (MàJ par la RFC6790)
[RFC3209]	D. Awduche, et autres, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (Mise à jour par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC6790)

[RFC3373]	D. Katz, R. Saluja, "Prise de contact à trois pour les adjacences point à point de système intermédiaire à système intermédiaire (IS-IS)", septembre 2002. (Obsolète, voir RFC5303) (Information)

[RFC3630]	D. Katz, K. Kompella et D. Yeung, "Extensions d'ingénierie de trafic à OSPF version 2", septembre 2003.

[RFC3784]	H. Smit, T. Li, "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour l'ingénierie du trafic (TE)", juin  2004. (Obsolète, voir RFC5305) (MàJ par RFC4205) (Information)

[RFC4875]	R. Aggarwal et autres, "Extensions au protocole de réservation de Ressource avec ingénierie du trafic (RSVP-TE) pour chemins à commutation d'étiquettes (LSP) en point à multipoint", mai 2007 (MàJ par RFC6510). (P.S.)

[RFC4970]	A. Lindem et autres, "Extensions à OSPF pour l'annonce des capacités facultatives de routeur", juillet 2007. (P.S.)
[RFC4971]	JP. Vasseur et autres, "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour l'annonce des informations de routeur", juillet 2007. (P.S. ; MàJ par RFC7981)

10.2	Références pour information

[RFC2154]	S. Murphy, M. Badger et B. Wellington, "OSPF avec des signatures numériques", juin 1997.

[RFC3567]	T. Li et R. Atkinson, "Authentification cryptographique de système intermédiaire à système intermédiaire (IS-IS)", juillet 2003. (Rendue obsolète par la RFC5304)

[RFC4203]	K. Kompella et autres, "Extensions OSPF pour la prise en charge de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", octobre 2005. (MàJ RFC3630) (P.S.)

[RFC4205]	K. Kompella et Y. Rekhter, éd., "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour la prise en charge de la commutation généralisée d'étiquettes multiprotocoles (GMPLS)", octobre 2005. (Obsolète, voir RFC5307) (MàJ RFC3784)

[RFC4420]	A. Farrel et autres, "Codage des attributs pour l'établissement de chemin à commutation d'étiquettes (LSP) de la commutation d'étiquettes multiprotocoles (MPLS) en utilisant le protocole de réservation de ressources avec extensions d’ingénierie de trafic (RSVP-TE)", février 2006. (MàJ RFC3209, RFC3473) (P.S.  : Obsolète, voir RFC  5420, )

[RFC4461]	S. Yasukawa, éd., "Exigences de signalisation pour les chemins à commutation d'étiquettes (LPS) de MPLS à ingénierie de trafic en point à multipoint", avril 2006. (Information)

[RFC5329]	K. Ishiguro et autres, "Extensions d'ingénierie du trafic à OSPF version 3", septembre 2008. (P.S.)

Adresse des contributeurs

Seisho Yasukawa	Stefano Previdi	Peter Psenak	
NTT	Cisco Systems, Inc	Cisco Systems, Inc	
3-9-11 Midori-cho,	Via Del Serafico 200	Pegasus Park DE Kleetlaan 6A	
Musashino-shi, Tokyo 180-8585	Roma, 00142	Diegmen, 1831	
Japan	Italia	Belgique	
mél : s.yasukawa@hco.ntt.co.jp	mél : sprevidi@cisco.com 	mél : ppsenak@cisco.com 	

Paul Mabbey
Comcast
USA

Adresse des éditeurs

Jean-Philippe Vasseur	Jean-Louis Le Roux	
Cisco Systems, Inc.	France Telecom	
1414 Massachusetts Avenue	2, avenue Pierre-Marzin	
Boxborough, MA, 01719	22307 Lannion Cedex	
USA	France	
mél : jpv@cisco.com 	mél : jeanlouis.leroux@orange-ftgroup.com 	

Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2007).

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 contenues sont fournis 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 encloses ne viole 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 pourraien ê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 le 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 .