Subject: [6lowpan] Issue of the week: Charter finalization

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Dec 2007 20:45:10 +0100

(Sending from my gmail account, as lists.ietf.org seems to have some  
issues:)

Lowpanners,

we have had some recent discussion on issues related to network
structure, in particular the use of multicast and the issue of
sleeping nodes.  I don't want to interrupt this discussion, but I
would like to remind everyone that we also have one short term
objective: Getting rechartered.

The *theme of the week* for the working group is the finalization of the
charter.  In particular, the following questions have been raised:

A) is the timeline, which was too tight, now too relaxed?  (Obviously,
   the chairs don't think so, but what do you think?)

B) should there be work on a "minimal 6lowpan/IPv6 profile"?  (I had
   envisioned each of the use cases to explain what protocols are used
   in implementing that particular use case, not the generation of a
   unified minimal profile that would apply to all use cases.)

C) Daniel has reminded us that there needs to be a management solution
   at some point.  I'm not sure that simply defining a MIB is the
   right way to provide this (SNMPv3 on sensor nodes?).  Instead, we
   could add "management method" to the subjects of the architecture
   document before actually creating the solution.  Is that the right
   place?

D) The discussions about multicast have reminded us that 4944 alone
   does not provide a solution beyond a single radio range.  MANET's
   SMF provides one, but presupposes some support from the routing
   protocol.  The BbR approach reminds me of 802.11, where all
   multicast is unicast to the AP which then sends it back into the
   wireless network (which might allow a simplified flooding based on
   something like RPF).

E) There were some comments during the meeting that we already were
   taking on a sizable amount of work.  I'm not sure we want to take
   on all of the other points Daniel raised:

   [...] I guess we should consider how to improve the quality of RFC
   4944, especially Global Address HC, TCP operation, ICMPv6 operation
   and etc. RFC 4944-bis is one of options.

   [...] how to dig out *mobility issue* from the proposed charter. I
   guess some of requirements of mobility for 6lowpan networks is
   doable for the initial activity at this stage except specific
   mobility solutions.

F) Going through each of the documents, the following contributions
have been promised recently:

1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have
longstanding contributions from Samita Chakrabarti and Erik Nordmark.
Anybody else?  Daniel has also proposed to split 1 into bootstrapping
and ND optimization.  There is also the subject of commissioning.
What is the right set of documents, and which ones do (each of) you
want to work on?

2 "Problem Statement for Stateful Header Compression in 6LoWPANs":
During the meeting, Kris Pister indicated that he was interested in
contributing, and Carsten Bormann (that would be me) might be
contributing a bit of ROHC background.

3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff
Mulligan, and JP Vasseur.  Any other takers?  In particular, somebody
with a network management slant?

3a "Routing requirements" (which needs its own milestone entry) has a
draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann.  During
the RL2N BOF, a similar document was proposed as a result of the
RL2N-followup WG to be formed.  We need to understand whether the two
documents (the 6lowpan one and the rl2n++ one) are sufficiently
different or whether we simply need to cooperate on one document,
which would then have to include the 6lowpan-specific aspects
including mesh-under.

4 "Use Cases for 6LoWPAN".  Zach Shelby has indicated his interest.
Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs"
might provide a basis, but we need more input, in particular from
implementors of each of these scenarios that we actually want to use
as use cases.

5 "6LoWPAN Security Analysis".  Nobody?  (I might provide some input,
but can't do this on my own.)

6 Implementers' guide: Zach Shelby is interested

7 Interop guide: Zach Shelby is interested

In order to accelerate rechartering, we should have answers to these
questions/credibles sets of contributors to these documents at the end
of this week, so please don't hesitate providing your input.

Gruesse, Carsten

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Dec 2007 21:46:53 +0100

>   document before actually creating the solution.  Is that the right

[...]

> with a network management slant?

[...]

Just to let you know that I am still lurking on this list. I am not
sure what is needed at this point in time concering management. SNMP
can be reasonably byte efficient (and there were proposals in the past
to make it even more efficient) but it uses a polling approach which
may be questioned on some 6lowpan scenarios where you might want to
save the requests and perhaps even do aggregation along the routing
path. On the other hand, we might be able to reuse some of the IPv6
MIBs and that might be goodness.

During our 6lowpan implementation exercise, we found a few things in
the RFC that would be nice to fix and which we have posted to this
list (without much feedback I must say). From my perspective, I think
there should be continued work on the 6lowpan specifications - either
as an implementors guide or simply work towards revised specifications.

And it might help to actually have interoperability tests carried out
to see how much implementations interoperate in terms of the various
compression schemes and fragmentation. Who would participate in some
interoperability test at one of the upcoming IETFs?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 10 Dec 2007 22:51:26 -0700

Juergen,
  I guess that I missed your suggestions on fixes to the RFC?

Perhaps after we get this rechartering done we can take up the fixes.

I like the idea of finding a way to more efficiently transfer SNMP
messages as well as a simpler way to implement SNMP (not a full ASN.1)

	geoff

---

From: [email-masked]
Date: Tue, 11 Dec 2007 21:46:56 +0100

>   I guess that I missed your suggestions on fixes to the RFC?

http://www1.ietf.org/mail-archive/web/6lowpan/current/msg00669.html
http://www1.ietf.org/mail-archive/web/6lowpan/current/msg00670.html
http://www1.ietf.org/mail-archive/web/6lowpan/current/msg00671.html
http://www1.ietf.org/mail-archive/web/6lowpan/current/msg00672.html

Matus

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Dec 2007 23:18:07 +0100

>   I guess that I missed your suggestions on fixes to the RFC?

The relevant messages were posted in June:

Message-ID: <[email-masked]>
Date: Tue, 19 Jun 2007 00:12:09 +0200
From: Matus Harvan <[email-masked]>
Subject: [6lowpan] compressed UDP Length field

Message-ID: <[email-masked]>
Date: Tue, 19 Jun 2007 02:17:05 +0200
From: Matus Harvan <[email-masked]>
Subject: [6lowpan] ICMP error messages - ICMP payload

Message-ID: <[email-masked]>
Date: Tue, 19 Jun 2007 01:43:33 +0200
From: Matus Harvan <[email-masked]>
Subject: [6lowpan] fragment reassembly

Message-ID: <[email-masked]>
Date: Tue, 19 Jun 2007 02:06:46 +0200
From: Matus Harvan <[email-masked]>
Subject: [6lowpan] alignment of HC-compressed/inline-carried fields
 
> messages as well as a simpler way to implement SNMP (not a full ASN.1)

SNMP never used full ASN.1 - and I am not sure BER encoding is
actually a problem. There are implementation techniques to deal with
BER data reasonably fast and with a small memory footprint.

Most of the overhead in SNMP messages comes from the OIDs if an SNMP
message carries multiple varbinds; there have been proposals in the
past to perform OID compression - not sure whether some of this would
be applicable here.

The other probably more important thing is of course again security;
SNMPv1 is historic and SNMPv3 with security is much more verbose and
computationally expensive (if you enable security).

/js

---

From: "Pete St. Pierre" <[email-masked]>
Date: Tue, 11 Dec 2007 20:21:06 -0800

Carsten, Geoff, et. al.,
Thanks for all your hard work in getting the draft charter finalized  
for WG discussion last week in Vancouver.  I think it did a very good  
job of incorporating the many opinions discussed on the list in the  
last few months.

While there were always be room to massage details, I'm definitely in  
favor of adopting the work items as described and look forward to  
contributing to some of the deliverables.

Additional comments below.

>  the chairs don't think so, but what do you think?)

I think the timelines are reasonable.  I believe some of the items  
depend on more empirical data which can only be gained from deployment  
experience.  The scenario descriptions help here, but I think we need  
much more depth in the descriptions.

>  unified minimal profile that would apply to all use cases.)

I think there is value (if a useful unified set can be found) to a  
single profile.  We're pushing for interoperability and there's  
nothing more frustrating that saying, "yes, it's 6lowpan, but not that  
profile".

>  on all of the other points Daniel raised:

For the current charter, I think we've set a good course.  I think  
there is merit to Daniel's comments, but I think we need to focus on  
the initial items.  If the priority changes or we find ourselves  
incredibly efficient, we can always propose amending the charter.
> have been promised recently:
< -- document list clipped to save electrons -- >

Given that I'm in the midst of a Java implementation of IPv6/6lowpan  
I'm really looking forward to contributing to the Implementer's guide  
and interoperability drafts.  I cut my networking teeth in the SNMP  
space and wouldn't refreshing my cranial cache and pitching in on the  
architecture spec if my time allows.  Implementation and  
interoperability are definitely my main concerns at this time.

...Pete
--
Pete St. Pierre
Sun Microsystems, Inc
http://www.sunspotworld.com

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 13 Dec 2007 05:51:41 +0100 (CET)

Hi Geoff, Carsten, all,

>    unified minimal profile that would apply to all use cases.)

We believe there could be a minimal 6lowpan/Ipv6 profile derived from the
analysis of the different uses cases. If the profile is not reduced we can
define a set of profiles, suitable for different uses cases. A
profile-based solution could address the diversity of requirements that
arise from different use cases.

>    document before actually creating the solution.  Is that the right

Yes, we believe management should be considered in the architecture

>    wireless network (which might allow a simplified flooding based on

We believe some multicast solution should be supported, but it should be
considered possibly by RL2N, where unicast and multicast routing protocols
can be matched if necessary.

>    and etc. RFC 4944-bis is one of options.

Transport protocols should be considered. See our comment below (regarding
the architecture topic).

>    doable for the initial activity at this stage except specific

According to our vision, mobility is not a strict requirement at this
stage. In most cases, it can be solved through a quick network
reconfiguration.

> with a network management slant?

We believe transport protocols should be considered. In a reduced resource
network, crosslayer issues should be considered. Architecture should
consider this fact providing mechanisms to exchange relevant information
(reliability, link quality,..) through layers

> which would then have to include the 6lowpan-specific aspects

We believe, at least at this time, it might not be necessary having two
different routing requirements documents (one from RL2N and one from
6LoWPAN). Since LoWPAN scenarios are a subset of those considered by RL2N,
at least there should be an RL2N requirements document, which should
address the requirements for 6LoWPAN. If RL2N requirements were too broad
for 6LoWPAN, then a routing requirements document for 6LoWPAN would make
sense.

> implementors of each of these scenarios that we actually want to use

We can contribute. We have developed applications for home automation,
healthcare and city management environments.

> 6 Implementers' guide: Zach Shelby is interested

We may contribute.

> 7 Interop guide: Zach Shelby is interested

Best regards,

Carles Gomez
Technical University of Catalonia

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Thu, 13 Dec 2007 17:15:24 +0900

Hi Carles,

My thought is inline;

>[....]

[E] Carles, as you already know, RL2N focuses on 3 scenarios at this
moment  based on multiple PHY/MAC condition. I believe that 6LoWPAN
needs its own routing requirement narrowing down the scope of the
document as 6LoWPAN specific, including its very unique node
characteristics. I think that RL2N can use the input as one of the
area where RL2N solution will be used.

> healthcare and city management environments.

[E] I think the current "application space" documents contains home
automation and healthcare. I think the doc need to have deeper depth
by collecting experiences like you did. It must be great to work
together.

-eunah

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Dec 2007 09:25:03 +0100

Hi:

Maybe we should be more explicit on what we assume from the mesh-under when there is a mesh-under. 
In particular what we expect as multicast routing from that L2 mesh-under service. 
If we make no assumption then we implicitly accept that plain flooding/pruning is also a supported option to carry L3 multicast.
And I would not base ND support on that.

Pascal

>-----Original Message-----
>From: Eunsook "Eunah" Kim [mailto:[email-masked]] 
>Sent: jeudi 13 décembre 2007 09:15
>To: Carles Gomez Montenegro
>Cc: Carsten Bormann; 6lowpan
>Subject: Re: [6lowpan] Issue of the week: Charter finalization
>
>Hi Carles,
>
>My thought is inline;
>
>>[....]
>> > 3a "Routing requirements" (which needs its own milestone 
>entry) has 
>> > a draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann.  
>> > During the RL2N BOF, a similar document was proposed as a 
>result of 
>> > the RL2N-followup WG to be formed.  We need to understand whether 
>> > the two documents (the 6lowpan one and the rl2n++ one) are 
>> > sufficiently different or whether we simply need to 
>cooperate on one 
>> > document, which would then have to include the 6lowpan-specific 
>> > aspects including mesh-under.
>>
>> We believe, at least at this time, it might not be necessary having 
>> two different routing requirements documents (one from RL2N and one 
>> from 6LoWPAN). Since LoWPAN scenarios are a subset of those 
>considered 
>> by RL2N, at least there should be an RL2N requirements 
>document, which 
>> should address the requirements for 6LoWPAN. If RL2N 
>requirements were 
>> too broad for 6LoWPAN, then a routing requirements document for 
>> 6LoWPAN would make sense.
>>
>
>[E] Carles, as you already know, RL2N focuses on 3 scenarios 
>at this moment  based on multiple PHY/MAC condition. I believe 
>that 6LoWPAN needs its own routing requirement narrowing down 
>the scope of the document as 6LoWPAN specific, including its 
>very unique node characteristics. I think that RL2N can use 
>the input as one of the area where RL2N solution will be used.
>
>[E] I think the current "application space" documents contains 
>home automation and healthcare. I think the doc need to have 
>deeper depth by collecting experiences like you did. It must 
>be great to work together.
>
>-eunah
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 17 Dec 2007 13:17:34 +0100 (CET)

Hi all,

Regarding our comment on routing requirements in our last e-mail, we
would like to clarify our point of view.

We believe RL2N/ROLL should have a set of routing requirements which
should satisfy the ones provided by 6LoWPAN. We would like to emphasize
that we strongly support the need for 6LoWPAN own routing requirements
draft, according to the specificities of 6LoWPAN environments.

Best regards,

Carles