Adding a few comments ...
On Jul 18, 2007, at 9:53 AM, dculler wrote:
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.
In which case, multi-hop routing where hops are interconnected by PAN
where mesh-under routing take place
lead to Inconsistent Routing. It is then very difficult to optimize
the path with regards to a specific metric since there
is no to way to have a consistent end to end view.
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?
Indeed, since we do need RL2N why would we need mesh-under (sorry I
keep repeating myself here). I would
argue that having both would even be an issue, as pointed out above,
not mentioning the operational complexity.
Cheers.
JP.
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.
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
