Networking Working Group P. Levis Internet-Draft Stanford University Intended status: Informational JP. Vasseur Expires: January 8, 2008 Cisco Systems, Inc D. Culler Arch Rock July 7, 2007 Overview of Existing Wireless Mesh Routing Protocols for Low Power and Lossy Networks draft-levis-rl2n-overview-protocols-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 8, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Networks of low power wireless devices introduce novel IP routing issues. Nodes (such as sensor, actuator or various forms of objects) are constrained in several ways: limited memory and processing power and so on. Furthermore, most of them are battery-powered thus making Levis, et al. Expires January 8, 2008 [Page 1] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 the use of energy efficient routing protocol of high importance. Wireless links can vary significantly over time, requiring protocols to make agile decisions yet minimize the energy cost of topology changes. Thus such networks also referred to as L2Ns (Low Power and Lossy networks) have very specific routing requirements that are partially addressed by existing mesh routing protocols. The aim of this document is to provide a brief survey of the strengths and weaknesses of existing protocol with respect to these issues in order to provide guidance on how their lessons can be leveraged in future protocol design. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Levis, et al. Expires January 8, 2008 [Page 2] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Link State Protocols . . . . . . . . . . . . . . . . . . . . . 6 3.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Distance Vector protocols . . . . . . . . . . . . . . . . . . 7 4.1. RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. DSDV . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Ad-hoc On Demand Vector Routing (AODV) . . . . . . . . . . 8 4.4. DYMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. DSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Routing Considerations . . . . . . . . . . . . . . . . . . . . 9 5.1. Multi-path routing . . . . . . . . . . . . . . . . . . . . 9 5.2. Resource awareness . . . . . . . . . . . . . . . . . . . . 10 5.3. Small footprint . . . . . . . . . . . . . . . . . . . . . 11 5.4. Small MTU . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Flooding Control and Density Awareness . . . . . . . . . . 12 5.6. Low power . . . . . . . . . . . . . . . . . . . . . . . . 12 5.7. Multi-topology Routing . . . . . . . . . . . . . . . . . . 12 6. Security Issues . . . . . . . . . . . . . . . . . . . . . . . 12 7. Manageability Issues . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Levis, et al. Expires January 8, 2008 [Page 3] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 1. Terminology AODV: Ad-hoc On Demand Vector Routing DSDV: Destination Sequenced Distance Vector DSR: Dynamic Source Routing DYMO: Dynamic Mobile On-Demand MANET: Mobile Ad-hoc Networks MAC: Medium Access Control MPLS: Multiprotocol Label Switching MPR: Multipoint Relays MTU: Maximum Transmission Unit L2N: Low power and Lossy Networks LSA: Link State Advertisement LSDB: Link State Database OLSR: Optimized Link State Routing RL2N: Routing in Low power and Lossy Networks TDMA: Time Division Multiple Access 2. Introduction Networks of low power wireless devices introduce novel IP routing issues. Nodes (such as sensor, actuator or various forms of objects) are constrained in several ways: limited memory and processing power and so on. Furthermore most of them are battery-powered thus making the use of energy efficient routing protocol of high importance. Wireless links can vary significantly over time, requiring protocols to make agile decisions yet minimize the energy cost of topology changes. Thus such networks also referred to as L2Ns (Low Power and Lossy networks) have very specific routing requirements that are partially addressed by existing mesh routing protocols. The aim of this document is not to provide an exhaustive tutorial on routing protocols but to provide a brief survey of the strengths and weaknesses of existing protocols with respect to these issues in Levis, et al. Expires January 8, 2008 [Page 4] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 order to provide guidance on how their lessons can be leveraged in future protocol design. Routing protocols broadly fall into two classes: link-state and distance-vector. A router running a link-state protocol first establishes adjacency with its neighbors and then floods the local topology information in the form of a Link State Advertisement packet using a reliable flooding mechanism across the network. The collection of LSAs constitutes the Link State Database (LSDB) that represents the network topology. Thus each node in the network has a complete view of the network topology. Each router then uses the LSDB to compute the routing table where each entry (reachable IP destination address) points to the next hop along the shortest path according to some metric. Link state protocols (such as OSPF and IS-IS) support the concept of area (called "level" for IS-IS) whereby all the routers in the same area share the same view (they have the same LSDB) and areas are interconnected by border routers according to specific rules that advertise IP prefix reachability between areas. A distance vector protocol exchanges routing information rather than topological information. A router running a distance vector protocol exchanges information with its "neighbors" with which it has link layer connectivity. Tunneling and similar mechanisms can virtualize link layer connectivity to allow neighbors that are multiple layer 2 hops away. Rather than a map of the network topology from which each router can calculate routes, a distance vector protocol node has information on what routes its neighbors have. Each node's set of available routes is the union of its neighbors routes plus a route to itself. In a distance vector protocol, nodes may only advertise routes which are in use, enabling on-demand discovery. In comparison to link state protocols, distance vector protocols have the advantage of only requiring neighbor routing information, but also have corresponding limitations which protocols must address, such as routing loops (count to infinity, split horizon, ...), slow convergence times to mention a few of them. Wired networks draw from both approaches. OSPF or IS-IS, for example, are link-state protocols, while RIP is a distance-vector protocol. MANETs similarly draw from both approaches. OLSR is a link-state protocol, while AODV, DSDV, and DYMO are distance vector protocols. The general consensus in the Internet community is to use link state routing protocols as IGPs for a number of reasons: in many cases having a complete network topology view is required to adequately compute the shortest path according to some metrics. For some Levis, et al. Expires January 8, 2008 [Page 5] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 applications such as MPLS Traffic Engineering it is even required to have the knowledge of the Traffic Engineering Database for constraint based routing. XXX draft-ietf-manet-packetbb-04.txt draft-ietf-manet-nhdp-02.txt Furthermore link state protocols are usually superior in terms of convergence speed (ability to find an alternate path in case of network element failure), they are easier to debug and troubleshoot and so on and require less bandwidth than distance vector protocols. In contrast, distance vector protocols are simpler, require less computation, and have smaller storage requirements. Most of these tradeoffs are similar in wireless networks, with one exception. Because wireless links can suffer from significant temporal variation, link state protocols can have higher traffic loads as topology changes must propagate globally, while in a distance vector protocol a node can make local routing decisions with no effect on the global routing topology. One major protocol, DSR, does not easily fit into one of these two classes. Although it is a distance vector protocol, DSR has several properties that make it differ from most other protocols in this class. We discuss these differences in Section 4.5. A brief summary of several well established routing protocols is providing before considering the protocol characteristics in terms of the RL2N requirements. 3. Link State Protocols 3.1. OSPF OSPF (specified in [RFC2328] for IPv4 and in [RFC2740] for IPv6) is a link state protocol designed for routing within an Internet Autonomous System (AS). OSPF provides the ability to divide a network into areas, which can establish a routing hierarchy. The topology within an area is hidden from other areas and IP prefix reachability across areas (inter-area routing) is provided using summary LSA. The hierarchy implies that there is a top-level routing area (the backbone area) which connects other areas. Routing adjacencies with neighbors are maintained by sending OSPF hello messages. OSPF calculates the shortest path to a node using link metrics (that may reflect the link bandwidth, propagation delay, ...). OSPF Traffic Engineering (OSPF-TE) (see [RFC3630]) extends OSPF to include information on reservable, unreserved, and available bandwidth, affinity and so on. Levis, et al. Expires January 8, 2008 [Page 6] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 3.2. OLSR Optimized Link State Routing (OLSR) (see [RFC3626] and [I-D.ietf-manet-olsrv2]) is a link state routing protocol intended for wireless mesh networks. OLSR nodes flood route discovery packets throughout the entire network, such that each node has a map of the mesh topology. Because link variations can lead to heavy flooding traffic when using a link state approach, OLSR establishes a topology for minimizing this communication. Each node maintains a set of nodes called its Multipoint Relays (MPR), which is a subset of the one-hop neighbors whose connectivity covers the two-hop neighborhood. Each node that is an MPR maintains a set called its MPR selectors, which are nodes that have chosen it to be an MPR. OLSR uses these two sets to apply three optimizations. First, only MPRs generate link state information. Second, nodes can use MPRs to limit the set of nodes that forward link state packets. Third, an MPR, rather than advertise all of its links, can advertise only links to its MPR selectors. Together, these three optimizations can greatly reduce the control traffic in dense networks, as the number of MPRs should not increase significantly as a network becomes denser. Together, these optimizations mean that an OLSR node maintains closer to O(n) rather than O(n^2) state. OLSR selects routes based on hop counts, and assumes an underlying protocol that determines whether a link exists between two nodes. OLSR's constrained flooding allows it to quickly adapt to and propagate topology changes. OLSR is closely related to clustering algorithms in the wireless sensor networking literature, in which cluster heads are elected such that routing occurs over links between cluster heads and all other nodes are leafs that communicate to a cluster head. 4. Distance Vector protocols 4.1. RIP The Routing Information Protocol (RIP) (defined in [RFC2453]) predates OSPF. As it is a distance vector protocol, routing loops can occur and considerable work has been done to accelerate convergence since the initial RIP protocols were introduced. RIP measures route cost in terms of hops, and detects routing loops by observing a route cost approach infinity where "infinity" is referred to as a maximum number of hops. RIP is typically not appropriate for situations where routes need to be chosen based on real-time parameters such as measured delay, reliability, or load or when the Levis, et al. Expires January 8, 2008 [Page 7] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 network topology needs to be known for route computation. It is worth mentioned an important RIP optimization: "Triggered RIP" (defined in [RFC2091]) that was originally designed to support "on- demand" circuits. The aim of triggered RIP is to avoid to systematically send the routing database on regular intervals but only when there was a routing update or a next hop adjacency change. Thus once neighbors have exchanged their routing database, only incremental updates are further sent. Because regular broadcast of routing tables are replaced by incremental updates on such links, triggered RIP introduces acknowledgment based mechanisms. 4.2. DSDV Destination Sequenced Distance Vector Routing uses distance vectors to continuously maintain routes throughout a network. Unlike RIP, DSDV uses per-node sequence numbers to provide a total ordering on route information age in order to prevent loops. In DSDV, each node maintains a route to each other node, which has O(n) state. 4.3. Ad-hoc On Demand Vector Routing (AODV) AODV specified in [RFC3561] is a distance vector protocol intended for mobile ad-hoc networks. When one AODV node requires a route to another, it floods a request in the network to discover a route. A depth-scoped flooding process is advocated to avoid the discovery from any single node expanding to the most distant regions of the network in directions that are away from the destination. If the route request reaches the destination or a node that already has a route to the destination, the recipient sends a reply along the reverse route. All nodes along the reverse route can cache the route. When routes break due to topology changes, AODV issues a new request. If an AODV network supports active flows to D different destinations, a node may require O(D) state. In the worst case, an AODV node must maintain a route to every node, requiring O(n) state. 4.4. DYMO Dynamic Mobile On-Demand routing (DYMO) ([I-D.ietf-manet-dymo]) is an evolution of AODV. The basic functionality is the same, but it has different packet formats, handling rules, and supports path accumulation. Like AODV, DYMO can require each node to store O(D) state and uses hop counts as its routing metric. 4.5. DSR Dynamic Source Routing (DSR) ([RFC4728]) is a distance vector protocol, but a DSR packet source explicitly specifies the route for Levis, et al. Expires January 8, 2008 [Page 8] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 each packet. Because the route is determined at a single place -- the source -- DSR does not require sequence numbers or other mechanisms to prevent routing loops, as there is no problem of inconsistent routing tables. Unlike DSDV, AODV, and DYMO, by pushing state into packet headers, DSR does not require all nodes to store O(n) state. Instead, a node originating packets needs to store up to O(n) state (the spanning tree of routes). In degenerate topologies such as lines, a single route may require O(n) state, but in meshes the state an originator must maintain is dependent on the number of destinations and the topology of the network. 5. Routing Considerations [I-D.culler-rl2n-routing-reqs] provides a superset of the requirements of a wide variety of L2Ns. While it is unlikely that a single routing protocol will satisfy all of them well, it is useful to consider how well existing protocols meet the requirements of L2Ns. Of course, none of these protocols were designed with all these considerations in mind, and so it is not surprising that some of the issues remain unsolved. 5.1. Multi-path routing Whereas multipath routing has traditionally been viewed as a load balancing mechanism, in L2Ns it is more fundamentally a reliability mechanism. The connectivity between a pair of nodes is subject to frequent variations over time, regardless of traffic on that link, because RF opaque obstructions may move between the two devices, path loss characteristics of free space change with environmental conditions, changes in the environment away from the line of sight may introduce multipath effects, the noise level may be raised at the receive due to other RF communication or unrelated electromagnet emissions. Layer 1 mechanisms to ameliorate these factors, such as multiple antennas, that are common in physically large devices are less common in small, embedded ones. Multipath routing provides an alternative form of spatial diversity through multiple potential receivers. However, none of the protocols in our survey (except in specific conditions) maintain multiple candidates that allow the forwarding mechanism to select among them to achieve enhance robustness. In particular, the tree-based discovery and reversal techniques in AODV and DYMO bind many such single-path choices at time of discovery. The route management traffic required to detect and repair such links may exceed the actual data traffic of many L2N applications dramatically. Reactive forwarding over diverse paths may be more easily integrated into proactive protocols, such as OLSR, and especially so among the reduced set of MPRs. L2Ns of large extent will typically have multiple ingress/egress points to well- Levis, et al. Expires January 8, 2008 [Page 9] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 provisioned networks. Thus, multipath routing has considerations beyond the characteristics local to the hops along a physically localized path. For communication external to the L2N, it may be important to choose among geographically unrelated options in exiting the L2N or in entering the L2N. The considerations are most closely related to those in the inter-area routing where OSPF is employed and are not yet addressed by the family of MANET protocols. DSR actively supports path diversity. OSPF and IS-IS supports Multi- path routing in case of ECMP (Equal Cost Multipath). All other protocols use single path routing. Note that it is not uncommon to require asymmetrical load balancing of traffic flow along a set of paths of different cost. IGPs such as OSPF, IS-IS or OLSR do not support such features (routing loop issues). 5.2. Resource awareness In all existing routing protocols the computed path is based on link costs with no consideration of the node attributes and constraints. None of the above protocols explicitly acknowledge the presence of nodes whose unequal energy or memory resources may allow them to play a different routing role. Such characteristics may be of a permanent nature (mains powered device or device with sizable memory or both), a predictable nature (solar powered device in full sun), or evolutionary (battery has become depleted). In any case, the criteria in the route selection is based on characteristics other than the quality of the link or the capacity of the flows. In such networks, it may be desirable to use a policy routing based approach using hierarchical constraints: for example, avoid using a path P1 traversing a node with Node-constraint > X (e.g. reflecting a low battery) if an alternate path P2 can be found that provides a path cost such that Cost(P2) < K * Cost(P1) (with K>1). Furthermore, in some networks, it may be advantageous to follow a path where data can be aggregated along the path to a data collector (e.g. Sink). The knowledge of such node capability could be taken into account by the routing process. Nevertheless, some of them can manipulate their mechanisms to achieve this goal. For example, OLSR can preferentially select more powerful nodes to be MPRs but this does not provides a high degree of granularity in the routing decision. Levis, et al. Expires January 8, 2008 [Page 10] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 5.3. Small footprint Most protocols have state (memory) requirements that can be prohibitive in this domain, in particular the link state protocol where a path to all destinations is systematically computed, which is usually not need in most Sensor Networks or L2Ns where arbitrary node-to-node communication is not common. For example, in monitoring applications the vast majority of the flows are likely to be between the sensor nodes and the data collection points. In automation applications, the majority of the flows are likely to be between actuation points (e.g. the light switch) and the associated control points (the lights that are controlled by the switch). In larger industrial settings, the control points feed to centralized controllers for all control points, so again the majority of flows are highly correlated. At the same time, field devices and remote control units may move through the space introducing other point-to- point flows, but in a monitory role. For networks where there is traffic destinations are highly concentrated, O(D) can be kept small. In the most degenerate case where the traffic is mainly P2MP (Point to Multipoint) or MP2P (Multipoint to Point), a collection tree, it can be O(1). Large and complex protocols can have prohibitively large code bases. A typical collection tree is 8K of code on a 16-bit micro controller. Protocols such as DYMO are slightly larger, as they typically require the same complexity of link estimation by additionally have route maintenance and timing. Protocols such as GPSR tend to be very large (20kB) due to complexities that real world network behavior bring to establishing very regular topologies such as planar graphs. 5.4. Small MTU Most protocols intended for the Internet did not have the tiny MTUs of low-power wireless in mind. The standard AODV header, for example, is 24 bytes. AODV requires route management packet bandwidth that increases with the size of the network to maintain the consistency of the distributed data structure. The protocols that carry a full path in the routing packet generally assume the MTU is large enough to accommodate the diameter of the network. This question of small MTU is not expected to be only a short term concern. Low power generally implies a low Eb/No ratio. The frame length shows up in the exponent part of the expect probability of successful reception expression where it is applied to a quantity smaller than one. Levis, et al. Expires January 8, 2008 [Page 11] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 5.5. Flooding Control and Density Awareness Flooding is the straightforward approach to discover network routes and neighbors. However, arbitrary retransmission can be dangerous (Broadcast Storm), especially in very dense networks. Instead, flooding protocols that adapt to network density (achieving coverage without a retransmission implosion) enable flooding to maintain good delivery rates and prevent network collapse. 5.6. Low power None of the above protocols are inherently low power. Collection trees are often used in a low-power application by simply pushing power conservation to the MAC layer, either using TDMA or channel sampling. Low-power operation typically adds latency, either through TDMA or channel sampling. Many L2N will employ deeply power managed layer 2 media managed layers that leave the radio turned off for the vast majority (i.e 99%) of the time. These generally take one of two forms, sampling techniques that frequently listen for very short intervals and require the transmitter to expend effort to wake up the receiver and TDMA-like techniques to schedule when a node listens to potentially receive packets. Existing analysis of the routing protocols in the survey assume an "always on" behavior of the underlying links. Sampling techniques approximate this assumption, but still may impact the expected delay of a flood, route notification propagation, etc. For networks where data communication is measured in small packets every many minutes, the overhead, scheduled reception may introduce minutes of delay. Such characteristics may eliminate some protocol options. 5.7. Multi-topology Routing MTR (Multi topology Routing) allows for multiple topologies that can be used to route packets according to the shortest paths computed for specific metrics but this comes at the price of high memory consumption. None of the distance vectors currently defined supports for MTR. 6. Security Issues TBD Levis, et al. Expires January 8, 2008 [Page 12] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 7. Manageability Issues TBD 8. IANA Considerations This document includes no request to IANA. 9. Security Considerations TBD 10. Acknowledgements 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [I-D.culler-rl2n-routing-reqs] Vasseur, J. and D. Cullerot, "Routing Requirements for Low-Power Wireless Networks", draft-culler-rl2n-routing-reqs-00 (work in progress), July 2007. [I-D.ietf-manet-dymo] Perkins, C. and I. Chakeres, "Dynamic MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo-10 (work in progress), July 2007. [I-D.ietf-manet-olsrv2] Clausen, T., "The Optimized Link State Routing Protocol version 2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007. [RFC1387] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1387, January 1993. [RFC2091] Meyer, G. and S. Sherry, "Triggered Extensions to RIP to Support Demand Circuits", RFC 2091, January 1997. Levis, et al. Expires January 8, 2008 [Page 13] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, February 2007. Authors' Addresses P Levis Stanford University Email: pal@cs.stanford.edu JP Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: jpv@cisco.com Levis, et al. Expires January 8, 2008 [Page 14] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 D Culler Arch Rock 657 Mission St. Suite 600 San Francisco, CA 94105 USA Email: dculler@archrock.com Levis, et al. Expires January 8, 2008 [Page 15] Internet-Draft draft-levis-rl2n-overview-protocols-01 July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Levis, et al. Expires January 8, 2008 [Page 16]