Subject: RE: [6lowpan] Agenda for next meeting

From: "Eunsook Kim" <[email-masked]>
Date: Mon, 5 Mar 2007 17:24:36 +0900

Geoff,

>I think that the main topic for the meeting is the rechartering, but I 
>think that it is extremely important that we talk with the Manet group 
>and understand if their work can apply to 6lowpans. 
> 
>This understanding though may be based on the network architecture that 
>we are trying to build.  This is why I think that we should start with 
>defining the 6lowpan arch. 

I have my two thumbs-up for your suggestion to start with defining the 6lowpan arch.
While I have been approaching 6lowpan work from routing perspective,
I strongly felt that we need architecture, framework, specific requirements for 6lowpan beforehand of all details. 

I would like to happily involve this work, if there is any space to fill up. :-)

>Additionally, we need to reach some consensus on: 
>  * Routing (scalable, mesh under, route over) 
>  * Security 
>  * bootstrapping/commissioning 

In terms of routing, I would like to suggest to have the same approach with Arch. work.
We need to think more fundamental perspective for routing before going further to the details.

Thanks,

- eunsook

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

---

From: Tiago Camilo <[email-masked]>
Date: Tue, 06 Mar 2007 12:33:05 +0000

Hi,
Eunsook Kim wrote
> I would like to happily involve this work, if there is any space to fill up. :-)
I truly agree with the need to come up with a 6lowpan architecture, that 
became the basis of our working group. Such draft should address the 
topology, architecture and 6lowpan devices. Is important to understand 
how can mesh devices, from as small as 4K of flash and 100s of bytes of 
RAM up to devices full capable of routing, sensing and acting. Should we 
consider in adopting some kind of addressing functions for the smaller 
devices? or as Ron Strich stated: "Should we make it easy for these 
simple protocol implementations at this level to adapt to 6lowpan? If we 
want to include these small devices, should we consider a more 
constrained design (limited payload, P2P/star only) that would simplify 
the adaptation layer?"
I think that in the near future 6lowpan networks will be a group of 
truly mesh devices, that will present different characteristics (i.e. 
power, memory and radio frequency) and therefore is important to create 
a stable 6lowpan framework, allowing the devices communication.
As Eunsook Kim i also would like to be involve, if possible, in such 
definition.
Tiago Camilo