Internet Engineering Task Force J. Hui Internet-Draft Cisco Systems, Inc. Intended status: Informational J. Vasseur Expires: September 29, 2011 Cisco Systems, Inc March 28, 2011 Routing Architecture in Low-Power and Lossy Networks (LLNs) draft-routing-architecture-iot-00 Abstract The IETF ROLL Working Group has specified a routing protocol designed for the Low power and Lossy Networks (LLN) also referred to as IP smart objects networks or the "Internet of things". Still, the debate of where routing functions should occur within the network stack tend to get revived on a regular basis. A mesh-under approach places routing functions in the link layer to emulate a single broadcast domain where all devices appear as immediate neighbors to the network layer. In contrast, a route-over approach places all routing functions at the network layer, following the IP architecture. For LLNs, a mesh-under approach may seem simple and attractive because it seeks to hide characteristics of multi-hop communication through the LLN from the network layer. However, resource constraints and dynamic link characteristics limit to what extent link-layer routing can hide those characteristics. This document presents architectural issues of using a mesh-under approach in LLNs and how a route-over approach does not suffer from these issues. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 29, 2011. Hui & Vasseur Expires September 29, 2011 [Page 1] Internet-Draft Routing Architecture in LLNs March 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Ethernet Abstraction . . . . . . . . . . . . . . . . . . . 4 3. The Mesh-Under Fantasy . . . . . . . . . . . . . . . . . . . . 5 4. Multi-Layer Routing Issues . . . . . . . . . . . . . . . . . . 6 4.1. Multi-Layer Path Computation . . . . . . . . . . . . . . . 7 4.2. Multi-Layer Recovery . . . . . . . . . . . . . . . . . . . 7 4.3. Incompatible Features . . . . . . . . . . . . . . . . . . 8 4.4. Implementation Overhead . . . . . . . . . . . . . . . . . 8 4.5. Management Overhead . . . . . . . . . . . . . . . . . . . 8 5. Additional Mesh-Under Issues . . . . . . . . . . . . . . . . . 8 5.1. Insufficient Address Scoping . . . . . . . . . . . . . . . 9 5.2. Nondeterministic Link Characteristics . . . . . . . . . . 10 5.3. Lack of Visibility into Link Topology . . . . . . . . . . 10 6. Routing Only at the IP Layer . . . . . . . . . . . . . . . . . 11 7. Route-Over and Link-Layer Forwarding . . . . . . . . . . . . . 12 8. Lessons from the Past . . . . . . . . . . . . . . . . . . . . 12 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. Informative References . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Hui & Vasseur Expires September 29, 2011 [Page 2] Internet-Draft Routing Architecture in LLNs March 2011 1. Introduction A decade ago, both academia and industry viewed the use of Internet Protocol (IP) as ill-suited for use in Low-Power and Lossy Networks (LLNs). Unlike traditional IP networks, LLNs must operate under severe resource constraints (e.g. limited memory, computation, and communication) and handle the lossy and dynamic nature of low-power link technologies (e.g. IEEE 802.15.4). For this reason, the LLN community felt it was necessary to free themselves of the IP architecture and revisit assumptions and develop new networking solutions. Since those beginnings, the LLN field has matured substantially. A variety of protocols have been invented and evaluated. Significant networks have been deployed for a variety of real-world applications. But because much of those efforts were designed outside of the IP architecture, connecting those LLNs back to an existing IP-based infrastructure (both private IP networks and the public Internet) involved the use of application gateways that translate between the IP and non-IP worlds. Unfortunately, such gateways are known to be difficult to design, deploy, and maintain - mapping between protocols often required significant functional and semantic translation (e.g. routing, quality of service, and security); state management made the gateway a single point of failure; and upgrades to application protocols required careful synchronization between the gateway and end devices. In effect, gateways limit the innovation and growth that the IP architecture was designed to foster. To address these concerns, the IETF began to focus work on the use of IP in LLNs by forming the IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) working group to standardize the use of IPv6 in IEEE 802.15.4 networks. The IETF then formed the Routing over Low Power and Lossy Links (ROLL) to specify the Routing Protocol for LLNs (RPL) [I-D.ietf-roll-rpl]), an IP-layer routing protocol designed specifically for LLNs. The IETF also formed the Constrained RESTful Environments working group to specify the Constrained Application Protocol (CoAP) [I-D.ietf-core-coap], an application protocols in LLNs. All of these IETF working groups focused their efforts exclusively on IPv6, rather than IPv4, in anticipation of the IPv4 address space depletion and to take advantage of new features in IPv6, such as autoconfiguration. A number of standards organizations have placed significant effort into standardizing networking protocols for LLNs, including ZigBee/IP, Wavenis, and IEEE. All of these efforts began outside of the IP architecture when IP was viewed as ill-suited for use in LLNs. However, most of these organizations, including ZigBee/IP, Wavenis, and IEEE P1901.2, are now focusing their efforts to standardize IP- Hui & Vasseur Expires September 29, 2011 [Page 3] Internet-Draft Routing Architecture in LLNs March 2011 based architectures for LLNs. Today, it is safe to say that IPv6 has won the battle over non-IP- based protocols in LLNs. However, from time to time, the debate on the role that routing plays within an LLN gets revived. In one view, LLNs should implement link-specific networking protocols and add IP as a minimal shim below the application layer. This so-called mesh- under approach performs routing below the IP layer and, in effect, all devices appear as immediate neighbors to the network layer. In another view, LLNs should place all routing functions at the IP layer and none in the link layer, following the IP architecture. This so- called route-over approach equates each physical hop as a single IP hop. RPL supports the route-over approach because it is an IPv6 network layer routing protocol designed for LLNs. The purpose of this document is to preset the architectural issues that arise with a mesh-under approach. These issues have caused leading standards organizations to specify a route-over approach, including the IETF, ZigBee, and Wavenis. In fact, no industry standard today places routing functions at the link layer. 2. The Ethernet Abstraction Originally based on a single shared media, Ethernet provides a simple communication abstraction. In particular, Ethernet provides the following properties: o Single broadcast domain: All devices appear directly attached to the same broadcast medium and the IP layer can transmit a datagram to any number of devices attached to the same link. More formally, all communication is transitive within a single broadcast domain (if A can send to B and B can send to C, then A can send to C). o Deterministic link characteristics: any differences in link characteristics (e.g. communication latency, throughput, and loss rates) between different node pairs attached to the same link are insignificant. From a routing perspective, the link cost rarely varies. o High reliability: the link delivers messages to their intended destination with relatively high reliability. A link that provides these Ethernet properties is attractive because it simplifies the IP layer. At the network layer, any device can send IP datagrams to any number of devices attached to the same link simply by indicating the unicast or multicast address of the Hui & Vasseur Expires September 29, 2011 [Page 4] Internet-Draft Routing Architecture in LLNs March 2011 destination(s). The network layer never needs to perform routing functions when sending IP datagrams to other devices attached to the same link. The network layer also does not need to consider differences in link characteristics. The most common WiFi deployments are infrastructure-based, where WiFi access points provide network connectivity for WiFi clients. Due to the limited range of wireless communication and security policies, WiFi clients are often restricted to communicating only with an access point. However, WiFi maintains the Ethernet abstraction by implementing link-layer routing functions on the access point. Even in enterprise deployments that involve multiple access points connected by an Ethernet backbone, the entire WiFi network appears as a single broadcast domain. The ubiquity of the Ethernet abstraction has led critical IP-layer protocols, such as IPv6 Neighbor Discovery (ND) [RFC4861], to assume it. For example, ND uses Duplicate Address Detection (DAD) to verify the uniqueness of an address, it sends a single multicast query to all devices in the network. When ND checks that a device is reachable, it assumes that error rates are low and round-trip communication latency is deterministic. Furthermore, when ND performs default router selection, it does not take into account the link cost of reaching the default router and assumes that link characteristics are uniform. 3. The Mesh-Under Fantasy The mesh-under approach places mesh routing functions in the link layer in attempt to support the Ethernet abstraction. Some argue that mesh-under provides the following advantages: o Maintain existing non-IP networking solutions: a huge amount of time, money, and effort has been invested in existing solutions that do not adhere to the IP architecture. As a result, one possible way to quickly obtain an IP-based solution is to simply transport IP datagrams over an existing non-IP networking solution for LLNs. o Hide LLN complexities within the link layer: compared to more traditional link technologies, LLNs can exhibit complex topologies over a large physical extent combined with the lossy and dynamic nature of LLN link technologies. Successfully hiding such complexities within the link layer allows the IP layer to ignore them. Hui & Vasseur Expires September 29, 2011 [Page 5] Internet-Draft Routing Architecture in LLNs March 2011 o Routing outside the IP architecture: by operating at the link layer, the routing protocol does not need to conform to the IP architecture. As we will see later in this document, these properties of a mesh- under solution actually cause more technical challenges and risks than they solve, in addition to weakening the overall layered architecture of IP. Even so, initial efforts to bring IP to LLNs focused on mesh-under solutions. In 2007, the IETF 6LoWPAN working group set the foundation for a mesh-under solution by publishing RFC 4944 that specifies the encoding IPv6 datagrams in IEEE 802.15.4 frames [RFC4944]. The focus on mesh-under led to the following mechanisms in RFC 4944: o Mesh Addressing Header: this header allows a packet to identify the end-points of a path using IEEE 802.15.4 addresses and enables link-layer routing and forwarding mechanisms to deliver IPv6 datagrams over multiple radio hops. o Broadcast Header: to support IPv6 multicast, the broadcast header carries a sequence number to support a simple PAN-wide flooding mechanism to emulate a single broadcast domain. o Link-Local Address Compression: the IPv6 header compression mechanism is only capable of reducing the size of link-local IPv6 addresses, making the assumption that devices will communicate primarily with link-local addresses. At the same time, much of the forward looking efforts within the 6LoWPAN working group focused on filling out a mesh-under approach. Proposals for link- layer routing [I-D.daniel-6lowpan-load-adhoc-routing], IPv6 ND optimizations [I-D.chakrabarti-6lowpan-ipv6-nd], and network bootstrap [I-D.daniel-6lowpan-commissioning] protocols all assumed a mesh-under approach. Initial efforts outside the IETF also focused on mesh-under solutions. However, in light of the architectural issues with mesh- under presented in this document, most of those efforts have now adopted a route-over approach using RPL, the standardized IPv6 routing protocol for LLNs by the IETF ROLL Working Group. 4. Multi-Layer Routing Issues Much of the IP architecture's success is due to its layered approach, allowing each layer to evolve independently and build networks that are composed of a variety of different link technologies. Although IEEE 802.15.4 was recently seen as the link technology for LLNs, other link technologies are beginning to proliferate (e.g. Low Power Hui & Vasseur Expires September 29, 2011 [Page 6] Internet-Draft Routing Architecture in LLNs March 2011 WiFi, Wavenis, and Power Line Communication). Each link technology targets different deployment environments, but also brings their own sets of communication characteristics. The most effective deployments combine multiple link technologies into a single IP network. Of course, this is a primary reason for the shift in consensus towards utilizing IP in LLNs. To interconnect multiple networks made of a variety of link layers (including LLNs), an IP routing protocol is needed. As a result, a mesh-under approach would require routing functions operating at both the link and network layers. While the IP-layer routing protocol computes end-to-end paths, the link-layer routing protocol computes paths within a link network. As a result, the IP layer sees each other device in the same link network as neighbors and has limited, if any, visibility into the path computation to reach those devices. In this section, we discuss additional architectural issues that arise with multi-layer routing. 4.1. Multi-Layer Path Computation A mesh-under approach makes it challenging for an IP routing protocol to compute an effective end-to-end path. Strict adherence to the layered architecture would imply that the link-layer routing protocol does not have visibility in the cost of paths that extend beyond the link network. Similarly, the IP-layer routing protocol does not have visibility into the path costs within a link network because all paths through the link network appear as direct IP neighbors. One approach is for the link and IP routing protocols to share dynamic path cost information through cross-layer APIs. However, for the two protocols to make effective use of the information, they must implement the same objective functions, metrics, and constraints when optimizing routes. It is not sufficient for them to optimize paths with similar goals, such as minimum latency or transmission cost. Even time-constant differences in low-pass filters used to compute metrics could cause inefficient operation and end-to-end path convergence issues due to unintended interactions with multi-layer recovery. 4.2. Multi-Layer Recovery In the presence of physical connectivity changes due to link or node failures, it is challenging to coordinate recovery operations across routing protocols operating at different layers. Complex interactions can occur when the different routing protocols independently notice and react to a link failure simultaneously. The link-layer may detect a link failure and perform recovery operations Hui & Vasseur Expires September 29, 2011 [Page 7] Internet-Draft Routing Architecture in LLNs March 2011 to repair the path to a destination. However, if the path is not restored quickly enough, the IP routing protocol may determine that a failure has occurred and it should begin searching for a new route. A commonly proposed solution is to use a bottom-up timer-based approach, where the higher layer must delay its rerouting operations for some time T. However, choosing an appropriate value of T can be non-trivial, as it effectively sets an upper bound on the link- layer's convergence time and a lower bound on the overall system's convergence time. In other words, a value too large will increase the system's convergence time, and a value too small may lead to concurrent rerouting operations. 4.3. Incompatible Features Significant issues arise when the link- and IP-layer routing protocols implement different functionalities. In such cases, they must drop to the least common denominator. For example, if the link layer routing protocol does not implement Multi-Topology Routing or constraint-based routing, the IP routing protocol will not be able to utilize similar functions effectively. Differences in the selection of metrics, their computation, or their usage can make it difficult to effectively optimize a path end-to-end. As mentioned before, such differences can also exacerbate issues with multi-layer recovery. 4.4. Implementation Overhead The complex interactions of multi-layer path computation and recovery and feature incompatibilities lead to complex implementations that require significant computing and memory resources (e.g. IP over ATM or DWDM). In contrast, LLNs must operate with strict resource constraints (e.g. limited memory, computation, and communication). Furthermore, due to their embedded nature, LLNs must operate unattended for many years. 4.5. Management Overhead Dealing with multiple routing protocols is operationally challenging. Network administrators must be educated and prepared to configure, operate, and debug different link-layer routing protocols for each link technology in addition to the IP-layer routing protocol that binds all the link technologies together. 5. Additional Mesh-Under Issues There is a common mindset within the LLN community that a given LLN will operate as a stub network and utilize only a single link Hui & Vasseur Expires September 29, 2011 [Page 8] Internet-Draft Routing Architecture in LLNs March 2011 technology. This is understandable, especially considering that many existing LLN networking standards began outside of the IP architecture and were not designed to inter-network with other LLNs or traditional networks. Although there is momentum in adopting a route-over approach, some believe that the simplest path towards incorporating an IP-based architecture is with a mesh-under approach that transports IP datagrams over an existing mesh networking technology. However, even with this simplistic view of LLNs, a number of architectural issues arise. 5.1. Insufficient Address Scoping The IPv6 addressing architecture supports the notion of address scopes. Each IPv6 address encodes a scope that defines the topological span within which the address is a unique identifier for a set of interfaces. Unicast addresses have either link-local or global scope. The former uniquely identifies interfaces attached to the same link and the latter uniquely identifies interfaces anywhere on the Internet. In either case, the smallest address scope that can identify interfaces attached to the same link is link-local. This is understandable since the IP layer assumes that any device attached to the same link is an immediate neighbor. Because all devices in the same network appear attached to the same link with a mesh-under approach, a link-local IP address is effectively limited to an identifier for any arbitrary device or set of devices in the network. A mesh-under approach expands link-local scope to include the entire LLN. In contrast, a route-over approach limits link-local scope to those devices reachable by the physical layer. As a result, the link-layer in a mesh-under approach must be prepared to discover routes to arbitrary devices in the network when receiving any datagram from the IP layer. In other words, all IP datagrams that the IP layer sends to the link layer may trigger non- trivial routing mechanisms at the link layer. The problem with mesh-under is that IP-based protocols have no mechanism to pass any additional topological knowledge they may have about the destination. The best they can do is say whether or not the destination(s) are restricted to devices in the network. In LLN applications, there are a number of practical scenarios where the application has better knowledge on the location of the device. Furthermore, LLN applications tend to take advantage of their spatial correlation and are more likely to communicate with devices in close physical proximity. IP-based protocols typically use link-local multicast communication to discover devices attached to the same link. IPv6 Neighbor Discovery uses multicast for discovering devices attached to the same Hui & Vasseur Expires September 29, 2011 [Page 9] Internet-Draft Routing Architecture in LLNs March 2011 link. But because the link spans the entire LLN with mesh-under, the link layer must be prepared to deliver a single multicast message to all devices in the network. Whether multicast is implemented at the link layer using simple flooding or more sophisticated multicast trees, delivering a message to many devices in a network is a costly operation. 5.2. Nondeterministic Link Characteristics IP-based protocols often assume that link characteristics are deterministic when communicating with any device attached to the same link. However, using link-layer routing techniques to maintain deterministic link characteristics with a mesh-under routing approach is nearly impossible. Communication latency, throughput, and reliability can vary greatly between different devices depending on their location in the network and variations in traffic load or link qualities. Limited throughput, channel capacity, and memory make communication properties highly sensitive to the network topology and variations in network conditions. At first glance, it may seem simple enough to provide hints to the IP layer on current communication properties to another device in the network. The challenge comes in managing the interactions between link and IP layer protocols. The responsibility of a link-layer routing protocol is to discover and maintain paths for destinations within the network. Changes in physical connectivity may trigger the link-layer routing protocol to repair the route. If the link layer is unable to repair the route quickly enough, the IP layer may prematurely determine that a destination is unreachable. This can reduce the reliability of IPv6 ND Neighbor Unreachability Detection or Address Resolution. A more significant interaction arises in deployments that involve multiple default routers. IPv6 ND is also responsible for dynamically selecting a default route. Using Neighbor Unreachability Detection, IPv6 ND can detect reachability issues and change its default route if necessary. If the link layer is unable to repair a route to the default router in time, IPv6 ND may prematurely determine the router is unreachable and select a different default router. However, doing so will cause the link layer to configure routes to the new default router, causing additional control traffic and wasting any effort in repairing the route to the old default router, a typical multi-layer routing architecture challenge. 5.3. Lack of Visibility into Link Topology Due to the resource constraints of LLNs, there has been significant work in the use of overlays to support in-network processing within Hui & Vasseur Expires September 29, 2011 [Page 10] Internet-Draft Routing Architecture in LLNs March 2011 LLNs. Overlays are often proposed to reduce communication latency, channel utilization, and energy consumption. An inherent requirement for building an effective overlay in LLNs is that devices must be able to discover and utilize the link connectivity to maximize the benefits of using such mechanisms. A mesh-under routing approach makes it impossible to support effective overlays using IP-based protocols. In performing data aggregation, for example, devices must be able to process message payloads as they forward them along to their destination. But by routing and forwarding datagrams at the link layer, forwarding devices never pass IP datagrams up to the IP layer. While it may be possible to form an IP datagram destined for the next aggregation point at each hop, it is not possible to do so in a way that mirrors the physical topology. 6. Routing Only at the IP Layer A route-over approach places routing functions only at the IP-layer, following the IP architecture. In doing so, a route-over approach fully exposes the link connectivity to the IP layer. Device's IP neighbors are those devices within physical transmission range of its transceiver. As a result, the LLN is composed of multiple overlapping broadcast domains (one per device) and communication is non-transitive within the LLN. If an IP datagram must traverse one or more devices to reach a destination, then routing occurs at the IP layer. With the route-over approach, all routing functions are implemented by a single routing protocol at the IP layer (e.g. RPL for LLN), even when the LLN is composed of multiple different link technologies. As a result, the route-over approach does not suffer from issues of multi-layer path computation and recovery, incompatible functionality, and increased implementation and management costs associated with supporting multiple layers of independent routing protocols. Futhermore, route-over does not suffer from architectural issues due to insufficient address scope, nondeterministic link statistics, and lack of visibility into physical topology. IPv6-based application protocols can use link-local addresses to limit the scope of addressable devices to immediate neighbors or the IPv6 Hop Limit field to control the topological extent of a message. Furthermore, with the ability to discover the physical link topology, IP-based applications can implement in-network processing. Finally, because the IP link is constrained to those devices within physical range, any differences in link characteristics are independent of network Hui & Vasseur Expires September 29, 2011 [Page 11] Internet-Draft Routing Architecture in LLNs March 2011 diameter or a link-layer routing protocol. For many of the reasons mentioned above, focus shifted towards supporting a route-over approach. Recently, the 6LoWPAN standards were updated to support a route-over approach. In particular, IPv6 header compression for 6LoWPANs was updated to support for IPv6 extension headers, such as the Hop-by-Hop Options [I-D.ietf-6man-rpl-option] and Routing headers [I-D.ietf-6man-rpl-routing-header]. Specifications for the use of IPv6 ND in 6LoWPANs were also updated with both the route-over and mesh-under approaches in mind. To support IP routing within LLNs, the IETF Routing Over Low Power and Lossy Networks (ROLL) working group specified Routing Protocol for LLNs (RPL), an IP routing protocol designed specifically for LLNs. RPL is a distance vector routing protocol designed to meet the requirements of scale (e.g. thousands of resource-constrained devices), low-power and lossy links that provide limited throughput and have highly variable link characteristics, and limited memory and computation resources. Today, standards organizations, including ZigBee/IP and Wavenis, have adopted a route-over approach using RPL. 7. Route-Over and Link-Layer Forwarding Note that while a route-over approach places all routing functions at the IP layer, it does not require forwarding functions to occur only at the IP layer. In particular, a route-over approach allows forwarding IP datagrams at the link layer. This is done today in more traditional IP-based networks with the combination of IP-layer routing protocols (e.g. OSPF [RFC5340] or IS-IS [RFC1142] and Multi- Protocol Label Switching (MPLS) [RFC3031]. An advantage of forwarding datagrams at the link layer is that each forwarding device does not need to process IP header to forward packet. This may be especially interesting in LLNs to reduce the overhead of encoding a path when source routing. Furthermore, the use of Label Switch Paths allow networks to implement traffic engineering or VPN (Virtual Private Networks) functions. 8. Lessons from the Past Emulating a single broadcast domain was largely successful with Ethernet and WiFi due to their abundant resources and simple network topologies. There is little issue in providing subnet-wide multicast and both Ethernet and WiFi can easily and reliably deliver any subnet-wide multicast traffic generated by the network layer. Furthermore, there is little variation in link-layer communication Hui & Vasseur Expires September 29, 2011 [Page 12] Internet-Draft Routing Architecture in LLNs March 2011 properties between different pairs off nodes within the subnet. In particular, a host need not consider the link topology in selecting among multiple default routers. A host simply assumes that the link layer can provide the same level of service regardless of which default router it chooses. In other words, unlike resource- constrained LLNs, Ethernet and WiFi take advantage of their abundant resources and simple network topologies to make any differences in communication properties insignificant to IP. As a result, it was acceptable to hide those differences from the IP layer. The mesh-under approach in IP networks have not always been successful, especially with more complex link technologies. Applying a mesh-under approach to asynchronous transfer mode (ATM) using the PNNI routing protocol did not take hold because they could neither adequately hide nor give necessary visibility into the complex dynamics of connection-based communication. In particular, efforts to support a mesh-under approach in ATM turned out to be extremely complex, requiring heavy processing on the nodes with a limited success due to a lack of end-to-end path cost visibility, the co- existence of routing protocols (e.g. OSPF or IS-IS) with different objective functions and routing metrics, issues related to multi- layer recovery, not to mention the complexity to operate and manage two routing protocols. As with mesh-under in ATMs, the resource constraints and complex link dynamics typical to LLNs make it very difficult and inefficient to effectively apply a mesh-under approach. Variability in communication latency, throughput, and reliability grows significantly with the network size in both hops and diameter. Indeed, this would imply that a mesh-under approach may be successful in a LLN with a handful of devices communicating through a single LLN Border Router. However, LLNs are becoming more complex, utilizing multiple LLN Border Routers, larger network topologies in nodes and physical extent, as well as different link technologies. For this reason, adopting a route-over approach is the only viable option that does not suffer from the architectural issues presented in this document. 9. Conclusion The IP architecture has proven to be flexible and robust even while sustaining remarkable grown and innovation of the past three decades. IP's layered architecture has allowed each layer to evolve independently of other layers while still allowing cross-layer optimizations through standard APIs. The application of the IP architecture to LLNs is just another stage in the evolution of IP networks to support the "Internet of Things." Hui & Vasseur Expires September 29, 2011 [Page 13] Internet-Draft Routing Architecture in LLNs March 2011 LLNs are evolving to incorporate a number of low-power and lossy link technologies (e.g. IEEE 802.15.4, Low Power WiFi, and Power-Line Communication) in addition to more capable ones (e.g. Ethernet and WiFi) and grow in size (both density and diameter). The use of multiple link-layer technologies requires IP-layer routing to route across different link domains. Combining IP-layer routing with link- layer routing in a mesh-under approach raises very significant challenges in dealing with multi-layer path computation and recovery, inconsistent functionality, and increased implementation and management costs. Significant architectural issues exist even in cases where no IP- layer routing occurs (e.g. a stub LLN operating with a single link technology). To effectively operate in the resource constraints and lossy links of LLNs, applications and the IP-based protocols that implement them must have the ability to constrain the scope of addressing devices and how far a message may propagate. They must have visibility into link characteristics that can vary due to network density, diameter, and dynamic internal and environmental conditions. They must have the ability to distinguish immediate neighbors from other devices in the LLN. In this document, we presented a number of architectural issues that arise with a mesh-under approach and why a route-over approach does not suffer from these issues. As a result, a route-over approach provides the best path forward to an efficient and scalable Internet of Things. 10. IANA Considerations This document includes no request to IANA. 11. Security Considerations This document includes no security considerations. 12. Informative References [I-D.chakrabarti-6lowpan-ipv6-nd] Chakrabarti, S. and E. Nordmark, "LowPan Neighbor Discovery Extensions", draft-chakrabarti-6lowpan-ipv6-nd-05 (work in progress), July 2008. [I-D.daniel-6lowpan-commissioning] Hui & Vasseur Expires September 29, 2011 [Page 14] Internet-Draft Routing Architecture in LLNs March 2011 Kim, K., Lim, C., Yoo, S., Park, S., and G. Mulligan, "Commissioning in 6LoWPAN", draft-daniel-6lowpan-commissioning-02 (work in progress), July 2008. [I-D.daniel-6lowpan-load-adhoc-routing] Park, S., "6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD)", draft-daniel-6lowpan-load-adhoc-routing-03 (work in progress), June 2007. [I-D.ietf-6man-rpl-option] Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Information in Data-Plane Datagrams", draft-ietf-6man-rpl-option-02 (work in progress), February 2011. [I-D.ietf-6man-rpl-routing-header] Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with RPL", draft-ietf-6man-rpl-routing-header-02 (work in progress), March 2011. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-05 (work in progress), March 2011. [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-19 (work in progress), March 2011. [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. Hui & Vasseur Expires September 29, 2011 [Page 15] Internet-Draft Routing Architecture in LLNs March 2011 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. Authors' Addresses Jonathan Hui Cisco Systems, Inc. 170 West Tasman Drive San Jose, 95134 USA Email: jonhui@cisco.com JP Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins Issy Les Moulineaux, 92782 France Email: jpv@cisco.com Hui & Vasseur Expires September 29, 2011 [Page 16]