Groupe de travail RéseauZ. Ali, Cisco Systems	Z. Ali, Cisco Systems	
Request for Comments : 4558	R. Rahman, Cisco Systems	
Catégorie : Sur la voie de la normalisation	D. Prairie, Cisco Systems	
	D. Papadimitriou, Alcatel	
Traduction Claude Brière de L'Isle	juin 2006	

Précisions sur le Hello fondé sur l'identifiant de nœud du 
protocole de réservation de ressource (RSVP)

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

Résumé
L'utilisation du message Hello fondé sur l'identifiant de nœud du protocole de réservation de ressource (RSVP, Resource Reservation Protocol) est impliquée dans un certain nombre de cas, par exemple, quand les plans de données et de contrôle sont séparés, quand les liaisons TE ne sont pas numérotées. De plus, quand la détection de défaillance au niveau liaison est effectuée par des moyens autres que l'échange de messages Hello RSVP, l'utilisation d'une session de Hello fondé sur l'identifiant de nœud est optimale pour détecter une défaillance d'adjacence de signalisation pour le protocole de réservation de ressource avec ingénierie du trafic (RSVP-TE, Resource reSerVation Protocol-Traffic Engineering). Néanmoins, le comportement impliqué n'est pas clair, et le présent document formalise l'utilisation de la session de Hello RSVP fondé sur l'identifiant de nœud dans certains scénarios. La procédure décrite dans le document s'applique aux nœuds capables de commutation d'étiquettes multi protocoles (MPLS, Multi-Protocol Label Switching) et de MPLS généralisé (GMPLS).

 	1.	Introduction

L'échange de messages Hello RSVP a été introduit dans la [RFC3209]. L'usage du Hello RSVP a été étendu dans la [RFC3473] pour prendre en charge les procédures de redémarrage en douceur (GR, Graceful Restart) RSVP.

Plus précisément, la [RFC3473] spécifie l'utilisation des messages Hello RSVP pour les procédures de GR pour MPLS généralisé (GMPLS). GMPLS introduit la notion de séparation du plan de contrôle et du plan de données. En d'autres termes, dans les réseaux GMPLS, les informations de plan de contrôle sont portées sur un réseau de contrôle dont les points d'extrémité ont la capacité IP et cela peut être physiquement ou logiquement disjoint des liaisons qui portent les données qu'il contrôle. Une des conséquences de la séparation des liaisons porteuses de données des canaux de contrôle est que les messages Hello RSVP ne se terminent pas sur les interfaces des liaisons porteuses de données même si celles-ci (ou certaines d'entre elles) sont numérotées. Au lieu de cela, les messages Hello RSVP se terminent aux points d'extrémité du canal de contrôle (à capacité IP). Ce dernier PEUT être identifié par la valeur allouée au nœud qui héberge ces canaux de contrôle, c'est-à-dire l'identifiant de nœud. Par conséquent, l'utilisation des messages Hello RSVP pour les applications de GR introduit un besoin d'éclaircissements sur le comportement et l'usage des sessions de Hello fondé sur l'identifiant de nœud.

Même dans le cas d'interfaces capables de commutation de paquets, quand la détection de la défaillance de la liaison est effectuée par des moyens autres que des messages Hello RSVP (par exemple, la [RFC5880]) l'utilisation de session de Hello fondé sur l'identifiant de nœud est aussi optimale pour la détection de défaillances d'adjacence de signalisation pour GMPLS-RSVP-TE et RSVP-TE quand il y a plus d'une liaison entre une paire de nœuds. De même, quand toutes les liaisons TE entre des nœuds voisins sont non numérotées, cela implique que les nœuds échangent des messages Hello fondé sur l'identifiant de nœud pour la détection de défaillances d'adjacence de signalisation. Le présent document précise aussi l'utilisation des échanges de messages Hello fondé sur l'identifiant de nœud quand toutes les liaisons ou un sous ensemble d'entre elles ne sont pas numérotées.

 	2.	Terminologie

Identifiant de nœud : identifiant de routeur TE tel qu'annoncé dans le TLV Adresse de routeur pour OSPF [RFC3630] et le TLV Identifiant de routeur d'ingénierie du trafic pour ISIS [RFC3784]. Pour IPv6, l'identifiant de nœud se réfère à l'adresse de routeur IPv6 pour OSPFv3 [RFC5329] et à l'identifiant de routeur IPv6 pour IS-IS [RFC6119].

Session de Hello fondé sur l'identifiant de nœud : session de Hello dans laquelle des identifiants de nœud local et distant sont utilisés dans les champs, respectivement, source et destination du paquet Hello.

Session de Hello à interface limitée : session de Hello dans laquelle les adresses locale et distante de l'interface en question sont utilisées dans les champs, respectivement, de source et de destination du paquet Hello.

 	2.1	Conventions utilisées dans ce document
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.	Messages Hello RSVP fondé sur l'identifiant de nœud

Une session de Hello fondé sur l'identifiant de nœud est établie par un échange de messages Hello RSVP de façon telle que les identifiants de nœud local et distant sont respectivement utilisés dans les champs source et destination des paquets Hello. Ici, pour IPv4, identifiant de nœud se réfère à l'identifiant de routeur TE comme défini dans le TLV Adresse de routeur pour OSPF [RFC3630] et au TLV Identifiant de routeur d'ingénierie de trafic pour ISIS [RFC3784]. Pour IPv6,  l'identifiant de nœud se réfère à l'adresse IPv6 de routeur pour OSPFv3 [RFC5329] à l'identifiant de routeur TE IPv6 pour IS-IS [RFC6119]. Cette section formalise une procédure pour établir des sessions de Hello fondé sur l'identifiant de nœud.

Si un nœud souhaite établir une session de Hello fondé sur l'identifiant de nœud avec ses voisins, il envoie un message Hello avec son identifiant de nœud dans le champ Adresse IP de source du paquet Hello. De plus, le nœud met aussi l'identifiant de nœud du voisin dans le champ Adresse de destination du paquet IP.

Quand un nœud reçoit un paquet Hello où l'adresse IP de destination est son identifiant de nœud local comme annoncé dans la topologie IGP-TE, le nœud DOIT utiliser son identifiant de nœud en répondant au message Hello. En d'autres termes, les nœuds DOIVENT s'assurer que les identifiant de nœud utilisés dans les messages Hello RSVP sont ceux déduits/contenus dans la topologie IGP-TE. De plus, un nœud peut seulement faire fonctionner une session de Hello RSVP fondé sur l'identifiant de nœud par instance IGP (c'est à dire, par paire d'identifiant de nœud) avec son voisin.

Même dans le cas d'interfaces capables de commutation de paquets, quand la détection de défaillance de niveau liaison est effectuée par des moyens autres que l'échange de messages Hello RSVP, l'utilisation des sessions de Hello fondé sur l'identifiant de nœud est aussi optimale pour détecter des défaillances d'adjacence de signalisation pour GMPLS-RSVP-TE et RSVP-TE quand il y a plus d'une liaison entre une paire de nœuds. De même, si toutes les interfaces entre une paire de nœuds sont non numérotées, la façon optimale d'utiliser RSVP pour détecter la défaillance d'adjacence de signalisation est de faire des sessions de Hello fondé sur l'identifiant de nœud. De plus, dans le cas d'un réseau optique avec un seul ou plusieurs canaux de contrôle numérotés ou non, l'utilisation de messages Hello fondé sur l'identifiant de nœud pour détecter une défaillance d'adjacence de signalisation est aussi optimale. Donc, quand la détection de défaillance de liaison est effectuée par des moyens autres que l'échange de messages Hello RSVP, ou si toutes les interfaces entre une paire de nœuds sont non numérotées, ou dans un réseau GMPLS avec séparation des plans de données et de contrôle, un nœud DOIT utiliser des sessions de Hello fondé sur l'identifiant de nœud pour la détection de la défaillance d'adjacence de signalisation pour RSVP-TE. Néanmoins, si on désire distinguer les défaillances d'adjacence de signalisation et de liaison, les sessions de Hello fondé sur l'identifiant de nœud peuvent coexister avec l'échange de messages Hello à interface limitée. De même, si une paire de nœuds partage des liaisons TE numérotées et non numérotées, les sessions de Hello fondé sur l'identifiant de nœud et fondé sur l'interface peuvent coexister.

 	4.	Note pour la rétro compatibilité

La procédure présentée dans ce document est rétro compatible avec la [RFC3209] et la [RFC3473].

Selon la [RFC3209], le mécanisme de Hello est destiné à être utilisé entre les voisins immédiats, et les messages Hello sont par défaut envoyés entre les voisins RSVP directs. Le présent document ne modifie pas ce comportement, car il utilise comme "identifiant de nœud local" l'adresse IPv4/IPv6 de source du nœud envoyeur et comme "identifiant de nœud distant" l'adresse IPv4/IPv6 de destination du nœud voisin. Le réglage et le traitement de la limite de TTL/bonds sont aussi inchangés.

De plus, le présent document ne modifie pas l'utilisation du traitement de Hello pour la récupération d'état comme définie au paragraphe 9.3 de la [RFC3473] (incluant la définition et le traitement de l'objet RESTART_CAP).

 	5.	Considérations sur la sécurité

Comme le présent document ne modifie ni n'étend l'échange de messages Hello RSVP entre les voisin RSVP immédiats, il n'introduit pas de nouvelles considérations de sécurité.

Les considérations de sécurité relevant de la [RFC3209] originales restent pertinentes. La sécurité du message RSVP est décrite dans la [RFC2747] et assure l'intégrité et l'authentification du message Hello du propriétaire de l'identifiant de nœud.

 	6.	Remerciements

Nous tenons à remercier Anca Zamfir, Jean-Louis Le Roux, Arthi Ayyangar, et Carol Iturralde de leurs utiles commentaires et suggestions.

 	7.	Références
 	7.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)

[RFC2747]	F. Baker, B. Lindell, M. Talwar, "Authentification cryptographique RSVP", janvier 2000. (MàJ par RFC3097) (P.S.)

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

[RFC3473]	L. Berger, "Extensions d'ingénierie de protocole - trafic de signalisation de réservation de ressource (RSVP-TE) de commutation d'étiquettes multi-protocoles généralisée (GMPLS)", janvier 2003. (P.S., MàJ par 4003, 4201, 4420, 4783, 4784, 4873, 4974, 5063, 5151,  8359)

 	7.2	Références pour 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)

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

[RFC5880]	D. Katz, D. Ward, "Détection de transmission bidirectionnelle (BFD)", juin 2010. (P. S. ; MàJ par RFC7880)

[RFC6119]	J. Harrison, J. Berger, M. Bartlett, "Ingénierie du trafic IPv6 en IS-IS", février 2011. (P. S.)

 	Adresse des auteurs

Zafar Ali	Reshad Rahman	Danny Prairie	
Cisco Systems Inc.	Cisco Systems Inc.	Cisco Systems Inc.	
100 South Main St. #200	2000 Innovation Dr.,	2000 Innovation Dr.,	
Ann Arbor, MI 48104, USA	Kanata, Ontario, K2K 3E8, Canada	Kanata, Ontario, K2K 3E8, Canada	
téléphone : (734) 276-2459	téléphone : (613) 254-3519	téléphone : (613) 254-3544	
mél : zali@cisco.com 	mél : rrahman@cisco.com 	mél : dprairie@cisco.com 	

Dimitri Papadimitriou
Alcatel
Fr. Wellesplein 1,
B-2018 Antwerpen
Belgique
téléphone : +32 3 240-8491
mél : dimitri.papadimitriou@alcatel.be 

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

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 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'activité de soutien administatif (IASA) de l'IETF.