A.1. Traitement des événements de distribution d'étiquettes

Cette section définit les procédures de distribution d'étiquettes LDP en spécifiant un algorithme pour chaque événement de distribution d'étiquettes. L'exigence imposée à une implémentation LDP est que son traitement des événements doive avoir l'effet spécifié par les algorithmes. Autrement dit, une implémentation n'a pas besoin de suivre exactement les étapes spécifiées par les algorithmes, tant que l'effet est identique.

Les algorithmes de traitement des événements de distribution d'étiquettes partagent des actions communes. Les spécifications ci-dessous regroupent ces actions communes en unités de procédure. Les spécifications de ces procédures communes se trouvent dans leur propre section, "Common Label Distribution Procedures", qui suit celle-ci.

Une implémentation utiliserait des structures de données pour stocker les informations relatives à l'activité du protocole. Cet annexe spécifie les informations à stocker avec un niveau de détail suffisant pour décrire les algorithmes, et suppose la capacité de récupérer ces informations selon les besoins. Elle ne spécifie pas les détails des structures de données.

A.1.1. Réception d'un Label Request

Résumé :

La réponse d'un LSR à la réception d'une demande d'étiquette pour une FEC de la part d'un pair LDP peut impliquer une ou plusieurs des actions suivantes :

• La transmission au LSR demandeur d'un message de notification indiquant pourquoi un mappage d'étiquettes pour la FEC ne peut pas être fourni ;

• La transmission au LSR demandeur d'un mappage d'étiquettes pour la FEC ;

• La transmission d'une demande d'étiquette pour la FEC au next hop de la FEC ;

• L'installation d'étiquettes pour un usage de transfert/commutation par le LSR.

Contexte :

• LSR. Le LSR qui traite l'événement.

• MsgSource. Le pair LDP qui a envoyé le message.

• FEC. La FEC spécifiée dans le message.

• RAttributes. Attributs reçus avec le message, par exemple Hop Count, Path Vector.

• SAttributes. Attributs à inclure dans le message Label Request, le cas échéant, propagé vers le FEC Next Hop.

• StoredHopCount. Le nombre de sauts, le cas échéant, précédemment enregistré pour la FEC.

Algorithme :

   LRq.1   Exécuter la procédure Check_Received_Attributes (MsgSource,
           LabelRequest, RAttributes).
           Si Loop Detected, aller à LRq.4.

   LRq.2   Existe-t-il un Next Hop pour la FEC ?
           Si non, aller à LRq.5.

   LRq.3   MsgSource est-il le Next Hop ?
           Si non, aller à LRq.6.

   LRq.4   Exécuter la procédure Send_Notification (MsgSource, Loop
           Detected).
           Aller à LRq.13

   LRq.5   Exécuter la procédure Send_Notification (MsgSource, No Route).
           Aller à LRq.13.

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

   LRq.7   La demande d'étiquette est-elle une demande en double ?
           Si oui, aller à LRq.13. (Voir Note 2.)

   LRq.8   Enregistrer la demande d'étiquette pour la FEC reçue de
           MsgSource et la marquer comme en attente (pending).

   LRq.9   Exécuter la procédure de distribution d'étiquettes du LSR :

         Pour Downstream Unsolicited Independent Control OU Pour
         Downstream On Demand Independent Control

            1. Le LSR a-t-il précédemment reçu et conservé un mappage
               d'étiquettes pour la FEC de la part du Next Hop ?
               Si oui, mettre Propagating à IsPropagating.
               Si non, mettre Propagating à NotPropagating.

            2. Exécuter la procédure
               Prepare_Label_Mapping_Attributes(MsgSource, FEC,
               RAttributes, SAttributes, Propagating,
               StoredHopCount).

            3. Exécuter la procédure Send_Label (MsgSource, FEC,
               SAttributes).

            4. Le LSR est-il l'egress pour la FEC ? OU Le LSR a-t-il
               précédemment reçu et conservé un mappage d'étiquettes
               pour la FEC de la part du Next Hop ?
               Si oui, aller à LRq.11.
               Si non, aller à LRq.10.

            Pour Downstream Unsolicited Ordered Control OU Pour
            Downstream On Demand Ordered Control

            1. Le LSR est-il l'egress pour la FEC ? OU Le LSR a-t-il
               précédemment reçu et conservé un mappage d'étiquettes
               pour la FEC de la part du Next Hop ?
               (Voir Note 3.)
               Si non, aller à LRq.10.

            2. Exécuter la procédure
               Prepare_Label_Mapping_Attributes(MsgSource, FEC,
               RAttributes, SAttributes, IsPropagating,
               StoredHopCount)

            3. Exécuter la procédure Send_Label (MsgSource, FEC,
               SAttributes).
               Aller à LRq.11.

   LRq.10  Exécuter la procédure de demande d'étiquettes du LSR :

      Pour Request Never

               1. Aller à LRq.13.

      Pour Request When Needed OU
      Pour Request On Request

            1.  Exécuter la procédure Prepare_Label_Request_Attributes
               (Next Hop, FEC, RAttributes, SAttributes);

            2. Exécuter la procédure Send_Label_Request (Next Hop, FEC,
               SAttributes).
               Aller à LRq.13.

   LRq.11  Le LSR a-t-il envoyé avec succès une étiquette pour la FEC à
           MsgSource ?
           Si non, aller à LRq.13. (Voir Note 4.)

   LRq.12  Exécuter la procédure d'utilisation d'étiquettes du LSR.

           Pour Use Immediate OU Pour Use If Loop Not Detected

            1. Installer l'étiquette envoyée à MsgSource et l'étiquette
               provenant du Next Hop (si le LSR n'est pas l'egress) pour
               un usage de transfert/commutation.

   LRq.13  FIN.

Notes :

  1. Dans le cas où MsgSource est un LSR qui ne fusionne pas les
     étiquettes, il enverra une demande d'étiquette pour chaque pair
     LDP en amont qui lui a demandé une étiquette pour la FEC. Le LSR
     doit pouvoir distinguer de telles demandes, provenant d'un
     MsgSource qui ne fusionne pas les étiquettes, des demandes
     d'étiquettes en double.

     Le LSR utilise le message ID des messages Label Request reçus
     pour détecter les demandes en double. Cela signifie qu'un LSR (le
     pair en amont) ne peut pas réutiliser le message ID utilisé pour
     un Label Request avant que la transaction Label Request ne soit
     terminée.

  2. Lorsqu'un LSR envoie une demande d'étiquette à un pair, il
     enregistre que la demande a été envoyée et la marque comme en
     cours (outstanding). Tant que la demande est marquée comme en
     cours, le LSR NE DEVRAIT PAS (SHOULD NOT) envoyer une autre
     demande pour la même étiquette au pair. Une telle seconde demande
     serait un doublon. La procédure Send_Label_Request décrite
     ci-dessous obéit à cette règle.

     Une demande d'étiquette en double est considérée comme une erreur
     de protocole et DEVRAIT (SHOULD) être abandonnée par le LSR
     récepteur (éventuellement avec une notification appropriée
     renvoyée à MsgSource).

  3. Si le LSR n'est pas capable de fusion, ce test échouera.

  4. La procédure Send_Label peut échouer par manque de ressources
     d'étiquettes, auquel cas le LSR NE DEVRAIT PAS (SHOULD NOT)
     exécuter la procédure d'utilisation d'étiquettes.

A.1.2. Réception d'un Label Mapping

Résumé :

La réponse d'un LSR à la réception d'un mappage d'étiquettes pour une FEC de la part d'un pair LDP peut impliquer une ou plusieurs des actions suivantes :

• La transmission au pair LDP d'un message Label Release pour l'étiquette de la FEC ;

• La transmission de messages Label Mapping pour la FEC à un ou plusieurs pairs LDP ;

• L'installation de l'étiquette nouvellement apprise pour un usage de transfert/commutation par le LSR.

Contexte :

• LSR. Le LSR qui traite l'événement.

• MsgSource. Le pair LDP qui a envoyé le message.

• FEC. La FEC spécifiée dans le message.

• Label. L'étiquette spécifiée dans le message.

• PrevAdvLabel. L'étiquette pour la FEC, le cas échéant, précédemment annoncée à un pair en amont. En supposant qu'aucune étiquette n'ait été précédemment annoncée, il s'agit de la même étiquette que celle du message Label Mapping en cours de traitement.

• StoredHopCount. Le nombre de sauts précédemment enregistré pour la FEC.

• RAttributes. Attributs reçus avec le message, par exemple Hop Count, Path Vector.

• SAttributes à inclure dans le message Label Mapping, le cas échéant, propagé vers les pairs en amont.

Algorithme :

   LMp.1   Le mappage d'étiquettes reçu correspond-il à une demande
           d'étiquette en cours pour la FEC précédemment envoyée à
           MsgSource ? Si non, aller à LMp.3.

   LMp.2   Supprimer l'enregistrement de la demande d'étiquette en cours
           pour la FEC.

   LMp.3   Exécuter la procédure Check_Received_Attributes (MsgSource,
           LabelMapping, RAttributes).
           Si No Loop Detected, aller à LMp.9.

   LMp.4   Le LSR a-t-il un mappage d'étiquettes pour la FEC
           précédemment reçu de MsgSource ? (Voir Note 1.)
           Si non, aller à LMp.8. (Voir Note 2.)

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

           LMp.6   Supprimer le mappage d'étiquettes correspondant pour
           la FEC précédemment reçu de MsgSource.

   LMp.7   Retirer Label de l'usage de transfert/commutation. (Voir
           Note 5.)

   LMp.8   Exécuter la procédure Send_Message (MsgSource, Label Release,
           FEC, Label, Loop Detected Status code). Aller à LMp.33.

   LMp.9   Le LSR a-t-il un mappage d'étiquettes pour la FEC
           précédemment reçu de MsgSource pour le LSP en question ?
           (Voir Note 6.)
           Si non, aller à LMp.11.

   LMp.10  L'étiquette précédemment reçue de MsgSource correspond-elle à
           Label (c'est-à-dire l'étiquette reçue dans le message) ?
           (Voir Note 3.)
           OU
           Le mappage d'étiquettes reçu est-il en réponse à une demande
           d'étiquette en cours précédemment envoyée à MsgSource ?
           (Voir Note 12.)
           Si oui, aller à LMp.11.

   LMp.10a Le LSR fonctionne-t-il en mode Downstream Unsolicited ? Si
           oui, supprimer le mappage d'étiquettes correspondant à
           l'étiquette précédemment reçue de MsgSource et le retirer de
           l'usage de transfert/commutation.
           Exécuter la procédure Send_Message (MsgSource, Label Release,
           FEC, label précédemment reçu de MsgSource).

   LMp.11  Déterminer le Next Hop pour la FEC.

   LMp.12  MsgSource est-il le Next Hop pour la FEC ?
           Si oui, aller à LMp.14.

   LMp.13  Exécuter la procédure de libération d'étiquettes du LSR :

                 Pour Conservative Label retention :

                    1. Aller à LMp.32.

                 Pour Liberal Label retention :

                    1. Enregistrer que le mappage d'étiquettes pour la
                       FEC avec Label et RAttributes a été reçu de
                       MsgSource. Aller à LMp.33.

   LMp.14  Le LSR est-il un ingress pour la FEC ?
           Si non, aller à LMp.16.

   LMp.15  Installer Label pour un usage de transfert/commutation.

   LMp.16  Enregistrer que le mappage d'étiquettes pour la FEC avec
           Label et RAttributes a été reçu de MsgSource.

   LMp.17  Itérer de LMp.18 à LMp.31 pour chaque Peer. (Voir Note 7.)

   LMp.18  Le LSR a-t-il précédemment envoyé un mappage d'étiquettes
           pour la FEC au Peer pour le LSP en question ? (Voir Note 8.)
           Si oui, aller à LMp.22.

   LMp.19  La procédure de distribution d'étiquettes Downstream
           Unsolicited Ordered Control est-elle utilisée par le LSR ?
           Si non, aller à LMp.28.

   LMp.20  Exécuter la procédure Prepare_Label_Mapping_Attributes (Peer,
           FEC, RAttributes, SAttributes, IsPropagating,
           StoredHopCount).

   LMp.21  Exécuter la procédure Send_Message (Peer, Label Mapping, FEC,
           PrevAdvLabel, SAttributes). (Voir Note 13.)
           Aller à LMp.28.

   LMp.22  Itérer de LMp.23 à LMp.27 pour chaque mappage d'étiquettes
           pour la FEC précédemment envoyé au Peer.

   LMp.23  Les RAttributes du mappage d'étiquettes reçu sont-ils
           cohérents avec ceux précédemment envoyés au Peer ? Si oui,
           poursuivre l'itération depuis LMp.22 pour le mappage
           d'étiquettes suivant. (Voir Note 9.)

   LMp.24  Exécuter la procédure Prepare_Label_Mapping_Attributes (Peer,
           FEC, RAttributes, SAttributes, IsPropagating,
           StoredHopCount).

   LMp.25  Exécuter la procédure Send_Message (Peer, Label Mapping, FEC,
           PrevAdvLabel, SAttributes). (Voir Note 10.)

   LMp.26  Mettre à jour l'enregistrement du mappage d'étiquettes pour
           la FEC précédemment envoyé au Peer afin d'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'étiquettes pour la FEC de la
           part du Peer marquées comme en attente ?
           Si non, aller à LMp.30.

   LMp.29  Exécuter la procédure de distribution d'étiquettes du LSR :

         Pour Downstream Unsolicited Independent Control OU Pour
         Downstream Unsolicited Ordered Control

            1. Exécuter la procédure
               Prepare_Label_Mapping_Attributes (Peer, FEC,
               RAttributes, SAttributes, IsPropagating,
               UnknownHopCount).

            2. Exécuter la procédure Send_Label (Peer, FEC, SAttributes).
               Si la procédure échoue, poursuivre l'itération pour le
               Peer suivant à LMp.17.

            3. S'il n'existe aucune demande en attente pour le Peer,
               aller à LMp.30. (Voir Note 11.)

         Pour Downstream On Demand Independent Control OU Pour
         Downstream On Demand Ordered Control

            1. Itérer de l'étape 2 à l'étape 5 pour chaque demande
               d'étiquette en attente pour la FEC de la part du Peer
               marquée comme en attente.

            2. Exécuter la procédure
               Prepare_Label_Mapping_Attributes (Peer, FEC,
               RAttributes, SAttributes, IsPropagating,
               UnknownHopCount)

            3. Exécuter la procédure Send_Label (Peer, FEC, SAttributes).
               Si la procédure échoue, poursuivre l'itération pour le
               Peer suivant à LMp.17.

            4. Supprimer l'enregistrement de la demande en attente.

            5. Fin de l'itération depuis l'étape 1.

            6. Aller à LMp.30.

   LMp.30  Exécuter la procédure d'utilisation d'étiquettes du LSR :

         Pour Use Immediate OU Pour Use If Loop Not Detected

            1. Itérer de l'étape 2 à l'étape 3 pour chaque mappage
               d'étiquettes pour la FEC précédemment envoyé au Peer.

            2. Installer l'étiquette reçue et l'étiquette envoyée au
               Peer pour un usage de transfert/commutation.

            3. Fin de 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, Label Release,
           FEC, Label).

   LMp.33  FIN.

Notes :

1. Si le LSR fusionne, il devrait y avoir au plus 1 mappage reçu pour la FEC pour le LSP en question. Dans le cas où il ne fusionne pas, il pourrait y avoir plusieurs mappages reçus pour la FEC pour le LSP en question.

2. Si le LSR a détecté une boucle et qu'il n'a pas précédemment reçu de mappage d'étiquettes de MsgSource pour la FEC, il libère simplement l'étiquette.

3. L'étiquette reçue dans le message correspond-elle à l'un des 1 ou plusieurs mappages d'étiquettes identifiés à l'étape précédente (LMp.4 ou LMp.9) ?

4. Un mappage non sollicité portant une étiquette différente de la part du même pair serait une tentative d'établir une commutation d'étiquettes à chemins multiples, qui n'est pas prise en charge dans cette version de LDP.

5. Si Label n'est pas en usage de transfert/commutation, LMp.7 n'a aucun effet.

6. Si le message Label Mapping reçu correspondait à une demande d'étiquette en cours à LMp.1, alors (par définition) le LSR n'a pas précédemment reçu de mappage d'étiquettes pour la FEC pour le LSP en question. Si le LSR fusionne les étiquettes en amont pour le LSP en question, il devrait y avoir au plus 1 mappage reçu. Dans le cas où il ne fusionne pas, il pourrait y avoir plusieurs mappages d'étiquettes reçus pour la même FEC, un pour chaque LSP résultant.

7. L'itération LMp.17 inclut MsgSource afin de traiter le cas où le LSR fonctionne en mode Downstream Unsolicited Ordered Control. Le contrôle ordonné empêche le LSR d'annoncer une étiquette pour la FEC jusqu'à ce qu'il ait reçu un mappage d'étiquettes de son next hop (MsgSource) pour la FEC.

8. Si le LSR fusionne le LSP, il peut avoir précédemment envoyé des mappages d'étiquettes pour le LSP de la FEC à un ou plusieurs pairs. Si le LSR ne fusionne pas, il peut avoir envoyé un mappage d'étiquettes pour le LSP en question à au plus un LSR.

9. L'attribut Loop Detection Path Vector est pris en compte dans cette vérification. Si les RAttributes reçus incluent un Path Vector et qu'aucun Path Vector n'avait été précédemment envoyé au Peer, ou si le Path Vector reçu est incohérent avec le Path Vector précédemment envoyé au Peer, alors les attributs sont considérés comme incohérents. Notez qu'un LSR n'est pas tenu de stocker un Path Vector reçu après avoir propagé le Path Vector dans un message de mappage. Si un LSR ne stocke pas le Path Vector, il n'a aucun moyen de vérifier la cohérence d'un Path Vector nouvellement reçu. Cela signifie que chaque fois qu'un tel LSR reçoit un message de mappage portant un Path Vector, il doit toujours propager le Path Vector.

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 un mappage du pair en aval après avoir envoyé un mappage à un pair en amont. Dans cette situation, le LSR doit propager en amont tout attribut modifié, tel que le Hop Count. Si la détection de boucles est configurée, les attributs propagés doivent inclure le Path Vector.

11. Un LSR fonctionnant en mode Downstream Unsolicited DOIT (MUST) traiter tout message Label Request qu'il reçoit. S'il existe des demandes d'étiquettes en attente, il enchaîne avec les procédures Downstream on Demand afin de satisfaire les demandes en attente.

12. Tel que déterminé à l'étape LMp.1.

13. Un LSR fonctionnant en mode Ordered Control peut choisir, à ce stade, de ne pas tenir compte du pair dont il a reçu l'annonce qui l'a amené à générer le message de mappage d'étiquettes. Cela fournira en effet une forme de split-horizon.

A.1.3. Réception d'un Label Abort Request

Résumé :

Lorsqu'un LSR reçoit un message Label Abort Request d'un pair, il vérifie s'il a déjà répondu à la demande d'étiquette en question. S'il l'a fait, il ignore silencieusement le message. S'il ne l'a pas fait, il envoie au pair une Notification Label Request Aborted. En outre, s'il a une demande d'étiquette en cours pour le LSP en question vers un pair en aval, il envoie un Label Abort Request au pair en aval pour abandonner le LSP.

Contexte :

• LSR. Le LSR qui traite l'événement.

• MsgSource. Le pair LDP qui a envoyé le message.

• FEC. La FEC spécifiée dans le message.

• RequestMessageID. Le message ID du message de demande d'étiquette à abandonner.

• Next Hop. Le next hop pour la FEC.

Algorithme :

   LAbR.1  Le message correspond-il à un message Label Request précédemment
           reçu de MsgSource ? (Voir Note 1.)
           Si non, aller à LAbR.12.

   LAbR.2  Le LSR a-t-il répondu à la demande d'étiquette précédemment
           reçue ?
           Si oui, aller à LAbR.12.

   LAbR.3  Exécuter la procédure Send_Message (MsgSource, Notification,
           Label Request Aborted, TLV), où TLV est le Label Request
           Message ID TLV reçu dans le message Label Abort Request.

   LAbR.4  Le LSR a-t-il un message Label Request en cours pour la FEC ?
           Si oui, aller à LAbR.7.

   LAbR.5  Le LSR a-t-il un mappage d'étiquettes pour la FEC ? Si non,
           aller à LAbR.11.

   LAbR.6  Générer l'événement : Received Label Release message pour la
           FEC de la part de MsgSource. (Voir Note 2.)
           Aller à LAbR.11.

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

   LAbR.8  Existe-t-il des demandes d'étiquettes en cours pour cette FEC ?
           Si oui, aller à LAbR.11.

   LAbR.9  Exécuter la procédure Send_Message (Next Hop, Label Abort
           Request, FEC, TLV), où TLV est un Label Request message ID TLV
           contenant le Message ID utilisé par le LSR dans le message
           Label Request en cours.

   LAbR.10 Enregistrer qu'une demande d'abandon d'étiquette pour la FEC
           est en attente.

   LAbR.11 Supprimer l'enregistrement de la demande d'étiquette pour la
           FEC de la part de MsgSource.

   LAbR.12 FIN.

Notes :

1. Le LSR utilise la FEC et le Label Request message ID TLV transporté par la demande d'abandon d'étiquette pour localiser son enregistrement (s'il existe) de la demande d'étiquette précédemment reçue de MsgSource.

2. Si le LSR a reçu un mappage d'étiquettes de NextHop, il devrait se comporter comme s'il avait annoncé un mappage d'étiquettes à MsgSource et que MsgSource l'avait libéré.

A.1.4. Réception d'un Label Release

Résumé :

Lorsqu'un LSR reçoit un message Label Release pour une FEC de la part d'un pair, il vérifie si d'autres pairs détiennent l'étiquette libérée. Si aucun ne le fait, le LSR retire l'étiquette de l'usage de transfert/commutation, s'il ne l'a pas déjà fait, et si le LSR détient un mappage d'étiquettes provenant du next hop de la FEC, il libère le mappage d'étiquettes.

Contexte :

• LSR. Le LSR qui traite l'événement.

• MsgSource. Le pair LDP qui a envoyé le message.

• Label. 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 MsgSource de l'enregistrement des pairs qui détiennent
           Label pour la FEC. (Voir Note 1.)

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

   LRl.4   Supprimer l'enregistrement du retrait d'étiquette en cours
           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'étiquettes en cours pour cette
           FEC ?
           Si oui, aller à LRl.11.

   LRl.7   Le LSR est-il l'egress pour la FEC ?
           Si oui, aller à LRl.11.

   LRl.8   Existe-t-il un Next Hop pour la FEC ? ET Le LSR a-t-il un
           mappage d'étiquettes pour la FEC précédemment reçu du Next
           Hop ?
           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 (Next Hop, Label Release,
           FEC, Label provenant du Next Hop).

   LRl.11  Retirer Label de l'usage de transfert/commutation pour le
           trafic en provenance de MsgSource.

   LRl.12  Des pairs détiennent-ils encore Label pour la FEC ?
           Si oui, aller à LRl.14.

   LRl.13  Libérer la Label.

   LRl.14  FIN.

Notes :

1. Si le LSR utilise la distribution d'étiquettes Downstream Unsolicited, il NE DEVRAIT PAS (SHOULD NOT) ré-annoncer un mappage d'étiquettes pour la FEC à MsgSource avant que MsgSource ne le demande.

2. LRl.5 à LRl.9 traitent de la détermination de l'endroit où le LSR devrait propager le Label Release vers un pair en aval (LRl.9).

3. Si LRl.9 est atteint, aucun LSR en amont ne détient d'étiquette pour la FEC, et le LSR détient une étiquette pour la FEC provenant du FEC Next Hop. Le LSR pourrait propager le Label Release vers le Next Hop. En propageant le Label Release, le LSR libère une ressource d'étiquettes potentiellement rare. Ce faisant, il augmente également la latence de rétablissement du LSP si MsgSource ou un autre LSR en amont lui envoie une nouvelle demande Label Request pour la FEC.

   Le choix de propager ou non la libération n'est pas une question de protocole. La distribution d'étiquettes fonctionnera correctement, que la libération soit propagée ou non. La décision de propager ou non devrait prendre en compte des facteurs tels que : le fait que les étiquettes soient ou non une ressource rare dans l'environnement d'exploitation, l'importance de maintenir une faible latence d'établissement du LSP en gardant petit le volume de signalisation requise, et le fait que l'établissement du LSP soit contrôlé par l'ingress ou par l'egress dans l'environnement d'exploitation.

A.1.5. Réception d'un Label Withdraw

Résumé :

Lorsqu'un LSR reçoit un message Label Withdraw pour une FEC de la part d'un pair LDP, il répond par un message Label Release et il retire l'étiquette de tout usage de transfert/commutation. Si le contrôle ordonné (Ordered Control) est utilisé, le LSR envoie un message Label Withdraw à chaque pair LDP auquel il a précédemment envoyé un mappage d'étiquettes pour la FEC. Si le LSR utilise l'annonce d'étiquettes Downstream on Demand avec contrôle indépendant, il agit alors comme s'il venait de reconnaître la FEC.

Contexte :

• LSR. Le LSR qui traite l'événement.

• MsgSource. Le pair LDP qui a envoyé le message.

• Label. L'étiquette spécifiée dans le message.

• FEC. La FEC spécifiée dans le message.

Algorithme :

   LWd.1   Retirer Label de l'usage de transfert/commutation. (Voir
           Note 1.)

   LWd.2   Exécuter la procédure Send_Message (MsgSource, Label Release,
           FEC, Label).

   LWd.3   Le LSR a-t-il précédemment reçu et conservé un mappage
           d'étiquettes correspondant pour la FEC de la part de
           MsgSource ?
           Si non, aller à LWd.13.

   LWd.4   Supprimer le mappage d'étiquettes correspondant pour la FEC
           précédemment reçu de MsgSource.

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

   LWd.6   MsgSource utilise-t-il l'annonce d'étiquettes Downstream On
           Demand ?
           Si non, aller à LWd.13.

   LWd.7   Générer l'événement : Recognize New FEC pour la FEC. Aller à
           LWd.13. (Voir Note 2.)

   LWd.8   Itérer de LWd.9 à LWd.12 pour chaque Peer, autre que
           MsgSource.

   LWd.9   Le LSR a-t-il précédemment envoyé un mappage d'étiquettes pour
           la FEC au Peer ?
           Si non, poursuivre l'itération pour le Peer suivant à LWd.8.

   LWd.10  L'étiquette précédemment envoyée au Peer "mappe"-t-elle à la
           Label retirée ?
           Si non, poursuivre l'itération pour le Peer suivant à LWd.8.
           (Voir Note 3.)

   LWd.11  Exécuter la procédure Send_Label_Withdraw (Peer, FEC, Label
           précédemment envoyée au Peer).

   LWd.12  Fin de l'itération depuis LWd.8.

   LWd.13  FIN.

Notes :

1. Si la Label n'est pas en usage de transfert/commutation, LWd.1 n'a aucun effet.

2. LWd.7 traite le cas où le LSR utilise la distribution d'étiquettes Downstream On Demand avec contrôle indépendant. Dans cette situation, le LSR devrait envoyer une demande d'étiquette au next hop de la FEC comme s'il venait de reconnaître la FEC.

3. LWd.10 traite à la fois les cas de fusion d'étiquettes (une ou plusieurs étiquettes entrantes mappent vers la même étiquette sortante) et d'absence de fusion d'étiquettes (une étiquette mappe vers l'étiquette sortante).

A.1.6. Reconnaissance d'une nouvelle FEC

Résumé :

La réponse d'un LSR à l'apprentissage d'une nouvelle FEC via la table de routage peut impliquer une ou plusieurs des actions suivantes :

• La transmission de mappages d'étiquettes pour la FEC à un ou plusieurs pairs LDP ;

• La transmission d'une demande d'étiquette pour la FEC au next hop de la FEC ;

• L'une quelconque des actions qui peuvent se produire lorsque le LSR reçoit un mappage d'étiquettes pour la FEC de la part du next hop de la FEC.

Contexte :

• LSR. Le LSR qui traite l'événement.

• FEC. La FEC nouvellement reconnue.

• Next Hop. Le next hop pour la FEC.

• InitAttributes. Attributs à associer à la nouvelle FEC. (Voir Note 1.)

• SAttributes. Attributs à inclure dans les messages Label Mapping ou Label Request, le cas échéant, envoyés aux pairs.

• StoredHopCount. Nombre de sauts associé au mappage d'étiquettes de la FEC, le cas échéant, précédemment reçu du Next Hop.

Algorithme :

   FEC.1   Exécuter la procédure de distribution d'étiquettes du LSR :

         Pour Downstream Unsolicited Independent Control

            1. Itérer de l'étape 2 à l'étape 5 pour chaque Peer.

            2. Le LSR a-t-il précédemment reçu et conservé un mappage
               d'étiquettes pour la FEC de la part du Next Hop ?
               Si oui, mettre Propagating à IsPropagating.
               Si non, mettre Propagating à NotPropagating.

            3. Exécuter la procédure Prepare_Label_Mapping_Attributes
               (Peer, FEC, InitAttributes, SAttributes, Propagating,
               Unknown hop count(0)).

            4. Exécuter la procédure Send_Label (Peer, FEC, SAttributes).

            5. Fin de l'itération depuis l'étape 1.
               Aller à FEC.2.

         Pour Downstream Unsolicited Ordered Control

            1. Itérer de l'étape 2 à l'étape 5 pour chaque Peer.

            2. Le LSR est-il l'egress pour la FEC ? OU Le LSR a-t-il
               précédemment reçu et conservé un mappage d'étiquettes
               pour la FEC de la part du Next Hop ?
               Si non, poursuivre l'itération pour le Peer suivant.

            3. Exécuter la procédure Prepare_Label_Mapping_Attributes
               (Peer, FEC, InitAttributes, SAttributes, Propagating,
               StoredHopCount).

            4. Exécuter la procédure Send_Label (Peer, FEC, SAttributes).

            5. Fin de l'itération depuis l'étape 1.
               Aller à FEC.2.

         Pour Downstream On Demand Independent Control OU
         Pour Downstream On Demand Ordered Control

            1. Aller à FEC.2. (Voir Note 2.)

   FEC.2   Le LSR a-t-il précédemment reçu et conservé un mappage
           d'étiquettes pour la FEC de la part du Next Hop ?
           Si oui, aller à FEC.5

   FEC.3   Le Next Hop est-il un pair LDP ?
           Si non, aller à FEC.6

   FEC.4   Exécuter la procédure de demande d'étiquettes du LSR :

         Pour Request Never

            1. Aller à FEC.6

         Pour Request When Needed OU
         Pour Request On Request

            1. Exécuter la procédure
               Prepare_Label_Request_Attributes (Next Hop, FEC,
               InitAttributes, SAttributes);

            2. Exécuter la procédure Send_Label_Request (Next Hop, FEC,
               SAttributes).
               Aller à FEC.6.

   FEC.5   Générer l'événement : Received Label Mapping de la part du
           Next Hop. (Voir Note 3.)

   FEC.6   FIN.

Notes :

1. Un exemple d'attribut pouvant faire partie des InitAttributes est un attribut qui spécifie les caractéristiques souhaitées du LSP, telles que la Class of Service (CoS). (Notez que, bien que la version actuelle de LDP ne spécifie pas d'attribut CoS, des extensions LDP le pourraient.)

   Le moyen par lequel les FEC InitAttributes, le cas échéant, sont spécifiés dépasse le cadre de LDP. Notez que les InitAttributes n'incluront pas de Hop Count connu ni de Path Vector.

2. Un LSR utilisant la distribution d'étiquettes Downstream On Demand n'enverrait une étiquette que s'il avait une demande d'étiquette précédemment reçue marquée comme en attente. Le LSR n'aurait aucune telle demande en attente, car il répond à toute demande d'étiquette portant sur une FEC inconnue en envoyant au LSR demandeur une notification No Route et en écartant la demande d'étiquette ; voir LRq.3

3. Si le LSR dispose d'une étiquette pour la FEC provenant du Next Hop, il devrait se comporter comme s'il venait de recevoir l'étiquette du Next Hop. Cela se produit dans le cas du mode de rétention d'étiquettes libéral.

A.1.7. Détection d'un changement de next hop d'une FEC

Résumé :

La réponse d'un LSR à un changement de next hop pour une FEC peut impliquer une ou plusieurs des actions suivantes :

• Le retrait, de l'usage de transfert/commutation, de l'étiquette provenant de l'ancien next hop de la FEC ;

• La transmission de messages Label Mapping pour la FEC à un ou plusieurs pairs LDP ;

• La transmission d'une demande d'étiquette au nouveau next hop de la FEC ;

• L'une quelconque des actions qui peuvent se produire lorsque le LSR reçoit un mappage d'étiquettes de la part du nouveau next hop de la FEC.

Contexte :

• LSR. Le LSR qui traite l'événement.

• FEC. La FEC dont le next hop a changé.

• New Next Hop. Le next hop actuel pour la FEC.

• Old Next Hop. Le next hop précédent pour la FEC.

• OldLabel. L'étiquette, le cas échéant, précédemment reçue de Old Next Hop.

• CurAttributes. Les attributs, le cas échéant, actuellement associés à la FEC.

• SAttributes. Attributs à inclure dans le message Label Request, le cas échéant, envoyé à New Next Hop.

Algorithme :

   NH.1   Le LSR a-t-il précédemment reçu et conservé un mappage
          d'étiquettes pour la FEC de la part de Old Next Hop ? Si non,
          aller à NH.6.

   NH.2   Retirer l'étiquette de l'usage de transfert/commutation.
          (Voir Note 1.)

   NH.3   Le LSR utilise-t-il la Liberal Label retention ?
          Si oui, aller à NH.6.

   NH.4   Exécuter la procédure Send_Message (Old Next Hop, Label
          Release, OldLabel).

   NH.5   Supprimer le mappage d'étiquettes pour la FEC précédemment
          reçu de Old Next Hop.

   NH.6   Le LSR a-t-il une demande d'étiquette en attente auprès de Old
          Next Hop ?
          Si non, aller à NH.10.

   NH.7   Le LSR utilise-t-il la Conservative Label retention ?
          Si non, aller à NH.10.

   NH.8   Exécuter la procédure Send_Message (Old Next Hop, Label Abort
          Request, FEC, TLV), où TLV est un Label Request Message ID TLV
          qui transporte le message ID de la demande d'étiquette en
          attente.

   NH.9   Enregistrer qu'une demande d'abandon d'étiquette est en attente
          pour la FEC auprès de Old Next Hop.

   NH.10  Existe-t-il un New Next Hop pour la FEC ?
          Si non, aller à NH.16.

   NH.11  Le LSR a-t-il précédemment reçu et conservé un mappage
          d'étiquettes pour la FEC de la part de New Next Hop ?
          Si non, aller à NH.13.

   NH.12  Générer l'événement : Received Label Mapping de la part de New
          Next Hop. Aller à NH.20. (Voir Note 2.)

   NH.13  Le LSR utilise-t-il l'annonce Downstream on Demand ? OU Le Next
          Hop utilise-t-il l'annonce Downstream on Demand ? OU Le LSR
          utilise-t-il la Conservative Label retention ? (Voir Note 3.)
          Si oui, aller à NH.14.
          Si non, aller à NH.20.

   NH.14  Exécuter la procédure Prepare_Label_Request_Attributes (Next
          Hop, FEC, CurAttributes, SAttributes).

   NH.15  Exécuter la procédure Send_Label_Request (New Next Hop, FEC,
          SAttributes). (Voir Note 4.)
          Aller à NH.20.

   NH.16  Itérer de NH.17 à NH.19 pour chaque Peer.

   NH.17  Le LSR a-t-il précédemment envoyé un mappage d'étiquettes pour
          la FEC au Peer ?
          Si non, poursuivre l'itération pour le Peer suivant à NH.16.

   NH.18  Exécuter la procédure Send_Label_Withdraw (Peer, FEC, Label
          précédemment envoyée au Peer).

   NH.19  Fin de l'itération depuis NH.16.

   NH.20  FIN.

Notes :

1. Si la Label n'est pas en usage de transfert/commutation, NH.2 n'a aucun effet.

2. Si le LSR dispose d'une étiquette pour la FEC provenant de New Next Hop, il devrait se comporter comme s'il venait de recevoir l'étiquette de New Next Hop.

3. Le but de la vérification du mode de rétention d'étiquettes est d'éviter une course avec les étapes LMp.12-LMp.13 de la procédure de traitement d'un message Label Mapping, où le LSR fonctionnant en mode Conservative Label retention peut avoir libéré un mappage d'étiquettes reçu de New Next Hop avant d'avoir détecté que le next hop de la FEC avait changé.

4. Quel que soit le mode de la procédure de demande d'étiquettes utilisé par le LSR, il DOIT (MUST) envoyer une demande d'étiquette si les conditions de NH.13 sont remplies. Par conséquent, il exécute directement la procédure Send_Label_Request plutôt que d'exécuter la procédure de demande d'étiquettes du LSR.

A.1.8. Réception d'une Notification / Label Request Aborted

Résumé :

Lorsqu'un LSR reçoit une notification Label Request Aborted d'un pair LDP, il enregistre que la transaction de demande d'étiquette correspondante, le cas échéant, est terminée.

Contexte :

• LSR. Le LSR qui traite l'événement.

• FEC. La FEC pour laquelle une étiquette a été demandée.

• RequestMessageID. Le message ID du message de demande d'étiquette à abandonner.

• MsgSource. Le pair LDP qui a envoyé le message Notification.

Algorithme :

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

   LRqA.2  Enregistrer que la demande d'étiquette pour la FEC a été
           abandonnée.

   LRqA.3  FIN.

Note :

1. Le LSR utilise la FEC et le RequestMessageID pour localiser son enregistrement, s'il existe, de l'abandon de demande d'étiquette en cours.

A.1.9. Réception d'une Notification / No Label Resources

Résumé :

Lorsqu'un LSR reçoit une notification No Label Resources d'un pair LDP, il cesse d'envoyer des messages de demande d'étiquette au pair jusqu'à ce qu'il reçoive une Label Resources Available Notification de ce pair.

Contexte :

• LSR. Le LSR qui traite l'événement.

• FEC. La FEC pour laquelle une étiquette a été demandée.

• MsgSource. Le pair LDP qui a envoyé le message Notification.

Algorithme :

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

   NoRes.2 Enregistrer qu'un mappage d'étiquettes pour la FEC de la part
           de MsgSource est nécessaire, mais qu'aucune ressource
           d'étiquettes n'est disponible.

   NoRes.3 Positionner un enregistrement de statut indiquant qu'il n'est
           pas permis d'envoyer des demandes d'étiquette à MsgSource.

   NoRes.4 FIN.

A.1.10. Réception d'une Notification / No Route

Résumé :

Lorsqu'un LSR reçoit une notification No Route d'un pair LDP en réponse à un message Label Request, la procédure Label No Route utilisée dicte sa réponse. Le LSR soit ne prendra aucune mesure supplémentaire, soit différera la demande d'étiquette en démarrant un timer et enverra un autre message Label Request au pair lorsque le timer expirera plus tard.

Contexte :

• LSR. Le LSR qui traite l'événement.

• FEC. La FEC pour laquelle une étiquette a été demandée.

• Attributes. Les attributs associés à la demande d'étiquette.

• MsgSource. Le pair 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  Exécuter la procédure Label No Route du LSR.

         Pour Request No Retry

            1. Aller à NoNH.3.

         Pour Request Retry

            1. Enregistrer la demande d'étiquette différée pour la FEC et
               les Attributes à envoyer à MsgSource.

            2. Démarrer le timer d'expiration. Aller à NoNH.3.

   NoNH.3  FIN.

A.1.11. Réception d'une Notification / Loop Detected

Résumé :

Lorsqu'un LSR reçoit un Status Code Loop Detected d'un pair LDP en réponse à un message Label Request ou à un message Label Mapping, il se comporte comme s'il avait reçu une notification No Route.

Contexte :

Voir "Receive Notification / No Route".

Algorithme :

Voir "Receive Notification / No Route".

Note :

1. Lorsque la notification Loop Detected est en réponse à un message Label Request, elle arrive dans un Status Code TLV d'un message Notification. Lorsqu'elle est en réponse à un message Label Mapping, elle arrive dans un Status Code TLV d'un message Label Release.

A.1.12. Réception d'une Notification / Label Resources Available

Résumé :

Lorsqu'un LSR reçoit une notification Label Resources Available d'un pair LDP, il reprend l'envoi de demandes d'étiquette au pair.

Contexte :

• LSR. Le LSR qui traite l'événement.

• MsgSource. Le pair LDP qui a envoyé le message Notification.

• SAttributes. Attributs stockés avec le message Label Request reporté.

Algorithme :

   Res.1   Positionner un enregistrement de statut indiquant qu'il est
           permis d'envoyer des demandes d'étiquette à MsgSource.

   Res.2   Itérer de Res.3 à Res.6 pour chaque enregistrement d'un
           mappage d'étiquettes de FEC nécessaire de la part de MsgSource
           pour lequel aucune ressource d'étiquettes n'est disponible.

   Res.3   MsgSource est-il le next hop pour la FEC ?
           Si non, aller à Res.5.

   Res.4   Exécuter la procédure Send_Label_Request (MsgSource, FEC,
           SAttributes). Si la procédure échoue, terminer l'itération.

   Res.5   Supprimer l'enregistrement selon lequel aucune ressource n'est
           disponible pour un mappage d'étiquettes de FEC nécessaire de
           la part de MsgSource.

   Res.6   Fin de l'itération depuis Res.2.

   Res.7   FIN.

A.1.13. Détection du fait que des ressources d'étiquettes locales sont devenues disponibles

Résumé :

Après qu'un LSR a envoyé une notification No Label Resources à un pair LDP, lorsque des ressources d'étiquettes deviennent ultérieurement disponibles, il envoie une notification Label Resources Available à chacun de ces pairs.

Contexte :

• LSR. Le LSR qui traite l'événement.

• Attributes. Attributs stockés avec le message Label Mapping reporté.

Algorithme :

   ResA.1  Itérer de ResA.2 à ResA.4 pour chaque Peer auquel le LSR a
           précédemment envoyé une notification No Label Resources.

   ResA.2  Exécuter la procédure Send_Notification (Peer, Label Resources
           Available).

   ResA.3  Supprimer l'enregistrement selon lequel une notification No
           Label Resources a été précédemment envoyée au Peer.

   ResA.4  Fin de l'itération depuis ResA.1.

   ResA.5  Itérer de ResA.6 à ResA.8 pour chaque enregistrement d'un
           mappage d'étiquettes nécessaire pour la FEC pour le Peer mais
           sans ressource d'étiquettes (no-label-resources). (Voir
           Note 1.)

   ResA.6  Exécuter la procédure Send_Label (Peer, FEC, Attributes). Si
           la procédure échoue, terminer l'itération.

   ResA.7  Effacer l'enregistrement du mappage d'étiquettes de FEC
           nécessaire pour le peer mais sans ressource d'étiquettes.

   ResA.8  Fin de l'itération depuis ResA.5

   ResA.9  FIN.

Note :

1. L'itération ResA.5 à ResA.8 traite la situation où le LSR utilise la distribution d'étiquettes Downstream Unsolicited et n'a précédemment pas pu allouer d'étiquette pour une FEC.

A.1.14. Le LSR décide de ne plus commuter d'étiquettes pour une FEC

Résumé :

Un LSR peut décider unilatéralement de ne plus commuter d'étiquettes pour une FEC à l'intention d'un pair LDP. Un LSR qui agit ainsi DOIT (MUST) envoyer un message Label Withdraw pour la FEC au pair.

Contexte :

• Peer. Le pair.

• FEC. La FEC.

• PrevAdvLabel. L'étiquette pour la FEC précédemment annoncée au Peer.

Algorithme :

   NoLS.1  Exécuter la procédure Send_Label_Withdraw (Peer, FEC,
           PrevAdvLabel). (Voir Note 1.)

   NoLS.2  FIN.

Note :

1. Le LSR peut retirer l'étiquette de l'usage de transfert/commutation dans le cadre de cet événement ou dans le cadre du traitement du Label Release provenant du pair en réponse au retrait d'étiquette. Si le LSR n'attend pas le message Label Release du pair, il NE DEVRAIT PAS (SHOULD NOT) réutiliser l'étiquette avant d'avoir reçu le Label Release.

A.1.15. Expiration du délai d'un Label Request différé

Résumé :

Les demandes d'étiquettes sont différées en réponse aux notifications No Route et Loop Detected. Lorsqu'une demande d'étiquette de FEC différée pour un pair expire, le LSR envoie la demande d'étiquette.

Contexte :

• LSR. Le LSR qui traite l'événement.

• FEC. La FEC associée à l'événement d'expiration.

• Peer. Le pair LDP associé à l'événement d'expiration.

• Attributes. Attributs stockés avec le message Label Request différé.

Algorithme :

   TO.1    Récupérer l'enregistrement de la demande d'étiquette différée.

   TO.2    Le Peer est-il le next hop pour la FEC ?
           Si non, aller à TO.4.

   TO.3    Exécuter la procédure Send_Label_Request (Peer, FEC).

   TO.4    FIN.