Re: [6lo] Comparison of 6lo-rpl drafts

["Pascal Thubert (pthubert)" <[e-mail]>]

Typo below, please read:



> I picked position 1, because we need 3 bits for RPL, TWO bitS for the

> proposed compression format, and then one bit for the NH flag.



Proposed rpl-nhc:

            0   1   2   3   4   5   6   7

          +---+---+---+---+---+---+---+---+

          | 1 | 0 | I | K | O | R | F |NH |

          +---+---+---+---+---+---+---+---+



Classical 6lowpan-nhc:

            0   1   2   3   4   5   6   7

          +---+---+---+---+---+---+---+---+

          | 1 | 1 | 1 | 0 |    EID    |NH |

          +---+---+---+---+---+---+---+---+



Classical udp-nhc:
            0   1   2   3   4   5   6   7
          +---+---+---+---+---+---+---+---+
          | 1 | 1 | 1 | 1 | 0 | C |   P   |
          +---+---+---+---+---+---+---+---+



Cheers,



Pascal





> -----Original Message-----

> From: Pascal Thubert (pthubert)

> Sent: jeudi 18 septembre 2014 10:27

> To: 'Carsten Bormann'; Martin Turon

> Cc: [e-mail]; [e-mail]

> Subject: RE: [6lo] Comparison of 6lo-rpl drafts

>

> Hello Carsten and Martin;

>

> One thing we need to be very clear on is the way LOWPAN_NHC works in

> 6282. That's very different from the dispatch type for instance.

>

> You have a sequence on 1's followed by a 0. The number of 1's tell you what

> the LOWPAN_NHC type is. The bits after the first 0 are used for the specific

> use of that NHC.

>

> With three 1's (first 0 at position 3, that is the fourth bit) the NHC an

> enumeration if classical NHCs, used to enable the compression of whatever

> comes after (eg UDP) without saving anything on that particular header.

> With four 1's (first 0 at position 4) the NHC is UDP. We picked it because we

> could compress UDP with 3 bits in the LOWPAN_NHC.

> Which leaves us with 6 possibilities for the first 0 at positions 0, 1, 2, 5, 6 and

> 7.

>

> I picked one position 1, because we need 3 bits for RPL, one bit for the

> proposed compression format, and then one bit for the NH flag.

> Because we need to kept the headers bytes-aligned, using a different

> encoding would probably lead us to one more octet overall, which would be

> very bad news for a 6lo based solution.

>

> That would leave us with 5 more positions for the future out of  a total 8 at

> the beginning of times.

>

> With this clearly in mind, would you suggest a different compression format?

>

> Pascal

>

>

> > -----Original Message-----

> > From: Carsten Bormann [mailto:[e-mail]]

> > Sent: mardi 16 septembre 2014 22:59

> > To: Pascal Thubert (pthubert)

> > Cc: Tisch; Martin Turon; [e-mail]<mailto:[e-mail]>

> > Subject: Re: [6lo] Comparison of 6lo-rpl drafts

> >

> > Hi Pascal,

> >

> > being back in the office, I have now looked at draft-thubert-6lo-rpl-nhc-01.

> > Section 4/5 works for me: this is a nicer solution than the one I derived.

> > (As with my draft, some additional text is needed to discuss how a hbh

> > header that contains a RPL option beside other hbh option(s) is to be

> > handled.)

> >

> > Honestly, I'm not so hot about the verbiage in Section 1/2 of the draft.

> > If we could get a draft that just contains the parts that need

> > consensus, I could mark draft-bormann-6lo-rpl-mesh-01.txt as

> > replaced-by that updated version, removing some of the current

> > confusion about the way forward on this.

> >

> > Using up 1/4 of the RFC 6282 NHC space for the RPL hbh option strikes

> > me as expensive, even if we only have used ~ 1/8 of that space yet

> > (GHC will need ~ another 1/16).

> > (I think this is the essence of Martin's comment, too.) If we want to

> > work further on this draft, we should look for ways moving this down

> > to, say, 1/8, without unduly increasing complexity.

> > E.g., we could get rid of the forwarding-error bit, as that applies to

> > storing mode only (we could use one additional NHC code, followed by

> > the rest of the NHC code, to indicate a forwarding-error if people

> > really think storing mode needs to be kept alive).

> >

> > Note that we'll need another chunk of the NHC space to compress RFC

> > 6554, so the total usage for RPL will be even higher.  (I tried to

> > initiate the discussion for this with my question whether we need to

> > stick with the reversible "segments left" model of RFC 6554 or can

> > discard addresses that have been traversed.  If nobody has an opinion

> > on this, I might want to go ahead and propose something.)

> >

> > Grüße, Carsten