Subject: [6lowpan] HC1g and HC2g

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Mar 2008 14:41:06 +0100

Hi Jonathan:

We've been discussing HC1g quite extensively. I'd wish to discuss
variations on your initial proposal:

------------------------------------------------------
  The LOWPAN_HC1g encoding as currently in the draft

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     |  SC   |  DC   |VTF|  NH   |L4C|
                     +---+---+---+---+---+---+---+---+

   HC2g for UDP

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     | S | D | L |   reserved         |
                     +---+---+---+---+---+---+---+---+

------------------------------------------------------

What seeems to be missing:

 - Hop limit compression (takes 2 bits)
 - UDP checksum compression

My proposal includes to keep using the mesh header format for route over
to carry the short addresses and hop limit.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     |  SC   |  DC   |VTF| Hlim  |L4C|
                     +---+---+---+---+---+---+---+---+

             HLIM: 
                00  not compressed  
                01  placed in the mesh header to count PAN hops
                10  fully elided, packet generated inside the PAN
                11  fully elided, packet came in a stub 

   HC2g for UDP

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     |  NH   | S | D | L | C | rsvrd |
                     +---+---+---+---+---+---+---+---+
  
            C: checksum is compressed.

Note1: with that new format you need an HC2g to be able to compress NH.
I do not mind.
Note2: if NH is 0 then the NH is placed after the HC2G as it is taken as
an L4 parm not between HC1G  and HC2G. The parsing of bits 2..7 depends
on that NH.

What do you think?

Pascal
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 06 Mar 2008 08:57:15 -0800

Hi Pascal,

I think it's reasonable to incorporate some of your ideas into HC1g. UDP 
checksums make sense.

I also understand the motivation for eliding the Hop Limit field. But 
I'd like to find a way to make it only a single bit. The motivation for 
this is in the following paragraph. To me, eliding the Hop Limit field 
only makes sense when communicating over a single IP hop. How about a 
single bit states if the HLIM is elided or not, and can only be elided 
when one of the L3 addresses are completely elided. The latter 
restriction ensures that Hop Limit is only elided on the 6LoWPAN side 
for a single IP hop. Am I missing a case here?

If we can remove one bit from HLIM, then I think we can move the NH 
field back into HC1. I would remove the L4C bit and say that if NH is 
non-zero, then HC2 must be included. I believe NH is still part of the 
L3 header, so it should remain in HC1. The S, D, L, and C fields in HC2 
should remain there because they are UDP specific. Also, I was proposing 
to move HC2 to the start of the L4 header and putting the NH field there 
seems strange to me.

What do you think?

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Mar 2008 21:16:17 +0100

Hi Jonathan:

In a more general fashion, the hop limit can be elided over the first
and the last L2 hops.

On the first hop, either the packet reaches onlink destination, or the
router that terminates the 6LoWPAN compression can use a default Hop
limit to forward to the world. On the last hop, whatever is is above 1
is as good as 1 since you're done with L3.

So the rules can turn out to be:

- LoWPAN node that originates the packet can elide the Hop limit.
- router performing local delivery over the LoWPAN can elide the Hop
Limit
; else the Hop limit MUST NOT be compressed

With that set of rules in place I think we're fine with one bit. There
are a number of assumptions behind about proxy and stubs, but I think
we're OK.
 
I still like the idea to move the NH to HC2. Even if it is an IP header
field, it really talks about the HC2 content, and that balances the
preserved bits leaving flexibility in HC1G.

Pascal

>-----Original Message-----
>From: Jonathan Hui [mailto:[email-masked]]
>Sent: jeudi 6 mars 2008 17:57
>To: Pascal Thubert (pthubert)
>Cc: 6lowpan
>Subject: Re: HC1g and HC2g
>
>
>Hi Pascal,
>

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 06 Mar 2008 13:01:26 -0800

Hi Pascal,

--
Jonathan Hui

> are a number of assumptions behind about proxy and stubs, but I think

Yup. The reason why I tied it to the eliding of L3 addresses is in the 
case where each 15.4 node is doing L3 forwarding and modifying the Hop 
Limit. I don't want a 15.4 node having to do a memmove() simply to 
insert a Hop Limit when forwarding it to the next hop. But I am fine 
with having a router that's forwarding to the outside world to eat this 
cost. Maybe the rule should state if more than one IP hop is taken in 
the PAN, then the Hop Limit must not be compressed.

For the assumptions, yes, I'm continuing to assume that 15.4 nodes will 
operate in stub networks.

> preserved bits leaving flexibility in HC1G.

I had originally proposed with HC1g to move HC2 after the compressed L3 
header. In this scenario, putting NH into HC2 doesn't work because the 
position of HC2 depends on whether the Next Hop field appears in the 
compressed L3 header or not. If you look at the IPv6 header 
architecture, the Next Header field always describes what header is 
coming next. So it's a pretty well understood concept. In the 6LoWPAN 
adaptation layer, however, we did design it in the way you suggest.

If we want flexibility in the HC1 header, I'd argue replacing VTF with a 
bit that expands the HC1 header by another byte and put the VTF bit 
there. I like reserving extra room in the HC2 header because I'd also 
like to make provisions for using stateful compression of the UDP ports.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Mar 2008 22:34:52 +0100

>the PAN, then the Hop Limit must not be compressed.

[Pascal] I would not use must :) but I see what you're saying. If you
have RFD types of devices they wouldn't know what to expect. They can be
configured to do one way or the other for a given deployment.

Note that with the single bit, we can not detect the case where a packet
bounces from one router to another due to improper L2 operation but
stays within the PAN.

>adaptation layer, however, we did design it in the way you suggest.
[Pascal] Remember I took great care to place the expanded NH after HC2.
So that it works (see the note at the very bottom of this mail). Just
that when you read HC2, if the HC bits are 0 you need to read the full
HC after HC2 to parse the bits in HC2. I do think it's still cleanly
putting L4 things together - and TLV is also a well understood concept
;)

>like to make provisions for using stateful compression of the UDP
ports.

[Pascal] But will that be enough anyway? Hard to know what to reserve
for this so I'd do whatever seems right with what I have. I'd rather
expand HC2 later with whatever room you need when you know more
precisely what it is you need and leave VTF in place right now...

Pascal 

>>>> Note2: if NH is 0 then the NH is placed after the HC2G as it is
taken
>> as

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 06 Mar 2008 14:59:39 -0800

Hi Pascal,

> configured to do one way or the other for a given deployment.

I'm not strongly opposed to a memmove() because of the differences in 
computation vs. communication energy. However, I am opposed to doing 
memmove() repeatedly just to forward a message. To save memory, I'm 
guessing such insertions will occur in-place. That's why I was fishing 
for ideas to see if there's ways to avoid it. I didn't want to start 
going down a slippery slope.

> bounces from one router to another due to improper L2 operation but

If it's due to improper L2 operation, does having the Hop Limit field in 
the L3 header help us?

> putting L4 things together - and TLV is also a well understood concept

Ah, I didn't see your note at the bottom. Rather than having the Next 
Hop field be in potentially three different places, how about this idea: 
Leave the L4C bit in HC1 as before, but rename it to NHC for next-header 
compression (if NHC is 0, then the Next Header field is carried inline 
and no HC2 header appears; if NHC is 1, then an HC2 header follows). 
Then we define a HC2_UDP as follows:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |0|S|P|C|  rsv  |
   +-+-+-+-+-+-+-+-+

The difference here is that we fix the first bit as '0' for UDP and 
leave compression mechanisms for other Next Header values undefined for 
now. As we define new NHC compression mechanisms, they can be added by 
setting the first bit to '1' and some other bit-pattern following. It's 
a huffman-style encoding, but we're just assuming that UDP is going to 
be the most common case, so we give it the best case.

I've also taken out the 'L' option, opting to say that UDP length should 
always be elided and derived from lower layers, just as we've done with 
the IP header.

> precisely what it is you need and leave VTF in place right now...

Agreed. I was just trying to see if there are other ways to leave 
flexibility in the HC1 header.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Mar 2008 00:40:29 +0100

>                                            Rather than having the Next

[Pascal] I love it. Note that it's too bad that UDP comes first in this
encoding though it needs few bits... So the hop limit compression now
resides in one of the 2 freed NH bits and the other one is reserved,
right?

Pascal

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 06 Mar 2008 15:51:59 -0800

Hi Pascal,

> resides in one of the 2 freed NH bits and the other one is reserved,

It is too bad that UDP needs only a few bits. But there are ways to 
utilize those extra bits :-). If you mean the hop limit compression 
resides in one of the freed HLIM bits, then that's correct.

---

From: "Robert Assimiti" <[email-masked]>
Date: Mon, 10 Mar 2008 20:54:15 -0400

Hello,

For the newbies out here in 6LowPan land, what does HC1g refer to?

I assume it is part of some current draft proposed within IETF. 

Could you point me to the exact draft?

Thks

"The nice thing about standards is that there are so many to choose from." - Andrew S. Tanenbaum 
Robert Assimiti
Executive Staff Engineer
Office: [678]-202-6859
Mobile: [404]-578-0205
[email-masked]

-----Original Message-----
From: Jonathan Hui [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 4:01 PM
To: Pascal Thubert (pthubert)
Cc: 6lowpan; Jay Werb; [email-masked]; Robert Assimiti
Subject: Re: HC1g and HC2g

Hi Pascal,

--
Jonathan Hui

--
Jonathan Hui

>>> an L4 parm not between HC1G  and HC2G. The parsing of bits 2..7

This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 10 Mar 2008 18:30:41 -0700

HC1g refers to a (now expired) draft that attempted to provide effective 
header compression for non-link-local communication.

HC1g has been replaced with the 6lowpan-hc draft that I posted to the 
mailing list earlier today.

--
Jonathan Hui