3. Panoramica del protocollo

Lo scopo di questa sezione è descrivere RPL nello spirito della [RFC4101]. I dettagli del protocollo possono essere trovati nelle sezioni successive.

3.1. Topologie

Questa sezione descrive le topologie RPL di base che possono essere formate e le regole con cui vengono costruite, ovvero le regole che governano la formazione del DODAG.

3.1.1. Costruzione delle topologie

Le LLN, come le reti radio, non hanno tipicamente topologie predefinite, ad esempio quelle imposte da cavi punto-punto, quindi RPL deve scoprire i collegamenti e quindi selezionare i peer con parsimonia.

In molti casi, poiché gli intervalli di livello 2 si sovrappongono solo parzialmente, RPL forma topologie di rete non transitive / Non-Broadcast Multi-Access (NBMA) su cui calcola le rotte.

Le rotte RPL sono ottimizzate per il traffico verso o da una o più radici che fungono da sink per la topologia. Di conseguenza, RPL organizza una topologia come un grafo aciclico diretto (DAG) partizionato in uno o più DAG orientati alla destinazione (DODAG), un DODAG per sink. Se il DAG ha più radici, si prevede che le radici siano federate da un backbone comune, come un collegamento di transito.

3.1.2. Identificatori RPL

RPL utilizza quattro valori per identificare e mantenere una topologia:

• Il primo è un RPLInstanceID. Un RPLInstanceID identifica un insieme di uno o più DAG orientati alla destinazione (DODAG). Una rete può avere più RPLInstanceID, ciascuno dei quali definisce un insieme indipendente di DODAG, che possono essere ottimizzati per diverse funzioni obiettivo (OF) e/o applicazioni. L'insieme di DODAG identificati da un RPLInstanceID è chiamato istanza RPL. Tutti i DODAG nella stessa istanza RPL utilizzano la stessa OF.

• Il secondo è un DODAGID. L'ambito di un DODAGID è un'istanza RPL. La combinazione di RPLInstanceID e DODAGID identifica univocamente un singolo DODAG nella rete. Un'istanza RPL può avere più DODAG, ciascuno dei quali ha un DODAGID univoco.

• Il terzo è un DODAGVersionNumber. L'ambito di un DODAGVersionNumber è un DODAG. Un DODAG viene talvolta ricostruito dalla radice DODAG, incrementando il DODAGVersionNumber. La combinazione di RPLInstanceID, DODAGID e DODAGVersionNumber identifica univocamente una versione DODAG.

• Il quarto è il rango (Rank). L'ambito del rango è una versione DODAG. Il rango stabilisce un ordine parziale su una versione DODAG, definendo le posizioni dei singoli nodi rispetto alla radice DODAG.

3.1.3. Istanze, DODAG e versioni DODAG

Un'istanza RPL contiene una o più radici DODAG. Un'istanza RPL può fornire rotte verso determinati prefissi di destinazione, raggiungibili tramite le radici DODAG o percorsi alternativi all'interno del DODAG. Queste radici possono operare in modo indipendente o possono coordinarsi su una rete che non è necessariamente vincolata come una LLN.

Un'istanza RPL può comprendere:

• un singolo DODAG con una singola radice

  • Ad esempio, un DODAG ottimizzato per ridurre al minimo la latenza radicato in un singolo controller di illuminazione centralizzato in un'applicazione di domotica.

• più DODAG non coordinati con radici indipendenti (DODAGID diversi)

  • Ad esempio, più punti di raccolta dati in un'applicazione di raccolta dati urbana che non dispongono di connettività adeguata per coordinarsi tra loro o che utilizzano la formazione di più DODAG come mezzo per partizionare dinamicamente e autonomamente la rete.

• un singolo DODAG con una radice virtuale che coordina i sink LLN (con lo stesso DODAGID) su una rete backbone.

  • Ad esempio, più router di confine che operano con un collegamento di transito affidabile, ad esempio, a supporto di un'applicazione IPv6 Low-Power Wireless Personal Area Network (6LoWPAN), che sono in grado di agire come interfacce logicamente equivalenti al sink dello stesso DODAG.

• una combinazione di quanto sopra adatta a un determinato scenario applicativo.

Ogni pacchetto RPL è associato a un particolare RPLInstanceID (vedere la Sezione 11.2) e, quindi, a un'istanza RPL (Sezione 5). Il provisioning o la scoperta automatizzata di una mappatura tra un RPLInstanceID e un tipo o servizio di traffico applicativo è fuori dall'ambito di questa specifica (da definire in future specifiche di accompagnamento).

La Figura 1 mostra un esempio di un'istanza RPL comprendente tre DODAG con radici DODAG R1, R2 e R3. Ognuna di queste radici DODAG pubblicizza lo stesso RPLInstanceID. Le linee raffigurano la connettività tra genitori e figli.

La Figura 2 mostra come un incremento di DODAGVersionNumber porti a una nuova versione DODAG. Questa rappresentazione illustra un incremento di DODAGVersionNumber che si traduce in una diversa topologia DODAG. Si noti che una nuova versione DODAG non implica sempre una diversa topologia DODAG. Per accogliere determinate modifiche alla topologia è necessaria una nuova versione DODAG, come descritto più avanti in questa specifica.

Negli esempi seguenti, si noti che le strutture ad albero sono raffigurate per semplicità, sebbene la struttura DODAG consenta a ciascun nodo di avere più genitori quando la connettività lo supporta.

     +----------------------------------------------------------------+
     |                                                                |
     | +--------------+                                               |
     | |              |                                               |
     | |     (R1)     |            (R2)                   (R3)        |
     | |     /  \     |            /| \                  / |  \       |
     | |    /    \    |           / |  \                /  |   \      |
     | |  (A)    (B)  |         (C) |  (D)     ...    (F) (G)  (H)    |
     | |  /|\     |\  |         /   | / |\             |\  |    |     |
     | | : : :    : : |        :   (E)  : :            :  `:    :     |
     | |              |            / \                                |
     | +--------------+           :   :                               |
     |      DODAG                                                     |
     |                                                                |
     +----------------------------------------------------------------+
                                Istanza RPL

                          Figura 1: Istanza RPL

            +----------------+                +----------------+
            |                |                |                |
            |      (R1)      |                |      (R1)      |
            |      /  \      |                |      /         |
            |     /    \     |                |     /          |
            |   (A)    (B)   |         \      |   (A)          |
            |   /|\   / |\   |    ------\     |   /|\          |
            |  : : (C)  : :  |           \    |  : : (C)       |
            |                |           /    |        \       |
            |                |    ------/     |         \      |
            |                |         /      |         (B)    |
            |                |                |          |\    |
            |                |                |          : :   |
            |                |                |                |
            +----------------+                +----------------+
                Versione N                       Versione N+1

                          Figura 2: Versione DODAG

3.2. Rotte verso l'alto e costruzione DODAG

RPL fornisce rotte verso l'alto (Up) verso le radici DODAG, formando un DODAG ottimizzato secondo una funzione obiettivo (OF). I nodi RPL costruiscono e mantengono questi DODAG tramite messaggi DODAG Information Object (DIO).

3.2.1. Funzione obiettivo (OF)

La funzione obiettivo (OF) definisce come i nodi RPL selezionano e ottimizzano le rotte all'interno di un'istanza RPL. L'OF è identificata da un punto di codice obiettivo (OCP) all'interno dell'opzione di configurazione DIO. Un'OF definisce come i nodi traducono una o più metriche e vincoli, che sono a loro volta definiti in [RFC6551], in un valore chiamato rango (Rank), che approssima la distanza del nodo da una radice DODAG. Un'OF definisce anche come i nodi selezionano i genitori. Ulteriori dettagli possono essere trovati nella Sezione 14, [RFC6551], [RFC6552] e nelle relative specifiche di accompagnamento.

3.2.2. Riparazione DODAG

Una radice DODAG istituisce un'operazione di riparazione globale incrementando il DODAGVersionNumber. Questo avvia una nuova versione DODAG. I nodi nella nuova versione DODAG possono scegliere una nuova posizione il cui rango non è vincolato dal loro rango all'interno della vecchia versione DODAG.

RPL supporta anche meccanismi che possono essere utilizzati per la riparazione locale all'interno della versione DODAG. Il messaggio DIO specifica i parametri necessari configurati e controllati dalla policy alla radice DODAG.

3.2.3. Sicurezza

RPL supporta la riservatezza e l'integrità dei messaggi. È progettato in modo tale che i meccanismi a livello di collegamento possano essere utilizzati quando disponibili e appropriati; tuttavia, in loro assenza, RPL può utilizzare i propri meccanismi. RPL ha tre modalità di sicurezza di base.

Nella prima, chiamata "non protetta", i messaggi di controllo RPL vengono inviati senza alcun meccanismo di sicurezza aggiuntivo. La modalità non protetta non implica che la rete RPL non sia sicura: potrebbe utilizzare altre primitive di sicurezza presenti (ad esempio, sicurezza a livello di collegamento) per soddisfare i requisiti di sicurezza dell'applicazione.

Nella seconda, chiamata "preinstallata", i nodi che si uniscono a un'istanza RPL hanno chiavi preinstallate che consentono loro di elaborare e generare messaggi RPL protetti.

La terza modalità è chiamata "autenticata". In modalità autenticata, i nodi hanno chiavi preinstallate come nella modalità preinstallata, ma la chiave preinstallata può essere utilizzata solo per unirsi a un'istanza RPL come foglia. L'unione a un'istanza RPL autenticata come router richiede l'ottenimento di una chiave da un'autorità di autenticazione. Il processo mediante il quale viene ottenuta questa chiave è fuori dall'ambito di questa specifica. Si noti che questa specifica da sola non fornisce dettagli sufficienti affinché un'implementazione RPL operi in modo sicuro in modalità autenticata. Affinché un'implementazione RPL operi in modo sicuro in modalità autenticata, è necessario che una futura specifica di accompagnamento dettagli i meccanismi mediante i quali un nodo ottiene/richiede il materiale di autenticazione (ad esempio, chiave, certificato) e determini da dove tale materiale debba essere ottenuto. Vedere anche la Sezione 10.3.

3.2.4. DODAG a terra e fluttuanti

I DODAG possono essere a terra o fluttuanti: la radice DODAG pubblicizza quale sia il caso. Un DODAG a terra offre connettività agli host necessari per soddisfare l'obiettivo definito dall'applicazione. Un DODAG fluttuante non dovrebbe soddisfare l'obiettivo; nella maggior parte dei casi, fornisce solo rotte ai nodi all'interno del DODAG. I DODAG fluttuanti possono essere utilizzati, ad esempio, per preservare l'interconnettività durante la riparazione.

3.2.5. DODAG locali

I nodi RPL possono ottimizzare le rotte verso una destinazione all'interno di una LLN formando un DODAG locale la cui radice DODAG è la destinazione desiderata. A differenza dei DAG globali, che possono essere costituiti da più DODAG, i DAG locali hanno uno e un solo DODAG e quindi una radice DODAG. I DODAG locali possono essere costruiti su richiesta.

3.2.6. Preferenza amministrativa

Un'implementazione/distribuzione può specificare che alcune radici DODAG dovrebbero essere utilizzate rispetto ad altre tramite una preferenza amministrativa. La preferenza amministrativa offre un modo per controllare il traffico e progettare la formazione del DODAG al fine di supportare meglio i requisiti o le esigenze dell'applicazione.

3.2.7. Convalida del percorso dati e rilevamento dei cicli

La natura a bassa potenza e con perdite delle LLN motiva l'uso da parte di RPL del rilevamento dei cicli su richiesta utilizzando pacchetti di dati. Poiché il traffico dati può essere poco frequente, mantenere una topologia di instradamento costantemente aggiornata con la topologia fisica può sprecare energia. Le LLN tipiche mostrano variazioni nella connettività fisica che sono transitorie e innocue per il traffico, ma che sarebbe costoso tracciare da vicino dal piano di controllo. Le modifiche transitorie e poco frequenti nella connettività non devono essere affrontate da RPL finché non ci sono dati da inviare. Questo aspetto della progettazione di RPL trae spunto dai protocolli LLN esistenti e altamente utilizzati, nonché da ampie prove sperimentali e di distribuzione sulla sua efficacia.

Le informazioni sul pacchetto RPL che vengono trasportate con i pacchetti di dati includono il rango del trasmettitore. Un'incoerenza tra la decisione di instradamento per un pacchetto (verso l'alto o verso il basso) e la relazione di rango tra i due nodi indica un possibile ciclo. Alla ricezione di tale pacchetto, un nodo istituisce un'operazione di riparazione locale.

Ad esempio, se un nodo riceve un pacchetto contrassegnato come in movimento nella direzione verso l'alto e se quel pacchetto registra che il trasmettitore è di un rango inferiore (minore) rispetto al nodo ricevente, allora il nodo ricevente è in grado di concludere che il pacchetto non è progredito nella direzione verso l'alto e che il DODAG è incoerente.

3.2.8. Funzionamento dell'algoritmo distribuito

Una panoramica di alto livello dell'algoritmo distribuito, che costruisce il DODAG, è la seguente:

• Alcuni nodi sono configurati per essere radici DODAG, con configurazioni DODAG associate.

• I nodi pubblicizzano la loro presenza, affiliazione con un DODAG, costo di instradamento e metriche correlate inviando messaggi DIO multicast link-local a tutti i nodi RPL (all-RPL-nodes).

• I nodi ascoltano i DIO e utilizzano le loro informazioni per unirsi a un nuovo DODAG (selezionando così i genitori DODAG) o per mantenere un DODAG esistente, secondo la funzione obiettivo specificata e il rango dei loro vicini.

• I nodi forniscono voci della tabella di instradamento, per le destinazioni specificate dal messaggio DIO, tramite i loro genitori DODAG nella versione DODAG. I nodi che decidono di unirsi a un DODAG possono fornire uno o più genitori DODAG come hop successivo per la rotta predefinita e un numero di altre rotte esterne per l'istanza associata.

3.3. Rotte verso il basso e annuncio di destinazione

RPL utilizza messaggi Destination Advertisement Object (DAO) per stabilire rotte verso il basso (Downward). I messaggi DAO sono una funzionalità opzionale per le applicazioni che richiedono traffico punto-multipunto (P2MP) o punto-punto (P2P). RPL supporta due modalità di traffico verso il basso: memorizzazione (completamente stateful) o non memorizzazione (completamente source routed); vedere la Sezione 9. Qualsiasi istanza RPL data è o di memorizzazione o di non memorizzazione. In entrambi i casi, i pacchetti P2P viaggiano verso l'alto verso una radice DODAG e poi verso il basso verso la destinazione finale (a meno che la destinazione non sia sulla rotta verso l'alto). Nel caso di non memorizzazione, il pacchetto viaggerà fino a una radice DODAG prima di viaggiare verso il basso. Nel caso di memorizzazione, il pacchetto può essere diretto verso il basso verso la destinazione da un antenato comune della sorgente e della destinazione prima di raggiungere una radice DODAG.

Al momento della stesura di questa specifica, non si prevede che alcuna implementazione supporti entrambe le modalità di funzionamento di memorizzazione e non memorizzazione. Si prevede che la maggior parte delle implementazioni non supporti alcuna rotta verso il basso, solo la modalità non memorizzazione o solo la modalità memorizzazione. Altre modalità di funzionamento, come un mix ibrido di modalità di memorizzazione e non memorizzazione, sono fuori dall'ambito di questa specifica e possono essere descritte in altre specifiche di accompagnamento.

Questa specifica descrive una modalità operativa di base a supporto del traffico P2P. Si noti che soluzioni P2P più ottimizzate possono essere descritte in specifiche di accompagnamento.

3.4. Scoperta rotte DODAG locali

Facoltativamente, una rete RPL può supportare la scoperta su richiesta di DODAG verso destinazioni specifiche all'interno di una LLN. Tali DODAG locali si comportano in modo leggermente diverso dai DODAG globali: sono definiti univocamente dalla combinazione di DODAGID e RPLInstanceID. L'RPLInstanceID indica se un DODAG è un DODAG locale.

3.5. Proprietà del rango

Il rango di un nodo è una rappresentazione scalare della posizione di quel nodo all'interno di una versione DODAG. Il rango viene utilizzato per evitare e rilevare cicli e, in quanto tale, deve dimostrare determinate proprietà. Il calcolo esatto del rango è lasciato alla funzione obiettivo. Anche se il calcolo specifico del rango è lasciato alla funzione obiettivo, il rango deve implementare proprietà generiche indipendentemente dalla funzione obiettivo.

In particolare, il rango dei nodi deve diminuire in modo monotono man mano che la versione DODAG viene seguita verso la destinazione DODAG. A tal proposito, il rango può essere considerato una rappresentazione scalare della posizione o del raggio di un nodo all'interno di una versione DODAG.

I dettagli su come la funzione obiettivo calcola il rango sono fuori dall'ambito di questa specifica, sebbene tale calcolo possa dipendere, ad esempio, dai genitori, dalle metriche di collegamento, dalle metriche del nodo e dalla configurazione e dalle policy del nodo. Vedere la Sezione 14 per ulteriori informazioni.

Il rango non è un costo del percorso, sebbene il suo valore possa essere derivato e influenzato dalle metriche del percorso. Il rango ha proprietà proprie che non sono necessariamente quelle di tutte le metriche:

Tipo: : Il rango è un valore numerico astratto.

Funzione: : Il rango è l'espressione di una posizione relativa all'interno di una versione DODAG rispetto ai vicini e non è necessariamente una buona indicazione o un'espressione corretta di una distanza o di un costo del percorso verso la radice.

Stabilità: : La stabilità del rango determina la stabilità della topologia di instradamento. Si RACCOMANDA un certo smorzamento o filtraggio per mantenere stabile la topologia; quindi, il rango non cambia necessariamente velocemente come farebbero alcune metriche di collegamento o di nodo. Una nuova versione DODAG sarebbe una buona opportunità per riconciliare le discrepanze che potrebbero formarsi nel tempo tra metriche e ranghi all'interno di una versione DODAG.

Proprietà: : Il rango viene incrementato in modo rigorosamente monotono e può essere utilizzato per convalidare una progressione da o verso la radice. Una metrica, come la larghezza di banda o il jitter, non mostra necessariamente questa proprietà.

Astratto: : Il rango non ha un'unità fisica, ma piuttosto un intervallo di incremento per hop, in cui l'assegnazione di ciascun incremento deve essere determinata dalla funzione obiettivo.

Il valore del rango alimenta la selezione del genitore DODAG, secondo la strategia di evitamento dei cicli RPL. Una volta aggiunto un genitore e pubblicizzato un valore di rango per il nodo all'interno del DODAG, le ulteriori opzioni del nodo per quanto riguarda la selezione del genitore DODAG e il movimento all'interno del DODAG sono limitate a favore dell'evitamento dei cicli.

3.5.1. Confronto rango (DAGRank())

Il rango può essere pensato come un numero a virgola fissa, in cui la posizione del punto radice tra la parte intera e la parte frazionaria è determinata da MinHopRankIncrease. MinHopRankIncrease è l'aumento minimo del rango tra un nodo e uno qualsiasi dei suoi genitori DODAG. Una radice DODAG fornisce MinHopRankIncrease. MinHopRankIncrease crea un compromesso tra la precisione del costo dell'hop e il numero massimo di hop che una rete può supportare. Un MinHopRankIncrease molto grande, ad esempio, consente una caratterizzazione precisa dell'effetto di un dato hop sul rango ma non può supportare molti hop.

Quando una funzione obiettivo calcola il rango, la funzione obiettivo opera sull'intera quantità di rango (cioè 16 bit). Quando il rango viene confrontato, ad esempio per la determinazione delle relazioni con i genitori o il rilevamento dei cicli, deve essere utilizzata la parte intera del rango. La parte intera del rango viene calcolata dalla macro DAGRank() come segue, dove floor(x) è la funzione che valuta l'intero più grande minore o uguale a x:

           DAGRank(rank) = floor(rank/MinHopRankIncrease)

Ad esempio, se una quantità di rango a 16 bit è decimale 27 e il MinHopRankIncrease è decimale 16, allora DAGRank(27) = floor(1.6875) = 1. La parte intera del rango è 1 e la parte frazionaria è 11/16.

Seguendo le convenzioni in questo documento, l'utilizzo della macro DAGRank(node) può essere interpretato come DAGRank(node.rank), dove node.rank è il valore di rango mantenuto dal nodo.

Un nodo A ha un rango inferiore al rango di un nodo B se DAGRank(A) è inferiore a DAGRank(B).

Un nodo A ha un rango uguale al rango di un nodo B se DAGRank(A) è uguale a DAGRank(B).

Un nodo A ha un rango maggiore del rango di un nodo B se DAGRank(A) è maggiore di DAGRank(B).

3.5.2. Relazioni di rango

I calcoli del rango mantengono le seguenti proprietà per qualsiasi nodo M e N che sono vicini nella LLN:

DAGRank(M) è minore di DAGRank(N):

: In questo caso, la posizione di M è più vicina alla radice DODAG rispetto alla posizione di N. Il nodo M può tranquillamente essere un genitore DODAG per il nodo N senza rischio di creare un ciclo. Inoltre, per un nodo N, tutti i genitori nel set di genitori DODAG devono essere di un rango inferiore a DAGRank(N). In altre parole, il rango presentato da un nodo N DEVE essere maggiore di quello presentato da uno qualsiasi dei suoi genitori.

DAGRank(M) è uguale a DAGRank(N):

: In questo caso, le posizioni di M e N all'interno del DODAG e rispetto alla radice DODAG sono simili o identiche. L'instradamento attraverso un nodo con rango uguale può causare un ciclo di instradamento (cioè, se anche quel nodo sceglie di instradare attraverso un nodo con rango uguale).

DAGRank(M) è maggiore di DAGRank(N):

: In questo caso, la posizione di M è più lontana dalla radice DODAG rispetto alla posizione di N. Inoltre, il nodo M potrebbe in effetti trovarsi nel sotto-DODAG del nodo N. Se il nodo N seleziona il nodo M come genitore DODAG, c'è il rischio di creare un ciclo.

Come esempio, il rango potrebbe essere calcolato in modo tale da tracciare da vicino ETX (conteggio di trasmissione previsto, una metrica di instradamento abbastanza comune utilizzata nelle LLN e definita in [RFC6551]) quando la metrica che una funzione obiettivo minimizza è ETX, o latenza, o in un modo più complicato appropriato alla funzione obiettivo utilizzata all'interno del DODAG.

3.6. Metriche di instradamento e vincoli utilizzati da RPL

Le metriche di instradamento vengono utilizzate dai protocolli di instradamento per calcolare i percorsi più brevi. I protocolli gateway interni (IGP) come IS-IS ([RFC5120]) e OSPF ([RFC4915]) utilizzano metriche di collegamento statiche. Tali metriche di collegamento possono semplicemente riflettere la larghezza di banda o possono anche essere calcolate secondo una funzione polinomiale di diverse metriche che definiscono diverse caratteristiche di collegamento. Alcuni protocolli di instradamento supportano più di una metrica: nella stragrande maggioranza dei casi, viene utilizzata una metrica per (sotto)topologia. Meno spesso, una seconda metrica può essere utilizzata come spareggio in presenza di percorsi multipli a costo uguale (ECMP). L'ottimizzazione di più metriche è nota come un problema NP-completo ed è talvolta supportata da un motore di calcolo del percorso centralizzato.

Al contrario, le LLN richiedono il supporto di metriche sia statiche che dinamiche. Inoltre, sono richieste metriche sia di collegamento che di nodo. Nel caso di RPL, è praticamente impossibile definire una metrica, o anche una metrica composita, che soddisfi tutti i casi d'uso.

Inoltre, RPL supporta l'instradamento basato su vincoli in cui i vincoli possono essere applicati sia ai collegamenti che ai nodi. Se un collegamento o un nodo non soddisfa un vincolo richiesto, viene "potato" dall'insieme di vicini candidati, portando così a un percorso più breve vincolato.

Una funzione obiettivo specifica gli obiettivi utilizzati per calcolare il percorso (vincolato). Inoltre, i nodi sono configurati per supportare un insieme di metriche e vincoli e selezionare i loro genitori nel DODAG in base alle metriche e ai vincoli pubblicizzati nei messaggi DIO. Le metriche upstream e downstream possono essere unite o pubblicizzate separatamente a seconda dell'OF e delle metriche. Quando vengono pubblicizzate separatamente, può accadere che l'insieme dei genitori DIO sia diverso dall'insieme dei genitori DAO (un genitore DAO è un nodo a cui vengono inviati messaggi DAO unicast). Tuttavia, tutti sono genitori DODAG per quanto riguarda le regole per il calcolo del rango.

La funzione obiettivo è disaccoppiata dalle metriche di instradamento e dai vincoli utilizzati da RPL. Mentre l'OF detta regole come la selezione del genitore DODAG, il bilanciamento del carico e così via, l'insieme di metriche e/o vincoli utilizzati, e quindi quelli che determinano il percorso preferito, si basano sulle informazioni trasportate all'interno dell'opzione contenitore DAG nei messaggi DIO.

L'insieme di vincoli e metriche di collegamento/nodo supportati è specificato in [RFC6551].

Esempio 1: Percorso più breve: percorso che offre il ritardo end-to-end più breve.

Esempio 2: Percorso vincolato più breve: il percorso che non attraversa alcun nodo alimentato a batteria e che ottimizza l'affidabilità del percorso.

3.7. Evitamento dei cicli

RPL cerca di evitare di creare cicli quando subisce modifiche alla topologia e include meccanismi di convalida del percorso dati basati sul rango per rilevare i cicli quando si verificano (vedere la Sezione 11 per maggiori dettagli). In pratica, ciò significa che RPL non garantisce né la selezione del percorso privo di cicli né tempi di convergenza del ritardo stretti, ma può rilevare e riparare un ciclo non appena viene utilizzato. RPL utilizza questo rilevamento dei cicli per garantire che i pacchetti facciano progressi in avanti all'interno della versione DODAG e attivino le riparazioni quando necessario.

3.7.1. Avidità e instabilità

Un nodo è avido se tenta di spostarsi più in profondità (aumentare il rango) nella versione DODAG al fine di aumentare la dimensione dell'insieme dei genitori o migliorare qualche altra metrica. Una volta che un nodo si è unito a una versione DODAG, RPL non consente determinati comportamenti, inclusa l'avidità, al fine di prevenire le conseguenti instabilità nella versione DODAG.

Supponiamo che un nodo sia disposto a ricevere ed elaborare un messaggio DIO da un nodo nel proprio sotto-DODAG e, in generale, da un nodo più profondo di se stesso. In questo caso, esiste la possibilità che venga creato un ciclo di feedback, in cui due o più nodi continuano a provare a muoversi nella versione DODAG mentre tentano di ottimizzare l'uno contro l'altro. In alcuni casi, ciò risulterà in instabilità. È per questo motivo che RPL limita i casi in cui un nodo può elaborare messaggi DIO da nodi più profondi a qualche forma di riparazione locale. Questo approccio crea un "orizzonte degli eventi", per cui un nodo non può essere influenzato oltre un certo limite in un'instabilità dall'azione di nodi che potrebbero trovarsi nel proprio sotto-DODAG.

3.7.1.1. Esempio: Selezione del genitore avida e instabilità

         (A)                    (A)                    (A)
          |\                     |\                     |\
          | `-----.              | `-----.              | `-----.
          |        \             |        \             |        \
         (B)       (C)          (B)        \            |        (C)
                                  \        |            |        /
                                   `-----. |            | .-----'
                                          \|            |/
                                          (C)          (B)

              -1-                    -2-                    -3-

                  Figura 3: Selezione del genitore DODAG avida

La Figura 3 mostra un DODAG in tre diverse configurazioni. Un collegamento utilizzabile tra (B) e (C) esiste in tutte e tre le configurazioni. Nella Figura 3-1, il nodo (A) è un genitore DODAG per i nodi (B) e (C). Nella Figura 3-2, il nodo (A) è un genitore DODAG per i nodi (B) e (C) e il nodo (B) è anche un genitore DODAG per il nodo (C). Nella Figura 3-3, il nodo (A) è un genitore DODAG per i nodi (B) e (C) e il nodo (C) è anche un genitore DODAG per il nodo (B).

Se un nodo RPL è troppo avido, in quanto tenta di ottimizzare per un numero aggiuntivo di genitori oltre ai suoi genitori più preferiti, può verificarsi un'instabilità. Considerare il DODAG illustrato nella Figura 3-1. In questo esempio, i nodi (B) e (C) potrebbero preferire il nodo (A) come genitore DODAG, ma considereremo il caso in cui operano in condizioni di avidità che cercheranno di ottimizzare per due genitori.

• Sia la Figura 3-1 la condizione iniziale.

• Supponiamo che il nodo (C) sia in grado prima di lasciare il DODAG e di riunirsi a un rango inferiore, prendendo sia i nodi (A) che (B) come genitori DODAG come illustrato nella Figura 3-2. Ora il nodo (C) è più profondo di entrambi i nodi (A) e (B) e il nodo (C) è soddisfatto di avere due genitori DODAG.

• Supponiamo che il nodo (B), nella sua avidità, sia disposto a ricevere ed elaborare un messaggio DIO dal nodo (C) (contro le regole di RPL), e quindi il nodo (B) lascia il DODAG e si riunisce a un rango inferiore, prendendo sia i nodi (A) che (C) come genitori DODAG. Ora il nodo (B) è più profondo di entrambi i nodi (A) e (C) ed è soddisfatto con due genitori DAG.

• Quindi, il nodo (C), poiché è anch'esso avido, lascerà e si riunirà più in profondità, per ottenere di nuovo due genitori e avere un rango inferiore a entrambi.

• Successivamente, il nodo (B) lascerà di nuovo e si riunirà più in profondità, per ottenere di nuovo due genitori.

• Di nuovo, il nodo (C) lascia e si riunisce più in profondità.

• Il processo si ripeterà e il DODAG oscillerà tra la Figura 3-2 e la Figura 3-3 finché i nodi non contano fino all'infinito e riavviano il ciclo di nuovo.

• Questo ciclo può essere evitato tramite meccanismi in RPL:

  • I nodi (B) e (C) rimangono a un rango sufficiente per attaccarsi al loro genitore più preferito (A) e non cercano genitori alternativi più profondi (peggiori) (i nodi non sono avidi).

  • I nodi (B) e (C) non elaborano messaggi DIO da nodi più profondi di se stessi (poiché tali nodi sono forse nei propri sotto-DODAG).

Questi meccanismi sono ulteriormente descritti nella Sezione 8.2.2.4.

3.7.2. Cicli DODAG

Un ciclo DODAG può verificarsi quando un nodo si stacca dal DODAG e si riattacca a un dispositivo nel suo precedente sotto-DODAG. In particolare, ciò può accadere quando i messaggi DIO vengono persi. L'uso rigoroso del DODAGVersionNumber può eliminare questo tipo di ciclo, ma questo tipo di ciclo può essere eventualmente riscontrato quando si utilizzano alcuni meccanismi di riparazione locale.

Ad esempio, considerare il meccanismo di riparazione locale che consente a un nodo di staccarsi dal DODAG, pubblicizzare un rango di INFINITE_RANK (al fine di avvelenare le sue rotte / informare il suo sotto-DODAG) e quindi riattaccarsi al DODAG. In alcuni di questi casi, il nodo può riattaccarsi al proprio precedente sotto-DODAG, causando un ciclo DODAG, perché l'avvelenamento potrebbe fallire se gli annunci INFINITE_RANK vengono persi nell'ambiente LLN. (In questo caso, i meccanismi di convalida del percorso dati basati sul rango rileverebbero e attiverebbero infine la correzione del ciclo).

3.7.3. Cicli DAO

Un ciclo DAO può verificarsi quando il genitore ha una rotta installata dopo aver ricevuto ed elaborato un messaggio DAO da un figlio, ma il figlio ha successivamente ripulito lo stato DAO correlato. Questo ciclo si verifica quando un No-Path (un messaggio DAO che invalida un prefisso precedentemente annunciato, vedere la Sezione 6.4.3) è stato perso e persiste finché tutto lo stato non è stato ripulito. RPL include un meccanismo opzionale per confermare i messaggi DAO, che può mitigare l'impatto di un singolo messaggio DAO perso. RPL include meccanismi di rilevamento dei cicli che mitigano l'impatto dei cicli DAO e ne attivano la riparazione. (Vedere la Sezione 11.2.2.3.)