5. 6LoWPAN Routing Requirements (Requisiti di routing 6LoWPAN)

Questa sezione definisce un elenco di requisiti per il routing 6LoWPAN. Una proprietà di progettazione importante specifica delle reti a bassa potenza è che i LoWPAN devono supportare più tipi di dispositivi e ruoli, come:

• nodi host che traggono la loro alimentazione da batterie primarie o utilizzano l'energy harvesting (a volte chiamati "nodi a energia limitata")
• nodi host alimentati dalla rete elettrica (un esempio di ciò che chiamiamo "nodi a energia abbondante")
• gateway ad alte prestazioni a energia abbondante (ma non necessariamente alimentati dalla rete elettrica)
• nodi con varie funzionalità (aggregatori di dati, relay, manager/coordinatori locali, ecc.)

A causa di questi diversi tipi di dispositivi e ruoli, i LoWPAN devono considerare i seguenti due attributi principali:

• Conservazione dell'energia: alcuni dispositivi sono alimentati dalla rete elettrica, ma molti sono alimentati a batteria e devono durare diversi mesi fino a pochi anni con una singola batteria AA. Molti dispositivi sono alimentati dalla rete elettrica per la maggior parte del tempo, ma devono ancora funzionare a batteria per periodi possibilmente prolungati (ad esempio, in un cantiere edile prima che l'alimentazione elettrica dell'edificio venga attivata per la prima volta).

• Bassa prestazione: dispositivi minuscoli, dimensioni di memoria ridotte, processori a basse prestazioni, bassa larghezza di banda, tassi di perdita elevati, ecc.

Questi attributi fondamentali dei LoWPAN influenzano la progettazione delle soluzioni di routing. Che le specifiche di routing esistenti siano semplificate e modificate, o che vengano introdotte nuove soluzioni per adattarsi ai requisiti di bassa potenza dei LoWPAN, esse devono soddisfare i requisiti descritti di seguito.

5.1. Support of 6LoWPAN Device Properties (Supporto delle proprietà dei dispositivi 6LoWPAN)

Gli obiettivi generali elencati in questa sezione devono essere soddisfatti dai protocolli di routing 6LoWPAN. L'importanza di ciascun requisito dipende dal tipo di nodo su cui il protocollo è in esecuzione e dal ruolo del nodo. I seguenti requisiti considerano la presenza di nodi alimentati a batteria nei LoWPAN.

[R01] I protocolli di routing 6LoWPAN DOVREBBERO (SHOULD) consentire un'implementazione con dimensioni di codice ridotte e richiedere uno stato di routing basso per adattarsi alla tipica capacità del nodo 6LoWPAN. In generale, la dimensione del codice è limitata dalla dimensione della memoria flash disponibile, e la tabella di routing è limitata dalla dimensione della RAM, possibilmente limitandola a meno di 32 voci.

La dimensione della RAM dei nodi LoWPAN spesso varia tra 4 KB e 10 KB (minimo 2 KB), e la memoria flash del programma consiste normalmente di 48 KB a 128 KB. (Ad esempio, nel mercato attuale, MICAz ha 128 KB di flash programma, 4 KB di EEPROM e 512 KB di ROM flash esterna; TIP700CM ha 48 KB di flash programma, 10 KB di RAM e 1 MB di ROM flash esterna.)

A causa di queste restrizioni hardware, il codice DOVREBBE (SHOULD) rientrare in una dimensione di memoria ridotta -- non più di 48 KB a 128 KB di memoria flash, inclusi almeno alcune decine di KB di dimensione del codice dell'applicazione. (Come osservazione generale, un protocollo di routing di bassa complessità può aiutare a raggiungere l'obiettivo di riduzione del consumo energetico, migliora la robustezza, richiede uno stato di routing inferiore, è più facile da analizzare e può essere meno vulnerabile agli attacchi di sicurezza.)

Inoltre, il funzionamento con quantità limitate di stato di routing (come tabelle di routing ed elenchi di vicini) DOVREBBE (SHOULD) essere mantenuto, poiché alcune dimensioni di memoria tipiche escludono la memorizzazione dello stato di un gran numero di nodi. Ad esempio, le applicazioni di monitoraggio industriale potrebbero dover supportare un massimo di 20 hop [RFC5673]. Le reti di piccole dimensioni possono essere progettate per supportare un numero inferiore di hop. Sebbene la necessità di ciò dipenda fortemente dall'architettura di rete, dovrebbe esistere almeno una modalità operativa che possa funzionare con 32 voci di inoltro o meno.

[R02] I protocolli di routing 6LoWPAN DOVREBBERO (SHOULD) causare un consumo energetico minimo utilizzando efficientemente i pacchetti di controllo (ad esempio, minimizzando il costoso multicast IP, che causa il broadcast del link all'intero LoWPAN) e instradando efficientemente i pacchetti di dati.

Un modo per ottimizzare la durata della batteria consiste nel raggiungere un overhead minimo di messaggi di controllo. Rispetto a funzioni come operazioni computazionali o campionamento di sensori, la comunicazione radio è di gran lunga il fattore dominante del consumo energetico [Doherty]. Il consumo energetico della trasmissione e/o ricezione dipende linearmente dalla lunghezza delle unità di dati e dalla frequenza di trasmissione e ricezione delle unità di dati [Shih].

Il consumo energetico di due controller di radiofrequenza (RF) esemplificativi per nodi a bassa potenza è mostrato in [Hill]. La radio TR1000 consuma 21 mW durante la trasmissione a 0,75 mW e 15 mW durante la ricezione (con una sensibilità del ricevitore di -85 dBm). Il CC1000 consuma 31,6 mW durante la trasmissione a 0,75 mW e 20 mW durante la ricezione (con una sensibilità del ricevitore di -105 dBm). La durata energetica sotto il concetto di una fonte di alimentazione idealizzata è spiegata in [Hill]. Basandosi sull'energia di una batteria AA idealizzata, il CC1000 può trasmettere per circa 4 giorni consecutivi o ricevere per 9 giorni consecutivi. Si noti che la disponibilità per le attività reali dipende dalla frequenza di comunicazione e da altre operazioni a basso ciclo di lavoro, nonché dalla capacità energetica fornita dalla batteria.

In alcuni casi, l'overhead introdotto dal protocollo di routing è elevato. [Doherty] riporta che nel protocollo LEACH utilizzato per il routing gerarchico, i pacchetti di dati e protocollo proposti in [Heinzelman] consumano il 97% dell'energia di trasmissione a una velocità di 100 bit al secondo. Nei casi in cui il requisito di overhead dei pacchetti di controllo non è così impegnativo, i pacchetti di controllo giocano comunque un ruolo importante. Per i dati dei sensori della rete personale wireless a bassa velocità e bassa potenza (LR-WPAN), ZigBee (IEEE 802.15.4) utilizza il routing AODV nella trasmissione dei dati dei sensori, i pacchetti del protocollo di routing consumano circa il 15% dell'energia di trasmissione, mentre il consumo energetico di trasmissione dei pacchetti di dati è di circa l'85% [Doherty]. Pertanto, i protocolli di routing DOVREBBERO (SHOULD) considerare l'utilizzo di meccanismi di routing efficienti e formati di pacchetti di protocollo di scambio semplici.

[R03] I messaggi di controllo del protocollo di routing 6LoWPAN NON DOVREBBERO (SHOULD NOT) superare la dimensione di un singolo frame MAC IEEE 802.15.4 (massimo 127 byte) per evitare i costosi costi di frammentazione e riassemblaggio.

La dimensione massima del pacchetto del livello fisico di un singolo frame IEEE 802.15.4 è di 127 byte [IEEE802.15.4]. Nel caso in cui LLC/SNAP trasporti il tipo di frame Ethernet, un'intestazione IPv6 da 40 byte più un'intestazione UDP richiede 8 byte, e quindi, il payload UDP è di 74 byte. In generale, per mantenere il protocollo semplice ed evitare la frammentazione e il riassemblaggio dei frame, i messaggi di controllo del protocollo di routing 6LoWPAN DOVREBBERO (SHOULD) essere inviati in quantità limitate ed essere il più piccoli possibile.

5.2. Support of 6LoWPAN Link Properties (Supporto delle proprietà dei collegamenti 6LoWPAN)

A causa delle condizioni topologiche dei LoWPAN, i guasti dei collegamenti e i guasti di trasmissione si verificano frequentemente. Può essere necessaria una maggiore affidabilità dei pacchetti o l'utilizzo di trasmissioni di backup aggiuntive. La gestione di condizioni di rete impreviste (come pacchetti di dati o di controllo persi, collegamenti unidirezionali, qualità del collegamento variabile) è fondamentale per progettare protocolli di routing robusti e affidabili. I protocolli di routing non solo devono essere consapevoli di questi tipi di condizioni di rete nella loro progettazione, ma devono anche utilizzare la funzionalità fornita dall'interconnettività 6LoWPAN per garantire che i dati possano essere consegnati in modo affidabile dalla sorgente alla destinazione. I seguenti requisiti considerano le caratteristiche dei collegamenti nei LoWPAN.

[R04] La progettazione dei protocolli di routing per i LoWPAN DEVE (MUST) considerare l'affidabilità del collegamento, il tasso di errore del collegamento, la qualità del collegamento e la stabilità del collegamento per l'ottimizzazione del routing.

I collegamenti wireless a bassa potenza sono intrinsecamente inaffidabili e ci sono molteplici ragioni per la perdita di pacchetti, come:

• Molti dispositivi possono essere in modalità sleep per la maggior parte del tempo, quindi potrebbero non esserci vicini in ascolto quando vengono trasmessi i pacchetti.
• Fattori ambientali come EMI, ostacoli da edifici e infrastrutture, terreno, ecc., possono causare guasti di trasmissione o far diventare i collegamenti simmetrici asimmetrici e viceversa.
• Congestione, in particolare nelle reti di sensori, dove la comunicazione multi-hop e il traffico di routing da molte sorgenti convergenti verso il gateway aumentano la probabilità di congestione attorno ai nodi vicini al gateway [Shelby-6LoWPAN].
• Lo spettro wireless è tipicamente condiviso e richiede un coordinamento tra diverse tecnologie wireless che utilizzano le bande ISM, e le reti che operano in queste bande possono essere influenzate da interferenze di altre reti o dispositivi.

Pertanto, la progettazione dei protocolli di routing 6LoWPAN DEVE (MUST) considerare l'affidabilità del collegamento, il tasso di errore del collegamento, la qualità del collegamento e la stabilità del collegamento per l'ottimizzazione del routing.

[R05] La progettazione dei protocolli di routing per i LoWPAN DEVE (MUST) considerare i collegamenti asimmetrici.

I protocolli di routing 6LoWPAN DEVONO (MUST) supportare collegamenti asimmetrici perché molti collegamenti pratici nei LoWPAN sono asimmetrici (ad esempio, collegamenti tra nodi di rilevamento a bassa potenza e stazioni base a energia abbondante) [Shelby-CoAP]. In tali casi, la selezione dei percorsi di routing DEVE (MUST) gestire i collegamenti asimmetrici.

[R06] I protocolli di routing 6LoWPAN DOVREBBERO (SHOULD) essere robusti alle variazioni dinamiche di perdita nei collegamenti.

I protocolli di routing 6LoWPAN DOVREBBERO (SHOULD) essere robusti alle variazioni di perdita del collegamento per gestire la natura inaffidabile dei collegamenti IEEE 802.15.4. I collegamenti tipici connessi ai nodi LoWPAN potrebbero non essere disponibili tutto il tempo. Le variazioni di perdita del collegamento possono essere dovute a vari fattori come il movimento dei nodi, l'esaurimento dell'alimentazione/batteria, i cicli di sleep, il fading del segnale o la riduzione della potenza del segnale ricevuto e le interferenze, e possono causare la disattivazione dei collegamenti per periodi prolungati. I protocolli di routing DOVREBBERO (SHOULD) gestire le caratteristiche di questi collegamenti in modo adeguato.

[R07] I protocolli di routing 6LoWPAN DOVREBBERO (SHOULD) essere progettati per gestire correttamente le possibili dimensioni dei frame.

In alcuni LoWPAN, la dimensione massima possibile dei pacchetti di controllo è molto limitata (fino a 127 byte in un singolo frame MAC IEEE 802.15.4) perché il livello MAC non ha supporto nativo per la frammentazione e il riassemblaggio.

La dimensione massima del frame significa che piccole intestazioni e basso overhead dei messaggi di stato DEVONO (MUST) essere applicati. I pacchetti di controllo DOVREBBERO (SHOULD) essere abbastanza piccoli da adattarsi in un singolo frame di livello link. Tuttavia, è ancora necessaria flessibilità nella costruzione dei messaggi; il design dei messaggi DEVE (MUST) adattare lo spazio richiesto per le intestazioni IPv6 standard e altre intestazioni (come intestazioni di livello link e intestazioni di livello di adattamento), e DEVE (MUST) anche essere in grado di accogliere le opzioni richieste da altri protocolli di routing e protocolli IETF esistenti.

5.3. Support of 6LoWPAN Characteristics (Supporto delle caratteristiche 6LoWPAN)

Questa sezione considera le caratteristiche fondamentali della rete che possono influenzare la progettazione dei protocolli di routing 6LoWPAN.

[R08] La progettazione dei protocolli di routing 6LoWPAN DOVREBBE (SHOULD) tenere conto dei modelli di traffico, della densità della rete, dei possibili ruoli o funzioni dei nodi e dell'uso e del numero di diverse configurazioni di rete.

I protocolli di routing 6LoWPAN DOVREBBERO (SHOULD) essere in grado di gestire una varietà di topologie LoWPAN diverse, come:

• Modelli di traffico punto-punto, punto-multipunto, multipunto-punto o multipunto-multipunto
• Traffico di comunicazione concentrato in un singolo punto (ad esempio, gateway)
• Densità variabile di host e router, rapporto router-host variabile
• La funzionalità del router può essere diversa dalla funzionalità dell'host o può essere sullo stesso nodo
• Diverse funzionalità dei nodi, come nodi vincolati e non vincolati, o nodi che svolgono funzioni come routing, relaying, aggregazione, ecc.
• Diverse configurazioni di rete, come peer-to-peer, stella, reti mesh
• Formazione di rete dinamica e cambiamenti topologici durante il periodo post-distribuzione (runtime)
• Dimensione della rete variabile; la dimensione delle reti può anche essere molto diversa, da reti con pochi nodi a diverse centinaia o più nodi
• La partizione della rete può verificarsi e deve essere gestita

[R09] La metrica utilizzata dai protocolli di routing 6LoWPAN DOVREBBE (SHOULD) fornire considerazione per gli effetti combinati degli attributi di nodo e collegamento.

È importante incorporare la qualità del collegamento e gli attributi del nodo nelle metriche di routing per minimizzare il consumo energetico e garantire una consegna riuscita. Ad esempio, il percorso più breve con il numero minimo di hop potrebbe non essere il percorso più efficiente dal punto di vista energetico perché potrebbe passare attraverso nodi molto congestionati o attraverso collegamenti che sperimentano più errori e quindi richiedono più ritrasmissioni.

Per quanto riguarda i tipi di metriche, le metriche di routing dovrebbero essere in grado di rappresentare efficacemente:

• Metriche di collegamento: Indicazione della potenza del segnale ricevuto (RSSI), Indicazione della qualità del collegamento (LQI), Conteggio previsto delle trasmissioni (ETX), throughput, latenza
• Metriche del nodo: stato (sleep, sveglio, in ascolto), energia rimanente, conteggio hop, informazioni geografiche (ad esempio, coordinate GPS)
• Metriche composite (collegamento e nodo)

Altre possibili metriche DOVREBBERO (SHOULD) essere anche considerate, come:

• Affidabilità
• Robustezza
• Stabilità

[R10] I protocolli di routing 6LoWPAN DOVREBBERO (SHOULD) essere progettati per ottenere sia scalabilità che longevità nei 6LoWPAN.

I requisiti di scalabilità e longevità sono caratteristiche fondamentali dei LoWPAN:

• Scalabilità: Un LoWPAN può contenere solo pochi nodi (ad esempio, per una rete personale o una rete corporea), ma può anche contenere numeri molto più elevati di dispositivi (ad esempio, monitoraggio di un'infrastruttura urbana o di un'autostrada). Per le applicazioni di automazione domestica, si prevede che il protocollo di routing DEBBA (MUST) supportare 250 dispositivi nella rete [RFC5826], mentre i protocolli di routing per reti di sensori su scala metropolitana DEVONO (MUST) essere in grado di raggruppare un gran numero di nodi di rilevamento in regioni contenenti dell'ordine di 10^2 a 10^4 nodi di rilevamento ciascuna [RFC5548]. È quindi necessario che i meccanismi di routing siano progettati per essere scalabili per il funzionamento in reti di varie dimensioni. Tuttavia, a causa di una mancanza di dimensioni di memoria e potenza computazionale, il routing 6LoWPAN potrebbe limitare le voci di inoltro a un numero ridotto, come un massimo di 32 voci della tabella di routing. In particolare nelle reti di grandi dimensioni, il meccanismo di routing DEVE (MUST) essere progettato in modo tale che il numero di router sia inferiore al numero di host.

• Longevità: La procedura di riparazione del percorso e i messaggi di controllo correlati NON DOVREBBERO (SHOULD NOT) danneggiare il consumo energetico complessivo dei protocolli di routing.

[R11] La procedura di riparazione del percorso e i messaggi di controllo correlati NON DOVREBBERO (SHOULD NOT) danneggiare il consumo energetico complessivo dei protocolli di routing.

La riparazione locale migliora il throughput e la latenza end-to-end, specialmente nelle reti di grandi dimensioni. Poiché i percorsi vengono riparati rapidamente, vengono eliminati meno pacchetti di dati e è necessario un numero inferiore di trasmissioni di pacchetti del protocollo di routing, poiché i percorsi possono essere riparati senza scoperta di percorso avviata dalla sorgente [Lee]. Una considerazione importante qui potrebbe essere evitare l'esaurimento prematuro dell'energia, anche se ciò compromette altri requisiti.

[R12] I protocolli di routing 6LoWPAN DOVREBBERO (SHOULD) consentire topologie dinamicamente adattive e nodi mobili. Quando si supportano topologie dinamiche e nodi mobili, la manutenzione del percorso dovrebbe tenere a mente l'obiettivo di uno stato di routing minimo e un overhead minimo dei messaggi del protocollo di routing.

La mobilità topologica del nodo può essere il risultato di movimento fisico e/o di un ambiente radio in cambiamento, rendendo molto probabile che la mobilità debba essere gestita anche in una rete con nodi fisicamente statici. I 6LoWPAN non utilizzano un protocollo separato per mantenere la connettività ai nodi mobili, ma si aspettano che il protocollo di routing lo gestisca.

Inoltre, alcuni nodi possono spostarsi da un 6LoWPAN a un altro e si prevede che diventino membri funzionali di quest'ultimo 6LoWPAN in un periodo di tempo limitato.

Le applicazioni di monitoraggio degli edifici, ad esempio, hanno una serie di requisiti rispetto al tempo di recupero e al tempo di stabilizzazione per la mobilità che variano tra 5 e 20 secondi (Sezione 5.3.1 di [RFC5867]). Per applicazioni più interattive come quelle utilizzate nei sistemi di automazione domestica, dove gli utenti forniscono input e si aspettano feedback istantanei, i requisiti di mobilità sono anche più rigorosi e, per spostamenti all'interno di una rete, è comunemente richiesto un tempo di convergenza inferiore a 0,5 secondi (Sezione 3.2 di [RFC5826]). Negli ambienti industriali, dove le attrezzature mobili (ad esempio, gru) si muovono, il protocollo di routing deve supportare velocità veicolari fino a 35 km/h [RFC5673]. Attualmente, i 6LoWPAN normalmente non vengono utilizzati per una mobilità così veloce, ma l'associazione e la disassociazione dinamiche DEVONO (MUST) essere supportate nei 6LoWPAN.

Ci sono diverse sfide che dovrebbero essere affrontate da un protocollo di routing 6LoWPAN per creare routing robusto in ambienti dinamici:

• Nodi mobili che cambiano la loro posizione all'interno di un LoWPAN: Se il modello di movimento dei nodi è sconosciuto, la mobilità non può essere facilmente rilevata o distinta dai protocolli di routing. I nodi mobili possono essere trattati come nodi che scompaiono e riappaiono in un altro luogo. Il tracciamento dei modelli di movimento aumenta la complessità e può essere evitato gestendo i nodi mobili utilizzando aggiornamenti di percorso reattivi.

• Movimento di un LoWPAN rispetto ad altri LoWPAN (inter)connessi: All'interno di ogni rete stub, (uno o più) nodi gateway relativamente potenti (6LBR) devono essere configurati per gestire i LoWPAN mobili.

• Nodi che si uniscono o lasciano permanentemente il LoWPAN: Per facilitare gli aggiornamenti della tabella di routing, ridurre la dimensione di questi aggiornamenti e minimizzare i messaggi di controllo degli errori, i nodi che lasciano la rete possono annunciare la loro disassociazione al router edge più vicino o a un nodo specifico (se presente) che si occupa dell'associazione e della disassociazione locale.

[R13] Un protocollo di routing 6LoWPAN DOVREBBE (SHOULD) supportare vari modelli di traffico -- punto-punto, punto-multipunto e multipunto-punto -- evitando al contempo un traffico multicast eccessivo in un LoWPAN.

I 6LoWPAN hanno spesso modelli di traffico punto-multipunto o multipunto-punto. Molte applicazioni emergenti includono anche la comunicazione punto-punto. I protocolli di routing 6LoWPAN dovrebbero essere progettati tenendo conto dell'inoltro di pacchetti da/verso più sorgenti/destinazioni. I documenti attuali del gruppo di lavoro ROLL spiegano che il carico di lavoro o il modello di traffico dei casi d'uso per i LoWPAN tende ad essere altamente strutturato, a differenza dei trasferimenti di dati any-to-any che dominano i carichi di lavoro tipici di client e server. In molti casi, sfruttare tale struttura può semplificare problemi difficili derivanti da vincoli di risorse o variazioni di connettività.

5.4. Support of Security (Supporto della sicurezza)

La sicurezza è un problema critico per le reti a bassa potenza. Qualsiasi soluzione per i protocolli di routing 6LoWPAN DOVREBBE (SHOULD) soddisfare i seguenti requisiti di sicurezza di base. Questi requisiti DEVONO (MUST) applicarsi al meccanismo di routing e allo scambio di dati di rete, evitando al contempo un consumo energetico eccessivo e l'utilizzo della potenza di elaborazione.

[R14] I protocolli di routing 6LoWPAN DOVREBBERO (SHOULD) supportare servizi di integrità dei messaggi, autenticazione della sorgente dei messaggi e riservatezza dei messaggi per difendersi dalle minacce di routing.

Considerando l'importanza della sicurezza dei protocolli di routing e la natura delle minacce di sicurezza ai 6LoWPAN (ad esempio, come descritto in [ROLL-SEC]), i protocolli di routing DOVREBBERO (SHOULD) supportare:

• Integrità dei messaggi, per prevenire la modifica dei messaggi di protocollo da parte dei nodi intermedi
• Autenticazione della sorgente dei messaggi, per prevenire attacchi di spoofing da sorgenti falsificate
• Riservatezza dei messaggi, per prevenire l'intercettazione passiva

Dovrebbe essere considerata anche la tempestività dei messaggi. I messaggi obsoleti possono essere essi stessi una forma di attacco, nel qual caso i servizi di tempestività a livello applicativo stesso o insieme alle funzioni di sicurezza del collegamento dati sono utili per i 6LoWPAN.

I protocolli di routing DEVONO (MUST) essere protetti da attacchi come replay, injection, modification, ecc., che possono portare a minacce tra cui loop di routing o topologia, denial of service mirato a nodi specifici, generazione di informazioni di routing false, esaurimento delle risorse o partizione della rete [ROLL-SEC].

Il supporto della sicurezza sarà un'opzione e, se abilitato, si conformerà a tutte le regole per l'utilizzo di protocolli di routing 6LoWPAN sicuri. Implementando la sicurezza a livello di collegamento (sicurezza in modalità CCM* come definito nella sottoclausola 7.6 di IEEE 802.15.4) e aggiungendo ulteriori meccanismi di sicurezza e controllo dell'integrità dei messaggi specifici del protocollo di routing (come timestamp o numeri di sequenza), può essere ottenuta la resistenza alla maggior parte delle minacce di sicurezza.

Il design DEVE (MUST) considerare il costo delle operazioni pesanti che il protocollo DEVE (MUST) eseguire. Ad esempio, l'utilizzo di chiavi pubbliche può comportare un consumo energetico più elevato rispetto alle chiavi simmetriche. Le soluzioni generali per le operazioni di sicurezza che richiedono grandi quantità di stato del nodo (come gestione indirizzo/chiave, autenticazione, stabilimento di chiavi a livello di collegamento) dovrebbero essere utilizzate in tutti i protocolli LoWPAN per risparmiare overhead. I protocolli di routing 6LoWPAN DOVREBBERO (SHOULD) essere progettati per supportare l'abilitazione di queste funzionalità, e queste funzionalità stesse dovrebbero fare attenzione a non consumare energia eccessiva.

5.5. Support of Mesh-Under Forwarding (Supporto dell'inoltro mesh-under)

L'architettura 6LoWPAN attuale consente l'inoltro multi-hop attraverso il routing mesh-under [RFC4944]. Una caratteristica chiave di questo approccio è che la capacità di supportare l'inoltro mesh-under e il routing route-over può essere un requisito nei protocolli 6LoWPAN. Ma se questo è un requisito per i protocolli di routing 6LoWPAN rimane una questione aperta. A questo riguardo, dobbiamo considerare i requisiti per questi due approcci diversi (uno che utilizza il routing IP, l'altro che utilizza il proprio meccanismo di inoltro).

Il meccanismo di inoltro mesh-under utilizza indirizzi a livello di collegamento (indirizzi MAC), quindi si ferma al confine di una sottorete IP. Quando viene utilizzato in congiunzione con il routing route-over che utilizza indirizzi IPv6 e tabelle di routing, può richiedere informazioni inter-livello, inclusa la propria tabella di inoltro.

Per questo motivo, il meccanismo di inoltro mesh-under può fornire i propri messaggi di manutenzione della topologia e tabella di inoltro per le operazioni correlate. Questo può essere paragonabile alla funzionalità richiesta dai protocolli di routing route-over, che vengono utilizzati per la scoperta di vicini/collegamenti, la gestione delle voci della tabella di inoltro, la manutenzione della topologia e la scoperta del percorso.

Pertanto, una questione chiave è come questi due approcci (route-over e mesh-under) dovrebbero essere combinati, come possono lavorare in coordinamento, evitando così qualsiasi ridondanza o problema di interoperabilità che potrebbe sorgere. Il lavoro futuro dovrebbe concentrarsi specificamente su queste questioni architetturali.

5.6. Support of Management (Supporto della gestione)

Per la gestione della rete, i seguenti requisiti DOVREBBERO (SHOULD) essere considerati.

I LoWPAN potrebbero dover essere configurati e inizializzati dinamicamente, ad esempio, dopo l'accensione di un gateway, esso non sa quali nodi appartengono alla sua sottorete. La capacità dei nodi di unirsi a una rete è intrinsecamente indipendente dalla tecnologia di routing, anche se alcuni protocolli di routing possono facilitare questo processo. I protocolli di routing DOVREBBERO (SHOULD) supportare l'inizializzazione e la configurazione della rete. Questo può coinvolgere l'interazione tra il protocollo di routing e altre funzioni come l'assegnazione degli indirizzi, l'autoconfigurazione e la scoperta dei vicini.

Per il monitoraggio e il debug, la capacità di ottenere parametri rilevanti del protocollo di routing, la configurazione corrente e lo stato corrente della funzionalità di router e host è importante. Dovrebbe essere possibile ottenere informazioni come tabelle di routing, tabelle dei vicini, conteggi dei messaggi e informazioni sulla qualità del collegamento. Dovrebbero essere considerate interfacce per funzioni di diagnostica, rilevamento guasti, monitoraggio e reporting di eventi/allarmi. Sebbene in alcuni casi possano essere disponibili protocolli e interfacce esistenti a questo scopo, potrebbero essere necessarie soluzioni specificamente adattate ai LoWPAN.

Poiché alcuni LoWPAN tipicamente entrano periodicamente in modalità sleep, dovrebbe essere possibile controllare il modello di sleep/risveglio del nodo in modo che le informazioni possano essere raccolte con latenza inferiore.

La capacità di supportare l'evoluzione del protocollo di routing e di modificare i parametri di routing in base alle circostanze e ai modelli di traffico è importante. Ad esempio, potrebbe essere necessario selezionare un tipo di metrica, regolare i valori dei timer o selezionare/modificare la modalità del protocollo (se supportato). Una possibilità è passare a un protocollo completamente diverso. Tuttavia, questo potrebbe non essere fattibile a causa dei requisiti di dimensione del codice. Gli utenti dovrebbero essere in grado di supportare implementazioni di più protocolli di routing.

I seguenti aspetti di gestione aggiuntivi dovrebbero essere considerati:

• Capacità di gestione dei dispositivi e configurazione della topologia dei nodi
• Gestione della sicurezza, inclusa la gestione delle chiavi
• Gestione della pianificazione del sonno
• Gestione della qualità del servizio
• Riparazione del percorso, rilevamento guasti e controllo
• Integrazione e coordinamento inter-livello