11. Inoltro dei Pacchetti e Evitamento/Rilevamento dei Cicli

11.1. Suggerimenti per l'Inoltro dei Pacchetti

Questo documento specifica un protocollo di instradamento. Questi suggerimenti non normativi sono forniti per aiutare nella progettazione di un'implementazione di inoltro illustrando come tale implementazione potrebbe funzionare con RPL.

Quando si inoltra un pacchetto a una destinazione, la precedenza è data alla selezione di un successore next-hop come segue:

1. Questa specifica copre solo come un successore viene selezionato dalla versione DODAG che corrisponde al RPLInstanceID marcato nell'intestazione IPv6 del pacchetto che viene inoltrato. L'instradamento al di fuori dell'istanza può essere fatto purché vengano messe in atto regole aggiuntive come l'ordinamento rigoroso delle istanze e protocolli di instradamento per proteggere dai cicli. Tali regole possono essere definite in un documento separato.

2. Se una preferenza amministrativa locale favorisce una rotta che è stata appresa da un protocollo di instradamento diverso da RPL, allora utilizzare quel successore.

3. Se l'intestazione del pacchetto specifica una rotta alla sorgente includendo un'intestazione RH4 come specificato in [RFC6554], allora utilizzare quella rotta. Se il nodo non riesce a inoltrare il pacchetto con quella rotta alla sorgente specificata, allora quel pacchetto dovrebbe essere scartato. Il nodo PUÒ registrare un errore. Il nodo può inviare un messaggio di errore ICMPv6 nell'intestazione di instradamento alla sorgente alla sorgente del pacchetto (vedi Sezione 20.18).

4. Se c'è una voce nella tabella di instradamento corrispondente alla destinazione che è stata appresa da un annuncio di destinazione multicast (ad esempio, la destinazione è un vicino a un hop), allora utilizzare quel successore.

5. Se c'è una voce nella tabella di instradamento corrispondente alla destinazione che è stata appresa da un annuncio di destinazione unicast (ad esempio, la destinazione si trova in basso nel sub-DODAG), allora utilizzare quel successore. Se ci sono bit di controllo del percorso DAO associati a più successori, allora consultare i bit di controllo del percorso per ordinare i successori per preferenza quando si sceglie. Se, per un dato bit di controllo del percorso DAO, più successori sono registrati come aventi asserito quel bit, la precedenza dovrebbe essere data al successore che ha asserito quel bit più recentemente.

6. Se c'è una versione DODAG che offre una rotta verso un prefisso corrispondente alla destinazione, allora selezionare uno di quei genitori DODAG come successore secondo l'OF e le metriche di instradamento.

7. Qualsiasi altro genitore DODAG non ancora tentato può essere scelto per il prossimo tentativo di inoltrare un pacchetto unicast quando non esiste una corrispondenza migliore.

8. Infine, il pacchetto viene scartato. ICMP Destination Unreachable PUÒ essere invocato (viene rilevata un'inconsistenza).

L'Hop Limit DEVE essere decrementato durante l'inoltro per [RFC2460].

Nota che il successore scelto NON DEVE essere il vicino che era il predecessore del pacchetto (split horizon), tranne nel caso in cui si intenda che il pacchetto cambi da una direzione verso l'alto a una verso il basso, come determinato dalla tabella di instradamento del nodo che effettua il cambiamento, come il passaggio da rotte DIO a rotte DAO man mano che ci si avvicina alla destinazione per continuare a viaggiare verso la destinazione.

11.2. Evitamento e Rilevamento dei Cicli

I meccanismi di evitamento dei cicli RPL sono mantenuti semplici e progettati per minimizzare il churn e gli stati. I cicli possono formarsi per una serie di motivi, ad esempio, perdita di pacchetti di controllo. RPL include una tecnica di rilevamento dei cicli reattiva che protegge dal meltdown e innesca la riparazione dei percorsi interrotti.

Il rilevamento dei cicli RPL utilizza le informazioni sul pacchetto RPL che sono trasportate all'interno dei pacchetti di dati, basandosi su un meccanismo esterno come [RFC6553] che inserisce le informazioni sul pacchetto RPL in un'intestazione opzionale IPv6 Hop-by-Hop.

Il contenuto delle informazioni sul pacchetto RPL è definito come segue:

• Down 'O': Flag a 1 bit che indica se il pacchetto è previsto che progredisca verso l'alto o verso il basso. Un router imposta il flag 'O' quando il pacchetto è previsto che progredisca verso il basso (utilizzando rotte DAO), e lo cancella quando inoltra verso la radice del DODAG (verso un nodo con un Rango inferiore). Un host o un nodo foglia RPL DEVE impostare il flag 'O' a 0.

• Rank-Error 'R': Flag a 1 bit che indica se è stato rilevato un errore di Rango. Un errore di Rango viene rilevato quando c'è una discrepanza nei Ranghi relativi e la direzione come indicato nel bit 'O'. Un host o un nodo foglia RPL DEVE impostare il bit 'R' a 0.

• Forwarding-Error 'F': Flag a 1 bit che indica che questo nodo non può inoltrare ulteriormente il pacchetto verso la destinazione. Il bit 'F' potrebbe essere impostato da un nodo figlio che non ha una rotta verso la destinazione per un pacchetto con il bit Down 'O' impostato. Un host o un nodo foglia RPL DEVE impostare il bit 'F' a 0.

• RPLInstanceID: Campo a 8 bit che indica l'istanza DODAG lungo la quale il pacchetto viene inviato.

• SenderRank: Campo a 16 bit impostato a zero dalla sorgente e a DAGRank(rank) da un router che inoltra all'interno della rete RPL.

11.2.1. Operazione del Nodo Sorgente

Se la sorgente è a conoscenza del RPLInstanceID che è preferito per il pacchetto, allora DEVE impostare il campo RPLInstanceID associato al pacchetto di conseguenza; altrimenti, DEVE impostarlo a RPL_DEFAULT_INSTANCE.

11.2.2. Operazione del Router

11.2.2.1. Inoltro dell'Istanza

Il RPLInstanceID è associato dalla sorgente al pacchetto. Questo RPLInstanceID DEVE corrispondere all'istanza RPL su cui il pacchetto è posizionato da qualsiasi nodo, sia esso un host o un router. Il RPLInstanceID è parte delle informazioni sul pacchetto RPL.

Un router RPL che inoltra un pacchetto nella rete RPL DEVE controllare se il pacchetto include le informazioni sul pacchetto RPL. In caso contrario, allora il router RPL DEVE inserire le informazioni sul pacchetto RPL. Se il router è un router di ingresso che inietta il pacchetto nella rete RPL, il router DEVE impostare il campo RPLInstanceID nelle informazioni sul pacchetto RPL. I dettagli di come quel router determina la mappatura a un RPLInstanceID sono fuori dall'ambito di questa specifica e lasciati a specifiche future.

Un router che inoltra un pacchetto al di fuori della rete RPL DEVE rimuovere le informazioni sul pacchetto RPL.

Quando un router riceve un pacchetto che specifica un dato RPLInstanceID e il nodo può inoltrare il pacchetto lungo il DODAG associato a quell'istanza, allora il router DEVE farlo e lasciare il valore RPLInstanceID invariato.

Se un nodo non può inoltrare un pacchetto lungo il DODAG associato al RPLInstanceID, allora il nodo DOVREBBE scartare il pacchetto e inviare un messaggio di errore ICMP.

11.2.2.2. Rilevamento dei Cicli di Inconsistenza DAG

Il DODAG è inconsistente se la direzione di un pacchetto non corrisponde alla relazione di Rango. Un ricevitore rileva un'inconsistenza se riceve un pacchetto con:

• il bit 'O' impostato (verso il basso) da un nodo di un Rango superiore.

• il bit 'O' cancellato (verso l'alto) da un nodo di un Rango inferiore.

Quando la radice del DODAG incrementa il DODAGVersionNumber, può formarsi una discontinuità di Rango temporanea tra la prossima versione DODAG e la precedente versione DODAG, in particolare se i nodi stanno aggiustando il loro Rango nella prossima versione DODAG e differendo la loro migrazione nella prossima versione DODAG. Un router che è ancora membro della precedente versione DODAG può scegliere di inoltrare un pacchetto a un (futuro) genitore che è nella prossima versione DODAG. In alcuni casi, questo potrebbe causare al genitore di rilevare un'inconsistenza perché l'ordinamento dei Ranghi nella precedente versione DODAG non è necessariamente lo stesso che nella prossima versione DODAG, e il pacchetto può essere giudicato come non in progresso in avanti. Se il router mittente è consapevole che il successore scelto si è già unito alla prossima versione DODAG, allora il router mittente DEVE aggiornare il SenderRank a INFINITE_RANK mentre inoltra i pacchetti attraverso la discontinuità nella prossima versione DODAG al fine di evitare una falsa rilevazione di inconsistenza di Rango.

Un'inconsistenza lungo il percorso non è considerata un errore critico e il pacchetto può continuare. Tuttavia, una seconda rilevazione lungo il percorso dello stesso pacchetto non dovrebbe verificarsi e il pacchetto DEVE essere scartato.

Questo processo è controllato dal bit Rank-Error associato al pacchetto. Quando viene rilevata un'inconsistenza su un pacchetto, se il bit Rank-Error non era impostato, allora il bit Rank-Error viene impostato. Se era impostato il pacchetto DEVE essere scartato e il timer Trickle DEVE essere reimpostato.

11.2.2.3. Rilevamento e Recupero dell'Inconsistenza DAO

Il recupero del ciclo di inconsistenza DAO è un meccanismo che si applica solo alla modalità di operazione Storing.

In modalità Non-Storing, i pacchetti sono instradati alla sorgente verso la destinazione, e le inconsistenze DAO non sono corrette localmente. Invece, un errore ICMP con un nuovo codice "Errore nell'intestazione di instradamento alla sorgente" viene inviato indietro alla radice. Il messaggio "Errore nell'intestazione di instradamento alla sorgente" ha lo stesso formato del "Messaggio di destinazione irraggiungibile", come specificato in [RFC4443]. La porzione del pacchetto invocante che viene inviata indietro nel messaggio ICMP dovrebbe registrare almeno fino all'intestazione di instradamento, e l'intestazione di instradamento dovrebbe essere consumata da questo nodo in modo che la destinazione nell'intestazione IPv6 sia il prossimo hop che questo nodo non è riuscito a raggiungere.

Un'inconsistenza DAO accade quando un router ha una rotta verso il basso che è stata precedentemente appresa da un messaggio DAO via un figlio, ma quella rotta verso il basso non è più valida nel figlio, ad esempio, perché quello stato correlato nel figlio è stato ripulito. Con il recupero del ciclo di inconsistenza DAO, un pacchetto può essere utilizzato per esplorare e ripulire ricorsivamente gli stati DAO obsoleti lungo un sub-DODAG.

In modo generale, un pacchetto che va verso il basso non dovrebbe mai andare di nuovo verso l'alto. Se viene applicato il recupero del ciclo di inconsistenza DAO, allora il router DOVREBBE inviare il pacchetto indietro al genitore che lo ha passato con il bit Forwarding-Error 'F' impostato e il bit 'O' lasciato intatto. Altrimenti, il router DEVE scartare silenziosamente il pacchetto.

Alla ricezione di un pacchetto con un bit Forwarding-Error impostato, il nodo DEVE rimuovere gli stati di instradamento che hanno causato l'inoltro a quel vicino, cancellare il bit Forwarding-Error, e tentare di inviare di nuovo il pacchetto. Il pacchetto può essere inviato a un vicino alternativo, dopo la scadenza di un timer specifico dell'implementazione configurabile dall'utente. Se quel vicino alternativo ha ancora uno stato DAO inconsistente via questo nodo, il processo sarà ricorsivo, questo nodo imposterà il bit Forwarding-Error 'F', e lo stato di instradamento nel vicino alternativo sarà anch'esso ripulito.