18. Considerazioni sulla gestibilità

Lo scopo di questa sezione è prendere in considerazione la gestibilità di RPL e come RPL sarà gestito in una LLN. L'ambito di questa sezione è considerare i seguenti aspetti della gestibilità: configurazione, monitoraggio, gestione dei guasti, contabilità e prestazioni del protocollo alla luce delle raccomandazioni stabilite in [RFC5706].

18.1. Introduzione

La maggior parte degli standard di gestione IETF esistenti sono moduli MIB (modelli di dati basati sulla Structure of Management Information (SMI)) per monitorare e gestire i dispositivi di rete.

Per una serie di protocolli, la comunità IETF ha utilizzato l'IETF Standard Management Framework, incluso il Simple Network Management Protocol [RFC3410], la Structure of Management Information [RFC2578] e i modelli di dati MIB per la gestione di nuovi protocolli.

Come sottolineato in [RFC5706], la politica comune in termini di funzionamento e gestione è stata estesa a una politica più aperta a un insieme di strumenti e protocolli di gestione piuttosto che affidarsi rigorosamente a un singolo protocollo come SNMP.

Nel 2003, l'Internet Architecture Board (IAB) ha tenuto un workshop sulla gestione della rete [RFC3535] che ha discusso i punti di forza e di debolezza di alcuni protocolli di gestione della rete IETF e li ha confrontati con le esigenze operative, in particolare la configurazione.

Un problema discusso è stato la scarsa facilità d'uso del formato binario di SNMP [RFC3410]. Nel caso delle LLN, va notato che al momento della stesura di questo documento, il gruppo di lavoro CoRE sta lavorando attivamente sulla gestione delle risorse dei dispositivi nelle LLN. Tuttavia, si ritiene che questa sezione fornisca una guida importante su come RPL dovrebbe essere distribuito, gestito e amministrato.

Come affermato in [RFC5706]:

Un modello di informazioni di gestione dovrebbe includere una discussione su ciò che è gestibile, quali aspetti del protocollo devono essere configurati, quali tipi di operazioni sono consentiti, quali eventi specifici del protocollo potrebbero verificarsi, quali eventi possono essere contati e per quali eventi un operatore dovrebbe essere avvisato.

Questi aspetti sono discussi in dettaglio nelle sezioni seguenti.

RPL sarà utilizzato su una varietà di dispositivi che possono avere risorse come la memoria che variano da pochi kilobyte a diverse centinaia di kilobyte e persino megabyte. Quando la memoria è molto limitata, potrebbe non essere possibile soddisfare tutti i requisiti elencati in questa sezione. Tuttavia vale la pena elencarli tutti in modo esaustivo, e gli implementatori determineranno quindi quali di questi requisiti potrebbero essere soddisfatti in base alle risorse disponibili sul dispositivo.

18.2. Gestione della configurazione

Questa sezione discute la gestione della configurazione, elencando i parametri del protocollo per i quali la gestione della configurazione è rilevante.

Alcuni dei parametri RPL sono opzionali. I requisiti per la configurazione sono applicabili solo per le opzioni che vengono utilizzate.

18.2.1. Modalità di inizializzazione

"Architectural Principles of the Internet" [RFC1958], Sezione 3.8, afferma: "Evitare opzioni e parametri quando possibile. Qualsiasi opzione e parametro dovrebbe essere configurato o negoziato dinamicamente piuttosto che manualmente". Ciò è particolarmente vero nelle LLN dove il numero di dispositivi può essere grande e la configurazione manuale è inattuabile. Di ciò si è tenuto conto nella progettazione di RPL in cui la radice DODAG fornisce una serie di parametri ai dispositivi che si uniscono al DODAG, evitando così configurazioni ingombranti sui router e potenziali fonti di errata configurazione (ad es. valori dei timer Trickle, ecc.). Tuttavia, ci sono parametri RPL aggiuntivi che un'implementazione RPL dovrebbe consentire di configurare, che sono discussi in questa sezione.

18.2.1.1. Modalità operativa DIS all'avvio

Quando un nodo viene acceso per la prima volta:

1. Il nodo può decidere di rimanere in silenzio, in attesa di ricevere messaggi DIO dal DODAG di interesse (che annuncia una OF e metriche/vincoli supportati) e non inviare alcun messaggio DIO multicast fino a quando non si è unito a un DODAG.

2. Il nodo può decidere di inviare uno o più messaggi DIS (facoltativamente, richiedendo DIO per un DODAG specifico) come sonda iniziale per i DODAG vicini e, in assenza di messaggi DIO in risposta dopo un certo periodo di tempo configurabile, il nodo può decidere di radicare un DODAG fluttuante e iniziare a inviare messaggi DIO multicast.

Un'implementazione RPL DOVREBBE consentire di configurare la modalità operativa preferita sopra elencata insieme ai parametri richiesti (nella seconda modalità: il numero di messaggi DIS e il relativo timer).

18.2.2. Configurazione dei messaggi e delle opzioni base DIO e DAO

RPL specifica una serie di parametri di protocollo considerando l'ampio spettro di applicazioni in cui verrà utilizzato. Detto questo, è stata prestata particolare attenzione a limitare il numero di questi parametri che devono essere configurati su ciascun router RPL. Invece, è possibile utilizzare una serie di valori predefiniti e, quando richiesto, questi parametri possono essere forniti dalla radice DODAG consentendo così l'impostazione dinamica dei parametri.

Un'implementazione RPL DOVREBBE consentire di configurare i seguenti parametri del protocollo di routing. Come sottolineato sopra, si noti che un ampio set di parametri è configurato sulla radice DODAG.

18.2.3. Parametri del protocollo da configurare su ogni router nella LLN

Un'implementazione RPL DEVE consentire di configurare i seguenti parametri RPL:

• RPLInstanceID [messaggio DIO, nel messaggio base DIO]. Sebbene l'RPLInstanceID debba essere configurato sulla radice DODAG, deve anche essere configurato come politica su ogni nodo al fine di determinare se il nodo debba unirsi o meno a un particolare DODAG. Si noti che un secondo RPLInstanceID può essere configurato sul nodo, nel caso in cui diventi radice di un DODAG fluttuante.

• Elenco degli Objective Code Points (OCP) supportati

• Elenco delle metriche supportate: [RFC6551] specifica una serie di metriche e vincoli utilizzati per la formazione del DODAG. Pertanto, un'implementazione RPL dovrebbe consentire di configurare l'elenco delle metriche che un nodo può accettare e comprendere. Se viene ricevuto un DIO con una metrica e/o un vincolo non compreso o supportato, come specificato nella Sezione 8.5, il nodo si unirà come nodo foglia.

• Informazioni sul prefisso, insieme alla durata valida e preferita e ai flag 'L' e 'A'. [Messaggio DIO, Opzione Prefix Information]. Un'implementazione RPL DOVREBBE consentire di configurare se l'opzione Prefix Information deve essere trasportata con il messaggio DIO per distribuire le informazioni sul prefisso per l'autoconfigurazione. In tal caso, l'implementazione RPL DEVE consentire che l'elenco dei prefissi sia annunciato nel PIO insieme ai flag corrispondenti.

• Informazioni sollecitate [messaggio DIS, nell'opzione Solicited Information]. Si noti che un'implementazione RPL DOVREBBE consentire di configurare quando tali messaggi devono essere inviati e in quali circostanze, insieme al valore dell'ID RPLInstance, flag 'V'/'I'/'D'.

• Flag 'K': quando un nodo dovrebbe impostare il flag 'K' in un messaggio DAO [messaggio DAO, nel messaggio base DAO].

• MOP (Modalità operativa) [messaggio DIO, nel messaggio base DIO].

• Informazioni sul percorso (e preferenza) [messaggio DIO, nell'opzione Route Information]

18.2.4. Parametri del protocollo da configurare su ogni router non radice DODAG nella LLN

Un'implementazione RPL DEVE consentire di configurare il prefisso Target [messaggio DAO, nell'opzione RPL Target].

Inoltre, ci sono circostanze in cui un nodo potrebbe voler designare un Target per consentire un'elaborazione specifica del Target (prioritizzazione, ecc.). Tali regole di elaborazione esulano dall'ambito di questa specifica. Quando utilizzata, un'implementazione RPL DOVREBBE consentire di configurare il descrittore del target su base per target (ad esempio, utilizzando elenchi di accesso).

Un nodo il cui insieme di genitori DODAG è vuoto può diventare la radice DODAG di un DODAG fluttuante. Può anche impostare la sua DAGPreference in modo che sia meno preferito. Pertanto, un'implementazione RPL DEVE consentire di configurare l'insieme di azioni che il nodo dovrebbe avviare in questo caso:

• Avviare il proprio DODAG (fluttuante): il nuovo DODAGID deve essere configurato in aggiunta alla sua DAGPreference.

• Avvelenare il percorso interrotto (vedere la procedura nella Sezione 8.2.2.5).

• Attivare una riparazione locale.

18.2.5. Parametri da configurare sulla radice DODAG

Inoltre, molti altri parametri sono configurati solo sulla radice DODAG e annunciati nelle opzioni trasportate nei messaggi DIO.

Come specificato nella Sezione 8.3, un'implementazione RPL fa uso di timer Trickle per governare l'invio di messaggi DIO. Il funzionamento dell'algoritmo Trickle è determinato da un insieme di parametri configurabili, che DEVONO essere configurabili e che vengono poi annunciati dalla radice DODAG lungo il DODAG nei messaggi DIO.

• DIOIntervalDoublings [messaggio DIO, nell'opzione DODAG Configuration]

• DIOIntervalMin [messaggio DIO, nell'opzione DODAG Configuration]

• DIORedundancyConstant [messaggio DIO, nell'opzione DODAG Configuration]

Inoltre, un'implementazione RPL DOVREBBE consentire di configurare il seguente set di parametri RPL:

• Path Control Size [messaggio DIO, nell'opzione DODAG Configuration]

• MinHopRankIncrease [messaggio DIO, nell'opzione DODAG Configuration]

• Il campo DODAGPreference [messaggio DIO, oggetto base DIO]

• DODAGID [messaggio DIO, nell'opzione base DIO] e [messaggio DAO, quando il flag 'D' del messaggio DAO è impostato]

Comportamento della radice DAG: in alcuni casi, un nodo potrebbe non voler agire permanentemente come radice DODAG fluttuante se non può unirsi a un DODAG con messa a terra. Ad esempio, un nodo alimentato a batteria potrebbe non voler agire come radice DODAG fluttuante per un lungo periodo di tempo. Pertanto, un'implementazione RPL PUÒ supportare la capacità di configurare se un nodo può agire o meno come radice DODAG fluttuante per un periodo di tempo configurato.

Incremento del numero di versione DAG: un'implementazione RPL può consentire, tramite configurazione alla radice DODAG, di aggiornare gli stati DODAG aggiornando il DODAGVersionNumber. Un'implementazione RPL DOVREBBE consentire di configurare se i meccanismi periodici o attivati da eventi sono utilizzati dalla radice DODAG per controllare la modifica del DODAGVersionNumber (che attiva una riparazione globale come specificato nella Sezione 3.2.2).

18.2.6. Configurazione dei parametri RPL relativi ai meccanismi basati su DAO

I messaggi DAO sono opzionali e utilizzati nei DODAG che richiedono un'operazione di routing verso il basso. Questa sezione tratta l'insieme di parametri relativi ai messaggi DAO e fornisce raccomandazioni sulla loro configurazione.

Come indicato nella Sezione 9.5, si consiglia di ritardare l'invio del messaggio DAO ai genitori DAO al fine di massimizzare le possibilità di eseguire l'aggregazione dei percorsi. Alla ricezione di un messaggio DAO, il nodo dovrebbe quindi avviare un timer DelayDAO. Il valore predefinito è DEFAULT_DAO_DELAY. Un'implementazione RPL PUÒ consentire di configurare il timer DelayDAO.

In una modalità operativa di memorizzazione, un nodo di memorizzazione può incrementare il DTSN per attivare in modo affidabile un insieme di aggiornamenti DAO dai suoi figli immediati, come parte degli aggiornamenti e della manutenzione di routine della tabella di routing. Un'implementazione RPL PUÒ consentire di configurare un insieme di regole che specificano i trigger per l'incremento del DTSN (manuale o basato su eventi).

Quando una voce DAO scade o viene invalidata, un nodo DOVREBBE fare un ragionevole tentativo di segnalare un No-Path a ciascuno dei genitori DAO. Quel numero di tentativi PUÒ essere configurabile.

Un'implementazione dovrebbe supportare la limitazione della velocità di invio dei messaggi DAO. I parametri relativi POSSONO essere configurabili.

18.2.7. Configurazione dei parametri RPL relativi ai meccanismi di sicurezza

Come descritto nella Sezione 10, le funzionalità di sicurezza descritte in questo documento sono opzionali da implementare e una determinata implementazione può supportare un sottoinsieme (incluso l'insieme vuoto) delle funzionalità di sicurezza descritte.

A tal fine, un'implementazione che supporta le funzionalità di sicurezza descritte può concettualmente implementare un database delle politiche di sicurezza. A supporto dei meccanismi di sicurezza, un'implementazione RPL DOVREBBE consentire di configurare un sottoinsieme dei seguenti parametri:

• Modalità di sicurezza accettate [modalità non protetta, modalità preinstallata, modalità autenticata]

• Valori KIM accettati [messaggi di controllo RPL sicuri, nella sezione Sicurezza]

• Valori di livello accettati [messaggi di controllo RPL sicuri, nella sezione Sicurezza]

• Valori dell'algoritmo accettati [messaggi di controllo RPL sicuri, nella sezione Sicurezza]

• Materiale chiave a supporto delle modalità chiave Autenticata o Preinstallata.

Inoltre, un'implementazione RPL DOVREBBE consentire di configurare una radice DODAG con un sottoinsieme dei seguenti parametri:

• Valori di livello annunciati [messaggio DIO sicuro, nella sezione Sicurezza]

• Valore KIM annunciato [messaggio DIO sicuro, nella sezione Sicurezza]

• Valore dell'algoritmo annunciato [messaggio DIO sicuro, nella sezione Sicurezza]

18.2.8. Valori predefiniti

Questo documento specifica i valori predefiniti per il seguente set di variabili RPL:

• DEFAULT_PATH_CONTROL_SIZE
• DEFAULT_DIO_INTERVAL_MIN
• DEFAULT_DIO_INTERVAL_DOUBLINGS
• DEFAULT_DIO_REDUNDANCY_CONSTANT
• DEFAULT_MIN_HOP_RANK_INCREASE
• DEFAULT_DAO_DELAY

Si consiglia di specificare i valori predefiniti nei protocolli; detto questo, come discusso in [RFC5706], i valori predefiniti potrebbero avere sempre meno senso. RPL è un protocollo di routing che dovrebbe essere utilizzato in una serie di contesti in cui le caratteristiche della rete come il numero di nodi e i tipi di collegamento e nodo dovrebbero variare in modo significativo. Pertanto, è probabile che questi valori predefiniti cambino con il contesto e con l'evoluzione della tecnologia. In effetti, la tecnologia correlata alle LLN (ad esempio, hardware, livelli di collegamento) si è evoluta radicalmente negli ultimi anni e si prevede che tali tecnologie cambieranno ed evolveranno considerevolmente nei prossimi anni.

I valori proposti non si basano su ampie best practice attuali e sono considerati conservativi.

18.3. Monitoraggio del funzionamento di RPL

Diversi parametri RPL dovrebbero essere monitorati per verificare il corretto funzionamento del protocollo di routing e della rete stessa. Questa sezione elenca l'insieme dei parametri di monitoraggio di interesse.

18.3.1. Monitoraggio dei parametri di un DODAG

Un'implementazione RPL DOVREBBE fornire informazioni sui seguenti parametri:

• Numero di versione DODAG [messaggio DIO, nel messaggio base DIO]

• Stato del flag 'G' [messaggio DIO, nel messaggio base DIO]

• Stato del campo MOP [messaggio DIO, nel messaggio base DIO]

• Valore del DTSN [messaggio DIO, nel messaggio base DIO]

• Valore del Rango [messaggio DIO, nel messaggio base DIO]

• DAOSequence: Incrementato ad ogni messaggio DAO univoco, echeggiato nel messaggio DAO-ACK [messaggi DAO e DAO-ACK]

• Informazioni sul percorso [messaggio DIO, opzione Route Information] (elenco dei prefissi IPv6 per genitore insieme a durata e preferenza]

• Parametri Trickle:

  • DIOIntervalDoublings [messaggio DIO, nell'opzione DODAG Configuration]
  • DIOIntervalMin [messaggio DIO, nell'opzione DODAG Configuration]
  • DIORedundancyConstant [messaggio DIO, nell'opzione DODAG Configuration]

• Path Control Size [messaggio DIO, nell'opzione DODAG Configuration]

• MinHopRankIncrease [messaggio DIO, nell'opzione DODAG Configuration]

Valori che possono essere monitorati solo sulla radice DODAG:

• Informazioni di transito [DAO, opzione Transit Information]: un'implementazione RPL DOVREBBE consentire di configurare se l'insieme di opzioni Transit Information ricevute deve essere visualizzato sulla radice DODAG. In questo caso, il database RPL delle informazioni di transito ricevute dovrebbe contenere anche la sequenza del percorso, il controllo del percorso, la durata del percorso e l'indirizzo del genitore.

18.3.2. Monitoraggio delle incongruenze DODAG e rilevamento dei loop

Il rilevamento delle incongruenze DODAG è particolarmente critico nelle reti RPL. Pertanto, si raccomanda a un'implementazione RPL di fornire strumenti di monitoraggio appropriati. Un'implementazione RPL DOVREBBE fornire un contatore che riporta il numero di volte in cui il nodo ha rilevato un'incongruenza rispetto a un genitore DODAG, ad esempio se il DODAGID è cambiato.

Quando possibile, dovrebbero essere fornite informazioni più granulari sul rilevamento delle incongruenze. Un'implementazione RPL PUÒ fornire contatori che riportano il numero delle seguenti incongruenze:

• Pacchetti ricevuti con bit 'O' impostato (verso il basso) da un nodo con un rango superiore

• Pacchetti ricevuti con bit 'O' cancellato (verso l'alto) da un nodo con un rango inferiore

• Numero di pacchetti con il bit 'F' impostato

• Numero di pacchetti con il bit 'R' impostato

18.4. Monitoraggio delle strutture dati RPL

18.4.1. Struttura dati dei vicini candidati

Un nodo nell'elenco dei vicini candidati è un nodo scoperto con gli stessi mezzi e qualificato per diventare potenzialmente un genitore (con una confidenza locale sufficientemente elevata). Un'implementazione RPL DOVREBBE fornire un modo per consentire il monitoraggio dell'elenco dei vicini candidati con una metrica che rifletta la confidenza locale (il grado di stabilità dei vicini) misurata da alcune metriche.

Un'implementazione RPL PUÒ fornire un contatore che riporta il numero di volte in cui un vicino candidato è stato ignorato, nel caso in cui il numero di vicini candidati superi il valore massimo autorizzato.

18.4.2. Tabella del grafo aciclico diretto orientato alla destinazione (DODAG)

Per ogni DODAG, ci si aspetta che un'implementazione RPL tenga traccia dei seguenti valori della tabella DODAG:

• RPLInstanceID

• DODAGID

• DODAGVersionNumber

• Rango

• Objective Code Point

• Un insieme di genitori DODAG

• Un insieme di prefissi offerti verso l'alto lungo il DODAG

• Timer Trickle utilizzati per governare l'invio di messaggi DIO per il DODAG

• Elenco dei genitori DAO

• DTSN

• Stato del nodo (router rispetto a foglia)

Un'implementazione RPL DOVREBBE consentire il monitoraggio dell'insieme di parametri sopra elencati.

18.4.3. Tabella di routing e voci di routing DAO

Un'implementazione RPL mantiene diversi elementi informativi relativi al DODAG e alle voci DAO (per i nodi di memorizzazione). Nel caso di un nodo non di memorizzazione, viene mantenuta una quantità limitata di informazioni (la tabella di routing è per lo più ridotta a un insieme di genitori DODAG insieme alle caratteristiche del DODAG come menzionato sopra); mentre nel caso di nodi di memorizzazione, queste informazioni sono aumentate con voci di routing.

Un'implementazione RPL DOVREBBE consentire il monitoraggio dei seguenti parametri:

• Next Hop (genitore DODAG)

• Interfaccia Next Hop

• Valore delle metriche del percorso per ciascun genitore DODAG

Una voce della tabella di routing DAO contiene concettualmente i seguenti elementi (solo per i nodi di memorizzazione):

• Informazioni sul vicino che fa pubblicità

• Indirizzo IPv6

• ID interfaccia a cui questa voce è stata segnalata ai genitori DAO

• Contatore di tentativi

• Equivalente logico del contenuto DAO:

  • DAO-Sequence
  • Sequenza del percorso
  • Durata DAO
  • Controllo del percorso DAO

• Prefisso di destinazione (o indirizzo o gruppo multicast)

Un'implementazione RPL DOVREBBE fornire informazioni sullo stato di ciascuno stato della voce della tabella di routing DAO.

18.5. Gestione dei guasti

La gestione dei guasti è un componente critico utilizzato per la risoluzione dei problemi, la verifica della corretta modalità operativa del protocollo e la progettazione della rete; inoltre, è un componente chiave del monitoraggio delle prestazioni della rete. Un'implementazione RPL DOVREBBE consentire la fornitura delle seguenti informazioni relative alla gestione dei guasti:

• Overflow della memoria insieme alla causa (ad esempio, overflow delle tabelle di routing, ecc.)

• Numero di volte in cui un pacchetto non ha potuto essere inviato a un genitore DODAG contrassegnato come valido

• Numero di volte in cui è stato ricevuto un pacchetto per il quale il router non aveva un RPLInstanceID corrispondente

• Numero di volte in cui è stata attivata una procedura di riparazione locale

• Numero di volte in cui è stata attivata una riparazione globale dalla radice DODAG

• Numero di messaggi malformati ricevuti

• Numero di secondi con pacchetti da inoltrare e nessun hop successivo (genitore DODAG)

• Numero di secondi senza hop successivo (genitore DODAG)

• Numero di volte in cui un nodo si è unito a un DODAG come foglia perché ha ricevuto un DIO con una metrica/vincolo non compreso ed è stato configurato per unirsi come nodo foglia in questo caso (vedere la Sezione 18.6)

Si RACCOMANDA di segnalare i guasti almeno tramite messaggi di registro degli errori. Altri protocolli possono essere utilizzati per segnalare tali guasti.

18.6. Politica

Le regole di politica possono essere utilizzate da un'implementazione RPL per determinare se al nodo è consentito o meno unirsi a un particolare DODAG annunciato da un vicino tramite messaggi DIO.

Questo documento specifica il funzionamento all'interno di un singolo DODAG. Un DODAG è caratterizzato dalla seguente tupla (RPLInstanceID, DODAGID). Inoltre, come sottolineato sopra, i messaggi DIO sono utilizzati per annunciare altre caratteristiche del DODAG come le metriche di routing e i vincoli utilizzati per costruire il DODAG e la funzione obiettivo in uso (specificata da OCP).

Le prime regole di politica consistono nello specificare le seguenti condizioni che un nodo RPL deve soddisfare per unirsi a un DODAG:

• RPLInstanceID

• Elenco delle metriche e dei vincoli di routing supportati

• Funzione obiettivo (valori OCP)

Un'implementazione RPL DEVE consentire di configurare questi parametri e DOVREBBE specificare se il nodo deve semplicemente ignorare il DIO se il DODAG annunciato non è conforme alla politica locale o se il nodo deve unirsi come nodo foglia se solo l'elenco delle metriche e dei vincoli di routing supportati e l'OF non è supportato. Inoltre, un'implementazione RPL DOVREBBE consentire l'aggiunta del DODAGID come parte della politica.

Un'implementazione RPL DOVREBBE consentire di configurare l'insieme di funzioni obiettivo (OF) accettabili o preferite referenziate dai loro Objective Code Points (OCP) affinché un nodo si unisca a un DODAG e quale azione dovrebbe essere intrapresa se nessuno dei vicini candidati di un nodo annuncia una delle funzioni obiettivo consentite configurate o se la metrica/vincolo annunciato non è compreso/supportato. In questo caso possono essere intraprese due azioni:

• Il nodo si unisce al DODAG come nodo foglia come specificato nella Sezione 8.5.

• Il nodo non si unisce al DODAG.

Un nodo in una LLN può apprendere informazioni di routing da diversi protocolli di routing incluso RPL. In questo caso, è auspicabile controllare, tramite preferenza amministrativa, quale percorso dovrebbe essere favorito. Un'implementazione DOVREBBE consentire la specifica di una preferenza amministrativa per il protocollo di routing da cui è stato appreso il percorso.

Strutture dati interne: alcune implementazioni RPL possono limitare la dimensione dell'elenco dei vicini candidati al fine di limitare l'utilizzo della memoria; nel qual caso, alcuni vicini candidati altrimenti validi potrebbero non essere presi in considerazione e semplicemente eliminati dall'elenco dei vicini candidati.

Un'implementazione RPL PUÒ fornire un indicatore sulla dimensione dell'elenco dei vicini candidati.

18.7. Isolamento dei guasti

Si RACCOMANDA di mettere in quarantena i vicini che iniziano a emettere messaggi malformati a velocità inaccettabili.

18.8. Impatto su altri protocolli

RPL ha un impatto molto limitato su altri protocolli. Laddove è richiesto più di un protocollo di routing su un router, come un LBR, ci si aspetta che il dispositivo supporti funzioni di ridistribuzione del routing tra i protocolli di routing per consentire la raggiungibilità tra i due domini di routing. Tale ridistribuzione DOVREBBE essere governata dall'uso di una politica configurabile dall'utente.

Per quanto riguarda l'impatto in termini di traffico sulla rete, RPL è stato progettato per limitare il traffico di controllo grazie a meccanismi come i timer Trickle (Sezione 8.3). Pertanto, l'impatto di RPL su altri protocolli dovrebbe essere estremamente limitato.

18.9. Gestione delle prestazioni

La gestione delle prestazioni è sempre un aspetto importante di un protocollo e RPL non fa eccezione. Diverse metriche di interesse sono state specificate dal gruppo di lavoro IP Performance Monitoring (IPPM): detto questo, saranno difficilmente applicabili alle LLN considerando il costo del monitoraggio di queste metriche in termini di risorse sui dispositivi e larghezza di banda richiesta. Tuttavia, le implementazioni RPL POSSONO supportare alcune di queste e altri parametri di interesse sono elencati di seguito:

• Numero di riparazioni e tempo di riparazione in secondi (media, varianza)

• Numero di volte e periodo di tempo durante il quale un dispositivo non ha potuto inoltrare un pacchetto a causa della mancanza di un vicino raggiungibile nella sua tabella di routing

• Monitoraggio del consumo di risorse da parte di RPL in termini di larghezza di banda e memoria richiesta

• Numero di messaggi di controllo RPL inviati e ricevuti

18.10. Diagnostica

Potrebbero esserci situazioni in cui un nodo dovrebbe essere messo in modalità "verbose" per migliorare la diagnostica. Pertanto, un'implementazione RPL DOVREBBE fornire la capacità di mettere un nodo dentro e fuori dalla modalità verbose al fine di ottenere ulteriori informazioni diagnostiche.