MOBOPTS Y. Cui Internet-Draft K. Xu Expires: January 12, 2006 J. Wu CERNET H. Deng Hitachi July 11, 2005 Handover Control Function Based Handover for Mobile IPv6 draft-cui-mobopts-hcf-wlan-00.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 January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document propose a scheme to support MIP6 deployment based on Wireless LAN by extending HMIPv6. The HCF (Handover Control Function) described in this document should record all APs's MAC address, backend AR's address and network prefix of those APs. All MNs will periodically report all AP's MAC address and signal strength Cui, et al. Expires January 12, 2006 [Page 1] Internet-Draft HCF Based Handover for MIPv6 July 2005 information to HCF which MN can probe, then HCF should decide whether or which AP MN shall associate with and notify MN about the new AP/ AR's information, meanwhile, a bi-cast mechanism shall be applied to further improve handover performance by reducing the packet loss during handover. This mechanism can be used in the nationwide university Wireless LAN based MIP6 network deployment to support VoIP and Video Telephony. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Deployment Scenario of HCF Based Handover . . . . . . . . . . 5 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Mobile Node Operation . . . . . . . . . . . . . . . . . . 8 4.2 Handover Control Function Operation . . . . . . . . . . . 8 4.3 Home Agent Operation . . . . . . . . . . . . . . . . . . . 8 4.4 Access Router Operation . . . . . . . . . . . . . . . . . 9 4.5 Correspondent Node Operation . . . . . . . . . . . . . . . 9 5. Mobile IPv6 Extension . . . . . . . . . . . . . . . . . . . . 10 5.1 HCFReq message . . . . . . . . . . . . . . . . . . . . . . 10 5.1.1 AP info options . . . . . . . . . . . . . . . . . . . 11 5.2 HCFRep message . . . . . . . . . . . . . . . . . . . . . . 11 5.2.1 Acess Router information option . . . . . . . . . . . 13 6. HCF Bicast Traffic . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1 Normative References . . . . . . . . . . . . . . . . . . . 18 9.2 Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 20 Cui, et al. Expires January 12, 2006 [Page 2] Internet-Draft HCF Based Handover for MIPv6 July 2005 1. Introduction There are many proposals trying to give the solution for Mobile IPv6 deployment for Wireless LAN network. Especially there are some nationwide Wireless LAN network for the universities and research institutes, they would like to deploy VoIP and Video Telephone based on Mobile IPv6. One important issue is that they can not modify current Access Routers to support Fast handover even just small part of Access Routers. In order to considering VoIP and Video Telephone, the performance of fast handover have to be achieved. This document propose a scheme to support MIP6 deployment based on Wireless LAN by extending HMIPv6. The HCF (Handover Control Function) described in this document should record all APs's MAC address, backend AR's address and network prefix of those APs. All MNs will periodically report all AP's MAC address and signal strength information to HCF which MN can probe, then HCF should decide whether or which AP MN shall associate with and notify MN about the new AP/ AR's information, meanwhile, a bi-cast mechanism shall be applied to further improve handover performance by reducing the packet loss during handover. Before MN handover the new AP/AR, HCF shall notify MN about the new AP/AR's information such as AP's MAC address, AR interface address, and network prefix. Then, MN will configure its new CoA before moving to the new AP. After handover, Layer 2 trigger may be used to support the handover. This protocol defines two mobility options to support communication between MN and HCF. Since HCF decide which AR's interface MN will move to, so the new network prefix of MN will be notified by HCF through HCFRep message. If MN's address is computed using interface indentifier, like EUI64, Duplicated Address Detection can be omitted during handover. Furthermore, recent study reveals that DAD is not _applicable_ to Wireless LAN environment. Therefore, In this protocol, HCF will know MN's new CoA according to MN's old CoA and MN's new network prefix. Under this situation, a bi-casting mechanism can also be applied to further improve handover performance. HCF will act as a extention of MAP in HMIPv6 which shall begin to bi-cast to both MN's old CoA and new CoA after sending HCFRep to MN in order to reduce packet loss during handover. This protocol can be used in the nationwide university Wireless LAN based MIP6 network deployment to support VoIP and Video Telephony. Cui, et al. Expires January 12, 2006 [Page 3] Internet-Draft HCF Based Handover for MIPv6 July 2005 2. Terminology The keywords "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 [1]. In addition, new terms are defined below:: Home Agent (HA) A router on a MN's home link with which the MN has registered its current Care-of address. While the MN is away from home, the HA intercepts packets on the home link destined to the MN's home address, encapsulates them, and tunnels them to the MN's registered Care-of address. Handover Control Function (HCF) A extension of MAP in HMIPv6 which should record all APs's MAC address, backend AR's address and network prefix of those APs. HCF should decide whether or which AP MN shall associate with and notify MN about the new AP/AR's information. Meanwhile, HCF shall split a bi-cast stream to both MN's new CoA and old CoA. Mobile Node (MN) A node that can change its point of attachment from one link to another, while still being reachable via its home address. Access Point (AP) A Layer 2 device connected to an IP subnet that offers wireless connectivity to a MN. An Access Point Identifier (AP-ID) refers the AP's L2 address. Sometimes, AP-ID is also referred to as a Base Station Subsystem ID (BSSID). Access Router (AR) The MN's default router Handover A process of terminating existing connectivity and obtaining new IP connectivity. Bicasting The splitting of a stream of packets destined for a MN via its current HCF(the MAP) into two streams, and the simultaneous transmission of thestreams to old CoA and new CoA. Cui, et al. Expires January 12, 2006 [Page 4] Internet-Draft HCF Based Handover for MIPv6 July 2005 3. Deployment Scenario of HCF Based Handover The following Figure gives the topology layout about how to deploy this protocol (HCF Based handover for Mobile IPv6) for nationwide Mobile IPv6 network deployment based on Wireless LAN. |------------------------------| |---------- | | | | |---| |---| |---| |---| |HA | |HA | |HA | |CN | |---| |---| |---| |---| |-------------------------------------------------------| | | | Internet | | | |-------------------------------------------------------| | | |----| |----| |HCF1| |HCF2| |----| |----| / \ / \ / \ / \ / \ / \ / \ / \ |---| |---| |---| |---| |AR1| |AR2| |AR3| |AR4| |---| |---| |---| |---| /\ | /\ | / \ | / \ | / \ | / \ | | | | | | | |---| |---| |---| |---| |---| |---| |AP1| |AP2| |AP3| |AP4| |AP5| |AP6| |---| |---| |---| |---| |---| |---| / \ / \ / \ /\ /\ /MN\ ------------> /MN\ /----\ /----\ Figure 1: Network Scenario of HCF based handover In this network scenario, there might one AR will connect to multiple APs, those APs might have same network prefix or different network prefix. Cui, et al. Expires January 12, 2006 [Page 5] Internet-Draft HCF Based Handover for MIPv6 July 2005 When MN move from AP2 to AP3, the attached Access Router also change from AR1 to AR2 as well. HCF will has administrative network domain, which can cover many ARs and APs. There are some network deployment scenarios such as University. There are might have one or multiple HCF in one university. If there are more than one HCF in each university, the inter-connection between different HCF will be out of the scope of this document. Cui, et al. Expires January 12, 2006 [Page 6] Internet-Draft HCF Based Handover for MIPv6 July 2005 4. Protocol Operation MN HCF HA | | | |------------------- BU ------------------>| | | | |<------------------ BA -------------------| | | | |------HCFReq-------->| | | | | |<-----HCFRep---------| | | | | Config New CoA | | ....Handover | | Layer 2 trigger | | | | | |------- BU --------->| | |<------ BA ----------| | | |------- BU -------->| | |<------ BA ---------| |<====================== deliver packets | | Figure 2: Protocol for HCF based handover 1. When MN register to HA first time, it will send Bingding Update message to HA, and HA will response with Binding Acknowledgement. 2. After MN probes all Neighbor AP's information, and MinWlanTime is up, MN shall send HCFReq message directly to HCF to report the information of its neighbor AP. 3. After HCF receive the MAPReq message, it will decide whether or which AR/AP MN shall associate with. 4. Detail algorithm for HCF judgement of MN handover mostly is based on the signal strenth MN received from neighbor APs and HCF's network administraing policy. 5. HCF judge MN in some sense which also can help load balance among different ARs and APs, if the number of registered MNs in one AR or AP have over more than the threshold, HCF will not approve MN move to that network. 6. After HCF make decision which AR/AP MN will move to, HCF will notify MN about new AR/AP's information such as link prefix and Cui, et al. Expires January 12, 2006 [Page 7] Internet-Draft HCF Based Handover for MIPv6 July 2005 AR's address. Those information will help MN make a new CoA before it handover. This address also has been known by HCF since new CoA is made based on EUI-64. 7. After MN receive the HCFReq message, it knows which AR/AP it will associate with and will configure its new CoA based on HCFReq message information about new AP/AR. 8. When MN moves from AP2 to AP3, the attached Access Router also change from AR1 to AR2. MN will intensively deassociate with AP2 and associate with AP3. 9. HCF works as an extension of MAP, and will send bicast traffic from HCF to both MN's old CoA and new CoA. Once MN attach AP3/ AR2, those traffic will go directly to MN's new CoA. After receving the new binding update from new CoA, HCF will remove traffic going to old coA. 4.1 Mobile Node Operation Mobile Node will periodically report all neighbor's AP information to HCF by using HCFReq message, and modify its configuration based on informaiton transferred by HCFRep message. And also Mobile Node shall support layer 2 trigger and optimized DAD to support fast handover. 4.2 Handover Control Function Operation HCF should collect all AP's MAC address, and AR's address and network prefix et al. It can be done by network administrators manualy or other solution which is out the scope of this protocol. HCF create a database inside or using LDAP to record those information in other network entities. HCF will decide whether which AP/AR MN will associate with, and will notify the related information of next AR/AP to MN. HCF will be responsible for authenticate and authorize the MN in order to reduce signal burdern in the access network, The HCF acts as a extension of MAP in hierarchical Mobile IPv6, it will bicast the traffic from CN to both old CoA and new CoA. 4.3 Home Agent Operation Home agent will work as Mobile IPv6 specificaiton, it will also accept the registration from HCF as a extension of MAP in HMIPv6. Cui, et al. Expires January 12, 2006 [Page 8] Internet-Draft HCF Based Handover for MIPv6 July 2005 4.4 Access Router Operation There are no specific security association requirement between MN and AR, which shall save signal overhead in the access network side. Meanwhile there exist some scenario, for example, in the university network, access routers are not expected to do any authentication. 4.5 Correspondent Node Operation Correspondent Node will work as Mobile IPv6 specification. Cui, et al. Expires January 12, 2006 [Page 9] Internet-Draft HCF Based Handover for MIPv6 July 2005 5. Mobile IPv6 Extension MN will probe its neighor all AP's information and send these information to HCF using HCFReq message. HCF will select an AP based on those information together with AR's information, and respond a HCFRep message including the MAC address of suggested AP along with some backend AR's information in that link, like network prefix and router address. HCF is an indenpendent entity as MAP in HMIPv6. Messages between HCF and MN are introduced above as HCFReq and HCFRep. These two messages are implemented here as an extension to Mobile IPv6, the format of two new Mobility Messagesare defined as following: 5.1 HCFReq message The HCF Request message uses the MH Type value MH_HCFREQ_TYPE. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP info 1 | . . | AP info 2 | . . . . . . | AP info n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Sequence # A 16-bit unsigned integer used by the receiving node to sequence the HCFReq message and also by the sending node to match a returned HCFRep message with the HCFReq. An outdated HCFRep may be helpless for Mobile Node, and SHOULD be ignored by the Mobile Node which sent out the HCFReq message. Cui, et al. Expires January 12, 2006 [Page 10] Internet-Draft HCF Based Handover for MIPv6 July 2005 Number A 8-bit unsigned integer to indicate the number of AP info that are attached below in this message. This field MUST be equal to the actual number of AP info in message, otherwise HCF MUST ignore this HCFReq message. The value of this field MUST be at least 1, or more than one. AP info A HCFReq message could contain more than one AP info options. Detailed description of one AP info option is defined in next subsection: 5.1.1 AP info options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | Strength | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TBD TBD, consider reserved Strength The field is current signal strength received by Mobile Node from this AP. This is a 8-bits unsigned integer which can represent strength level from 0 to 255. Any special computation scheme MAY be used as long as all AP are treated equally. Selection of a particular computation scheme is out of scope of this draft. MAC Address This field is the 48-bits MAC address of the AP. Which is the unique identification of AP known by Mobile Node. 5.2 HCFRep message The HCF Reply message uses the MH Type value MH_HCFREP_TYPE. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Cui, et al. Expires January 12, 2006 [Page 11] Internet-Draft HCF Based Handover for MIPv6 July 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Status | Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AR info 1 | . . | AR info 2 | . . . . . . | AR info n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Sequence # A 16-bit unsigned integer. The Sequence Number in the HCFRep is copied from the Sequence Number field in the HCFReq. It is used by the Mobile Node in matching this HCFRep with an outstanding HCFReq message. Status 8-bit unsigned integer indicating the disposition of the HCFReq message. The following Status values are currently defined: Number A 8-bit unsigned integer to indicate the number of Access Router info that are attached below in this message. This field MUST be equal to the actual number of AR info in message, otherwise HCF MUST ignore this HCFReq message. The value of this field MUST be at least 1, or more than one. AR info A HCFRep message could contain more than one Acess Router info options. Detailed description of one AP info option is define in next subsection: Cui, et al. Expires January 12, 2006 [Page 12] Internet-Draft HCF Based Handover for MIPv6 July 2005 5.2.1 Acess Router information option +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Preference | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC Address This field is the 48-bits MAC address of the AP that HCF suggested. Preference This field is a 8-bits unsigned integer indicating the preference level of AP suggested by HCF. Prefix Length A 8-bits unsigned integer. The value of this field MUST NOT be more than 128, therefore the first bit of this field MUST be 0. This is prefix lenth of access router on the same link with the suggested AP. Prefix A 128-bits IPv6 address prefix of the access router on the same link with the suggested AP. Cui, et al. Expires January 12, 2006 [Page 13] Internet-Draft HCF Based Handover for MIPv6 July 2005 Address A 128-bits IPv6 address of the access router on the same link with the suggested AP. Cui, et al. Expires January 12, 2006 [Page 14] Internet-Draft HCF Based Handover for MIPv6 July 2005 6. HCF Bicast Traffic Here HCF work as a extension of MAP in HMIPv6. After HCF send out HCFRep message, it will trigger MAP to Bi-cast traffic for the MN for a short period to its current location and to new location where HCF suggest MN moving to shortly. HCF Bicasting traffic also removes the timing ambiguity regarding when to start sending traffic for the MN to its new point of attachment followng a Fast Handover. It also saves the MN periods of service disruption in the case of ping-pong movement. Here we refer to the Bi-cast/N-cast draft [7] lifetime mechanism, the HCF MUST create a new binding cache sub-entry (linked to the original entry for the old CoA) for the MN's new CoA. This sub-entry contains the same fields as normal binding cache entries but it MUST not replace any existing entries for the MN. The new sub-entry will have two lifetimes instead of one: the normal new CoA BU lifetime (sent in the BA) and a Bicasting lifetime set to SHORT_BINDING_LIFETIME (sent in the BA sub-option). The new CoA lifetime runs in parallel with the Bicasting lifetime. Until the Bicasting lifetime expires, the HCF MUST send a copy of the data destined for the MN to the old CoA and to the new CoA in the linked binding cache sub-entry or sub- entries. When the Bicasting lifetime expires, the HCF MUST remove the bicasting lifetime field and replace the old binding cache entry for the old CoA with the new CoA sub-entry. As a result, the HCF will end up with one entry for the MN's new CoA with the remaining new CoA lifetime. The default value for SHORT_BINDING_LIFETIME is 2s. This parameter MUST be configurable as it my vary depending on the type of radio link in the system. After HCF received BU from new CoA, old CoA binding is deleted, and new CoA binding kept alive after that There are also two issues similar to [7]: 1. Multiple copies of packets received at AR. 2. Reception of multiple copies in the MN. In this version, Multiple-Casting has not yet been considered. It will be analysized in the future. Cui, et al. Expires January 12, 2006 [Page 15] Internet-Draft HCF Based Handover for MIPv6 July 2005 7. IANA Considerations This document updates the IANA Registry for Mobile IPv6 Mobility Header Types. A new MH type MH_HCFREQ_TYPE is define in section 5.1 of this document to identify new HCFReq message in Mobile IPv6 protocol. A new MH type MH_HCFREP_TYPE is define in section 5.2 of this document to identify new HCFRep message in Mobile IPv6 protocol. Cui, et al. Expires January 12, 2006 [Page 16] Internet-Draft HCF Based Handover for MIPv6 July 2005 8. Security Considerations HCF does not introduce any more security problems than Mobile IPv6 and Hierarchical Mobile IPv6. Same IPSec protection used in Mobile IPv6 signals MUST be used to protect two new messages, HCFReq, HCFRep, in this solution. All messages between MN and HCF MUST be authenticated. This means that the mobile host has to share an authentication key (private or public) with all HCFs it may visit. These keys can be pre-installed manually or obtained dynamically via IKE or AAA servers. Since HCF is an extension to Mobile Anchor Point in HMIPv6. These authentication key SHOULD be the key between MN and MAP as specified in HMIPv6. Cui, et al. Expires January 12, 2006 [Page 17] Internet-Draft HCF Based Handover for MIPv6 July 2005 9. References 9.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. 9.2 Informative References [4] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", draft-ietf-mipshop-80211fh-04 (work in progress), April 2005. [5] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in progress), October 2004. [6] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004. [7] Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-05 (work in progress), November 2003. [8] Jung, H., "Fast Handover for Hierarchical MIPv6 (F-HMIPv6)", draft-jung-mobopts-fhmipv6-00 (work in progress), April 2005. [9] Kempf, J., "Problem Statement for IP Local Mobility", draft-kempf-netlmm-nohost-ps-00 (work in progress), June 2005. Authors' Addresses Yong Cui CERNET Department of Computer Science and Technology Tsinghua University Beijing 100084 China Email: yong@csnet1.cs.tsinghua.edu.cn Cui, et al. Expires January 12, 2006 [Page 18] Internet-Draft HCF Based Handover for MIPv6 July 2005 Ke Xu CERNET Department of Computer Science and Technology Tsinghua University Beijing 100084 China Email: xuke@csnet1.cs.tsinghua.edu.cn Jianping Wu CERNET Department of Computer Science and Technology Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Hui Deng Hitachi Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: hdeng@hitachi.cn Cui, et al. Expires January 12, 2006 [Page 19] Internet-Draft HCF Based Handover for MIPv6 July 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Cui, et al. Expires January 12, 2006 [Page 20]