Network Working Group K. Kim, Ed. Internet-Draft picosNet Corp/Ajou Univ. Intended status: Standards Track S. Daniel Park, Ed. Expires: December 21, 2007 SAMSUNG Electronics G. Montenegro Microsoft Corporation S. Yoo Ajou University N. Kushalnagar Intel Corp June 19, 2007 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD) draft-daniel-6lowpan-load-adhoc-routing-03.txt 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 December 21, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD) is intended for use by IEEE 802.15.4 devices in a 6LoWPAN. It is a simplified on-demand routing protocol based on AODV. Kim, et al. Expires December 21, 2007 [Page 1] Internet-Draft LOAD June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Routing Table Entry . . . . . . . . . . . . . . . . . . . 6 5.2 Route Request Table Entry . . . . . . . . . . . . . . . . 6 5.3 Message Format . . . . . . . . . . . . . . . . . . . . . . 7 5.3.1 Route Request (RREQ) . . . . . . . . . . . . . . . . . 7 5.3.2 Route Reply (RREP) . . . . . . . . . . . . . . . . . . 8 5.3.3 Route Error (RERR) . . . . . . . . . . . . . . . . . . 10 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1 Generating Route Request . . . . . . . . . . . . . . . . . 11 6.2 Processing and Forwarding Route Request . . . . . . . . . 11 6.3 Generating Route Reply . . . . . . . . . . . . . . . . . . 11 6.4 Receiving and Forwarding Route Reply . . . . . . . . . . . 12 6.5 Local Repair and RERR . . . . . . . . . . . . . . . . . . 12 7. Configuration Parameters . . . . . . . . . . . . . . . . . . . 13 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgments . . .. . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1 Normative Reference . . . . . . . . . . . . . . . . . . . 14 11.2 Informative Reference . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 17 Kim, et al. Expires December 21, 2007 [Page 2] Internet-Draft LOAD June 2007 1. Introduction The IEEE 802.15.4 standard [ieee802.15.4] targets low power personal area networks. The "IPv6 over IEEE 802.15.4" document [I-D.montenegro-lowpan-ipv6-over-802.15.4] defines basic functionality required to carry IPv6 packets over IEEE 802.15.4 networks (including an adaptation layer, header compression, etc). Likewise, the functionality required for packet delivery in IEEE 802.15.4 meshes is defined, as mesh topologies are expected to be common in LoWPAN networks. However, neither the IEEE 802.15.4 standard nor the "IPv6 over IEEE 802.15.4" specification provide any information as to how such a mesh topology could be obtained and maintained. The 6LoWPAN Ad hoc Routing Protocol (LOAD) is a simplified on-demand routing protocol based on AODV[RFC3561] for 6LoWPAN. Besides the main AODV specification [RFC3561], several efforts aim at simplifications of the protocol, as in the AODVjr proposal [AODVjr] or the TinyAODV implementation [TinyAODV]. Similarly, DyMO allows for minimalist implementation leaving non-essential functionality as optional [I-D.ietf-manet-dymo]. LOAD enables multihop routing between IEEE 802.15.4 devices to establish and maintain routing routes in 6LoWPAN. This document defines the message formats, the data structures, and the operations of LOAD. 2. Requirements notation 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 [RFC2119]. 3. Overview This section describes the distinctive features of LOAD compared to AODV. LOAD is defined to be operating on top of the adaptation layer instead of the transport layer. That is, it creates a mesh network topology underneath and unbeknownst to IPv6 network layer. IPv6 sees a 6LoWPAN as a single link. This is similar to how other technologies regularly create complex structures underneath IP (e.g., ethernet spanning tree bridges, token ring source routing, ATM, etc). LOAD control packets use the encapsulation defined in [I-D.montenegro -lowpan-ipv6-over-802.15.4]. All LOAD control packets shall use the prot_type value TBD (suggested value of 4). LOAD assumes the use of either one of the two different addresses for routing: the EUI-64 address and the 16 bit short address of the 6LoWPAN device. Kim, et al. Expires December 21, 2007 [Page 3] Internet-Draft LOAD June 2007 LOAD makes use of broadcast in its route discovery. It does so in order to propagate the Route Request (RREQ) messages. In this specification, such broadcast packets are obtained by setting the PAN id to the broadcast PAN (0xffff) and by setting the destination address to the broadcast short address (0xffff). LOAD doesn't use the destination sequence number in order to reduce the size of the control messages and simplify the route discovery process. For ensuring loop freedom, only the destination of a route SHOULD generate a RREP in reply. The intermediate nodes SHOULD not respond with a RREP. By the same reason, LOAD does not use the "Gratuitous RREP". LOAD MAY use the local repair for a link break during a data delivery. In a local repair, only the destination generates a RREP in reply because of no use of the destination sequence number. If a local repair fails, LOAD MAY generate a Route Error (RERR) message toward the originator of the data delivery to notify that the destination is no longer reachable by way of the broken link. The format of RERR is simplified to include only one unreachable destination while the RERR of AODV MAY include multiple ones. LOAD does not use the "precursor list" of AODV to simplify the routing table structure. Notice that AODV uses the precursors for forwarding RERR messages in the event of detection of the loss of the next hop link. In LOAD, RERR is forwarded only to the originator of the failed data delivery, thus no requiring to use the precursor list. LOAD MAY use the route cost, which is the accumulated link cost from the originator to the destination, as a metric of routing. For this, LOAD utilizes the Link Quality Indicator (LQI) of the 6LoWPAN PHY layer in the routing decision in addition to the hop distance. There are many ways to include LQI in the routing metric. The approach taken by LOAD avoids a route which contains weak links whose LQI is below certain threshold value (i.e. WEAK_LQI_VALUE). LOAD SHOULD utilize the acknowledged transmission option at the 6LoWPAN MAC layer for keeping track of the connectivity of a route. LOAD uses neither the passive acknowledgements nor the HELLO messages of AODV. Kim, et al. Expires December 21, 2007 [Page 4] Internet-Draft LOAD June 2007 The basic operations of LOAD are route discovery, managing data structures and maintaining local connections. For these operations, LOAD maintains the following two tables: the routing table and the route request table. The routing table stores route information such as destination, next hop node, and status. The route request table stores the temporary route information used in the route discovery process. There are two different types of 6LoWPAN devices: the reduced function device(RFD) and the full function device (FFD). LOAD SHOULD utilize only FFD for mesh routing. Thus, A FFD SHOULD implement the operations of LOAD and maintain the data structures of LOAD. 4. Terminology This section defines the terminology of LOAD that is not defined in [RFC3753] and [RFC3561]. destination A node to which data packets are to be transmitted. Same as "destination node". forward route A route set up to send data packets from the originator to its destination. link cost The link Quality (LQ) between a node and its neighbor node. link quality indicator (LQI) A mechanism to measure the Link Quality (LQ) in IEEE 802.15.4 PHY layer [ieee802.15.4]. It measures LQ by receiving the signal energy level. A high LQ value implies the good quality of communication (i.e. low link cost). weak link A link of which the LQI falls below WEAK_LQI_VALUE. originator A node that initiates a route discovery process. Same as "originating node" Kim, et al. Expires December 21, 2007 [Page 5] Internet-Draft LOAD June 2007 route cost An accumulated link cost as a LOAD control message (RREQ or RREP) passes through the nodes on the route. reverse route A route set up to forward a RREP back to the originator from the destination. Same as "reverse route" in [RFC3561]. 5. Data Structures A FFD in 6LoWPAN SHOULD maintain a routing table and a route request table. This section describes the tables and the message formats. 5.1 Routing Table Entry The routing table of LOAD includes the following fields: destination address The 16 bit short or EUI-64 link layer address of the final destination of a route next hop address The 16 bit short or EUI-64 link layer addresses of the next hop node to the destination. status The status of a route. It includes the following states: VALID, INVALID, ROUTE_DISCOVERY, etc. life time The valid time in milliseconds before the expiration or the deletion of a route. 5.2 Route Request Table Entry Route request table is used for discovering routes. It stores the following route request information until a route is discovered. route request ID a sequence number uniquely identifying the particular RREQ when taken in conjunction with the originator Kim, et al. Expires December 21, 2007 [Page 6] Internet-Draft LOAD June 2007 originator address The 16 bit short or EUI-64 link layer address of the node which originates a RREQ. reverse route address The 16 bit short or EUI-64 link layer address of the next hop node on the reverse route to the originator. forward route cost The accumulated link cost along the forward route from the originator to the current node through which a RREQ is forwarded. reverse route cost The accumulated link cost along the reverse route from the final destination to the current node through which a RREP is forwarded. valid time The time of the expiration or deletion of a route in milliseconds. 5.3 Message Format 5.3.1 Route Request (RREQ) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|D|O|Reserved | CT | WL | RREQ ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RC | Link Layer Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Originator Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RREQ message format is shown in Fig. 1 and contains the following fields: Type 1 for indicating a RREQ message. Kim, et al. Expires December 21, 2007 [Page 7] Internet-Draft LOAD June 2007 CT Type of route cost. The followings are the current route cost types known: 0 : Hop count while avoiding weak links 1-0xf: TBD WL The total number of weak links on the routing path from the originator to the sender of the RREQ. R 1 Local Repair. D 1 for the 16 bit address of the destination, 0 for the EUI-64 address of the destination. O 1 for the 16 bit address of the originator, 0 for the EUI-64 address of the originator. RC(Route cost) The accumulated link cost of the reverse route from the originator to the sender of the RREQ. The type of link cost is specified by CT. RREQ ID A sequence number uniquely identifying the particular RREQ when taken in conjunction with the originator. Reserved 0; ignored on reception. Link layer Destination Address The 16 bit short or EUI-64 link layer address of the destination for which a route is supplied. Link layer Originator Address The 16 bit short or EUI-64 link layer address of the node which originated the Route Request. 5.3.2 Route Reply (RREP) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|D|O|Reserved | CT | WL | RREQ ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RC |Link layer Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link layer Originator Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kim, et al. Expires December 21, 2007 [Page 8] Internet-Draft LOAD June 2007 The RREP message format is shown in Fig. 2 and contains the following fields: Type 2 for indicating a RREP message. CT Type of route cost. The followings are the current route cost types known: 0 : Hop count while avoiding weak links 1-0xf: TBD WL The total number of weak links on the routing path from the originator of the RREP to the sender of the RREP. R 1 Local Repair. D 1 for the 16 bit address of the destination, 0 for the EUI-64 address of the destination. O 1 for the 16 bit address of the originator, 0 for the EUI-64 address of the originator. Reserved 0; ignored on reception. RC(Route cost) The accumulated link cost of the route from the originator of the RREP to the sender of the RREP. The type of link cost is specified by CT. RREQ ID A sequence number uniquely identifying the particular RREQ when taken in conjunction with the originator. Link layer Destination Address The 16 bit short or EUI-64 link layer address of the destination for which a route is supplied. Link layer Originator Address The 16 bit short or EUI-64 link layer address of the node which originated the Route Request. Kim, et al. Expires December 21, 2007 [Page 9] Internet-Draft LOAD June 2007 5.3.3 Route Error (RERR) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |D| Reserved | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreachable Link Layer Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RERR message format is shown in Fig. 3 and contains the following fields: Type 3 for indicating a RERR message. D 1 for the 16 bit address of the destination, 0 for the EUI-64 address of the destination. Reserved 0; ignored on reception. Error Code Numeric value for describing error. 0x00 = No available route 0x01 = Low battery 0x02 = routing cost not supported 0x03 - 0xff = reserved (TBD) Unreachable Link Layer Destination Address The 16 bit short or EUI-64 link layer address of the final destination that has become unreachable due to a link break. Kim, et al. Expires December 21, 2007 [Page 10] Internet-Draft LOAD June 2007 6. Operation 6.1 Generating Route Request The basic operations of LOAD include route discovery, managing data structures and maintaining local connections. A node maintains the following two tables for routing: the routing table and the routing request table. During the discovery period, an originator, a node that requests a route discovery, generates a Route Request (RREQ) message with the RREQ ID which was incremented by one from the previous RREQ ID value. A node SHOULD NOT originate more than RREQ_RATELIMIT RREQs per second. After brocasting a RREQ, a node waits for a RREP. If a route is not discovered within NET_TRAVERSAL_TIME milliseconds, the node MAY try again the discovery process a maximum of RREQ_RETRIES times. 6.2 Processing and Forwarding Route Request Upon receiving a RREQ, an intermediate FFD node tries to find the entry of the same originator address and RREQ ID pair in the route request table. If the entry is found, the node just discards the RREQ. Otherwise, the node creates a reverse route to the originator in the routing table and a RREQ entry in the route request table. It then checks whether the link through which the RREQ is received is a weak link or not. If the link is a weak link, the node adds 1 to the WL field of the RREQ. Then, the node forwards the RREQ. 6.3 Generating Route Reply When the destination receives a RREQ, it tries to find the entry of the same originator address and RREQ ID pair in the route request table. If the entry is found, the destination compares the route cost of the RREQ with the forward route cost of the entry. If the cost of the RREQ is better than(i.e. less than) that of the entry, the desti- nation updates the reverse route to the originator in the routing table and generates a RREP in reply. If the cost of the RREQ is not less than that of the entry, the destination just discards the RREQ. If the CT field of the RREQ is 0 (i.e. hop count while avoiding weak links), the route cost becomes a tuple of (WL, RC) and is ordered lexicographically. That is, the route cost (WL,RC) is said to be better (or smaller) than or equal to (WL',RC') if the following condition holds. (WL,RC) <= (WL',RC') if and only if WL < WL', or WL == WL' and RC <= RC' Kim, et al. Expires December 21, 2007 [Page 11] Internet-Draft LOAD June 2007 6.4 Receiving and Forwarding Route Reply Upon receiving a RREP, an intermediate node checks whether the link through which the RREP is received is a weak link or not. If the link is a weak link, the node add 1 to the WL field of the RREP. The node then checks whether it has a route entry for the destination of the RREP (i.e. the originator of the corresponding RREQ). If it does not have the route entry, it just discards the RREP. Otherwise, it also checks for the existence of the corresponding RREQ entry (which has the same RREQ ID and originator address pair as that of the RREP) in the route request table. If there is no such entry, then it just discards the RREP. If there is such an entry and the entry has worse reverse route cost (i.e. higher value) than the route cost of the RREP, the node updates the entry with the information of the RREP and forwards it to the previous hop node toward the destination of the RREP. If the entry has better reverse route cost (i.e. lower value) than that of the RREP, the node just discards the RREP. If the CT field of the RREP is 0 (i.e. hop count while avoiding weak links), the route cost becomes a tuple of (WL,RC) and is ordered lexicographically. During the delivery of the RREP to the originator, the route cost value of the RREP is accumulated on the reverse route from the destination to the originator. 6.5 Local Repair and Route Error (RERR) Messages If a link break occurs or a device fails during the delivery of data packets, the upstream node of the link break MAY repair the route locally. To repair a route, the node disseminates a RREQ with the originator address set to its own address and the destination address set to the data packet's destination address. In this case, the 'R flag' of the RREQ is set to 1. The data packet is buffered during the route discovery period. If the destination node receives the RREQ for a route repair, it responds with a RREP of which the 'R flag' is also set to 1. If the repairing node cannot receive a RREP from the final destination until the end of the route discovery period, it unicasts a RERR with an error code that indicates the reason of the repair failure to the originator. A repairing node SHOULD NOT generate more than RERR_RATELIMIT RERRs per second. Then, the buffered data packet is discarded. If the originator that sends a data packet receives the RERR, it MAY try to reinitiate route discovery. Kim, et al. Expires December 21, 2007 [Page 12] Internet-Draft LOAD June 2007 When the repairing node receives a RREP from the destination during the route discovery period, it updates the routing table entry information from the RREP. Then the node transmits the buffered data packet to the destination through the new route. 7. Configuration Parameters This section describes the default values for some important parameters associated with LOAD operations. Parameter Name Value --------------------- ------------- NET_TRAVERSAL_TIME TBD RREQ_RETRIES 3 RREQ_RATELIMIT 2 RERR_RATELIMIT 2 WEAK_LQI_VALUE 8 8. IANA Consideration This document needs an additional IANA registry for the prot_type value that indicates the LOAD format. 9. Security Considerations The security considerations of the [RFC3561] are applicable to this document. As described in the charter of the 6lowpan w.g., LOAD will also try to reuse existing security considerations related to Ad hoc routing protocols. Further considerations will be studied in the next version. 10. Acknowledgments Thanks to the authors of RFC 3753 and RFC 3561, as parts of this document are patterned after theirs. Thanks to Nandakishore Kushalnagar, Byeong-Hee Roh, Myung-ho Jung, Dae-hong Son, and Minho Lee for their useful discussions and supports for writing this document. Kim, et al. Expires December 21, 2007 [Page 13] Internet-Draft LOAD June 2007 11. References 11.1 Normative Reference [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html. [I-D.ietf-6lowpan-format] N., Kushalnagar., Montenegro, G., Hui, J., and D. Culler, "6LoWPAN: Transmission of IPv6 Packets over IEEE 802.15.4 Networks", draft-ietf-6lowpan-format (work in progress), April 2007. [I-D.ietf-ipv6-rfc2462bis] Thomson, S., "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08 (work in progress), May 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [ieee802.15.4] IEEE Compure Society, "IEEE Std. 802.15.4-2003", IEEE Std. 802.15.4-2003, October 2003. 11.2 Informative Reference [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995. [I-D.ietf-6lowpan-problem] N., Kushalnagar., Montenegro, G., and C. Schumacher, "6LoWPAN: Overview, Assumptions, Problem Statement and Goals", draft-ietf-6lowpan-problem (work in progress), February 2007. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. Kim, et al. Expires December 21, 2007 [Page 14] Internet-Draft LOAD June 2007 [AODVjr] Chakeres, Ian and Klein-Berndt, Luke, "AODVjr, AODV Simplified", ACM SIGMOBILE Mobile Computing and Communications Review pp. 100-101, July 2002. [I-D.ietf-manet-dymo] Chakeres, I., "Dynamic MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo (work in progress), May 2007. [TinyAODV] "TinyAODV Implementation", TinyOS Source Code Repository h ttp://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-1.x/ contrib/hsn/. Kim, et al. Expires December 21, 2007 [Page 15] Internet-Draft LOAD June 2007 Authors' Addresses Kim, Ki Hyung (editor) picosNet Corp/Ajou Univ. San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 219 2433 EMail: kkim86@picosnet.com Soohong Daniel Park, Editor Mobile Platform Laboratory, SAMSUNG Electronics 416 Maetan-3dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-742 KOREA Phone: +82 31 200 4508 Email: soohong.park@samsung.com Gabriel Montenegro Microsoft Corporation US Email: gabriel_montenegro_2000@yahoo.com Seung Wha Yoo Ajou University San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 219 1603 Email: swyoo@ajou.ac.kr Nandakishore Kushalnagar Intel Corp US Email: nandakishore.kushalnagar@intel.com Kim, et al. Expires December 21, 2007 [Page 16] Internet-Draft LOAD June 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. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kim, et al. Expires December 21, 2007 [Page 17]