Mobile IP Working Group MIPv4 Handoffs Design Team
INTERNET-DRAFT Karim El Malki (Editor)
Expires: November 2001 Pat R. Calhoun
Tom Hiller
James Kempf
Peter J. McCann
Ajoy Singh
Hesham Soliman
Sebastian Thalanany
May 2001
Low Latency Handoff in Mobile IPv4
<draft-ietf-mobileip-lowlatency-handoffs-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
This document is a product of the Mobile IP WG.
Abstract
Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs
between subnets served by different Foreign Agents. 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. In addition, a combination of these two
methods is described. The described techniques allow greater support
MIPv4 handoffs design team [Page 1]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
for real-time services on a Mobile IPv4 network by minimising the
period of time when a Mobile Node is unable to send or receive IP
packets due to the delay in the Mobile IP Registration process.
TABLE OF CONTENTS
1. Introduction.....................................................3
1.1 Terminology .................................................3
1.2 The Techniques ..............................................5
1.3 L2 triggers .................................................6
1.4 Requirements language .......................................8
2. Requirements.....................................................9
3. The PRE-REGISTRATION Handoff Method..............................9
3.1 Operation .................................................10
3.2 Network-Initiated Handoff .................................11
3.3 Mobile-Initiated Handoff ..................................13
3.4 Obtaining and Proxying nFA Advertisements .................15
3.4.1 Inter-FA Solicitation.................................15
3.4.2 Tunneled nFA Advertisements...........................15
3.4.3 Piggy-backing Advertisements on L2 messaging.........16
3.5 Caching Router Advertisements .............................16
3.6 Movement Detection and MN Considerations ..................17
3.7 Simultaneous Bindings .....................................17
3.8 L2 Address Considerations .................................18
3.9 Applicability of PRE-REGISTRATION Handoff .................19
4. The POST-REGISTRATION Handoff Method............................20
4.1 Operation .................................................20
4.2 Role of BETs ..............................................23
4.3 Foreign Agent Considerations ..............................24
4.4 Handoff Request Message ...................................26
4.5 Handoff Reply Message .....................................27
4.6 Applicability of POST-REGISTRATION Handoff Method..........29
5. Combined Handoff Method.........................................30
6. Reverse Tunneling Support.......................................30
7. Generalized Link Layer Address Extension........................31
7.1 IMSI Link Layer Address Extension .........................31
7.2 Ethernet Link Layer Address Extension .....................32
7.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension ..33
7.4 Solicited IP Address Extension ............................33
7.5 Solicited Access Point Identifier Extension ...............34
8. IANA Considerations.............................................34
9. Security Considerations.........................................35
9.1 AAA Considerations for Security ...........................36
10. References.....................................................37
11. Authors' Addresses.............................................38
12. Full Copyright Statement.......................................40
Appendix A - Gateway Foreign Agents................................41
Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs......44
El Malki (Editor) et. al. [Page 2]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
1. Introduction
Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IP-layer
handoff between subnets served by different Foreign Agents (FAs). In
certain cases, the latency involved in handoff 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 handoff during movement between FAs.
The presented techniques allow greater support for real-time services
on a Mobile IPv4 network by minimising the period of time when a MN
is unable to send or receive IP packets due to the delay in the
Mobile IP Registration process.
In the rest of this section, terminology used throughout the document
is presented, the handoff techniques are briefly described, and the
use of link layer information is outlined. In Section 2, a brief
description of requirements is presented. Section 3 describes the
details of the PRE-REGISTRATION handoff technique, while Section 4
describes the details of the POST-REGISTRATION handoff technique. In
Section 5, ways to use both handoff techniques together are
presented. Section 6 discusses reverse tunneling support, while
Section 7 describes the protocol extensions required by the handoff
techniques. Sections 8 and 9 discuss IANA and security
considerations. Two appendicies discuss additional material related
to the handoff techniques. Appendix A describes how Regional
Registration [2] and simultaneous bindings can be used together with
low latency handoff. Appendix B discusses low latency handoff when a
MN has multiple wireless L2 interfaces, in which case the techniques
in this document may not be necessary.
1.1 Terminology
This section presents a few terms used throughout the document.
oFA - old Foreign Agent, the FA involved in handling a MN's
care of address prior to an L3 handoff.
nFA - new Foreign Agent, the FA anticipated to be handling a
MN's care of address after completion of an L3 handoff.
L2 handoff - Movement of a MN's point of Layer 2 (L2)
connection from one wireless access point to another.
L3 handoff - Movement of the FA handling a MN's care of address
at Layer 3 (L3) from oFA to nFA.
L2 trigger - Information from L2 that informs L3 of particular
events before and after L2 handoff. The descriptions of L2
triggers in this document are not specific to any particular
L2, but rather represent generalizations of L2 information
available from a wide variety of L2 protocols.
El Malki (Editor) et. al. [Page 3]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
source trigger - An L2 trigger that occurs at oFA, informing
the oFA that L2 handoff is about to occur.
target trigger - An L2 trigger that occurs at nFA, informing
the nFA that an MN is about to be handed off to nFA.
low latency handoff - L3 handoff in which the period of time
during which the MN is unable to receive packets is
minimized.
low loss handoff - L3 handoff in which the number of packets
dropped or delayed is minimized. Low loss handoff is often
called smooth handoff.
seamless handoff - L3 handoff that is both low latency and low
loss.
bicasting - The splitting of a stream of packets destined for a
MN via its current FA (the oFA) into two or more streams,
and the simultaneous transmission of the streams to oFA and
one or more nFA. Bicasting is a handoff smoothing technique
used to reduce packet loss during handover.
bi-directional edge tunnel (BET) - A particular kind of
bicasting in which the oFA bicasts packets destined for a MN
to both nFA and the L2 on which the MN previously resided.
The packets to nFA are tunneled. The tunnel is bi-
directional because nFA tunnels packets from MN while it is
using its old care of address back to oFA, so the packets
appear on a topologically correct network. If the packets
were not tunneled back to the oFA, they might be dropped by
egress filtering. Bi-directional edge tunnels are only
needed in POST-REGISTRATION handoff.
ping-ponging - Rapid back and forth movement between two
wireless access points due to failure of L2 handoff. Ping-
ponging can occur if radio conditions for both the old and
new access points are about equivalent and less than optimal
for establishing a good, low error L2 connection.
network-initiated handoff - L3 handoff in which oFA or nFA
initiates the handoff.
mobile-initiated handoff - L3 handoff in which the MN initiates
the handoff.
IP address identifier - An IP address of a MN or FA, or an L2
identifier that allows an FA to deduce the IP address of a
MN or FA. If the IP address identifier is an L2 identifier,
it may be specific to the L2 technology.
El Malki (Editor) et. al. [Page 4]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
1.2 The Techniques
Mobile IP was originally designed without any assumptions about the
underlying link layers over which it would operate so that it could
have the widest possible applicability. This approach has the
advantage of facilitating a clean separation between L2 and L3 of the
protocol stack, but it has negative consequences for handoff latency.
The strict separation between L2 and L3 results in the following
built-in sources of delay:
- The MN may only communicate with a directly connected FA. This
implies that a MN may only begin the registration process after
an L2 handoff to nFA has completed.
- The registration process takes some non-zero time to complete as
the Registration Requests propagate through the network. During
this period of time the MN is not able to send or receive
IP packets.
This document presents techniques for reducing these built-in delay
components of Mobile IP. The techniques can be divided into two
general categories, depending on which of the above problems they
are attempting to address:
- Allow the MN to communicate with the nFA while still connected
to the oFA.
- Provide for data delivery to the MN at the nFA even before the
formal registration process has completed.
The first category of techniques allows the MN to "pre-build" its
registration state on the nFA prior to an underlying L2 handoff.
The second category of techniques allow for service to continue
uninterrupted while the handoff is being processed by the network.
Three methods are presented in this draft to achieve low-latency L3
handoff, one for each category described above and one as a
combination of the two:
- PRE-REGISTRATION handoff method,
- POST-REGISTRATION handoff method,
- combined handoff method.
The PRE-REGISTRATION handoff method allows the MN to be involved in
an anticipated IP-layer handoff. The MN is assisted by the network in
performing an L3 handoff before it completes the L2 handoff. The L3
handoff can be either network-initiated or mobile-initated.
Accordingly, L2 triggers are used both in the MN and in the FA to
trigger particular L3 handoff events. The PRE-REGISTRATION method
El Malki (Editor) et. al. [Page 5]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
coupled to L2 mobility helps to achieve seamless handoffs between
FAs. The basic Mobile IPv4 concept involving advertisement followed
by registration is supported and the PRE-REGISTRATION handoff method
relies on Mobile IP security. No new messages are proposed, except
for an extension to the Agent Solicitation message in the mobile-
initiated case.
The POST-REGISTRATION handoff method proposes extensions to the
Mobile IP protocol to allow the oFA and nFA to utilize L2 triggers to
set up a registration on the nFA 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 to minimize
the impact on real-time applications. The MN must eventually perform
a formal Mobile IP registration after L2 communication with the new
FA is established. 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.
The combined method involves running a PRE-REGISTRATION and a POST-
REGISTRATION handoff in parallel. If the PRE-REGISTRATION handoff can
be completed before the L2 handoff completes, the combined method
resolves to a PRE-REGISTRATION handoff. However, if the PRE-
REGISTRATION handoff does not complete within an access technology
dependent time period, the oFA starts forwarding traffic destined to
the MN to the nFA as specified in the POST-REGISTRATION handoff
method. This provides for a useful backup mechanism when completion
of a PRE-REGISTRATION handoff cannot always be guaranteed before the
L2 handoff completion.
It should be noted that the methods described in this document may be
applied to MNs having a single interface (e.g. Wireless LAN
interface) or multiple interfaces (e.g. two WLAN interfaces, one WLAN
and one cellular interface). However, the case of multiply-interfaced
MNs needs special consideration, since the handoff methods described
in this document may not be required in all cases (see Appendix B).
1.3 L2 triggers
An L2 trigger is used to signal some event during the process of L2
handoff. One possible event is early notice of an upcoming change in
the L2 point of attachment of the mobile node to the access network.
Another possible event is the completion of relocation of the mobile
node's L2 point of attachment to a new L2 access point. This
information comes from L2 programmatically or is derived from L2
messages. Although the protocols outlined in this document make use
of specific L2 information, Mobile IP should be kept independent of
any specific L2. L2 triggers are an abstraction mechanism for a link
technology specific trigger. Therefore, an L2 trigger that is made
El Malki (Editor) et. al. [Page 6]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
available to the Mobile IPv4 stack is assumed to be generic and
technology independent. The precise format of these triggers is not
covered in this document, but the information required to be
contained in the L2 triggers for low latency handoffs is specified.
In order to properly abstract from the L2, it is assumed that one of
the three entities - the MN, oFA, or nFA - is made aware of the need
for an L2 handoff, and that the nFA or MN can optionally also be made
aware that an L2 handoff has completed. A specific L2 will often
dictate when a trigger is received and which entity will receive it.
Certain L2s provide advance triggers on the network-side, while
others provide advance triggers on the MN. Also, the particular
timing of the trigger with respect to the actual L2 handoff may
differ from technology to technology. For example, some wireless
links may provide such a trigger well in advance of the actual
handoff. In contrast, other L2s may provide no or little information
in anticipation of the L2 handoff.
An L2 trigger may be categorized according to whether it is
received by the MN, oFA, or nFA. Table 1 gives such a categorization
along with information expected to be contained in the trigger. The
methods presented in this document operate based on different types
of L2 triggers as shown in Table 1. Once the L2 trigger is received,
the handoff processes described in Sections 3 or 4 is performed.
El Malki (Editor) et. al. [Page 7]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
+-------------+----------------------+------------------------------+
| L2 trigger | mobile | source |
| | pretrigger | trigger |
| | (L2-MPT) | (L2-ST) |
+-------------+----------------------+------------------------------+
| Recipient | MN | oFA |
+-------------+----------------------+--------------+---------------+
| Method | PRE | PRE | POST |
| | mobile- | network- | source |
| | initiated | initiated | trigger |
+-------------+----------------------+--------------+---------------+
| When? | sufficiently before | sufficiently | sufficiently |
| | the L2 handover | before L2 | before L2 |
| | so that MN can | handover for | handover for |
| | solicit ProxyRtAdv | FA to send | oFA & nFA to |
| | from oFA. | proxyRtAdv | exchange |
| | | to MN. | HRq/HRy. |
+-------------+----------------------+--------------+---------------+
| Parameters | nFA IP address | nFA IP address identifier |
| | identifier | MN IP address identifier |
| | | |
+-------------+----------------------+------------------------------+
+------------+------------------------+-------------+---------------+
| L2 trigger | target | mobile | network |
| | trigger | handoff | handoff |
| | (L2-TT) | complete | complete |
| | | (L2-MHC) | (L2-NHC) |
|------------+------------------------+-------------+---------------+
| Recipient | nFA | MN | nFA |
|------------+------------+-----------+-------------+---------------+
| Method | PRE | POST | POST | POST |
| | network | target | (optional) | (optional) |
| | initiated | trigger | | |
|------------+------------------------+-------------+---------------+
| When? | | when radio | when radio |
| | same as | conditions | conditions |
| | source trigger | are OK for | are OK for |
| | | MIP register| MIP register |
|------------+------------------------+-------------+---------------+
| Parameters | oFA IP address id | none | none |
| | MN IP address id. | | |
|------------+------------------------+-------------+---------------+
Table 1 - L2 Triggers
1.4 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].
El Malki (Editor) et. al. [Page 8]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
2. Requirements
The following requirements are applicable to low-latency handoff
techniques and are supported by the methods in this document:
- provide low-latency and low loss handoff for real time services,
- minimize the effects at L3 of ping-ponging,
- no dependence on a wireless L2 technology,
- support inter- and intra-access technology handoffs,
- limit wireless bandwidth usage.
3. The PRE-REGISTRATION Handoff Method
The PRE-REGISTRATION handoff method is based on the original concept
of Mobile IP handoff as specified in [1], in which:
- an advertisement for an FA is received by an MN,
- the advertisement allows the MN to perform movement detection,
- the MN registers with the FA.
The PRE-REGISTRATION method allows both the MN and FA to initiate
handoff. In both cases, abiding by the basic Mobile IP handoff
concept allows the MN to choose with which FA to register. The PRE-
REGISTRATION method can make use of L2 triggers on either the FA or
MN side, depending on whether network-initiated or mobile-initiated
handoff occurs. PRE-REGISTRATION does not require any new messages to
be defined in the network-initiated case and specifies one new
extension to ICMP Solicitations for the mobile-initiated case.
The PRE-REGISTRATION method supports handoff for a single network
interface or between multiple network interfaces on the MN. The rest
of this section discusses single interface handoff, Appendex C
describes how multiple interface handoff is supported. PRE-
REGISTRATION also supports both the normal Mobile IP model [1] in
which the MN is receiving packets from a Home Agent (HA) and the
Regional Registration model [2] in which the MN receives packets from
a Gateway Foreign Agent (GFA). Finally PRE-REGISTRATION supports
movement to a new domain, in which a new AAA transaction must occur
to authenticate the MN with the new domain.
El Malki (Editor) et. al. [Page 9]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
3.1 Operation
The overall PRE-REGISTRATION Handoff mechanism is summarised in
Figure 1 below:
+---------+
| HA (GFA)|<---------+
+---------+ | 4. (Reg)RegReq
| 5. (Reg)RegReply
v
+-----+ 1a. RtSol +-----+
| | -----------------> | nFA |
| oFA | 1b. RtAdv | |
+-----+ <----------------- +-----+
^ | ^
(2a. ProxyRtSol) | | 2b /
| | ProxyRtAdv / 3. (Reg)RegReq
| | /
| v ---------------
+-----+ /
| MN |
+-----+ - - - - - ->
Movement
Figure 1 - PRE-REGISTRATION Handoff Protocol
The following steps provide more detail on the protocol:
1. Messages 1a and 1b contain a solicitation of a Router
Advertisement by oFA from nFA and a reply Router Advertisement from
nFA. These messages SHOULD occur in advance of the PRE-REGISTRATION
Handoff in order to not delay the handoff. For this to occur, oFA MAY
solicit and cache advertisements from the nFA, thus decoupling the
timing of this exchange from the rest of the PRE-REGISTRATION
Handoff. When the L3 handoff is initiated by a target L2 trigger at
nFA, message 1b is sent unsolicited directly to MN rather than
relayed by oFA.
2. The presence of message 2a indicates that the handoff is mobile-
initated and its absence means that the handoff is network-initiated.
In mobile-initiated handoff, message 2a occurs if there is an L2
trigger in the MN to solicit for a Proxy Router Advertisement. When
message 2a is received by the oFA, the oFA returns the Proxy Router
Advertisement in message 2b. In network-initiated handoff, the L2
trigger occurs at oFA and oFA relays the Router Advertisement in
message 2b without the need for MN to solicit. Note that it is also
possible for nFA to advertise directly to the MN in the network-
El Malki (Editor) et. al. [Page 10]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
initiated target-trigger case (section 3.2). In all cases message 2b
is simply nFA's router advertisement.
3. The MN performs movement detection upon receipt of either a
solicited or unsolicited Router Advertisement and, if appropriate, it
sends a Registration Request message [1] [2] in message 3 to nFA
requesting a simultaneous binding. Message 3 is routed through oFA
since the MN is not directly connected to nFA prior to the L2
handoff.
4. Messages 3, 4 and 5 constitute a standard Mobile IP Registration
[1] or Regional Registration [2]. The Registration Reply in message 5
MUST be copied by nFA to the MN both through oFA and directly on-
link. This is necessary, unless the L2/L3 interaction is engineered
such that the MN may not detach from oFA until it has received the
Reply. Since this will not always be the case, the Reply SHOULD be
tunneled by nFA to oFA and sent directly on-link. Figures 2 and 3
illustrate this tunneling, though it is not shown in Figure 1.
Tunneling can take place either at L3 or L2. The MN's L2 address may
be obtained using the extensions in Section 7, as described in 3.5.
5. Because of the uncertainty as to when the L2 connection between
the MN and the nFA becomes fully established and can be used for L3
traffic, simultaneous bindings with the GFA or the HA are used to
allow traffic for the MN to be sent to both the oFA and the nFA.
Between the time when the Registration Reply is sent from HA or GFA
to nFA and when the MN's connection on L2 at the nFA is fully
established, the HA or GFA bicasts traffic for the MN to both oFA and
nFA. The MN is able to receive traffic independently of the exact L2
handoff timing. Also, should the L2 handoff procedure fail,
terminate abruptly, or ping-pong, the use of simultaneous bindings
allows the MN to maintain L3 connectivity with the oFA, smoothing the
handoff.
PRE-REGISTRATION is not dependent on Regional Registration extensions
[2]. However if the HA is at a distance (in terms of delay) from the
nFA, the use of a local GFA reduces the time required for the handoff
procedure to complete.
Figures 2, 3, and 4 contain message timing diagrams for both the
network-initiated and mobile-initiated PRE-REGISTRATION handoff
procedures.
3.2 Network-Initiated Handoff
As described in Table 1, a PRE-REGISTRATION handoff can be initated
El Malki (Editor) et. al. [Page 11]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
at oFA by a source trigger or at nFA by a target trigger. A source-
triggered network-initiated handoff occurs when an L2 trigger is
received at the oFA informing it of a certain MN's upcoming movement
from oFA to nFA. The L2 trigger will contain information such as the
MN's IP address identifier (i.e. MN's IP address or identifier which
can be resolved by the oFA to the MN's IP address) and the nFA's IP
address identifier. An identifier may be specific to the wireless
technology (e.g. Access Point ID). A target-triggered network-
initiated handoff occurs when an L2 trigger is received at the nFA
informing it of a certain MN's upcoming movement from oFA. This type
of trigger is also shown in Table 1. The L2 trigger contains
information such as the MN's IP address identifier and the oFA's IP
address identifier.
In a source-triggered handoff, message 2b, the Proxy Router
Advertisement, is sent by oFA to the MN. Messages 1a and 1b are
exchanged by oFA and nFA before the L2 trigger is received. Message
2a is not used. In a target-triggered handoff, nFA tunnels an Agent
Advertisement directly to the MN to initiate the L3 handoff. The
inner Advertisement is unicast by nFA to MN, thus nFA treats the
target-trigger as a Router Solicitation. This Advertisement is
tunneled to oFA which functions as a normal router, decapsulating the
Advertisement and forwarding it to the MN.
Figures 2 and 3 contain message timing diagrams describing the PRE-
REGISTRATION network-initiated handoff for source and target
triggers.
MN oFA nFA HA/GFA
| |<~~~~~~ L2-Source | |
| | Trigger | |
|<--------------------| | |
| ProxyRtAdv | | |
| | | |
|---------------------------------------->| |
| HA Reg. or | | |
| RegReg (routed | |------------------->|
| via oFA if pre | | HA reg or RegReg |
| L2 Handoff) | | |
| | |<-------------------|
| | | Reg Reply |
| | | |
|<----------------------------------------| |
|<--------------------|<------------------| |
| | Reg Reply | |
| |(sent to MN through| |
oFA and directly)
Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram
(Network-Initiated, Source Trigger)
El Malki (Editor) et. al. [Page 12]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
MN oFA nFA HA/GFA
| | L2-Target~~~~~~~~>| |
| | Trigger | |
| | | |
| |...................| |
|<--------------------------------------- | |
| (ProxyRtAdv) |...................| |
| | Tunneled Agent | |
| | Advertisement | |
| | | |
|---------------------------------------->| |
| HA Reg. or | | |
| RegReg (routed | |------------------->|
| via oFA if pre | | HA reg or RegReg |
| L2 Handoff) | | |
| | |<-------------------|
| | | Reg Reply |
| | | |
|<----------------------------------------| |
|<--------------------|<------------------| |
| | Reg Reply | |
| |(sent to MN | |
tunneled through oFA and directly on-link)
Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram
(Network-Initiated, Target Trigger)
3.3 Mobile-Initiated Handoff
As shown in Table 1, a mobile-initiated handoff occurs when an L2
trigger is received at the MN informing it that it will shortly move
to nFA. The L2 trigger contains information such as the nFA's IP
address identifier (i.e. nFA's IP address or an identifier which can
be resolved by MN to the nFA's IP address). The message timing
diagram is shown in Figure 4.
As a consequence of the L2 trigger, the MN issues message 1a, the
Proxy Router Solicitation. The message is either:
- Unicast to nFA's IP address, in which case the procedure is a
normal agent solicitation, apart from having a TTL greater than 1.
- Unicast to oFA, in which case the solicitation is for a Proxy
Router Advertisement. This solicitation MUST have a TTL=1 as in [1].
Proxy Router Advertisement solicitation is required because the
amount of topological distance between nFA and MN could preclude a
Router Advertisement sent in reply prior to an L2 handoff. This is
different from [1], where a TTL of 1 is mandated.
El Malki (Editor) et. al. [Page 13]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
MN oFA nFA HA/GFA
|<~~~~~ L2-Trigger | | |
| | | |
|-------------------->| | |
| ProxyRtSol | | |
| | | |
|<--------------------| | |
| ProxyRtAdv | | |
| | | |
|---------------------------------------->| |
| HA Reg. or | | |
| RegReg (routed | |------------------->|
| via oFA if pre | | HA reg or RegReg |
| L2 Handoff) | | |
| | |<-------------------|
| | | Reg Reply |
|<----------------------------------------| |
|<--------------------|<------------------| |
| | Reg Reply | |
| |(sent to MN through| |
oFA and directly)
Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram
(Mobile-Initiated)
The Proxy Router Advertisement solicitation is an agent solicitation
with a special extension. The solicitation MUST have an extension
containing an IP address idenfifier because the MN is soliciting a
specific FA's advertisement from the oFA. This specific FA is the one
which will be its nFA. The IP address identifier contains the IP
address of the nFA or an identifier that can be used by the oFA to
resolve to nFA's IP address. If the identifier is not an IP address,
it may be specific to the underlying wireless technology, for
example, an Access Point or Base Station ID. The extension is a
subtype of the Generalised Link-Layer Address extension described in
Section 7. Two subtypes have been defined to contain the nFA's IP
address and an access point identifier They are called the Solicited
Agent IP Address Extension and the Access Point Identifier Extension,
and are described in Sections 7.4 and 7.5. Only one of the two should
be present in the MN's solicitation.
As a result of the MN solicitation message, the oFA sends message 2b,
the Proxy Router Advertisement, to the MN. The Proxy Router
Advertisement contains the agent advertisement for the requested nFA.
In order to expedite the handoff, the actual nFA advertisement SHOULD
be cached by the oFA following a previous exchange with nFA, shown in
messages 1a and 1b, and specified in Section 3.5.
El Malki (Editor) et. al. [Page 14]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
3.4 Obtaining and Proxying nFA Advertisements
If L2 triggers are involved in initiating PRE-REGISTRATION handoff,
the trigger timing SHOULD be arranged such that a full L3 PRE-
REGISTRATION handoff can complete before L2 handoff initiates. That
is, the L2 handoff should be initiated after the MN's Registration
with the nFA completes and produces a simultaneous binding at the
GFA/HA. The Registration MAY be transmitted more than once to reduce
the probability that it is lost due to errors on the wireless link.
A PRE-REGISTRATION handoff in this case requires the MN to receive
agent advertisements from the nFA through the old wireless access
point, and to perform a registration with the nFA through the old
wireless access point. Three ways of performing this are discussed in
the following subsections.
3.4.1 Inter-FA Solicitation
Inter-FA solicitation assumes that oFA has access to the IP address
of the nFA. The IP address of nFA is obtained either by means of an
L2 trigger at oFA in the network-initiated case (see Section 3.2) or
by means of the extension to the Proxy Router Solicitation from the
MN in the mobile-initiated case (see Section 3.3).
Conceptually, once the oFA has access to the address of the nFA for a
specific MN, it MUST send a unicast agent solicitation to nFA. The
nFA replies to the oFA by unicasting an Agent Advertisement with
appropriate extensions. This method removes the TTL limitation of [1]
for Mobile IP messages (i.e. TTL=1). The TTL limitation cannot be
applied since oFA and nFA may be more than one hop away and is
unnecessary for a unicast message in any case. Security between oFA
and nFA should be in place to ensure that agent solicitations and
advertisements are protected and to enable nFA to determine that oFA
is authorised to solicit agent advertisements.
As a practical matter, oFA SHOULD pre-solicit and cache
advertisements from known FAs topologically near it, in order to
prevent having to perform the above solicitation during an actual
handoff procedure (see Section 3.5).
3.4.2 Tunneled nFA Advertisements
Tunneling nFA advertisments assumes that nFA is aware of the IP
address for oFA and the MN. These IP addresses are obtained either by
means of the IP address identifiers in an L2 trigger at nFA in the
network-initiated case (see Section 3.2) or by means of the Proxy
Router Solicitation from the MN in the mobile-initiated case (see
Section 3.3). A solicitation from MN directly to nFA must reach nFA
and identify the oFA, so the solicitation must include an extension
containing an IP address identifier. This can be either oFA's IP
address or an Access Point identifier which may be specific to the
El Malki (Editor) et. al. [Page 15]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
underlying wireless technology. As a result of the tunneled
solicitation, the nFA sends a Router Advertisement tunneled to the MN
through oFA. This message is effectively message 2b, coming from nFA
instead and only routed through oFA.
However in [1] the MN cannot solicit an Advertisement from the nFA
directly (Mobile-Initiated Handoff) since it is not on the same link
as the MN. This restriction applies if the TTL must be 1 on Router
Solicitations. The same would apply to Router Advertisements from the
nFA, which also affects the Network-Initiated Handoff case. Therefore
tunneling advertisements is only applicable where the TTL limitation
of [1] can be relaxed. This should be the case for unicast messages.
3.4.3 Piggy-backing Advertisements on L2 messaging
Piggy-backing advertisements on L2 messaging involves utilizing the
L2 messaging involved in L2 handoff to transmit the Router
Advertisement from the nFA to the MN or oFA. When the first L2
handoff messages are exchanged, it may be possible to transmit a
Router Advertisement piggybacked onto L2 messages. Alternatively, the
L2 at oFA may cache nFA's advertisements and not need to receive
Router Advertisements upon every L2 handoff initiation. Whether this
technique is possible depends on the particulars of the L2 technology
and is outside the scope of this document.
3.5 Caching Router Advertisements
If done during a handoff, message exchange 1 in Figure 1 imposes an
additional latency penalty on the L3 handoff process. In order to
remove this source of latency, the inter-FA Router Solicitation and
Advertisement exchange SHOULD be performed in advance of handoff. A
process SHOULD be in place at the oFA to solicit its neighbouring
nFAs at a predefined time interval (MIN_SOLICITATION_INTERVAL). This
interval SHOULD NOT be set too small to avoid unnecessary consumption
of network bandwidth and nFA processing resources. The minimum value
of MIN_SOLICITATION_INTERVAL is 1 sec. If the FA Challenge/Response
mechanism in [11] is used then the MIN_SOLICITATION_INTERVAL must be
set to a value smaller or equal to the CHALLENGE_WINDOW (in nFA) so
that the nFA challenge does not expire before the MN issues the
Registration Request.
The oFA SHOULD cache the most recent advertisements from its
neighbouring nFAs. These advertisements should be sent to the MN in
message 2b with a TTL=1. The oFA SHOULD also have a mechanism in
place to create a list of neighbouring nFAs. The minimum support is
to manually configure a list of nFAs for each FA in the network with
which an L3 handoff is possible. The list will depend on deployment
and radio coverage. It is also possible to specify another protocol
to achieve nFA discovery, but it is outside the scope of this
document.
El Malki (Editor) et. al. [Page 16]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
3.6 Movement Detection and MN Considerations
When the MN receives an Agent Advertisement with a Mobility Agent
extension, it should perform actions according to the following
movement detection mechanisms. The MN MUST be:
- "Eager" to perform new bindings,
- "Lazy" in releasing existing bindings.
The above means that the MN MUST perform Registrations with any new
FA from which it receives an advertisement (i.e. MN is Eager), as
long as there are no locally-defined policies in the MN that
discourage the use of the discovered FA. For example, the MN may have
a policy based on the 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
old FA and the lifetime of its existing binding expires (i.e. MN is
Lazy).
If the MN has at least one existing binding with an FA, additional
simultaneous Registrations are performed requesting a short lifetime.
This is done to limit the lifetime of temporary bindings and
therefore limit bandwidth usage. Temporary bindings occur when the MN
is moving between FAs and uses PRE-REGISTRATION handoff to achieve
low loss IP mobility. By limiting the lifetime, the Registrations
time out quickly avoiding the need for the MN to cancel the
registration. Temporary bindings are also useful to support ping-
ponging between FAs.
3.7 Simultaneous Bindings
Simultaneous bindings are used by a GFA or HA to decouple L3 handoff
from L2 handoff and to reduce packet loss. Simultaneous bindings
allow a GFA or HA to bicast packets destined to the MN to multiple
potential future MN locations before the MN actually moves there.
Simultaneous bindings and bicasting are also useful to support ping-
ponging.
Using normal Mobile IP with an HA only and 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 in Section 3.6.
However, having multiple simultaneous bindings for the MN at the HA
causes the HA to send multiple copies of data packets towards
mutliple FAs that may be topologically distant. Bicasting from the HA
is not efficient unless the HA is close to the FAs in question. Also,
if the round-trip time between the HA and FAs is not negligible, the
MN's new Registration and therefore L3 handoff can be delayed.
El Malki (Editor) et. al. [Page 17]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
If a GFA is present, low loss handoff is achieved by bicasting
traffic from the GFA to the oFA and the nFA while the MN is moving
between them. The MN sets the "S" bit in the Registration Request
[2]. When a Regional Registration Request has the "S" bit set, the
receiving regional FA or GFA that has an existing binding with the MN
adds the relevant new binding for the MN but also maintains any
existing bindings it has for the MN, bicasting traffic to the MN at
both FAs.
If the MN has simultaneous active bindings with FAs, it could (but
preferably should not) receive multiple copies of the same traffic
directed to it. The use of simultaneous bindings does not mean that
the MN is receiving packets contemporarily from multiple sources.
This depends on the characteristics of the access (L2) technology.
The bicasting of packets involves 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 and fully establishes the new L2 link, the new
FA MAY receive packets for a MN to which it does not have a direct
link layer connection. The FA MAY:
- drop all packets for the MN, or
- buffer packets for the MN.
The choice of which action to take may depend on the type of traffic
involved, but this is outside the scope of this document. The MN MAY
also in parallel attempt to establish a link-layer connection with
the MN. An FA MUST NOT send ICMP Destination Unreachable messages if
it drops packets or is unable to deliver the received IP packets due
to unavailability of direct layer connection with the MN.
Appendix A contains more information about GFA considerations for the
PRE-REGISTRATION handoff.
3.8 L2 Address Considerations
If a wired backbone network connects wireless access points and the
wireless network is not bridged (i.e. the wireless access points are
not acting as routers) so that the FA is not directly on the same
link as the MN, the MN MAY use an L2 address extension to the
Registration message when the MN is performing a registration.
Because the MN is registering with an FA that is not its first-hop
router, the L2 address of the frame containing the MN's registration
packet is not MN's address. The MN must use some means to communicate
its L2 address other than the frame address, which is the method
specified in [1]. To communicate its L2 address, the MN includes a
Generalised Link Layer Extension (see Section 7) with its
registration. The FA uses the L2 address in the extension to
communicate with the MN. If a particular wireless L2 technology has
defined a special L2 interface to the wireless network that allows
the FA to resolve the mapping between an MN IP address and an L2
El Malki (Editor) et. al. [Page 18]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
address without the need to use the extension, the extension is not
needed.
3.9 Applicability of PRE-REGISTRATION Handoff
Security for the PRE-REGISTRATION handoff method is based on the same
security model as [1] including the use of AAA. A prerequisite for
PRE-REGISTRATION is that the FA or MN are able to obtain an L2
trigger informing them of a pending L2 handoff procedure. The target
of the L2 handoff is another access point or radio network which is
in the coverage area of a new FA. The L2 trigger information may be
in the form of IP address identifiers which may need to be resolved
to IP addresses using methods that may be specific to the wireless
network and are not considered here. If, for example, the FA
determines that the IP address of the new FA is within its coverage
area (i.e. is its own address) the PRE-REGISTRATION handoff should
not be initiated.
The L2 trigger must allow enough time for the PRE-REGISTRATION
handoff procedure to be performed. In many wireless L2 technologies,
the L2 handoff procedure involves a number of message exchanges
before the effective L2 handoff is performed. For such technologies,
PRE-REGISTRATION handoff 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 network such that this succession
of events is ensured.
The PRE-REGISTRATION Handoff method is applicable in the following
cases:
- when the MN has locally defined policies that determine a
preference for one access over another, for example service cost,
within the same or different technology, etc., and therefore
where it is necessary to allow the MN to select the appropriate FA
with which to connect,
- when L3 cannot rely upon L2 security between the MN and the FA to
make modifications to IP routing and therefore authenticated
Mobile IP messages are required,
- when the trigger to initiate the handoff is received at the MN.
In the first case it is necessary to involve eventual local MN
policies in the movement detection procedure as described in 3.2.
El Malki (Editor) et. al. [Page 19]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
4. The POST-REGISTRATION Handoff Method
The POST-REGISTRATION handoff method is based on a network-initiated
model of handoff. The technique does not require any MN involvement
until the actual L2 connection with nFA is completed. The oFA and nFA
perform a message exchange that allows the MN to establish a
temporary registration on the nFA until the MN performs a formal
Mobile IP FA registration. The technique derives its name because the
registration occurs after L2 handoff is complete. POST-REGISTRATION
makes use of bi-directional edge tunnels (BETs) to smooth packet
delivery while the MN is in transition between oFA and nFA. If the FA
determines that there is no change in the FA, based on the L2 trigger
information, then the POST-REGISTRATION handoff procedures are not
initiated. POST-REGISTRATION depends on standard AAA-based Mobile IP
security [13], but for true low-latency handoff, pre-established
security associations between FAs are necessary. In summary, POST-
REGISTRATION handoff covers new cases that are not addressed by the
framework in [1].
4.1 Operation
In the POST-REGISTRATION method, the FA issues handoff messages on
behalf of the Mobile Node, acting as a surrogate of sorts. The FA
becomes aware that a handoff is about to occur at L2 through the use
of an L2 trigger. An FA can receive two types of triggers, a source
trigger at oFA and a target trigger at nFA. Section 1.1 and Table 1
contain more details about source and target triggers.
Figures 5 and 6 contain message sequences for source and target
triggered POST-REGISTRATION handoff, respectively. Figures 7 and 8
contain message timing diagrams for the message sequences in Figures
5 and 6. In Figure 5, a source trigger is obtained by oFA when L2
detects that the MN is about to depart its coverage area. In Figure
6, a target trigger is obtained by the nFA when L2 detects that the
MN has just arrived in the coverage area of the nFA prior to the
completion of the L2 handoff. Note that both triggers are available
before the actual completion of the link layer handoff.
+-----+ 1. Handoff Request +-----+
| | -----------------> | |
0. Source ~~~> | oFA | | nFA |
Trigger | | 2. Handoff Reply | |
+-----+ <----------------- +-----+
^ |
3. Reg Request | | 4. Reg Reply
| v
+-----+ Movement +-----+
| MN | - - - - - - - - -> | MN |
+-----+ +-----+
Figure 5 - Source Trigger POST-REGISTRATION Handoff
El Malki (Editor) et. al. [Page 20]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
+-----+ 1. Handoff Request +-----+
| | <----------------- | |
| oFA | | nFA |<~~~~ 0. Target
| | 2. Handoff Reply | | Trigger
+-----+ -----------------> +-----+
^ |
3. Reg Request | | 4. Reg Reply
| v
+-----+ Movement +-----+
| MN | - - - - - - - - -> | MN |
+-----+ +-----+
Figure 6 - Target Trigger POST-REGISTRATION Handoff
The message sequences between oFA and nFA depicted in Figures 5 and 6
are very similar. The main difference is in the initiator of the
Handoff Request message. In both the source and target trigger
cases, an FA obtains link-layer information that indicates the
necessity of a handoff to the nFA. In the event of a source trigger,
oFA transmits a Handoff Request message to nFA. The Handoff Request
MUST include the MN's home address, HA address, remaining
registration lifetime, and a Generalized Link-Layer Address Extension
(see Section 7) with the MN's L2 address. Upon receipt of the
message, nFA MUST create the MN's visitor entry, and respond with the
Handoff Reply message.
In the event of a target trigger, the trigger occurs on nFA, and nFA
transmits a Handoff Request to oFA. The Handoff Request message MUST
include the MN's L2 address in a Generalized Link-Layer Address
Extension (see Section 7) in order for oFA to correctly identify the
MN. The request message MAY include additional MN information, if
such information was provided by the L2. Upon receipt of the request,
oFA MUST respond with the Handoff Reply message, including the MN's
home address, HA address, remaining registration lifetime and a
Generalized Link-Layer Address Extension with the MN's link layer
address.
El Malki (Editor) et. al. [Page 21]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
MN oFA nFA HA/GFA
| | | |
| | |<~~~~~~~ L2-TT |
| |<------------------| |
| | HReq(t) | |
| | | |
| |------------------>| |
| | HRply(t) | |
| | | |
| |...................| |
| |<----------------->| |
| |...................| |
|<--------------------------------------->| |
| | Tunneled Traffic | |
| | to/from MN | |
|<~ ~ ~ ~ L2-MHC | | |
| (optional) | | |
| | | |
|- - - - - - - - - - - - - - - - - - - - >| |
| RtSol | | |
| | |<~ ~ ~ ~ L2-NHC |
|<- - - - - - - - - - - - - - - - - - - - | (optional) |
| | RtAdv | |
| | | |
|------------------------------------------------------------->|
| HA Reg or RegReg | | |
| | | |
Figure 7 - POST-REGISTRATION Handoff Message Timing Diagram
(Target-Trigger)
Completion of POST-REGISTRATION handoff requires MN to perform a full
FA and HA/GFA registration. A trigger that signals the completion of
the handoff, designated as L2-NHC (Layer-2 Network Handoff Complete)
or L2-MHC (Layer-2 Mobile Handoff Complete) in Figures 7 and 8,
performs this function. If the MN receives an L2-MHC trigger, it
SHOULD send a Router Solicitation message. The Router Solicitation
causes nFA to send a Router Advertisement, allowing the MN to perform
a complete Mobile IP or Regional Registration. Alternatively, if the
nFA receives the L2-NHC trigger, nFA SHOULD send a Router
Advertisement, allowing the MN to perform a complete Mobile IP or
Regional Registration. The L2-MHC and L2-NHC triggers are optional.
If they are not available, the MN MUST wait until nFA sends a
periodic Agent Advertisement and MUST respond by registering with
nFA.
El Malki (Editor) et. al. [Page 22]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
MN oFA nFA HA/GFA
| |<~~~~~~ L2-ST | |
| | | |
| |------------------>| |
| | HReq(s) | |
| | | |
| |<------------------| |
| | HRply(s) | |
| |...................| |
| |<----------------->| |
| |...................| |
|<--------------------------------------->| |
| | | |
| | Tunneled Traffic | |
| | to/from MN | |
| | | |
|<~ ~ ~ ~ L2-MHC | | |
| (optional) | | |
| | | |
|- - - - - - - - - - - - - - - - - - - - >| |
| RtSol | | |
| | |<~ ~ ~ ~ L2-NHC |
|<- - - - - - - - - - - - - - - - - - - - | (optional) |
| | RtAdv | |
| | | |
|------------------------------------------------------------->|
| HA Reg or RegReg | | |
| | | |
Figure 8 - POST-REGISTRATION Handoff Message Timing Diagram
(Source Trigger)
4.2 Role of BETs
Bi-directional edge tunnels, or BETs, are used to achieve low loss of
traffic to and from the MN during a handoff and to smooth handoff
when an MN undergoes ping-ponging. The tunnel from nFA back to oFA
allows the MN to use its old care of address prior to registering
with nFA. If this tunnel is not established, the old care of address
cannot be used because it is topologically incorrect and may trigger
egress filtering in nFA's subnet, resulting in the MN's packets being
dropped.
Figure 9 provides an example of a BET. The BET is placed when the oFA
issues a successful Handoff Reply to nFA, or receives a successful
Handoff Reply from nFA. This causes oFA to forward the MN's traffic
to the nFA. The nFA forwards the traffic further to the MN if an L2
connection exists. In the reverse direction, as soon as MN comes up
on the L2 connection with nFA, it can start sending packets with the
old care of address, and nFA tunnels them to nFA, where they are
detunneled and forwarded as if they originated through oFA.
El Malki (Editor) et. al. [Page 23]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
Data +-----+ Data +----+
+------------>| oFA |<--------------------------| HA |
| +-----+ +----+
v ^ ^
+----+ Handoff | | Data
| MN | Request | |
+----+ | |
^ v v
| +-----+
+------------>| nFA |
Data +-----+
Figure 9 - Bi-Casting by the Foreign Agent
4.3 Foreign Agent Considerations
Upon receipt of a trigger event, an FA SHOULD issue a Handoff Request
message to the FA to which or from which the mobile is being handed
off.
If the message is the result of a target trigger, the Type Of Trigger
bit in the Handoff Request message MUST be set and the Generalized
Link-Layer Address Extension (see Section 7) MUST be present. The
sender of the Handoff Request is nFA and the handoff is target
triggered. The message's home address and HA 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, the oFA MUST respond with the Handoff Reply message. The
Handoff Reply MUST include both the MN's home address and HA address.
The MN's remaining registration lifetime MUST be included in the
Handoff Reply's lifetime field. Furthermore, the oFA issuing the
Handoff Reply MAY include any security associations that were
dynamically created. The oFA that issues a Handoff Reply with the
Code field set to success (zero value) MUST bi-cast all packets
destined to the MN to both the L2 to which the MN is currently
connected and by tunneling to the nFA.The oFA must also be prepared
to receive tunneled packets from the nFA in which the MN's packets
appear with the old care of address.
The nFA that receives a Handoff Reply message with a zero value in
the Code field creates a visitor entry with the information found in
the message. The FA MUST be prepared to deliver packets to the MN
prior to receiving a Registration Request [1] from the MN, and it
MUST be prepared to tunnel packets sent by the MN under the MN's old
care of address to oFA.
Note that it is possible for the encapsulation method used between
oFA and nFA to be different from the one requested by the MN during
El Malki (Editor) et. al. [Page 24]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
its Registration process. When this occurs, the respective FAs MUST
perform encapsulation translation.
An FA that receives a source trigger MUST send a Handoff Request
message with the Type Of Trigger bit disabled. The sender of the
Handoff Request message is the oFA and the handoff is source
triggered. The message MUST also include the MN's home address, the
HA address and the Link Layer Address extension (see section 7). The
MN's remaining registration lifetime MUST be included in the lifetime
field. The oFA MAY also include any security associations that were
dynamically created.
Upon receipt of a Handoff Request with the Type Of Trigger bit
disabled, the nFA MUST process the packet and respond with the
Handoff Reply message. If successfully processed, the nFA MUST create
a visitor entry for the MN, and be prepared to deliver tunneled
packets received by the initiator of the Handoff Request destined for
the MN, and to tunnel packets from the MN sent under its old care of
addres to the oFA. The Handoff Reply message MUST include the home
address, HA address, lifetime value, and the Generalized Link-Layer
Address Extension (see Section 7) with the MN's link layer address.
An oFA that receives a Handoff Reply with the Code field set to
success (zero value) MUST bi-cast all packets destined for the MN to
both the MN on the old L2 and by tunneling to the nFA. The oFA must
also be prepared to receive packets sent by the MN under its old care
of address on the new L2 that are tunneled by nFA.
Once a visitor entry has been created in nFA, and the MN establishes
an L2 connection with the nFA, its traffic will be immediately
delivered, along with an Agent Advertisement message [1]. The nFA can
determine when to send the Agent Advertisement by the L2-NHC trigger.
If the MN receives an L2-MHC trigger, it can send an Agent
Advertisement Solicitation. Alternatively, if neither L2 trigger is
available, the MN will respond to a periodic Agent Advertisement sent
according to [1]. In any case, the MN can continue to use its old
care of address without any delay in uplink L3 connectivity until it
is established on the new L3 since the nFA tunnels its packets back
to the oFA. An MN MUST issue a Registration Request when it receives
an Agent Advertisement from the nFA, completing the L3 handoff.
Note that the nFA MAY delay sending an Agent Advertisement,
especially to reduce noticeable service disruption during a ping-
pong. However, when doing so, the nFA MAY need to re-issue a new
Handoff Request to oFA, to extend the visitor entry's lifetime.
In the event that the visitor entry for an MN at nFA is about to
expire and the MN has not yet issued a Registration Request, the nFA
has the option to transmit a new Handoff Request message to the oFA
to renew the registration. Whether the renewal is performed on behalf
of the MN is a policy decision up to the network administrator.
El Malki (Editor) et. al. [Page 25]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
An FA MAY receive packets for a MN to which it does not have a direct
link layer connection. The FA MAY:
- drop all packets for the MN, or
- buffer packets for the MN.
The choice of which action to take may depend on the type of traffic
involved, but this is outside the scope of this document. The MN MAY
also in parallel attempt to establish a link-layer connection with
the MN. An FA MUST NOT send ICMP Destination Unreachable messages if
it drops packets or is unable to deliver the received IP packets due
to unavailability of direct layer connection with the MN. Given that
a MN's packets will be delivered prior to a proper registration, the
MN MAY discard all packets received from FAs with which it has not
registered.
When the nFA receives the MN's Registration Request [1] and the HA's
or GFA's successful Registration Reply [1][2], it MUST transmit a
Handoff Request message to the oFA with the lifetime field set to
zero. An oFA 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. The oFA SHOULD stop bicasting at this point, and tear
down the reverse tunnel from nFA, since the MN is now fully connected
at L3 on the new subnet. The oFA MAY issue a Handoff Request to the
nFA in the future if it wishes to keep receiving the mobile's packets
for possible delivery.
4.4 Handoff Request Message
The Handoff Request message is used to inform a peer that a POST-
REGISTRATION 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 HA fields MAY be set to zero
(unless this information was communicated by the link layer, which is
outside the scope of this document).
El Malki (Editor) et. al. [Page 26]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type TBD (Handoff Request)
S When set it indicates that both oFA and nFA will
attempt to deliver datagrams directly to MN, if
a link-layer connection exists.
I Type of Trigger. A value of zero is a source
trigger (request sent by oFA), while a value of
one is a target trigger (request sent by nFA).
M, G, T As defined in [1,5]. This refers to the
tunnel between oFA and nFA.
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 MN. When using
a private address, the G and T flags must be
sent and a GRE Key extension must be included.
HA Addr The HA address of the mobile node.
Identification As in defined in [1].
Extensions The Message MUST include LLA (see Section 7) and
the FA-FA Authentication Extension [2].
4.5 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, the Handoff Reply message is sent with a successful code if
the Visitor Entry was successfully created. When a target trigger
El Malki (Editor) et. al. [Page 27]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
caused the Handoff Request message, receipt of the Handoff Reply
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA 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 it indicates that both oFA and nFA will
attempt to deliver datagrams directly to MN, if
a link-layer connection exists.
I Type of Trigger. A value of zero is a source
trigger (reply sent by nFA), while a value of
one is a target trigger (reply sent by oFA).
M, G, T As defined in [1,5]. This refers to the
tunnel between oFA and nFA.
El Malki (Editor) et. al. [Page 28]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
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.
HA Addr The HA 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 7)
and the FA-FA Authentication Extension [2].
4.6 Applicability of POST-REGISTRATION Handoff Method
The POST-REGISTRATION handoff approach allows FAs to communicate
directly about a pending handoff, and does not require any IP layer
messages to be sent to or from a MN prior to the L2 handoff event.
Therefore, it does not place the MN'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 imposes hard deadlines on the time at
which a handoff must occur, such as when a MN is rapidly moving out
of a radio coverage area, but when the MN's IP stack is not
implemented as a hard real-time system.
Because a POST-REGISTRATION handoff is triggered by an unspecified
mechanism that informs the oFA or nFA that an L2 handoff is pending,
the POST-REGISTRATION approach is only applicable to networks where
such a mechanism is available. For example, an L2 may provide power
measurements or other indications of radio signal quality that cause
the oFA or nFA to send the POST-REGISTRATION handoff messages. Any
such indications must also provide each FA involved in the handoff
with the identity of the other, so that messages can be sent to the
right place. This may involve mapping L2 information onto FA IP
addresses. Also, the FAs involved in a handoff must have pre-
provisioned security arrangements so that the POST-REGISTRATION
messages can be authenticated. If a handoff is to be completed as a
result of the POST-REGISTRATION messaging without continuing to
bicast traffic to both the old and new coverage areas, any L2 handoff
indications must also be securely authenticated so that traffic to
the old point of attachment is not improperly halted.
POST-REGISTRATION handoff is appropriate in the following cases:
- L2 triggers are available on the network to indicate that L2
handoff is pending.
El Malki (Editor) et. al. [Page 29]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
- Pre-provisioned security mechanisms are in place to allow fast
and secure messaging between the FAs and between the MN and an FA.
- Access point choice by the MN is not a concern or choice requires
user intervention and therefore is not on the critical path for
handoff.
5. Combined Handoff Method
The combined method uses both PRE-REGISTRATION and POST-REGISTRATION
handoff by running the PRE-REGISTRATION method and in parallel
exchanging the POST-REGISTRATION handoff messages between oFA and
nFA. The only case not considered already in the POST-REGISTRATION
method is mobile-initiated handoff. In the mobile-initiated case, the
Handoff Request message is initated by the oFA or nFA when it
receives the Registration Request from the MN.
The combined method follows the PRE-REGISTRATION Handoff when it is
successful before the completion of the MN's L2 handoff. However, if
PRE-REGISTRATION does not complete prior to the expiration of a timer
on one or the other of the FAs, POST-REGISTRATION handoff is used.
Using POST-REGISTRATION handoff insulates the MN from delays caused
by errors such as loss of one of the Mobile IP messages involved in
PRE-REGISTRATION.
The start of POST-REGISTRATION is gated by the expiration of a timer
on the FAs. The timer is started at oFA following a source-trigger,
at nFA following the target-trigger, or at oFA and nFA following the
receipt of the Registration Request from the MN in the mobile-
initiated case. The timer is reset if the Registration Reply message
is received by the appropriate FA and sent to the MN.
Although the POST-REGISTRATION Handoff Request and Handoff Reply
messages are exchanged in advance, no forwarding of traffic between
oFA and nFA is performed unless the timer expires. The timer should
be set to a value that allows forwarding between oFA and nFA to occur
before the MN completes the L2 handoff to nFA.
6. Reverse Tunneling Support
The handoff methods support reverse tunneling. The MN may request
reverse tunneling [5] by setting the 'T' bit in its Registration
Request. In the case of POST-REGISTRATION, if the MN had requested
Reverse Tunneling previously at oFA, the Handoff message from oFA
(see Sections 4.7 and 4.8) includes the 'T' bit enabled to inform nFA
to establish a BET for the visitor entry. Typically, the 'T' bit will
always be set to ensure that any delays in the MN receiving its new
care of address do not result in any delay in uplink packet
transmission from the MN, but local policies and particular L2
El Malki (Editor) et. al. [Page 30]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
technologies may allow the reverse tunnel to be turned off unless the
MN specifically requests it.
7. Generalized Link Layer Address Extension
This section defines the Generalized Link Layer Address (LLA)
Extension, used by any node 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 five sub-types. 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, five 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]
4 Solicited IP Address
5 Solicited Access Point Identifier
The following subsections describe the extensions.
7.1 IMSI Link Layer Address Extension
The IMSI Link Layer Address Extension contains the International
Mobile Station Identity.
El Malki (Editor) et. al. [Page 31]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 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 | Length | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
7.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)
El Malki (Editor) et. al. [Page 32]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
Sub-Type
2
MAC
Contains the 48 bit Ethernet MAC Address.
7.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
9 (includes the Sub-Type field)
Sub-Type
3
MAC
Contains the 64-Bit Global Identifier Address.
7.4 Solicited IP Address Extension
The 32-bit Solicited IP Address Extension contains the IP address of
the agent (FA) being solicited. This extension MAY be present in an
ICMP Agent Solicitation as explained in Section 3.3.
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 | IP addr ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
El Malki (Editor) et. al. [Page 33]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
Type
TBD (skippable) [1]
Length
5 (includes the Sub-Type field)
Sub-Type
4
IP Address
Contains the 32-Bit IP Address of the solicited node.
7.5 Solicited Access Point Identifier Extension
The 32-bit Solicited Access Point Identifier Extension contains an
Identifier of the Access Point to which the MN will move. This may be
a wireless L2 identifier. The MN is able to solicit an advertisement
from the FA servicing a certain Access Point by using this extension
with Agent Solicitations as explained in Section 3.3.
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 | AP ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
5 (includes the Sub-Type field)
Sub-Type
5
AP ID
Contains the 32-Bit Access Point Identifier.
8. IANA Considerations
Section 7 introduces the Generalized Link Layer Address Extension
numbering space that requires IANA management. This specification
El Malki (Editor) et. al. [Page 34]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
makes use of the values 1-5, and all other values other than zero (0)
are available for assignment via IETF consensus [14]. The numbers for
the Generalized Link Layer Address Extension are 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 POST-REGISTRATION Handoffs method, Sections 4.4 and 4.5
require numbers assigned from the Mobile IP control message type
address space. The numbers assigned MUST NOT conflict with [1] and
[2].
9. Security Considerations
A security consideration for PRE-REGISTRATION method involves
changing the TTL for Router Advertisement messages sent between oFAs
and nFAs, where multiple hops are present between oFA and nFA. The
same applies to Registration Request messages sent by the MN to nFA
routed through oFA and similarly Registration Reply messages. As
discussed in Section 3.8, oFA and nFA must share a security
association and oFA must be authorized to solicit nFA and relay
Registration Request/Reply. In addition, the case involving tunneling
of Agent Advertisements between the nFA and the MN requires
restricitions to be relaxed so the TTL of the Router Advertisement is
not required to be 1, as described in Section 3.4.2. Otherwise, PRE-
REGISTRATION uses AAA-based security for both inter-domain and intra-
domain handoff as described in [1] and [2]. Also, if the FA
Challenge/Response mechanism in [11] is used then the
MIN_SOLICITATION_INTERVAL must be set to a value smaller or equal to
the CHALLENGE_WINDOW (in nFA) so that the nFA challenge does not
expire before the MN issues the Registration Request.
POST-REGISTRATION introduces a new change to Mobile IP, which is the
possibility that a MN may receive packets from an FA with which it
has not yet registered. In the event that the MN does not wish to
receive packets from unknown FAs, it MAY drop them. In a similar way
to PRE-REGISTRATION, oFA and nFA must share a security association
required to protect the Handoff Request and Reply messages.
Since the techniques outlined in this document depend on particular
aspects of L2 handoff to optimize performance, some amount of L2
security is assumed. Both techniques depend on L2 triggers, and the
security of handoff requires that the L2 triggers be secure. In
addition, the POST-REGISTRATION technique depends on the ability of
the wireless network to securely identify MNs. Although this document
does not specify how FAs can identify or track MNs, it is assumed
that the wireless L2 is sufficiently secure in order to correctly
identify a MN. Wireless networks that do not provide such features
will be subject to impersonation attacks, where malicious nodes could
cause FAs to believe that a MN has moved to other service areas, and
El Malki (Editor) et. al. [Page 35]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
to allow a bogus MN to obtain unauthorized service from an FA prior
to performing a Mobile IP registration. The PRE-REGISTRATION
technique instead depends on Mobile IP security between MN and FA, so
the same security considerations in [1] apply.
9.1 AAA Considerations for Security
For handoff between Administrative Domains (ADs), both techniques may
experience additional latency if the MN must establish a security
association with nFA prior to the handoff taking effect. For PRE-
REGISTRATION, the need to establish a security association could
delay the registration process so that no Registration Reply is
received. For POST-REGISTRATION, it could result in the MN's traffic
being delayed until the completion of a formal Mobile IP registration
rather than as soon as the MN establishes an L2 connection at nFA.
This section discusses an approach for reducing latency due to the
need to establish a new security association.
+-----+ +-----+
| AAA |-------------->| AAA |
+-----+ +-----+
^ |
| |
| AAA |
| Hand-Off |
| Req |
| v
+-----+ +-----+
| oFA | | nFA |
+-----+ +-----+
+-----+ Movement +-----+
| MN | - - - - - - > | MN |
+-----+ +-----+
Figure 11 - Inter-FA communication using AAA
If the existing AAA infrastructure is used to establish dynamic
security associations between FAs and HAs in different ADs, the same
infrastructure could be used to establish the required security
association for the purposes of inter-domain handoff as shown in
Figure 11.
Note that it is possible for geographically neighboring FAs owned by
different ADs 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.
El Malki (Editor) et. al. [Page 36]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
10. 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.
[14] T. Narten, H, Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998
El Malki (Editor) et. al. [Page 37]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
11. 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
Sun Microsystems Laboratories
Sun Microsystems, Inc.
901 San Antonio Rd., UMTV 29-221
Palo Alto, California, 94303
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
Sun Microsystems Laboratories
Sun Microsystems, Inc.
901 San Antonio Rd., UMTV29-221
Palo Alto, California, 94303
USA
Phone: +1 650 336 1684
Fax: +1 650 691 0893
E-mail: james.kempf@sun.com
El Malki (Editor) et. al. [Page 38]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 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 Megisto Systems Inc.
6000 Connection Drive EMail: proberts@megisto.com
Irving, TX 75039
USA
Phone: +1 972-894-6709
El Malki (Editor) et. al. [Page 39]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
EMail: Raj.Patil@nokia.com
Fax : +1 972-894-5349
12. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, 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."
El Malki (Editor) et. al. [Page 40]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 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 FAs
providing service to a MN have in common. Figure A.1 provides an
example of a MN's initial registration through the GFA. If this is
the first registration message, the message MUST be forwarded to the
HA. All packets destined for the mobile will be delivered to the GFA,
which in turn will forward the packets to the FA servicing the MN.
Reg Req +-----+ Reg Req
+----------->| oFA |--------------+
| +-----+ |
| v
+----+ +-----+ Reg Req +----+
| MN | | GFA |<------->| HA |
+----+ +-----+ +----+
+-----+
| nFA |
+-----+
Figure A.1 - Initial Registrations through GFA
If the MN moves to a nFA that is serviced by a GFA common with oFA,
the MN MAY issue a Regional Registration Request (see Figure A.2).
The Regional Registration message does not need to be forwarded to
the HA, since the MN'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.
El Malki (Editor) et. al. [Page 41]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
A.1 GFA Considerations in the PRE-REGISTRATION Method
When there is a hierarchy of foreign agents between the GFA and the
announcing FA, the announcing FA MAY include the corresponding FA
addresses in order between its own address (first) 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.
The MN needs to choose the appropriate HA address in the Regional
Registration Request. The following two subsections discuss options.
A.1.1 Mobility Agent Extension Advertises FA and GFA Address Only
In this case, there is always a single path from the MN to the GFA.
The MN always performs Regional Registrations using the GFA address
as the HA address and the advertising FA as care of address. As the
Regional Registration Request is relayed towards the GFA, each FA
receiving it checks whether it has an existing binding with the MN
and whether the Regional Registration has the "S" bit set to request
simultaneous bindings. If this is true and the Regional Registration
is validated by the GFA, the FAs activate the simultaneous binding
upon receiving the successful Regional Registration Reply from the
GFA. It is not necessary to advertise all FA addresses in the
hierarchical branch to the MN, thus reducing bandwidth usage over the
wireless link.
A.1.2 Mobility Agent Advertisement Extension Advertises all FAs
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 previously
unseen FA that has a different Mobility Agent Advertisement
extension, it is eager to perform a new binding. The MN compares the
IP addresses in the new Mobility Agent Advertisement extension with
the cached Advertisements for its active bindings. If there is an IP
address in common between these extensions, named the common route FA
or GFA, the MN uses that IP address as the HA address and the
destination address of its Regional Registration Request. In the case
of a request for bicasting, the "S" bit is set. The care-of address
El Malki (Editor) et. al. [Page 42]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
is the advertising FA's address. The MN adds 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 returns a Regional Registration Reply to the
MN.
If there is no IP address in common between the extensions, then the
MN has moved into a new hierarchy and the GFA advertised in the new
extension is different from the one in the previously cached
extensions. When the MN changes GFA, the MN uses the new GFA's IP
address as care of address in its new Registration Request to the HA
and adds 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 performs a low loss handoff as explained in this
document.
The MN is able to perform GFA registration during PRE-REGISTRATION
handoffs only if its binding lifetime with the GFA or HA does not
expire during the period needed by the MN to run PRE-REGISTRATION and
complete its L2 handoff. Intermediate regional FAs are able to accept
the MN's regional registration as simultaneous bindings only if the
intermediate regional FA has an existing active binding for the MN.
The resulting simultaneous binding therefore has 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.
El Malki (Editor) et. al. [Page 43]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs
For MNs that have two wireless network interfaces, either on the same
wireless network or on wireless networks having different wireless L2
technologies, the techniques discussed in this draft may be
unnecessary if the Mobile IP stack on the MN allows switching an IP
address binding between interfaces. This Appendix discusses how
multiple wireless interfaces can aid low latency handoff.
Figure B.1 illustrates the normal and hierarchical MIPv4 models. As
shown in the figure, assume that the MN is connected to Radio Network
1 (RN1) and is registered with oFA through which it is receiving
traffic. Suppose MN enters the coverage area of RN2 and nFA and 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 activates the interface to RN2 but continues communicating
through RN1. The MN may solicit advertisements from nFA through the
interface connected to RN1 to speed up the handoff process, provided
there is no TTL restriction, or it can solicit advertisements through
the interface connected to RN2 if it has been configured for IP
traffic.
+------+ +---------+
| HA |--------| (GFA) |
+------+ +---------+
/ \
/ \
... ...
/ \
/ \
+------+ +------+
| oFA | | nFA |
+------+ +------+
| |
+------+ +------+
| RN1 | | RN2 |
+------+ +------+
+------+
| MN | --------->
+------+
Movement
Figure B.1 - Network Model for Mobile IPv4 With Multi-Access
Once the MN is registered with nFA and is successfully receiving and
transmitting through the new network, it tears down the interface to
El Malki (Editor) et. al. [Page 44]
INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001
RN1. If the MN has enough time to complete this procedure without
incurring degraded service or disconnection, the MN would experience
a seamless multi-access handoff but it may not be possible in all
cases, due to network coverage or for other reasons. Should multiple
interface handoff be possible then the low latency methods described
in this document are not necessary.
In order to support the possible failure of the connectivity with the
new network (RN2/nFA) in the short period following handoff, the MN
may use the "S" bit in its Mobile IP Registration Request to maintain
simultaneous bindings both its existing (HA or GFA) binding with oFA
and a new binding with nFA.
El Malki (Editor) et. al. [Page 45]
