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

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 May 2014 11:51:37 +1200

On 18/04/2014 02:27, Pascal Thubert (pthubert) wrote:
> 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.

The proposal really does three things:

1. Asserts (implicitly) that a ROLL domain is really, truly, absolutely
separated from the Internet at layer 3 except for traffic through its
root node (acting as a border router).

I think that needs to be stated very explicitly as a fundamental
requirement for this spec to be acceptable.

2. It recommends that the root rewrites the flow label on
outbound packets according to the provisions in RFC 6437.
The slight deviation from RFC 6437 purism there is that it
treats the existing flow label on the packets as if it was zero.

3. It requires that the root rewrites the flow label
on inbound packets even if they are already set to non-zero.
That is indeed a violation of RFC 6437. But it is a violation
we have already accepted in another case: "for compelling operational
security reasons". What's lost? The ability for nodes
inside the ROLL domain to perform flow-label based load balancing
for such inbound packets. I think it's for ROLL and 6TISCH
to say whether that loss matters.

In my opinion, we shouldn't be religious about this as long
as point 1 is guaranteed. I don't see any risks to the generic
use of the flow label.

I think the language around the relationship with RFC 6437
is a bit defensive at the moment and could probably be a bit
simpler and clearer. ("The following exceptions to the rules
in [RFC6437] are made:..."). I'd have a preference for doing that
without a formal update to 6437, because it's only RPL implementors
who need to change anything.

    Brian

> 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: Pat Kinney <[email-masked]>
Date: Thu, 1 May 2014 11:39:42 -0500

Dear All;

Over the past 8 years ISA100 has been involved with wireless industrial networks using battery operated wireless modules that must last at least 10 years on a single battery.  Since these applications are typically low data rate (50 - 250 kb/s), and TDMA for low energy usage, these industrial networks use the IEEE 802.15.4 MAC/PHY standard.  Since industrial environments contain significant interference, using shorter packet durations significantly increase the likelihood of a successful message receipt, dramatically reducing retries which consume energy and reduce network throughput.
 
ISA100 worked with the IETF to allow ISA's first wireless standard, ISA100.11a that is now shipping, to use IPv6 with the 6LoWPAN header compression (RFC6282) at the network layer with a string critical requirement to keep the frame size minimal so as to stay under the 127 bytes limit as per the 802.15.4.  ISA100 would now like to consider a wireless industrial standard using the full 6TiSCH suite and in particular RPL (RFC 6550) and the backbone router technology; however using the RPL option in a Hop-by-Hop header as proposed in RFC6553 would add an additional 8 bytes to the packet.  Regretfully, this additional overhead can't be tolerated since it would result in security configuration packets (and others) being larger than the 127 byte limit. 
 
As a co-chair of ISA100 as well as the editor of ISA100.11a-2011, I would ask the IETF 6man to seriously consider adopting draft-thubert-6man-flow-label-for-rpl that combines optimally with RFC6282 for a minima overhead in the compressed packet. 

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked]

On Apr 17, 2014, at 9:26 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

Dear all;

Cheers,
 
Pascal

 
X.

2014-04-16 22:44 GMT+02:00 Ines Robles <[email-masked]>:
+1
 
Ines
 
2014-04-15 21:19 GMT-03:00 Qin Wang <[email-masked]>:
+1
 
Qin
On Wednesday, April 16, 2014 1:47 AM, Prof. Diego Dujovne <[email-masked]> wrote:
+1 !

2014-04-15 12:25 GMT-03:00 Tom Phinney <[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:25, Pascal Thubert (pthubert) wrote:
Dear all:

 

 
Cheers,
 
Pascal

[email-masked]

[email-masked]

www.ingenieria.udp.cl
(56 2) 676 8125
 
[email-masked]

[email-masked]

[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 May 2014 13:32:09 +0000

Hi Brian:

Thanks a bunch for your review and support:

To address your issues, what would you think about:

" 

1.1.  Applicability

   This specification applies to a RPL [RFC6282] domain that forms a
   stub LLN and is connected to the Internet by and only by its RPL
   root(s), which act(s) as Border Router(s) for the LLN. With RPL, a
   root is the bottleneck for all the traffic between the Internet and
   the Destination-Oriented Directed Acyclic Graph (DODAG) that it
   serves.

   In that context, the specification entitles a RPL root to rewrite the
   IPv6  [RFC2460] Flow Label of all packets entering or leaving the RPL
   domain in both directions, from and towards the Internet, regardless
   of the original setting.  This may seem contradictory with the IPv6
   Flow Label Specification  [RFC6437] which stipulates that once it is
   set, the Flow Label is left unchanged; but the RFC also indicates a
   violation to the rule can be accepted for compelling reasons, and
   that security is a case justifying such a violation.

   This specification suggests that energy-saving, which is the crux of
   most LLN applications, is another compelling reason for a violation
   to the aforementioned rule, and that the violation is acceptable as
   long as 1) it is contained within the RPL domain and 2) the IPv6 Flow
   Label is rewritten in a manner that conforms the prescriptions of
   [RFC6437].

"

I'm adding some more text to address your points 2 and 3, but it seems to me that the above is what addresses the core of your suggestion.
Does that seem OK?

Cheers,

Pascal

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: vendredi 2 mai 2014 01:52
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]; [email-masked]; roll; Xavier Vilajosana; Ines Robles
> > 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.
> 
> 1. Asserts (implicitly) that a ROLL domain is really, truly, absolutely separated
> from the Internet at layer 3 except for traffic through its root node (acting as
> a border router).
> 
> I think that needs to be stated very explicitly as a fundamental requirement
> for this spec to be acceptable.
> 
> 2. It recommends that the root rewrites the flow label on outbound packets
> according to the provisions in RFC 6437.
> The slight deviation from RFC 6437 purism there is that it treats the existing
> flow label on the packets as if it was zero.
> 
> 3. It requires that the root rewrites the flow label on inbound packets even if
> they are already set to non-zero.
> That is indeed a violation of RFC 6437. But it is a violation we have already
> accepted in another case: "for compelling operational security reasons".
> What's lost? The ability for nodes inside the ROLL domain to perform flow-
> label based load balancing for such inbound packets. I think it's for ROLL and
> 6TISCH to say whether that loss matters.
> 
> In my opinion, we shouldn't be religious about this as long as point 1 is
> guaranteed. I don't see any risks to the generic use of the flow label.
> 
> I think the language around the relationship with RFC 6437 is a bit defensive
> at the moment and could probably be a bit simpler and clearer. ("The
> following exceptions to the rules in [RFC6437] are made:..."). I'd have a
> preference for doing that without a formal update to 6437, because it's only
> RPL implementors who need to change anything.
> 
>     Brian
> 
> > Cheers,
> >
> > Pascal
> >
> > +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.
> > ===
> >
> > 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!
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 May 2014 13:06:57 +1200

> To address your issues, what would you think about:

Yes, IMHO it's clear and allows for a clear decision.

Thanks
    Brian