Subject: [6tisch] [Roll] Support of flow label to carry the RPL information in data packets

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 17 Apr 2014 14:27:29 +0000

Dear all;

Considering the support we have at 6TiSCH and ROLL for the work, I published draft-thubert-6man-flow-label-for-rpl-00.txt to the 6MAN WG.
The main discussion is probably to confirm whether our proposed use of the flow label inside the RPL domain is compatible with the goals that are achieved by RFC6437. Let us continue the discussion there from now on.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: jeudi 17 avril 2014 10:00
To: Ines Robles
Cc: Pascal Thubert (pthubert); [email-masked]; roll
Subject: Re: [6tisch] [Roll] Support of flow label to carry the RPL information in data packets

+1 I think this is more than needed. In addition RFC 6282 defines how header compression needs to be handled together with extension headers. I think this is not clear and leads to confusions (afecting already some wireshark dissectors). The use of flow label will solve several problems at once.

X.

2014-04-16 22:44 GMT+02:00 Ines Robles <[email-masked]<mailto:[email-masked]>>:
+1

Ines

2014-04-15 21:19 GMT-03:00 Qin Wang <[email-masked]<mailto:[email-masked]>>:
+1

Qin
On Wednesday, April 16, 2014 1:47 AM, Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>> wrote:
+1 !

2014-04-15 12:25 GMT-03:00 Tom Phinney <[email-masked]<mailto:[email-masked]>>:
+1 for sure. The flow label has always been the preferable method for me, and I suspect for others with knowledge of how it is used in ISA100.11a.
===

On 2014.04.15 07<tel:2014.04.15%2007>:25, Pascal Thubert (pthubert) wrote:
Dear all:

As some of you remember, the RPL specification has changed over time WRT to the location of the information that RPL places in the data packets. We started with the flow label but these were the days when what became RFC 6437 was being defined at 6MAN, so we shied away and defined the HbH technique that is now specified as RFC 6553.

We’ll note that the RPL option defined in RFC 6553 takes 6 octets, and with the HbH hdr we end up with 8 extra octets. An extra IP-in-IP encapsulation is required on top of that unless both endpoints are in the same RPL domain. All this overhead may be acceptable when power is available and the PHY allows for larger frames, but in traditional battery-operated 15.4 with ~ 80 bytes usable per frame, my experience from integrating 6LoWPAN HC with ISA100.11a says that all these extra bytes will be on the way of the 6TiSCH adoption.

Still, both RFC 6550 and RFC 6552 are designed to allow for an alternate technique and in particular for the use of the flow label, as is elaborated in http://tools.ietf.org/html/draft-thubert-roll-flow-label-02 . Using the flow label reduces the cost of the RPL information dramatically, down to a level that is probably acceptable for the target SDOs.

So my plan for now is to move the flow label draft to 6MAN and prepare for a hot season, and I’m looking for support from both 6TiSCH and ROLL to back me up from the start.  Yes, you can help!

Please +1 if you agree we need this work to happen, and/or provide any suggestion.

Cheers,

Pascal

_______________________________________________

6tisch mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl/>
(56 2) 676 8125<tel:%2856%202%29%20676%208125>

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

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

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Apr 2014 11:49:24 -0300

Hi, Pascal,

On 04/17/2014 11:27 AM, Pascal Thubert (pthubert) wrote:
> 
> Considering the support we have at 6TiSCH and ROLL for the work, I
> published draft-thubert-6man-flow-label-for-rpl-00.txt to the 6MAN WG.
> 
> The main discussion is probably to confirm whether our proposed use of
> the flow label inside the RPL domain is compatible with the goals that
> are achieved by RFC6437. Let us continue the discussion there from now on.

I just skimmed through the I-D. Two quick questions:

1) Does your document propose/require that the Flow Label be rewritten
by some border router? -- I ask because, at the time, there was strong
opposition to this.

2) Does the algorithm/scheme with which you'll rewrite the Flow-Label
lead to predictable sequences? And/or, would the resulting values have a
uniform distribution?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 17 Apr 2014 17:08:02 +0000

Hello Fernando

Thanks for your review, and we can certainly use some piece of advice from you here:

1) Yes, the idea is that leaves of a RPL network do not use the flow label. Inside the RPL domain it is used to support RPL operations. 
At the border router, which is a RPL root, it is finally set to the value that is visible in the Internet. I can expect some knee jerk about this proposal but before rejecting in on some principle we must consider the benefits in IoT applications, and whether the interests that the flow label serves in the core can still be enabled with this proposal.

2) The draft did not finalize the way the Flow Label is computed in the Internet side. If we agree on the principle then we can work out the details.

To give you an idea, my mind is to compute classically a hash for a given flow.

The root is expected to have a policy that indicates whether the original source address is relevant or not in the identification of a flow (it is not for a compound flow that we do not want to see separated in the Internet). The instance ID that is in the original flow label is certainly relevant and is used in the hash computation. A random computed by the root at boot would be useful as well.

We expect few flows to emerge from a given RPL root, and even fewer from a given constrained device.
The random and the hash are really there to enable load balancing between flows out of different backbone routers.

Cheers,

Pascal

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: jeudi 17 avril 2014 16:49
> To: Pascal Thubert (pthubert); [email-masked]
> Cc: [email-masked]; Ines Robles; roll
> 1) Does your document propose/require that the Flow Label be rewritten by
> some border router? -- I ask because, at the time, there was strong
> opposition to this.
> 
> 2) Does the algorithm/scheme with which you'll rewrite the Flow-Label lead
> to predictable sequences? And/or, would the resulting values have a
> uniform distribution?
> 
> Thanks!
> 
> Best regards,
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked] PGP Fingerprint:
> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Apr 2014 08:31:30 +1200

Fernando,

> by some border router? -- I ask because, at the time, there was strong

It was of course contested, but we have to remember that the flow label
is an unauthenticated field, so our interpretation of it has to be
robust against altered values. RFC 6437 indeed covers the case where a
forwarding node sets the flow label.

> lead to predictable sequences? And/or, would the resulting values have a

The same part of RFC 6437 does RECOMMEND a uniform distribution.

Also, the very first paragraph of RFC 6437 states that "a flow is not
necessarily 1:1 mapped to a transport connection", so there is reasonable
flexibility.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Apr 2014 19:43:44 -0300

Hi, Brian,

> forwarding node sets the flow label.

FWIW, I was just asking to get an overall/quick understanding of where
they wanted to go, and contrast that where 6man seemed to want to go at
the time. Just that. IHMO, if the point/use case is valid, we should
"evaluate" their proposal (i.e., by no means I was meaning "6man doesn't
like that, forget it".)

> The same part of RFC 6437 does RECOMMEND a uniform distribution.

Agreed. Again, I was checking the extent to which they might be
deviating from that was set here.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492