Groupe de travail Réseau	J. Ash, AT&T
Request for Comments: 3213	M. Girish, Atoga Systems
Catégorie : Information	E. Gray, Sandburst
Traduction Claude Brière de L'Isle	G. Wright, Nortel Networks
	B. Jamoussi, Nortel Networks
	janvier 2002

Déclaration d'applicabilité pour CR-LDP

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 (2002). Tous droits réservés.

Résumé
Le présent document discute de l'applicabilité de l'établissement de LSP fondé sur la contrainte en utilisant LDP. Il discute les applications réseau possibles, les extensions au protocole de distribution d'étiquettes (LDP, Label Distribution Protocol) requises pour mettre en œuvre l'acheminement fondé sur la contrainte, les lignes directrices pour le déploiement, et les limitations connues du protocole. Le présent document est un pré requis pour l'avancement de CR-LDP sur la voie de la normalisation.
Table des matières
1. Introduction	1
2. Applicabilité des extensions à LDP	2
3. Considérations de mise en œuvre et de déploiement en relation avec LDP	2
4. Limitations	3
5. Considérations sur la sécurité	3
6. Remerciements	3
7. Références	3
7. Adresse des auteurs	4
9. Déclaration complète de droits de reproduction	4

 	1.	Introduction

Avec l'évolution de l'Internet, des capacités supplémentaires sont requises pour assurer un traitement approprié des données [RFC2702], de la voix, de la vidéo et autres trafics sensibles au délai [RFC3214]. MPLS améliore l'acheminement de source et permet certaines techniques, utilisées dans la commutation de circuits, dans les réseaux IP. Cela permet une approche adaptable pour traiter ces diverses exigences de transmission. CR-LDP [RFC3212] est un protocole de signalisation simple, adaptable, ouvert, non propriétaire, d'ingénierie du trafic pour les réseaux IP MPLS.

CR-LDP fournit des mécanismes pour établir des chemins de commutation d'étiquettes (LSP, Label Switched Path) acheminés explicitement. Ces mécanismes sont définis comme des extensions à LDP [RFC3036]. Parce que LDP est un protocole d'homologue à homologue fondé sur l'établissement et la maintenance de sessions TCP, il procure les avantages naturels suivants :

-	les messages CR-LDP sont livrés de façon fiable par le TCP sous-jacent, et les informations d'état associées aux LSP acheminés explicitement n'exigent pas de rafraîchissement périodique.

-	les messages CR-LDP sont en flux contrôlés (régulateur) à travers TCP.

CR-LDP est spécifiquement défini pour l'établissement et le maintien des LSP à acheminement explicite. Les capacités supplémentaires facultatives incluses ont un impact minimal sur les performances et les exigences du système quand elles ne sont pas utilisées pour un LSP à acheminement explicite spécifique. Les capacités facultatives permettent la négociation des paramètres des services LSP et de gestion du trafic sur et au-dessus de la livraison au mieux des paquets incluant l'allocation de bande passante, l'établissement et la conservation des priorités. CR-LDP permet facultativement que ces paramètres soit modifiés dynamiquement sans interrompre le fonctionnement du LSP (en service) [RFC3214].

CR-LDP permet la spécification d''un ensemble de paramètres à signaler avec la demande d'établissement de LSP. De plus, le réseau peut être provisionné avec un ensemble de fonctions de conditionnement de trafic de bordure (qui pourraient inclure le marquage, la métrique, la régulation et le formatage). Cet ensemble de paramètres avec la spécification des fonctions de conditionnement de bordure peut être assez adéquat et puissant pour décrire, caractériser et paramétrer une grande variété de scénarios de qualité de service et de services incluant les services différenciés IP [RFC3475], les services intégrés [RFC2215], les classes de service ATM [ATM-TMS], et le relais de trame [I.370].

CR-LDP est conçu pour prendre adéquatement en charge les divers types de supports que MPLS a été conçu pour prendre en charge (ATM, relais de trame, Ethernet, PPP, etc.). Donc, il va fonctionner également bien pour les réseaux commutés multi services, les réseaux de routeurs, ou les réseaux hybrides.

Cette déclaration d'applicabilité n'empêche pas l'utilisation d'autres protocoles de signalisation et de distribution d'étiquettes pour l'application d'ingénierie du trafic dans des 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 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 quel protocole est techniquement supérieur. Donc, les administrateurs de réseau devraient faire un choix entre les deux sur la base de leurs besoins et de leur situation particulière. L'applicabilité de RSVP-TE est décrite dans la [RFC3210].

 	2.	Applicabilité des extensions à LDP

Pour assurer la prise en charge de services de LSP supplémentaires, les extensions à CR-LDP sont définies de façon à être directement traduisibles en objets et messages utilisés dans les autres protocoles définis pour fournir des services similaires [RFC3209]. Les mises en œuvre peuvent tirer aussi parti de cela pour :

-	Établir des LSP pour la fourniture d'un service agrégé associé aux services fournis via ces autres protocoles.

-	Traduire directement les messages de protocole pour fournir les services définis dans une portion non CR-LDP du réseau.

-	Décrire, caractériser et paramétrer une grande variété de scénarios et services de qualité de service incluant les services différenciés IP, les services intégrés, les classes de service ATM, et le relais de trame.

Les informations d'état ferme requises pour la maintenance appropriée d'un LSP peuvent faire 200 octets ou moins. Il n'est pas déraisonnable de prévoir qu'une mise en œuvre de CR-LDP peut prendre en charge plus de cent mille ou un million de LSP à travers un seul routeur de commutation d'étiquettes (LSR, Label Switching Router) dans des conditions très stables.

Parce que CR-LDP fournit de faibles frais généraux par LSP – à la fois en termes d'informations d'état nécessaires et de trafic de contrôle - CR-LDP est applicable aux portions de l'Internet où de très grands nombres de LSP peuvent devoir être commutés à chaque LSR. Un exemple serait celui de grands cœurs de réseau utilisant MPLS exclusivement pour transporter de très grands nombres de flux de trafic entre un nombre modérément grand de nœuds de bordure MPLS.

CR-LDP peut aussi être applicable comme service médiateur entre des réseaux fournissant des extensions de service similaires utilisant des modèles de signalisation très variés.

 	3.	Considérations de mise en œuvre et de déploiement en relation avec LDP

LDP spécifie les modes suivants de distribution et gestion d'étiquettes (qui peuvent être combinés de diverses façons logiques décrites dans LDP) :
- Distribution d'étiquettes vers l'aval à la demande
- Distribution d'étiquettes vers l'aval non sollicitée
- Contrôle indépendant de distribution d'étiquettes
- Contrôle ordonné de distribution  d'étiquettes
- Mode prudent de rétention d'étiquettes
- Mode libéral de rétention d'étiquettes

L'applicabilité de LDP est décrite dans la [RFC3037].

Dans les réseaux où seuls des LSP à ingénierie du trafic sont nécessaires, la mise en œuvre et le déploiement de CR- LDP n'exige pas toutes les fonctionnalités définies dans la spécification de LDP. Les messages de base Découverte, Session, et Notification sont exigés. Cependant, CR-LDP exige une combinaison spécifique de modes de distribution d'étiquettes : la distribution ordonnée d'étiquettes vers l'aval à la demande et le mode de rétention prudent d'étiquettes.

Bien que CR-LDP soit défini comme une extension à LDP, la prise en charge des modes d'annonce d'étiquette non sollicitée vers l'aval et de contrôle indépendant n'est pas exigée pour les chemins explicites stricts. De plus, les mises en œuvre de CR-LDP PEUVENT être capables de prendre en charge les chemins explicites lâches via l'utilisation de "nœuds abstraits" et/ou "acheminement hiérarchique explicite", sans utiliser LDP pour l'établissement de LSP bond par bond.

CR-LDP inclut aussi la prise en charge de chemins explicites lâches. L'utilisation de cette capacité permet à l'opérateur de réseau de définir un "chemin explicite" à travers des portions de son réseau avec une connaissance imparfaite de la topologie entière du réseau. Une utilisation appropriée de cette capacité peut aussi permettre aux mises en œuvre de CR-LDP d'inter-opérer avec des mises en œuvre "imparfaites" de LDP – en particulier si on désire établir un LSP explicitement acheminé pour une livraison de paquet au mieux via un chemin à définition lâche.

Finalement, dans des réseaux où sont requis à la fois des LSP à acheminement dirigé par un protocole (autrement dit un LSP bond par bond) et des LSP à ingénierie du trafic, un seul protocole (LDP, avec les extensions définies dans CR-LDP) peut être utilisé pour les LSP TE et bond par bond. De nouveaux protocoles n'ont pas à être introduits dans le réseau pour fournir la signalisation de LSP TE.

 	4.	Limitations

La spécification CR-LDP prend seulement en charge les LSP en point à point. Le multipoint à point et le point à multipoint sont pour étude ultérieure.

La spécification CR-LDP prend seulement en charge l'établissement de LSP unidirectionnels. L'établissement de LSP bidirectionnels fera l'objet d'études ultérieures.

La spécification CR-LDP prend seulement en charge une unique allocation d'étiquette par établissement de LSP. Les allocations de plusieurs étiquettes par établissement de LSP feront l'objet d'études ultérieures.

 	5.	Considérations sur la sécurité

Aucune question de sécurité supplémentaire n'est introduite dans ce document. Comme extension à LDP, CR-LDP partage les soucis de sécurité associés à LDP.

 	6.	Remerciements

Les auteurs remercient les personnes suivantes de leur relecture attentive du document et de leurs commentaires : Loa Andersson, Peter Ashwood-Smith, Anoop Ghanwani, Juha Heinanen, Jon Weil et Adrian Farrel.

 	7.	Références

[ATM-TMS]	ATM Forum "Traffic Management Specification Version 4.1" (AF-TM-0121.000), mars 1999.

[I.370]	Recommandation UIT-T I.370, "Gestion d'encombrement pour le service support de relais de trame RNIS", Union Internationale des Télécommunications, Genève, 1991.

[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. (P.S.)

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

[RFC3036]	L. Andersson et autres, "Spécification de LDP", janvier 2001. (Obsolète, voir la RFC5036)

[RFC3037]	B. Thomas, E. Gray, "Conditions d'application de LDP", janvier 2001. (Information)

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

[RFC3210]	D. Awduche, A. Hannan, X. Xiao, "Déclaration d'applicabilité pour les extensions à RSVP pour tunnels LSP", décembre  2001. (Information)

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

[RFC3214]	J. Ash et autres, "Modification de LSP avec les CR-LDP", janvier 2002. (P.S.)

[RFC3475]	O. Aboul-Magd, "Documentation des allocations de l'IANA pour l'établissement de LSP fondés sur les contraintes en utilisant LDP (CR-LDP) Extensions pour réseau optique à commutation automatique (ASON)", mars 2003. (MàJ par RFC3468) (Information)

 	7.	Adresse des auteurs

Gerald R. Ash	Eric Gray	
AT&T	Sandburst	
Room MT D5-2A01	600 Federal Drive	
200 Laurel Avenue	Andover, MA  01810	
Middletown, NJ 07748	USA	
USA	téléphone : (978) 689-1610	
téléphone : 732-420-4578	mél : eric.gray@sandburst.com 	
mél : gash@att.com 		

Gregory Wright	M. K. Girish	Bilel Jamoussi	
Nortel Networks Corp.	Atoga Systems	Nortel Networks Corp.	
P O Box 3511 Station C	49026 Milmont Drive	600 Technology Park Drive	
Ottawa, ON K1Y 4H7	Fremont, CA 94538	Billerica, MA 01821	
Canada	USA	USA	
téléphone : +1 613 765-7912	mél : muckai@atoga.com 	téléphone: +1 978-288-4506	
mél : gwright@nortelnetworks.com 		mél : Jamoussi@nortelnetworks.com 	

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

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