6.2. Routing Locator Selection (Selezione del Routing Locator)
6.2. Routing Locator Selection (Selezione del Routing Locator)
I lati client e server potrebbero entrambi voler controllare la selezione RLOC utilizzata tra di loro per le loro sessioni. Questo viene ottenuto manipolando i campi Priority e Weight nei messaggi EID-to-RLOC Map-Reply. Le informazioni RLOC possono anche essere raccolte (gleaned) da pacchetti tunnelizzati ricevuti o da messaggi EID-to-RLOC Map-Request ricevuti.
Diversi scenari di selezione RLOC e quale controllo è disponibile sono:
o Il lato server restituisce un singolo RLOC. Il client può utilizzare solo quel singolo RLOC. Il server ha il controllo completo sulla selezione.
o Il lato server restituisce un elenco di RLOC in cui un sottoinsieme ha la stessa Priority ottimale. Il client può utilizzare solo quel sottoinsieme e può bilanciare il carico tra di essi in base ai Weight assegnati dal server. Il server controlla sia il sottoinsieme che la condivisione del carico all'interno del sottoinsieme. Il client può utilizzare gli RLOC al di fuori del sottoinsieme se determina che il sottoinsieme non è raggiungibile (a meno che la Priority degli RLOC non sia 255). Il controllo è parzialmente condiviso: il server determina l'elenco RLOC di destinazione e la distribuzione del carico, il client può selezionare alternative quando gli RLOC nell'elenco non sono raggiungibili.
o Il lato server imposta il Weight per un sottoinsieme di RLOC a 0. Il client può decidere come distribuire il carico sul sottoinsieme. Il server determina l'elenco e il client determina la distribuzione del carico. Il client può ancora utilizzare altri RLOC quando l'elenco fornito dal server non è raggiungibile.
o Uno dei due lati (più comunemente l'ETR lato server) decide di non inviare un Map-Request. Ad esempio, quando un ETR lato server non invia Map-Request, raccoglie (gleans) gli RLOC dall'ITR client con l'ITR client che assume la responsabilità della raggiungibilità e preferenza RLOC bidirezionali. Un ETR lato server implementa il gleaning memorizzando nella cache l'EID di origine interno e l'RLOC di origine esterno dei pacchetti che riceve. L'ITR client può ruotare gli RLOC di origine esterni utilizzati, consentendogli di essere aggiunto all'elenco utilizzato dall'ETR lato server per il traffico di ritorno. Questo metodo non fornisce Priority o Weight, e l'ETR lato server deve presumere che ciascun RLOC dell'ITR client abbia la stessa Priority ottimale con Weight zero. Inoltre, i pacchetti dati non possono trasmettere codifiche EID-Prefix, quindi la Cache EID-to-RLOC sui Tunnel Router potrebbe diventare molto grande.
o Le voci Map-Cache "gleaned" (apprese dall'RLOC di origine dei pacchetti incapsulati ricevuti) vengono memorizzate e utilizzate solo per pochi secondi in attesa di verifica. La verifica viene eseguita inviando un Map-Request all'EID di origine (l'indirizzo IP di origine interno) del pacchetto incapsulato ricevuto. Una risposta a questa "verifying Map-Request" viene utilizzata per riempire completamente la voce Map-Cache per l'EID gleaned e memorizzarla e utilizzarla secondo il campo TTL del Map-Reply ricevuto. Una volta che una voce verificata viene inserita, i pacchetti successivi il cui EID di origine corrisponde all'EID-Prefix della voce verificata non verranno più sottoposti a data gleaning.
Un RLOC che appare in un EID-to-RLOC Map-Reply si presume raggiungibile quando il bit R in un record Locator è impostato a 1. Quando il bit R è 0, un ITR o PITR NON DEVE incapsulare verso l'RLOC. Le informazioni contenute in un Map-Reply o memorizzate nel sistema del database di mappatura NON forniscono alcuna raggiungibilità del percorso per gli RLOC. La raggiungibilità non fa parte del sistema di mappatura ed è determinata da uno o più degli algoritmi di raggiungibilità Routing Locator descritti nella sezione successiva.