Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-05

From: Carsten Bormann <[email-masked]>
Date: Sun, 20 Sep 2009 16:55:31 +0200

Jonathan,

one change I don't understand:

OLD (-04):
    TF: Traffic Class, Flow Label:
       00: Traffic Class + 4-bit Pad + Flow Label (4 bytes)
NEW (-05):
    TF: Traffic Class, Flow Label:
       00: 4-bit Pad + Traffic Class + Flow Label (4 bytes)

This is not in the change notes.
It destroys the byte-alignment of the Traffic Class field.
It also hurts the (code-saving) similarities -04 had between the TF  
values 00, 01, and 10.

Clearly, this is a regression.
(Unfortunately, it is almost identical to the old version so I didn't  
notice the change in July.)

As an editorial comment, it would help to just say that the meaning of  
DAC/DAM simply is the same as that for SAC/SAM for M=0.

As another technical note: Are we sure that these changes really don't  
impact ISA100, which appear to be stuck on -04?  I haven't managed to  
verify that yet.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Sep 2009 14:54:24 +0200

Hi Carsten,

Yes, ISA100 is stuck at 04. They only use:

      01:  ECN + 2-bit Pad + Flow Label (3 bytes)
      11:  Version, Traffic Class, and Flow Label are compressed.

ISA100 is mesh under. Do they effectively carries the ECN bits in the L2
header over the radio to enable each hop to set the bits. The ECN field
is conceptually copied from the L2 to the 6LoWPAN header as the L2
header gets stripped upon reception.

Thanks a lot for raising the flag though. And I agree that the version
in 04 was better. 

Jonathan?

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carsten Bormann
>Sent: dimanche 20 septembre 2009 16:56
>To: Jonathan Hui
>Cc: 6lowpan
>Subject: Re: [6lowpan] Fwd: New Version Notification
fordraft-ietf-6lowpan-hc-05
>_______________________________________________
>6lowpan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 21 Sep 2009 15:08:26 +0200

On Sep 21, 2009, at 14:54, Pascal Thubert (pthubert) wrote:

> Yes, ISA100 is stuck at 04.

So what about the change to SAC/SAM (1/00 is now reserved with -05,  
and 0/00 is the one you now use for 128 bits inline)?

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Sep 2009 18:03:12 +0200

Hi Carsten:

ISA only uses stateful format even for the join process that uses link
local addresses.
They do not do ND (no use of unspecified). So it works :)

Pascal

>From: Carsten Bormann [mailto:[email-masked]]
>Sent: lundi 21 septembre 2009 15:08
>To: Pascal Thubert (pthubert)
>Cc: Jonathan Hui; 6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 21 Sep 2009 18:24:02 +0200

On Sep 21, 2009, at 18:03, Pascal Thubert (pthubert) wrote:

> ISA only uses stateful format

So they never send 128 bit inline addresses?
All addresses compress (statefully) in all cases?
Congratulations, but I wouldn't know how to do that...

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 21 Sep 2009 12:35:20 -0700

Hi Carsten,

On Sep 20, 2009, at 7:55 AM, Carsten Bormann wrote:
> (Unfortunately, it is almost identical to the old version so I  
> didn't notice the change in July.)

If you want to be precise in the text you call out, neither version  
sufficiently specifies how the fields are encoded - that specification  
is delayed until Section 2.2.1 in both drafts.  Would you prefer to  
list ECN and DSCP separately and in the order that they appear in a  
LOWPAN_IPHC encoded header?  For example:

00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
01: ECN + 2-bit Pad + Flow Label (3 bytes)
10: ECN + DSCP (1 byte)
11: Version, Traffic Class, and Flow Label are compressed.

Or would you prefer a note that points towards Section 2.2.1? Or  
something else?

> As an editorial comment, it would help to just say that the meaning  
> of DAC/DAM simply is the same as that for SAC/SAM for M=0.

There is a proposal to make SAC=1, SAM=00 to indicate the Unspecified  
Address.  Would you prefer text that says they are the same with  
exception?  Or keep the text as is?

> As another technical note: Are we sure that these changes really  
> don't impact ISA100, which appear to be stuck on -04?  I haven't  
> managed to verify that yet.

I defer to Pascal who has more knowledge of ISA100 than me.

--
Jonathan Hui

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 21 Sep 2009 22:24:25 +0200

Hi Jonathan,

> Would you prefer to list ECN and DSCP separately and in the order  
> that they appear in a LOWPAN_IPHC encoded header?  For example:
>

Great.  Concise and precise.  I'd maybe add:

> 01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided
> 10: ECN + DSCP (1 byte), Flow Label is elided

> 11: (0 bytes), Traffic Class and Flow Label are elided.
> All elided fields are decompressed as zero, except that Version is  
> always elided and decompressed as 6.
> As usual, bit fields are concatenated by filling the most  
> significant bits first.

>
> There is a proposal to make SAC=1, SAM=00 to indicate the  
> Unspecified Address.

So why don't we stick with the way this was done in -04, not risking  
any incompatibilities with ISA100?
(Of course, we should wait until we fully understand the ISA100  
situation.)

> Would you prefer text that says they are the same with exception?   
> Or keep the text as is?

When they (SAC/SAM and DAC/DAM) really are the same, or there is one  
value that only is allowed for SAC/SAM, I'd prefer to unify them  
(editorial preference).  Technical preference is of course that we can  
have as much code reuse as possible.

The wart, of course, is M/SAC/SAM = 1/1/00.  Why do we have that  
again?  0/0/00 means exactly the same.
Why is SAC=1 for this stateless case (I know, because we already took  
all four stateless cases.)
If we really want to have a special multicast case, why don't we  
compress out at least the first byte of the address, which is always  
0xFF in this case?
(Changes for multicast don't impact ISA100.)

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 22 Sep 2009 10:03:25 +0200

>(Of course, we should wait until we fully understand the ISA100

There's no incompatibility with ISA100.11a there. ISA100.11a only uses
the stateful encoding format - or no compression at all. 
- ISA100.11a does not use the unspecified address. 
- It does not do any ND/DAD. 
- It always compresses the IPv6 address. 

In more details:

- All of the traffic (but ne flow) uses the 16bit short addresses. A
system manager assigns the short address and the mapping into an IPv6
address, a bit ala DHCP. Any remote address will be mapped into a local
short address as well to be expanded by the backbone router. So ISA100
is fully stateful, and the short address is an index in the context -
there's only one context.

- The only exception is the join process. The joining of a new node is a
special flow and the only one that uses a 64bits MAC-64 Link Layer
Address. From the network layer standpoint, the flow is performed using
the EUI-64 based Link Local Address and should theoretically be encoded
in a stateless form. But for simplicity ISA decided to have an implicit
state virtually indexed by the MAC-64 link layer address and thus uses
the stateful encoding even there. The 16bit address and the
corresponding IPv6 address of the node are assigned as part of the join
process. 

- Any flow is started under the control of the system manager that will
pass the addresses of the remote node and other contract information
such as QoS parameters. QoS parameters end up encoded in the flow label.
DSCP in not defined at ISA100.11a so TF bits can be either 01 or 11.
There's work at ISA100.15 and ODVA that aim at defining industrial
DSCPs. When that happens, we might very well see this work retrofitted
in a revision of ISA100.11a that would enable all the TF possibilities.

CC'ing Christos who was the lead editor of the network layer section.
Christos, do I miss anything?

Cheers,

Pascal