3.2 The Link-State NLRI (Il Link-State NLRI)
3.2. The Link-State NLRI (Il Link-State NLRI)
Gli attributi MP_REACH_NLRI e MP_UNREACH_NLRI sono i contenitori di BGP per il trasporto di informazioni opache. Ogni Link-State NLRI descrive un nodo, un link o un prefisso.
Tutte le informazioni non-VPN su link, nodi e prefissi DEVONO essere codificate utilizzando AFI 16388 / SAFI 71. Le informazioni VPN su link, nodi e prefissi DEVONO essere codificate utilizzando AFI 16388 / SAFI 72.
Per consentire a due speaker BGP di scambiare Link-State NLRI, DEVONO utilizzare BGP Capabilities Advertisement per assicurarsi che entrambi siano in grado di elaborare correttamente tali NLRI. Questo avviene come specificato in [RFC4760], utilizzando il Capability Code 1 (Multi-Protocol BGP), con AFI 16388 / SAFI 71 per BGP-LS e AFI 16388 / SAFI 72 per BGP-LS-VPN.
Il formato del Link-State NLRI è mostrato nelle seguenti 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Il campo Total NLRI Length contiene la lunghezza cumulativa in ottetti del resto del NLRI, escluso il campo NLRI Type o se stesso. Per applicazioni VPN, include anche la lunghezza del 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
I Route Distinguisher sono definiti e discussi in [RFC4364].
Il Node NLRI (NLRI Type = 1) è mostrato nella seguente figura.
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
Il Link NLRI (NLRI Type = 2) è mostrato nella seguente figura.
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
Gli NLRI di prefisso IPv4 e IPv6 (NLRI Type = 3 e Type = 4) utilizzano lo stesso formato, come mostrato nella seguente figura.
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
Il campo Protocol-ID può contenere uno dei seguenti valori:
+-------------+----------------------------------+
| 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
I tipi di protocollo 'Direct' e 'Static configuration' DOVREBBERO essere utilizzati quando BGP-LS sta ottenendo informazioni locali. Per tutte le informazioni derivate da altri protocolli, DEVE essere utilizzato l'appropriato Protocol-ID. Se BGP-LS ha accesso diretto alle informazioni dell'interfaccia e desidera annunciare un link locale, allora DOVREBBE essere utilizzato il Protocol-ID 'Direct'. Per modellare link virtuali, come descritto nella Sezione 4, DOVREBBE essere utilizzato il Protocol-ID 'Static configuration'.
Sia OSPF che IS-IS POSSONO eseguire più istanze del protocollo di routing sullo stesso link. Vedere [RFC6822] e [RFC6549]. Queste istanze definiscono "universi di routing" indipendenti. Il campo Identifier a 64 bit viene utilizzato per identificare l'universo di routing a cui appartiene il NLRI. Gli NLRI che rappresentano oggetti Link-State (nodi, link o prefissi) dallo stesso universo di routing DEVONO avere lo stesso valore 'Identifier'. Gli NLRI con valori 'Identifier' diversi DEVONO essere considerati provenienti da universi di routing diversi. La Tabella 3 elenca i valori 'Identifier' definiti come noti in questo documento.
+------------+----------------------------------+
| Identifier | Routing Universe |
+------------+----------------------------------+
| 0 | Default Layer 3 Routing topology |
+------------+----------------------------------+
Table 3: Well-Known Instance Identifiers
Se un dato protocollo non supporta universi di routing multipli, allora DOVREBBE impostare il campo Identifier secondo la Tabella 3. Tuttavia, un'implementazione PUÒ rendere l''Identifier' configurabile per un dato protocollo.
Ogni Node Descriptor e Link Descriptor è composto da uno o più TLV, come descritto nelle seguenti sezioni.
Ogni link è ancorato da una coppia di Router-ID utilizzati dall'IGP sottostante, ovvero un System-ID ISO a 48 bit per IS-IS e un Router-ID a 32 bit per OSPFv2 e OSPFv3. Un IGP può utilizzare uno o più Router-ID ausiliari aggiuntivi, principalmente per scopi di Traffic Engineering. Ad esempio, IS-IS può avere uno o più Router-ID TE IPv4 e IPv6 [RFC5305] [RFC6119]. Questi Router-ID ausiliari DEVONO essere inclusi nell'attributo Link descritto nella Sezione 3.3.2.
È auspicabile che le assegnazioni dei Router-ID all'interno del Node Descriptor siano globalmente uniche. Tuttavia, potrebbero esserci spazi di Router-ID (ad esempio ISO) in cui non esiste una registrazione globale, o peggio ancora, i Router-ID sono stati assegnati secondo l'assegnazione IP privata descritta in RFC 1918 [RFC1918]. BGP-LS utilizza il numero di Autonomous System (AS) e il BGP-LS Identifier (vedi Sezione 3.2.1.4) per disambiguare i Router-ID, come descritto nella Sezione 3.2.1.1.
Un problema che deve essere risolto è la capacità di identificare globalmente un nodo IGP (dove per "globalmente" intendiamo all'interno del database BGP-LS raccolto da tutti gli speaker BGP-LS che comunicano tra loro). Questo può essere espresso dai seguenti due requisiti:
(A) Lo stesso nodo NON DEVE essere rappresentato da due chiavi (altrimenti un nodo apparirà come due nodi).
(B) Due nodi diversi NON DEVONO essere rappresentati dalla stessa chiave (altrimenti due nodi appariranno come un nodo).
Definiamo un "dominio IGP" come l'insieme di nodi (e quindi, per estensione, link e prefissi) all'interno dei quali ogni nodo ha una rappresentazione IGP unica utilizzando la combinazione di Area-ID, Router-ID, Protocol-ID, Multi-Topology-ID e Instance-ID. Il problema è che BGP può ricevere informazioni su nodi/link/prefissi da più "domini IGP" indipendenti e dobbiamo distinguere tra di loro. Inoltre, non possiamo assumere che ci sia sempre e solo un dominio IGP per AS. Durante le transizioni IGP, possono esserci due IGP ridondanti.
Nella Sezione 3.2.1.4 viene descritto un insieme di Sub-TLV che consente la specifica di una chiave flessibile per qualsiasi informazione su nodi/link, in modo tale che l'unicità globale del NLRI sia garantita.
Il TLV Local Node Descriptors contiene Node Descriptor per il nodo che ancora l'estremità locale del link. Questo è un TLV obbligatorio in tutti e tre i tipi di NLRI (nodo, link e prefisso). La lunghezza di questo TLV è variabile. Il valore contiene uno o più Node Descriptor Sub-TLV definiti nella Sezione 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
Il TLV Remote Node Descriptors contiene Node Descriptor per il nodo che ancora l'estremità remota del link. Questo è un TLV obbligatorio per i Link NLRI. La lunghezza di questo TLV è variabile. Il valore contiene uno o più Node Descriptor Sub-TLV definiti nella Sezione 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
I codici di tipo dei Node Descriptor Sub-TLV e le lunghezze sono elencati nella seguente tabella:
+--------------------+-------------------+----------+
| 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
I valori dei Sub-TLV nei Node Descriptor TLV sono definiti come segue:
Autonomous System: Valore opaco (numero AS a 32 bit)
BGP-LS Identifier: Valore opaco (ID a 32 bit). In combinazione con il numero Autonomous System (ASN), identifica in modo univoco il dominio BGP-LS. La combinazione di ASN e BGP-LS-ID DEVE essere globalmente univoca. Tutti gli speaker BGP-LS all'interno di un insieme di flooding IGP (insieme di nodi IGP all'interno dei quali viene eseguito il flooding di un LSP/LSA) DEVONO utilizzare la stessa tupla ASN, BGP-LS-ID. Se un dominio IGP è composto da più insiemi di flooding, allora tutti gli speaker BGP-LS all'interno del dominio IGP DOVREBBERO utilizzare la stessa tupla ASN, BGP-LS-ID.
Area-ID: Utilizzato per identificare l'area a 32 bit a cui appartiene il NLRI. L'Area Identifier consente la differenziazione di NLRI diversi dello stesso router.
IGP Router-ID: Valore opaco. Questo è un TLV obbligatorio. Per un non-pseudonodo IS-IS, contiene un Node-ID ISO a 6 ottetti (System-ID ISO). Per un pseudonodo IS-IS corrispondente a una LAN, contiene il Node-ID ISO del DIS più un ottetto non nullo. Per OSPF, contiene il Router-ID OSPF.
Il TLV Multi-Topology ID (MT-ID) trasporta uno o più ID Multi-Topology IS-IS o OSPF per un link, nodo o prefisso.
La semantica del MT-ID IS-IS è definita nella Sezione 7.2 di RFC 5120 [RFC5120]. La semantica del MT-ID OSPF è definita nella Sezione 3.7 di RFC 4915 [RFC4915]. Se il valore nel MT-ID TLV è derivato da OSPF, allora i 9 bit superiori DEVONO essere impostati a 0. I bit R sono riservati e DOVREBBERO essere impostati a 0 all'origine e ignorati alla ricezione.
Il formato del MT-ID TLV è mostrato nella seguente figura.
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
dove Type è 263, Length è 2*n, e n è il numero di MT-ID trasportati nel TLV.
Il MT-ID TLV PUÒ essere presente in un Link Descriptor, un Prefix Descriptor o l'attributo BGP-LS di un Node NLRI. In un Link o Prefix Descriptor è consentito un solo MT-ID TLV, che contiene il MT-ID della topologia in cui il link o il prefisso è raggiungibile. Se si desidera annunciare più topologie per un dato Link Descriptor o Prefix Descriptor, devono essere generati più NLRI, ciascuno contenente un MT-ID univoco. Nell'attributo BGP-LS di un Node NLRI è consentito un MT-ID TLV che contiene l'array di MT-ID di tutte le topologie in cui il nodo è raggiungibile.
Il campo Link Descriptor è un insieme di triple Type/Length/Value (TLV). Il formato di ciascun TLV è mostrato nella Sezione 3.1. I Link Descriptor TLV identificano in modo univoco un link tra più link paralleli tra una coppia di router di ancoraggio. Un link descritto dai Link Descriptor TLV è in realtà un "mezzo link", una rappresentazione unidirezionale di un link logico. Per descrivere completamente un singolo link logico, due router originari annunciano ciascuno un mezzo link, ovvero due Link NLRI vengono annunciati per un dato link point-to-point.
Il formato e la semantica dei campi Value nella maggior parte dei Link Descriptor TLV corrispondono al formato e alla semantica dei campi Value nei Sub-TLV IS-IS Extended IS Reachability definiti in [RFC5305], [RFC5307] e [RFC6119]. Sebbene le codifiche per i Link Descriptor TLV siano state originariamente definite per IS-IS, i TLV possono trasportare dati originati da IS-IS o OSPF.
I seguenti TLV sono validi come Link Descriptor nel 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
Le informazioni su un link presenti nell'LSA/LSP originato dal nodo locale del link determinano l'insieme di TLV nel Link Descriptor del link.
Il campo Prefix Descriptor è un insieme di triple Type/Length/Value (TLV). I Prefix Descriptor TLV identificano in modo univoco un prefisso IPv4 o IPv6 originato da un nodo. I seguenti TLV sono validi come Prefix Descriptor nell'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
Il TLV OSPF Route Type è un TLV opzionale che PUÒ essere presente nei Prefix NLRI. Viene utilizzato per identificare il tipo di route OSPF del prefisso. Viene utilizzato quando un prefisso OSPF viene annunciato nel dominio OSPF con più tipi di route. Il Route Type TLV consente la differenziazione di questi annunci. Il formato del TLV OSPF Route Type è mostrato nella seguente figura.
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
dove i campi Type e Length del TLV sono definiti nella Tabella 6.
I valori del campo OSPF Route Type sono definiti nel protocollo OSPF e possono essere uno dei seguenti:
- Intra-Area (0x1)
- Inter-Area (0x2)
- External 1 (0x3)
- External 2 (0x4)
- NSSA 1 (0x5)
- NSSA 2 (0x6)
Il TLV IP Reachability Information è un TLV obbligatorio che contiene un prefisso di indirizzo IP (IPv4 o IPv6) originariamente annunciato nella topologia IGP. Il suo scopo è collegare un dato BGP service NLRI tramite il suo BGP Next Hop a un dato nodo nell'LSDB. Un router DOVREBBE annunciare un IP Prefix NLRI per ciascuno dei suoi BGP Next Hop.
Il formato del TLV IP Reachability Information è mostrato nella seguente figura:
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
I campi Type e Length del TLV sono definiti nella Tabella 6. I seguenti due campi determinano le informazioni di raggiungibilità della famiglia di indirizzi. Il campo Prefix Length contiene la lunghezza del prefisso in bit. Il campo IP Prefix contiene gli ottetti più significativi del prefisso, ovvero 1 ottetto per lunghezza del prefisso da 1 a 8, 2 ottetti per lunghezza del prefisso da 9 a 16, 3 ottetti per lunghezza del prefisso da 17 a 24, 4 ottetti per lunghezza del prefisso da 25 a 32, ecc.