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
<draft-shiva-improved-lowlatency-handoff-v4-01.txt>
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, <draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt>
3. Khalil et al., Internet Draft, Buffer Management for Mobile IP
<draft-mkhalil-mobileip-buffer-00.txt>
4. Calhoun et al., Internet Draft, Foreign Agent Assisted Hand-off
<draft-calhoun-mobileip-proactive-fa-03.txt>
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, <draft-kahng-rss-mipv4-00.txt>
6. Shim/Gitlin, Internet Draft, Fast Handoff Using Neighbor
Information, <draft-shim-mobileip-neighbor-00.txt>
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]