Groupe de travail Réseau	L. Andersson, éditeur,  Acreo AB	
Request for Comments : 5036	I. Minei, éditeur, Juniper Networks	
RFC rendue obsolète : 3036	B. Thomas, éditeur, Cisco Systems, Inc.	
Catégorie : Sur la voie de la normalisation	octobre 2007	
Traduction Claude Brière de L'Isle		

Spécification du protocole de distribution d'étiquettes (LDP)

Statut du présent mémoire
Le présent document spécifie un protocole Internet sur la voie de la 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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé
L'architecture de commutation d'étiquette multi-protocoles (MPLS, Multiprotocol Étiquette Switching) est décrite dans la RFC  3031. Un concept fondamental de MPLS est que deux routeurs de commutation d'étiquettes (LSR, Étiquette Switching Router) doivent se mettre d'accord sur la signification des étiquettes utilisées pour transmettre le trafic entre et à travers eux. Cette compréhension commune est réalisée en utilisant un ensemble de procédures, appelé un protocole de distribution d'étiquettes, par lequel un LSR en informe un autre des liaisons d'étiquettes qu'il a faites. Le présent document définit un ensemble de telles procédures appelé protocole de distribution d'étiquettes (LDP, Label Distribution Protocol) par lesquelles les LSR distribuent les étiquettes pour la prise en charge de la transmission MPLS le long de chemins normaux.
Table des Matières
1. Généralités sur LDP	2
1.1 Homologues LDP	2
1.2 Échange de messages LDP	3
1.3 Structure du message LDP	3
1.4 Traitement des erreurs dans LDP	3
1.5 Extensibilité et compatibilité future de LDP	3
1.6 Langage de spécification	3
2. Fonctionnement de LDP	4
2.1 Les classes d’équivalence de transmission	4
2.2 Espaces, identifiants, sessions, et transport d’étiquettes	4
2.3 Sessions LDP entre des LSR non directement connectés	5
2.4 Découverte de LDP	5
2.5 Établissement et maintenance des sessions LDP	6
2.6 Distribution et gestion d’étiquettes	10
2.7 Identifiant LDP et adresse de prochain bond	12
2.8 Détection de boucle	12
2.9 Authenticité et intégrité des messages LDP	15
2.10 Distribution des étiquettes pour les LSP à acheminement explicite	16
3. Spécification du protocole	16
3.1 PDU LDP	16
3.2 Procédures de LDP	17
3.3 Codage des TLV	17
3.4 Codages de TLV pour les paramètres d’utilisation courante	18
3.5 Messages LDP	24
3.6. Messages et TLV pour l’extensibilité	43
3.7 Sommaire des messages	45
3.8 Sommaire des TLV	45
3.9 Sommaire des codes d’état	46
3.10 Numéros bien connus	46
4. Considérations relatives à l’IANA	47
4.1 Espace de nom des types de message	47
4.2 Espace de nom des types de TLV	47
4.3 Espace de nom des types de FEC	47
4.4 Espace de nom des codes d’état	48
4.5 Espace de nom d’identifiant expérimental	48
5. Considérations pour la sécurité	48
5.1 Usurpation d’identité	48
5.2 Confidentialité	49
5.3 Déni de service	49
6. Domaines d’études futures	50
7. Changements par rapport à la RFC3036	50
8. Remerciements	51
9. Références	52
9.1. Références normatives	52
9.2. Références pour information	52
Appendice A. Procédures de distribution des étiquettes LDP	53
A.1 Traitement des événements de distribution d’étiquettes	54
A.2 Procédures communes de distribution d’étiquettes	68
Adresse des éditeurs	74
Déclaration complète de droits de reproduction	74

1.	Généralités sur LDP

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

L’architecture MPLS ne suppose pas un seul protocole de distribution d’étiquettes. En fait, un certain nombre de différents protocoles de distribution d’étiquettes sont en cours de normalisation. Les protocoles existants ont été étendus de telle sorte que la distribution des étiquettes puisse être portée sur eux. De nouveaux protocoles ont aussi été définis dans le but explicite de distribuer les étiquettes. L’architecture MPLS discute certaines de ces considérations lors du choix d’un protocole de distribution d’étiquettes à utiliser pour des applications MPLS particulières telles que l’ingénierie du trafic de la [RFC2702].

Le protocole de distribution d’étiquettes (LDP, Label Distribution Protocol) est un protocole défini pour distribuer des étiquettes. Il a été à l’origine publié comme [RFC3036] en janvier 2001. Il était produit par le groupe de travail MPLS de l’IETF et ses auteurs étaient 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 de commutation d’étiquettes (LSR) établissent des chemins de commutation d’étiquettes (LSP, Label Switched Path) à travers un réseau en transposant des informations d’acheminement de couche réseau directement en chemins commutés de couche de liaison des données. Ces LSP peuvent avoir un point d’extrémité à un voisin directement rattaché (comparable à une transmission IP bond par bond) ou peuvent avoir un point d’extrémité à un nœud de sortie de réseau, permettant la commutation via tous les nœuds intermédiaires.

LDP associe une classe d’équivalence de transmission (FEC, Forwarding Equivalence Class) [RFC3031] à chaque LSP qu’il crée. La FEC associée à un LSP spécifie quels paquets sont "transposés" dans ce LSP. Les LSP sont étendus à travers un réseau car chaque LSR "greffe" les étiquettes entrantes pour une FEC sur l’étiquette sortante allouée au prochain bond pour cette FEC.

Plus d’informations sur l’applicabilité de LDP se trouvent dans la [RFC3037].

Le présent document suppose (sans l’exiger) une certaine familiarité avec l’architecture MPLS de la [RFC3031]. Noter que la [RFC3031] comporte un glossaire des termes de MPLS, tels que entrée, chemin de commutation d’étiquettes, etc.

1.1	Homologues LDP
Deux LSR qui utilisent LDP pour échanger des informations de transposition d’étiquette et/ou de FEC sont appelés des "homologues LDP" par rapport à ces informations, et on parle d’une "session LDP" entre eux. Une seule session LDP permet à chaque homologue d’apprendre les transpositions d’étiquettes de l’autre, c’est-à-dire que le protocole est bidirectionnel.

1.2	Échange de messages LDP
Il y a quatre catégories de messages LDP :
1.	Les messages de découverte, utilisés pour annoncer et entretenir la présence d’un LSR dans un réseau.
2.	Les messages de session, utilisés pour établir, entretenir, et terminer les sessions entre homologues LDP.
3.	Les messages d’annonces, utilisés pour créer, changer, et supprimer les transpositions d’étiquettes pour les FEC.
4.	Les messages de notification, utilisés pour fournir des informations et signaler des erreurs.

Les messages de découverte fournissent un mécanisme par lequel les LSR indiquent leur présence dans un réseau par l’envoi périodique d’un message Hello. Celui-ci est transmis comme paquet UDP à l’accès du LDP à l’adresse de diffusion groupée "Tous les routeurs sur ce sous-réseau". Lorsque un LSR choisit d’établir une session avec un autre LSR appris via le message Hello, il utilise la procédure d’initialisation de LDP sur transport TCP. Lorsque la procédure d’initialisation s’est terminée avec succès, les deux LSR sont des homologues LDP, et peuvent échanger des messages d’annonce.

Le moment où demander une étiquette ou annoncer une transposition d’étiquette à un homologue est largement une décision locale prise par un LSR. En général, le LSR demande une transposition d’étiquette à un LSR du voisinage lorsque il en a besoin d’une, et annonce une transposition d’étiquette à un LSR voisin lorsque il souhaite que le voisin utilise une étiquette.

Le fonctionnement correct 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, Annonce et Notification, c’est-à-dire, pour tout, sauf le mécanisme de découverte fondé sur UDP.

1.3	Structure du message LDP
Tous les messages LDP ont une structure commune qui utilise un schéma de codage Type-Longueur-Valeur (TLV) ; voir le paragraphe 3.3 "Codage de Type-Longueur-Valeur". La partie Valeur d’un objet codé en TLV, ou TLV en abrégé, peut elle-même contenir un ou plusieurs TLV.

1.4	Traitement des erreurs dans LDP
Les erreurs LDP et les autres événements intéressants sont signalés à un homologue LDP par des messages Notification.

Il y a deux sortes de messages Notification LDP :

1.	Notifications d’erreur, utilisés pour signaler des erreurs fatales. Si un LSR reçoit une Notification d’erreur de la part d’un homologue pour une session LDP, il met un terme à la session LDP en fermant la connexion de transport TCP pour la session et en éliminant toutes les transpositions d’étiquettes apprises via la session.

2.	Notifications d’information, utilisées pour passer des informations du LSR sur la session LDP ou l’état de certains messages antérieurs reçus de l’homologue.

1.5	Extensibilité et compatibilité future de LDP
Des fonctionnalités peuvent être ajoutées à l’avenir à LDP. Il est vraisemblable que de futures fonctionnalités utiliseront de nouveaux types de messages et d’objets (des TLV). Il peut être souhaitable d’employer de tels nouveaux messages et TLV au sein d’un réseau qui utilise de plus anciennes mises en œuvre qui ne les reconnaissent pas. Bien qu’il ne soit pas possible de rendre rétro-comptatibles toutes les améliorations futures, une certaine anticipation peut faciliter l’introduction de nouvelles capacités. La présente spécification définit à cette fin des règles pour le traitement des types de message inconnus et des TLV inconnus.

1.6	Langage de spécification
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

2.	Fonctionnement de LDP
2.1	Les classes d’équivalence de transmission
Il est nécessaire de spécifier précisément quels paquets peuvent être transposés dans chaque LSP. Cela est fait en fournissant une spécification de FEC pour chaque LSP. La FEC identifie l’ensemble de paquets IP qui peut être transposé sur ce LSP.

Chaque FEC est spécifiée comme un ensemble d’un ou plusieurs éléments de FEC. Chaque élément de FEC identifie un ensemble de paquets qui peuvent être transposés sur le LSP correspondant. Lorsque un LSP est partagé par plusieurs éléments de FEC, ce LSP se termine au nœud (ou avant) où les éléments de FEC ne peuvent plus partager le même chemin.

La présente spécification définit un seul type d’élément de FEC, l’élément "FEC de préfixe d’adresse". Cet élément est un préfixe d’adresse de longueur quelconque entre 0 et une adresse complète, incluse.

Des éléments de FEC supplémentaires peuvent être définis, en tant que de besoin, par d’autres spécifications.

Dans le reste de cette section, on donne les règles à utiliser pour transposer les paquets dans les LSP qui ont été établis en utilisant un élément de FEC de préfixe d’adresse.

On dit qu’une certaine adresse "correspond" à un certain préfixe d’adresse si et seulement si cette adresse commence par ce préfixe. On dit aussi qu’un certain paquet correspond à un certain LSP si et seulement si ce LSP a un élément de FEC de préfixe d’adresse qui correspond à l’adresse de destination du paquet. Par rapport à un certain paquet et un certain LSP, on dit que tout élément de FEC de préfixe d’adresse qui correspond au paquet est le "préfixe correspondant".

La procédure de transposition d’un paquet particulier à un LSP particulier utilise les règles suivantes. Chaque règle est appliquée tout à tour jusqu’à ce que le paquet puisse être transposé sur un LSP.

-	Si un paquet correspond exactement à un LSP, le paquet est transposé sur ce LSP.

-	Si un paquet correspond à plusieurs LSP il est transposé sur le LSP dont le préfixe correspondant est le plus long. Si il n’y a pas de LSP dont le préfixe correspondant soit plus long, le paquet est transposé sur un des LSP de l’ensemble dont le préfixe correspondant est plus long que celui des autres. La procédure de choix d’un de ces LSP sort du domaine d’application du présent document.

-	Si on sait qu’un paquet doit traverser un routeur de sortie particulier, et qu’un LSP a un élément de FEC de préfixe d’adresse qui est une adresse /32 de ce routeur, le paquet est alors transposé sur ce LSP. La procédure pour obtenir cette connaissance sort du domaine d’application du présent document.

La procédure pour déterminer qu’un paquet doit traverser un routeur de sortie particulier sort du domaine d’application du présent document. (Par exemple, si on utilise un algorithme d’acheminement d’état de liaison, il est possible d’obtenir ces informations de la base de données d’état de liaison. Autre exemple, si on utilise BGP, il est possible d’obtenir ces informations de l’attribut Prochain bond de BGP du chemin du paquet.)

2.2	Espaces, identifiants, sessions, et transport d’étiquettes
2.2.1	Espaces d’étiquettes
La notion "d’espace d’étiquettes" est utile pour discuter des allocations et de la distribution des étiquettes. Il y a deux types d’espaces d’étiquettes :

-	Espace d’étiquettes par interface. Les étiquettes entrantes spécifiques de l’interface sont utilisées pour les interfaces qui utilisent des ressources d’interface comme étiquette. Un exemple d’une telle interface est une interface ATM contrôlée par étiquette qui utilise des identifiants de canal virtuel (VCI, Virtual Channel Identifier) comme étiquettes, ou une interface de relais de trame qui utilise comme étiquettes des identifiants de connexion de liaison de données (DLCI, Data Link Connection Identifier).

Noter que l’utilisation d’un espace d’étiquettes par interface n’a de sens que lorsque les homologues LDP sont "directement connectés" sur une interface, et que l’étiquette ne va être utilisée que pour du trafic envoyé sur cette interface.

-	Espace d’étiquettes par plateforme. Les étiquettes entrantes aux dimensions d’une plateforme sont utilisées pour les interfaces qui peuvent partager les mêmes étiquettes.

2.2.2	Identifiants LDP
Un identifiant LDP est une quantité de six octets utilisée pour identifier un espace d’étiquettes de LSR. Les quatre premiers octets identifient le LSR et doivent être une valeur unique au monde, telle qu’un identifiant de routeur de 32 bits alloué au LSR. Les deux derniers octets identifient un espace d’étiquettes spécifique au sein du LSR. Les deux derniers octets des identifiants LDP pour les espaces d’étiquettes aux dimensions d’une plateforme sont toujours tous deux à zéro. Le présent document utilise la représentation d’impression suivante pour les identifiants LDP :

<LSR Id> : <id d’espace d’étiquettes>

par exemple, lsr171:0, lsr19:2.

Noter qu’un LSR qui gère et annonce plusieurs espaces d’étiquettes utilise un identifiant LDP différent pour chacun de ces espaces d’étiquettes.

Une situation dans laquelle un LSR aurait besoin d’annoncer plus d’un espace d’étiquette à un homologue, et donc d’utiliser plus d’un identifiant LDP, survient lorsque le LSR a deux liaisons avec l’homologue et que toutes deux sont ATM (et utilisent des étiquettes par interface). Une autre situation serait celle où le LSR a deux liaisons avec l’homologue, dont l’une est un ethernet (et utilise des étiquettes par plateforme) et l’autre est ATM.

2.2.3	Sessions LDP
Les sessions LDP existent entre les LSR pour prendre en charge leurs échanges d’étiquettes.

Lorsque un LSR utilise LDP pour annoncer plus d’un espace d’étiquettes à un autre LSR, il utilise une session LDP séparée pour chaque espace d’étiquettes.

2.2.4	Transport LDP
LDP utilise TCP comme transport fiable pour les sessions.

Lorsque plusieurs sessions LDP sont nécessaires entre deux LSR, il y a une session TCP pour chaque session LDP.

2.3	Sessions LDP entre des LSR non directement connectés
Des sessions LDP entre des LSR qui ne sont pas directement connectés au niveau liaison peuvent être souhaitables dans certaines situations.

Par exemple, considérons une application "d’ingénierie du trafic" où le LSRa envoie du trafic correspondant à certains critères via un LSP à un LSRb non directement connecté plutôt que de transmettre le trafic le long de son chemin d’acheminement normal.

Le chemin entre le LSRa et le LSRb inclurait un ou plusieurs LSR intermédiaires (LSR1,...LSRn). Une session LDP entre le LSRa et le LSRb permettrait au LSRb d’étiqueter le trafic arrivant sur le LSP en provenance du LSRa en fournissant au LSRb le moyen d’annoncer les étiquettes à cette fin au LSRa.

Dans cette situation, le LSRa appliquerait deux étiquettes au trafic qu’il transmet sur le LSP au LSRb : une étiquette apprise du LSR1 pour transmettre le trafic le long du chemin LSP du LSRa au LSRb ; et une étiquette apprise du LSRb pour permettre au LSRb d’étiqueter le trafic qui arrive sur le LSP.

Le LSRa ajoute d’abord l’étiquette apprise via sa session LDP avec le LSRb à la pile d’étiquettes du paquet (soit en remplaçant l’étiquette au sommet de la pile d’étiquettes du paquet si le paquet arrive étiqueté, soit en la poussant si le paquet arrive non étiqueté). Ensuite, il pousse l’étiquette pour le LSP apprise du LSR1 sur la pile d’étiquettes.

2.4	Découverte de LDP
La découverte de LDP est un mécanisme qui permet à un LSR de découvrir des homologues LDP potentiels. La découverte rend inutile de configurer explicitement les homologues de commutation d’étiquette d’un LSR.

Il y a deux variantes du mécanisme de découverte :
-	Un mécanisme  de découverte de base utilisé pour découvrir les LSR voisins qui sont directement connectés au niveau liaison.
-	Un mécanisme de découverte étendu utilisé pour localiser les LSR qui ne sont pas directement connectés au niveau liaison.

2.4.1	Mécanisme de découverte de base
Pour effectuer la découverte de base de LDP sur une interface, un LSR envoie périodiquement des Hello de liaison LDP à partir de l’interface. Les Hello de liaison LDP sont envoyés comme paquets UDP adressés à l’accès bien connu de découverte LDP à l’adresse de diffusion groupée "Tous les routeurs sur le sous-réseau".

Un Hello de liaison LDP envoyé par un LSR porte l’identifiant LDP pour l’espace d’étiquettes que le LSR entend utiliser pour l’interface et d’éventuelles informations supplémentaires.

La réception d’un Hello de liaison LDP sur une interface identifie une "adjacence de Hello" avec un homologue LDP potentiel accessible au niveau liaison sur l’interface ainsi que l’espace d’étiquettes que l’homologue entend utiliser pour l’interface.

2.4.2	Mécanisme de découverte étendu
Les sessions LDP entre des LSR non directement connectés sont prises en charge par la découverte étendue de LDP.

Pour effectuer la découverte étendue de LDP, un LSR envoie périodiquement des Hello ciblés LDP à une adresse spécifique. Les Hello ciblés LDP sont envoyés comme paquets UDP adressés à l’accès bien connu de découverte LDP à l’adresse spécifique.

Un Hello ciblé LDP envoyé par un LSR porte l’identifiant LDP pour l’espace d’étiquettes que le LSR entend utiliser et d’éventuelles informations facultatives supplémentaires.

La découverte étendue diffère de la découverte de base par les traits suivants :
-	Un Hello ciblé est envoyé à une adresse spécifique plutôt qu’à l’adresse de diffusion groupée "Tous les routeurs" pour l’interface sortante.
-	À la différence de la découverte de base, qui est symétrique, la découverte étendue est asymétrique.
Un LSR initie la découverte étendue avec un autre LSR ciblé, et le LSR ciblé décide si il répond ou si il ignore le Hello ciblé. Un LSR ciblé qui choisit de répondre le fait en envoyant périodiquement des Hello ciblés au LSR initiateur.
La réception d’un Hello LDP ciblé identifie une "adjacence de Hello" avec un homologue LDP potentiel accessible au niveau réseau et l’espace d’étiquettes que l’homologue entend utiliser.

2.5	Établissement et maintenance des sessions LDP
2.5.1	Établissement des sessions LDP
L’échange des Hello de découverte LDP entre deux LSR déclenche l’établissement de la session LDP. L’établissement de session est un processus en deux étapes :
-	Établissement de la connexion de transport.
-	Initialisation de session

On décrit l’établissement d’une session LDP entre les LSR, LSR1 et LSR2 du point de vue du LSR1. Il suppose l’échange de Hello spécifiant l’espace d’étiquettes "LSR1:a" pour le LSR1 et l’espace d’étiquettes "LSR2:b" pour le LSR2.

2.5.2	Établissement des connexions de transport
L’échange de Hello résulte en la création d’une adjacence de Hello au LSR1 qui sert à lier la liaison (L) et les espaces d’étiquettes LSR1:a et LSR2:b.

1.	Si le LSR1 n’a pas déjà une session LDP pour l’échange d’espaces d’étiquettes LSR1:a et LSR2:b, il tente d’ouvrir une connexion TCP pour une nouvelle session LDP avec le LSR2.
Le LSR1 détermine les adresses de transport à utiliser à son extrémité (A1) et à l’extrémité (A2) du LSR2 de la connexion TCP de LDP. L’adresse A1 est déterminée comme suit :
a.	si le LSR1 utilise l’objet facultatif Adresse de transport (TLV) dans les Hello qu’il envoie au LSR2 pour annoncer une adresse, A1 est l’adresse LSR1 annoncée via l’objet facultatif ;
b.	si le LSR1 n’utilise pas l’objet facultatif Adresse de transport, A1 est l’adresse de source utilisée dans les Hello qu’il envoie au LSR2.

De même, l’adresse A2 est déterminée comme suit :
a.	si LSR2 utilise l’objet facultatif Adresse de transport, A2 est l’adresse que LSR2 annonce via l’objet facultatif ;
b.	si LSR2 n’utilise pas l’objet facultatif Adresse de transport, A2 est l’adresse de source dans les Hello reçus de LSR2.

2.	LSR1 détermine si il va jouer le rôle actif ou passif dans l’établissement de session en comparant les adresses A1 et A2 comme entiers non signés. Si A1 > A2, le LSR1 joue le rôle actif ; autrement, il est passif.

La procédure de comparaison de A1 et A2 comme entiers non signés est :
-	Si A1 et A2 ne sont pas dans la même famille d’adresses, ils ne sont pas comparables, et aucune session ne peut être établie.
- 	Soit U1 un entier abstrait non signé obtenu en traitant A1 comme une séquence d’octets, où l’octet qui apparaît en premier dans le message est l’octet de poids fort de l’entier et l’octet qui apparaît en dernier dans le message est l’octet de moindre poids de l’entier.
-	Soit U2 l’entier abstrait non signé obtenu de A2 de façon similaire.
-	Comparer U1 et U2. Si U1 > U2, alors A1 > A2 ; si U1 < U2, alors A1 < A2.

3.	Si le LSR1 est actif, il tente d’établir la connexion TCP de LDP en se connectant à l’accès LDP bien connu à l’adresse A2. Si le LSR1 est passif, il attend que LSR2 établisse la connexion TCP LDP à son accès LDP bien connu.

Noter que lorsque un LSR envoie un Hello, il choisit l’adresse de transport pour sa fin de connexion de session et utilise le Hello pour annoncer l’adresse, soit explicitement en l’incluant dans un TLV facultatif d’adresse de transport, soit implicitement en omettant le TLV et en l’utilisant comme adresse de source du Hello.

Un LSR DOIT annoncer la même adresse de transport dans tous les Hello qui annoncent le même espace d’étiquettes. Cette exigence assure que deux LSR reliés par plusieurs adjacences de Hello qui utilisent le même espace d’étiquettes jouent le même rôle d’établissement de connexion pour chaque adjacence.

2.5.3	Initialisation de session
Après que LSR1 et LSR2 ont établi une connexion de transport, ils négocient les paramètres de session en échangeant des messages Initialisation LDP. Les paramètres négociés incluent la version de protocole LDP, la méthode de distribution d’étiquettes, les valeurs de temporisateurs, les gammes de VPI/VCI (Identifiant de chemin virtuel / Identifiant de canal virtuel) pour le relais de trame contrôlé par étiquette, les gammes d’identifiant de connexion de liaison de données (DLCI, Data Link Connection Identifier) pour le relais de trame contrôlé par étiquette, etc.

Une négociation réussie achève l’établissement d’une session LDP entre le LSR1 et le LSR2 pour l’annonce des espaces d’étiquettes LSR1:a et LSR2:b.

On décrit ensuite l’initialisation de session du point de vue du LSR1.

Après l’établissement de la connexion, si le LSR1 joue le rôle actif, il initie la négociation des paramètres de session en envoyant un message Initialisation au LSR2. Si LSR1 est passif, il attend que LSR2 initie la négociation des paramètres.

En général, lorsque il y a plusieurs liaisons entre LSR1 et LSR2 et plusieurs espaces d’étiquettes à annoncer par chacun, le LSR passif ne peut pas savoir quel espace d’étiquettes annoncer sur une connexion TCP nouvellement établie jusqu’à ce qu’il reçoive le message Initialisation LDP sur la connexion. Le message Initialisation porte à la fois l’identifiant LDP pour l’espace d’étiquettes de l’envoyeur (le LSR actif) et l’identifiant LDP pour l’espace d’étiquettes du receveur (LSR passif).

En attendant le message Initialisation de son homologue, le LSR passif peut confronter l’espace d’étiquettes à annoncer par l’homologue (tel que déterminé à partir de l’identifiant LDP dans l’en-tête d’unité de données de protocole (PDU, Protocol Data Unit) pour le message Initialisation) avec une adjacence de Hello précédemment créée lorsque les Hello ont été échangés.

1.	Lorsque LSR1 jour le rôle passif :
a.	Si LSR1 reçoit un message Initialisation, il tente de confronter l’identifiant LDP porté dans le message PDU avec une adjacence de Hello.
b.	Si il y a une adjacence de Hello qui correspond, l’adjacence spécifie l’espace d’étiquettes local pour la session.
Ensuite, le LSR1 vérifie si les paramètres de session proposés dans le message sont acceptables. Si ils le sont, le LSR1 répond par son propre message Initialisation pour proposer les paramètres qu’il souhaite utiliser et un message Garder en vie pour signaler l’acceptation des paramètres de LSR2. Si les paramètres ne sont pas acceptables, le LSR1 répond en envoyant un message Notification Session rejetée/Erreur de paramètres, et en fermant la connexion TCP.
c.	Si LSR1 ne peut pas trouver une adjacence de Hello correspondante, il envoie un message Notification Session rejetée/Erreur Pas de Hello et ferme la connexion TCP.
d.	Si LSR1 reçoit un Garder en vie en réponse à son message Initialisation, la session est opérationnelle du point de vue du LSR1.
e.	Si LSR1 reçoit un message Notification d’erreur, LSR2 a rejeté sa proposition de session et LSR1 ferme la connexion TCP.
2.	Lorsque LSR1 joue le rôle actif :
a.	Si LSR1 reçoit un message Notification d’erreur, LSR2 a rejeté sa proposition de session et LSR1 ferme la connexion TCP.
b.	Si LSR1 reçoit un message Initialisation, il vérifie si les paramètres de session sont acceptables. Si ils le sont, il répond par un message Garder en vie. Si les paramètres de session sont inacceptables, LSR1 envoie un message Notification Session rejetée/Erreur de paramètres et ferme la connexion.
c.	Si LSR1 reçoit un message Garder en vie, LSR2 a accepté sa proposition de paramètres de session.
d.	Lorsque LSR1 a reçu à la fois un message Initialisation acceptable et un message Garder en vie, la session est opérationnelle du point de vue de LSR1. Jusqu’à ce que la session LDP soit établie, aucun autre message, excepté ceux énumérés dans les procédures ci-dessus, ne peut être échangé, et les règles de traitement du bit U dans les messages LDP sont outrepassées. Si un message autre que ceux énumérés dans les procédures ci-dessus est reçu, un message Fermeture DOIT être transmis et la connexion de transport DOIT être fermée.

Il est possible qu’une paire de LSR à configurations incompatibles qui sont en désaccord sur des paramètres de session s’engagent dans une séquence interminable de messages car chacun fait un Non accusé de réception (NAK) aux messages Initialisation de l’autre avec des messages Notification d’erreur.

Un LSR DOIT augmenter le délai séparant ses tentatives d’essai d’établissement de session d’un retard croissant de façon exponentielle dans les situations où les messages Initialisation reçoivent un Non accusé de réception. Il est aussi recommandé qu’un LSR qui détecte une telle situation le notifie à l’opérateur.

La tentative d’établissement de session qui suit un Non accusé de réception d’un message Initialisation DOIT être retardée de pas moins de 15 secondes, et les retards suivants DOIVENT augmenter jusqu’à un retard maximum de pas moins de deux minutes. L’action d’établissement de session spécifique qui doit être retardée est la tentative d’ouvrir la  connexion de transport de session par le LSR qui joue le rôle actif.

La séquence de NAK d’initialisation ralentie ne va vraisemblablement pas cesser tant que l’intervention d’un opérateur n’aura pas reconfiguré un des LSR. Après une telle action de configuration, il n’est plus nécessaire de diminuer le rythme des tentatives ultérieures d’établissement de session (jusqu’à ce que leurs messages Initialisation reçoivent des Non accusés de réception).

Du fait de la nature asymétrique de l’établissement de session, la reconfiguration du LSR passif va passer inaperçue par le LSR actif s’il n’y a pas d’autre action. Le paragraphe 3.5.2 "Message Hello" décrit un mécanisme facultatif qu’un LSR peut utiliser pour signaler de potentiels homologues LDP qu’il a reconfigurés.

2.5.4	Automate à états d’initialisation
Il est pratique de décrire le comportement de négociation de session LDP en termes d’automate à états. On définit l’automate à états LDP comme ayant cinq états possibles et présentant le comportement comme un tableau de transition d’états et comme un diagramme de transitions d’état. Noter qu’un message Fermeture est mis en œuvre comme message Notification avec un TLV État indiquant une erreur fatale.

Tableau de transitions d’états d’initialisation de session

ÉTAT	ÉVÉNEMENT	NOUVEL ÉTAT
NON EXISTANT	Session établie, connexion TCP établie	INITIALISÉ
INITIALISÉ	Transmet le message Initialisation (rôle actif)	OUVERTENVOYÉ
	Réception acceptable	OUVERTREÇU
	Message Initialisation (rôle passif)
	Action : Transmet msg Initialisation et msg GarderEnVie
	Réception de tout autre msg LDP	NON EXISTANT
	Action : Transmet msg Notification d’erreur (NAK) 
et ferme la connexion de transport
OUVERTREÇU	Message GarderEnVie reçu	OPÉRATIONNEL
	Tout autre msg LDP reçu	NON EXISTANT
	Action : Transmettre msg Notification d’erreur (NAK) 
et fermer la connexion de transport
OUVERTENVOYÉ	Réception acceptable	OUVERTREÇU
	Message Initialisation
	Action : Transmettre msg GarderEnVie
	Tout autre msg LDP reçu	NON EXISTANT
	Action : Transmettre msg Notification d’erreur (NAK) 
et fermer la connexion de transport
OPÉRATIONNEL	Message Fermeture reçu	NON EXISTANT
	Action  : Transmettre msg Fermeture et clore la connexion de transport
	Réception d’autres messages LDP	OPÉRATIONNEL
	Fin de temporisation	NON EXISTANT
	Action : Transmettre msg Fermeture et clore la connexion de transport

Diagramme de transition d’états d’initialisation de session

                              +------------+
                              |            |
                +------------>|NON EXISTANT|<--------------------+
                |             |            |                     |
                |             +------------+                     |
                | Connexion de   |    ^                          |
                |   session      |    |                          |
                |   établie      |    | Rx tout msg LDP sauf     |
                |                V    | msg Init ou Fin de tempo |
                |            +-----------+                       |
   Rx tout autre|            |           |                       |
      msg ou    |            |INITIALIZED|                       |
  TX msg Fin de |        +---|           |-+                     |
  tempo / NAK   |        |   +-----------+ |                     |
                |        | (Rôle passif) | |(Rôle actif)         |
                |        | Rx acceptable   | Tx msg Init         |
                |        |    msg Init  /  |                     |
                |        | Tx msg Init     |                     |
                |        | Tx msg GarderEnV|                     |
                |        V                 V                     |
                |   +----------+     +--------+                  |
                |   |          |     |        |                  |
                +---|OUVERTREÇU|     |OUVERTEN|----------------->|
                +---|          |     |        | Rx tout autre msg|
                |   +----------+     +--------+    ou Fin tempor |
   Rx message   |        ^                |     Tx msg NAK       |
   GarderEnVie  |        |                |                      |
                |        |                | Rx acceptable        |
                |        |                |   msg Init  /        |
                |        +----------------+ Tx msg GarderEnVie   |
                |                                                |
                |      +------------+                            |
                +----->|            |                            |
                       |OPÉRATIONNEL|                            |
                       |            |--------------------------->+
                       +------------+     Rx message Fermeture
               Tous autres |   ^          ou TX msg Fin de temporisation /
              messages LDP |   |             Fermeture
                           |   |
                           +---+

2.5.5	Maintenance des adjacences de Hello
Une session LDP avec un homologue a une ou plusieurs adjacences de Hello.

Une session LDP a plusieurs adjacences de Hello lorsque une paire de LSR est connectée par plusieurs liaisons qui partagent le même espace d’étiquettes ; par exemple, plusieurs liaisons PPP entre une paire de routeurs. Dans cette situation, les Hello qu’envoie un LSR sur chacune de ces liaison portent le même identifiant LDP.

LDP comporte des mécanismes pour surveiller le besoin d’une session LDP et ses adjacences de Hello.

LDP utilise la réception régulière des Hello de découverte LDP pour indiquer l’intention d’un homologue d’utiliser l’espace d’étiquettes identifié par le Hello. Un LSR entretient un temporisateur de garde avec chaque adjacence de Hello qui est redémarré lorsque il reçoit un Hello qui correspond à l’adjacence. Si le temporisateur arrive à expiration sans réception d’un Hello correspondant de la part de l’homologue, LDP en conclut que l’homologue ne souhaite plus commuter d’étiquettes en utilisant cet espace d’étiquettes pour cette liaison (ou cible, dans le cas de Hello ciblés) ou que l’homologue a eu une défaillance. Le LSR supprime alors l’adjacence de Hello. Lorsque la dernière adjacence de Hello est supprimée pour une session LDP, le LSR termine la session LDP en envoyant un message Notification et en fermant la connexion de transport.

2.5.6	Maintenance des sessions LDP
LDP comporte des mécanismes pour surveiller l’intégrité de la session LDP.

LDP utilise la réception régulière des PDU LDP sur la connexion de transport de session pour surveiller l’intégrité de la session. Un LSR entretient un temporisateur de maintien en vie pour chaque session d’homologue qu’il remet à zéro chaque fois qu’il reçoit une PDU LDP de la part de l’homologue de session. Si le temporisateur de maintien en vie arrive à expiration sans réception d’une PDU LDP de l’homologue, le LSR en conclut que la connexion de transport est mauvaise ou que l’homologue a une défaillance, et il met un terme à la session LDP en fermant la connexion de transport.

Après l’établissement d’une session LDP, un LSR doit s’arranger pour que son homologue reçoive de lui une PDU LDP au moins toutes les périodes de GarderEnVie pour assurer que l’homologue redémarre le temporisateur GarderEnVie de la session. Le LSR peut envoyer n’importe quel message de protocole pour satisfaire cette exigence. Dans des circonstances où un LSR n’a pas d’autres informations à communiquer à son homologue, il envoie un message Garder en vie.

Un LSR peut choisir à tout moment de terminer une session LDP avec un homologue. Si il choisit de le faire, il informe l’homologue par un message Fermeture.

2.6	Distribution et gestion d’étiquettes
L’architecture MPLS [RFC3031] permet à un LSR de distribuer un lien étiquette FEC en réponse à une demande explicite d’un autre LSR. C’est ce qu’on appelle la distribution d’étiquette vers l’aval à la demande. Cela permet aussi à un LSR de distribuer des liens d’étiquettes aux LSR qui ne les ont pas explicitement demandés. La [RFC3031] appelle cette méthode de distribution d’étiquettes "vers l’aval non sollicité" ; le présent document utilise le terme "vers l’aval non sollicité".

Ces deux techniques de distribution d’étiquette peuvent être utilisées en même temps dans le même réseau. Cependant, pour toute session LDP, chaque LSR doit connaître la méthode de distribution d’étiquette utilisée par son homologue afin d’éviter des situations où un homologue qui utilise la distribution d’étiquettes vers l’aval non sollicitée suppose que son homologue le fait aussi. Voir au paragraphe 3.5.7.1.3 "Annonce d’étiquette vers l’aval à la demande".

2.6.1	Mode de contrôle de distribution d’étiquette
Le comportement de l’établissement initial des LSP est déterminé par le fonctionnement du LSR en contrôle de LSP indépendant ou ordonné. Un LSR peut prendre en charge les deux types de contrôle comme option configurable.

2.6.1.1	Contrôle indépendant de distribution d’étiquette
Lorsque il utilise le contrôle indépendant du LSP, chaque LSR peut annoncer la transposition d’étiquettes à ses voisins au moment qu’il désire. Par exemple, lorsque il fonctionne en mode indépendant vers l’aval à la demande, un LSR peut répondre immédiatement aux demandes de transposition d’étiquettes, sans attendre une transposition d’étiquette provenant du prochain bond. Lorsqu’il fonctionne en mode indépendant vers l’aval non sollicité, un LSR peut annoncer une transposition d’étiquette pour une FEC à ses voisins chaque fois qu’il est prêt à faire une commutation d’étiquette pour cette FEC.

Une conséquence de l’utilisation du mode indépendant est qu’une étiquette peut être annoncée avant qu’une étiquette aval ne soit reçue.

2.6.1.2	Contrôle ordonné de distribution d’étiquette
Lorsque il utilise le contrôle ordonné de LSP, un LSR ne peut initier la transmission d’une transposition d’étiquette que pour une FEC pour laquelle il a une transposition d’étiquette pour la FEC du prochain bond, ou pour laquelle le LSR est la sortie. Pour chaque FEC pour laquelle le LSR n’est pas la sortie et pour laquelle il n’existe pas de transposition, le LSR DOIT attendre que soit reçue une étiquette de la part d’un LSR aval avant de transposer la FEC et de passer les étiquettes correspondantes aux LSR vers l’amont. Un LSR peut être une sortie pour certaines FEC et une non sortie pour d’autres.

Un LSR peut agir comme LSR de sortie, par rapport à une certaine FEC, sous l’une des conditions suivantes :
1.	La FEC se réfère au LSR lui-même (incluant une de ses interfaces directement rattachées).
2.	Le routeur de prochain bond pour la FEC est en-dehors du réseau de commutation d’étiquettes.
3.	Les éléments de FEC sont accessibles en franchissant la frontière d’un domaine d’acheminement, comme une autre zone pour les résumés de réseau OSPF, ou un autre système autonome (AS) pour les AS externes OSPF et les chemins BGP [RFC2328], [RFC4271].

Noter que le fait qu’un LSR soit une sortie pour une certains FEC peut changer avec le temps, en fonction de l’état du réseau et des réglages de configuration du LSR.

2.6.2	Mode de rétention d’étiquette
L’architecture MPLS [RFC3031] introduit la notion de mode de rétention d’étiquette qui spécifie si un LSR conserve un lien d’étiquette pour une FEC apprise d’un voisin qui n’est pas son prochain bond pour cette FEC.

2.6.2.1	Mode prudent de rétention d’étiquette
En mode d’annonce vers l’aval non sollicité, les annonces de transposition d’étiquette pour tous les chemins peuvent être reçus de tous les LSR homologues. Lorsque on utilise la rétention prudente d’étiquettes, les transpositions d’étiquettes annoncées ne sont conservées que si elles vont être utilisées pour transmettre des paquets (c’est-à-dire, si elles sont reçues d’un prochain bond valide selon l’acheminement). Si on fonctionne en mode vers l’aval à la demande, un LSR ne va demander la transposition d’étiquettes qu’à partir du LSR de prochain bond selon l’acheminement. Comme le mode vers l’aval à la demande est principalement utilisé lorsque la conservation d’étiquette est désirée (par exemple, un commutateur ATM avec un espace limité d’inter connexion) il est normalement utilisé avec le mode de rétention prudente d’étiquettes.

Le principal avantage du mode prudent est que seules les étiquettes qui sont requises pour la transmission de données sont allouées et entretenues. Ceci est particulièrement important dans les LSR où l’espace d’étiquettes est limité par nature, comme dans un commutateur ATM. Un inconvénient du mode prudent est que si l’acheminement change le prochain bond pour une certaine destination, une nouvelle étiquette doit être obtenue du nouveau prochain bond avant que des paquets étiquetés puissent être transmis.

2.6.2.2	Mode libéral de rétention d’étiquette
En mode d’annonce vers l’aval non sollicité, les annonces de transposition d’étiquette pour tous les chemins peuvent être reçues de tous les homologues LDP. Lorsque on utilise la rétention libérale d’étiquettes, chaque transposition d’étiquettes reçue d’un LSR homologue est conservée sans considération de ce que le LSR est ou non le prochain bond pour la transposition annoncée. Lorsque on fonctionne en mode vers l’aval à la demande avec la rétention libérale d’étiquettes, un LSR peut choisir de demander la transposition d’étiquettes pour tous les préfixes connus provenant de tous les LSR homologues. Noter, cependant, que le mode vers l’aval à la demande est normalement utilisé par des appareils tels que les LSR qui s’appuient sur des commutateurs ATM pour lesquels l’approche prudente est recommandée.

Le principal avantage du mode prudent de rétention d’étiquettes est que la réaction aux changements d’acheminement peut être rapide parce que les étiquettes existent déjà. Le principal inconvénient du mode libéral est que des transpositions d’étiquettes inutiles sont distribuées et conservées.

2.6.3	Mode d’annonce d’étiquette
Chaque interface sur un LSR est configurée pour fonctionner en mode d’annonce vers l’aval non sollicité ou en mode vers l’aval à la demande. Les LSR échangent les modes d’annonce durant l’initialisation. La différence majeure entre le mode vers l’aval non sollicité et le mode vers l’aval à la demande est dans le LSR qui prend la responsabilité d’initier les demandes de transposition et les annonces de transposition.

2.7	Identifiant LDP et adresse de prochain bond
Un LSR conserve les étiquettes apprises dans une base de données d’informations d’étiquettes (LIB, Label Information Base). Lors du fonctionnement en mode vers l’aval non sollicité, l’entrée de LIB pour un préfixe d’adresse associe une collection de paires (identifiant LDP, étiquette) avec le préfixe, une telle paire pour chaque homologue qui annonce une étiquette pour le préfixe.

Lorsque le prochain bond pour un préfixe change, le LSR doit restituer l’étiquette annoncée par le nouveau prochain bond à partir de la LIB pour l’utiliser à la transmission. Pour restituer l’étiquette, le LSR doit être capable de transposer l’adresse du prochain bond pour le préfixe en un identifiant LDP.

De même, lorsque le LSR apprend une étiquette pour un préfixe de la part d’un homologue LDP, il doit être capable de déterminer si cet homologue est actuellement un prochain bond pour le préfixe pour déterminer si il a besoin de commencer à utiliser l’étiquette nouvellement apprise lorsque il transmet des paquets qui correspondent au préfixe. Pour prendre cette décision, le LSR doit être capable de transposer un identifiant LDP en l’adresse de l’homologue pour vérifier si il y a un prochain bond pour le préfixe.

Pour permettre aux LSR de faire la transposition entre l’identifiant de l’homologue LDP et les adresses d’homologues, les LSR annoncent leurs adresses en utilisant les messages LDP Adresse et Retrait d’adresse.

Un LSR envoie un message Adresse pour annoncer ses adresses à un homologue. Un LSR envoie un message Retrait d’adresse pour retirer des adresses annoncées précédemment par un homologue.

2.8	Détection de boucle
La détection de boucle est une option configurable qui fournit un mécanisme pour trouver des LSP en boucle et pour empêcher un message Demande d’étiquettes de faire une boucle en présence de LSR sans capacité de fusion.

Le mécanisme fait usage des TLV Vecteur de chemin et Compte de bonds portés par les messages Demande d’étiquette et Transposition d’étiquettes. Il s’appuie sur les propriétés de base suivantes de ces TLV :

-	Un TLV Vecteur de chemin contient une liste des LSR que son message contenant a traversés. Un LSR est identifié dans une liste de vecteurs de chemin par son identifiant unique de LSR, qui est les quatre premiers octets de son identifiant LDP. Lorsque un LSR propage un message contenant un TLV Vecteur de chemin, il ajoute son identifiant de LSR à la liste de vecteurs de chemin. Un LSR qui reçoit un message avec un vecteur de chemin qui contient son identifiant de LSR détecte que le message a traversé une boucle. LDP prend en charge la notion de longueur maximum admissible de vecteur de chemin ; un LSR qui détecte qu’un vecteur de chemin a atteint la longueur maximum se comporte comme si le message contenant avait traversé une boucle.

-	Un TLV Compte de bonds contient un compte des LSR que le message contenant a traversés. Lorsque un LSR propage un message contenant un TLV Compte de bonds, il incrémente le compte. Un LSR qui détecte qu’un compte de bonds a atteint une valeur de maximum configurée se comporte comme si le message contenant avait traversé une boucle. Par convention, un compte de 0 est interprété comme signifiant que le compte de bonds est inconnu. Incrémenter une valeur de compte de bonds inconnue résulte en une valeur de compte de bonds inconnue (0).

Les paragraphes qui suivent décrivent les procédures de détection de boucle LDP. Pour ces paragraphes, et seulement ces paragraphes, "DOIT" est redéfini comme signifiant "DOIT si configuré pour la détection de boucle". Ces paragraphes spécifient des messages qui DOIVENT porter des TLV Vecteur de chemin et Compte de bonds. Noter que le TLV Compte de bonds et ses procédures sont utilisés dans le TLV Vecteur de chemin dans les situations où la détection de boucle n’est pas configurée (voir les [RFC3035] et [RFC3034]).

2.8.1	Message Demande d’étiquette
L’utilisation du TLV Vecteur de chemin et du TLV Compte de bonds empêche le message Demande d’étiquettes de se mettre en boucle dans des environnements qui comportent des LSR sans capacité de fusion.

Les règles qui gouvernent l’utilisation du TLV Compte de bonds dans un message Demande d’étiquettes par le LSR R lorsque la détection de boucle est activée sont les suivantes :

-	Le message Demande d’étiquette DOIT inclure un TLV Compte de bonds.

-	Si R envoie la demande d’étiquette parce que c’est une entrée de FEC, il DOIT inclure un TLV Compte de bonds avec la valeur de compte de bonds 1.

-	Si R envoie la demande d’étiquette par suite de la réception d’une demande d’étiquette d’un LSR amont, et si la demande d’étiquette reçue contient un TLV Compte de bonds, R DOIT incrémenter la valeur de compte de bonds reçu de 1 et DOIT passer la valeur résultante dans un TLV Compte de bonds à son prochain bond avec le message Demande d’étiquette.

Les règles qui gouvernent l’utilisation du TLV Vecteur de chemin dans le message Demande d’étiquettes par le LSR R lorsque la détection de boucle est activée sont les suivantes :

-	Si R envoie la demande d’étiquette parce qu’il est une entrée de FEC, et si R est sans capacité de fusion, il DOIT inclure un TLV Vecteur de chemin de longueur 1 contenant son propre identifiant de LSR.

-	Si R envoie la demande d’étiquette par suite de la réception d’une demande d’étiquette de la part d’un LSR amont, si la demande d’étiquette reçue contient un TLV Vecteur de chemin ou si R est sans capacité de fusion, R DOIT ajouter son propre identifiant de LSR au vecteur de chemin, et DOIT passer le vecteur de chemin résultant à son prochain bond avec le message Demande d’étiquette. Si la demande d’étiquette ne contient pas de TLV Vecteur de chemin, R DOIT inclure un TLV Vecteur de chemin de longueur 1 contenant son propre identifiant de LSR.

Noter que si R reçoit un message Demande d’étiquette pour une FEC particulière, et si R a précédemment envoyé à son prochain bond un message Demande d’étiquette pour cette FEC et n’a pas encore reçu une réponse, et si R a l’intention de fusionner la demande d’étiquette nouvellement reçue avec la demande d’étiquette en cours existante, alors R ne propage pas la demande d’étiquette au prochain bond.

Si R reçoit un message Demande d’étiquette de son prochain bond avec un TLV Compte de bonds qui excède la valeur de maximum configurée, ou avec un TLV Vecteur de chemin contenant son propre identifiant de LSR ou qui excède la longueur maximale admissible, alors R détecte que le message Demande d’étiquette a voyagé dans une boucle.

Lorsque R détecte une boucle, il DOIT envoyer un message Notification Boucle détectée à la source du message Demande d’étiquette et abandonner le message Demande d’étiquette.

2.8.2	Message Transposition d’étiquette
L’utilisation du TLV Vecteur de chemin et du TLV Compte de bonds dans le message Transposition d’étiquette fournit un mécanisme pour trouver et terminer les boucles des LSP. Lorsque un LSR reçoit un message Transposition d’étiquette d’un prochain bond, le message est propagé en amont comme spécifié ci-dessous jusqu’à ce qu’un LSR d’entrée soit atteint ou qu’une boucle soit trouvée.

Les règles qui gouvernent l’usage du TLV Compte de bonds dans le message Transposition d’étiquettes envoyé par un LSR R lorsque la détection de boucle est activée sont les suivantes :
-	R DOIT inclure un TLV Compte de bonds  ;
-	Si R est la sortie, la valeur de compte de bonds DOIT être 1  ;
-	Si le message Transposition d’étiquette va être envoyé pour propager un message Transposition d’étiquette reçu du prochain bond à un homologue en amont, la valeur du compte de bonds DOIT être déterminée comme suit :
o	Si R est un membre de l’ensemble bordure d’un domaine LSR dont les LSR n’effectuent pas la diminution de TTL (par exemple, un domaine LSR ATM ou un domaine LSR en relais de trame) et si l’homologue amont est au sein de ce domaine, R DOIT remettre le compte de bonds à 1 avant de propager le message.
o	Autrement, R DOIT incrémenter le compte de bonds reçu du prochain bond avant de propager le message.
-	Si le message Transposition d’étiquette ne va pas être envoyé pour propager un message Transposition d’étiquette, la valeur du compte de bonds DOIT être le résultat de l’incrémentation de la connaissance actuelle de R du compte de bonds appris du précédent message Transposition d’étiquettes. Noter que cette valeur de compte de bonds sera inconnue si R n’a pas reçu un message Transposition d’étiquette du prochain bond.

Tout message Transposition d’étiquette PEUT contenir un TLV Vecteur de chemin. Les règles qui gouvernent l’utilisation obligatoire du TLV Vecteur de chemin dans le message Transposition d’étiquettes envoyé par le LSR R lorsque la détection de boucle est activée sont les suivantes :
-	Si R est la sortie, le message Transposition d’étiquette n’a pas besoin d’inclure un TLV Vecteur de chemin  ;
-	Si R envoie le message Transposition d’étiquette pour propager un message Transposition d’étiquette reçu du prochain bond à un homologue en amont, alors :
o	Si R est capable de fusion et si R n’a pas envoyé précédemment un message Transposition d’étiquette à l’homologue amont, il DOIT alors inclure un TLV Vecteur de chemin  ;
o	Si le message reçu contient un compte de bonds inconnu, R DOIT alors inclure un TLV Vecteur de chemin  ;
o	Si R a envoyé précédemment un message Transposition d’étiquette à l’homologue amont, il DOIT alors inclure un TLV Vecteur de chemin si le message reçu fait rapport d’une augmentation du compte de bonds du LSP, d’un changement du compte de bonds de inconnu à connu, ou d’un changement de connu à inconnu.

Si les règles ci-dessus exigent que R inclue un TLV Vecteur de chemin dans le message Transposition d’étiquette, R le calcule comme suit :
o	Si le message Transposition d’étiquette reçu incluait un vecteur de chemin, le vecteur de chemin envoyé en amont DOIT être le résultat de l’ajout de l’identifiant de LSR de R au vecteur de chemin reçu.
o	Si le message reçu n’avait pas de vecteur de chemin, le vecteur de chemin envoyé en amont DOIT être un vecteur de chemin de longueur 1 contenant l’identifiant de LSR de R.
-	Si le message Transposition d’étiquette n’est pas envoyé pour propager un message reçu vers l’amont, le message Transposition d’étiquette DOIT inclure un vecteur de chemin de longueur 1 contenant l’identifiant de LSR de R.

Si R reçoit un message Transposition d’étiquette de son prochain bond avec un TLV Compte de bonds qui excède la valeur maximum configurée, ou avec un TLV Vecteur de chemin contenant son propre identifiant de LSR, ou qui excède la longueur maximum admissible, R détecte alors que le LSP correspondant contient une boucle.

Lorsque R détecte une boucle, il DOIT arrêter d’utiliser l’étiquette pour la transmission, abandonner le message Transposition d’étiquette, et signaler l’état Boucle détectée à la source du message Transposition d’étiquette.

2.8.3	Discussion
Si la détection de boucle est désirée dans un domaine MPLS, elle devrait alors être activée dans TOUS les LSR au sein de ce domaine MPLS, autrement, la détection de boucle ne va pas fonctionner correctement et il peut en résulter des boucles non détectées ou des boucles détectées à tort.

Les LSR qui sont configurés pour la détection de boucle NE SONT PAS supposés mémoriser les vecteurs de chemin au titre de l’état du LSP.

Noter que dans un réseau où ne sont présents que des LSR sans capacité de fusion, les vecteurs de chemin sont passés vers l’aval de l’entrée à la sortie, et ne sont pas passés vers l’amont. Même lorsque la fusion est prise en charge, les vecteurs de chemin n’ont pas besoin d’être passés en amont le long d’un LSP qui est connu pour atteindre la sortie. Lorsque un LSR rencontre un changement de prochain bond, il n’a besoin de passer les vecteurs de chemin vers l’amont que lorsque il ne peut pas dire d’après le compte de bonds que le changement de prochain bond ne provoque pas une boucle.

Dans le cas de la distribution ordonnée d’étiquettes, les messages Transposition d’étiquettes sont propagés de la sortie vers l’entrée, créant naturellement le vecteur de chemin le long du chemin. Dans le cas de la distribution indépendante d’étiquettes, un LSR peut générer un message Transposition d’étiquette pour une FEC avant de recevoir un message Transposition d’étiquette de son homologue aval pour cette FEC. Dans ce cas, le message Transposition d’étiquette suivant pour la FEC reçu de l’homologue aval est traité comme une mise à jour des attributs du LSP, et le message Transposition d’étiquette doit être propagé vers l’amont. Donc, il est recommandé que la détection de boucle soit configurée en conjonction avec la distribution ordonnée d’étiquettes, pour minimiser le nombre de messages Transposition d’étiquette de mise à jour.

2.9	Authenticité et intégrité des messages LDP
Ce paragraphe spécifie un mécanisme pour protéger contre l’introduction de segments TCP usurpés dans les flux de connexion de session LDP. L’utilisation de ce mécanisme DOIT être prise en charge comme option configurable.

Le mécanisme se fonde sur l’utilisation de l’option de signature MD5 de TCP spécifiée dans la [RFC2385] pour être utilisée par BGP [RFC4271]. Voir dans la [RFC1321] la spécification de la fonction de hachage MD5. Du point de vue de la maturité des normes, le document actuel se rapporte à la [RFC2385] de la même façon que la [RFC4271] se rapporte à la [RFC2385]. Ceci est expliqué dans la [RFC4278].

2.9.1	Option TCP de signature MD5
La citation suivante de la [RFC2385] souligne les propriétés de sécurité réalisées en utilisant l’option de signature MD5 de TCP et résume son fonctionnement :

"Note de l’IESG
Le présent document décrit les pratiques courantes qui existent pour sécuriser BGP contre certaines attaques simples. Il est admis qu’il existe des faiblesse de la sécurité face à des attaques concertées."

"Résumé
Le présent mémoire décrit une extension à TCP pour améliorer la sécurité de BGP. Il définit une nouvelle option TCP pour porter un résumé MD5 [RFC1321] dans un segment TCP. Ce résumé agit comme une signature pour ce segment, incorporant des informations connues seulement des points d’extrémité de la connexion. Comme BGP utilise TCP comme transport, utiliser cette option de la façon décrite dans ce document réduit de façon significative le danger de certaines attaques contre la sécurité de BGP."

"Introduction
La motivation principale de cette option est de permettre à BGP de se protéger contre l’introduction de segments TCP falsifiés dans le flux de connexion. Les redémarrages TCP sont particulièrement visés.

Pour falsifier une connexion en utilisant le schéma décrit dans ce document, un attaquant devrait non seulement avoir deviné les numéros de séquence TCP, mais devrait aussi obtenir le mot de passe inclus dans le résumé MD5. Ce mot de passe n’apparaît jamais dans le flux de connexion, et la forme réelle du mot de passe dépend de l’application. Il pourrait même changer pendant la durée de vie d’une certaine connexion dans la mesure où ce changement serait synchronisé entre les deux extrémités (bien que la retransmission puisse devenir problématique dans certaines mises en œuvre de TCP avec des changements de mot de passe).

Finalement, il n’y a pas de négociation pour l’utilisation de cette option dans la connexion, et c’est plutôt une pure affaire de politique du site que de décider si ses connexions utilisent ou non l’option."

"MD5 a un algorithme de hachage
Depuis la première publication de ce mémoire (avec un titre différent) l’algorithme MD5 s’est révélé vulnérable aux attaques de recherche de collision [Dobb], et est considéré par certains comme insuffisamment fort pour ce type d’application.

Le présent mémoire spécifie quand même l’algorithme MD5, cependant, comme l’option a déjà été déployée dans les mises en œuvre, il n’y avait pas de champ "type d’algorithme" défini pour permettre une mise à niveau utilisant le même numéro d’option. Le document d’origine ne spécifiait pas de champ Type car cela aurait exigé au moins un octet supplémentaire, et il a été estimé à l’époque que prendre 19 octets pour l’option complète (qui serait probablement bourrée à 20 octets dans les mises en œuvre de TCP) serait un gaspillage trop important de l’espace d’option déjà limité.

Cela n’empêche pas le déploiement d’une autre option similaire qui utiliserait un autre algorithme de hachage (comme SHA-1). Aussi, si la plupart des mises en œuvre bourrent de toutes façons l’option de 18 octets comme défini à 20 octets, il serait tout aussi bien de définir une nouvelle option qui contienne un champ Type d’algorithme.

Cela devra cependant être traité par un autre document."

Fin de citation de la [RFC2385].

2.9.2	Utilisation par LDP de l’option TCP de signature MD5
LDP utilise l’option TCP de signature MD5 comme suit :
-	L’utilisation de l’option de signature MD5 pour les connexions TCP de LDP est une option de LSR configurable.
-	Un LSR qui utilise l’option de signature MD5 est configuré avec un mot de passe (secret partagé) pour chaque homologue LDP potentiel.
-	Le LSR applique l’algorithme MD5 comme spécifié dans la [RFC2385] pour calculer le résumé MD5 pour un segment TCP à envoyer à un homologue. Ce calcul utilise le mot de passe de l’homologue ainsi que le segment TCP.
-	Lorsque le LSR reçoit un segment TCP avec un résumé MD5, il valide le segment en calculant le résumé MD5 (en utilisant son propre enregistrement du mot de passe) et compare le résumé calculé au résumé reçu. Si la comparaison échoue, le segment est abandonné sans réponse à l’envoyeur.
-	Le LSR ignore les Hello LDP provenant de tout LSR pour lequel un mot de passe n’a pas été configuré. Cela assure que le LSR établit des connexions TCP de LDP seulement avec des LSR pour lesquels un mot de passe a été configuré.

2.10	Distribution des étiquettes pour les LSP à acheminement explicite
L’ingénierie du trafic [RFC2702] est supposée être une importante application de MPLS. La prise en charge de l’ingénierie du trafic par MPLS utilise des LSP à acheminement explicite, qui n’ont pas besoin de suivre des chemins à acheminement normal (bond par bond) comme déterminé par les protocoles d’acheminement fondés sur la destination. CR-LDP [RFC3212] définit des extensions à LDP pour utiliser LDP pour établir des LSP à acheminement explicite.

3.	Spécification du protocole

Les sections précédentes qui décrivent le fonctionnement de LDP ont exposé des scénarios qui impliquent un échange de messages entre LDP homologues. Cette section spécifie les codages de message et les procédures de traitement des messages.

Les échanges de message LDP sont accomplis en envoyant des unités de données de protocole (PDU, protocol data unit) LDP sur les connexions TCP des sessions LDP.

Chaque PDU LDP peut porter un ou plusieurs messages LDP. Noter que les messages dans une PDU LDP n’ont pas besoin d’être en relation les uns avec les autres. Par exemple, une seule PDU pourrait porter un message annonçant des liens de FEC à étiquette pour plusieurs FEC, un autre message demandant des liens d’étiquettes pour plusieurs autres FEC, et un troisième message Notification signalerait un certain événement.

3.1	PDU LDP
Chaque PDU LDP est un en-tête LDP suivi par un ou plusieurs messages LDP. L’en-tête LDP est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Version                      |         Longueur de la PDU    |
+---------------+---------------+---------------+---------------+
|                         Identifiant LDP                       |
+                               +---------------+---------------+
|                               |
+---------------+---------------+

Version : C’est un entier non signé de deux octets qui contient le numéro de version du protocole. La présente version de la spécification est la version de protocole LDP 1.

Longueur de PDU : C’est un entier de deux octets qui spécifie la longueur totale de cette PDU en octets, excluant les champs Version et Longueur de PDU. La Longueur maximum de PDU admissible est négociable lorsque une session LDP est initialisée. Avant de mener la négociation, la longueur maximum admissible est de 4096 octets.

Identifiant LDP : Champ de six octets qui identifie de façon univoque l’espace d’étiquettes du LSR d’envoi pour lequel cette PDU s’applique. Les quatre premiers octets identifient le LSR et DOIVENT être une valeur unique au monde. Ce DEVRAIT être un identifiant de routeur de 32 bits alloué au LSR et aussi utilisé pour l’identifier dans un vecteur de chemin de détection de boucles. Les deux derniers octets identifient un espace d’étiquette au sein du LSR. Pour un espace d’étiquettes à l’échelle d’une plate-forme, ils DEVRAIENT être tous deux à zéro.

Noter qu’il n’y a pas d’exigence d’alignement pour le premier octet d’une PDU LDP.

3.2	Procédures de LDP
LDP définit des messages, des TLV, et des procédures dans les domaines suivants :
-	découverte d’homologues
-	gestion de session
-	distribution d’étiquettes
-	notification des erreurs et informations de conseil

Les paragraphes qui suivent décrivent le codage des messages et des TLV pour ces domaines et les procédures qui s’y appliquent.

Les procédures de distribution d’étiquettes sont complexes et difficiles à bien décrire, de façon cohérente et sans ambiguïté, comme une collection de messages séparés et de spécifications de TLV.

L’Appendice A, "Procédures de distribution des étiquettes de LDP", décrit ces procédures en termes d’événements de distribution d’étiquettes qui peuvent survenir à un LSR et comment le LSR doit répondre. L’Appendice A est la spécification des procédures de distribution des étiquettes de LDP. Si une procédure décrite ailleurs dans ce document entre en conflit avec l’Appendice A, c’est celui-ci qui fait foi.

3.3	Codage des TLV
LDP utilise un schéma de codage de Type-Longueur-Valeur (TLV) pour coder beaucoup des informations portées dans les messages LDP.

Un TLV LDP est codé comme un champ de deux octets qui utilise 14 bits pour spécifier un Type et deux bits pour spécifier le comportement lorsque un LSR ne reconnaît pas le type, suivi par les deux octets du champ Longueur, suivi par un champ Valeur de longueur variable.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|        Type               |          Longueur             |
+-+-+-----------+---------------+---------------+---------------+
|                                                               |
|                             Valeur                            |
~                                                               ~
|                                                               |
|                               +---------------+---------------+
|                               |
+---------------+---------------+

Bit U (Unknown) : C’est le bit du TLV inconnu. À réception d’un TLV inconnu, si U n’est pas établi (= 0) une notification DOIT être retournée au générateur du message et le message entier DOIT être ignoré ; si U est établi (= 1) le TLV inconnu DOIT être ignoré en silence, et le reste du message traité comme si le TLV inconnu n’existait pas. Les paragraphes suivants qui définissent des TLV spécifient une valeur pour le bit U.

Bit F (Forward) : C’est le bit de transmission du TLV inconnu. Ce bit ne s’applique que lorsque le bit U est établi et que le message LDP contenant le TLV inconnu est à transmettre. Si F n’est pas établi (= 0) le TLV inconnu n’est pas transmis avec le message contenant ; si F est établi (= 1) le TLV inconnu est transmis avec le message contenant. Les paragraphes suivants qui définissent des TLV spécifient une valeur pour le bit F. En établissant les deux bits U et F, un TLV peut être propagé comme des données opaques à travers des nœuds qui ne reconnaissent pas le TLV.

Type : Code comment interpréter le champ Valeur.

Longueur : Spécifie la longueur du champ Valeur en octets.

Valeur : Chaîne d’octets des octets de longueur qui code les informations à interpréter comme spécifié par le champ Type.

Noter qu’il n’y a pas d’exigence d’alignement pour le premier octet d’un TLV.

Noter que le champ Valeur lui-même peut contenir des codages de TLV. C’est-à-dire que des TLV peuvent être incorporés.

Le schéma de codage de TLV est très général. En principe, tout ce qui apparaît dans une PDU LDP pourrait être codé comme TLV. La présente spécification n’utilise pas le schéma de TLV dans toute sa généralité. Il n’est pas utilisé lorsque sa généralité n’est pas nécessaire et que son utilisation serait un gaspillage inutile d’espace. Il y a normalement des endroits où le type d’une valeur à coder est connu, par exemple par sa position dans un message ou dans un TLV, et la longueur de la valeur est fixée ou directement déduite du codage de la valeur lui-même.

Certains des TLV définis pour LDP sont similaires à un autre. Par exemple, il y a un TLV Étiquette générique, un TLV Étiquette ATM, et un TLV Étiquette de relais de trame; voir les paragraphes 3.4.2.1, "TLV Étiquette générique", 3.4.2.2, "TLV Étiquette ATM", et 3.4.2.3, "TLV Étiquette de relais de trame".

Bien qu’il soit possible de voir les TLV rapportés de cette façon en termes de type de TLV qui spécifie une classe de TLV et de sous-type de TLV qui spécifie une sorte particulière de TLV au sein de cette classe, la présente spécification ne formalise pas la notion de sous-type de TLV.

La spécification affecte des valeurs de type aux TLV en cause, comme les TLV Étiquette, à partir d’un bloc contigu dans l’espace de numéro de type de TLV de 16 bits.

Le paragraphe 3.8, "Sommaire des TLV" fait la liste des TLV définis dans cette version du protocole et des paragraphes de ce document qui décrivent chacun d’eux.

3.4	Codages de TLV pour les paramètres d’utilisation courante
Plusieurs paramètres sont utilisés par plus d’un message LDP. Les codages de TLV pour ces paramètres d’utilisation commune sont spécifiés dans ce paragraphe.

3.4.1	TLV FEC
Les étiquettes sont liées à des classes d’équivalence de transmission (FEC, Forwarding Equivalence Classe). Une FEC est une liste d’un ou plusieurs éléments de FEC. Le TLV FEC code les éléments de FEC.

Son codage est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FEC (0x0100)              |      Longueur                 |
+---------------+---------------+---------------+---------------+
|                        FEC élément 1                          |
+---------------+---------------+---------------+---------------+
|                                                               |
~                                                               ~
|                                                               |
+---------------+---------------+---------------+---------------+
|                        FEC élément n                          |
+---------------+---------------+---------------+---------------+

FEC élément 1 à FEC élément n : Il y a plusieurs types d’éléments de FEC ; voir au paragraphe 2.1, "Les classes d’équivalence de transmission". Le codage de l’élément de FEC dépend du type de l’élément de FEC.

Une valeur d’élément de FEC est codée par un champ d’un octet qui spécifie le type d’élément, et par un champ de longueur variable qui est la valeur de l’élément dépendant du type. Noter que bien que la représentation de la valeur de l’élément de FEC dépende du type, le codage de l’élément de FEC lui-même est de un lorsque le codage standard de TLV LDP n’est pas utilisé.
Le codage de la valeur d’élément de FEC est :

Nom du type d’élément de FEC	Type	Valeur
Générique	0x01	pas de valeur ; c’est à dire 0 octet de valeur ; voir ci-dessous.
Préfixe	0x02	voir ci-dessous.

Noter que la présente version de LDP prend en charge l’utilisation de plusieurs éléments de FEC par FEC pour le seul message Transposition d’étiquette. L’utilisation de plusieurs éléments de FEC dans les autres messages n’est pas permise dans cette version, et fera l’objet de travaux futurs.

Élément générique de FEC : À utiliser seulement dans les messages Retrait d’étiquette et Libération d’étiquettes. Il indique que le retrait/libération est à appliquer à toutes les FEC associées à l’étiquette au sein du TLV d’étiquette suivant. Il doit être le seul élément de FEC dans le TLV FEC.

Codage de la valeur de l’élément de FEC Préfixe :
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Préfixe (2)  |     Famille d’adresse         | Long. préfixe |
+---------------+---------------+---------------+---------------+
|                     Préfixe                                   |
+---------------+---------------+---------------+---------------+

Famille d’adresse : Quantité de deux octets qui contient une valeur tirée de ADDRESS FAMILY NUMBERS dans [ASSIGNED_AF] qui code la famille d’adresses pour le préfixe d’adresse dans le champ Préfixe.

Long. préfixe : Entier d’un octet non signé contenant la longueur en bits du préfixe d’adresse qui suit. Une longueur de zéro indique un préfixe qui correspond à toutes les adresses (la destination par défaut) ; dans ce cas, le préfixe lui-même fait zéro octet).

Préfixe : Préfixe d’adresse codé conformément au champ Famille d’adresse, dont la longueur en bits a été spécifiée dans le champ Longueur de préfixe, bourré jusqu’à une limite d’octet.

3.4.1.1	Procédures de FEC
Si en décodant un TLV FEC un LSR rencontre un élément de FEC avec une famille d’adresse qu’il ne prend pas en charge, il DEVRAIT arrêter de décoder le TLV FEC, interrompre le traitement du message contenant le TLV, et envoyer un message Notification "Famille d’adresse non acceptée" à son homologue LDP pour signaler une erreur.

Si il rencontre un type d’élément de FEC qu’il ne peut pas décoder, il DEVRAIT arrêter de décoder le TLV FEC, interrompre le traitement du message contenant le TLV, et envoyer un message Notification "FEC inconnue" à son homologue LDP pour signaler une erreur.

3.4.2	TLV Étiquette
Les TLV Étiquette codent les étiquettes. Les TLV Étiquette sont portés par les messages utilisés pour annoncer, demander, libérer, et retirer les transpositions d’étiquettes.
Il y a plusieurs sortes différentes de TLV Étiquette qui peuvent apparaître dans des situations qui exigent un TLV Étiquette.
3.4.2.1	TLV Étiquette générique
Un LSR utilise le TLV Étiquette générique pour coder des étiquettes à utiliser sur des liaisons pour lesquelles les valeurs d’étiquettes sont indépendantes de la technologie de liaison sous-jacente. Des exemples de telles liaisons sont PPP et Ethernet.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|ÉtiquetteGénérique (0x0200)|      Longueur                 |
+---------------+---------------+---------------+---------------+
|     Étiquette                                                 |
+---------------+---------------+---------------+---------------+

Étiquette : C’est une valeur d’étiquette de 20 bits représentée par un nombre de 20 bits dans un champ de 4 octets comme suit :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Étiquette                         |                       |
+---------------+---------------+---------------+---------------+

Pour des précisions, voir la [RFC3032].

3.4.2.2	TLV Étiquette ATM
Un LSR utilise le TLV Étiquette ATM pour coder des étiquettes à utiliser sur des liaisons ATM.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Étiquette ATM (0x0201)    |         Longueur              |
+-+-+-----------+---------------+---------------+---------------+
|Rés| V |          VPI          |         VCI                   |
+---+---+-------+---------------+---------------+---------------+

Rés : Ce champ est réservé. Il DOIT être réglé à zéro à l’émission et DOIT être ignoré à réception.

Bits V : Deux bits d’indicateur de commutation. Si les bits V sont 00, le VPI et le VCI sont tous deux significatifs. Si les bits V sont 01, seul le champ VPI est significatif. Si les bits V sont à 10, seul le VCI est significatif.

VPI : Identifiant de chemin virtuel. Si VPI fait moins de 12 bits, il DEVRAIT être justifié à droite dans ce champ et les bits précédents DEVRAIENT être réglés à 0.

VCI : Identifiant de canal virtuel. Si le VCI fait moins de 16 bits, il DEVRAIT être justifié à droite dans le champ et les bits précédents DOIVENT être réglés à 0. Si la commutation de chemin virtuel est indiquée dans le champ Bits V, alors ce champ DOIT être ignoré par le receveur et réglé à 0 par l’envoyeur.

3.4.2.3	TLV Étiquette de relais de trame
Un LSR utilise le TLV Étiquette de relais de trame pour coder les étiquettes à utiliser sur les liaisons en relais de trame.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|Étiq. relais trame (0x0202)|       Longueur                |
+-+-°-----------+---------------+---------------+---------------+
|   Réservé   |Lon|                     DLCI                    |
+-------------+-+-+-------------+---------------+---------------+

Réservé : Ce champ est réservé. Il DOIT être réglé à zéro en émission et DOIT être ignoré à réception.

Lon : Ce champ spécifie le nombre de bits du DLCI. Les valeurs suivantes sont acceptées :
0 = 10 bits de DLCI
2 = 23 bits de DLCI
Les valeurs de Lon 1 et 3 sont réservées.

DLCI : C’est l’identifiant de connexion de liaison de données (DLCI, Data Link Connection Identifier)

Pour un DLCI de 10 bits, le codage est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|Étiq. relais trame (0x0202)|       Longueur                |
+-+-+-----------+---------------+---------------+---------------+
| Réservé     |Lon|            0            |   DLCI de 10 bits |
+-------------+-+-+-------------+-----------+-------------------+

Pour un DLCI de 23 bits, le codage est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|Étiq. relais trame (0x0202)|       Longueur                |
+-+-+-----------+---------------+---------------+---------------+
| Réservé     |Lon|             DLCI de 23 bits                 |
+-------------+-+-+-------------+---------------+---------------+

Pour des précisions, voir la [RFC3034].

3.4.3	TLV Liste d’adresses
Le TLV Liste d’adresses apparaît dans les messages Adresse et Retrait d’adresse.

Son codage est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Liste d’adresses (0x0101) |      Longueur                 |
+-+-+-----------+---------------+---------------+---------------+
|     Famille d’adresse         |                               |
+---------------+---------------+                               |
|                                                               |
|                         Adresses                              |
~                                                               ~
|                                                               |
+---------------+---------------+---------------+---------------+

Famille d’adresse : Quantité de deux octets qui contient une valeur tirée de ADDRESS FAMILY NUMBERS dans [ASSIGNED_AF] qui code les adresses contenues dans le champ Adresses.

Adresses : C’est une liste d’adresses de la famille d’adresse spécifiée. Le codage de chaque adresse dépend de la famille d’adresses.

Les codages d’adresse qui suivent sont définis dans la présente version du protocole : 

Famille d’adresse	Codage d’adresse
IPv4	adresse IPv4 complète de 4 octets
IPv6	adresse IPv6 complète de 16 octets

3.4.4	TLV Compte de bonds
Le TLV Compte de bonds apparaît comme un champ facultatif dans un message qui établit des LSP. Il calcule le nombre de bonds de LSR le long d’un LSP lors de l’établissement du LSP.
Noter que les procédures d’établissement des LSP qui traversent des liaisons ATM et de relais de trame exigent l’utilisation du TLV Compte de bonds (voir les [RFC3035] et [RFC3034]).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Compte de bonds (0x0103)  |      Longueur                 |
+---------------+---------------+---------------+---------------+
| Valeur de CdB |
+-+-+-+-+-+-+-+-+

Valeur de CdB : Valeur d’entier non signé de compte de bonds sur un octet.

3.4.4.1	Procédures de compte de bonds 
Durant l’établissement d’un LSP, un LSR R peut recevoir un message Transposition d’étiquette ou Demande d’étiquette pour le LSP qui contient le TLV Compte de bonds. Si il le fait, il DEVRAIT enregistrer la valeur de compte de bonds.

Si le LSR R propage alors le message Transposition d’étiquette pour le LSP à un homologue amont ou le message Demande d’étiquette à un homologue aval pour continuer l’établissement du LSP, il doit déterminer un compte de bonds à inclure dans le message propagé comme suit :
-	si le message est un message Demande d’étiquette, R DOIT incrémenter le compte de bonds reçu ;
-	si le message est un message Transposition d’étiquette, R détermine le compte de bonds comme suit :
o	si R est un membre de l’ensemble bordure du domaine d’un LSR dont les LSR n’effectuent pas la diminution du TTL et dont l’homologue amont est au sein de ce domaine, R DOIT remettre le compte de bonds à 1 avant de propager le message  ;
o	autrement, R DOIT incrémenter le compte de bonds reçu.

Le premier LSR dans le LSP (entrée pour un message Demande d’étiquette, sortie pour un message Transposition d’étiquette) DEVRAIT régler la valeur de compte de bonds à 1.

Par convention, une valeur de 0 indique un compte de bonds inconnu. Le résultat de l’incrémentation d’un compte de bonds  inconnu est lui-même un compte de bonds inconnu (0).

L’utilisation de la valeur de compte de bonds inconnu réduit considérablement la redondance de signalisation lorsque on utilise le contrôle indépendant. Lorsque un nouveau LSP est établi, chaque LSR commence avec un compte de bonds inconnu. L’ajout d’un nouveau LSR dont le compte de bonds est aussi inconnu ne cause pas la propagation en amont d’une mise à jour de compte de bonds car le compte de bonds reste inconnu. Lorsque la sortie est finalement ajoutée au LSP, les LSR propagent alors les mises à jour du compte de bonds en amont via un message Transposition d’étiquettes.

Sans l’utilisation du compte de bonds inconnu, chaque fois qu’un nouveau LSR est ajouté au LSP, une mise à jour du compte de bonds devrait être propagée en amont si le nouveau LSR est plus proche de la sortie que les autres LSR. Ces mises à jour constituent une redondance inutile car elles ne reflètent pas le compte de bonds jusqu’à la sortie.

Du point de vue du nœud d’entrée, le fait que le compte de bonds soit inconnu n’a pas d’implication sur le fait qu’un paquet envoyé sur le LSP atteigne effectivement la sortie. Tout ce que cela implique est que la mise à jour du compte de bonds à partir de la sortie n’a pas encore atteint l’entrée.

Si un LSR reçoit un message contenant un TLV Compte de bonds, il DOIT vérifier la valeur du compte de bonds pour déterminer si le compte de bonds a dépassé sa valeur maximum admissible configurée. Si il l’a dépassée, il DOIT se comporter comme si le message contenant avait traversé une boucle en envoyant un message Notification signalant Boucle détectée en réponse à l’envoyeur du message.

Si la détection de boucle est configurée, le LSR DOIT suivre les procédures spécifiées au paragraphe 2.8 "Détection de boucle".

3.4.5	TLV Vecteur de chemin
Le TLV Vecteur de chemin est utilisé avec le TLV Compte de bonds dans les messages Demande d’étiquette et Transposition d’étiquette pour mettre en œuvre le mécanisme LDP facultatif de détection de boucle (voir au paragraphe 2.8, "Détection de boucle". Son utilisation dans le message Demande d’étiquette enregistre le chemin des LSR que la demande a traversés. Son utilisation dans le message Transposition d’étiquette enregistre le chemin des LSR qu’une annonce d’étiquette a traversés pour établir un LSP. Son codage est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Vecteur de chemin (0x0104)|        Longueur               |
+-+-+-----------+---------------+---------------+---------------+
|                      Identifiant de LSR 1                     |
+---------------+---------------+---------------+---------------+
|                                                               |
~                                                               ~
|                                                               |
+---------------+---------------+---------------+---------------+
|                       Identifiant de LSR n                    |
+---------------+---------------+---------------+---------------+

Identifiants d’un ou plusieurs LSR : Liste d’identifiants de routeurs qui indique le chemin des LSR que le message a traversés. Chaque identifiant de LSR est les quatre premiers octets (identifiant de routeur) de l’identifiant LDP pour le LSR correspondant. Cela assure qu’il est unique au sein du réseau de LSR.

3.4.5.1	Procédures de vecteur de chemin
Le TLV Vecteur de chemin est porté dans les messages Transposition d’étiquette et Demande d’étiquette lorsque la détection de boucle est configurée.

3.4.5.1.1	Demande d’étiquette Vecteur de chemin
Le paragraphe 2.8, "Détection de boucle" spécifie les situations où un LSR doit inclure un TLV Vecteur de chemin dans un message Demande d’étiquette.

Un LSR qui reçoit un vecteur de chemin dans un message Demande d’étiquette DOIT effectuer les procédures décrites au paragraphe 2.8, "Détection de boucle".

Si le LSR détecte une boucle, il DOIT rejeter le message Demande d’étiquette.

Le LSR DOIT :
1.	Transmettre un message Notification au LSR d’envoi signalant "Boucle détectée".
2.	Ne pas propager plus loin le message Demande d’étiquette.
Noter qu’un message Demande d’étiquette avec un TLV Vecteur de chemin est transmis jusqu’à ce que :
1.	on trouve une boucle,
2.	on atteigne la sortie du LSP, ou
3.	on atteigne la limite de vecteur de chemin maximum ou la limite du compte de bonds maximum. Ceci est traité comme si une boucle avait été détectée.

3.4.5.1.2	Transposition d’étiquette Vecteur de chemin
Le paragraphe 2.8, "Détection de boucle" spécifie les situations où un LSR doit inclure un TLV Vecteur de chemin dans un message Transposition d’étiquette.

Un LSR qui reçoit un vecteur de chemin dans un message Transposition d’étiquette DOIT effectuer les procédures décrites au paragraphe 2.8, "Détection de boucle".

Si le LSR détecte une boucle, il DOIT rejeter le message Transposition d’étiquette afin d’empêcher une boucle de transmission. Le LSR DOIT :
1.	transmettre un message Libération d’étiquette portant un TLV État au LSR d’envoi pour signaler "Boucle détectée"  ;
2.	ne pas propager plus loin le message  ;
3.	vérifier si le message Transposition d’étiquette est pour un LSP existant. Si il l’est, le LSR doit détacher toutes les étiquettes amont qui sont greffées sur l’étiquette aval pour cette FEC.
Noter qu’un message Transposition d’étiquette avec un TLV Vecteur de chemin est transmis jusqu’à ce que :
1.	on trouve une boucle,
2.	on atteigne une entrée du LSP, ou
3.	on atteigne un vecteur de chemin maximum ou une limite de compte de bonds maximum. Ceci est traité comme si une boucle avait été détectée.

3.4.6	TLV État
Les messages Notification portent des TLV État pour spécifier les événements signalés.
Le codage du TLV État est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| État   (0x0300)           |      Longueur                 |
+-+-+-----------+---------------+---------------+---------------+
|                     Code d’état                               |
+---------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|      Type de message          |
+---------------+---------------+

Bit U : Il DEVRAIT être 0 lorsque le TLV État est envoyé dans un message Notification. Il DEVRAIT être 1 lorsque le TLV État est envoyé dans un autre message.

Bit F : Il DEVRAIT être le même que le réglage du bit F dans le champ Code d’état.

Code d’état : Entier non signé de 32 bits codant l’événement signalé. La structure d’un code d’état est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|F|                 Données d’état                            |
+-+-+-----------+---------------+---------------+---------------+

Bit E : Bit d’Erreur fatale. Si il est établi (=1), c’est une notification d’erreur fatale. Si il n’est pas établi (= 0) c’est la notification d’un conseil.

Bit F (Forward) : Bit de transmission. Si il est établi (= 1) la notification DEVRAIT être transmise au LSR pour le prochain bond ou au bond précédent pour le LSP, s’il en est, associé à l’événement signalé. Si il n’est pas établi (= 0) la notification NE DEVRAIT PAS être transmise.

Données d’état : Entier non signé de 30 bits qui spécifie les informations d’état. Cette spécification définit les codes d’état (entiers non signés de 32 bits avec le codage ci-dessus). Un code d’état de 0 signale le succès.

Identifiant de message : Si il est différent de zéro, c’est une valeur de 32 bits qui identifie le message homologue auquel se réfère le TLV État. Si il est à zéro, aucun message homologue spécifique n’est identifié.

Type de message : Si il est différent de zéro, c’est le type du message homologue auquel se réfère le TLV État. Si il est à zéro, le TLV État ne se réfère à aucun type de message spécifique.

Noter que l’utilisation du TLV État n’est pas limitée aux messages Notification. Un message autre qu’un message Notification peut porter un TLV État comme paramètre facultatif. Lorsque un message autre qu’une notification porte un TLV État, le bit U du TLV État DEVRAIT être réglé à 1 pour indiquer que le receveur DEVRAIT éliminer en silence le TLV si il n’est pas prêt à le traiter.

3.5	Messages LDP
Tous les messages LDP ont le format suivant :
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|   Type de message           |      Longueur de message      |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
+                                                               +
|                     Paramètres obligatoires                   |
~                                                               ~
|                                                               |
+---------------+---------------+---------------+---------------+
+                                                               +
|                     Paramètres facultatifs                    |
~                                                               ~
|                                                               |
+---------------+---------------+---------------+---------------+

Bit U : Bit du message inconnu. À réception d’un message inconnu, si U n’est pas mis (= 0) une notification est retournée à l’origine du message ; si U est établi (= 1) le message inconnu est ignoré en silence. Les paragraphes qui suivent et définissent des messages spécifient une valeur pour le bit U.

Type de message : Identifie le type de message.

Longueur de message : Spécifie la longueur cumulée en octets de l’identifiant de message, des paramètres obligatoires, et des paramètres facultatifs.

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message. Utilisé par le LSR d’envoi pour faciliter l’identification des messages Notification qui peuvent s’appliquer à ce message. Un LSR qui envoie un message Notification en réponse à ce message DEVRAIT inclure cet identifiant de message dans le TLV État porté par le message Notification ; voir le paragraphe 3.5.1 "Message Notification".

Paramètres obligatoires : Ensemble de longueur variable des paramètres obligés de message. Certains messages n’ont pas de paramètre obligé. Pour les messages qui ont des paramètres obligés, les paramètres obligés DOIVENT apparaître dans l’ordre spécifié par la spécification du message concerné au paragraphe qui suit.

Paramètres facultatifs : Ensemble de longueur variable de paramètres facultatifs de message. De nombreux messages n’ont pas de paramètres facultatifs. Pour les messages qui ont des paramètres facultatifs, ceux-ci peuvent apparaître dans n’importe quel ordre.

Noter qu’il n’y a pas d’exigence d’alignement pour le premier octet d’un message LDP et il n’y a pas de bourrage à la fin d’un message ; c’est-à-dire que les paramètres peuvent sur des limites d’octet impaires.

Les types de message suivants sont définis dans cette version de LDP :

Nom du message	Titre du paragraphe
Notification	3.5.1 "Message Notification"
Hello	3.5.2 "Message Hello"
Initialisation	3.5.3 "Message Initialisation"
GarderEnVie	3.5.4 "Message Garder en vie"
Adresse	3.5.5 "Message Adresse"
Retrait d’adresse	3.5.6 "Message Retrait d’adresse"
Transposition d’étiquette	3.5.7 "Message Transposition d’étiquette"
Demande d’étiquette	3.5.8 "Message Demande d’étiquette"
Demande d’abandon d’étiquette	3.5.9 "Message Demande d’abandon d’étiquette"
Retrait d’étiquette 	3.5.10 "Message Retrait d’étiquette"
Libération d’étiquette	3.5.11 "Message Libération d’étiquette"

Les paragraphes qui suivent spécifient le codage et les procédures de ces messages.
Certains des messages ci-dessus sont en relation les uns avec les autres, par exemple les messages Transposition d’étiquette, Demande d’étiquette, Retrait d’étiquette, et Libération d’étiquette.

Bien qu’il soit possible de voir les messages en relation de cette façon en termes de type de message qui spécifie une classe de message et de sous-type de message qui spécifie une sorte particulière de message au sein de cette classe, la présente spécification ne formalise pas la notion de sous-type de message.

La spécification affecte des valeurs de type aux messages en relations, comme les messages Étiquette, à partir d’un bloc contigu dans l’espace de numéro à 16 bits de type de message.

3.5.1	Message Notification
Un LSR envoie un message Notification pour informer un homologue LDP d’un événement significatif. Un message Notification signale une erreur fatale ou fournit des informations de conseil telles que le résultat du traitement d’un message LDP ou l’état de la session LDP.

Le codage du message Notification est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|   Notification (0x0001)     |      Longueur de message      |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                     État   (TLV)                              |
+---------------+---------------+---------------+---------------+
|                     Paramètres facultatifs                    |
+---------------+---------------+---------------+---------------+

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message.

TLV État : Indique l’événement signalé. Le codage du TLV État est spécifié au paragraphe 3.4.6 "TLV État".

Paramètres facultatifs : Ce champ de longueur variable contient 0, un ou plusieurs paramètres, codés chacun comme un TLV. Les paramètres facultatifs suivants sont génériques et peuvent apparaître dans tout message Notification  :

Paramètre facultatif	Type	Longueur	Valeur
État étendu	0x0301	4	Voir ci-dessous
PDU retournée	0x0302	variable	Voir ci-dessous
Message retourné	0x0303	variable	Voir ci-dessous

D’autres paramètres facultatifs, spécifiques de l’événement particulier signalé par le message Notification, peuvent apparaître. Ils sont décrits ailleurs.

État étendu : La valeur d’octet 4 est un code d’état étendu qui code des informations supplémentaires qui augmentent les informations d’état contenues dans le Notification Code d’état.

PDU retournée : Un LSR utilise ce paramètre pour retourner une partie d’une PDU LDP au LSR qui l’a envoyée. La valeur de ce TLV est l’en-tête de la PDU et autant de données de la PDU suivant l’en-tête qu’il est approprié pour la condition signalée par le message Notification.

Message retourné : Un LSR utilise ce paramètre pour retourner une partie d’un message LDP au LSR qui l’a envoyé. La valeur de ce TLV est les champs Type et Longueur du message et autant de données du message qui suivent les champs Type et Longueur qu’il est approprié pour la condition signalée par le message Notification.

3.5.1.1	Procédures du message Notification
Si un LSR rencontre une condition qui exige qu’il notifie à son homologue des informations de conseil ou d’erreur, il envoie à l’homologue un message Notification qui contient un TLV État qui code les informations et facultativement des TLV supplémentaires qui fournissent plus d’informations sur la condition.

Si la condition est une de celles qui constituent une erreur fatale, le code d’état porté dans la notification va l’indiquer. Dans ce cas, après l’envoi du message Notification, le LSR DEVRAIT terminer la session LDP en fermant la connexion TCP de session et éliminer tout état associé à la session, y compris tout lien étiquette-FEC appris via la session.

Lorsque un LSR reçoit un message Notification qui porte un code d’état qui indique une erreur fatale, il DEVRAIT terminer immédiatement la session LDP en fermant la connexion TCP de la session et éliminer tout état associé à la session, y compris tout lien étiquette-FEC appris via la session.

La déclaration ci-dessus ne s’applique pas au traitement du message Fermeture dans la procédure d’initialisation de session. Lorsque un LSR reçoit un message Fermeture durant l’initialisation de session, il DEVRAIT transmettre un message Fermeture puis clore la connexion de transport.

3.5.1.2	Événements signalés par les messages Notification
Il est utile pour les besoins de la description de classer les événements signalés par les messages Notification dans les catégories suivantes.

3.5.1.2.1	PDU ou message mal formé
Les PDU ou messages LDP mal formés font partie du mécanisme de découverte LDP qui les traite en les éliminant en silence.

Une PDU LDP reçue sur une connexion TCP pour une session LDP est mal formée si :
-	L’identifiant LDP dans l’en-tête de PDU est inconnu du receveur, ou si il est connu mais n’est pas l’identifiant LDP associé par le receveur à l’homologue LDP pour cette session LDP. C’est une erreur fatale signalée par le code d’état Mauvais identifiant LDP.
-	La version de protocole LDP n’est pas acceptée par le receveur, ou elle est acceptée mais ce n’est pas la version négociée pour la session durant l’établissement de session. C’est une erreur fatale signalée par le code d’état Mauvaise version de protocole.
-	Le champ Longueur de la PDU est trop petit (inférieur à 14) ou trop grand (supérieur à la longueur maximum de PDU). C’est une erreur fatale signalée par le code d’état Mauvaise longueur de PDU. Le paragraphe 3.5.3 "Message Initialisation" décrit comment est déterminée la longueur maximum de PDU pour une session.

Un message LDP est mal formé si :
-	Le type de message est inconnu.
Si le type de message est inférieur à 0x8000 (bit de poids fort = 0) c’est une erreur signalée par le code d’état Type de message inconnu.
Si l type de message est ≥ 0x8000 (bit de poids fort = 1) il est éliminé en silence.
-	La longueur de message est trop grande, c’est-à-dire qu’elle indique que le message s’étend au delà de la fin de la PDU LDP contenante. C’est une erreur fatale signalée par le code d’état Mauvaise longueur de message.
-	La longueur de message est trop petite, c’est-à-dire, plus petite que la plus petite valeur possible d’un composant. C’est une erreur fatale signalée par le code d’état Mauvaise longueur de message.
-	Le message manque d’un ou plusieurs paramètres obligatoires. C’est une erreur non fatale signalée par le code d’état Paramètres de message manquants.

3.5.1.2.2	TLV inconnu ou mal formé
Les TLV mal formés contenus dans les messages LDP qui font partie du mécanisme de découverte de LDP sont traités par l’élimination en silence du message contenant.

Un TLV contenu dans un message LDP reçu sur une connexion TCP d’un LDP est mal formé si :
-	Le TLV Longueur est trop grand, c’est-à-dire, indique que le TLV s’étend au delà de la fin du message contenant. C’est une erreur fatale signalée par le code d’état Mauvais TLV Longueur.
-	Le type de TLV est inconnu. Si le type de TLV est inférieur à 0x8000 (bit de poids fort = 0) c’est une erreur signalée par le code d’état TLV inconnu. Si le type de TLV est ≥ 0x8000 (bit de poids fort = 1) le TLV est abandonné en silence.
-	Le TLV Valeur est mal formé. Cela survient lorsque le receveur traite le TLV mais ne peut pas le décoder. C’est interprété comme indiquant une erreur dans le LSR d’envoi ou de réception. C’est une erreur fatale signalée par le code d’état TLV Valeur mal formé.

3.5.1.2.3	Expiration du temporisateur de garde en vie de session
C’est une erreur fatale signalée par le code d’état Expiration du temporisateur GarderEnVie.

3.5.1.2.4	Fermeture unilatérale de session
C’est un événement fatal signalé par le code d’état Fermeture. Le message Notification peut facultativement inclure un TLV État étendu pour fournir une raison pour la fermeture. Le LSR d’envoi termine la session immédiatement après l’envoi du message Notification.

3.5.1.2.5	Événements de message d’initialisation
La négociation d’initialisation de session (voir le paragraphe 2.5.3 "Initialisation de session") peut échouer si les paramètres de session reçus dans le message Initialisation sont inacceptables. C’est une erreur fatale. Le code d’état spécifique dépend du paramètre réputé inacceptable, et est défini au paragraphe 3.5.3 "Message Initialisation".

3.5.1.2.6	Événements résultant d’autres messages
Les messages autres que le message Initialisation peuvent avoir pour résultat des événements qui doivent être signalés aux homologues LDP via des messages Notification. Ces événements et les codes d’état utilisés dans les messages Notification pour les signaler sont décrits dans les paragraphes qui décrivent ces messages.

3.5.1.2.7	Erreurs internes
Une mise en œuvre de LDP peut être capable de détecter des conditions de problème spécifiques de sa mise en œuvre. Lorsque une telle condition empêche une mise en œuvre d’interagir correctement avec un homologue, la mise en œuvre devrait, lorsque elle est capable de le faire, utiliser le code d’état Erreur interne pour le signaler à l’homologue. C’est une erreur fatale.

3.5.1.2.8	Événements divers
Il y a des événements qui ne rentrent dans aucune des catégories ci-dessus. Il n’y a pas d’événement divers défini dans la présente version du protocole.

3.5.2	Message Hello
Les messages Hello LDP sont échangés au titre du mécanisme de découverte LDP ; voir le paragraphe 2.4 "Découverte de LDP".

Le codage du message Hello est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|   Hello (0x0100)            |      Longueur de message      |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                 TLV de paramètres Hello communs               |
+---------------+---------------+---------------+---------------+
|                     Paramètres facultatifs                    |
+---------------+---------------+---------------+---------------+

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message.

TLV de paramètres Hello communs : Il spécifie les paramètres communs à tous les messages Hello. Le codage du TLV de paramètres Hello communs est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|Param Hello communs(0x0400)|      Longueur                 |
+-+-+-----------+---------------+---------------+---------------+
|      Temps de garde           |T|R| Réservé                   |
+---------------+---------------+-+-+-----------+---------------+

Temps de garde : C’est le temps de garde du Hello en secondes. Un LSR conserve un enregistrement des Hello reçus des homologues potentiels (voir le paragraphe 3.5.2.1 "Procédures de message Hello"). Le temps de garde de Hello spécifie la durée pendant laquelle le LSR d’envoi va conserver son enregistrement des Hello provenant du LSR receveur sans recevoir un autre Hello. Une paire de LSR négocie les temps de garde qu’ils utilisent pour leurs Hello réciproques. Chacun propose un temps de garde. Le temps de garde utilisé est le minimum des temps de garde proposés dans leurs Hello. Une valeur de 0 signifie d’utiliser la valeur par défaut, qui est de 15 secondes pour les Hello de liaisons et de 45  secondes pour les Hello ciblés. Une valeur de 0xffff signifie l’infini.

T, (Targeted) Hello ciblé : Une valeur de 1 spécifie que ce Hello est un Hello ciblé. Une valeur de 0 spécifie que ce Hello est un Hello de liaison.

R, (Request) Demande d’envoi de Hello ciblés : Une valeur de 1 demande au receveur d’envoyer des Hello ciblés périodiques à la source de ce Hello. Une valeur de 0 ne fait pas de demande. Un LSR qui initie la découverte étendue règle R à 1. Si R est à 1, le LSR receveur vérifie si il a été configuré pour envoyer avec cette demande des Hello ciblés à la source du Hello en réponse aux Hello. Si il n’a pas été configuré pour cela, il ignore la demande. Si il l’a été, il initie des transmissions périodiques de Hello ciblés à la source du Hello.

Réservé : Ce champ est réservé. Il DOIT être réglé à zéro à l’émission et ignoré à réception .

Paramètres facultatifs : Ce champ de longueur variable du message Hello contient 0, un ou plusieurs paramètres, codés chacun comme TLV. Les paramètres facultatifs définis par cette version du protocole sont  :

Paramètre facultatif	Type	Longueur	Valeur
Adresse de transport IPv4	0x0401	4	Voir ci-dessous
Numéro de séquence de configuration	0x0402	4	Voir ci-dessous
Adresse de transport IPv6	0x0403	 16	Voir ci-dessous

Adresse de transport IPv4 : Spécifie l’adresse IPv4 à utiliser pour le LSR d’envoi lors de l’ouverture de la connexion TCP de la session LDP. Si ce TLV facultatif n’est pas présent, l’adresse IPv4 de source pour le paquet UDP qui porte le Hello DEVRAIT être utilisée.

Numéro de séquence de configuration : Spécifie un numéro de séquence de configuration de 4 octets non signés qui identifie l’état de configuration du LSR d’envoi. Utilisé par le LSR receveur pour détecter les changements de configuration sur le LSR d’envoi.

Adresse de transport IPv6 : Spécifie l’adresse IPv6 à utiliser pour le LSR d’envoi lorsque il ouvre la connexion TCP de la session LDP. Si ce TLV facultatif n’est pas présent, l’adresse IPv6 de source pour le paquet UDP qui porte le Hello DEVRAIT être utilisée.

3.5.2.1	Procédures du message Hello
Un LSR qui reçoit des Hello d’un autre LSR conserve une adjacence de Hello correspondant aux Hello. Le LSR entretient un temporisateur de garde avec l’adjacence de Hello, qui est redémarré chaque fois qu’il reçoit un Hello qui correspond à l’adjacence de Hello. Si le temporisateur de garde pour une adjacence de Hello arrive à expiration, le LSR élimine l’adjacence de Hello : voir aux paragraphes 2.5.5 "Maintenance des adjacences de Hello" et 2.5.6 "Maintenance des sessions LDP".

Il est recommandé que l’intervalle entre les transmissions de Hello soit au plus d’un tiers du temps de garde de Hello.

Un LSR traite un Hello LDP reçu comme suit  :
1.	Le LSR vérifie si le Hello est acceptable. Les critères pour déterminer si un Hello est acceptable dépendent de la mise en œuvre (voir plus loin des exemples de critères).
2.	Si le Hello n’est pas acceptable, le LSR l’ignore.
3.	Si le Hello est acceptable, le LSR vérifie si il a une adjacence de Hello pour la source du Hello. Si oui, il redémarre le temporisateur de garde pour l’adjacence de Hello. Si non, il crée une adjacence de Hello pour la source du Hello et lance son temporisateur de garde.
4.	Si le Hello porte des TLV facultatifs, le LSR les traite (voir ci-dessous).
5.	Finalement, si le LSR n’a pas de session LDP pour l’espace d’étiquette spécifié par l’identifiant LDP dans l’en-tête de PDU pour le Hello, il suit les procédures du paragraphe 2.5.1 "Établissement dfe session LDP".

Voici des exemples de critères d’acceptabilité pour les Hello de liaison et ciblés :

Un Hello de liaison est acceptable si l’interface sur laquelle il a été reçu a été configurée pour la commutation d’étiquettes.

Un Hello ciblé provenant d’une adresse de source A est acceptable si :
-	le LSR a été configuré pour accepter les Hello ciblés, ou
-	si le LSR a été configuré pour envoyer des Hello ciblés à A.

Voici comment un LSR traite les TLV facultatifs de Hello :

Adresse de transport : Le LSR associe l’adresse de transport spécifiée avec l’adjacence de Hello.

Numéro de séquence de configuration : le paramètre facultatif Numéro de séquence de configuration est utilisé par le LSR d’envoi pour signaler des changements de configuration au LSR receveur. Lorsque un LSR receveur qui joue le rôle actif dans l’établissement de la session LDP détecte un changement dans la configuration du LSR d’envoi, il peut supprimer le délai de retard d’établissement de session, s’il en est un, associé au LSR d’envoi (voir au paragraphe 2.5.3 "Initialisation de session").

Un LSR d’envoi qui utilise ce paramètre facultatif est chargé de la maintenance du numéro de séquence de configuration qu’il transmet dans les messages Hello. Chaque fois qu’il y a un changement de configuration sur le LSR d’envoi, il incrémente le numéro de séquence de configuration.

3.5.3	Message Initialisation
Le message Initialisation LDP est échangé au titre de la procédure d’établissement de session LDP ; voir le paragraphe  2.5.1 "Établissement de session LDP".

Le codage du message Initialisation est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|   Initialisation (0x0200)   |   Longueur de message         |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                  TLV de paramètres communs de session         |
+---------------+---------------+---------------+---------------+
|                     Paramètres facultatifs                    |
+---------------+---------------+---------------+---------------+

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message.

TLV de paramètres de session communs : Spécifie les valeurs proposées par le LSR d’envoi pour les paramètres qui doivent être négociés pour chaque session LDP.

Le codage du TLV de paramètres de session communs est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|Param communs sessi(0x0500)|      Longueur                 |
+-+-+-----------+---------------+---------------+---------------+
| Version du protocole          |    Temps de garde en vie      |
+---------------+---------------+---------------+---------------+
|A|D|  Réservé  |     PVLim     |      Longueur max de PDU      |
+-+-+-----------+---------------+---------------+---------------+
|                 Identifiant LDP du receveur                   |
+                               +---------------+---------------+
|                               |
+---------------+---------------+

Version du protocole : Entier non signé de deux octets contenant le numéro de version du protocole. La présente version de la spécification porte la version 1 de protocole LDP.

Temps de garde en vie : Entier non signé différent de zéro de deux octets qui indique le nombre de secondes que le LSR d’envoi propose pour la valeur du temps de garde en vie. Le LSR receveur DOIT calculer la valeur du temporisateur de garde en vie en utilisant le plus petit de son temps de garde en vie proposé et du temps de garde en vie reçu dans la PDU. La valeur choisie pour le temps de garde en vie indique le nombre maximum de secondes qui peut s’écouler entre la réception de PDU successives de la part de l’homologue LDP sur la connexion TCP de session. Le temporisateur de garde en vie est remis à zéro chaque fois qu’arrive une PDU.

A, (Advertisement) Discipline d’annonce d’étiquette : Indique le type d’annonce d’étiquette. Une valeur de 0 signifie une annonce vers l’aval non sollicitée; une valeur de 1 signifie vers l’aval à la demande.

Si un LSR propose vers l’aval non sollicité et si l’autre propose vers l’aval à la demande, les règles de résolution de cette différence sont :
-	Si la session est pour une liaison ATM contrôlée par étiquette ou une liaison en relais de trame contrôlée par étiquette, c’est vers l’aval à la demande qui DOIT alors être utilisé.
-	Autrement, vers l’aval non sollicité DOIT être utilisé.
Si la discipline d’annonce d’étiquette déterminée de cette façon est inacceptable pour un LSR, il DOIT envoyer un message Notification Mode d’annonce de session/paramètres rejeté en réponse au message Initialisation et ne pas établir la session.

D, Détection de boucle : Indique si la détection de boucle fondée sur les vecteurs de chemin est activée. Une valeur de 0 signifie que la détection de boucle est désactivée ; une valeur de 1 signifie que la détection de boucle est activée.

PVLim, Limite de vecteur de chemin : Longueur maximum configurée de vecteur de chemin. DOIT être 0 si la détection de boucle est désactivée (D = 0). Si les procédures de détection de boucle exigeraient que le LSR envoie un vecteur de chemin qui excède cette limite, le LSR se comportera comme si une boucle avait été détectée pour la FEC en question.

Lorsque la détection de boucle est activée dans une portion d’un réseau, il est recommandé que tous les LSR de cette portion du réseau soient configurés avec la même limite de vecteur de chemin. Bien que la connaissance de la limite de vecteur de chemin d’un homologue ne change pas le comportement d’un LSR, cela permet au LSR d’alerter un opérateur d’une possible erreur de configuration.

Réservé : Ce champ est réservé. Il DOIT être réglé à zéro à l’émission et ignoré à réception .

Longueur maximum de PDU : Entier non signé de deux octets qui propose la longueur maximum admissible des PDU LDP pour la session. Une valeur de 255 ou moins spécifie la longueur maximum par défaut de 4096 octets.
Le LSR receveur DOIT calculer la longueur maximum de PDU pour la session en utilisant la plus petite entre sa longueur maximale de PDU et celle proposée par son homologue. La longueur maximum de PDU par défaut s’applique avant l’achèvement de l’initialisation de session.
Si la longueur maximum de PDU déterminée de cette façon est inacceptable pour un LSR, il DOIT envoyer un message Notification Longueur max de PDU de session/Paramètres rejetés en réponse au message Initialisation et ne pas établir la session.

Identifiant de receveur LDP : Identifie l'espace d’étiquettes du receveur. Cet identifiant LDP, avec l’identifiant LDP de l’envoyeur dans l’en-tête de PDU, permet au receveur de faire correspondre le message Initialisation avec une de ses adjacences de Hello; voir le paragraphe  3.5.2.1 "Procédures de message Hello".

Si il n”y a pas d’adjacence de Hello correspondante, le LSR DOIT envoyer un message Notification Session rejetée/Pas de Hello en réponse au message Initialisation et ne pas établir la session.

Paramètres facultatifs : Ce champ de longueur variable contient 0, un ou plusieurs paramètres, codé chacun en TLV. Ce sont  :
Paramètre facultatif	Type	Longueur	Valeur
Paramètres de session ATM	0x0501	variable	Voir ci-dessous
Paramètres de session de relais de trame 	0x0502	variable	Voir ci-dessous

Paramètres de session ATM : Utilisé lorsque une session LDP gère un échange d’étiquettes pour une liaison ATM pour spécifier des paramètres de session spécifiques d’ATM.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|   ATM Sess Parms (0x0501) |      Longueur                 |
+-+-+-----------+---------------+---------------+---------------+
| M |   N   |D|                        Réservé                  |
+---+-------+-+-+---------------+---------------+---------------+
|             Gamme d’étiquette ATM Composant 1                 |
+---------------+---------------+---------------+---------------+
~                                                               ~
+---------------+---------------+---------------+---------------+
|              Gamme d’étiquette ATM Composant N                |
+---------------+---------------+---------------+---------------+

M, (Merge) Capacités de fusion ATM : Spécifie les capacités de fusion d’un commutateur ATM. Les valeurs suivantes sont acceptées dans cette version de la spécification :
Valeur	Signification
0	Fusion non acceptée
1	Fusion de VP acceptée
2	Fusion de VC acceptée
3	Fusion de VP & VC acceptée

Si les capacités de fusion des deux LSR diffèrent, alors :
-	Les LSR sans fusion et les LSR à fusion de VC peuvent librement interopérer.
-	L’interopérabilité de commutateurs capables de fusion de VP avec des commutateurs sans capacité de fusion de VP fera l’objet d’études complémentaires.
Lorsque les LSR diffèrent sur l’utilisation de la fusion de VP, la session est établie, mais la fusion de VP n’est pas utilisée.

Noter que si la fusion de VP est utilisée, il est de la responsabilité du nœud d’entrée de s’assurer que le VCI choisi est unique au sein du domaine LSR.

N, Nombre de composants de gamme d’étiquette : Spécifie le nombre de composants de gamme d’étiquettes ATM inclus dans le TLV.

D, Directionnalité du VC : Une valeur de 0 spécifie la capacité de VC bidirectionnel, ce qui signifie que le LSR peut (au sein d’un certain VPI) prendre en charge l’utilisation d’un certain VCI comme une étiquette pour les deux directions de la liaison indépendamment. Une valeur de 1 spécifie une capacité unidirectionnelle de VC, ce qui signifie que (au sein d’un certain VPI) un certain VCI peut apparaître dans une transposition d’étiquette pour une seule direction de la liaison. Lorsque l’un ou l’autre ou les deux homologues spécifient la capacité de VC unidirectionnelle, les deux LSR utilisent l’allocation d’étiquette unidirectionnelle de VC pour la liaison comme suit  : les LSR comparent leurs identifiants LDP comme des entiers non signés  ; le LSR qui a le plus grand identifiant LDP ne peut allouer comme étiquettes que des VCI impairs dans la gamme des VPI/VCI. Le système qui a le plus petit identifiant LDP ne peut allouer comme étiquettes que des VCI pairs dans la gamme des VPI/VCI.

Réservé : Ce champs est réservé. Il DOIT être réglé à zéro à l’émission et ignoré à réception .

Un ou plusieurs composants de gamme d’étiquettes ATM : Liste de composants de gamme d’étiquettes ATM qui ensemble spécifient la gamme d’étiquettes acceptée par le LSR émetteur.

Un LSR receveur DOIT calculer l’intersection entre la gamme reçue et sa propre gamme d’étiquettes prise en charge. L’intersection est la gamme dans laquelle le LSR peut allouer et accepter des étiquettes. Les LSR NE DOIVENT PAS établir une session avec des voisins pour lesquels l’intersection des gammes est NULLE. Dans ce cas, le LSR DOIT envoyer un message Notification Session rejetée/Gamme d’étiquettes de paramètres en réponse au message Initialisation et ne pas établir la session.

Le codage pour un composant de gamme d’étiquettes ATM est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Rés  |     VPI minimum       |       VCI minimum             |
+-------+-------+---------------+---------------+---------------+
|  Rés  |    VPI maximum        |      VCI maximum              |
+-------+-------+---------------+---------------+---------------+

Rés : Ce champ est réservé. Il DOIT être réglé à zéro à l’émission et DOIT être ignoré à réception.

VPI minimum (12 bits) : Ce champ de 12 bits spécifie la limite inférieure d’un bloc d’identifiants de chemin virtuel qui est accepté sur le commutateur d’origine. Si le VPI fait moins de 12 bits, il DEVRAIT être justifié à droite dans ce champ et les bits précédents DEVRAIENT être réglés à 0.

VCI minimum (16 bits) : Ce champ de 16 bits spécifie la limite inférieure d’un bloc d’identifiants de canal virtuel qui est accepté sur le commutateur d’origine. Si le VCI fait moins de 16 bits, il DEVRAIT être justifié à droite dans ce champ et les bits précédents DEVRAIENT être mis à 0.

VPI maximum (12 bits) : Ce champ de 12 bits spécifie la limite supérieure d’un bloc d’identifiants de chemin virtuel qui est accepté sur le commutateur d’origine. Si le VPI fait moins de 12 bits, il DEVRAIT être justifié à droite dans ce champ et les bits précédents DEVRAIENT être mis à 0.

VCI maximum (16 bits) : Ce champ de 16 bits spécifie la limite supérieure d’un bloc d’identifiants de connexion virtuelle qui est accepté sur le commutateur d’origine Si le VCI fait moins de 16 bits, il DEVRAIT être justifié à droite dans ce champ et les bits précédents DEVRAIENT être mis à 0.

Lorsque des LSR homologues sont connectés indirectement au moyen d’un VP ATM, le LSR d’envoi DEVRAIT régler les champs VPI minimum et maximum à 0, et le LSR receveur DOIT ignorer les champs VPI Minimum et Maximum.

Paramètres de session de relais de trame : Utilisé quand une session LDP gère un échange d’étiquettes pour une liaison en relais de trame pour spécifier des paramètres de session spécifiques du relais de trame.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Param session RT (0x0502) |      Longueur                 |
+-+-+-----------+---------------+---------------+---------------+
| M |   N   |D|                        Réservé                  |
+---+-------+-+-+---------------+---------------+---------------+
|         Gamme d’étiquettes de relais de trame composant 1     |
+---------------+---------------+---------------+---------------+
|                                                               |
~                                                               ~
|                                                               |
+---------------+---------------+---------------+---------------+
|         Gamme d’étiquettes de relais de trame composant N     |
+---------------+---------------+---------------+---------------+

M, (Merge) Capacité de fusion de relais de trame : Spécifie la capacité de fusion d’un commutateur de relais de trame. Les valeurs suivantes sont prises en charge dans cette version de la spécification :
Valeur	Signification
0	Fusion non prise en charge
1	Fusion prise en charge
Les LSR de relais de trame sans fusion et capables de fusion peuvent librement interopérer.

N, Nombre de composants de gamme d’étiquette : Spécifie le nombre de composants de gamme d’étiquettes de relais de trame inclus dans le TLV.

D, Directionnalité de VC : Une valeur de 0 spécifie la capacité de VC bidirectionnel VC, ce qui signifie que le LSR peut prendre en charge l’utilisation d’un certain DLCI comme étiquette pour les deux directions de la liaison indépendamment. Une valeur de 1 spécifie une capacité de VC unidirectionnel, ce qui signifie qu’un certain DLCI peut apparaître dans une transposition d’étiquette seulement pour une direction de la liaison. Lorsque l’un ou l’autre ou les deux homologues spécifient une capacité unidirectionnelle de VC, les deux LSR utilisent l’allocation d’étiquette de VC unidirectionnel comme suit. Les LSR comparent leurs identifiants LDP comme des entiers non signés. Le LSR qui a le plus grand identifiant LDP ne peut allouer comme étiquettes que des DLCI impairs dans cette gamme. Le système qui a le plus petit identifiant LDP ne peut allouer comme étiquettes que des DLCI pairs dans la gamme.

Réservé : Ce champ est réservé. Il DOIT être réglé à zéro à l’émission et ignoré à réception .

Un ou plusieurs composants de gamme d’étiquettes de relais de trame : Liste de composants de gamme d’étiquettes de relais de trame qui ensemble spécifient la gamme d’étiquettes prise en charge par le LSR émetteur.

Un LSR récepteur DOIT calculer l’intersection entre la gamme reçue et sa propre gamme d’étiquettes prise en charge. L’intersection est la gamme dans laquelle le LSR peut allouer et accepter des étiquettes. Les LSR NE DOIVENT PAS établir une session avec des voisins pour lesquels l’intersection des gammes est NULLE. Dans ce cas, le LSR DOIT envoyer un message Notification Session rejetée/Gamme de paramètres d’étiquettes en réponse au message Initialisation et ne pas établir la session.

Le codage pour un composant de gamme d’étiquettes de relais de trame est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Réservé     |Lon|                DLCI minimum                 |
+-------------+-+-+-------------+---------------+---------------+
| Réservé         |                DLCI maximum                 |
+---------------+-+-------------+---------------+---------------+

Réservé : Ce champ est réservé. Il DOIT être réglé à zéro à l’émission et ignoré à réception .

Lon : Ce champ spécifie le nombre de bits du DLCI. Les valeurs suivantes sont acceptées :
Longueur 	Bits du DLCI
0	10
2	23
Les valeurs de longueur 1 et 3 sont réservées.

DLCI minimum : Ce champ de 23 bits spécifie la limite inférieure d’un bloc d’identifiants de connexion de liaison de données (DLCI, Data Link Connection Identifier) qui est accepté sur le commutateur d’origine. Le DLCI DEVRAIT être justifié à droite dans ce champ et les bits inutilisés DEVRAIE  NT être mis à 0.

DLCI maximum : Ce champ de 23 bits spécifie la limite supérieure d’un bloc d’identifiants de connexion de liaison de données (DLCI) qui est accepté sur le commutateur d’origine. Le DLCI DEVRAIT être justifié à droite dans ce champ et les bits inutilisés DEVRAIENT être à 0.

Noter qu’il n’y a pas de TLV générique de paramètres de session pour les sessions qui annoncent des étiquettes génériques.

3.5.3.1	Procédures du message Initialisation
Voir au paragraphe 2.5.1 "Établissement de session LDP" et en particulier au paragraphe 2.5.3 "Initialisation de session" les procédures générales de traitement du message Initialisation.

3.5.4	Message Garder en vie
Un LSR envoie des messages Garder en vie au titre d’un mécanisme qui surveille l’intégrité de la connexion de transport de la session LDP.

Le codage du message Garder en vie est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| GarderEnVie (0x0201)        |      Longueur de message      |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                     Paramètres facultatifs                    |
+---------------+---------------+---------------+---------------+

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message.

Paramètres facultatifs : Aucun paramètre facultatif n’est défini pour le message Garder en vie.

3.5.4.1	Procédures du message Garder en vie
Le mécanisme du temporisateur GarderEnVie décrit au paragraphe 2.5.6 "Maintenance des sessions LDP" remet à zéro le temporisateur GarderEnVie d’une session chaque fois qu’une PDU LDP est reçue sur la connexion TCP de la session. Le message Garder en vie est fourni pour permettre de remettre à zéro le temporisateur Garder en vie dans des circonstances où un LSR n’a pas d’autres informations à communiquer à un homologue LDP.

Un LSR DOIT s’arranger pour que son homologue reçoive de lui un message LDP au moins tous les intervalles de GarderEnVie. Tout message de protocole LDP fera l’affaire, mais dans des circonstances où aucun autre message de protocole LDP n’a été envoyé dans la période, un message Garder en vie DOIT être envoyé.

3.5.5	Message Adresse
Un LSR envoie le message Adresse à un homologue LDP pour annoncer ses adresses d’interface.

Le codage du message Adresse est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|   Adresse (0x0300)          |      Longueur de message      |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                                                               |
|                    TLV Liste d’adresses                       |
|                                                               |
+---------------+---------------+---------------+---------------+
|                     Paramètres facultatifs                    |
+---------------+---------------+---------------+---------------+

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message.

TLV Liste d’adresses : Liste des adresses d’interfaces annoncées par le LSR d’envoi. Le codage du TLV Liste d’adresses est spécifié au paragraphe 3.4.3 "TLV Liste d’adresses".

Paramètres facultatifs : aucun paramètre facultatif n’est défini pour le message Adresse.

3.5.5.1	Procédures du message Adresse
Un LSR qui reçoit un message Adresse utilise les adresses qu’il apprend pour maintenir une base de données pour la transposition entre identifiants d’homologues LDP et adresses de prochain bond ; voir au paragraphe 2.7 "Identifiants LDP et adresses de prochain bond".

Lorsque une nouvelle session LDP est initialisée et avant d’envoyer un message Transposition d’étiquette ou Demande d’étiquette, un LSR DEVRAIT annoncer ses adresses d’interface avec un ou plusieurs messages Adresse.

Chaque fois que un LSR "active" une nouvelle adresse d’interface, il DEVRAIT annoncer la nouvelle adresse par un message Adresse.

Chaque fois que un LSR "désactive" une adresse annoncée précédemment, il DEVRAIT retirer l’adresse par un message Retrait d’adresse; voir au paragraphe 3.5.6 "Message Retrait d’adresse".

Si un LSR ne prend pas en charge une famille d’adresse spécifiée dans le TLV Liste d’adresses, il DEVRAIT envoyer un message Notification Famille d’adresse non acceptée à son LDP pour signaler une erreur et interrompre le traitement du message.

Un LSR peut réannoncer une adresse (A) qu’il avait annoncée précédemment sans retirer explicitement l’adresse. Si le receveur a déjà le lien d’adresse (LSR, A) il DEVRAIT n’entreprendre aucune autre action.

Un LSR peut retirer une adresse (A) sans l’avoir annoncé précédemment. Si le receveur n’a pas de lien d’adresse (LSR, A) il DEVRAIT n’entreprendre aucune autre action.

3.5.6	Message Retrait d’adresse
Un LSR envoie le message Retrait d’adresse à un homologue LDP pour retirer des adresses d’interface annoncées précédemment.

Le codage du message Retrait d’adresse est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|  Retrait d’adresse (0x0301) |      Longueur de message      |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                                                               |
|                     TLV Liste d’adresses                      |
|                                                               |
+---------------+---------------+---------------+---------------+
|                     Paramètres facultatifs                    |
+---------------+---------------+---------------+---------------+

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message.

TLV Liste d’adresses : Liste des adresses d’interface qui sont retirées par le LSR d’envoi. Le codage du TLV Liste d’adresses est spécifié au paragraphe 3.4.3 "TLV Liste d’adresses".

Paramètres facultatifs : aucun paramètre facultatif n’est défini pour le message Retrait d’adresse.

3.5.6.1	Procédures du message Retrait d’adresse
Voir au paragraphe 3.5.5.1 "Procédures du message Adresse".

3.5.7	Message Transposition d’étiquette
Un LSR envoie un message Transposition d’étiquette à un homologue LDP pour annoncer des liens FEC-étiquette à l’homologue.

Le codage du message Transposition d’étiquette est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Transpo d’étiquette (0x0400)|      Longueur de message      |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                      TLV FEC                                  |
+---------------+---------------+---------------+---------------+
|                      TLV Étiquette                            |
+---------------+---------------+---------------+---------------+
|                     Paramètres facultatifs                    |
+---------------+---------------+---------------+---------------+

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message.

TLV FEC : Spécifie le composant FEC de la transposition FEC-étiquette qui est annoncée. Voir le codage au paragraphe 3.4.1 "TLV FEC".

TLV Étiquette : Spécifie le composant Étiquette de la transposition FEC-étiquette. Voir le codage au paragraphe 3.4.2 "TLV Étiquette".

Paramètres facultatifs : Ce champ de longueur variable contient 0, un ou plusieurs paramètres, codé chacun en TLV. Les paramètres facultatifs sont  :

Paramètre facultatif	Longueur	Valeur
TLV Identifiant de message Demande d’étiquette	4	Voir ci-dessous
TLV Compte de bonds 	1	Voir ci-dessous
TLV Vecteur de chemin	variable	Voir ci-dessous

Le codage pour les TLV Compte de bonds et Vecteur de chemin se trouve au paragraphe 3.4 "Codages de TLV pour les paramètres d’utilisation courante".

Identifiant de message Demande d’étiquette : si ce message Transposition d’étiquette est une réponse à un message Demande d’étiquette, il DOIT inclure le paramètre facultatif Identifiant de message Demande d’étiquette. La valeur de ce paramètre facultatif est l’identifiant de message du message Demande d’étiquette correspondant.

Compte de bonds : Spécifie le total courant du nombre de bonds de LSR le long du LSP en cours d’établissement par le message Étiquette. Le paragraphe 3.4.4.1 "Procédures de compte de bonds" décrit comment traiter ce TLV.

Vecteur de chemin : Spécifie les LSR le long du LSP établit par le message Étiquette. Le paragraphe 3.4.5.1 "Procédures de vecteur de chemin" décrit comment traiter ce TLV.

3.5.7.1	Procédures du message Transposition d’étiquette
Le message Transposition est utilisé par un LSR pour distribuer une transposition d’étiquette pour une FEC à un homologue LDP. Si un LSR distribue une transposition pour une FEC à plusieurs homologues LDP, la question de savoir si il transpose une seule étiquette à la FEC et distribue cette transposition à tous ses homologues, ou si il utilise une transposition différente pour chacun de ses homologues, est une affaire locale.

Un LSR est responsable de la cohérence de la transposition des étiquettes qu’il a distribuées et de ce que ses homologues ont ces transpositions.

Un LSR qui reçoit un message Transposition d’étiquette d’un LSR aval pour un préfixe NE DEVRAIT PAS utiliser l’étiquette pour la transmission tant que son tableau d’acheminement ne contient pas une entrée qui corresponde exactement à l’élément de FEC.

Pour plus de détails, voir l’Appendice A, "Procédures de distribution d’étiquettes LDP".

3.5.7.1.1	Transposition en contrôle indépendant
Si un LSR est configuré pour le contrôle indépendant, un message Transposition est transmis par le LSR dans l’une des conditions suivantes :
1.	Le LSR reconnaît une nouvelle FEC via le tableau de transmission, et le mode d’annonce d’étiquette est vers l’aval non sollicité.
2.	Le LSR reçoit un message Demande d’un homologue amont pour une FEC présente dans le tableau de transmission du LSR.
3.	Changement de prochain bond pour une FEC au profit d’un autre homologue LDP lorsque la détection de boucle est configurée.
4.	Changement des attributs d’une transposition.
5.	Réception d’une transposition de la part du prochain bond aval ET
a)	il n’a pas été créé de transposition amont, OU
b)	la détection de boucle est configurée, OU
c)	les attributs de la transposition ont changé.

3.5.7.1.2	Transposition en contrôle ordonné
Si un LSR fait le contrôle ordonné, un message Transposition est transmis par les LSR aval dans l’une des conditions suivantes :
1.	Le LSR reconnaît une nouvelle FEC via le tableau de transmission et est la sortie pour cette FEC.
2.	Le LSR reçoit un message Demande d’un homologue amont pour une FEC présente dans le tableau de transmission du LSR, et le LSR est la sortie pour cette FEC OU a une transposition aval pour cette FEC.
3.	Le prochain bond pour une FEC change pour un autre homologue LDP, et la détection de boucle est configurée.
4.	Les attributs d’une transposition changent.
5.	La réception d’une transposition de la part d’un prochain bond aval, ET
a)	aucune transposition amont n’a été créée, OU
b)	la détection de boucle est configurée, OU
c)	les attributs de la transposition ont changé.

3.5.7.1.3	Annonce d’étiquette vers l’aval à la demande
En général, le LSR amont est chargé de demander la transposition d’étiquettes lorsque il fonctionne en mode vers l’aval à la demande. Cependant, sauf si on suit des règles, il est possible que les LSR du voisinage qui ont des modes d’annonce différents se trouvent dans une situation de blocage où tout fonctionne correctement, mais aucune étiquette n’est distribuée. Par exemple, considérons deux LSR, Ru et Rd, où Ru est le LSR amont et Rd est le LSR aval pour une certaine FEC. Dans cet exemple, Ru utilise le mode d’annonce vers l’aval non sollicité et Rd utilise le mode vers l’aval à la demande. Dans ce cas, Rd peut supposer que Ru va demander une transposition d’étiquette lorsque il en veut une et Ru peut supposer que Rd va annoncer une étiquette si il veut que Ru en utilise une. Si Rd et Ru fonctionnent comme suggéré, aucune étiquette ne sera distribuée de Rd à Ru.

Cette situation de blocage peut être évitée si la règle suivante est observée : un LSR fonctionnant en mode vers l’aval à la demande NE DEVRAIT PAS être supposé envoyer d’annonce de transposition non sollicitée. Donc, si le LSR aval fonctionne en mode vers l’aval à la demande, le LSR amont est chargé de demander en tant que de besoin les transpositions d’étiquettes.

3.5.7.1.4	Annonce d’étiquette vers l’aval non sollicitée
En général, le LSR aval est chargé d’annoncer une transposition d’étiquette lorsque il veut qu’un LSR amont utilise l’étiquette. Un LSR amont peut produire une demande de transposition si tel est son désir.

La combinaison du mode vers l’aval non sollicité et de la rétention prudente d’étiquettes peut conduire à une situation où un LSR libère pour une FEC l’étiquette dont il aura besoin plus tard. Par exemple, si le LSR Rd annonce au LSR Ru l’étiquette pour une FEC pour laquelle il n’est pas le prochain bond de Ru, Ru va libérer l’étiquette. Si le prochain bond de Ru pour cette FEC change ultérieurement au profit de Rd, il va avoir besoin de l’étiquette précédemment libérée.

Pour traiter cette situation, Ru peut explicitement demander l’étiquette lorsque il en a besoin, ou Rd peut périodiquement la réannoncer à Ru. Dans de nombreuses situations, Ru va savoir quand il a besoin de l’étiquette provenant de Rd. Par exemple, lorsque son prochain bond pour la FEC change au profit de Rd. Cependant, il pourrait y avoir des situations où Ru ne le sait pas. Par exemple, Rd peut tenter d’établir un LSP avec des propriétés non standard. Forcer Ru à demander explicitement l’étiquette dans cette situation exigerait de maintenir l’état sur un LSP potentiel avec des propriétés non standard.

Dans des situations où Ru sait qu’il a besoin de l’étiquette, il est chargé de demander explicitement l’étiquette au moyen d’un message Demande d’étiquette. Dans des situations où Ru peut ne pas savoir qu’il a besoin de l’étiquette, Rd est chargé de réannoncer périodiquement l’étiquette à Ru.

Pour la présente version de LDP, la seule situation où Ru sait qu’il a besoin d’une étiquette pour une FEC de la part de Rd est lorsque Rd est son prochain bond pour la FEC, que Ru n’a pas d’étiquette provenant de Rd, et que le LSP pour la FEC est un LSP qui peut être établi avec les TLV définis dans le présent document.

3.5.8	Message Demande d’étiquette
Un LSR envoie le message Demande d’étiquette à un homologue LDP pour demander un lien (transposition) pour une FEC.

Le codage du message Demande d’étiquette est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Demande d’étiquette (0x0401)|      Longueur de message      |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                     TLV FEC                                   |
+---------------+---------------+---------------+---------------+
|                     Paramètres facultatifs                    |
+---------------+---------------+---------------+---------------+

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message.

TLV FEC : FEC pour laquelle une étiquette est demandée. Voir le codage au paragraphe 3.4.1 "TLV FEC".

Paramètres facultatifs : Ce champ de longueur variable contient 0, un ou plusieurs paramètres, codé chacun en TLV. Les paramètres facultatifs sont  :
Paramètre facultatif	Longueur	Valeur
TLV Compte de bonds	1	Voir ci-dessous
TLV Vecteur de chemin	variable	Voir ci-dessous

Les codages pour les TLV Compte de bonds et Vecteur de chemins se trouvent au paragraphe 3.4 "Codages des TLV pour les paramètres d’utilisation courante".

Compte de bonds : Spécifie le total en cours du nombre de bonds de LSR le long du LSP en cours d’établissement par le message Demande d’étiquette. Le paragraphe 3.4.4.1 "Procédures de compte de bonds" décrit comment traiter ce TLV.

Vecteur de chemin : Spécifie les LSR le long du LSP en cours d’établissement par le message Demande d’étiquette. Le paragraphe 3.4.5.1 "Procédures de vecteur de chemin" décrit comment traiter ce TLV.

3.5.8.1	Procédures du message Demande d’étiquette
Le message Demande d’étiquette est utilisé par un LSR amont pour demander explicitement que le LSR aval alloue et annonce une étiquette pour une FEC.

Un LSR peut transmettre un message Demande dans une des conditions suivantes :

1.	Le LSR reconnaît une nouvelle FEC via le tableau de transmission, et le prochain bond est un homologue LDP, et le LSR n’a pas encore une transposition de la part du prochain bond pour cette FEC.

2.	Le prochain bond pour cette FEC change, et le LSR n’a pas encore de transposition provenant de ce prochain bond pour cette FEC.

Noter que si le LSR a déjà un message Demande d’étiquette en cours pour le nouveau prochain bond, il NE DEVRAIT PAS produire une Demande d’étiquette supplémentaire en réponse à un changement de prochain bond.

3.	Le LSR reçoit une demande d’étiquette pour une FEC de la part d’un homologue LDP amont, la FEC du prochain bond est un homologue LDP, et le LSR n’a pas encore de transposition de la part du prochain bond.

Noter que comme un LSR sans fusion doit établir un LSP distinct pour chaque homologue amont qui demande une étiquette, il doit envoyer une Demande d’étiquette distincte pour chacun de ces homologues. Cela a pour conséquence qu’un LSR sans fusion peut avoir plusieurs messages Demande d’étiquette pour une certaine FEC en cours au même moment.

Le LSR receveur DEVRAIT répondre à un message Demande d’étiquette par une Transposition d’étiquette pour l’étiquette demandée, ou par un message Notification indiquant pourquoi il ne peut pas satisfaire la demande.

Lorsque la FEC pour laquelle une étiquette est demandée est un élément de FEC Préfixe, le LSR receveur utilise son tableau d’acheminement pour déterminer sa réponse. Sauf si son tableau d’acheminement comporte une entrés qui correspond exactement au préfixe demandé, le LSR DOIT répondre par un message Notification Pas de chemin.

L’identifiant de message du message Demande d’étiquette sert d’identifiant pour la transaction de demande d’étiquette. Lorsque le LSR receveur répond par un message Transposition d’étiquette, le message de transposition DOIT inclure un paramètre facultatif TLV Demande d’étiquette/Identifiant de message retourné qui comporte l’identifiant de message du message Demande d’étiquette. Noter que comme les LSR utilisent les identifiants de message Demande d’étiquette comme identifiants de transaction, un LSR NE DEVRAIT PAS réutiliser l’identifiant de message d’un message Demande d’étiquette tant que la transaction correspondante n’est pas achevée.

La présente version du protocole définit les codes d’état suivants pour un message Notification qui signale qu’une demande ne peut pas être satisfaite :

Pas de chemin : La FEC pour laquelle une étiquette a été demandée inclut un élément de FEC pour lequel le LSR n’a pas de chemin.

Pas de ressources d’étiquette : Le LSR ne peut pas fournir une étiquette à cause de limitations de ressources. Lorsque les ressources deviennent disponibles, le LSR DOIT le notifier au LSR demandeur en envoyant un message Notification avec le code d’état Ressources d’étiquettes disponibles.

Un LSR qui reçoit une réponse Pas de ressources d’étiquettes à un message Demande d’étiquette NE DOIT PAS produire d’autres messages Demande d’étiquette jusqu’à ce qu’il reçoive un message Notification avec le code d’état Ressources d’étiquettes disponibles.

Boucle détectée : Le LSR a détecté message Demande d’étiquette en boucle.

Voir l’Appendice A, "Procédures de distribution d’étiquettes LDP", pour plus de détails.

3.5.9	Message Demande d’abandon d’étiquette
Le message Demande d’abandon d’étiquette peut être utilisé pour interrompre un message Demande d’étiquette en cours.

Le codage du message Demande d’abandon d’étiquette est :
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Demande abandon Étiq(0x0404)|      Longueur de message      |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                     TLV FEC                                   |
+---------------+---------------+---------------+---------------+
|      TLV Identifiant de message de demande d’étiquette        |
+---------------+---------------+---------------+---------------+
|                     Paramètres facultatifs                    |
+---------------+---------------+---------------+---------------+

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message.

TLV FEC : Identifie la FEC pour laquelle la demande d’étiquette est interrompue.

TLV Identifiant de message Demande d’étiquette : Spécifie l’identifiant du message Demande d’étiquette à interrompre.

Paramètres facultatifs : Aucun paramètre facultatif n’est défini pour le message Demande d’abandon d’étiquette.

3.5.9.1	Procédures du message Demande d’abandon d’étiquette
Un LSR Ru peut envoyer un message Demande d’abandon d’étiquette pour interrompre un message Demande d’étiquette en cours pour une FEC, envoyé à un LSR Rd dans les circonstances suivantes :
1.	Le prochain bond de Ru pour la FEC a changé du LSR Rd au LSR X ; ou
2.	Ru est un LSR sans fusion qui n’est pas LSR d’entrée, et a reçu une demande d’abandon d’étiquette pour la FEC de la part d’un homologue amont Y.
3.	Ru est un LSR à fusion, qui n’est pas LSR d’entrée et il a reçu une demande d’abandon d’étiquette pour la FEC d’un homologue amont Y et Y est le seul LSR amont (le dernier) qui demande une étiquette pour la FEC.

Il peut y avoir d’autres situations où un LSR peut choisir d’interrompre un message Demande d’étiquette en cours afin de récupérer la ressource associée au LSP en cours. Cependant, la spécification de stratégies générales d’utilisation du mécanisme d’abandon sort du domaine d’application de LDP.

Lorsque un LSR reçoit un message Demande d’abandon d’étiquette, si il n’a pas précédemment répondu au Demande d’étiquette qui va être interrompu par un message Transposition d’étiquette ou quelque autre message Notification, il DOIT accuser réception de l’abandon en répondant avec un message Notification Demande d’étiquette interrompue. Le Notification DOIT inclure un TLV Identifiant de message Demande d’étiquette qui porte l’identifiant de message du message Demande d’étiquette interrompu.

Si un LSR reçoit un message Demande d’abandon d’étiquette après qu’il a répondu au Demande d’étiquette en question par un message Transposition d’étiquette ou un message Notification, il ignore la demande d’abandon.

Si un LSR reçoit un message Transposition d’étiquette en réponse à un message Demande d’étiquette après qu’il a envoyé un message Demande d’abandon d’étiquette pour interrompre la demande d’étiquette, l’étiquette dans le message Transposition d’étiquette est valide. Le LSR peut choisir d’utiliser l’étiquette ou de la libérer avec un message Libération d’étiquette.

Un LSR qui interrompt un message Demande d’étiquette ne peut pas réutiliser l’identifiant de message pour le message Demande d’étiquette jusqu’à ce qu’il reçoive de son homologue un des messages suivants :
-	un message Notification Demande d’étiquette interrompue qui accuse réception de l’abandon,
-	un message Transposition d’étiquette en réponse au message Demande d’étiquette en cours d’abandon,
-	un message Notification en réponse au message Demande d’étiquette en cours d’abandon (par exemple, Boucle détectée, Pas de ressource d’étiquette, etc.).

Pour se protéger contre des homologues en retard ou des mises en œuvres d’homologue déficientes, un LSR peut choisir d’affecter une temporisation à la réception de ces messages. La période de temporisation devrait être relativement longue (plusieurs minutes). Si la période de temporisation s’écoule sans réponse de la part de l’homologue, le LSR peut réutiliser l’identifiant de message du message Demande d’étiquette ; si il le fait, il devrait aussi éliminer tous les enregistrements de messages Demande d’étiquette et Interruption d’étiquette en cours.

Noter que la réponse à un message Demande d’abandon d’étiquette n’est jamais "ordonnée". C’est-à-dire, la réponse ne dépend pas de l’état aval de l’établissement de LSP qui est interrompu. Un LSR qui reçoit un message Demande d’abandon d’étiquette DOIT le traiter immédiatement, sans considération de l’état aval du LSP, en répondant par une Notification Demande d’étiquette interrompue ou en l’ignorant, selon ce qui est approprié.

3.5.10	Message Retrait d’étiquette
Un LSR envoie un message Retrait d’étiquette à un homologue LDP pour lui signaler qu’il ne peut pas continuer à utiliser la transposition spécifique étiquette/FEC que le LSR avait annoncée précédemment. Cela casse la transposition entre les FEC et les étiquettes.

Le codage du message Retrait d’étiquette est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Retrait d’étiquette (0x0402)|      Longueur de message      |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                     TLV FEC                                   |
+---------------+---------------+---------------+---------------+
|                     TLV Étiquette (facultatif)                |
+---------------+---------------+---------------+---------------+
|                     Paramètres facultatifs                    |
+---------------+---------------+---------------+---------------+

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message.

TLV FEC : Identifie la FEC pour laquelle la transposition d’étiquette/FEC est retirée.

Paramètres facultatifs : Ce champ de longueur variable contient 0, un ou plusieurs paramètres, codé chacun en TLV. Les paramètres facultatifs sont  :
Paramètre facultatif	Longueur	Valeur
TLV Étiquette	variable	Voir ci-dessous
Le codage du TLV Étiquette se trouve au paragraphe 3.4.2 "TLV Étiquette".

Étiquette : Si il est présent, spécifie l’étiquette qui est retirée (voir les procédures ci-dessous).

3.5.10.1	Procédures du message Retrait d’étiquette
Un LSR transmet un message Retrait d’étiquette dans les conditions suivantes :
1.	Le LSR ne reconnaît plus une FEC précédemment connue pour laquelle il avait annoncé une étiquette.
2.	Le LSR a décidé unilatéralement (par exemple, via sa configuration) de ne plus faire la commutation d’étiquettes pour une (ou des) FEC et il en retire la transposition d’étiquettes.

Le TLV FEC spécifie la FEC pour laquelle les étiquettes sont à retirer. Si aucun TLV Étiquette ne suit la FEC, toutes les étiquettes associées à la FEC sont à retirer ; autrement, seule l’étiquette spécifiée dans le TLV Étiquette facultatif est à retirer.

Le TLV FEC peut contenir l’élément FEC générique ; s’il en est ainsi, il ne peut contenir aucun autre élément de FEC. Dans ce cas, si le message Retrait d’étiquette contient un TLV Étiquette facultatif, alors l’étiquette est à retirer de toutes les FEC auxquelles elle est liée. Si il n’y a pas de TLV Étiquette facultatif dans le message Retrait d’étiquette, le LSR d’envoi retire alors toutes les transpositions d’étiquette annoncées précédemment au LSR receveur.

Un LSR qui reçoit un message Retrait d’étiquette DOIT répondre par un message Libération d’étiquette.

Voir d’autres détails à l’Appendice A, "Procédures de distribution d’étiquettes LDP".

3.5.11	Message Libération d’étiquette
Un LSR envoie un message Libération d’étiquette à un homologue LDP pour lui signaler que le LSR n’a plus besoin de la transposition spécifique FEC-étiquette demandée précédemment et/ou annoncée par l’homologue.

Le codage du Message Libération d’étiquette est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Libérat d’étiquette (0x0403)|      Longueur de message      |
+---------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                     TLV FEC                                   |
+---------------+---------------+---------------+---------------+
|                     TLV Étiquette (facultatif)                |
+---------------+---------------+---------------+---------------+
|                     Paramètres facultatifs                    |
+---------------+---------------+---------------+---------------+

Identifiant de message : Valeur de 32 bits utilisée pour identifier ce message.

TLV FEC : Identifie la FEC pour laquelle la transposition FEC-étiquette est libérée.

Paramètres facultatifs : Ce champ de longueur variable contient 0, un ou plusieurs paramètres, codé chacun en TLV. Les paramètres facultatifs sont  :
Paramètre facultatif	Longueur	Valeur
TLV Étiquette	variable	Voir ci-dessous
Les codages pour les TLV Étiquette se trouvent au paragraphe 3.4.2 "TLV Étiquette".

Étiquette : S’il est présent, c’est l’étiquette libérée (voir les procédures ci-dessous).

3.5.11.1	Procédures du message Libération d’étiquette
Un LSR transmet un message Libération d’étiquette à un homologue lorsqu’il n’a plus besoin d’une étiquette précédemment reçue ou demandée de cet homologue.

Un LSR DOIT transmettre un message Libération d’étiquette dans une des conditions suivantes :
1.	Le LSR qui envoie la transposition d’étiquette n’est plus le prochain bond pour la FEC transposée, et le LSR est configuré pour un fonctionnement prudent.
2.	Le LSR reçoit une transposition d’étiquette d’un LSR qui n’est pas le prochain bond pour la FEC, et le LSR est configuré pour le fonctionnement prudent.
3.	Le LSR reçoit un message Retrait d’étiquette.

Noter que si un LSR est configuré pour le "mode libéral", un message de libération ne sera jamais transmis dans le cas des conditions (1) et (2) spécifiées ci-dessus. Dans ce cas, le LSR amont conserve chacune des étiquettes non utilisées, de sorte qu’il puisse les utiliser immédiatement si l’homologue aval devient le prochain bond pour la FEC.

Le TLV FEC spécifie la FEC pour laquelle les étiquettes sont à libérer. Si aucun TLV Étiquette ne suit la FEC, toutes les étiquettes associées à la FEC sont à libérer ; autrement, seule l’étiquette spécifiée dans le TLV Étiquette facultatif est à libérer.

Le TLV FEC peut contenir l’élément générique de FEC ; si il en est ainsi, il ne peut contenir aucun autre élément de FEC. Dans ce cas, si le message Libération d’étiquette contient un TLV Étiquette facultatif, l’étiquette est alors à libérer pour toutes les FEC auxquelles elle est liée. Si il n’y a pas un TLV Étiquette facultatif dans le message Libération d’étiquette, alors le LSR d’envoi va libérer toutes les transpositions d’étiquette apprises précédemment du LSR receveur.

Voir les détails complémentaires dans l’Appendice A, "Procédures de distribution des étiquettes LDP".

3.6.	Messages et TLV pour l’extensibilité
La prise en charge de l’extensibilité de LDP inclut les règles pour les bits U et F qui spécifient comment un LSR traite les TLV et messages inconnus.

Ce paragraphe spécifie les TLV et les messages pour fabricant privé et pour utilisation expérimentale.

3.6.1	Extensions LDP de fabricant privé
Les TLV et messages de fabricant privé sont utilisés pour convoyer des informations de fabricant privé entre les LSR.

3.6.1.1	TLV Fabricant privé LDP
La gamme de type de 0x3E00 à 0x3EFF est réservée pour les TLV de fabricant privé.

Le codage pour un TLV de fabricant privé est  :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|    Type (0x3E00-0x3EFF)   |            Longueur           |
+-+-+-----------+---------------+---------------+---------------+
|                   Identifiant de fabricant                    |
+---------------+---------------+---------------+---------------+
|                                                               |
|                           Données.                            |
~                                                               ~
|                                                               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bit U (Unknown) : Bit TLV inconnu. À réception d’un TLV inconnu, si U n’est pas établi (= 0) une notification DOIT être retournée à l’origine du message et le message entier DOIT être ignoré ; si U est établi (= 1) le TLV inconnu est ignoré en silence, et le reste du message est traité comme si le TLV inconnu n’existait pas.

La détermination de si un message de fabricant privé est compris se fonde sur le type et sur le champ obligatoire Identifiant de fabricant.

Les mises en œuvre qui prennent en charge les TLV Fabricant privé DOIVENT prendre en charge une interface de configuration accessible à l’utilisateur qui cause l’établissement du bit U sur tous les TLV Fabricant privé transmis ; cette exigence PEUT être satisfaite par une interface de configuration accessible à l’utilisateur qui empêche la transmission de tous les TLV Fabricant privé pour lesquels le bit U n’est pas établi.

Bit F (Forward) : Bit de transmission du TLV inconnu. Ce bit ne s’applique que lorsque le bit U est établi et que le message LDP contenant le TLV inconnu est à transmettre. Si F n’est pas établi (=0), le TLV inconnu n’est pas transmis avec le message contenant ; si F est établi (= 1) le TLV inconnu est transmis avec le message contenant.

Type : Valeur de type dans la gamme de 0x3E00 à 0x3EFF. Ensemble, les champs Type et identifiant de fabricant spécifient que le champ Données est à interpréter.

Longueur : Spécifie la longueur cumulée en octets des champ Identifiant de fabricant et Données.

Identifiant de fabricant : Identifiant IEEE 802 de fabricant tel qu’alloué par l’IEEE.

Données : Les octets restants après l’identifiant de fabricant dans le champ Valeur sont des données facultatives qui dépendent du fabricant.

3.6.1.2	Messages LDP de fabricant privé
La gamme Type de message de 0x3E00 à 0x3EFF est réservée pour les messages de fabricant privé.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|    Msg Type (0x3E00-0x3EFF) |      Longueur de message      |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de message                    |
+---------------+---------------+---------------+---------------+
|                     Identifiant de fabricant                  |
+---------------+---------------+---------------+---------------+
+                                                               +
|                     Paramètres obligatoires restants          |
+                                                               +
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
+                                                               +
|                     Paramètres facultatifs                    |
+                                                               +
|                                                               |
+---------------+---------------+---------------+---------------+

Bit U : Bit de message inconnu. À réception d’un message inconnu, si U n’est pas établi (= 0) une notification est retournée au générateur du message ; si U est établi (= 1) le message inconnu est ignoré en silence.

La détermination de si un message de fabricant privé est compris se fonde sur les paramètres Type de message et l’identifiant de fabricant.

Les mises en œuvre qui prennent en charge les messages de fabricant privé DOIVENT prendre en charge l’interface de configuration accessible à l’utilisateur qui cause l’établissement du bit U sur tous les messages de fabricant privé transmis ; cette exigence PEUT être satisfaite par une interface de configuration accessible à l’utilisateur qui empêche la transmission de tous les messages de fabricant privé pour lesquels le bit U n’est pas établi.

Type de message : Valeur de type de message dans la gamme de 0x3E00 à 0x3EFF. Ensemble, le type de message et l’identifiant de fabricant spécifient comment le message doit être interprété.

Longueur de message : Spécifie la longueur cumulée en octets de l’identifiant de message, de l’identifiant de fabricant, des paramètres obligatoires restants, et des paramètres facultatifs.

Identifiant de message : Entier de 32 bits utilisé pour identifier ce message. Utilisé par le LSR d’envoi pour faciliter l’identification des messages Notification qui peuvent s’appliquer à ce message. Un LSR qui envoie un message Notification en réponse à ce message va inclure cet identifiant de message dans le message Notification ; voir au paragraphe 3.5.1 "Message Notification".

Identifiant de fabricant : Identifiant IEEE 802 de fabricant tel qu’alloué par l’IEEE.

Paramètres obligatoires restants : Ensemble de longueur variable des paramètres de message obligatoires restants.

Paramètres facultatifs : Ensemble de longueur variable des paramètres de message facultatifs.

3.6.2	Extensions LDP expérimentales
La prise en charge des expérimentations par LDP est similaire à la prise en charge des extensions de fabricant privé avec les différences suivantes :
-	La gamme de types de 0x3F00 à 0x3FFF est réservée aux TLV expérimentaux.
-	La gamme de type de message de 0x3F00 à 0x3FFF est réservée aux messages expérimentaux.
-	Le codage des TLV et des messages expérimentaux est similaire au codage de fabricant privé avec la différence suivante.
Les TLV et messages expérimentaux utilisent un champ Identifiant expérimental au lieu d’un champ Identifiant de fabricant. Le champ Identifiant expérimental est utilisé avec le champ Type ou Type de message pour spécifier l’interprétation du TLV ou message expérimental.

L’administration des identifiants expérimentaux est de la responsabilité des expérimentateurs.
3.7	Sommaire des messages
Voici les messages LDP définis dans la présente version du protocole.

Nom du message	Type	Titre du paragraphe
Notification	0x0001	3.5.1 "Message Notification"
Hello	0x0100	3.5.2 "Message Hello "
Initialisation	0x0200	3.5.3 "Message Initialisation"
Garder en vie	0x0201	3.5.4 "Message Garder en vie"
Adresse	0x0300	3.5.5 "Message Adresse"
Retrait d’adresse	0x0301	3.5.6 "Message Retrait d’adresse"
Transposition d’étiquette	0x0400	3.5.7 "Message Transposition d’étiquette"
Demande d’étiquette	0x0401	3.5.8 "Message Demande d’étiquette"
Retrait d’étiquette	0x0402	3.5.10 "Message Retrait d’étiquette"
Libération d’étiquette	0x0403	3.5.11 "Message Libération d’étiquette"
Demande d’abandon d’étiquette	0x0404	3.5.9 "Message Demande d’abandon d’étiquette"
Fabricant privé	0x3E00-0x3EFF	3.6.1.1 "Extensions de fabricant privé LDP"
Expérimental	0x3F00- 0x3FFF	3.6.2 "Extensions LDP expérimentales"

3.8	Sommaire des TLV
Ci-après figurent les TLV définis dans cette version du protocole.

TLV	Type	Titre du paragraphe
FEC	0x0100	3.4.1 "TLV FEC"
Liste d’adresses	0x0101	3.4.3 "TLV Liste d’adresses"
Compte de bonds	0x0103	3.4.4 "TLV Compte de bonds"
Vecteur de chemin	0x0104	3.4.5 "TLV Vecteur de chemin"
Étiquette générique	0x0200	3.4.2.1 "TLV Étiquette générique"
Étiquette ATM	0x0201	3.4.2.2 "TLV Étiquette ATM"
Étiquette de relais de trame	0x0202	3.4.2.3 "TLV Étiquette de relais de trame"
État	0x0300	3.4.6 "TLV État"
État étendu	0x0301	3.5.1 "Message Notification"
PDU retournée	0x0302	3.5.1 "Message Notification"
Message retourné	0x0303	3.5.1 "Message Notification"
Paramètres communs de Hello	0x0400	3.5.2 "Message Hello"
Adresse de transport IPv4	0x0401	3.5.2 "Message Hello"
Numéro de séquence de configuration	0x0402	3.5.2 "Message Hello"
Adresse de transport IPv6	0x0403	3.5.2 "Message Hello"
Paramètres communs de session	0x0500	3.5.3 "Message Initialisation"
Paramètres de session ATM	0x0501	3.5.3 "Message Initialisation"
Paramètres de session relais de trame	0x0502	3.5.3 "Message Initialisation"
Identifiant de message Demande d’étiquette 	0x0600	3.5.7 "Message Transposition d’étiquette"
Fabricant privé	0x3E00- 0x3EFF	3.6.1 "Extensions de fabricant privé LDP"
Expérimental	0x3F00- 0x3FFF	3.6.2 "Extensions LDP expérimentales"

3.9	Sommaire des codes d’état
Les Codes d’état définis dans cette version du protocole figurent ci-après.

La colonne "E" est le réglage exigé pour le bit E de code d’état ; la colonne "Données d’état" est la valeur du champ de 30 bits Données d’état dans le TLV Code d’état. Noter que le réglage du bit F de code d’état est à la discrétion du LSR qui génère le TLV État.

Code d’état	E	Données d’état	Titre du paragraphe
Succès	0	0x00000000	3.4.6 "TLV État"
Mauvais identifiant LDP	1	0x00000001	3.5.1.2 "Événements signalés par ..."
Mauvaise version de protocole	1	0x00000002	3.5.1.2 "Événements signalés par ..."
Mauvaise longueur de PDU	1	0x00000003	3.5.1.2 "Événements signalés par ..."
Type de message inconnu	0	0x00000004	3.5.1.2 "Événements signalés par ..."
Mauvaise longueur de message	1	0x00000005	3.5.1.2 "Événements signalés par ..."
TLV inconnu	0	0x00000006	3.5.1.2 "Événements signalés par ..."
Mauvaise longueur de TLV	1	0x00000007	3.5.1.2 "Événements signalés par ..."
Valeur de TLV mal formée	1	0x00000008	3.5.1.2 "Événements signalés par ..."
Temporisateur de garde expiré	1	0x00000009	3.5.1.2 "Événements signalés par ..."
Fermeture	1	0x0000000A	3.5.1.2 "Événements signalés par ..."
Boucle détectée	0	0x0000000B	2.8 "Détection de boucle"
FEC inconnue	0	0x0000000C	3.4.1.1 "Procédures de FEC"
Pas de chemin	0	0x0000000D	2.8.1 "Message Demande d’étiquette"
Pas de ressource d’étiquette	0	0x0000000E	2.8.1 "Message Demande d’étiquette"
Ressources d’étiquette disponible	0	0x0000000F	2.8.1 "Message Demande d’étiquette"
Session Rejetée/Pas de Hello	1	0x00000010	2.5.3 "Initialisation de session"
Session Rejetée/Mode d’annonce param.	1	0x00000011	2.5.3 "Initialisation de session"
Session Rejetée/Longueur max PDU param.	1	0x00000012	2.5.3 "Initialisation de session"
Session Rejetée/Gamme param. d’étiquette	1	0x00000013	2.5.3 "Initialisation de session"Temporisateur GarderEnVie expiré	1	0x00000014	3.5.1.2 "Événements signalés par ..."
Demande d’étiquette interrompue	0	0x00000015	3.5.9 "Msg Demande d’abandon d’étiquette"
Paramètres de message manquants	0	0x00000016	3.5.1.2 "Événements signalés par ..."
Famille d’adresse non acceptée	0	0x00000017	3.4.1.1 "Procédures de FEC" 
			3.5.5.1 "Procédures du message Adresse"
Session Rejetée/Mauvais tempo GarderEnVie	1	0x00000018	2.5.3 "Initialisation de session"
Erreur interne	1	0x00000019	3.5.1.2 "Événements signalés par ..."

3.10	Numéros bien connus
3.10.1	Accès UDP et TCP
L’accès UDP pour les messages Hello de LDP est 646.

L’accès TCP pour établir les connexions de session LDP est 646.

3.10.2	Étiquette implicite NULLE
L’étiquette implicite NULLE est définie au paragraphe 4.1.5 de la [RFC3031] comme suit :
"L’étiquette NULLE implicite est une étiquette avec une sémantique particulière qu’un LSR peut lier à un préfixe d’adresse. Si le LSR Ru, en consultant son ILM, voit que le paquet étiqueté P doit être transmis ensuite à Rd, mais que Rd a distribué un lien de NUL implicite au préfixe d’adresse correspondant, au lieu de remplacer alors la valeur de l’étiquette du sommet de la pile d’étiquettes, Ru saute la pile d’étiquettes, puis transmet le paquet résultant à Rd."

L’étiquette implicite NULLE est représentée dans LDP comme un TLV Étiquette générique avec la valeur de champ Étiquette de 3, comme défini dans la [RFC3032].

4.	Considérations relatives à l’IANA

LDP définit les espaces de noms suivants qui exigent d’être gérés :
-	Espaces de noms Type de message
-	Espaces de noms TLV Type
-	Espaces de noms Type de FEC
-	Espaces de noms Code d’état
-	Espaces de noms Identifiant expérimental

Les paragraphes qui suivent donnent des lignes directrices pour la gestion de ces espaces de noms.

4.1	Espace de nom des types de message
LDP divise l’espace de noms pour les types de message en trois gammes. Voici des lignes directrices pour la gestion de ces gammes :

-	Type de messages 0x0000 - 0x3DFF. Les types de message dans cette gamme font partie du protocole LDP de base. Suivant les politiques exposées dans la [RFC2434], les types de message dans cette gamme sont alloués par action de consensus de l’IETF.

-	Type de messages 0x3E00 - 0x3EFF. Les types de message dans cette gamme sont réservés aux extensions de fabricant privé et sont de la responsabilité des fabricants individuels (voir au paragraphe 3.6.1.2 "Messages LDP de fabricant privé"). La gestion par l’IANA de cette gamme de l’espace de noms de type de message est inutile.

-	Type de messages 0x3F00 - 0x3FFF. Les types de message dans cette gamme sont réservés aux extensions expérimentales et sont de la responsabilité des expérimentateurs individuels (voir aux paragraphes 3.6.2 "Extensions expérimentales à LDP" et 4.5 "Espace de noms d’identifiant expérimental"). La gestion par l’IANA de cette gamme d’espace de noms de type de message n’est pas nécessaire ; cependant, l’IANA est chargée de gérer une partie de l’espace de noms d’identifiant expérimental (voir ci-dessous).

4.2	Espace de nom des types de TLV
LDP divise l’espace de noms des types de TLV en trois gammes. Voici les lignes directrices pour la gestion de ces gammes  :

-	Types de TLV de 0x0000 à 0x3DFF. Les types de TLV dans cette gamme font partie du protocole LDP de base. Suivant les politiques exposées dans la [RFC2434], les types de TLV dans cette gamme sont allouées par action de consensus de l’IETF.

-	Types de TLV de 0x3E00 à 0x3EFF. Les types de TLV dans cette gamme sont réservés aux extensions de fabricant privé et sont de la responsabilité des fabricants individuels (voir au paragraphe 3.6.1.1 "TLV Fabricants privés LDP"). La gestion par l’IANA de cette gamme de l’espace de noms de type de TLV n’est pas nécessaire.

-	Types de TLV 0x3F00 à 0x3FFF. Les types de TLV dans cette gamme sont réservés aux extensions expérimentales et sont de la responsabilité des expérimentateurs individuels (voir les paragraphes 3.6.2 "Extensions expérimentales à LDP" et 4.5 "Espace de noms d’identifiant expérimental"). La gestion par l’IANA de cette gamme d’espace de noms de TLV n’est pas nécessaire ; cependant, l’IANA est chargée de gérer une partie de l’espace de noms d’identifiant expérimental (voir ci-dessous).

4.3	Espace de nom des types de FEC
La gamme des types de FEC est de 0 à 255.

Suivant les politiques exposées dans la [RFC2434], les types de FEC dans la gamme de 0 à 127 sont alloués par action de consensus de l’IETF, les types dans la gamme de 128 à 191 sont alloués au premier qui le demande, et les types dans la gamme de 192 à 255 sont réservés à des utilisations privées.

4.4	Espace de nom des codes d’état
La gamme des codes d’état est de 0x00000000 à 0x3FFFFFFF.

Suivant les politiques exposées dans la [RFC2434], les codes d’état dans la gamme 0x00000000 à 0x1FFFFFFF sont alloués par action de consensus de l’IETF, les codes dans la gamme de 0x20000000 à 0x3EFFFFFF sont alloués au premier qui les demande, et les codes dans la gamme de 0x3F000000 à 0x3FFFFFFF sont réservés pour utilisation privée.

4.5	Espace de nom d’identifiant expérimental
La gamme des identifiants expérimentaux est de 0x00000000 à 0xffffffff.

Suivant les politiques exposées dans la [RFC2434], les identifiants expérimentaux dans la gamme de 0x00000000 à 0xefffffff sont alloués au premier qui les demande, et les identifiants expérimentaux dans la gamme de 0xf0000000 à 0xffffffff sont réservés pour utilisation privée.

5.	Considérations pour la sécurité

La présente section identifie les menaces auxquelles LDP peut être vulnérable et expose les moyens par lesquels ces menaces peuvent être déjouées.

5.1	Usurpation d’identité
Il y a deux types de communication LDP qui pourraient être la cible d’une attaque en usurpation d’identité.

1.	Découverte des échanges portés par UDP
Les LSR indiquent leur volonté d’établir et maintenir une session LDP en envoyant périodiquement des messages Hello. La réception de Hello sert à créer une nouvelle "adjacence de Hello", s’il n’en existe déjà une, ou pour rafraîchir celle qui existe. Usurper un paquet Hello pour une adjacence existante peut causer la péremption de l’adjacence et il peut en résulter la terminaison de la session associée. Cela peut survenir lorsque le Hello usurpé spécifie un temps de garde petit, ce qui fait que le receveur attend des Hello pendant cet intervalle, alors que le vrai voisin continue d’envoyer des Hello à la plus faible fréquence sur laquelle ils s’étaient mis d’accord antérieurement.

Les LSR directement connectés au niveau liaison échangent des messages Hello basiques sur la liaison. La menace d’usurpation de Hello de base peut être réduite par :
o	n’accepter les Hello de base que sur les interfaces auxquelles seuls des LSR de confiance peuvent être directement connectés,
o	ignorer les Hello de base qui ne sont pas adressés à l’adresse Tous les routeurs sur le groupe de diffusion groupée de ce sous-réseau.
Les LSR qui ne sont pas directement connectés au niveau liaison peuvent utiliser les messages de Hello étendus pour indiquer leur volonté d’établir une session LDP. Un LSR peut réduire la menace d’usurpation de Hello étendus en les filtrant et en n’acceptant que ceux qui sont générés par des sources permises par une liste d’accès.

2.	Communication de session portée par TCP
LDP spécifie l’utilisation de l’option TCP Signature MD5 pour fournir l’authenticité et l’intégrité des messages de session.

La [RFC2385] affirme que l’authentification MD5 est maintenant considérée par certains comme trop faible pour cette application. Elle souligne aussi qu’une option TCP similaire avec un algorithme de hachage plus fort (elle cite SHA-1 en exemple) pourrait être déployée. À notre connaissance, aucune option TCP de cette sorte n’a été définie et déployée. Cependant, on note que LDP peut utiliser toute technique de résumé de message disponible sur TCP, et lorsque il en sera spécifiée une plus forte que MD5 et qu’elle sera mise en œuvre, la mise à niveau de LDP pour l’utiliser serait relativement facile.

5.2	Confidentialité
LDP ne fournit pas de mécanisme pour la protection de la confidentialité de la distribution des étiquettes.

Les exigences de sécurité des protocoles de distribution des étiquettes sont essentiellement identiques à celles des protocoles qui distribuent des informations d’acheminement. En fournissant un mécanisme pour assurer l’authenticité et l’intégrité de ses messages, LDP fournit un niveau de sécurité qui est au moins aussi bon, bien que pas meilleur, que ce qui peut être fourni par les protocoles d’acheminement eux-mêmes. La question plus générale de savoir si la confidentialité devrait être une exigence pour les protocoles d’acheminement sort du domaine d’application du présent document.

On pourrait objecter que la distribution des étiquettes exige la confidentialité pour contrer la menace d’usurpation d’étiquette. Cependant, cette confidentialité ne protègerait pas contre les attaques d’usurpation d’étiquette car les paquets de données portent les étiquettes en clair. De plus, les attaques d’usurpation d’étiquette peuvent être faites sans connaître la FEC liée à une étiquette.

Pour éviter les attaques d’usurpation d’étiquette, il est nécessaire de s’assurer que les paquets de données étiquetés le sont par des LSR de confiance et que les étiquettes placées sur les paquets sont acquises correctement par les LSR étiqueteurs.

5.3	Déni de service
LDP fournit ceux cibles potentielles aux attaques de déni de service (DoS) :

1.	Accès UDP bien connu pour la découverte de LDP
Un administrateur de LSR peut traiter la menace d’attaque de DoS via des Hello de base en s’assurant que le LSR est directement connecté aux seuls homologues qui peuvent être de confiance pour ne pas lancer de telles attaques. Les interfaces avec des homologues intérieurs au domaine de l’administrateur ne devraient pas représenter une menace dans la mesure où les homologues intérieurs sont sous le contrôle de l’administrateur. Les interfaces avec les homologues extérieurs au domaine représentent une menace potentielle car les homologues extérieurs ne le sont pas. Un administrateur peut réduire cette menace en ne connectant le LSR qu’aux homologues extérieurs qui peuvent être de confiance pour ne pas initier d’attaque de Hello de base.

Les attaques de DoS via des Hello étendus représentent une menace potentiellement plus sérieuse. Cette menace peut être traitée par filtrage des Hello étendus en utilisant des listes d’accès qui définissent des adresses avec lesquelles la découverte étendue est permise. Cependant, effectuer le filtrage exige des ressources de LSR.

Dans un environnement où un nuage MPLS de confiance peut être identifié, les LSR à la bordure du nuage peuvent être utilisés pour protéger les LSR intérieurs contre des attaques de DoS via des Hello étendus en filtrant les Hello étendus générés en dehors du nuage MPLS de confiance, en n’acceptant que ceux qui sont générés aux adresses permises par les listes d’accès. Ce filtrage protège les LSR à l’intérieur du nuage mais consomme des ressources à la périphérie.

2.	Accès TCP bien connu pour l’établissement de session LDP
Comme les autres protocoles de plan de contrôle qui utilisent TCP, LDP peut être la cible d’attaques de DoS, telles que des attaques de synchronisation (SYN). LDP n’est ni plus ni moins vulnérable à de telles attaques que les autres protocoles de plan de contrôle qui utilisent TCP.

La menace de telles attaques peut être quelque peu atténuée par ce qui suit :

o	Un LSR DEVRAIT éviter les écoutes sans discrimination du TCP pour l’établissement de session LDP. Il DEVRAIT n’utiliser que les écoutes qui sont spécifiques des homologues découverts. Cela lui permet d’éliminer les paquets d’attaque tôt dans le traitement car il est moins probable qu’ils correspondent à une connexion existante ou en cours d’ouverture.

o	L’utilisation de l’option MD5 aide un peu car elle empêche un segment SYN d’être accepté à moins que la somme de contrôle de segment MD5 soit valide. Cependant, le receveur doit calculer la somme de contrôle avant de pouvoir décider d’éliminer un segment SYN par ailleurs acceptable.

o	L’utilisation de mécanismes de liste d’accès appliquée à la frontière du nuage MPLS d’une manière similaire à celle suggérée ci-dessus pour les Hello étendus peut protéger l’intérieur contre des attaques générées de l’extérieur du nuage.

6.	Domaines d’études futures

Les sujets suivants qui ne sont pas traités dans la présente version de LDP sont des domaines possibles pour des études futures :

-	Le paragraphe 2.16 de l’architecture de MPLS [RFC3031] demande que la négociation initiale de protocole de distribution d’étiquettes entre LSR homologues permette à chaque LSR de déterminer si son homologue est capable de sauter la pile d’étiquettes. La présente version de LDP suppose que les LSR prennent en charge le saut d’étiquette pour tous les types de liaison excepté ATM et le relais de trame. Une version future pourra spécifier les moyens de faire que cette détermination fasse partie de la négociation d’initialisation de session.

-	La prise en charge par LDP de la classe de service n’est pas spécifiée dans cette version. La prise en charge de la classe de service pourra être traitée dans une future version.

-	La prise en charge de la diffusion groupée par LDP n’est pas spécifiée dans cette version. La prise en charge de la diffusion groupée pourra être traitée dans une future version.

-	La prise en charge par LDP de la commutation d’étiquette multi chemin n’est pas spécifiée dans cette version. La prise en  charge du multi chemin pourra être traitée dans une future version.

-	La prise en charge par LDP de la signalisation de l’unité de transmission maximum n’est pas spécifiée dans cette version. Elle est discutée dans le document expérimental [RFC3988].

-	La spécification actuelle ne traite pas la découverte de l’homologue de base sur des supports multi accès sans diffusion (NBMA, Non-Broadcast Multi-Access). La solution disponible dans la spécification actuelle est d’utiliser la découverte étendue d’homologue dans de tels établissements. La question de définir un mécanisme sémantiquement similaire à la découverte de base (limite de un bond, lien de l’adjacence de Hello à une interface) qui utilise des adresses préconfigurées de voisin fera l’objet d’une étude complémentaire.

-	La spécification actuelle ne prend pas en charge la fermeture d’une adjacence. Les motifs de cette situation et les mécanismes pour y arriver feront l’objet d’une étude complémentaire.

-	La spécification actuelle n’inclut pas de méthode pour sécuriser les messages Hello, pour détecter les Hello usurpés. Les scénarios où cela est nécessaire, ainsi que le mécanisme pour le réaliser feront l’objet d’études complémentaires.

-	La spécification actuelle n’offre pas la capacité de détecter un redémarrage rapide sans état de plan de contrôle. La méthode pour le réaliser, éventuellement par un numéro "d’incarnation/d’instance" porté dans le message Hello, fera l’objet d’une étude complémentaire.

-	La spécification actuelle ne prend pas en charge un message "fin de LIB", analogue au message "fin de RIB" de BGP qu’un LSR LDP (fonctionnant en mode DU) utiliserait à la suite de l’établissement de session. La discussion sur le besoin d’un tel mécanisme et sur sa mise en œuvre fera l’objet d’une étude complémentaire.

-	La spécification actuelle ne traite pas des situations où différents LSR annoncent la même adresse. De telles situations surviennent normalement par suite d’erreurs de configuration, et le but, dans ce cas, est de fournir aux LSR qui annoncent la même adresse suffisamment d’informations pour permettre aux opérateurs de prendre des actions correctrices. La spécification de ce mécanisme fera l’objet d’un document distinct.

7.	Changements par rapport à la RFC3036

Voici une liste des changements par rapport à la RFC3036
1.	Retrait de la FEC Adresse d’hôte et de ses références, car elle n’est utilisée dans aucune mise en œuvre.
2.	Partage de la liste des référence en références normatives et références pour information.
3.	Retrait de "Utilisation de la commutation de chemin virtuel ATM par MPLS" de la liste des références normatives, et de ses références.
4.	Retrait de la référence à la RFC1700, remplacée par un lien sur http://www.iana.org/assignments/address-family-numbers.
5.	Retrait de la référence à la RFC1771, remplacée par une référence à la RFC4271.
6.	Précision sur l’utilisation du bit F.
7.	Ajout de l’option permettant l’horizon partagé en effectuant le contrôle ordonné.
8.	Précision du traitement des messages avec le bit U établi durant la procédure d’initialisation de session.
9.	Précision du traitement du bit E durant la procédure d’initialisation de session.
10.	Ajout d’un texte expliquant que le message Fermeture dans le diagramme de transition d’état est mis en œuvre comme message Notification avec un TLV État indiquant une erreur fatale.
11.	Ajout du cas de la longueur de TLV trop courte dans la spécification du traitement des TLV mal formés.
12.	Explication de la menace de sécurité posée par les Hello usurpés.
13.	Ajout d’une référence aux  RFC4271 et RFC4278 et d’un texte sur la variation de maturité des normes par rapport à l’option MD5.
14.	Ajout d’un texte tiré de la RFC3031 qui explique le traitement de l’étiquette implicite NULLE.
15.	Inclusion du codage des DLCI pour retirer la référence normative à la RFC3034.
16.	Déplacement des références aux RFC3031, 3032, et 3034 dans le paragraphe des références pour information.
17.	Dans le paragraphe sur le traitement du TLV inconnu, suppression des références à des paragraphes inexistants (errata dans le document d’origine).
18.	Ajout d’un texte clarifiant comment réaliser l’interopérabilité lors de l’envoi de TLV et messages de fabricant privé.
19.	Dans la procédure de "réception de demande d’étiquette", si une boucle est détectée, changement de la procédure d’envoi d’une notification avant d’abandonner le reste du traitement.
20.	Dans la procédure de "réception de libération d’étiquette", précision du comportement des LSR capables de fusion.
21.	Dans la procédure de "réception de libération d’étiquette", précision du comportement de réception de FEC inconnue.
22.	Dans la note 4 de "Détection de changement de la FEC du prochain bond", modification du texte pour faire référence à l’ensemble correct de conditions d’envoi d’une procédure de demande d’étiquette (erreur typographique dans le document d’origine).
23.	Dans la procédure où le "LSR décide de ne plus faire la commutation d’étiquette pour une FEC", précision du fait que l’étiquette ne doit pas être réutilisée jusqu’à ce qu’une libération d’étiquette ait été reçue.
24.Dans le sous-programme "Prepare_Étiquette_Mapping_Attributes", ajout d’une note concernant le traitement des TLV inconnus selon leurs bits U et F.
25.Dans la procédure de traitement du message Adresse, précision du comportement dans le cas où un LSR reçoit une nouvelle annonce d’une adresse précédemment annoncée, ou du retrait d’un adresse de la part d’un LSR qui ne l’avait pas annoncée précédemment.
26.	Dans le sous-programme "Réception de transposition d’étiquette", précision de la signification de PrevAdvLabel lorsque aucun message d’annonce d’étiquette n’a été envoyé précédemment.
27.	Dans la procédure de "Réception de transposition d’étiquette", si une boucle est détectée, modification de la procédure d’envoi d’une notification avant d’interrompre le reste du traitement.
28.	Dans la procédure de "Réception de transposition d’étiquette", correction de l’étape LMp.10 pour traiter les messages de transposition d’étiquette pour des LSP supplémentaires (sans fusion) pour la FEC.
29.	Dans la procédure de "Réception de transposition d’étiquette", précision du comportement lors de la réception d’une étiquette dupliquée pour la même FEC.
30.	Dans le sous-programme "Réception d’une demande d’abandon d’étiquette", précision du comportement des LSR sans fusion.
31.	Ajout des éléments suivants au paragraphe sur les domaines d’études futures :
o	extensions pour communiquer l’unité maximum de transmission,
o	découverte de l’homologue de base sur support NBMA,
o	option de fermeture d’une adjacence,
o	mécanismes pour sécuriser les messages Hello,
o	détection d’un redémarrage rapide sans état du plan de contrôle,
o	prise en charge d’un message "Fin de LIB",
o	mécanisme pour traiter le cas où différents LSR annoncent la même adresse.

8.	Remerciements

Le présent document a été produit au titre de l’avancement de la spécification LDP à l’état de projet de norme. Le présent document a été publié à l’origine comme RFC3036 en janvier 2001. Il avait été produit par le groupe de travail MPLS de l’IETF et ses auteurs conjoints étaient Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette, et Bob Thomas.

Les idées et le texte de la RFC3036 ont été collectés à de nombreuses sources. Nous tenons à remercier Rick Boivie, Ross Callon, Alex Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Rekhter, et Arun Viswanathan de leurs apports à la RFC3036.

Les éditeurs tiennent à remercier Eric Gray, David Black, et Sam Hartman de leurs apports et de leur relecture du présent document.

De plus, les éditeurs tiennent à remercier les membres du groupe de travail MPLS pour leurs idées et le soutien qu’ils ont apporté au présent document, et en particulier, à Eric Rosen, Luca Martini, Markus Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama Ramakrishnan, Nick Weeds, Adrian Farrel, et Andy Malis.

9.	Références
9.1.	Références normatives

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC 5226)

[RFC1321]	R. Rivest, "Algorithme de résumé de message MD5", avril 1992. (Information)

[ASSIGNED_AF] http://www.iana.org/assignments/address-family-numbers 

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

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

[RFC3035]	B. Davie et autres, "Utilisation de MPLS dans la commutation de circuit virtuel LDP et ATM", janvier 2001. (P.S.)

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

9.2.	Références pour information

[Dobb]	Dobbertin, "The Status of MD5 After a Recent Attack", RSA Labs' CryptoBytes, Vol. 2 n°2, été 1996. http://www.rsa.com/rsalabs/pubs/cryptobytes.html 

[RFC2328]	J. Moy, "OSPF version 2", STD 54, avril 1998.

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

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

[RFC3032]	E. Rosen et autres, "Codage de pile d'étiquettes MPLS", janvier 2001.

[RFC3034]	A. Conta, P. Doolan, A. Malis, "Spécification de l'utilisation de la commutation d'étiquettes sur les réseaux en relais de trame", janvier 2001. (P.S.)

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

[RFC3988]	B. Black, K. Kompella, "Extensions de signalisation d'unité de transmission maximum pour le protocole de distribution d'étiquettes", janvier 2005. (Expérimentale)

[RFC4271]	Y. Rekhter, T. Li et S. Hares, "Protocole de routeur frontière version 4 (BGP-4)", janvier 2006. (D.S.)

[RFC4278]	S. Bellovin, A. Zinin, "Différence de niveau de normalisation entre l'option de signature MD5 de TCP de la (RFC2385) et la spécification BGP-4", janvier 2006. (Information)

Appendice A.	Procédures de distribution des étiquettes LDP

La présente section spécifie le comportement de distribution d’étiquettes en termes de réponse du LSR aux événements suivants :
-	Réception du message Demande d’étiquette ;
-	Réception du message Transposition d’étiquette ;
-	Réception du message Demande d’abandon d’étiquette ;
-	Réception du message Libération d’étiquette ;
-	Réception du message Retrait d’étiquette ;
-	Reconnaissance d’une nouvelle FEC ;
-	Détection d’un changement de la FEC du prochain bond ;
-	Réception du message Notification / Interruption de demande d’étiquette ;
-	Réception du message Notification / Pas de ressource d’étiquette ;
-	Réception du message Notification / Pas de chemin ;
-	Réception du message Notification / Boucle détectée ;
-	Réception du message Notification / Ressources d’étiquette disponibles ;
-	Détection que des ressources locales d’étiquette sont devenues disponibles ;
-	Le LSR décide de ne plus effectuer la commutation d’étiquettes pour une FEC ;
-	Fin de temporisation des demandes d’étiquette différées.

La spécification du comportement du LSR en réponse à un événement est en trois parties :
1.	Résumé  : texte qui décrit les grandes lignes de la réponse du LSR à l’événement.
2.	Contexte  : liste des éléments visés par la partie algorithme de la spécification.
3.	Algorithme : algorithme de la réponse du LSR à l’événement.

Le résumé peut omettre des détails de la réponse du LSR, comme les actions de tenu de livres de bord ou des comportements qui dépendent du mode d’annonce d’étiquettes, du mode de contrôle, ou du mode de rétention d’étiquette utilisé par le LSR. L’intention est que l’algorithme spécifie pleinement et sans ambiguïté la réponse du LSR.

Dans cette section, les algorithmes utilisent les procédures définies dans la spécification de l’architecture MPLS [RFC3031] pour le trafic acheminé bond par bond. Ces procédures sont :

-	La procédure de distribution d’étiquette, qui est effectuée par un LSR aval pour déterminer quand distribuer une étiquette pour une FEC à un homologues LDP. L’architecture définit quatre procédures de distribution d’étiquette :
	contrôle indépendant vers l’aval non sollicité, appelé poussé inconditionnel dans la [RFC3031].
	contrôle ordonné vers l’aval non sollicité, appelé poussé conditionnel dans la [RFC3031].
	contrôle indépendant vers l’aval à la demande, appelé tiré inconditionnel dans la [RFC3031].
	contrôle ordonné vers l’aval à la demande, appelé tiré conditionnel dans la [RFC3031].

-	La procédure de retrait d’étiquette, qui est effectuée par un LSR aval pour déterminer quand retirer une transposition d’étiquette en FEC précédemment distribuée aux homologues LDP. L’architecture définit une seule procédure de retrait d’étiquette. Chaque fois qu’un LSR casse le lien entre une étiquette et une FEC, il DOIT retirer la transposition d’étiquette en FEC de tous les homologues LDP auxquels il avait précédemment envoyé la transposition.

-	La procédure de demande d’étiquette, qui est effectuée par un LSR amont pour déterminer quand demander explicitement qu’un LSR aval lie une étiquette à une FEC et lui envoyer la transposition d’étiquette correspondante. L’architecture définit trois procédures de demande d’étiquette :
	Ne jamais demander. Le LSR ne demande jamais une étiquette.
	Demander quand nécessaire. Le LSR demande une étiquette chaque fois qu’il en a besoin d’une.
	Demande sur demande. Cette procédure est utilisée par les LSR sans fusion d’étiquettes. Le LSR demande une étiquette quand il en reçoit une demande, en plus de chaque fois qu’il en a besoin d’une.

-	Procédure de libération d’étiquette, qui est effectuée par un LSR amont pour déterminer quand libérer une transposition d’étiquette précédemment reçue pour une FEC. L’architecture définit deux procédures de libération d’étiquette :
	rétention prudente d’étiquettes, appelée Libération sur changement dans la [RFC3031].
	rétention libérale d’étiquette, appelée Pas de libération sur changement dans la [RFC3031].

-	Procédure d’utilisation d’étiquette, qui est effectuée par un LSR pour déterminer quand commencer à utiliser une étiquette de FEC pour la transmission/commutation. L’architecture définit trois procédures d’utilisation d’étiquette :
	Utilisation immédiate. Le LSR utilise immédiatement une étiquette reçue d’une FEC de prochain bond pour la transmission/commutation.
	Utilisation si pas de boucle. Le LSR n’utilise une étiquette de FEC reçue d’une FEC de prochain bond pour la transmission/commutation que si il a déterminé qu’en faisant ainsi il ne va pas causer une boucle de transmission.
	Utilisation si boucle non détectée. Cette procédure est la même que Utilisation immédiate sauf si le LSR a détecté une boucle dans le LSP de la FEC. L’utilisation de l’étiquette de la FEC pour la transmission/commutation va continuer jusqu’à ce que le prochain bond pour la FEC change ou que la boucle ne soit plus détectée.

La présente version de LDP n’inclut pas de mécanisme de prévention de boucle ; donc, les procédures ci-dessous n’utilisent pas la procédure Utilisation si pas de boucle.

-	Procédure Pas de chemin d’étiquette (appelée procédure Non disponible dans la [RFC3031]) qui est effectuée par un LSR amont pour déterminer comment répondre à une notification Pas de chemin de la part d’un LSR aval en réponse à une demande de transposition d’étiquette en FEC. La spécification de l’architecture définit deux procédures de Pas de chemin d’étiquette :
	Réessayer la demande. Le LSR devrait produire la demande d’étiquette ultérieurement.
	Ne pas réessayer la demande. Le LSR devrait supposer que le LSR aval fournira une transposition d’étiquette lorsque le LSR aval aura un prochain bond, et il ne devrait pas produire la demande à nouveau.

A.1	Traitement des événements de distribution d’étiquettes
La présente section définit des procédures de distribution d’étiquettes LDP en spécifiant un algorithme pour chaque événement de distribution d’étiquette. L’exigence pour une mise en œuvre de LDP est que le traitement de l’événement doit avoir l’effet spécifié par les algorithmes. C’est-à-dire que une mise en œuvre n’a pas besoin de suivre exactement les étapes spécifiée par les algorithmes pour autant que l’effet soit identique.

Les algorithmes pour traiter les événements de distribution d’étiquette partagent des actions communes. Les spécifications ci-dessous groupent ces actions communes en unités de procédure. Les spécifications pour ces procédures communes sont dans leur propre section, "Procédures communes de distribution d’étiquettes", qui suit celle-ci.

Une mise en œuvre va utiliser des structures de données pour mémoriser les informations sur l’activité du protocole. Le présent appendice spécifie les informations à mémoriser avec un niveau de détail suffisant pour décrire les algorithmes, et suppose la capacité de restituer les informations en tant que de besoin. Il ne spécifie pas les détails des structures de données.

A.1.1	Réception d’une demande d’étiquette
Résumé : La réponse par un LSR à la réception d’une demande d’étiquette de FEC de la part d’un homologue LDP peut impliquer une ou plusieurs des actions suivantes :
-	Transmission d’un message Notification au LSR demandeur qui indique pourquoi une transposition d’étiquette pour la FEC ne peut pas être fournie ;
-	Transmission d’une transposition d’étiquette de FEC au LSR demandeur ;
-	Transmission d’une demande d’étiquette de FEC au prochain bond de la FEC ;
-	Installation d’étiquettes à utiliser pour transmission/commutation par le LSR.

Contexte :
-	LSR : le LSR qui traite l’événement.
-	Source du message : l’homologue LDP qui envoie le message.
-	FEC : la FEC spécifiée dans le message.
-	Rattributes : attributs reçus avec le message, par exemple, Compte de bonds, Vecteur de chemin.
-	Sattributes : attributs à inclure dans le message Demande d’étiquette, s’il en est, propagés au prochain bond de FEC.
-	StoredHopCount  : compte de bonds, s’il en est, précédemment enregistré pour la FEC.

Algorithme :

LRq.1 : Exécute la procédure Check_Received_Attributes (MsgSource, LabelRequest, RAttributes).
	Si Boucle détectée, aller à LRq.4.

LRq.2 : Y a t-il un prochain bond pour la FEC ?
	Si non, aller à LRq.5.

LRq.3 : La source du message est elle le prochain bond ?
	Si non, aller à LRq.6.

LRq.4 : Exécuter la procédure Send_Notification (MsgSource, Boucle détectée).
	Aller à LRq.13

LRq.5 : Exécuter la procédure Send_Notification (MsgSource, Pas de chemin).
	Aller à LRq.13.

LRq.6 : Le LSR a t-il précédemment reçu une demande d’étiquette pour la FEC de la source du message ?
	Si non, aller à LRq.8.  (Voir Note 1.)

LRq.7  : La demande d’étiquette est-elle une demande dupliquée ?
	Si oui, aller à LRq.13.  (Voir Note 2.)

LRq.8 : Enregistrer la demande d’étiquette pour la FEC reçue de la source du message et la marquer comme en cours.

LRq.9 : Effectuer la procédure de distribution d’étiquettes par le LSR :
Pour le contrôle indépendant vers l’aval non sollicité OU pour le contrôle indépendant vers l’aval à la demande
1. Le LSR a t-il précédemment reçu et conservé une transposition d’étiquette pour la FEC de la part du prochain bond ?
Si oui, régler la propagation à IsPropagating.
Si non, régler la propagation à NotPropagating.
2. Exécuter la procédure
Prepare_Étiquette_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, Propagation, StoredHopCount).
3. Exécuter la procédure Send_Étiquette (MsgSource, FEC, SAttributes).
4. Le LSR est il la sortie pour la FEC ? OU le LSR a t-il précédemment reçu et conservé une transposition d’étiquette en FEC du prochain bond ?
Si oui, aller à LRq.11.
Si non, aller à LRq.10.
Pour le contrôle ordonné vers l’aval non sollicité OU pour le contrôle ordonné vers o’aval à la demande
1. Le LSR est il la sortie pour la FEC ? OU le LSR a t-il précédemment reçu et conservé une transposition d’étiquette en FEC du prochain bond ?  (Voir Note 3.)
Si non, aller à LRq.10.
2. Exécuter la procédure Prepare_Étiquette_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount)
3. Exécuter la procédure Send_Étiquette (MsgSource, FEC, SAttributes).
Aller à LRq.11.

LRq.10  : Effectuer la procédure de demande d’étiquette du LSR :
Pour Ne jamais demander
1. Aller à LRq.13.
Pour Demande quand nécessaire OU pour Demande à la demande
1. Exécuter la procédure Prepare_Étiquette_Request_Attributes (Prochain bond, FEC, RAttributes, SAttributes);
2. Exécuter la procédure Send_Étiquette_Request (Next Hop, FEC, SAttributes).
Aller à LRq.13.

LRq.11 : Le LSR a t-il réussi à envoyer une étiquette pour la FEC à la source du message ?
Si non, aller à LRq.13. (Voir Note 4.)

LRq.12 : Effectuer la procédure d’utilisation d’étiquette par le LSR.
Pour Utilisation immédiate OU pour Utilisation si une boucle n’est pas détectée
1. Installer l’étiquette envoyée à la Source du msg et l’étiquette provenant du prochain bond (si le LSR n’est pas la sortie) pour utilisation en transmission/commutation.

LRq.13 : TERMINÉ.

Notes :
1.	Dans le cas où la source du message est un LSR sans fusion d’étiquettes, il va envoyer une demande d’étiquette pour chaque homologue LDP amont qui lui a demandé une étiquette pour la FEC. Le LSR doit être capable de distinguer de telles demandes provenant d’une source de message sans capacité de fusion d’étiquettes des demandes d’étiquette dupliquées.
Le LSR utilise l’identifiant de message des messages Demande d’étiquette reçus pour détecter les demandes dupliquées. Cela signifie qu’un LSR (l’homologue amont) ne peut pas réutiliser l’identifiant de message utilisé pour une demande d’étiquette jusqu’à l’achèvement de la transaction de demande d’étiquette.
2.	Lorsque un LSR envoie une demande d’étiquette à un homologue, il enregistre que la demande a été envoyée et la marque comme en cours. Tant que la demande est marquée comme en cours, le LSR NE DEVRAIT PAS envoyer une autre demande pour la même étiquette à l’homologue. Une telle seconde demande serait une duplication. La procédure Send_Étiquette_Request décrite ci-dessous obéit à cette règle.
Une demande d’étiquette dupliquée est considérée comme une erreur de protocole et DEVRAIT être abandonnée par le LSR receveur (peut-être avec une notification convenable retournée à la source du message).
3.	Si le LSR est sans capacité de fusion, cet essai va échouer.
4.	La procédure Send_Étiquette peut échouer à cause du manque de ressources en étiquette, auquel cas le LSR NE DEVRAIT PAS effectuer la procédure Utilisation d’étiquette.

A.1.2	Réception d’une Transposition d’étiquette
Résumé : La réponse d’un LSR à la réception d’une transposition d’étiquette en FEC de la part d’un homologue LDP peut impliquer une ou plusieurs des actions suivantes :
-	Transmission d’un message Libération d’étiquette pou l’étiquette de FEC à l’homologue LDP ;
-	Transmission d’un message Transposition d’étiquettes pour la FEC à un ou plusieurs homologues LDP ;
-	Installation de l’étiquette nouvellement apprise pour être utilisée à la transmission/commutation par le LSR.

Contexte :
-	LSR : Le LSR qui traite l’événement.
-	Source du message : L’homologue LDP qui envoie le message.
-	FEC : La FEC spécifiée dans le message.
-	Étiquette : L’étiquette spécifiée dans le message.
-	PrevAdvLabel  : L’étiquette pour la FEC, s’il en est, annoncée précédemment à un homologue amont. Si on suppose qu’aucune étiquette n’a été annoncée précédemment, c’est la même étiquette que celle qui est dans le message Transposition d’étiquette qui est traité.
-	StoredHopCount : C’est le compte de bonds précédemment enregistré pour la FEC.
-	Rattributes  : Attributs reçus avec le message, par exemple, Compte de bonds, Vecteur de chemin.
-	SAttributes : Attributs à inclure dans le message Transposition d’étiquette, s’il en est, propagés aux homologues amont.

Algorithme :

LMp.1 :	La transposition d’étiquette reçue correspond elle à une demande d’étiquette en cours pour la FEC envoyée précédemment à la source du message ? 
	Si non, aller à LMp.3.

LMp.2 :	Supprimer l’enregistrement de la demande d’étiquette de FEC en cours.

LMp.3 :	Exécuter la procédure Check_Received_Attributes (MsgSource, LabelMapping, RAttributes).
	Si Pas de boucle détectée, aller à LMp.9.

LMp.4 :	Le LSR a t-il une transposition d’étiquette reçue précédemment de la source du message pour la FEC ? (Voir Note 1.)
	Si non, aller à LMp.8. (Voir Note 2.)

LMp.5 :	L’étiquette reçue précédemment de la source du message correspond elle à l’étiquette (c’est-à-dire, à l’étiquette reçue dans le message) ?  (Voir Note 3.)
	Si non, aller à LMp.8.  (Voir Note 4.)

LMp.6 :	Supprimer la transposition d’étiquette correspondante pour la FEC reçue précédemment de la source du message.

LMp.7 :	Retirer l’étiquette de l’utilisation de transmission/commutation. (Voir Note 5.)

LMp.8 :	Exécuter la procédure Send_Message (MsgSource, Libération d’étiquette, FEC, Étiquette, Boucle détectée, Code d’état). Aller à LMp.33.

LMp.9 :	Le LSR a t-il reçu précédemment de la source du message une transposition d’étiquette pour la FEC pour le LSP en question ?  (Voir Note 6.)
	Si non, aller à LMp.11.

LMp.10 :	L’étiquette reçue précédemment de la source su message correspond elle à Étiquette (c’est-à-dire, l’étiquette reçue dans le message) ?  (Voir Note 3.)
	OU
	la transposition d’étiquette reçue est-elle en réponse à une demande d’étiquette en cours précédemment envoyée à la source du message ?  (Voir Note 12.)
	Si oui, aller à LMp.11.

LMp.10a  : Le LSR fonctionne t-il en mode vers l’aval non sollicité ? Si oui, supprimer la transposition d’étiquette pour l’étiquette reçue précédemment de la source du message et la retirer de l’utilisation en transmission/commutation.
	Exécuter la procédure Send_Message (MsgSource, Libération d’étiquette, FEC, étiquette reçue précédemment de la source du message).

LMp.11 :	Déterminer le prochain bond pour la FEC.

LMp.12 :	La source du message est-elle le prochain bond pour la FEC ?
	Si oui, aller à LMp.14.

LMp.13  :	Le LSR effectue la procédure de libération d’étiquette :
Pour la rétention prudente d’étiquettes :
1. Aller à LMp.32.

Pour la rétention libérale d’étiquette :
1. Enregistrer la transposition d’étiquette pour la FEC avec Étiquette et RAttributes qui ont été reçus de la source du message.
Aller à LMp.33.

LMp.14 : Le LSR est il une entrée pour la FEC ?
	Si non, aller à LMp.16.

LMp.15 : Installer l’étiquette pour une utilisation en transmission/commutation.

LMp.16 : Enregistrer la transposition d’étiquette en FEC avec l’étiquette et les RAttributes qui ont été reçus de la source du message.

LMp.17 : Itérer jusqu’à LMp.31 pour chaque homologue. (Voir Note 7).

LMp.18 : Le LSR a t-il envoyé précédemment une transposition d’étiquette en FEC à l’homologue pour le LSP en question  ?  (Voir Note 8.)
	Si oui, aller à LMp.22.

LMp.19 : La procédure de distribution d’étiquette en contrôle ordonné vars l’aval non sollicité est elle utilisée par le LSR  ?
	Si non, aller à LMp.28.

LMp.20 : Exécuter la procédure Prepare_Étiquette_Mapping_Attributes (Homologue, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).

LMp.21 : Exécuter la procédure Send_Message (Homologue, Transposition d’étiquette, FEC, PrevAdvLabel, SAttributes). (Voir Note 13.)
	Aller à LMp.28.

LMp.22 : Itérer jusqu’à LMp.27 pour chaque transposition d’étiquette en FEC envoyée précédemment à l’homologue.

LMp.23 : Les RAttributes dans la transposition d’étiquette reçue sont ils cohérents avec ceux envoyés précédemment à l’homologue ?  Si oui, continuer l’itération à partir de LMp.22 pour la prochaine transposition d’étiquette. (Voir Note 9.)

LMp.24 : Exécuter la procédure Prepare_Étiquette_Mapping_Attributes (Homologue, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).

LMp.25 : Exécuter la procédure Send_Message (Homologue, Transposition d’étiquette, FEC, PrevAdvLabel, SAttributes).  (Voir Note 10.)

LMp.26 : Mettre à jour l’enregistrement de transposition d’étiquette en FEC envoyée précédemment à l’homologue pour y inclure les nouveaux attributs envoyés.

LMp.27 : Fin de l’itération depuis LMp.22.

LMp.28 : Le LSR a t-il des demandes d’étiquette pour une FEC de la part de l’homologue qui sont marquées en cours ?
	Si non, aller à LMp.30.

LMp.29 : Le LSR effectue la procédure de distribution d’étiquette :
Pour le contrôle indépendant vers l’aval non sollicité OU pour le contrôle ordonné vers l’aval non sollicité
1. Exécuter la procédure Prepare_Étiquette_Mapping_Attributes (Homologue, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount).
2. Exécuter la procédure Send_Étiquette (Homologue, FEC, SAttributes).
Si la procédure échoue, continuer l’itération pour le prochain homologue à LMp.17.
3. Si il n’existe aucune demande en cours pour l’homologue, aller à LMp.30. (Voir Note 11.)

Pour le contrôle indépendant vers l’aval à la demande OU pour le contrôle ordonné vers l’aval à la demande
1. Itérer jusqu’à l’étape 5 pour chaque demande d’étiquette en cours pour la FEC de la part de l’homologue, qui est marquée comme en cours.
2. Exécuter la procédure Prepare_Étiquette_Mapping_Attributes (Homologue, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount)
3. Exécuter la procédure Send_Étiquette (Homologue, FEC, SAttributes).
Si la procédure échoue, continuer l’itération pour le prochain homologue à LMp.17.
4. Supprimer l’enregistrement de la demande en cours.
5. Terminer l’itération depuis l’étape 1.
6. Aller à LMp.30.

LMp.30 : Le LSR effectue la procédure Utilisation d’étiquette :
Pour Utilisation immédiate OU pour Utilisation si boucle non détectée
1. Itérer depuis l’étape 3 pour chaque transposition d’étiquette en FEC précédemment envoyée à l’homologue.
2. Installer l’étiquette reçue et l’étiquette envoyée à l’homologue pour utilisation en transmission/commutation.
3. Terminer l’itération depuis l’étape 1.
4. Aller à LMp.31.

LMp.31 : Fin de l’itération depuis LMp.17.
	Aller à LMp.33.

LMp.32  : Exécuter la procédure Send_Message (MsgSource,  Libération d’étiquette, FEC, Étiquette).

LMp.33 : TERMINÉ.

Notes :
1.	Si le LSR est capable de fusion, il devrait y avoir au plus une transposition reçue pour la FEC sur le LSP en question. Dans le cas de non fusion, il pourrait y avoir plusieurs transpositions reçues pour la FEC sur le LSP en question.
2.	Si le LSR a détecté une boucle et si il n’a pas reçu précédemment de transposition d’étiquette de la source du message pour la FEC, il libère simplement l’étiquette.
3.	L’étiquette reçue dans le message correspond elle à une ou plusieurs des transpositions d’étiquette identifiées à l’étape précédente (LMp.4 ou LMp.9) ?
4.	Une transposition non sollicitée avec une étiquette différente provenant du même homologue serait une tentative d’établissement d’une commutation d’étiquette multi chemin, ce qui n’est pas accepté par cette version de LDP.
5.	Si l’étiquette n’est pas en utilisation de transmission/commutation, LMp.7 n’a pas d’effet.
6.	Si le message Transposition d’étiquette reçu ne correspond pas à une demande d’étiquette en cours dans LMp.1, alors (par définition) le LSR n’a pas reçu précédemment une transposition d’étiquette en FEC pour le LSP en question. Si le LSR fusionne les étiquettes amont pour le LSP en question, il devrait y avoir au plus une transposition reçue. Dans le cas de non fusion, il pourrait y avoir plusieurs transpositions d’étiquette reçues pour la même FEC, une pour chaque LSP résultant.
7.	L’itération LMp.17 comporte MsgSource afin de traiter le cas où le LSR fonctionne en mode contrôle ordonné vers l’aval non sollicité. Le contrôle ordonné empêche le LSR d’annoncer une étiquette pour la FEC jusqu’à ce qu’il ait reçu une transposition d’étiquette de son prochain bond (MsgSource) pour la FEC.
8.	Si le LSR fusionne le LSP, il peut avoir envoyé précédemment la transposition d’étiquettes en FEC pour le LSP à un ou plusieurs homologues. Si le LSR ne fait pas la fusion, il peut avoir envoyé une transposition d’étiquette pour le LSP en question à au plus un LSR.
9.	L’attribut Détection de boucle du vecteur de chemin est pris en compte dans cette vérification. Si le RAttributes reçu inclut un vecteur de chemin et qu’il n’a pas été envoyé précédemment de vecteur de chemin à l’homologue, ou si le vecteur de chemin reçu n’est pas cohérent avec le vecteur de chemin envoyé précédemment à l’homologue, les attributs sont alors considérés comme incohérents. Noter qu’un LSR n’est pas obligé de mémoriser un vecteur de chemin reçu après qu’il a propagé le vecteur de chemin dans un message Transposition. Si un LSR ne mémorise pas le vecteur de chemin, il n’a pas de moyen de vérifier la cohérence d’un vecteur de chemin nouvellement reçu. Cela signifie que chaque fois qu’un tel LSR reçoit un message de transposition qui porte un vecteur de chemin, il doit toujours propager le vecteur de chemin.
10.	LMp.22 à LMp.27 traitent d’une situation qui peut survenir lorsque le LSR utilise le contrôle indépendant et qu’il reçoit une transposition de la part de l’homologue aval après qu’il a envoyé une transposition à un homologue amont. Dans cette situation, le LSR a besoin de propager tous les attributs qui ont changé, comme un compte de bonds, en amont. Si la détection de boucle est configurée, les attributs propagés doivent inclure le vecteur de chemin.
11.	Un LSR qui fonctionne en mode vers l’aval non sollicité DOIT traiter tout message Demande d’étiquette qu’il reçoit. Si il y a des demandes d’étiquette en cours, il revient aux procédures vers l’aval à la demande afin de satisfaire les demandes en instance.
12.	Comme déterminé par l’étape LMp.1.
13.	Un LSR qui fonctionne en mode de contrôle ordonné peut choisir de sauter à cette étape l’homologue de qui il a reçu l’annonce qui l’a amené à générer le message de transposition d’étiquette. Le faire va avoir pour effet de fournir une forme d’horizon partagé.

A.1.3	Réception d’une Demande d’abandon d’étiquette
Résumé : Lorsque un LSR reçoit un message Demande d’abandon d’étiquette de la part d’un homologue, il vérifie si il a déjà répondu à la demande d’étiquette en question. Si il l’a fait, il ignore le message en silence. Si il ne l’a pas fait, il envoie à l’homologue une Notification d’abandon de demande d’étiquette. De plus, si il a une demande d’étiquette en instance pour le LSP en question pour un homologue aval, il envoie une Demande d’abandon d’étiquette à l’homologue aval pour interrompre le LSP.

Contexte :
-	LSR : Le LSR qui traite l’événement.
-	Source du message : L’homologue LDP qui envoie le message.
-	FEC : La FEC spécifiée dans le message.
-	RequestMessageID : Identifiant de message du message de demande d’étiquette à interrompre.
-	Prochain bond : Le prochain bond pour la FEC.

Algorithme :

LAbR.1 : Le message correspond il à un message Demande d’étiquette précédemment reçu de la source du message ? 
(Voir Note 1.)
	Si non, aller à LAbR.12.

LAbR.2 : Le LSR a t-il répondu à la demande d’étiquette reçue précédemment ?
	Si oui, aller à LAbR.12.
LAbR.3 : Exécuter la procédure Send_Message (MsgSource, Notification, Interruption de demande d’étiquette, TLV) où TLV est le TLV Identifiant de message Demande d’étiquette reçu dans le message Demande d’abandon d’étiquette.

LAbR.4 : Le LSR a t-il un message Demande d’étiquette en instance pour la FEC ?
	Si oui, aller à LAbR.7.

LAbR.5 : Le LSR a t-il une transposition d’étiquette pour la FEC ?
Si non, aller à LAbR.11.

LAbR.6 : Générer l’événement : Message Libération d’étiquette pour la FEC reçu de la source du message. (Voir Note 2.)
	Aller à LAbR.11.

LAbR.7 : Le LSR fusionne t-il les LSP pour la FEC ?
	Si non, aller à LAbR.9.

LAbR.8 : Y a t-il des demandes d’étiquette en instance pour cette FEC ?
	Si oui, aller à LAbR.11.

LAbR.9 : Exécuter la procédure Send_Message (Prochain bond, Demande d’abandon d’étiquette, FEC, TLV) où TLV est un TLV Identifiant de message Demande d’étiquette contenant l’identifiant de message utilisé par le LSR dans le message Demande d’étiquette en instance.

LAbR.10 : Enregistrer qu’une demande d’abandon d’étiquette est en instance pour cette FEC.

LAbR.11 : Supprimer l’enregistrement de la demande d’étiquette pour la FEC de la part de la source du message.

LAbR.12 : TERMINÉ.

Notes :
1.	Le LSR utilise la FEC et le TLV Identifiant de message Demande d’étiquette portés par la demande d’abandon d’étiquette pour localiser son enregistrement (s’il en est) pour la demande d’étiquette précédemment reçue de MsgSource.
2.	Si le LSR a reçu une transposition d’étiquette du prochain bond, il devrait se comporter comme si il avait annoncé une transposition d’étiquette à MsgSource et si MsgSource l’avait libérée.

A.1.4	Réception d’une Libération d’étiquette
Résumé : Lorsque un LSR reçoit d’un homologue un message Libération d’étiquette pour une FEC, il vérifie si d’autres homologues détiennent l’étiquette libérée. Si aucun ne l’a, le LSR retire l’étiquette de l’utilisation transmission/ commutation, si il ne l’a pas déjà fait, et si le LSR détient une transposition d’étiquette de la FEC de prochain bond, il libère la transposition d’étiquette.

Contexte :
-	LSR : Le LSR qui traite l’événement.
-	Source du message : L’homologue LDP qui envoie le message.
-	Étiquette : L’étiquette spécifiée dans le message.
-	FEC : La FEC spécifiée dans le message.

Algorithme :

LRl.1 : La FEC correspond elle à une FEC connue ?  Si non, aller à LRl.14.

LRl.2 : Retirer la source du message des enregistrements d’homologues qui détiennent l’étiquette pour la FEC. (Voir Note  1.)

LRl.3 : Le message correspond il à un retrait d’étiquette en instance pour la FEC précédemment envoyé à MsgSource ?
Si non, aller à LRl.5

LRl.4 : Supprimer l’enregistrement du retrait d’étiquette en instance pour la FEC précédemment envoyé à MsgSource.

LRl.5 : Le LSR fusionne t-il les étiquettes pour cette FEC ?  Si non, aller à LRl.7. (Voir Note 2.)

LRl.6 : Le LSR a t-il des annonces d’étiquette en cours pour cette FEC ?
Si oui, aller à LRl.11.

LRl.7 : Le LSR est il la sortie pour la FEC ?
Si oui, aller à LRl.11.

LRl.8 : Y a t-il un prochain bond pour la FEC ? ET le LSR a t-il une transposition d’étiquette pour la FEC précédemment reçue du prochain bond ?
Si non, aller à LRl.11.

LRl.9 : Le LSR est il configuré pour propager les libérations ?
Si non, aller à LRl.11.  (Voir Note 3.)

LRl.10 : Exécuter la procédure Send_Message (Prochain bond, Libération d’étiquette, FEC, Étiquette du prochain bond).

LRl.11 : Retirer l’étiquette de l’utilisation transmission/commutation pour le trafic provenant de MsgSource.

LRl.12 : Un homologue détient il encore l’étiquette pour la FEC ?
Si oui, aller à LRl.14.

LRl.13 : Libérer l’étiquette.

LRl.14 : TERMINÉ.

Notes :
1.	Si le LSR utilise la distribution d’étiquette vers l’aval non sollicité, il NE DEVRAIT PAS réannoncer une transposition d’étiquette pour la FEC à la source du message tant que celle-ci ne le demande pas.
2.	LRl.5 à LRl.9 traite de la détermination de si le LSR devrait propager la libération d’étiquette à un homologue aval (LRl.9).
3.	Si l’étape LRl.9 est atteinte, aucun LSR amont ne détient une étiquette pour la FEC, et le LSR détient une étiquette pour la FEC de la FEC de prochain bond. Le LSR pourrait propager la libération d’étiquette au prochain bond. En propageant la libération d’étiquette, le LSR libère une ressource d’étiquette potentiellement rare. En faisant cela, il augmente aussi la latence pour rétablir le LSP si MsgSource ou quelque autre LSR amont lui envoie une nouvelle demande d’étiquette pour la FEC.
Propager ou non la libération n’est pas une question de protocole. La distribution d’étiquette va fonctionner correctement que la propagation de la libération se fasse ou non. La décision de propager ou non devrait prendre en considération des facteurs comme la rareté de la ressource d’étiquette dans l’environnement de fonctionnement, l’importance de garder la latence d’établissement du LSP à un faible niveau en minimisant la quantité de signalisation nécessaire, et si l’établissement du LSP est contrôlé par l’entrée ou par la sortie dans l’environnement de fonctionnement.

A.1.5	Réception d’un Retrait d’étiquette
Résumé : Lorsque un LSR reçoit un message Retrait d’étiquette pour une FEC de la part d’un homologue LDP, il répond par un message Libération d’étiquette et il retire l’étiquette de toute utilisation de transmission/commutation. Si le contrôle ordonné est utilisé, le LSR envoie un message Retrait d’étiquette à chaque homologue LDP auquel il a précédemment envoyé une transposition d’étiquette pour la FEC. Si le LSR utilise l’annonce d’étiquette vers l’aval à la demande avec le contrôle indépendant, il agit alors comme si il avait juste reconnu la FEC.

Contexte :
-	LSR : Le LSR qui traite l’événement.
-	MsgSource : l’homologue LDP qui envoie le message.
-	Étiquette : L’étiquette spécifiée dans le message.
-	FEC : La FEC spécifiée dans le message.

Algorithme :

LWd.1 : Retirer l’étiquette de l’utilisation transmission/commutation. (Voir Note 1.)

LWd.2 : Exécuter la procédure Send_Message (MsgSource, Libération d’étiquette, FEC, Étiquette).

LWd.3 : Le LSR a t-il précédemment reçu de MsgSource et conservé une transposition d’étiquette correspondante pour la FEC ?
Si non, aller à LWd.13.

LWd.4 : Supprimer la transposition d’étiquette correspondante pour la FEC précédemment reçue de MsgSource.

LWd.5 : Le LSR utilise t-il le contrôle ordonné ?
Si oui, aller à LWd.8.

LWd.6 : MsgSource utilise t-elle l’annonce d’étiquette vers l’aval à la demande ?
Si non, aller à LWd.13.

LWd.7 : Générer l’événement : Reconnaître la nouvelle FEC comme FEC. Aller à LWd.13. (Voir Note 2.)

LWd.8 : Itérer jusqu’à LWd.12 pour chaque homologue, autre que MsgSource.

LWd.9 : Le LSR a t-il précédemment envoyé une transposition d’étiquette en FEC à l’homologue ?
Si non, continuer l’itération pour le prochain homologue à LWd.8.

LWd.10 : L’étiquette précédemment envoyée à l’homologue "se transpose t-elle" en l’étiquette retirée ?
Si non, continuer l’itération pour le prochain homologue à LWd.8. (Voir Note 3.)

LWd.11 : Exécuter la procédure Send_Étiquette_Withdraw (Homologue, FEC, Étiquette précédemment envoyée à l’homologue).

LWd.12 : Terminer l’itération à partir de LWd.8.

LWd.13 : TERMINÉ.

Notes :
1.	Si l’étiquette n’est pas en utilisation de transmission/commutation, LWd.1 n’a pas d’effet.
2.	LWd.7 traite le cas où le LSR utilise la distribution d’étiquette vers l’aval à la demande avec contrôle indépendant. Dans cette situation, le LSR devrait envoyer une demande d’étiquette au prochain bond de la FEC comme si il avait juste reconnu la FEC.
3.	LWd.10 traite aussi bien le cas de la fusion d’étiquette (une ou plusieurs étiquettes entrantes se transposent en la même étiquette sortante) que celui de la non fusion d’étiquette (une étiquette se transpose en l’étiquette sortante).

A.1.6	Reconnaissance d’une nouvelle FEC
Résumé : La réponse par un LSR en apprenant une nouvelle FEC via le tableau d’acheminement peut impliquer une ou plusieurs des actions suivantes :
-	Transmission de transposition d’étiquettes pour la FEC en un ou plusieurs homologues LDP ;
-	Transmission d’une demande d’étiquette pour la FEC au prochain bond de la FEC ;
-	Toute action qui peut survenir lorsque le LSR reçoit du prochain bond de la FEC une transposition d’étiquette pour la FEC.

Contexte :
-	LSR : Le LSR qui traite l’événement.
-	FEC : la FEC nouvellement reconnue.
-	Prochain bond : Le prochain bond pour la FEC.
-	InitAttributes : Attributs à associer à la nouvelle FEC. (Voir Note 1.)
-	Sattributes : Attributs à inclure dans le message Transposition d’étiquette ou Demande d’étiquette, s’il en est, envoyé aux homologues.
-	StoredHopCount : Compte de bonds associé à la transposition d’étiquette en FEC, s’il en est, précédemment reçue du prochain bond.

Algorithme :

FEC.1 : Le LSR effectue la procédure de distribution d’étiquette.
Pour le contrôle indépendant vers l’aval non sollicité
1. Itérer jusqu’à 5 pour chaque homologue.
2. Le LSR a t-il précédemment reçu du prochain bond et conservé une transposition d’étiquette en FEC ?
Si oui, régler Propagation à IsPropagating.
Si non, régler Propagation à NotPropagating.
3. Exécuter la procédure Prepare_Étiquette_Mapping_Attributes (Homologue, FEC, InitAttributes, SAttributes, Propagation, Compte de bonds inconnu (0)).
4. Exécuter la procédure Send_Étiquette (Homologue, FEC, SAttributes).
5. Fin de l’itération depuis 1.
Aller à FEC.2.
Pour le contrôle ordonné vers l’aval non sollicité
1. Itérer jusqu’à 5 pour chaque homologue.
2. Le LSR est il la sortie pour la FEC ? OU le LSR a t-il précédemment reçu du prochain bond et conservé une transposition d’étiquette en FEC ?
Si non, continuer l’itération pour le prochain homologue.
3. Exécuter la procédure Prepare_Étiquette_Mapping_Attributes (Homologue, FEC, InitAttributes, SAttributes, Propagation, StoredHopCount).
4. Exécuter la procédure Send_Étiquette (Homologue, FEC, SAttributes).
5. Fin de l’itération depuis 1.
Aller à FEC.2.Pour le contrôle indépendant vers l’aval à la demande OU pour le contrôle ordonné vers l’aval à la demande
1. Aller à FEC.2.  (Voir Note 2.)

FEC.2 : Le LSR a t-il précédemment reçu et conservé du prochain bond une transposition d’étiquette en FEC ?
Si oui, aller à FEC.5

FEC.3 : Le prochain bond est il un homologue LDP ?
Si non, Aller à FEC.6

FEC.4  : Le LSR effectue la procédure de demande d’étiquette :
Pour Ne jamais demander
1. Aller à FEC.6
Pour Demande quand nécessaire OU pour Demande sur demande
1. Exécuter la procédure Prepare_Étiquette_Request_Attributes (Prochain bond, FEC, InitAttributes, SAttributes);
2. Exécuter la procédure Send_Étiquette_Request (Prochain bond, FEC, SAttributes).
Aller à FEC.6.

FEC.5 : Générer l’événement : Transposition d’étiquette reçue du prochain bond. (Voir Note 3.)

FEC.6 : TERMINÉ.

Notes :
1.	Un exemple d’attribut qui pourrait faire partie de InitAttributes est celui qui spécifie les caractéristiques désirées du LSP, telle que la classe de service (CS). (Noter que bien que la version actuelle de LDP ne spécifie pas un attribut de CS, des extensions à LDP le peuvent.) Les moyens par lesquels les attributs initiaux de FEC, s’il en est, sont spécifiés sortent du domaine d’application de LDP. Noter que les attributs initiaux ne vont pas inclure un compte de bonds ou un vecteur de chemin connus.
2.	Un LSR qui utilise la distribution d’étiquette vers l’aval à la demande n’enverrait une étiquette que si il avait précédemment reçu une demande d’étiquette marquée comme en instance. Le LSR n’aurait pas de telles demandes en instance parce qu’il répond à toute demande d’étiquette pour une FEC inconnue par l’envoi au LSR demandeur d’une notification Pas de chemin et par l’élimination de la demande d’étiquette ; voir LRq.3
3.	Si le LSR a une étiquette pour la FEC provenant du prochain bond, il devrait se comporter comme si il avait juste reçu l’étiquette du prochain bond. Cela survient dans le cas du mode de rétention libéral d’étiquette.

A.1.7	Détecter un changement de la FEC du prochain bond
Résumé : La réponse d’un LSR à un changement de prochain bond pour une FEC peut impliquer une ou plusieurs des actions suivantes :
-	Retrait de l’étiquette de l’ancien prochain bond pour la FEC de l’utilisation de transmission/commutation ;
-	Transmission des messages de transposition d’étiquette pour la FEC à un ou plusieurs homologues LDP ;
-	Transmission d’une demande d’étiquette au nouveau prochain bond de la FEC ;
-	Toute action qui peut survenir lorsque le LSR reçoit une transposition d’étiquette provenant du nouveau prochain bond pour la FEC.
.
Contexte :
-	LSR : Le LSR qui traite l’événement.
-	FEC : La FEC dont le prochain bond a changé.
-	Nouveau prochain bond : Le prochain bond actuel pour la FEC.
-	Ancien prochain bond : Le prochain bond précédent pour la FEC.
-	Ancienne étiquette : L’étiquette, s’il en est, précédemment reçue de l’ancien prochain bond.
-	CurAttributs : Attributs, s’il en est, actuellement associés à la FEC.
-	SAttributs : Attributs à inclure dans le message Demande d’étiquette, s’il en est, envoyé par le nouveau prochain bond.

Algorithme :

NH.1 : Le LSR a t-il précédemment reçu et conservé une transposition d’étiquette pour la FEC de l’ancien prochain bond ? Si non, aller à NH.6.

NH.2 : Retirer l’étiquette de l’utilisation en transmission/commutation. (Voir Note 1.)

NH.3 : Le LSR utilise t-il la rétention libérale d’étiquette ?
Si oui, aller à NH.6.

NH.4 : Exécuter la procédure Send_Message (Ancien prochain bond,  Libération d’étiquette, AncienneÉtiquette).

NH.5 : Supprimer la transposition d’étiquette précédemment reçue pour la FEC de l’ancien prochain bond.

NH.6 : Le LSR a t-il une demande d’étiquette en instance avec l’ancien prochain bond ?
Si non, aller à NH.10.

NH.7  : Le LSR utilise t-il la rétention prudente d’étiquettes ?
Si non, aller à NH.10.

NH.8 : Exécuter la procédure Send_Message (Ancien prochain bond, Demande d’abandon d’étiquette, FEC, TLV) où TLV est un TLV Identifiant de message Demande d’étiquette qui porte l’identifiant de message de la demande d’étiquette en instance.

NH.9 : Enregistrer qu’une demande d’abandon d’étiquette est en cours pour la FEC auprès de l’ancien prochain bond.

NH.10 : Y a t-il un nouveau prochain bond pour la FEC ?
Si non, aller à NH.16.

NH.11 : Le LSR a t-il précédemment reçu et conservé une transposition d’étiquette pour la FEC venant du nouveau prochain bond ?
Si non, aller à NH.13.

NH.12 : Générer l’événement : Réception d’une transposition d’étiquette du nouveau prochain bond.
Aller à NH.20.  (Voir Note 2.)

NH.13  : Le LSR utilise t-il l’annonce vers l’aval à la demande ? OU le prochain bond utilise t-il l’annonce vers l’aval à la demande ? OU le LSR utilise t-il la rétention prudente d’étiquettes? (Voir Note 3.)
Si oui, aller à NH.14.
Si non, aller à NH.20.

NH.14 : Exécuter la procédure Prepare_Étiquette_Request_Attributes (Prochain bond, FEC, CurAttributes, SAttributes).

NH.15 : Exécuter la procédure Send_Étiquette_Request (Nouveau prochain bond, FEC, SAttributes).  (Voir Note 4.)
Aller à NH.20.

NH.16 : Itérer jusqu’à NH.19 pour chaque homologue.

NH.17 : Le LSR a t-il précédemment envoyé une transposition d’étiquette en FEC à l’homologue ?
Si non, continuer l’itération pour le prochain homologue à NH.16.

NH.18 : Exécuter la procédure Send_Étiquette_Withdraw (Homologue, FEC, Étiquette précédemment envoyée à l’homologue).

NH.19 : Fin d’itération depuis NH.16.

NH.20 : TERMINÉ.

Notes :
1.	Si l’étiquette n’est pas en utilisation de transmission/commutation, NH.2 n’a pas d’effet.
2.	Si le LSR a une étiquette pour la FEC provenant du nouveau prochain bond, il devrait se comporter comme si il avait juste reçu l’étiquette du nouveau prochain bond.
3.	L’objet de la vérification sur le mode de rétention d’étiquette est d’éviter une concurrence entre les étapes LMp.12-LMp.13 de la procédure de traitement du message Transposition d’étiquette lorsque le LSR qui fonctionne en mode de rétention prudente d’étiquettes peut avoir libéré une transposition d’étiquette reçue du nouveau prochain bond avant d’avoir détecté que le prochain bond de la FEC a changé.
4.	Sans considération de la procédure de demande d’étiquette utilisée par le LSR, il DOIT envoyer une demande d’étiquette si les conditions de NH.13 tiennent. Donc, il exécute directement la procédure Send_Étiquette_Request plutôt que d’effectuer la procédure de demande d’étiquette par le LSR.

A.1.8	Réception de Notification / Demande d’abandon d’étiquette
Résumé : Lorsque un LSR reçoit une notification Demande d’abandon d’étiquette d’un homologue LDP, il enregistre que la transaction correspondante de demande d’étiquette, s’il en est, s’est terminée.

Contexte :
-	LSR : Le LSR qui traite l’événement.
-	FEC : La FEC pour laquelle une étiquette a été demandée.
-	RequestMessageID : Identifiant de message du message Demande d’étiquette à interrompre.
- 	MsgSource : Homologue LDP qui envoie le message Notification.

Algorithme :

LRqA.1 : La notification correspond elle à une demande d’abandon d’étiquette en cours pour la FEC ?  (Voir Note.)
Si non, aller à LRqA.3.

LRqA.2 : Enregistrer que la demande d’étiquette pour la FEC a été interrompue.

LRqA.3 : TERMINÉ.

Note : Le LSR utilise la FEC et l’identifiant de message de demande pour localiser son enregistrement, s’il en est, de l’abandon de demande d’étiquette en instance.

A.1.9	Réception de Notification / Pas de ressource d’étiquette
Résumé : Lorsque un LSR reçoit une notification Pas de ressource d’étiquette de la part d’un homologue LDP, il arrête d’envoyer des messages de demande d’étiquette à l’homologue jusqu’à ce qu’il reçoive une notification Ressource d’étiquette disponible de l’homologue.

Contexte :
-	LSR : Le LSR qui traite l’événement.
-	FEC : FEC pour laquelle une étiquette a été demandée.
-	MsgSource : Homologue LDP qui a envoyé le message Notification.

Algorithme :

NoRes.1 : Supprimer l’enregistrement de demande d’étiquette en cours pour la FEC envoyée à MsgSource.

NoRes.2 : Enregistrer que la transposition d’étiquette en FEC venant de MsgSource est nécessaire mais qu’aucune ressources d’étiquette n’est disponible.

NoRes.3 : Établir un enregistrement d’état indiquant qu’il n’y a pas d’accord pour envoyer des demandes d’étiquette à MsgSource.

NoRes.4 : TERMINÉ.

A.1.10	Réception de Notification / Pas de chemin
Résumé : Lorsque un LSR reçoit une notification Pas de chemin d’un homologue LDP en réponse à un message Demande d’étiquette, la procédure Pas de chemin d’étiquette utilisée dicte sa réponse. Le LSR ne va prendre aucune autre action, ou il va différer la demande d’étiquette en lançant un temporisateur et envoyer un autre message Demande d’étiquette à l’homologue lorsque le temporisateur sera arrivé à expiration.

Contexte :
-	LSR : Le LSR qui traite l’événement.
-	FEC : FEC pour laquelle une étiquette a été demandée.
-	Attributs : Les attributs associés à la demande d’étiquette.
-	MsgSource  : Homologue LDP qui a envoyé le message Notification.

Algorithme :
NoNH.1 : Supprimer l’enregistrement de la demande d’étiquette en cours pour la FEC envoyée à MsgSource.

NoNH.2 : Effectuer la procédure de LSR Pas de chemin d’étiquette.
Pour Pas de réessai de demande
1. Aller à NoNH.3.
Pour Réessai de demande
1. Enregistrer la demande d’étiquette différée pour la FEC et les attributs à envoyer à MsgSource.
2. Lancer le temporisateur. Aller à NoNH.3.

NoNH.3 : TERMINÉ.

A.1.11	Réception de Notification / Boucle détectée
Résumé : Lorsque un LSR reçoit un code d’état Boucle détectée d’un homologue LDP en réponse à un message Demande d’étiquette ou à un message Transposition d’étiquette, il se comporte comme si il avait reçu une notification Pas de chemin.

Contexte : Voir "Réception de Notification / Pas de chemin".

Algorithme : Voir "Réception de Notification / Pas de chemin".

Note : Lorsque la notification Boucle détectée est en réponse à un message Demande d’étiquette, elle arrive dans un TLV Code d’état dans un message Notification. Lorsque elle est en réponse à un message Transposition d’étiquette, elle arrive dans un TLV Code d’état dans un message Libération d’étiquette.

A.1.12	Réception de Notification / Ressources d’étiquette disponibles
Résumé : Lorsque un LSR reçoit une notification Ressources d’étiquette disponibles d’un homologue LDP, il reprend l’envoi des demandes d’étiquette à l’homologue.

Contexte :
-	LSR : Le LSR qui traite l’événement.
-	MsgSource : Homologue LDP qui envoie le message Notification.
-	SAttributes : Attributs mémorisés avec le message Demande d’étiquette retardé.

Algorithme :

Res.1 ; Établir un enregistrement d’état indiquant qu’il y a accord pour envoyer les demandes d’étiquette à MsgSource.

Res.2 :	Itérer jusqu’à Res.6 pour chaque enregistrement d’une transposition étiquette/FEC nécessaire provenant de MsgSource pour lesquels aucune ressource d’étiquette n’est disponible.

Res.3 : MsgSource est il le prochain bond pour la FEC ?
Si non, aller à Res.5.

Res.4 : Exécuter la procédure Send_Étiquette_Request (MsgSource, FEC, SAttributes). Si la procédure échoue, terminer l’itération.

Res.5 : Supprimer l’enregistrement qu’aucune ressource n’est disponible pour une transposition d’étiquette pour la FEC nécessaire pour MsgSource.

Res.6 : Terminer l’itération à partir de Res.2.

Res.7 : TERMINÉ.

A.1.13	Détecter que des ressources locales d’étiquette sont devenues disponibles
Résumé : Après qu’un LSR a envoyé une notification Pas de ressource d’étiquette à un homologue LDP, lorsque plus tard, des ressources deviennent disponibles, il envoie une notification Ressources d’étiquette disponibles à chacun de ces homologues.

Contexte :
-	LSR : Le LSR qui traite l’événement.
-	Attributs : Les attributs mémorisés avec le message Transposition d’étiquette retardé.

Algorithme :

ResA.1 : Itérer jusqu’à ResA.4 pour chaque Homologue auquel le LSR a envoyé précédemment une notification Pas de ressource d’étiquette.

ResA.2 : Exécuter la procédure Send_Notification (Homologue, Ressources d’étiquette disponibles).

ResA.3 : Supprimer l’enregistrement que la notification Pas de ressource d’étiquette a été précédemment envoyée à l’homologue.

ResA.4 : Terminer l’itération à partir de ResA.1.

ResA.5 : Itérer jusqu’à ResA.8 pour chaque enregistrement d’une transposition d’étiquette nécessaire pour la FEC pour l’homologue mais pas de ressource d’étiquette. (Voir Note.)

ResA.6 : Exécuter la procédure Send_Étiquette (Homologue, FEC, Attributs). Si la procédure échoues, terminer l’itération.

ResA.7 : Supprimer l’enregistrement de transposition d’étiquette en FEC nécessaire pour l’homologue mais pas de ressource d’étiquette.

ResA.8 : Terminer l’itération à partir de ResA.5.

ResA.9 : TERMINÉ.

Note :	L’itération de ResA.5 à ResA.8 traite la situation où le LSR utilise la distribution d’étiquette vers l’aval non sollicité et n’était précédemment pas capable d’allouer une étiquette pour une FEC.

A.1.14	Le LSR décide de ne plus faire de commutation d’étiquette pour une FEC
Résumé : Un LSR peut unilatéralement décider de ne plus faire de commutation d’étiquette pour une FEC pour un homologue LDP. Un LSR qui fait ainsi DOIT envoyer un message Retrait d’étiquette pour la FEC à l’homologue.

Contexte :
-	Homologue : c’est l’homologue.
-	FEC : c’est la FEC.
-	PrevAdvLabel : c’est l’étiquette pour la FEC qui était précédemment annoncée à l’homologue.

Algorithme :

NoLS.1 : Exécuter la procédure Send_Étiquette_Withdraw (Homologue, FEC, PrevAdvLabel). (Voir Note.)

NoLS.2 : TERMINÉ.

Note :	Le LSR peut retirer l’étiquette de l’utilisation de transmission/commutation au titre de cet événement ou au titre du traitement de libération d’étiquette provenant de l’homologue en réponse au retrait de l’étiquette. Si le LSR n’attend pas le message Libération d’étiquette provenant de l’homologue, il NE DEVRAIT PAS réutiliser l’étiquette jusqu’à ce qu’il reçoive la Libération d’étiquette.

A.1.15	Fin de temporisation d’une demande d’étiquette différée
Résumé : Les demandes d’étiquette sont retardées en réponse aux notifications Pas de chemin et Boucle détectée. Lorsque arrive en fin de temporisation une demande d’étiquette de FEC différée, le LSR envoie la demande d’étiquette.

Contexte :
-	LSR : Le LSR qui traite l’événement.
-	FEC : La FEC associée à l’événement de fin de temporisation.
-	Homologue : L’homologue LDP associé à l’événement de fin de temporisation.
-	Attributs : Les attributs mémorisés avec le message Demande d’étiquette différé.

Algorithme :

TO.1 : Restituer l’enregistrement de la demande d’étiquette différée.

TO.2 : L’homologue est il le prochain bond pour la FEC ?
Si non, aller à TO.4.

TO.3 : Exécuter la procédure Send_Étiquette_Request (Homologue, FEC).

TO.4 : TERMINÉ.

A.2	Procédures communes de distribution d’étiquettes
Cette section spécifie les procédures utilisées par les algorithmes qui traitent les événements de distribution d’étiquettes.

A.2.1	Send_Étiquette
Résumé : La procédure Send_Étiquette alloue une étiquette pour une FEC pour un homologue LDP, si possible, et envoie une transposition d’étiquette pour la FEC à l’homologue. Si le LSR est dans l’incapacité d’allouer l’ étiquette et si il a une demande d’étiquette en cours de la part de l’homologue, il envoie à l’homologue LDP une notification Pas de ressource d’étiquette.

Paramètres :
-	Homologue : L’homologue LDP auquel la transposition d’étiquette est à envoyer.
-	FEC  : La FEC pour laquelle une transposition d’étiquette est à envoyer.
-	Attribut  : Les attributs à inclure avec la transposition d’étiquette.

Contexte supplémentaire :
-	LSR : Le LSR qui exécute la procédure.
-	Étiquette : C’est l’étiquette allouée et envoyée à l’homologue.

Algorithme :

SL.1  : Le LSR a t-il une étiquette à allouer ?
Si non, aller à SL.9.

SL.2 : Allouer l’étiquette et la lier à la FEC.

SL.3 : Installer l’étiquette pour utilisation en transmission/commutation.

SL.4  : Exécuter la procédure Send_Message (Homologue, Transposition d’étiquette, FEC, Étiquette, Attributs).

SL.5 : Enregistrer la transposition d’étiquette pour la FEC avec l’étiquette et les attributs qui ont été envoyés à l’homologue.

SL.6 : Le LSR a t-il un enregistrement de demande d’étiquette de FEC provenant de l’homologue marquée comme en cours  ?
Si non, aller à SL.8.

SL.7 : Supprimer l’enregistrement de demande d’étiquette en cours pour la FEC provenant de l’homologue.

SL.8 : Retourner une indication de réussite.

SL.9 : Le LSR a t-il une demande d’étiquette pour la FEC provenant de l’homologue et marquée comme en cours ?
	Si non, aller à SL.13.

SL.10 : Exécuter la procédure Send_Notification (Homologue, Pas de ressource d’étiquette).

SL.11 : Supprimer l’enregistrement de demande d’étiquette en cours pour la FEC de l’homologue.

SL.12 : Enregistrer que la notification Pas de ressource d’étiquette a été envoyée à l’homologue.
Aller à SL.14.

SL.13 : Enregistrer la transposition d’étiquette nécessaire pour la FEC et les attributs pour l’homologue, mais pas de ressource d’étiquette. (Voir Note.)

SL.14 : Retourner une indication d’échec.

Note :	SL.13 traite le cas de la distribution d’étiquette vers l’aval non sollicitée lorsque le LSR est dans l’incapacité d’allouer une étiquette pour une FEC à envoyer à un homologue.

A.2.2.	Send_Étiquette_Request
Résumé : Un LSR utilise la procédure Send_Étiquette_Request pour envoyer une demande d’étiquette pour une FEC à un homologue LDP si il est actuellement permis de le faire.

Paramètres :
-	Homologue : L’homologue LDP auquel la demande d’étiquette est à envoyer.
-	FEC  : La FEC pour laquelle une demande d’étiquette est à envoyer.
-	Attributs : Les attributs à inclure dans la demande d’étiquette, par exemple, Compte de bonds, Vecteur de chemin.

Contexte supplémentaire :
-	LSR : Le LSR qui exécute la procédure.

Algorithme :

SLRq.1 : Une demande d’étiquette pour la FEC a t-elle été précédemment envoyée à l’homologue et est elle marquée comme en instance ?
	Si oui, Retourner une indication de réussite. (Voir Note.)

SLRq.2 : L’enregistrement d’état qui indique l’accord pour envoyer les demandes d’étiquette à l’homologue est il établi ?
	Si non, aller à SLRq.6

SLRq.3  : Exécuter la procédure Send_Message (Homologue, Demande d’étiquette, FEC, Attributs).

SLRq.4 : Enregistrer que la demande d’étiquette pour la FEC a été envoyée à l’homologue et la marquer comme en instance.

SLRq.5 : Retourner une indication de réussite.

SLRq.6 : Différer la demande d’étiquette en enregistrant que la transposition d’étiquette pour la FEC et les attributs provenant de l’homologue est nécessaire mais qu’aucune ressource d’étiquette n’est disponible.

SLRq.7 : Retourner une indication d’échec.

Note :	Si le LSR est un LSR sans fusion, il doit distinguer entre les tentatives d’envoi des demandes d’étiquette pour une FEC déclenchées par un homologues LDP amont différent et les demandes dupliquées. Cette procédure ne va pas envoyer de demande d’étiquette dupliquée.

A.2.3	Send_Étiquette_Withdraw
Résumé : UN LSR utilise la procédure Send_Étiquette_Withdraw pour retirer une étiquette pour une FEC d’un homologue LDP. Pour faire cela, le LSR envoie un message Retrait d’étiquette à l’homologue.

Paramètres :
-	Homologue : L’homologue LDP auquel le retrait d’étiquette est à envoyer.
-	FEC : La FEC pour laquelle l’étiquette est retirée.
-	Étiquette : L’étiquette qui est retirée.

Contexte supplémentaire :
-	LSR : Le LSR qui exécute la procédure.

Algorithme :

SWd.1  : Exécute la procédure Send_Message (Homologue, Retrait d’étiquette, FEC, Étiquette).

SWd.2 : Enregistre que ce retrait d’étiquette pour cette FEC a été envoyé à l’homologue et qu’elle a été marquée comme étant en instance.

A.2.4	Send_Notification
Résumé : Un LSR utilise la procédure Send_Notification pour envoyer à un homologue LDP un message Notification.

Paramètres :
-	Homologue : L’homologue LDP auquel le message Notification est à envoyer.
-	État : Code d’état à inclure dans le message Notification.

Contexte supplémentaires : Aucun.

Algorithme :

SNt.1 : Exécuter la procédure Send_Message (Homologue, Notification, État)

A.2.5	Send_Message
Résumé : Un LSR utilise la procédure Send_Message pour envoyer à un homologue LDP un message LDP.

Paramètres :
-	Homologue : L’homologue LDP auquel le message est destiné.
-	Type de message : Le type du message à envoyer.
-	Contenu de message supplémentaire . . .  .

Contexte supplémentaires : Aucun.

Algorithme :

Cette procédure est le moyen par lequel un LSR envoie un message LDP du type spécifié à l’homologue LDP spécifié.

A.2.6	Check_Received_Attributes
Résumé : Vérifier les attributs reçus dans un message Transposition d’étiquette ou Demande d’étiquette. Si les attributs incluent un Compte de bonds ou un Vecteur de chemin, effectuer une vérification de détection de boucle. Si une boucle est détectée, provoquer l’envoi d’un message Notification Boucle détectée à MsgSource.

Paramètres :
-	MsgSource : L’homologue LDP qui envoie le message.
-	MsgType : Le type du message reçu.
-	Rattributes : Les attributs dans le message.

Contexte supplémentaire :
-	LSR Id : C’est l’identifiant univoque de LSR de ce LSR.
-	Compte de bonds  : C’est le compte de bons, s’el en est un, dans les attributs reçus.
	Vecteur de chemin : C’est le vecteur de chemin, s’il en est un, dans les attributs reçus.

Algorithme :

CRa.1  : RAttributes comporte t-il un compte de bonds ?
	Si non, aller à CRa.5.

CRa.2  : Le compte de bonds excède t-il le compte de bonds maximum admissible ?
	Si oui, aller à CRa.6.

CRa.3  : RAttributes comporte t-il un vecteur de chemin ?
	Si non, aller à CRa.5.

CRa.4  : Vecteur de chemin comporte t-il un LSR Id ? OU la longueur du vecteur de chemin excède t-elle la longueur maximum admissible ?
	Si oui, aller à CRa.6

CRa.5 : Retourner Pas de boucle détectée.

CRa.6 : Le type de message est il Transposition d’étiquette ?
	Si oui, aller à CRa.8. (Voir Note.)

CRa.7 : Exécuter la procédure Send_Notification (MsgSource, Boucle détectée).

CRa.8  : Retourner Boucle détectée.

CRa.9 : TERMINÉ.

Note :	Lorsque les attributs à vérifier ont été reçus dans un message Transposition d’étiquette, le LSR envoie la notification Boucle détectée dans un TLV Code d’état dans un message Libération d’étiquette. (Voir au paragraphe A.1.2 "Réception de transposition d’étiquette".)

A.2.7	Prepare_Étiquette_Request_Attributes
Résumé : Cette procédure est utilisée chaque fois qu’une demande d’étiquette est à envoyer à un homologue pour calculer le compte de bonds et le vecteur de chemin, s’il en est, à inclure dans le message.

Paramètres :
-	Homologue : C’est l’homologue LDP auquel le message est à envoyer.
-	FEC : La FEC pour laquelle une demande d’étiquette est à envoyer.
-	RAttributes : Ce sont les attributs que ce LSR associe au LSP pour cette FEC.
-	SAttributes  : Ce sont les attributs à inclure dans le message Demande d’étiquette.

Contexte supplémentaire :
-	LSR Id : C’est l’identifiant univoque de LSR de ce LSR.

Algorithme :

PRqA.1 : Le compte de bonds est il exigé pour cet homologue ? (Voir Note 1.) OU RAttributes comporte t-il un compte de bonds ? OU la détection de boucle est elle configurée sur le LSR ?
Si non, aller à PRqA.14.

PRqA.2 : Le LSR est il l’entrée pour la FEC ?
Si non, aller à PRqA.6.

PRqA.3 : Inclure un compte de bonds de 1 dans SAttributes.

PRqA.4 : La détection de boucle est elle configurée sur le LSR ?  Si non, aller à PRqA.14.

PRqA.5 : Le LSR est il capable de fusion ?
Si oui, aller à PRqA.14.
Si non, aller à PRqA.13.

PRqA.6 : RAttributes comporte t-il un compte de bonds ?
Si non, aller à PRqA.8.

PRqA.7 : Incrémenter le compte de bonds de RAttributes et copier le compte de bonds résultant dans SAttributes. (Voir Note 2.)
Aller à PRqA.9.

PRqA.8 : Inclure un compte de bonds de "inconnu" (0) dans SAttributes.

PRqA.9 : La détection de boucle est elle configurée sur le LSR ?
Si non, aller à PRqA.14.

PRqA.10 : RAttributes a t-il un vecteur de chemin ?
Si oui, aller à PRqA.12.

PRqA.11 : Le LSR est il capable de fusion ?
Si oui, aller à PRqA.14.
Si non, aller à PRqA.13.

PRqA.12 : Ajouter le LSR Id au début du vecteur de chemin à partir de RAttributes et copier le vecteur de chemin résultant dans SAttributes.
Aller à PRqA.14.

PRqA.13 : Inclure un vecteur de chemin de longueur 1 contenant le LSR Id dans les SAttributes.

PRqA.14 : TERMINÉ.

Notes :
1.	La liaison avec l’homologue peut exiger que le compte de bonds soit inclus dans les messages Demande d’étiquette ; par exemple, voir [RFC3035] et [RFC3034].
2.	Pour l’arithmétique de compte de bonds, inconnu + 1 = inconnu.

A.2.8	Prepare_Étiquette_Mapping_Attributes
Résumé : Cette procédure est utilisée chaque fois qu’une transposition d’étiquette est à envoyer à un homologue pour calculer le compte de bonds et le vecteur de chemin, s’il en est, à inclure dans le message.

Paramètres :
-	Homologue : C’est l’homologue LDP auquel le message est à envoyer.
-	FEC : C’est la FEC pour laquelle une demande d’étiquette est à envoyer.
-	RAttributes : Attributs que ce LSR associe au LSP pour cette FEC.
-	SAttributes : Attributs à inclure dans le message Transposition d’étiquette.
-	IsPropagating : Le LSR envoie le message Transposition d’étiquette pour propager celui qu’il a reçu du prochain bond de FEC.
-	PrevHopCount : C’est le compte de bonds, s’il en est, que ce LSR associe au LSP pour cette FEC.

Contexte supplémentaire :
-	SR Id : C’est l’identifiant univoque de LSR de ce LSR.

Algorithme :

PMpA.1 : RAttributes comporte t-il un TLV inconnu ?
Si non, aller à PMpA.4.

PMpA.2 : Le réglage des bits U- et F- exige t-il la transmission ce ces TLV ?
Si non, aller à PMpA.4.

PMpA.3 : Copier les TLV inconnus dans SAttributes.

PMpA.4 : Le compte de bonds est il exigé pour cet homologue ?  (Voir la Note 1.) OU RAttributes comporte t-il un compte de bonds ? OU la détection de boucle est elle configurée sur le LSR ?
Si non, aller à PMpA.24.

PMpA.5 : Le LSR est il la sortie pour la FEC ?
Si non, aller à PMpA.7.

PMpA.6 : Inclure un compte de bonds de 1 dans SAttributes. Aller à PMpA.24.

PMpA.7 : RAttributes a t-il un compte de bonds ?
Si non, aller à PMpA.11.

PMpA.8 : Le LSR est il un membre de l’ensemble bordure pour un domaine de LSR dont les LSR ne font pas la diminution de TTL ET l’homologue se trouve t-il dans ce domaine ? (Voir Note 2.) Si non, aller à PMpA.10.

PMpA.9 : Inclure un compte de bonds de 1 dans SAttributes. Aller à PMpA.12.

PMpA.10 : Incrémenter le compte de bonds de RAttributes et copier le compte de bonds résultant dans SAttributes. (Voir Note 2.)  Aller à PMpA.12.

PMpA.11 : Inclure un compte de bonds de "inconnu" (0) dans SAttributes.

PMpA.12 : La détection de boucle est elle configurée sur le LSR ?
Si non, aller à PMpA.24.

PMpA.13 : RAttributes a t-il un vecteur de chemin ?
Si oui, aller à PMpA.22.

PMpA.14 : Le LSR propage t-il une transposition d’étiquette reçue ?
Si non, aller à PMpA.23.

PMpA.15 : Le LSR prend il en charge la fusion ?
Si non, aller à PMpA.17.

PMpA.16 : Le LSR a t-il précédemment envoyé une transposition d’étiquette pour cette FEC à l’homologue ?
Si non, aller à PMpA.23.

PMpA.17 : RAttributes comporte t-il un compte de bonds ?
Si non, aller à PMpA.24.

PMpA.18 : Le compte de bonds dans RAttributes est il inconnu (0) ?
Si oui, aller à PMpA.23.

PMpA.19 : Le LSR a t-il précédemment envoyé une transposition d’étiquette pour cette FEC à l’homologue ?
Si non, aller à PMpA.24.

PMpA.20 : Le compte de bonds dans RAttributes est il différent du PrevHopCount ?
 Si non, aller à PMpA.24.

PMpA.21 : Le compte de bonds dans RAttributes est il supérieur à PrevHopCount ? OU PrevHopCount est il inconnu (0) ?
Si non, aller à PMpA.24.

PMpA.22 : Ajouter l’identifiant de LSR au début du vecteur de chemin à partir de RAttributes et copier le vecteur de chemin résultant dans SAttributes.
Aller à PMpA.24.

PMpA.23 : Inclure un vecteur de chemin de longueur 1 contenant l’identifiant de LSR dans SAttributes.

PMpA.24 : TERMINÉ.

Notes :
1.	La liaison avec l’homologue peut exiger que le compte de bonds soit inclus dans le message Transposition d’étiquette ; par exemple, voir [RFC3035] et [RFC3034].
2.	Si le LSR est à la bordure d’un nuage de LSR qui n’effectuent pas la diminution du TTL et si il propage le message Transposition d’étiquette en amont dans le nuage, il règle le compte de bonds à 1 afin que le compte de bonds soit calculé correctement à travers le nuage. Cela assure une gestion correcte du TTL pour les paquets transmis à travers la partie du LSP qui passe à travers le nuage.
3.	Pour l’arithmétique de compte de bonds, inconnu + 1 = inconnu.

Adresse des éditeurs

Loa Andersson	Ina Minei	Bob Thomas	
Acreo AB	Juniper Networks	Cisco Systems, Inc.	
Isafjordsgatan 22	1194 N. Mathilda Ave.	1414 Massachusetts Ave	
Kista, Sweden	Sunnyvale, CA 94089	Boxborough, MA 01719	
mél : loa.andersson@acreo.se 
         loa@pi.se 	mél : ina@juniper.net 	mél : rhthomas@cisco.com 	

Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2007).

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 qui y sont 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 ci encloses ne violent 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 pourraient ê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 droits de reproduction, 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.