Mobile IP Working Group MIPv4 Handoffs Design Team
INTERNET-DRAFT Karim El Malki (Editor)
Expires: August 2001 Pat R. Calhoun
Tom Hiller
James Kempf
Peter J. McCann
Ajoy Singh
Hesham Soliman
Sebastian Thalanany
February 23, 2001
Low latency Handoffs in Mobile IPv4
<draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt>
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 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
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
Mobile IP (RFC2002) describes how a Mobile Node (MN) can perform IP-
layer handoffs between Foreign Agent (FA) subnets. In certain cases,
the latency involved in these handoffs can be above the threshold
required for the support of delay-sensitive or real-time services.
The aim of this document is to present two methods to achieve low-
latency Mobile IP handoffs (movement between FA subnets). These allow
MIPv4 handoffs team [Page 1]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
greater support for real-time services on a Mobile IPv4 network by
minimising the period of service disruption due to the delay in the
Mobile IP Registration process.
TABLE OF CONTENTS
1. Introduction....................................................3
1.1 Requirements language........................................4
2. Requirements....................................................4
3. Network Assisted, Mobile and Network Controlled (NAMONC) Handoff
Method..........................................................4
3.1 Initiating NAMONC Handoffs through the "previous" FA.........9
I. Inter-FA Solicitation .....................................10
II. Piggy-backing Advertisements on L2 messaging.............10
3.2 Movement Detection and MN Considerations.....................10
3.3 Regional Deregistration for NAMONC Handoffs..................13
3.4 Smooth Handoffs between Hierarchies (GFAs)...................13
3.5 L2 Address Considerations for NAMONC Handoffs................14
3.6 Advantages and Applicability of NAMONC Handoff Method........15
4. Network Initiated, Mobile Terminated (NIMOT) Handoff Method....15
4.1 Registration Latency........................................16
4.2 Movement Detection..........................................17
4.3 Ping-Pong effect............................................19
4.4 Reverse Tunneling Support...................................20
4.5 Security Relationships......................................20
4.6 Operation...................................................21
4.6.1 Foreign Agent Considerations...........................21
4.6.2 Gateway Foreign Agent Considerations...................24
4.7 Handoff Request Message.....................................24
4.8 Handoff Reply Message.......................................26
4.9 Error Values................................................27
4.10 Security Considerations.....................................27
4.11 Advantages and Applicability of NIMOT Handoff Method....... 28
5. Generalized Link Layer Address Extension.......................29
5.1 IMSI Link Layer Address Extension...........................29
5.2 Ethernet Link Layer Address Extension.......................30
5.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension....31
6. IANA Considerations.............................................31
7. References......................................................32
8. Authors' Addresses..............................................33
Appendix A - Gateway Foreign Agents................................36
Appendix B - Bicasting Applicability Statement.....................37
MIPv4 Handoffs Design Team [Page 2]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
1. Introduction
Mobile IPv4 (RFC2002) describes how a Mobile Node (MN) can perform
IP-layer handoffs between Foreign Agent (FA) subnets. In certain
cases, the latency involved in these handoffs can be above the
threshold required for the support of delay-sensitive or real-time
services. The aim of this document is to present two methods to
achieve low-latency Mobile IP handoffs (movement between FA subnets).
These allow greater support for real-time services on a Mobile IPv4
network by minimising the period of service disruption due to the
delay in the Mobile IP Registration process.
The two methods presented in this draft to achieve low-latency IP-
layer handoffs are:
- Network Assisted, Mobile and Network Controlled (NAMONC) Handoffs
- Network Initiated, Mobile Terminated (NIMOT) Handoffs
The Network Assisted, Mobile and Network Controlled (NAMONC) Handoff
method allows the MN to be involved in an anticipated IP-layer
handoff procedure. The MN is therefore assisted by the network in
performing an anticipated L3 handoff before it completes the L2
handoff. Information from L2 (L2 triggers) may be used both in the MN
and in the FA. This method proposes the use of simultaneous bindings
in order to send multiple copies of the traffic to potential Mobile
Node movement locations before MN movement occurs. Therefore, the
Mobile-Assisted Handoff method coupled to layer 2 mobility may help
in achieving seamless (low latency + low loss) handoffs between
Foreign Agents. However L2 connectivity may cause packet losses. In
addition to handling the simple case of a MN, FA, and Home Agent, the
NAMONC Handoff method also allows the use of Regional Registrations
[2]. The Mobile IPv4 concept (Advertisement-Registration) is
supported and NAMONC handoffs rely on Mobile IP security. No new
messages are proposed. In cases where the MN is able to activate
multiple interfaces and thus be data-connected to multiple access
points simultaneously, the MN may not need to support anticipated
simultaneous bindings and may achieve seamless handoffs simply by
establishing connectivity through registrations with the new FA
before disconnecting from the current interface.
The Network Initiated, Mobile Terminated (NIMOT) handoffs method
proposes extensions to the Mobile IP protocol to allow the old FA
and new FA to utilize information from layer 2 (the L2 "trigger") to
set up a kind of "pre-registration" prior to receiving a formal
Registration Request from the Mobile Node. This enables a very rapid
establishment of service at the new point of attachment so that the
effect of the handoff on real-time applications is minimized,
although the MN must eventually perform a formal Mobile IP
registration. The proposed extensions make a few minimal assumptions
about support available from the link layer. Although the assumptions
address the kinds of link layer support available in existing radio
MIPv4 Handoffs Design Team [Page 3]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
link layers, the assumptions are not based on any specific radio link
protocol. Security is handled by standard Mobile IP mechanisms, and
both intra-domain and inter-domain handoff are supported. The
technique can be used for inter-technology handoff but it requires
the active involvement by the mobile to switch from one network
interface to another. This technique covers a handoff scenario not
addressed by RFC 2002, namely a pro-active, network-assisted handoff.
Each method may be better suited for certain access network
characteristics and the features and advantages of each method will
be described later. NAMONC and NIMOT handoffs may be implemented
independently. It is up to the implementor, based on the link-layer
characteristics of the specific implementation and the features of
each method supplied in this document to decide upon which is most
appropriate for that case.
1.1 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [3].
2. Requirements
The following requirements are applicable to low-latency handoffs and
are supported by both methods:
- Support delay-sensitive (real-time) services in domain
- Support back-and-forth movement of MN between FAs (ping-pong)
- No dependency on a wireless L2 technology
- Support Inter and Intra-access technology handoffs
- Limit wireless bandwidth usage
3. Network Assisted, Mobile and Network Controlled (NAMONC) Handoff
Method
This method is intended to support low latency IP-layer handoffs for:
- Multi-access mobility
(different access technologies; MN and network controlled)
- Single-access mobility
(same access technology; MN and network controlled)
This method considers both the normal Mobile IP model [1] and the
Regional (hierarchical) Mobile IP model [2]. These are shown in
Figure 1 where the Access Points (APs) or Radio Networks (RNs) are
MIPv4 Handoffs Design Team [Page 4]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
used to provide a MN with wireless or wired L2 access. Both inter and
intra-domain (AAA-assisted) mobility is considered.
The additional features for this method are:
- Support MN-control of L3 handoff (as RFC2002)
MN controls its registrations and there are no proxy registrations
on MN's behalf.
- Support network(FA)-control of L3 handoff (as RFC2002)
FA controls advertisements (which cause MN handoff) and can
accept/reject registrations.
- No new messages
- Maintain RFC2002 concept thus allowing MN to determine which FA it
will register with(advertisement->movement detection->registration)
- Rely on existing Mobile IP security model MN-FA-HA (e.g. using
AAA) but make no assumption on L2 security
- No L3 knowledge of exact L2 handoff timing (but this method can
make use of handoff indications or triggers from L2 on either the
network or terminal side depending on the initiator)
Figure 1 illustrates the normal and hierarchical MIPv4 models. In the
simplest multi-access or single-access case where the MN is able to
activate more than one interface (corresponding to different or the
same access technologies) and thus be data-connected to multiple
access points simultaneously it is possible to achieve low-latency
handoffs in a relatively simple manner. Assume that the MN is
connected to RN2 and is registered with FA2 through which it is
receiving traffic. The MN may enter the coverage area of RN1 and FA1
and decide that it prefers connectivity to this network for reasons
beyond the scope of this document (e.g. user preferences, cost, QoS
available etc.). The MN would then activate the interface to RN1 as
well as continue communicating through RN2. The MN may solicit
advertisements from FA1 to speed up the handoff process. Once it is
registered with FA1 and is successfully receiving and transmitting
through the new network it may then tear down the interface to RN2.
If the MN has enough time to complete this procedure without
incurring degraded service or disconnection then it would provide the
MN with a seamless multi-access handoff. In order to support the
possible failure of the connectivity with the new network (RN1/FA1)
in the short period following handoff the MN MAY use the "S" bit in
its Mobile IP Registration Request to maintain both its existing (HA
or GFA) binding with FA2 and a new binding with FA1 (i.e.
simultaneous bindings). The use of simultaneous bindings is not
necessary in most of the cases belonging to this scenario.
MIPv4 Handoffs Design Team [Page 5]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
_________ _________
| | | |
| HA |--------| (GFA) |________
|_________| |_________| \
/ | \ \
\
... ... ... \
\
______/_ _\______ |
| | | | |
| FA2 | | FA1 | |
|________| |________| |
____|___ ____|___ ____|___
| | | | | |
| AP/RN 2| | AP/RN 1| | AP/RN 3|
|________| |________| |________|
| ____|___
| |
CN | MN |
|________|
Figure 1 - Normal(HA only) and Hierarchical(HA and GFA) MIPv4 model
In the remaining part of the description of the NAMONC Handoffs
method, the scenarios for single and multi-access handoffs will be
considered. In these scenarios the MN is unable to activate and
communicate over more than one interface or connection to the
network. This may be due to limitations imposed by the access
technology or configuration of the mobile node. In these cases it is
necessary to anticipate the IP-layer handoff before the MN's movement
actually happens in order to achieve a seamless mobility effect as
close as possible to that described previously.
In Figure 1, using normal Mobile IP (no GFA) the MN MAY perform
registrations with the HA using simultaneous bindings. This is
described in [1] and the method to anticipate MN movement by
interacting with the wireless L2 is described later in this draft.
Simultaneous bindings are used to decouple the IP-layer handoff from
the L2 handoff by having data reaching the multiple possible MN
locations before the MN moves there since the details of the L2
handoff timing are unknown to L3. "Bicasting" or simultaneous
bindings are also useful to support "ping-pong" or fast back-and-
forth MN movement between FAs due to fast mobility or handoff
failures.
An alternative method to perform improved handoffs, namely Smooth
Handoffs, is described in [4]. The method for NAMONC Handoffs
addresses the need to support services having strict delay bounds
(i.e. real-time) which in certain cases may be hard to support if
MIPv4 Handoffs Design Team [Page 6]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
traffic has to be forwarded between FAs using Smooth Handoffs. This
is especially true if the two FAs are not directly connected. If
there is a common router or router network connecting the two FAs and
the HA, forwarding traffic between FAs would cause twice the
bandwidth usage on the common router/s and a considerable increase in
delay. Also, in the non-realtime case it may be possible that the new
FA receives both buffered traffic from the previous FA (smooth
handoff) and traffic from the HA which could cause some delayed and
possibly out-of-order packets to be delivered to the MN. This could
affect the performance of higher level protocols (e.g. TCP). The same
situation will not arise using NAMONC Handoffs.
However, having multiple simultaneous bindings for MNs at the HA will
cause the HA to send multiple copies of data packets towards mutliple
FAs which may be in the same region or domain. In terms of bandwidth
usage this would not be efficient unless the HA is close to the FAs
in question, however this is not always the case. Also, if the round-
trip time between HA and FAs is not negligible this may slow down the
MN's new Registration and therefore the Mobile IP handoff. The
Hierarchical MIPv4 model addresses these problems.
The Regional (Hierarchical) Mobile IPv4 scheme introduced in Regional
Registrations [2] allows a Mobile Node to perform registrations
locally with a Gateway Foreign Agent (GFA) in order to reduce the
number of signalling messages to the home network. This achieves a
reduction in the signalling delay when a Mobile Node moves between
Foreign Agents and therefore improves the performance of such
handoffs. This draft is applicable to single-level (GFA only with no
regional FAs) and multi-level Hierarchical Mobile IPv4 networks
described in Regional Registrations [2]. Networks utilizing Regional
Registrations with NAMONC Handoffs offer advantages which are
especially important for the support of real-time services. As
mentioned previously, the GFA may well be the first-hop router for
the MN.
In the Regional (Hierarchical) Mobile IP case the NAMONC Handoff is
achieved by "bicasting" traffic from the GFA to the previous FA and
new FA while the MN is moving between them. The anticipation of the
MN's movement is achieved by tight coupling with Layer 2
functionality in the FA which is dependent on the type of access
technology used. Bicasting is achieved through simultaneous bindings,
where the MN activates the "S" bit in the Registration Request
(described in [1]). In a hierarchical MIPv4 network, when a Regional
Registration Request has the "S" bit set, the receiving regional FA
or GFA which has an existing binding with the MN will add the
relevant new binding for the MN but will also maintain any other
existing bindings it had for the MN.
When the MN has multiple active bindings with FAs, it MAY receive
multiple copies of the same traffic directed to it. The use of
simultaneous bindings does not necessarily mean that the MN is
MIPv4 Handoffs Design Team [Page 7]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
receiving packets contemporarily from multiple sources. This depends
on the characteristics of the access (L2) technology. The bicasting
of packets is used to anticipate the MN's movement and speed up
handoffs by sending a copy of the data to the FA which the MN is
moving to. Until the MN actually completes the L2 handoff to the new
FA, the data "copy" reaching this FA may be discarded. In this way
the total handoff delay is limited to the time needed to perform the
L2 handoff. Thus, NAMONC Handoffs coupled to the L2 access
potentially result in loss-less IP-layer mobility. As described in
3.1, depending on the L2 characteristics, it is also possible for an
MN to initiate a NAMONC Handoff through the "previous" FA without
having direct access to the "new" FA.
The overall NAMONC Handoff mechanism is summarised in Figure 2 below:
+-----+
| GFA |<---------+
+-----+ | 4. RegRegReq.
| 5. RegRegReply
v
+-----+ (1a RtSol) +-----+
| | -----------------> | nFA |
| oFA | 1b.RtAdv | |
+-----+ <----------------- +-----+
^ | ^
(2a. RtSol) | | 2b. /
| | ProxyRtAdv / 3. RegRegReq
| | /
| v ---------------
+-----+ /
| MN |
+-----+ - - - - - ->
Movement
Figure 2 - NAMONC Handoff Message exchange
Messages 1a and 1b (Router Solicitation and Router Advertisement)
should occur in advance of the NAMONC Handoff and should not delay
the sending of message 2b. For this purpose the old FA (oFA) MAY
solicit and cache advertisements from the new FA (nFA), thus
decoupling the timing of this exchange from the rest of the NAMONC
Handoff. Message 2a occurs if there is an L2 trigger in the MN to
solicit for a router advertisement. In network-controlled wireless
systems the L2 trigger will be in the network and will reach oFA
which will transmit the Proxy Router Advertisement (message 2b). This
is simply nFA's advertisement relayed by oFA. The MN will perform
movement detection and, if appropriate, send a Regional Registration
Request message [2] (message 3) to nFA requesting a simultaneous
binding. Message 3 may be routed through oFA since the MN is not
directly connected to nFA at this point. Messages 3, 4 and 5 are
MIPv4 Handoffs Design Team [Page 8]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
described in [2]. The Regional Registration Reply (message 5) needs
to be forwarded by nFA to the MN. Unless the system is engineered
such that the MN may not detach from oFA until it has received the
Reply, the MN may at this time have disconnected. Therefore the Reply
should be copied by nFA to the MN's old location (tunnelling the
Regional Registration Reply to oFA) and to the MN's new location. The
MN's new L2 address may be obtained using the extensions in section
5, as described in 3.5. At this moment it may still not be known at
L3 whether the MN has detached and connected to nFA. Even if it was
known at the exact instant, in most wireless systems there would not
be enough time for L3 to react and forward traffic to the MN's new
location by the time the MN has attached. For this reason, to
maintain L3 connectivity, simultaneous binding are used. Therefore
for a short time interval from the moment the Regional Registration
Reply is sent by the from GFA to nFA, the GFA will start bicasting
traffic for the MN to both oFA and nFA. Therefore the MN will be able
to receive traffic independently of the exact L2 handoff timing.
Also, should the L2 handoff procedure fail or terminate abruptly, the
use of simultaneous bindings allows the MN to maintain L3
connectivity with oFA. The same stands for the case in which the MN
performs "ping-pong" or fast back-and-forth movement between FAs,
where simultaneous bindings allow continued L3 connectivity without
the need to continuously receive advertisements and send registration
messages. This reduces the signalling load over the air interface.
Note that this method can be applied to the case where multiple
possible nFAs are identified by oFA.
3.1 Initiating NAMONC Handoffs through the "previous" FA
Some existing wireless L2 technologies and their implementations do
not allow a MN to be data-connected to multiple wireless access
points simultaneously. In order to perform a NAMONC Handoff it is
necessary for some form of interworking between layers 2 and 3 to
determine when a L3 handoff should be triggered by a L2 handoff. It
should be noted that the method used by an FA to determine when a MN
has initiated an L2 handoff (L2 trigger) for which the FA should
initate a NAMONC Handoff is outside the scope of this draft and may
involve interaction with L2 messaging. If the FA determines from the
L2 trigger that movement between FAs will not occur then the NAMONC
Handoff should not be initiated. When this is not the case, the
interaction between L2 and L3 (on the network side and/or MN-side)
should allow the Mobile Node to complete a L2 handoff (resulting in
movement between FAs) after having performed the L3 NAMONC Handoff
described in this draft. That is, the L2 handoff should be completed
after the MN's Registration with the "new" FA which produces a
simultaneous binding at the GFA/HA. This Registration may be
transmitted more than once to reduce the probability that it is lost
due to errors on the wireless link.
MIPv4 Handoffs Design Team [Page 9]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
A NAMONC Handoff in this case requires the MN to receive "new" agent
advertisements through the "old" wireless access points, and to
perform a registration with the "new" FA through the "old" wireless
access point. This procedure should be performed before the layer-2
handoff event. Two ways of performing this follow.
I. Inter-FA Solicitation
This solution assumes that the FA with which the MN is currently
registered is aware of the IP address of the "new" FA which the MN is
moving to. The method by which the current FA is informed of this may
depend on interaction with L2 and is outside the scope of this draft.
Once the current FA is aware of the address of the FA which the MN
will move to, it will send the "new" FA an agent solicitation
message. The "new" FA will reply to the current FA by sending it an
agent advertisement with appropriate extensions. The current FA will
then send the agent advertisement to the MN's address. As a
consequence, the MN, being eager to perform new registrations, will
send a registration request to the "new" FA through the "old"
wireless access point served by the current FA.
II. Piggy-backing Advertisements on L2 messaging
Using Figure 1, consider a case where an MN initiates an L2 handoff
from AP/RN1 to AP/RN2 (Note that it may not be the MN which takes
decisions on L2 handoffs). It is assumed that when an L2 handoff is
initiated, AP/RN1 and AP/RN2 perform L2 messaging procedures to
negotiate the L2 handoff. Since the MN is not attached to AP/RN2 yet,
FA2 is unaware of the IP address of the MN and cannot send an
advertisement to it. Therefore it is necessary for the L2 procedures
(which must be common to AP/RN1 and AP/RN2) to interwork with Mobile
IP.
Once a L2 handoff is initiated, such that AP/RN2 and AP/RN1 are in
communication, it is possible for AP/RN2 to solicit an advertisement
from FA2 and transfer it to AP/RN1. Once this is received by the MN,
the MN can perform a registration directed to FA2 even though the MN
has no data-connection to AP/RN2 yet.
The precise definition of such L2 procedures is outside the scope of
Mobile IP.
3.2 Movement Detection and MN Considerations
When there is a hierarchy of foreign agents between the GFA and the
announcing foreign agent, the announcing foreign agent MAY include
the corresponding addresses in order between its own address (first)
MIPv4 Handoffs Design Team [Page 10]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
and the GFA address (last) in the Mobility Agent Advertisement
extension of its Agent Advertisements. If there are only two
hierarchical levels, a foreign agent announces itself and a GFA in
the Agent Advertisement; in the first and last address in the care-of
address field in the Mobility Agent Advertisement extension. There
must be at least one care-of address in the Mobility Agent
Advertisement extension. If there is only one care-of address it is
the address of the GFA, and the MN is connected directly to it.
When the MN receives an Agent Advertisement with a Mobility Agent
extension and the "I" bit set, as specified in [2], it should perform
actions according to the following movement detection mechanisms. In
a Hierarchical Mobile IP network such as the one described in this
draft, the MN MUST be:
- "Eager" to perform new bindings
- "Lazy" in releasing existing bindings
The above means that the MN MUST perform Regional Registrations with
any "new" FA from which it receives an advertisement (Eager) as long
as there are no locally-defined policies in the MN which discourage
the use of this FA (e.g. cost of service). The method by which the MN
determines whether the FA is a "new" FA is described in [1] and may
make use of an FA-NAI extension. However the MN MUST NOT release
existing bindings until it no longer receives advertisement from the
relative FA and the lifetime of its existing binding expires (Lazy).
It should be noted that the MN may add a Hierarchical FA extension to
Registration Requests in order to identify the exact FA path to be
followed by the Registration Request. This extension must not be
removed by regional FAs.
If the MN has at least one existing binding with a FA, additional
simultaneous regional registrations will be performed requesting a
short lifetime. This is done in order to limit the lifetime of
bindings which the MN only needs temporarily and therefore limit
bandwidth usage. This is the case when the MN is moving between FAs
and uses NAMONC Handoffs to achieve loss-less IP mobility. The
lifetime of additional "auxiliary" bindings needed for NAMONC
Handoffs is thus limited. This may also be useful to support eventual
the MN's "ping-pong" movement between FAs which would otherwise
require continuous registrations and thus handoff delays.
The remaining issue is the choice of the appropriate HA address in
the Regional Registration Request when the MN has at least an
existing active regional binding. Two options follow:
1) Mobility Agent extension advertises FA and GFA address only
In this case it is assumed that there is always a single path from
MIPv4 Handoffs Design Team [Page 11]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
the MN to the GFA. The MN will always perform Regional Registrations
using the GFA address as HA address and the advertising FA as care-of
address. As the Regional Registration Request is relayed towards the
GFA, each FA receiving it will check whether it has an existing
binding with the MN and whether the Regional Registration has the "S"
bit set to request for simultaneous bindings. If this is true and the
Regional Registration is validated by the GFA, these FAs will
activate the simultaneous binding upon receiving the (successful)
Regional Registration Reply from the GFA. Therefore it is not
necessary to advertise to the MN all of the FA addresses in the
hierarchical branch, thus reducing bandwidth usage over wireless.
2) Mobility Agent Advertisement extension advertises complete order
of FAs in the branch
In specific cases where multiple regional FA levels and multiple
paths from the MN to the GFA are present and are advertised, it may
be necessary for the MN to identify the "common route" FA using the
complete list of FAs in the hierarchical branch. It is assumed that
the GFA advertises only one care-of address on all its interfaces
towards the MN.
The MN must cache the Mobility Agent Advertisement extensions for its
active bindings. When it receives an advertisement from a "new" FA
which has a different Mobility Agent Adv. extension, it will be eager
to perform a new binding. The MN compares the IP addresses in the new
Mobility Agent Adv. extension with the ones it has cached for its
active binding(s). If there is an IP address in common between these
extensions, named "common route" FA or GFA, the MN will use that IP
address as HA address and destination address of its Regional
Registration Request in which the "S" bit will be set. The care-of
address is the advertising FA's address. The MN may add a
Hierarchical FA extension to the Regional Registration Request, in
order to identify the regional FA path to be followed by the Request
up the hierarchy. A Regional FA receiving a Regional Registration
Request with it's own address as HA address may return a Regional
Registration Reply to the MN.
If there is no IP address in common between the extensions, then the
MN must have moved into a new hierarchy and the GFA advertised in the
new extension must be different from the one in the previously cached
extension(s). When the MN moves between administrative domains (i.e.
changes GFA) then the MN should use the new GFA's IP address as care-
of address in its new Registration Request to the HA and may add the
Hierarchical FA extension as described previously. If the MN has at
least one existing active binding when it moves to the new GFA, it
may perform a smooth handoff as explained in section 3.4.
The MN is able to perform this option to implement NAMONC Handoffs
only if its binding lifetime with the GFA or HA does not expire
MIPv4 Handoffs Design Team [Page 12]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
during the period needed by the MN to complete its handoff.
Intermediate regional FAs are able to accept the MN's regional
registration (simultaneous binding) only if the intermediate regional
FA has an existing active binding for the MN. The resulting
simultaneous binding may therefore have a maximum possible lifetime
equal to the lifetime remaining in its previously existing active
binding. Once the registration lifetime with the GFA or HA is about
to expire, the MN must perform a new Mobile IP registration with the
HA.
3.3 Regional Deregistration for NAMONC Handoffs
Regional deregistration is described in [2]. In this draft we apply
the deregistration procedure to NAMONC Handoffs. When the MN performs
a regional registration with a "new" regional FA, then a regional
deregistration must be performed with the MN's old location, which
may include all the FAs in its old regional branch. This is necessary
to avoid incorrect routing of packets by the "previous" FA(s) in the
old regional branch during the interval in which the MN has moved but
the "previous" FA(s)'s regional binding lifetime for the MN has not
yet expired.
The regional deregistration is performed by a regional FA upon the
first time it receives a valid Regional Registration Request, without
the "S" bit set, from a MN which had previously set the "S" bit in
its regional registration(s). This regional FA may respond with a
Registration reply and may perform the Regional deregistration by
sending a Binding Update with zero lifetime to the "next" regional FA
in the MN's old regional branch, setting the Binding Update's care-of
address to the the previous care-of address it had registered for the
MN (i.e. the "previous" lowest level FA). The Binding Update is
relayed down towards the previous care-of address, and each regional
foreign agent in the hierarchy receiving this notification removes
its binding for the MN. In this way, the MN updates all the Regional
FAs in the "old" hierarchical branch between the "common route" FA
and the "old" lowest level FA. It is assumed that GFA/FAs within the
same hierarchical domain share a Security Association which can be
used to perform this deregistration.
The MN will be able to perform regional deregistrations through
intermediate regional FAs if the GFA shares its GFA-MN security
association with the regional FAs. Otherwise the regional
deregistration will be performed by the GFA.
3.4 Smooth Handoffs between Hierarchies (GFAs)
When the MN moves between domains it receives Mobility Agent
extensions containing a new GFA IP address. The MN registers with its
HA using the new GFA IP address as care-of address. In order to
MIPv4 Handoffs Design Team [Page 13]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
improve inter-domain handoffs it may use the Previous Foreign Agent
extension in the Regional Registration Request [4]. This results in a
smooth handoff between the domains.
A new flag is required in the Binding Update message to perform a
smooth handoff while maintaining the existing binding in the
"previous" FA. This is the "S" bit for the simultaneous binding. This
simultaneous binding is necessary in the case in which the MN only
momentarily moves "forward" to the new domain, then returns back to
the "previous" FA (domain) before its previous binding expires. In
this case the binding for the MN with the "previous" FA must be
maintained. Following is the new Binding Update message with the "S"
flag added which replaces one bit of the Reserved space. The "S" flag
is described below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |A|I|M|G|S| Rsv | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
S Simultaneous Bindings flag (see [1]). When set (1) it
indicates that this binding for the MN must be added to
the binding list and MUST NOT replace existing bindings
for that MN.
3.5 L2 Address Considerations for NAMONC Handoffs
MNs connected to networks utilising interfaces such as ethernet (e.g.
between FAs and wireless access points) MAY use an L2 extension to
the Registration messages. Such an extension is required in Ethernet-
based networks when the MN performing a registration with a FA which
is not its first-hop router needs to communicate its L2 address to
that FA. Therefore the FA must use the L2 address in this extension
to communicate with the MN instead of the L2 source address of the
incoming Registration Request message as specified in RFC2002. Such
an extension is described in section 5 of this draft. In many cases
MIPv4 Handoffs Design Team [Page 14]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
wireless standards have defined special L2 interfaces to the wireless
network which allows these networks to resolve the mapping between MN
IP address and L2 address without the need to use these extensions.
Therefore such extensions would not be needed.
3.6 Advantages and Applicability of NAMONC Handoff Method
The NAMONC Handoff method is applicable to scenarios where Mobile IP
Registrations are supported by the mobile nodes and the network. This
method is compatible with RFC2002 and therefore is based on the same
security model including the use of AAA. It is assumed that FAs are
able to obtain L2 triggers from the wireless network which inform the
FA that an L2 handoff procedure is being initated for a certain MN to
another access point or radio network having a certain ID. The FA
must be able to determine the IP address of the new FA from this ID
using methods which may be specific to the wireless network and are
not considered here. If the FA determines that the ID is within its
coverage area then NAMONC Handoff should not be initiated. This
"anticipated" L2 trigger must allow enough time for the NAMONC
Handoff procedure to be performed. In many wireless systems the L2
handoff procedure involves a number of message exchanges before the
effective L2 handoff is performed. Therefore the NAMONC Handoff
method can be initiated at the beginning of the L2 handoff procedure
and completed before the L2 handoff is completed. It may be necessary
to engineer the system such that this succession of events is
ensured.
The NAMONC Handoff method provides advantages in the following cases:
- When the MN has locally defined policies that determine a
preference for one access over another (e.g. service cost) and
therefore where it is necessary to allow the MN to select the
appropriate FA to connect to.
- When L3 cannot rely upon L2 security (between MN and FA) to make
modifications to IP routing and therefore authenticated Mobile IP
messages are required.
In the first case it is necessary to involve eventual local MN
policies in the movement detection procedure as described in 3.2.
4. Network Initiated, Mobile Terminated (NIMOT) Handoff Method
As discussed in the Introduction, in the Network-Assisted Handoff
method, the FA makes use of information from layer 2 to optimize
handoff by doing a fast "pre-registration" prior to the formal Mobile
IP registration done by the MN. The goal of the Network-Assisted
Handoff design is to take maximum advantage of layer 2 information
MIPv4 Handoffs Design Team [Page 15]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
without specifying particular layer 2 technologies. Thus the design
depends on abstract L2 _triggers_ that have a very broad set of
characteristics exhibited by many radio layer 2 protocols. In RFC
2002, no assumptions are made about the existence of any layer 2
support for handoff. In pursuit of the lowest latency possible given
such layer 2 information, the Network-Assisted design proposes taking
maximum advantage of any layer 2 information available, and therfore
that RFC 2002 requires enhancement. The Network-Assisted design
proposes new messages that work together with standard Mobile-IP
handoff to reduce handoff latency.
In this document, we will assume that the link-layer events are
signaled to the Foreign Agent as "triggers". We assume that any such
triggers will be sufficient to derive the IP addresses of the Foreign
Agents that will receive or send the hand-off. If such a trigger is
not available or if the MN decides on its own that a hand-off is to
take place, then one of the FAs can often still derive the identity
(IP address) of the other from link-layer messages or through
preconfiguration.
In order for the Mobile IP protocol to provide low-latency hand-off,
the following problems must be addressed:
1. Reducing the latency involved in the registration process.
Although optimization of the Registration process is not typically
considered a Hand-Off problem, this proposal assumes that such a
mechanism is in place.
2. Reducing the latency involved in the Mobile Node's movement
detection process.
3. "Bi-casting" the Mobile Node's traffic to two (or more) points
of attachment, ensuring that the mobile's traffic is delivered as
soon as the link layer hand-off is completed.
4. Support for Reverse Tunneling, which MAY be required for private
addresses.
5. The Security Relationships between the mobility entities for
inter-domain hand-offs.
6. Does not increase mobile power consumption
4.1 Registration Latency
The Mobile IP protocol [1] requires that a Mobile Node registers with
a Foreign Agent, and subsequently its Home Agent, in order to have
its packets delivered to its current point of attachment. The Mobile
IP Regional Registration [2] specification proposes optimized
registration approaches using Gateway Foreign Agents (GFAs), which
are mobility agents that act as concentration points for Foreign
Agents within an Administrative Domain. GFAs allow a Mobile Node's
registration message to be processed by a Mobility Agent in the local
domain, eliminating the need to contact the Home Agent, which MAY be
topologically distant.
MIPv4 Handoffs Design Team [Page 16]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
4.2 Movement Detection
The Mobile IP protocol [1] and the Regional Registration extension
[2] require Mobile Nodes to listen for, or solicit, advertisements in
order to detect that a movement to a new IP subnet has occurred. This
movement detection mechanism introduces significant latency into the
hand-off process, which causes service degradation, especially for
real-time services. Service is further impacted given the additional
latency introduced through the registration process that follows the
movement detection, since the mobile's traffic can only be delivered
once all of the registration has completed.
There have been many solutions proposed to solve this problem,
including increasing the advertisement frequency. In networks where
radio spectrum is expensive or bandwidth is limited, the additional
signaling required for increasing advertisement frequency is a
serious issue impacting deployability.
In this document, we propose that the Foreign Agent take a pro-active
approach and issue the Handoff messages on behalf of the Mobile Node
(acting as a surrogate of sorts). When a Foreign Agent is aware that
a hand-off is occurring at the link-layer, a trigger is sent to the
Mobile IP protocol stack.
+-----+
| GFA |
+-----+
^ |
3. Regional | | 4. Regional
Reg Request | | Reg Reply
| v
+-----+ 1. Handoff Request +-----+
| | -----------------> | |
| oFA | | nFA |
| | 2. Handoff Reply | |
+-----+ <----------------- +-----+
+-----+ Movement +-----+
| MN | - - - - - - - - -> | MN |
+-----+ +-----+
Figure 3 - Source Trigger Pro-Active Handoff
A source trigger (see Figure 3) is one that is obtained by the old
Foreign Agent (oFA) once the link layer detects that the Mobile Node
is departing its coverage area. A target trigger (see Figure 4), on
the other hand, is one that is obtained by the new Foreign Agent
(nFA) once the link layer detects that the Mobile Node is arriving in
its coverage area. Note that both triggers may be available before
the actual completion of the link layer handoff.
MIPv4 Handoffs Design Team [Page 17]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
The messages depicted in both Figures 3 and 4 are very similar. The
main difference is the initiator of the Handoff Request message. In
both examples, an optional Gateway Foreign Agent is used, which
requires the use of the Regional Registration messages [2]. In both
the source and target triggers, a Foreign Agent obtains link-layer
information, such as power measurements, that indicate the necessity
of a handoff to the new Foreign Agent. In the event of a source
trigger, oFA transmits a Handoff Request message to nFA. The Handoff
Request MUST include the Mobile Node's Home Address, Home Agent
Address, remaining registration lifetime, as well as the Link-Layer
Address Extension (see Section 5). The GFA's identity MUST also be
present, if one was used for the Mobile Node's registration. Upon
receipt of the message, nFA MUST create the Mobile Node's visitor
entry, and respond with the Handoff Reply message.
+-----+
| GFA |
+-----+
^ |
3. Regional | | 4. Regional
Reg Request | | Reg Reply
| v
+-----+ 1. Handoff Request +-----+
| | <----------------- | |
| oFA | | nFA |
| | 2. Handoff Reply | |
+-----+ -----------------> +-----+
+-----+ Movement +-----+
| MN | - - - - - - - - -> | MN |
+-----+ +-----+
Figure 4 - Target Trigger Pro-Active Handoff
In target triggers, the trigger occurs on nFA, which results in the
transmission of a Handoff Request to oFA. The Handoff Request message
MUST include the Mobile Node's Link-Layer Address (see Section 5) in
order for oFA to correctly identify the Mobile Node. The request
message MAY include additional Mobile Node information, if such
information was provided by the link layer. Upon receipt of the
request, oFA MUST respond with the Handoff Reply message, which
includes the Mobile Node's Home Address, Home Agent Address,
remaining registration lifetime and Link-Layer Address Extension. If
a GFA was used in the Mobile Node's registration, it's address MUST
be supplied. Regardless of the direction of the Handoff Request, if
nFA receives GFA information within the message from oFA, it SHOULD
issue a Regional Registration Request with the GFA, which will
respond with the Regional Registration Reply.
MIPv4 Handoffs Design Team [Page 18]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
4.3 Ping-Pong effect
Some link-layers are subject to rapid motion of MNs between two FAs.
For example, even though link-layer power measurements may indicate
that a hand-off is necessary, the mobile may fail to attach to the
new point of attachment, and return almost immediately to its old
point of attachment. This event is known as a "ping-pong" effect.
Data +-----+ Data +----+
+-------------| oFA |<--------------------------| HA |
| +-----+ +----+
v ^ |
+----+ Handoff | | Data
| MN | Request | |
+----+ | |
^ v v
| +-----+
+-------------| nFA |
Data +-----+
Figure 5 - Bi-Casting by the Anchor Foreign Agent
Figure 5 provides an example of bi-casting a Mobile Node's through
both the old and new Foreign Agents. Bi-casting is established when
the oFA issues a successful Handoff Reply to nFA, or receives a
successful Handoff Reply from nFA. This causes oFA to forward all of
the Mobile Node's traffic to the nFA, as well as to the Mobile Node,
if a link-layer channel exists.
Figure 6 provides an example where bi-casting is performed on the
Gateway Foreign Agent, which is initiated by nFA setting the 'S' bit
(Simultaneous Binding) in the Regional Registration Request.
Data +-----+ Data
+-------------| oFA |<-------------+
| +-----+ |
v |
+----+ +-----+ Data +----+
| MN | | GFA |<--------| HA |
+----+ +-----+ +----+
^ |
| +-----+ |
+-------------| nFA |<-------------+
Data +-----+ Data
Figure 6 - Bi-Casting by the Gateway Foreign Agent
When simultaneous bindings are in effect, and a ping-pong event
occurs, the mobile's service is guaranteed not to experience any
additional latency beyond that imposed by the link-layer handoff.
MIPv4 Handoffs Design Team [Page 19]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
4.4 Reverse Tunneling Support
In the event the Mobile Node requested Reverse Tunneling [5] support,
by setting the 'T' bit in its Registration Request, the Handoff
message from oFA (see Sections 4.7 and 4.8) includes the 'T' bit
enabled to inform nFA to establish a bi-directional tunnel for the
visitor entry.
4.5 Security Relationships
The Mobile IP Regional Registration specification [2] requires that
the communicating Mobility Agents exchange authenticated messages.
This imposes a requirement for Mobility Agents to share a pre-
established security association. This assumption is valid for intra-
domain mobility (mobility within an Administrative Domain). However,
such a requirement introduces a scaling problem when the Mobility
Agents are owned by separate Administrative Domains (ADs).
Given that the existing AAA infrastructure is used to establish
dynamic security associations between Foreign and Home Agents in
different ADs, the same infrastructure could be used to establish the
required security association for the purposes of inter-domain hand-
offs (see Figure 7).
+-----+ +-----+
| AAA |-------------->| AAA |
+-----+ +-----+
^ |
| |
| AAA |
| Hand-Off |
| Req |
| v
+-----+ +-----+
| oFA | | nFA |
+-----+ +-----+
+-----+ Movement +-----+
| MN | - - - - - - > | MN |
+-----+ +-----+
Figure 7 - Inter-FA communication using AAA
Note that it is possible for geographically neighboring Foreign
Agents owned by different Administrative Domains to have a pre-
established security association, which would reduce the latency
introduced by the AAA infrastructure traversal. Given that such
geographically neighboring FAs MAY be small in number, such an
approach MAY be reasonable.
MIPv4 Handoffs Design Team [Page 20]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
4.6 Operation
A Foreign Agent can receive two different types of triggers informing
it of a handoff (The event that causes the trigger may be derived via
link layer messaging assistance from the network or from the mobile):
- a "source trigger" is when the old FA is informed of an
upcoming link-layer handoff,
- a "target trigger" occurs at the new FA when it is informed
that a link layer handoff is in progress.
The method by which such triggers occur are link-layer specific, and
are outside the scope of this document. It is also possible that a
particular kind of link layer technology can support both source and
target triggers.
4.6.1 Foreign Agent Considerations
Upon receipt of a trigger event, a Foreign Agent MAY issue a Handoff
request message to the Foreign Agent the mobile is being handed off
to/from. If the message is the result of a target trigger, the Type
Of Trigger bit MUST be set and the Link-Layer Address Extension (see
Section 5) MUST be present. The message's Home Address and Home Agent
Address fields MAY be set to NULL if this information is not known at
the time the message is transmitted.
Upon receipt of a Handoff Request message with the Type Of Trigger
bit set, a Foreign Agent MUST respond with the Handoff Reply message.
The Handoff Reply MUST include both the Mobile Node's Home Address
and Home Agent Address in the message header. The remaining mobile's
registration lifetime MUST be included in the Reply's lifetime field.
Furthermore, the Foreign Agent MAY include any security associations
that were dynamically created. If a Gateway Foreign Agent was used in
the Mobile's registration, the GFA's identity MUST be included in the
Gateway Foreign Agent Address Extension [2] MUST be present.
A Foreign Agent that issues such a Handoff Reply with the Code field
set to success (zero value) MUST "bi-cast" all packets destined to
the Mobile Node to both the Mobile Node and to the new Foreign Agent.
The Foreign Agent that receives a successful Handoff Reply message
(one that includes a zero value in the Code field), a visitor entry
is created with the information found in the message. The Foreign
Agent MUST be prepared to deliver packets to the Mobile Node prior to
receiving a Registration Request [1] from the Mobile Node.
Note that it is possible for the encapsulation method used between
oFA and nFA to be different from the one requested by the Mobile Node
MIPv4 Handoffs Design Team [Page 21]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
during its Registration process. When this occurs, the respective
Foreign Agents MUST perform encapsulation translation.
A Foreign Agent that receives a source trigger, it MUST send a
Handoff Request message with the Type Of Trigger bit disabled. The
message MUST also include the Mobile Node's Home Address and Home
Agent Address in the message header. The remaining mobile
registration lifetime MUST be included in the lifetime field. The
Foreign Agent MAY also include any security associations that were
dynamically created. If a Gateway Foreign Agent was used for the
mobile, it's identity MUST be included in the Gateway Foreign Agent
Address Extension [2].
Upon receipt of a Handoff Request with the Type Of Trigger bit
disabled, a Foreign Agent MUST process the packet and respond with
the Handoff Reply message. If successfully processed, the Foreign
Agent MUST create a Visitor Entry for the Mobile Node, and be
prepared to deliver packets received by the initiator of the Handoff
Request destined for the Mobile Node. The Handoff Reply message MUST
include the Home Address, Home Agent Address, lifetime value, and the
Link-Layer Address Extension (see Section 5).
A Foreign Agent that receives a Handoff Reply with the Code field set
to success (zero value) MUST "bi-cast" all packets destined to the
Mobile Node to both the Mobile Node and to the new Foreign Agent. If
the message received by the new Foreign Agent contained a GFA IP
Address Extension [2], and it shares a security association with the
GFA, it MUST issue a Regional Registration Request to the GFA. The
Regional Registration Request's Care-Of address field MUST be set to
the local Foreign Agent's address, while the GFA IP Address MUST be
set to the address of the recipient of the request. The request's
lifetime field is set to an administratively configured value. A
successful Regional Registration Reply MUST cause the Foreign Agent
to create a visitor entry for the Mobile Node.
If a Regional Registration Reply message is received with the code
field set to DO_NOT_SERVICE_MN (Section 4.9), the Foreign Agent
SHOULD NOT provide service to the Mobile Node. The Foreign Agent MAY
enforce this by closing the Link-Layer connection (if possible), not
issuing any Mobility Advertisements to the Mobile Node (assuming a
point-to- point Link Layer), or simply denying all Registration
Requests with the error code set to 65 (Administratively Prohibited)
[1].
Once a visitor entry has been created, and the Mobile Node
establishes a link layer channel with the Foreign Agent, its traffic
will be immediately delivered, along with a Mobility Advertisement
message [1]. A Mobile Node MUST issue a Registration Request when it
receives a Mobility Advertisement from a new Foreign Agent.
MIPv4 Handoffs Design Team [Page 22]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
Note that Foreign Agents MAY delay in sending Mobility
Advertisements, especially to reduce noticeable service disruption
during a ping-pong effect. However, when doing so, the Foreign Agent
MAY need to re-issue a new Handoff Request to oFA (and optionally the
Regional Registration message to GFA), to extend the visitor entry's
lifetime.
Delaying Mobility Advertisements MAY also be done in wireless
technologies that support dormant mobiles. When this is done, a
Foreign Agent would typically wait to send the advertisement until
the mobile is no longer in the dormant mode. When data is received by
the Foreign Agent for a dormant Mobile Node, it SHOULD initiate the
link-layer mechanism that causes the mobile to "wake-up" (this is
typically known as paging).
The above procedures require that Foreign Agents issue Handoff
Requests as a result of Link-Layer triggers. However, the discovery
of the identity of the Foreign Agents to which the Handoff messages
must be sent is outside the scope of this document.
In the event that a Foreign Agent handling a particular Mobile Node's
visitor entry is soon to expire, and the Mobile Node has not yet
issued a Registration Request, the FA has the option to transmit a
new Handoff Request message to the old Foreign Agent (and the
optional Regional Registration Request to the GFA). Whether the
renewal is performed on behalf of the Mobile Node is a policy
decision up to the network administrator.
A Foreign Agent MAY receive packets for a Mobile Node to which it
does not have a direct link layer connection. At this point, the
Foreign Agent MAY:
1. Drop all packets for the Mobile Node
2. Buffer packets for the Mobile Node
3. Attempt to establish a link-layer connection with the mobile
4. Issue a Regional Registration Request with a zero lifetime
Given that a Mobile Node's packets will be delivered prior to
registration, a Mobile Node is free to discard all packets received
from Foreign Agents with which it hasn't registered.
When the new Foreign Agent receives the Mobile Node's Registration
Request [1], its Anchor Foreign Agent (GFA as first-hop router)
changes to the new Foreign Agent. The Foreign Agent MUST transmit a
Handoff Request message to the old Foreign Agent with the lifetime
field set to zero. A Foreign Agent that receives a Handoff Request
with the lifetime field set to zero is being informed that it is no
longer the anchor point for the mobile. It MAY issue a Handoff
Request to the new Foreign Agent in the future if it wishes to keep
receiving the mobile's packets for possible delivery.
MIPv4 Handoffs Design Team [Page 23]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
When a Foreign Agent determines that it is no longer servicing a
Mobile Node, it SHOULD issue a Regional Registration Request message
with the lifetime field set to zero (0). This will cause the visitor
entry associated with the Foreign Agent's Care-Of address on the GFA
to be deleted. Foreign Agents MAY decide to not issue this message
immediately when a link-layer trigger is received, in order to
support smooth service during a ping-pong event.
4.6.2 Gateway Foreign Agent Considerations
Upon receipt of a Regional Registration Request, a GFA MUST create a
visitor entry indicating the Mobile Node's current point of
attachment. In the event that a visitor entry already exists, the
GFA SHOULD be able to create multiple visitor entries for the same
Mobile Nodes with different Care-Of addresses. If the 'S' bit was
enabled in the Regional Registration Request, the GFA MUST be able to
forward the mobile's packets to all Foreign Agents in the visitor
entries.
When constructing the Regional Registration Reply, the GFA SHOULD
include the FA-FA authentication extension [2], and set the lifetime
field to the lesser of:
1. number of seconds before the Mobile Node's Registration with
its Home Agent will expire.
2. The lifetime of the locally created Visitor Entry.
In the event that the Regional Registration Request's lifetime field
was set to zero (0), the GFA MUST remove the visitor entry associated
with the Care-Of address in the message.
Should the GFA decide that the Foreign Agent is not to provide
service to the Mobile Node, it MUST issue a Regional Registration
Reply message, with the code field set to DO_NOT_SERVICE_MN (see
Section 4.9).
4.7 Handoff Request Message
The Handoff Request message is used to inform a peer that a pro-
active handoff is being initiated. The Handoff Request message can be
used for both source and target triggers, through the Type of Trigger
'I' bit in the message flags. When sent as a result of a target
trigger, the Home Address and Home Agent fields MAY be set to zero
(unless this information was communicated by the link layer, which is
outside the scope of this document).
MIPv4 Handoffs Design Team [Page 24]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |S|x|I|M|G|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type TBD (Handoff Request)
S When set, and when no GFA address extension is
present, it indicates that both oFA and nFA will
attempt to deliver datagrams directly to MN, if
a link-layer connection exists. If a GFA
address extension is present, it implies that
nFA should set the 'S' bit in its regional
registration.
I Type of Trigger. A value of zero is a source
trigger (sent by oFA), while a value of one is a
target trigger (sent by nFA).
M, G, T As defined in [1,5]. This refers to the
tunnel between oFA and nFA, or, if GFA IP
address extension is present, to the parameters
that should be requested in the Regional Reg
Req.
Lifetime The requested Lifetime for which nFA will serve
the MN on behalf of oFA, without requiring a new
registration.
MN Home Address The home address of the mobile node. When using
a private address, the G and T flags must be
sent and a GRE Key extension must be included.
Home Agent Addr The home agent address of the mobile node.
Identification As in defined in [1].
Extensions The Message MUST include LLA (see Section 5),
the FA-FA Authentication Extension [2], and MAY
include GFA IP address.
MIPv4 Handoffs Design Team [Page 25]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
4.8 Handoff Reply Message
The Handoff Reply message is sent in response to the Handoff Request
message. When a source trigger caused the Handoff Request message to
be sent, this message is sent with a successful code if the Visitor
Entry was successfully created. When a target trigger caused the
Handoff Request message, receipt of this message with a successfuly
code SHOULD cause the Visitor Entry to be created.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|x|I|M|G|r|T|x| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type TBD (Handoff Reply)
Code A value indicating the result of the Handoff
Request. See below for a list of currently
defined Code values.
Lifetime If the Code field indicates that the
registration was accepted, the Lifetime field is
set to the number of seconds remaining before
the registration is considered expired. A value
of zero indicates that the mobile node has been
deregistered. A value of 0xffff indicates
infinity. If the Code field indicates that the
registration was denied, the contents of the
Lifetime field are unspecified and MUST be
ignored on reception.
S When set, and when no GFA address extension is
present, it indicates that both oFA and nFA will
attempt to deliver datagrams directly to MN, if
a link-layer connection exists. If a GFA
address extension is present, it implies that
nFA should set the 'S' bit in its regional
registration.
MIPv4 Handoffs Design Team [Page 26]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
I Type of Trigger. A value of zero is a source
trigger (sent by oFA), while a value of one is a
target trigger (sent by nFA).
M, G, T As defined in [1,5]. This refers to the
tunnel between oFA and nFA, or, if GFA IP
address extension is present, to the parameters
that should be requested in the Regional Reg
Req.
MN Home Address The home address of the mobile node. When using
a private address, the G and T flags must be
sent and a GRE Key extension must be included.
Home Agent Addr The home agent address of the mobile node.
Lifetime The requested Lifetime for which nFA will serve
the MN on behalf of oFA, without requiring a new
registration.
Identification As in defined in [1].
Extensions The Message MUST include LLA (see Section 5)
and the FA-FA Authentication Extension [2].
4.9 Error Values
The following table contains the name of Code [6] to be returned in a
Registration Reply, the value for the Code, and the section in which
the error is first mentioned in this specification.
Error Name Value Section of Document
---------------------- ----- -------------------
DO_NOT_SERVICE_MN TBD 4.6.1
4.10 Security Considerations
Similar to [2], this specification assumes that the local Foreign
Agent, and the GFA inherently trust each other. This MAY be achieved
through the use of a long lived security association.
This specification introduces a new change to Mobile IP, which is the
ability for a Mobile Node to receive packets from a Foreign Agent to
which it has not yet registered. In the event that the Mobile Node
does not wish to receive packets from unknown Foreign Agents, it MAY
drop them.
Although this document does not specify how Foreign Agents can
identify, or track, Mobile Nodes, it is assumed that the wireless
MIPv4 Handoffs Design Team [Page 27]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
link layer be sufficiently secure in order to correctly identify a
Mobile Node. Wireless networks that do not provide such features will
be subjected to impersonation attacks, where malicious nodes could
cause the Foreign Agents to believe that a Mobile Node has moved to
other service areas.
4.11 Advantages and Applicability of NIMOT Handoff Method
The NIMOT handoff approach allows foreign agents to communicate
directly about a pending handoff, and does not require any IP layer
messages to be sent to or from a mobile node prior to the link layer
handoff event. Therefore, it does not place the mobile node's IP
stack or Mobile IP client implementation on the critical path after a
need for handoff is recognized but before the handoff can take place.
This separation is necessary when the link layer (or the laws of
physics) imposes hard deadlines on the time at which a handoff must
occur, such as when a mobile node is rapidly moving out of a radio
coverage area, but when the mobile node's IP stack is not implemented
as a hard real-time system.
Because a NIMOT handoff is triggered by some unspecified mechanism
that informs the old or new foreign agent that a handoff is needed,
the NIMOT approach is only applicable to networks where such a
mechanism is available. For example, a link layer may provide power
measurements or other indications of radio signal quality that cause
the old or new foreign agent to send the NIMOT handoff messages. Any
such indications must also provide each foreign agent involved in the
handoff with the identity of the other, so that messages can be sent
to the right place. This may involve mapping link layer information
onto foreign agent identities. Also, the foreign agents involved in
a handoff must have pre-provisioned security arrangements so that the
NIMOT messages can be authenticated. If a handoff is to be completed
as a result of the NIMOT messaging without continuing to bicast
traffic to both the old and new coverage areas, then any link layer
handoff indications must also be securely authenticated so that
traffic to the old point of attachment is not improperly halted.
MIPv4 Handoffs Design Team [Page 28]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
5. Generalized Link Layer Address Extension
This section defines the Generalized Link Layer Address (LLA)
Extension, used by any that needs to communicate Link Layer
Addresses. The format of the extension follows MIER [7], and each
sub-type of link-layer address defines its own sub-structure. This
draft defines two sub-types, the IMSI and the Ethernet Address.
Future RFCs should allocate their own sub-type and define their own
address formats.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
The length of the Link Layer Address + the one octet Sub-Type
field
Sub-Type
This field contains the Link Layer sub-type identifier
LLA
Contains the Link Layer Address
In this document, two subtypes are defined:
1 International Mobile Station Identity (e.g. [8])
2 Ethernet 48 bit MAC address [9]
3 64 bit Global ID, EUI-64 [10]
5.1 IMSI Link Layer Address Extension
The IMSI Link Layer Address Extension contains the International
Mobile Station Identity.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MIPv4 Handoffs Design Team [Page 29]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
Type
TBD (skippable) [1]
Length
The length of the IMSI field + the one octet Sub-Type field
Sub-Type
1
IMSI
Contains the IMSI, in the form:
<IMSI>:<Connection Id>
Where the <IMSI> is an ASCII-based representation of the
International Mobile Station Identifier, most significant digit
first, ":" is ASCII 0x3a, and the Connection ID is the ASCII
representation of a small, decimal number used for
distinguishing different link-layer connections from the same
device.
5.2 Ethernet Link Layer Address Extension
The Ethernet Link Layer Address Extension contains the 48 bit
Ethernet MAC Address, as defined in [9].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
7 (includes the Sub-Type field)
Sub-Type
2
MAC
MIPv4 Handoffs Design Team [Page 30]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
Contains the 48 bit Ethernet MAC Address.
5.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension
The 64-Bit Global Identifier (EUI-64) Address Extension contains the
64 bit address, as defined in [10].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
7 (includes the Sub-Type field)
Sub-Type
3
MAC
Contains the 64-Bit Global Identifier Address.
6. IANA Considerations
The number for the Generalized Link Layer Address Extension in
section 5 is taken from the numbering space defined for Mobile IP
registration extensions defined in RFC 2002 [1]. These MUST NOT
conflict with any numbers used in RFC 2002[1], RFC 2344 [5], RFC 2356
[12], RFC 2794 [13] and RFC 3012 [11].
In the NIMOT Handoffs method, the Code values specified for errors,
listed in section 4.9, MUST NOT conflict with any other code values
listed in RFC 2002 [1], RFC 2344 [5], RFC 2356 [12], RFC 2794 [13]
and RFC 3012 [11]. Also Sections 4.7 and 4.8 require numbers assigned
from the Mobile IP control message type address space. The numbers
assigned MUST NOT conflict with [1] and [2].
MIPv4 Handoffs Design Team [Page 31]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
7. References
[1] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October
1996.
[2] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional
Tunnel Management ", draft-ietf-mobileip-reg-tunnel-03.txt
(work in progress), July 2000.
[3] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels". BCP 14. RFC 2119. March 1997.
[4] C. Perkins and D. Johnson, "Route Optimization in Mobile
IP",draft-ietf-mobileip-optim-10.txt (work in progress),
November 2000.
[5] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344,
May 1998.
[6] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing
Encapsulation (GRE). Request for Comments (Informational)
1701, Internet Engineering Task Force, October 1994.
[7] M. Khalil, R. Narayanan, H. Akhtar and E. Qaddoura, "Mobile IP
Extensions Rationalization (MIER)", draft-ietf-mobileip-mier-
05 (work in progress), Dec. 1999
[8] TIA/EIA/IS-95-B
[9] D. Plummer, "An Ethernet Address Resolution Protocol - or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", RFC 826,
Symbolics,Inc., November 1982.
[10] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
March 1997.
[11] C. Perkins, P. Calhoun, Mobile IP Challenge/Response
Extensions. RFC 3012, November 2000.
[12] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal
for Mobile IP", RFC 2356, June 1998.
[13] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier
Extension", RFC 2794, March 2000.
MIPv4 Handoffs Design Team [Page 32]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
8. Authors' Addresses
The authors may be contacted at the addresses below:
Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vag. 8
126 25 Stockholm
SWEDEN
Phone: +46 8 7195803
Fax: +46 8 7190170
E-mail: Karim.El-Malki@era.ericsson.se
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650 786 7733
Fax: +1 650 786 6445
E-mail: pcalhoun@eng.sun.com
Tom Hiller
Lucent Technologies
Rm 2F-218
263 Shuman Blvd
Naperville, IL 60566-7050
USA
Phone: +1 630 979 7673
Fax: +1 630 979 7673
E-Mail: tom.hiller@lucent.com
James Kempf
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650 786 5890
Fax: +1 650 786 6445
E-mail: james.kempf@eng.sun.com
MIPv4 Handoffs Design Team [Page 33]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
Peter J. McCann
Lucent Technologies
Rm 2Z-305
263 Shuman Blvd
Naperville, IL 60566-7050
USA
Phone: +1 630 713 9359
Fax: +1 630 713 4982
E-Mail: mccap@lucent.com
Ajoy Singh
Motorola
1501 West Shure Drive
Arlington Heights, IL o 60004
USA
Phone: +1 847 632 6941
E-mail: asingh1@email.mot.com
Hesham Soliman
Ericsson Radio Systems
Torshamnsgatan 29, Kista
Stockholm
SWEDEN
Phone: +46 8 7578162
Fax: +46 8 4043630
E-mail: Hesham.Soliman@era.ericsson.se
Sebastian Thalanany
Motorola
1475 West Shure Drive
Arlington Heights, IL - 60004
USA
Phone: +1 847 435 9296
E-mail: sthalan1@email.mot.com
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Motorola M/S M8-540
6000 Connection Drive 1501 West Shure Drive
Irving, TX 75039 Arlington Heights, IL 60004
USA USA
MIPv4 Handoffs Design Team [Page 34]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
Phone: +1 972-894-6709 Phone: +1 847-632-3148
EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com
Fax : +1 972-894-5349
9. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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, 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 anyway, 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 onan
"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."
MIPv4 Handoffs Design Team [Page 35]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
Appendix A - Gateway Foreign Agents
The Mobile IP Regional Registration specification [2] introduces the
Gateway Foreign Agent (GFA), as a mobility agent that two Foreign
Agents providing service to a Mobile Node have in common. Figure 1
provides an example of a Mobile's initial registration, through the
GFA. Given this is the first registration message, the message MUST
be forwarded to the Home Agent. All packets destined for the mobile
will be delivered to the GFA, which in turn will forward the packets
to the Foreign Agent servicing the Mobile Node.
Reg Req +-----+ Reg Req
+----------->| oFA |--------------+
| +-----+ |
| v
+----+ +-----+ Reg Req +----+
| MN | | GFA |<------->| HA |
+----+ +-----+ +----+
+-----+
| nFA |
+-----+
Figure A.1 - Initial Registrations through GFA
In the event that the mobile moves to a new Foreign Agent that is
serviced by a GFA that is common with oFA, the Mobile Node MAY issue
a Regional Registration Request (see Figure A.2). The Regional
Registration message does not need to be forwarded to the Home Agent,
since the mobile's traffic can still be delivered to the same GFA.
This optimized approach effectively reduces the latency involved in
the registration process.
+-----+
| oFA |
+-----+
+----+ +-----+ +----+
| MN | | GFA | | HA |
+----+ +-----+ +----+
| ^
| +-----+ |
+------------>| nFA |-------------+
Regional Reg +-----+ Regional Reg
Figure A.2 - Regional Registration through GFA
Note that the GFA may also be the MN's first-hop router.
MIPv4 Handoffs Design Team [Page 36]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001
Appendix B - Bicasting Applicability Statement
Both NAMONC and NIMOT Handoffs propose using bicasting as a technique
for delivering packets to the MN through both the old and new FA.
Bicasting is used in order to avoid dropping packets while the
handoff is in progress and to decouple the handoff process from layer
2 handoff timing. Other techniques, for example buffering, have been
proposed for smooth handoff [4]. Since the interaction between TCP
and bicasting has not been fully studied, bicasting should be
considered only in cases where layer 2 support is available to co-
ordinate handoff such that duplicate packet delivery to the MN can be
reduced or avoided, until the interactions between TCP and bicasting
are more clearly understood. Neither low latency handoff technique is
dependent on the use of bicasting for low-loss handoffs, though a
low-loss handoff technique is required for a fully seamless solution.
MIPv4 Handoffs Design Team [Page 37]
