3.4. TLV-Kodierungen für häufig verwendete Parameter
Es gibt mehrere Parameter, die von mehr als einer LDP-Nachricht verwendet werden. Die TLV-Kodierungen für diese häufig verwendeten Parameter werden in diesem Abschnitt spezifiziert.
3.4.1. FEC TLV
Labels werden an Forwarding-Equivalence-Classes (FECs) gebunden. Eine FEC ist eine Liste von einem oder mehreren FEC-Elementen. Das FEC TLV kodiert FEC-Elemente.
Seine Kodierung 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FEC (0x0100) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Element 1 bis FEC Element n Es gibt mehrere Typen von FEC-Elementen; siehe den Abschnitt "FECs". Die Kodierung des FEC-Elements hängt vom Typ des FEC-Elements ab.
Ein FEC Element-Wert wird als ein Feld aus 1 Oktett, das den Elementtyp angibt, und ein Feld variabler Länge, das der typabhängige Elementwert ist, kodiert. Beachten Sie, dass, obwohl die Darstellung des FEC-Elementwerts typabhängig ist, die FEC-Elementkodierung selbst eine ist, bei der die standardmäßige LDP-TLV-Kodierung nicht verwendet wird.
Die Kodierung des Werts des FEC Element ist:
FEC Element Type Value
type name
Wildcard 0x01 No value; i.e., 0 value octets;
see below.
Prefix 0x02 See below.
Beachten Sie, dass diese Version von LDP die Verwendung mehrerer FEC Elements pro FEC nur für die Label Mapping-Nachricht unterstützt. Die Verwendung mehrerer FEC Elements in anderen Nachrichten ist in dieser Version nicht zulässig und ist Gegenstand zukünftiger Studien.
Wildcard FEC Element
Nur in den Nachrichten Label Withdraw und Label Release zu verwenden. Zeigt an, dass der Entzug/die Freigabe auf alle FECs anzuwenden ist, die innerhalb des folgenden Label-TLV mit dem Label verbunden sind. Muss das einzige FEC Element im FEC TLV sein.
Kodierung des Werts des Prefix FEC Element:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family
Zwei Oktette, die einen Wert aus ADDRESS FAMILY NUMBERS in [ASSIGNED_AF] enthalten, der die Adressfamilie für das Adresspräfix im Feld Prefix kodiert.
PreLen
Eine vorzeichenlose Ganzzahl aus einem Oktett, die die Länge des folgenden Adresspräfixes in Bits enthält. Eine Länge von null zeigt ein Präfix an, das auf alle Adressen passt (das Standardziel, default destination); in diesem Fall ist das Prefix selbst null Oktette lang.
Prefix
Ein gemäß dem Feld Address Family kodiertes Adresspräfix, dessen Länge in Bits im Feld PreLen angegeben wurde, auf eine Byte-Grenze aufgefüllt.
3.4.1.1. FEC-Verfahren
Wenn ein LSR beim Dekodieren eines FEC TLV auf ein FEC Element mit einer Address Family stößt, die er nicht unterstützt, SOLLTE (SHOULD) er die Dekodierung des FEC TLV beenden, die Verarbeitung der das TLV enthaltenden Nachricht abbrechen und eine Notification-Nachricht "Unsupported Address Family" an seinen LDP-Peer senden, die einen Fehler signalisiert.
Wenn er auf einen FEC Element-Typ stößt, den er nicht dekodieren kann, SOLLTE (SHOULD) er die Dekodierung des FEC TLV beenden, die Verarbeitung der das TLV enthaltenden Nachricht abbrechen und eine Notification-Nachricht "Unknown FEC" an seinen LDP-Peer senden, die einen Fehler signalisiert.
3.4.2. Label TLVs
Label TLVs kodieren Labels. Label TLVs werden von den Nachrichten mitgeführt, die zum Ankündigen, Anfordern, Freigeben und Entziehen von Label-Abbildungen verwendet werden.
Es gibt mehrere verschiedene Arten von Label TLVs, die in Situationen erscheinen können, die ein Label TLV erfordern.
3.4.2.1. Generic Label TLV
Ein LSR verwendet Generic Label TLVs, um Labels für die Verwendung auf Verbindungen zu kodieren, bei denen die Labelwerte unabhängig von der zugrunde liegenden Verbindungstechnologie sind. Beispiele für solche Verbindungen sind PPP und Ethernet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Dies ist ein 20-Bit-Labelwert, der als 20-Bit-Zahl in einem Feld aus 4 Oktetten wie folgt dargestellt wird:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Weitere Informationen finden Sie in [RFC3032].
3.4.2.2. ATM Label TLV
Ein LSR verwendet ATM Label TLVs, um Labels für die Verwendung auf ATM-Verbindungen zu kodieren.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| ATM Label (0x0201) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| V | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res Dieses Feld ist reserviert. Es MUSS (MUST) bei der Übertragung auf null gesetzt und MUSS (MUST) beim Empfang ignoriert werden.
V-bits Zwei-Bit-Vermittlungsanzeiger. Wenn V-bits 00 ist, sind sowohl der VPI als auch der VCI von Bedeutung. Wenn V-bits 01 ist, ist nur das Feld VPI von Bedeutung. Wenn V-bit 10 ist, ist nur der VCI von Bedeutung.
VPI Virtual Path Identifier. Wenn der VPI weniger als 12 Bits umfasst, SOLLTE (SHOULD) er in diesem Feld rechtsbündig stehen, und die vorangehenden Bits SOLLTEN (SHOULD) auf 0 gesetzt werden.
VCI Virtual Channel Identifier. Wenn der VCI weniger als 16 Bits umfasst, SOLLTE (SHOULD) er im Feld rechtsbündig stehen, und die vorangehenden Bits MÜSSEN (MUST) auf 0 gesetzt werden. Wenn im Feld V-bits Virtual Path Switching angezeigt wird, dann MUSS (MUST) dieses Feld vom Empfänger ignoriert und vom Sender auf 0 gesetzt werden.
3.4.2.3. Frame Relay Label TLV
Ein LSR verwendet Frame Relay Label TLVs, um Labels für die Verwendung auf Frame-Relay-Verbindungen zu kodieren.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res Dieses Feld ist reserviert. Es MUSS (MUST) bei der Übertragung auf null gesetzt und MUSS (MUST) beim Empfang ignoriert werden.
Len Dieses Feld gibt die Anzahl der Bits des DLCI an. Die folgenden Werte werden unterstützt:
0 = 10 bits of DLCI
2 = 23 bits of DLCI
Die Len-Werte 1 und 3 sind reserviert.
DLCI Der Data Link Connection Identifier
Für einen 10-Bit-DLCI ist die Kodierung:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| 0 | 10-bit DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Für einen 23-Bit-DLCI ist die Kodierung:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| 23-bit DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Weitere Informationen finden Sie in [RFC3034].
3.4.3. Address List TLV
Das Address List TLV erscheint in den Nachrichten Address und Address Withdraw.
Seine Kodierung 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Addresses |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family Zwei Oktette, die einen Wert aus ADDRESS FAMILY NUMBERS in [ASSIGNED_AF] enthalten, der die im Feld Addresses enthaltenen Adressen kodiert.
Addresses Eine Liste von Adressen aus der angegebenen Address Family. Die Kodierung der einzelnen Adressen hängt von der Address Family ab.
Die folgenden Adresskodierungen werden von dieser Version des Protokolls definiert:
Address Family Address Encoding
IPv4 4 octet full IPv4 address
IPv6 16 octet full IPv6 address
3.4.4. Hop Count TLV
Das Hop Count TLV erscheint als optionales Feld in Nachrichten, die LSPs aufbauen. Es berechnet die Anzahl der LSR-Hops entlang einer LSP, während die LSP aufgebaut wird.
Beachten Sie, dass die Aufbauverfahren für LSPs, die ATM- und Frame-Relay-Verbindungen durchlaufen, die Verwendung des Hop Count TLV erfordern (siehe [RFC3035] und [RFC3034]).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Hop Count (0x0103) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC Value |
+-+-+-+-+-+-+-+-+
HC Value Vorzeichenlose Ganzzahl aus 1 Oktett als Hop-Zahl-Wert.
3.4.4.1. Hop Count-Verfahren
Während des Aufbaus einer LSP kann ein LSR R eine Label Mapping- oder Label Request-Nachricht für die LSP empfangen, die das Hop Count TLV enthält. Wenn dies der Fall ist, SOLLTE (SHOULD) er den Hop-Zahl-Wert aufzeichnen.
Wenn LSR R dann die Label Mapping-Nachricht für die LSP an einen vorgelagerten Peer oder die Label Request-Nachricht an einen nachgelagerten Peer weiterleitet, um den LSP-Aufbau fortzusetzen, muss er eine Hop-Zahl bestimmen, die in die weitergegebene Nachricht aufzunehmen ist, und zwar wie folgt:
-
Wenn die Nachricht eine Label Request-Nachricht ist, MUSS (MUST) R die empfangene Hop-Zahl erhöhen;
-
Wenn die Nachricht eine Label Mapping-Nachricht ist, bestimmt R die Hop-Zahl wie folgt:
o Wenn R Mitglied der Randmenge (edge set) einer LSR-Domäne ist, deren LSRs keine 'TTL-Dekrementierung' durchführen, 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 empfangene Hop-Zahl erhöhen.
Der erste LSR in der LSP (Ingress für eine Label Request-Nachricht, Egress für eine Label Mapping-Nachricht) SOLLTE (SHOULD) den Hop-Zahl-Wert auf 1 setzen.
Konventionsgemäß zeigt ein Wert von 0 eine unbekannte Hop-Zahl an. Das Ergebnis der Erhöhung einer unbekannten Hop-Zahl ist selbst eine unbekannte Hop-Zahl (0).
Die Verwendung des Werts für eine unbekannte Hop-Zahl verringert den Signalisierungsaufwand erheblich, wenn unabhängige Steuerung verwendet wird. Wenn eine neue LSP aufgebaut wird, beginnt jeder LSR mit einer unbekannten Hop-Zahl. Das Hinzufügen eines neuen LSR, dessen Hop-Zahl ebenfalls unbekannt ist, führt nicht dazu, dass eine Hop-Zahl-Aktualisierung vorgelagert weitergegeben wird, da die Hop-Zahl unbekannt bleibt. Wenn der Egress schließlich zur LSP hinzugefügt wird, geben die LSRs Hop-Zahl-Aktualisierungen über Label Mapping-Nachrichten vorgelagert weiter.
Ohne Verwendung der unbekannten Hop-Zahl müsste jedes Mal, wenn ein neuer LSR zur LSP hinzugefügt wird, eine Hop-Zahl-Aktualisierung vorgelagert weitergegeben werden, wenn der neue LSR näher am Egress liegt als alle anderen LSRs. Diese Aktualisierungen sind nutzloser Aufwand, da sie die Hop-Zahl zum Egress nicht widerspiegeln.
Aus der Perspektive des Ingress-Knotens impliziert die Tatsache, dass die Hop-Zahl unbekannt ist, nichts darüber, ob ein auf der LSP gesendetes Paket tatsächlich den Egress erreichen wird. Sie impliziert nur, dass die Hop-Zahl-Aktualisierung vom Egress den Ingress noch nicht erreicht hat.
Wenn ein LSR eine Nachricht empfängt, die ein Hop Count TLV enthält, MUSS (MUST) er den Hop-Zahl-Wert prüfen, um zu bestimmen, ob die Hop-Zahl seinen konfigurierten maximal zulässigen Wert überschritten hat. Wenn ja, MUSS (MUST) er sich so verhalten, als hätte die enthaltende Nachricht eine Schleife durchlaufen, indem er als Antwort an den Absender der Nachricht eine Notification-Nachricht sendet, die Loop Detected signalisiert.
Wenn die Schleifenerkennung konfiguriert ist, MUSS (MUST) der LSR die im Abschnitt "Loop Detection" spezifizierten Verfahren befolgen.
3.4.5. Path Vector TLV
Das Path Vector TLV wird zusammen mit dem Hop Count TLV in Label Request- und Label Mapping-Nachrichten verwendet, um den optionalen LDP-Schleifenerkennungsmechanismus zu implementieren. Siehe den Abschnitt "Loop Detection". Seine Verwendung in der Label Request-Nachricht zeichnet den Pfad der LSRs auf, die die Anforderung durchlaufen hat. Seine Verwendung in der Label Mapping-Nachricht zeichnet den Pfad der LSRs auf, die eine Label-Ankündigung durchlaufen hat, um eine LSP aufzubauen. Seine Kodierung 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Path Vector (0x0104) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One or more LSR Ids Eine Liste von Router-Ids, die den Pfad der LSRs angibt, die die Nachricht durchlaufen hat. Jede LSR Id besteht aus den ersten vier Oktetten (Router-Id) des LDP Identifier für den entsprechenden LSR. Dies stellt sicher, dass sie innerhalb des LSR-Netzes eindeutig ist.
3.4.5.1. Path Vector-Verfahren
Das Path Vector TLV wird in Label Mapping- und Label Request-Nachrichten mitgeführt, wenn die Schleifenerkennung konfiguriert ist.
3.4.5.1.1. Label Request Path Vector
Der Abschnitt "Loop Detection" legt Situationen fest, in denen ein LSR ein Path Vector TLV in eine Label Request-Nachricht aufnehmen muss.
Ein LSR, der einen Path Vector in einer Label Request-Nachricht empfängt, MUSS (MUST) die im Abschnitt "Loop Detection" beschriebenen Verfahren durchführen.
Wenn der LSR eine Schleife erkennt, MUSS (MUST) er die Label Request-Nachricht zurückweisen.
Der LSR MUSS (MUST):
-
Eine Notification-Nachricht an den sendenden LSR übertragen, die "Loop Detected" signalisiert.
-
Die Label Request-Nachricht nicht weiter weiterleiten.
Beachten Sie, dass eine Label Request-Nachricht mit einem Path Vector TLV weitergeleitet wird, bis:
-
eine Schleife gefunden wird,
-
der LSP-Egress erreicht wird oder
-
die maximale Path Vector-Grenze oder die maximale Hop Count-Grenze erreicht wird. Dies wird so behandelt, als wäre eine Schleife erkannt worden.
3.4.5.1.2. Label Mapping Path Vector
Der Abschnitt "Loop Detection" legt die Situationen fest, in denen ein LSR ein Path Vector TLV in eine Label Mapping-Nachricht aufnehmen muss.
Ein LSR, der einen Path Vector in einer Label Mapping-Nachricht empfängt, MUSS (MUST) die im Abschnitt "Loop Detection" beschriebenen Verfahren durchführen.
Wenn der LSR eine Schleife erkennt, MUSS (MUST) er die Label Mapping-Nachricht zurückweisen, um eine Weiterleitungsschleife zu verhindern. Der LSR MUSS (MUST):
-
Eine Label Release-Nachricht, die ein Status TLV mitführt, an den sendenden LSR übertragen, um "Loop Detected" zu signalisieren.
-
Die Nachricht nicht weiter weiterleiten.
-
Prüfen, ob die Label Mapping-Nachricht für eine bestehende LSP bestimmt ist. Wenn ja, muss der LSR alle vorgelagerten Labels trennen (unsplice), die mit dem nachgelagerten Label für die FEC verschweißt (spliced) sind.
Beachten Sie, dass eine Label Mapping-Nachricht mit einem Path Vector TLV weitergeleitet wird, bis:
-
eine Schleife gefunden wird,
-
ein LSP-Ingress erreicht wird oder
-
die maximale Path Vector- oder die maximale Hop Count-Grenze erreicht wird. Dies wird so behandelt, als wäre eine Schleife erkannt worden.
3.4.6. Status TLV
Notification-Nachrichten führen Status TLVs mit, um die signalisierten Ereignisse anzugeben.
Die Kodierung für das Status TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit SOLLTE (SHOULD) 0 sein, wenn das Status TLV in einer Notification-Nachricht gesendet wird. SOLLTE (SHOULD) 1 sein, wenn das Status TLV in einer anderen Nachricht gesendet wird.
F-bit SOLLTE (SHOULD) mit der Einstellung des F-Bits im Feld Status Code übereinstimmen.
Status Code Eine vorzeichenlose 32-Bit-Ganzzahl, die das signalisierte Ereignis kodiert. Die Struktur eines Status Code 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|F| Status Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-bit Fatal error bit. Wenn gesetzt (=1), ist dies eine fatale Error Notification. Wenn nicht gesetzt (=0), ist dies eine Advisory Notification.
F-bit Forward bit. Wenn gesetzt (=1), SOLLTE (SHOULD) die Benachrichtigung an den LSR für den Next-Hop oder Previous-Hop für die LSP, falls vorhanden, weitergeleitet werden, der mit dem signalisierten Ereignis verbunden ist. Wenn nicht gesetzt (=0), SOLLTE (SHOULD) die Benachrichtigung NICHT weitergeleitet werden.
Status Data Eine vorzeichenlose 30-Bit-Ganzzahl, die die Statusinformation angibt.
Diese Spezifikation definiert Status Codes (vorzeichenlose 32-Bit-Ganzzahlen mit der obigen Kodierung).
Ein Status Code von 0 signalisiert Erfolg.
Message ID Wenn ungleich null, ein 32-Bit-Wert, der die Peer-Nachricht identifiziert, auf die sich das Status TLV bezieht. Wenn null, wird keine bestimmte Peer-Nachricht identifiziert.
Message Type Wenn ungleich null, der Typ der Peer-Nachricht, auf die sich das Status TLV bezieht. Wenn null, bezieht sich das Status TLV auf keinen bestimmten Nachrichtentyp.
Beachten Sie, dass die Verwendung des Status TLV nicht auf Notification-Nachrichten beschränkt ist. Eine andere Nachricht als eine Notification-Nachricht kann ein Status TLV als Optional Parameter mitführen. Wenn eine andere Nachricht als eine Notification ein Status TLV mitführt, SOLLTE (SHOULD) das U-bit des Status TLV auf 1 gesetzt werden, um anzuzeigen, dass der Empfänger das TLV stillschweigend verwerfen SOLLTE (SHOULD), wenn er nicht darauf vorbereitet ist, es zu verarbeiten.