3. Summary of Operation (Riepilogo delle Operazioni)
3. Summary of Operation (Riepilogo delle Operazioni)
Il Border Gateway Protocol (BGP) è un protocollo di routing inter-Autonomous System. È costruito sull'esperienza acquisita con EGP (come definito in [RFC904]) e l'uso di EGP nella dorsale NSFNET (come descritto in [RFC1092] e [RFC1093]). Per ulteriori informazioni relative a BGP, vedere [RFC1772], [RFC1930], [RFC1997] e [RFC2858].
La funzione principale di un sistema che parla BGP è scambiare informazioni di raggiungibilità della rete con altri sistemi BGP. Queste informazioni di raggiungibilità della rete includono informazioni sull'elenco dei Sistemi Autonomi (AS) che le informazioni di raggiungibilità attraversano. Queste informazioni sono sufficienti per costruire un grafo della connettività AS per questa raggiungibilità, da cui i loop di routing possono essere eliminati e, a livello AS, alcune decisioni di policy possono essere applicate.
Nel contesto di questo documento, assumiamo che uno speaker BGP annunci ai suoi peer solo quelle route che usa esso stesso (in questo contesto, si dice che uno speaker BGP "usa" una route BGP se è la route BGP più preferita ed è usata 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 via BGP supportano solo il paradigma di inoltro basato sulla destinazione, che assume che un router inoltri un pacchetto basandosi esclusivamente sull'indirizzo di destinazione trasportato nell'intestazione IP del pacchetto. Questo, a sua volta, riflette l'insieme delle decisioni di policy che possono (e non possono) essere applicate utilizzando BGP. Si noti che alcune policy non possono essere supportate dal paradigma di inoltro basato sulla destinazione, e quindi richiedono tecniche come il source routing (alias explicit routing) per essere applicate. Tali policy non possono essere applicate nemmeno utilizzando BGP. Ad esempio, BGP non consente a un AS di inviare traffico a un AS vicino per l'inoltro a una destinazione (raggiungibile attraverso ma) oltre quell'AS vicino, con l'intenzione che il traffico prenda un percorso diverso da quello preso dal traffico originato nell'AS vicino (per quella stessa destinazione). D'altra parte, BGP può supportare qualsiasi policy conforme al paradigma di inoltro basato sulla destinazione.
BGP-4 fornisce un nuovo insieme di meccanismi per supportare il Classless Inter-Domain Routing (CIDR) [RFC1518, RFC1519]. Questi meccanismi includono il supporto per annunciare un insieme di destinazioni come un prefisso IP ed eliminare il concetto di "classe" di rete all'interno di BGP. BGP-4 introduce anche meccanismi che consentono l'aggregazione delle route, inclusa l'aggregazione dei percorsi AS.
Questo documento utilizza il termine `Autonomous System' (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 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 set 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 unico piano di routing interno coerente e presenta un'immagine coerente delle destinazioni raggiungibili attraverso di esso.
BGP utilizza TCP [RFC793] come suo protocollo di trasporto. Questo elimina la necessità di implementare frammentazione esplicita degli aggiornamenti, ritrasmissione, riconoscimento e sequenziamento. BGP ascolta sulla porta TCP 179. Il meccanismo di notifica degli errori utilizzato in BGP assume che TCP supporti una chiusura "graceful" (cioè, che tutti i dati in sospeso saranno consegnati prima che la connessione venga chiusa).
Una connessione TCP è formata 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 che è consentita dalla policy di esportazione, chiamata Adj-Ribs-Out (vedere 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 ai cambiamenti di policy locale di avere l'effetto corretto senza reimpostare alcuna connessione BGP, uno speaker BGP DOVREBBE o (a) conservare la versione corrente delle route annunciate ad esso da tutti i suoi peer per la durata della connessione, o (b) fare uso dell'estensione Route Refresh [RFC2918].
Messaggi KEEPALIVE possono essere inviati periodicamente per assicurare che la connessione sia attiva. Messaggi NOTIFICATION vengono inviati in risposta a errori o condizioni speciali. Se una connessione incontra una condizione di errore, un messaggio NOTIFICATION viene inviato e la connessione viene chiusa.
Un peer in un AS diverso è indicato come un peer esterno (external peer), mentre un peer nello stesso AS è indicato come un peer interno (internal peer). BGP interno ed esterno sono comunemente abbreviati come IBGP ed EBGP.
Se un particolare AS ha più speaker BGP e sta fornendo servizio di transito per altri AS, allora si deve prestare attenzione per assicurare una visione coerente del routing all'interno dell'AS. Una visione coerente delle route interne dell'AS è fornita dall'IGP utilizzato all'interno dell'AS. Ai fini di questo documento, si assume che una visione coerente delle route esterne all'AS sia fornita facendo in modo che tutti gli speaker BGP all'interno dell'AS mantengano IBGP l'uno con l'altro.
Questo documento specifica il comportamento di base del protocollo BGP. Questo comportamento può essere, ed è, modificato da specifiche di estensione. Quando il protocollo viene esteso, il nuovo comportamento è completamente documentato nelle specifiche di estensione.