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

[JP Vasseur <[e-mail]>]

Hi,

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

> 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 <[e-mail]> 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.
>
>> * I would suggest to add two bullets in the "Design Space" section:
>> 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. :-)
>

Surely, let's talk next week.

>> 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).
>
> 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).
>
>> Security level: high
>> MTR: no
>> Support of QoS: no
>> Traffic Pattern: P2MP/MP2P
>>
> Thanks. I will add it.
>
>> * Agricultural:
>>         Security level: high
>> MTR: no
>> Support of QoS: no
>>         Traffic Pattern: P2MP/MP2P and P2P
>>
> OK. :)
>
>> * 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
>>
>
> 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. :)


OK

>
>> * 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. :)
>

Great, cheers.

JP.

>> Thanks.
>>
>> JP.
>>


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