MIPSHOP Working Group Heejin Jang Internet-Draft Samsung AIT Intended status: Informational Junghoon Jee Expires: March 3, 2008 ETRI Youn-Hee Han KUT Soohong Daniel Park Samsung Electronics Jaesun Cha ETRI August 31, 2007 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks draft-ietf-mipshop-fh80216e-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 March 3, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Jang, et al. Expires March 3, 2008 [Page 1] Internet-Draft FMIPv6 over 802.16e August 2007 Abstract This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the 802.16e suite of specifications. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IEEE 802.16e Handover Overview . . . . . . . . . . . . . . . . 6 4. Network Topology Acquisition and Network Selection . . . . . . 8 5. Interaction between FMIPv6 and IEEE 802.16e . . . . . . . . . 9 5.1. Access Router Discovery . . . . . . . . . . . . . . . . . 9 5.2. Handover Preparation . . . . . . . . . . . . . . . . . . . 9 5.3. Handover Execution . . . . . . . . . . . . . . . . . . . . 10 5.4. Handover Completion . . . . . . . . . . . . . . . . . . . 10 6. The Examples of Handover Scenario . . . . . . . . . . . . . . 11 6.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 11 6.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 12 7. Consideration for the prefix management . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Jang, et al. Expires March 3, 2008 [Page 2] Internet-Draft FMIPv6 over 802.16e August 2007 1. Introduction Mobile IPv6 (MIPv6) [RFC3775] is currently available to provide the session continuity during handover. It is capable of handling IP handover between different subnets in a transparent way for higher- level connections. However, the handover latency resulting from MIPv6 is often unacceptable to real-time traffic such as Voice over IP, and Mobile IPv6 Fast Handover protocol (FMIPv6) [RFC4068] has been proposed as a mechanism to reduce the handover latency by predicting and preparing the impending handover in advance. As [RFC4260] pointed out, FMIPv6 assumes the support from the link- layer technology, but the specific link-layer information available, as well as the timing of its availability (before, during or after a handover occurs), differs according to the particular link-layer technology in use. This document is proposed to provide informational guide to the developers about how to optimize the FMIPv6 handover procedure in the 802.16 networks for seamless handover. This document introduces a set of useful messages among primitives proposed by IEEE 802.21 which can be cooperated with 802.16 handover and FMIPv6 procedures, and provides the most appropriate timing for the trigger of each selected primitive during 802.16 handover procedure. We begin with a summary of a handover procedure of [802.16e] which is the amendment of 802.16 for mobility. Then the interaction between 802.16e and FMIPv6 is presented with the primitives proposed by IEEE 802.21 [802.21] for the close interaction between Layer 2 and Layer 3. Lastly, the examples of handover scenario are described for both predictive mode and reactive mode. Jang, et al. Expires March 3, 2008 [Page 3] Internet-Draft FMIPv6 over 802.16e August 2007 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document is to be interpreted as described in [RFC2119]. Most of terms used in this document are defined in MIPv6 [RFC3775] and FMIPv6 [RFC4068]. The following terms come from IEEE 802.16e specification [802.16e]. MOB_NBR-ADV An IEEE 802.16e neighbor advertisement message sent periodically by a base station. MOB_MSHO-REQ An IEEE 802.16e handover request message sent by a mobile node. MOB_BSHO-RSP An IEEE 802.16e handover response message sent by a base station. MOB_BSHO-REQ An IEEE 802.16e handover request message sent by a base station. MOB_HO-IND An IEEE 802.16e handover indication message sent by a mobile node. BSID An IEEE 802.16e base station identifier. Additionally, the following primitives are proposed by [802.21] and the standardization is in progress. Link_Detected (LD) A trigger from the link layer to the IP layer in a mobile node to report that a new link is detected. Jang, et al. Expires March 3, 2008 [Page 4] Internet-Draft FMIPv6 over 802.16e August 2007 Link_Handover_Imminent (LHI) A trigger from the link layer to the IP layer in a mobile node to report that a native link layer handover/switch decision has been made and its execution is imminent. Link_Up (LUP) A trigger from the link layer to the IP layer in a mobile node to report that the mobile node completes the link layer connection establishment with a new BS. Handover_Commit (HC) A control command from the IP layer to the link layer in a mobile node in order to force the mobile node to switch from an old BS to a new BS. Jang, et al. Expires March 3, 2008 [Page 5] Internet-Draft FMIPv6 over 802.16e August 2007 3. IEEE 802.16e Handover Overview Compared with the handover in the wireless LAN, the 802.16e handover mechanism consists of more steps since 802.16e embraces the functionality for elaborate parameter adjustment and procedural flexibility. When a mobile node (MN) stays in a link, it listens to L2 neighbor advertisement messages, named a MOB_NBR-ADV, from its serving base station (BS). A BS broadcasts them periodically to identify the network and announces the characteristics of neighbor BSs. Once receiving this, the MN decodes this message to find out information about the parameters of neighbor BSs for its future handover. With the provided information in a MOB_NBR-ADV, the MN may minimize the handover latency by obtaining the channel number of neighbors and reducing the scanning time, or may select the better target BS based on the signal strength, QoS level, service price, etc. The handover procedure is conceptually divided into two steps: ``handover preparation'' and ``handover execution'' [SH-802.16e]. The handover preparation can be initiated by either MN or BS. During this period, neighbors are compared by the metrics such as signal strength or QoS parameters and a target BS is selected among them. If necessary, the MN may try to associate (initial ranging) with candidate BSs to expedite a future handover. Once the MN decides handover, it notifies its intent by sending a MOB_MSHO-REQ message to the serving BS. The BS then replies with a MOB_BSHO-RSP containing the recommended BSs to the MN after negotiating with candidates. Optionally it may confirm handover to the target BS over backbone when the target is decided. The BS alternatively may trigger handover with a MOB_BSHO-REQ message. After handover preparation, handover execution starts. When the MN is about to move to the new link after deciding the target BS, it sends a MOB_HO-IND message to the serving BS as a final indication for its handover. Once the MN makes a new attachment, it conducts 802.16e ranging through which it can acquire physical parameters from the target BS, tuning its parameters to the target BS. After ranging with the target BS successfully, the MN negotiates basic capabilities such as maximum transmit power, modulator/demodulator type, etc. It then performs authentication and key exchange procedure, and finally registers with the target BS. If the target BS has already learned some contexts such as authentication or capability parameters through backbone, it may omit the corresponding procedures. For the detailed procedure of the 802.16 network entry, refer to section 6.3.22 of [802.16e]. After completing registration, the target BS starts to serve the MN and communication via target BS is available. However, when the MN moves to a different subnet, it should re-configure a new Jang, et al. Expires March 3, 2008 [Page 6] Internet-Draft FMIPv6 over 802.16e August 2007 IP address and re-establish IP connection. To resume the active session of previous link, the MN should perform IP layer handover additionally. Jang, et al. Expires March 3, 2008 [Page 7] Internet-Draft FMIPv6 over 802.16e August 2007 4. Network Topology Acquisition and Network Selection This section describes how discovery of adjacent networks and selection of target network work in 802.16e for background information. An MN can learn the network topology and acquire the link information in two ways. One method is via L2 neighbor advertisements. A BS supporting mobile functionality shall broadcast a MOB_NBR-ADV message including the network topology periodically (maximum interval, 1sec.). This message includes BSIDs and channel information of neighbor BSs, and is used to facilitate the MN's synchronization with neighbor BSs. An MN can collect the necessary information of the neighbor BSs through this message for its future handover. Another method for acquisition of network topology is scanning, which is the process to seek and monitor available BSs in order to find suitable handover targets. While a MOB_NBR-ADV message includes static information about neighbor BSs, scanning provides rather dynamic parameters such as link quality parameters. Since the MOB_NBR-ADV message delivers a list of neighbor BSIDs periodically and scanning provides a way to sort out some adequate BSs, it is recommended that when new BSs are found in the advertisement, the MN identifies them via scanning and resolves their BSIDs to the information of the subnet where the BS is connected. The association, an optional initial ranging procedure occurring during scanning, is one of the helpful methods to facilitate the impending handover. The MN is able to get ranging parameters and service availability information for the purpose of proper selection of the target BS and expediting a potential future handover to it. The detailed explanation of association is described in section 6.3.22 of [802.16e]. After learning about neighbors, the MN may compare them to find a BS which can serve better than the serving BS. The target BS may be determined by considering various criteria such as required QoS, cost, user preference, policy, etc. How to select the target BS is not in the scope of this document. Jang, et al. Expires March 3, 2008 [Page 8] Internet-Draft FMIPv6 over 802.16e August 2007 5. Interaction between FMIPv6 and IEEE 802.16e In this section, we describe the desirable FMIPv6 handover procedure in 802.16 networks. We introduce four primitives proposed by [802.21] for the close interaction between FMIPv6 and 802.16e, and present the detailed interaction procedure. 5.1. Access Router Discovery Once a new BS is detected through the reception of a MOB_NBR-ADV and scanning, an MN may try to learn the associated AR information as soon as possible. In order to enable quick discovery of the associated AR information in the IP layer, the link layer (802.16) triggers a Link_Detected primitive to the IP layer (FMIPv6) on detecting the new BS. Receiving the Link_Detected from the link layer, the IP layer tries to learn the associated AR information by exchanging the RtSolPr (Router Solicitation for Proxy Advertisement) and the PrRtAdv (Proxy Router Advertisement) with the PAR. The result of resolving BSIDs is a list of [BSID, AR-Info] tuple(s). AR-Info consists of AR's prefix, IP address and link layer address. 5.2. Handover Preparation As mentioned in section 4, an MN initiates handover by sending a MOB_MSHO-REQ to the BS and receives a MOB_BSHO-RSP from the BS as a response. Alternatively, the BS can initiate handover by sending a MOB_BSHO-REQ to the MN. After receiving either MOB_BSHO-RSP or MOB_BSHO-REQ message, the MN sends an FBU (Fast Binding Update) to the PAR. When the response, an FBack message, arrives at the MN, the Link_Handover_Imminent (LHI) is used to signal the IP layer of the arrival of MOB_BSHO-REQ/MOB_BSHO-RSP in the link layer as soon as possible. According to [802.21], the LHI primitive is used to report that a native link layer handover/switch decision has been made and its execution is imminent. At this time, the target network decided in the link layer is notified to the IP layer by using the MAC_access_router parameter (MAC address of the target AR) of the LHI primitive. On receiving the LHI, the IP layer sends an FBU to the PAR. Before sending an FBack (Fast Binding Acknowledgement) to the MN, the PAR sets up tunnel between PCoA (Previous CoA) and NCoA (New CoA) by exchanging HI (Handover Initiate) and HAck (Handover Acknowledge) messages with the NAR, and forwards the packets destined for the MN to NCoA. During this time, an available NCoA is confirmed with a HAck message. Jang, et al. Expires March 3, 2008 [Page 9] Internet-Draft FMIPv6 over 802.16e August 2007 After the MN sends a MOB_HO-IND to the serving BS, data packet transfer between MN and BS is not allowed any more. Therefore, if possible, the MN should exchange an FBU and an FBack message with the PAR before sending a MOB_HO-IND to the BS so as to operate in predictive mode. 5.3. Handover Execution When an FBack message arrives before handover, an MN runs in predictive mode. If the MN can not acquire an FBack message on the current link, it should run in reactive mode after handover. Note that when a MOB_HO-IND is sent before an FBack arrives, the MN will operate in reactive mode because the serving BS releases MN's all connections and resources after it receives a MOB_HO-IND. The BS may retain the resource until the resource retain timer expires. When an FBack message arrives, a Handover_Commit (HC) may be issued from the IP layer to the link layer optionally so as to promote the issue of MOB_HO-IND message immediately. Until the HC occurs, the link-layer keeps the current link if possible and postpone sending a MOB_HO-IND message as long as possible to operate in predictive mode. Similar concept has already introduced for the wireless LAN in [I-D.irtf-mobopts-l2-abstractions]. An HC is also a command service provided by [802.21]. After switching links, the MN synchronizes with the target BS and performs the 802.16e network entry procedure. The MN exchanges the RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP and REG-REQ/RSP messages with the target BS. Some of these messages may be omitted if the (previously) serving BS transferred the context to the target BS over the backbone beforehand. When the network entry procedure is completed and the link layer is ready for data transmission, it informs the IP layer of the fact with a Link_Up (LUP) primitive, forcing the IP layer to send an FNA (Fast Neighbor Advertisement) to the NAR. In case of reactive mode, the MN should include an FBU within an FNA message. 5.4. Handover Completion When an MN establishes link connectivity with the NAR, it sends an FNA message to the NAR. When an NCoA in the FNA is acceptable, in predictive mode, the NAR stops defending the NCoA and delivers the buffered packets to the MN. In reactive mode, the MN sends the FNA containing the FBU. If the NAR detects the NCoA is already in use, it MUST discard the FBU and reply with Router Advertisement with Neighbor Advertisement Acknowledge (NAACK) option to the MN. Otherwise, the NAR forwards the inner FBU to the PAR, establishes the tunnel, and finally delivers packets destined for the NCoA to the MN. Jang, et al. Expires March 3, 2008 [Page 10] Internet-Draft FMIPv6 over 802.16e August 2007 6. The Examples of Handover Scenario In this section, the recommended handover procedure over 802.16 network is shown for both predictive mode and reactive mode. 6.1. Predictive Mode The procedure is described briefly as follows. 1. A BS broadcasts a MOB_NBR-ADV periodically. 2. If an MN discovers a new neighbor BS in this message, it may perform scanning for the BS. 3. When a new BS is found through the MOB_NBR-ADV and scanning, the MN's link layer notifies it to the IP layer (FMIPv6) by a Link_Detected primitive. 4. Then the MN tries to resolve the new BS's BSID to the associated AR by exchange of RtSolPr and PrRtAdv messages with the PAR. 5. The MN initiates handover by sending a MOB_MSHO-REQ message to the BS and receives a MOB_BSHO-RSP from the BS. Alternatively, the BS may initiate handover by sending a MOB_BSHO-REQ to the MN. 6. When the MN receives either MOB_BSHO-RSP or MOB_BSHO-REQ from the BS, its link layer triggers a Link_Handover_Imminent primitive to the IP layer. 7. On reception of a Link_Handover_Imminent, the MN's IP layer sends an FBU message to the PAR. If the PAR receives this, it establishes tunnel with the NAR by exchange of HI and HAck messages. During this time, the NAR confirms NCoA availability in the new link via HAck. 8. The MN receives an FBack message before its handover and operates in predictive mode after handover. It sends a MOB_HO-IND message as a final indication of handover. Issue of a MOB_HO-IND may be promoted by using a Handover_Commit command from the IP layer. Jang, et al. Expires March 3, 2008 [Page 11] Internet-Draft FMIPv6 over 802.16e August 2007 9. The MN conducts handover to the target BS and performs 802.16e network entry procedure. 10. As soon as the network entry procedure is completed, the MN's link layer signals the IP layer with a Link_Up and the MN issues an FNA to the NAR. 11. When the NAR receives the FNA from the MN, it delivers the buffered packets to the MN. ---------- ---------- MN L3 MN L2 | s-BS PAR | | NAR t-BS | ---------- ---------- | | | | | | 1-2. | |<---MOB_NBR-ADV & Scan--| | | | 3. |<-LD--| | | | | 4. |--------------(RtSolPr)-------------->| | | |<--------------PrRtAdv----------------| | | | | | | | | 5. | |------MOB_MSHO-REQ----->| | | | | |<-----MOB_BSHO-RSP------| | | | | | or | | | | | |<-----MOB_BSHO-REQ------| | | | 6. |<-LHI-| | | | | 7. |------------------FBU---------------->| | | | | | |-----HI---->| | | | | |<---HACK----| | |<-----------------FBack---------------|--> | | 8. |(HC)->|-------MOB_HO-IND------>| forward pkt=====>| | disconnect| | | | | connect | | | | | 9. | |<-------------802.16 network entry---------------->| 10. |<-LUP-| | | | | |-------------------------FNA---------------------->| | 11. |<=============================================deliver pkt | | | | | | Figure 3. Predictive Fast Handover in 802.16 6.2. Reactive Mode The procedure is described as follows in case of reactive mode. 1.~ 7. The same as the case of predictive Mode. Jang, et al. Expires March 3, 2008 [Page 12] Internet-Draft FMIPv6 over 802.16e August 2007 8. In case the MN cannot receive an FBack message before its handover, it operates in reactive mode after handover. It sends a MOB_HO-IND message as a final indication of handover. 9. The MN conducts handover to the target BS and performs 802.16e network entry procedure. 10. As soon as the network entry procedure is completed, the MN's link layer signals the IP layer with a Link_Up and the MN issues an FNA encapsulating an FBU to the NAR. 11. Receiving the FNA, the NAR verifies the availability of NCoA and forwards the inner FBU to the PAR, establishing the tunnel. If the NAR detects an NCoA is already in use, it MUST discard the FBU and reply with Router Advertisement with NAACK option to the MN. Otherwise, it delivers the packets destined for NCoA to the MN. ---------- ---------- MN L3 MN L2 | s-BS PAR | | NAR t-BS | ---------- ---------- | | | | | | 1-2. | |<---MOB_NBR-ADV & Scan--| | | | 3. |<-LD--| | | | | 4. |--------------(RtSolPr)-------------->| | | |<--------------PrRtAdv----------------| | | | | | | | | 5. | |------MOB_MSHO-REQ----->| | | | | |<-----MOB_BSHO-RSP------| | | | | | or | | | | | |<-----MOB_BSHO-REQ------| | | | 6. |<-LHI-| | | | | 7. |--------FBU----X---> | | | | 8. | |-------MOB_HO-IND------>| | | | disconnect| | | | | connect | | | | | 9. | |<-------------802.16 network entry---------------->| 10. |<-LUP-| | | | | |-------------------------FNA[FBU]----------------->| | 11. | | | |<---FBU-----| | | | | |----FBack-->| | | | | forward pkt=====>| | |<=============================================deliver pkt | | | | | | | Figure 4. Reactive Fast Handover in 802.16 Jang, et al. Expires March 3, 2008 [Page 13] Internet-Draft FMIPv6 over 802.16e August 2007 7. Consideration for the prefix management In some networks with the point-to-point link, each mobile node is assigned a unique IPv6 prefix. In such networks, it needs a way for the PAR to provide each MN with the prefix available on the target networks without the scalability problem. But there can be several ways of achieving this without modification of [RFC4068]. For example, an NCoA can be enforced by the NAR via a HAck message with code 3 (Handover Accepted, NCoA assigned) which will be finally delivered to the MN in an FBack or via NAACK option. Whatever used, the proposed scheme in this document does not depend on the deployed link model and address management scheme unless they violate the standard FMIPv6. Jang, et al. Expires March 3, 2008 [Page 14] Internet-Draft FMIPv6 over 802.16e August 2007 8. Security Considerations The security consideration of the FMIPv6 specification [RFC4068] is applicable to this document. Particularly, 802.16e architecture supports a number of mandatory authentication mechanisms, for example, EAP-TTLS, EAP-SIM and EAP-AKA, as well as, secure IP address management between the MN and its network entity. That will allow secure handover operation between the MN and the network entity. Jang, et al. Expires March 3, 2008 [Page 15] Internet-Draft FMIPv6 over 802.16e August 2007 9. Acknowledgment Many thanks IETF Mobility Working Group members of KWISF (Korea Wireless Internet Standardization Forum) for their efforts on this work. In addition, we would like to thank Alper E. Yegin, Jinhyeock Choi, Rajeev Koodli, Soininen Jonne, Gabriel Montenegro, Singh Ajoy, Yoshihiro Ohba and Behcet Sarikaya who have provided the technical advice. Jang, et al. Expires March 3, 2008 [Page 16] Internet-Draft FMIPv6 over 802.16e August 2007 10. Normative References [I-D.irtf-mobopts-l2-abstractions] Teraoka, F., "Unified L2 Abstractions for L3-Driven Fast Handover", draft-irtf-mobopts-l2-abstractions-04 (work in progress), August 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", RFC 4260, November 2005. [802.16e] IEEE 802.16 TGe Working Document, "Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1", IEEE Std 802.16e¢â-2005 and IEEE Std 802.16¢â-2004/ Cor 1-2005, February 2006. [802.21] IEEE 802.21 Working Group Document,"Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE P802.21/D07.00, July 2007. [SH-802.16e] Kim, K., Kim, C., and T. Kim, "A Seamless Handover Mechanism for IEEE 802.16e Broadband Wireless Access", International Conference on Computational Science, vol. 2, pp. 527-534, 2005. Jang, et al. Expires March 3, 2008 [Page 17] Internet-Draft FMIPv6 over 802.16e August 2007 Authors' Addresses Heejin Jang Samsung Advanced Institute of Technology P.O. Box 111 Suwon 440-600 Korea Email: heejin.jang@samsung.com Junghoon Jee Electronics and Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejon 305-350 Korea Email: jhjee@etri.re.kr Youn-Hee Han Korea University of Technology and Education Email: yh21.han@gmail.com Soohong Daniel Park Samsung Electronics 416 Maetan-3dong, Yeongtong-gu Suwon 442-742 Korea Email: soohong.park@samsung.com Jaesun Cha Electronics and Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejon 305-350 Korea Email: jscha@etri.re.kr Jang, et al. Expires March 3, 2008 [Page 18] Internet-Draft FMIPv6 over 802.16e August 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). Jang, et al. Expires March 3, 2008 [Page 19]