3.3 The BGP-LS Attribute (Das BGP-LS-Attribut)
3.3. The BGP-LS Attribute (Das BGP-LS-Attribut)
Das BGP-LS-Attribut ist ein optionales, nicht-transitives BGP-Attribut, das verwendet wird, um Link-, Knoten- und Präfix-Parameter und -Attribute zu übertragen. Es ist als ein Satz von Type/Length/Value (TLV)-Tripeln definiert, die im folgenden Abschnitt beschrieben werden. Dieses Attribut SOLLTE nur mit Link-State NLRIs enthalten sein. Dieses Attribut MUSS für alle anderen Adressfamilien ignoriert werden.
Node attribute TLVs sind die TLVs, die im BGP-LS-Attribut mit einem Node NLRI kodiert werden können. Die folgenden Node Attribute TLVs sind definiert:
+-------------+----------------------+----------+-------------------+
| TLV Code | Description | Length | Reference |
| Point | | | (RFC/Section) |
+-------------+----------------------+----------+-------------------+
| 263 | Multi-Topology | variable | Section 3.2.1.5 |
| | Identifier | | |
| 1024 | Node Flag Bits | 1 | Section 3.3.1.1 |
| 1025 | Opaque Node | variable | Section 3.3.1.5 |
| | Attribute | | |
| 1026 | Node Name | variable | Section 3.3.1.3 |
| 1027 | IS-IS Area | variable | Section 3.3.1.2 |
| | Identifier | | |
| 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 |
| | Local Node | | |
+-------------+----------------------+----------+-------------------+
Table 7: Node Attribute TLVs
Der Node Flag Bits TLV trägt eine Bitmaske, die Knotenattribute beschreibt. Der Wert ist ein Bit-Array variabler Länge von Flags, wobei jedes Bit eine Knoten-Fähigkeit darstellt.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|T|E|B|R|V| Rsvd|
+-+-+-+-+-+-+-+-+-+
Figure 15: Node Flag Bits TLV Format
Die Bits sind wie folgt definiert:
+-----------------+-------------------------+------------+
| Bit | Description | Reference |
+-----------------+-------------------------+------------+
| 'O' | Overload Bit | [ISO10589] |
| 'T' | Attached Bit | [ISO10589] |
| 'E' | External Bit | [RFC2328] |
| 'B' | ABR Bit | [RFC2328] |
| 'R' | Router Bit | [RFC5340] |
| 'V' | V6 Bit | [RFC5340] |
| Reserved (Rsvd) | Reserved for future use | |
+-----------------+-------------------------+------------+
Table 8: Node Flag Bits Definitions
Ein IS-IS-Knoten kann Teil eines oder mehrerer IS-IS-Bereiche sein. Jede dieser Bereichsadressen wird im IS-IS Area Identifier TLV übertragen. Wenn mehrere Bereichsadressen vorhanden sind, werden mehrere TLVs verwendet, um sie zu kodieren. Der IS-IS Area Identifier TLV KANN im BGP-LS-Attribut nur vorhanden sein, wenn er im Link-State Node NLRI angekündigt 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Area Identifier (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: IS-IS Area Identifier TLV Format
Der Node Name TLV ist optional. Seine Struktur und Kodierung wurden von [RFC5301] übernommen. Das Value-Feld identifiziert den symbolischen Namen des Router-Knotens. Dieser symbolische Name kann der vollständig qualifizierte Domänenname (Fully Qualified Domain Name, FQDN) für den Router sein, er kann eine Teilmenge des FQDN sein (z.B. ein Hostname), oder er kann eine beliebige Zeichenkette sein, die Operatoren für den Router verwenden möchten. Die Verwendung von FQDN oder einer Teilmenge davon wird dringend EMPFOHLEN. Die maximale Länge des Node Name TLV beträgt 255 Oktette. Das Value-Feld ist in 7-Bit-ASCII kodiert. Wenn eine Benutzerschnittstelle zum Konfigurieren oder Anzeigen dieses Feldes Unicode-Zeichen zulässt, ist diese Benutzerschnittstelle dafür verantwortlich, den ToASCII- und/oder ToUnicode-Algorithmus anzuwenden, wie in [RFC5890] beschrieben, um das korrekte Format für die Übertragung oder Anzeige zu erreichen.
Obwohl [RFC5301] eine IS-IS-spezifische Erweiterung beschreibt, ist die Verwendung des Node Name TLV für alle Protokolle möglich. Wie ein Router Knotennamen ableitet und injiziert, z.B. OSPF-Knoten, liegt außerhalb des Geltungsbereichs dieses Dokuments.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Node Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Node Name Format
Die lokalen IPv4/IPv6 Router-ID TLVs werden verwendet, um Hilfs-Router-IDs zu beschreiben, die das IGP möglicherweise verwendet, z.B. für TE- und Migrationszwecke wie die Korrelation einer Node-ID zwischen verschiedenen Protokollen. Wenn mehr als eine Hilfs-Router-ID eines bestimmten Typs vorhanden ist, wird jede in ihrem eigenen TLV kodiert.
Der Opaque Node Attribute TLV ist eine Hülle, die optional Node Attribute TLVs transparent überträgt, die von einem Router angekündigt werden. Ein ursprünglicher Router muss diesen TLV verwenden, um Informationen zu kodieren, die spezifisch für das im NLRI-Header-Protocol-ID-Feld angekündigte Protokoll sind, oder neue Protokollerweiterungen zum im NLRI-Header-Protocol-ID-Feld angekündigten Protokoll, für die es keine protokollneutrale Darstellung im BGP Link-State NLRI gibt. Die primäre Verwendung des Opaque Node Attribute TLV besteht darin, die Dokumentenverzögerung zu überbrücken, z.B. zwischen der Definition eines neuen IGP-Link-State-Attributs und der Veröffentlichung der protokollneutralen BGP-LS-Erweiterungen. Ein Router könnte beispielsweise diese Erweiterung verwenden, um die Node Attribute TLVs des nativen Protokolls anzukündigen, wie das in [RFC7770] definierte OSPF Router Informational Capabilities TLV oder das in [RFC5073] beschriebene IGP TE Node Capability Descriptor TLV.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque node attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Opaque Node Attribute Format
Link Attribute TLVs sind TLVs, die im BGP-LS-Attribut mit einem Link NLRI kodiert werden können. Jedes 'Link Attribute' ist ein Type/Length/Value (TLV)-Tripel, das wie in Abschnitt 3.1 definiert formatiert ist. Das Format und die Semantik der Value-Felder in einigen Link Attribute TLVs entsprechen dem Format und der Semantik der Value-Felder in IS-IS Extended IS Reachability Sub-TLVs, die in [RFC5305] und [RFC5307] definiert sind. Andere Link Attribute TLVs sind in diesem Dokument definiert. Obwohl die Kodierungen für Link Attribute TLVs ursprünglich für IS-IS definiert wurden, können die TLVs Daten übertragen, die entweder von IS-IS oder OSPF stammen.
Die folgenden Link Attribute TLVs sind im BGP-LS-Attribut mit einem Link NLRI gültig:
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Remote Node | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 |
| | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.4 |
| | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 |
| | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 |
| | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 |
| | Type | | |
| 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 |
| 1095 | IGP Metric | --- | Section 3.3.2.4 |
| 1096 | Shared Risk Link | --- | Section 3.3.2.5 |
| | Group | | |
| 1097 | Opaque Link | --- | Section 3.3.2.6 |
| | Attribute | | |
| 1098 | Link Name | --- | Section 3.3.2.7 |
+-----------+---------------------+--------------+------------------+
Table 9: Link Attribute TLVs
Die lokalen/entfernten IPv4/IPv6 Router-ID TLVs werden verwendet, um Hilfs-Router-IDs zu beschreiben, die das IGP möglicherweise verwendet, z.B. für TE-Zwecke. Alle Hilfs-Router-IDs sowohl des lokalen als auch des entfernten Knotens MÜSSEN im Link-Attribut jedes Link NLRI enthalten sein. Wenn mehr als eine Hilfs-Router-ID eines bestimmten Typs vorhanden ist, werden mehrere TLVs verwendet, um sie zu kodieren.
Der MPLS Protocol Mask TLV trägt eine Bitmaske, die beschreibt, welche MPLS-Signalisierungsprotokolle aktiviert sind. Die Länge dieses TLV beträgt 1. Der Wert ist ein Bit-Array von 8 Flags, wobei jedes Bit eine MPLS-Protokollfähigkeit darstellt.
Die Generierung des MPLS Protocol Mask TLV ist nur für Urheber gültig und SOLLTE nur mit Urhebern verwendet werden, die lokale Link-Einsicht haben, beispielsweise die Protocol-IDs 'Static configuration' oder 'Direct' gemäß Tabelle 2. Der MPLS Protocol Mask TLV DARF NICHT in NLRIs mit den anderen in Tabelle 2 aufgeführten Protocol-IDs enthalten sein.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|R| Reserved |
+-+-+-+-+-+-+-+-+
Figure 19: MPLS Protocol Mask TLV
Die folgenden Bits sind definiert:
+------------+------------------------------------------+-----------+
| Bit | Description | Reference |
+------------+------------------------------------------+-----------+
| 'L' | Label Distribution Protocol (LDP) | [RFC5036] |
| 'R' | Extension to RSVP for LSP Tunnels | [RFC3209] |
| | (RSVP-TE) | |
| 'Reserved' | Reserved for future use | |
+------------+------------------------------------------+-----------+
Table 10: MPLS Protocol Mask TLV Codes
Der TE Default Metric TLV trägt die Traffic-Engineering-Metrik für diesen Link. Die Länge dieses TLV ist fest auf 4 Oktette eingestellt. Wenn ein Quellprotokoll eine Metrikbreite von weniger als 32 Bits verwendet, dann MÜSSEN die höherwertigen Bits dieses Feldes mit Null aufgefüllt 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Default Link Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: TE Default Metric TLV Format
Der IGP Metric TLV trägt die Metrik für diesen Link. Die Länge dieses TLV ist variabel, abhängig von der Metrikbreite des zugrunde liegenden Protokolls. IS-IS-Kleinmetriken haben eine Länge von 1 Oktett (die zwei signifikantesten Bits werden ignoriert). OSPF-Link-Metriken haben eine Länge von 2 Oktetten. IS-IS-Breitmetriken haben eine Länge von 3 Oktetten.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IGP Link Metric (variable length) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: IGP Metric TLV Format
Der Shared Risk Link Group (SRLG) TLV trägt die Shared Risk Link Group-Informationen (siehe Abschnitt 2.3 ("Shared Risk Link Group Information") von [RFC4202]). Er enthält eine Datenstruktur, die aus einer (variablen) Liste von SRLG-Werten besteht, wobei jedes Element in der Liste 4 Oktette hat, wie in Abbildung 22 dargestellt. Die Länge dieses TLV beträgt 4 * (Anzahl der SRLG-Werte).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ............ //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Shared Risk Link Group TLV Format
Der SRLG TLV für OSPF-TE ist in [RFC4203] definiert. In IS-IS werden die SRLG-Informationen in zwei verschiedenen TLVs übertragen: dem IPv4 (SRLG) TLV (Typ 138), der in [RFC5307] definiert ist, und dem IPv6 SRLG TLV (Typ 139), der in [RFC6119] definiert ist. Im Link-State NLRI werden sowohl IPv4- als auch IPv6-SRLG-Informationen in einem einzigen TLV übertragen.
Der Opaque Link Attribute TLV ist eine Hülle, die optional Link Attribute TLVs transparent überträgt, die von einem Router angekündigt werden. Ein ursprünglicher Router muss diesen TLV verwenden, um Informationen zu kodieren, die spezifisch für das im NLRI-Header-Protocol-ID-Feld angekündigte Protokoll sind, oder neue Protokollerweiterungen zum im NLRI-Header-Protocol-ID-Feld angekündigten Protokoll, für die es keine protokollneutrale Darstellung im BGP Link-State NLRI gibt. Die primäre Verwendung des Opaque Link Attribute TLV besteht darin, die Dokumentenverzögerung zu überbrücken, z.B. zwischen der Definition eines neuen IGP-Link-State-Attributs und der Veröffentlichung der 'protokollneutralen' BGP-LS-Erweiterungen.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque link attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Opaque Link Attribute TLV Format
Der Link Name TLV ist optional. Das Value-Feld identifiziert den symbolischen Namen des Router-Links. Dieser symbolische Name kann der FQDN für den Link sein, er kann eine Teilmenge des FQDN sein, oder er kann eine beliebige Zeichenkette sein, die Operatoren für den Link verwenden möchten. Die Verwendung von FQDN oder einer Teilmenge davon wird dringend EMPFOHLEN. Die maximale Länge des Link Name TLV beträgt 255 Oktette. Das Value-Feld ist in 7-Bit-ASCII kodiert. Wenn eine Benutzerschnittstelle zum Konfigurieren oder Anzeigen dieses Feldes Unicode-Zeichen zulässt, ist diese Benutzerschnittstelle dafür verantwortlich, den ToASCII- und/oder ToUnicode-Algorithmus anzuwenden, wie in [RFC5890] beschrieben, um das korrekte Format für die Übertragung oder Anzeige zu erreichen.
Wie ein Router Link-Namen ableitet und injiziert, liegt außerhalb des Geltungsbereichs dieses Dokuments.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Link Name TLV Format
Präfixe werden aus der IGP-Topologie (IS-IS oder OSPF) mit einem Satz von IGP-Attributen (wie Metrik, Route-Tags usw.) gelernt, die im BGP-LS-Attribut mit einem Präfix-NLRI widergespiegelt werden MÜSSEN. Dieser Abschnitt beschreibt die verschiedenen Attribute, die sich auf die IPv4/IPv6-Präfixe beziehen.
Prefix Attribute TLVs SOLLTEN nur bei der Ankündigung von NLRI-Typen 3 und 4 verwendet werden. Die folgenden Prefix Attribute TLVs sind definiert:
+---------------+----------------------+----------+-----------------+
| TLV Code | Description | Length | Reference |
| Point | | | |
+---------------+----------------------+----------+-----------------+
| 1152 | IGP Flags | 1 | Section 3.3.3.1 |
| 1153 | IGP Route Tag | 4*n | [RFC5130] |
| 1154 | IGP Extended Route | 8*n | [RFC5130] |
| | Tag | | |
| 1155 | Prefix Metric | 4 | [RFC5305] |
| 1156 | OSPF Forwarding | 4 | [RFC2328] |
| | Address | | |
| 1157 | Opaque Prefix | variable | Section 3.3.3.6 |
| | Attribute | | |
+---------------+----------------------+----------+-----------------+
Table 11: Prefix Attribute TLVs
Der IGP Flags TLV enthält IS-IS- und OSPF-Flags und -Bits, die ursprünglich dem Präfix zugewiesen wurden. Der IGP Flags TLV ist 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|N|L|P| Resvd.|
+-+-+-+-+-+-+-+-+
Figure 25: IGP Flag TLV Format
Das Value-Feld enthält Bits, die gemäß der folgenden Tabelle definiert sind:
+----------+---------------------------+-----------+
| Bit | Description | Reference |
+----------+---------------------------+-----------+
| 'D' | IS-IS Up/Down Bit | [RFC5305] |
| 'N' | OSPF "no unicast" Bit | [RFC5340] |
| 'L' | OSPF "local address" Bit | [RFC5340] |
| 'P' | OSPF "propagate NSSA" Bit | [RFC5340] |
| Reserved | Reserved for future use. | |
+----------+---------------------------+-----------+
Table 12: IGP Flag Bits Definitions
Der IGP Route Tag TLV trägt ursprüngliche IGP-Tags (IS-IS [RFC5130] oder OSPF) des Präfixes und ist 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Route Tags (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: IGP Route Tag TLV Format
Length ist ein Vielfaches von 4. Das Value-Feld enthält einen oder mehrere Route-Tags, wie sie in der IGP-Topologie gelernt wurden.
Der Extended IGP Route Tag TLV trägt IS-IS Extended Route Tags des Präfixes [RFC5130] und ist 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extended Route Tag (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Extended IGP Route Tag TLV Format
Length ist ein Vielfaches von 8. Das Extended Route Tag-Feld enthält einen oder mehrere Extended Route Tags, wie sie in der IGP-Topologie gelernt wurden.
Der Prefix Metric TLV ist ein optionales Attribut und kann nur einmal auftreten. Wenn vorhanden, trägt er die Metrik des Präfixes, wie sie in der IGP-Topologie bekannt ist, wie in Abschnitt 4 von [RFC5305] beschrieben (und stellt daher die Erreichbarkeitskosten zum Präfix dar). Wenn nicht vorhanden, bedeutet dies, dass das Präfix ohne Erreichbarkeit angekündigt 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Prefix Metric TLV Format
Length beträgt 4.
Der OSPF Forwarding Address TLV [RFC2328] [RFC5340] trägt die OSPF-Weiterleitungsadresse, wie sie in der ursprünglichen OSPF-Ankündigung bekannt ist. Die Weiterleitungsadresse kann entweder IPv4 oder IPv6 sein.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Forwarding Address (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OSPF Forwarding Address TLV Format
Length beträgt 4 für eine IPv4-Weiterleitungsadresse und 16 für eine IPv6-Weiterleitungsadresse.
Der Opaque Prefix Attribute TLV ist eine Hülle, die optional Prefix Attribute TLVs transparent überträgt, die von einem Router angekündigt werden. Ein ursprünglicher Router muss diesen TLV verwenden, um Informationen zu kodieren, die spezifisch für das im NLRI-Header-Protocol-ID-Feld angekündigte Protokoll sind, oder neue Protokollerweiterungen zum im NLRI-Header-Protocol-ID-Feld angekündigten Protokoll, für die es keine protokollneutrale Darstellung im BGP Link-State NLRI gibt. Die primäre Verwendung des Opaque Prefix Attribute TLV besteht darin, die Dokumentenverzögerung zu überbrücken, z.B. zwischen der Definition eines neuen IGP-Link-State-Attributs und der Veröffentlichung der protokollneutralen BGP-LS-Erweiterungen.
Das Format des TLV ist 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque Prefix Attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Opaque Prefix Attribute TLV Format
Type ist wie in Tabelle 11 spezifiziert. Length ist variabel.