Aller au contenu principal

2. Fonctionnement de LDP

2.1. FEC​

Il est nécessaire de spécifier précisément quels paquets peuvent être mappés à chaque LSP. Cela se fait en fournissant une spécification de FEC pour chaque LSP. La FEC identifie l'ensemble des paquets IP susceptibles d'être mappés à 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 susceptibles d'être mappés au LSP correspondant. Lorsqu'un LSP est partagé par plusieurs éléments de FEC, ce LSP est terminé au niveau du nœud (ou avant celui-ci) 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'"Address Prefix FEC element". Cet élément est un préfixe d'adresse de toute longueur, de 0 à une adresse complète inclusivement.

D'autres éléments de FEC peuvent être définis, au besoin, par d'autres spécifications.

Dans le reste de cette section, nous donnons les règles à utiliser pour mapper des paquets à des LSP qui ont été établis au moyen d'un Address Prefix FEC element.

Nous disons qu'une adresse particulière "correspond" à un préfixe d'adresse particulier si et seulement si cette adresse commence par ce préfixe. Nous disons également qu'un paquet particulier correspond à un LSP particulier si et seulement si ce LSP possède un Address Prefix FEC element qui correspond à l'adresse de destination du paquet. Pour un paquet particulier et un LSP particulier, nous appelons "matching prefix" tout Address Prefix FEC element qui correspond au paquet.

La procédure de mappage d'un paquet particulier à un LSP particulier utilise les règles suivantes. Chaque règle est appliquée à son tour jusqu'à ce que le paquet puisse être mappé à un LSP.

  • Si un paquet correspond exactement à un LSP, le paquet est mappé à ce LSP.

  • Si un paquet correspond à plusieurs LSP, il est mappé au LSP dont le matching prefix est le plus long. S'il n'existe pas un LSP unique dont le matching prefix soit le plus long, le paquet est mappé à l'un de l'ensemble des LSP dont le matching prefix est plus long que les autres. La procédure de sélection de l'un de ces LSP dépasse le cadre de ce document.

  • S'il est connu qu'un paquet doit traverser un routeur de sortie (egress) particulier, et s'il existe un LSP qui possède un Address Prefix FEC element correspondant à une adresse /32 de ce routeur, alors le paquet est mappé à ce LSP. La procédure d'obtention de cette connaissance dépasse le cadre de ce document.

La procédure permettant de déterminer qu'un paquet doit traverser un routeur de sortie particulier dépasse le cadre de ce document. (À titre d'exemple, si l'on exécute un algorithme de routage à état de liens, il peut être possible d'obtenir cette information à partir de la base de données d'état de liens. Autre exemple : si l'on exécute BGP, il peut être possible d'obtenir cette information à partir de l'attribut next hop BGP de la route du paquet.)

2.2. Espaces d'étiquettes, identifiants, sessions et transport​

2.2.1. Espaces d'étiquettes​

La notion d'"espace d'étiquettes" (label space) est utile pour discuter de l'attribution et de la distribution des étiquettes. Il existe deux types d'espaces d'étiquettes :

  • Espace d'étiquettes par interface (per interface label space). Les étiquettes entrantes propres à une interface sont utilisées pour les interfaces qui consomment des ressources d'interface pour les étiquettes. Un exemple d'une telle interface est une interface ATM à contrôle par étiquettes qui utilise des VCI (Virtual Channel Identifier) comme étiquettes, ou une interface Frame Relay qui utilise des DLCI (Data Link Connection Identifier) comme étiquettes.

    Notez que l'utilisation d'un espace d'étiquettes par interface n'a de sens que lorsque les pairs LDP sont "directement connectés" via une interface, et que l'étiquette ne sera utilisée que pour le trafic envoyé sur cette interface.

  • Espace d'étiquettes par plateforme (per platform label space). Les étiquettes entrantes à l'échelle de la plateforme sont utilisées pour les interfaces qui peuvent partager les mêmes étiquettes.

2.2.2. LDP Identifiers​

Un LDP Identifier 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 globalement unique, telle qu'un router Id de 32 bits attribué au LSR. Les deux derniers octets identifient un espace d'étiquettes spécifique au sein du LSR. Les deux derniers octets des LDP Identifiers pour les espaces d'étiquettes à l'échelle de la plateforme sont toujours tous deux nuls. Ce document utilise la représentation imprimée suivante pour les LDP Identifiers :

  <LSR Id> : <label space id>

par exemple, lsr171:0, lsr19:2.

Notez qu'un LSR qui gère et annonce plusieurs espaces d'étiquettes utilise un LDP Identifier différent pour chacun de ces espaces d'étiquettes.

Une situation dans laquelle un LSR devrait annoncer plus d'un espace d'étiquettes à un pair, et donc utiliser plus d'un LDP Identifier, se produit lorsque le LSR a deux liaisons vers le pair et que les deux sont ATM (et utilisent des étiquettes par interface). Une autre situation serait celle où le LSR aurait deux liaisons vers le pair, dont l'une est Ethernet (et utilise des étiquettes par plateforme) et l'autre ATM.

2.2.3. Sessions LDP​

Des sessions LDP existent entre LSR pour prendre en charge l'échange d'étiquettes entre eux.

Lorsqu'un LSR utilise LDP pour annoncer plus d'un espace d'étiquettes à un autre LSR, il utilise une session LDP distincte 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 LSR non directement connectés​

Les sessions LDP entre LSR qui ne sont pas directement connectés au niveau de la liaison peuvent être souhaitables dans certaines situations.

Par exemple, considérons une application d'"ingénierie de trafic" dans laquelle LSRa envoie du trafic correspondant à certains critères via un LSP vers LSRb, qui n'est pas directement connecté, plutôt que de transférer le trafic le long de son chemin routé normalement.

Le chemin entre LSRa et LSRb comprendrait un ou plusieurs LSR intermédiaires (LSR1,...LSRn). Une session LDP entre LSRa et LSRb permettrait à LSRb de commuter d'étiquettes le trafic arrivant sur le LSP depuis LSRa, en fournissant à LSRb un moyen d'annoncer des étiquettes à cette fin à LSRa.

Dans cette situation, LSRa appliquerait deux étiquettes au trafic qu'il transfère sur le LSP vers LSRb : une étiquette apprise de LSR1 pour transférer le trafic le long du chemin du LSP de LSRa à LSRb ; et une étiquette apprise de LSRb pour permettre à LSRb de commuter d'étiquettes le trafic arrivant sur le LSP.

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

2.4. Découverte LDP​

La découverte LDP est un mécanisme qui permet à un LSR de découvrir des pairs LDP potentiels. La découverte rend inutile la configuration explicite des pairs de commutation d'étiquettes d'un LSR.

Il existe deux variantes du mécanisme de découverte :

  • Un mécanisme de découverte de base (Basic Discovery) utilisé pour découvrir les voisins LSR directement connectés au niveau de la liaison.

  • Un mécanisme de découverte étendue (Extended Discovery) utilisé pour localiser les LSR qui ne sont pas directement connectés au niveau de la liaison.

2.4.1. Mécanisme de découverte de base​

Pour s'engager dans la Basic Discovery LDP sur une interface, un LSR envoie périodiquement des LDP Link Hellos sur l'interface. Les LDP Link Hellos sont envoyés sous forme de paquets UDP adressés au port bien connu de découverte LDP, à l'adresse de groupe multicast "all routers on this subnet".

Un LDP Link Hello envoyé par un LSR transporte le LDP Identifier de l'espace d'étiquettes que le LSR a l'intention d'utiliser pour l'interface, ainsi que, éventuellement, des informations supplémentaires.

La réception d'un LDP Link Hello sur une interface identifie une "Hello adjacency" avec un pair LDP potentiel joignable au niveau de la liaison sur l'interface, ainsi que l'espace d'étiquettes que le pair a l'intention d'utiliser pour l'interface.

2.4.2. Mécanisme de découverte étendue​

Les sessions LDP entre LSR non directement connectés sont prises en charge par la LDP Extended Discovery.

Pour s'engager dans la LDP Extended Discovery, un LSR envoie périodiquement des LDP Targeted Hellos à une adresse spécifique. Les LDP Targeted Hellos sont envoyés sous forme de paquets UDP adressés au port bien connu de découverte LDP, à l'adresse spécifique.

Un LDP Targeted Hello envoyé par un LSR transporte le LDP Identifier de l'espace d'étiquettes que le LSR a l'intention d'utiliser et, éventuellement, des informations optionnelles supplémentaires.

La Extended Discovery diffère de la Basic Discovery des manières suivantes :

  • Un Targeted Hello est envoyé à une adresse spécifique plutôt qu'à l'adresse de groupe multicast "all routers" de l'interface de sortie.

  • Contrairement à la Basic Discovery, qui est symétrique, la Extended Discovery est asymétrique.

    Un LSR initie la Extended Discovery avec un autre LSR ciblé, et le LSR ciblé décide de répondre ou d'ignorer le Targeted Hello. Un LSR ciblé qui choisit de répondre le fait en envoyant périodiquement des Targeted Hellos au LSR initiateur.

La réception d'un LDP Targeted Hello identifie une "Hello adjacency" avec un pair LDP potentiel joignable au niveau du réseau, ainsi que l'espace d'étiquettes que le pair a l'intention d'utiliser.

2.5. Établissement et maintien des sessions LDP​

2.5.1. Établissement de session LDP​

L'échange de LDP Discovery Hellos entre deux LSR déclenche l'établissement d'une session LDP. L'établissement de session est un processus en deux étapes :

  • Établissement de la connexion de transport
  • Initialisation de la session

Ce qui suit décrit l'établissement d'une session LDP entre les LSR LSR1 et LSR2 du point de vue de LSR1. Cela suppose l'échange de Hellos spécifiant l'espace d'étiquettes LSR1:a pour LSR1 et l'espace d'étiquettes LSR2:b pour LSR2.

2.5.2. Établissement de la connexion de transport​

L'échange de Hellos aboutit à la création, au niveau de LSR1, d'une Hello adjacency qui sert à lier la liaison (L) et les espaces d'étiquettes LSR1:a et LSR2:b.

  1. Si LSR1 n'a pas déjà de session LDP pour l'échange des espaces d'étiquettes LSR1:a et LSR2:b, il tente d'ouvrir une connexion TCP pour une nouvelle session LDP avec LSR2.

    LSR1 détermine les adresses de transport à utiliser à son extrémité (A1) et à l'extrémité de LSR2 (A2) de la connexion TCP LDP. L'adresse A1 est déterminée comme suit :

    a. Si LSR1 utilise l'objet optionnel Transport Address (TLV) dans les Hellos qu'il envoie à LSR2 pour annoncer une adresse, A1 est l'adresse que LSR1 annonce via l'objet optionnel ;

    b. Si LSR1 n'utilise pas l'objet optionnel Transport Address, A1 est l'adresse source utilisée dans les Hellos qu'il envoie à LSR2.

    De même, l'adresse A2 est déterminée comme suit :

    a. Si LSR2 utilise l'objet optionnel Transport Address, A2 est l'adresse que LSR2 annonce via l'objet optionnel ;

    b. Si LSR2 n'utilise pas l'objet optionnel Transport Address, A2 est l'adresse source des Hellos reçus de LSR2.

  2. LSR1 détermine s'il jouera le rôle actif ou passif dans l'établissement de la session en comparant les adresses A1 et A2 en tant qu'entiers non signés. Si A1 > A2, LSR1 joue le rôle actif ; sinon, il est passif.

    La procédure de comparaison de A1 et A2 en tant qu'entiers non signés est la suivante :

    • Si A1 et A2 ne sont pas dans la même famille d'adresses, elles sont incomparables et aucune session ne peut être établie.

    • Soit U1 l'entier non signé abstrait obtenu en traitant A1 comme une séquence d'octets, où l'octet qui apparaît le plus tôt dans le message est l'octet de poids fort de l'entier et l'octet qui apparaît le plus tard dans le message est l'octet de poids faible de l'entier.

      Soit U2 l'entier non signé abstrait obtenu à partir de A2 de manière similaire.

    • Comparez U1 et U2. Si U1 > U2, alors A1 > A2 ; si U1 < U2, alors A1 < A2.

  3. Si LSR1 est actif, il tente d'établir la connexion TCP LDP en se connectant au port LDP bien connu à l'adresse A2. Si LSR1 est passif, il attend que LSR2 établisse la connexion TCP LDP vers son port LDP bien connu.

Notez que, lorsqu'un LSR envoie un Hello, il sélectionne l'adresse de transport pour son extrémité de la connexion de session et utilise le Hello pour annoncer l'adresse, soit explicitement en l'incluant dans un Transport Address TLV optionnel, soit implicitement en omettant le TLV et en l'utilisant comme adresse source du Hello.

Un LSR DOIT (MUST) annoncer la même adresse de transport dans tous les Hellos qui annoncent le même espace d'étiquettes. Cette exigence garantit que deux LSR reliés par plusieurs Hello adjacencies utilisant les mêmes espaces 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 Initialization LDP. Les paramètres négociés comprennent la version du protocole LDP, la méthode de distribution d'étiquettes, les valeurs de temporisation, les plages VPI/VCI (Virtual Path Identifier / Virtual Channel Identifier) pour ATM à contrôle par étiquettes, les plages DLCI (Data Link Connection Identifier) pour Frame Relay à contrôle par étiquettes, etc.

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

Ce qui suit décrit l'initialisation de session du point de vue de LSR1.

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

En général, lorsqu'il existe plusieurs liaisons entre LSR1 et LSR2 et que plusieurs espaces d'étiquettes doivent être annoncés par chacun, le LSR passif ne peut pas savoir quel espace d'étiquettes annoncer sur une connexion TCP nouvellement établie avant d'avoir reçu le message Initialization LDP sur la connexion. Le message Initialization transporte à la fois le LDP Identifier de l'espace d'étiquettes de l'émetteur (LSR actif) et le LDP Identifier de l'espace d'étiquettes du récepteur (LSR passif).

En attendant le message Initialization de son pair, le LSR passif peut faire correspondre l'espace d'étiquettes à annoncer par le pair (tel que déterminé à partir du LDP Identifier de l'en-tête du PDU du message Initialization) à une Hello adjacency précédemment créée lors de l'échange des Hellos.

  1. Lorsque LSR1 joue le rôle passif :

    a. Si LSR1 reçoit un message Initialization, il tente de faire correspondre le LDP Identifier transporté par le PDU du message à une Hello adjacency.

    b. S'il existe une Hello adjacency correspondante, l'adjacence spécifie l'espace d'étiquettes local pour la session.

    Ensuite, LSR1 vérifie si les paramètres de session proposés dans le message sont acceptables. S'ils le sont, LSR1 répond par un message Initialization de son cru pour proposer les paramètres qu'il souhaite utiliser, et par un message KeepAlive pour signaler l'acceptation des paramètres de LSR2. Si les paramètres ne sont pas acceptables, LSR1 répond en envoyant un message Notification Session Rejected/Parameters Error et en fermant la connexion TCP.

    c. Si LSR1 ne trouve pas de Hello adjacency correspondante, il envoie un message Notification Session Rejected/No Hello Error et ferme la connexion TCP.

    d. Si LSR1 reçoit un KeepAlive en réponse à son message Initialization, la session est opérationnelle du point de vue de LSR1.

    e. Si LSR1 reçoit un message Error Notification, LSR2 a rejeté la session qu'il a proposée et LSR1 ferme la connexion TCP.

  2. Lorsque LSR1 joue le rôle actif :

    a. Si LSR1 reçoit un message Error Notification, LSR2 a rejeté la session qu'il a proposée et LSR1 ferme la connexion TCP.

    b. Si LSR1 reçoit un message Initialization, il vérifie si les paramètres de session sont acceptables. Si oui, il répond par un message KeepAlive. Si les paramètres de session sont inacceptables, LSR1 envoie un message Notification Session Rejected/Parameters Error et ferme la connexion.

    c. Si LSR1 reçoit un message KeepAlive, LSR2 a accepté les paramètres de session qu'il a proposés.

    d. Lorsque LSR1 a reçu à la fois un message Initialization acceptable et un message KeepAlive, la session est opérationnelle du point de vue de LSR1.

    Jusqu'à l'établissement de la session LDP, aucun autre message que ceux énumérés dans les procédures ci-dessus ne peut être échangé, et les règles de traitement du U-bit 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 Shutdown msg DOIT (MUST) être transmis et la connexion de transport DOIT (MUST) être fermée.

Il est possible que deux LSR configurés de manière incompatible, qui ne s'accordent pas sur les paramètres de session, s'engagent dans une séquence sans fin de messages, chacun NAKant les messages Initialization de l'autre par des messages Error Notification.

Un LSR DOIT (MUST) limiter (throttle) ses tentatives de réessai d'établissement de session au moyen d'un backoff exponentiel dans les situations où des messages Initialization sont NAKés. Il est également recommandé qu'un LSR détectant une telle situation prenne des mesures pour en avertir un opérateur.

La tentative d'établissement de session suivant un message Initialization NAKé DOIT (MUST) être différée d'au moins 15 secondes, et les délais ultérieurs DOIVENT (MUST) croître jusqu'à un délai maximal d'au moins 2 minutes. L'action spécifique d'établissement de session qui doit être différée est la tentative d'ouvrir la connexion de transport de session par le LSR jouant le rôle actif.

La séquence limitée de NAK d'Initialization a peu de chances de cesser avant qu'une intervention de l'opérateur ne reconfigure l'un des LSR. Après une telle action de configuration, il n'est plus nécessaire de limiter les tentatives ultérieures d'établissement de session (jusqu'à ce que leurs messages Initialization soient NAKés).

En raison de la nature asymétrique de l'établissement de session, la reconfiguration du LSR passif passera inaperçue du LSR actif en l'absence de toute action supplémentaire. La section "Hello Message" décrit un mécanisme optionnel qu'un LSR peut utiliser pour signaler à des pairs LDP potentiels qu'il a été reconfiguré.

2.5.4. Machine à états d'initialisation​

Il est commode de décrire le comportement de négociation de session LDP en termes de machine à états. Nous définissons la machine à états LDP comme ayant cinq états possibles et présentons le comportement sous forme d'une table de transition d'états et d'un diagramme de transition d'états. Notez qu'un message Shutdown est mis en œuvre sous forme d'un message Notification avec un Status TLV indiquant une erreur fatale.

            Session Initialization State Transition Table

STATE         EVENT                               NEW STATE

NON EXISTENT  Session TCP connection established  INITIALIZED
              established

INITIALIZED   Transmit Initialization msg         OPENSENT
                    (Active Role)

              Receive acceptable                  OPENREC
                    Initialization msg
                    (Passive Role)
                Action: Transmit Initialization
                        msg and KeepAlive msg

              Receive Any other LDP msg           NON EXISTENT
                Action: Transmit Error Notification msg
                        (NAK) and close transport connection

OPENREC       Receive KeepAlive msg               OPERATIONAL

              Receive Any other LDP msg           NON EXISTENT
                Action: Transmit Error Notification msg
                        (NAK) and close transport connection

OPENSENT      Receive acceptable                  OPENREC
                    Initialization msg
                Action: Transmit KeepAlive msg

              Receive Any other LDP msg           NON EXISTENT
                Action: Transmit Error Notification msg
                        (NAK) and close transport connection

OPERATIONAL   Receive Shutdown msg                NON EXISTENT
                Action: Transmit Shutdown msg and
                        close transport connection

              Receive other LDP msgs              OPERATIONAL
              Timeout                             NON EXISTENT
                Action: Transmit Shutdown msg and
                        close transport connection
           Session Initialization State Transition Diagram

                           +------------+
                           |            |
             +------------>|NON EXISTENT|<--------------------+
             |             |            |                     |
             |             +------------+                     |
             | Session        |    ^                          |
             |   connection   |    |                          |
             |   established  |    | Rx any LDP msg except    |
             |                V    |   Init msg or Timeout    |
             |            +-----------+                       |
Rx Any other |            |           |                       |
   msg or    |            |INITIALIZED|                       |
   Timeout / |        +---|           |-+                     |
Tx NAK msg   |        |   +-----------+ |                     |
             |        | (Passive Role)  | (Active Role)       |
             |        | Rx Acceptable   | Tx Init msg         |
             |        |    Init msg /   |                     |
             |        | Tx Init msg     |                     |
             |        |    Tx KeepAlive |                     |
             |        V    msg          V                     |
             |   +-------+        +--------+                  |
             |   |       |        |        |                  |
             +---|OPENREC|        |OPENSENT|----------------->|
             +---|       |        |        | Rx Any other msg |
             |   +-------+        +--------+    or Timeout    |
Rx KeepAlive |        ^                |     Tx NAK msg       |
   msg       |        |                |                      |
             |        |                | Rx Acceptable        |
             |        |                |    Init msg /        |
             |        +----------------+ Tx KeepAlive msg     |
             |                                                |
             |      +-----------+                             |
             +----->|           |                             |
                    |OPERATIONAL|                             |
                    |           |---------------------------->+
                    +-----------+     Rx Shutdown msg
             All other  |   ^            or Timeout /
               LDP msgs |   |         Tx Shutdown msg
                        |   |
                        +---+

2.5.5. Maintien des Hello adjacencies​

Une session LDP avec un pair possède une ou plusieurs Hello adjacencies.

Une session LDP possède plusieurs Hello adjacencies lorsqu'une paire de LSR est relié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 Hellos qu'un LSR envoie sur chacune de ces liaisons transportent le même LDP Identifier.

LDP inclut des mécanismes pour surveiller la nécessité d'une session LDP et de ses Hello adjacencies.

LDP utilise la réception régulière de LDP Discovery Hellos pour indiquer l'intention d'un pair d'utiliser l'espace d'étiquettes identifié par le Hello. Un LSR maintient un hold timer pour chaque Hello adjacency, qu'il redémarre lorsqu'il reçoit un Hello correspondant à l'adjacence. Si le timer expire sans réception d'un Hello correspondant de la part du pair, LDP conclut que le pair ne souhaite plus commuter d'étiquettes en utilisant cet espace d'étiquettes pour cette liaison (ou cette cible, dans le cas des Targeted Hellos) ou que le pair a échoué. Le LSR supprime alors la Hello adjacency. Lorsque la dernière Hello adjacency d'une session LDP est supprimée, le LSR termine la session LDP en envoyant un message Notification et en fermant la connexion de transport.

2.5.6. Maintien des sessions LDP​

LDP inclut des mécanismes pour surveiller l'intégrité de la session LDP.

LDP utilise la réception régulière de PDU LDP sur la connexion de transport de session pour surveiller l'intégrité de la session. Un LSR maintient un KeepAlive Timer pour chaque session de pair, qu'il réinitialise chaque fois qu'il reçoit un PDU LDP du pair de la session. Si le KeepAlive Timer expire sans réception d'un PDU LDP de la part du pair, le LSR conclut que la connexion de transport est défaillante ou que le pair a échoué, et il termine la session LDP en fermant la connexion de transport.

Après l'établissement d'une session LDP, un LSR doit faire en sorte que son pair reçoive de sa part un PDU LDP au moins à chaque période de KeepAlive time, afin de garantir que le pair redémarre le session KeepAlive Timer. Le LSR peut envoyer n'importe quel message du protocole pour satisfaire à cette exigence. Dans les circonstances où un LSR n'a aucune autre information à communiquer à son pair, il envoie un message KeepAlive.

Un LSR peut choisir de terminer à tout moment une session LDP avec un pair. S'il choisit de le faire, il en informe le pair au moyen d'un message Shutdown.

2.6. Distribution et gestion des étiquettes​

L'architecture MPLS [RFC3031] permet à un LSR de distribuer une liaison d'étiquettes de FEC en réponse à une demande explicite d'un autre LSR. C'est ce qu'on appelle la distribution d'étiquettes Downstream On Demand. Elle permet également à un LSR de distribuer des liaisons d'étiquettes à des LSR qui ne les ont pas explicitement demandées. [RFC3031] appelle cette méthode de distribution d'étiquettes Unsolicited Downstream ; le présent document utilise le terme Downstream Unsolicited.

Ces deux techniques de distribution d'étiquettes peuvent être utilisées dans le même réseau en même temps. Toutefois, pour une session LDP donnée, chaque LSR doit connaître la méthode de distribution d'étiquettes utilisée par son pair afin d'éviter les situations où un pair utilisant la distribution d'étiquettes Downstream Unsolicited suppose que son pair fait de même. Voir la section "Downstream on Demand Label Advertisement".

2.6.1. Mode de contrôle de la distribution d'étiquettes​

Le comportement de l'établissement initial des LSP est déterminé par le fait que le LSR fonctionne en contrôle 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 de distribution d'étiquettes indépendant​

En contrôle LSP indépendant, chaque LSR peut annoncer des mappages d'étiquettes à ses voisins à tout moment qu'il souhaite. Par exemple, en mode Downstream on Demand indépendant, un LSR peut répondre immédiatement aux demandes de mappages d'étiquettes, sans attendre un mappage d'étiquettes du next hop. En mode Downstream Unsolicited indépendant, un LSR peut annoncer un mappage d'étiquettes pour une FEC à ses voisins dès qu'il est prêt à commuter d'étiquettes cette FEC.

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

2.6.1.2. Contrôle de distribution d'étiquettes ordonné​

En contrôle LSP ordonné, un LSR ne peut initier la transmission d'un mappage d'étiquettes que pour une FEC pour laquelle il dispose d'un mappage d'étiquettes pour le next hop de la FEC, ou pour laquelle le LSR est l'egress. Pour chaque FEC pour laquelle le LSR n'est pas l'egress et pour laquelle aucun mappage n'existe, le LSR DOIT (MUST) attendre qu'une étiquette d'un LSR en aval soit reçue avant de mapper la FEC et de transmettre les étiquettes correspondantes aux LSR en amont. Un LSR peut être un egress pour certaines FEC et un non-egress pour d'autres.

Un LSR peut agir comme LSR egress, relativement à une FEC particulière, dans l'une quelconque des conditions suivantes :

  1. La FEC se rapporte au LSR lui-même (y compris l'une de ses interfaces directement rattachées).

  2. Le routeur next hop de la FEC est en dehors du réseau à commutation d'étiquettes.

  3. Les éléments de FEC sont joignables en franchissant une frontière de domaine de routage, telle qu'une autre zone pour les réseaux de résumé OSPF, ou un autre système autonome pour les externes AS OSPF et les routes BGP [RFC2328] [RFC4271].

Notez que le fait qu'un LSR soit un egress pour une FEC donnée peut changer au fil du temps, selon l'état du réseau et les réglages de configuration du LSR.

2.6.2. Mode de rétention d'étiquettes​

L'architecture MPLS [RFC3031] introduit la notion de mode de rétention d'étiquettes (label retention mode), qui spécifie si un LSR conserve une liaison d'étiquettes pour une FEC apprise d'un voisin qui n'est pas son next hop pour la FEC.

2.6.2.1. Mode de rétention d'étiquettes conservateur​

En mode d'annonce Downstream Unsolicited, les annonces de mappage d'étiquettes pour toutes les routes peuvent être reçues de tous les LSR pairs. En rétention d'étiquettes conservatrice (Conservative Label retention), les mappages d'étiquettes annoncés ne sont conservés que s'ils seront utilisés pour transférer des paquets (c'est-à-dire s'ils sont reçus d'un next hop valide selon le routage). En mode Downstream on Demand, un LSR ne demandera des mappages d'étiquettes qu'au LSR next hop selon le routage. Comme le mode Downstream on Demand est principalement utilisé lorsque la conservation des étiquettes est souhaitée (par exemple, un commutateur ATM disposant d'un espace de connexion croisée limité), il est typiquement utilisé avec le mode de rétention d'étiquettes conservateur.

Le principal avantage du mode conservateur est que seules les étiquettes nécessaires au transfert des données sont allouées et maintenues. Ceci est particulièrement important dans les LSR où l'espace d'étiquettes est intrinsèquement limité, comme dans un commutateur ATM. Un inconvénient du mode conservateur est que, si le routage change le next hop pour une destination donnée, une nouvelle étiquette doit être obtenue du nouveau next hop avant que des paquets étiquetés puissent être transférés.

2.6.2.2. Mode de rétention d'étiquettes libéral​

En mode d'annonce Downstream Unsolicited, les annonces de mappage d'étiquettes pour toutes les routes peuvent être reçues de tous les pairs LDP. En rétention d'étiquettes libérale (Liberal Label retention), chaque mappage d'étiquettes reçu d'un LSR pair est conservé, que le LSR soit ou non le next hop du mappage annoncé. En mode Downstream on Demand avec rétention d'étiquettes libérale, un LSR peut choisir de demander des mappages d'étiquettes pour tous les préfixes connus à tous les LSR pairs. Notez toutefois que le mode Downstream on Demand est typiquement utilisé par des dispositifs tels que les LSR à base de commutateur ATM, pour lesquels l'approche conservatrice est recommandée.

Le principal avantage du mode de rétention d'étiquettes libéral est que la réaction aux changements de routage peut être rapide, car les étiquettes existent déjà. Le principal inconvénient du mode libéral est que des mappages d'étiquettes inutiles sont distribués et maintenus.

2.6.3. Mode d'annonce d'étiquettes​

Chaque interface d'un LSR est configurée pour fonctionner soit en mode d'annonce Downstream Unsolicited, soit en mode d'annonce Downstream on Demand. Les LSR échangent leurs modes d'annonce pendant l'initialisation. La différence majeure entre les modes Downstream Unsolicited et Downstream on Demand réside dans le LSR qui assume la responsabilité d'initier les demandes de mappage et les annonces de mappage.

2.7. LDP Identifiers et adresses de next hop​

Un LSR maintient les étiquettes apprises dans une Label Information Base (LIB). En mode Downstream Unsolicited, l'entrée de LIB d'un préfixe d'adresse associe une collection de paires (LDP Identifier, label) au préfixe, une telle paire pour chaque pair annonçant une étiquette pour le préfixe.

Lorsque le next hop d'un préfixe change, le LSR doit récupérer dans la LIB l'étiquette annoncée par le nouveau next hop, afin de l'utiliser pour le transfert. Pour récupérer l'étiquette, le LSR doit pouvoir faire correspondre l'adresse de next hop du préfixe à un LDP Identifier.

De même, lorsque le LSR apprend une étiquette pour un préfixe auprès d'un pair LDP, il doit pouvoir déterminer si ce pair est actuellement un next hop du préfixe, afin de déterminer s'il doit commencer à utiliser l'étiquette nouvellement apprise lors du transfert des paquets qui correspondent au préfixe. Pour prendre cette décision, le LSR doit pouvoir faire correspondre un LDP Identifier aux adresses du pair afin de vérifier si l'une d'elles est un next hop du préfixe.

Pour permettre aux LSR de faire correspondre un LDP Identifier de pair et les adresses du pair, les LSR annoncent leurs adresses au moyen des messages LDP Address et Withdraw Address.

Un LSR envoie un message Address pour annoncer ses adresses à un pair. Un LSR envoie un message Withdraw Address pour retirer des adresses précédemment annoncées auprès d'un pair.

2.8. Détection de boucles​

La détection de boucles est une option configurable qui fournit un mécanisme pour trouver les LSP en boucle et pour empêcher les messages Label Request de boucler en présence de LSR incapables de fusion (non-merge capable).

Le mécanisme utilise les Path Vector et Hop Count TLVs transportés par les messages Label Request et Label Mapping. Il s'appuie sur les propriétés de base suivantes de ces TLV :

  • Un Path Vector TLV contient une liste des LSR que le message qui le contient a traversés. Un LSR est identifié dans une liste de Path Vector par son LSR Identifier (Id) unique, qui correspond aux quatre premiers octets de son LDP Identifier. Lorsqu'un LSR propage un message contenant un Path Vector TLV, il ajoute son LSR Id à la liste de Path Vector. Un LSR qui reçoit un message dont le Path Vector contient son LSR Id détecte que le message a traversé une boucle. LDP prend en charge la notion de longueur maximale autorisée de Path Vector ; un LSR qui détecte qu'un Path Vector a atteint la longueur maximale se comporte comme si le message conteneur avait traversé une boucle.

  • Un Hop Count TLV contient un décompte des LSR que le message conteneur a traversés. Lorsqu'un LSR propage un message contenant un Hop Count TLV, il incrémente le décompte. Un LSR qui détecte qu'un Hop Count a atteint une valeur maximale configurée se comporte comme si le message conteneur avait traversé une boucle. Par convention, un décompte de 0 est interprété comme signifiant que le nombre de sauts est inconnu. L'incrémentation d'une valeur de nombre de sauts inconnu donne une valeur de nombre de sauts inconnu (0).

Les paragraphes suivants décrivent les procédures de détection de boucles LDP. Pour ces paragraphes, et uniquement pour ceux-ci, "MUST" est redéfini comme signifiant "MUST si configuré pour la détection de boucles". Les paragraphes spécifient les messages qui DOIVENT (MUST) transporter des Path Vector et Hop Count TLVs. Notez que le Hop Count TLV et ses procédures sont utilisés sans le Path Vector TLV dans les situations où la détection de boucles n'est pas configurée (voir [RFC3035] et [RFC3034]).

2.8.1. Message Label Request​

L'utilisation du Path Vector TLV et du Hop Count TLV empêche les messages Label Request de boucler dans les environnements qui comprennent des LSR incapables de fusion.

Les règles qui régissent l'utilisation du Hop Count TLV dans les messages Label Request par un LSR R lorsque la détection de boucles est activée sont les suivantes :

  • Le message Label Request DOIT (MUST) inclure un Hop Count TLV.

  • Si R envoie le Label Request parce qu'il est un ingress de la FEC, il DOIT (MUST) inclure un Hop Count TLV avec une valeur de nombre de sauts de 1.

  • Si R envoie le Label Request parce qu'il a reçu un Label Request d'un LSR en amont, et si le Label Request reçu contient un Hop Count TLV, R DOIT (MUST) incrémenter de 1 la valeur du nombre de sauts reçue et DOIT (MUST) transmettre la valeur résultante dans un Hop Count TLV à son next hop, en même temps que le message Label Request.

Les règles qui régissent l'utilisation du Path Vector TLV dans les messages Label Request par un LSR R lorsque la détection de boucles est activée sont les suivantes :

  • Si R envoie le Label Request parce qu'il est un ingress de la FEC, alors si R est incapable de fusion, il DOIT (MUST) inclure un Path Vector TLV de longueur 1 contenant son propre LSR Id.

  • Si R envoie le Label Request parce qu'il a reçu un Label Request d'un LSR en amont, alors si le Label Request reçu contient un Path Vector TLV ou si R est incapable de fusion :

    R DOIT (MUST) ajouter son propre LSR Id au Path Vector, et DOIT (MUST) transmettre le Path Vector résultant à son next hop, en même temps que le message Label Request. Si le Label Request ne contient aucun Path Vector TLV, R DOIT (MUST) inclure un Path Vector TLV de longueur 1 contenant son propre LSR Id.

Notez que si R reçoit un message Label Request pour une FEC particulière, et que R a précédemment envoyé un message Label Request pour cette FEC à son next hop et n'a pas encore reçu de réponse, et si R a l'intention de fusionner le Label Request nouvellement reçu avec le Label Request en cours existant, alors R ne propage pas le Label Request vers le next hop.

Si R reçoit un message Label Request de son next hop avec un Hop Count TLV qui dépasse la valeur maximale configurée, ou avec un Path Vector TLV contenant son propre LSR Id ou qui dépasse la longueur maximale autorisée, alors R détecte que le message Label Request a circulé en boucle.

Lorsque R détecte une boucle, il DOIT (MUST) envoyer un message Notification Loop Detected à la source du message Label Request et abandonner le message Label Request.

2.8.2. Message Label Mapping​

L'utilisation du Path Vector TLV et du Hop Count TLV dans le message Label Mapping fournit un mécanisme pour trouver et terminer les LSP en boucle. Lorsqu'un LSR reçoit un message Label Mapping d'un next hop, le message est propagé en amont comme spécifié ci-dessous jusqu'à ce qu'un LSR ingress soit atteint ou qu'une boucle soit trouvée.

Les règles qui régissent l'utilisation du Hop Count TLV dans les messages Label Mapping envoyés par un LSR R lorsque la détection de boucles est activée sont les suivantes :

  • R DOIT (MUST) inclure un Hop Count TLV.

  • Si R est l'egress, la valeur du nombre de sauts DOIT (MUST) être 1.

  • Si le message Label Mapping est envoyé pour propager vers un pair en amont un message Label Mapping reçu du next hop, la valeur du nombre de sauts DOIT (MUST) être déterminée comme suit :

    o Si R est membre de l'ensemble de bordure d'un domaine de LSR dont les LSR n'effectuent pas de 'TTL-decrement' (par exemple, un domaine de LSR ATM ou un domaine de LSR Frame Relay) et que le pair en amont se trouve dans ce domaine, R DOIT (MUST) réinitialiser le nombre de sauts à 1 avant de propager le message.

    o Sinon, R DOIT (MUST) incrémenter le nombre de sauts reçu du next hop avant de propager le message.

  • Si le message Label Mapping n'est pas envoyé pour propager un message Label Mapping, la valeur du nombre de sauts DOIT (MUST) être le résultat de l'incrémentation de la connaissance actuelle de R du nombre de sauts apprise des messages Label Mapping précédents. Notez que cette valeur de nombre de sauts sera inconnue si R n'a pas reçu de message Label Mapping du next hop.

Tout message Label Mapping PEUT (MAY) contenir un Path Vector TLV. Les règles qui régissent l'utilisation obligatoire du Path Vector TLV dans les messages Label Mapping envoyés par un LSR R lorsque la détection de boucles est activée sont les suivantes :

  • Si R est l'egress, le message Label Mapping n'a pas besoin d'inclure un Path Vector TLV.

  • Si R envoie le message Label Mapping pour propager vers un pair en amont un message Label Mapping reçu du next hop, alors :

    o Si R est capable de fusion et si R n'a pas précédemment envoyé de message Label Mapping au pair en amont, il DOIT (MUST) inclure un Path Vector TLV.

    o Si le message reçu contient un nombre de sauts inconnu, alors R DOIT (MUST) inclure un Path Vector TLV.

    o Si R a précédemment envoyé un message Label Mapping au pair en amont, il DOIT (MUST) inclure un Path Vector TLV si le message reçu rapporte une augmentation du nombre de sauts du LSP, un passage du nombre de sauts d'inconnu à connu, ou un passage de connu à inconnu.

Si les règles ci-dessus exigent que R inclue un Path Vector TLV dans le message Label Mapping, R le calcule comme suit :

o Si le message Label Mapping reçu incluait un Path Vector, le Path Vector envoyé en amont DOIT (MUST) être le résultat de l'ajout du LSR Id de R au Path Vector reçu.

o Si le message reçu n'avait pas de Path Vector, le Path Vector envoyé en amont DOIT (MUST) être un Path Vector de longueur 1 contenant le LSR Id de R.

  • Si le message Label Mapping n'est pas envoyé pour propager en amont un message reçu, le message Label Mapping DOIT (MUST) inclure un Path Vector de longueur 1 contenant le LSR Id de R.

    Si R reçoit un message Label Mapping de son next hop avec un Hop Count TLV qui dépasse la valeur maximale configurée, ou avec un Path Vector TLV contenant son propre LSR Id ou qui dépasse la longueur maximale autorisée, alors R détecte que le LSP correspondant contient une boucle.

    Lorsque R détecte une boucle, il DOIT (MUST) cesser d'utiliser l'étiquette pour le transfert, abandonner le message Label Mapping et signaler le statut Loop Detected à la source du message Label Mapping.

2.8.3. Discussion​

Si la détection de boucles est souhaitée dans un domaine MPLS, elle devrait être activée dans TOUS les LSR de ce domaine MPLS, sinon la détection de boucles ne fonctionnera pas correctement et pourra entraîner des boucles non détectées ou des boucles détectées à tort.

Les LSR configurés pour la détection de boucles NE sont PAS censés stocker les Path Vectors dans le cadre de l'état du LSP.

Notez que, dans un réseau où seuls des LSR incapables de fusion sont présents, les Path Vectors sont transmis en aval de l'ingress vers l'egress, et ne sont pas transmis en amont. Même lorsque la fusion est prise en charge, les Path Vectors n'ont pas besoin d'être transmis en amont le long d'un LSP connu pour atteindre l'egress. Lorsqu'un LSR connaît un changement de next hop, il n'a besoin de transmettre des Path Vectors en amont que lorsqu'il ne peut pas déduire du nombre de sauts que le changement de next hop n'entraîne pas de boucle.

Dans le cas d'une distribution d'étiquettes ordonnée, les messages Label Mapping sont propagés de l'egress vers l'ingress, créant naturellement le Path Vector au passage. Dans le cas d'une distribution d'étiquettes indépendante, un LSR peut émettre un message Label Mapping pour une FEC avant de recevoir un message Label Mapping de son pair en aval pour cette FEC. Dans ce cas, le message Label Mapping ultérieur pour la FEC reçu du pair en aval est traité comme une mise à jour des attributs du LSP, et le message Label Mapping doit être propagé en amont. Ainsi, il est recommandé de configurer la détection de boucles conjointement avec une distribution d'étiquettes ordonnée, afin de minimiser le nombre de messages de mise à jour Label Mapping.

2.9. Authenticité et intégrité des messages LDP​

Cette section spécifie un mécanisme pour se 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 (MUST) être prise en charge comme option configurable.

Le mécanisme est fondé sur l'utilisation du TCP MD5 Signature Option spécifié dans [RFC2385] pour l'usage de BGP [RFC4271]. Voir [RFC1321] pour une spécification de la fonction de hachage MD5. Du point de vue de la maturité des normes, le présent document se rapporte à [RFC2385] de la même manière que [RFC4271] se rapporte à [RFC2385]. Ceci est expliqué dans [RFC4278].

2.9.1. TCP MD5 Signature Option​

Les citations suivantes de [RFC2385] décrivent les propriétés de sécurité obtenues par l'utilisation du TCP MD5 Signature Option et résument son fonctionnement :

"Note de l'IESG (IESG Note)

  Ce document décrit la pratique existante actuelle pour protéger
  BGP contre certaines attaques simples. Il est entendu qu'elle
  présente des faiblesses de sécurité face à des attaques
  concertées."

"Résumé (Abstract)

  Ce mémo décrit une extension de TCP visant à renforcer la
  sécurité de BGP. Il définit une nouvelle option TCP destinée à
  transporter un condensé MD5 [RFC1321] dans un segment TCP. Ce
  condensé agit comme une signature pour ce segment, en y
  incorporant des informations connues uniquement des points
  d'extrémité de la connexion. Comme BGP utilise TCP comme
  transport, l'utilisation de cette option de la manière décrite
  dans ce document réduit sensiblement le danger de certaines
  attaques de sécurité contre BGP."

"Introduction (Introduction)

  La motivation première de cette option est de permettre à BGP
  de se protéger contre l'introduction de segments TCP usurpés
  dans le flux de connexion. Les réinitialisations (reset) TCP
  sont particulièrement préoccupantes.

  Pour usurper une connexion au moyen du schéma décrit dans ce
  document, un attaquant devrait non seulement deviner les numéros
  de séquence TCP, mais aussi avoir obtenu le mot de passe inclus
  dans le condensé 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 connexion particulière, pour autant que ce changement soit
  synchronisé aux deux extrémités (bien que la retransmission
  puisse devenir problématique dans certaines implémentations TCP
  lorsque les mots de passe changent).

  Enfin, il n'y a pas de négociation pour l'utilisation de cette
  option dans une connexion ; son emploi ou non relève purement de
  la politique du site."

"MD5 comme algorithme de hachage (MD5 as a Hashing Algorithm)

  Depuis la première publication de ce mémo (sous un autre titre),
  l'algorithme MD5 a été jugé vulnérable aux attaques par
  recherche de collision [Dobb], et est considéré par certains
  comme insuffisamment robuste pour ce type d'application.

  Ce mémo spécifie toutefois encore l'algorithme MD5, puisque
  l'option a déjà été déployée en exploitation et qu'aucun champ
  "type d'algorithme" n'a été défini pour permettre une mise à
  niveau en utilisant le même numéro d'option. Le document
  d'origine ne spécifiait pas de champ de type, car cela aurait
  requis au moins un octet de plus, et l'on estimait à l'époque
  que consacrer 19 octets à l'option complète (qui serait
  probablement complétée à 20 octets dans les implémentations TCP)
  constituerait un gaspillage excessif de l'espace d'options déjà
  limité.

  Cela n'empêche pas le déploiement d'une autre option similaire
  utilisant un autre algorithme de hachage (comme SHA-1). De plus,
  si la plupart des implémentations complètent de toute façon
  l'option de 18 octets telle que définie à 20 octets, il serait
  tout aussi pertinent de définir une nouvelle option contenant un
  champ de type d'algorithme.

  Cela devrait toutefois être traité dans un autre document."

Fin des citations de [RFC2385].

2.9.2. Utilisation de TCP MD5 Signature Option par LDP​

LDP utilise le TCP MD5 Signature Option comme suit :

  • L'utilisation du MD5 Signature Option pour les connexions TCP LDP est une option configurable du LSR.

  • Un LSR qui utilise le MD5 Signature Option est configuré avec un mot de passe (secret partagé) pour chaque pair LDP potentiel.

  • Le LSR applique l'algorithme MD5 comme spécifié dans [RFC2385] pour calculer le condensé MD5 d'un segment TCP à envoyer à un pair. Ce calcul utilise le mot de passe du pair ainsi que le segment TCP.

  • Lorsque le LSR reçoit un segment TCP muni d'un condensé MD5, il valide le segment en calculant le condensé MD5 (au moyen de son propre enregistrement du mot de passe) et compare le condensé calculé avec le condensé reçu. Si la comparaison échoue, le segment est abandonné sans aucune réponse à l'émetteur.

  • Le LSR ignore les LDP Hellos de tout LSR pour lequel un mot de passe n'a pas été configuré. Cela garantit que le LSR n'établit de connexions TCP LDP qu'avec des LSR pour lesquels un mot de passe a été configuré.

2.10. Distribution d'étiquettes pour les LSP à routage explicite​

L'ingénierie de trafic (Traffic Engineering) [RFC2702] devrait être une application MPLS importante. La prise en charge de l'ingénierie de trafic par MPLS utilise des LSP à routage explicite, qui n'ont pas besoin de suivre les chemins routés normalement (saut par saut) tels que déterminés par les protocoles de routage fondés sur la destination. CR-LDP [CRLDP] définit des extensions de LDP permettant d'utiliser LDP pour établir des LSP à routage explicite.