Groupe de travail Réseau	B. Thomas, Cisco Systems, Inc.
Request for Comments: 3037	E. Gray, Zaffire, Inc.
Catégorie : Information	janvier 2001
Traduction Claude Brière de L'Isle

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

Résumé
La commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching) est une méthode pour transmettre des paquets qui utilise de courtes valeurs de longueur fixe portées par les paquets, appelées des étiquettes, pour déterminer le prochain bond du paquet. Un concept fondamental de MPLS est que deux routeurs de commutation d'étiquettes (LSR, Label Switching Router) doivent s'accorder sur la signification des étiquettes utilisées pour transmettre du trafic entre et à travers eux. Cette compréhension commune est réalisée en utilisant un ensemble de procédures, appelées un protocole de distribution d'étiquettes, par lequel un LSR en informe un autre des liens d'étiquettes qu'il fait. Le présent document décrit l'applicabilité d'un ensemble de telles procédures appelé protocole de distribution d'étiquettes (LDP, Label Distribution Protocol) par lequel les LSR distribuent les étiquettes pour prendre en charge la transmission MPLS le long de chemins acheminés normalement.
Table des matières
1. Applicabilité de LDP	1
2. Niveau d'exigence	2
3. Vue d'ensemble des caractéristiques	2
4. Considérations d'adaptabilité	3
5. Considérations sur la sécurité	3
6. Références	3
7. Adresse des auteurs	4
8. Déclaration complète de droits de reproduction	4

 	1.	Applicabilité de LDP

Un protocole de distribution d'étiquettes est un ensemble de procédures par lequel un routeur de commutation d'étiquettes (LSR, Label Switching Router) en informe un autre de la signification des étiquettes utilisées pour transmettre du trafic entre et à travers eux.

L'architecture MPLS permet la possibilité de plus d'une seule méthode de distribution d'étiquettes, et un certain nombre de protocoles de distribution d'étiquettes différents sont normalisés. Les protocoles existants ont été étendus afin que la distribution d'étiquettes puisse être portée sur eux, et de nouveaux protocoles ont été définis dans ce but explicite de distribution d'étiquettes.

Le présent document décrit l'applicabilité du protocole de distribution d'étiquettes (LDP, Label Distribution Protocol) nouveau protocole pour la distribution d'étiquettes conçu pour prendre charge la distribution d'étiquettes pour la transmission MPLS le long de chemins à acheminement normal, comme déterminé par les protocoles d'acheminement fondé sur la destination. Cela est parfois appelé la transmission MPLS bond par bond.

LDP, conjointement avec un plan d'acheminement IP et un logiciel pour programmer les tableaux d'interconnexion de commutateur ATM ou de relais de trame, peut mettre en œuvre IP dans un réseau de commutateurs ATM et/ou de relais de trame sans exiger un recouvrement ou l'utilisation d'un adressage ou acheminement spécifique de ATM ou de relais de trame.

LDP est aussi utile dans des situations qui exigent des tunnels acheminés efficacement bond par bond, comme des architectures de VPN fondées sur MPLS [RFC2547] et le tunnelage entre des routeurs frontières BGP.

De plus, LDP inclut un mécanisme qui rend possible son extension à la prise en charge de caractéristiques MPLS qui vont au delà de la transmission bond par bond au mieux.

Un protocole autonome pour distribuer les étiquettes LDP ne s'appuie pas sur la présence de protocoles d'acheminement spécifiques à chaque bond le long d'un chemin de LSP afin d'établir un LSP. Donc, LDP est utile dans des situations où un LSP doit traverser des nœuds qui peuvent ne pas du tout prendre en charge une approche commune de portage pour distribuer les étiquettes.

L'ingénierie du trafic (TE, Traffic Engineering) est supposée être une application MPLS importante. La prise en charge par MPLS de l'ingénierie du trafic utilise explicitement des LSP acheminés, qui n'ont pas besoin de suivre les chemins (bond par bond) d'acheminement normal.

Les LSP à acheminement explicite peuvent être établis par CR-LDP [RFC3213], un ensemble d'extensions à LDP, ou par RSVP-TE [RFC3210], un ensemble d'extensions à RSVP. Il n'y a actuellement pas de consensus sur lequel de ces protocoles 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 la situation.

 	2.	Niveau d'exigence

Le "niveau d'exigence" [RFC2026] pour LDP est :

La mise en œuvre de LDP est recommandée pour les appareils qui effectuent la transmission MPLS le long de chemins à acheminement normal, comme déterminé par les protocoles d'acheminement fondé sur la destination.

 	3.	Vue d'ensemble des caractéristiques

LDP associe une classe d'équivalence de transmission (FEC, Forwarding Equivalence Class) [RFC3031] à chaque étiquette qu'il distribue. Deux LSR qui utilisent LDP pour échanger des informations de lien entre FEC et étiquette sont appelés des "homologues LDP", et on dit qu'il y a une "session LDP" entre eux.

LDP utilise TCP pour la communication de sessions. L'utilisation de TCP assure que les messages de session sont livrés de façon fiable, et que les étiquettes distribuées et les information d'état associées aux LSP n'ont pas besoin d'être rafraîchies périodiquement.

LDP inclut un mécanisme par lequel un LSR peut découvrir de potentiels homologues LDP. Le mécanisme de découverte rend inutile que les opérateurs configurent explicitement chaque LSR avec ses homologues LDP.

Quand un LSR découvre un autre LSR, il suit la procédure d'établissement de session LDP pour établir une session LDP. Au moyen de cette procédure, les LSR établissent une connexion de session TCP et l'utilisent pour négocier les paramètres de la session, comme la méthode de distribution d'étiquettes à utiliser (voir ci-dessous). Après que les LSR se sont accordés sur les paramètres, la session est opérationnelle et les LSR utilisent la connexion TCP pour la distribution des étiquettes.

LDP supporte deux méthodes différentes pour la distribution des étiquettes. Un LSR qui utilise la distribution non sollicitée vers l'aval annonce les liens FEC-étiquette à son homologue quand il est prêt à transmettre des paquets dans la FEC au moyen de MPLS. Un LSR qui utilise la distribution vers l'aval à la demande fournit les liens FEC-étiquette à un homologue en réponse à des demandes spécifiques de l'homologue pour une étiquette pour la FEC.

LDP permet aux LSR de la souplesse dans les stratégies de conservation des étiquettes apprises. Un LSR qui utilise une rétention libérale d'étiquettes mémorise toutes les étiquettes apprises des homologues sans considération de si il en a actuellement besoin pour la transmission, tandis que celui qui utilise une rétention d'étiquettes prudente ne mémorise que les étiquettes dont il a l'usage immédiat et supprime les étiquettes inutiles annoncées par l'homologue.

De plus, LDP permet une souplesse dans les stratégies d'annonce des liens entre FEC et étiquette. Un LSR qui utilise un mode de contrôle indépendant annonce les liens FEC-étiquette aux homologues chaque fois que cela lui convient, tandis que celui qui utilise le contrôle ordonné n'annonce les liens que quand il a précédemment reçu une étiquette pour la FEC provenant du prochain bond de FEC ou qu'il est une sortie MPLS pour la FEC.

La distribution vers l'aval à la demande avec rétention d'étiquettes prudente et contrôle ordonné est appropriée dans les situations où les étiquettes sont une ressource relativement rare qui doit être préservée, et la distribution non sollicitée vers l'aval avec rétention libérale des étiquettes et contrôle indépendant est appropriée lorsque les étiquettes sont abondantes et n'ont pas besoin d'être conservées avec soin. Cependant, le protocole permet d'autres combinaisons de méthodes de distribution, de mode de rétention d'étiquette et de mode de contrôle, incluant des variantes hybrides.

LDP définit un mécanisme de détection de boucle pour protéger contre les boucles de transmission dans les LSP qui traversent des nuages MPLS sans TTL ; voir dans la [RFC3031] la discussion de situations qui peuvent trouver avantage à ce mécanisme. Le mécanisme de détection de boucle est facultatif au sens où il peut être désactivé par la configuration de LSR. Cependant, un LSR conforme à LDP doit le mettre en œuvre.

LDP inclut un mécanisme d'extension qui prend en charge le développement de caractéristiques de fabricant privé et expérimentales. Ce mécanisme définit des procédures pour introduire de nouveaux types de messages et TLV, méthodes qu'un LSR peut utiliser pour détecter de tels messages et TLV, et procédures qu'un LSR doit suivre quand il reçoit un message ou une TLV qu'il ne met pas en œuvre. Bien qu'il ne soit pas possible de rendre chaque amélioration future rétro compatible, ces procédures facilitent l'introduction de nouvelles capacités dans les réseaux MPLS qui incluent d'anciennes mises en œuvre qui ne les reconnaissent pas.

 	4.	Considérations d'adaptabilité

Les facteurs suivants peuvent influencer l'adaptabilité des mises en œuvre de LDP :

-	La distribution des étiquettes LDP est incrémentaire, n'exigeant pas de rafraîchissements périodiques des liens entre FEC et étiquette.

-	Dans les situations où les ressources d'étiquettes peuvent être rares (liaisons ATM et de relais de trame) l'utilisation de la méthode de distribution vers l'aval à la demande avec rétention prudente des étiquettes assure que seules les étiquettes nécessaires pour prendre en charge les chemins d'acheminement normal sont allouées et distribuées.

-	Dans les situations où les ressources d'étiquettes ne sont pas rares, l'utilisation de la méthode non sollicitée vers l'aval assure que des changements dans la FEC de prochain bond d'un homologue LDP à un autre n'exigent pas d'action de distribution pour mettre à jour les étiquettes distribuées précédemment.

-	Les limitations du nombre de connexions TCP qu'un LSR prend en charge limitent le nombre d'homologues LDP que le LSR peut supporter.

-	L'utilisation du vecteur de chemin facultatif fondé sur le mécanisme de détection de boucle impose des exigences supplémentaires de mémoire et de traitement à un LSR, ainsi que du trafic LDP supplémentaire. Les deux impactent l'adaptabilité.

 	5.	Considérations sur la sécurité

LDP définit l'utilisation facultative de l'option TCP Signature MD5 pour protéger contre l'introduction de segments TCP usurpés dans les flux de connexion de session LDP. L'utilisation par LDP de l'option TCP Signature MD5 est similaire à l'utilisation par BGP [RFC1771] de l'option spécifiée dans la [RFC2385].

 	6.	Références

[RFC1771]	Y. Rekhter, T. Li , "Protocole de routeur frontière v. 4 (BGP-4)", mars 1995. (Obsolète, voir RFC4271) (D.S.)

[RFC2026]	S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, 3668, 3932, 3979, 3978, 5378, 6410, 8179, 8789)

[RFC2385]	A. Heffernan, "Protection des sessions de BGP via l'option de signature MD5 de TCP", août 1998. (P.S. ; MàJ par la RFC6691 ; remplacée par RFC5925)

[RFC2547]	E. Rosen, Y. Rekhter, "VPN BGP/MPLS", mars 1999. (Obsolète, voir RFC4364) (Information)

[RFC3031]	E. Rosen, A. Viswanathan, R. Callon, "Architecture de commutation d'étiquettes multi protocoles", janvier 2001. (P.S.) (MàJ par la RFC6790)

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

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

[RFC3213]	J. Ash et autres, "Déclaration d'applicabilité pour CR-LDP", janvier 2002. (Information)

 	7.	Adresse des auteurs

Eric Gray	Bob Thomas	
Zaffire, Inc	Cisco Systems, Inc.	
2630 Orchard Parkway,	250 Apollo Dr.	
San Jose, CA 95134-2020	Chelmsford, MA 01824	
téléphone :  408-894-7362	téléphone :  978-244-8078	
mél : ewgray@mindspring.com 	mél : rhthomas@cisco.com	

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