Passa al contenuto principale

16. Riepilogo dei Requisiti per Implementazioni Interoperabili

Questa sezione riassume l'interoperabilità di base e fa riferimento al testo normativo per le implementazioni RPL che operano in una delle tre modalità principali. Ci si aspetta che le implementazioni supportino o nessuna rotta verso il basso, solo modalità Non-Storing, o solo modalità Storing. Una quarta modalità, operazione come foglia, è anche possibile.

Le implementazioni conformi a questa specifica possono contenere diversi sottoinsiemi di capacità a seconda dello scenario applicativo. È importante per l'implementatore supportare un livello di interoperabilità coerente con quello richiesto dallo scenario applicativo. A tal fine, ulteriori indicazioni possono essere fornite oltre questa specifica (ad esempio, come dichiarazioni di applicabilità), ed è inteso che in alcuni casi tali ulteriori indicazioni possono sovrascrivere parti di questa specifica.

16.1. Requisiti Comuni​

In un caso generale, il massimo livello di interoperabilità può essere raggiunto quando tutti i nodi in una LLN RPL cooperano per utilizzare lo stesso MOP, OF, metriche e vincoli, e sono quindi in grado di agire come router RPL. Quando un nodo non è in grado di essere un router RPL, può essere possibile interagire in modo più limitato come foglia RPL.

Tutte le implementazioni RPL devono supportare l'uso delle informazioni sui pacchetti RPL trasportate all'interno dei pacchetti dati (Sezione 11.2). Un tale meccanismo è descritto in [RFC6553].

Le implementazioni RPL dovranno supportare l'uso di Neighbor Unreachability Detection (NUD), o un meccanismo equivalente, per mantenere la raggiungibilità dei nodi RPL vicini (Sezione 8.2.1). Meccanismi alternativi possono essere ottimizzati per le capacità vincolate dell'implementazione, come suggerimenti dal livello di collegamento.

Questa specifica fornisce mezzi per ottenere una PIO e quindi formare un indirizzo IPv6. Quando viene utilizzato tale meccanismo, potrebbe essere necessario eseguire la risoluzione degli indirizzi e il rilevamento degli indirizzi duplicati attraverso un processo esterno, come IPv6 ND [RFC4861] o 6LoWPAN ND [6LOWPAN-ND].

16.2. Operazione come Nodo Foglia RPL (Solo)​

  • Un'implementazione di un nodo foglia (solo) non partecipa mai come router RPL. Le implementazioni interoperabili di nodi foglia si comportano come riassunto nella Sezione 8.5.

  • Il supporto di una particolare codifica MOP non è richiesto, sebbene se il nodo foglia invia messaggi DAO per impostare rotte verso il basso, il nodo foglia dovrebbe farlo in modo coerente con la modalità di operazione indicata dal MOP.

  • Il supporto di una particolare OF non è richiesto.

  • In sintesi, un nodo foglia non emette generalmente messaggi DIO, può emettere messaggi DAO e DIS. Un nodo foglia accetta messaggi DIO sebbene generalmente ignori messaggi DAO e DIS.

16.3. Operazione come Router RPL​

Se non sono disponibili ulteriori indicazioni, allora un'implementazione di router RPL DEVE almeno supportare l'OF0 senza metriche [RFC6552].

Per un funzionamento coerente, un'implementazione di router RPL deve supportare il MOP in uso dal DODAG.

Tutti i router RPL dovranno implementare Trickle [RFC6206].

16.3.1. Supporto per Rotte Verso l'Alto (Solo)​

Un'implementazione di un router RPL che supporta solo rotte verso l'alto supporta quanto segue:

  • Rotte verso l'alto (Sezione 8)

  • Codifica MOP 0 (Sezione 20.3)

  • In sintesi, vengono emessi messaggi DIO e DIS, e i messaggi DAO non vengono emessi. I messaggi DIO e DIS vengono accettati, e i messaggi DAO vengono ignorati.

16.3.2. Supporto per Rotte Verso l'Alto e Rotte Verso il Basso in Modalità Non-Storing​

Un'implementazione di un router RPL che supporta rotte verso l'alto e rotte verso il basso in modalità Non-Storing supporta quanto segue:

  • Rotte verso l'alto (Sezione 8)

  • Rotte verso il basso (Non-Storing) (Sezione 9)

  • Codifica MOP 1 (Sezione 20.3)

  • Traffico verso il basso instradato alla sorgente ([RFC6554])

  • In sintesi, vengono emessi messaggi DIO e DIS, e i messaggi DAO vengono emessi verso la radice del DODAG. I messaggi DIO e DIS vengono accettati, e i messaggi DAO vengono ignorati dai nodi diversi dalle radici del DODAG. Il multicast non è supportato attraverso i mezzi descritti in questa specifica, sebbene possa essere supportato attraverso alcuni mezzi alternativi.

16.3.3. Supporto per Rotte Verso l'Alto e Rotte Verso il Basso in Modalità Storing​

Un'implementazione di un router RPL che supporta rotte verso l'alto e rotte verso il basso in modalità Storing supporta quanto segue:

  • Rotte verso l'alto (Sezione 8)

  • Rotte verso il basso (Storing) (Sezione 9)

  • Codifica MOP 2 (Sezione 20.3)

  • In sintesi, vengono emessi messaggi DIO, DIS e DAO. I messaggi DIO, DIS e DAO vengono accettati. Il multicast non è supportato attraverso i mezzi descritti in questa specifica, sebbene possa essere supportato attraverso alcuni mezzi alternativi.

16.3.3.1. Supporto Opzionale per Schema Multicast Base​

Un'implementazione in modalità Storing può essere migliorata con il supporto multicast base attraverso le seguenti aggiunte:

  • Supporto Multicast Base (Sezione 12)

  • Codifica MOP 3 (Sezione 20.3)

16.4. Elementi per Specifiche Future​

Un certo numero di elementi sono lasciati a specifiche future, inclusi ma non limitati a quanto segue:

  • Come collegare un nodo non-RPL come un host IPv6, ad esempio, per distribuire coerentemente almeno materiale PIO al nodo collegato.

  • Come ottenere materiale di autenticazione in supporto se viene utilizzata la modalità autenticata (Sezione 10.3).

  • Dettagli dell'operazione su più istanze simultanee.

  • Meccanismi di configurazione avanzati, come il provisioning di RPLInstanceID, la parametrizzazione delle Funzioni Obiettivo e parametri per controllare la sicurezza. (Si prevede che tali meccanismi possano estendere il DIO come mezzo per disseminare informazioni attraverso il DODAG).

Ultimo aggiornamento il