9. Rotte Discendenti

Questa sezione descrive come RPL scopre e mantiene le rotte discendenti (Downward routes). RPL costruisce e mantiene le rotte discendenti con messaggi Destination Advertisement Object (DAO). Le rotte discendenti supportano i flussi P2MP, dalle radici del DODAG verso le foglie. Le rotte discendenti supportano anche i flussi P2P: i messaggi P2P possono fluire verso una radice del DODAG (o un antenato comune) attraverso una rotta ascendente, poi allontanarsi dalla radice del DODAG verso una destinazione attraverso una rotta discendente.

Questa specifica descrive le due modalità tra cui un'istanza RPL può scegliere per mantenere le rotte discendenti. Nella prima modalità, chiamata "Storing" (Memorizzazione), i nodi memorizzano le tabelle di instradamento discendenti per il loro sub-DODAG. Ogni hop su una rotta discendente in una rete storing esamina la sua tabella di instradamento per decidere il prossimo hop. Nella seconda modalità, chiamata "Non-Storing" (Non Memorizzazione), i nodi non memorizzano le tabelle di instradamento discendenti. I pacchetti discendenti sono instradati con rotte alla sorgente popolate da una radice del DODAG [RFC6554].

RPL consente una semplice ottimizzazione P2P a un hop sia per le reti storing che per quelle non-storing. Un nodo può inviare un pacchetto P2P destinato a un vicino a un hop direttamente a quel nodo.

9.1. Genitori Destination Advertisement

Per stabilire rotte discendenti, i nodi RPL inviano messaggi DAO verso l'alto. Le destinazioni next-hop di questi messaggi DAO sono chiamate "DAO parents" (genitori DAO). L'insieme dei genitori DAO di un nodo è chiamato "DAO parent set".

1. Un nodo PUÒ inviare messaggi DAO utilizzando l'indirizzo multicast all-RPL-nodes, che è un'ottimizzazione per fornire l'instradamento a un hop. Il bit 'K' DEVE essere azzerato alla trasmissione del DAO multicast.

2. L'insieme dei genitori DAO di un nodo DEVE essere un sottoinsieme del suo insieme dei genitori DODAG.

3. Nell'operazione in modalità Storing, un nodo NON DEVE indirizzare messaggi DAO unicast a nodi che non sono genitori DAO.

4. Nell'operazione in modalità Storing, gli indirizzi IPv6 sorgente e destinazione di un messaggio DAO DEVONO essere indirizzi link-local.

5. Nell'operazione in modalità Non-Storing, un nodo NON DEVE indirizzare messaggi DAO unicast a nodi che non sono radici del DODAG.

6. Nell'operazione in modalità Non-Storing, gli indirizzi IPv6 sorgente e destinazione di un messaggio DAO DEVONO essere un indirizzo unique-local o globale.

La selezione dei genitori DAO è specifica dell'implementazione e della Funzione Obiettivo.

9.2. Scoperta e Manutenzione delle Rotte Discendenti

Il Destination Advertisement può essere configurato per essere interamente disabilitato, o operare in modalità Storing o Non-Storing, come riportato nel MOP nel messaggio DIO.

1. Tutti i nodi che si uniscono a un DODAG DEVONO attenersi all'impostazione MOP dalla radice. I nodi che non hanno la capacità di partecipare pienamente come router, ad esempio, che non corrispondono al MOP annunciato, POSSONO unirsi al DODAG come foglia.

2. Se il MOP è 0, indicando nessun instradamento discendente, i nodi NON DEVONO trasmettere messaggi DAO e POSSONO ignorare i messaggi DAO.

3. In modalità Non-Storing, la radice del DODAG DOVREBBE memorizzare le voci della tabella di instradamento alla sorgente per le destinazioni apprese dai DAO. La radice del DODAG DEVE essere in grado di generare rotte alla sorgente per quelle destinazioni apprese dai DAO che sono state memorizzate.

4. In modalità Storing, tutti i nodi non-radice, non-foglia DEVONO memorizzare le voci della tabella di instradamento per le destinazioni apprese dai DAO.

Un DODAG può avere una di diverse possibili modalità di operazione, come definito dal campo MOP. O non supporta le rotte discendenti, o supporta le rotte discendenti attraverso l'instradamento alla sorgente dalle radici del DODAG, o supporta le rotte discendenti attraverso tabelle di instradamento all'interno della rete.

Quando le rotte discendenti sono supportate attraverso l'instradamento alla sorgente dalle radici del DODAG, ci si aspetta generalmente che la radice del DODAG abbia memorizzato le informazioni di instradamento alla sorgente apprese dai DAO al fine di costruire le rotte alla sorgente. Se la radice del DODAG non riesce a memorizzare alcune informazioni, allora alcune destinazioni potrebbero essere irraggiungibili.

Quando le rotte discendenti sono supportate attraverso tabelle di instradamento all'interno della rete, l'operazione multicast definita in questa specifica può o meno essere supportata, anche come indicato dal campo MOP.

Quando le rotte discendenti sono supportate attraverso tabelle di instradamento all'interno della rete, come descritto in questa specifica, ci si aspetta che i nodi che agiscono come router siano stati approvvigionati sufficientemente per mantenere lo stato della tabella di instradamento richiesto. Se un nodo che agisce come router non è in grado di mantenere l'intero stato della tabella di instradamento, allora lo stato di instradamento non è completo, i messaggi possono essere scartati di conseguenza, e un guasto può essere registrato (Sezione 18.5). Estensioni future a RPL possono elaborare azioni/comportamenti raffinati per gestire questo caso.

Al momento della stesura di questa specifica, RPL non supporta l'operazione in modalità mista, dove alcuni nodi effettuano instradamento alla sorgente e altri memorizzano tabelle di instradamento: estensioni future a RPL possono supportare questa modalità di operazione.

9.2.1. Manutenzione della Sequenza del Percorso

Per ogni Target che è associato a (posseduto da) un nodo, quel nodo è responsabile di emettere messaggi DAO al fine di fornire le rotte discendenti. Le informazioni Target+Transit contenute in quei messaggi DAO si propagano successivamente verso l'alto nel DODAG. Il contatore Path Sequence (Sequenza del Percorso) nell'opzione Transit Information è utilizzato per indicare la freschezza e aggiornare le informazioni di instradamento discendenti obsolete come descritto nella Sezione 7.

Per un Target che è associato a (posseduto da) un nodo, quel nodo DEVE incrementare il contatore Path Sequence, e generare un nuovo messaggio DAO, quando:

1. il Path Lifetime deve essere aggiornato (ad esempio, un aggiornamento o un no-Path).

2. la lista del sottocampo DODAG Parent Address deve essere cambiata.

Per un Target che è associato a (posseduto da) un nodo, quel nodo PUÒ incrementare il contatore Path Sequence, e generare un nuovo messaggio DAO, occasionalmente al fine di aggiornare le informazioni di instradamento discendenti. In modalità Storing, il nodo genera un tale DAO verso ciascuno dei suoi genitori DAO al fine di abilitare il multipath. Tutti i DAO generati nello stesso momento per lo stesso Target DEVONO essere inviati con la stessa Path Sequence nella Transit Information.

9.2.2. Generazione di Messaggi DAO

Un nodo potrebbe inviare messaggi DAO quando riceve messaggi DAO, come risultato di cambiamenti nel suo insieme dei genitori DAO, o in risposta a un altro evento come la scadenza di un lifetime di prefisso correlato. Nel caso di ricezione di DAO, importa se il messaggio DAO è "nuovo" o contiene nuove informazioni. In modalità Non-Storing, ogni messaggio DAO che un nodo riceve è "nuovo". In modalità Storing, un messaggio DAO è "nuovo" se soddisfa uno qualsiasi di questi criteri per un Target contenuto:

1. ha un numero di Path Sequence più recente,

2. ha bit di Path Control aggiuntivi, o

3. è un messaggio No-Path DAO che rimuove l'ultima rotta discendente verso un prefisso.

Un nodo che riceve un messaggio DAO dal suo sub-DODAG PUÒ sopprimere la pianificazione di una trasmissione di messaggio DAO se quel messaggio DAO non è nuovo.

9.3. Regole Base DAO

1. Se un nodo invia un messaggio DAO con informazioni più recenti o diverse rispetto alla trasmissione del messaggio DAO precedente, DEVE incrementare il campo DAOSequence di almeno uno. Una trasmissione di messaggio DAO che è identica alla trasmissione del messaggio DAO precedente PUÒ incrementare il campo DAOSequence.

2. I campi RPLInstanceID e DODAGID di un messaggio DAO DEVONO essere lo stesso valore dei membri dell'insieme dei genitori del nodo e dei DIO che trasmette.

3. Un nodo PUÒ impostare il flag 'K' in un messaggio DAO unicast per sollecitare un DAO-ACK unicast in risposta al fine di confermare il tentativo.

4. Un nodo che riceve un messaggio DAO unicast con il flag 'K' impostato DOVREBBE rispondere con un DAO-ACK. Un nodo che riceve un messaggio DAO senza il flag 'K' impostato PUÒ rispondere con un DAO-ACK, specialmente per segnalare una condizione di errore.

5. Un nodo che imposta il flag 'K' in un messaggio DAO unicast ma non riceve un DAO-ACK in risposta PUÒ riprogrammare la trasmissione del messaggio DAO per un altro tentativo, fino a un numero di tentativi specifico dell'implementazione.

6. I nodi DOVREBBERO ignorare i DAO senza numeri di sequenza più recenti e NON DEVONO elaborarli ulteriormente.

A differenza del campo Version di un DIO, che è incrementato solo da una radice del DODAG e ripetuto immutato da altri nodi, i valori DAOSequence sono unici per ogni nodo. Lo spazio dei numeri di sequenza per i messaggi DAO unicast e multicast può essere lo stesso o distinto. È RACCOMANDATO utilizzare lo stesso spazio dei numeri di sequenza.

9.4. Struttura dei Messaggi DAO

I DAO seguono una struttura comune sia nelle reti storing che non-storing. Nella forma più generale, un messaggio DAO può includere diversi gruppi di opzioni, dove ogni gruppo consiste di una o più opzioni Target seguite da una o più opzioni Transit Information.

L'intero gruppo di opzioni Transit Information si applica all'intero gruppo di opzioni Target. Le sezioni successive descrivono ulteriori dettagli per ciascuna modalità di operazione.

1. I nodi RPL DEVONO includere una o più opzioni RPL Target in ogni messaggio DAO che trasmettono. Un'opzione RPL Target DEVE avere un prefisso che include l'indirizzo IPv6 del nodo se quel nodo ha bisogno che il DODAG fornisca rotte discendenti verso quel nodo. L'opzione RPL Target PUÒ essere immediatamente seguita da un'opzione opaca RPL Target Descriptor che la qualifica.

2. Quando un nodo aggiorna le informazioni in un'opzione Transit Information per un'opzione Target che copre uno dei suoi indirizzi, DEVE incrementare il numero Path Sequence in quell'opzione Transit Information. Il numero Path Sequence PUÒ essere incrementato occasionalmente per causare un aggiornamento alle rotte discendenti.

3. Una o più opzioni RPL Target in un messaggio DAO unicast DEVONO essere seguite da una o più opzioni Transit Information. Tutte le opzioni transit si applicano a tutte le opzioni Target che le precedono immediatamente.

4. I DAO Multicast NON DEVONO includere il sottocampo DODAG Parent Address nelle opzioni Transit Information.

5. Un nodo che riceve ed elabora un messaggio DAO contenente informazioni per un Target specifico, e che ha informazioni precedenti per quel Target, DEVE utilizzare il numero Path Sequence nell'opzione Transit Information associata a quel Target al fine di determinare se il messaggio DAO contiene o meno informazioni aggiornate per la Sezione 7.

6. Se un nodo riceve un messaggio DAO che non segue le regole di cui sopra, DEVE scartare il messaggio DAO senza ulteriore elaborazione.

In modalità Non-Storing, la radice costruisce un'intestazione di instradamento alla sorgente rigorosa (strict source routing header), hop-by-hop, cercando ricorsivamente informazioni a un hop che legano un Target (indirizzo o prefisso) e un indirizzo di transito insieme. In alcuni casi, quando un indirizzo figlio è derivato da un prefisso che è posseduto e annunciato da un genitore, quella relazione genitore-figlio può essere dedotta dalla radice allo scopo di costruire l'intestazione di instradamento alla sorgente. In tutti gli altri casi, è necessario informare la radice della relazione transito-Target da un target raggiungibile, in modo da abilitare successivamente la costruzione ricorsiva dell'intestazione di instradamento. Un indirizzo che è annunciato come Target in un messaggio DAO DEVE essere collocato nello stesso router, o raggiungibile on-link dal router che possiede l'indirizzo che è indicato nella Transit Information associata. Le seguenti regole aggiuntive si applicano per garantire la continuità del percorso di instradamento alla sorgente end-to-end:

1. L'indirizzo di un genitore utilizzato nell'opzione transit DEVE essere preso da un PIO da quel genitore con il flag 'R' impostato. Il flag 'R' in un PIO indica che il campo prefisso contiene in realtà l'indirizzo completo del genitore ma il figlio NON DOVREBBE assumere che l'indirizzo del genitore sia on-link.

2. Un PIO con un flag 'A' impostato indica che il nodo figlio RPL può utilizzare il prefisso per autoconfigurare un indirizzo. Un genitore che annuncia un prefisso in un PIO con il flag 'A' impostato DEVE garantire che l'indirizzo o l'intero prefisso nel PIO sia raggiungibile dalla radice annunciandolo come target DAO. Se il genitore imposta anche il flag 'L' indicando che il prefisso è on-link, allora DEVE annunciare l'intero prefisso come Target in un messaggio DAO. Se il flag 'L' è azzerato e il flag 'R' è impostato, indicando che il genitore fornisce il proprio indirizzo nel PIO, allora il genitore DEVE annunciare quell'indirizzo come target DAO.

3. Un indirizzo che è annunciato come Target in un messaggio DAO DEVE essere collocato nello stesso router o raggiungibile on-link dal router che possiede l'indirizzo che è indicato nella Transit Information associata.

4. Al fine di abilitare una compressione ottima dell'intestazione di instradamento, il genitore DOVREBBE impostare il flag 'R' in tutti i PIO con il flag 'A' impostato e il flag 'L' azzerato, e il figlio DOVREBBE preferire utilizzare come transito l'indirizzo del genitore che si trova nel PIO che è utilizzato per autoconfigurare l'indirizzo che è annunciato come Target nel messaggio DAO.

5. Un router potrebbe avere target che non sono noti per essere on-link per un genitore, o perché sono indirizzi situati su un'interfaccia alternativa o perché appartengono a nodi che sono esterni a RPL, per esempio host connessi. Al fine di iniettare un tale Target nella rete RPL, il router DEVE annunciare se stesso come il sottocampo DODAG Parent Address nell'opzione Transit Information per quel target, utilizzando un indirizzo che è on-link per il genitore DAO di quel nodo. Se il Target appartiene a un nodo esterno, allora il router DEVE impostare il flag External 'E' nella Transit Information.

Un nodo figlio che ha autoconfigurato un indirizzo da un PIO genitore con il flag 'L' impostato non ha bisogno di annunciare quell'indirizzo come Target DAO poiché il genitore garantisce che l'intero prefisso sia già raggiungibile dalla radice. Tuttavia, se il flag 'L' non è impostato, allora è necessario, in modalità Non-Storing, che il nodo figlio informi la radice della relazione genitore-figlio, utilizzando un indirizzo raggiungibile del genitore, in modo da abilitare la costruzione ricorsiva dell'intestazione di instradamento. Questo viene fatto associando un indirizzo del genitore come transito con l'indirizzo del figlio come Target in un messaggio DAO.

9.5. Pianificazione della Trasmissione DAO

Poiché i DAO fluiscono verso l'alto, ricevere un DAO unicast può innescare l'invio di un DAO unicast a un genitore DAO.

1. Alla ricezione di un messaggio DAO unicast con informazioni aggiornate, come contenente un'opzione Transit Information con una nuova Path Sequence, un nodo DOVREBBE inviare un DAO. NON DOVREBBE inviare questo messaggio DAO immediatamente. DOVREBBE ritardare l'invio del messaggio DAO al fine di aggregare le informazioni DAO da altri nodi per i quali è un genitore DAO.

2. Un nodo DOVREBBE ritardare l'invio di un messaggio DAO con un timer (DelayDAO). La ricezione di un messaggio DAO avvia il timer DelayDAO. I messaggi DAO ricevuti mentre il timer DelayDAO è attivo non reimpostano il timer. Quando il timer DelayDAO scade, il nodo invia un DAO.

3. Quando un nodo aggiunge un nodo al suo insieme dei genitori DAO, DOVREBBE pianificare una trasmissione di messaggio DAO.

Il valore e il calcolo di DelayDAO sono dipendenti dall'implementazione. Un valore predefinito di DEFAULT_DAO_DELAY è definito in questa specifica.

9.6. Innesco dei Messaggi DAO

I nodi possono innescare il loro sub-DODAG a inviare messaggi DAO. Ogni nodo mantiene un DAO Trigger Sequence Number (DTSN), che comunica attraverso messaggi DIO.

1. Se un nodo sente uno dei suoi genitori DAO incrementare il suo DTSN, il nodo DEVE pianificare una trasmissione di messaggio DAO utilizzando le regole nelle Sezioni 9.3 e 9.5.

2. In modalità Non-Storing, se un nodo sente uno dei suoi genitori DAO incrementare il suo DTSN, il nodo DEVE incrementare il proprio DTSN.

In una modalità di operazione Storing, come parte degli aggiornamenti e della manutenzione di routine della tabella di instradamento, un nodo storing PUÒ incrementare il DTSN al fine di innescare affidabilmente un insieme di aggiornamenti DAO dai suoi figli immediati.

In una modalità di operazione Storing, non è necessario innescare aggiornamenti DAO dall'intero sub-DODAG, poiché quelle informazioni di stato si propagheranno hop-by-hop verso l'alto nel DODAG.

In una modalità di operazione Non-Storing, un incremento DTSN causerà anche ai figli immediati di un nodo di incrementare il loro DTSN a loro volta, innescando un insieme di aggiornamenti DAO dall'intero sub-DODAG. Tipicamente, in una modalità di operazione Non-Storing, solo la radice incrementerebbe indipendentemente il DTSN quando è necessario un aggiornamento DAO ma una riparazione globale (come incrementando il DODAGVersionNumber) non è desiderata. Tipicamente, in una modalità di operazione Non-Storing, tutti i nodi non-radice incrementerebbero il loro DTSN solo quando si osserva che il loro genitore(i) lo fa.

In generale, un nodo può innescare aggiornamenti DAO secondo logiche specifiche dell'implementazione, come basato sul rilevamento di un'inconsistenza della rotta discendente o occasionalmente basato su un timer interno.

In una rete storing, selezionare un DelayDAO appropriato per i DAO innescati può ridurre notevolmente il numero di DAO trasmessi. L'innesco fluisce verso il basso nel DODAG; nel caso migliore, i DAO fluiscono verso l'alto nel DODAG in modo tale che le foglie inviino i DAO per prime, con ogni nodo che invia un messaggio DAO solo una volta. Una tale pianificazione potrebbe essere approssimata impostando DelayDAO inversamente proporzionale al Rango. Nota che questo suggerimento è inteso come un'ottimizzazione per consentire un'aggregazione efficiente (non è richiesto per il funzionamento corretto nel caso generale).

9.7. Modalità Non-Storing

In modalità Non-Storing, RPL instrada i messaggi verso il basso utilizzando l'instradamento alla sorgente IP. La seguente regola si applica ai nodi che sono in modalità Non-Storing. La modalità Storing ha un insieme separato di regole, descritto nella Sezione 9.8.

1. Il sottocampo DODAG Parent Address di un'opzione Transit Information DEVE contenere uno o più indirizzi. Tutti questi indirizzi DEVONO essere indirizzi di genitori DAO del mittente.

2. I DAO sono inviati direttamente alla radice lungo una rotta predefinita installata come parte della selezione del genitore.

3. Quando un nodo rimuove un nodo dal suo insieme dei genitori DAO, PUÒ generare un nuovo messaggio DAO con un'opzione Transit Information aggiornata.

In modalità Non-Storing, un nodo utilizza i DAO per segnalare i suoi genitori DAO alla radice del DODAG. La radice del DODAG può mettere insieme una rotta discendente verso un nodo utilizzando gli insiemi dei genitori DAO da ciascun nodo nella rotta. Le informazioni di Path Sequence possono essere utilizzate per rilevare informazioni DAO obsolete. Lo scopo di questo calcolo della rotta per-hop è minimizzare il traffico quando i genitori DAO cambiano. Se i nodi segnalassero rotte alla sorgente complete, allora a un cambiamento di genitore DAO, l'intero sub-DODAG dovrebbe inviare nuovi DAO alla radice del DODAG. Pertanto, in modalità Non-Storing, un nodo può inviare un singolo DAO, sebbene potrebbe scegliere di inviare più di un messaggio DAO a ciascuno di più genitori DAO.

I nodi impacchettano i DAO inviando un singolo messaggio DAO con più opzioni RPL Target. Ogni opzione RPL Target ha le sue opzioni Transit Information, immediatamente successive.

9.8. Modalità Storing

In modalità Storing, RPL instrada i messaggi verso il basso tramite l'indirizzo di destinazione IPv6. Le seguenti regole si applicano ai nodi che sono in modalità Storing:

1. Il sottocampo DODAG Parent Address di un'opzione Transmit Information DEVE essere vuoto.

2. Alla ricezione di un DAO unicast, un nodo DEVE calcolare se il DAO cambierebbe l'insieme di prefissi che il nodo stesso annuncia. Questo calcolo DOVREBBE includere la consultazione delle informazioni di Path Sequence nelle opzioni Transit Information associate al DAO, per determinare se il messaggio DAO contiene informazioni più recenti che sostituiscono le informazioni già memorizzate nel nodo. Se è così, il nodo DEVE generare un nuovo messaggio DAO e trasmetterlo, seguendo le regole nella Sezione 9.5. Un tale cambiamento include la ricezione di un No-Path DAO.

3. Quando un nodo genera un nuovo DAO, DOVREBBE inviarlo via unicast a ciascuno dei suoi genitori DAO. NON DEVE inviare il messaggio DAO via unicast a nodi che non sono genitori DAO.

4. Quando un nodo rimuove un nodo dal suo insieme dei genitori DAO, DOVREBBE inviare un messaggio No-Path DAO (Sezione 6.4.3) a quel genitore DAO rimosso per invalidare la rotta esistente.

5. Se i messaggi verso un indirizzo discendente annunciato soffrono di un errore di inoltro, Neighbor Unreachable Detection (NUD), o guasto simile, un nodo PUÒ marcare l'indirizzo come irraggiungibile e generare un No-Path DAO appropriato.

I DAO annunciano verso quali indirizzi di destinazione e prefissi un nodo ha rotte. A differenza della modalità Non-Storing, questi DAO non comunicano informazioni sulle rotte stesse: quell'informazione è memorizzata all'interno della rete ed è implicita dall'indirizzo sorgente IPv6. Quando un nodo storing genera un DAO, utilizza lo stato memorizzato dei DAO che ha ricevuto per produrre un insieme di opzioni RPL Target e le loro opzioni Transmit Information associate.

Poiché questa informazione è memorizzata all'interno delle tabelle di instradamento di ciascun nodo, in modalità Storing, i DAO sono comunicati direttamente ai genitori DAO, che memorizzano questa informazione.

9.9. Controllo del Percorso (Path Control)

Un messaggio DAO da un nodo contiene una o più opzioni Target. Ogni opzione Target specifica o un prefisso annunciato dal nodo, un prefisso di indirizzi raggiungibili all'esterno della LLN, l'indirizzo di una destinazione nel sub-DODAG del nodo, o un gruppo multicast a cui un nodo nel sub-DODAG sta ascoltando. Il campo Path Control dell'opzione Transit Information consente ai nodi di richiedere o permettere più rotte discendenti. Un nodo costruisce il campo Path Control di un'opzione Transit Information come segue:

1. La larghezza in bit del campo Path Control DEVE essere uguale al valore (PCS + 1), dove PCS è specificato nel campo di controllo dell'opzione DODAG Configuration. I bit maggiori o uguali al valore (PCS + 1) DEVONO essere azzerati alla trasmissione e DEVONO essere ignorati alla ricezione. I bit al di sotto di quel valore sono considerati bit "attivi".

2. Il nodo DEVE logicamente costruire raggruppamenti dei suoi genitori DAO mentre popola il campo Path Control, dove ogni gruppo consiste di genitori DAO di uguale preferenza. Quei gruppi DEVONO poi essere ordinati secondo la preferenza, che consente una mappatura logica dei genitori DAO sui sottocampi Path Control (vedi Figura 27). I gruppi POSSONO essere ripetuti al fine di estendersi sull'intera larghezza in bit del campo Path Control, ma l'ordine, inclusi i gruppi ripetuti, DEVE essere mantenuto in modo che la preferenza sia propriamente comunicata.

3. Per un'opzione RPL Target che descrive l'indirizzo proprio di un nodo o un prefisso esterno alla LLN, almeno un bit attivo del campo Path Control DEVE essere impostato. Più bit attivi del campo Path Control POSSONO essere impostati.

4. Se un nodo riceve più DAO con la stessa opzione RPL Target, DEVE effettuare l'OR bit a bit dei campi Path Control che riceve. Questo OR bit a bit aggregato rappresenta il numero di rotte discendenti che il prefisso richiede.

5. Quando un nodo invia un messaggio DAO a uno dei suoi genitori DAO, DEVE selezionare uno o più dei bit che sono impostati attivi nel sottocampo che è mappato al gruppo contenente quel genitore DAO dal campo Path Control aggregato. Un dato bit può essere presentato come attivo solo a un genitore. Il messaggio DAO che trasmette al suo genitore DEVE avere questi bit attivi impostati e tutti gli altri bit attivi azzerati.

6. Per l'opzione RPL Target e il numero DAOSequence, i DAO che un nodo invia a diversi genitori DAO DEVONO avere insiemi disgiunti di bit Path Control attivi. Un nodo NON DEVE impostare lo stesso bit attivo su DAO verso due diversi genitori DAO.

7. I bit Path Control DOVREBBERO essere allocati secondo la mappatura di preferenza dei genitori DAO sui sottocampi Path Control, in modo tale che i bit Path Control attivi, o raggruppamenti di bit, che appartengono a un particolare sottocampo Path Control siano allocati ai genitori DAO all'interno del gruppo che è stato mappato a quel sottocampo.

8. In una modalità di operazione Non-Storing, un nodo PUÒ far passare i DAO senza eseguire alcuna ulteriore elaborazione sul campo Path Control.

9. Un nodo NON DEVE inviare via unicast un messaggio DAO che non ha bit attivi impostati nel campo Path Control. È possibile che, per una data opzione Target, un nodo non abbia abbastanza bit Path Control aggregati per inviare un messaggio DAO contenente quel Target a ciascuno dei suoi genitori DAO, nel qual caso quei genitori DAO meno preferiti potrebbero non ricevere un messaggio DAO per quel Target.

Il campo Path Control consente a un nodo di limitare quante rotte discendenti saranno generate verso di esso. Imposta un numero di bit nel campo Path Control uguale al numero massimo di rotte discendenti che preferisce. Al massimo, ogni bit viene inviato a un genitore DAO; cluster di bit possono essere inviati a un singolo genitore DAO affinché lo divida tra i suoi genitori DAO.

Un nodo che fornisce una rotta DAO per un Target che ha un campo Path Control associato DOVREBBE utilizzare il contenuto di quel campo Path Control al fine di determinare un ordine di preferenza tra più rotte DAO alternative per quel Target. L'assegnazione del campo Path Control è derivata dalla preferenza (dei genitori DAO), come determinato sulla base della migliore conoscenza di questo nodo delle metriche aggregate "end-to-end" nella direzione discendente come per la Funzione Obiettivo. In modalità Non-Storing la radice può determinare la rotta discendente aggregando le informazioni da ogni DAO ricevuto, che include le indicazioni Path Control dei genitori DAO preferiti.

9.9.1. Esempio di Controllo del Percorso

Supponiamo che ci sia una LLN operante in modalità Storing che contiene un Nodo N con quattro genitori, P1, P2, P3 e P4. Sia N avere tre figli, C1, C2 e C3 nel suo sub-DODAG. Sia PCS 7, in modo che ci saranno 8 bit attivi nel campo Path Control: 11111111b. Considera il seguente esempio:

Il campo Path Control è diviso in quattro sottocampi, PC1 (11000000b), PC2 (00110000b), PC3 (00001100b) e PC4 (00000011b), in modo che quei quattro sottocampi rappresentino quattro diversi livelli di preferenza per Figura 27. L'implementazione al Nodo N, in questo esempio, raggruppa {P1, P2} per essere di uguale preferenza l'uno all'altro e il gruppo più preferito complessivamente. {P3} è meno preferito di {P1, P2}, e più preferito di {P4}. Sia il Nodo N quindi eseguire la sua mappatura Path Control in modo tale che:

       {P1, P2} -> PC1 (11000000b) nel campo Path Control
       {P3}     -> PC2 (00110000b) nel campo Path Control
       {P4}     -> PC3 (00001100b) nel campo Path Control
       {P4}     -> PC4 (00000011b) nel campo Path Control

Nota che l'implementazione ha ripetuto {P4} al fine di ottenere una copertura completa del campo Path Control.

1. Sia C1 inviare un DAO contenente un Target T con un Path Control 10000000b. Il Nodo N memorizza una voce associando 10000000b con il campo Path Control per C1 e Target T.

2. Sia C2 inviare un DAO contenente un Target T con un Path Control 00010000b. Il Nodo N memorizza una voce associando 00010000b con il campo Path Control per C1 e Target T.

3. Sia C3 inviare un DAO contenente un Target T con un Path Control 00001100b. Il Nodo N memorizza una voce associando 00001100b con il campo Path Control per C1 e Target T.

4. In un momento successivo, il Nodo N genera un DAO per il Target T. Il Nodo N costruirà un campo Path Control aggregato effettuando l'OR insieme del contributo da ciascuno dei suoi figli che hanno dato un DAO per il Target T. Quindi, il campo Path Control aggregato ha i bit attivi impostati come: 10011100b.

5. Il Nodo N distribuisce poi i bit Path Control aggregati tra i suoi genitori P1, P2, P3 e P4 al fine di preparare i messaggi DAO.

6. P1 e P2 sono idonei a ricevere bit attivi dal sottocampo più preferito (11000000b). Quei bit sono 10000000b nel campo Path Control aggregato. Il Nodo N deve impostare il bit a uno solo dei due genitori. In questo caso, al Nodo P1 viene allocato il bit e ottiene il campo Path Control 10000000b per il suo DAO. Non ci sono bit rimasti da allocare al Nodo P2; quindi, il Nodo P2 avrebbe un campo Path Control di 00000000b e un DAO non può essere generato verso il Nodo P2 poiché non ci sono bit attivi.

7. Il secondo sottocampo più preferito (00110000b) ha i bit attivi 00010000b. Il Nodo N ha mappato P3 a questo sottocampo. Il Nodo N può allocare il bit attivo a P3, costruendo un DAO per P3 contenente il Target T con un Path Control di 00010000b.

8. Il terzo sottocampo più preferito (00001100b) ha i bit attivi 00001100b. Il Nodo N ha mappato P4 a questo sottocampo. Il Nodo N può allocare entrambi i bit a P4, costruendo un DAO per P4 contenente il Target T con un Path Control di 00001100b.

9. Il sottocampo meno preferito (00000011b) non ha bit attivi. Se ci fossero stati bit attivi, quei bit sarebbero stati aggiunti al campo Path Control del DAO costruito per P4.

10. Il processo di popolamento dei messaggi DAO destinati a P1, P2, P3, P4 con altri target (diversi da T) procede secondo i campi Path Control aggregati raccolti per quei target.

9.10. Messaggi Multicast Destination Advertisement

Un caso speciale di operazione DAO, distinto dall'operazione DAO unicast, è l'operazione DAO multicast che può essere utilizzata per popolare le voci della tabella di instradamento '1-hop'.

1. Un nodo PUÒ inviare in multicast un messaggio DAO all'indirizzo multicast all-RPL-nodes di ambito link-local.

2. Un messaggio DAO multicast DEVE essere utilizzato solo per annunciare informazioni sul nodo stesso, cioè, prefissi direttamente connessi a o posseduti dal nodo, come un gruppo multicast a cui il nodo è iscritto o un indirizzo globale posseduto dal nodo.

3. Un messaggio DAO multicast NON DEVE essere utilizzato per inoltrare informazioni di connettività apprese (ad esempio, attraverso DAO unicast) da un altro nodo.

4. Un nodo NON DEVE eseguire alcuna altra elaborazione correlata al DAO su un messaggio DAO multicast ricevuto; in particolare, un nodo NON DEVE eseguire le azioni di un genitore DAO alla ricezione di un DAO multicast.

• Il DAO multicast può essere utilizzato per abilitare la comunicazione P2P diretta, senza bisogno che il DODAG inoltri i pacchetti.