Subject: [6lowpan] Re: I-D ACTION:draft-ekim-6lowpan-scenarios-00.txt

From: JP Vasseur <[email-masked]>
Date: Tue, 17 Jul 2007 19:43:42 -0400

Hi,

First of all, great idea to write such draft !! This is exactly along  
the lines of what I was proposing to add to the charter  
(Applicability statement) in a previous email recently sent to the list.

Some Comments:

* When describing the problem space I would suggest to explicitly  
mention that a LoWPAN is made of devices of various nature including  
Sensors but certainly there are non sensors devices (actuators, ...).
* I would suggest to add two bullets in the "Design Space" section:  
Management (self healing properties) and Security.

For each of the example that you provide, I would suggest to add a  
few dominant parameters:
	* Required Level of Security
	* Requirement for Multi-topology routing
	* Requirement for QoS support	
	* Traffic pattern: P2MP/MP2P or P2P

* Structural Monitoring: just mention that the number of nodes may in  
some cases be on the order on a few hundreds of nodes. I would not  
say that most of topologies are start topologies (there are many  
deployment cases where we have true mesh networks).
	Security level: high
	MTR: no
	Support of QoS: no
	Traffic Pattern: P2MP/MP2P

* Agricultural:
         Security level: high
	MTR: no
	Support of QoS: no
         Traffic Pattern: P2MP/MP2P and P2P

* Healthcare: I would suggest to list several applications here: (1)  
Healthcare at home (with scheduled monitoring and emergency), (2)  
Hospitals (and again there might be several applications with  
different level of criticality: at one end of the spectrum the ER  
(e.g. SMART project) and at the other end of spectrum for object  
tracking.
         Security level: high
	MTR: TBD
	Support of QoS: yes
         Traffic Pattern: P2MP/MP2P and P2P

* Vehicular: might be good to differentiate car to fix infrastructure  
(your example) and car to car communication in this case.

* I would suggest to add the Industrial (process control, ...) and  
Connected Home cases.

About Section 4: there are of course many other benefits that could  
be listed but I would certainly suggest to add the fact that we'll  
see more and more device-to-device communication, in which case two  
nodes running different proprietary protocols would have to  
communicate via a protocol translation gateway with all known  
consequences.

Thanks.

JP.

On Jun 11, 2007, at 3:50 PM, [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Design and Application Spaces for 6LoWPANs
> 	Author(s)	: E. Kim, et al.
> 	Filename	: draft-ekim-6lowpan-scenarios-00.txt
> 	Pages		: 16
> 	Date		: 2007-6-11
> 	
>    This document investigates potential application scenarios and use
>    cases for low-power wireless personal area networks (LoWPANs).
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ekim-6lowpan- 
> scenarios-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ekim-6lowpan-scenarios-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ekim-6lowpan-scenarios-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Wed, 18 Jul 2007 17:53:58 +0900

Hi JP,

Thanks for your support on this draft and your valuable comments.
I will add your comments in the next version.
Some answers are inline. :)

Thanks,

-eunsook

On 7/18/07, JP Vasseur <[email-masked]> wrote:
> Hi,
>
> First of all, great idea to write such draft !! This is exactly along the
> lines of what I was proposing to add to the charter (Applicability
> statement) in a previous email recently sent to the list.
>
> Some Comments:
>
> * When describing the problem space I would suggest to explicitly mention
> that a LoWPAN is made of devices of various nature including Sensors but
> certainly there are non sensors devices (actuators, ...).

Good point. It will be added in the next version.

> Management (self healing properties) and Security.

Good suggestion. It would be good that you can contribute on this part
if you have something already in your mind. :-)

> For each of the example that you provide, I would suggest to add a few
> dominant parameters:
> * Structural Monitoring: just mention that the number of nodes may in some
> cases be on the order on a few hundreds of nodes. I would not say that most
> of topologies are start topologies (there are many deployment cases where we
> have true mesh networks).

Yes, it won't be only with star topologies. We want to mention an
example to have very simple star or two or three tiers of hierarchical
star topologies (different from hierarchical tree which is one of
mesh).

> Traffic Pattern: P2MP/MP2P
Thanks. I will add it.

>         Traffic Pattern: P2MP/MP2P and P2P
OK. :)

> Healthcare at home (with scheduled monitoring and emergency), (2) Hospitals
> (and again there might be several applications with different level of
> criticality: at one end of the spectrum the ER (e.g. SMART project) and at
> the other end of spectrum for object tracking.
>         Security level: high
> MTR: TBD
> Support of QoS: yes

Thanks. We will add it to the next version.

> * Vehicular: might be good to differentiate car to fix infrastructure (your
> example) and car to car communication in this case.
>
Right. As this is an initial version, we add only car to fix
infrastructure, but later car to car communication can be studied and
added later. :)

> * I would suggest to add the Industrial (process control, ...) and Connected
> Home cases.
>
> About Section 4: there are of course many other benefits that could be
> listed but I would certainly suggest to add the fact that we'll see more and
> more device-to-device communication, in which case two nodes running
> different proprietary protocols would have to communicate via a protocol
> translation gateway with all known consequences.
>

right. :)

---

From: JP Vasseur <[email-masked]>
Date: Fri, 20 Jul 2007 17:12:11 -0400

Hi,

On Jul 18, 2007, at 4:53 AM, Eunsook Eunah Kim wrote:

>> mention

Surely, let's talk next week.

>> few
>> Hospitals

OK

>> Connected

Great, cheers.

JP.