Subject: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix

From: "David Culler" <[email-masked]>
Date: Mon, 16 Jul 2007 16:38:26 -0700

Folks,
  We'd like to draw your attention to I-D

    http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc1g-00.txt

that was posted two weeks ago.  It generalizes HC1 to provide the same level
of header compression for a PAN-wide global prefix.  HC1 only compresses
addresses that use the link local prefix.  A global prefix is always used in
communication with endpoints external to the PAN.  It may be used as well
within the PAN.  In the context of mesh-under, HC1g applies to originator /
final.

Thanks,

     David Culler and Jonathan Hui
_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 16 Jul 2007 21:23:13 -0700 (PDT)

thanks Jonathan,

just a quick comment below...

----- Original Message ----

Link-local communication covers an important subset of applications. But 
we do see benefits in allowing nodes to communicate directly with other 
IP devices outside the LoWPAN network....

gab> That is not an issue, as nodes are perfectly capable to communicate directly
with other IP devices outside the LoWPAN network. They can certainly use
global prefixes, no issue there. The only question was whether such communication
merited being optimized. It seemed to us (without any real data to support it, though)
that the extra complexity was not worth the marginal benefit cuz most packets from
puny devices would be local and only a small percentage would need to use the global prefix. 
If there is any data to justify the tradeoff of the additional complexity, it would be good
to see it.

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 17 Jul 2007 00:00:04 -0700 (PDT)

Hi David,

I hope it's clear from several msgs ago that I completely agree with the objective.
What I'm not sure is how (if) you've achieved it.

>From your draft:
      Compressed 64-bit Address:  64-bit prefix elided, 64-bit interface
         identifier carried in-line.  The 64-bit prefix is derived from
         the 64-bit prefix assigned to the PAN.When we looked at it, it seemed like using routing advertisements to dole out prefix information
did not allow for the above (no such thing as *the* link prefix). One can always define additional
mechanisms to go with the new semantics, get those approved, published, etc.  It seems to me like
those are needed if the above snippet is to work. I'm just asking if you had data to determine that
the extra effort needed to actually make this work is worth it, given the marginal benefit. We did not
have any real deployment data, by the way.

-gabriel

----- Original Message ----
From: David Culler <[email-masked]>
To: Jonathan Hui <[email-masked]>
Cc: gabriel montenegro <[email-masked]>; [email-masked]
Sent: Monday, July 16, 2007 11:30:02 PM
Subject: Re: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix

Gabriel,
  Thanks for weighing in.  To expand a little on Jonathan's comments...  The potential to have multiple global ipv6 would not seem to suggest that NONE of them should be compressible.  hc1g allows ONE of them to be, but doesn't prevent the use of the others.  Doesn't it seem a shame to lose the advantages of 6LoWPAN just because you assign IPv6 addresses to the nodes in addition to the default link local address.  The philosophy of 6LoWPAN seems to be to provide a way to improve the common case while still supporting the general case correctly.  We cannot compress all the UDP ports, just a selected region.  I think that you would agree that two of the most important reasons for putting IPV6 on the 
802.15.4 network in the first place is the ability to name a node with a globally meaningful IP address and the ability to route packets to and from nodes on the 802.15.4 network.  HC1g preserves the the HC1 compression in these two cases.

On 7/16/07, Jonathan Hui <[email-masked]> wrote:

gabriel montenegro wrote:
> We actually discussed this a while back with Erik Nordmark in some
> detail. The issue is that an IPv6 link
> can have several prefixes, and they are not guaranteed to be advertised

> in any particular order by the router
> or routers on that link. So one could not use a bit pattern easily to
> refer to:
>
>     * "the" global prefix (cuz there may be more than one)

>     * "the first global prefix" (cuz node A's first might be node B's
> second)
>

Yes, the global compressible prefix must be clearly identified if nodes
are assigned more than one prefix. Our thoughts are that this can be

done using either stateless autoconfiguration mechanisms (i.e. IPv6 ND),
by extending RAs and using a reserved bit to indicate its compressible
status; through stateful autoconfiguration (i.e. DHCPv6) through IA

Address options; or through some yet-to-be-defined 6LoWPAN configuration
protocol. If there is a configuration error and more than one global
prefix is marked as compressible, then the node must not compress the

prefix. This is not stated in the current draft and probably should be.

> At the end we did not see a clear and easy way of doing so, so we
> limited the header compression scheme
> to only the link-local addresses (cuz the "prefix" in that case in

> unequivocally known). It also did not seem
> like overall, complicating the basic scheme with additional header
> compression for global prefixes was
> very meaningful as most traffic would probably be link-local anyways.

Link-local communication covers an important subset of applications. But
we do see benefits in allowing nodes to communicate directly with other
IP devices outside the LoWPAN network. By utilizing IP end-to-end,

LoWPAN nodes can readily communicate with any other non-LoWPAN node, and
it can do so without a stateful translation gateway in between.

> In case it is not clear, an assumption above (as in all the format

> document) was that we wanted to have
> support for IPv6, not for some watered-down or somewhat tweaked (even if
> only slightly) version of IPv6.
> It was also pretty clear that without this we wouldn't have been able to

> have a working group.

We completely agree that we would like to support full IPv6. LOWPAN_HC1g
supports just that, allowing nodes to communicate with any arbitrary prefix.

--
Jonathan Hui

[email-masked]