FYI - Feel free to register to RSN and provide feed-back if of interest.
Thanks.
JP.
Begin forwarded message:
From: JP Vasseur <[EMAIL PROTECTED]>
Date: May 23, 2007 4:33:31 AM GMT+02:00
To: [EMAIL PROTECTED]
Cc: David Culler <[EMAIL PROTECTED]>
Subject: Next step for RSN ?
Dear List members,
Looking at the number of people who registered to this list, there
seems to be a strong interest in designing a Routing solution for
Sensor Networks. David and I had during the last few months a
number of off-line discussions with positive feed-back and support,
it is now a good time to use the Mailing List to gauge whether
there is a consensus on whether to work on this topic.
David provided an excellent problem statement below. I'd like to
add a few comments and get feed-back from the ML members on whether
we collectively want to work on this item.
With no doubt, we'll see many other radio networks emerging soon
and sensor networks will soon be made links using various layer1/2
protocols defined by other SDOs: 802.15.4, Wifi, WiMax but also non
wireless links. Such networks will also comprise sensor nodes with
a wide range of capabilities, which makes the routing fairly unique
in term of requirement. Thus the proposal is to design a IP routing
solution specifically for sensor networks, that would of course be
independent to the L1/L2 protocol in use (it may be desirable to
take into account link layer attributes when calculating a route
but the routing process would not be tied up with the link layer).
It looks fairly obvious that a network made of N "mesh-under"
routing protocols is very unlikely to satisfy an end to end path
constraint and would be fairly complex to manage and tune. We all
remember the issue of IP routing over ATM PVCs routed by PNNI.
Think of this with N "Mesh-under" routing protocols. That said,
this is not to say that we exclude the use of "mesh-under"
solutions, but we propose to define a IP-based routing protocol.
What would be a charter proposal ?
First we would need to spend a good amount of time on the routing
requirements. David and I posted a first revision of a generic
requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next
revision will soon be posted accounting for the comments received
so far. I would propose to continue to list the generic
requirements in this draft and have other application-specific
routing requirements drafts discussed in other IDs: for home
networking, industrial applications, ... Such approach has been
successfully adopted in other WGs.
The second step would consist of making a survey on the existing
routing protocols and see whether (1) they could be used as such
(2) they should be adapted (for instance, see whether AODV or OLR
or RIP could be made energy efficient, could support some form of
constrained based routing, ...) or (3) we should design a new
generic new protocol.
Note that we may not be able to satisfy all the requirements, and
this might be perfectly acceptable and should be documented.
Indeed, we all know that Sensor Networks may significantly differ
in term of degree of mobility, link layer reliability/bandwidth,
node constraints, ... A very good outcome of this work might be
that the newly defined/adapted protocol could satisfy the
requirement IDs A, B, D and E but not C.
So please use this list to provide feed-back on whether you would
support such initiative and if so your contribution is more than
welcome. Note that several people already mentioned some interest
and we do expect to see new IDs posted before Chicago.
JP and David.
Begin forwarded message:
From: "dculler" <[EMAIL PROTECTED]>
Date: May 23, 2007 1:24:58 AM GMT+02:00
To: <[EMAIL PROTECTED]>
Subject: [RSN] Interest in the Interplay of "routing" and "meshing"
Reply-To: [EMAIL PROTECTED]
Several of the comments on this list have touched on the issue of
different kinds of "multihop routing" in the context of sensor
networks. Is there interest in working on how these forms of
routing tie together?
To make the question more grounded: Low power radios have
relatively short range. IEEE 802.15.4 radios are typically 1 mW
transmit power, vs 100 mW for 802.11, and have typical ranges in
10s to 100 m. Generally speaking, the power required to
communicate a given distance by radio grows polynomially with
distance. In typical settings it grows like the cube, but it can
be much worse near the ground or somewhat better with directional
antennas. The cost to communicate hop-by-hop grows only linearly,
and it offers the potential to route around obstacles and enhance
reliability through "receiver diversity".
The question is at what layer(s) in the stack this routing occurs
and how it relates to IP routing more generally. Most multihop
protocols in the sensor network research community are effectively
at layer2 - they form a single "patch" of homogeneous media.
Logically, they are a subnet, although few of the protocols
address what happens beyond the "patch" of sensor nodes, other
than that some of the nodes are "gateways". Current industry
standards, such as Zigbee, Zwave, and wirelessHART, are also a
"multihop link", leaving open the question of how nodes within the
sensor patch communicate with nodes outside.
6LoWPAN provides a compressed header format for "mesh routing",
meaning multihop forwarding of packets within the 802.15.4 link.
Such a link is assumed to be formed by a contiguously connected
set of 802.15.4 nodes. The presence of such "mesh routing"
capabilities does not eliminate the need for layer 3 routing. If
a 15.4 node communicates with a remote node, say an 802.11 node,
how is routing and forwarding carried out? If two "LoWPAN
subnets" [sic] happen to be connected by 15.4 nodes, how does 15.4-
to-15.4 routing occur? The 6LoWPAN header format is, of course, a
general solution for carrying IP over 802.15.4, so it is able to
express these other forms of routing, as well. In the extreme
case, each individual node is an IP link and all routing is done
at the IP layer. On the other hand, patches of nodes may want to
function as a logical subnet, even if the wireless multihop
routing is done at the IP layer. At this point, the concerns
overlap with those addressed in autoconf (cf., draft-ietf-autoconf-
manetarch-01).
There is substantial commonality of concerns at the different
layers of multihop routing, but also differences. It is also
important to separate the process of forming a routing topology
from the process of forwarding packets. Both of which are
distinct (but not entirely independent of) how power management
(turning on/off the radios) is performed.
_______________________________________________
RSN mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/rsn
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
