3.2 The Link-State NLRI (NLRI d'état de liaison)
3.2. The Link-State NLRI (NLRI d'état de liaison)
Les attributs MP_REACH_NLRI et MP_UNREACH_NLRI sont les conteneurs de BGP pour transporter des informations opaques. Chaque Link-State NLRI décrit soit un noeud, soit un lien, soit un préfixe.
Toutes les informations de lien, de noeud et de préfixe non-VPN DOIVENT être encodées en utilisant AFI 16388 / SAFI 71. Les informations de lien, de noeud et de préfixe VPN DOIVENT être encodées en utilisant AFI 16388 / SAFI 72.
Pour que deux locuteurs BGP puissent échanger des Link-State NLRI, ils DOIVENT utiliser BGP Capabilities Advertisement pour s'assurer qu'ils sont tous deux capables de traiter correctement ces NLRI. Ceci est fait comme spécifié dans [RFC4760], en utilisant le code de capacité 1 (multi-protocol BGP), avec AFI 16388 / SAFI 71 pour BGP-LS, et AFI 16388 / SAFI 72 pour BGP-LS-VPN.
Le format du Link-State NLRI est montré dans les figures suivantes.
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
Le champ Total NLRI Length contient la longueur cumulative, en octets, du reste du NLRI, n'incluant pas le champ NLRI Type ou lui-même. Pour les applications VPN, il inclut également la longueur du 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
Les Route Distinguishers sont définis et discutés dans [RFC4364].
Le Node NLRI (NLRI Type = 1) est montré dans la figure suivante.
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
Le Link NLRI (NLRI Type = 2) est montré dans la figure suivante.
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
Les IPv4 et IPv6 Prefix NLRIs (NLRI Type = 3 et Type = 4) utilisent le même format, comme montré dans la figure suivante.
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
Le champ Protocol-ID peut contenir l'une des valeurs suivantes:
+-------------+----------------------------------+
| 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
Les types de protocole 'Direct' et 'Static configuration' DEVRAIENT être utilisés lorsque BGP-LS source des informations locales. Pour toutes les informations dérivées d'autres protocoles, le Protocol-ID correspondant DOIT être utilisé. Si BGP-LS a un accès direct aux informations d'interface et souhaite annoncer un lien local, alors le Protocol-ID 'Direct' DEVRAIT être utilisé. Pour modéliser des liens virtuels, tels que décrits dans la Section 4, le Protocol-ID 'Static configuration' DEVRAIT être utilisé.
OSPF et IS-IS PEUVENT exécuter plusieurs instances de protocole de routage sur le même lien. Voir [RFC6822] et [RFC6549]. Ces instances définissent des "univers de routage" indépendants. Le champ Identifier de 64 bits est utilisé pour identifier l'univers de routage auquel appartient le NLRI. Les NLRIs représentant des objets d'état de liaison (noeuds, liens ou préfixes) du même univers de routage DOIVENT avoir la même valeur 'Identifier'. Les NLRIs avec des valeurs 'Identifier' différentes DOIVENT être considérés comme provenant d'univers de routage différents. Le Tableau 3 liste les valeurs 'Identifier' qui sont définies comme bien connues dans ce document.
+------------+----------------------------------+
| Identifier | Routing Universe |
+------------+----------------------------------+
| 0 | Default Layer 3 Routing topology |
+------------+----------------------------------+
Table 3: Well-Known Instance Identifiers
Si un protocole donné ne supporte pas plusieurs univers de routage, alors il DEVRAIT définir le champ Identifier selon le Tableau 3. Cependant, une implémentation PEUT rendre l' 'Identifier' configurable pour un protocole donné.
Chaque Node Descriptor et Link Descriptor consiste en un ou plusieurs TLVs, comme décrit dans les sections suivantes.
Chaque lien est ancré par une paire de Router-IDs utilisés par l'IGP sous-jacent, à savoir un System-ID ISO de 48 bits pour IS-IS et un Router-ID de 32 bits pour OSPFv2 et OSPFv3. Un IGP peut utiliser un ou plusieurs Router-IDs auxiliaires supplémentaires, principalement à des fins de Traffic Engineering. Par exemple, IS-IS peut avoir un ou plusieurs TE Router-IDs IPv4 et IPv6 [RFC5305] [RFC6119]. Ces Router-IDs auxiliaires DOIVENT être inclus dans l'attribut de lien décrit dans la Section 3.3.2.
Il est souhaitable que les affectations de Router-ID à l'intérieur du Node Descriptor soient globalement uniques. Cependant, il peut y avoir des espaces de Router-ID (par exemple, ISO) où aucun registre global n'existe, ou pire, des Router-IDs ont été alloués suivant l'allocation IP privée décrite dans RFC 1918 [RFC1918]. BGP-LS utilise le numéro de système autonome (AS) et l'identifiant BGP-LS (voir Section 3.2.1.4) pour désambiguïser les Router-IDs, comme décrit dans la Section 3.2.1.1.
Un problème qui doit être résolu est la capacité d'identifier un noeud IGP globalement (par "globalement", nous entendons dans la base de données BGP-LS collectée par tous les locuteurs BGP-LS qui communiquent entre eux). Ceci peut être exprimé à travers les deux exigences suivantes:
(A) Le même noeud NE DOIT PAS être représenté par deux clés (sinon, un noeud ressemblera à deux noeuds).
(B) Deux noeuds différents NE DOIVENT PAS être représentés par la même clé (sinon, deux noeuds ressembleront à un seul noeud).
Nous définissons un "domaine IGP" comme l'ensemble de noeuds (donc, par extension, de liens et de préfixes) dans lequel chaque noeud a une représentation IGP unique en utilisant la combinaison d'Area-ID, Router-ID, Protocol-ID, Multi-Topology ID et Instance-ID. Le problème est que BGP peut recevoir des informations de noeud/lien/préfixe de multiples "domaines IGP" indépendants, et nous devons les distinguer. De plus, nous ne pouvons pas supposer qu'il y a toujours un et un seul domaine IGP par AS. Pendant les transitions IGP, il peut arriver que deux IGPs redondants soient en place.
Dans la Section 3.2.1.4, un ensemble de sub-TLVs est décrit, qui permet la spécification d'une clé flexible pour toute information de noeud/lien donnée de telle sorte que l'unicité globale du NLRI soit assurée.
Le TLV Local Node Descriptors contient des Node Descriptors pour le noeud ancrant l'extrémité locale du lien. C'est un TLV obligatoire dans tous les trois types de NLRIs (noeud, lien et préfixe). La longueur de ce TLV est variable. La valeur contient un ou plusieurs Node Descriptor Sub-TLVs définis dans la 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
Le TLV Remote Node Descriptors contient des Node Descriptors pour le noeud ancrant l'extrémité distante du lien. C'est un TLV obligatoire pour les Link NLRIs. La longueur de ce TLV est variable. La valeur contient un ou plusieurs Node Descriptor Sub-TLVs définis dans la 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
Les points de code de type Sub-TLV de Node Descriptor et les longueurs sont listés dans le tableau suivant:
+--------------------+-------------------+----------+
| 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
Les valeurs de sub-TLV dans les TLVs Node Descriptor sont définies comme suit:
Autonomous System: Valeur opaque (numéro AS 32 bits)
BGP-LS Identifier: Valeur opaque (ID 32 bits). En conjonction avec le numéro de système autonome (ASN), identifie de manière unique le domaine BGP-LS. La combinaison d'ASN et de BGP-LS ID DOIT être globalement unique. Tous les locuteurs BGP-LS au sein d'un ensemble d'inondation IGP (ensemble de noeuds IGP dans lequel un LSP/LSA est inondé) DOIVENT utiliser le même tuple ASN, BGP-LS ID. Si un domaine IGP consiste en plusieurs ensembles d'inondation, alors tous les locuteurs BGP-LS au sein du domaine IGP DEVRAIENT utiliser le même tuple ASN, BGP-LS ID.
Area-ID: Utilisé pour identifier la zone de 32 bits à laquelle appartient le NLRI. L'identifiant d'aire permet de discriminer différents NLRIs du même routeur.
IGP Router-ID: Valeur opaque. C'est un TLV obligatoire. Pour un non-pseudonode IS-IS, cela contient un Node-ID ISO de 6 octets (system-ID ISO). Pour un pseudonode IS-IS correspondant à un LAN, cela contient l'ISO Node-ID du DIS plus un octet non nul. Pour OSPF, cela contient le Router-ID OSPF.
Le TLV Multi-Topology ID (MT-ID) transporte un ou plusieurs IDs de Multi-Topology IS-IS ou OSPF pour un lien, un noeud ou un préfixe.
La sémantique du MT-ID IS-IS est définie dans la Section 7.2 de RFC 5120 [RFC5120]. La sémantique du MT-ID OSPF est définie dans la Section 3.7 de RFC 4915 [RFC4915]. Si la valeur dans le TLV MT-ID est dérivée d'OSPF, alors les 9 bits supérieurs DOIVENT être mis à 0. Les bits R sont réservés et DEVRAIENT être mis à 0 lors de l'origine et ignorés à la réception.
Le format du TLV MT-ID est montré dans la figure suivante.
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
où Type est 263, Length est 2*n, et n est le nombre de MT-IDs transportés dans le TLV.
Le TLV MT-ID PEUT être présent dans un Link Descriptor, un Prefix Descriptor, ou l'attribut BGP-LS d'un Node NLRI. Dans un Link ou Prefix Descriptor, un seul TLV MT-ID contenant le MT-ID de la topologie où le lien ou le préfixe est atteignable est autorisé. Dans le cas où l'on souhaite annoncer plusieurs topologies pour un Link Descriptor ou Prefix Descriptor donné, plusieurs NLRIs doivent être générés où chaque NLRI contient un MT-ID unique. Dans l'attribut BGP-LS d'un Node NLRI, un TLV MT-ID contenant le tableau de MT-IDs de toutes les topologies où le noeud est atteignable est autorisé.
Le champ Link Descriptor est un ensemble de triplets Type/Length/Value (TLV). Le format de chaque TLV est montré dans la Section 3.1. Les TLVs Link Descriptor identifient de manière unique un lien parmi plusieurs liens parallèles entre une paire de routeurs d'ancrage. Un lien décrit par les TLVs Link Descriptor est en fait un "demi-lien", une représentation unidirectionnelle d'un lien logique. Afin de décrire complètement un seul lien logique, deux routeurs d'origine annoncent chacun un demi-lien, c'est-à-dire que deux Link NLRIs sont annoncés pour un lien point-à-point donné.
Le format et la sémantique des champs Value dans la plupart des TLVs Link Descriptor correspondent au format et à la sémantique des champs Value dans les sub-TLVs IS-IS Extended IS Reachability, définis dans [RFC5305], [RFC5307], et [RFC6119]. Bien que les encodages pour les TLVs Link Descriptor aient été initialement définis pour IS-IS, les TLVs peuvent transporter des données provenant soit d'IS-IS soit d'OSPF.
Les TLVs suivants sont valides comme Link Descriptors dans le 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
Les informations sur un lien présent dans le LSA/LSP originé par le noeud local du lien déterminent l'ensemble de TLVs dans le Link Descriptor du lien.
Le champ Prefix Descriptor est un ensemble de triplets Type/Length/Value (TLV). Les TLVs Prefix Descriptor identifient de manière unique un préfixe IPv4 ou IPv6 originé par un noeud. Les TLVs suivants sont valides comme Prefix Descriptors dans le 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
Le TLV OSPF Route Type est un TLV optionnel qui PEUT être présent dans les Prefix NLRIs. Il est utilisé pour identifier le type de route OSPF du préfixe. Il est utilisé lorsqu'un préfixe OSPF est annoncé dans le domaine OSPF avec plusieurs types de route. Le TLV Route Type permet la discrimination de ces annonces. Le format du TLV OSPF Route Type est montré dans la figure suivante.
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
où les champs Type et Length du TLV sont définis dans le Tableau 6.
Les valeurs du champ OSPF Route Type sont définies dans le protocole OSPF et peuvent être l'une des suivantes:
- Intra-Area (0x1)
- Inter-Area (0x2)
- External 1 (0x3)
- External 2 (0x4)
- NSSA 1 (0x5)
- NSSA 2 (0x6)
Le TLV IP Reachability Information est un TLV obligatoire qui contient un préfixe d'adresse IP (IPv4 ou IPv6) initialement annoncé dans la topologie IGP. Son objectif est de coller un NLRI de service BGP particulier en vertu de son next hop BGP à un noeud donné dans le LSDB. Un routeur DEVRAIT annoncer un IP Prefix NLRI pour chacun de ses next hops BGP.
Le format du TLV IP Reachability Information est montré dans la figure suivante:
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
Les champs Type et Length du TLV sont définis dans le Tableau 6. Les deux champs suivants déterminent les informations de joignabilité de la famille d'adresses. Le champ Prefix Length contient la longueur du préfixe en bits. Le champ IP Prefix contient les octets les plus significatifs du préfixe, c'est-à-dire 1 octet pour une longueur de préfixe de 1 à 8, 2 octets pour une longueur de préfixe de 9 à 16, 3 octets pour une longueur de préfixe de 17 à 24, 4 octets pour une longueur de préfixe de 25 à 32, etc.