Hello Geoff,
[Geoff]: So route-over is a fact. The question should be "Do you need mesh-under in addition to route-over?" Why?
This is indeed an interesting question. Here are some of my thoughts on the argument for "mesh-under" routing: 1.) The ability to fully exploit 6lowpan's adaptation layer (header compression for energy saving): Link-level meshing has so far been approached as a winner-take-all, but the dispatch value in 6lowpan's format allows for coexistence of different mesh-under algorithms. Therefore, depending of the type of sensor network, a differently optimized routing protocol could be used, be it a reactive, proactive, data-aware, or a geographical one. 2.) To make use of link-layer feedback for route optimization: The main characteristics of low-power networks is their battery-operation and that the nodes "die" after battery depletion. It is therefore the main goal and number one priority to reduce energy consumption in any way possible, and bringing the routing "under" the IP-layer is one method of doing so. Examples include the possible avoidance of DAD and simplified neighbor discovery using addresses that are directly derived from globally unique MAC addresses. 3.) End-to-end communication is not expected for sensor networks: Sensor networks are "edge networks" and should not be used as transit networks and routing onto or off the PAN needs to consider energy consumption. Packets should not be "blindly" routed in and out of a PAN. Basically, in many sensor application scenarios there shouldn't be anything going "directly into the PAN". Therefore, end-to-end communication clearly is not a 'high priority' design principle for sensor network nodes. Packets that travel "to the PAN" are most likely queries of some sort. A gateway/collection point/controller is a very efficient way to handle such queries and to reply with cached data, instead of burdening the entire PAN with routing overhead on each single (maybe redundant) query. Therefore, mesh-under routing can be applied in the most efficient way to periodically report new sensor data to the gateway. Such a gateway is not an artificial, but a very realistic architectural element for efficient sensor network functionality. 4.) Continuing the 6lowpan work: The 6lowpan WG has decided to specialize and build on top of IEEE 802.15.4 networks. It is therefore straightforward to utilize this existing framework for building an energy-optimized "mesh-under" routing solution that exploits link-layer feedback. Best regards, Dominik On 7/18/07, dculler <[EMAIL PROTECTED]> 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. 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.
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
