Subject: [Roll] Writing SenderRank in flow label.

From: "JeongGil Ko (John)" <[email-masked]>
Date: Thu, 18 Feb 2010 10:19:43 -0800

Hi!

I see an issue with how the usage of the flow label is specified in Section 7.2. Section 7.2.1 of the rpl draft v6 states the following, " A packet that is sourced at a node connected to a RPL network or destined to a node connected to a RPL network MUST be issued with the flow label zeroed out, but for the RPLInstanceID field."

However, the details in 7.2 and also intuitively, the SenderRank should also be set when the packet is issued at the source node and modified as the packet passes router nodes in the RPL network. When the SenderRank is set as zero (as what the draft states) the first router that receives this message can notice that it is the first hop of the packet's forwarding process (since the SenderRank is set to zero and no such rank should exist, given that the rank of the DODAG root is 1) and proceed the forwarding process, but it will not be able to check if this forwarding process is valid or not (procedures specified in Sections 7.2.2.*). I agree that this breaks the compliance with RFC 3697 that Section 7.2.2.1 discusses (since it is difficult to know what the initial senderRank was) but I still think we would need the sender rank in place when the packet is initially issued, at least for the sake of consistency. Given that RPL's modification of the flow label becomes tricky when packets from 'outer-RPL' networks flow in to RPL networks (it is hard to know what the original flow label was after modifications within the RPL network), I think we should start thinking of ways to break out of the flow label field and configure a new header format maybe :)

Thanks.

-John

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 18 Feb 2010 10:32:13 -0800

Hi John,

We cannot assume that the source and/or destination node is running  
RPL, let alone having some information about the Rank of it's  
attachment router.  Also, when receiving a packet from the source node  
or delivering a packet to the destination node, no loops occur since  
you know you're one end of the path.  Loops only occur among  
forwarding routers and only they must be concerned with setting the  
appropriate data-path fields necessary for loop-detection/recovery.   
Of course, if the source/destination is a RPL router, then the node  
*could* set the fields appropriately and maybe the text should be  
changed to allow this.

As for where to carry the bits, we are currently investigating other  
options (in addition to the flow label).  They all have their pros/cons.

--
Jonathan Hui

On Feb 18, 2010, at 10:19 AM, JeongGil Ko (John) wrote:

> Hi!
>
> I see an issue with how the usage of the flow label is specified in  
> Section 7.2. Section 7.2.1 of the rpl draft v6 states the following,  
> " A packet that is sourced at a node connected to a RPL network or  
> destined to a node connected to a RPL network MUST be issued with  
> the flow label zeroed out, but for the RPLInstanceID field."
>
> However, the details in 7.2 and also intuitively, the SenderRank  
> should also be set when the packet is issued at the source node and  
> modified as the packet passes router nodes in the RPL network. When  
> the SenderRank is set as zero (as what the draft states) the first  
> router that receives this message can notice that it is the first  
> hop of the packet's forwarding process (since the SenderRank is set  
> to zero and no such rank should exist, given that the rank of the  
> DODAG root is 1) and proceed the forwarding process, but it will not  
> be able to check if this forwarding process is valid or not  
> (procedures specified in Sections 7.2.2.*). I agree that this breaks  
> the compliance with RFC 3697 that Section 7.2.2.1 discusses (since  
> it is difficult to know what the initial senderRank was) but I still  
> think we would need the sender rank in place when the packet is  
> initially issued, at least for the sake of consistency. Given that  
> RPL's modification of the flow label becomes tricky when packets  
> from 'outer-RPL' networks flow in to RPL networks (it is hard to  
> know what the original flow label was after modifications within the  
> RPL network), I think we should start thinking of ways to break out  
> of the flow label field and configure a new header format maybe :)
>
> Thanks.
>
> -John
>
> ------
> JeongGil Ko (John)
> Ph.D. Student
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll