James Kempf Internet Draft Youngjune L. Gwon Document: draft-kempf-mobileip-postmit-handover-00.txt Daichi Funato Expires: June 2002 Atsushi Takeshita Jonathan Wood Post-handover Mobile Initiated Tunneling for Fast Mobile IPv4 Handover Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract The Mobile IP working group has been considering enhancements that significantly reduce the amount of service disruption involved in Mobile IP handover. The proposals considered by the working group so far are based on having Layer 2 information available prior to the handover that allows the Mobile Node and/or the old Foreign Agent to prepare for handover in some fashion. In this document, an extension of the POSTREG protocol is proposed that allows the Mobile Node to initiate the construction of a bi-directional edge tunnel between the old and new Foreign Agents after Layer 2 handover has been completed. This protocol extends the tunneling technique of POSTREG to mobile-controlled handover. Simulation results indicate that the protocol performs competitively with the two proposed low latency protocols, PREREG and POSTREG, and that it is better than standard Mobile IPv4. Table of Contents Kempf, J., et. al Individual [Page 1] Internet Draft Posthandover Tunneling December, 2001 1.0 Introduction...............................................2 2.0 Layer 2 Requirements.......................................2 3.0 The Protocol...............................................3 4.0 Simulation Results.........................................3 5.0 References.................................................4 6.0 Author's Contact Information...............................4 7.0 IPR Statement..............................................5 1.0 Introduction The Mobile IP working group has been considering enhancements that significantly reduce the amount of service disruption involved in Mobile IPv4 handover [1]. The proposals considered by the working group so far [2] are based on having Layer 2 information available prior to the handover that allows the Mobile Node and/or the old Foreign Agent to prepare for handover in some fashion. Two approaches have been proposed, PREREG and POSTREG. PREREG allows the Mobile Node to initiate the handover by signaling the old Foreign Agent over the radio link, while POSTREG allows the old Foreign Agent to initiate the handover without any radio link signaling. POSTREG constructs a bi-directional edge tunnel between the old and new Foreign Agents, so that the Mobile Node need not change its Care-of Address on the new Foreign Agent until user traffic has decreased, thus minimizing any further disruption due to Home Agent registration. PREREG requires that the Mobile Node change its Care-of Address. It would be desirable to have a protocol that allowed the Mobile Node to initiate handover but did not require the Mobile Node to change its Care-of Address. Such a proposal would also allow use of the minimal amount of information from Layer 2, but still achieve optimization over standard Mobile IPv4 handover. In this document, an extension of the POSTREG protocol is proposed that allows the Mobile Node to initiate the construction of a bi- directional edge tunnel between the old and new Foreign Agents after Layer 2 handover has been completed. The extension is called Post-handover Mobile Initiated Tunneling (POST-MIT). The tunnel enables the Mobile Node to continue receiving real time traffic without the disruption of having to register with the Home Agent until it is ready. Or, the Mobile Node can initiate registration with the Home Agent immediately. Simulation results are presented indicating that the protocol performs competitively with the two proposed low latency protocols, PREREG and POSTREG, and that it is better than standard Mobile IPv4. 2.0 Layer 2 Requirements The only Layer 2 requirement for POST-MIT is that the Mobile Node receives a Link Up trigger when it arrives on the link with the new Foreign Agent. The Link Up trigger allows the Mobile Node to quickly initiate signaling with the new Foreign Agent to start the Kempf, J., et. al Individual [Page 2] Internet Draft Posthandover Tunneling December, 2001 process of tunnel establishment. The Link Up trigger need contain no parameters. See [4] for more information on L2 triggers. 3.0 The Protocol Upon receipt of the Link Up trigger, the Mobile Node sends a Solicitation for Foreign Agent Advertisement (SolFAAdv) exactly as described in [1] for standard Mobile IPv4. However, the SolFAAdv contains a LLA extension [2] with the IP address of the old Foreign Agent. The Mobile Node initiates sending packets opportunistically, as soon as it has sent the SolFAAdv. The new Foreign Agent is free to drop the packets or buffer them until it receives confirmation from the old Foreign Agent before routing them further. Upon receipt of the SolFAAdv, the new Foreign Agent sends a Handoff Request to the old Foreign Agent, as if it had received a target trigger. The old Foreign Agent replies with a Handoff Reply, and begins tunneling packets to the new Foreign Agent. The new Foreign Agent then sends the Foreign Agent Advertisement back to the Mobile Node, and delivers packets to/from the Mobile Node. If the old Foreign Agent denies the handoff, the new Foreign Agent indicates that the registration is denied in the Foreign Agent Advertisement sent back to the Mobile Node, and drops any buffered packets from the Mobile Node. The following figure illustrates the messaging. 3) HRply +------+ -------> +------+ | oFA | | nFA | +------+ <------- +------+ 2) HRqst | ^ | | 4) FAAdv | | 1) SolFAAdv + IP addr of oFA | | | | V | +------+ | MN | +------+ 4.0 Simulation Results Table 1 contains results comparing POST-MIT with PREREG, POSTREG, and standard MIPv4 (SMIPv4) handover. The simulation framework is described in [3], from which these numbers were taken. The SMIPv4 implementation makes use of a Link Up trigger to optimize sending of the SolFAAdv, like POST-MIT. The data in the table were taken for a 300 kbps simulated wireless link with a latency of 10 ms per radio frame. The pre-trigger latency was tuned for PREREG to get optimal performance. For each protocol, the Layer 2 handover Kempf, J., et. al Individual [Page 3] Internet Draft Posthandover Tunneling December, 2001 latency was fixed and the total handover latency for the protocol was measured. For POST-MIT, the new Foreign Agent began routing packets as soon as it received the SolFAAdv. As the table shows, POST-MIT total handover latency is competitive with PREREG and POSTREG, and better than SMIPv4. Layer 2 Handover Latency POSTREG PREREG POST-MIT SMIPv4 --------- ------- ------ -------- ------ 20 ms 32 ms 42 ms 35 ms 68 ms 40 ms 56 ms 60 ms 60 ms 80 ms 80 ms 92 ms 98 ms 102 ms 120 ms 200 ms 214 ms 218 ms 220 ms 240 ms Table 1 - Total Handover Latency for Mobile IPv4 Protocol [3] 5.0 References [1] Perkins, C., ôIP Mobility Support,ö RFC 2002, October 1996. [2] El Malki, K., et al., ôLow Latency Handoffs in Mobile IPv4,ö draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt (work in progress), October 2001. [3] Kempf, J., Wood, J., and Frascone, D., "Analysis and Comparison of Mobile IPv4 Handoff Algorithms," to be submitted to Mobicomm 2002. [4] Kempf, J., editor, " Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems," draft- manyfolks-l2-mobilereq-04.txt, a work in progress. 6.0 Author's Contact Information James Kempf DoCoMo Communications Labs USA 181 Metro Drive San Jose, CA 94043 Phone: 408-451-4711 Email: kempf@docomolabs-usa.com Youngjune L. Gwon DoCoMo Communications Labs USA 181 Metro Drive San Jose, CA 94043 Kempf, J., et. al Individual [Page 4] Internet Draft Posthandover Tunneling December, 2001 Phone: 408-451-4734 Email: gyj@docomolabs-usa.com Daichi Funato DoCoMo Communications Labs USA 181 Metro Drive San Jose, CA 94043 Phone: 408-451-4736 Email: funato@docomolabs-usa.com Atsushia Takeshita DoCoMo Communications Labs USA 181 Metro Drive San Jose, CA 94043 Phone: 408-451-4705 Email: takeshita@docomolabs-usa.com Jonathan Wood DoCoMo Communications Labs USA 181 Metro Drive San Jose, CA 94043 Phone: 408-451-4746 Email: wood@docomolabs-usa.com 7.0 IPR Statement DoCoMo Communications Laboratories USA, Inc. (DoCoMo USA Labs) hereby declares that it is in conformity with Section 10 of RFC 2026. Contributions of DoCoMo USA Labs may contain one or more patents or patent applications. To the extent that the contribution of DoCoMo USA Labs is adopted to the specification, DoCoMo USA Labs undertakes to license patents technically necessary to implement the specification on fair, reasonable and nondiscriminatory terms based on reciprocity. 8.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, Kempf, J., et. al Individual [Page 5] Internet Draft Posthandover Tunneling December, 2001 copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Kempf, J., et. al Individual [Page 6]