The argument for route-over is pretty simple.
1. In the vast majority of wireless sensor networks in existance the
dominant communication pattern is data collection (from nodes in the
PAN to IP-based computers external to the PAN) and control actions
(from controllers external to the PAN to devices within the PAN).
There are cases where data collection point and/or the controller is a
gateway device on the PAN, but this physical collocation is rather
artificial. If is far more typical that where a gateway is deployed
it is used to bridge communication to other networks.
This is true not only for wireless instrumentation, but wired
instrumentation as well. See for example
BACNET: http://www.bacnet.org/Tutorial/HMN-Overview/sld028.htm and
http://www.bacnet.org/Tutorial/HMN-Overview/sld029.htm
and
HART:
http://www.hartcomm2.org/hart_protocol/tech_info/eval_networks/compnet.html
and Wireless HART
http://www.hartcomm2.org/hart_protocol/wireless_hart/architecture.html
Routing onto or off the PAN utilizes a routable IP address for the
device within the PAN. It is important for this address to be
compressible, just as when both endpoints are within the PAN. No
matter how effective is the L2 mesh routing within the PAN, you still
need to deal with IP routing off the PAN. This is, of course, the
purpose of IP routing. Whatever mesh-under is done, there will also
be route-over. The mesh-under path is, at least, one of the
route-over hops. Possibly more of the IP hops may occur over 802.15.4
links.
2. It is very common that devices route between distinct networks that
use the same media, ie. distinct Ethernet subnets or distinct WiFi
subnets. This will happen in 802.15.4 networks where the networks use
the same physical link, but different PAN_IDs, different channels (or
different sets of channels or different channel schedules), different
MAC layers, etc. Even different meshing protocols. They will be
stiched together by IP routing.
3. The Mesh-under protocol is currently undefined. 6lowpan is
sufficient to describe single hop communication. It also identifies
the endpoints (original and final) of multihop mesh-routed
communication, but it does not define how the intervening hops are
determined or what information is exchanged to establish
routes. Clearly it anticipates that such L2 protocols will be
developed and standardized. However, if a single 802.15.4 hop is
performed per IP hop, any L3 routing algorithm can be used to set up
the routing tables and forwarding occurs according to the routing
tables. (Worst come to worst, you can hammer the tables in place by
external means.) If mesh routing does become defined, IP routing can
be applied per L2 mesh path. Thus, IP routing applies whether or not
mesh routing is defined. All of the IP visibility and management
tools apply to the IP hops. None of them apply to the mesh hops
within an IP hop.
4. Many IP routing protocols are defined and a diversity of protocols
has become the norm. One of the key elements of IP is that it
separates routing from forwarding. We tolerate the use of different
routing protocols in different settings. These protocols set up the
tables and forwarding works across them. We have had multiple
competing routing protocols apply to the same setting (e.g., RIP vs
OSPF in the campus area) and their relative strengths have become
clear over time.
This has not been the case with link-level "meshing"; so far it has
been approached as a winner-take-all and unfortunately this means that
everybody must agree on the protocol before they have much experience
with the use of the protocol. For example, in Zigbee we have seen
that after several years of development, but no broad usage, Zigbee
1.0 is obsoleted in favor of Zigbee 2006, which is incompatible and
also incompatible with Zigbee 2007, which is not yet fully defined.
We have seen numerous proprietary protocols, proprietary extensions to
standard protocols, and open research protocols for meshing that are
all incompatible. In some cases they optimize for different aspects,
in some cases they integrate aspects of all layers of the stack. In
any case, they don't play well together. So, one of the key virtues of
route-over is that we have an established framework and long history
of stiching together a variety of routing protocols to establish the
tables such that forwarding works across them and where we can gain
experience over time. Call it "rough consensus and running code".
One might argue these aspects are sociological, rather than technical.
Well, the separation of topology formation, path selection, and route
table maintainance from forwarding is awfully important. So are the
vast set of tools to gain visibility into IP routing. At the very
least, source routing, exploration, etc. will need to be developed for
the PAN for mesh-under to mature. It is an interesting question
whether you need to be within the PAN to utilize the equivalent of
traceroute.
5. History suggests that once IP routing is available for a particular
kind of link, sub-IP routing tends to dissappear. Remember x.25 and
frame relay. Of course, we do some form of "mesh" routing in switched
ethernets and mesh wifi, but generally it is transparent. The link
looks like the unswitched counterpart.
So I think it is very clear that IP routing will occur over IEEE
802.15.4 links. It is already there. For every single hop 15.4
network it is done. For deeper networks, there are many ways to set
up the tables.
So route-over is a fact. The question should be "Do you need
mesh-under in addition to route-over?" Why?
______________________________________________________________
From: JP Vasseur [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 17, 2007 4:28 PM
To: Dominik Kaspar
Cc: 6lowpan; [EMAIL PROTECTED]
Subject: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02
Dear Coauthors,
Few Comments on draft-dokaspar-6lowpan-routreq-02.
First of all, I think that we will need to have that debate on
whether we indeed need both a "Mesh-under" and a "Route over"
solutions. If the answer turns out to be "yes, we need both" I
would volunteer to write the ID capturing the pros and
cons ...
In the meantime, here are a few comments:
1) I would suggest to use a consistent terminology for the
"Mesh-under" routing. Not trying to quibble on the terminology
here but this is quite important to avoid confusion with the
RSN initiative. "Lowpan mesh routing" looks more like Route
over.
2) Section 2
These fundamental features of LoWPANs can affect the design of
routing solutions, so that existing routing specifications
should be
simplified and modified to the smallest extent possible, in
order to
fit the low-power requirements of LoWPANs.
We had that discussion before ... Yes, if one can find an
existing protocol that meets
the requirement and that can be adapted, then great. But
whether any of the current
protocols can be adapted to meet these requirements is not a
given.
3) Section 2
In order to find energy-optimal routing paths, LoWPAN mesh
routing
protocols should minimize power consumption by utilizing a
combination of the link quality indication (LQI) provided by
the MAC
layer and other measures, such as hop count. Route repair and
route
error messages should be avoided for minimizing the overall
number of
control messages and the required energy for sending them.
Two comments:
* This is a difference with Route-over where we will define IP
metric to reflect
the link characteristics to be used by the routing engine but
we do want to
remain layer 2 agnostic, thus the need for a minimal
abstraction layer.
* Should we avoid "Route Repair" ? mmm ... I'm not so sure
since there are
applications that require fast rerouting to forward sensitive
data. A cheap
alternative is to compute disjoint paths but this comes at the
path quality
cost.
3) Section 3
Transparent IP routing between LoWPAN domains and higher layer
networks must be provided bidirectionally. A LoWPAN mesh
routing
protocol must allow for gateways to forward packets out of the
local
domain and it must be possible to query a LoWPAN device from
outside
of the local domain. Strategies must be considered to avoid
battery
depletion of nodes by too many queries from higher level
networks.
End-to-end communication is not a design goal of LoWPAN.
This is one on my main motivations of a Route-over strategy.
4) Section 3.2
Because network layer routing imposes too much overhead for
LoWPANs
JP> Which Routing protocol ?
and link layer techniques are out of scope of IETF, LoWPAN
mesh
routing should be performed within the adaptation layer
defined in
[3]. Both addressing modes provided by the IEEE 802.15.4
standard,
16-bit short addresses and 64-bit extended addresses, must be
considered by LoWPAN mesh routing protocols. It is also
assumed that
nodes participating in LoWPAN mesh routing are assigned only a
single
address/identifier and do not support multiple interfaces.
Just a note here to mention that L2Ns will more than likely
support multiple
interfaces thanks to multiple non overlapping frequencies.
Thanks.
JP.
_______________________________________________
RSN mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/rsn
