8.2.2. Vicini e genitori attraverso le versioni DODAG

Le regole di cui sopra governano una singola versione DODAG. Le regole in questa sezione definiscono come RPL opera quando ci sono più versioni DODAG.

8.2.2.1. Versione DODAG

1. La tupla (RPLInstanceID, DODAGID, DODAGVersionNumber) definisce in modo univoco una versione DODAG. Ogni elemento dell'insieme dei genitori DODAG di un nodo, come trasmesso dall'ultimo messaggio DIO ascoltato da ogni genitore DODAG, DEVE appartenere alla stessa versione DODAG. Gli elementi dell'insieme dei vicini candidati di un nodo POSSONO appartenere a diverse versioni DODAG.

2. Un nodo è membro di una versione DODAG se ogni elemento del suo insieme dei genitori DODAG appartiene a quella versione DODAG, o se quel nodo è la radice del DODAG corrispondente.

3. Un nodo NON DEVE inviare DIO per versioni DODAG di cui non è membro.

4. Le radici DODAG POSSONO incrementare il DODAGVersionNumber che annunciano e quindi passare a una nuova versione DODAG. Quando una radice DODAG incrementa il suo DODAGVersionNumber, DEVE seguire le convenzioni di Serial Number Arithmetic come descritto nella Sezione 7. Gli eventi che attivano l'incremento del DODAGVersionNumber sono descritti più avanti in questa sezione e nella Sezione 18.

5. All'interno di un dato DODAG, un nodo che non è una radice NON DEVE annunciare un DODAGVersionNumber superiore al DODAGVersionNumber più alto che ha sentito. Superiore è definito come l'operatore maggiore-di nella Sezione 7.

6. Una volta che un nodo ha annunciato una versione DODAG inviando un DIO, NON DEVE essere membro di una versione DODAG precedente dello stesso DODAG (cioè con lo stesso RPLInstanceID, lo stesso DODAGID e un DODAGVersionNumber inferiore). Inferiore è definito come l'operatore minore-di nella Sezione 7.

Quando l'insieme dei genitori DODAG diventa vuoto su un nodo che non è una radice (cioè l'ultimo genitore è stato rimosso, facendo sì che il nodo non sia più associato a quel DODAG), le informazioni DODAG non dovrebbero essere soppresse fino alla scadenza di un timer locale specifico dell'implementazione. Durante l'intervallo prima della soppressione del "vecchio" stato DODAG, il nodo sarà in grado di osservare se il DODAGVersionNumber è stato incrementato se dovessero apparire nuovi genitori. Questo aiuterà a proteggere contro la possibilità di loop che possono verificarsi se quel nodo dovesse inavvertitamente ricongiungersi alla vecchia versione DODAG nel proprio precedente sotto-DODAG.

Man mano che il DODAGVersionNumber viene incrementato, una nuova versione DODAG si propaga verso l'esterno dalla radice DODAG. Un genitore che annuncia il nuovo DODAGVersionNumber non può appartenere al sotto-DODAG di un nodo che annuncia un DODAGVersionNumber più vecchio. Pertanto, un nodo può aggiungere in modo sicuro un genitore di qualsiasi Rank con un DODAGVersionNumber più recente senza formare un loop.

Ad esempio, supponiamo che un nodo abbia lasciato un DODAG con DODAGVersionNumber N. Supponiamo che un nodo avesse un sotto-DODAG e abbia tentato di avvelenare quel sotto-DODAG annunciando un Rank di INFINITE_RANK, ma tali annunci potrebbero essersi persi nel LLN. Quindi, se il nodo osservasse un vicino candidato che annuncia una posizione in quel DODAG originale al DODAGVersionNumber N, quel vicino candidato potrebbe essere stato nel precedente sotto-DODAG del nodo, e c'è un caso possibile in cui l'aggiunta di quel vicino candidato come genitore potrebbe causare un loop. In questo caso, se quel vicino candidato viene osservato annunciare un DODAGVersionNumber N+1, allora quel vicino candidato è certamente sicuro, poiché è certo di non essere nel sotto-DODAG di quel nodo originale, in quanto è stato in grado di incrementare il DODAGVersionNumber ascoltando dalla radice DODAG mentre quel nodo originale era distaccato. Per questo motivo, è utile per il nodo distaccato ricordare le informazioni DODAG originali, incluso il DODAGVersionNumber N.

Esattamente quando una radice DODAG incrementa il DODAGVersionNumber dipende dall'implementazione ed è fuori dall'ambito di questa specifica. Gli esempi includono l'incremento periodico del DODAGVersionNumber, su intervento amministrativo o su rilevamento a livello di applicazione di perdita di connettività o inefficienza del DODAG.

Dopo che un nodo passa a e annuncia una nuova versione DODAG, le regole di cui sopra lo rendono incapace di annunciare la versione DODAG precedente (DODAGVersionNumber precedente) una volta che si è impegnato ad annunciare la nuova versione DODAG.

8.2.2.2. Radici DODAG

1. Una radice DODAG senza possibilità di soddisfare l'obiettivo definito dall'applicazione NON DEVE impostare il bit Grounded.

2. Una radice DODAG DEVE annunciare un Rank di ROOT_RANK.

3. Un nodo il cui insieme di genitori DODAG è vuoto PUÒ diventare la radice DODAG di un DODAG fluttuante. PUÒ anche impostare la sua DAGPreference in modo che sia meno preferita.

In un dispiegamento che utilizza collegamenti non-LLN per federare un numero di radici LLN, è possibile eseguire RPL su quei collegamenti non-RPL e utilizzare un router come "radice backbone". La radice backbone è la radice virtuale del DODAG ed espone un Rank di BASE_RANK sul backbone. Tutte le radici LLN che sono figlie di quella radice backbone, inclusa la radice backbone stessa se funge anche da radice LLN, espongono un Rank di ROOT_RANK al LLN. Queste radici virtuali fanno parte dello stesso DODAG e annunciano lo stesso DODAGID. Coordinano i DODAGVersionNumbers e altri parametri DODAG con la radice virtuale sul backbone. Il metodo di coordinamento è fuori dall'ambito di questa specifica (da definire in future specifiche complementari).

8.2.2.3. Selezione DODAG

La Funzione Obiettivo e l'insieme delle metriche e vincoli di routing annunciati di un DAG determinano come un nodo seleziona il suo insieme di vicini, l'insieme dei genitori e i genitori preferiti. Questa selezione determina implicitamente anche il DODAG all'interno di un DAG. Tale selezione può includere la preferenza amministrativa (Prf) così come metriche o altre considerazioni.

Se un nodo ha l'opzione di unirsi a un DODAG più preferito pur soddisfacendo altri obiettivi di ottimizzazione, allora il nodo cercherà generalmente di unirsi al DODAG più preferito come determinato dall'OF. A parità di tutte le altre condizioni, spetta all'implementazione determinare quale DODAG è più preferito (poiché, come promemoria, un nodo deve unirsi solo a un DODAG per istanza RPL).

8.2.2.4. Rank e movimento all'interno di una versione DODAG

1. Un nodo NON DEVE annunciare un Rank inferiore o uguale a qualsiasi membro del suo insieme di genitori all'interno della versione DODAG.

2. Un nodo PUÒ annunciare un Rank inferiore al suo annuncio precedente all'interno della versione DODAG.

3. Sia L il Rank più basso all'interno di una versione DODAG che un dato nodo ha annunciato. All'interno della stessa versione DODAG, quel nodo NON DEVE annunciare un Rank effettivo superiore a L + DAGMaxRankIncrease. INFINITE_RANK è un'eccezione a questa regola: un nodo PUÒ annunciare un INFINITE_RANK all'interno di una versione DODAG senza restrizioni. Se il Rank di un nodo dovesse essere superiore a quello consentito da L + DAGMaxRankIncrease, quando annuncia il Rank, DEVE annunciare il suo Rank come INFINITE_RANK.

4. Un nodo PUÒ, in qualsiasi momento, scegliere di unirsi a un DODAG diverso all'interno di un'istanza RPL. Tale unione non ha restrizioni di Rank, a meno che quel DODAG diverso non sia una versione DODAG di cui questo nodo è stato precedentemente membro; in tal caso, deve essere osservata la regola del punto precedente (3). Fino a quando un nodo trasmette un DIO che indica la sua nuova appartenenza DODAG, DEVE inoltrare i pacchetti lungo il DODAG precedente.

5. Un nodo PUÒ, in qualsiasi momento dopo aver sentito il DODAGVersionNumber successivo annunciato da genitori DODAG adatti, scegliere di migrare alla versione DODAG successiva all'interno del DODAG.

Concettualmente, un'implementazione mantiene un insieme di genitori DODAG all'interno della versione DODAG. Il movimento comporta cambiamenti nell'insieme dei genitori DODAG. Muoversi verso l'alto non presenta il rischio di creare un loop, ma muoversi verso il basso potrebbe, quindi tale operazione è soggetta a vincoli aggiuntivi.

Quando un nodo migra alla versione DODAG successiva, l'insieme dei genitori DODAG deve essere ricostruito per la nuova versione. Un'implementazione potrebbe rinviare la migrazione per un periodo di tempo ragionevole, per vedere se altri vicini con metriche potenzialmente migliori ma Rank più alto si annunciano. Allo stesso modo, quando un nodo salta in un nuovo DODAG, deve costruire un nuovo insieme di genitori DODAG per questo nuovo DODAG.

Se un nodo deve muoversi verso il basso in un DODAG a cui è collegato, aumentando il suo Rank, allora PUÒ avvelenare le sue rotte e ritardare prima di muoversi come descritto nella Sezione 8.2.2.5.

Un nodo è autorizzato a unirsi a qualsiasi versione DODAG di cui non è mai stato membro precedente senza alcuna restrizione, ma se il nodo è stato membro precedente della versione DODAG, allora deve continuare a osservare la regola che non può annunciare un Rank superiore a L+DAGMaxRankIncrease in qualsiasi punto della vita della versione DODAG. Questa regola deve essere osservata per non creare una scappatoia che permetterebbe al nodo di incrementare effettivamente il suo Rank fino a INFINITE_RANK, il che può avere impatto su altri nodi e creare uno scenario di conteggio all'infinito che spreca risorse.

8.2.2.5. Avvelenamento

1. Un nodo avvelena le rotte annunciando un Rank di INFINITE_RANK.

2. Un nodo NON DEVE avere nodi con un Rank di INFINITE_RANK nel suo insieme di genitori.

Sebbene un'implementazione possa annunciare INFINITE_RANK ai fini dell'avvelenamento, farlo non è lo stesso che impostare il Rank su INFINITE_RANK. Ad esempio, un nodo può continuare a inviare pacchetti di dati le cui Informazioni sui Pacchetti RPL includono un Rank che non è INFINITE_RANK, pur annunciando INFINITE_RANK nei suoi DIO.

Quando si osserva che un (ex) genitore annuncia un Rank di INFINITE_RANK, quel (ex) genitore si è distaccato dal DODAG e non è più in grado di agire come genitore, né c'è modo che un altro nodo possa essere considerato avere un Rank maggiore di INFINITE_RANK. Pertanto, quel (ex) genitore non può più agire come genitore e viene rimosso dall'insieme dei genitori.

8.2.2.6. Distacco

1. Un nodo incapace di rimanere connesso a un DODAG all'interno di una data versione DODAG, cioè che non può mantenere un insieme di genitori non vuoto senza violare le regole di questa specifica, PUÒ distaccarsi da questa versione DODAG. Un nodo che si distacca diventa la radice del proprio DODAG fluttuante e DOVREBBE immediatamente annunciare questa nuova situazione in un DIO come alternativa all'avvelenamento.

8.2.2.7. Seguire un genitore

1. Se un nodo riceve un DIO da uno dei suoi genitori DODAG, indicando che il genitore ha lasciato il DODAG, quel nodo DOVREBBE rimanere nel suo DODAG attuale attraverso un genitore DODAG alternativo, se possibile. PUÒ seguire il genitore che se ne va.

Un genitore DODAG potrebbe essersi spostato, migrato alla versione DODAG successiva o saltato a un DODAG diverso. Un nodo dovrebbe dare una certa preferenza a rimanere nel DODAG attuale, se possibile tramite un genitore alternativo, ma dovrebbe seguire il genitore se non ci sono altre opzioni.