Subject: [Roll] DIO compression option

From: "Turner, Randy" <[email-masked]>
Date: Thu, 24 Sep 2015 15:24:11 +0000

Yes, I think that's what I'm doing with the compression context option (syntactically recreating it for DIO) - the options' interpretation is identical to RFC 6775 - the only difference I can possibly see between the 6775 text and the option I proposed is regarding "when" these options might appear in DIOs from the root.

Randy

Re: [Roll] DIO compression option
Carsten Bormann <[email-masked]> Thu, 24 September 2015 14:45 UTCShow header
> Yes, I mentioned this in Prague (the fact that 6775 6CO already exists).
>  The Zigbee NAN group decided that the additional traffic imposed by
> neighbor discovery was not required (in the presence of DIO and DIO
> options) - however, we still would like to receive compression options,
> and we've already paid the DIO price traffic-wise, so we're piggy
> backing the compression option onto DIOs we're already handling.
>
>
>
> I'm trying to maintain the context lifecycles per 6775, so the existing
> text will be modified to include the "lifetime" field in the option (the
> "C" bit already exists)

So is the observation fair that this is essentially about repackaging
6CO into the syntactic environment of a ROLL message?

I think we could do that for the rest of the 6Lo-ND messages as well and
reduce the cognitive dissonance of sending ND information with ROLL
messages.

Grüße, Carsten

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Cenk Gündogan <[email-masked]>
Date: Thu, 24 Sep 2015 22:55:53 +0200

Hello Carsten, Pascal, Randy, *

I like the idea of having the 6CO included into RPL, simply because it 
already includes the PIO
and there is no RPL-ish way to tag any prefix information with context 
identifiers in 6LoWPANs.
Hence, and that is just my opinion, it is not desired, but a necessity 
to add the 6CO to RPL's
known options list.

Also: RFC 6775#1.4 clearly states that in order to substitute multihop 
prefix distribution,
it is also necessary to substitute the distribution of header 
compression contexts.
To quote RFC 6775 "... [they] go hand in hand."

With this quote in mind, adding the 6CO to RPL and using them (PIO + 
6CO) in DIOs could be
the first step in dropping the ABRO overhead in RA messages when using 
RPL in a 6LoWPAN.
Currently, running RPL and 6LoWPAN-ND simultaneously would require to 
handle the versioning
of DODAGs (by DODAG root) and the versioning of ABRO related information 
(PIO + 6CO) (by 6LBR).
Without looking too much into details, and please correct me if I am 
wrong, but:
The ABRO and the DIO seem to have a few similarities. Both have 
versioning and both have a
concept of an "origin" (DODAG-ID <-> 6LBR Address).

So, wouldn't it be possible to abandon the ABRO in RPL domains where RPL 
also controls the PIOs and 6COs ?

Cheers,
Cenk

On 24.09.2015 17:24, Turner, Randy wrote:
>
> Yes, I think that’s what I’m doing with the compression context option 
> (syntactically recreating it for DIO) – the options’ interpretation is 
> identical to RFC 6775 – the only difference I can possibly see between 
> the 6775 text and the option I proposed is regarding “when” these 
> options might appear in DIOs from the root.
>
> Randy
>
> > options) – however, we still would like to receive compression options,
>
> > and we’ve already paid the DIO price traffic-wise, so we’re piggy
>
> > backing the compression option onto DIOs we’re already handling.
>
> >
>
> >
>
> >
>
> > I’m trying to maintain the context lifecycles per 6775, so the existing
>
> > text will be modified to include the “lifetime” field in the option (the
>
> > “C” bit already exists)
>
> This e-mail (including any attachments) is confidential and may be 
> legally privileged. If you are not an intended recipient or an 
> authorized representative of an intended recipient, you are prohibited 
> from using, copying or distributing the information in this e-mail or 
> its attachments. If you have received this e-mail in error, please 
> notify the sender immediately by return e-mail and delete all copies 
> of this message and any attachments. Thank you.
>
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Sep 2015 08:19:34 +0000

Hello Cenk

The 6TiSCH architecture is the first IETF effort that combines RPL and 6LoWPAN ND and suggests a way of putting them together. The effort is not complete but it raises that sort of coexistence problem.

One of the conclusions is that the 6BBR and the RPL root should be collocated so that a root gets a device unique ID (from 6LoWPAN ND) and a sequence counter (from RPL) since in practice both are needed for the backbone router operation. The architecture also suggests that RPL DAO sequence counter should be used as TID in an extended ARO option.

This conclusion matches yours that even though the 2 protocols are designed to survive stand alone, some simplifications and pairings are needed when they coexist.

ABRO is not the only one. The DIO does not provide the router SLLA for instance, so the RA is still needed for that as well.

I’ll support, and even contribute if needed, to work at ROLL that allows ABRO, SLLAO, MTUO and 6CO in DIOs. The work may impact the DIS that can be used to request some options that do not need to be carried in all DIOs in a fashion similar to the DODAG Configuration option. It may also discuss in more details how DIOs are sent on constrained maximum frame size when multiple options are needed.

Question to the chairs: is that work within WH charter boundaries?

Cheers,

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Cenk Gündogan
Sent: jeudi 24 septembre 2015 22:56
To: [email-masked]
Subject: Re: [Roll] DIO compression option

I like the idea of having the 6CO included into RPL, simply because it already includes the PIO
and there is no RPL-ish way to tag any prefix information with context identifiers in 6LoWPANs.
Hence, and that is just my opinion, it is not desired, but a necessity to add the 6CO to RPL's
known options list.

Also: RFC 6775#1.4 clearly states that in order to substitute multihop prefix distribution,
it is also necessary to substitute the distribution of header compression contexts.
To quote RFC 6775 "... [they] go hand in hand."

With this quote in mind, adding the 6CO to RPL and using them (PIO + 6CO) in DIOs could be
the first step in dropping the ABRO overhead in RA messages when using RPL in a 6LoWPAN.
Currently, running RPL and 6LoWPAN-ND simultaneously would require to handle the versioning
of DODAGs (by DODAG root) and the versioning of ABRO related information (PIO + 6CO) (by 6LBR).
Without looking too much into details, and please correct me if I am wrong, but:
The ABRO and the DIO seem to have a few similarities. Both have versioning and both have a
concept of an "origin" (DODAG-ID <-> 6LBR Address).

So, wouldn't it be possible to abandon the ABRO in RPL domains where RPL also controls the PIOs and 6COs ?

Cheers,
Cenk

Yes, I think that’s what I’m doing with the compression context option (syntactically recreating it for DIO) – the options’ interpretation is identical to RFC 6775 – the only difference I can possibly see between the 6775 text and the option I proposed is regarding “when” these options might appear in DIOs from the root.

Randy

Re: [Roll] DIO compression option
Carsten Bormann <[email-masked]><mailto:[email-masked]> Thu, 24 September 2015 14:45 UTCShow header

Grüße, Carsten

Roll mailing list

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

---

From: Joakim Eriksson <[email-masked]>
Date: Fri, 25 Sep 2015 14:42:48 +0200

I also promote thinking and developments in this direction. RPL and 6LoWPAN ND do have overlaps and if we can add
more options to DIOs that would probably simplify implementations significantly. We would be happy
to help out test some of these ideas in ContikiRPL.

Best regards,
— Joakim Eriksson, SICS Swedish ICT

> On 25 Sep 2015, at 10:19, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Cenk
>  
> From: Roll [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Cenk Gündogan
> To: [email-masked] <mailto:[email-masked]>
> Carsten Bormann <[email-masked]> <mailto:[email-masked]> Thu, 24 September 2015 14:45 UTCShow header
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>