Subject: Re: [6lowpan] Rechartering consensus...

From: JP Vasseur <[email-masked]>
Date: Sat, 14 Jul 2007 10:03:38 -0400

Hi Geoff and Mark,

Some overdue comments/feedback in line.

On Jun 25, 2007, at 1:45 PM, Mark Townsley wrote:

> Geoff Mulligan wrote:
>> 6LoWPAN group,
>>   It would appear that we have consensus on the work items for the
>> working group rechartering - the following 5 topics have been  
>> relatively
>> unchanged for months.
>>
>> As I have been working with folks that are implementing 6LoWPAN  
>> and from
>> some of the messages on the list I have realized that we should  
>> probably
>> be focused on those topics that are necessary to resolve for
>> interoperability between implementations.  Some of the 5 items  
>> here are
>> targeted to this and some of the topics mentioned on the list,  
>> such as a
>> standard/defined MIC could fall under one of the topics.
>>
>> - “6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations”
>> - “Problem Statement for Stateful Header Compression in 6lowpans”
>> - “Recommendations for 6lowpan Applications”
>> - “6lowpan Mesh Routing”
>> - “6lowpan Security Analysis”

Few comments here:

6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations:

JP> Yes.

“Problem Statement for Stateful Header Compression in 6lowpans”

JP> Yes.

“Recommendations for 6lowpan Applications”

JP> Do you mean applicability statement ? In this case, in strong  
support.
This is one of the missing pieces particularly important to show that  
PAN
can be implemented on IP. Note that there are many other pieces that  
must
first be worked out (security, management, routing, ...) before we  
will be able
to produce applicability statement but would be good to have it in  
the charter
indeed.

“6lowpan Mesh Routing”

JP> One of these "hot" topic. And of course, the main question will  
to be
discuss whether Mesh-under routing is required if Route over is  
available.
In particular, open questions are "If we claim a need for a mesh  
under routing,
does that mean that we'll see a plethora of IDs showing how to adapt all
protocols (e.g. MANET) used in a 802.15.4 environment ?"

“6lowpan Security Analysis”
JP: All for it. We are starting some work on RSN to address that  
particular issue
from a routing standpoint we clearly this is a key item of the WG.  
Yes we still hear
people promoting proprietary standards because they think that this  
is provides
a high degree of security.

I would propose to add "Management": in most PANs we do expect a high  
number
of devices requiring self-management, so I think that this should be  
listed at a
WG item.

And the final one is "Service discovery"

>>
>> I have attached a proposed new charter for the working group.
>>
>> 	geoff
>>
>>
>>    
>> --------------------------------------------------------------------- 
>> ---
>>
>> Background/Introduction:
>>
>> Well-established fields such as control networks, and burgeoning ones
>> such as "sensor" (or transducer) networks, are increasingly being
>> based on wireless technologies. Most (but certainly not all) of these
>> nodes are amongst the most constrained that have ever been networked
>> wirelessly. Extreme low power (such that they will run potentially  
>> for
>> years on batteries) and extreme low cost (total device cost in single
>> digit dollars, and riding Moore's law to continuously reduce that
>> price point) are seen as essential enablers towards their deployment
>> in networks with the following characteristics:
>> * Significantly more devices than current networks
>>
> This statement seems a bit dubious to me. More devices than what  
> "current" networks? And, what exactly is the limit of a "network"  
> in this statement (the Internet is a network, for example, and I  
> don't think you are building anything larger than the Internet  
> itself).

Indeed, and it depends on what we mean by "larger" but at least we  
can safely
refer to a potentially large number of devices per square foot with  
densely
connected devices.

>> * Severely limited code and ram space (e.g., highly desirable to
>> fit the required code--MAC, IP and anything else needed to
>> execute the embedded application-- in, for example, 32K of flash
>> memory, using 8-bit microprocessors)
>>
>> * Unobtrusive but very different user interface for configuration
>> (e.g., using gestures or interactions involving the physical
>> world)
>>   * Robustness and simplicity in routing or network fabric
>>
> This is a bit of a platitude, and why *or* here?
>> A chief component of these devices is wireless communication
>> technology. In particular, the IEEE 802.15.4 standard is very
>> promising for the lower (physical and link) layers. As for higher
>> layer functions, there is considerable interest from non-IETF groups
>> in using IP technology. The working group is expected to coordinate
>> and interact with such groups.

Which groups ? Are you referring to official liaisons with non  
official SDO ?

>>
>> The working group has completed a problem statement/requirements RFC
>> and and adaptation layer (IPv6 over 802.15.4) RFC.  The working group
>>
> Double "and"
>> has as its main objective to complete those topics and areas  
>> necessary
>> for successful implmentation interoperability.
>>
> What do you mean by "complete those topics"? Continue to advance on  
> the standards track?

I guess that stands for "start working on several missing pieces" ?

>> The required work includes items in the following (incomplete) list:
>>   * Addressing schemes and address management
>> * Network management
>> * Routing in dynamically adaptive topologies

Of course we need to be more specific here: under-mesh ?

>> * Security, including set-up and maintenance
>> * Application programming interface

We should then explain what this means since this is typically a topic
what could meant very different things ...

>> * Discovery (of devices, of services, etc)
>> * Implementation considerations

You mean implementation considerations.

Looks to me that the number of topics is really large without sufficient
description for each of them.

>>
>> Whereas at least some of the above items are within the purview of  
>> the
>> IETF, at this point it is not clear that all of them are.  
>> Accordingly,
>> the 6LoWPAN working group will address a reduced, more focused set of
>> objectives.
>>
> I think the above list raises more questions than it answers. When  
> I read it, I immediately ask "who is doing all this work? Should we  
> liaise with someone on it? is it possible to have interoperable  
> implementations without addressing all of these items? What else is  
> left? etc." Rather than try and capture the entire landscape in an  
> incomplete list, let's focus the charter on two things (1) What the  
> 6lowpan group is going to do, and (2) any *important* things that  
> this WG is *not* going to do. For the latter, any pointers to other  
> WGs, SDOs, etc. would be welcome.

AD's call but I do concur.

>> Scope of 6lowpan:
>>
>>   1. Produce “6lowpan Bootstrapping and 6lowpan IPv6 ND  
>> Optimizations”
>> to define the required optimizations to make IPv6 ND applicable in
>> 6lowpans, given the fact that IPv6 ND is too expensive for the  
>> devices
>> of 6lowpan and requires multicast.
> Do we have consensus that ND is too expensive? If so, great, but I  
> want to be sure.
>

I'm not so sure ... shouldn't we conduct some careful analysis first  
and just
indicate the WG item with no conclusion at this stage ?

> Secondly, do we have consensus that ND is required? If 6lowpans  
> have their own built-in address resolution due to the way addresses  
> are managed, what aspects of ND are necessary?
>> This document will define how to
>> bootstrap a 6lowpan network and explore ND optimizations such as
>> reusing the 802.15.4 network structure (use the coordinators), and
>> obviate multicast by having devices talk to coordinators without
>> creating a single point-of-failure, and changing the IPv6 ND  
>> multicast
>> semantics. This document will be a proposed standard.
>>
> This work item needs to be a little more crisp. Is this  
> "Bootstrapping" or "ND" or both? If both, are we making the  
> assumption that ND is the Bootstrapping method, but that it needs  
> to be changed to work in a lowpan?

Got the same questions.

>>   2. Produce “Problem Statement for Stateful Header Compression in
>> 6lowpans” to document the problem of using stateful header  
>> compression
>> (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of
>> stateless header compression given the assumption that stateful  
>> header
>> compression may be too complex. This document will determine if the
>> assumption is correct and will be an informational document.
>>
> For the last sentence "The WG will determine if the assumption is  
> correct at this time and record the findings in this informational  
> document."
>>   3. Produce “Recommendations for 6lowpan Applications” to define a
>> set of recommendations of protocols to use for applications. The
>> recommendations will cover protocols for transport, application  
>> layer,
>> discovery, configuration and commissioning. This document will be an
>> informational document.
>>
> Can we be specific as to which protocols will be covered? This  
> seems very open-ended.

Do we want to really provide recommendations or applicability  
statements ??
Also recommendations for configuration, commissioning and application  
layers
seem a bit out of the scope.

>>   4. Produce “6lowpan Mesh Routing” to evaluate different mesh  
>> routing
>> protocols for use within 6lowpans. While most routing protocols are
>> defined above the IP layer, 6lowpan requires a mesh routing protocol
>> below the IP layer. “6lowpan Mesh Routing” may be several proposed
>> standard documents.
>>
> I think we need to be sure that the line between this and the "RSN"  
> effort that is spinning up is clear. Also, nailing down which PS  
> documents will be necessary would be a very nice thing to do.

Indeed + first agree that a Mesh under solution is indeed required. I  
know
that this is likely to provide reactions but fair to ask at this point.

>>   5. Produce “6lowpan Security Analysis” to define the threat  
>> model of
>> 6lowpans and to document suitability of existing key management
>> schemes and to discuss bootstrapping/installation/commissioning/setup
>> issues. This document will be an informational document.
>>
> And you will need a security area adviser appointed for this. When  
> the time comes we will need to ask the secdir to appoint someone.
>
>> The working group will reuse existing specifications whenever
>> reasonable and possible.
>>
> s/specifications/protocols and mechanisms
>> The working group will also serve as a venue for ongoing discussions
>> on other topics related to the more complete list outlined above.
>> Additional related milestones may be added in the future via a
>> rechartering operation.
>>
> Not sure this is good advice. You already have a big chunk of work  
> to chew on. If discussion naturally ends up on this list for other  
> work, that's fine, but I don't see why it needs to be listed in the  
> charter as specifically allowed.
>> Note: As may be obvious from its official name above, this particular
>> working group will not work on IPv4 over IEEE 802.15.4  
>> specifications.
>> Given the limitations of the target devices, dual-stack deployments
>> are not practical. Because of its higher potential for header
>> compression, its support for the huge number of devices expected and
>> of cleanly built-in features such as address autoconfiguration, IPv6
>> is the exclusive focus of the working group.
>>
> I understand keeping IPv4 out of scope for within the lowpan, but I  
> do think it is important to write a recommendation for the 6lowpan  
> communicating on the Internet at large, in particular the IPv4  
> Internet. Thoughts on this?

Oh yes ! Would be happy to help there.

Still, I think that it would be nice to have at some point an open  
discussion on why NOT
IPv4, not pushing for anything here ... but having a "documented"  
discussion would I think
be helpful.

Cheers.

JP.

>
> Thanks,
>
> - Mark
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> 6lowpan mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/6lowpan
>>
>
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/6lowpan

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

---

From: "Timothy J. Salo" <[email-masked]>
Date: Sun, 15 Jul 2007 23:25:13 -0500

Geoff Mulligan wrote:
> 6lowpans” to document the problem of using stateful header compression
> stateless header compression given the assumption that stateful header

The need for and value of this document escapes me, but maybe it's
just me.

The 6lowpan format document contains the following language:

10.  Header Compression

    There is much published and in-progress standardization work on
    header compression.  Nevertheless, header compression for IPv6 over
    IEEE 802.15.4 has differing constraints summarized as follows:

       Existing work assumes that there are many flows between any two
       devices.  Here, we assume a very simple and low-context flavor of
       header compression.  Whereas this works independently of flows
       (potentially several), it does not use any context specific to any
       flow.  Thus, it cannot achieve as much compression as schemes that
       build separate context for each flow to be compressed.

       Given the very limited packet sizes, it is highly desirable to
       integrate layer 2 with layer 3 compression, something
       traditionally not done (although now changing due to the ROHC
       working group).

       It is expected that IEEE 802.15.4 devices will be deployed in
       multi-hop networks.  However, header compression in a mesh departs
       from the usual point-to-point link scenario in which the
       compressor and decompressor are in direct and exclusive
       communication with each other.  In an IEEE 802.15.4 network, it is
       highly desirable for a device to be able to send header compressed
       packets via any of its neighbors, with as little preliminary
       context-building as possible.

While we might consider tightening up this language, I think it at
least hints at all the reasons why 6lowpan networks need a static
header compression scheme:

o  We really need to compress headers where ever possible, not just in
    those cases where existing IETF approaches work (e.g., on
    point-to-point links and with flows that are long enough to
    create enough state to do the compression).

o  6lowpan devices can't affort to hold much state for any purpose,
    much less for dynamic header compression algorithms.

o  6lowpan topologies are likely to be highly dynamic (e.g., most
    devices may sleep most of the time).  Synchronizing the header
    compression state information after, for example, a device
    wakes up will probably be much more costly than using a stateless
    header compression scheme like that described in the 6lowpan
    document.

How is the existing language in the 6lowpan format document fail
to meet what ever objective is embodied in this work item?

I suggest that we:

o  Include any necessary justification for a stateless header
    compression scheme in the 6lowpan format document, rather than
    clutter up the RFC process and repository with another RFC that
    doesn't really say very much.

o  Figure out whether and how the existing language in the 6lowpan
    format document is deficient, and enhance it (if necessary).

(By the way, JPL developed some stateless header compressed
Internet protocols, namely SCPS-NP (IP), SCPS-TP (TCP) and
SCPS-SP (IPsec).)

-tjs