Subject: [Roll] Clarification on SenderRank in RPL HbH option

From: Dario Tedeschi <[email-masked]>
Date: Tue, 09 Oct 2012 11:50:42 -0700

While writing ZigBee-IP test procedures for RPL and discussing with 
other ZigBee-IP members, it appears there may be an error in RFC 6550.

RFC 6550 says:

   SenderRank: 16-bit field set to zero by the source and to
          DAGRank(rank) by a router that forwards inside the RPL network.

Firstly, it seems wrong that the source of a datagram would set its 
SenderRank to zero. If this packet were moving up the DAG the first 
forwarder would set the Rank-Error bit to 1, because the SenderRank 
field in the HbH option would be lower than its own rank. Similarly, if 
the datagram were mistakenly moving down the DAG, where the source's 
real rank was higher than the forwarder's rank a potential routing loop 
could be missed.

Secondly, why is DAGRank(rank) used to set SenderRank, when SenderRank 
is a 16bit field. Wouldn't doing this allow for potential routing loops 
to be missed?

Could someone (preferably one of the RPL authors) please clarify.

- Dario

---

From: Dario Tedeschi <[email-masked]>
Date: Tue, 16 Oct 2012 09:28:51 -0700

Can anyone clarify this for me or at least indicate if it has already 
been discussed some time in the past.

- Dario

On 09/10/2012 11:50 AM, Dario Tedeschi wrote:
> field in the HbH option would be lower than its own rank. Similarly, 
> if the datagram were mistakenly moving down the DAG, where the 
> source's real rank was higher than the forwarder's rank a potential 
> routing loop could be missed.
>
> is a 16bit field. Wouldn't doing this allow for potential routing 
> loops to be missed?
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 17 Oct 2012 17:22:26 +0000

Hello Dario:

One thing is "A DODAG root MUST advertise a Rank of ROOT_RANK" ==1  which means that zero is non sensical as a Rank.

Instead, RPL allows a node that is not a router for this instance and this DODAG Version to set the Rank to zero meaning 'I do not have a Rank in that Version, I'm a dumb leaf'
In that case the packet is injected by the first router in the RPL domain and that router is responsible for setting the initial RANK.
Till then the Rank is non-sensical and cannot be used. In particular, that is a way for us to support non-RPL nodes at the edge of the RPL network, and it is compatible with the RPL information carried in the flow label.

One might envision a mote as a collapsed dumb host and router, and virtually one can figure that both operations happen inside the mote between the two, so the packet is emitted over the radio by the router piece with a correct Rank.

For the second point, DAGRank(Rank) must be strictly monotonical. In the case above that is the floor of the Rank of the router. How exactly can that miss a loop?

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dario Tedeschi
Sent: mardi 16 octobre 2012 18:29
To: [email-masked]
Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option

Can anyone clarify this for me or at least indicate if it has already been discussed some time in the past.

- Dario

> Could someone (preferably one of the RPL authors) please clarify.

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 17 Oct 2012 12:14:39 -0700

Hi Pascal

Thanks for the response. Please see my comments in line.

Regards
Dario

> One might envision a mote as a collapsed dumb host and router, and virtually one can figure that both operations happen inside the mote between the two, so the packet is emitted over the radio by t…

So if a node is *not* acting as a leaf node and it originates a packet, 
should it set the SenderRank field to its real integer rank (i.e. 
DAGRank(Rank) or zero?

> For the second point, DAGRank(Rank) must be strictly monotonical. In the case above that is the floor of the Rank of the router. How exactly can that miss a loop?

I admit that, after running through several scenarios on paper, it does 
appear highly unlikely. I was just concerned that DAGRank() truncates 
rank information that might be needed for loop detection, but I can't 
qualify that or come up with any good examples.

---

From: Pascal Thubert <[email-masked]>
Date: Wed, 17 Oct 2012 22:01:08 +0200

Hi Dario;

A node that is not a leaf and participates to RPL is a router and therefore must advertize its real nonZero Rank...

Cheers,

Pascal

Le 17 oct. 2012 à 21:14, Dario Tedeschi <[email-masked]> a écrit :

> So if a node is *not* acting as a leaf node and it originates a packet, should it set the SenderRank field to its real integer rank (i.e. DAGRank(Rank) or zero?
> 
> 
> I admit that, after running through several scenarios on paper, it does appear highly unlikely. I was just concerned that DAGRank() truncates rank information that might be needed for loop detection, but I can't qualify that or come up with any good examples.
> 
>> Cheers,
>> 
>> Pascal
>>

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 17 Oct 2012 14:12:07 -0700

Ok, then I think the following text in RFC 6550 is misleading:

"""
"""

It should be something like:

   SenderRank: 16-bit field set to DAGRank(rank) by a RPL router or to zero
           by a source that is only acting as leaf node inside a RPL 
network.

What do you think?

- Dario

On 17/10/2012 1:01 PM, Pascal Thubert wrote:
> Le 17 oct. 2012 à 21:14, Dario Tedeschi<[email-masked]>  a écrit :
>
>> Hi Pascal
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Oct 2012 08:34:25 +0000

Hi Dario:

It's probably  a bit late to change anything here... In any case I think that set 
' to  DAGRank(rank) by a router that forwards inside the RPL network' is very clear.

Note that a RPL router may forward the packet outside the RPL domain. In which case your proposal fails.
Also, the term source allows for a host that is not even a RPL leaf, and that's an important use case for us. 

All in all, every sentence is touchy, was hard to agree upon, and at least that one does not say anything wrong.

Cheers,

Pascal

-----Original Message-----
From: Dario Tedeschi [mailto:[email-masked]] 
Sent: mercredi 17 octobre 2012 23:12
To: Pascal Thubert
Cc: Pascal Thubert (pthubert); [email-masked]
Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option

"""

   SenderRank: 16-bit field set to DAGRank(rank) by a RPL router or to zero
           by a source that is only acting as leaf node inside a RPL network.

What do you think?

- Dario

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 18 Oct 2012 10:47:59 +0200

Hi Dario and Pascal

I think we can errata it as it can reduce any doubts, if the WG agrees
to such comment. For me I agree your comment, and recommend to discuss
errata further.

AB

On 10/18/12, Pascal Thubert (pthubert) <[email-masked]> wrote:
>> A node that is not a leaf and participates to RPL is a router and
>> therefore must advertize its real nonZero Rank...
>>
>> Cheers,
>>
>> Pascal
>>
>>>> One thing is "A DODAG root MUST advertise a Rank of ROOT_RANK" ==1
>>>> which means that zero is non sensical as a Rank.
>>>>
>>>> Instead, RPL allows a node that is not a router for this instance and
>>>> this DODAG Version to set the Rank to zero meaning 'I do not have a Rank
>>>> in that Version, I'm a dumb leaf'
>>>> In that case the packet is injected by the first router in the RPL
>>>> domain and that router is responsible for setting the initial RANK.
>>>> Till then the Rank is non-sensical and cannot be used. In particular,
>>>> that is a way for us to support non-RPL nodes at the edge of the RPL
>>>> network, and it is compatible with the RPL information carried in the
>>>> flow label.
>>>>
>>>> One might envision a mote as a collapsed dumb host and router, and
>>>> virtually one can figure that both operations happen inside the mote
>>>> between the two, so the packet is emitted over the radio by the router
>>>> piece with a correct Rank.
>>>> For the second point, DAGRank(Rank) must be strictly monotonical. In the
>>>> case above that is the floor of the Rank of the router. How exactly can
>>>> that miss a loop?