A.1. Behandlung von Labelverteilungsereignissen

Dieser Abschnitt definiert die LDP-Labelverteilungsverfahren, indem für jedes Labelverteilungsereignis ein Algorithmus angegeben wird. Die Anforderung an eine LDP-Implementierung ist, dass ihre Ereignisbehandlung die durch die Algorithmen angegebene Wirkung haben muss. Das heißt, eine Implementierung muss nicht genau die durch die Algorithmen angegebenen Schritte befolgen, solange die Wirkung identisch ist.

Die Algorithmen zur Behandlung von Labelverteilungsereignissen verwenden gemeinsame Aktionen. Die folgenden Spezifikationen fassen diese gemeinsamen Aktionen zu Prozedureinheiten zusammen. Die Spezifikationen für diese gemeinsamen Prozeduren finden sich in ihrem eigenen Abschnitt, "Common Label Distribution Procedures", der auf diesen folgt.

Eine Implementierung würde Datenstrukturen verwenden, um Informationen über die Protokollaktivität zu speichern. Dieser Anhang gibt die zu speichernden Informationen so detailliert an, dass die Algorithmen beschrieben werden, und setzt die Fähigkeit voraus, die Informationen nach Bedarf abzurufen. Er spezifiziert nicht die Details der Datenstrukturen.

A.1.1. Empfang einer Label Request

Zusammenfassung:

Die Reaktion eines LSR auf den Empfang einer FEC-Label-Anforderung von einem LDP-Peer kann eine oder mehrere der folgenden Aktionen umfassen:

• Übertragung einer Benachrichtigungsnachricht an den anfordernden LSR, die angibt, warum keine Label-Abbildung für die FEC bereitgestellt werden kann;

• Übertragung einer FEC-Label-Abbildung an den anfordernden LSR;

• Übertragung einer FEC-Label-Anforderung an den FEC-Next-Hop;

• Installation von Labels zur Weiterleitungs-/Vermittlungsnutzung durch den LSR.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• MsgSource. Der LDP-Peer, der die Nachricht gesendet hat.

• FEC. Die in der Nachricht angegebene FEC.

• RAttributes. Mit der Nachricht empfangene Attribute, z. B. Hop Count, Path Vector.

• SAttributes. Attribute, die in die Label Request-Nachricht aufzunehmen sind, falls eine an den FEC-Next-Hop weitergegeben wird.

• StoredHopCount. Die gegebenenfalls zuvor für die FEC aufgezeichnete Hop-Zahl.

Algorithmus:

   LRq.1   Prozedur Check_Received_Attributes (MsgSource,
           LabelRequest, RAttributes) ausführen.
           Bei Loop Detected: gehe zu LRq.4.

   LRq.2   Gibt es einen Next Hop für die FEC?
           Wenn nicht, gehe zu LRq.5.

   LRq.3   Ist MsgSource der Next Hop?
           Wenn nicht, gehe zu LRq.6.

   LRq.4   Prozedur Send_Notification (MsgSource, Loop
           Detected) ausführen.
           Gehe zu LRq.13

   LRq.5   Prozedur Send_Notification (MsgSource, No Route) ausführen.
           Gehe zu LRq.13.

   LRq.6   Hat der LSR zuvor eine Label-Anforderung für die FEC von
           MsgSource empfangen?
           Wenn nicht, gehe zu LRq.8. (Siehe Anmerkung 1.)

   LRq.7   Ist die Label-Anforderung eine doppelte Anforderung?
           Wenn ja, gehe zu LRq.13. (Siehe Anmerkung 2.)

   LRq.8   Label-Anforderung für die FEC von MsgSource aufzeichnen und
           als ausstehend (pending) markieren.

   LRq.9   LSR-Labelverteilungsprozedur ausführen:

         Für Downstream Unsolicited Independent Control ODER Für
         Downstream On Demand Independent Control

            1. Hat der LSR zuvor eine Label-Abbildung für die FEC vom
               Next Hop empfangen und beibehalten?
               Wenn ja, Propagating auf IsPropagating setzen.
               Wenn nicht, Propagating auf NotPropagating setzen.

            2. Prozedur
               Prepare_Label_Mapping_Attributes (MsgSource, FEC,
               RAttributes, SAttributes, Propagating,
               StoredHopCount) ausführen.

            3. Prozedur Send_Label (MsgSource, FEC,
               SAttributes) ausführen.

            4. Ist der LSR der Egress für die FEC? ODER Hat der LSR
               zuvor eine Label-Abbildung für die FEC vom Next Hop
               empfangen und beibehalten?
               Wenn ja, gehe zu LRq.11.
               Wenn nicht, gehe zu LRq.10.

            Für Downstream Unsolicited Ordered Control ODER Für
            Downstream On Demand Ordered Control

            1. Ist der LSR der Egress für die FEC? ODER Hat der LSR
               zuvor eine Label-Abbildung für die FEC vom Next Hop
               empfangen und beibehalten?
               (Siehe Anmerkung 3.)
               Wenn nicht, gehe zu LRq.10.

            2. Prozedur
               Prepare_Label_Mapping_Attributes(MsgSource, FEC,
               RAttributes, SAttributes, IsPropagating,
               StoredHopCount) ausführen

            3. Prozedur Send_Label (MsgSource, FEC,
               SAttributes) ausführen.
               Gehe zu LRq.11.

   LRq.10  LSR-Labelanforderungsprozedur ausführen:

      Für Request Never

               1. Gehe zu LRq.13.

      Für Request When Needed ODER
      Für Request On Request

            1.  Prozedur Prepare_Label_Request_Attributes
               (Next Hop, FEC, RAttributes, SAttributes) ausführen;

            2. Prozedur Send_Label_Request (Next Hop, FEC,
               SAttributes) ausführen.
               Gehe zu LRq.13.

   LRq.11  Hat der LSR erfolgreich ein Label für die FEC an MsgSource
           gesendet?
           Wenn nicht, gehe zu LRq.13. (Siehe Anmerkung 4.)

   LRq.12  LSR-Labelverwendungsprozedur ausführen.

           Für Use Immediate ODER Für Use If Loop Not Detected

            1. Das an MsgSource gesendete Label und das Label vom Next
               Hop (falls der LSR nicht der Egress ist) zur
               Weiterleitungs-/Vermittlungsnutzung installieren.

   LRq.13  Fertig (DONE).

Anmerkungen:

1. Im Fall, dass MsgSource ein nicht label-zusammenführender (non-label merging) LSR ist, sendet er für jeden vorgelagerten LDP-Peer, der bei ihm ein Label für die FEC angefordert hat, eine Label-Anforderung. Der LSR muss solche Anforderungen von einem nicht label-zusammenführenden MsgSource von doppelten Label-Anforderungen unterscheiden können.

   Der LSR verwendet die Message ID empfangener Label Request-Nachrichten, um doppelte Anforderungen zu erkennen. Das bedeutet, dass ein LSR (der vorgelagerte Peer) die für eine Label Request verwendete Message ID nicht wiederverwenden darf, bis die Label Request-Transaktion abgeschlossen ist.

2. Wenn ein LSR eine Label-Anforderung an einen Peer sendet, zeichnet er auf, dass die Anforderung gesendet wurde, und markiert sie als ausstehend (outstanding). Solange die Anforderung als ausstehend markiert ist, SOLLTE (SHOULD) der LSR NICHT eine weitere Anforderung für dasselbe Label an den Peer senden. Eine solche zweite Anforderung wäre ein Duplikat. Die unten beschriebene Prozedur Send_Label_Request befolgt diese Regel.

   Eine doppelte Label-Anforderung wird als Protokollfehler angesehen und SOLLTE (SHOULD) vom empfangenden LSR verworfen werden (möglicherweise mit einer geeigneten, an MsgSource zurückgesendeten Benachrichtigung).

3. Wenn der LSR nicht merge-fähig ist, schlägt dieser Test fehl.

4. Die Prozedur Send_Label kann wegen fehlender Label-Ressourcen fehlschlagen; in diesem Fall SOLLTE (SHOULD) der LSR die Labelverwendungsprozedur NICHT durchführen.

A.1.2. Empfang einer Label Mapping

Zusammenfassung:

Die Reaktion eines LSR auf den Empfang einer FEC-Label-Abbildung von einem LDP-Peer kann eine oder mehrere der folgenden Aktionen umfassen:

• Übertragung einer Label Release-Nachricht für das FEC-Label an den LDP-Peer;

• Übertragung von Label Mapping-Nachrichten für die FEC an einen oder mehrere LDP-Peers;

• Installation des neu erlernten Labels zur Weiterleitungs-/Vermittlungsnutzung durch den LSR.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• MsgSource. Der LDP-Peer, der die Nachricht gesendet hat.

• FEC. Die in der Nachricht angegebene FEC.

• Label. Das in der Nachricht angegebene Label.

• PrevAdvLabel. Das Label für die FEC, das gegebenenfalls zuvor einem vorgelagerten Peer angekündigt wurde. Unter der Annahme, dass zuvor kein Label angekündigt wurde, ist dies dasselbe Label wie das in der gerade verarbeiteten Label Mapping-Nachricht.

• StoredHopCount. Die zuvor für die FEC aufgezeichnete Hop-Zahl.

• RAttributes. Mit der Nachricht empfangene Attribute, z. B. Hop Count, Path Vector.

• SAttributes, die in die Label Mapping-Nachricht aufzunehmen sind, falls eine an vorgelagerte Peers weitergegeben wird.

Algorithmus:

   LMp.1   Entspricht die empfangene Label-Abbildung einer ausstehenden
           Label-Anforderung für die FEC, die zuvor an MsgSource
           gesendet wurde? Wenn nicht, gehe zu LMp.3.

   LMp.2   Aufzeichnung der ausstehenden FEC-Label-Anforderung löschen.

   LMp.3   Prozedur Check_Received_Attributes (MsgSource,
           LabelMapping, RAttributes) ausführen.
           Bei No Loop Detected: gehe zu LMp.9.

   LMp.4   Hat der LSR eine zuvor von MsgSource empfangene
           Label-Abbildung für die FEC? (Siehe Anmerkung 1.)
           Wenn nicht, gehe zu LMp.8. (Siehe Anmerkung 2.)

   LMp.5   Entspricht das zuvor von MsgSource empfangene Label dem
           Label (d. h. dem in der Nachricht empfangenen Label)? (Siehe
           Anmerkung 3.)
           Wenn nicht, gehe zu LMp.8. (Siehe Anmerkung 4.)

           LMp.6   Passende Label-Abbildung für die FEC, die zuvor von
           MsgSource empfangen wurde, löschen.

   LMp.7   Label aus der Weiterleitungs-/Vermittlungsnutzung entfernen.
           (Siehe Anmerkung 5.)

   LMp.8   Prozedur Send_Message (MsgSource, Label Release,
           FEC, Label, Loop Detected Status code) ausführen.
           Gehe zu LMp.33.

   LMp.9   Hat der LSR eine zuvor von MsgSource empfangene
           Label-Abbildung für die FEC für die betreffende LSP?
           (Siehe Anmerkung 6.)
           Wenn nicht, gehe zu LMp.11.

   LMp.10  Entspricht das zuvor von MsgSource empfangene Label dem
           Label (d. h. dem in der Nachricht empfangenen Label)?
           (Siehe Anmerkung 3.)
           ODER
           Ist die empfangene Label-Abbildung eine Antwort auf eine
           zuvor an MsgSource gesendete ausstehende Label-Anforderung?
           (Siehe Anmerkung 12.)
           Wenn ja, gehe zu LMp.11.

   LMp.10a Arbeitet der LSR im Downstream Unsolicited-Modus? Wenn ja,
           die Label-Abbildung für das zuvor von MsgSource empfangene
           Label löschen und sie aus der Weiterleitungs-/Vermittlungs-
           nutzung entfernen.
           Prozedur Send_Message (MsgSource, Label Release,
           FEC, zuvor von MsgSource empfangenes Label) ausführen.

   LMp.11  Den Next Hop für die FEC bestimmen.

   LMp.12  Ist MsgSource der Next Hop für die FEC?
           Wenn ja, gehe zu LMp.14.

   LMp.13  LSR-Label-Freigabeprozedur ausführen:

                 Für Conservative Label retention:

                    1. Gehe zu LMp.32.

                 Für Liberal Label retention:

                    1. Aufzeichnen, dass eine Label-Abbildung für die
                       FEC mit Label und RAttributes von MsgSource
                       empfangen wurde.
                       Gehe zu LMp.33.

   LMp.14  Ist der LSR ein Ingress für die FEC?
           Wenn nicht, gehe zu LMp.16.

   LMp.15  Label zur Weiterleitungs-/Vermittlungsnutzung installieren.

   LMp.16  Aufzeichnen, dass eine Label-Abbildung für die FEC mit Label
           und RAttributes von MsgSource empfangen wurde.

   LMp.17  Für jeden Peer durch LMp.31 iterieren. (Siehe Anmerkung 7.)

   LMp.18  Hat der LSR zuvor eine Label-Abbildung für die FEC an den
           Peer für die betreffende LSP gesendet? (Siehe Anmerkung 8.)
           Wenn ja, gehe zu LMp.22.

   LMp.19  Wird die Labelverteilungsprozedur Downstream Unsolicited
           Ordered Control vom LSR verwendet?
           Wenn nicht, gehe zu LMp.28.

   LMp.20  Prozedur Prepare_Label_Mapping_Attributes (Peer,
           FEC, RAttributes, SAttributes, IsPropagating,
           StoredHopCount) ausführen.

   LMp.21  Prozedur Send_Message (Peer, Label Mapping, FEC,
           PrevAdvLabel, SAttributes) ausführen. (Siehe Anmerkung 13.)
           Gehe zu LMp.28.

   LMp.22  Für jede zuvor an den Peer gesendete Label-Abbildung für die
           FEC durch LMp.27 iterieren.

   LMp.23  Sind die RAttributes in der empfangenen Label-Abbildung
           konsistent mit denen, die zuvor an den Peer gesendet wurden?
           Wenn ja, die Iteration von LMp.22 für die nächste
           Label-Abbildung fortsetzen. (Siehe Anmerkung 9.)

   LMp.24  Prozedur Prepare_Label_Mapping_Attributes (Peer,
           FEC, RAttributes, SAttributes, IsPropagating,
           StoredHopCount) ausführen.

   LMp.25  Prozedur Send_Message (Peer, Label Mapping, FEC,
           PrevAdvLabel, SAttributes) ausführen. (Siehe Anmerkung 10.)

   LMp.26  Die Aufzeichnung der zuvor an den Peer gesendeten
           Label-Abbildung für die FEC aktualisieren, um die neu
           gesendeten Attribute einzuschließen.

   LMp.27  Iteration von LMp.22 beenden.

   LMp.28  Hat der LSR Label-Anforderungen für die FEC vom Peer, die als
           ausstehend (pending) markiert sind?
           Wenn nicht, gehe zu LMp.30.

   LMp.29  LSR-Labelverteilungsprozedur ausführen:

         Für Downstream Unsolicited Independent Control ODER Für
         Downstream Unsolicited Ordered Control

            1. Prozedur
               Prepare_Label_Mapping_Attributes (Peer, FEC,
               RAttributes, SAttributes, IsPropagating,
               UnknownHopCount) ausführen.

            2. Prozedur Send_Label (Peer, FEC, SAttributes) ausführen.
               Wenn die Prozedur fehlschlägt, die Iteration für den
               nächsten Peer bei LMp.17 fortsetzen.

            3. Wenn für den Peer keine ausstehenden Anforderungen
               existieren, gehe zu LMp.30.
               (Siehe Anmerkung 11.)

         Für Downstream On Demand Independent Control ODER Für
         Downstream On Demand Ordered Control

            1. Für jede als ausstehend markierte Label-Anforderung für
               die FEC vom Peer durch Schritt 5 iterieren.

            2. Prozedur
               Prepare_Label_Mapping_Attributes (Peer, FEC,
               RAttributes, SAttributes, IsPropagating,
               UnknownHopCount) ausführen

            3. Prozedur Send_Label (Peer, FEC, SAttributes) ausführen.
               Wenn die Prozedur fehlschlägt, die Iteration für den
               nächsten Peer bei LMp.17 fortsetzen.

            4. Aufzeichnung der ausstehenden Anforderung löschen.

            5. Iteration von Schritt 1 beenden.

            6. Gehe zu LMp.30.

   LMp.30  LSR-Labelverwendungsprozedur ausführen:

         Für Use Immediate ODER Für Use If Loop Not Detected

            1. Für jede zuvor an den Peer gesendete Label-Abbildung für
               die FEC durch Schritt 3 iterieren.

            2. Das empfangene Label und das an den Peer gesendete Label
               zur Weiterleitungs-/Vermittlungsnutzung installieren.

            3. Iteration von Schritt 1 beenden.

            4. Gehe zu LMp.31.

   LMp.31  Iteration von LMp.17 beenden.
           Gehe zu LMp.33.

   LMp.32  Prozedur Send_Message (MsgSource, Label Release,
           FEC, Label) ausführen.

   LMp.33  Fertig.

Anmerkungen:

1. Wenn der LSR zusammenführt (merging), sollte es höchstens 1 empfangene Abbildung für die FEC für die betreffende LSP geben. Im nicht zusammenführenden Fall könnte es mehrere empfangene Abbildungen für die FEC für die betreffende LSP geben.

2. Wenn der LSR eine Schleife erkannt hat und zuvor keine Label-Abbildung von MsgSource für die FEC empfangen hat, gibt er einfach das Label frei.

3. Entspricht das in der Nachricht empfangene Label einer der 1 oder mehr Label-Abbildungen, die im vorangegangenen Schritt (LMp.4 oder LMp.9) identifiziert wurden?

4. Eine unangeforderte Abbildung mit einem anderen Label vom selben Peer wäre ein Versuch, Multipath-Label-Switching aufzubauen, was in dieser Version von LDP nicht unterstützt wird.

5. Wenn das Label nicht in Weiterleitungs-/Vermittlungsnutzung ist, hat LMp.7 keine Wirkung.

6. Wenn die empfangene Label Mapping-Nachricht in LMp.1 einer ausstehenden Label-Anforderung entsprach, dann hat der LSR (per Definition) zuvor keine Label-Abbildung für die FEC für die betreffende LSP empfangen. Wenn der LSR vorgelagerte Labels für die betreffende LSP zusammenführt, sollte es höchstens 1 empfangene Abbildung geben. Im nicht zusammenführenden Fall könnte es mehrere empfangene Label-Abbildungen für dieselbe FEC geben, eine für jede resultierende LSP.

7. Die Iteration LMp.17 schließt MsgSource ein, um den Fall zu behandeln, in dem der LSR im Modus Downstream Unsolicited Ordered Control arbeitet. Ordered Control hindert den LSR daran, ein Label für die FEC anzukündigen, bis er eine Label-Abbildung von seinem Next Hop (MsgSource) für die FEC empfangen hat.

8. Wenn der LSR die LSP zusammenführt, hat er möglicherweise zuvor Label-Abbildungen für die FEC-LSP an einen oder mehrere Peers gesendet. Wenn der

   LSR nicht zusammenführt, hat er möglicherweise eine Label-Abbildung für die betreffende LSP an höchstens einen LSR gesendet.

9. Das Loop Detection Path Vector-Attribut wird bei dieser Prüfung berücksichtigt. Wenn die empfangenen RAttributes einen Path Vector enthalten und zuvor kein Path Vector an den Peer gesendet wurde, oder wenn der empfangene Path Vector mit dem zuvor an den Peer gesendeten Path Vector inkonsistent ist, dann gelten die Attribute als inkonsistent. Beachten Sie, dass ein LSR nicht verpflichtet ist, einen empfangenen Path Vector zu speichern, nachdem er den Path Vector in einer Mapping-Nachricht weitergegeben hat. Wenn ein LSR den Path Vector nicht speichert, hat er keine Möglichkeit, die Konsistenz eines neu empfangenen Path Vector zu prüfen. Das bedeutet, dass ein solcher LSR, wann immer er eine Mapping-Nachricht mit einem Path Vector empfängt, den Path Vector immer weitergeben muss.

10. LMp.22 bis LMp.27 befassen sich mit einer Situation, die auftreten kann, wenn der LSR unabhängige Steuerung verwendet und eine Abbildung vom nachgelagerten Peer empfängt, nachdem er eine Abbildung an einen vorgelagerten Peer gesendet hat. In dieser Situation muss der LSR alle geänderten Attribute, wie etwa die Hop-Zahl, vorgelagert weitergeben. Wenn die Schleifenerkennung aktiviert ist, müssen die weitergegebenen Attribute den Path Vector enthalten.

11. Ein LSR, der im Downstream Unsolicited-Modus arbeitet, MUSS (MUST) jede empfangene Label Request-Nachricht verarbeiten. Wenn ausstehende Label-Anforderungen vorhanden sind, in die Downstream on Demand-Verfahren übergehen, um die ausstehenden Anforderungen zu erfüllen.

12. Wie in Schritt LMp.1 bestimmt.

13. Ein LSR, der im Ordered Control-Modus arbeitet, kann in diesem Stadium den Peer überspringen, von dem er die Ankündigung empfangen hat, die ihn zur Erzeugung der Label-Map-Nachricht veranlasst hat. Dies stellt effektiv eine Form von Split Horizon bereit.

A.1.3. Empfang einer Label Abort Request

Zusammenfassung:

Wenn ein LSR eine Label Abort Request-Nachricht von einem Peer empfängt, prüft er, ob er bereits auf die betreffende Label-Anforderung geantwortet hat. Wenn ja, ignoriert er die Nachricht stillschweigend. Wenn nicht, sendet er dem Peer eine Label Request Aborted Notification. Wenn er darüber hinaus eine ausstehende Label-Anforderung für die betreffende LSP an einen nachgelagerten Peer hat, sendet er eine Label Abort Request an den nachgelagerten Peer, um die LSP abzubrechen.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• MsgSource. Der LDP-Peer, der die Nachricht gesendet hat.

• FEC. Die in der Nachricht angegebene FEC.

• RequestMessageID. Die Message ID der abzubrechenden Label-Anforderungsnachricht.

• Next Hop. Der Next Hop für die FEC.

Algorithmus:

   LAbR.1  Entspricht die Nachricht einer zuvor von MsgSource
           empfangenen Label Request-Nachricht? (Siehe Anmerkung 1.)
           Wenn nicht, gehe zu LAbR.12.

   LAbR.2  Hat der LSR auf die zuvor empfangene Label-Anforderung
           geantwortet?
           Wenn ja, gehe zu LAbR.12.

   LAbR.3  Prozedur Send_Message (MsgSource, Notification,
           Label Request Aborted, TLV) ausführen, wobei TLV das in der
           Label Abort Request-Nachricht empfangene Label Request
           Message ID TLV ist.

   LAbR.4  Hat der LSR eine ausstehende Label Request-Nachricht für die
           FEC?
           Wenn ja, gehe zu LAbR.7.

   LAbR.5  Hat der LSR eine Label-Abbildung für die FEC? Wenn nicht,
           gehe zu LAbR.11.

   LAbR.6  Ereignis erzeugen: Label Release-Nachricht für die FEC von
           MsgSource empfangen. (Siehe Anmerkung 2.)
           Gehe zu LAbR.11.

   LAbR.7  Führt der LSR die LSP für die FEC zusammen?
           Wenn nicht, gehe zu LAbR.9.

   LAbR.8  Gibt es ausstehende Label-Anforderungen für diese FEC?
           Wenn ja, gehe zu LAbR.11.

   LAbR.9  Prozedur Send_Message (Next Hop, Label Abort
           Request, FEC, TLV) ausführen, wobei TLV ein Label Request
           Message ID TLV ist, das die vom LSR in der ausstehenden
           Label Request-Nachricht verwendete Message ID enthält.

   LAbR.10  Aufzeichnen, dass eine Label-Abbruchanforderung für die FEC
            ausstehend ist.

   LAbR.11  Aufzeichnung der Label-Anforderung für die FEC von MsgSource
            löschen.

   LAbR.12  Fertig.

Anmerkungen:

1. Der LSR verwendet die FEC und das von der Label-Abbruchanforderung mitgeführte Label Request Message ID TLV, um seine Aufzeichnung (falls vorhanden) für die zuvor von MsgSource empfangene Label-Anforderung zu finden.

2. Wenn der LSR eine Label-Abbildung von NextHop empfangen hat, sollte er sich so verhalten, als hätte er eine Label-Abbildung an MsgSource angekündigt und MsgSource hätte sie freigegeben.

A.1.4. Empfang einer Label Release

Zusammenfassung:

Wenn ein LSR eine Label Release-Nachricht für eine FEC von einem Peer empfängt, prüft er, ob andere Peers das freigegebene Label halten. Wenn keiner dies tut, entfernt der LSR das Label aus der Weiterleitungs-/Vermittlungsnutzung, falls er dies nicht bereits getan hat, und wenn der LSR eine Label-Abbildung vom FEC-Next-Hop hält, gibt er die Label-Abbildung frei.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• MsgSource. Der LDP-Peer, der die Nachricht gesendet hat.

• Label. Das in der Nachricht angegebene Label.

• FEC. Die in der Nachricht angegebene FEC.

Algorithmus:

   LRl.1   Entspricht die FEC einer bekannten FEC? Wenn nicht, gehe zu
           LRl.14.

   LRl.2   MsgSource aus der Aufzeichnung der Peers entfernen, die das
           Label für die FEC halten. (Siehe Anmerkung 1.)

   LRl.3   Entspricht die Nachricht einem ausstehenden Label-Entzug für
           die FEC, der zuvor an MsgSource gesendet wurde?
           Wenn nicht, gehe zu LRl.5

   LRl.4   Aufzeichnung des ausstehenden Label-Entzugs für die FEC, der
           zuvor an MsgSource gesendet wurde, löschen.

   LRl.5   Führt der LSR Labels für diese FEC zusammen? Wenn nicht,
           gehe zu LRl.7. (Siehe Anmerkung 2.)

   LRl.6   Hat der LSR ausstehende Label-Ankündigungen für diese FEC?
           Wenn ja, gehe zu LRl.11.

   LRl.7   Ist der LSR der Egress für die FEC?
           Wenn ja, gehe zu LRl.11.

   LRl.8   Gibt es einen Next Hop für die FEC? UND Hat der LSR eine
           zuvor vom Next Hop empfangene Label-Abbildung für die FEC?
           Wenn nicht, gehe zu LRl.11.

   LRl.9   Ist der LSR dafür konfiguriert, Freigaben weiterzugeben?
           Wenn nicht, gehe zu LRl.11. (Siehe Anmerkung 3.)

   LRl.10  Prozedur Send_Message (Next Hop, Label Release,
           FEC, Label from Next Hop) ausführen.

   LRl.11  Das Label für Verkehr von MsgSource aus der Weiterleitungs-/
           Vermittlungsnutzung entfernen.

   LRl.12  Halten noch Peers das Label für die FEC?
           Wenn ja, gehe zu LRl.14.

   LRl.13  Das Label freigeben.

   LRl.14  Fertig.

Anmerkungen:

1. Wenn der LSR die Downstream Unsolicited-Labelverteilung verwendet, SOLLTE (SHOULD) er eine Label-Abbildung für die FEC nicht erneut an MsgSource ankündigen, bis MsgSource dies anfordert.

2. LRl.5 bis LRl.9 befassen sich mit der Bestimmung, ob der LSR die Label Release an einen nachgelagerten Peer weitergeben sollte (LRl.9).

3. Wenn LRl.9 erreicht wird, hält kein vorgelagerter LSR ein Label für die FEC, und der LSR hält ein Label für die FEC vom FEC-Next-Hop. Der LSR könnte die Label Release an den Next Hop weitergeben. Durch die Weitergabe der Label Release gibt der LSR eine potenziell knappe Label-Ressource frei. Dadurch erhöht er jedoch auch die

   Latenz für die Wiederherstellung der LSP, falls MsgSource oder ein anderer vorgelagerter LSR ihm eine neue Label Request für die FEC sendet.

   Ob die Freigabe weitergegeben wird oder nicht, ist keine Protokollfrage. Die Labelverteilung funktioniert ordnungsgemäß, unabhängig davon, ob die Freigabe weitergegeben wird. Die Entscheidung, weiterzugeben oder nicht, sollte Faktoren berücksichtigen wie: ob Labels in der Betriebsumgebung eine knappe Ressource sind, die Bedeutung, die LSP-Aufbaulatenz durch einen geringen Signalisierungsaufwand niedrig zu halten, und ob der LSP-Aufbau in der Betriebsumgebung ingressegesteuert oder egressgesteuert ist.

A.1.5. Empfang eines Label Withdraw

Zusammenfassung:

Wenn ein LSR eine Label Withdraw-Nachricht für eine FEC von einem LDP-Peer empfängt, antwortet er mit einer Label Release-Nachricht und entfernt das Label aus jeder Weiterleitungs-/Vermittlungsnutzung. Wenn Ordered Control verwendet wird, sendet der LSR eine Label Withdraw-Nachricht an jeden LDP-Peer, an den er zuvor eine Label-Abbildung für die FEC gesendet hat. Wenn der LSR die Downstream on Demand-Label-Ankündigung mit unabhängiger Steuerung verwendet, verhält er sich anschließend so, als hätte er die FEC gerade erkannt.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• MsgSource. Der LDP-Peer, der die Nachricht gesendet hat.

• Label. Das in der Nachricht angegebene Label.

• FEC. Die in der Nachricht angegebene FEC.

Algorithmus:

   LWd.1   Label aus der Weiterleitungs-/Vermittlungsnutzung entfernen.
           (Siehe Anmerkung 1.)

   LWd.2   Prozedur Send_Message (MsgSource, Label Release,
           FEC, Label) ausführen.

   LWd.3   Hat der LSR zuvor eine passende Label-Abbildung für die FEC
           von MsgSource empfangen und beibehalten?
           Wenn nicht, gehe zu LWd.13.

   LWd.4   Passende Label-Abbildung für die FEC, die zuvor von
           MsgSource empfangen wurde, löschen.

   LWd.5   Verwendet der LSR Ordered Control?
           Wenn ja, gehe zu LWd.8.

   LWd.6   Verwendet MsgSource die Downstream On Demand-Label-
           Ankündigung?
           Wenn nicht, gehe zu LWd.13.

   LWd.7   Ereignis erzeugen: Neue FEC für die FEC erkennen. Gehe zu
           LWd.13. (Siehe Anmerkung 2.)

   LWd.8   Für jeden Peer außer MsgSource durch LWd.12 iterieren.

   LWd.9   Hat der LSR zuvor eine Label-Abbildung für die FEC an den
           Peer gesendet?
           Wenn nicht, die Iteration für den nächsten Peer bei LWd.8
           fortsetzen.

   LWd.10  Entspricht das zuvor an den Peer gesendete Label dem
           entzogenen Label ("map to")?
           Wenn nicht, die Iteration für den nächsten Peer bei LWd.8
           fortsetzen. (Siehe Anmerkung 3.)

   LWd.11  Prozedur Send_Label_Withdraw (Peer, FEC, Label
           previously sent to Peer) ausführen.

   LWd.12  Iteration von LWd.8 beenden.

   LWd.13  Fertig.

Anmerkungen:

1. Wenn das Label nicht in Weiterleitungs-/Vermittlungsnutzung ist, hat LWd.1 keine Wirkung.

2. LWd.7 behandelt den Fall, in dem der LSR die Downstream On Demand-Labelverteilung mit unabhängiger Steuerung verwendet. In dieser Situation sollte der LSR eine Label-Anforderung an den FEC-Next-Hop senden, als hätte er die FEC gerade erkannt.

3. LWd.10 behandelt sowohl den Fall des Label-Zusammenführens (ein oder mehrere eingehende Labels werden auf dasselbe ausgehende Label abgebildet) als auch den Fall ohne Label-Zusammenführen (ein Label wird auf das ausgehende Label abgebildet).

A.1.6. Erkennen einer neuen FEC

Zusammenfassung:

Die Reaktion eines LSR auf das Erlernen einer neuen FEC über die Routing-Tabelle kann eine oder mehrere der folgenden Aktionen umfassen:

• Übertragung von Label-Abbildungen für die FEC an einen oder mehrere LDP-Peers;

• Übertragung einer Label-Anforderung für die FEC an den FEC-Next-Hop;

• jede der Aktionen, die auftreten können, wenn der LSR eine Label-Abbildung für die FEC vom FEC-Next-Hop empfängt.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• FEC. Die neu erkannte FEC.

• Next Hop. Der Next Hop für die FEC.

• InitAttributes. Attribute, die der neuen FEC zuzuordnen sind. (Siehe Anmerkung 1.)

• SAttributes. Attribute, die in Label Mapping- oder Label Request-Nachrichten aufzunehmen sind, falls solche an Peers gesendet werden.

• StoredHopCount. Hop-Zahl, die der gegebenenfalls zuvor vom Next Hop empfangenen FEC-Label-Abbildung zugeordnet ist.

Algorithmus:

   FEC.1   LSR-Labelverteilungsprozedur ausführen:

         Für Downstream Unsolicited Independent Control

            1. Für jeden Peer durch 5 iterieren.

            2. Hat der LSR zuvor eine Label-Abbildung für die FEC vom
               Next Hop empfangen und beibehalten?
               Wenn ja, Propagating auf IsPropagating setzen.
               Wenn nicht, Propagating auf NotPropagating setzen.

            3. Prozedur Prepare_Label_Mapping_Attributes
               (Peer, FEC, InitAttributes, SAttributes, Propagating,
               Unknown hop count(0)) ausführen.

            4. Prozedur Send_Label (Peer, FEC, SAttributes) ausführen.

            5. Iteration von 1 beenden.
               Gehe zu FEC.2.

         Für Downstream Unsolicited Ordered Control

            1. Für jeden Peer durch 5 iterieren.

            2. Ist der LSR der Egress für die FEC? ODER Hat der LSR
               zuvor eine Label-Abbildung für die FEC vom Next Hop
               empfangen und beibehalten?
               Wenn nicht, die Iteration für den nächsten Peer
               fortsetzen.

            3. Prozedur Prepare_Label_Mapping_Attributes
               (Peer, FEC, InitAttributes, SAttributes, Propagating,
               StoredHopCount) ausführen.

            4. Prozedur Send_Label (Peer, FEC, SAttributes) ausführen.

            5. Iteration von 1 beenden.
               Gehe zu FEC.2.

         Für Downstream On Demand Independent Control ODER
         Für Downstream On Demand Ordered Control

            1. Gehe zu FEC.2. (Siehe Anmerkung 2.)

   FEC.2   Hat der LSR zuvor eine Label-Abbildung für die FEC vom Next
           Hop empfangen und beibehalten?
           Wenn ja, gehe zu FEC.5

   FEC.3   Ist der Next Hop ein LDP-Peer?
           Wenn nicht, gehe zu FEC.6

   FEC.4   LSR-Labelanforderungsprozedur ausführen:

         Für Request Never

            1. Gehe zu FEC.6

         Für Request When Needed ODER
         Für Request On Request

            1. Prozedur
               Prepare_Label_Request_Attributes (Next Hop, FEC,
               InitAttributes, SAttributes) ausführen;

            2. Prozedur Send_Label_Request (Next Hop, FEC,
               SAttributes) ausführen.
               Gehe zu FEC.6.

   FEC.5   Ereignis erzeugen: Label Mapping vom Next Hop empfangen.
           (Siehe Anmerkung 3.)

   FEC.6   Fertig.

Anmerkungen:

1. Ein Beispiel für ein Attribut, das Teil von InitAttributes sein könnte, ist eines, das gewünschte LSP-Eigenschaften wie Class of Service (CoS) angibt. (Beachten Sie, dass die aktuelle Version von LDP kein CoS-Attribut spezifiziert, LDP-Erweiterungen dies jedoch tun können.)

   Die Art und Weise, in der FEC InitAttributes, falls vorhanden, angegeben werden, liegt außerhalb des Geltungsbereichs von LDP. Beachten Sie, dass die InitAttributes keine bekannte Hop-Zahl und keinen Path Vector enthalten werden.

2. Ein LSR, der die Downstream On Demand-Labelverteilung verwendet, würde

   ein Label nur senden, wenn er eine zuvor empfangene Label-Anforderung hätte, die als ausstehend markiert ist. Der LSR hätte keine solchen ausstehenden Anforderungen, weil er auf jede Label-Anforderung für eine unbekannte FEC reagiert, indem er dem anfordernden LSR eine No Route-Benachrichtigung sendet und die Label-Anforderung verwirft; siehe LRq.3

3. Wenn der LSR ein Label für die FEC vom Next Hop hat, sollte er sich so verhalten, als hätte er das Label gerade vom Next Hop empfangen. Dies tritt im Fall des Liberal Label retention-Modus auf.

A.1.7. Erkennen einer Änderung des FEC-Next-Hop

Zusammenfassung:

Die Reaktion eines LSR auf eine Änderung des Next Hop für eine FEC kann eine oder mehrere der folgenden Aktionen umfassen:

• Entfernen des Labels vom alten Next Hop der FEC aus der Weiterleitungs-/Vermittlungsnutzung;

• Übertragung von Label Mapping-Nachrichten für die FEC an einen oder mehrere LDP-Peers;

• Übertragung einer Label-Anforderung an den neuen Next Hop der FEC;

• jede der Aktionen, die auftreten können, wenn der LSR eine Label-Abbildung vom neuen Next Hop der FEC empfängt.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• FEC. Die FEC, deren Next Hop sich geändert hat.

• New Next Hop. Der aktuelle Next Hop für die FEC.

• Old Next Hop. Der vorherige Next Hop für die FEC.

• OldLabel. Das gegebenenfalls zuvor vom Old Next Hop empfangene Label.

• CurAttributes. Die der FEC derzeit gegebenenfalls zugeordneten Attribute.

• SAttributes. Attribute, die in die gegebenenfalls an den New Next Hop gesendete Label Request-Nachricht aufzunehmen sind.

Algorithmus:

   NH.1   Hat der LSR zuvor eine Label-Abbildung für die FEC vom Old
          Next Hop empfangen und beibehalten? Wenn nicht, gehe zu NH.6.

   NH.2   Label aus der Weiterleitungs-/Vermittlungsnutzung entfernen.
          (Siehe Anmerkung 1.)

   NH.3   Verwendet der LSR Liberal Label retention?
          Wenn ja, gehe zu NH.6.

   NH.4   Prozedur Send_Message (Old Next Hop, Label
          Release, OldLabel) ausführen.

   NH.5   Label-Abbildung für die FEC, die zuvor vom Old Next Hop
          empfangen wurde, löschen.

   NH.6   Hat der LSR eine ausstehende Label-Anforderung beim Old Next
          Hop?
          Wenn nicht, gehe zu NH.10.

   NH.7   Verwendet der LSR Conservative Label retention?
          Wenn nicht, gehe zu NH.10.

   NH.8   Prozedur Send_Message (Old Next Hop, Label Abort
          Request, FEC, TLV) ausführen, wobei TLV ein Label Request
          Message ID TLV ist, das die Message ID der ausstehenden
          Label-Anforderung mitführt.

   NH.9   Aufzeichnen, dass eine Label-Abbruchanforderung für die FEC
          beim Old Next Hop ausstehend ist.

   NH.10  Gibt es einen New Next Hop für die FEC?
          Wenn nicht, gehe zu NH.16.

   NH.11  Hat der LSR zuvor eine Label-Abbildung für die FEC vom New
          Next Hop empfangen und beibehalten?
          Wenn nicht, gehe zu NH.13.

   NH.12  Ereignis erzeugen: Label Mapping vom New Next Hop empfangen.
          Gehe zu NH.20. (Siehe Anmerkung 2.)

   NH.13  Verwendet der LSR die Downstream on Demand-Ankündigung? ODER
          Verwendet der Next Hop die Downstream on Demand-Ankündigung?
          ODER Verwendet der LSR Conservative Label retention? (Siehe
          Anmerkung 3.)
          Wenn ja, gehe zu NH.14.
          Wenn nicht, gehe zu NH.20.

   NH.14  Prozedur Prepare_Label_Request_Attributes (Next
          Hop, FEC, CurAttributes, SAttributes) ausführen.

   NH.15  Prozedur Send_Label_Request (New Next Hop, FEC,
          SAttributes) ausführen. (Siehe Anmerkung 4.)
          Gehe zu NH.20.

   NH.16  Für jeden Peer durch NH.19 iterieren.

   NH.17  Hat der LSR zuvor eine Label-Abbildung für die FEC an den
          Peer gesendet?
          Wenn nicht, die Iteration für den nächsten Peer bei NH.16
          fortsetzen.

   NH.18  Prozedur Send_Label_Withdraw (Peer, FEC, Label
          previously sent to Peer) ausführen.

   NH.19  Iteration von NH.16 beenden.

   NH.20  Fertig.

Anmerkungen:

1. Wenn das Label nicht in Weiterleitungs-/Vermittlungsnutzung ist, hat NH.2 keine Wirkung.

2. Wenn der LSR ein Label für die FEC vom New Next Hop hat, sollte er sich so verhalten, als hätte er das Label gerade vom New Next Hop empfangen.

3. Der Zweck der Prüfung des Label-Beibehaltungsmodus ist, ein Wettrennen (race) mit den Schritten LMp.12-LMp.13 des Verfahrens zur Behandlung einer Label Mapping-Nachricht zu vermeiden, bei dem der im Conservative Label retention-Modus arbeitende LSR möglicherweise eine vom New Next Hop empfangene Label-Abbildung freigegeben hat, bevor er erkannt hat, dass sich der FEC-Next-Hop geändert hat.

4. Unabhängig von der vom LSR verwendeten Label Request-Prozedur MUSS (MUST) er eine Label-Anforderung senden, wenn die Bedingungen in NH.13 gelten. Daher führt er die Prozedur Send_Label_Request direkt aus, anstatt die LSR-Labelanforderungsprozedur durchzuführen.

A.1.8. Empfang einer Notification / Label Request Aborted

Zusammenfassung:

Wenn ein LSR eine Label Request Aborted-Benachrichtigung von einem LDP-Peer empfängt, zeichnet er auf, dass die entsprechende Label-Anforderungstransaktion, falls vorhanden, abgeschlossen ist.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• FEC. Die FEC, für die ein Label angefordert wurde.

• RequestMessageID. Die Message ID der abzubrechenden Label-Anforderungsnachricht.

• MsgSource. Der LDP-Peer, der die Notification-Nachricht gesendet hat.

Algorithmus:

   LRqA.1  Entspricht die Benachrichtigung einem ausstehenden Abbruch
           einer Label-Anforderung für die FEC? (Siehe Anmerkung 1.)
           Wenn nicht, gehe zu LRqA.3.

   LRqA.2  Aufzeichnen, dass die Label-Anforderung für die FEC
           abgebrochen wurde.

   LRqA.3  Fertig.

Anmerkung:

1. Der LSR verwendet die FEC und RequestMessageID, um seine Aufzeichnung (falls vorhanden) des ausstehenden Abbruchs der Label-Anforderung zu finden.

A.1.9. Empfang einer Notification / No Label Resources

Zusammenfassung:

Wenn ein LSR eine No Label Resources-Benachrichtigung von einem LDP-Peer empfängt, hört er auf, Label-Anforderungsnachrichten an den Peer zu senden, bis er eine Label Resources Available Notification vom Peer empfängt.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• FEC. Die FEC, für die ein Label angefordert wurde.

• MsgSource. Der LDP-Peer, der die Notification-Nachricht gesendet hat.

Algorithmus:

   NoRes.1 Aufzeichnung der an MsgSource gesendeten ausstehenden
           Label-Anforderung für die FEC löschen.

   NoRes.2 Aufzeichnen, dass eine Label-Abbildung für die FEC von
           MsgSource benötigt wird, aber keine Label-Ressourcen
           verfügbar sind.

   NoRes.3 Statusaufzeichnung setzen, die angibt, dass es nicht in
           Ordnung ist, Label-Anforderungen an MsgSource zu senden.

   NoRes.4 Fertig.

A.1.10. Empfang einer Notification / No Route

Zusammenfassung:

Wenn ein LSR eine No Route-Benachrichtigung von einem LDP-Peer als Antwort auf eine Label Request-Nachricht empfängt, bestimmt die verwendete Label No Route-Prozedur seine Reaktion. Der LSR wird entweder keine weiteren Maßnahmen ergreifen oder die Label-Anforderung zurückstellen, indem er einen Timer startet und eine weitere Label Request-Nachricht an den Peer sendet, wenn der Timer später abläuft.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• FEC. Die FEC, für die ein Label angefordert wurde.

• Attributes. Die der Label-Anforderung zugeordneten Attribute.

• MsgSource. Der LDP-Peer, der die Notification-Nachricht gesendet hat.

Algorithmus:

   NoNH.1  Aufzeichnung der an MsgSource gesendeten ausstehenden
           Label-Anforderung für die FEC löschen.

   NoNH.2  LSR-Label-No-Route-Prozedur ausführen.

         Für Request No Retry

            1. Gehe zu NoNH.3.

         Für Request Retry

            1. Zurückgestellte Label-Anforderung für die FEC und die an
               MsgSource zu sendenden Attributes aufzeichnen.

            2. Zeitüberschreitung starten. Gehe zu NoNH.3.

   NoNH.3  Fertig.

A.1.11. Empfang einer Notification / Loop Detected

Zusammenfassung:

Wenn ein LSR einen Loop Detected-Status Code von einem LDP-Peer als Antwort auf eine Label Request-Nachricht oder eine Label Mapping-Nachricht empfängt, verhält er sich so, als hätte er eine No Route-Benachrichtigung empfangen.

Kontext:

Siehe "Receive Notification / No Route".

Algorithmus:

Siehe "Receive Notification / No Route".

Anmerkung:

1. Wenn die Loop Detected-Benachrichtigung eine Antwort auf eine Label Request-Nachricht ist, trifft sie in einem Status Code TLV in einer Notification-Nachricht ein. Wenn sie eine Antwort auf eine Label Mapping-Nachricht ist, trifft sie in einem Status Code TLV in einer Label Release-Nachricht ein.

A.1.12. Empfang einer Notification / Label Resources Available

Zusammenfassung:

Wenn ein LSR eine Label Resources Available-Benachrichtigung von einem LDP-Peer empfängt, nimmt er das Senden von Label-Anforderungen an den Peer wieder auf.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• MsgSource. Der LDP-Peer, der die Notification-Nachricht gesendet hat.

• SAttributes. Attribute, die mit der zurückgestellten Label Request-Nachricht gespeichert wurden.

Algorithmus:

   Res.1   Statusaufzeichnung setzen, die angibt, dass es in Ordnung
           ist, Label-Anforderungen an MsgSource zu senden.

   Res.2   Für jede Aufzeichnung einer von MsgSource benötigten
           FEC-Label-Abbildung, für die keine Label-Ressourcen
           verfügbar sind, durch Res.6 iterieren.

   Res.3   Ist MsgSource der Next Hop für die FEC?
           Wenn nicht, gehe zu Res.5.

   Res.4   Prozedur Send_Label_Request (MsgSource, FEC,
           SAttributes) ausführen. Wenn die Prozedur fehlschlägt, die
           Iteration beenden.

   Res.5   Aufzeichnung löschen, dass keine Ressourcen für eine von
           MsgSource benötigte Label-Abbildung für die FEC verfügbar
           sind.

   Res.6   Iteration von Res.2 beenden.

   Res.7   Fertig.

A.1.13. Erkennen, dass lokale Label-Ressourcen verfügbar geworden sind

Zusammenfassung:

Nachdem ein LSR eine No Label Resources-Benachrichtigung an einen LDP-Peer gesendet hat, sendet er, wenn später Label-Ressourcen verfügbar werden, eine Label Resources Available-Benachrichtigung an jeden solchen Peer.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• Attributes. Attribute, die mit der zurückgestellten Label Mapping-Nachricht gespeichert wurden.

Algorithmus:

   ResA.1  Für jeden Peer, an den der LSR zuvor eine No Label
           Resources-Benachrichtigung gesendet hat, durch ResA.4
           iterieren.

   ResA.2  Prozedur Send_Notification (Peer, Label Resources
           Available) ausführen.

   ResA.3  Aufzeichnung löschen, dass eine No Label Resources-
           Benachrichtigung zuvor an den Peer gesendet wurde.

   ResA.4  Iteration von ResA.1 beenden.

   ResA.5  Für jede Aufzeichnung einer für den Peer benötigten
           Label-Abbildung für eine FEC, für die keine
           Label-Ressourcen verfügbar sind, durch ResA.8 iterieren.
           (Siehe Anmerkung 1.)

   ResA.6  Prozedur Send_Label (Peer, FEC, Attributes) ausführen. Wenn
           die Prozedur fehlschlägt, die Iteration beenden.

   ResA.7  Aufzeichnung der für den Peer benötigten FEC-Label-Abbildung,
           für die keine Label-Ressourcen verfügbar sind, löschen.

   ResA.8  Iteration von ResA.5 beenden

   ResA.9  Fertig.

Anmerkung:

1. Die Iteration ResA.5 bis ResA.8 behandelt die Situation, in der der LSR die Downstream Unsolicited-Labelverteilung verwendet und zuvor nicht in der Lage war, ein Label für eine FEC zuzuweisen.

A.1.14. Der LSR entscheidet, eine FEC nicht mehr labelzuvermitteln

Zusammenfassung:

Ein LSR kann einseitig entscheiden, eine FEC für einen LDP-Peer nicht mehr labelzuvermitteln. Ein LSR, der dies tut, MUSS (MUST) eine Label Withdraw-Nachricht für die FEC an den Peer senden.

Kontext:

• Peer. Der Peer.

• FEC. Die FEC.

• PrevAdvLabel. Das zuvor dem Peer angekündigte Label für die FEC.

Algorithmus:

   NoLS.1  Prozedur Send_Label_Withdraw (Peer, FEC,
           PrevAdvLabel) ausführen. (Siehe Anmerkung 1.)

   NoLS.2  Fertig.

Anmerkung:

1. Der LSR kann das Label als Teil dieses Ereignisses oder als Teil der Verarbeitung der Label Release vom Peer als Antwort auf den Label-Entzug aus der Weiterleitungs-/Vermittlungsnutzung entfernen. Wenn der LSR nicht auf die Label Release-Nachricht vom Peer wartet, SOLLTE (SHOULD) er das Label NICHT wiederverwenden, bis er die Label Release empfängt.

A.1.15. Zeitüberschreitung einer zurückgestellten Label-Anforderung

Zusammenfassung:

Label-Anforderungen werden als Antwort auf No Route- und Loop Detected-Benachrichtigungen zurückgestellt. Wenn eine zurückgestellte FEC-Label-Anforderung für einen Peer zeitlich abläuft, sendet der LSR die Label-Anforderung.

Kontext:

• LSR. Der LSR, der das Ereignis behandelt.

• FEC. Die dem Zeitüberschreitungsereignis zugeordnete FEC.

• Peer. Der dem Zeitüberschreitungsereignis zugeordnete LDP-Peer.

• Attributes. Attribute, die mit der zurückgestellten Label Request-Nachricht gespeichert wurden.

Algorithmus:

   TO.1    Die Aufzeichnung der zurückgestellten Label-Anforderung
           abrufen.

   TO.2    Ist der Peer der Next Hop für die FEC?
           Wenn nicht, gehe zu TO.4.

   TO.3    Prozedur Send_Label_Request (Peer, FEC) ausführen.

   TO.4    Fertig.