Mobile IPv6 Working Group Rajeev Koodli INTERNET DRAFT Nokia Research Center 27 February 2006 Syam Madanapalli Samsung FMIPv6 Usage with DNA Protocol draft-ietf-dna-fmip-00.txt 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 document is a submission of the IETF DNA WG. Comments should be directed to the DNA WG mailing list, dna@eng.monash.edu.au. Abstract In this document, we describe how the Fast Mobile IPv6 Handovers (FMIPv6) protocol can work where DNA protocol support is available, but the neighborhood information, which is part of the FMIPv6 operation, is not available. Koodli Expires 27 August 2006 [Page i]
Internet Draft FMIPv6 and DNA Usage 27 February 2006 Contents Abstract i 1. Introduction 1 2. FMIPv6 Operating Modes 2 3. FMIPv6 with DNA 2 4. Protocol Operation 3 5. IANA Considerations 4 6. Security Considerations 4 Intellectual Property Statement 4 Disclaimer of Validity 5 Copyright Statement 5 Acknowledgment 5 1. Introduction The Fast Handovers for Mobile IPv6 [1] defines a protocol to reduce delay and packet loss from IP protocol operations during a handover. These protocol operations include movement detection, IP configuration and location update with a distant mobility agent such as a Home Agent. When route optimization is used, the location update could be higher. The FMIPv6 protocol is designed to effectively eliminate the delays due to movement detection and IP configuration latencies, while disengaging the location update latency from the time-critical path so that applications such as Voice over IP are provided real-time mobility support. The Detecting Network Attachment (DNA) WG is designing protocols to quickly detect movement and establish IP connectivity as soon as a mobile node is attaches to a new subnet. DNA protocols provide faster and reliable mechanisms for determining the link identity and router discovery on the new subnet. A DNA host uses the link identifier or landmark to check for the subnet change. DNA routers provide FastRA without Random Delay for hosts to discover new router address and prefixes on the subnet. A host implementing DNA Koodli Expires 27 August 2006 [Page 1]
Internet Draft FMIPv6 and DNA Usage 27 February 2006 mechanisms determines the subnet change and configures new care of address significantly faster than non-DNA (unmodified) hosts on networks with DNA support. The purpose of this document is to illustrate how the FMIPv6 protocol could make use of the DNA protocol to retain the desired handover performance in certain circumstances. In order to do that, some background on the two operating modes of the FMIPv6 protocol is necessary. 2. FMIPv6 Operating Modes The FMIPv6 protocol can effectively eliminate the movement detection and IP configuration latencies when knowledge of the neighborhood access points and their subnet affiliation is available. For instance, a Mobile Node can query its access router to provide the subnet prefix, IP address and MAC address of a target router attached to a neighboring access point. With this information, it builds a neighborhood map of Access Point Identifier to Access Router Information. So, a conceptual neighborhood data structure consists of [AP-ID, AR-Info] tuples, with each AR-Info structure consisting of a router's IP address, MAC address and subnet prefix corresponding to the interface to which the Access Point is attached to. Such a neighborhood data structure serves two purposes: First, it allows a MN to map an association to a new radio connection to subnet information immediately, which allows it to bypass router discovery. Second, it allows a MN to use a new IP address on the new subnet link immediately, which allows it to send data packets immediately. There are two modes of operation assuming neighborhood information. In the "predictive mode", a MN is able to effect a local route update before departing from its current link. That is, a MN updates its access router's route table to forward packets to the new IP address before the MN departs the current link. In the "reactive" mode, the MN effects such a route update after it regains radio connectivity on the new link. In both the cases, the latencies due to movement detection and IP configuration are eliminated. In some cases however, neighborhood information may not be available. We discuss this in the following section. 3. FMIPv6 with DNA There are scenarios where DNA protocol operation could be beneficial for FMIPv6. For instance, an access network may not be able to provide neighborhood information for whatever reasons, or a MN may end up on an unanticipated Access Point for which it has no neighborhood information available. In another scenario, the Koodli Expires 27 August 2006 [Page 2]
Internet Draft FMIPv6 and DNA Usage 27 February 2006 neighborhood information maintained could be marked as stale using some measure. Under these scenarios, if DNA protocol is available, it can expedite FMIPv6 handover. When a MN with no neighborhood information regains link connectivity, it performs DNA movement detection to verify roaming to a new subnet. If it has moved to a new subnet, it performs DNA router discovery to learn new subnet prefix and router addresses. Subsequently, it runs Optimistic DAD [], and sends the FMIPv6 Fast Binding Update (FBU) message to its previous access router. This special-case of reactive handover is expected to be faster than having to perform these operations in the absence of DNA protocol enhancements. 4. Protocol Operation The following are the steps that take place when an MN with no neighborhood information attaches to an AP. 1. MN (re)associates with an Access Point (AP) and gets the AP-ID (BSSID) 2. The MN Looks for [AP-ID, AR info] Tuple and corresponding FMIPv6 state. If [AP-ID AR info] is available, MN proceeds with the rest of the FMIPv6 protocol. If the tuple info is not available, it invokes the DNA protocol (see below). 3. The MN sends a Router Solicitation with DNA options (if any) to determine if there is a subnet change and to acquire new prefixes on the subnet. 4. The MN receives a Fast Router Advertisement, determines change in subnet, configures new care of address and makes the address optimistic [2]. 5. The MN sends a Fast Binding Update (FBU) to the Previous Access Router (PAR) directly without being encapsulated in FNA. 6. The PAR should send a Handover Initiate (HI) message to the New Access Router (NAR). 7. The NAR should send a Handover Acknowledge (HAck) message to the PAR. 8. The PAR sends a Fast Binding Acknowledgement (FBack) message to the MN on the new link. 9. The PAR starts tunneling the packets to the MN's new CoA. Koodli Expires 27 August 2006 [Page 3]
Internet Draft FMIPv6 and DNA Usage 27 February 2006 5. IANA Considerations There are no IANA considerations introduced by this draft. 6. Security Considerations This draft is informational. Nevertheless, the security considerations of the FMIPv6 protocol and the DNA protocol must be taken into account. For instance, the FBU message mentioned above needs to be protected using a security association between the MN and the PAR. Similar considerations apply for the DNA protocol. References [1] R. Koodli (Editor). Fast Handovers for Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-mipshop-fast-mipv6-03.txt, October 2005. [2] N. Moore. Optimistic DAD for IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-iesg-http-cookies-02.txt, February 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. Koodli Expires 27 August 2006 [Page 4]
Internet Draft FMIPv6 and DNA Usage 27 February 2006 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 (2006). 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. Koodli Expires 27 August 2006 [Page 5]
