Passa al contenuto principale

9. UPDATE Message Handling (Gestione dei messaggi UPDATE)

  1. UPDATE Message Handling (Gestione dei messaggi UPDATE)

    Un messaggio UPDATE può essere ricevuto solo nello stato Established. Ricevere un messaggio UPDATE in qualsiasi altro stato è un errore. Quando viene ricevuto un messaggio UPDATE, ogni campo viene controllato per la validità, come specificato nella Sezione 6.3.

    Se un attributo opzionale non-transitivo non è riconosciuto, viene silenziosamente ignorato. Se un attributo opzionale transitivo non è riconosciuto, il bit Partial (il terzo bit più significativo) nell'ottetto dei flag dell'attributo viene impostato a 1, e l'attributo viene conservato per la propagazione ad altri speaker BGP.

    Se un attributo opzionale è riconosciuto e ha un valore valido, allora, a seconda del tipo dell'attributo opzionale, viene elaborato localmente, conservato e aggiornato, se necessario, per una possibile propagazione ad altri speaker BGP.

    Se il messaggio UPDATE contiene un campo WITHDRAWN ROUTES non vuoto, le route precedentemente annunciate, le cui destinazioni (espresse come prefissi IP) sono contenute in questo campo, devono (SHALL) essere rimosse dall'Adj-RIB-In. Questo speaker BGP deve (SHALL) eseguire il suo processo di decisione perché la route precedentemente annunciata non è più disponibile per l'uso.

    Se il messaggio UPDATE contiene una route fattibile, l'Adj-RIB-In verrà aggiornato con questa route come segue: se il NLRI della nuova route è identico a quello che la route ha attualmente memorizzato nell'Adj-RIB-In, allora la nuova route deve (SHALL) sostituire la route più vecchia nell'Adj-RIB-In, ritirando così implicitamente la route più vecchia dal servizio. Altrimenti, se l'Adj-RIB-In non ha route con NLRI identico alla nuova route, la nuova route deve (SHALL) essere posta nell'Adj-RIB-In.

    Una volta che lo speaker BGP aggiorna l'Adj-RIB-In, lo speaker deve (SHALL) eseguire il suo processo di decisione.

9.1. Decision Process (Processo di decisione)

Il processo di decisione seleziona le route per l'annuncio successivo applicando le politiche nella Policy Information Base locale (PIB) alle route memorizzate nei suoi Adj-RIBs-In. L'output del processo di decisione è l'insieme delle route che verranno annunciate ai peer; le route selezionate verranno memorizzate negli Adj-RIBs-Out dello speaker locale, secondo la politica.

Il processo di decisione BGP descritto qui è concettuale e non deve essere implementato precisamente come descritto, purché le implementazioni supportino la funzionalità descritta ed esibiscano lo stesso comportamento visibile esternamente.

Il processo di selezione è formalizzato definendo una funzione che prende l'attributo di una data route come argomento e restituisce (a) un intero non negativo che denota il grado di preferenza per la route, o (b) un valore che denota che questa route non è idonea per essere installata in Loc-RIB e sarà esclusa dalla fase successiva di selezione della route.

La funzione che calcola il grado di preferenza per una data route non deve (SHALL NOT) utilizzare nessuno dei seguenti come suoi input: l'esistenza di altre route, la non esistenza di altre route, o gli attributi di percorso di altre route. La selezione della route consiste quindi nell'applicazione individuale della funzione di grado di preferenza a ogni route fattibile, seguita dalla scelta di quella con il più alto grado di preferenza.

Il processo di decisione opera sulle route contenute negli Adj-RIBs-In, ed è responsabile di:

  • selezione delle route da utilizzare localmente dallo speaker

  • selezione delle route da annunciare ad altri peer BGP

  • aggregazione di route e riduzione delle informazioni di route

Il processo di decisione si svolge in tre fasi distinte, ciascuna innescata da un evento diverso:

a) La fase 1 è responsabile del calcolo del grado di preferenza per ogni route ricevuta da un peer.

b) La fase 2 viene invocata al completamento della fase 1. È responsabile della scelta della route migliore tra tutte quelle disponibili per ogni destinazione distinta, e dell'installazione di ogni route scelta nel Loc-RIB.

c) La fase 3 viene invocata dopo che il Loc-RIB è stato modificato. È responsabile della disseminazione delle route nel Loc-RIB a ogni peer, secondo le politiche contenute nel PIB. L'aggregazione di route e la riduzione delle informazioni possono opzionalmente essere eseguite in questa fase.

9.1.1. Phase 1: Calculation of Degree of Preference (Fase 1: Calcolo del grado di preferenza)

La funzione di decisione di fase 1 viene invocata ogni volta che lo speaker BGP locale riceve, da un peer, un messaggio UPDATE che annuncia una nuova route, una route di sostituzione o route ritirate.

La funzione di decisione di fase 1 è un processo separato che si completa quando non ha più lavoro da fare.

La funzione di decisione di fase 1 blocca un Adj-RIB-In prima di operare su qualsiasi route contenuta al suo interno, e lo sblocca dopo aver operato su tutte le route nuove o non fattibili contenute al suo interno.

Per ogni route fattibile appena ricevuta o di sostituzione, lo speaker BGP locale determina un grado di preferenza come segue:

Se la route è appresa da un peer interno, viene preso come grado di preferenza il valore dell'attributo LOCAL_PREF, oppure il sistema locale calcola il grado di preferenza della route in base alle informazioni di politica preconfigurate. Si noti che quest'ultima può risultare nella formazione di cicli di routing persistenti.

Se la route è appresa da un peer esterno, allora lo speaker BGP locale calcola il grado di preferenza in base alle informazioni di politica preconfigurate. Se il valore di ritorno indica che la route non è idonea, la route non può (MAY NOT) servire come input alla fase successiva di selezione della route; altrimenti, il valore di ritorno deve (MUST) essere utilizzato come valore LOCAL_PREF in qualsiasi riannuncio IBGP.

La natura esatta di queste informazioni di politica, e il calcolo coinvolto, è una questione locale.

9.1.2. Phase 2: Route Selection (Fase 2: Selezione della route)

La funzione di decisione di fase 2 viene invocata al completamento della fase 1. La funzione di fase 2 è un processo separato che si completa quando non ha più lavoro da fare. Il processo di fase 2 considera tutte le route che sono idonee negli Adj-RIBs-In.

La funzione di decisione di fase 2 è bloccata dall'esecuzione mentre la funzione di decisione di fase 3 è in corso. La funzione di fase 2 blocca tutti gli Adj-RIBs-In prima di iniziare la sua funzione, e li sblocca al completamento.

Se l'attributo NEXT_HOP di una route BGP raffigura un indirizzo che non è risolvibile, o se diventerebbe non risolvabile se la route fosse installata nella tabella di routing, la route BGP deve (MUST) essere esclusa dalla funzione di decisione di fase 2.

Se l'attributo AS_PATH di una route BGP contiene un ciclo AS, la route BGP dovrebbe (SHOULD) essere esclusa dalla funzione di decisione di fase 2. Il rilevamento del ciclo AS viene effettuato scansionando il percorso AS completo (come specificato nell'attributo AS_PATH) e verificando che il numero di sistema autonomo del sistema locale non appaia nel percorso AS. Le operazioni di uno speaker BGP configurato per accettare route con il proprio numero di sistema autonomo nel percorso AS sono al di fuori dell'ambito di questo documento.

È critico che gli speaker BGP all'interno di un AS non prendano decisioni contrastanti riguardo alla selezione della route che potrebbero causare l'occorrenza di cicli di inoltro.

Per ogni insieme di destinazioni per cui esiste una route fattibile negli Adj-RIBs-In, lo speaker BGP locale identifica la route che ha:

a) il più alto grado di preferenza di qualsiasi route verso lo stesso insieme di destinazioni, o

b) è l'unica route verso quella destinazione, o

c) è selezionata come risultato delle regole di spareggio di fase 2 specificate nella Sezione 9.1.2.2.

Lo speaker locale deve (SHALL) quindi installare quella route nel Loc-RIB, sostituendo qualsiasi route verso la stessa destinazione che è attualmente conservata nel Loc-RIB. Quando la nuova route BGP viene installata nella tabella di routing, bisogna prestare attenzione affinché le route esistenti verso la stessa destinazione che sono ora considerate invalide vengano rimosse dalla tabella di routing. Se la nuova route BGP sostituisce una route non-BGP esistente nella tabella di routing dipende dalla politica configurata sullo speaker BGP.

Lo speaker locale deve (MUST) determinare l'indirizzo del prossimo hop immediato dall'attributo NEXT_HOP della route selezionata (vedere Sezione 5.1.3). Se cambia il prossimo hop immediato o il costo IGP verso il NEXT_HOP (dove il NEXT_HOP è risolto attraverso una route IGP), la selezione della route di fase 2 deve (MUST) essere eseguita di nuovo.

Si noti che anche se le route BGP non devono essere installate nella tabella di routing con il/i prossimo/i hop immediato/i, le implementazioni devono (MUST) fare attenzione che, prima che qualsiasi pacchetto venga inoltrato lungo una route BGP, il suo indirizzo NEXT_HOP associato venga risolto nell'indirizzo del prossimo hop immediato (direttamente connesso), e che questo indirizzo (o più indirizzi) venga finalmente utilizzato per l'effettivo inoltro dei pacchetti.

Le route non risolvibili devono (SHALL) essere rimosse dal Loc-RIB e dalla tabella di routing. Tuttavia, le corrispondenti route non risolvibili dovrebbero (SHOULD) essere mantenute negli Adj-RIBs-In (nel caso diventino risolvibili).

9.1.2.1. Route Resolvability Condition (Condizione di risolvibilità della route)

Come indicato nella Sezione 9.1.2, gli speaker BGP dovrebbero (SHOULD) escludere le route non risolvibili dalla decisione di fase 2. Questo garantisce che solo le route valide vengano installate in Loc-RIB e nella tabella di routing.

La condizione di risolvibilità della route è definita come segue:

  1. Una route Rte1, che fa riferimento solo all'indirizzo di rete intermedio, è considerata risolvibile se la tabella di routing contiene almeno una route risolvibile Rte2 che corrisponde all'indirizzo di rete intermedio di Rte1 e non è risolta ricorsivamente (direttamente o indirettamente) attraverso Rte1. Se sono disponibili più route corrispondenti, dovrebbe (SHOULD) essere considerata solo la route corrispondente più lunga.

  2. Le route che fanno riferimento a interfacce (con o senza indirizzi intermedi) sono considerate risolvibili se lo stato dell'interfaccia referenziata è attivo e se l'elaborazione IP è abilitata su questa interfaccia.

Le route BGP non fanno riferimento a interfacce, ma possono essere risolte attraverso le route nella tabella di routing che possono essere di entrambi i tipi (quelle che specificano interfacce o quelle che non lo fanno). Le route IGP e le route verso reti direttamente connesse sono previste per specificare l'interfaccia in uscita. Le route statiche possono specificare l'interfaccia in uscita, l'indirizzo intermedio, o entrambi.

Si noti che una route BGP è considerata non risolvibile in una situazione in cui la tabella di routing dello speaker BGP non contiene route che corrispondono al NEXT_HOP della route BGP. Le route mutuamente ricorsive (route che risolvono l'una l'altra o se stesse) falliscono anche il controllo di risolvibilità.

È anche importante che le implementazioni non considerino route fattibili che diventerebbero non risolvibili se fossero installate nella tabella di routing, anche se i loro NEXT_HOP sono risolvibili utilizzando il contenuto attuale della tabella di routing (un esempio di tali route sarebbero le route mutuamente ricorsive). Questo controllo garantisce che uno speaker BGP non installi route nella tabella di routing che verranno rimosse e non utilizzate dallo speaker. Pertanto, oltre alla stabilità della tabella di routing locale, questo controllo migliora anche il comportamento del protocollo nella rete.

Ogni volta che uno speaker BGP identifica una route che fallisce il controllo di risolvibilità a causa di ricorsione mutua, un messaggio di errore dovrebbe (SHOULD) essere registrato.

9.1.2.2. Breaking Ties (Phase 2) (Spareggio (Fase 2))

Nei suoi Adj-RIBs-In, uno speaker BGP può avere diverse route verso la stessa destinazione che hanno lo stesso grado di preferenza. Lo speaker locale può selezionare solo una di queste route per l'inclusione nel Loc-RIB associato. Lo speaker locale considera tutte le route con gli stessi gradi di preferenza, sia quelle ricevute da peer interni che quelle ricevute da peer esterni.

La seguente procedura di spareggio presume che, per ogni route candidata, tutti gli speaker BGP all'interno di un sistema autonomo possano accertare il costo di un percorso (distanza interna) all'indirizzo raffigurato dall'attributo NEXT_HOP della route, e seguano lo stesso algoritmo di selezione della route.

L'algoritmo di spareggio inizia considerando tutte le route ugualmente preferibili verso la stessa destinazione, e poi seleziona le route da rimuovere dalla considerazione. L'algoritmo termina non appena rimane in considerazione una sola route. I criteri devono (MUST) essere applicati nell'ordine specificato.

Diversi dei criteri sono descritti utilizzando pseudo-codice. Si noti che il pseudo-codice mostrato è stato scelto per chiarezza, non per efficienza. Non è inteso per specificare alcuna implementazione particolare. Le implementazioni BGP possono (MAY) utilizzare qualsiasi algoritmo che produca gli stessi risultati di quelli descritti qui.

a) Rimuovere dalla considerazione tutte le route che non sono in pareggio per avere il numero più piccolo di numeri AS presenti nei loro attributi AS_PATH. Si noti che quando si conta questo numero, un AS_SET conta come 1, indipendentemente da quanti AS sono nel set.

b) Rimuovere dalla considerazione tutte le route che non sono in pareggio per avere il numero Origin più basso nel loro attributo Origin.

c) Rimuovere dalla considerazione le route con attributi MULTI_EXIT_DISC meno preferiti. MULTI_EXIT_DISC è comparabile solo tra route apprese dallo stesso AS vicino (l'AS vicino è determinato dall'attributo AS_PATH). Le route che non hanno l'attributo MULTI_EXIT_DISC sono considerate avere il valore MULTI_EXIT_DISC più basso possibile.

Questo è anche descritto nella seguente procedura:

for m = all routes still under consideration for n = all routes still under consideration if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) remove route m from consideration

Nel pseudo-codice sopra, MED(n) è una funzione che restituisce il valore dell'attributo MULTI_EXIT_DISC della route n. Se la route n non ha attributo MULTI_EXIT_DISC, la funzione restituisce il valore MULTI_EXIT_DISC più basso possibile (cioè, 0).

Similmente, neighborAS(n) è una funzione che restituisce l'AS vicino da cui la route è stata ricevuta. Se la route è appresa via IBGP, e l'altro speaker IBGP non ha originato la route, è l'AS vicino da cui l'altro speaker IBGP ha appreso la route. Se la route è appresa via IBGP, e l'altro speaker IBGP ha (a) originato la route, o (b) creato la route per aggregazione e l'attributo AS_PATH della route aggregata è vuoto o inizia con un AS_SET, è l'AS locale.

Se un attributo MULTI_EXIT_DISC viene rimosso prima di riannunciare una route in IBGP, allora il confronto basato sull'attributo MULTI_EXIT_DISC EBGP ricevuto può (MAY) ancora essere eseguito. Se un'implementazione sceglie di rimuovere MULTI_EXIT_DISC, allora il confronto opzionale su MULTI_EXIT_DISC, se eseguito, deve (MUST) essere eseguito solo tra route apprese via EBGP. La migliore route appresa via EBGP può poi essere confrontata con le route apprese via IBGP dopo la rimozione dell'attributo MULTI_EXIT_DISC. Se MULTI_EXIT_DISC viene rimosso da un sottoinsieme di route apprese via EBGP, e la "migliore" route appresa via EBGP selezionata non avrà MULTI_EXIT_DISC rimosso, allora il MULTI_EXIT_DISC deve essere utilizzato nel confronto con le route apprese via IBGP. Per le route apprese via IBGP, il MULTI_EXIT_DISC deve (MUST) essere utilizzato nei confronti di route che raggiungono questo passo nel processo di decisione. Includere il MULTI_EXIT_DISC di una route appresa via EBGP nel confronto con una route appresa via IBGP, poi rimuovere l'attributo MULTI_EXIT_DISC, e annunciare la route è stato dimostrato causare cicli di route.

d) Se almeno una delle route candidate è stata ricevuta via EBGP, rimuovere dalla considerazione tutte le route che sono state ricevute via IBGP.

e) Rimuovere dalla considerazione tutte le route con costo interno meno preferito. Il costo interno di una route è determinato calcolando la metrica verso il NEXT_HOP per la route utilizzando la tabella di routing. Se il NEXT_HOP hop per una route è raggiungibile, ma non può essere determinato alcun costo, allora questo passo dovrebbe essere saltato (equivalentemente, considerare tutte le route come aventi costi uguali).

Questo è anche descritto nella seguente procedura.

for m = all routes still under consideration for n = all routes in still under consideration if (cost(n) is lower than cost(m)) remove m from consideration

Nel pseudo-codice sopra, cost(n) è una funzione che restituisce il costo del percorso (distanza interna) all'indirizzo dato nell'attributo NEXT_HOP della route.

f) Rimuovere dalla considerazione tutte le route diverse dalla route che è stata annunciata dallo speaker BGP con il valore di identificatore BGP più basso.

g) Preferire la route ricevuta dall'indirizzo peer più basso.

9.1.3. Phase 3: Route Dissemination (Fase 3: Disseminazione della route)

La funzione di decisione di fase 3 viene invocata al completamento della fase 2, o quando si verifica uno dei seguenti eventi:

a) quando le route nel Loc-RIB verso destinazioni locali sono cambiate

b) quando le route generate localmente apprese con mezzi esterni a BGP sono cambiate

c) quando è stata stabilita una nuova connessione speaker BGP

La funzione di fase 3 è un processo separato che si completa quando non ha più lavoro da fare. La funzione di decisione di routing di fase 3 è bloccata dall'esecuzione mentre la funzione di decisione di fase 2 è in corso.

Tutte le route nel Loc-RIB vengono elaborate negli Adj-RIBs-Out secondo la politica configurata. Questa politica può (MAY) escludere una route nel Loc-RIB dall'essere installata in un particolare Adj-RIB-Out. Una route non deve (SHALL NOT) essere installata nell'Adj-Rib-Out a meno che la destinazione e NEXT_HOP descritti da questa route possano essere inoltrati appropriatamente dalla tabella di routing. Se una route in Loc-RIB è esclusa da un particolare Adj-RIB-Out, la route precedentemente annunciata in quell'Adj-RIB-Out deve (MUST) essere ritirata dal servizio per mezzo di un messaggio UPDATE (vedere 9.2).

Le tecniche di aggregazione di route e riduzione delle informazioni (vedere Sezione 9.2.2.1) possono opzionalmente essere applicate.

Qualsiasi politica locale che risulti nell'aggiunta di route a un Adj-RIB-Out senza essere anche aggiunte alla tabella di inoltro dello speaker BGP locale è al di fuori dell'ambito di questo documento.

Quando l'aggiornamento degli Adj-RIBs-Out e della tabella di routing è completo, lo speaker BGP locale esegue il processo Update-Send di 9.2.

9.1.4. Overlapping Routes (Route sovrapposte)

Uno speaker BGP può trasmettere route con Network Layer Reachability Information (NLRI) sovrapposte a un altro speaker BGP. La sovrapposizione NLRI si verifica quando un insieme di destinazioni è identificato in più route non corrispondenti. Poiché BGP codifica NLRI utilizzando prefissi IP, la sovrapposizione mostrerà sempre relazioni di sottoinsieme. Una route che descrive un insieme più piccolo di destinazioni (un prefisso più lungo) si dice più specifica di una route che descrive un insieme più grande di destinazioni (un prefisso più corto); similmente, una route che descrive un insieme più grande di destinazioni si dice meno specifica di una route che descrive un insieme più piccolo di destinazioni.

La relazione di precedenza decompone effettivamente le route meno specifiche in due parti:

  • un insieme di destinazioni descritto solo dalla route meno specifica, e

  • un insieme di destinazioni descritto dalla sovrapposizione della route meno specifica e della route più specifica

L'insieme di destinazioni descritto dalla sovrapposizione rappresenta una porzione della route meno specifica che è fattibile, ma non è attualmente in uso. Se una route più specifica viene successivamente ritirata, l'insieme di destinazioni descritto dalla sovrapposizione rimarrà raggiungibile utilizzando la route meno specifica.

Se uno speaker BGP riceve route sovrapposte, il processo di decisione deve (MUST) considerare entrambe le route in base alla politica di accettazione configurata. Se vengono accettate sia una route meno specifica che una più specifica, allora il processo di decisione deve (MUST) installare, in Loc-RIB, o entrambe le route meno e più specifiche o aggregare le due route e installare, in Loc-RIB, la route aggregata, a condizione che entrambe le route abbiano lo stesso valore dell'attributo NEXT_HOP.

Se uno speaker BGP sceglie di aggregare, allora dovrebbe (SHOULD) includere tutti gli AS utilizzati per formare l'aggregato in un AS_SET, o aggiungere l'attributo ATOMIC_AGGREGATE alla route. Questo attributo è ora principalmente informativo. Con l'eliminazione dei protocolli di routing IP che non supportano il routing classless, e l'eliminazione delle implementazioni di router e host che non supportano il routing classless, non c'è più bisogno di disaggregare. Le route non dovrebbero (SHOULD NOT) essere disaggregate. In particolare, una route che porta l'attributo ATOMIC_AGGREGATE non deve (MUST NOT) essere disaggregata. Cioè, il NLRI di questa route non può essere più specifico. L'inoltro lungo una tale route non garantisce che i pacchetti IP attraverseranno effettivamente solo gli AS elencati nell'attributo AS_PATH della route.

9.2. Update-Send Process (Processo Update-Send)

Il processo Update-Send è responsabile dell'annuncio dei messaggi UPDATE a tutti i peer. Ad esempio, distribuisce le route scelte dal processo di decisione ad altri speaker BGP, che possono essere situati nello stesso sistema autonomo o in un sistema autonomo vicino.

Quando uno speaker BGP riceve un messaggio UPDATE da un peer interno, lo speaker BGP ricevente non deve (SHALL NOT) ridistribuire le informazioni di routing contenute in quel messaggio UPDATE ad altri peer interni (a meno che lo speaker non agisca come un riflettore di route BGP [RFC2796]).

Come parte della fase 3 del processo di selezione della route, lo speaker BGP ha aggiornato i suoi Adj-RIBs-Out. Tutte le route appena installate e tutte le route appena non fattibili per le quali non esiste route di sostituzione devono (SHALL) essere annunciate ai suoi peer per mezzo di un messaggio UPDATE.

Uno speaker BGP non dovrebbe (SHOULD NOT) annunciare una data route BGP fattibile dal suo Adj-RIB-Out se produrrebbe un messaggio UPDATE contenente la stessa route BGP come precedentemente annunciata.

Tutte le route nel Loc-RIB contrassegnate come non fattibili devono (SHALL) essere rimosse. I cambiamenti alle destinazioni raggiungibili all'interno del proprio sistema autonomo devono (SHALL) anche essere annunciati in un messaggio UPDATE.

Se, a causa dei limiti sulla dimensione massima di un messaggio UPDATE (vedere Sezione 4), una singola route non si adatta al messaggio, lo speaker BGP non deve (MUST NOT) annunciare la route ai suoi peer e può (MAY) scegliere di registrare un errore localmente.

9.2.1. Controlling Routing Traffic Overhead (Controllo del sovraccarico del traffico di routing)

Il protocollo BGP vincola la quantità di traffico di routing (cioè, messaggi UPDATE), al fine di limitare sia la larghezza di banda del collegamento necessaria per annunciare messaggi UPDATE sia la potenza di elaborazione necessaria dal processo di decisione per digerire le informazioni contenute nei messaggi UPDATE.

9.2.1.1. Frequency of Route Advertisement (Frequenza dell'annuncio di route)

Il parametro MinRouteAdvertisementIntervalTimer determina la quantità minima di tempo che deve trascorrere tra un annuncio e/o ritiro di route verso una destinazione particolare da parte di uno speaker BGP a un peer. Questa procedura di limitazione della frequenza si applica per destinazione, sebbene il valore di MinRouteAdvertisementIntervalTimer sia impostato per peer BGP.

Due messaggi UPDATE inviati da uno speaker BGP a un peer che annunciano route fattibili e/o ritiro di route non fattibili verso un insieme comune di destinazioni devono (MUST) essere separati da almeno MinRouteAdvertisementIntervalTimer. Questo può essere raggiunto solo mantenendo un timer separato per ogni insieme comune di destinazioni. Questo sarebbe un sovraccarico ingiustificato. Qualsiasi tecnica che garantisca che l'intervallo tra due messaggi UPDATE inviati da uno speaker BGP a un peer che annunciano route fattibili e/o ritiro di route non fattibili verso un insieme comune di destinazioni sarà di almeno MinRouteAdvertisementIntervalTimer, e garantirà anche un limite superiore costante sull'intervallo è accettabile.

Poiché è necessaria una convergenza rapida all'interno di un sistema autonomo, o (a) il MinRouteAdvertisementIntervalTimer utilizzato per i peer interni dovrebbe (SHOULD) essere più breve del MinRouteAdvertisementIntervalTimer utilizzato per i peer esterni, o (b) la procedura descritta in questa sezione non dovrebbe (SHOULD NOT) applicarsi alle route inviate ai peer interni.

Questa procedura non limita il tasso di selezione della route, ma solo il tasso di annuncio della route. Se nuove route vengono selezionate più volte mentre si attende la scadenza di MinRouteAdvertisementIntervalTimer, l'ultima route selezionata deve (SHALL) essere annunciata alla fine di MinRouteAdvertisementIntervalTimer.

9.2.1.2. Frequency of Route Origination (Frequenza di originazione della route)

Il parametro MinASOriginationIntervalTimer determina la quantità minima di tempo che deve trascorrere tra annunci successivi di messaggi UPDATE che riportano cambiamenti all'interno dei propri sistemi autonomi dello speaker BGP annunciante.

9.2.2. Efficient Organization of Routing Information (Organizzazione efficiente delle informazioni di routing)

Dopo aver selezionato le informazioni di routing che annuncerà, uno speaker BGP può avvalersi di diversi metodi per organizzare queste informazioni in modo efficiente.

9.2.2.1. Information Reduction (Riduzione delle informazioni)

La riduzione delle informazioni può implicare una riduzione della granularità del controllo delle politiche - dopo che le informazioni sono state ridotte, le stesse politiche si applicheranno a tutte le destinazioni e percorsi nella classe di equivalenza.

Il processo di decisione può opzionalmente ridurre la quantità di informazioni che metterà negli Adj-RIBs-Out con uno dei seguenti metodi:

a) Network Layer Reachability Information (NLRI):

Gli indirizzi IP di destinazione possono essere rappresentati come prefissi di indirizzi IP. Nei casi in cui esiste una corrispondenza tra la struttura degli indirizzi e i sistemi sotto il controllo di un amministratore di sistema autonomo, sarà possibile ridurre la dimensione del NLRI trasportato nei messaggi UPDATE.

b) AS_PATHs:

Le informazioni sul percorso AS possono essere rappresentate come AS_SEQUENCEs ordinati o AS_SETs non ordinati. Gli AS_SETs sono utilizzati nell'algoritmo di aggregazione di route descritto nella Sezione 9.2.2.2. Riducono la dimensione delle informazioni AS_PATH elencando ogni numero AS solo una volta, indipendentemente da quante volte possa essere apparso in più AS_PATHs che sono stati aggregati.

Un AS_SET implica che le destinazioni elencate nel NLRI possono essere raggiunte attraverso percorsi che attraversano almeno alcuni dei sistemi autonomi costituenti. Gli AS_SETs forniscono informazioni sufficienti per evitare cicli di informazioni di routing; tuttavia, il loro uso può potare percorsi potenzialmente fattibili perché tali percorsi non sono più elencati individualmente nella forma di AS_SEQUENCEs. In pratica, questo probabilmente non sarà un problema perché una volta che un pacchetto IP arriva al bordo di un gruppo di sistemi autonomi, lo speaker BGP è probabile che abbia informazioni sul percorso più dettagliate e possa distinguere i percorsi individuali dalle destinazioni.

9.2.2.2. Aggregating Routing Information (Aggregazione delle informazioni di routing)

L'aggregazione è il processo di combinazione delle caratteristiche di diverse route in modo tale che una singola route possa essere annunciata. L'aggregazione può verificarsi come parte del processo di decisione per ridurre la quantità di informazioni di routing che sarà posta negli Adj-RIBs-Out.

L'aggregazione riduce la quantità di informazioni che uno speaker BGP deve memorizzare e scambiare con altri speaker BGP. Le route possono essere aggregate applicando la seguente procedura, separatamente, agli attributi di percorso dello stesso tipo e alle Network Layer Reachability Information.

Le route che hanno attributi MULTI_EXIT_DISC diversi non devono (SHALL NOT) essere aggregate.

Se la route aggregata ha un AS_SET come primo elemento nel suo attributo AS_PATH, allora il router che origina la route non dovrebbe (SHOULD NOT) annunciare l'attributo MULTI_EXIT_DISC con questa route.

Gli attributi di percorso che hanno codici di tipo diversi non possono essere aggregati insieme. Gli attributi di percorso dello stesso codice di tipo possono essere aggregati, secondo le seguenti regole:

NEXT_HOP: Quando si aggregano route che hanno attributi NEXT_HOP diversi, l'attributo NEXT_HOP della route aggregata deve (SHALL) identificare un'interfaccia sullo speaker BGP che esegue l'aggregazione.

Attributo ORIGIN: Se almeno una route tra le route che sono aggregate ha ORIGIN con il valore INCOMPLETE, allora la route aggregata deve (MUST) avere l'attributo ORIGIN con il valore INCOMPLETE. Altrimenti, se almeno una route tra le route che sono aggregate ha ORIGIN con il valore EGP, allora la route aggregata deve (MUST) avere l'attributo ORIGIN con il valore EGP. In tutti gli altri casi, il valore dell'attributo ORIGIN della route aggregata è IGP.

Attributo AS_PATH: Se le route da aggregare hanno attributi AS_PATH identici, allora la route aggregata ha lo stesso attributo AS_PATH di ogni route individuale.

Per scopo di aggregazione degli attributi AS_PATH, modelliamo ogni AS all'interno dell'attributo AS_PATH come una tupla <type, value>, dove "type" identifica un tipo del segmento di percorso a cui appartiene l'AS (ad esempio, AS_SEQUENCE, AS_SET), e "value" identifica il numero AS. Se le route da aggregare hanno attributi AS_PATH diversi, allora l'attributo AS_PATH aggregato deve (SHALL) soddisfare tutte le seguenti condizioni:

  • tutte le tuple di tipo AS_SEQUENCE nell'AS_PATH aggregato devono (SHALL) apparire in tutti gli AS_PATHs nell'insieme iniziale di route da aggregare.

  • tutte le tuple di tipo AS_SET nell'AS_PATH aggregato devono (SHALL) apparire in almeno uno degli AS_PATHs nell'insieme iniziale (possono apparire come tipi AS_SET o AS_SEQUENCE).

  • per qualsiasi tupla X di tipo AS_SEQUENCE nell'AS_PATH aggregato, che precede la tupla Y nell'AS_PATH aggregato, X precede Y in ogni AS_PATH nell'insieme iniziale, che contiene Y, indipendentemente dal tipo di Y.

  • Nessuna tupla di tipo AS_SET con lo stesso valore deve (SHALL) apparire più di una volta nell'AS_PATH aggregato.

  • Più tuple di tipo AS_SEQUENCE con lo stesso valore possono apparire nell'AS_PATH aggregato solo quando adiacenti a un'altra tupla dello stesso tipo e valore.

Un'implementazione può scegliere qualsiasi algoritmo che si conformi a queste regole. Come minimo, un'implementazione conforme deve (SHALL) essere in grado di eseguire il seguente algoritmo che soddisfa tutte le condizioni di cui sopra:

  • determinare la sequenza iniziale più lunga di tuple (come definito sopra) comune a tutti gli attributi AS_PATH delle route da aggregare. Rendere questa sequenza la sequenza iniziale dell'attributo AS_PATH aggregato.

  • impostare il tipo del resto delle tuple dagli attributi AS_PATH delle route da aggregare su AS_SET, e aggiungerle all'attributo AS_PATH aggregato.

  • se l'AS_PATH aggregato ha più di una tupla con lo stesso valore (indipendentemente dal tipo della tupla), eliminare tutte tranne una tale tupla eliminando le tuple di tipo AS_SET dall'attributo AS_PATH aggregato.

  • per ogni coppia di tuple adiacenti nell'AS_PATH aggregato, se entrambe le tuple hanno lo stesso tipo, unirle insieme, purché ciò non causi la generazione di un segmento con lunghezza superiore a 255.

L'Appendice F, Sezione F.6 presenta un altro algoritmo che soddisfa le condizioni e consente configurazioni di politica più complesse.

ATOMIC_AGGREGATE: Se almeno una delle route da aggregare ha l'attributo di percorso ATOMIC_AGGREGATE, allora la route aggregata deve (SHALL) avere anche questo attributo.

AGGREGATOR: Tutti gli attributi AGGREGATOR dalle route da aggregare non devono (MUST NOT) essere inclusi nella route aggregata. Lo speaker BGP che esegue l'aggregazione di route può (MAY) allegare un nuovo attributo AGGREGATOR (vedere Sezione 5.1.7).

9.3. Route Selection Criteria (Criteri di selezione della route)

In generale, regole aggiuntive per confrontare route tra diverse alternative sono al di fuori dell'ambito di questo documento. Ci sono due eccezioni:

  • Se l'AS locale appare nel percorso AS della nuova route considerata, allora quella nuova route non può essere vista come migliore di qualsiasi altra route (a condizione che lo speaker sia configurato per accettare tali route). Se tale route fosse mai utilizzata, potrebbe risultare un ciclo di routing.

  • Al fine di ottenere un'operazione distribuita di successo, solo route con una probabilità di stabilità possono essere scelte. Pertanto, un AS dovrebbe (SHOULD) evitare di utilizzare route instabili, e non dovrebbe (SHOULD NOT) effettuare cambiamenti rapidi e spontanei alla sua scelta di route. Quantificare i termini "instabile" e "rapido" (dalla frase precedente) richiederà esperienza, ma il principio è chiaro. Le route che sono instabili possono essere "penalizzate" (ad esempio, utilizzando le procedure descritte in [RFC2439]).

9.4. Originating BGP routes (Originazione di route BGP)

Uno speaker BGP può originare route BGP iniettando informazioni di routing acquisite con altri mezzi (ad esempio, via un IGP) in BGP. Uno speaker BGP che origina route BGP assegna il grado di preferenza (ad esempio, secondo la configurazione locale) a queste route passandole attraverso il processo di decisione (vedere Sezione 9.1). Queste route possono (MAY) anche essere distribuite ad altri speaker BGP all'interno dell'AS locale come parte del processo di aggiornamento (vedere Sezione 9.2). La decisione se distribuire route acquisite non-BGP all'interno di un AS via BGP dipende dall'ambiente all'interno dell'AS (ad esempio, tipo di IGP) e dovrebbe (SHOULD) essere controllata tramite configurazione.

Ultimo aggiornamento il