Subject: [6lowpan] Compressing HC1 and HC2 into HC3

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Mar 2008 13:36:45 +0100

Dear 6LoWPANers,

Though HC1 and HC2 provide us with the capability to express any
combination of compression, the most expected (or at least shot for)
case does not lead to a better compression of the HC headers themselves.

Seems that we could define an HC3 that would compress the pair of HC1
and HC2 for that best case. My proposal for doing this would be to:

- define a new dispatch
         | 01  000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and
transport

- define HC3 itself to:

	- implicitly say that the first 5 bits of HC1 are all ones
	- carry HC1 bits 5 and 6 (Next Header) 
      - replace HC2 so bit 7 of HC1 is useless  
      - provide transport specific bits such as those defined for
HC-UDP,
        then again assuming a predefined best case if room is missing
  
An example of what the HC3 octet could be:

  bits        0                  1              2-3
4-7  
 
+------------------+-------------+-----------------+--------------------
---------------------+
       | reserved         |  reserved   |  Next Header    |    transport
specific control bits      |
 
+------------------+-------------+-----------------+--------------------
---------------------+

Next header:  as defined in HC1, bits 5 and 6

transport specific control bits for UDP: 
   bit 4 echoes HC-UDP bit 0 on UDP source port
   bit 5 echoes HC-UDP bit 1 on UDP destination port
   bit 6 echoes HC-UDP bit 2 on UDP length
   bit 7 is reserved

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

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 04 Mar 2008 09:05:04 -0800

Hi Pascal,

Thanks for sharing your thoughts.

By assuming the first 5 bits in HC1 are '1', you're staking a claim that 
mesh-under link-local communication within a PAN is going to be most 
common case and the one we've "shot for". If link-local is all we focus 
on, then we are missing the point of IP. Frankly, I don't see much 
benefit of IP if communication is limited to the PAN.

W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN 
nodes will communicate via route-over using routable addresses (e.g. 
ROLL). This brings us back to a broader topic of route-under vs. 
mesh-under. While both will probably exist for some time, it raises the 
question of whether 6LoWPAN implementations can support one or do they 
have to support both.

W.r.t compressing Hop Limit, I don't quite understand why you're using a 
bit in HC3 to indicate where the message originated. If you're assuming 
link-local communication, then messages shouldn't be forwarded across 
links anyway.

I do agree that there is work to do on compression and agree that there 
are cases where HC1 and HC2 are not sufficient. This is why I've been 
working, albeit slowly, on HC1g.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Mar 2008 08:46:39 +0100

Hi Jonathan:

You are assuming explicitly that I am assuming implicitly... mesh
under... Hum.

Please have a look at
http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router
-00.txt and it should be apparent that I'm not. In particular the
backbone router is the device that will set and use the hop limit bit.
So will all those interconnecting devices used in pseudowire, split
bridges, IP Mobility, etc... if they are deployed in this space.

What I'm really assuming is a gateway or an edge server on the link.
It's there in most architectures that I know of at this point that's why
I included it in the case we shoot for and saved 2 bits. Note that when
the ULA and global addresses are used on top of link local, it makes
sense that we define a mechanism to compress them as well. But this is
not what HC3 is about.

The goal of my initial proposal is illustrative, to foster this very
discussion around the idea that we can shoot for a favorite case and
make an HC3 out of HC1 and HC2 for that case. Now, if we as a group
think that the GW assumption is not reasonable, then, fine, let us
affect 2 bits in HC3 to indicate whether the addresses are compressed. 

What do the others think?

Pascal
>-----Original Message-----
>From: Jonathan Hui [mailto:[email-masked]]
>Sent: mardi 4 mars 2008 18:05
>To: Pascal Thubert (pthubert)
>Cc: 6lowpan; [email-masked]; Jay Werb
>Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3
>
>
>Hi Pascal,
>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 04 Mar 2008 23:59:03 -0800

In your draft, you claim that 6LoWPAN nodes address each other and the 
backbone router using link-local addresses. If that occurs over multiple 
radio hops, that sounds like mesh under to me... In other words, you are 
assuming that an entire PAN functions as a single IP link (the IPv6 
definition of a link). Am I missing something here?

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 05 Mar 2008 00:28:06 -0800

Regarding the GW assumption on the link, I think we need to take a step 
back for a second. While it is true that most architectures up until 
this point follow this assumption, most architectures that I know of 
haven't been built using IP. ZigBee nodes, for example, only communicate 
with ZigBee nodes at every hop and there isn't any effort to do 
internetworking.

But now that we actually have IP, we are no longer constrained to a 
single link technology. Rather, nodes can communicate with each other, 
directly using 802.15.4, or over other technologies such as WiFi, 
Ethernet, GPRS, etc. This really opens up the network architecture 
possibilities, and there are many cases where adding these additional 
links are desirable. I know that ISA's proposed backbone routers provide 
this functionality, but I'd rather support such networks at the IP 
layer, rather than abstracting a combination of link technologies as 
single IP link and defining any new machinery to do so.

BTW it's great that we're having this discussion. It is long overdue.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Mar 2008 13:06:34 +0100

Hi Jonathan:

The Backbone Router (BbR) draft makes no assumption that I am aware of
on whether there is or not more than one radio hop over a LoWPAN; both
cases are supported. Now I think it's fair to make a distinction between
radio hops over the LowPAN and hops over the backbone:

- First, the backbone is not supposed to be of the same technology as
the LoWPAN. A backbone router is thus expected to expand the 6LoWPAN
compressed packets and reassemble the fragments. The backbone can a
simple ethernet cable, but it might as well be a mesh of tunnels over a
WAN. The packet might be delivered to an IPv6 node sitting on the
backbone, or be forwarded across a destination LoWPAN via another
backbone router. Because the destination LoWPAN might be different in
nature from the source LoWPAN, uncompressed IP is the esperanto over the
backbone.

- Second, the routing protocol is somewhat different. The backbone
router uses proxy ND techniques to represent its field devices over the
link abstraction that is the backbone and make routing decision to
forward over the LoWPAN vs. over the backbone; and the types of routing
that sustains the backbone itself can be virtually anything from
spanning tree to BGP.

The goal for this draft is to federate multiple small LoWPANs into one
larger IPv6 link over a backbone of any sort that is also part of the
link. The single link requirement matches the current applications that
I know of and enables a field device to move from one BrB to another one
on the same link while retaining transparently its address and active
connections. 

The backbone router is the router that enables that LoWPAN
interconnection, and proxy ND is the technique that is proposed to
achieve the goal above. Other techniques such as NETLMM/proxy MIP were
discussed but seemed overkill for the desired result and the constraints
of the LoWPAN.

Pascal

>Sent: mercredi 5 mars 2008 08:59
>>> W.r.t compressing Hop Limit, I don't quite understand why you're
using
>> a

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Mar 2008 13:15:55 +0100

Hi Jonathan

I agree it's great we are having this discussion :)

Multiple thread could spawn from it because there are multiple topic.
And some of this might belong to ROLL as you pointed out earlier.

I'd wish to keep this thread for its original question on whether it is
desirable, in the context of what we already have, to further compress
HC1 and HC2 into a single HC3. For that specific thread, I retain that
you do not oppose but that you vote for retaining some information on
whether the addresses are elided or not.

Is that fair?

Pascal

>Sent: mercredi 5 mars 2008 09:28
using

---

From: Zach Shelby <[email-masked]>
Date: Wed, 05 Mar 2008 14:21:46 +0200

Very nice discussion.

I see the logic in going after a more aggressive HC3 compression for use 
within the 6lowpan network. It also would incorporate elided CRC which I 
would also like to see it for local use. So far from my implementation 
and use experience HC3 would cover 95% of our use of 6lowpan.

Why wouldn't the HC3 proposal work with both mesh under or route over? 
e.g. MANET routing protocols are also mainly using flat IP addressing 
within the MANET. So in reality route-over would likely use the MAC 
address of the interface and elide the IPv6 address when using 6lowpan 
at least, just as in 6lowpan "mesh under" as long as the destination 
address is in the same subnet. It would be quite easy to switch to 
HC1+HC2 or HC1g in the case that you detect that the destination address 
has a different non link-local prefix. Please correct me if I am wrong 
here...

Of course both HC3 and HC1g would be needed in such networks, as HC1g 
allows us to communicate outside the 6lowpan network with minimal 
overhead. So I am in favor of both. Of course there is the question if 
we would have a place for HC3 in the new charter?

- Zach

-- 
Zach Shelby | CTO | +358 40 7796297
Sensinode Ltd.   www.sensinode.com
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Mar 2008 13:42:10 +0100

Hi Jonathan:

I do not see the backbone router as an ISA thing. I see that ISA
requires a functionality and that some people at 6LoWPAN (that obviously
includes me but I hope there's more) are willing to work on an IETF
solution to help them out. So the requirement is ISA100 but the solution
draft is 6LoWPAN for sure.

I'm very positive with ROLL and I'll help as much as I can there; I
agree with all your points about architecture. Now, the problems to be
solved are quite complex and that's certainly quite a lot of work ahead
to get all the basic ingredients in place to propose a global solution.
Just the compression of the addresses across multiple hops will be an
interesting challenge. Will we use 2 bytes addresses as labels?
Centralize routing?

Now if we consider the time frames, the specs that we have available
(that's mostly RFC 4944) and the cases that must be solved in the near
term, then the single link with a gateway is a reasonable first step to
crystallize what we have - though I'm 100% with you that it is certainly
not the end of the way. 

So I'm looking for an HC3 that is an immediate improvement on HC1 and 2
as we know them for a very practical application that we have already in
front of us waiting. Thus the proposals that you have seen. I do not see
that as a threat for the future end-to-end IPv6 which will definitely
come in time. 

Do we seem to agree after all?

Pascal

using

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Mar 2008 14:05:24 +0100

Hi Zach;

I'd be glad to work with Jonathan in pushing some benefits from HC1g
into HC3 if that's what this group wishes to do.
 
Seems to me that the configuration that makes most sense for ULA and
global addresses is that the local prefix and suffix are compressed but
the remote is not at all. 

If that's so then one bit in HC3 is enough just to say LLA versus
ULA|GLO, expecting that in the former case both addresses are compressed
and in the latter only the local side is elided.

What do you think?

Pascal

>From: Zach Shelby [mailto:[email-masked]]
>Sent: mercredi 5 mars 2008 13:22
>Cc: [email-masked]; 6lowpan; Jay Werb
using

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 05 Mar 2008 08:26:27 -0800

Hi Pascal,

I think our definition of 'mesh-under' is conflicting. What I mean by 
'mesh-under' is that forwarding occurs below IP, that is, the Hop Limit 
does not get decremented by intermediate forwarding nodes. 'Route-over' 
on the other hand is simply IP routing - nodes forwarding datagrams also 
decrement the Hop Limit. As you state, the goal of BbR is to abstract 
one or more PANs to appear as a single IP link, possibly with the 
support of other link technologies.

Given this definition of 'mesh-under', would you agree that BbR is 
supporting mesh-under?

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 05 Mar 2008 08:26:34 -0800

Hi Zach. See below:

> and use experience HC3 would cover 95% of our use of 6lowpan.

This completely depends on how you implement your 6LoWPAN network. I can 
see how HC3 would work well for mesh-under networks where one or more 
802.15.4 networks are abstracted as a single IP link. However, HC3 does 
not work well if we assume route-over, where every link/radio hop is an 
IP hop. Because I've been working with route-over networks, I can say 
that HC3 is insufficient for 95% of my use cases.

> has a different non link-local prefix. Please correct me if I am wrong 

In my view, one difference between mesh-under and route-over is whether 
or not the 6LoWPAN Mesh Addressing header is used. In mesh-under, the 
Mesh Addressing header is used to deliver a datagram over multiple L2 
hops but only a single IP hop, and when link-local addresses are used, 
both addresses in the IP header can be completely elided. In route-over, 
no Mesh Addressing header is used, every L2 hop is an IP hop, and the 
source and destination addresses are carried directly in the IP header.

Given this difference, I don't see how HC3 would support carrying 
addresses in the IP header. Now, as you state, ad-hoc routing does often 
boil down to host based routing. For that very point, I think the 
difference between forwarding at L2 vs. forwarding at L3 is less than we 
think. At some level, it's about where do the addresses go. The goal of 
HC1g is to provide a way to express both extended and short addresses in 
the IP header, with the assumption that the Mesh Addressing header will
not be used.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 05 Mar 2008 08:31:00 -0800

I think it's fair to say that we should continue working on IP header 
compression. However, I also think we must evaluate whether we are 
willing to specialize such compression schemes for route-over vs. 
mesh-under networks. I don't have a problem with such specialization, 
but I would have a problem if we required any 6LoWPAN implementation to 
support specialized schemes for both mesh-under and route-over 
simultaneously.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Mar 2008 17:57:57 +0100

Hi Jonathan:

I see what you're saying and you are certainly correct from that
perspective.

You got me quite confused because there's that other mail to Zach when
you associate mesh-under with a mesh header, and that definition is
actually way closer to mine. A mesh is a radio topology and mesh-under
is about routing at L2 on that topology. 

Note that proxy-ND is still ND, in other words it is a layer 3
operation, not a 'below IP' thing. Proxy-ND is a L3 tool that enables to
merge the link local addressing spaces of 2 links into a single, larger
one. And the backbone router is a real L3 gateway, that terminates a
Layer 2 network to route packets onto another one.

For the rest I see what you're saying and I'm certainly willing to
modify HC3 to satisfy the routing over case you're talking about; I made
a step in another thread; let's see how it goes: I'd wish to hear other
opinions.

Pascal

>Sent: mercredi 5 mars 2008 17:26
>Subject: Re: Mesh Under vs. ND proxy
>
>
>Hi Pascal,
>
>>>> It's there in most architectures that I know of at this point
that's
>> why
>>>>> By assuming the first 5 bits in HC1 are '1', you're staking a
claim
>>>> that
>>>>> mesh-under. While both will probably exist for some time, it
raises
>> the

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Mar 2008 18:14:50 +0100

Hi Jonathan:

I'm certainly not willing to specialize HC3 to mesh-under whatever your
definition of the term. I'm willing to specialize HC3 to elide a number
off "always on" bits so that when these bits are on, HC3 is used instead
of HC1 and HC2. I hope this much is clear by now.

Consider this: even HC1g is specialized; it is specilized to the case
when only the terminating networks are LoWPANs. For instance, how do you
compress a packet in a LoWPAN that would sit between the source LoWPAN
and the destination LoWPAN - that's ROLL for you? 

Like I said in another mail, this is a pretty difficult issue, maybe
more complex than laying labels. My point is we do not know what ROLL
will be made of; it will certainly be very interesting but it would be
hazardous at this point to reserve bits for assumptions we could make on
it.

Let's look at what we have, which are the most important toggles and fit
those in HC3. I'll be glad to define that the address that designs a
node on this LoWPAN (the local address) is elided but is not a
link-local-address and that the remote address is not elided. Or
something else that makes sense like the local address is elided and is
the one that unabiguously matches the scope of the remote address.

So what's the case you're shooting for?

Pascal

>Sent: mercredi 5 mars 2008 17:31
that's
claim
raises

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 05 Mar 2008 09:31:32 -0800

Hi Pascal, see below:

> of HC1 and HC2. I hope this much is clear by now.

Yes, this is clear now.

> and the destination LoWPAN - that's ROLL for you? 

I never said that HC1g wasn't specialized. Any compression scheme must 
make assumptions about the underlying pattern, otherwise there is no 
compression to be had.

ROLL for me is where every node operates as an IP router. HC1g is trying 
to address a PAN where each L2 hop is an IP hop. However, it is not 
trying to address cases where the PAN is a transit network for external 
networks that can have arbitrary prefixes. In other words, any messages 
going into the PAN will be destined for those nodes in the PAN, and 
similarly any messages leaving the PAN will be sourced by a node in the 
PAN. But in both cases, the addresses used are routable addresses. This 
is the case I'm shooting for. Is this scenario realistic to you?

--
Jonathan Hui

---

From: Zach Shelby <[email-masked]>
Date: Wed, 05 Mar 2008 19:41:03 +0200

Guys,

I also would not like specialized solutions for mesh-under and 
route-over, and in fact with ROLL certainly going L3.. I am foreseeing 
already that the 6lowpan Mesh Header will depreciate eventually.

So I agree with Jonathan that we need to allow for routing using 
(compressed) L3 addresses, and any further compression option should 
allow for this. I would encourage a combined HC3/HC1g which allows for 
route-over for current usage and UDP Checksum eliding combining the most 
common compression options. HC1g has been slow coming along, maybe this 
combination would give it the wider support needed?

We are currently using the 6lowpan Mesh Header for routing but also 
employ ICMP messages with IPv6 hop-limit decrements, so it is really 
just a matter of where to store the addresses. Whose idea was the mesh 
header in the first place? ;-) It has at least used up tons of IETF 
mailing list bandwidth!

- Zach

Jonathan Hui wrote:
> 
> Hi Zach. See below:
> 
> Zach Shelby wrote:
>> Very nice discussion.
>>
>> I see the logic in going after a more aggressive HC3 compression for 
>> use within the 6lowpan network. It also would incorporate elided CRC 
>> which I would also like to see it for local use. So far from my 
>> implementation and use experience HC3 would cover 95% of our use of 
>> 6lowpan.
> 
>> HC1+HC2 or HC1g in the case that you detect that the destination 
>> address has a different non link-local prefix. Please correct me if I 
>> am wrong here...
>

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 05 Mar 2008 10:09:46 -0800

Hi Zach,

I agree that we should have an approach that supports both mesh-under 
and route-over. I also think there is hope for us to get there.

In moving toward that direction, I can rev the HC1g draft and 
incorporate some of the ideas mentioned recently on this list. I can 
incorporate the UDP checksum optimization, that is easy to do as HC1g 
uses the same HC2 header. I can also work with Pascal to find a way in 
incorporating his suggestions. In this case, the name will probably 
change from HC1g since it's no longer just about routable addresses. I 
wasn't able to generate much discussion about the initial draft on HC1g, 
so hopefully the new rev will stimulate more discussion :-).

--
Jonathan Hui

Zach Shelby wrote:
>> This completely depends on how you implement your 6LoWPAN network. I 
>> can see how HC3 would work well for mesh-under networks where one or 
>> more 802.15.4 networks are abstracted as a single IP link. However, 
>> HC3 does not work well if we assume route-over, where every link/radio 
>> hop is an IP hop. Because I've been working with route-over networks, 
>> I can say that HC3 is insufficient for 95% of my use cases.
>>
>>> Why wouldn't the HC3 proposal work with both mesh under or route 
>>> over? e.g. MANET routing protocols are also mainly using flat IP 
>>> addressing within the MANET. So in reality route-over would likely 
>>> use the MAC address of the interface and elide the IPv6 address when 
>>> using 6lowpan at least, just as in 6lowpan "mesh under" as long as 
>>> the destination address is in the same subnet. It would be quite easy 
>>> to switch to HC1+HC2 or HC1g in the case that you detect that the 
>>> destination address has a different non link-local prefix. Please 
>>> correct me if I am wrong here...
>>
>> In my view, one difference between mesh-under and route-over is 
>> whether or not the 6LoWPAN Mesh Addressing header is used. In 
>> mesh-under, the Mesh Addressing header is used to deliver a datagram 
>> over multiple L2 hops but only a single IP hop, and when link-local 
>> addresses are used, both addresses in the IP header can be completely 
>> elided. In route-over, no Mesh Addressing header is used, every L2 hop 
>> is an IP hop, and the source and destination addresses are carried 
>> directly in the IP header.
>>
>> addresses in the IP header. Now, as you state, ad-hoc routing does 
>> often boil down to host based routing. For that very point, I think 
>> the difference between forwarding at L2 vs. forwarding at L3 is less 
>> than we think. At some level, it's about where do the addresses go. 
>> The goal of HC1g is to provide a way to express both extended and 
>> short addresses in the IP header, with the assumption that the Mesh 
>> Addressing header will
>> not be used.
>>
>> -- 
>> Jonathan Hui
>>
>>> overhead. So I am in favor of both. Of course there is the question 
>>> if we would have a place for HC3 in the new charter?
>>>
>>> - Zach
>>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Mar 2008 20:28:44 +0100

Hi Jonathan:

I'm not sure ROLL precludes the idea of prefix and aggregation, so I'm
not sure every node operates as a router, not even than every node can
operate as a router. In fact I'm not even sure that every forwarding
node performs routing computations either. I think that ROLL is what we
have not made it yet.
 
We are in sync on what HC1g does and why; that makes all the sense in
the world to me and you've got my support and help if needed. My
question was really what is the HG1g pattern that you expect most times?
I mean, if you propose a compression mechanism you intend to use it. And
I'd say heavily. If I follow you well:

- It seems obvious that the local address suffix can be compressed if it
is based on EUI-64 or is unambiguously associated to a 16 bits address
using states somewhere (nd, reverse-ND, ...). The prefix can be
compressed if it is the only one on-link, or then again unambiguously
associated to a 16-bits address. I'd assume that for both, considering
the value of compressing, people will make sure that the conditions are
met for the compression to happen.

- It seems pretty obvious too that the remote address will not be
compressed: if it was on-link the nodes could and should use link local
addresses; So it is arbitrary. So the answer I expect for my question
above is that you expect that most times we will fully compress the
local address and not at all the remote address. 

Would that be your guess too?

Pascal

>Sent: mercredi 5 mars 2008 18:32
>>>> I'd wish to keep this thread for its original question on whether
it
>> is
>>>>>> I included it in the case we shoot for and saved 2 bits. Note
that
>>>> when
>>>>>> sense that we define a mechanism to compress them as well. But
this
>>>> is
>>>>>>> common case and the one we've "shot for". If link-local is all
we
>>>> focus
>>>>>>> question of whether 6LoWPAN implementations can support one or
do
>>>> they
>>>>>>> I do agree that there is work to do on compression and agree
that
>>>> there
>>>>>>>> Seems that we could define an HC3 that would compress the pair
of
>>>> HC1

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 05 Mar 2008 12:14:04 -0800

> I'd say heavily. If I follow you well:

HC1g assumes the following:
- IID is either derived directly from EUI-64 or short address.
- All nodes within a PAN are assigned a single common routable prefix.

For demonstration purposes, let's first assume that every node acts as 
an L3 forwarder. In this case, no Mesh Addressing header is used and 
compressed addresses are carried in the compressed L3 header.

- For communication that stays within the PAN, there is between 4 and 16 
bytes for L3 compressed addresses depending on whether the IID is 
derived from the short or extended address. The resulting compressed L3 
header is as small as 6 bytes (HC1, hlim, src, dst).

- For communication that crosses the PAN boundary, one of the IP 
addresses is always compressed and the other is not compressed. 
Although, I am planning to put in provisions to allow stateful 
compression by using a reserved short address range as defined in 
RFC4944 similar to how I've proposed to compress well-known multicast 
addresses. The resulting compressed L3 header is 20 bytes, but only 6 
bytes if stateful compression is used.

- When the communication occurs over a single IP hop, then the IIDs can 
be completely compressed and the resulting compressed IP header does not 
contain any addressing information. This also works when L2 forwarding 
occurs and the Mesh Addressing header is used. The resulting compressed 
L3 header is only 2 bytes (HC1, hlim).

- To support both link-local and the common routable prefix, two 
different dispatch values are used. I was originally thinking that the 
same compression format could be used in both cases. But, as you point 
out, we might have greater optimizations here. The nice thing with the 
same compression format is that the same parsing code path can be used 
for both link-local and routable cases, but comes at the cost of one 
additional byte per datagram. So there is a tradeoff between code-size 
and compression efficiency, as discussed early in this thread.

Do you think this is a reasonable approach?

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Mar 2008 22:53:55 +0100

>- All nodes within a PAN are assigned a single common routable prefix.

[Pascal] yes, perfect.

>compressed addresses are carried in the compressed L3 header.
[Pascal] But if there's no mesh, why can't we pick the addresses from
the MAC header?

>header is as small as 6 bytes (HC1, hlim, src, dst).
[Pascal] Why not use HC1 with link local in that case? Seems not a most
probable case for HC3.

>addresses is always compressed and the other is not compressed.
[Pascal] makes sense. I guess that's the right case for HC3?

>bytes if stateful compression is used.
[Pascal] great but definitely further work.

>L3 header is only 2 bytes (HC1, hlim).
[Pascal] I miss the rationale for the single IP hop... I must be tired
:)

>and compression efficiency, as discussed early in this thread.
[Pascal] I agree with that too. Still HC1g needs an HC2. The real issue
with HC3 seems to be the code-size compression trade off. Maybe writing
some pseudo code will help figuring that out. If that's one byte in most
packets it might be worth it. Also, it could mean a fast path though the
parsing, and thus a better energy-efficiency.

>Do you think this is a reasonable approach?
[Pascal] It is. Comments:

1) I'm missing the 2 bits to compress the hop limit though considering
your assumptions there's a great chance that the PAN is a stub. I'd take
the next header 2 bits off to HC2 to make room for this. 

2) there's a well identified best case for HC3. I still think we can
make room in HC3 to indicate this and have a common HC3 for 1 and 1g.

On the side) I fail to see why we can not fully compress a EUI-64 based
suffix with HC1G.

Pascal
>>>> when only the terminating networks are LoWPANs. For instance, how
do
>> you
>>>> hazardous at this point to reserve bits for assumptions we could
make
>> on
>>>> it.
>>>>
>>>> Let's look at what we have, which are the most important toggles
and
>> fit
>>>> something else that makes sense like the local address is elided
and
>>>>> but I would have a problem if we required any 6LoWPAN
implementation
>> to
>>>>>> you do not oppose but that you vote for retaining some
information
>> on
>>>>>>> Regarding the GW assumption on the link, I think we need to take
a
>>>> step
>>>>>>> this point follow this assumption, most architectures that I
know
>>>>>>> But now that we actually have IP, we are no longer constrained
to
>>>>>>> layer, rather than abstracting a combination of link
technologies
>> as
>>>>>>>> backbone router is the device that will set and use the hop
limit
>>>>>> bit.
>>>>>>>> discussion around the idea that we can shoot for a favorite
case
>>>> and
>>>>>>>>> mesh-under link-local communication within a PAN is going to
be
>>>> most
>>>>>>>>> W.r.t mesh-under, there are efforts within the IETF that
assume
>>>>>> 6LoWPAN
>>>>>>>>> are cases where HC1 and HC2 are not sufficient. This is why
I've
>>>>>> been
>>>>>>>>>> combination of compression, the most expected (or at least
shot
>>>>>> for)
>>>>>>>>>> and HC2 for that best case. My proposal for doing this would
be
>>>> to:
>>>>>>>>>> - define a new dispatch
>>>>>>>>>>          | 01  000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed
IPv6
>>>> and

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 05 Mar 2008 14:15:05 -0800

> [Pascal] But if there's no mesh, why can't we pick the addresses from

I think our ideas of the network are still not matching up. In one case, 
I'm assuming that every node is doing L3 forwarding, meaning that each 
15.4 hop is an IP hop. Every 15.4 hop decrements the IPv6 Hop Limit by 
one. In this case, you can deliver messages over multiple hops without a 
Mesh Addressing header. But you still need source and destination 
addresses distinct from the MAC header. If you are delivering a message 
over a single L2 hop, then the IP addresses can be completely elided and 
derived from the 15.4 header.

In the case where nodes are doing L2 forwarding, then a Mesh Addressing 
header is required to define the end-points of an IP hop and we can 
completely elide the addresses in the IP header. The format defined by 
HC1g supports both cases.

I've said this in an earlier email, but I believe the difference between 
L2 and L3 forwarding is smaller than we think. In both cases, nodes are 
essentially naming each other using MAC addresses. If this is the case, 
I would prefer to have the forwarding occur at L3. Doing so allows us to 
utilize functionality provided by IP, rather than re-defining 
functionality below IP to make L2 hops look like a single IP hop.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Mar 2008 23:43:48 +0100

>derived from the 15.4 header.

[Pascal] Now I think I'm with you. I was confused by what you design as
a PAN that I associated with a link. So you have a single 802.15.4 short
address domain but still multiple IP hops. I guess you're doing host
routes in the original MANET fashion within the PAN and then aggregate
outside the PAN.

[Pascal] I a formal world, you should undo/redo 6lowpan at each hop and
present the encompressed packet to routing. Obviously you do not want to
do that so you accept a routing plane at L3 and a forwarding at 6LoWPAN
shim. If that's so, why not keep the mesh header format when you stay in
the same PAN?

Talk to you soon,

Pascal
>--
>Jonathan Hui
>
>
>>> - For communication that stays within the PAN, there is between 4
and
>> 16
>>>> - It seems obvious that the local address suffix can be compressed
if
>>>>>> I'm certainly not willing to specialize HC3 to mesh-under
whatever
>>>> your
>>>>> similarly any messages leaving the PAN will be sourced by a node
in
>>>>>> will be made of; it will certainly be very interesting but it
would
>>>>>> those in HC3. I'll be glad to define that the address that
designs
>>>>>>>> HC1 and HC2 into a single HC3. For that specific thread, I
retain
>>>>>>>>> single link technology. Rather, nodes can communicate with
each
>>>>>> other,
>>>>>>>>> links are desirable. I know that ISA's proposed backbone
routers
>>>>>>>> provide
>>>>>>>>> this functionality, but I'd rather support such networks at
the
>> IP
>>>>>>>>>> What I'm really assuming is a gateway or an edge server on
the
>>>>>> link.
>>>>>>>>>> the ULA and global addresses are used on top of link local,
it
>>>>>> makes
>>>>>>>>>> The goal of my initial proposal is illustrative, to foster
this
>>>>>> very
>>>>>>>>>> think that the GW assumption is not reasonable, then, fine,
let
>>>> us
>>>>>>>>>>> on, then we are missing the point of IP. Frankly, I don't
see
>>>> much
>>>>>>>>>>> nodes will communicate via route-over using routable
addresses
>>>>>> (e.g.
>>>>>>>>>>> bit in HC3 to indicate where the message originated. If
you're
>>>>>>>> assuming
>>>>>>>>>>> link-local communication, then messages shouldn't be
forwarded
>>>>>>>> across
>>>>>>>>>>>> Though HC1 and HC2 provide us with the capability to
express
>>>> any
>>>>>>>>>>>> case does not lead to a better compression of the HC
headers
>>>>>>>>>> themselves.
>>>>>>>>>>>>       - provide transport specific bits such as those
defined
>>>> for
>>>>>>>>>>>> HC-UDP,
>>>>>>>>>>>>         then again assuming a predefined best case if room
is
>>>>>>>> missing

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 05 Mar 2008 15:05:11 -0800

Hi Pascal,

> routes in the original MANET fashion within the PAN and then aggregate

Yes, that's right. But, if we step back a bit, it's not much different 
than routing at L2, nodes are still named by their 15.4 addresses.

> shim. If that's so, why not keep the mesh header format when you stay in

I am technically undoing/redoing 6lowpan at each L2 hop. One way to look 
at my L3 forwarding proposal is that the 6LoWPAN Mesh Addressing header 
is always compressed out because the Mesh Addressing source and 
destination addresses are identical to the 15.4 source and destination. 
Then we are left with a header that includes the 15.4 header and the 
compressed IP header.

- When a node communicates with other nodes within a single radio hop, 
then both source and destination addresses may be completely elided, 
deriving them from the lower layers.

- When a node communicates over multiple IP hops but stay within the 
PAN, then compressed source and destination addresses appear in the IP 
header.

- When a node communicates with devices outside the PAN, then one of the 
addresses are carried uncompressed in the IP header.

There's no need to use the Mesh Addressing header in any of these cases. 
  I hope I'm making myself more clear.

--
Jonathan Hui

---

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

Hi Jonathan and all:

I'd wish to move forward on the original subject for this thread.

Basically the question is whether it is worth consuming a dispatch for
an HC3 that would represent the best case of what HC1 and HC2 can
compress.

Pros: saves one byte in the headers and a fast path in the code
Cons: Additional encoding complexity and one dispatch.

On the side, there's a compression mechanism coming up for ULA/GLO
(HC1g). 
Can we make HC3 ready for that upcoming mechanism? Should we wait?

I'll ask Geoff if some discussion can happen in Philly to conclude on
the topic.

Pascal

---

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

Hi Pascal,

Given that it looks like we can include two of your three proposals into 
HC1g, I'm not so sure whether defining a new format adds that much 
benefit. Adding the ability to elide the UDP checksum and the hop limit 
into HC1g already provides 3 bytes of savings. Compared to your proposed 
modifications to HC1g, HC3 only saves one byte (which you've observed). 
I'll put this idea out now, but I believe HC1g has the potential to 
supersede HC1+HC2. Really, we should rename HC1g to be something like 
HCx since it's not really specific to routable addresses.

My alternative proposal is as follows:
- Use the HCx format for both link-local and non-link-local communication.
- Define a dispatch HCl when communicating with link-local addresses.
- Define a dispatch HCr when communicating with routable addresses.

The reason why I'm pushing for a single format is that I believe the 
most optimized code will work with the format directly to save RAM and 
code. That means that 6LoWPAN nodes generally do not expand compressed 
datagrams into uncompressed datagrams and the other way around. Thus, it 
involves more than just the encoder/decoder functions and could involve 
the entire stack (including the application).

What do you/others think?

--
Jonathan Hui

---

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

Hi Jonathan:

I'm can't wait to see the proposal that saves the 3 additional bytes as
we discussed turn into a WG doc, and that would be the priority. I'm
also concerned that the 3 bytes be elided when the addresses are link
local because that's the current use in ISA100, though I'm pretty sure
we could use HC1G there. 

I think that the work on compressing the HCs themselves is also
important because each byte in the headers is a percentage of
battery-life (or something). And that's mostly orthogonal work. They
intersect if:

- we need to delay HC3 till HC1's are well defined
- We're missing dispatch bits.

So I still wish to have the question discussed in Philly if that's
possible within constraints...

Pascal

>Sent: jeudi 6 mars 2008 17:29
>Cc: 6lowpan

---

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

Hi Pascal,

I've asked for a time slot to talk about HCx and will incorporate stuff 
we've been discussing so far. We can bring up the discussion of further 
compressing the HC's there as well.

--
Jonathan Hui