Passa al contenuto principale

5. Modello concettuale di un host (Conceptual Model of a Host)

Sebbene non sia richiesto che le implementazioni si conformino a un modello concettuale specifico di un host, questa sezione descrive un modello concettuale che può essere utilizzato dagli host per aiutare a comprendere Neighbor Discovery. Un host mantiene concettualmente un numero di strutture dati:

Neighbor Cache - Un insieme di voci sui singoli vicini a cui è stato inviato traffico di recente. Le voci sono indicizzate sull'indirizzo IP unicast on-link del vicino e contengono informazioni come il suo indirizzo di livello di collegamento, un flag che indica se il vicino è un router o un host (chiamato IsRouter in questo documento), un puntatore a eventuali pacchetti in coda in attesa del completamento della risoluzione degli indirizzi, ecc. Una voce Neighbor Cache contiene anche informazioni utilizzate dall'algoritmo Neighbor Unreachability Detection, incluso lo stato di raggiungibilità, il numero di sonde senza risposta e il momento in cui è previsto che si verifichi il prossimo evento di Neighbor Unreachability Detection.

Destination Cache - Un insieme di voci sulle destinazioni a cui è stato inviato traffico di recente. Il Destination Cache include sia destinazioni on-link che off-link e fornisce un livello di indirezione nel Neighbor Cache; il Destination Cache mappa un indirizzo IP di destinazione all'indirizzo IP del vicino di next-hop. A differenza del Neighbor Cache, il Destination Cache contiene voci sia per destinazioni on-link che off-link. Mantenere un Destination Cache separato dal Neighbor Cache serve a molteplici scopi. In primo luogo, il Destination Cache può contenere voci per destinazioni che non sono adiacenti sul collegamento. In secondo luogo, il Destination Cache può contenere voci soggette a Path MTU Discovery, messaggi Redirect, ecc.

Prefix List - Un elenco dei prefissi che definiscono un insieme di indirizzi che sono on-link. Le voci Prefix List vengono create dalle informazioni ricevute nei Router Advertisements. Ogni voce ha un valore di timer di invalidazione associato (estratto dall'annuncio) utilizzato per far scadere i prefissi. Una voce Prefix List contiene anche un flag che indica se il prefisso può essere utilizzato per la determinazione on-link e/o l'autoconfigurazione degli indirizzi, come specificato in [ADDRCONF].

Default Router List - Un elenco di router a cui possono essere inviati pacchetti. Le voci Default Router List puntano a voci nel Neighbor Cache; l'algoritmo per la selezione di un router predefinito favorisce i router noti per essere raggiungibili rispetto a quelli la cui raggiungibilità è sospetta. Ogni voce ha anche un valore di timer di invalidazione associato (estratto dai Router Advertisements) utilizzato per eliminare le voci che non vengono più annunciate.

Le strutture dati concettuali descritte sopra sono funzionalmente separate; le implementazioni sono libere di combinarne alcune o tutte nel modo più conveniente. I requisiti di questo protocollo possono essere soddisfatti in modo diretto attraverso l'uso delle strutture dati sopra nel pseudocodice nelle sezioni seguenti. Tuttavia, un'implementazione è libera di utilizzare strutture dati alternative purché il comportamento esterno dell'implementazione rimanga invariato.

5.1. Strutture dati concettuali (Conceptual Data Structures)​

Sebbene non sia necessario che gli host mantengano tutte le strutture dati descritte di seguito, questa sezione descrive un insieme di strutture dati sufficienti per implementare Neighbor Discovery.

5.2. Algoritmo di invio concettuale (Conceptual Sending Algorithm)​

Quando un nodo ha un pacchetto da inviare, esamina prima il Destination Cache. Se non esiste alcuna voce per la destinazione, il nodo ne crea una e inizializza il suo indirizzo di next-hop invocando l'algoritmo di determinazione del next-hop (Sezione 5.2). Una volta creata una voce Destination Cache, il nodo esamina quindi lo stato della voce Neighbor Cache per il next-hop.

Una voce Neighbor Cache può essere in uno dei cinque stati:

INCOMPLETE (incompleto) - La risoluzione degli indirizzi è attualmente in corso sulla voce. Specificamente, un Neighbor Solicitation è stato inviato all'indirizzo multicast solicited-node del target, ma il Neighbor Advertisement corrispondente non è ancora stato ricevuto.

REACHABLE (raggiungibile) - La voce è nota per essere stata raggiungibile di recente (entro decine di secondi fa). È stata ricevuta una conferma positiva negli ultimi ReachableTime millisecondi che il percorso in avanti verso il vicino funzionava correttamente. Mentre è REACHABLE, non si verifica alcuna azione speciale quando vengono inviati pacchetti.

STALE (obsoleto) - La voce è nota per essere stata raggiungibile di recente, ma non è stata ricevuta alcuna conferma di recente. Mentre è STALE, non si verifica alcuna azione fino a quando non viene inviato un pacchetto. Quando viene inviato un pacchetto, un nodo trasferisce la voce a DELAY o PROBE, a seconda dell'implementazione.

DELAY (ritardo) - La voce è nota per essere stata raggiungibile di recente, e un pacchetto è stato inviato negli ultimi DELAY_FIRST_PROBE_TIME secondi. Se non viene ricevuta alcuna conferma di raggiungibilità entro DELAY_FIRST_PROBE_TIME secondi dall'ingresso nello stato DELAY, inviare un Neighbor Solicitation e cambiare lo stato in PROBE. Ritardare la trasmissione della sonda offre l'opportunità ai protocolli di livello superiore di fornire conferma di raggiungibilità.

PROBE (sonda) - Una conferma di raggiungibilità viene attivamente cercata ritrasmettendo Neighbor Solicitations ogni RetransTimer millisecondi fino a quando non viene ricevuta una conferma di raggiungibilità.

Il Neighbor Cache contiene anche informazioni necessarie per eseguire l'algoritmo Neighbor Unreachability Detection, inclusi vari timer, contatori, ecc.

Quando si invia un pacchetto a un vicino, un nodo utilizza le informazioni sullo stato contenute nella voce Neighbor Cache per determinare cosa, se c'è qualcosa, deve essere fatto prima di inviare traffico a quel vicino. Il seguente pseudocodice illustra l'algoritmo di invio:

if (esiste voce Destination Cache) {
    next hop = next_hop del Destination Cache;
} else {
    next hop = Determinazione del next-hop (Sezione 5.2);
    creare voce Destination Cache;
}

if (esiste voce Neighbor Cache per next hop) {
    if (stato voce Neighbor Cache == INCOMPLETE) {
        mettere in coda il pacchetto sulla voce Neighbor Cache;
        /* La risoluzione degli indirizzi è già in corso */
    }
    if (stato voce Neighbor Cache == REACHABLE) {
        inviare pacchetto;
    }
    if (stato voce Neighbor Cache == STALE) {
        inviare pacchetto;
        impostare stato voce Neighbor Cache a DELAY;
        impostare timer voce Neighbor Cache a DELAY_FIRST_PROBE_TIME;
    }
    if (stato voce Neighbor Cache == DELAY) {
        inviare pacchetto;
        /* il timer è già impostato */
    }
    if (stato voce Neighbor Cache == PROBE) {
        inviare pacchetto;
        /* Neighbor Unreachability Detection è in corso */
    }
} else {
    creare voce Neighbor Cache;
    impostare stato voce Neighbor Cache a INCOMPLETE;
    if (indirizzo di livello di collegamento è facilmente disponibile) {
        impostare indirizzo di livello di collegamento;
        impostare stato voce Neighbor Cache a STALE;
        inviare pacchetto;
    } else {
        mettere in coda il pacchetto sulla voce Neighbor Cache;
        avviare risoluzione degli indirizzi;
    }
}

5.3. Requisiti di garbage collection e timeout (Garbage Collection and Timeout Requirements)​

Il Neighbor Cache, il Destination Cache e la Prefix List devono essere sottoposti a garbage collection e scadere. Tuttavia, i periodi di timeout specifici non sono deliberatamente specificati. I periodi di timeout devono essere scelti per fornire un equilibrio ragionevole tra il mantenimento di informazioni obsolete e il costo dell'aggiornamento di tali informazioni. In generale, i periodi di timeout dovrebbero essere abbastanza generosi da impedire il thrashing del contenuto della cache ma abbastanza brevi da impedire l'obsolescenza a lungo termine.

Un'implementazione concettuale potrebbe utilizzare le seguenti regole:

  • Le voci Neighbor Cache dovrebbero (SHOULD) rimanere per almeno un tempo specificato da ReachableTime dopo la transizione allo stato STALE. Tuttavia, possono rimanere più a lungo se l'implementazione utilizza una qualche forma di algoritmo di garbage collection per recuperare le voci. Le voci nello stato INCOMPLETE non hanno bisogno di rimanere per un periodo così prolungato.

  • Le voci Destination Cache dovrebbero (SHOULD) rimanere nella cache il più a lungo possibile (cioè, indefinitamente). Tuttavia, il periodo di tempo specifico dipende dall'implementazione. Le implementazioni DOVREBBERO (SHOULD) invalidare una voce Destination Cache se viene ricevuto un messaggio Redirect che specifica un percorso migliore verso la destinazione.

  • Le voci nella Prefix List scadono in conformità con la durata specificata nei Router Advertisements. La durata di una voce viene aggiornata quando arriva un nuovo Router Advertisement.

  • Le voci nella Default Router List scadono in conformità con la Router Lifetime specificata nei Router Advertisements. I Router Advertisements ricevuti con una Router Lifetime di zero indicano che il router dovrebbe essere rimosso dalla Default Router List immediatamente.

Ultimo aggiornamento il