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 <[EMAIL PROTECTED]> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
