RFC 4379 - 3. Packet Format
3. Paketformat (Packet Format)
Dieser Abschnitt definiert die Nachrichtentypen, Antwortmodi, Rückgabecodes und TLVs, die von MPLS-echo-Nachrichten verwendet werden.
Ein MPLS echo request ist ein (möglicherweise gelabeltes) IPv4- oder IPv6-UDP-Paket; der Inhalt des UDP-Pakets hat das folgende Format:
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 Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Die Version Number ist derzeit 1. (Hinweis: Die Versionsnummer ist immer dann zu erhöhen, wenn eine Änderung vorgenommen wird, die die Fähigkeit einer Implementierung beeinträchtigt, ein MPLS echo request/reply korrekt zu parsen oder zu verarbeiten. Zu diesen Änderungen gehören alle syntaktischen oder semantischen Änderungen an einem der festen Felder sowie an der Zuweisung oder am Format eines Type-Length-Value (TLV) oder Sub-TLV, das unter einer bestimmten Versionsnummer definiert ist. Die Versionsnummer muss möglicherweise nicht geändert werden, wenn ein optionales TLV oder Sub-TLV hinzugefügt wird.)
Das Feld Global Flags ist ein Bitvektor mit dem folgenden Format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Derzeit ist ein Flag definiert, das V-Bit; die übrigen Bits müssen beim Senden auf null gesetzt und beim Empfang ignoriert werden (MUST).
Das Flag V (Validate FEC Stack) wird auf 1 gesetzt, wenn der Sender möchte, dass der Empfänger eine FEC-Stack-Validierung durchführt; ist V gleich 0, bleibt die Wahl dem Empfänger überlassen.
Der Message Type ist einer der folgenden:
| Wert | Bedeutung |
|---|---|
| 1 | MPLS echo request (MPLS-Echo-Anfrage) |
| 2 | MPLS echo reply (MPLS-Echo-Antwort) |
Der Reply Mode kann einen der folgenden Werte annehmen:
| Wert | Bedeutung |
|---|---|
| 1 | Do not reply (nicht antworten) |
| 2 | Reply via an IPv4/IPv6 UDP packet (per IPv4/IPv6-UDP-Paket antworten) |
| 3 | Reply via an IPv4/IPv6 UDP packet with Router Alert (per IPv4/IPv6-UDP-Paket mit Router Alert antworten) |
| 4 | Reply via application level control channel (über einen Steuerkanal auf Anwendungsebene antworten) |
Ein MPLS echo request mit 1 (nicht antworten) im Feld Reply Mode kann für einseitige Konnektivitätstests verwendet werden; der empfangende Router kann Lücken in den Sequence Number protokollieren und/oder Verzögerungs- und Jitter-Statistiken führen. Ein MPLS echo request hat normalerweise 2 (per IPv4/IPv6-UDP-Paket antworten) im Feld Reply Mode. Wird der normale IP-Rückweg als unzuverlässig angesehen, kann man 3 (per IPv4/IPv6-UDP-Paket mit Router Alert antworten) verwenden. Beachten Sie, dass dies erfordert, dass alle Zwischenrouter MPLS echo reply verstehen und wissen, wie sie weiterzuleiten sind. Der echo reply verwendet dieselbe IP-Versionsnummer wie der empfangene echo request, d. h. auf einen IPv4-gekapselten echo request wird mit einem IPv4-gekapselten echo reply geantwortet.
Einige Anwendungen unterstützen einen IP-Steuerkanal. Ein Beispiel ist der in Virtual Circuit Connectivity Verification (VCCV) [VCCV] definierte zugehörige Steuerkanal (associated control channel). Jede Anwendung, die zwischen ihren Steuerentitäten einen IP-Steuerkanal unterstützt, kann den Reply Mode auf 4 (über einen Steuerkanal auf Anwendungsebene antworten) setzen, um sicherzustellen, dass Antworten denselben Kanal verwenden. Eine weitergehende Definition dieses Codepoints ist anwendungsspezifisch und liegt daher außerhalb des Geltungsbereichs dieses Dokuments.
Rückgabecodes und -subcodes werden im nächsten Abschnitt beschrieben.
Das Sender's Handle wird vom Sender ausgefüllt und vom Empfänger in der echo reply (falls vorhanden) unverändert zurückgegeben. Mit diesem Handle sind keine Semantiken verbunden, obwohl ein Sender es als nützlich erachten kann, um Anfragen und Antworten einander zuzuordnen.
Die Sequence Number wird vom Sender des MPLS echo request vergeben und kann (beispielsweise) verwendet werden, um fehlende Antworten zu erkennen.
Der TimeStamp Sent ist die Tageszeit (in Sekunden und Mikrosekunden, nach der Uhr des Senders) im NTP-Format [NTP], zu der das MPLS echo request gesendet wird. Der TimeStamp Received in einer echo reply ist die Tageszeit (nach der Uhr des Empfängers) im NTP-Format, zu der das entsprechende echo request empfangen wurde.
TLVs (Type-Length-Value-Tupel) haben das folgende Format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Die Typen sind unten definiert; Length ist die Länge des Value-Felds in Oktetten. Das Value-Feld hängt vom Type ab; es wird mit Nullen aufgefüllt, um an einer 4-Oktett-Grenze ausgerichtet zu sein. TLVs können in andere TLVs verschachtelt werden; in diesem Fall werden die verschachtelten TLVs als Sub-TLVs bezeichnet. Sub-TLVs haben unabhängige Typen und müssen ebenfalls auf 4 Oktette ausgerichtet sein (MUST).
Es folgen zwei Beispiele. Das LDP-IPv4-FEC-Sub-TLV des Label Distribution Protocol (LDP) hat das folgende Format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Die Length für dieses TLV ist 5. Ein Ziel-FEC-Stapel-TLV, das ein LDP-IPv4-FEC-Sub-TLV und ein VPN-IPv4-Präfix-Sub-TLV enthält, hat das folgende Format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (FEC TLV) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 6 (VPN IPv4 prefix)| Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Im Folgenden wird eine Beschreibung der Typen und Werte (Types and Values) der TLV der obersten Ebene für LSP ping gegeben:
| Typ-Nr. (Type #) | Wertfeld (Value Field) |
|---|---|
| 1 | Target FEC Stack (Ziel-FEC-Stapel) |
| 2 | Downstream Mapping (Downstream-Mapping) |
| 3 | Pad (Auffüllung) |
| 4 | Not Assigned (nicht zugewiesen) |
| 5 | Vendor Enterprise Number (Hersteller-Enterprise-Nummer) |
| 6 | Not Assigned (nicht zugewiesen) |
| 7 | Interface and Label Stack (Schnittstelle und Label-Stapel) |
| 8 | Not Assigned (nicht zugewiesen) |
| 9 | Errored TLVs (fehlerhafte TLVs) |
| 10 | Reply TOS Byte (Reply-TOS-Byte) |
Typen kleiner als 32768 (d. h. mit dem höchstwertigen Bit gleich 0) sind verpflichtende (mandatory) TLVs, die von einer Implementierung entweder unterstützt werden müssen oder dazu führen müssen, dass in der echo-Antwort der Rückgabecode 2 ("ein oder mehrere der TLVs wurden nicht verstanden") gesendet wird (MUST).
Typen größer oder gleich 32768 (d. h. mit dem höchstwertigen Bit gleich 1) sind optionale (optional) TLVs, die ignoriert werden sollten, wenn die Implementierung sie nicht versteht oder nicht unterstützt (SHOULD).
3.1. Rückgabecodes (Return Codes)
Der Rückgabecode wird vom Sender auf null gesetzt. Der Empfänger kann ihn auf einen der unten aufgeführten Werte setzen. Die Notation
| Wert | Bedeutung |
|---|---|
| 0 | No return code (Kein Rückgabecode) |
| 1 | Malformed echo request received (Fehlerhafter echo request empfangen) |
| 2 | One or more of the TLVs was not understood (Ein oder mehrere TLVs wurden nicht verstanden) |
| 3 | Replying router is an egress for the FEC at stack-depth |
| 4 | Replying router has no mapping for the FEC at stack-depth |
| 5 | Downstream Mapping Mismatch (Nichtübereinstimmung des Downstream-Mappings) (siehe Anmerkung 1) |
| 6 | Upstream Interface Index Unknown (Upstream-Schnittstellenindex unbekannt) (siehe Anmerkung 1) |
| 7 | Reserved (Reserviert) |
| 8 | Label switched at stack-depth |
| 9 | Label switched but no MPLS forwarding at stack-depth |
| 10 | Mapping for this FEC is not the given label at stack-depth |
| 11 | No label entry at stack-depth |
| 12 | Protocol not associated with interface at FEC stack-depth |
| 13 | Premature termination of ping due to label stack shrinking to a single label (Vorzeitige Beendigung des ping, weil der Label-Stapel auf ein einzelnes Label geschrumpft ist) |
Anmerkung 1
Der Rückgabe-Subcode enthält die Stelle im Label-Stapel, an der die Verarbeitung beendet wurde. Ist der RSC 0, so wurden keine Labels verarbeitet. Andernfalls wäre das Paket in der Tiefe RSC umgeschaltet (label switched) worden.
3.2. Ziel-FEC-Stapel (Target FEC Stack)
Ein Ziel-FEC-Stapel (Target FEC Stack) ist eine Liste von Sub-TLVs. Die Anzahl der Elemente ergibt sich aus den Längenfeldern der Sub-TLVs.
| Sub-Typ (Sub-Type) | Länge (Length) | Wertfeld (Value Field) |
|---|---|---|
| 1 | 5 | LDP IPv4 prefix (LDP-IPv4-Präfix) |
| 2 | 17 | LDP IPv6 prefix (LDP-IPv6-Präfix) |
| 3 | 20 | RSVP IPv4 LSP (RSVP-IPv4-LSP) |
| 4 | 56 | RSVP IPv6 LSP (RSVP-IPv6-LSP) |
| 5 | Not Assigned (nicht zugewiesen) | |
| 6 | 13 | VPN IPv4 prefix (VPN-IPv4-Präfix) |
| 7 | 25 | VPN IPv6 prefix (VPN-IPv6-Präfix) |
| 8 | 14 | L2 VPN endpoint (L2-VPN-Endpunkt) |
| 9 | 10 | "FEC 128" Pseudowire ("FEC 128"-Pseudowire, veraltet) |
| 10 | 14 | "FEC 128" Pseudowire ("FEC 128"-Pseudowire) |
| 11 | 16+ | "FEC 129" Pseudowire ("FEC 129"-Pseudowire) |
| 12 | 5 | BGP labeled IPv4 prefix (BGP-IPv4-Präfix mit Label) |
| 13 | 17 | BGP labeled IPv6 prefix (BGP-IPv6-Präfix mit Label) |
| 14 | 5 | Generic IPv4 prefix (generisches IPv4-Präfix) |
| 15 | 17 | Generic IPv6 prefix (generisches IPv6-Präfix) |
| 16 | 4 | Nil FEC (Nil FEC) |
Weitere FEC-Typen werden nach Bedarf definiert.
Beachten Sie, dass dieses TLV einen Stapel von FECs definiert, wobei das erste FEC-Element der Spitze (top) des Label-Stapels entspricht und so weiter.
Ein MPLS echo request muss einen Ziel-FEC-Stapel besitzen, der den geprüften FEC-Stapel beschreibt (MUST). Wenn beispielsweise ein LSR X eine LDP-Zuordnung [LDP] für 192.168.1.1 hat (sagen wir Label 1001), so kann X, um zu prüfen, dass Label 1001 tatsächlich einen Egress-LSR erreicht, der dieses Präfix über LDP bekannt gegeben hat, einen MPLS echo request mit einem FEC-Stapel-TLV senden, das genau einen FEC enthält, nämlich vom Typ LDP IPv4 prefix mit dem Präfix 192.168.1.1/32, und den echo request mit dem Label 1001 senden.
Angenommen, LSR X möchte prüfen, ob der Label-Stapel <1001, 23456> der richtige Label-Stapel ist, um ein VPN-IPv4-Präfix (siehe Abschnitt 3.2.5) 10/8 in der VPN foo zu erreichen. Weiterhin habe LSR Y mit der Loopback-Adresse 192.168.1.1 das Präfix 10/8 mit dem Route Distinguisher RD-foo-Y (der sich im Allgemeinen von dem Route Distinguisher unterscheiden kann, den LSR X in seinen eigenen Ankündigungen für VPN foo verwendet), dem Label 23456 und dem BGP-Next-Hop 192.168.1.1 angekündigt [BGP]. Schließlich empfange LSR X über LDP eine Label-Bindung von 1001 für 192.168.1.1. X hat beim Senden eines MPLS echo request zwei Möglichkeiten: X kann einen MPLS echo request mit einem FEC-Stapel-TLV senden, das einen einzigen FEC vom Typ VPN IPv4 prefix mit dem Präfix 10/8 und dem Route Distinguisher RD-foo-Y enthält. Alternativ kann X ein FEC-Stapel-TLV mit zwei FECs senden, wobei der erste vom Typ LDP IPv4 mit dem Präfix 192.168.1.1/32 und der zweite vom Typ IP VPN mit dem Präfix 10/8 und dem Route Distinguisher RD-foo-Y ist. In beiden Fällen hätte der MPLS echo request einen Label-Stapel von <1001, 23456>. (Anmerkung: In diesem Beispiel ist 1001 das "äußere" und 23456 das "innere" Label.)
3.2.1. LDP-IPv4-Präfix (LDP IPv4 Prefix)
Der IPv4-Präfix-FEC ist in [LDP] definiert. Wenn ein LDP-IPv4-Präfix in einem Label-Stapel kodiert wird, wird das folgende Format verwendet. Der Wert besteht aus 4 Oktetten eines IPv4-Präfixes, gefolgt von 1 Oktett Präfixlänge in Bit; das Format ist unten angegeben. Das IPv4-Präfix liegt in Netzwerk-Byte-Reihenfolge vor; ist das Präfix kürzer als 32 Bit, sollten die nachfolgenden Bits auf null gesetzt werden (SHOULD). Ein Beispiel einer Zuordnung für einen IPv4-FEC finden Sie in [LDP].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.2. LDP-IPv6-Präfix (LDP IPv6 Prefix)
Der IPv6-Präfix-FEC ist in [LDP] definiert. Wenn ein LDP-IPv6-Präfix in einem Label-Stapel kodiert wird, wird das folgende Format verwendet. Der Wert besteht aus 16 Oktetten eines IPv6-Präfixes, gefolgt von 1 Oktett Präfixlänge in Bit; das Format ist unten angegeben. Das IPv6-Präfix liegt in Netzwerk-Byte-Reihenfolge vor; ist das Präfix kürzer als 128 Bit, sollten die nachfolgenden Bits auf null gesetzt werden (SHOULD). Ein Beispiel einer Zuordnung für einen IPv6-FEC finden Sie in [LDP].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.3. RSVP-IPv4-LSP (RSVP IPv4 LSP)
Der Wert hat das unten angegebene Format. Die Wertfelder stammen aus RFC 3209, Abschnitte 4.6.1.1 und 4.6.2.1. Siehe [RSVP-TE].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.4. RSVP-IPv6-LSP (RSVP IPv6 LSP)
Der Wert hat das unten angegebene Format. Die Wertfelder stammen aus RFC 3209, Abschnitte 4.6.1.2 und 4.6.2.2. Siehe [RSVP-TE].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.5. VPN-IPv4-Präfix (VPN IPv4 Prefix)
VPN-IPv4-Netzwerkschicht-Routinginformationen (NLRI) sind in [RFC4365] definiert. Dieses Dokument verwendet den Begriff VPN IPv4 prefix für ein VPN-IPv4-NLRI, das in BGP mit einem MPLS-Label angekündigt wurde. Siehe [BGP-LABEL].
Wenn ein VPN-IPv4-Präfix in einem Label-Stapel kodiert wird, wird das folgende Format verwendet. Das Wertfeld besteht aus dem mit dem VPN-IPv4-Präfix angekündigten Route Distinguisher, dem IPv4-Präfix (mit nachfolgenden 0-Bits, sodass insgesamt 32 Bit entstehen) und einer Präfixlänge, wie folgt.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Der Route Distinguisher (RD) ist ein 8 Oktett langer Bezeichner; er enthält keine inhärente Information. Der Zweck des RD besteht allein darin, unterschiedliche Routen zu einem gemeinsamen IPv4-Adresspräfix erzeugen zu können. Die Kodierung des RD ist hier nicht wichtig. Beim Abgleich dieses Feldes mit den lokalen FEC-Informationen wird es als opaker Wert behandelt.
3.2.6. VPN-IPv6-Präfix (VPN IPv6 Prefix)
VPN-IPv6-Netzwerkschicht-Routinginformationen (NLRI) sind in [RFC4365] definiert. Dieses Dokument verwendet den Begriff VPN IPv6 prefix für ein VPN-IPv6-NLRI, das in BGP mit einem MPLS-Label angekündigt wurde. Siehe [BGP-LABEL].
Wenn ein VPN-IPv6-Präfix in einem Label-Stapel kodiert wird, wird das folgende Format verwendet. Das Wertfeld besteht aus dem mit dem VPN-IPv6-Präfix angekündigten Route Distinguisher, dem IPv6-Präfix (mit nachfolgenden 0-Bits, sodass insgesamt 128 Bit entstehen) und einer Präfixlänge, wie folgt.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Der Route Distinguisher ist mit dem RD des VPN-IPv4-Präfixes identisch, außer dass er hier dazu dient, unterschiedliche Routen zu IPv6-Präfixen erzeugen zu können. Siehe Abschnitt 3.2.5. Beim Abgleich dieses Feldes mit lokalen FEC-Informationen wird es als opaker Wert behandelt.
3.2.7. L2-VPN-Endpunkt (L2 VPN Endpoint)
VPLS steht für Virtual Private LAN Service. Die Begriffe VPLS BGP NLRI und VE ID (VPLS Edge Identifier) sind in [VPLS-BGP] definiert. Dieses Dokument verwendet den einfacheren Begriff L2 VPN endpoint, wenn es sich auf ein VPLS BGP NLRI bezieht. Der Route Distinguisher ist ein 8 Oktett langer Bezeichner, mit dem Informationen über verschiedene von einem Knoten angekündigte L2-VPNs unterschieden werden. Die VE ID ist ein 2 Oktett langer Bezeichner, mit dem ein bestimmter Knoten identifiziert wird, der als Dienstanbindungspunkt innerhalb eines VPLS dient. Die Struktur dieser beiden Bezeichner ist hier unwichtig; beim Abgleich dieser Felder mit lokalen FEC-Informationen werden sie als opake Werte behandelt. Der Kapselungstyp ist identisch mit dem PW Type in Abschnitt 3.2.8 unten.
Wenn ein L2-VPN-Endpunkt in einem Label-Stapel kodiert wird, wird das folgende Format verwendet. Das Wertfeld besteht aus einem Route Distinguisher (8 Oktette), der VE ID des Senders (des ping) (2 Oktette), der VE ID des Empfängers (2 Oktette) und einem Kapselungstyp (2 Oktette), formatiert wie folgt.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's VE ID | Receiver's VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.8. FEC-128-Pseudowire (veraltet) (FEC 128 Pseudowire (Deprecated))
FEC 128 (0x80) ist in [PW-CONTROL] definiert, ebenso die Begriffe PW ID (Pseudowire ID) und PW Type (Pseudowire Type). Eine PW ID ist eine von null verschiedene 32-Bit-Verbindungskennung. Der PW Type ist eine 15-Bit-Zahl, die den Kapselungstyp angibt. Er wird rechtsbündig in dem unten als Kapselungstyp (encapsulation type) bezeichneten Feld übertragen, wobei das höchstwertige Bit auf null gesetzt ist. Beide Felder werden in diesem Protokoll als opake Werte behandelt.
Wenn ein FEC 128 in einem Label-Stapel kodiert wird, wird das folgende Format verwendet. Das Wertfeld besteht aus der Adresse des entfernten PE (der Zieladresse der gezielten LDP-Sitzung), der PW ID und dem Kapselungstyp, wie folgt.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dieser FEC ist veraltet und wird nur aus Gründen der Abwärtskompatibilität beibehalten. Implementierungen von LSP ping sollten dieses TLV akzeptieren und verarbeiten (SHOULD), aber LSP-ping-echo-Requests mit dem neuen TLV senden (siehe nächster Abschnitt), sofern sie nicht ausdrücklich für die Verwendung des alten TLV konfiguriert sind (SHOULD).
Ein LSR, der dieses TLV empfängt, sollte die Quell-IP-Adresse des LSP echo request verwenden, um die PE-Adresse des Senders abzuleiten (SHOULD).
3.2.9. FEC-128-Pseudowire (aktuell) (FEC 128 Pseudowire (Current))
FEC 128 (0x80) ist in [PW-CONTROL] definiert, ebenso die Begriffe PW ID (Pseudowire ID) und PW Type (Pseudowire Type). Eine PW ID ist eine von null verschiedene 32-Bit-Verbindungskennung. Der PW Type ist eine 15-Bit-Zahl, die den Kapselungstyp angibt. Er wird rechtsbündig in dem unten als Kapselungstyp (encapsulation type) bezeichneten Feld übertragen, wobei das höchstwertige Bit auf null gesetzt ist.
Beide Felder werden in diesem Protokoll als opake Werte behandelt. Beim Abgleich dieser Felder mit den lokalen FEC-Informationen muss die Übereinstimmung exakt sein (MUST).
Wenn ein FEC 128 in einem Label-Stapel kodiert wird, wird das folgende Format verwendet. Das Wertfeld besteht aus der Adresse des PE des Senders (der Quelladresse der gezielten LDP-Sitzung), der Adresse des entfernten PE (der Zieladresse der gezielten LDP-Sitzung), der PW ID und dem Kapselungstyp, wie folgt.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.10. FEC-129-Pseudowire (FEC 129 Pseudowire)
FEC 129 (0x81) sowie die Begriffe PW Type, Attachment Group Identifier (AGI), Attachment Group Identifier Type (AGI Type), Attachment Individual Identifier Type (AII Type), Source Attachment Individual Identifier (SAII) und Target Attachment Individual Identifier (TAII) sind in [PW-CONTROL] definiert. Der PW Type ist eine 15-Bit-Zahl, die den Kapselungstyp angibt. Er wird rechtsbündig im unten stehenden Feld PW Type übertragen, wobei das höchstwertige Bit auf null gesetzt ist. Alle anderen Felder werden als opake Werte behandelt und direkt aus dem FEC-129-Format übernommen. Alle diese Werte zusammen definieren den FEC innerhalb des Geltungsbereichs der LDP-Sitzung, die durch die Quell- und die entfernte PE-Adresse identifiziert wird, eindeutig.
Wenn ein FEC 129 in einem Label-Stapel kodiert wird, wird das folgende Format verwendet. Die Length dieses TLV ist 16 + AGI-Länge + SAII-Länge + TAII-Länge. Mit Auffüllung (padding) wird die Gesamtlänge zu einem Vielfachen von 4 gemacht; die Länge der Auffüllung wird nicht in das Length-Feld eingerechnet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.11. BGP-IPv4-Präfix mit Label (BGP Labeled IPv4 Prefix)
BGP-IPv4-Präfixe mit Label sind in [BGP-LABEL] definiert. Wenn ein BGP-IPv4-Präfix mit Label in einem Label-Stapel kodiert wird, wird das folgende Format verwendet. Das Wertfeld besteht aus dem IPv4-Präfix (mit nachfolgenden 0-Bits, sodass insgesamt 32 Bit entstehen) und der Präfixlänge, wie folgt.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.12. BGP-IPv6-Präfix mit Label (BGP Labeled IPv6 Prefix)
BGP-IPv6-Präfixe mit Label sind in [BGP-LABEL] definiert. Wenn ein BGP-IPv6-Präfix mit Label in einem Label-Stapel kodiert wird, wird das folgende Format verwendet. Der Wert besteht aus 16 Oktetten eines IPv6-Präfixes, gefolgt von 1 Oktett Präfixlänge in Bit; das Format ist unten angegeben. Das IPv6-Präfix liegt in Netzwerk-Byte-Reihenfolge vor; ist das Präfix kürzer als 128 Bit, sollten die nachfolgenden Bits auf null gesetzt werden (SHOULD).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.13. Generisches IPv4-Präfix (Generic IPv4 Prefix)
Der Wert besteht aus 4 Oktetten eines IPv4-Präfixes, gefolgt von 1 Oktett Präfixlänge in Bit; das Format ist unten angegeben. Das IPv4-Präfix liegt in Netzwerk-Byte-Reihenfolge vor; ist das Präfix kürzer als 32 Bit, sollten die nachfolgenden Bits auf null gesetzt werden (SHOULD). Dieser FEC wird verwendet, wenn das Protokoll, das das Label ankündigt, unbekannt ist oder sich im Verlauf des LSP ändern kann. Ein Beispiel ist ein Inter-AS-LSP, das in einem autonomen System (AS) von LDP, in einem anderen AS von RSVP-TE [RSVP-TE] und zwischen den ASs von BGP signalisiert werden kann, wie es für Inter-AS-VPNs üblich 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.14. Generisches IPv6-Präfix (Generic IPv6 Prefix)
Der Wert besteht aus 16 Oktetten eines IPv6-Präfixes, gefolgt von 1 Oktett Präfixlänge in Bit; das Format ist unten angegeben. Das IPv6-Präfix liegt in Netzwerk-Byte-Reihenfolge vor; ist das Präfix kürzer als 128 Bit, sollten die nachfolgenden Bits auf null gesetzt werden (SHOULD).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.15. Nil FEC (Nil FEC)
Mitunter können Labels aus dem reservierten Bereich, z. B. Router Alert und Explicit-null, zu verschiedenen diagnostischen Zwecken wie der Beeinflussung des Load-Balancing zum Label-Stapel hinzugefügt werden. Diese Labels haben möglicherweise keinen explizit zugeordneten FEC. Der Nil-FEC-Stapel ist definiert, um zu ermöglichen, dass ein Ziel-FEC-Stapel-Sub-TLV zum Ziel-FEC-Stapel hinzugefügt wird, um solche Labels zu berücksichtigen, damit weiterhin eine ordnungsgemäße Validierung durchgeführt werden kann.
Die Length ist 4. Labels sind 20-Bit-Werte, die als Zahlen behandelt werden.
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 | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label ist der tatsächliche Labelwert, der in den Label-Stapel eingefügt wird; die MBZ-Felder müssen beim Senden null sein (MUST) und werden beim Empfang ignoriert.
3.3. Downstream-Mapping (Downstream Mapping)
Das Downstream-Mapping-Objekt ist ein TLV, das in eine echo-request-Nachricht aufgenommen werden kann (MAY). In einer echo request darf nur ein Downstream-Mapping-Objekt erscheinen. Das Vorhandensein eines Downstream-Mapping-Objekts ist die Aufforderung, Downstream-Mapping-Objekte in die echo reply aufzunehmen. Ist der antwortende Router das Ziel des FEC, so sollte kein Downstream-Mapping-TLV in die echo reply aufgenommen werden (SHOULD NOT). Andernfalls sollte der antwortende Router für jede Schnittstelle, über die dieser FEC weitergeleitet werden könnte, ein Downstream-Mapping-Objekt aufnehmen (SHOULD). Eine genauere Definition des Begriffs "downstream" finden Sie in Abschnitt 3.3.2, "Downstream-Router und -Schnittstelle (Downstream Router and Interface)".
Die Length ist K + M + 4*N Oktette, wobei M die Multipath-Länge (Multipath Length) und N die Anzahl der Downstream-Labels (Downstream Label) ist. Werte für K finden sich in der Beschreibung des Adresstyps (Address Type) unten. Das Value-Feld eines Downstream-Mappings hat das folgende Format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximale Übertragungseinheit (Maximum Transmission Unit, MTU)
Die MTU ist die Größe des größten MPLS-Rahmens (einschließlich Label-Stapel) in Oktetten, der auf die Schnittstelle zum Downstream-LSR passt.
Adresstyp (Address Type)
Der Adresstyp gibt an, ob die Schnittstelle nummeriert (numbered) oder unnummeriert (unnumbered) ist. Er bestimmt außerdem die Länge der Felder Downstream IP Address und Downstream Interface. Die sich ergebende Summe für den Anfangsteil des TLV ist in der Tabelle unten als "K Octets" aufgeführt. Der Adresstyp wird auf einen der folgenden Werte gesetzt.
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 16
2 IPv4 Unnumbered 16
3 IPv6 Numbered 40
4 IPv6 Unnumbered 28
DS Flags (Downstream-Flags)
Das Feld DS Flags ist ein Bitvektor mit dem folgenden Format.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+
Derzeit sind zwei Flags definiert, I und N. Die übrigen Flags müssen beim Senden auf null gesetzt werden (MUST) und werden beim Empfang ignoriert.
| Flag | Name und Bedeutung |
|---|---|
| I | Interface and Label Stack Object Request (Anforderung des Objekts Schnittstelle und Label-Stapel): Ist dieses Flag gesetzt, zeigt es an, dass der antwortende Router ein Interface-and-Label-Stack-Objekt in die echo-reply-Nachricht aufnehmen sollte (SHOULD). |
| N | Treat as a Non-IP Packet (als Nicht-IP-Paket behandeln): echo-request-Nachrichten werden zur Diagnose von Nicht-IP-Flüssen verwendet. Diese Nachrichten werden jedoch in IP-Paketen transportiert. Für einen Router, der seinen ECMP-Algorithmus anhand des FEC oder einer tiefen Paketprüfung ändert, fordert dieses Flag, dass der Router dies so behandelt, wie er es tun würde, wenn die Bestimmung einer IP-Nutzlast fehlgeschlagen wäre. |
Downstream IP Address und Downstream Interface Address
IPv4-Adressen und Schnittstellenindizes werden in 4 Oktetten kodiert; IPv6-Adressen werden in 16 Oktetten kodiert.
Ist die Schnittstelle zum Downstream-LSR nummeriert, muss der Adresstyp auf IPv4 oder IPv6 gesetzt werden (MUST), die Downstream IP Address muss entweder auf die Router-ID des Downstream-LSR oder auf die Schnittstellenadresse des Downstream-LSR gesetzt werden (MUST), und die Downstream Interface Address muss auf die Schnittstellenadresse des Downstream-LSR gesetzt werden (MUST).
Ist die Schnittstelle zum Downstream-LSR unnummeriert, muss der Adresstyp IPv4 Unnumbered oder IPv6 Unnumbered sein (MUST), die Downstream IP Address muss die Router-ID des Downstream-LSR sein (MUST), und die Downstream Interface Address muss auf den vom Upstream-LSR der Schnittstelle zugewiesenen Index gesetzt werden (MUST).
Kennt ein LSR die IP-Adresse seines Nachbarn nicht, muss es den Adresstyp auf IPv4 Unnumbered oder IPv6 Unnumbered setzen (MUST). Für IPv4 muss es die Downstream IP Address auf 127.0.0.1 setzen; für IPv6 wird die Adresse auf 0::1 gesetzt. In beiden Fällen muss der Schnittstellenindex auf 0 gesetzt werden (MUST). Empfängt ein LSR ein Echo-Request-Paket mit einer dieser Adressen im Feld Downstream IP Address, so zeigt dies an, dass es die Schnittstellenprüfung überspringen (MUST), aber mit der Label-Validierung fortfahren muss.
Möchte der Urheber eines Echo-Request-Pakets Downstream-Mapping-Informationen erhalten, kennt aber den erwarteten Label-Stapel nicht, so sollte er den Adresstyp auf IPv4 Unnumbered oder IPv6 Unnumbered setzen (SHOULD). Für IPv4 muss er die Downstream IP Address auf 224.0.0.2 setzen (MUST); für IPv6 muss die Adresse auf FF02::2 gesetzt werden (MUST). In beiden Fällen muss der Schnittstellenindex auf 0 gesetzt werden (MUST). Empfängt ein LSR ein Echo-Request-Paket mit der All-Routers-Multicast-Adresse, so zeigt dies an, dass es sowohl die Schnittstellen- als auch die Label-Stapel-Validierung überspringen (MUST), aber Downstream-Mapping-TLVs mit den bereitgestellten Informationen zurückgeben muss.
Multipath-Typ (Multipath Type)
Die folgenden Multipath-Typen sind definiert.
| Schlüssel | Typ | Multipath-Informationen |
|---|---|---|
| 0 | no multipath (kein Multipath) | Leer (Multipath Length = 0) |
| 2 | IP address (IP-Adresse) | IP-Adressen |
| 4 | IP address range (IP-Adressbereich) | Paare aus niedriger/hoher Adresse |
| 8 | Bit-masked IP address set (bitmaskierte IP-Adressmenge) | IP-Adresspräfix und Bitmaske |
| 9 | Bit-masked label set (bitmaskierte Label-Menge) | Label-Präfix und Bitmaske |
Typ 0 zeigt an, dass alle Pakete über diese eine Schnittstelle weitergeleitet werden.
Die Typen 2, 4, 8 und 9 legen fest, dass die angegebenen Multipath-Informationen dazu dienen, diesen Pfad zu beaufschlagen (exercise).
Tiefenbegrenzung (Depth Limit)
Die Tiefenbegrenzung gilt nur für einen Label-Stapel und ist die maximale Anzahl von Labels, die im Hash berücksichtigt werden; sie sollte auf null gesetzt werden, wenn sie nicht angegeben oder unbegrenzt ist (SHOULD).
Multipath-Länge (Multipath Length)
Die Länge der Multipath-Informationen in Oktetten.
Multipath-Informationen (Multipath Information)
Gemäß dem Multipath-Typ kodierte Adress- oder Labelwerte. Kodierungsdetails finden Sie im nächsten Abschnitt.
Downstream-Label (Downstream Label(s))
Die Menge von Labels im Label-Stapel, wie er ausgesehen hätte, wenn dieser Router das Paket über diese Schnittstelle weitergeleitet hätte. Etwaige Implicit-Null-Labels sind ausdrücklich enthalten. Labels werden als Zahlen behandelt, d. h. sie sind im Feld rechtsbündig ausgerichtet.
Ein Downstream-Label ist 24 Bit lang, im gleichen Format wie ein MPLS-Label ohne das TTL-Feld, d. h. das MSBit des Labels ist Bit 0, das LSBit ist Bit 19, die EXP-Bits sind die Bits 20-22 und Bit 23 ist das S-Bit. Der antwortende Router sollte die EXP- und S-Bits ausfüllen (SHOULD); der LSR, der die echo reply empfängt, kann diese Bits ignorieren (MAY).
Protokoll (Protocol)
Das Protokoll ist der folgenden Tabelle zu entnehmen.
| Protocol # | Signalisierungsprotokoll |
|---|---|
| 0 | Unknown (unbekannt) |
| 1 | Static (statisch) |
| 2 | BGP |
| 3 | LDP |
| 4 | RSVP-TE |
3.3.1. Kodierung der Multipath-Informationen (Multipath Information Encoding)
Die Multipath-Informationen (Multipath Information) kodieren die Labels oder Adressen, die diesen Pfad beaufschlagen werden. Die Multipath-Informationen hängen vom Multipath-Typ ab. Der Inhalt des Feldes ist in der Tabelle oben dargestellt. IPv4-Adressen stammen aus dem Bereich 127/8; IPv6-Adressen stammen aus dem Bereich 0:0:0:0:0:FFFF:127/104. Labels werden als Zahlen behandelt, d. h. sie sind im Feld rechtsbündig ausgerichtet. Für Typ 4 dürfen sich die durch Adresspaare angegebenen Bereiche nicht überlappen (MUST NOT) und müssen in aufsteigender Reihenfolge vorliegen (MUST).
Typ 8 ermöglicht eine dichtere Kodierung von IP-Adressen. Das IP-Präfix wird als Basis-IP-Adresse formatiert, wobei die zum Präfix nicht gehörenden niedrigwertigen Bits auf null gesetzt sind. Die maximale Präfixlänge ist 27. Auf das Präfix folgt eine Maske der Länge 2^(32-Präfixlänge) Bit für IPv4 und 2^(128-Präfixlänge) Bit für IPv6. Jedes auf 1 gesetzte Bit stellt eine gültige Adresse dar. Die Adresse ist die Basis-IPv4-Adresse zuzüglich der Position des Bits in der Maske, wobei die Bits von links nach rechts beginnend mit null nummeriert werden. Zum Beispiel würden die IPv4-Adressen 127.2.1.0, 127.2.1.5-127.2.1.15 und 127.2.1.20-127.2.1.29 wie folgt kodiert.
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 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dieselben in IPv6 eingebetteten Adressen würden wie folgt kodiert.
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 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Typ 9 ermöglicht eine dichtere Kodierung von Labels. Das Label-Präfix wird als Basis-Labelwert formatiert, wobei die zum Präfix nicht gehörenden niedrigwertigen Bits auf null gesetzt sind. Die maximale Präfixlänge (einschließlich führender Nullen aufgrund der Kodierung) ist 27. Auf das Präfix folgt eine Maske der Länge 2^(32-Präfixlänge) Bit. Jedes auf eins gesetzte Bit stellt ein gültiges Label dar. Das Label ist das Basis-Label zuzüglich der Position des Bits in der Maske, wobei die Bits von links nach rechts beginnend mit null nummeriert werden. Die Labelwerte aller ungeraden Zahlen zwischen 1152 und 1279 würden wie folgt kodiert.
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
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Anmerkung: In der englischen Vorlage (RFC 4379) ist die Bitmap dieses Beispiels an einem Satzumbruch zerrissen. Sie ist hier wörtlich wie in der englischen Vorlage wiedergegeben. Ihre Bedeutung ist, dass der Anfang das Präfix des Basis-Labels 1152 (= 0b10010000000) und der darauf folgende Teil die Maske der ungeraden Labels mit alternierend gesetzten Bits ist.
Sind die empfangenen Multipath-Informationen nicht leer, müssen die Labels und IP-Adressen aus der bereitgestellten Menge gewählt werden (MUST). Bildet keines dieser Labels oder Adressen auf eine bestimmte Downstream-Schnittstelle ab, so muss für diese Schnittstelle der Typ auf 0 gesetzt werden (MUST). Sind die empfangenen Multipath-Informationen leer (d. h. Multipath Length = 0 oder bei den Typen 8 und 9 eine Maske aus lauter Nullen), muss der Typ auf 0 gesetzt werden (MUST).
Angenommen, LSR X in Hop 10 hat zwei Downstream-LSRs, Y und Z, für den betreffenden FEC. Der empfangende X könnte Multipath-Typ 4 zurückgeben, mit den niedrigen/hohen IP-Adressen 127.1.1.1->127.1.1.255 für den Downstream-LSR Y und 127.2.1.1->127.2.1.255 für den Downstream-LSR Z. Das Head-End spiegelt diese Information an LSR Y. Y, das drei Downstream-LSRs hat, U, V und W, berechnet, dass 127.1.1.1->127.1.1.127 zu U und 127.1.1.128->127.1.1.255 zu V gehen würde. Y würde dann mit 3 Downstream-Mappings antworten: an U mit Multipath-Typ 4 (127.1.1.1->127.1.1.127); an V mit Multipath-Typ 4 (127.1.1.127->127.1.1.255); und an W mit Multipath-Typ 0.
Beachten Sie, dass die Berechnung der Multipath-Informationen eine erhebliche Verarbeitungslast für den Empfänger bedeuten kann. Ein Empfänger kann daher wählen, nur eine Teilmenge der empfangenen Präfixe zu verarbeiten (MAY). Der Sender sollte beim Empfang einer Antwort auf ein Downstream-Mapping mit Teilinformationen davon ausgehen, dass die in der Antwort fehlenden Präfixe vom Empfänger übersprungen wurden (SHOULD), und kann Informationen darüber in einer neuen echo request erneut anfordern (MAY).
3.3.2. Downstream-Router und -Schnittstelle (Downstream Router and Interface)
Die Begriffe "Downstream-Router" und "Downstream-Schnittstelle" sollten erläutert werden. Betrachten Sie einen LSR X. Wenn ein Paket, das mit TTL n>1 erzeugt wurde, mit dem äußersten Label L und TTL=1 am LSR X ankäme, muss X berechnen können, welche LSRs das Paket empfangen könnten, wenn es mit TTL=n+1 erzeugt würde, über welche Schnittstelle die Anforderung ankäme und welchen Label-Stapel diese LSRs sehen würden. (Wie diese Berechnung durchgeführt wird, liegt außerhalb des Rahmens dieses Dokuments.) Die Menge dieser LSRs/Schnittstellen bildet die Downstream-Router/-Schnittstellen (und ihre entsprechenden Labels) für X in Bezug auf L. Für jedes Paar aus Downstream-Router und -Schnittstelle muss der Antwort ein separates Downstream-Mapping hinzugefügt werden.
Der Fall, dass X der LSR ist, der die echo request erzeugt, ist ein Sonderfall. X muss ermitteln, welche LSRs die MPLS echo request für einen gegebenen FEC-Stapel, den X mit TTL=1 erzeugt, empfangen würden.
Die Menge der Downstream-Router an X kann aus alternativen Pfaden (siehe die Diskussion zu ECMP unten) oder aus gleichzeitigen Pfaden (z. B. bei MPLS-Multicast) bestehen. Im ersteren Fall dienen die Multipath-Informationen als Hinweis an den Sender, wie er die Wahl zwischen diesen Alternativen beeinflussen kann.
3.4. Pad-TLV (Pad TLV)
Der Wertteil des Pad-TLV enthält eine variable Anzahl (>= 1) von Oktetten. Das erste Oktett nimmt Werte aus der folgenden Tabelle an; alle anderen Oktette (falls vorhanden) werden ignoriert. Der Empfänger sollte prüfen, dass das TLV vollständig empfangen wurde (SHOULD), ignoriert aber ansonsten den Inhalt dieses TLV, abgesehen vom ersten Oktett.
| Wert | Bedeutung |
|---|---|
| 1 | Drop Pad TLV from reply (Pad-TLV aus der Antwort verwerfen) |
| 2 | Copy Pad TLV to reply (Pad-TLV in die Antwort kopieren) |
| 3-255 | Für zukünftige Verwendung reserviert |
3.5. Hersteller-Enterprise-Nummer (Vendor Enterprise Number)
SMI Private Enterprise Numbers werden von der IANA gepflegt. Die Length ist immer 4; der Wert ist der SMI-Private-Enterprise-Code des Herstellers in Netzwerk-Byte-Reihenfolge, der eine herstellereigene Erweiterung (Vendor Private) an einem der Felder im festen Teil der Nachricht hat; in diesem Fall muss dieses TLV vorhanden sein (MUST). Hat keines der Felder im festen Teil der Nachricht herstellereigene Erweiterungen, ist die Aufnahme dieses TLV optional (OPTIONAL). Für Nachrichtentypen, Antwortmodi und Rückgabecodes wurden herstellereigene Bereiche definiert. Wird einer davon verwendet, muss das TLV der Hersteller-Enterprise-Nummer in die Nachricht aufgenommen werden (MUST).
3.6. Schnittstelle und Label-Stapel (Interface and Label Stack)
Das Interface-and-Label-Stack-TLV kann in eine Antwortnachricht aufgenommen werden, um die Schnittstelle, auf der die Anforderungsnachricht empfangen wurde, und den Label-Stapel, der sich beim Empfang auf dem Paket befand, zu melden (MAY). Es darf nur ein solches Objekt erscheinen. Der Zweck des Objekts besteht darin, dem Upstream-Router den Zugriff auf die exakten Schnittstellen- und Label-Stapel-Informationen zu ermöglichen, wie sie am antwortenden LSR vorliegen.
Die Length ist K + 4*N Oktette; N ist die Anzahl der Labels im Label-Stapel. Werte für K finden sich in der Beschreibung des Adresstyps (Address Type) unten. Das Value-Feld eines Downstream-Mappings hat das folgende Format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Label Stack .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adresstyp (Address Type)
Der Adresstyp gibt an, ob die Schnittstelle nummeriert oder unnummeriert ist. Er bestimmt außerdem die Länge der Felder IP Address und Interface. Die sich ergebende Summe für den Anfangsteil des TLV ist in der Tabelle unten als "K Octets" aufgeführt. Der Adresstyp wird auf einen der folgenden Werte gesetzt.
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 12
2 IPv4 Unnumbered 12
3 IPv6 Numbered 36
4 IPv6 Unnumbered 24
IP Address und Interface
IPv4-Adressen und Schnittstellenindizes werden in 4 Oktetten kodiert; IPv6-Adressen werden in 16 Oktetten kodiert.
Ist die Schnittstelle, auf der die echo-request-Nachricht empfangen wurde, nummeriert, muss der Adresstyp auf IPv4 oder IPv6 gesetzt werden (MUST), die IP Address muss entweder auf die Router-ID des LSR oder auf die Schnittstellenadresse gesetzt werden (MUST), und das Interface muss auf die Schnittstellenadresse gesetzt werden (MUST).
Ist die Schnittstelle unnummeriert, muss der Adresstyp entweder IPv4 Unnumbered oder IPv6 Unnumbered sein (MUST), die IP Address muss die Router-ID des LSR sein (MUST), und das Interface muss auf den der Schnittstelle zugewiesenen Index gesetzt werden (MUST).
Label-Stapel (Label Stack)
Der Label-Stapel der empfangenen echo-request-Nachricht. Wurden TTL-Werte durch diesen Router geändert, sollten sie wiederhergestellt werden (SHOULD).
3.7. Fehlerhafte TLVs (Errored TLVs)
Das folgende TLV ist ein TLV, das in eine echo reply aufgenommen werden kann, um den Sender einer echo request über obligatorische (mandatory) TLVs zu informieren, die von einer Implementierung entweder nicht unterstützt oder geparst und als fehlerhaft befunden wurden (MAY).
Das Value-Feld enthält die TLVs, die nicht verstanden wurden, als Sub-TLVs kodiert.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. Reply-TOS-Byte-TLV (Reply TOS Byte TLV)
Dieses TLV kann vom Urheber der echo request verwendet werden, um anzufordern, dass eine echo reply mit dem auf den im TLV angegebenen Wert gesetzten TOS-Byte des IP-Headers gesendet wird (MAY). Dieses TLV hat die Länge 4 mit dem folgenden Wertfeld.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply-TOS Byte| Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+