1. Aperçu de LDP

L'architecture MPLS [RFC3031] définit un protocole de distribution d'étiquettes comme un ensemble de procédures par lesquelles un routeur à commutation d'étiquettes (Label Switched Router, LSR) informe un autre LSR de la signification des étiquettes utilisées pour transférer le trafic entre eux et à travers eux.

L'architecture MPLS ne suppose pas un protocole de distribution d'étiquettes unique. En fait, un certain nombre de protocoles de distribution d'étiquettes différents sont en cours de normalisation. Des protocoles existants ont été étendus afin que la distribution d'étiquettes puisse leur être greffée. De nouveaux protocoles ont également été définis dans le but explicite de distribuer des étiquettes. L'architecture MPLS examine certaines des considérations liées au choix d'un protocole de distribution d'étiquettes à utiliser dans des applications MPLS particulières telles que l'ingénierie de trafic (Traffic Engineering) [RFC2702].

Le protocole de distribution d'étiquettes (Label Distribution Protocol, LDP) est un protocole défini pour distribuer des étiquettes. Il a été publié à l'origine sous le nom de RFC 3036 en janvier 2001. Il a été produit par le groupe de travail MPLS de l'IETF et a été rédigé conjointement par Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette et Bob Thomas.

LDP est un protocole défini pour distribuer des étiquettes. C'est l'ensemble des procédures et des messages par lesquels les routeurs à commutation d'étiquettes (LSR) établissent des chemins à commutation d'étiquettes (Label Switched Path, LSP) à travers un réseau en faisant correspondre directement les informations de routage de la couche réseau à des chemins commutés de la couche liaison de données. Ces LSP peuvent avoir une extrémité au niveau d'un voisin directement rattaché (comparable au transfert IP saut par saut), ou peuvent avoir une extrémité au niveau d'un nœud de sortie du réseau, permettant ainsi la commutation via tous les nœuds intermédiaires.

LDP associe une classe d'équivalence de transfert (Forwarding Equivalence Class, FEC) [RFC3031] à chaque LSP qu'il crée. La FEC associée à un LSP spécifie quels paquets sont "mappés" à ce LSP. Les LSP sont étendus à travers un réseau à mesure que chaque LSR "épisse" les étiquettes entrantes d'une FEC à l'étiquette sortante attribuée au saut suivant pour la FEC considérée.

De plus amples informations sur l'applicabilité de LDP se trouvent dans [RFC3037].

Ce document suppose (mais n'exige pas) une familiarité avec l'architecture MPLS [RFC3031]. Notez que [RFC3031] inclut un glossaire de la terminologie MPLS, telle que ingress, label switched path, etc.

1.1. Pairs LDP

Deux LSR qui utilisent LDP pour échanger des informations de mappage étiquette/FEC sont appelés "pairs LDP" (LDP Peers) relativement à ces informations, et on parle alors d'une "session LDP" (LDP Session) entre eux. Une session LDP unique permet à chaque pair d'apprendre les mappages d'étiquettes de l'autre ; autrement dit, le protocole est bidirectionnel.

1.2. Échange de messages LDP

Il existe quatre catégories de messages LDP :

1. Messages de découverte (Discovery), utilisés pour annoncer et maintenir la présence d'un LSR dans un réseau.

2. Messages de session (Session), utilisés pour établir, maintenir et terminer des sessions entre pairs LDP.

3. Messages d'annonce (Advertisement), utilisés pour créer, modifier et supprimer des mappages d'étiquettes pour des FEC.

4. Messages Notification, utilisés pour fournir des informations à titre indicatif et pour signaler des informations d'erreur.

Les messages de découverte fournissent un mécanisme par lequel les LSR indiquent leur présence dans un réseau en envoyant périodiquement un message Hello. Celui-ci est transmis sous forme de paquet UDP vers le port LDP à l'adresse de groupe multicast 'all routers on this subnet'. Lorsqu'un LSR choisit d'établir une session avec un autre LSR découvert via le message Hello, il utilise la procédure d'initialisation LDP sur le transport TCP. Une fois la procédure d'initialisation terminée avec succès, les deux LSR sont des pairs LDP et peuvent échanger des messages d'annonce.

Le moment où demander une étiquette ou annoncer un mappage d'étiquettes à un pair est en grande partie une décision locale prise par un LSR. En général, le LSR demande un mappage d'étiquettes à un LSR voisin lorsqu'il en a besoin, et annonce un mappage d'étiquettes à un LSR voisin lorsqu'il souhaite que le voisin utilise une étiquette.

Le bon fonctionnement de LDP exige une livraison fiable et dans l'ordre des messages. Pour satisfaire à ces exigences, LDP utilise le transport TCP pour les messages Session, Advertisement et Notification, c'est-à-dire pour tout sauf le mécanisme de découverte fondé sur UDP.

1.3. Structure des messages LDP

Tous les messages LDP ont une structure commune qui utilise un schéma d'encodage type-longueur-valeur (Type-Length-Value, TLV) ; voir la section "Type-Length-Value Encoding". La partie Value d'un objet encodé en TLV, ou TLV en abrégé, peut elle-même contenir un ou plusieurs TLV.

1.4. Traitement des erreurs LDP

Les erreurs LDP et les autres événements dignes d'intérêt sont signalés à un pair LDP par des messages Notification.

Il existe deux sortes de messages Notification LDP :

1. Les Error Notifications, utilisées pour signaler des erreurs fatales. Si un LSR reçoit une Error Notification d'un pair pour une session LDP, il termine la session LDP en fermant la connexion TCP de transport de la session et en écartant tous les mappages d'étiquettes appris via la session.

2. Les Advisory Notifications, utilisées pour transmettre des informations au LSR sur la session LDP ou sur l'état d'un message précédemment reçu du pair.

1.5. Extensibilité et compatibilité future de LDP

Des fonctionnalités peuvent être ajoutées à LDP à l'avenir. Il est probable que les fonctionnalités futures utiliseront de nouveaux messages et de nouveaux types d'objets (TLV). Il peut être souhaitable d'employer de tels nouveaux messages et TLV dans un réseau utilisant des implémentations plus anciennes qui ne les reconnaissent pas. Bien qu'il ne soit pas possible de rendre chaque amélioration future rétrocompatible, une certaine planification préalable peut faciliter l'introduction de nouvelles capacités. À cette fin, la présente spécification définit des règles de traitement des types de messages inconnus et des TLV inconnus.

1.6. Langage de spécification

Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans [RFC2119].