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

[Abdussalam Baryun <[e-mail]>]

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) <[e-mail]> wrote:
> 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:[e-mail]]
> Sent: mercredi 17 octobre 2012 23:12
> To: Pascal Thubert
> Cc: Pascal Thubert (pthubert); [e-mail]
> Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option
>
> Ok, then I think the following text in RFC 6550 is misleading:
>
> """
>    SenderRank: 16-bit field set to zero by the source and to
>           DAGRank(rank) by a router that forwards inside the RPL network.
> """
>
> 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:
>> 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<[e-mail]>  a écrit :
>>
>>> Hi Pascal
>>>
>>> Thanks for the response. Please see my comments in line.
>>>
>>> Regards
>>> Dario
>>>
>>> On 17/10/2012 10:22 AM, Pascal Thubert (pthubert) wrote:
>>>> 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.
>>> 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.
>>>
>>>> Cheers,
>>>>
>>>> Pascal
>>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>>> Dario Tedeschi
>>>> Sent: mardi 16 octobre 2012 18:29
>>>> To: [e-mail]
>>>> 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
>>>>
>>>> On 09/10/2012 11:50 AM, Dario Tedeschi wrote:
>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> Roll mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/roll
>>> _______________________________________________
>>> Roll mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>