Network Working Group K. Kim, Ed. Internet-Draft Ajou University Expires: September 5, 2007 Soohong Daniel Park, Ed. SAMSUNG Electronics G. Montenegro Microsoft Corporation I. Chakeres Boeing C. Perkins Nokia March 4, 2007 Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing draft-montenegro-6lowpan-dymo-low-routing-02 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 September 5, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Kim, et al. Expires September 5, 2007 [Page 1] Internet-Draft DYMO-low March 2007 Abstract This document specifies how to use the Dynamic MANET On-demand Routing Protocol over IEEE802.15.4 networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Simplifications for DYMO over IEEE 802.15.4 . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 6 3.2. DYMO-low Messages . . . . . . . . . . . . . . . . . . . . 6 3.2.1. DYMO-low Routing Messages . . . . . . . . . . . . . . 6 4. Detailed operation . . . . . . . . . . . . . . . . . . . . . . 9 4.1. DYMO-low Routing Table Operations . . . . . . . . . . . . 9 4.1.1. Creating or Updating a Route Table Entry from New Routing Information . . . . . . . . . . . . . . . . . 9 4.2. Routing message . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Routing message creation . . . . . . . . . . . . . . . 10 4.2.2. Routing message Processing . . . . . . . . . . . . . . 10 4.3. Route Maintenance . . . . . . . . . . . . . . . . . . . . 11 4.3.1. Monitoring of Active Links . . . . . . . . . . . . . . 11 4.3.2. Updating Route Lifetimes . . . . . . . . . . . . . . . 11 4.3.3. Route Error Generation . . . . . . . . . . . . . . . . 11 4.4. General DYMO-low Processing . . . . . . . . . . . . . . . 12 4.4.1. DYMO-low Processing . . . . . . . . . . . . . . . . . 12 4.4.2. DYMO-low Control Packet Transmission . . . . . . . . . 12 4.5. Packet Generation Limits . . . . . . . . . . . . . . . . . 12 5. Configuration Parameters . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Kim, et al. Expires September 5, 2007 [Page 2] Internet-Draft DYMO-low March 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.ietf- 6lowpan-format] defines basic functionality required to carry IPv6 packets over IEEE 802.15.4 networks (including an adaptation layer, header compression, etc). Likewise, as mesh topologies are expected to be common in LoWPAN networks, the functionality required for packet delivery in IEEE 802.15.4 meshes is defined. 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. This document specifies how to use the Dynamic MANET On-demand Routing Protocol (DYMO) [I-D.ietf-manet-dymo] over IEEE 802.15.4 networks to provide mesh routing. To distinguish this instantiation of the protocol from DYMO over IPv4 and DYMO over IPv6, the label "DYMO-low" is used in this document. Given the very stringent limitations of the target devices, this document specifies simplifications that are recommended to the base DYMO specification. 1.1. 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]. 2. Overview The addresses used in DYMO-low control messages are either 16 bit link layer short address or IEEE 64-bit extended addresses [EUI64]. Additionally, it should be noted that as used in this specification, DYMO-low is not layered on top of IP, but underneath it. It is an underlay. As such, it creates a mesh network topology of IEEE 802.15.4 devices that use single wireless interface each, underneath and unbeknownst to IP. IP sees a PAN 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). One can envision a sub-IP mesh creating the illusion that all the devices on that PAN are on the same IPv6 link (sharing the same IPv6 prefix). At the same time, normal usage of DYMO (above IP) could tie together several such "links" (potentially using different technologies for each) into a larger mesh. DYMO makes use of link-local multicast in its route discovery. It does so in order to propagate the Route Request control packets (RREQs). In this specification, such link-local multicast packets Kim, et al. Expires September 5, 2007 [Page 3] Internet-Draft DYMO-low March 2007 are obtained by setting the PAN id to the link-local multicast PAN (0xffff) and by setting the link layer destination address to the link-local multicast short address (0xffff). DYMO-low control packets use the encapsulation defined in [I-D.ietf-6lowpan-format]. All DYMO-low control packets shall use the prot_type value TBD (suggested value of 5). This prot_type is used to send DYMO-low messages in a manner similar to how DYMO uses a properly assigned UDP port. 2.1. Simplifications for DYMO over IEEE 802.15.4 This section specifies simplifications and distinctive features of DYMO-low compared to the base DYMO. DYMO allows for minimalist implementations by specifying non- essential functionality as optional [I-D.ietf-manet-dymo]. In keeping with DYMO, DYMO-low implements the routing message(RM) which provides both the RREQ (route request) and the RREP (route reply). The RERR (route error) message is also implemented. DYMO-low has the following characteristics: o RREQ messages are transmitted as IEEE 802.15.4 link-local multicast messages to reach all the next hop neighbors. DYMO packets SHOULD NOT be fragmented. o The generalized packet and message format [I-D.ietf-manet- packetbb] is not used in DYMO-low for the limited packet size and reducing packet processing complexity. o Only the final destination SHOULD respond to a RREQ by replying with a RREP. o Link quality (LQI) of IEEE 802.15.4[ieee802.15.4] in addition to the route cost is utilized for selecting best route to the destination. o The IEEE 802.15.4 acknowledgement mechanism is used to determine if a neighbor is no longer responsive. This information is obtained when transmitting a packet with acknowledgement option turned on. o Due to space limitations, nodes SHOULD append only one unreachable destination in RERR. o DYMO Sequence numbers allow nodes to judge the freshness of routing information and ensure loop freedom. Kim, et al. Expires September 5, 2007 [Page 4] Internet-Draft DYMO-low March 2007 o The transmission method for RREQ and RERR messages in DYMO is link-local multicast.However, considering the energy-constrained nature of 6lowpan, some efficient mechanisms other than broadcast are necessitated in DYMO-low (TBD). 2.2. Terminology Link Layer Destination Address (LinkLayerDestinationAddress) The 16 bit short or EUI-64 link layer address of the destination in the MAC layer. It is also called as the next-hop destination during hop-by-hop forwarding of packets. Link Layer Source Address (LinkLayerSourceAddress) The 16 bit short or EUI-64 link layer address of the source in the MAC layer. It is also called as the previous-hop source address during hop-by-hop forwarding of packets. Broadcast The broadcast in 6lowpan implies the link-local multicast in IEEE 802.15.4 MAC layer. This can be done by setting the link layer destination field to 0xffff. Target Node (TargetNode) The TargetNode is the ultimate destination of a message. This Node (ThisNode) ThisNode corresponds to the node currently performing a calculation or processing a message. Unreachable Node (UnreachableNode) An UnreachableNode is a node for which ThisNode does not have a forwarding route. DYMO Sequence Number (SeqNum) A DYMO Sequence Number is maintained by each node. This sequence number is used by other nodes to identify the order of routing information generated by a node and to ensure loop-free routes. Kim, et al. Expires September 5, 2007 [Page 5] Internet-Draft DYMO-low March 2007 3. Data Structures 3.1. Route Table Entry The route table entry is a conceptual data structure. Implementations may use any internal representation that conforms to the semantics of a route as specified in this document. Conceptually, a route table entry has the following fields: Route Destination Address (Route.DestAddress) The 16 bit short or EUI-64 link layer address of the final destination of a route. Route Cost (Route.RouteCost) Cumulative cost metric used for allowing a node to select an optimum route to the final destination. Route Next Hop Address (Route.NextHopAddress) The 16 bit short or EUI-64 link layer address of the next-hop node on the path toward the final destination. Route Sequence Number (Route.SeqNum) The 16 bit short or EUI-64 link layer address of the next-hop node on the path toward the final destination. Route.Broken A flag indicating whether this Route is broken. This flag is set if the next hop becomes unreachable or in response to processing a RERR. In addition to a route table data structure, each route table entry may have several timers associated with the information. The detailed timers/timeouts are TBD. 3.2. DYMO-low Messages DYMO-low messages are categorized either as a Routing Message (RM) or a Route Error (RERR) message. 3.2.1. DYMO-low Routing Messages Routing Messages (RMs) are used to disseminate routing information. A RM can be either a Route Request (RREQ) message or a Route Reply Kim, et al. Expires September 5, 2007 [Page 6] Internet-Draft DYMO-low March 2007 (RREP) message. These messages are very similar in information but vary in the way of their processing. 3.2.1.1. DYMO-low Route Request (RREQ) and Route Reply (RREP) messages 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 | HopLimit |T|O| CT | Res | TRouteCost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RREQID | TargetNode.Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OrigNode.Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OrigNode.SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Route Message Format Message Type (Type) The following is the list of the currently available message types. Type Value -------------------------------- ----- Route Request (RREQ) 1 Route Reply (RREP) 2 HopLimit 8-bit field that identifies the maximum number of times the message is to be retransmitted. Target (T-bit) 1 for the 16-bit address of the TargetNode. 0 for the EUI-64 address of the TargetNode. Originator (O-bit) 1 for the 16-bit address of the OrigNode. 0 for the EUI-64 address of the OrigNode. Cost Type (CT) 3-bits of cost type field defines the cost type. The detailed types are TBD. Kim, et al. Expires September 5, 2007 [Page 7] Internet-Draft DYMO-low March 2007 Target Route Cost (TRouteCost) 8-bit field that identifies the routing cost across the number of intermediate nodes through which a packet traversed on the route to this particular TargetNode.Address. RREQ ID An identifier that uniquely identifies the particular RREQ when taken in conjunction with the originator. It serves two purposes, i) It allows intermediate nodes to process the RREQ message once and ii) It matches a unique RREP message against unique RREQ in the wake of multiple RREQ generation. Target Node Address (TargetNode.Address) The node that is the ultimate destination of the message. In a RREQ the TargetNode is the destination for which a forwarding route does not exist and a route discovery is being performed. In a RREP the TargetNode is the corresponding RREQ's OrigNode. Originator Node Address (OrigNode.Address) In RREQ message, the OrigNode is the node that generates a RREQ message. In RREP, the OrigNode is the node that replies to RREQ. 3.2.1.2. 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 | HopLimit |T|O|U|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TargetNode.Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OrigNode.Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UnreachableNode.Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Route Error Message Format Type Value -------------------------------- ----- Route Error (RERR) 3 HopLimit Kim, et al. Expires September 5, 2007 [Page 8] Internet-Draft DYMO-low March 2007 8-bit field that identifies the maximum number of times the message is to be retransmitted. Target (T-bit) 1 for the 16-bit address of the TargetNode. 0 for the EUI-64 address of the TargetNode. Originator (O-bit) 1 for the 16-bit address of the OrigNode. 0 for the EUI-64 address of the OrigNode. U-bit (U-bit) 1 for the 16-bit address of UnreachableNode. 0 for the EUI-64 address of UnreachableNode. Target Node Address (TargetNode.Address) The 16-bit short or EUI-64 link layer address of the node that is the destination of the RERR message. Originator Node Address (OrigNode.Address) The 16-bit short or EUI-64 link layer address of the node that generates the RERR message. UnreachableNode.Address The 16-bit short or EUI-64 link layer address of the node that has become unreachable. 4. Detailed operation 4.1. DYMO-low Routing Table Operations 4.1.1. Creating or Updating a Route Table Entry from New Routing Information While processing a RM, as described in Section 4.2.2, a node checks its routing table for an entry to the OrigNode.Address in the RREQ. If a valid route exists to TargetNode.Address, the route can be used to send any queued data packets and to fulfill any outstanding route requests. Kim, et al. Expires September 5, 2007 [Page 9] Internet-Draft DYMO-low March 2007 In the event that no matching entry is found, an entry is created. If a matching entry is found, the routing information about OrigNode.Address contained in this RM is considered stale if the TRouteCost is greater than Route.RouteCost. If there exists a route AND the TRouteCost is equal to the Route.RouteCost in this RM, the information is not stale, but the routing information SHOULD be disregarded and no routing update should occur. If the information in this RM is stale or disregarded this DYMO-low packet MUST be dropped. If the route information for Originator is not stale or disregarded, then the following actions occur to the route table entry for OrigNode.Address: 1. the Route.RouteCost is set to the TRouteCost, 2. the Route.NextHopAddress is set to the node that transmitted this DYMO-low packet (LinkLayerSourceAddress), 3. if a valid route exists to TargetNode.Address, the route can be used to send any queued data packets and to fulfill any outstanding route requests. 4.2. Routing message 4.2.1. Routing message creation When a node creates a RREQ or RREP, it MUST create the RM. It sets the OrigNode.Address to its own address. 4.2.2. Routing message Processing After the general DYMO-low message pre-processing (Section 4.5.2), the routing message is processed to yield the route cost TRouteCost. That is, the route cost TRouteCost is said to be better (or equivalently smaller) than or equal to (Route.RouteCost') if the following condition holds (Note that the apostrophe refers to Route.RouteCost i.e., an already existing route entry in the routing table) TRouteCost < = Route.RouteCost' If a matching entry to the OrigNode.Address in the routing message is found in the routing table, the routing information about OrigNode.Address contained in this routing message is considered Kim, et al. Expires September 5, 2007 [Page 10] Internet-Draft DYMO-low March 2007 stale if TRouteCost is greater than the Route.RouteCost'. If the information in this routing message is stale or disregarded this DYMO-low packet MUST be dropped. If there exists a route AND equal the information is not stale, then the routing information SHOULD be disregarded and no routing update should occur. If the route information for OrigNode.Address is not stale or disregarded,then the following actions occur to the route table entry for OrigNode.Address: 1. the Route.RouteCost is set to the TRouteCost, 2. the Route.NextHopAddress is set to the node that transmitted this DYMO-low packet (LinkLayerSourceAddress), If this node is the TargetNode.Address AND the received RM's type is RREQ, this node MUST respond with a RREP. The target node creates a new RM as described in Section 4.2.1. The TargetNode.Address in the new RM is set to the OrigNode.Address from the RM currently being processed. The LinkLayerDestinationAddress is set to the Route.NextHopAddress for the TargetNode.Address. Then the new RM undergoes post-processing, according to Section 4.5.3. If this node is not the TargetNode.Address, the current RE SHOULD be handled according to Section 4.5.4. 4.3. Route Maintenance 4.3.1. Monitoring of Active Links Before a route can be used for forwarding a packet, it MUST be checked to make sure that the route is still valid. The detailed operation of checking is TBD. A RERR MUST be issued if a data packet is received and it cannot be delivered to the next hop. RERR generation is described in Section 4.4.3. A RERR SHOULD be issued after detecting a broken link of an active route to quickly notify nodes that a link break occurred and a route or routes are no longer available. 4.3.2. Updating Route Lifetimes TBD. 4.3.3. Route Error Generation When a data packet is received for a destination without a valid routing table entry, a Route Error (RERR) MUST be generated by this node. A RERR informs the source that the current route is no longer available. In the RERR, the TargetNode.Address field is the address Kim, et al. Expires September 5, 2007 [Page 11] Internet-Draft DYMO-low March 2007 of the unreachable node (final destination address) from the data packet. The setting of theL inkLayerDestinationAddress of the RERR and the RERR processing at the receiving node are TBD. 4.4. General DYMO-low Processing 4.4.1. DYMO-low Processing The Routing Message (RM) MUST be processed completely prior to any transmissions. Unless specific message processing requires dropping the DYMO-low packet, it is retransmitted after processing, according to the method described in Section 4.5.4. 4.4.1.1. Routing Message Pre-processing The RM in a DYMO-low packet undergoes pre-processing before the message specific processing occurs. During pre-processing, the HopLimit is decremented by one (1). 4.4.1.2. Routing Message Post-processing If the HopLimit is zero (0) the DYMO-low packet is dropped. If the HopLimit is greater than zero the DYMO-low packet is re-transmitted after processing of all messages. If the HopLimit of Routing Message (RM) is zero (0) after processing, it MUST be removed from the DYMO- low packet prior to transmission. 4.4.2. DYMO-low Control Packet Transmission DYMO-low packet transmission and re-transmission is controlled by the LinkLayerDestinationAddress. If the LinkLayerDestinationAddress is a unicast address, the packet LinkLayerDestinationAddress is replaced by the Route.NextHopAddress from a route table lookup for the TargetNode.Address. If a route for the TargetNode.Address is unknown or invalid the packet is dropped and a RERR SHOULD be generated. 4.5. Packet Generation Limits To avoid congestion, a node SHOULD NOT transmit more than RATE_LIMIT control messages per second. RREQ packets SHOULD be discarded before RREP or RERR packets. 4.6 Sequence Numbers The usage of sequence numbers in DYMO-low follows the base DYMO except the sequence number rollover. 4.6.1 Sequence Number Rollover If the sequence number has been assigned to be the largest possible number representable as a 8-bit unsigned integer, then the sequence number MUST be set to one (1) when incremented. 5. Configuration Parameters Here are some default parameter values for DYMO-low: Kim, et al. Expires September 5, 2007 [Page 12] Internet-Draft DYMO-low March 2007 Parameter Name Suggested Value --------------------------- --------------- NET_DIAMETER 256 RATE_LIMIT 2 RREQ_WAIT_TIME 1000 milliseconds RREQ_TRIES 2 6. IANA Considerations This document needs an additional IANA registry for the prot_type value that indicates the DYMO-low format. 7. Security Considerations The security considerations of the [RFC3561] are applicable to this document. As described in the charter of the 6lowpan w.g., DYMO-low will also try to reuse existing security considerations related to Ad hoc routing protocols. Further considerations will be studied in the next version. 8. Acknowledgements Thanks to Ali Hammad Akbar, Chae-Sung, Lim, Prof. Seung-Wha Yoo, Prof. Byeong-Hee Roh, Shafique Ahmad Chaudhry, and Hee-Jung Kim for their useful discussions and supports for writing this document. 9. References 9.1. Normative References [EUI64] 802.15.4-2003, IEEE Standard., "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY". [I-D.ietf-manet-packetbb] Clausen, T., "Generalized MANET Packet/ Message Format", draft-ietf-manet-packetbb-02 (work in progress), July 2006. [I-D.ietf-manet-dymo] Chakeres, I., "Dynamic MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo-07 (work in progress), February 2007. [I-D.ietf-6lowpan-problem] Kushalnagar, N., Montenegro, G., and C. Schumacher, "6LoWPAN: Overview, Assumptions, Problem Statement and Goals", draft-ietf-6lowpan-problem-08 (work in progress), February 2007. Kim, et al. Expires September 5, 2007 [Page 13] Internet-Draft DYMO-low March 2007 [I-D.ietf-6lowpan-format] Montenegro, G., N., Kushalnagar., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", draft-ietf-6lowpan-format-11 (work in progress), February 2007. [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. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [IEEE802.15.4] 802.15.4-2003, IEEE Standard., "Wireless medium access control and physical layer specifications for low-rate wireless personal area networks.", May 2003. 9.2. Informative References Authors' Addresses Kim, Ki Hyung (editor) Ajou University San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 219 2433 EMail: kkim86@ajou.ac.kr Soohong Daniel Park (editor) SAMSUNG Electronics 416 Maetan-3dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-742 KOREA Phone: +82 31 200 4508 EMail: soohong.park@samsung.com Kim, et al. Expires September 5, 2007 [Page 14] Internet-Draft DYMO-low March 2007 Gabriel Montenegro Microsoft Corporation USA EMail: gabriel_montenegro_2000@yahoo.com Ian Chakeres Boeing P.O. Box 3707 Mailcode 7L-49 SeaHopLimite, WA 98124-2207 USA EMail: ian.chakeres@gmail.com Charles E. Perkins Nokia 313 Fairchild Drive Mountain View, CA 94043 USA Phone: +1-650-625-2986 EMail: charles.perkins@nokia.com Kim, et al. Expires September 5, 2007 [Page 15] Internet-Draft DYMO-low March 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 September 5, 2007 [Page 16]