Network Working Group M-K. Shin Internet-Draft ETRI Expires: May 14, 2008 T. Camilo J. Silva University of Coimbra D. Kaspar ETRI November 11, 2007 Mobility Support in 6LoWPAN draft-shin-6lowpan-mobility-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 May 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Shin, et al. Expires May 14, 2008 [Page 1] Internet-Draft Mobility Support in 6LoWPAN November 2007 Abstract This draft lists mobility scenarios and suggests solutions of how to provide mobility support in IPv6 Low-power Wireless Personal Area Metworks (6LoWPANs). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scenario Considerations . . . . . . . . . . . . . . . . . . . 6 3.1. Device Movement within a Single WPAN Domain . . . . . . . 6 3.2. Device Movement between Multiple WPAN Domains . . . . . . 7 3.3. Single WPAN Movement (NEMO) . . . . . . . . . . . . . . . 8 3.4. MANEMO - Nested NEMO . . . . . . . . . . . . . . . . . . . 9 4. Mobility Support in 6LoWPAN . . . . . . . . . . . . . . . . . 11 4.1. Device Movement within a Single WPAN Domain . . . . . . . 11 4.2. Device Movement between Multiple WPAN DomainsS . . . . . . 11 4.3. Single WPAN movement (NEMO) . . . . . . . . . . . . . . . 14 4.4. MANEMO - Nested NEMO . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Shin, et al. Expires May 14, 2008 [Page 2] Internet-Draft Mobility Support in 6LoWPAN November 2007 1. Introduction A 6LoWPAN is a simple low cost communication network that allows wireless connectivity in applications with limited power and relaxed throughput requirements. A 6LoWPAN typically includes devices that work together to connect the physical environment to real-world applications, e.g., wireless sensors [I-D.ietf-6lowpan-problem]. 6LoWPANs must support various topologies like mesh as well as star. Mesh topologies imply multi-hop routing, to a desired destination. Mesh networks are likely to consist of nodes with a certain degree of mobility. Due to the low performance characteristics of 6LoWPAN devices, mobility support should be provided without high signaling involvement in end devices (e.g., RFD). Also, as recently seen in discussions related to MANEMO (Network mobility for MANET), a similar point was stated regarding network mobility in LoWPAN environments. Fast mobility detection will be a huge challenge and LoWPAN nodes might even change their location while being in state of hibernation. This document presents mobility scenarios and suggests solutions of how to provide mobility support in 6LoWPANs. 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]. 1.2. Terms Used o Reduced-Function Device (RFD): RFDs are intended for applications that are extremely simple, such as a light switch or a passive infrared sensor; they can be implemented using minimal resources and memory capacity. RFDs are not able to transmit MAC layer beacons, and can only communicate with FFDs in a master/slave star topology. RFDs may only associate with a single FFD at a time. o Full-Function Device (FFD): A device implementing the complete protocol set. FFDs have the possibility to send MAC layer beacon frames in order to indicate their presence to other FFDs or RFDs. FFDs can talk to RFDs or other FFDs, while an RFD can talk only to an FFD. o Coordinator-Function Device (CFD): A full-function device (FFD) acting as the principal LoWPAN coordinator, configured to provide synchronization services through the transmission of beacons. The CFD is responsible for unique address allocation. A LoWPAN has Shin, et al. Expires May 14, 2008 [Page 3] Internet-Draft Mobility Support in 6LoWPAN November 2007 exactly one CFD. Shin, et al. Expires May 14, 2008 [Page 4] Internet-Draft Mobility Support in 6LoWPAN November 2007 2. Goals Given the unique low-performance properties of 6LoWPANs, new challenges arise of enabling mobility support to devices with highly reduced memory and power. It is therefore crucial to reduce the additional mobility related signaling overhead or to possibly avoid it altogether. Especially to optimize power consumption, battery- powered devices should be correctly discovered and handled by more capable (and possibly mains-powered) devices in the network, such as the CFD. The fundamental goals for mobility support in 6LoWPANs can be listed as follows: o Mobile 6LoWPAN devices must be addressable by any corresponding node, independent of the current whereabouts. o RFDs should not be involved in any mobility related signaling. o Mobility related signaling for FFDs should be reduced, as much as possible. o Fast handover detection should be supported. o Mobile 6LoWPAN devices should change their location while being in state of hibernation. o Existing mobility protocols should be re-used, if possible. Shin, et al. Expires May 14, 2008 [Page 5] Internet-Draft Mobility Support in 6LoWPAN November 2007 3. Scenario Considerations Low-power WPAN technology is still in its early stage of development, but the range of conceivable usage scenarios is tremendous. The numerous possible applications of sensor networks make it obvious that mesh topologies will be prevalent in LoWPAN environments and mobility support will be a necessity. Mobility based communication can also prolong the lifetime of devices and increase the connectivity between nodes and clusters. Using distributed LoWPANs (i.e. sensor networks), it is possible to sculpt the devices density to cluster around areas of interest, cover large areas, and work more efficiently by filtering local data at the node level before it is transmitted or relayed peer-to-peer. Furthermore, multiple controlled mobile elements can be used to provide load balancing for gathering data. The required mobility is heavily dependent on the individual service scenario and the LoWPAN architecture. This document covers the following scenarios for mobility support in 6LoWPAN. Here are some of the key elements of an IEEE 802.15.4 network. Figure 1 illustrates the key elements of typical mobile 802.15.4 deployments. o Device movement within a single WPAN domain o Device movement between multiple WPAN domains o Single WPAN movement (NEMO) o MANEMO (nested NEMO) 3.1. Device Movement within a Single WPAN Domain Device movement within a single WPAN domain comprehends the change of location of one LoWPAN device without losing connectivity between the CFD/sink-node. Different behaviours can be expected depending on the type of topology used in the LoWPAN. In star topologies, where there is a direct communication between the RFD/FFD and the CFD/sink-node (single-hop), the communication is not affected by the device mobility if the mobile device stays in the radio range of the CFD/ sink-node. Shin, et al. Expires May 14, 2008 [Page 6] Internet-Draft Mobility Support in 6LoWPAN November 2007 +----------------------------+ | FFD | +----+ | |CFD | RFD | +----+ | | FFD | | RFD | | | +----------------------------+ Figure 1: Device mobility within a single WPAN domain In mesh topologies where the communication between the RFD/FFD and the CFD/sink-node is multi-hop the mobility needs to be supported by the routing protocol used within the LoWPAN. In this scenario it is important to distinct the RFD/FFD mobility from the CFD/sink-node mobility. 3.2. Device Movement between Multiple WPAN Domains In this scenario the LoWPAN devices move between different WPAN domains as illustrated in the Fig. 2. By changing from the WPAN1 controlled by the CFD1 to the WPAN2 each device (e.g. RFD and FFD) needs to advertise the CFD2 of its presence in order to receive new interface configurations. Due to the 6LoWPAN devices characteristics it is necessary to adjust exisiting IPv6 mobility protocol to such networks. Moreover it is important to understand that RFD represents several limitations regarding FFD, meaning that each one will have different roles regarding the handover process. +-----------------+ +------------------+ | FFD | | FFD | | +----+ +----+ | | FFD |CFD1| |CFD2| RFD | | +----+ +----+ | | | | | | RFD >---------> RFD | | FFD >---------> FFD | +-----------------+ +------------------+ WPAN1 WPAN2 Figure 2: Device mobility between multiple WPAN domains(1) Another consideration should be made if the moving LoWPAN device is the CFD1. In this case, such device will act as a CFD until he finds another CFD responsible for a new domain. Fig. 3 illustrates the situation when the sink-node (CFD1) moves from his domain to another domain becoming a common FFD, after negotiating with CFD2. The Shin, et al. Expires May 14, 2008 [Page 7] Internet-Draft Mobility Support in 6LoWPAN November 2007 former domain of CFD1 will need to elect a new CFD, in the example the CFD3. +-----------------+ +------------------+ | FFD | | FFD | | +----+ | +----+ | | |CFD3| | |CFD2| RFD | | +----+ | +----+ | | +----+ | | | RFD |CFD1|-------> FFD | | +----+ | | +-----------------+ +------------------+ WPAN1 WPAN2 Figure 3: Device mobility between multiple WPAN domains(2) 3.3. Single WPAN Movement (NEMO) In this scenario we consider the aggregation of nodes (FFDs and RFDs) in clusters, with the introduction of an elected node that will work as a Coordinator Function Device (CFD). This node will be responsible for the management of the cluster communication with the external networks. +----------------------------+ | FFD | +----------+ +----+ | | External |--- |CFD | RFD | | Network | +----+ | +----------+ | FFD | | FFD | | | +----------------------------+ Figure 4: WPAN movement In this section the WPAN is considered indivisible and presents mobility as an entity. Moreover, we consider a mobile WPAN as a leaf network, as it does not carry transit traffic. The CFD must be a FFD, as it requires supplementary functionalities when compared with RFDs, as extra processing and energy power. None of the FFDs and RFDs behind the CFD need to be aware of the WPAN mobility, being its movement completely transparent to those devices inside the mobile WPAN. The protocols that support the WPAN movement are very dependent of the following issues: - Application requirements Shin, et al. Expires May 14, 2008 [Page 8] Internet-Draft Mobility Support in 6LoWPAN November 2007 - Level of mobility of WPAN The level of mobility of the WPAN requires different routing updates. It is crucial that the routing protocol optimizes the traffic routes as the energy consumption is critical in node forwarding. Using the CFD concept is possible to create an architecture that reduces the energy consumed in WPAN movement, and thus increasing performance in these networks. The IPv6 [RFC2460] supports natively the mobility. Moreover, in contrast with IPv4, IPv6 offers extra functionalities for router optimization. However, it presents overheads and the routing is not optimal in the case of network mobility. The Nemo working group [RFC3963] that studies these scenarios, has already proposed a simple solution to transparently solve, part of the present needs. However the applicability to LowPAN networks is not trivial and requires extra adaptability to its limited characteristics. The new challenges in providing mobility for WPANs include resource management, network coverage, network lifetime, topology change, routing protocols, security, data reliability, QoS and timely dissemination. These challenges affect the performance of the mobile WPANs. 3.4. MANEMO - Nested NEMO In these scenarios, terminal devices or WPANs inside a WPAN could present mobility support, travelling to other fixed or mobile WPANs. These entities can move inside or outside high-level WPANs, forming nested entities. Sink node mobility, as a unique entity, was presented as a special case in sections 3.1 and 3.2. +----------------------------+ | FFD | +----------+ +----+ | | Exterior |--- |CFD | RFD | +----------+ +----+ | | FFD | | FFD +--------+ | | | WPAN | | +------+ | +--------+ | | WPAN | | RFD | +------+ +----------------------------+ Figure 5: MANEMO In these scenarios, due to its properties, several issues need to be covered (i.e. route optimization, bandwidth and encapsulation Shin, et al. Expires May 14, 2008 [Page 9] Internet-Draft Mobility Support in 6LoWPAN November 2007 overhead). In nested networks - in more complex scenarios, the problems are more accentuated and need several improvements and adaptations. Even if we use the redirect IPv6 properties [RFC3775], there stills to exist indirection and overhead, which is more critical when there are several hierarchical levels. Among the open research problems, real time solutions that result in low mobile device speeds and cooperation between multiple mobile devices stand out as challenges that have significant impact. Shin, et al. Expires May 14, 2008 [Page 10] Internet-Draft Mobility Support in 6LoWPAN November 2007 4. Mobility Support in 6LoWPAN In this section, some solutions and optimization techniques for each scenario described in section 3 will be discussed. 4.1. Device Movement within a Single WPAN Domain In this scenario, there is no need to additionally define any new mobility protocols. The mobility can be supported by the routing protocol used within the 6LoWPAN. The first choice to achieve this goal is to re-use existing MANET protocols without making any big modifications. (e.g., AODV, OLSR, DYMO, etc.) However, the modification or simplification of existing MANET routing protocols may be required for dynamic routing to be feasible in a LoWPAN domain, because other requirements apply to LoWPAN devices. Unlike MANET devices, LoWPAN nodes are characterized by much lower power supplies, smaller memory sizes, and lower processing power, which create new challenges on obtaining robust and reliable dynamic routing within LoWPANs. There exists a trade-off relationship between routing effectiveness and the requirements posed upon the devices participating in a dynamic network. The challenge is to create a balance between protocol simplicity and routing performance. But stripping down existing protocols to power-aware, low-overhead protocols decreases the efficacy and functionality of their sophisticated routing techniques, or possibly even endangers the goals they were designed for. The issues is being discussed now in [I-D.dokaspar-6lowpan- routreq]. The other way is to develop a new routing protocol for 6LoWPAN. The work is also being discussed in [I-D.culler-rsn-routing-reqs] and is especially focused on sensor networks (e.g., RL2N: Routing For Low Power and Lossy Networks). Considering the variety of sensor based applications, there may not be a single routing protocol satisfying the entire list of requirements, in which case it may be decided to define a limited set of routing protocols that could be combined to satisfy the overall objective. 4.2. Device Movement between Multiple WPAN DomainsS In this scenario, MIPv6 [RFC3775] could be considered for mobility solution. However, as listed in goals, RFDs should not to be involved in any MIPv6 mobility related signaling and mobility signaling messages in FFD should be reduced if possible. To support efficiently this scenario, network-based mobility Shin, et al. Expires May 14, 2008 [Page 11] Internet-Draft Mobility Support in 6LoWPAN November 2007 management approach (e.g., Proxy MIPv6 [I-D.ietf-netlmm-proxymip6]) would be preferred. The goals of network-based mobility management approach [RFC 4831] are: o Handover Performance Improvement o Reduction in Handover-Related Signaling Volume o Location Privacy o Limit Overhead in the Network o Simplify Mobile Node Mobility Management Security by Deriving from IP Network Access and/or IP Movement Detection Security o Link Technology Agnostic o Support for Unmodified Mobile Nodes o Reuse of Existing Protocols Where Sensible o Localized Mobility Management Independent of Global Mobility Management o Configurable Data Plane Forwarding between Local Mobility Anchor and Mobile Access Gateway Almost of the goal above fits to our goals for mobility support in 6LoWPAN described in section 2. Host-based mobility protocols (e.g., MIPv6) require a number of periodic signaling messages (e.g, Binding Update in MIPv6) at end devices. It can increase power consumption. Network-based mobility protocol (e.g., PMIPv6) does not require any mobility protocols in end devices. Instead, gateway (CFD) performs mobility functions (e.g., Proxy BU). At this phase, current PMIPv6 defines the MN-MAG interface applied in a single-hop [I-D.ietf-netlmm-mn-ar-if]. However, in this scenario, multi-hop and wireless mesh topologies should be additionnally considered. So, to use PMIPv6 in 6LoWPAN, the interface for multi- hop and mesh topologies between devices and gateway (CFD) should be extended and defined (e.g., ad-hoc manner, MANET, L2 routing, RL2N support, etc.). Thus, MN-MAG interface extensions for PMIPv6-6LoWPAN as shown in Shin, et al. Expires May 14, 2008 [Page 12] Internet-Draft Mobility Support in 6LoWPAN November 2007 Figure 6. It allows the MAG and/or 6LoWPAN devices to detect network attachment and detachment and forward this detection to the gateway (MAG) using existing MANET, RL2N or L2 (e,g, IEEE 802.15.4) routing, causing the MAG to use the PMIPv6 protocol to update routing at the LMA (Local Mobility Anchor) so that the end sensor node stays reachable when it roams across the WPAN domain. In general, in the absence of a L2 specific mechanisms to implement the 6LoWPAN devices - MAG interface, it is required to have a common interface defined at the L3 layer. Because no PMIPv6 specific software support is assumed to be present on 6LoWPAN devices, this interface has to rely only on standard tracks IPv6 protocols such as ND, DHCP, SEND, and DNA. However, for the interface for multi-hop and mesh topologies between devices and gateway (CFD) existing MANET, RL2N or L2 (e,g, IEEE 802.15.4) routing should be applied. 6LoWPAN-MAG Interface extension | | +------------+ +----------+ | | | | | | +--------+ | | +------+ | | | PMIPv6 |<-------->|PMIPv6| | | | +--------+ | | +------+ | | ^ ^ | | ^ | +----------+ | | | | | | | | | | | v | | | | | | +------+ | | | +-----+ | | | | | | | MANET| | | |MANET| | | | | | | | L2 Rt|<------|------>|L2 Rt| | | | | | | | RL2N | | | |RL2N | | | | | | | +------+ | | +-----+ | | | | | | ^ | | | ^ | | | | | | | | | | | | | | | | v | | | v | | | v | | +------+ | | +----+ | | | +------+ | | | | | | | | |<-+ | | | | | | | | | IPv6 | | | | IPv6 | | | | | | IPv6 |<------|------>|IPv6|<------------>| IPv6 | | | +------+ | | +----+ | | +------+ | | 6LoWPAN | | | | | | | device | | MAG | | LMA | +----------+ | +------------+ +----------+ | Figure 6: 6LoWPAN-MAG interface extensions Shin, et al. Expires May 14, 2008 [Page 13] Internet-Draft Mobility Support in 6LoWPAN November 2007 4.3. Single WPAN movement (NEMO) This scenario is exactly the same as that of NEMO. NEMO support [I-D.ietf-nemo-requirements] is concerned with managing the mobility of an entire network, viewed as a single unit, which changes its point of attachment to the Internet and thus its reachability in the Internet topology. Such a network is referred to as a mobile network and includes one or more mobile routers (MRs) which connect it to the global Internet. So, in this scenario a mobility network and MRs are mapped into WPAN and CFDs, respectively. To support this scenario, basic NEMO support protocol [RFC3963] should be supported in 6LoWPAN. 4.4. MANEMO - Nested NEMO MANEMO is a special case for Nested NEMO. When mobile routers (CFDs) and mobile nodes (RFDs/FFDs) converge at the edge of the Internet using wireless interfaces, they can form a 6LoWPAN network in an ad- hoc fashion and are able to provide Internet connectivity to one another. Several issues exist in this network configuration such as network loop, un-optimized path and multiple exit routers to the Internet. They are well-known MANEMO' issues. While fixed routers provide constantly connectivity, mobile routers (CFDs) can experience intermittent connectivity to the Internet due to their movement. When NEMO Basic Support [RFC3963] is used in this context, network loops naturally occur. So, a new MANEMO solution is required in 6LoWPAN. MANEMO solution is not finalized yet and it is at initial stage. When it is done, to support this scenario, it should be also supported in 6LoWPAN. Shin, et al. Expires May 14, 2008 [Page 14] Internet-Draft Mobility Support in 6LoWPAN November 2007 5. IANA Considerations This document requests no action by IANA. Shin, et al. Expires May 14, 2008 [Page 15] Internet-Draft Mobility Support in 6LoWPAN November 2007 6. Security Considerations RFD nodes must have a means of identifying friendly nodes and distinguishing them from not trusted nodes. Especially if the RFDs' mobility support is handled by an FFD or CFD, there must be some way for the RFD to tell whether that more capable device can be trusted or not. More to be defined. Shin, et al. Expires May 14, 2008 [Page 16] Internet-Draft Mobility Support in 6LoWPAN November 2007 7. Acknowledgements TBD Shin, et al. Expires May 14, 2008 [Page 17] Internet-Draft Mobility Support in 6LoWPAN November 2007 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. 8.2. Informative References [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007. [RFC4886] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007. [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007. [I-D.dokaspar-6lowpan-routreq] Kaspar, D., "Problem Statement, Design Goals and Requirements for 6LoWPAN Mesh Routing", draft-dokaspar-6lowpan-routreq-02 (work in progress), July 2007. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-07 (work in progress), November 2007. [I-D.chakrabarti-mobopts-lowpan-req] Park, S. and S. Chakrabarti, "LowPan Mobility Requirements Shin, et al. Expires May 14, 2008 [Page 18] Internet-Draft Mobility Support in 6LoWPAN November 2007 and Goals", draft-chakrabarti-mobopts-lowpan-req-01 (work in progress), March 2007. [I-D.ietf-netlmm-mn-ar-if] Narayanan, S. and J. Laganier, "Network-based Localized Mobility Management Interface between Mobile Node and Mobility Access Gateway", draft-ietf-netlmm-mn-ar-if-02 (work in progress), May 2007. Shin, et al. Expires May 14, 2008 [Page 19] Internet-Draft Mobility Support in 6LoWPAN November 2007 Authors' Addresses Myung-Ki Shin ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea Phone: +82 42 860 4847 Email: myungki.shin@gmail.com Tiago Camilo University of Coimbra Email: tandre@dei.uc.pt Jorge Sa Silva University of Coimbra Email: sasilva@dei.uc.pt Dominik Kaspar ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea Phone: +82 42 860 1702 Email: dominik@etri.re.kr Shin, et al. Expires May 14, 2008 [Page 20] Internet-Draft Mobility Support in 6LoWPAN November 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). Shin, et al. Expires May 14, 2008 [Page 21]