Internet Engineering Task Force Internet-Draft Shiva Raman Pandey Satish Jamadagni Sasken Communication Technologies Ltd. Bangalore, India Expires - Aug 2002 February 2002 Improved Low Latency Handoff in Mobile IPv4 Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract We are considering the IETF Mobile IP WG proposed Low Latency Handoff draft[2] in the different network scenerios and suggesting one simpler solution with low loss, reduced number of timers, reduced network overhead, along with the low latency. One more achievement will be reduction in the dependency on exact L2 trigger timing and Pre-Registration timer expiration in Combined Handoff method[2]. Table of Contents 1. Introduction 2. Terminology 3. Problems with the IETF Mobile IP WG proposed [2] approach 3.1 Problems with the Pre-Registration 3.2 Problems with the Post-Registration 3.3 Problems with the Combined Method 4. Suggested Improved Approach 4.1 Mobile-Initiated Handoff 4.2 Source Triggered Handoff Shiva, et al. [Page 1] Internet Draft Improved Low Latency Handoff In Mobile IPv4 Feb 2002 4.3 Target Triggered Handoff 5. Summary 6. References 7. Author's Address 1. Introduction The Mobile IP handoff as in [1] MAY introduce latency and packet loss that is not desirable for delay-sensitive and real-time applications. Lots of methods have been proposed to reduce this delay and packet loss.These methods include Pre-Registration [2], Post-Registration [2], Combined method [2], Buffer Management [3], Pro-active FA [4], Strict route info method [5] and Neighbor info through MN [6] method etc. In this draft we are suggesting some improvements over the Low Latency Mobile IPv4 Handoffs[2]. Specifically we suggest the use of bi-directional tunnels in the Pre-Registration to achieve reduced packet loss, reduced network overhead, reduced number of timers along with low latency L3 handoff. This ensures signaling advantages as well as prevents any data loss. 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 [3]. 3. Problems with the IETF Mobile IP WG proposed [2] approach 3.1 Problems with the Pre-Registration Pre-Registration will not achieve its requirement of low loss and low latency in the following cases a. When L2 trigger is recieved late. b. When Registration Request gets lost on its way to HA/GFA. c. HA/GFA is overloaded to handle the registration Request in time. d. Network between oFA and HA/GFA is congested. In the above mentioned cases L2 handoff will complete before the completion of L3 handoff. Packets arriving at oFA will not reach MN, as MN is now connected with nFA. This packet loss will hamper the quality of seamless handoff. 3.2 Problems with the Post-Registration In post registration we have extra overhead of maintaining several timers and extra signalling message HTT. 3.3 Problems with the Combined Method All the cases considered in section 3.1 and 3.2 hold true here, as only the bi-directional tunnel is being created in advance but it will not be Shiva, et al. [Page 2] Internet Draft Improved Low Latency Handoff In Mobile IPv4 Feb 2002 used till the Pre-Registraton timer expires. Here lots of dependency is being put on exact prediction of L2 trigger timing and timer expiration. The failure of this prediction will make this approach unsuitable for delay-sensitive and real-time applications. 4. Suggested Improved Approach We are suggesting an improved approach with the introduction of bi-directional tunnel in the Pre-Registration fast handoff. There will be no need for Post-registration without losing any advantages of [2]. A Bi-directional tunnel will be created between the oFA and the nFA along with the normal Pre-Registration process. As soon as the tunnel is created, all the data meant for the MN, reaching either end of tunnel will be sent directly on link to the MN and at the same time will be tunneled to the other end of tunnel. So MN will always be recieving packets, independent of with which FA(oFA or nFA), MN is currently connected at L2. In the cases considered in section 3.1, MN will never be at risk of loosing packets. Even if the L2 trigger is late or timer expiration prediction is incorrect, the handoff will be seamless. Actual signaling messages are as follows. Since we are suggesting some improvements over Low Latency Fast Handoff [2],we are following all the procedures, message formats, terminology of [2],unless explicitely stated otherwise. In the following descriptions, our focus will be only on the differences from [2] and their pros and cons. 4.1 Mobile-Initiated Handoff A mobile-initiated handoff occurs when an L2 trigger is received at the MN informing that it will shortly move to nFA. The message timing diagram is shown in Figure 1. Shiva, et al. [Page 3] Internet Draft Improved Low Latency Handoff In Mobile IPv4 Feb 2002 MN oFA nFA HA/GFA | | | | | |------------------>| | | | RtSol | | | |<------------------| | | | RtAdv | | |<~~~~~ L2-Trigger | | | | | | | |-------------------->| | | | ProxyRtSol | | | | | | | |<--------------------| | | | ProxyRtAdv | | | | | | | |---------------------------------------->| | | RegReq or |------------------>| | | RegRegReq | HRqst |------------------->| | (routed via oFA) |<------------------| RegReq or RegRegReq| | | HRply | | | | |<-------------------| | | | (Reg)RegReply | |<----------------------------------------| | | (Reg)RegReply | |<~~~~ LU | | |<------------------| | | | HRqst(r) | | | |------------------>| | | | HRply(r) | | Figure 1 - Improved Seamless Handoff Message Timing Diagram (Mobile-Initiated) Here the Handoff Request(HRqst) and Handoff Reply(HRply) messages are same as defined in the [2]. Unlike [2] we are not solely dependent on LD and LU messages to start and stop sending packets via tunnel. Instead we will start using the bi-directional tunnel as soon as it is created.The nFA will send the HRqst(r) to oFA to remove the tunnel as soon as RegReply is received at the nFA and MN is connected to nFA at L2. L2 Connection will be singalled by LU message. LU may arrive before or after RegRep is received at nFA. Only for simplicity it is shown arriving after RegRep in all timing diagrams. All other things related to HRqst and HRply will be same as described in [2]. 4.2 Source Triggered Handoff A Source triggered handoff occurs when an L2 trigger is received at the oFA informing that MN will shortly move to nFA. The message timing diagram is shown in Figure 2. Shiva, et al. [Page 4] Internet Draft Improved Low Latency Handoff In Mobile IPv4 Feb 2002 MN oFA nFA HA/GFA | | | | | |------------------>| | | | RtSol | | | |<------------------| | | | RtAdv | | | L2-Trigger ~~~~~>| | | | | | | |<--------------------| | | | ProxyRtAdv | | | | | | | |---------------------------------------->| | | RegReq or |------------------>| | | RegRegReq | HRqst |------------------->| | (routed via oFA) |<------------------| RegReq or RegRegReq| | | HRply | | | | |<-------------------| | | | (Reg)RegReply | |<----------------------------------------| | | | (Reg)RegReply |<~~~~ LU | | |<------------------| | | | HRqst(r) | | | |------------------>| | | | HRply(r) | | Figure 2 - Improved Seamless Handoff Message Timing Diagram (Source Triggered) 4.3 Target Triggered Handoff A Target triggered handoff occurs when an L2 trigger is received at the nFA informing that MN will shortly connect to nFA. The message timing diagram is shown in Figure 3. Shiva, et al. [Page 5] Internet Draft Improved Low Latency Handoff In Mobile IPv4 Feb 2002 MN oFA nFA HA/GFA | | | | | |------------------>| | | | RtSol | | | |<------------------| | | | RtAdv | | | | |<~~~~~ L2-Trigger | | |...................| | |<----------------------------------------| | | ProxyRtAdv |...................| | | | Tunneled RtAdv | | |---------------------------------------->| | | RegReq or |<------------------| | | RegRegReq | HRqst |------------------->| | (routed via oFA) |------------------>| RegReq or RegRegReq| | | HRply | | | | |<-------------------| | | | (Reg)RegReply | |<----------------------------------------| | | | (Reg)RegReply |<~~~~ LU | | |<------------------| | | | HRqst(r) | | | |------------------>| | | | HRply(r) | | Figure 3 - Improved Seamless Handoff Message Timing Diagram (Target Triggered) 5. Summary In our suggested approach, if any MIP message fails, it has to be repeated as described in [1]. Here, we are not using lots of timers to keep track of when to move the tunnel end point from nFA to the third FA, and when to start using the bi-directional tunnel etc. Similarly the message Handoff To Third(HTT) is not required. One drawback of our approach is that it creates and uses the bi-directional tunnel even if Pre-registration succeeds, but since it guarranties that there will be very less or no packet loss, this overhead is something, worth having. 6. References 1. Perkins, Mobile IP protocol, RFC 2002 2. Mobile IP working group, Internet Draft, Low latency handoff in Mobile IPv4, 3. Khalil et al., Internet Draft, Buffer Management for Mobile IP 4. Calhoun et al., Internet Draft, Foreign Agent Assisted Hand-off Shiva, et al. [Page 6] Internet Draft Improved Low Latency Handoff In Mobile IPv4 Feb 2002 5. Korea University, Internet Draft, Redirect Subnet Switching in Mobile IPv4, 6. Shim/Gitlin, Internet Draft, Fast Handoff Using Neighbor Information, 7. Author's Addresses Please send your comments to shiva@sasken.com Shiva Raman Pandey, Sasken Communication Technologies Ltd #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone:+91 80 535 5501 Ext 3296 Fax: +91 80 535 1133: Email: shiva@sasken.com Satish Jamadagni, Sasken Communication Technologies Ltd #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone:+91 80 5355501 Ext:3029 Fax: +91 80 5351133 Email: satishj@sasken.com Shiva, et al. Expires - Aug 2002 [Page 7]