3. Riepilogo delle Operazioni (Summary of Operation)
Il Border Gateway Protocol (BGP) è un protocollo di routing inter-Autonomous System. È costruito sull'esperienza acquisita con EGP (come definito in [RFC904]) e sull'utilizzo di EGP nel backbone NSFNET (come descritto in [RFC1092] e [RFC1093]). Per ulteriori informazioni relative a BGP, consultare [RFC1772], [RFC1930], [RFC1997] e [RFC2858].
La funzione principale di un sistema che supporta BGP è scambiare informazioni sulla raggiungibilità della rete con altri sistemi BGP. Queste informazioni sulla raggiungibilità della rete includono informazioni sull'elenco dei sistemi autonomi (AS) attraversati dalle informazioni di raggiungibilità. Queste informazioni sono sufficienti per costruire un grafo di connettività AS, da cui i loop di routing possono essere eliminati e, a livello AS, alcune decisioni politiche possono essere applicate.
Nel contesto di questo documento, assumiamo che uno speaker BGP annunci ai suoi peer solo le route che utilizza esso stesso (in questo contesto, si dice che uno speaker BGP "usa" una route BGP se è la route BGP più preferita ed è utilizzata nell'inoltro). Tutti gli altri casi sono al di fuori dell'ambito di questo documento.
Nel contesto di questo documento, il termine "indirizzo IP" si riferisce a un indirizzo IP versione 4 [RFC791].
Le informazioni di routing scambiate tramite BGP supportano solo il paradigma di inoltro basato sulla destinazione, che presume che un router inoltri un pacchetto basandosi esclusivamente sull'indirizzo di destinazione contenuto nell'intestazione IP del pacchetto. Questo, a sua volta, riflette l'insieme delle decisioni politiche che possono (e non possono) essere applicate utilizzando BGP. Si noti che alcune politiche non possono essere supportate dal paradigma di inoltro basato sulla destinazione e richiedono quindi tecniche come il routing sorgente (noto anche come routing esplicito) per essere applicate. Tali politiche non possono essere applicate nemmeno utilizzando BGP. Ad esempio, BGP non consente a un AS di inviare traffico a un AS vicino per inoltrarlo verso una destinazione (raggiungibile attraverso ma) oltre quell'AS vicino, intendendo che il traffico prenda una route diversa da quella presa dal traffico che origina nell'AS vicino (per quella stessa destinazione). D'altra parte, BGP può supportare qualsiasi politica conforme al paradigma di inoltro basato sulla destinazione.
BGP-4 fornisce un nuovo insieme di meccanismi per supportare il routing inter-dominio senza classi (Classless Inter-Domain Routing, CIDR) [RFC1518, RFC1519]. Questi meccanismi includono il supporto per annunciare un insieme di destinazioni come prefisso IP ed eliminare il concetto di "classe" di rete all'interno di BGP. BGP-4 introduce anche meccanismi che consentono l'aggregazione di route, inclusa l'aggregazione di percorsi AS.
Questo documento utilizza il termine "Sistema Autonomo" (AS) in tutto il testo. La definizione classica di un sistema autonomo è un insieme di router sotto un'unica amministrazione tecnica, che utilizzano un protocollo di gateway interno (IGP) e metriche comuni per determinare come instradare i pacchetti all'interno dell'AS e utilizzano un protocollo di routing inter-AS per determinare come instradare i pacchetti verso altri AS. Da quando questa definizione classica è stata sviluppata, è diventato comune per un singolo AS utilizzare diversi IGP e, a volte, diversi insiemi di metriche all'interno di un AS. L'uso del termine Sistema Autonomo sottolinea il fatto che, anche quando vengono utilizzati più IGP e metriche, l'amministrazione di un AS appare agli altri AS come avente un piano di routing interno unico e coerente e presenta un'immagine coerente delle destinazioni raggiungibili attraverso di esso.
BGP utilizza TCP [RFC793] come protocollo di trasporto. Questo elimina la necessità di implementare la frammentazione, la ritrasmissione, il riconoscimento e il sequenziamento espliciti degli aggiornamenti. BGP ascolta sulla porta TCP 179. Il meccanismo di notifica degli errori utilizzato in BGP presume che TCP supporti una chiusura "graziosa" (cioè che tutti i dati in sospeso verranno consegnati prima che la connessione venga chiusa).
Una connessione TCP viene stabilita tra due sistemi. Essi scambiano messaggi per aprire e confermare i parametri di connessione.
Il flusso di dati iniziale è la porzione della tabella di routing BGP consentita dalla politica di esportazione, chiamata Adj-Ribs-Out (vedi 3.2). Gli aggiornamenti incrementali vengono inviati man mano che le tabelle di routing cambiano. BGP non richiede un aggiornamento periodico della tabella di routing. Per consentire alle modifiche delle politiche locali di avere l'effetto corretto senza reimpostare alcuna connessione BGP, uno speaker BGP dovrebbe (SHOULD) (a) mantenere la versione corrente delle route annunciate da tutti i suoi peer per la durata della connessione, oppure (b) utilizzare l'estensione Route Refresh [RFC2918].
I messaggi KEEPALIVE possono (MAY) essere inviati periodicamente per garantire che la connessione sia attiva. I messaggi NOTIFICATION vengono inviati in risposta a errori o condizioni speciali. Se una connessione incontra una condizione di errore, viene inviato un messaggio NOTIFICATION e la connessione viene chiusa.
Un peer in un AS diverso è chiamato peer esterno (external peer), mentre un peer nello stesso AS è chiamato peer interno (internal peer). Il BGP interno e il BGP esterno sono comunemente abbreviati come IBGP ed EBGP.
Se un AS particolare ha più speaker BGP e fornisce servizio di transito per altri AS, è necessario prestare attenzione per garantire una vista coerente del routing all'interno dell'AS. Una vista coerente delle route interne dell'AS è fornita dall'IGP utilizzato all'interno dell'AS. Ai fini di questo documento, si presume che una vista coerente delle route esterne all'AS sia fornita facendo in modo che tutti gli speaker BGP all'interno dell'AS mantengano l'IBGP tra loro.
Questo documento specifica il comportamento di base del protocollo BGP. Questo comportamento può essere, ed è, modificato dalle specifiche di estensione. Quando il protocollo viene esteso, il nuovo comportamento è completamente documentato nelle specifiche di estensione.
3.1. Route: Annuncio e Archiviazione (Routes: Advertisement and Storage)
Ai fini di questo protocollo, una route è definita come un'unità di informazione che associa un insieme di destinazioni con gli attributi di un percorso verso quelle destinazioni. L'insieme di destinazioni sono sistemi i cui indirizzi IP sono contenuti in un prefisso di indirizzo IP trasportato nel campo Network Layer Reachability Information (NLRI) di un messaggio UPDATE, e il percorso è l'informazione riportata nel campo degli attributi del percorso dello stesso messaggio UPDATE.
Le route vengono annunciate tra gli speaker BGP nei messaggi UPDATE. Più route che hanno gli stessi attributi di percorso possono essere annunciate in un singolo messaggio UPDATE includendo più prefissi nel campo NLRI del messaggio UPDATE.
Le route vengono memorizzate nelle basi di informazioni di routing (Routing Information Bases, RIB): ovvero, gli Adj-RIBs-In, il Loc-RIB e gli Adj-RIBs-Out, come descritto nella sezione 3.2.
Se uno speaker BGP sceglie di annunciare una route precedentemente ricevuta, può (MAY) aggiungere o modificare gli attributi del percorso della route prima di annunciarla a un peer.
BGP fornisce meccanismi mediante i quali uno speaker BGP può informare i suoi peer che una route precedentemente annunciata non è più disponibile per l'uso. Esistono tre metodi mediante i quali uno speaker BGP può indicare che una route è stata ritirata dal servizio:
a) il prefisso IP che esprime la destinazione per una route precedentemente annunciata può essere annunciato nel campo WITHDRAWN ROUTES del messaggio UPDATE, contrassegnando così la route associata come non più disponibile per l'uso,
b) una route sostitutiva con lo stesso NLRI può essere annunciata, oppure
c) la connessione dello speaker BGP può essere chiusa, il che rimuove implicitamente tutte le route che la coppia di speaker si era annunciata reciprocamente dal servizio.
La modifica degli attributi di una route viene realizzata annunciando una route sostitutiva. La route sostitutiva porta nuovi attributi (modificati) e ha lo stesso prefisso di indirizzo della route originale.
3.2. Base di Informazioni di Routing (Routing Information Base)
La base di informazioni di routing (Routing Information Base, RIB) all'interno di uno speaker BGP è composta da tre parti distinte:
a) Adj-RIBs-In: Gli Adj-RIBs-In memorizzano le informazioni di routing apprese dai messaggi UPDATE in entrata ricevuti da altri speaker BGP. Il loro contenuto rappresenta le route disponibili come input per il processo di decisione (Decision Process).
b) Loc-RIB: Il Loc-RIB contiene le informazioni di routing locali che lo speaker BGP ha selezionato applicando le sue politiche locali alle informazioni di routing contenute nei suoi Adj-RIBs-In. Queste sono le route che verranno utilizzate dallo speaker BGP locale. Il next hop per ciascuna di queste route deve (MUST) essere risolvibile tramite la tabella di routing dello speaker BGP locale.
c) Adj-RIBs-Out: Gli Adj-RIBs-Out memorizzano le informazioni che lo speaker BGP locale ha selezionato per l'annuncio ai suoi peer. Le informazioni di routing memorizzate negli Adj-RIBs-Out verranno trasportate nei messaggi UPDATE dello speaker BGP locale e annunciate ai suoi peer.
In sintesi, gli Adj-RIBs-In contengono informazioni di routing non elaborate che sono state annunciate allo speaker BGP locale dai suoi peer; il Loc-RIB contiene le route che sono state selezionate dal processo di decisione dello speaker BGP locale; e gli Adj-RIBs-Out organizzano le route per l'annuncio a peer specifici (mediante i messaggi UPDATE dello speaker locale).
Sebbene il modello concettuale distingua tra Adj-RIBs-In, Loc-RIB e Adj-RIBs-Out, ciò non implica né richiede che un'implementazione debba mantenere tre copie separate delle informazioni di routing. La scelta dell'implementazione (ad esempio, 3 copie delle informazioni rispetto a 1 copia con puntatori) non è vincolata dal protocollo.
Le informazioni di routing che lo speaker BGP utilizza per inoltrare i pacchetti (o per costruire la tabella di inoltro utilizzata per l'inoltro dei pacchetti) sono mantenute nella tabella di routing (Routing Table). La tabella di routing accumula route verso reti direttamente connesse, route statiche, route apprese dai protocolli IGP e route apprese da BGP. Se una route BGP specifica debba essere installata nella tabella di routing e se una route BGP debba sovrascrivere una route verso la stessa destinazione installata da un'altra fonte è una decisione di politica locale e non è specificata in questo documento. Oltre all'effettivo inoltro dei pacchetti, la tabella di routing viene utilizzata per la risoluzione degli indirizzi next hop specificati negli aggiornamenti BGP (vedi sezione 5.1.3).