3.2 The Link-State NLRI (Das Link-State NLRI)
3.2. The Link-State NLRI (Das Link-State NLRI)
Die MP_REACH_NLRI- und MP_UNREACH_NLRI-Attribute sind die Container von BGP zum Übertragen opaker Informationen. Jedes Link-State NLRI beschreibt entweder einen Knoten, einen Link oder ein Präfix.
Alle Nicht-VPN-Link-, Knoten- und Präfix-Informationen MÜSSEN unter Verwendung von AFI 16388 / SAFI 71 kodiert werden. VPN-Link-, Knoten- und Präfix-Informationen MÜSSEN unter Verwendung von AFI 16388 / SAFI 72 kodiert werden.
Damit zwei BGP-Speaker Link-State NLRIs austauschen können, MÜSSEN sie BGP Capabilities Advertisement verwenden, um sicherzustellen, dass beide in der Lage sind, solche NLRIs ordnungsgemäß zu verarbeiten. Dies erfolgt wie in [RFC4760] spezifiziert, unter Verwendung des Capability-Codes 1 (Multi-Protokoll-BGP), mit AFI 16388 / SAFI 71 für BGP-LS und AFI 16388 / SAFI 72 für BGP-LS-VPN.
Das Format des Link-State NLRI ist in den folgenden Abbildungen dargestellt.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Link-State AFI 16388 / SAFI 71 NLRI 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Route Distinguisher +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Link-State VPN AFI 16388 / SAFI 72 NLRI Format
Das Feld Total NLRI Length enthält die kumulative Länge in Oktetten des Rests des NLRI, ohne das NLRI Type-Feld oder sich selbst. Für VPN-Anwendungen enthält es auch die Länge des Route Distinguisher.
+------+---------------------------+
| Type | NLRI Type |
+------+---------------------------+
| 1 | Node NLRI |
| 2 | Link NLRI |
| 3 | IPv4 Topology Prefix NLRI |
| 4 | IPv6 Topology Prefix NLRI |
+------+---------------------------+
Table 1: NLRI Types
Route Distinguishers sind in [RFC4364] definiert und diskutiert.
Das Node NLRI (NLRI Type = 1) ist in der folgenden Abbildung dargestellt.
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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: The Node NLRI Format
Das Link NLRI (NLRI Type = 2) ist in der folgenden Abbildung dargestellt.
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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: The Link NLRI Format
Die IPv4- und IPv6-Präfix-NLRIs (NLRI Type = 3 und Type = 4) verwenden das gleiche Format, wie in der folgenden Abbildung dargestellt.
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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Prefix Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The IPv4/IPv6 Topology Prefix NLRI Format
Das Protocol-ID-Feld kann einen der folgenden Werte enthalten:
+-------------+----------------------------------+
| Protocol-ID | NLRI information source protocol |
+-------------+----------------------------------+
| 1 | IS-IS Level 1 |
| 2 | IS-IS Level 2 |
| 3 | OSPFv2 |
| 4 | Direct |
| 5 | Static configuration |
| 6 | OSPFv3 |
+-------------+----------------------------------+
Table 2: Protocol Identifiers
Die Protokolltypen 'Direct' und 'Static configuration' SOLLTEN verwendet werden, wenn BGP-LS lokale Informationen bezieht. Für alle aus anderen Protokollen abgeleiteten Informationen MUSS die entsprechende Protocol-ID verwendet werden. Wenn BGP-LS direkten Zugriff auf Schnittstelleninformationen hat und einen lokalen Link ankündigen möchte, dann SOLLTE die Protocol-ID 'Direct' verwendet werden. Zur Modellierung virtueller Links, wie in Abschnitt 4 beschrieben, SOLLTE die Protocol-ID 'Static configuration' verwendet werden.
Sowohl OSPF als auch IS-IS KÖNNEN mehrere Routing-Protokoll-Instanzen über denselben Link ausführen. Siehe [RFC6822] und [RFC6549]. Diese Instanzen definieren unabhängige "Routing-Universen". Das 64-Bit-Identifier-Feld wird verwendet, um das Routing-Universum zu identifizieren, zu dem das NLRI gehört. Die NLRIs, die Link-State-Objekte (Knoten, Links oder Präfixe) aus demselben Routing-Universum darstellen, MÜSSEN denselben 'Identifier'-Wert haben. NLRIs mit unterschiedlichen 'Identifier'-Werten MÜSSEN als aus unterschiedlichen Routing-Universen stammend betrachtet werden. Tabelle 3 listet die 'Identifier'-Werte auf, die in diesem Dokument als bekannt definiert sind.
+------------+----------------------------------+
| Identifier | Routing Universe |
+------------+----------------------------------+
| 0 | Default Layer 3 Routing topology |
+------------+----------------------------------+
Table 3: Well-Known Instance Identifiers
Wenn ein gegebenes Protokoll mehrere Routing-Universen nicht unterstützt, dann SOLLTE es das Identifier-Feld gemäß Tabelle 3 setzen. Eine Implementierung KANN jedoch den 'Identifier' für ein gegebenes Protokoll konfigurierbar machen.
Jeder Node Descriptor und Link Descriptor besteht aus einem oder mehreren TLVs, wie in den folgenden Abschnitten beschrieben.
Jeder Link ist durch ein Paar von Router-IDs verankert, die vom zugrunde liegenden IGP verwendet werden, nämlich eine 48-Bit-ISO-System-ID für IS-IS und eine 32-Bit-Router-ID für OSPFv2 und OSPFv3. Ein IGP kann eine oder mehrere zusätzliche Hilfs-Router-IDs verwenden, hauptsächlich für Traffic-Engineering-Zwecke. Beispielsweise kann IS-IS eine oder mehrere IPv4- und IPv6-TE-Router-IDs haben [RFC5305] [RFC6119]. Diese Hilfs-Router-IDs MÜSSEN im Link-Attribut enthalten sein, das in Abschnitt 3.3.2 beschrieben ist.
Es ist wünschenswert, dass die Router-ID-Zuweisungen innerhalb des Node Descriptor global eindeutig sind. Es kann jedoch Router-ID-Räume (z.B. ISO) geben, in denen keine globale Registrierung existiert, oder schlimmer noch, Router-IDs wurden gemäß der in RFC 1918 [RFC1918] beschriebenen privaten IP-Zuweisung zugewiesen. BGP-LS verwendet die Autonomous System (AS)-Nummer und den BGP-LS Identifier (siehe Abschnitt 3.2.1.4), um die Router-IDs zu disambiguieren, wie in Abschnitt 3.2.1.1 beschrieben.
Ein Problem, das gelöst werden muss, ist die Fähigkeit, einen IGP-Knoten global zu identifizieren (mit "global" meinen wir innerhalb der BGP-LS-Datenbank, die von allen BGP-LS-Sprechern gesammelt wird, die miteinander kommunizieren). Dies kann durch die folgenden zwei Anforderungen ausgedrückt werden:
(A) Derselbe Knoten DARF NICHT durch zwei Schlüssel dargestellt werden (andernfalls wird ein Knoten wie zwei Knoten aussehen).
(B) Zwei verschiedene Knoten DÜRFEN NICHT durch denselben Schlüssel dargestellt werden (andernfalls werden zwei Knoten wie ein Knoten aussehen).
Wir definieren eine "IGP-Domäne" als die Menge von Knoten (und damit durch Erweiterung Links und Präfixe), innerhalb derer jeder Knoten eine eindeutige IGP-Darstellung hat, indem die Kombination aus Area-ID, Router-ID, Protocol-ID, Multi-Topology-ID und Instance-ID verwendet wird. Das Problem besteht darin, dass BGP Knoten-/Link-/Präfix-Informationen von mehreren unabhängigen "IGP-Domänen" empfangen kann, und wir müssen zwischen ihnen unterscheiden. Darüber hinaus können wir nicht davon ausgehen, dass es immer eine und nur eine IGP-Domäne pro AS gibt. Während IGP-Übergängen kann es vorkommen, dass zwei redundante IGPs vorhanden sind.
In Abschnitt 3.2.1.4 wird ein Satz von Sub-TLVs beschrieben, der die Spezifikation eines flexiblen Schlüssels für jede gegebene Knoten-/Link-Information ermöglicht, sodass die globale Eindeutigkeit des NLRI sichergestellt ist.
Der Local Node Descriptors TLV enthält Node Descriptors für den Knoten, der das lokale Ende des Links verankert. Dies ist ein obligatorischer TLV in allen drei NLRI-Typen (Knoten, Link und Präfix). Die Länge dieses TLV ist variabel. Der Wert enthält einen oder mehrere Node Descriptor Sub-TLVs, die in Abschnitt 3.2.1.4 definiert sind.
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 Descriptor Sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Local Node Descriptors TLV Format
Der Remote Node Descriptors TLV enthält Node Descriptors für den Knoten, der das entfernte Ende des Links verankert. Dies ist ein obligatorischer TLV für Link-NLRIs. Die Länge dieses TLV ist variabel. Der Wert enthält einen oder mehrere Node Descriptor Sub-TLVs, die in Abschnitt 3.2.1.4 definiert sind.
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 Descriptor Sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Remote Node Descriptors TLV Format
Die Node Descriptor Sub-TLV-Typ-Codepunkte und -Längen sind in der folgenden Tabelle aufgeführt:
+--------------------+-------------------+----------+
| Sub-TLV Code Point | Description | Length |
+--------------------+-------------------+----------+
| 512 | Autonomous System | 4 |
| 513 | BGP-LS Identifier | 4 |
| 514 | OSPF Area-ID | 4 |
| 515 | IGP Router-ID | Variable |
+--------------------+-------------------+----------+
Table 4: Node Descriptor Sub-TLVs
Die Sub-TLV-Werte in Node Descriptor TLVs sind wie folgt definiert:
Autonomous System: Opaker Wert (32-Bit-AS-Nummer)
BGP-LS Identifier: Opaker Wert (32-Bit-ID). In Verbindung mit der Autonomous System Number (ASN) identifiziert er eindeutig die BGP-LS-Domäne. Die Kombination aus ASN und BGP-LS-ID MUSS global eindeutig sein. Alle BGP-LS-Sprecher innerhalb eines IGP-Flooding-Sets (Satz von IGP-Knoten, innerhalb derer ein LSP/LSA geflutet wird) MÜSSEN dasselbe ASN-, BGP-LS-ID-Tupel verwenden. Wenn eine IGP-Domäne aus mehreren Flooding-Sets besteht, dann SOLLTEN alle BGP-LS-Sprecher innerhalb der IGP-Domäne dasselbe ASN-, BGP-LS-ID-Tupel verwenden.
Area-ID: Wird verwendet, um den 32-Bit-Bereich zu identifizieren, zu dem das NLRI gehört. Der Area Identifier ermöglicht die Unterscheidung verschiedener NLRIs desselben Routers.
IGP Router-ID: Opaker Wert. Dies ist ein obligatorischer TLV. Für einen IS-IS-Nicht-Pseudoknoten enthält dies eine 6-Oktett-ISO-Node-ID (ISO-System-ID). Für einen IS-IS-Pseudoknoten, der einem LAN entspricht, enthält dies die ISO-Node-ID des DIS plus ein Nicht-Null-Oktett. Für OSPF enthält dies die OSPF-Router-ID.
Der Multi-Topology ID (MT-ID) TLV trägt eine oder mehrere IS-IS- oder OSPF-Multi-Topology-IDs für einen Link, Knoten oder Präfix.
Die Semantik der IS-IS MT-ID ist in Abschnitt 7.2 von RFC 5120 [RFC5120] definiert. Die Semantik der OSPF MT-ID ist in Abschnitt 3.7 von RFC 4915 [RFC4915] definiert. Wenn der Wert im MT-ID TLV von OSPF abgeleitet ist, dann MÜSSEN die oberen 9 Bits auf 0 gesetzt werden. Die Bits R sind reserviert und SOLLTEN bei der Ursprung auf 0 gesetzt und beim Empfang ignoriert werden.
Das Format des MT-ID TLV ist in der folgenden Abbildung dargestellt.
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=2*n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| Multi-Topology ID 1 | .... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// .... |R R R R| Multi-Topology ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Multi-Topology ID TLV Format
wobei Type 263 ist, Length 2*n ist und n die Anzahl der im TLV übertragenen MT-IDs ist.
Der MT-ID TLV KANN in einem Link Descriptor, einem Prefix Descriptor oder dem BGP-LS-Attribut eines Node NLRI vorhanden sein. In einem Link- oder Prefix-Descriptor ist nur ein einziger MT-ID TLV zulässig, der die MT-ID der Topologie enthält, in der der Link oder das Präfix erreichbar ist. Wenn man mehrere Topologien für einen gegebenen Link Descriptor oder Prefix Descriptor ankündigen möchte, müssen mehrere NLRIs generiert werden, wobei jedes NLRI eine eindeutige MT-ID enthält. Im BGP-LS-Attribut eines Node NLRI ist ein MT-ID TLV zulässig, der das Array von MT-IDs aller Topologien enthält, in denen der Knoten erreichbar ist.
Das Link Descriptor-Feld ist ein Satz von Type/Length/Value (TLV)-Tripeln. Das Format jedes TLV ist in Abschnitt 3.1 dargestellt. Die Link Descriptor TLVs identifizieren eindeutig einen Link unter mehreren parallelen Links zwischen einem Paar von Anker-Routern. Ein durch die Link Descriptor TLVs beschriebener Link ist tatsächlich ein "Halb-Link", eine unidirektionale Darstellung eines logischen Links. Um einen einzelnen logischen Link vollständig zu beschreiben, kündigen zwei ursprüngliche Router jeweils einen Halb-Link an, d.h. zwei Link-NLRIs werden für einen gegebenen Punkt-zu-Punkt-Link angekündigt.
Das Format und die Semantik der Value-Felder in den meisten Link Descriptor TLVs entsprechen dem Format und der Semantik der Value-Felder in IS-IS Extended IS Reachability Sub-TLVs, die in [RFC5305], [RFC5307] und [RFC6119] definiert sind. Obwohl die Kodierungen für Link Descriptor 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 TLVs sind als Link Descriptors im Link NLRI gültig:
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 |
| | Identifiers | | |
| 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 |
| | address | | |
| 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 |
| | address | | |
| 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 |
| | address | | |
| 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 |
| | address | | |
| 263 | Multi-Topology | --- | Section 3.2.1.5 |
| | Identifier | | |
+-----------+---------------------+--------------+------------------+
Table 5: Link Descriptor TLVs
Die Informationen über einen Link, die im LSA/LSP vorhanden sind, der vom lokalen Knoten des Links stammt, bestimmen den Satz von TLVs im Link Descriptor des Links.
Das Prefix Descriptor-Feld ist ein Satz von Type/Length/Value (TLV)-Tripeln. Prefix Descriptor TLVs identifizieren eindeutig ein IPv4- oder IPv6-Präfix, das von einem Knoten stammt. Die folgenden TLVs sind als Prefix Descriptors im IPv4/IPv6 Prefix NLRI gültig:
+-------------+---------------------+----------+--------------------+
| TLV Code | Description | Length | Reference |
| Point | | | (RFC/Section) |
+-------------+---------------------+----------+--------------------+
| 263 | Multi-Topology | variable | Section 3.2.1.5 |
| | Identifier | | |
| 264 | OSPF Route Type | 1 | Section 3.2.3.1 |
| 265 | IP Reachability | variable | Section 3.2.3.2 |
| | Information | | |
+-------------+---------------------+----------+--------------------+
Table 6: Prefix Descriptor TLVs
Der OSPF Route Type TLV ist ein optionaler TLV, der in Präfix-NLRIs vorhanden sein KANN. Er wird verwendet, um den OSPF-Routentyp des Präfixes zu identifizieren. Er wird verwendet, wenn ein OSPF-Präfix in der OSPF-Domäne mit mehreren Routentypen angekündigt wird. Der Route Type TLV ermöglicht die Unterscheidung dieser Ankündigungen. Das Format des OSPF Route Type TLV ist in der folgenden Abbildung dargestellt.
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 Type |
+-+-+-+-+-+-+-+-+
Figure 13: OSPF Route Type TLV Format
wobei die Type- und Length-Felder des TLV in Tabelle 6 definiert sind.
Die OSPF Route Type-Feldwerte sind im OSPF-Protokoll definiert und können einer der folgenden sein:
- Intra-Area (0x1)
- Inter-Area (0x2)
- External 1 (0x3)
- External 2 (0x4)
- NSSA 1 (0x5)
- NSSA 2 (0x6)
Der IP Reachability Information TLV ist ein obligatorischer TLV, der ein IP-Adresspräfix (IPv4 oder IPv6) enthält, das ursprünglich in der IGP-Topologie angekündigt wurde. Sein Zweck ist es, ein bestimmtes BGP-Service-NLRI durch seinen BGP-Next-Hop an einen gegebenen Knoten in der LSDB zu binden. Ein Router SOLLTE ein IP-Präfix-NLRI für jeden seiner BGP-Next-Hops ankündigen.
Das Format des IP Reachability Information TLV ist in der folgenden Abbildung dargestellt:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: IP Reachability Information TLV Format
Die Type- und Length-Felder des TLV sind in Tabelle 6 definiert. Die folgenden zwei Felder bestimmen die Erreichbarkeitsinformationen der Adressfamilie. Das Prefix Length-Feld enthält die Länge des Präfixes in Bits. Das IP Prefix-Feld enthält die signifikantesten Oktette des Präfixes, d.h. 1 Oktett für Präfixlänge 1 bis 8, 2 Oktette für Präfixlänge 9 bis 16, 3 Oktette für Präfixlänge 17 bis 24, 4 Oktette für Präfixlänge 25 bis 32 usw.