3. Protokollspezifikation

Die vorangegangenen Abschnitte, die den LDP-Betrieb beschreiben, haben Szenarien erörtert, die den Austausch von Nachrichten zwischen LDP-Peers betreffen. Dieser Abschnitt legt die Nachrichtenkodierungen und die Verfahren zur Verarbeitung der Nachrichten fest.

LDP-Nachrichtenaustausch erfolgt durch das Senden von LDP-Protokolldateneinheiten (Protocol Data Units, PDUs) über die TCP-Verbindungen der LDP-Sitzung.

Jede LDP-PDU kann eine oder mehrere LDP-Nachrichten transportieren. Beachten Sie, dass die Nachrichten in einer LDP-PDU nicht zueinander in Beziehung stehen müssen. Beispielsweise könnte eine einzelne PDU eine Nachricht transportieren, die FEC-Label-Bindungen für mehrere FECs ankündigt, eine weitere Nachricht, die Label-Bindungen für mehrere andere FECs anfordert, und eine dritte Notification-Nachricht, die ein Ereignis signalisiert.

3.1. LDP-PDUs

Jede LDP-PDU besteht aus einem LDP-Header, gefolgt von einer oder mehreren LDP-Nachrichten. Der LDP-Header ist:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Version                      |         PDU Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         LDP Identifier                        |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version Eine vorzeichenlose Ganzzahl aus zwei Oktetten, die die Versionsnummer des Protokolls enthält. Diese Version der Spezifikation legt LDP-Protokollversion 1 fest.

PDU Length Eine Ganzzahl aus zwei Oktetten, die die Gesamtlänge dieser PDU in Oktetten angibt, ohne die Felder Version und PDU Length.

Die maximal zulässige PDU Length ist verhandelbar, wenn eine LDP-Sitzung initialisiert wird. Vor Abschluss der Verhandlung beträgt die maximal zulässige Länge 4096 Byte.

LDP Identifier Ein Feld aus sechs Oktetten, das den Label-Raum des sendenden LSR, für den diese PDU gilt, eindeutig identifiziert. Die ersten vier Oktette identifizieren den LSR und MÜSSEN (MUST) ein global eindeutiger Wert sein. Er SOLLTE (SHOULD) eine dem LSR zugewiesene 32-Bit-Router-Id sein, die auch verwendet wird, um ihn in Loop Detection Path Vectors zu identifizieren. Die letzten beiden Oktette identifizieren einen Label-Raum innerhalb des LSR. Für einen plattformweiten Label-Raum SOLLTEN (SHOULD) beide null sein.

Beachten Sie, dass es keine Ausrichtungsanforderung für das erste Oktett einer LDP-PDU gibt.

3.2. LDP-Verfahren

LDP definiert Nachrichten, TLVs und Verfahren in den folgenden Bereichen:

• Peer-Discovery
• Sitzungsverwaltung
• Labelverteilung
• Benachrichtigung über Fehler und Hinweisinformationen

Die folgenden Abschnitte beschreiben die Nachrichten- und TLV-Kodierungen für diese Bereiche und die für sie geltenden Verfahren.

Die Labelverteilungsverfahren sind komplex und lassen sich nur schwer vollständig, kohärent und eindeutig als eine Sammlung separater Nachrichten- und TLV-Spezifikationen beschreiben.

Anhang A, "LDP Label Distribution Procedures", beschreibt die Labelverteilungsverfahren anhand von Labelverteilungsereignissen, die bei einem LSR auftreten können, und wie der LSR darauf reagieren muss. Anhang A ist die Spezifikation der LDP-Labelverteilungsverfahren. Wenn ein an anderer Stelle in diesem Dokument beschriebenes Verfahren mit Anhang A in Konflikt steht, legt Anhang A das LDP-Verhalten fest.

3.3. Type-Length-Value-Kodierung

LDP verwendet ein Type-Length-Value-(TLV-)Kodierungsschema, um einen Großteil der in LDP-Nachrichten transportierten Informationen zu kodieren.

Ein LDP TLV wird als ein Feld aus 2 Oktetten kodiert, das 14 Bits zur Angabe eines Type und 2 Bits zur Angabe des Verhaltens verwendet, wenn ein LSR den Type nicht erkennt, gefolgt von einem Length-Feld aus 2 Oktetten, gefolgt von einem Value-Feld variabler Länge.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|        Type               |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                             Value                             |
~                                                               ~
|                                                               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U-bit Unknown TLV bit. Bei Empfang eines unbekannten TLV MUSS (MUST), wenn U nicht gesetzt ist (=0), eine Benachrichtigung an den Nachrichtenursprung zurückgesendet und die gesamte Nachricht ignoriert werden; wenn U gesetzt ist (=1), MUSS (MUST) das unbekannte TLV stillschweigend ignoriert und der Rest der Nachricht verarbeitet werden, als ob das unbekannte TLV nicht existierte. Die folgenden Abschnitte, die TLVs definieren, geben einen Wert für das U-bit an.

F-bit Forward unknown TLV bit. Dieses Bit gilt nur, wenn das U-bit gesetzt ist und die das unbekannte TLV enthaltende LDP-Nachricht weitergeleitet werden soll. Wenn F nicht gesetzt ist (=0), wird das unbekannte TLV nicht mit der enthaltenden Nachricht weitergeleitet; wenn F gesetzt ist (=1), wird das unbekannte TLV mit der enthaltenden Nachricht weitergeleitet. Die folgenden Abschnitte, die TLVs definieren, geben einen Wert für das F-bit an. Durch Setzen sowohl des U- als auch des F-Bits kann ein TLV als undurchsichtige (opaque) Daten durch Knoten propagiert werden, die das TLV nicht erkennen.

Type Kodiert, wie das Value-Feld zu interpretieren ist.

Length Gibt die Länge des Value-Felds in Oktetten an.

Value Oktettfolge von Length Oktetten, die gemäß der Angabe im Type-Feld zu interpretierende Informationen kodiert.

Beachten Sie, dass es keine Ausrichtungsanforderung für das erste Oktett eines TLV gibt.

Beachten Sie, dass das Value-Feld selbst TLV-Kodierungen enthalten kann. Das heißt, TLVs können verschachtelt sein.

Das TLV-Kodierungsschema ist sehr allgemein. Prinzipiell könnte alles, was in einer LDP-PDU erscheint, als TLV kodiert werden. Diese Spezifikation nutzt das TLV-Schema nicht in seiner vollen Allgemeinheit. Es wird dort nicht verwendet, wo seine Allgemeinheit unnötig ist und seine Verwendung unnötig Platz verschwenden würde. Dies sind üblicherweise Stellen, an denen der Typ eines zu kodierenden Werts bekannt ist, beispielsweise durch seine Position in einer Nachricht oder einem umschließenden TLV, und die Länge des Werts entweder fest ist oder sich ohne Weiteres aus der Wertkodierung selbst ableiten lässt.

Einige der für LDP definierten TLVs sind einander ähnlich. Beispielsweise gibt es ein Generic Label TLV, ein ATM Label TLV und ein Frame Relay TLV; siehe die Abschnitte "Generic Label TLV", "ATM Label TLV" und "Frame Relay TLV".

Obwohl man TLVs, die auf diese Weise verwandt sind, im Hinblick auf einen TLV-Typ, der eine TLV-Klasse angibt, und einen TLV-Subtyp, der eine bestimmte Art von TLV innerhalb dieser Klasse angibt, betrachten könnte, formalisiert diese Spezifikation den Begriff eines TLV-Subtyps nicht.

Die Spezifikation weist verwandten TLVs, wie den Label-TLVs, Typwerte aus einem zusammenhängenden Block im 16-Bit-TLV-Typnummernraum zu.

Der Abschnitt "TLV Summary" listet die in dieser Version des Protokolls definierten TLVs und den Abschnitt in diesem Dokument auf, der jedes beschreibt.