8. Rotte Verso l'Alto

Questa sezione descrive come RPL scopre e mantiene le rotte verso l'Alto. Descrive l'uso dei DODAG Information Objects (DIO), i messaggi utilizzati per scoprire e mantenere queste rotte. Specifica come RPL genera e risponde ai DIO. Descrive anche i messaggi DODAG Information Solicitation (DIS), che vengono utilizzati per attivare le trasmissioni DIO.

Come menzionato nella Sezione 3.2.8, i nodi che decidono di unirsi a un DODAG DEVONO provisionare almeno un genitore DODAG come rotta predefinita per l'istanza associata. Questa rotta predefinita consente a un pacchetto di essere inoltrato verso l'Alto fino a quando non raggiunge un antenato comune da cui verrà instradato verso il Basso verso la destinazione. Se la destinazione non è nel DODAG, allora la radice del DODAG potrebbe essere in grado di inoltrare il pacchetto utilizzando la connettività verso l'esterno del DODAG; se non può inoltrare il pacchetto all'esterno, allora la radice del DODAG deve scartarlo.

Un messaggio DIO può anche trasportare informazioni di instradamento esplicite:

• DODAGID: Il DODAGID è un indirizzo IPv6 Globale o Unique Local della radice. Un nodo che si unisce a un DODAG DOVREBBE provisionare una rotta host tramite un genitore DODAG verso l'indirizzo utilizzato dalla radice come DODAGID.

• Prefisso RIO: La radice PUÒ inserire una o più opzioni Route Information (RIO) in un messaggio DIO. Il RIO viene utilizzato per annunciare una rotta esterna raggiungibile tramite la radice, associata a una preferenza, come presentato nella Sezione 6.7.5, che incorpora il RIO da [RFC4191]. È interpretato come una capacità della radice in opposizione a un annuncio di instradamento, e NON DEVE essere ridistribuito in un altro protocollo di instradamento sebbene DOVREBBE essere utilizzato da un router RPL di ingresso per selezionare un DODAG quando un pacchetto viene iniettato in un dominio RPL da un nodo collegato a quel router RPL. Una Funzione Obiettivo PUÒ utilizzare le rotte annunciate nel RIO o la preferenza per quelle rotte al fine di favorire un DODAG rispetto a un altro per la stessa istanza.

8.1. Regole Base DIO

1. Per i seguenti campi DIO Base, un nodo che non è una radice DODAG DEVE annunciare gli stessi valori del suo genitore DODAG preferito (definito nella Sezione 8.2.1). In questo modo, questi valori si propagheranno verso il Basso del DODAG invariati e annunciati da ogni nodo che ha una rotta verso quella radice DODAG. Questi campi sono i seguenti:

   1. Grounded (G)
   2. Modalità di Funzionamento (MOP)
   3. Preferenza DAG (Prf)
   4. Versione
   5. RPLInstanceID
   6. DODAGID

2. Un nodo PUÒ aggiornare i seguenti campi ad ogni hop:

   1. Rango (Rank)
   2. DTSN

3. Il campo DODAGID impostato da ogni radice DEVE essere unico all'interno dell'Istanza RPL e DEVE essere un indirizzo IPv6 instradabile appartenente alla radice.

8.2. Scoperta e Manutenzione delle Rotte Verso l'Alto

La scoperta delle rotte verso l'Alto consente a un nodo di unirsi a un DODAG scoprendo i vicini che sono membri del DODAG di interesse e identificando un insieme di genitori. Le politiche esatte per la selezione dei vicini e dei genitori dipendono dall'implementazione e sono guidate dall'OF. Questa sezione specifica l'insieme di regole che tali politiche devono seguire per l'interoperabilità.

8.2.1. Vicini e Genitori all'interno di una Versione DODAG

Gli algoritmi e l'elaborazione della scoperta delle rotte verso l'Alto di RPL sono in termini di tre insiemi logici di nodi link-local. Primo, l'insieme dei vicini candidati è un sottoinsieme dei nodi che possono essere raggiunti tramite multicast link-local. La selezione di questo insieme dipende dall'implementazione e dall'OF. Secondo, l'insieme dei genitori è un sottoinsieme ristretto dell'insieme dei vicini candidati. Infine, il genitore preferito è un membro dell'insieme dei genitori che è il next hop preferito nelle rotte verso l'Alto. Concettualmente, il genitore preferito è un singolo genitore; sebbene, possa essere un insieme di più genitori se tali genitori sono ugualmente preferiti e hanno un Rango identico.

Più precisamente:

1. L'insieme dei genitori DODAG DEVE essere un sottoinsieme dell'insieme dei vicini candidati.

2. Una radice DODAG DEVE avere un insieme dei genitori DODAG di dimensione zero.

3. Un nodo che non è una radice DODAG PUÒ mantenere un insieme dei genitori DODAG di dimensione maggiore o uguale a uno.

4. Il genitore DODAG preferito di un nodo DEVE essere un membro del suo insieme dei genitori DODAG.

5. Il Rango di un nodo DEVE essere maggiore di tutti gli elementi del suo insieme dei genitori DODAG.

6. Quando il Neighbor Unreachability Detection (NUD) [RFC4861], o un meccanismo equivalente, determina che un vicino non è più raggiungibile, un nodo RPL NON DEVE considerare questo nodo nell'insieme dei vicini candidati durante il calcolo e l'annuncio delle rotte fino a quando non determina che è nuovamente raggiungibile. Le rotte attraverso un vicino irraggiungibile DEVONO essere rimosse dalla tabella di instradamento.

Queste regole assicurano che esista un ordine parziale coerente sui nodi all'interno del DODAG. Finché i Ranghi dei nodi non cambiano, seguire le regole sopra indicate assicura che la rotta di ogni nodo verso una radice DODAG sia priva di loop, poiché il Rango diminuisce ad ogni hop verso la radice.

L'OF può guidare la selezione dell'insieme dei vicini candidati e dell'insieme dei genitori, come discusso in [RFC6552].

8.2.2. Vicini e Genitori attraverso le Versioni DODAG

Le regole sopra indicate 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 univocamente una Versione DODAG. Ogni elemento dell'insieme dei genitori DODAG di un nodo, come trasmesso dall'ultimo messaggio DIO ascoltato da ciascun 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 dell'Aritmetica dei Numeri di Serie 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 ascoltato. 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 precedente Versione DODAG 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), allora le informazioni DODAG non dovrebbero essere soppresse fino alla scadenza di un timer locale specifico dell'implementazione. Durante l'intervallo precedente alla soppressione del "vecchio" stato DODAG, il nodo sarà in grado di osservare se il DODAGVersionNumber è stato incrementato qualora dovessero apparire nuovi genitori. Questo aiuterà a proteggere contro la possibilità di loop che potrebbero verificarsi se quel nodo dovesse inavvertitamente riunirsi alla vecchia Versione DODAG nel suo precedente sotto-DODAG.

Man mano che il DODAGVersionNumber viene incrementato, una nuova Versione DODAG si diffonde verso l'esterno dalla radice del 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 sicurezza un genitore di qualsiasi Rango 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 avesse tentato di avvelenare quel sotto-DODAG annunciando un Rango di INFINITE_RANK, ma quegli annunci potrebbero essere andati persi nella LLN. Allora, se il nodo osservasse un vicino candidato annunciare 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 è certo di essere sicuro, poiché è certo di non essere nel sotto-DODAG di quel nodo originale, poiché è stato in grado di incrementare il DODAGVersionNumber ascoltando dalla radice del 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 dallo scopo di questa specifica. Esempi includono l'incremento del DODAGVersionNumber periodicamente, su intervento amministrativo o sul 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 sopra indicate lo rendono incapace di annunciare la precedente Versione DODAG (precedente DODAGVersionNumber) 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 Rango di ROOT_RANK.

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

In una distribuzione 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 Rango di BASE_RANK sul backbone. Tutte le radici LLN che sono imparentate con quella radice backbone, inclusa la radice backbone se funge anche da radice LLN stessa, espongono un Rango di ROOT_RANK alla 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 dallo scopo di questa specifica (da definire in future specifiche compagne).

8.2.2.3. Selezione del DODAG

La Funzione Obiettivo e l'insieme delle metriche di instradamento annunciate e dei vincoli di un DAG determinano come un nodo seleziona il suo insieme dei 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 altre condizioni, è lasciato all'implementazione determinare quale DODAG è più preferito (poiché, come promemoria, un nodo deve unirsi a un solo DODAG per Istanza RPL).

8.2.2.4. Rango e Movimento all'interno di una Versione DODAG

1. Un nodo NON DEVE annunciare un Rango minore o uguale a qualsiasi membro del suo insieme dei genitori all'interno della Versione DODAG.

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

3. Sia L il Rango 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 Rango 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 Rango di un nodo dovesse essere superiore a quanto consentito da L + DAGMaxRankIncrease, quando annuncia il Rango, DEVE annunciare il suo Rango 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 Rango, a meno che quel diverso DODAG sia una Versione DODAG di cui questo nodo è stato precedentemente membro; nel qual caso, la regola del punto precedente (3) deve essere osservata. Fino a quando un nodo non trasmette un DIO che indica la sua nuova appartenenza al DODAG, DEVE inoltrare i pacchetti lungo il precedente DODAG.

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

Concettualmente, un'implementazione sta mantenendo un insieme dei genitori DODAG all'interno della Versione DODAG. Il movimento comporta modifiche all'insieme dei genitori DODAG. Spostarsi verso l'Alto non presenta il rischio di creare un loop ma spostarsi verso il Basso potrebbe, quindi tale operazione è soggetta a vincoli aggiuntivi.

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

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

A un nodo è consentito unirsi a qualsiasi Versione DODAG di cui non è mai stato membro precedente senza alcuna restrizione, ma se il nodo è stato un membro precedente della Versione DODAG, allora deve continuare a osservare la regola che non può annunciare un Rango superiore a L+DAGMaxRankIncrease in qualsiasi momento della vita della Versione DODAG. Questa regola deve essere osservata per non creare una scappatoia che consentirebbe al nodo di incrementare efficacemente il suo Rango fino a INFINITE_RANK, il che potrebbe avere un impatto su altri nodi e creare uno scenario di count-to-infinity che spreca risorse.

8.2.2.5. Avvelenamento (Poisoning)

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

2. Un nodo NON DEVE avere alcun nodo con un Rango di INFINITE_RANK nel suo insieme dei genitori.

Sebbene un'implementazione possa annunciare INFINITE_RANK ai fini dell'avvelenamento, farlo non è la stessa cosa che impostare il Rango a INFINITE_RANK. Ad esempio, un nodo può continuare a inviare pacchetti dati le cui Informazioni Pacchetto RPL includono un Rango che non è INFINITE_RANK, e tuttavia annunciare INFINITE_RANK nei suoi DIO.

Quando un (ex) genitore viene osservato annunciare un Rango di INFINITE_RANK, quell'(ex) genitore si è distaccato dal DODAG e non è più in grado di agire come un genitore, né c'è alcun modo che un altro nodo possa essere considerato avere un Rango maggiore di INFINITE_RANK. Pertanto, quell'(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 dei 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 annunciare immediatamente 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 attuale DODAG tramite un genitore DODAG alternativo, se possibile. PUÒ seguire il genitore che se ne va.

Un genitore DODAG può essersi spostato, migrato alla successiva Versione DODAG o saltato a un diverso DODAG. 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.

8.2.3. Comunicazione dei Messaggi DIO

Quando viene ricevuto un messaggio DIO, il nodo ricevente deve prima determinare se il messaggio DIO deve essere accettato o meno per un'ulteriore elaborazione, e successivamente presentare il messaggio DIO per un'ulteriore elaborazione se idoneo.

1. Se il messaggio DIO è malformato, allora il messaggio DIO non è idoneo per un'ulteriore elaborazione e un nodo DEVE scartarlo silenziosamente. (Vedere la Sezione 18 per la registrazione degli errori).

2. Se il mittente del messaggio DIO è un membro dell'insieme dei vicini candidati e il messaggio DIO non è malformato, il nodo DEVE elaborare il DIO.

8.2.3.1. Elaborazione del Messaggio DIO

Man mano che i messaggi DIO vengono ricevuti dai vicini candidati, i vicini possono essere promossi a genitori DODAG seguendo le regole di scoperta DODAG come descritto nella Sezione 8.2. Quando un nodo inserisce un vicino nell'insieme dei genitori DODAG, il nodo diventa collegato al DODAG tramite il nuovo nodo genitore DODAG.

Il genitore più preferito dovrebbe essere utilizzato per limitare quali altri nodi possono diventare genitori DODAG. Alcuni nodi nell'insieme dei genitori DODAG possono essere di un Rango minore o uguale al genitore DODAG più preferito. (Questo caso può verificarsi, ad esempio, se un dispositivo con limitazioni energetiche è a un Rango minore ma dovrebbe essere evitato secondo un obiettivo di ottimizzazione, risultando in un genitore più preferito a un Rango maggiore.)

8.3. Trasmissione DIO

I nodi RPL trasmettono DIO utilizzando un timer Trickle [RFC6206]. Un DIO da un mittente con un DAGRank minore che non causa modifiche all'insieme dei genitori, al genitore preferito o al Rango del destinatario DOVREBBE essere considerato coerente rispetto al timer Trickle.

I seguenti pacchetti ed eventi DEVONO essere considerati incongruenze rispetto al timer Trickle e causare il reset del timer Trickle:

• Quando un nodo rileva un'incongruenza durante l'inoltro di un pacchetto, come dettagliato nella Sezione 11.2.

• Quando un nodo riceve un messaggio DIS multicast senza un'opzione Solicited Information, a meno che un flag DIS non limiti questo comportamento.

• Quando un nodo riceve un DIS multicast con un'opzione Solicited Information e il nodo soddisfa tutti i predicati nell'opzione Solicited Information, a meno che un flag DIS non limiti questo comportamento.

• Quando un nodo si unisce a una nuova Versione DODAG (ad esempio, aggiornando il suo DODAGVersionNumber, unendosi a una nuova Istanza RPL, ecc.).

Si noti che questo elenco non è esaustivo e un'implementazione PUÒ considerare altri messaggi o eventi come incongruenze.

Un nodo NON DOVREBBE resettare il suo timer Trickle DIO in risposta a messaggi DIS unicast. Quando un nodo riceve un DIS unicast senza un'opzione Solicited Information, DEVE inviare un DIO unicast al mittente in risposta. Questo DIO DEVE includere un'opzione DODAG Configuration. Quando un nodo riceve un messaggio DIS unicast con un'opzione Solicited Information e soddisfa i predicati di quell'opzione Solicited Information, DEVE inviare un DIO unicast al mittente in risposta. Questo DIO unicast DEVE includere un'opzione DODAG Configuration. Quindi, un nodo PUÒ trasmettere un messaggio DIS unicast a un potenziale genitore DODAG al fine di sondare la Configurazione DODAG e altri parametri.

8.3.1. Parametri Trickle

I parametri di configurazione del timer Trickle sono specificati come segue:

• Imin: appreso dal messaggio DIO come (2^DIOIntervalMin) ms. Il valore predefinito di DIOIntervalMin è DEFAULT_DIO_INTERVAL_MIN.

• Imax: appreso dal messaggio DIO come DIOIntervalDoublings. Il valore predefinito di DIOIntervalDoublings è DEFAULT_DIO_INTERVAL_DOUBLINGS.

• k: appreso dal messaggio DIO come DIORedundancyConstant. Il valore predefinito di DIORedundancyConstant è DEFAULT_DIO_REDUNDANCY_CONSTANT. In RPL, quando k ha il valore di 0x00, questo deve essere trattato come una costante di ridondanza di infinito in RPL, cioè, Trickle non sopprime mai i messaggi.

8.4. Selezione del DODAG

La selezione del DODAG dipende dall'implementazione e dall'OF. Al fine di limitare i movimenti erratici, e a parità di metriche, i nodi DOVREBBERO mantenere la loro selezione precedente. Inoltre, i nodi DOVREBBERO fornire un mezzo per filtrare un genitore la cui disponibilità è rilevata come fluttuante, almeno quando sono disponibili scelte più stabili.

Quando la connessione a un DODAG grounded non è possibile o preferibile per motivi di sicurezza o altri, i DODAG sparsi POSSONO aggregarsi il più possibile in DODAG più grandi al fine di consentire la connettività all'interno della LLN.

Un nodo DOVREBBE verificare che la connettività bidirezionale e una qualità del collegamento adeguata siano disponibili con un vicino candidato prima di considerare quel candidato come un genitore DODAG.

8.5. Funzionamento come Nodo Foglia

In alcuni casi, un nodo RPL può collegarsi a un DODAG solo come nodo foglia. Un esempio di tale caso è quando un nodo non capisce o non supporta (politica) l'OF dell'Istanza RPL o la metrica/vincolo annunciato. Come specificato nella Sezione 18.6, relativa alla funzione di politica, il nodo può unirsi al DODAG come nodo foglia o non unirsi al DODAG. Come menzionato nella Sezione 18.5, è quindi raccomandato registrare un guasto.

Un nodo foglia non estende la connettività DODAG; tuttavia, in alcuni casi, il nodo foglia potrebbe ancora aver bisogno di trasmettere DIO occasionalmente, in particolare, quando il nodo foglia potrebbe non aver sempre agito come nodo foglia e viene rilevata un'incongruenza.

Un nodo che opera come nodo foglia deve obbedire alle seguenti regole:

1. NON DEVE trasmettere DIO contenenti il DAG Metric Container.

2. I suoi DIO DEVONO annunciare un DAGRank di INFINITE_RANK.

3. PUÒ sopprimere la trasmissione DIO, a meno che la trasmissione DIO non sia stata attivata a causa del rilevamento di un'incongruenza quando un pacchetto viene inoltrato o in risposta a un messaggio DIS unicast, nel qual caso la trasmissione DIO NON DEVE essere soppressa.

4. PUÒ trasmettere DAO unicast come descritto nella Sezione 9.2.

5. PUÒ trasmettere DAO multicast al vicinato '1 hop' come descritto nella Sezione 9.10.

Un caso particolare che richiede a un nodo foglia di inviare un DIO è se quel nodo foglia era un membro precedente di un altro DODAG e un altro nodo inoltra un messaggio assumendo la vecchia topologia, attivando un'incongruenza. Il nodo foglia deve trasmettere un DIO al fine di riparare l'incongruenza. Si noti che a causa della natura con perdita delle LLN, anche se il nodo foglia potrebbe aver avvelenato ottimisticamente le sue rotte annunciando un Rango di INFINITE_RANK nel vecchio DODAG prima di diventare un nodo foglia, quell'annuncio potrebbe essere andato perso e un nodo foglia deve essere in grado di inviare un DIO più tardi al fine di riparare l'incongruenza.

Nel caso generale, il nodo foglia NON DEVE annunciarsi come un router (cioè, inviare DIO).

8.6. Rango Amministrativo

In alcuni casi, potrebbe essere vantaggioso regolare il Rango annunciato da un nodo oltre quello calcolato dall'OF sulla base di qualche politica specifica dell'implementazione e proprietà del nodo. Ad esempio, un nodo che ha una batteria limitata dovrebbe essere una foglia a meno che non ci sia altra scelta, e può quindi aumentare il calcolo del Rango specificato dall'OF al fine di esporre un Rango esagerato.