3.5.7. Message Label Mapping
Un LSR envoie un message Label Mapping à un pair LDP pour annoncer des liaisons FEC-étiquette au pair.
L'encodage du message Label Mapping 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| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID Valeur de 32 bits utilisée pour identifier ce message.
FEC TLV Spécifie la composante FEC du mappage FEC-Label annoncé. Voir la section "FEC TLVs" pour l'encodage.
Label TLV Spécifie la composante Label du mappage FEC-Label. Voir la section "Label TLV" pour l'encodage.
Optional Parameters Ce champ de longueur variable contient 0 ou plusieurs paramètres, chacun encodé sous forme de TLV. Les paramètres optionnels sont :
Optional Parameter Length Value
Label Request 4 See below
Message ID TLV
Hop Count TLV 1 See below
Path Vector TLV variable See below
Les encodages des Hop Count et Path Vector TLV se trouvent dans la section "TLV Encodings for Commonly Used Parameters".
Label Request Message ID Si ce message Label Mapping est une réponse à un message Label Request, il DOIT (MUST) inclure le paramètre optionnel Label Request Message ID. La valeur de ce paramètre optionnel est le Message ID du message Label Request correspondant.
Hop Count Spécifie le total cumulé du nombre de sauts de LSR le long du LSP en cours d'établissement par le message Label. La section "Hop Count Procedures" décrit comment traiter ce TLV.
Path Vector Spécifie les LSR le long du LSP en cours d'établissement par le message Label. La section "Path Vector Procedures" décrit comment traiter ce TLV.
3.5.7.1. Procédures du message Label Mapping
Le message Mapping est utilisé par un LSR pour distribuer un mappage d'étiquettes pour une FEC à un pair LDP. Si un LSR distribue un mappage pour une FEC à plusieurs pairs LDP, c'est une affaire locale de savoir s'il associe une étiquette unique à la FEC et distribue ce mappage à tous ses pairs, ou s'il utilise un mappage différent pour chacun de ses pairs.
Un LSR est responsable de la cohérence des mappages d'étiquettes qu'il a distribués et du fait que ses pairs disposent de ces mappages.
Un LSR qui reçoit un message Label Mapping d'un LSR en aval pour un Prefix NE DEVRAIT PAS (SHOULD NOT) utiliser l'étiquette pour le transfert à moins que sa table de routage ne contienne une entrée qui corresponde exactement au FEC Element.
Voir l'annexe A, "LDP Label Distribution Procedures", pour plus de détails.
3.5.7.1.1. Mappage en contrôle indépendant
Si un LSR est configuré pour le contrôle indépendant, un message Mapping est transmis par le LSR dans l'une quelconque des conditions suivantes :
-
Le LSR reconnaît une nouvelle FEC via la table de transfert, et le mode d'annonce d'étiquettes est l'annonce Downstream Unsolicited.
-
Le LSR reçoit un message Request d'un pair en amont pour une FEC présente dans la table de transfert du LSR.
-
Le next hop d'une FEC change pour devenir un autre pair LDP, et la détection de boucles est configurée.
-
Les attributs d'un mappage changent.
-
La réception d'un mappage du next hop en aval ET :
a) aucun mappage en amont n'a été créé, OU b) la détection de boucles est configurée, OU c) les attributs du mappage ont changé.
3.5.7.1.2. Mappage en contrôle ordonné
Si un LSR effectue un contrôle ordonné (Ordered Control), un message Mapping est transmis par les LSR en aval dans l'une quelconque des conditions suivantes :
-
Le LSR reconnaît une nouvelle FEC via la table de transfert et est le nœud de sortie (egress) pour cette FEC.
-
Le LSR reçoit un message Request d'un pair en amont pour une FEC présente dans la table de transfert du LSR, et le LSR est le nœud de sortie pour cette FEC OU dispose d'un mappage en aval pour cette FEC.
-
Le next hop d'une FEC change pour devenir un autre pair LDP, et la détection de boucles est configurée.
-
Les attributs d'un mappage changent.
-
La réception d'un mappage du next hop en aval ET :
a) no upstream mapping has been created OR
b) Loop Detection is configured OR
c) the attributes of the mapping have changed.
3.5.7.1.3. Annonce d'étiquettes Downstream on Demand
En général, le LSR en amont est responsable de la demande de mappages d'étiquettes lorsqu'il fonctionne en mode Downstream on Demand. Toutefois, à moins que certaines règles ne soient respectées, il est possible que des LSR voisins ayant des modes d'annonce différents se retrouvent dans une situation d'interblocage (livelock) où tout fonctionne correctement, mais où aucune étiquette n'est distribuée. Par exemple, considérons deux LSR Ru et Rd, où Ru est le LSR en amont et Rd le LSR en aval pour une FEC particulière. Dans cet exemple, Ru utilise le mode d'annonce Downstream Unsolicited et Rd utilise le mode Downstream on Demand. Dans ce cas, Rd peut supposer que Ru demandera un mappage d'étiquettes lorsqu'il en voudra un, et Ru peut supposer que Rd annoncera une étiquette s'il souhaite que Ru en utilise une. Si Rd et Ru fonctionnent comme suggéré, aucune étiquette ne sera distribuée de Rd vers Ru.
Cette situation d'interblocage peut être évitée si la règle suivante est respectée : un LSR fonctionnant en mode Downstream on Demand NE DEVRAIT PAS (SHOULD NOT) être censé envoyer des annonces de mappage non sollicitées. Par conséquent, si le LSR en aval fonctionne en mode Downstream on Demand, le LSR en amont est responsable de la demande de mappages d'étiquettes selon ses besoins.
3.5.7.1.4. Annonce d'étiquettes Downstream Unsolicited
En général, le LSR en aval est responsable de l'annonce d'un mappage d'étiquettes lorsqu'il souhaite qu'un LSR en amont utilise l'étiquette. Un LSR en amont peut émettre une demande de mappage s'il le souhaite.
La combinaison du mode Downstream Unsolicited et de la rétention conservatrice d'étiquettes (Conservative Label retention) peut conduire à une situation où un LSR libère l'étiquette d'une FEC dont il aura besoin ultérieurement. Par exemple, si le LSR Rd annonce au LSR Ru l'étiquette d'une FEC pour laquelle il n'est pas le next hop de Ru, Ru libérera l'étiquette. Si le next hop de Ru pour la FEC devient ensuite Rd, il aura besoin de l'étiquette précédemment libérée.
Pour faire face à cette situation, soit Ru peut demander explicitement l'étiquette lorsqu'il en a besoin, soit Rd peut la ré-annoncer périodiquement à Ru. Dans de nombreuses situations, Ru saura quand il a besoin de l'étiquette de Rd. Par exemple, lorsque son next hop pour la FEC devient Rd. Toutefois, il peut exister des situations où Ru ne le sait pas. Par exemple, Rd peut tenter d'établir un LSP aux propriétés non standard. Forcer Ru à demander explicitement l'étiquette dans cette situation l'obligerait à maintenir un état concernant un LSP potentiel aux propriétés non standard.
Dans les situations où Ru sait qu'il a besoin de l'étiquette, il est responsable de demander explicitement l'étiquette au moyen d'un message Label Request. Dans les situations où Ru peut ne pas savoir qu'il a besoin de l'étiquette, Rd est responsable de ré-annoncer périodiquement l'étiquette à Ru.
Pour cette 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 next hop pour la FEC, que Ru ne dispose pas d'une étiquette de Rd, et que le LSP pour la FEC est un LSP pouvant être établi avec les TLV définis dans ce document.