2. LDP-Betrieb

2.1. FECs

Es ist notwendig, präzise festzulegen, welche Pakete auf welche LSP abgebildet werden dürfen. Dies geschieht durch die Angabe einer FEC-Spezifikation für jede LSP. Die FEC identifiziert die Menge der IP-Pakete, die auf diese LSP abgebildet werden dürfen.

Jede FEC wird als eine Menge von einem oder mehreren FEC-Elementen spezifiziert. Jedes FEC-Element identifiziert eine Menge von Paketen, die auf die entsprechende LSP abgebildet werden dürfen. Wenn eine LSP von mehreren FEC-Elementen gemeinsam genutzt wird, wird diese LSP an (oder vor) dem Knoten beendet, an dem die FEC-Elemente nicht mehr denselben Pfad gemeinsam nutzen können.

Diese Spezifikation definiert einen einzigen Typ von FEC-Element, das "Address Prefix FEC element". Dieses Element ist ein Adresspräfix beliebiger Länge von 0 bis einschließlich einer vollständigen Adresse.

Zusätzliche FEC-Elemente können nach Bedarf durch andere Spezifikationen definiert werden.

Im Rest dieses Abschnitts geben wir die Regeln an, die für die Abbildung von Paketen auf LSPs verwendet werden, die unter Verwendung eines Address Prefix FEC element aufgebaut wurden.

Wir sagen, dass eine bestimmte Adresse ein bestimmtes Adresspräfix "trifft" (matches), genau dann, wenn diese Adresse mit diesem Präfix beginnt. Wir sagen ferner, dass ein bestimmtes Paket eine bestimmte LSP trifft, genau dann, wenn diese LSP ein Address Prefix FEC element hat, das die Zieladresse des Pakets trifft. In Bezug auf ein bestimmtes Paket und eine bestimmte LSP bezeichnen wir jedes Address Prefix FEC element, das das Paket trifft, als das "matching prefix".

Das Verfahren zur Abbildung eines bestimmten Pakets auf eine bestimmte LSP verwendet die folgenden Regeln. Jede Regel wird der Reihe nach angewendet, bis das Paket auf eine LSP abgebildet werden kann.

• Wenn ein Paket genau eine LSP trifft, wird das Paket auf diese LSP abgebildet.

• Wenn ein Paket mehrere LSPs trifft, wird es auf die LSP abgebildet, deren übereinstimmendes Präfix das längste ist. Gibt es keine einzelne LSP, deren übereinstimmendes Präfix das längste ist, wird das Paket auf eine aus der Menge der LSPs abgebildet, deren übereinstimmendes Präfix länger ist als das der anderen. Das Verfahren zur Auswahl einer dieser LSPs liegt außerhalb des Geltungsbereichs dieses Dokuments.

• Wenn bekannt ist, dass ein Paket einen bestimmten Egress-Router durchlaufen muss, und es eine LSP gibt, die ein Address Prefix FEC element besitzt, das eine /32-Adresse dieses Routers ist, dann wird das Paket auf diese LSP abgebildet. Das Verfahren zum Erlangen dieser Kenntnis liegt außerhalb des Geltungsbereichs dieses Dokuments.

Das Verfahren zur Bestimmung, dass ein Paket einen bestimmten Egress-Router durchlaufen muss, liegt außerhalb des Geltungsbereichs dieses Dokuments. (Wenn man beispielsweise einen Link-State-Routing-Algorithmus ausführt, kann es möglich sein, diese Information aus der Link-State-Datenbank zu erhalten. Als weiteres Beispiel kann es, wenn man BGP ausführt, möglich sein, diese Information aus dem BGP-Next-Hop-Attribut der Route des Pakets zu erhalten.)

2.2. Label-Räume, Identifikatoren, Sitzungen und Transport

2.2.1. Label-Räume

Der Begriff "label space" ist nützlich, um die Zuweisung und Verteilung von Labels zu erörtern. Es gibt zwei Arten von Label-Räumen:

• Pro-Schnittstelle-Label-Raum (Per interface label space). Schnittstellenspezifische eingehende Labels werden für Schnittstellen verwendet, die Schnittstellenressourcen für Labels nutzen. Ein Beispiel für eine solche Schnittstelle ist eine labelgesteuerte ATM-Schnittstelle, die VCIs (Virtual Channel Identifiers) als Labels verwendet, oder eine Frame-Relay-Schnittstelle, die DLCIs (Data Link Connection Identifiers) als Labels verwendet.

  Beachten Sie, dass die Verwendung eines Pro-Schnittstelle-Label-Raums nur dann sinnvoll ist, wenn die LDP-Peers über eine Schnittstelle "direkt verbunden" sind und das Label nur für den über diese Schnittstelle gesendeten Verkehr verwendet wird.

• Pro-Plattform-Label-Raum (Per platform label space). Plattformweite eingehende Labels werden für Schnittstellen verwendet, die dieselben Labels gemeinsam nutzen können.

2.2.2. LDP-Identifikatoren

Ein LDP Identifier ist eine sechs Oktett große Größe, die verwendet wird, um einen LSR-Label-Raum zu identifizieren. Die ersten vier Oktette identifizieren den LSR und müssen ein global eindeutiger Wert sein, wie etwa eine dem LSR zugewiesene 32-Bit-Router-Id. Die letzten beiden Oktette identifizieren einen bestimmten Label-Raum innerhalb des LSR. Die letzten beiden Oktette von LDP Identifiers für plattformweite Label-Räume sind immer beide null. Dieses Dokument verwendet die folgende Druckdarstellung für LDP Identifiers:

  <LSR Id> : <label space id>

z. B. lsr171:0, lsr19:2.

Beachten Sie, dass ein LSR, der mehrere Label-Räume verwaltet und ankündigt, für jeden dieser Label-Räume einen anderen LDP Identifier verwendet.

Eine Situation, in der ein LSR einem Peer mehr als einen Label-Raum ankündigen müsste und daher mehr als einen LDP Identifier verwenden müsste, tritt auf, wenn der LSR zwei Verbindungen zum Peer hat und beide ATM sind (und Pro-Schnittstelle-Labels verwenden). Eine andere Situation wäre, dass der LSR zwei Verbindungen zum Peer hätte, von denen eine Ethernet ist (und Pro-Plattform-Labels verwendet) und die andere ATM ist.

2.2.3. LDP-Sitzungen

LDP-Sitzungen bestehen zwischen LSRs, um den Label-Austausch zwischen ihnen zu unterstützen.

Wenn ein LSR LDP verwendet, um einem anderen LSR mehr als einen Label-Raum anzukündigen, verwendet er für jeden Label-Raum eine separate LDP-Sitzung.

2.2.4. LDP-Transport

LDP verwendet TCP als zuverlässigen Transport für Sitzungen.

Wenn zwischen zwei LSRs mehrere LDP-Sitzungen erforderlich sind, gibt es eine TCP-Sitzung für jede LDP-Sitzung.

2.3. LDP-Sitzungen zwischen nicht direkt verbundenen LSRs

LDP-Sitzungen zwischen LSRs, die auf Verbindungsebene nicht direkt verbunden sind, können in manchen Situationen wünschenswert sein.

Betrachten Sie beispielsweise eine "Traffic-Engineering"-Anwendung, bei der LSRa Verkehr, der bestimmte Kriterien erfüllt, über eine LSP an einen nicht direkt verbundenen LSRb sendet, anstatt den Verkehr entlang seines normal gerouteten Pfads weiterzuleiten.

Der Pfad zwischen LSRa und LSRb würde einen oder mehrere Zwischen-LSRs (LSR1,...LSRn) umfassen. Eine LDP-Sitzung zwischen LSRa und LSRb würde es LSRb ermöglichen, den auf der LSP von LSRa eintreffenden Verkehr labelzuvermitteln, indem LSRb ein Mittel bereitgestellt wird, um zu diesem Zweck Labels an LSRa anzukündigen.

In dieser Situation würde LSRa zwei Labels auf den Verkehr anwenden, den es auf der LSP an LSRb weiterleitet: ein von LSR1 erlerntes Label, um den Verkehr entlang des LSP-Pfads von LSRa nach LSRb weiterzuleiten; und ein von LSRb erlerntes Label, um LSRb in die Lage zu versetzen, den auf der LSP eintreffenden Verkehr labelzuvermitteln.

LSRa fügt zunächst das über seine LDP-Sitzung mit LSRb erlernte Label zum Label-Stack des Pakets hinzu (entweder indem es das Label oben auf dem Paket-Label-Stack durch dieses ersetzt, falls das Paket mit Label ankommt, oder indem es dieses einfügt (pusht), falls das Paket ohne Label ankommt). Als Nächstes fügt es das von LSR1 erlernte Label für die LSP oben auf den Label-Stack ein.

2.4. LDP-Discovery

LDP-Discovery ist ein Mechanismus, der es einem LSR ermöglicht, potenzielle LDP-Peers zu entdecken. Durch die Discovery entfällt die Notwendigkeit, die Label-Switching-Peers eines LSR explizit zu konfigurieren.

Es gibt zwei Varianten des Discovery-Mechanismus:

• Ein Basic-Discovery-Mechanismus, der verwendet wird, um LSR-Nachbarn zu entdecken, die auf Verbindungsebene direkt verbunden sind.

• Ein Extended-Discovery-Mechanismus, der verwendet wird, um LSRs zu lokalisieren, die auf Verbindungsebene nicht direkt verbunden sind.

2.4.1. Basic-Discovery-Mechanismus

Um LDP Basic Discovery auf einer Schnittstelle zu betreiben, sendet ein LSR periodisch LDP Link Hellos über die Schnittstelle aus. LDP Link Hellos werden als UDP-Pakete gesendet, die an den bekannten LDP-Discovery-Port für die Gruppen-Multicast-Adresse "all routers on this subnet" adressiert sind.

Ein von einem LSR gesendetes LDP Link Hello trägt den LDP Identifier für den Label-Raum, den der LSR für die Schnittstelle zu verwenden beabsichtigt, und möglicherweise zusätzliche Informationen.

Der Empfang eines LDP Link Hello auf einer Schnittstelle identifiziert eine "Hello-Adjazenz" (Hello adjacency) mit einem potenziellen LDP-Peer, der auf Verbindungsebene auf der Schnittstelle erreichbar ist, sowie den Label-Raum, den der Peer für die Schnittstelle zu verwenden beabsichtigt.

2.4.2. Extended-Discovery-Mechanismus

LDP-Sitzungen zwischen nicht direkt verbundenen LSRs werden durch LDP Extended Discovery unterstützt.

Um LDP Extended Discovery zu betreiben, sendet ein LSR periodisch LDP Targeted Hellos an eine bestimmte Adresse. LDP Targeted Hellos werden als UDP-Pakete gesendet, die an den bekannten LDP-Discovery-Port an der bestimmten Adresse adressiert sind.

Ein von einem LSR gesendetes LDP Targeted Hello trägt den LDP Identifier für den Label-Raum, den der LSR zu verwenden beabsichtigt, und möglicherweise zusätzliche optionale Informationen.

Extended Discovery unterscheidet sich von Basic Discovery auf folgende Weise:

• Ein Targeted Hello wird an eine bestimmte Adresse gesendet und nicht an die "all routers"-Gruppen-Multicast-Adresse für die ausgehende Schnittstelle.

• Anders als Basic Discovery, die symmetrisch ist, ist Extended Discovery asymmetrisch.

  Ein LSR initiiert Extended Discovery mit einem anderen angesprochenen (targeted) LSR, und der angesprochene LSR entscheidet, ob er auf das Targeted Hello antwortet oder es ignoriert. Ein angesprochener LSR, der sich für eine Antwort entscheidet, tut dies, indem er periodisch Targeted Hellos an den initiierenden LSR sendet.

Der Empfang eines LDP Targeted Hello identifiziert eine "Hello-Adjazenz" mit einem potenziellen LDP-Peer, der auf Netzwerkebene erreichbar ist, und den Label-Raum, den der Peer zu verwenden beabsichtigt.

2.5. Aufbau und Aufrechterhaltung von LDP-Sitzungen

2.5.1. LDP-Sitzungsaufbau

Der Austausch von LDP Discovery Hellos zwischen zwei LSRs löst den LDP-Sitzungsaufbau aus. Der Sitzungsaufbau ist ein zweistufiger Prozess:

• Aufbau der Transportverbindung
• Sitzungsinitialisierung

Das Folgende beschreibt den Aufbau einer LDP-Sitzung zwischen den LSRs LSR1 und LSR2 aus der Sicht von LSR1. Es wird davon ausgegangen, dass Hellos ausgetauscht werden, die den Label-Raum LSR1:a für LSR1 und den Label-Raum LSR2:b für LSR2 angeben.

2.5.2. Aufbau der Transportverbindung

Der Austausch von Hellos führt zur Erzeugung einer Hello-Adjazenz bei LSR1, die dazu dient, die Verbindung (L) und die Label-Räume LSR1:a und LSR2:b zu binden.

1. Wenn LSR1 nicht bereits eine LDP-Sitzung für den Austausch der Label-Räume LSR1:a und LSR2:b hat, versucht es, eine TCP-Verbindung für eine neue LDP-Sitzung mit LSR2 zu öffnen.

   LSR1 bestimmt die Transportadressen, die an seinem Ende (A1) und am Ende von LSR2 (A2) der LDP-TCP-Verbindung verwendet werden sollen. Die Adresse A1 wird wie folgt bestimmt:

   a. Wenn LSR1 das optionale Objekt Transport Address (TLV) in den an LSR2 gesendeten Hellos verwendet, um eine Adresse anzukündigen, ist A1 die Adresse, die LSR1 über das optionale Objekt ankündigt;

   b. Wenn LSR1 das optionale Objekt Transport Address nicht verwendet, ist A1 die Quelladresse, die in den an LSR2 gesendeten Hellos verwendet wird.

   In ähnlicher Weise wird die Adresse A2 wie folgt bestimmt:

   a. Wenn LSR2 das optionale Objekt Transport Address verwendet, ist A2 die Adresse, die LSR2 über das optionale Objekt ankündigt;

   b. Wenn LSR2 das optionale Objekt Transport Address nicht verwendet, ist A2 die Quelladresse in den von LSR2 empfangenen Hellos.

2. LSR1 bestimmt, ob er beim Sitzungsaufbau die aktive oder die passive Rolle spielen wird, indem er die Adressen A1 und A2 als vorzeichenlose Ganzzahlen vergleicht. Wenn A1 > A2, spielt LSR1 die aktive Rolle; andernfalls ist er passiv.

   Das Verfahren zum Vergleich von A1 und A2 als vorzeichenlose Ganzzahlen ist:

   • Wenn A1 und A2 nicht zur selben Adressfamilie gehören, sind sie nicht vergleichbar, und es kann keine Sitzung aufgebaut werden.

   • Sei U1 die abstrakte vorzeichenlose Ganzzahl, die man erhält, indem man A1 als Bytefolge behandelt, wobei das in der Nachricht zuerst erscheinende Byte das höchstwertige Byte der Ganzzahl und das in der Nachricht zuletzt erscheinende Byte das niederwertigste Byte der Ganzzahl ist.

     Sei U2 die abstrakte vorzeichenlose Ganzzahl, die auf ähnliche Weise aus A2 erhalten wird.

   • Vergleiche U1 mit U2. Wenn U1 > U2, dann A1 > A2; wenn U1 < U2, dann A1 < A2.

3. Wenn LSR1 aktiv ist, versucht er, die LDP-TCP-Verbindung aufzubauen, indem er sich mit dem bekannten LDP-Port an der Adresse A2 verbindet. Wenn LSR1 passiv ist, wartet er darauf, dass LSR2 die LDP-TCP-Verbindung zu seinem bekannten LDP-Port aufbaut.

Beachten Sie, dass ein LSR, wenn er ein Hello sendet, die Transportadresse für sein Ende der Sitzungsverbindung auswählt und das Hello verwendet, um die Adresse anzukündigen, entweder explizit durch Aufnahme in ein optionales Transport Address TLV oder implizit durch Weglassen des TLV und Verwendung als Hello-Quelladresse.

Ein LSR MUSS (MUST) dieselbe Transportadresse in allen Hellos ankündigen, die denselben Label-Raum ankündigen. Diese Anforderung stellt sicher, dass zwei LSRs, die durch mehrere Hello-Adjazenzen mit denselben Label-Räumen verbunden sind, für jede Adjazenz dieselbe Rolle beim Verbindungsaufbau spielen.

2.5.3. Sitzungsinitialisierung

Nachdem LSR1 und LSR2 eine Transportverbindung aufgebaut haben, verhandeln sie Sitzungsparameter durch den Austausch von LDP Initialization-Nachrichten. Zu den verhandelten Parametern gehören die LDP-Protokollversion, die Labelverteilungsmethode, Timer-Werte, VPI/VCI-(Virtual Path Identifier / Virtual Channel Identifier-)Bereiche für labelgesteuertes ATM, DLCI-(Data Link Connection Identifier-)Bereiche für labelgesteuertes Frame Relay usw.

Eine erfolgreiche Verhandlung schließt den Aufbau einer LDP-Sitzung zwischen LSR1 und LSR2 für die Ankündigung der Label-Räume LSR1:a und LSR2:b ab.

Das Folgende beschreibt die Sitzungsinitialisierung aus der Sicht von LSR1.

Nachdem die Verbindung aufgebaut ist, initiiert LSR1, wenn er die aktive Rolle spielt, die Verhandlung der Sitzungsparameter, indem er eine Initialization-Nachricht an LSR2 sendet. Wenn LSR1 passiv ist, wartet er darauf, dass LSR2 die Parameterverhandlung initiiert.

Im Allgemeinen kann der passive LSR, wenn mehrere Verbindungen zwischen LSR1 und LSR2 und mehrere von jedem anzukündigende Label-Räume vorhanden sind, nicht wissen, welchen Label-Raum er über eine neu aufgebaute TCP-Verbindung ankündigen soll, bis er die LDP Initialization-Nachricht auf der Verbindung empfängt. Die Initialization-Nachricht führt sowohl den LDP Identifier für den Label-Raum des Senders (aktiver LSR) als auch den LDP Identifier für den Label-Raum des Empfängers (passiver LSR) mit.

Indem der passive LSR auf die Initialization-Nachricht von seinem Peer wartet, kann er den vom Peer anzukündigenden Label-Raum (wie aus dem LDP Identifier im PDU-Header der Initialization-Nachricht bestimmt) mit einer zuvor beim Austausch von Hellos erzeugten Hello-Adjazenz abgleichen.

1. Wenn LSR1 die passive Rolle spielt:

   a. Wenn LSR1 eine Initialization-Nachricht empfängt, versucht er, den von der Nachrichten-PDU mitgeführten LDP Identifier mit einer Hello-Adjazenz abzugleichen.

   b. Wenn es eine passende Hello-Adjazenz gibt, legt die Adjazenz den lokalen Label-Raum für die Sitzung fest.

   Als Nächstes prüft LSR1, ob die in der Nachricht vorgeschlagenen Sitzungsparameter akzeptabel sind. Wenn ja, antwortet LSR1 mit einer eigenen Initialization-Nachricht, um die von ihm gewünschten Parameter vorzuschlagen, sowie mit einer KeepAlive-Nachricht, um die Annahme der Parameter von LSR2 zu signalisieren. Wenn die Parameter nicht akzeptabel sind, antwortet LSR1 mit dem Senden einer Session Rejected/Parameters Error Notification-Nachricht und schließt die TCP-Verbindung.

   c. Wenn LSR1 keine passende Hello-Adjazenz finden kann, sendet er eine Session Rejected/No Hello Error Notification-Nachricht und schließt die TCP-Verbindung.

   d. Wenn LSR1 als Antwort auf seine Initialization-Nachricht ein KeepAlive empfängt, ist die Sitzung aus der Sicht von LSR1 betriebsbereit.

   e. Wenn LSR1 eine Error Notification-Nachricht empfängt, hat LSR2 seine vorgeschlagene Sitzung abgelehnt, und LSR1 schließt die TCP-Verbindung.

2. Wenn LSR1 die aktive Rolle spielt:

   a. Wenn LSR1 eine Error Notification-Nachricht empfängt, hat LSR2 seine vorgeschlagene Sitzung abgelehnt, und LSR1 schließt die TCP-Verbindung.

   b. Wenn LSR1 eine Initialization-Nachricht empfängt, prüft er, ob die Sitzungsparameter akzeptabel sind. Wenn ja, antwortet er mit einer KeepAlive-Nachricht. Wenn die Sitzungsparameter nicht akzeptabel sind, sendet LSR1 eine Session Rejected/Parameters Error Notification-Nachricht und schließt die Verbindung.

   c. Wenn LSR1 eine KeepAlive-Nachricht empfängt, hat LSR2 seine vorgeschlagenen Sitzungsparameter akzeptiert.

   d. Wenn LSR1 sowohl eine akzeptable Initialization-Nachricht als auch eine KeepAlive-Nachricht empfangen hat, ist die Sitzung aus der Sicht von LSR1 betriebsbereit.

   Bis die LDP-Sitzung aufgebaut ist, dürfen keine anderen Nachrichten als die in den obigen Verfahren aufgeführten ausgetauscht werden, und die Regeln für die Verarbeitung des U-Bits in LDP-Nachrichten sind außer Kraft gesetzt. Wenn eine andere Nachricht als die in den obigen Verfahren aufgeführten empfangen wird, MUSS (MUST) eine Shutdown msg gesendet und MUSS (MUST) die Transportverbindung geschlossen werden.

Es ist möglich, dass ein Paar inkompatibel konfigurierter LSRs, die sich über die Sitzungsparameter uneinig sind, in eine endlose Nachrichtenfolge gerät, da jeder die Initialization-Nachrichten des anderen mit Error Notification-Nachrichten mit NAK beantwortet.

Ein LSR MUSS (MUST) seine Wiederholungsversuche zum Sitzungsaufbau in Situationen, in denen Initialization-Nachrichten mit NAK beantwortet werden, mit einem exponentiellen Backoff drosseln. Es wird außerdem empfohlen, dass ein LSR, der eine solche Situation erkennt, Maßnahmen ergreift, um einen Operator zu benachrichtigen.

Der Sitzungsaufbauversuch, der auf eine mit NAK beantwortete Initialization-Nachricht folgt, MUSS (MUST) um nicht weniger als 15 Sekunden verzögert werden, und nachfolgende Verzögerungen MÜSSEN (MUST) bis zu einer maximalen Verzögerung von nicht weniger als 2 Minuten anwachsen. Die konkrete Sitzungsaufbauaktion, die verzögert werden muss, ist der Versuch des die aktive Rolle spielenden LSR, die Sitzungstransportverbindung zu öffnen.

Die gedrosselte Folge von Initialization-NAKs wird wahrscheinlich erst enden, wenn ein Eingriff eines Operators einen der LSRs neu konfiguriert. Nach einer solchen Konfigurationsaktion besteht keine weitere Notwendigkeit mehr, nachfolgende Sitzungsaufbauversuche zu drosseln (bis ihre Initialization-Nachrichten mit NAK beantwortet werden).

Aufgrund der asymmetrischen Natur des Sitzungsaufbaus bleibt die Neukonfiguration des passiven LSR für den aktiven LSR unbemerkt, wenn keine weitere Aktion erfolgt. Der Abschnitt "Hello Message" beschreibt einen optionalen Mechanismus, den ein LSR verwenden kann, um potenziellen LDP-Peers zu signalisieren, dass er neu konfiguriert wurde.

2.5.4. Initialisierungs-Zustandsmaschine

Es ist zweckmäßig, das Verhandlungsverhalten von LDP-Sitzungen anhand einer Zustandsmaschine zu beschreiben. Wir definieren die LDP-Zustandsmaschine mit fünf möglichen Zuständen und stellen das Verhalten als Zustandsübergangstabelle und als Zustandsübergangsdiagramm dar. Beachten Sie, dass eine Shutdown-Nachricht als Notification-Nachricht mit einem Status TLV implementiert wird, das einen schwerwiegenden Fehler (fatal error) anzeigt.

            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. Aufrechterhaltung von Hello-Adjazenzen

Eine LDP-Sitzung mit einem Peer hat eine oder mehrere Hello-Adjazenzen.

Eine LDP-Sitzung hat mehrere Hello-Adjazenzen, wenn ein Paar von LSRs durch mehrere Verbindungen verbunden ist, die denselben Label-Raum gemeinsam nutzen; zum Beispiel mehrere PPP-Verbindungen zwischen einem Routerpaar. In dieser Situation tragen die Hellos, die ein LSR auf jeder solchen Verbindung sendet, denselben LDP Identifier.

LDP enthält Mechanismen zur Überwachung der Notwendigkeit einer LDP-Sitzung und ihrer Hello-Adjazenzen.

LDP verwendet den regelmäßigen Empfang von LDP Discovery Hellos, um die Absicht eines Peers anzuzeigen, den durch das Hello identifizierten Label-Raum zu verwenden. Ein LSR unterhält für jede Hello-Adjazenz einen Hold-Timer, den er neu startet, wenn er ein Hello empfängt, das zur Adjazenz passt. Wenn der Timer abläuft, ohne dass ein passendes Hello vom Peer empfangen wurde, schließt LDP daraus, dass der Peer die Labelvermittlung unter Verwendung dieses Label-Raums für diese Verbindung (oder dieses Ziel, im Fall von Targeted Hellos) nicht mehr wünscht oder dass der Peer ausgefallen ist. Der LSR löscht dann die Hello-Adjazenz. Wenn die letzte Hello-Adjazenz für eine LDP-Sitzung gelöscht wird, beendet der LSR die LDP-Sitzung, indem er eine Notification-Nachricht sendet und die Transportverbindung schließt.

2.5.6. Aufrechterhaltung von LDP-Sitzungen

LDP enthält Mechanismen zur Überwachung der Integrität der LDP-Sitzung.

LDP verwendet den regelmäßigen Empfang von LDP-PDUs auf der Sitzungstransportverbindung, um die Integrität der Sitzung zu überwachen. Ein LSR unterhält für jede Peer-Sitzung einen KeepAlive-Timer, den er zurücksetzt, wann immer er eine LDP-PDU vom Sitzungspeer empfängt. Wenn der KeepAlive-Timer abläuft, ohne dass eine LDP-PDU vom Peer empfangen wurde, schließt der LSR daraus, dass die Transportverbindung fehlerhaft ist oder dass der Peer ausgefallen ist, und er beendet die LDP-Sitzung, indem er die Transportverbindung schließt.

Nachdem eine LDP-Sitzung aufgebaut wurde, muss ein LSR dafür sorgen, dass sein Peer mindestens in jedem KeepAlive-Zeitintervall eine LDP-PDU von ihm empfängt, um sicherzustellen, dass der Peer den KeepAlive-Timer der Sitzung neu startet. Der LSR kann jede beliebige Protokollnachricht senden, um diese Anforderung zu erfüllen. In Umständen, in denen ein LSR seinem Peer keine anderen Informationen mitzuteilen hat, sendet er eine KeepAlive-Nachricht.

Ein LSR kann sich jederzeit dafür entscheiden, eine LDP-Sitzung mit einem Peer zu beenden. Sollte er sich dafür entscheiden, informiert er den Peer mit einer Shutdown-Nachricht.

2.6. Labelverteilung und -verwaltung

Die MPLS-Architektur [RFC3031] erlaubt es einem LSR, eine FEC-Label-Bindung als Antwort auf eine explizite Anforderung eines anderen LSR zu verteilen. Dies ist als Downstream On Demand-Labelverteilung bekannt. Sie erlaubt es einem LSR außerdem, Label-Bindungen an LSRs zu verteilen, die sie nicht explizit angefordert haben. [RFC3031] nennt diese Methode der Labelverteilung Unsolicited Downstream; dieses Dokument verwendet den Begriff Downstream Unsolicited.

Beide dieser Labelverteilungstechniken können gleichzeitig im selben Netz verwendet werden. Für eine gegebene LDP-Sitzung muss sich jedoch jeder LSR der von seinem Peer verwendeten Labelverteilungsmethode bewusst sein, um Situationen zu vermeiden, in denen ein Peer, der Downstream Unsolicited-Labelverteilung verwendet, annimmt, dass sein Peer dies ebenfalls tut. Siehe den Abschnitt "Downstream on Demand Label Advertisement".

2.6.1. Labelverteilungs-Steuermodus

Das Verhalten beim erstmaligen Aufbau von LSPs wird davon bestimmt, ob der LSR mit unabhängiger LSP-Steuerung (independent LSP control) oder geordneter LSP-Steuerung (Ordered LSP Control) arbeitet. Ein LSR kann beide Arten der Steuerung als konfigurierbare Option unterstützen.

2.6.1.1. Unabhängige Labelverteilungssteuerung

Bei Verwendung der unabhängigen LSP-Steuerung kann jeder LSR Label-Abbildungen an seine Nachbarn ankündigen, wann immer er möchte. Wenn er beispielsweise im unabhängigen Downstream on Demand-Modus arbeitet, kann ein LSR Anforderungen für Label-Abbildungen sofort beantworten, ohne auf eine Label-Abbildung vom nächsten Hop zu warten. Wenn er im unabhängigen Downstream Unsolicited-Modus arbeitet, kann ein LSR eine Label-Abbildung für eine FEC an seine Nachbarn ankündigen, wann immer er bereit ist, diese FEC labelzuvermitteln.

Eine Folge der Verwendung des unabhängigen Modus ist, dass ein vorgelagertes (upstream) Label angekündigt werden kann, bevor ein nachgelagertes (downstream) Label empfangen wird.

2.6.1.2. Geordnete Labelverteilungssteuerung

Bei Verwendung der geordneten LSP-Steuerung darf ein LSR die Übertragung einer Label-Abbildung nur für eine FEC initiieren, für die er eine Label-Abbildung für den FEC-Next-Hop hat oder für die der LSR der Egress ist. Für jede FEC, für die der LSR nicht der Egress ist und keine Abbildung existiert, MUSS (MUST) der LSR warten, bis ein Label von einem nachgelagerten LSR empfangen wird, bevor er die FEC abbildet und entsprechende Labels an vorgelagerte LSRs weitergibt. Ein LSR kann für einige FECs ein Egress und für andere kein Egress sein.

Ein LSR kann in Bezug auf eine bestimmte FEC unter einer der folgenden Bedingungen als Egress-LSR fungieren:

1. Die FEC bezieht sich auf den LSR selbst (einschließlich einer seiner direkt angeschlossenen Schnittstellen).

2. Der Next-Hop-Router für die FEC liegt außerhalb des Label Switching Network.

3. FEC-Elemente sind durch Überqueren einer Routing-Domänengrenze erreichbar, wie etwa eines anderen Bereichs für OSPF-Summary-Netze oder eines anderen autonomen Systems für OSPF-AS-Externals und BGP-Routen [RFC2328] [RFC4271].

Beachten Sie, dass es sich im Laufe der Zeit ändern kann, ob ein LSR für eine gegebene FEC ein Egress ist, abhängig vom Zustand des Netzes und den Konfigurationseinstellungen des LSR.

2.6.2. Label-Beibehaltungsmodus

Die MPLS-Architektur [RFC3031] führt den Begriff des Label-Beibehaltungsmodus (label retention mode) ein, der festlegt, ob ein LSR eine Label-Bindung für eine FEC beibehält, die von einem Nachbarn erlernt wurde, der nicht sein Next Hop für die FEC ist.

2.6.2.1. Konservativer Label-Beibehaltungsmodus

Im Downstream Unsolicited-Ankündigungsmodus können Label-Mapping-Ankündigungen für alle Routen von allen Peer-LSRs empfangen werden. Bei Verwendung der konservativen Label-Beibehaltung (Conservative Label retention) werden angekündigte Label-Abbildungen nur beibehalten, wenn sie zur Weiterleitung von Paketen verwendet werden (d. h., wenn sie gemäß dem Routing von einem gültigen Next Hop empfangen werden). Wenn er im Downstream on Demand-Modus arbeitet, fordert ein LSR Label-Abbildungen nur vom Next-Hop-LSR gemäß dem Routing an. Da der Downstream on Demand-Modus hauptsächlich verwendet wird, wenn Label-Ersparnis gewünscht ist (z. B. ein ATM-Switch mit begrenztem Cross-Connect-Raum), wird er typischerweise mit dem konservativen Label-Beibehaltungsmodus verwendet.

Der Hauptvorteil des konservativen Modus ist, dass nur die für die Weiterleitung von Daten erforderlichen Labels zugewiesen und beibehalten werden. Dies ist besonders wichtig in LSRs, bei denen der Label-Raum von Natur aus begrenzt ist, wie etwa in einem ATM-Switch. Ein Nachteil des konservativen Modus ist, dass, wenn das Routing den Next Hop für ein bestimmtes Ziel ändert, ein neues Label vom neuen Next Hop beschafft werden muss, bevor gelabelte Pakete weitergeleitet werden können.

2.6.2.2. Liberaler Label-Beibehaltungsmodus

Im Downstream Unsolicited-Ankündigungsmodus können Label-Mapping-Ankündigungen für alle Routen von allen LDP-Peers empfangen werden. Bei Verwendung der liberalen Label-Beibehaltung (Liberal Label retention) wird jede von einem Peer-LSR empfangene Label-Abbildung beibehalten, unabhängig davon, ob der LSR der Next Hop für die angekündigte Abbildung ist. Bei Betrieb im Downstream on Demand-Modus mit liberaler Label-Beibehaltung könnte sich ein LSR dafür entscheiden, Label-Abbildungen für alle bekannten Präfixe von allen Peer-LSRs anzufordern. Beachten Sie jedoch, dass der Downstream on Demand-Modus typischerweise von Geräten wie ATM-Switch-basierten LSRs verwendet wird, für die der konservative Ansatz empfohlen wird.

Der Hauptvorteil des liberalen Label-Beibehaltungsmodus ist, dass die Reaktion auf Routing-Änderungen schnell sein kann, weil die Labels bereits existieren. Der Hauptnachteil des liberalen Modus ist, dass nicht benötigte Label-Abbildungen verteilt und beibehalten werden.

2.6.3. Label-Ankündigungsmodus

Jede Schnittstelle auf einem LSR ist so konfiguriert, dass sie entweder im Downstream Unsolicited- oder im Downstream on Demand-Ankündigungsmodus arbeitet. LSRs tauschen die Ankündigungsmodi während der Initialisierung aus. Der Hauptunterschied zwischen dem Downstream Unsolicited- und dem Downstream on Demand-Modus besteht darin, welcher LSR die Verantwortung für die Initiierung von Mapping-Anforderungen und Mapping-Ankündigungen übernimmt.

2.7. LDP-Identifikatoren und Next-Hop-Adressen

Ein LSR führt erlernte Labels in einer Label-Informationsbasis (Label Information Base, LIB). Wenn er im Downstream Unsolicited-Modus arbeitet, ordnet der LIB-Eintrag für ein Adresspräfix dem Präfix eine Sammlung von (LDP Identifier, Label)-Paaren zu, ein solches Paar für jeden Peer, der ein Label für das Präfix ankündigt.

Wenn sich der Next Hop für ein Präfix ändert, muss der LSR das vom neuen Next Hop angekündigte Label aus der LIB abrufen, um es für die Weiterleitung zu verwenden. Um das Label abzurufen, muss der LSR in der Lage sein, die Next-Hop-Adresse für das Präfix einem LDP Identifier zuzuordnen.

In ähnlicher Weise muss der LSR, wenn er ein Label für ein Präfix von einem LDP-Peer erlernt, bestimmen können, ob dieser Peer derzeit ein Next Hop für das Präfix ist, um zu bestimmen, ob er beginnen muss, das neu erlernte Label beim Weiterleiten von Paketen zu verwenden, die zum Präfix passen. Um diese Entscheidung zu treffen, muss der LSR in der Lage sein, einen LDP Identifier den Adressen des Peers zuzuordnen, um zu prüfen, ob eine von ihnen ein Next Hop für das Präfix ist.

Um LSRs in die Lage zu versetzen, zwischen einem Peer-LDP-Identifier und den Adressen des Peers zuzuordnen, kündigen LSRs ihre Adressen mit LDP Address- und Withdraw Address-Nachrichten an.

Ein LSR sendet eine Address-Nachricht, um seine Adressen einem Peer anzukündigen. Ein LSR sendet eine Withdraw Address-Nachricht, um zuvor angekündigte Adressen von einem Peer zurückzuziehen.

2.8. Schleifenerkennung

Die Schleifenerkennung (Loop Detection) ist eine konfigurierbare Option, die einen Mechanismus bereitstellt, um schleifenförmige (looping) LSPs zu finden und um zu verhindern, dass Label Request-Nachrichten bei Vorhandensein von LSRs ohne Merge-Fähigkeit (non-merge capable) im Kreis laufen.

Der Mechanismus nutzt Path Vector- und Hop Count-TLVs, die von Label Request- und Label Mapping-Nachrichten mitgeführt werden. Er baut auf den folgenden grundlegenden Eigenschaften dieser TLVs auf:

• Ein Path Vector TLV enthält eine Liste der LSRs, die die es enthaltende Nachricht durchlaufen hat. Ein LSR wird in einer Path Vector-Liste durch seinen eindeutigen LSR Identifier (Id) identifiziert, der die ersten vier Oktette seines LDP Identifier sind. Wenn ein LSR eine Nachricht weiterleitet, die ein Path Vector TLV enthält, fügt er seine LSR Id zur Path Vector-Liste hinzu. Ein LSR, der eine Nachricht mit einem Path Vector empfängt, der seine LSR Id enthält, erkennt, dass die Nachricht eine Schleife durchlaufen hat. LDP unterstützt den Begriff einer maximal zulässigen Path Vector-Länge; ein LSR, der erkennt, dass ein Path Vector die maximale Länge erreicht hat, verhält sich so, als hätte die enthaltende Nachricht eine Schleife durchlaufen.

• Ein Hop Count TLV enthält eine Zählung der LSRs, die die enthaltende Nachricht durchlaufen hat. Wenn ein LSR eine Nachricht weiterleitet, die ein Hop Count TLV enthält, erhöht er die Zählung. Ein LSR, der erkennt, dass ein Hop Count einen konfigurierten Maximalwert erreicht hat, verhält sich so, als hätte die enthaltende Nachricht eine Schleife durchlaufen. Konventionsgemäß wird eine Zählung von 0 so interpretiert, dass die Hop-Zahl unbekannt ist. Das Erhöhen eines unbekannten Hop-Zahl-Werts ergibt einen unbekannten Hop-Zahl-Wert (0).

Die folgenden Absätze beschreiben die LDP-Schleifenerkennungsverfahren. Für diese Absätze, und nur für diese Absätze, wird "MUST" neu definiert mit der Bedeutung "MUST if configured for Loop Detection". Die Absätze legen Nachrichten fest, die Path Vector- und Hop Count-TLVs mitführen MÜSSEN (MUST). Beachten Sie, dass das Hop Count TLV und seine Verfahren ohne das Path Vector TLV in Situationen verwendet werden, in denen die Schleifenerkennung nicht konfiguriert ist (siehe [RFC3035] und [RFC3034]).

2.8.1. Label Request-Nachricht

Die Verwendung des Path Vector TLV und des Hop Count TLV verhindert, dass Label Request-Nachrichten in Umgebungen im Kreis laufen, die LSRs ohne Merge-Fähigkeit enthalten.

Die Regeln, die die Verwendung des Hop Count TLV in Label Request-Nachrichten durch LSR R bestimmen, wenn die Schleifenerkennung aktiviert ist, sind die folgenden:

• Die Label Request-Nachricht MUSS (MUST) ein Hop Count TLV enthalten.

• Wenn R die Label Request sendet, weil er ein FEC-Ingress ist, MUSS (MUST) er ein Hop Count TLV mit dem Hop-Zahl-Wert 1 einschließen.

• Wenn R die Label Request als Folge des Empfangs einer Label Request von einem vorgelagerten LSR sendet und wenn die empfangene Label Request ein Hop Count TLV enthält, MUSS (MUST) R den empfangenen Hop-Zahl-Wert um 1 erhöhen und MUSS (MUST) den resultierenden Wert in einem Hop Count TLV zusammen mit der Label Request-Nachricht an seinen nächsten Hop weitergeben.

Die Regeln, die die Verwendung des Path Vector TLV in Label Request-Nachrichten durch LSR R bestimmen, wenn die Schleifenerkennung aktiviert ist, sind die folgenden:

• Wenn R die Label Request sendet, weil er ein FEC-Ingress ist, dann MUSS (MUST) R, wenn er nicht merge-fähig ist, ein Path Vector TLV der Länge 1 einschließen, das seine eigene LSR Id enthält.

• Wenn R die Label Request als Folge des Empfangs einer Label Request von einem vorgelagerten LSR sendet, dann gilt, wenn die empfangene Label Request ein Path Vector TLV enthält oder wenn R nicht merge-fähig ist:

  R MUSS (MUST) seine eigene LSR Id zum Path Vector hinzufügen und MUSS (MUST) den resultierenden Path Vector zusammen mit der Label Request-Nachricht an seinen nächsten Hop weitergeben. Wenn die Label Request kein Path Vector TLV enthält, MUSS (MUST) R ein Path Vector TLV der Länge 1 einschließen, das seine eigene LSR Id enthält.

Beachten Sie, dass R, wenn er eine Label Request-Nachricht für eine bestimmte FEC empfängt, und R zuvor eine Label Request-Nachricht für diese FEC an seinen nächsten Hop gesendet und noch keine Antwort erhalten hat, und wenn R beabsichtigt, die neu empfangene Label Request mit der bestehenden offenen Label Request zusammenzuführen, dann die Label Request nicht an den nächsten Hop weiterleitet.

Wenn R eine Label Request-Nachricht von seinem nächsten Hop mit einem Hop Count TLV empfängt, das den konfigurierten Maximalwert überschreitet, oder mit einem Path Vector TLV, das seine eigene LSR Id enthält oder das die maximal zulässige Länge überschreitet, dann erkennt R, dass die Label Request-Nachricht im Kreis gelaufen ist.

Wenn R eine Schleife erkennt, MUSS (MUST) er eine Loop Detected Notification-Nachricht an die Quelle der Label Request-Nachricht senden und die Label Request-Nachricht verwerfen.

2.8.2. Label Mapping-Nachricht

Die Verwendung des Path Vector TLV und des Hop Count TLV in der Label Mapping-Nachricht bietet einen Mechanismus, um schleifenförmige LSPs zu finden und zu beenden. Wenn ein LSR eine Label Mapping-Nachricht von einem nächsten Hop empfängt, wird die Nachricht wie unten angegeben vorgelagert (upstream) weitergegeben, bis ein Ingress-LSR erreicht oder eine Schleife gefunden wird.

Die Regeln, die die Verwendung des Hop Count TLV in Label Mapping-Nachrichten bestimmen, die von einem LSR R gesendet werden, wenn die Schleifenerkennung aktiviert ist, sind die folgenden:

• R MUSS (MUST) ein Hop Count TLV einschließen.

• Wenn R der Egress ist, MUSS (MUST) der Hop-Zahl-Wert 1 sein.

• Wenn die Label Mapping-Nachricht gesendet wird, um eine vom nächsten Hop empfangene Label Mapping-Nachricht an einen vorgelagerten Peer weiterzugeben, MUSS (MUST) der Hop-Zahl-Wert wie folgt bestimmt werden:

  o Wenn R Mitglied der Randmenge (edge set) einer LSR-Domäne ist, deren LSRs keine 'TTL-Dekrementierung' durchführen (z. B. eine ATM-LSR-Domäne oder eine Frame-Relay-LSR-Domäne), und der vorgelagerte Peer sich innerhalb dieser Domäne befindet, MUSS (MUST) R die Hop-Zahl vor der Weitergabe der Nachricht auf 1 zurücksetzen.

  o Andernfalls MUSS (MUST) R die vom nächsten Hop empfangene Hop-Zahl vor der Weitergabe der Nachricht erhöhen.

• Wenn die Label Mapping-Nachricht nicht gesendet wird, um eine Label Mapping-Nachricht weiterzugeben, MUSS (MUST) der Hop-Zahl-Wert das Ergebnis der Erhöhung der aktuellen Kenntnis von R über die Hop-Zahl sein, die aus früheren Label Mapping-Nachrichten erlernt wurde. Beachten Sie, dass dieser Hop-Zahl-Wert unbekannt sein wird, wenn R keine Label Mapping-Nachricht vom nächsten Hop empfangen hat.

Jede Label Mapping-Nachricht KANN (MAY) ein Path Vector TLV enthalten. Die Regeln, die die verpflichtende Verwendung des Path Vector TLV in Label Mapping-Nachrichten bestimmen, die von LSR R gesendet werden, wenn die Schleifenerkennung aktiviert ist, sind die folgenden:

• Wenn R der Egress ist, muss die Label Mapping-Nachricht kein Path Vector TLV enthalten.

• Wenn R die Label Mapping-Nachricht sendet, um eine vom nächsten Hop empfangene Label Mapping-Nachricht an einen vorgelagerten Peer weiterzugeben, dann gilt:

  o Wenn R merge-fähig ist und wenn R zuvor keine Label Mapping-Nachricht an den vorgelagerten Peer gesendet hat, dann MUSS (MUST) er ein Path Vector TLV einschließen.

  o Wenn die empfangene Nachricht eine unbekannte Hop-Zahl enthält, dann MUSS (MUST) R ein Path Vector TLV einschließen.

  o Wenn R zuvor eine Label Mapping-Nachricht an den vorgelagerten Peer gesendet hat, dann MUSS (MUST) er ein Path Vector TLV einschließen, wenn die empfangene Nachricht einen Anstieg der LSP-Hop-Zahl, eine Änderung der Hop-Zahl von unbekannt zu bekannt oder eine Änderung von bekannt zu unbekannt meldet.

Wenn die obigen Regeln verlangen, dass R ein Path Vector TLV in die Label Mapping-Nachricht aufnimmt, berechnet R es wie folgt:

o Wenn die empfangene Label Mapping-Nachricht einen Path Vector enthielt, MUSS (MUST) der vorgelagert gesendete Path Vector das Ergebnis des Hinzufügens der LSR Id von R zum empfangenen Path Vector sein.

o Wenn die empfangene Nachricht keinen Path Vector hatte, MUSS (MUST) der vorgelagert gesendete Path Vector ein Path Vector der Länge 1 sein, das die LSR Id von R enthält.

• Wenn die Label Mapping-Nachricht nicht gesendet wird, um eine empfangene Nachricht vorgelagert weiterzugeben, MUSS (MUST) die Label Mapping-Nachricht ein Path Vector der Länge 1 einschließen, das die LSR Id von R enthält.

  Wenn R eine Label Mapping-Nachricht von seinem nächsten Hop mit einem Hop Count TLV empfängt, das den konfigurierten Maximalwert überschreitet, oder mit einem Path Vector TLV, das seine eigene LSR Id enthält oder das die maximal zulässige Länge überschreitet, dann erkennt R, dass die entsprechende LSP eine Schleife enthält.

  Wenn R eine Schleife erkennt, MUSS (MUST) er die Verwendung des Labels für die Weiterleitung beenden, die Label Mapping-Nachricht verwerfen und den Status Loop Detected an die Quelle der Label Mapping-Nachricht signalisieren.

2.8.3. Erörterung

Wenn Schleifenerkennung in einer MPLS-Domäne gewünscht wird, sollte sie in ALLEN LSRs innerhalb dieser MPLS-Domäne aktiviert werden, da sie sonst nicht ordnungsgemäß funktioniert und zu unentdeckten Schleifen oder zu fälschlich erkannten Schleifen führen kann.

Von LSRs, die für die Schleifenerkennung konfiguriert sind, wird NICHT erwartet, dass sie die Path Vectors als Teil des LSP-Zustands speichern.

Beachten Sie, dass in einem Netz, in dem nur LSRs ohne Merge-Fähigkeit vorhanden sind, Path Vectors nachgelagert (downstream) von Ingress zum Egress weitergegeben werden und nicht vorgelagert. Selbst wenn Merge unterstützt wird, müssen Path Vectors nicht vorgelagert entlang einer LSP weitergegeben werden, von der bekannt ist, dass sie den Egress erreicht. Wenn ein LSR eine Änderung des nächsten Hops erfährt, muss er Path Vectors nur dann vorgelagert weitergeben, wenn er anhand der Hop-Zahl nicht erkennen kann, dass die Änderung des nächsten Hops nicht zu einer Schleife führt.

Im Fall der geordneten Labelverteilung werden Label Mapping-Nachrichten vom Egress zum Ingress weitergegeben, wodurch unterwegs auf natürliche Weise der Path Vector entsteht. Im Fall der unabhängigen Labelverteilung kann ein LSR eine Label Mapping-Nachricht für eine FEC erzeugen, bevor er eine Label Mapping-Nachricht von seinem nachgelagerten Peer für diese FEC empfängt. In diesem Fall wird die anschließend für die FEC vom nachgelagerten Peer empfangene Label Mapping-Nachricht als Aktualisierung der LSP-Attribute behandelt, und die Label Mapping-Nachricht muss vorgelagert weitergegeben werden. Daher wird empfohlen, die Schleifenerkennung in Verbindung mit der geordneten Labelverteilung zu konfigurieren, um die Anzahl der Label Mapping-Aktualisierungsnachrichten zu minimieren.

2.9. Authentizität und Integrität von LDP-Nachrichten

Dieser Abschnitt legt einen Mechanismus fest, der davor schützt, dass gefälschte TCP-Segmente in die Verbindungsströme von LDP-Sitzungen eingebracht werden. Die Verwendung dieses Mechanismus MUSS (MUST) als konfigurierbare Option unterstützt werden.

Der Mechanismus basiert auf der Verwendung der TCP MD5 Signature Option, die in [RFC2385] zur Verwendung durch BGP [RFC4271] spezifiziert ist. Siehe [RFC1321] für eine Spezifikation der MD5-Hashfunktion. Aus Sicht der Standardsreife verhält sich das vorliegende Dokument zu [RFC2385] ebenso wie [RFC4271] zu [RFC2385]. Dies wird in [RFC4278] erläutert.

2.9.1. TCP MD5 Signature Option

Die folgenden Zitate aus [RFC2385] skizzieren die durch die Verwendung der TCP MD5 Signature Option erreichten Sicherheitseigenschaften und fassen ihre Funktionsweise zusammen:

"IESG-Hinweis (IESG Note)

  Dieses Dokument beschreibt die gegenwärtig bestehende Praxis zum Schutz von BGP gegen bestimmte einfache Angriffe. Es ist bekannt, dass es Sicherheitsschwächen gegenüber konzertierten Angriffen aufweist."

"Zusammenfassung (Abstract)

  Diese Memorandum beschreibt eine TCP-Erweiterung zur Verbesserung der Sicherheit von BGP. Sie definiert eine neue TCP-Option zum Transport eines MD5-[RFC1321-]Digests in einem TCP-Segment. Dieser Digest wirkt wie eine Signatur für dieses Segment und enthält Informationen, die nur den Verbindungsendpunkten bekannt sind. Da BGP TCP als Transport verwendet, verringert die Verwendung dieser Option in der in diesem Dokument beschriebenen Weise die Gefahr durch bestimmte Sicherheitsangriffe auf BGP erheblich."

"Einleitung (Introduction)

  Die Hauptmotivation für diese Option ist es, BGP in die Lage zu versetzen, sich gegen das Einbringen gefälschter TCP-Segmente in den Verbindungsstrom zu schützen. Von besonderer Bedeutung sind dabei TCP-Resets.

  Um eine Verbindung mit dem in diesem Dokument beschriebenen Schema zu fälschen, müsste ein Angreifer nicht nur TCP-Sequenznummern erraten, sondern auch das im MD5-Digest enthaltene Passwort erlangt haben. Dieses Passwort erscheint niemals im Verbindungsstrom, und die konkrete Form des Passworts obliegt der Anwendung. Es könnte sich sogar während der Lebensdauer einer bestimmten Verbindung ändern, solange diese Änderung an beiden Enden synchronisiert ist (in manchen TCP-Implementierungen kann die Neuübertragung bei sich ändernden Passwörtern jedoch problematisch werden).

  Schließlich gibt es keine Aushandlung für die Verwendung dieser Option in einer Verbindung; ob deren Verbindungen die Option verwenden, ist vielmehr allein eine Frage der Standortrichtlinie."

"MD5 als Hash-Algorithmus (MD5 as a Hashing Algorithm)

  Seitdem dieses Memorandum erstmals (unter einem anderen Titel) herausgegeben wurde, hat sich gezeigt, dass der MD5-Algorithmus anfällig für Kollisionssuchangriffe [Dobb] ist, und er wird von einigen für diese Art von Anwendung als nicht ausreichend stark angesehen.

  Dieses Memorandum spezifiziert dennoch weiterhin den MD5-Algorithmus, da die Option bereits operativ eingesetzt wurde und kein Feld für den "Algorithmustyp" definiert war, das ein Upgrade unter derselben Optionsnummer ermöglicht hätte. Das ursprüngliche Dokument spezifizierte kein Typfeld, da dies mindestens ein weiteres Byte erfordert hätte, und man war damals der Ansicht, dass 19 Byte für die vollständige Option (die in TCP-Implementierungen wahrscheinlich auf 20 Byte aufgefüllt würde) eine zu große Verschwendung des ohnehin begrenzten Optionsraums wären.

  Dies verhindert nicht die Einführung einer weiteren ähnlichen Option, die einen anderen Hash-Algorithmus (wie SHA-1) verwendet. Wenn die meisten Implementierungen die 18-Byte-Option, wie definiert, ohnehin auf 20 Byte auffüllen, wäre es außerdem ebenso gut, eine neue Option zu definieren, die ein Feld für den Algorithmustyp enthält.

  Dies müsste jedoch in einem anderen Dokument behandelt werden."

Ende der Zitate aus [RFC2385].

2.9.2. Verwendung der TCP MD5 Signature Option durch LDP

LDP verwendet die TCP MD5 Signature Option wie folgt:

• Die Verwendung der MD5 Signature Option für LDP-TCP-Verbindungen ist eine konfigurierbare LSR-Option.

• Ein LSR, der die MD5 Signature Option verwendet, wird mit einem Passwort (gemeinsames Geheimnis, shared secret) für jeden potenziellen LDP-Peer konfiguriert.

• Der LSR wendet den MD5-Algorithmus wie in [RFC2385] spezifiziert an, um den MD5-Digest für ein an einen Peer zu sendendes TCP-Segment zu berechnen. Diese Berechnung nutzt sowohl das Peer-Passwort als auch das TCP-Segment.

• Wenn der LSR ein TCP-Segment mit einem MD5-Digest empfängt, validiert er das Segment, indem er den MD5-Digest berechnet (unter Verwendung seiner eigenen Aufzeichnung des Passworts) und den berechneten Digest mit dem empfangenen Digest vergleicht. Wenn der Vergleich fehlschlägt, wird das Segment ohne jede Antwort an den Absender verworfen.

• Der LSR ignoriert LDP Hellos von jedem LSR, für den kein Passwort konfiguriert wurde. Dies stellt sicher, dass der LSR LDP-TCP-Verbindungen nur mit LSRs aufbaut, für die ein Passwort konfiguriert wurde.

2.10. Labelverteilung für explizit geroutete LSPs

Traffic Engineering [RFC2702] wird voraussichtlich eine wichtige MPLS-Anwendung sein. Die MPLS-Unterstützung für Traffic Engineering verwendet explizit geroutete LSPs, die nicht den normal gerouteten (Hop-by-Hop-)Pfaden folgen müssen, wie sie durch zielbasierte Routing-Protokolle bestimmt werden. CR-LDP [CRLDP] definiert Erweiterungen zu LDP, um LDP zum Aufbau explizit gerouteter LSPs zu verwenden.