3.2 The Link-State NLRI
3.2. The Link-State NLRI
The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers
for carrying opaque information. Each Link-State NLRI describes
either a node, a link, or a prefix.
All non-VPN link, node, and prefix information SHALL be encoded using
AFI 16388 / SAFI 71. VPN link, node, and prefix information SHALL be
encoded using AFI 16388 / SAFI 72.
In order for two BGP speakers to exchange Link-State NLRI, they MUST
use BGP Capabilities Advertisement to ensure that they are both
capable of properly processing such NLRI. This is done as specified
in [RFC4760], by using capability code 1 (multi-protocol BGP), with
AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for
BGP-LS-VPN.
The format of the Link-State NLRI is shown in the following figures.
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
The Total NLRI Length field contains the cumulative length, in
octets, of the rest of the NLRI, not including the NLRI Type field or
itself. For VPN applications, it also includes the length of the
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 are defined and discussed in [RFC4364].
The Node NLRI (NLRI Type = 1) is shown in the following figure.
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
The Link NLRI (NLRI Type = 2) is shown in the following figure.
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
The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the
same format, as shown in the following figure.
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
The Protocol-ID field can contain one of the following values:
+-------------+----------------------------------+
| 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
The 'Direct' and 'Static configuration' protocol types SHOULD be used
when BGP-LS is sourcing local information. For all information
derived from other protocols, the corresponding Protocol-ID MUST be
used. If BGP-LS has direct access to interface information and wants
to advertise a local link, then the Protocol-ID 'Direct' SHOULD be
used. For modeling virtual links, such as described in Section 4,
the Protocol-ID 'Static configuration' SHOULD be used.
Both OSPF and IS-IS MAY run multiple routing protocol instances over
the same link. See [RFC6822] and [RFC6549]. These instances define
independent "routing universes". The 64-bit Identifier field is used
to identify the routing universe where the NLRI belongs. The NLRIs
representing link-state objects (nodes, links, or prefixes) from the
same routing universe MUST have the same 'Identifier' value. NLRIs
with different 'Identifier' values MUST be considered to be from
different routing universes. Table 3 lists the 'Identifier' values
that are defined as well-known in this document.
+------------+----------------------------------+
| Identifier | Routing Universe |
+------------+----------------------------------+
| 0 | Default Layer 3 Routing topology |
+------------+----------------------------------+
Table 3: Well-Known Instance Identifiers
If a given protocol does not support multiple routing universes, then
it SHOULD set the Identifier field according to Table 3. However, an
implementation MAY make the 'Identifier' configurable for a given
protocol.
Each Node Descriptor and Link Descriptor consists of one or more
TLVs, as described in the following sections.
Each link is anchored by a pair of Router-IDs that are used by the
underlying IGP, namely, a 48-bit ISO System-ID for IS-IS and a 32-bit
Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more
additional auxiliary Router-IDs, mainly for Traffic Engineering
purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE
Router-IDs [RFC5305] [RFC6119]. These auxiliary Router-IDs MUST be
included in the link attribute described in Section 3.3.2.
It is desirable that the Router-ID assignments inside the Node
Descriptor are globally unique. However, there may be Router-ID
spaces (e.g., ISO) where no global registry exists, or worse, Router-
IDs have been allocated following the private-IP allocation described
in RFC 1918 [RFC1918]. BGP-LS uses the Autonomous System (AS) Number
and BGP-LS Identifier (see Section 3.2.1.4) to disambiguate the
Router-IDs, as described in Section 3.2.1.1.
One problem that needs to be addressed is the ability to identify an
IGP node globally (by "globally", we mean within the BGP-LS database
collected by all BGP-LS speakers that talk to each other). This can
be expressed through the following two requirements:
(A) The same node MUST NOT be represented by two keys (otherwise, one node will look like two nodes).
(B) Two different nodes MUST NOT be represented by the same key (otherwise, two nodes will look like one node).
We define an "IGP domain" to be the set of nodes (hence, by extension
links and prefixes) within which each node has a unique IGP
representation by using the combination of Area-ID, Router-ID,
Protocol-ID, Multi-Topology ID, and Instance-ID. The problem is that
BGP may receive node/link/prefix information from multiple
independent "IGP domains", and we need to distinguish between them.
Moreover, we can't assume there is always one and only one IGP domain
per AS. During IGP transitions, it may happen that two redundant
IGPs are in place.
In Section 3.2.1.4, a set of sub-TLVs is described, which allows
specification of a flexible key for any given node/link information
such that global uniqueness of the NLRI is ensured.
The Local Node Descriptors TLV contains Node Descriptors for the node
anchoring the local end of the link. This is a mandatory TLV in all
three types of NLRIs (node, link, and prefix). The length of this
TLV is variable. The value contains one or more Node Descriptor
Sub-TLVs defined in Section 3.2.1.4.
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
The Remote Node Descriptors TLV contains Node Descriptors for the
node anchoring the remote end of the link. This is a mandatory TLV
for Link NLRIs. The length of this TLV is variable. The value
contains one or more Node Descriptor Sub-TLVs defined in
Section 3.2.1.4.
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
The Node Descriptor Sub-TLV type code points and lengths are listed
in the following table:
+--------------------+-------------------+----------+
| 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
The sub-TLV values in Node Descriptor TLVs are defined as follows:
Autonomous System: Opaque value (32-bit AS Number)
BGP-LS Identifier: Opaque value (32-bit ID). In conjunction with Autonomous System Number (ASN), uniquely identifies the BGP-LS domain. The combination of ASN and BGP-LS ID MUST be globally unique. All BGP-LS speakers within an IGP flooding-set (set of IGP nodes within which an LSP/LSA is flooded) MUST use the same ASN, BGP-LS ID tuple. If an IGP domain consists of multiple flooding-sets, then all BGP-LS speakers within the IGP domain SHOULD use the same ASN, BGP-LS ID tuple.
Area-ID: Used to identify the 32-bit area to which the NLRI belongs. The Area Identifier allows different NLRIs of the same router to be discriminated.
IGP Router-ID: Opaque value. This is a mandatory TLV. For an IS-IS non-pseudonode, this contains a 6-octet ISO Node-ID (ISO system- ID). For an IS-IS pseudonode corresponding to a LAN, this
The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF
Multi-Topology IDs for a link, node, or prefix.
Semantics of the IS-IS MT-ID are defined in Section 7.2 of RFC 5120
[RFC5120]. Semantics of the OSPF MT-ID are defined in Section 3.7 of
RFC 4915 [RFC4915]. If the value in the MT-ID TLV is derived from
OSPF, then the upper 9 bits MUST be set to 0. Bits R are reserved
and SHOULD be set to 0 when originated and ignored on receipt.
The format of the MT-ID TLV is shown in the following figure.
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
where Type is 263, Length is 2*n, and n is the number of MT-IDs
carried in the TLV.
The MT-ID TLV MAY be present in a Link Descriptor, a Prefix
Descriptor, or the BGP-LS attribute of a Node NLRI. In a Link or
Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of
the topology where the link or the prefix is reachable is allowed.
In case one wants to advertise multiple topologies for a given Link
Descriptor or Prefix Descriptor, multiple NLRIs need to be generated
where each NLRI contains an unique MT-ID. In the BGP-LS attribute of
a Node NLRI, one MT-ID TLV containing the array of MT-IDs of all
topologies where the node is reachable is allowed.
The Link Descriptor field is a set of Type/Length/Value (TLV)
triplets. The format of each TLV is shown in Section 3.1. The Link
Descriptor TLVs uniquely identify a link among multiple parallel
links between a pair of anchor routers. A link described by the Link
Descriptor TLVs actually is a "half-link", a unidirectional
representation of a logical link. In order to fully describe a
single logical link, two originating routers advertise a half-link
each, i.e., two Link NLRIs are advertised for a given point-to-point
link.
The format and semantics of the Value fields in most Link Descriptor
TLVs correspond to the format and semantics of Value fields in IS-IS
Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307],
and [RFC6119]. Although the encodings for Link Descriptor TLVs were
originally defined for IS-IS, the TLVs can carry data sourced by
either IS-IS or OSPF.
The following TLVs are valid as Link Descriptors in the Link NLRI:
+-----------+---------------------+--------------+------------------+
| 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
The information about a link present in the LSA/LSP originated by the
local node of the link determines the set of TLVs in the Link
Descriptor of the link.
The Prefix Descriptor field is a set of Type/Length/Value (TLV)
triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6
prefix originated by a node. The following TLVs are valid as Prefix
Descriptors in the IPv4/IPv6 Prefix NLRI:
+-------------+---------------------+----------+--------------------+
| 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
The OSPF Route Type TLV is an optional TLV that MAY be present in
Prefix NLRIs. It is used to identify the OSPF route type of the
prefix. It is used when an OSPF prefix is advertised in the OSPF
domain with multiple route types. The Route Type TLV allows the
discrimination of these advertisements. The format of the OSPF Route
Type TLV is shown in the following figure.
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
where the Type and Length fields of the TLV are defined in Table 6.
The OSPF Route Type field values are defined in the OSPF protocol and
can be one of the following:
-
Intra-Area (0x1)
-
Inter-Area (0x2)
-
External 1 (0x3)
-
External 2 (0x4)
-
NSSA 1 (0x5)
-
NSSA 2 (0x6)
The IP Reachability Information TLV is a mandatory TLV that contains
one IP address prefix (IPv4 or IPv6) originally advertised in the IGP
topology. Its purpose is to glue a particular BGP service NLRI by
virtue of its BGP next hop to a given node in the LSDB. A router
SHOULD advertise an IP Prefix NLRI for each of its BGP next hops.
The format of the IP Reachability Information TLV is shown in the
following figure:
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
The Type and Length fields of the TLV are defined in Table 6. The
following two fields determine the reachability information of the
address family. The Prefix Length field contains the length of the
prefix in bits. The IP Prefix field contains the most significant
octets of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2
octets for prefix length 9 to 16, 3 octets for prefix length 17 up to
24, 4 octets for prefix length 25 up to 32, etc.