Re: [6lowpan] HC

[Jonathan Hui <[e-mail]>]

Hi Stephen, see below:

On Jul 17, 2008, at 5:40 PM, Stephen Dawson-Haggerty wrote:
> - support route-over combined with no hop-by-hop reassembly

We should clean up the terminology here since the working group seems  
to have different ideas of what "route-over" is. I admit, that I  
haven't been that clear myself over the past few months. I'd like us  
to decouple routing from forwarding in the way that IP has  
traditionally done. So it's probably more appropriate to say L3  
forwarding in this context. Route-over is a term meant to describe IP  
routing rather than L2 mesh routing.

> - support source routing
>
> As older discussions on the list have gone over, the first is
> currently possible by unpacking the IP headers in the first fragment
> and caching the routing information for successive fragments.  I think
> it's probably not necessary to do anything other then declare that the
> compressed IP headers must fit into the first fragment, but there
> could be other ideas for how to best allow this.

Yes. Some are concerned that this adds some state/complexity within  
the node. I'm not convinced that the added resource requirements are a  
huge issue. As for fitting into the first fragment, even an  
uncompressed IPv6 header should fit given the worst case. Unless you  
have a huge hop-by-hop options header or large (yet-to-be-defined)  
6lowpan headers, this shouldn't be much of an issue.

> The second belongs in any standard, because it interacts with address
> compression: the source route can be used to infer the source and
> destination IP address for intra-pan routing.  What I would suggest
> here is the addition of an LOWPAN_HCNH encoding for source routing.
> This also brings up the issue it should be possible to follow this
> header (NHSR?) with a NH_UDP encoding block so as to have compressed
> source routing as well as UDP headers.  Whatever header format is
> decided on should also support a record route option in the dispatch
> byte.  If people agree that this is important, I can write up a
> proposal on how to do this.

I can say that we've been using such functionality in production  
deployments for many months now and they are invaluable resources for  
debugging wireless networks (especially when routing protocols fail)  
and can be used for simple routing protocols as well (e.g. DSR-like  
protocols). While they do interact with HC, I did not include them in  
the first draft simply because it was more important to solve the  
initial problem of proposing a new HC format. Furthermore, routing  
type 0 was just deprecated and there is no existing definition for  
record-route in IPv6. I'm strongly in favor of including this  
functionality in the draft, but we need to be careful about the  
processing rules. If the working group things this is useful  
functionality to include in the doc, I'd be happy to see your ideas  
and we can compare with mine or others.

> What else do people see as needing work in HC?

Some of the issues on the plate that I plan to address in the next  
draft (as discussed in the last WG meeting):
- two bits for HLIM to indicate where the packet came from
- adding bits to identify the prefix context for supporting multiple  
prefixes
- removing option for checksum compression in UDP
- add a new UDP-like transport that relies on end-to-end MIC rather  
than checksum

Chairs, given the urgency of pushing HC through, I'd like to have some  
time at the WG meeting to talk about updates and issues. Thanks.

To answer the original question in this thread: I too am in favor of  
deprecating HC1 and pushing HC forward as quickly as possible.

--
Jonathan Hui

>
>
> Steve
>
> On Thu, Jul 17, 2008 at 7:54 AM, Geoff Mulligan <[e-mail]>  
> wrote:
>> I also agree.  Now is the right time before we have to carry this  
>> design
>> baggage forward.
>>
>> As Pascal pointed out - we then need to get HC done sooner.
>>
>>       geoff
>>
>> On Thu, 2008-07-17 at 10:56 +0200, Anthony Schoofs wrote:
>>> I am also in favor of that approach.
>>> We have had issues with routing packets from 6lowpan nodes to IP
>>> hosts, and we definitively need the HC compression to make things
>>> cleaner and optimized.
>>>
>>> Anthony
>>> --
>>> Anthony Schoofs
>>> Research Scientist
>>> Philips Research
>>> High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands
>>> Email: [e-mail]
>>>
>>> Inactive hide details for Pascal"Pascal Thubert (pthubert)"
>>> <[e-mail]>
>>>
>>>
>>>        "Pascal Thubert (pthubert)"
>>>        <[e-mail]>
>>>
>>>        Sent by:
>>>        [e-mail]
>>>
>>>        17-07-2008 10:13
>>>
>>>
>>>               To
>>>
>>> "David Culler"
>>> <[e-mail]>
>>> <[e-mail]>
>>>
>>>               cc
>>>
>>>
>>>
>>>          Subject
>>>
>>> Re: [6lowpan] HC
>>>
>>>   Classification
>>>
>>>
>>>
>>>
>>>
>>> Hi David:
>>>
>>> I do support that approach. I'd note that it would impose some
>>> pressure to release HC rather quickly.
>>> Is there a way to get a feedback on existing deployments that use
>>> 6LoWPAN HC1?
>>>
>>> Pascal
>>>
>>>
>>> ______________________________________________________________________
>>> From: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of David Culler
>>> Sent: mercredi 16 juillet 2008 18:25
>>> To: [e-mail]
>>> Subject: [6lowpan] HC
>>>
>>> It appears that the 6LoWPAN WG is poised to take up serious  
>>> discussion
>>> of HC (http://www3.tools.ietf.org/html/draft-hui-6lowpan-hc-00)  
>>> and I
>>> would like to encourage us to make a bold move forward while the
>>> number of "dusty deck 6LoWPAN implementations" are few - eliminate
>>> HC1/HC2 in the process.
>>>
>>> As a bit of background, the original format document defined HC1 for
>>> compression of link local IPv6 addresses and HC2 for compression of
>>> UDP and ICMP headers. Both were part of a rather awkward encoding.
>>> Most other parts of the encoding got cleaned up with the switch to  
>>> the
>>> stacked header format that went to RFC. Aside from its awkwardness,
>>> HC1 was never sufficient, because it provided no compression of
>>> routable addresses, nor for the most useful multicast addresses -  
>>> both
>>> rather essential to IPv6. HC1g was proposed to provide a similar
>>> (somewhat more effective) stateless compression of common  
>>> addresses of
>>> global scope. This meant two similar compression schemes, HC1 for
>>> link-local, HC1G for global. Both are implementable with much less
>>> than a thousand lines of code. No ambiguity about when to use which.
>>>
>>> HC provides a much cleaner approach which subsumes both HC1 and  
>>> HC1g,
>>> better supports multicast, and is much more usable with IPv6 stacked
>>> headers because the order of the subheaders is respected. (HC2 comes
>>> in between the dispatch and the address subheader, rather than as a
>>> portion of the transport subheader).
>>>
>>> The decision to take on HC, clean up the rough edges, and build
>>> consensus around it is the easy part. The bolder step that I would
>>> like to suggest is that we deprecate HC1 and get it removed soon.
>>>
>>> It is always easier to maintain backward compatibility than to  
>>> make a
>>> clean break. But, ultimately that is burdening all the many future
>>> implementations in order to avoid a burden on the few current
>>> implementations.
>>>
>>> The reason to avoid this burden is not that either is a huge  
>>> amount of
>>> code. Implementing any of these HCs is only several hundred LOC. The
>>> issue is testing and interoperability. The interoperability draft
>>> sheds some light on this. There are so many different compression
>>> forms and since each is an optimization on the uncompressed version,
>>> there are many different ways to represent the same thing. All with
>>> different sizes and offsets. At least they are all in the same  
>>> suite.
>>> To multiply that with all the combinations of HC1 and HC will be
>>> really unpleasant. Moreover, the only thing anyone will ever use  
>>> after
>>> a short while is HC, since it is so much cleaner and more effective.
>>> That means all the HC1 mess and all the testing and interoperability
>>> investment will be for nothing other than that - just to pass the
>>> test. But it will generate latent bugs, increase the footprint, and
>>> frustrate interoperabilty.
>>>
>>> So, as we imagine a future of billions of 6LoWPAN IP devices  
>>> embedded
>>> in important hard to reach places, lets take the step now to  
>>> simplify
>>> their implementation and testing, rather worry too much about  
>>> saving a
>>> few hours of coding for the half dozen existing implementations. If
>>> that is not reason enough, those same implementors will save many
>>> times that amount in reduced testing and interoperability  
>>> validation.
>>> _______________________________________________
>>> 6lowpan mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>
>>> _______________________________________________
>>> 6lowpan mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>
>> _______________________________________________
>> 6lowpan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowpan
>>
> _______________________________________________
> 6lowpan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan