Hi Bernard,
On Jul 9, 2007, at 5:50 PM, Bernard Tourancheau wrote:
Le 21 juin 07 à 23:00, JP Vasseur a écrit :
Hi Bernard,
On Jun 19, 2007, at 4:39 PM, Bernard Tourancheau wrote:
Hello all,
A few comments, probably very naive, I did not read entirely the
archive.
Other wireless networks do not have the strong energy constraint,
memory constraint, ... that sensors have. Thus lowpan deserves a
different perspective to reflect its physical reality. Routing
will be hierarchical because of the different capabilities of
each nodes.
We may "classify them by their routing resources ?:
Type | Capability
Fonctional Device
--------------------------------------------------------------------
----------------------------
leaf nodes, | send/recv
veryRFD?
hop nodes, | send/recv/fwd+treatment?
RFD?
bridge nodes. | send/recv/fwd/multi-cast/treatment FFD?
gateway nodes| send/recv/fwd/multi-cast/treatment + "always" up
veryFFD?
We may associate L3 to only FFDs ? The L2 forwarding is not
mandatory, automatic and blind, somehow it defines a cluster,
representing the first stage of the hierarchy.
At this stage, we've been working on the requirements. As pointed
out in a previous email, it may not be a good
idea to take the superset of all the requirements of L2Ns (again
let's try to use that terminology to refer to Low Power
and Lossy Networks, which includes Sensor Networks but is not
restricted to it).
Why ?
Because they drastically differ ... thus this may lead to trying
to design a routing protocols satisfying conflicting requirements
if we want to indeed design a network for light footprint nodes.
Thus the proposed approach is to have (in addition to the
generic ID above), several applications specific requirements
documents and define the protocol as a set of loadable
components.
I know that two IDs are in the works:
(1) Home Automation
(2) Industrial application
We would probably need to have another one for healthcare.
Hi JP,
I agree with your points.
ID classes could be defined for severals needs: for weather
forecast, for aerospace, for automotive, for electrical/gaz/sewage/
water grid, for environement temperature, ...
Yes, for the time being we'll try to focus on a few ones since in
this area it is "easy"
to get the work diluted but also to end up with a such a sparse
ranges of requirements
that no single protocol could satisfy all of them. At the end, we may
very end up having
a solution of "some" of these applications, which in my opinion would
be perfectly
acceptable, considering that today there is NO IP solution for L2Ns.
Back to your point, in a second step, we may decide to classify
nodes by category although I personally prefer to use
nodes attributes to provide a better granularity, to be discussed
with the group of course. Then the routing design will
follow.
At this point, I think that it is crucial to carefully analyze the
requirements ... although I know that we are all tempted to
jump into the protocol design discussion.
Would you want to provide comments to http://www.ietf.org/internet-
drafts/draft-culler-rsn-routing-reqs-00.txt?
This is interesting and of course "the" very good start !!!. I
would add sections about broadcast and multicast that will be a
requirement for L2N, at least for weak-up, alarm, data
collection, ... all the event-based control of these devices, not
speaking about neighbor discovery, announcement, routing set-up, etc.
I am also wandering about the possibility for a device to have
several addresses or a range of addresses, for instance one for
each sensing collector.
We briefly introduced the notion of "Groupcast" in the home
automation ID. Neighbor
discovery, ... would typically be addresses by 6lowpan but the
routing protocol would
of course have to support it.
Feed-back from 6lowpan ?
As I said other related IDs will be soon follow.
About mobility or slow mobility:
Are we sure this is a requirement for our targets ? As long a
connection exist no problem, its physical strength or the
forwarding path can vary due to slow mobility, energy level or
environment movements. When some connection is lost, let call it
broken link. A new connection in another forwarding cluster needs
dhcp style renegociation.
See this is why we need application specific IDs. If it turns out
that mobility is not a strong requirements it would be good to know
it before making the assumption that it is required, although in
this particular case I think it is ;-)
Ok, my point here was that for RFDs, mobility may not have the
strong IP meaning but just "disconnected" or less connected
meanings. I am not sure RFDs should spend energy dealing with
complex mobility protocols.
Absolutely. The routing protocol would have to be flexible enough to
not activate some
of the routing function on the most constrained node.
Cheers.
JP.
Cheers,
Bernard.
Thanks.
JP.
My 2motes,
Bernard.
_______________________________________________
RSN mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/rsn
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
