Subject: [6tisch] DR DIO message format from GD.

From: José Ángel Miranda <[email-masked]>
Date: Wed, 1 Jul 2015 09:29:49 +0200

We found some doubts when reading the DIO message sent by the DODAG Root
from the current GD version:

*1. * The DIO message is encoded with the IPv6 in IPv6 tunneling header. Is
it necessary ?

The minimal-10 draft at section 9.2 states:  " ... In the case that the
packets formed at the LLN need to cross through intermediate routers, these
MUST obey to the IP in IP encapsulation requirement... " ; since DIO
messages do not cross any router, but are sent hop by hop by every RPL
routing node why do we need to encapsulate them with this additional header
and " waste " more than 30 bytes of payload in a low power application like
WSN ?

*2*. The DIO Base byte number 5  ( G | 0 | MOP | Prf ) is seto to " 0xB8 "
; this means  G = 1 , MOP = 7 , Prf = 0 ( this bug has been already
detected by 6TiSCH ).

The RPL Standard at section 6.3.1 defines as assigned modes of operation
only numbers 0 to 3, so MOP = 7 is not admitted by the standard, thus a
node that receives such DIO message will certainly discard it since this
mode of operation is a non-standard one.

* 3*. The DIO message comes without any DIO Option and advertises a rank of
"0x0000" in bytes 3 and 4 of the DIO base.

The RPL standard at section 8.2.2.2 says  " ...  A DODAG root MUST
advertise a Rank of ROOT_RANK  ... " , and defines ROOT_RANK at point 17 as
"... This is the Rank for a DODAG root. ROOT_RANK has a value of
MinHopRankIncrease (as advertised by the DODAG root)   ... " . The
minimal-10 draft at section 9.1.1 states:

"... MinHopRankIncrease: the MinHopRankIncrease is set to the fixed
constant DEFAULT_MIN_HOP_rank_increment [RFC6550].
DEFAULT_MIN_HOP_rank_increment has a value of 256. "

Given that, shouldn't the rank of the DIO message be equal to
MinHopRankIncrease instead than zero ?  Moreover, don't you find
 convenient to insert the  " DODAG configuration option" in the DIO
message, in order to let nodes know how the DODAG works and be configured
accordingly ?

You can find attached a screenshot from the DR's DIO message reception.

------------------------------------------
*Jose A. Miranda Calero*

Embedded Software Engineer

Kirale Technologies S.L.
Logroño - Spain

tel:    +34941578578

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 1 Jul 2015 13:03:56 +0200

Jose,
Thanks a million for your e-mail. I will forward it to the
plugtest-specific ML.
Thomas

On Wed, Jul 1, 2015 at 9:29 AM, José Ángel Miranda <[email-masked]>
wrote:

> *1. * The DIO message is encoded with the IPv6 in IPv6 tunneling header.
> Is it necessary ?
>
> packets formed at the LLN need to cross through intermediate routers,
> these MUST obey to the IP in IP encapsulation requirement... " ; since DIO
> *2*. The DIO Base byte number 5  ( G | 0 | MOP | Prf ) is seto to " 0xB8
> " ; this means  G = 1 , MOP = 7 , Prf = 0 ( this bug has been already
> detected by 6TiSCH ).
>
> * 3*. The DIO message comes without any DIO Option and advertises a rank
> of "0x0000" in bytes 3 and 4 of the DIO base.
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 6 Jul 2015 12:57:48 +0000

Hello José

For 1) I agree that there is no need to encapsulate the DIO. The only message that is not hop by hop is the non-storing DAO, and since it is supposed to be contained in a DODAG, it does not need an extra encapsulation or routing header, but it requires a RPL option.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of José Ángel Miranda
Sent: mercredi 1 juillet 2015 09:30
To: Jacopo Soffritti; [email-masked]
Subject: [6tisch] DR DIO message format from GD.

We found some doubts when reading the DIO message sent by the DODAG Root from the current GD version:

1.  The DIO message is encoded with the IPv6 in IPv6 tunneling header. Is it necessary ?

The minimal-10 draft at section 9.2 states:  " ... In the case that the packets formed at the LLN need to cross through intermediate routers, these MUST obey to the IP in IP encapsulation requirement... " ; since DIO messages do not cross any router, but are sent hop by hop by every RPL routing node why do we need to encapsulate them with this additional header and " waste " more than 30 bytes of payload in a low power application like WSN ?

2. The DIO Base byte number 5  ( G | 0 | MOP | Prf ) is seto to " 0xB8 " ; this means  G = 1 , MOP = 7 , Prf = 0 ( this bug has been already detected by 6TiSCH ).

The RPL Standard at section 6.3.1 defines as assigned modes of operation only numbers 0 to 3, so MOP = 7 is not admitted by the standard, thus a node that receives such DIO message will certainly discard it since this mode of operation is a non-standard one.

 3. The DIO message comes without any DIO Option and advertises a rank of "0x0000" in bytes 3 and 4 of the DIO base.

The RPL standard at section 8.2.2.2 says  " ...  A DODAG root MUST advertise a Rank of ROOT_RANK  ... " , and defines ROOT_RANK at point 17 as "... This is the Rank for a DODAG root. ROOT_RANK has a value of MinHopRankIncrease (as advertised by the DODAG root)   ... " . The minimal-10 draft at section 9.1.1 states:

"... MinHopRankIncrease: the MinHopRankIncrease is set to the fixed constant DEFAULT_MIN_HOP_rank_increment [RFC6550]. DEFAULT_MIN_HOP_rank_increment has a value of 256. "

Given that, shouldn't the rank of the DIO message be equal to MinHopRankIncrease instead than zero ?  Moreover, don't you find  convenient to insert the  " DODAG configuration option" in the DIO message, in order to let nodes know how the DODAG works and be configured accordingly ?

Jose A. Miranda Calero

[https://docs.google.com/a/kirale.com/uc?id=0B2YgpSi01ToPSHljY2FMaFluNlk&export=download]