Subject: [6lowpan] Issue of the Week: Charter Finalization

From: Geoff Mulligan <[email-masked]>
Date: Mon, 10 Dec 2007 13:46:56 -0700

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.  

Carsten and I don't want to interrupt this discussion, but we would like
to remind everyone that we also have one CRITICAL 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"?  (We 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.  We're 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 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".  Daniel / Anybody?  (Carsten and Geoff
might provide some input, but can't do this on their own.)

6 Implementers' guide: Zach Shelby and Jonathan Hui are interested.
What about the other folks that have built or are building 6LoWPAN
implementations.

7 Interop guide: Zach Shelby and Jonathan Hui are interested. What about
the other folks that have built or are building 6LoWPAN implementations.

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

Gruesse, Carsten and Geoff

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Dec 2007 09:04:10 +0100

Hi Geoff:

My answer is 2 fold: organizational and functional.

1) moving forward:

What I see in the charter is a lot of good work ahead, and maybe not enough people for doing it! There's nothing I would drop from your long list. There's even some stuff I'd wish to add. But then we need to hire on this list!

Long as we have enough people committed on contributing to a given task, go for it.  Seems that a cross ref between prioritized work items and volunteers could help sort manning out. Are the tasks in the charter already ordered by priority?

2) items: 

I can commit to participate to the ND work, in particular WRT BrB. I agree with your image of an AP up to the point that with BrB, ND is done with recoverable unicast over a multihop mesh under, whereas in the WIFI AP case, we have direct sight and the AP actually rebroadcasts things that were passed unicast, with no recovery. So please count me in for the ND related work.

I'm also interested on a work item that is not mentioned on the charter, fragment flow control and recovery. Considering that a 1500 bytes packet will be sliced in about 25 pieces, and that the loss of a single fragment causes the resending of the 25 of them, it might be appropriate to propose a minimalist fragment recovery to start with, wouldn't you think?

Finally, I'm all for the 6LoWPAN profile and I know enough people who wish to contribute. The question is whether that one should be done at 6MAN or 6LoWPAN. Maybe we could get some wisdom from the ADs on this?

I hope this helps

Pascal

>-----Original Message-----
>From: Geoff Mulligan [mailto:[email-masked]] 
>Sent: lundi 10 décembre 2007 21:47
>To: 6lowpan
>Subject: [6lowpan] Issue of the Week: Charter Finalization
>
>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.  
>
>Carsten and I don't want to interrupt this discussion, but we 
>would like to remind everyone that we also have one CRITICAL 
>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:
>
>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?
>
>During the meeting, Kris Pister indicated that he was 
>interested in contributing, and Carsten Bormann 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.
>
>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".  Daniel / Anybody?  (Carsten 
>and Geoff might provide some input, but can't do this on their own.)
>
>What about the other folks that have built or are building 
>6LoWPAN implementations.
>
>7 Interop guide: Zach Shelby and Jonathan Hui are interested. 
>What about the other folks that have built or are building 
>6LoWPAN implementations.
>
>In order to accelerate rechartering, we should have answers to 
>these questions/credible sets of contributors to these 
>documents by the end of this week, so please don't hesitate 
>providing your input.
>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 11 Dec 2007 14:23:42 -0500

Hi Geoff,

The proposed charter captures very well the discussions that we've been
having for some time, thanks.

Minor comments in line,

> From: Geoff Mulligan <[email-masked]>
> Date: Mon, 10 Dec 2007 13:46:56 -0700
> To: 6lowpan <[email-masked]>
> charter.  

OK so I won't comment on this aspect for the time being ;-)

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

Are you planning to share the proposed Milestones?

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

Can't agree more ... We had an informational discussion on this topic last
Thursday and this was also my input: if we want to work on a minimal
6lowpan/IPv6 profile (and I think that we should), it will have to be on a
per-case basis.

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

I think so, at least to start with. Should there be a need to define a SSNMP
(Super Simple ....), would it be done here ?? I'm not against this idea, but
it is by itself a fairly heavy work item.

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

*If* a ROLL WG is formed that is certainly an area that we'll be working on.
Hopefully the solution should be applicable to 6lowpan.

>    doable for the initial activity at this stage except specific

I would certainly not add anything to what is already quite loaded.

> and ND optimization.

I second that.

There is also the subject of commissioning.
> What is the right set of documents, and which ones do (each of) you

Count me in (for comments).

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

If a ROLL WG is formed, the situation will be much clearer in a few months.
I can see two options here:
1) Leave this out of the new charter for the moment,
2) Include the mesh-under routing requirement as the WG item, in which case
it would be preferable to have one document with the mesh under routing
requirements specifics being worked out in 6lowpan, feeding ROLL (if
formed). The challenge here is that this document will most likely look
quite similar to the first routing requirement David and I had started with
before moving to a use case approach ...

> What about the other folks that have built or are building 6LoWPAN

Could you shed some light on what you mean by "Implementers' guide"
especially in an IETF context?

> the other folks that have built or are building 6LoWPAN implementations.

Certainly useful.

> of this week, so please don't hesitate providing your input.

Thanks.

JP.

---

From: "Ki-Hyung Kim" <[email-masked]>
Date: Wed, 12 Dec 2007 05:11:02 +0900

Hi Geoff and Carsten,

The proposed charter looks quite nice and appropriate to move forward.
The comments are in line.

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

The timeline looks OK and to be safe to keep.

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

I think this issue could be raised later case by case.

>   document before actually creating the solution.  Is that the right
Very simple NMP could be described in terms of architecture of 6lowpan.

>   doable for the initial activity at this stage except specific
I think we could consider them if we have volunteers anytime.

> What is the right set of documents, and which ones do (each of) you
I would like to contribute the bootstrapping and commissioning ID.

> with a network management slant?
I would like to contribute on the part of the architecture, including mesh
under vs route over, scalability issue (scalable 6lowpan architecture),
management mechanism for 6lowpan (very simple NMP), service discovery issue.

> implementors of each of these scenarios that we actually want to use
I might contribute some use cases of 6lowpan, including the testbed of
meteorological sensor networks which integrates 6lowpan with wireless mesh
networks, use cases of building management. for instance, we have more than
200 sensor nodes installed on one floor in our office building. It could be
extended to the entire building for multi-purposes of building management
such as security, energy saving, etc.

> the other folks that have built or are building 6LoWPAN implementations.
For both implementer's guide and interop guide, I could contribute some part
of them, as we have an implementation of 6lowpan and more than 10 reference
sites of 6lowpan in Korea.

> Gruesse, Carsten and Geoff

I hope this helps the WG to accelerate the rechartering and move forward.

-- 
Ki-Hyung Kim
Founder and CTO of picosNet, Inc. (http://www.picosnet.com)
Tel: +82-31-219-2433, Cel: +82-10-4760-2551
_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 11 Dec 2007 12:17:46 -0800

Overall, the charter looks good to me. Though I do think that some of 
the items must be more use case driven, as I think that we'll probably 
see different requirements based on the use cases. So maybe the wording 
on the charter items should change to reflect that? See comments below:

Geoff Mulligan wrote:

[...]

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

While we'd all like to see 6LoWPAN move faster, I think the current 
timeline is realistic and achievable.

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

Yes. But I do believe that it should be specified case-by-case driven by 
the application, network architecture, or both. Maybe this should be a 
part of the use case documents?

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

Manageability is important, but it's not clear whether SNMP or something 
SNMP-like is the right approach. Maybe we should have some work that 
surveys existing management mechanisms/methodology?

[...]

> What is the right set of documents, and which ones do (each of) you

I'm interested in specifying ND/autoconf for route-over. I know this 
overlaps with the AUTOCONF WG and I should probably start there. But I 
do believe that 802.15.4 places some more stringent requirements on the 
autoconf solution (e.g. 6LoWPAN's mapping of L3 to L2 addresses, extreme 
resource constraints, etc.) and that we can make 802.15.4 specific 
optimizations. Do the chairs have any thoughts on this?

> contributing, and Carsten Bormann might be contributing a bit of ROHC

I'm interested in continuing my effort on HC1g and defining 6LoWPAN 
header compression for route-over configurations. I do believe this may 
be separate from the solution for mesh-under.

> with a network management slant?

I can help out on the overall doc if help is needed.

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

Yes, it's unclear to me how the 6LoWPAN and ROLL documents are related 
and if they will be sufficiently different. I also believe that routing 
requirements must be use-case driven, so it's unclear to me whether this 
should be done in a single document, or as part of documents that 
describe use cases.

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

Not sure if the intention here is to generate a single Use Case 
document. I'm seeing a pattern here where decisions may and probably 
will be largely driven by the use case. This applies to minimal node 
requirements, routing requirements, etc. Maybe we should generate 
separate docs for individual use cases that the WG is interested in that 
lay out each of the requirements?

--
Jonathan Hui

---

From: Philip Levis <[email-masked]>
Date: Tue, 11 Dec 2007 14:32:58 -0800

> having for some time, thanks.

I agree with JP. The routing requirements work item will have some  
interesting collaborations with ROLL if it forms. But that does not  
mean 6lowpan should not do it. If anything, ROLL can take an approach  
from above while 6lowpan can take an approach from below.

Overall, I think the charter is in good shape and I support it.

Phil

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Wed, 12 Dec 2007 11:13:57 +0900

Hi Geoff & Carsten,

The current proposed rechartering items are well-shaped, but I feel
that somehow we restart some old discussion in some part. My comments
are inline.

> timeline is realistic and achievable.

[E] I agreed on it, but when I see the recharter discussion, it kinda
push us back to the previous meeting. We had a long discussion on
rechartering items until we see the current proposal.
I think we have good base documents for current recharter item, so the
way we can achieve the timeline is not to restart if we include
something or not, but to gather opinion what's our expectation on each
items. Then, the current authors and future contributors gather the
idea to progress the work.

> part of the use case documents?

[E] Yes. We had an informal meeting in Vancouver, including JP,
Jonathan, Mikko, Dominik and Eunsook to discuss this topic. We
discussed how to approach this work by our experience to implement
6lowpan. What we discussed was it's necessary work for implementors,
it will be an informational guide to 6lowpan implementors, and will be
described case by case (based on configuration, networking,
architecture)

But, I think in somehow, we mix the current 'use case' in the charter
with 'implementation guide'. It surely would be discribed
case-by-case, but it's different from the current 'use case' approach,
I think. In the current 'use case(scenario)', it shows applicability
of 6lowpan with a bit more general view, and more scenario base, which
could have similar configuration cases, different data gathering
pattern, etc. I totally agree that the current document needs to be
touched more implementation information, but I disagree to combine
'profiling cases for implemetation' with 'use case(scenario)' of
6lowpan.
It will delay the current work, and we need to spend some time to
match the different view on it.

> optimizations. Do the chairs have any thoughts on this?

[E] I'm also interested in ND, and I also think we can look at
autoconf wg work first.

> be separate from the solution for mesh-under.

no arguement at all. :)

> should be done in a single document, or as part of documents that

[E] If ROLL is in clear status, we can discuss how we will progress
this work together. But, I don't think we should take out this work
from our charter now. I clearly see we have both common and different
parts together. It doesn't mean that we don't need to do the work due
to the common part. We, 6lowpaners should make our requirements and
give the input to ROLL.
Actually, I partially agree that we need to describe the requirements
in use-case driven. Due to 6lowpan node characteristics, we have very
general 6lowpan requirements, and some part of requirements can be
different by use-case (not scenario, but more likely networking case).
We can enhance the current documents to specify more 6lowpan general
req, and put chapter to point out req. for different neworking cases.

> lay out each of the requirements?

[E] In my view, here 'use case' is a guideline to show 6lowpan's
applicability. Based on each application scenario, it should contain
deployment cases, topology, high-level technical characteristics for
each scenario, implementation perspective guide to deploy, etc.
As I mentioned in the above, I think we need to enhace the current doc
to collect more industries' input. But, again, this is not an specific
profiling or so. It should be more general picture for 6lowpan
applicatability, IMO.

> > What about the other folks that have built or are building 6LoWPAN

[E] If you mention profiling here. I already said my opinion in the
above that we, some 6lowpaners already volunteered, and I'm one of
them. Although you say different thing, I think implementer's guide is
always useful.

> > the other folks that have built or are building 6LoWPAN implementations.

[E] In the informal profiling meeting, we exchanged our thought on
having an event of interoperability test. :) It would be good to have
a doc for it. :)

Thanks chairs for the new charter, and I hope we have discussion to
progress the works in the new charter item now.

- Eunsook

---

From: "Myung J. Lee" <[email-masked]>
Date: Thu, 13 Dec 2007 14:52:26 -0500

Dear Carsten and Geoff,

You and the group members did a great job in preparing all the works
necessary for rechartering.
Although I have been working quite sometime for "mesh under" within IEEE
802.15.5, 6lowpan is relatively new to me. 
Nevertheless, I find that the categories of the work items are well done,
which would develop into a set of RFCs useful for the services envisioned in
the charter. 
    
Few comments are added inline below.

Thank you,

Myung Lee
[email-masked]

-------------------------------------------------------

==> I think the timeline is reasonable.

==> A unified profile would necessarily be fat and the other extreme would
pose interoperability problem. Thus, we may need to narrow down the use
cases into a few MAJOR categories according to some measures, for instance,
with/without line power, mobility, number of nodes, etc. Also, if there is a
urgent and strong market need, it should be taken care of first. 

==> Yes, we need management solution. Currently, 15.5 solution permits MAC
and Mesh MIB access via primitives in management plane. 

==> In view of performance, I believe any functions and services slanted
towards applications, they are to be placed at higher layers, but simple
common services to all layers may be placed lower.

===> We may work on specific requirements for reliable e2e protocol for WSN,
since TCP doesn't fit for error prone and band stricken 6lowpan environment.

==> The mobility issue may be undertaken in conjunction with the profiles
above, considering use cases that need mobility. I am interested in this
area. 

==> I am interested in this area.

==> I am interested in contributing some in this area.

---

From: "Daniel Park" <[email-masked]>
Date: Fri, 14 Dec 2007 12:35:56 +0900

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

Agreed.

<snip>

>   doable for the initial activity at this stage except specific

"draft-chakrabarti-mobopts-lowpan-req-01" is doable and I don't see
any harmful to this work at this stage. As a part of manemo (manet
mobility) use cases, we had a 6lowpan mobility discussion before
within IETF. 6lowpan WG is a base camp and works with others WGs (nemo
folks, manet folks, etc) together..By doing this work, we will be able
to deploy 6lowpan networks larger than today.

I guess Pascal can help out with his namo expertise in this space. Right ?

> What is the right set of documents, and which ones do (each of) you

I am interesting in ND optimization (based on 16ng ND extension
background) and commissioning part.

<snip>

> might provide some input, but can't do this on their own.)

If other guys are help me with their security expertise, that would be
great. I will go for the revision to be ready for WG adoption soon.

Thanks,

Daniel Park

---

From: Mikko Saarnivala <[email-masked]>
Date: Fri, 14 Dec 2007 12:13:48 +0200

Hello, Geoff and all - comments inline.

> to remind everyone that we also have one CRITICAL short term objective:

I feel that the proposed charter is nicely structured with well defined scope 
and support it with minimal changes.

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

 From my standpoint of view the timeline _could_ be even more aggressive on some 
items but maybe it's best to keep it as it is in order to remain realistic.

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

I think this would be recommendable as there seems to be several issues that 
need to be defined in order to guarantee system level interoperability. I would 
also be willing to contribute to this item.

Eunah has already mentioned on the list about the informal meeting that some of 
us (Eunah, JP, Dominik, Jonathan and I) had in Vancouver on the possible minimal 
6lowpan profile item. I took some notes on the meeting and will probably post 
them later on the list.

> What is the right set of documents, and which ones do (each of) you

I would be willing to contribute to this item.

> the other folks that have built or are building 6LoWPAN implementations.

Best regards,

-- 
Mr. Mikko Saarnivala | Software systems | +358 50 5696287
Sensinode Ltd. | <URL:http://www.sensinode.com>