Groupe de travail Réseau	D. Awduche, Movaz Networks
Request for Comments: 3210	A. Hannan, Routingloop
Catégorie : Information	X. Xiao, Photuris
Traduction Claude Brière de L'Isle	décembre 2001

Déclaration d'applicabilité des extensions à RSVP pour tunnels LSP

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Le présent mémoire 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 (2001). Tous droits réservés.

Résumé
Le présent mémoire discute de l'applicabilité des "extensions à RSVP (protocole de réservation de ressources) pour les tunnels LSP". Il souligne les principes de fonctionnement du protocole et décrit le contexte de réseau pour lequel il a été conçu. Des lignes directrices pour le déploiement sont proposées et les limitations connues du protocole sont indiquées. Le présent document est destiné à accompagner la soumission des "Extensions à RSVP pour les tunnels LSP" sur la voie de la normalisation de l'Internet.
Table des matières
1. Introduction	1
2. Revue technique des extensions à RSVP pour les tunnels LSP	2
3. Applicabilité des extensions à RSVP pour les tunnels LSP	2
4. Considérations de déploiement et de politique	3
5. Limitations	3
6. Conclusion	4
7. Considérations sur la sécurité	4
8. Remerciements	4
9. Références	4
10. Adresse des auteurs	4
11. Déclaration complète de droits de reproduction	5

 	1.	Introduction

Les fournisseurs de services et les utilisateurs ont indiqué qu'il y a un grand besoin de capacités d'ingénierie du trafic dans les réseaux IP. Ces capacités d'ingénierie du trafic peuvent être fondées sur la commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching) et peuvent être mises en œuvre sur les routeurs de commutation d'étiquettes (LSR, Label Switching Router) provenant de différents fabricants qui inter opèrent en utilisant une signalisation et un protocole de distribution d'étiquettes communs. Une description des exigences pour l'ingénierie du trafic dans les réseaux IP fondés sur MPLS se trouve dans la [RFC2702]. Il y a donc une exigence d'une signalisation et d'un protocole de distribution d'étiquettes ouverts, non propriétaires, fondés sur des normes, pour l'application d'ingénierie du trafic MPLS, qui vont permettre aux routeurs de commutation d'étiquettes provenant de fabricants différents d'interopérer.

La spécification "Extensions à RSVP pour les tunnels LSP" (RSVP-TE) [RFC3209] a été développée par le groupe de travail IETF MPLS pour traiter cette exigence. RSVP-TE est un composé de plusieurs propositions soumises au groupe de travail MPLS de l'IETF. Elle contient tous les objets nécessaires, formats de paquets, et procédures requises pour établir et conserver des chemins de commutation d'étiquettes (LSP, Label Switched Path) explicites. Les LSP explicites sont fondamentaux pour l'application de l'ingénierie du trafic dans les réseaux IP fondés sur MPLS. À côté de l'application de l'ingénierie du trafic, la spécification de RSVP-TE peut avoir d'autres utilisations au sein de l'Internet.

Le présent mémoire décrit l'applicabilité des spécifications de RSVP-TE [RFC3209]. Les principes de fonctionnement du protocole sont soulignés, le contexte de réseau pour lequel il a été développé est décrit, des lignes directrices de déploiement sont proposées, et les limitations connues du protocole sont indiquées.

Cette déclaration d'applicabilité concerne seulement l'utilisation de RSVP pour établir des tunnels LSP en envoi individuel.  Il est noté que toutes les caractéristiques décrites dans la [RFC2205] ne sont pas obligées de prendre en charge l'instanciation et la maintenance des tunnels LSP. Les aspects relatifs à la prise en charge d'autres caractéristiques et capacités de RSVP par une mise en œuvre qui prend aussi en charge les tunnels LSP sortent du domaine d'application de ce document. Cependant, la prise en charge de telles caractéristiques et capacités supplémentaires ne devrait pas introduire de nouvelles vulnérabilités de la sécurité dans des environnements qui utilisent RSVP seulement pour établir des tunnels LSP.

Cette déclaration d'applicabilité n'empêche pas l'utilisation d'autres protocoles de signalisation et de distribution d'étiquettes pour l'application de l'ingénierie du trafic dans les réseaux fondés sur MPLS. Les fournisseurs de services sont libres de déployer tout protocole de signalisation qui satisfait leurs besoins.

En particulier, CR-LDP [RFC3212] et RSVP-TE [RFC3209] sont deux protocoles de signalisation qui effectuent des fonctions similaires dans les réseaux MPLS. Il n'y a actuellement pas de consensus sur le protocole qui est techniquement supérieur. Donc, les administrateurs de réseaux devraient faire un choix entre les deux sur la base de leurs besoins et de leur situation particulière.

 	2.	Revue technique des extensions à RSVP pour les tunnels LSP

La spécification RSVP-TE étend le protocole RSVP original en lui donnant de nouvelles capacités qui prennent en charge les fonctions suivantes dans un domaine MPLS :
(1) distribution d'étiquettes vers l'aval à la demande
(2) instanciation de chemins de commutation d'étiquettes explicites
(3) allocation de ressources réseau (par exemple, bande passante) à des LSP explicites
(4) réacheminement de tunnels LSP établis en douceur en utilisant le concept de "faire avant de casser"
(5) traçage du chemin réel traversé par un tunnel LSP
(6) diagnostics sur les tunnels LSP
(7) concept de nœud abstrait
(8) options de préemption contrôlables administrativement

La spécification RSVP-TE introduit plusieurs nouveaux objets RSVP, incluant l'objet LABEL-REQUEST, l'objet RECORD-ROUTE, l'objet LABEL, l'objet EXPLICIT-ROUTE, et les nouveaux objets SESSION. De nouveaux messages  d'erreur sont définis pour fournir des notifications de conditions d'exception. Tous les nouveaux objets définis dans RSVP-TE sont facultatifs par rapport au protocole RSVP, sauf les objets LABEL-REQUEST et LABEL, qui sont tous deux obligatoires pour l'établissement des tunnels LSP.

Deux aspects fondamentaux distinguent la spécification RSVP-TE [RFC3209] du protocole RSVP original [RFC2205].

Le premier aspect distinctif est le fait que la spécification RSVP-TE [RFC3209] est destinée à être utilisée par les routeurs de commutation d'étiquettes (ainsi que les hôtes) pour établir et maintenir les tunnels LSP et pour réserver les ressources du réseau pour ces tunnels LSP. La spécification originale RSVP [RFC2205] était par ailleurs destinée à être utilisée par les hôtes pour demander et réserver les ressources du réseau pour des micro flux.

Le second aspect distinctif est le fait que la spécification RSVP-TE généralise le concept de "flux RSVP". La spécification RSVP-TE permet essentiellement qu'une session RSVP consiste en une agrégation arbitraire de trafic (sur la base de la politique locale) entre le nœud d'origine d'un tunnel LSP et le nœud de sortie du tunnel. Dans le protocole RSVP original [RFC2205], une session était définie comme un flux de données avec un protocole particulier de destination et de couche transport. Dans la spécification RSVP-TE, une session est implicitement définie comme l'ensemble de paquets auquel est allouée la même valeur d'étiquette MPLS au nœud d'origine d'un tunnel LSP. L'allocation des étiquettes aux paquets peut être fondée sur divers critères, et peut même englober tous les paquets (ou sous ensembles d'entre eux) entre les points d'extrémité du tunnel LSP. Parce que le trafic est agrégé, le nombre de tunnels LSP (et donc le nombre de sessions RSVP) n'augmente pas proportionnellement avec le nombre de flux dans le réseau. Donc, la spécification RSVP-TE [RFC3209] s'adresse à un problème majeur d'adaptabilité du protocole RSVP original [RFC2205], à savoir la grande quantité de ressources de système qui serait autrement nécessaire pour gérer les réservations et conserver l'état pour potentiellement des milliers ou même des millions de sessions RSVP à la granularité des micro flux.

Le lecteur se reportera à la [RFC3209] pour une description technique de la spécification du protocole RSVP-TE.

 	3.	Applicabilité des extensions à RSVP pour les tunnels LSP

L'utilisation de RSVP-TE est appropriée dans les contextes où il est utile d'établir et maintenir des chemins explicites de commutation d'étiquettes dans un réseau MPLS. Les tunnels LSP peuvent être instanciés dans un but de mesure et/ou de contrôle de l'acheminement. Ils peuvent aussi être instanciés pour d'autres raisons administratives.

Pour l'application de mesures, un tunnel LSP peut être utilisé pour capturer diverses statistiques de chemin entre ses points d'extrémité. Ceci peut être réalisé en associant diverses fonctions de gestion des performances et des fautes à un tunnel LSP, comme un compteur de paquets et d'octets. Par exemple, un tunnel LSP peut être instancié, avec ou sans allocation de bande passante, seulement dans le but de surveiller les statistiques de flux de trafic entre deux routeurs de commutation d'étiquettes.

Pour l'application de contrôle de l'acheminement, les tunnels LSP peuvent être utilisés pour transmettre des sous ensembles du trafic à traves des chemins qui sont indépendants des chemins calculés par les algorithmes conventionnels de plus court chemin en premier (SPF, Shortest Path First) du protocole de passerelle intérieure (IGP, Interior Gateway Protocol). Ce dispositif introduit une souplesse significative dans la fonction d'acheminement et permet de mettre en œuvre des politiques qui peuvent résulter en l'optimisation des performances des réseaux opérationnels. Par exemple, en utilisant des tunnels LSP, le trafic peut être acheminé en dehors de ressources réseau encombrées sur d'autres relativement inutilisées. Plus généralement, des politiques d'équilibrage de charge peuvent être actualisées pour augmenter la capacité effective du réseau.

Pour encore améliorer l'application de contrôle, RSVP-TE peut être augmenté avec une entité auxiliaire d'acheminement fondé sur la contrainte. Cette entité peut calculer des chemins explicites sur la base de certains attributs de trafic, tout en prenant en compte les contraintes du réseau. De plus, les annonces d'état de liaison de IGP peuvent être étendues pour propager les nouvelles informations d'état de la topologie. Ces informations peuvent être utilisées par l'entité d'acheminement fondé sur la contrainte pour calculer les chemins praticables. De plus, l'algorithme d'acheminement IGP peut lui-même être amélioré pour prendre en compte les tunnels LSP pré établis lors de la construction du tableau d'acheminement. Toutes ces augmentations sont utiles, mais pas obligatoires. En fait, la spécification RSVP-TE peut être déployée dans certains contextes sans aucun de ces composants supplémentaires.

La capacité de surveiller les statistiques de trafic en point à point entre deux routeurs et la capacité de contrôler les chemins de transmission de sous ensembles du trafic à travers une topologie de réseau donnée rendent ensemble les spécifications de RSVP-TE applicables et utiles pour l'ingénierie du trafic au sein des réseaux de fournisseurs de services.

Ces capacités rendent aussi RSVP-TE applicable, dans certains contextes, comme un composant d'un cadre de provisionnement de VPN fondé sur MPLS.

Il est significatif que l'architecture MPLS [RFC3031] déclare clairement qu'aucun protocole de distribution d'étiquettes seul n'est supposé pour la technologie MPLS. Donc, comme noté dans l'introduction, la présente déclaration d'applicabilité n'empêche pas (et ne devrait pas être conçue pour) un routeur de commutation d'étiquettes de mettre en œuvre d'autres protocoles de signalisation et de distribution d'étiquettes qui prennent aussi en charge l'établissement de LSP explicites et d'ingénierie du trafic dans les réseaux MPLS.

 	4.	Considérations de déploiement et de politique

Lors du déploiement de RSVP-TE, il devrait y avoir des politiques administratives bien définies pour gouverner le choix des nœuds qui vont servir de points d'extrémité des tunnels LSP. De plus, lors de la construction d'une topologie virtuelle pour les tunnels LSP, une considération particulière devrait être portée au compromis entre la complexité opérationnelle associée à un grand nombre de tunnels LSP et la granularité du contrôle permise par ce grand nombre de tunnels LSP. Dit autrement, un grand nombre de tunnels LSP permet un plus grand contrôle sur la distribution du trafic à travers le réseau, mais augmente la complexité  du fonctionnement du réseau. Dans les grands réseaux, il peut être conseillé de commencer avec une topologie simple de tunnels LSP virtuels puis d'introduire de la complexité sur la base des schémas de flux de trafic observés ou prévus.

Des politiques administratives peuvent aussi guider la quantité de bande passante à allouer (si il en est) à chaque tunnel LSP. Des politiques de ce type peuvent prendre en considération des statistiques empiriques de trafic déduites du fonctionnement du réseau en plus d'autres facteurs.

 	5.	Limitations

La spécification RSVP-TE prend en charge seulement les tunnels LSP en envoi individuel. Les tunnels LSP en diffusion groupée ne sont pas pris en charge.

La spécification RSVP-TE prend en charge seulement les tunnels LSP unidirectionnels. Les tunnels LSP bidirectionnels ne sont pas pris en charge.

La nature molle de RSVP reste une source d'inquiétude à cause du besoin de générer périodiquement des messages de rafraîchissement pour conserver l'état des tunnels LSP établis. Ce problème est traité dans plusieurs propositions qui ont été soumises au groupe de travail RSVP (voir par exemple la [RFC2961]).

 	6.	Conclusion

L'applicabilité de la spécification "Extensions à RSVP pour les tunnels LSP" a été discutée dans le présent document. La spécification a introduit plusieurs améliorations au protocole RSVP, qui la rendent applicable dans des contextes dans lesquels le protocole RSVP original aurait été inapproprié. Un contexte dans lequel la spécification RSVP-TE est particulièrement applicable est dans l'ingénierie du trafic dans les réseaux IP fondés sur MPLS.

 	7.	Considérations sur la sécurité

Le présent document n'introduit aucune nouvelle question de sécurité. La spécification RSVP-TE ajoute de nouveaux objets opaques à RSVP. Donc, les considérations sur la sécurité relevant du protocole RSVP original restent pertinentes. Lorsque déployé dans des réseaux de fournisseur de services, il est obligatoire de s'assurer que seules des entités autorisées ont la permission d'initier l'établissement de tunnels LSP.

 	8.	Remerciements

Les auteurs remercient chaleureusement de leurs utiles commentaires reçus les personnes suivantes durant la relecture initiale de ce mémoire sur la liste de diffusion du groupe de travail MPLS : Eric Gray, John Renwick, et George Swallow.

 	9.	Références

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

[RFC2702]	D. Awduche et autres, "Exigences d'ingénierie du trafic sur MPLS", septembre 1999. (Information)

[RFC2961]	L. Berger et autres, "Extensions de réduction de redondance de rafraîchissement pour RSVP", avril 2001. (MàJ par RFC5063) (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)

[RFC3212]	B. Jamoussi et autres, "Établissement de LSP fondé sur la contrainte avec LDP", janvier 2002. (MàJ par RFC3468) (P.S.)

 	10.	Adresse des auteurs

Daniel O. Awduche	Alan Hannan	XiPeng Xiao	
Movaz Networks	RoutingLoop	Photuris Inc.	
7926 Jones Branch Drive, Suite 615	112 Falkirk Court	2025 Stierlin Ct.	
McLean, VA 22102	Sunnyvale, CA 94087	Mountain View, CA 94043	
mél : awduche@movaz.com 	mél : alan@routingloop.com 	mél : xxiao@photuris.com 	
téléphone : +1 703-298-5291	téléphone : +1 408 666-2326	téléphone : +1 650-919-3215	

 	11.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2001). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant 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.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.