WDIFF

draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt --> draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt

Mobile IP Working Group MIPv4 Handoffs Design Team
INTERNET-DRAFT Karim El Malki (Editor)
Expires: August November 2001 Pat R. Calhoun
Tom Hiller
James Kempf
Peter J. McCann
Ajoy Singh
Hesham Soliman
Sebastian Thalanany

February 23,

May 2001

Low latency Handoffs Latency Handoff in Mobile IPv4
<draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt>
<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 RFC2026. 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 an individual submission to the IETF. Comments
should be directed to a product of the authors.

Abstract Mobile IP (RFC2002) WG.

Abstract

Mobile IPv4 describes how a Mobile Node (MN) can perform IP-
layer IP-layer handoffs
between subnets served by different Foreign Agent (FA) subnets. 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 (movement between FA subnets). These 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 February May 2001

greater support

for real-time services on a Mobile IPv4 network by minimising the
period of service disruption 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 Introduction.....................................................3
1.1 Terminology .................................................3
1.2 The Techniques ..............................................5
1.3 L2 triggers .................................................6
1.4 Requirements language........................................4 language .......................................8
2. Requirements....................................................4 Requirements.....................................................9
3. Network Assisted, Mobile and Network Controlled (NAMONC) The PRE-REGISTRATION Handoff
Method..........................................................4 Method..............................9
3.1 Initiating NAMONC Handoffs through the "previous" FA.........9
I. 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 .....................................10
II. Solicitation.................................15
3.4.2 Tunneled nFA Advertisements...........................15
3.4.3 Piggy-backing Advertisements on L2 messaging.............10
3.2 messaging.........16
3.5 Caching Router Advertisements .............................16
3.6 Movement Detection and MN Considerations.....................10
3.3 Regional Deregistration for NAMONC Handoffs..................13
3.4 Smooth Handoffs between Hierarchies (GFAs)...................13
3.5 Considerations ..................17
3.7 Simultaneous Bindings .....................................17
3.8 L2 Address Considerations for NAMONC Handoffs................14
3.6 Advantages and .................................18
3.9 Applicability of NAMONC PRE-REGISTRATION Handoff Method........15 .................19
4. Network Initiated, Mobile Terminated (NIMOT) The POST-REGISTRATION Handoff Method....15 Method............................20
4.1 Registration Latency........................................16 Operation .................................................20
4.2 Movement Detection..........................................17 Role of BETs ..............................................23
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 Considerations ..............................24
4.4 Handoff Request Message.....................................24
4.8 Message ...................................26
4.5 Handoff Reply Message.......................................26
4.9 Error Values................................................27
4.10 Security Considerations.....................................27
4.11 Advantages and Message .....................................27
4.6 Applicability of NIMOT POST-REGISTRATION Handoff Method....... 28 Method..........29
5. Combined Handoff Method.........................................30
6. Reverse Tunneling Support.......................................30
7. Generalized Link Layer Address Extension.......................29
5.1 Extension........................31
7.1 IMSI Link Layer Address Extension...........................29
5.2 Extension .........................31
7.2 Ethernet Link Layer Address Extension.......................30
5.3 Extension .....................32
7.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension....31

6. IANA Considerations.............................................31

7. References......................................................32 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..............................................33 Addresses.............................................38
12. Full Copyright Statement.......................................40
Appendix A - Gateway Foreign Agents................................36 Agents................................41
Appendix B - Bicasting Applicability Statement.....................37

MIPv4 Low Latency Handoffs Design Team for Multiply-Interfaced MNs......44

El Malki (Editor) et. al. [Page 2]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

1. Introduction

Mobile IPv4 (RFC2002) [1] describes how a Mobile Node (MN) can perform IP-layer handoffs
handoff between subnets served by different Foreign Agent (FA) subnets. Agents (FAs). In
certain cases, the latency involved in these handoffs 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 handoffs (movement handoff during movement between FA subnets).
These FAs.
The presented techniques allow greater support for real-time services
on a Mobile IPv4 network by minimising the period of service disruption time when a MN
is unable to send or receive IP packets due to the delay in the
Mobile IP Registration process.

The two methods presented in

In the rest of 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 section, terminology used throughout the MN to be involved in an anticipated IP-layer
handoff procedure. The MN document
is therefore assisted by presented, 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 techniques are briefly described, 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 link layer 2 mobility may help
in achieving seamless (low latency + low loss) handoffs between
Foreign Agents. However L2 connectivity may cause packet losses. information is outlined. In
addition to handling Section 2, a brief
description of requirements is presented. Section 3 describes the simple case
details of a MN, FA, and Home Agent, the
NAMONC Handoff method also allows PRE-REGISTRATION handoff technique, while Section 4
describes the use details 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 POST-REGISTRATION handoff technique. In
Section 5, ways to activate
multiple interfaces 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 thus be data-connected 9 discuss IANA and security
considerations. Two appendicies discuss additional material related
to multiple access
points simultaneously, the MN may not need to support anticipated handoff techniques. Appendix A describes how Regional
Registration [2] and simultaneous bindings and may achieve seamless handoffs simply by
establishing connectivity through registrations 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 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 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
and involved in handling a MN's
care of address prior to an L3 handoff.

nFA - new Foreign Agent, the FA anticipated to utilize information from layer 2 (the L2 "trigger") to
set up be handling a kind
MN's care of address after completion of an L3 handoff.

L2 handoff - Movement of "pre-registration" prior to receiving a formal
Registration Request MN's point of Layer 2 (L2)
connection from one wireless access point to another.

L3 handoff - Movement of the Mobile Node. This enables FA handling a very rapid
establishment MN's care of service address
at the new point of attachment so Layer 3 (L3) from oFA to nFA.

L2 trigger - Information from L2 that the
effect informs L3 of the handoff on real-time applications is minimized,
although the MN must eventually perform a formal Mobile IP
registration. particular
events before and after L2 handoff. The proposed extensions make a few minimal assumptions
about support descriptions of L2
triggers in this document are not specific to any particular
L2, but rather represent generalizations of L2 information
available from the link layer. Although the assumptions
address the kinds a wide variety of link layer support available in existing radio

MIPv4 Handoffs Design Team L2 protocols.

El Malki (Editor) et. al. [Page 3]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

link layers,

source trigger - An L2 trigger that occurs at oFA, informing
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 oFA that L2 handoff but it requires
the active involvement by is about to occur.

target trigger - An L2 trigger that occurs at nFA, informing
the mobile nFA that an MN is about to switch from one network
interface be handed off to another. This technique covers a nFA.

low latency 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 - L3 handoff in which the features and advantages period of each method will
be described later. NAMONC and NIMOT handoffs may be implemented
independently. It time
during which the MN is up unable to receive packets is
minimized.

low loss handoff - L3 handoff in which the implementor, based on 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 link-layer
characteristics simultaneous transmission of the specific implementation streams to oFA and the features
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
each method supplied
bicasting 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 oFA bicasts packets destined for a MN
to be interpreted as
described in [3].

2. Requirements both nFA and the L2 on which the MN previously resided.
The following requirements are applicable packets to low-latency handoffs and nFA are supported 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 both methods:

- Support delay-sensitive (real-time) services
egress filtering. Bi-directional edge tunnels are only
needed in domain POST-REGISTRATION handoff.

ping-ponging - Support back-and-forth Rapid back and forth movement of MN between FAs (ping-pong)
- No dependency on a two
wireless access points due to failure of L2 technology
- Support Inter handoff. Ping-
ponging can occur if radio conditions for both the old and Intra-access technology handoffs
- Limit wireless bandwidth usage

3. Network Assisted, Mobile
new access points are about equivalent and Network Controlled (NAMONC) Handoff
Method

This method is intended to support less than optimal
for establishing a good, low latency IP-layer handoffs for: error L2 connection.

network-initiated handoff - Multi-access mobility
(different access technologies; L3 handoff in which oFA or nFA
initiates the handoff.

mobile-initiated handoff - L3 handoff in which the MN and network controlled) initiates
the handoff.

IP address identifier - Single-access mobility
(same access technology; An IP address of a MN and network controlled)

This method considers both or FA, or an L2
identifier that allows an FA to deduce the normal Mobile IP model [1] and address of a
MN or FA. If the
Regional (hierarchical) Mobile IP model [2]. These are shown in
Figure 1 where address identifier is an L2 identifier,
it may be specific to the Access Points (APs) or Radio Networks (RNs) are

MIPv4 Handoffs Design Team L2 technology.

El Malki (Editor) et. al. [Page 4]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

used to provide

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 MN with wireless or wired clean separation between 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 the
protocol stack, but it has negative consequences for handoff (as RFC2002)
FA controls advertisements (which cause MN handoff) latency.
The strict separation between L2 and can
accept/reject registrations.

- No new messages L3 results in the following
built-in sources of delay:

- Maintain RFC2002 concept thus allowing The 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 may only communicate with a directly connected FA. This
implies that a MN may only begin the registration process after
an 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 to nFA has completed.

- The registration process takes some non-zero time to complete as
the normal and hierarchical MIPv4 models. In Registration Requests propagate through the
simplest multi-access or single-access case where network. During
this period of time the MN is not able to
activate more than one interface (corresponding to different send or the
same access technologies) and thus receive
IP packets.

This document presents techniques for reducing these built-in delay
components of Mobile IP. The techniques can be data-connected to multiple
access points simultaneously it is possible divided into two
general categories, depending on which of the above problems they
are attempting to achieve low-latency
handoffs in a relatively simple manner. Assume that address:

- Allow the MN is
connected to RN2 and is registered communicate 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 nFA while still connected
to this network the oFA.

- Provide for reasons
beyond data delivery to the scope of this document (e.g. user preferences, cost, QoS
available etc.). MN at the nFA even before the
formal registration process has completed.

The first category of techniques allows the MN would then activate to "pre-build" its
registration state on the interface nFA prior to RN1 as
well as continue communicating through RN2. an underlying L2 handoff.
The MN may solicit
advertisements from FA1 second category of techniques allow for service to speed up continue
uninterrupted while the handoff process. Once it is
registered with FA1 and is successfully receiving and transmitting
through being processed by the new network it may then tear down the interface network.

Three methods are presented in this draft to RN2.
If achieve low-latency L3
handoff, one for each category described above and one as a
combination of the MN has enough time to complete this procedure without
incurring degraded service or disconnection then it would provide two:

- PRE-REGISTRATION handoff method,

- POST-REGISTRATION handoff method,

- combined handoff method.

The PRE-REGISTRATION handoff method allows the MN with a seamless multi-access handoff. In order to support the
possible failure of the connectivity with be involved in
an anticipated IP-layer handoff. The MN is assisted by the new network (RN1/FA1) in
performing an L3 handoff before it completes the short period following L2 handoff. The L3
handoff can be either network-initiated or mobile-initated.
Accordingly, L2 triggers are used both in 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 FA to this scenario.

MIPv4 Handoffs Design Team
trigger particular L3 handoff events. The PRE-REGISTRATION method

El Malki (Editor) et. al. [Page 5]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

_________ _________
| | | |
| HA |--------| (GFA) |________
|_________| |_________| \
/ | \ \
\
... ... ... \
\
______/_ _\______ |
| | | | |
| FA2 | | FA1 | |
|________| |________| |
____|___ ____|___ ____|___
| | | | | |
| AP/RN 2| | AP/RN 1| | AP/RN 3|
|________| |________| |________|
| ____|___
| |
CN | MN |
|________|

Figure 1 - Normal(HA only) and Hierarchical(HA

coupled to L2 mobility helps to achieve seamless handoffs between
FAs. The basic Mobile IPv4 concept involving advertisement followed
by registration is supported and GFA) MIPv4 model

In the remaining part of PRE-REGISTRATION handoff method
relies on Mobile IP security. No new messages are proposed, except
for an extension to the description of the NAMONC Handoffs
method, Agent Solicitation message in the scenarios for single and multi-access handoffs will be
considered. In these scenarios mobile-
initiated case.

The POST-REGISTRATION handoff method proposes extensions to the MN is unable
Mobile IP protocol to activate allow the oFA and
communicate over more than one interface or connection nFA to utilize L2 triggers to
set up a registration on the
network. This may be due nFA prior to limitations imposed by receiving a formal
Registration Request from the access
technology or configuration Mobile Node. This enables a very rapid
establishment of service at the mobile node. In these cases it is
necessary new point of attachment to anticipate the IP-layer handoff before minimize
the MN's movement
actually happens in order to achieve impact on real-time applications. The MN must eventually perform
a seamless mobility effect as
close as possible to that described previously.

In Figure 1, using normal formal Mobile IP (no GFA) the MN MAY perform
registrations registration after L2 communication with the HA using simultaneous bindings. This new
FA is
described in [1] 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 method to anticipate MN movement active involvement by
interacting with the wireless L2 is described later in this draft.
Simultaneous bindings are used mobile to decouple switch from one
network interface to another.

The combined method involves running a PRE-REGISTRATION and a POST-
REGISTRATION handoff in parallel. If the IP-layer PRE-REGISTRATION handoff from can
be completed before the L2 handoff by having data reaching completes, the multiple possible MN
locations before combined method
resolves to a PRE-REGISTRATION handoff. However, if the MN moves there since PRE-
REGISTRATION handoff does not complete within an access technology
dependent time period, the details of oFA starts forwarding traffic destined to
the L2
handoff timing are unknown MN to L3. "Bicasting" or simultaneous
bindings are also 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 support "ping-pong" or fast back-and-
forth MN movement between FAs due to fast mobility 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
failures. methods described
in this document may not be required in all cases (see Appendix B).

1.3 L2 triggers

An alternative method L2 trigger is used to perform improved handoffs, namely Smooth
Handoffs, signal some event during the process of L2
handoff. One possible event is described early notice of an upcoming change in [4]. The method for NAMONC Handoffs
addresses
the need L2 point of attachment of the mobile node to support services having strict delay bounds
(i.e. real-time) which 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 certain cases may this document make use
of specific L2 information, Mobile IP should be hard to support if

MIPv4 Handoffs Design Team 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 February May 2001

traffic has

available to be forwarded between FAs using Smooth Handoffs. This
is especially true if the two FAs are not directly connected. If
there Mobile IPv4 stack is a common router or router network connecting the two FAs assumed to be generic and
the HA, forwarding traffic between FAs would cause twice the
bandwidth usage on the common router/s and a considerable increase
technology independent. The precise format of these triggers is not
covered in
delay. Also, this document, but the information required to be
contained in the non-realtime case L2 triggers for low latency handoffs is specified.

In order to properly abstract from the L2, it may be possible is assumed that one of
the new
FA receives both buffered traffic from three entities - the previous FA (smooth
handoff) and traffic from MN, oFA, or nFA - is made aware of the HA which could cause some delayed need
for an L2 handoff, and
possibly out-of-order packets to that the nFA or MN can optionally also be delivered to 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. This could
affect Also, the performance particular
timing 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 trigger with respect to the HA actual L2 handoff may
differ from technology to send multiple copies of data packets towards mutliple
FAs which technology. For example, some wireless
links may be provide such a trigger well in advance of the same region or domain. actual
handoff. In terms contrast, other L2s may provide no or little information
in anticipation of bandwidth
usage this would not be efficient unless the HA L2 handoff.

An L2 trigger may be categorized according to whether it is close
received by the MN, oFA, or nFA. Table 1 gives such a categorization
along with information expected to be contained in the FAs trigger. The
methods presented 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 document operate based on different types
of signalling messages to the home network. This achieves a
reduction L2 triggers as shown in Table 1. Once the signalling delay when a Mobile Node moves between
Foreign Agents and therefore improves L2 trigger is received,
the performance of such
handoffs. This draft handoff processes described in Sections 3 or 4 is applicable to single-level (GFA only with no
regional FAs) and multi-level Hierarchical performed.

El Malki (Editor) et. al. [Page 7]

INTERNET-DRAFT Low Latency 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 May 2001

Table 1 - L2 Triggers

1.4 Requirements language

In this document, the
MN's movement is achieved 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 tight coupling with Layer 2
functionality the methods in this document:

- provide low-latency and low loss handoff for real time services,

- minimize the FA which 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 dependent based on the type original concept
of access
technology used. Bicasting is achieved through simultaneous bindings,
where the MN activates the "S" bit Mobile IP handoff as specified in the Registration Request
(described [1], in [1]). In a hierarchical MIPv4 network, when a Regional
Registration Request has the "S" bit set, the receiving regional which:

- an advertisement for an FA
or GFA which has is received by an existing binding with MN,

- the advertisement allows the MN will add to perform movement detection,

- the
relevant new binding for MN registers with the FA.

The PRE-REGISTRATION method allows both the MN but will also maintain any other
existing bindings it had for and FA to initiate
handoff. In both cases, abiding by the MN.

When basic Mobile IP handoff
concept allows the MN has multiple active bindings to choose with FAs, it MAY receive
multiple copies of the same traffic directed which FA to it. register. The PRE-
REGISTRATION method can make use of
simultaneous bindings L2 triggers on either the FA or
MN side, depending on whether network-initiated or mobile-initiated
handoff occurs. PRE-REGISTRATION does not necessarily mean that require any new messages to
be defined in the MN is

MIPv4 Handoffs Design Team [Page 7]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001

receiving packets contemporarily from 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 sources. This depends network interfaces on the characteristics of the access (L2) technology. MN. The bicasting rest
of packets this section discusses single interface handoff, Appendex C
describes how multiple interface handoff is used to anticipate the MN's movement and speed up
handoffs by sending a copy of the data to supported. PRE-
REGISTRATION also supports both the FA normal Mobile IP model [1] in
which the MN is
moving to. Until receiving packets from a Home Agent (HA) and the
Regional Registration model [2] in which the MN actually completes the L2 handoff receives packets from
a Gateway Foreign Agent (GFA). Finally PRE-REGISTRATION supports
movement to the a 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 domain, in
3.1, depending on the L2 characteristics, it is also possible for an
MN to initiate which a NAMONC Handoff through the "previous" FA without
having direct access new AAA transaction must occur
to authenticate the "new" FA. 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 NAMONC PRE-REGISTRATION Handoff mechanism is summarised in
Figure 2 1 below:

+-----+

+---------+
| GFA |<---------+
+-----+ HA (GFA)|<---------+
+---------+ | 4. RegRegReq. (Reg)RegReq
| 5. RegRegReply (Reg)RegReply
v
+-----+ (1a RtSol) 1a. RtSol +-----+
| | -----------------> | nFA |
| oFA | 1b.RtAdv 1b. RtAdv | |
+-----+ <----------------- +-----+
^ | ^
(2a. RtSol) ProxyRtSol) | | 2b. 2b /
| | ProxyRtAdv / 3. RegRegReq (Reg)RegReq
| | /
| v ---------------
+-----+ /
| MN |
+-----+ - - - - - ->
Movement

Figure 2 1 - NAMONC PRE-REGISTRATION Handoff Message exchange Protocol

The following steps provide more detail on the protocol:

1. Messages 1a and 1b (Router Solicitation contain a solicitation of a Router
Advertisement by oFA from nFA and a reply Router Advertisement)
should Advertisement from
nFA. These messages SHOULD occur in advance of the NAMONC PRE-REGISTRATION
Handoff and should in order to not delay the sending of message 2b. handoff. For this purpose the old FA (oFA) to occur, oFA MAY
solicit and cache advertisements from the new FA (nFA), nFA, thus decoupling the
timing of this exchange from the rest of the NAMONC PRE-REGISTRATION
Handoff. Message 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 router advertisement. Proxy Router Advertisement. When
message 2a is received by the oFA, the oFA returns the Proxy Router
Advertisement in message 2b. In network-controlled wireless
systems network-initiated handoff, the L2
trigger will be in the network occurs at oFA and will reach oFA
which will transmit relays the Proxy Router Advertisement (message 2b). This
is simply nFA's advertisement relayed by oFA. The in
message 2b without the need for MN will perform 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, send it
sends a Regional Registration Request message [1] [2] (message 3) in message 3 to nFA
requesting a simultaneous binding. Message 3 may be is routed through oFA
since the MN is not directly connected to nFA at this point. prior to the L2
handoff.

4. Messages 3, 4 and 5 are

MIPv4 Handoffs Design Team [Page 8]

INTERNET-DRAFT Low Latency constitute a standard Mobile IPv4 Handoffs February 2001

described in IP Registration
[1] or Regional Registration [2]. The Regional Registration Reply (message 5) needs
to in message 5
MUST be forwarded copied by nFA to the MN. Unless MN both through oFA and directly on-
link. This is necessary, unless the system L2/L3 interaction is engineered
such that the MN may not detach from oFA until it has received the
Reply, the MN may at
Reply. Since this time have disconnected. Therefore will not always be the case, the Reply
should SHOULD be copied
tunneled by nFA to the MN's old location (tunnelling the
Regional Registration Reply to oFA) oFA and to the MN's new location. 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 new L2 address may
be obtained using the extensions in section
5, Section 7, as described in 3.5. At this moment it may still not be known at
L3 whether

5. Because of the uncertainty as to when the L2 connection between
the MN has detached and connected to nFA. Even if it was
known at the exact instant, in most wireless systems there would not nFA becomes fully established and can be enough time used for L3
traffic, simultaneous bindings with the GFA or the HA are used to react and forward
allow traffic for the MN to be sent to both the MN's new
location by oFA and the nFA.
Between the time when 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 HA or GFA
to nFA, nFA and when the MN's connection on L2 at the nFA is fully
established, the HA or GFA will start bicasting bicasts traffic for the MN to both oFA and
nFA. Therefore the The MN will be is able to receive traffic independently of the exact L2
handoff timing. Also, should the L2 handoff procedure fail or fail,
terminate abruptly, or ping-pong, the use of simultaneous bindings
allows the MN to maintain L3 connectivity with oFA. The same stands for the case in which oFA, smoothing the MN
performs "ping-pong" or fast back-and-forth movement between FAs,
where simultaneous bindings allow continued L3 connectivity without
handoff.

PRE-REGISTRATION is not dependent on Regional Registration extensions
[2]. However if the need to continuously receive advertisements and send registration
messages. This reduces HA is at a distance (in terms of delay) from the signalling load over
nFA, the air interface.
Note that this method can be applied to use of a local GFA reduces the case where multiple
possible nFAs are identified by oFA.

3.1 Initiating NAMONC Handoffs through time required for 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 handoff
procedure to perform a NAMONC Handoff it is
necessary complete.

Figures 2, 3, and 4 contain message timing diagrams for some form of interworking between layers 2 both the
network-initiated and 3 to
determine when mobile-initiated PRE-REGISTRATION handoff
procedures.

3.2 Network-Initiated Handoff

As described in Table 1, a L3 PRE-REGISTRATION handoff should can be triggered initated

El Malki (Editor) et. al. [Page 11]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001

at oFA by a L2 handoff. It
should be noted that the method used source trigger or at nFA by an FA to determine when a MN
has initiated target trigger. A source-
triggered network-initiated handoff occurs when an L2 handoff (L2 trigger) for which the FA should
initate a NAMONC Handoff trigger is outside
received at the scope oFA informing it of this draft and may
involve interaction with L2 messaging. If the FA determines from the a certain MN's upcoming movement
from oFA to nFA. The L2 trigger that movement between FAs will not occur then contain information such as the NAMONC
Handoff should not
MN's IP address identifier (i.e. MN's IP address or identifier which
can be initiated. When this is not resolved by the case, oFA to the
interaction between L2 MN's IP address) and L3 (on the network side and/or MN-side)
should allow the Mobile Node nFA's IP
address identifier. An identifier may be specific to complete a L2 the wireless
technology (e.g. Access Point ID). A target-triggered network-
initiated handoff (resulting in
movement between FAs) after having performed occurs when an L2 trigger is received at the L3 NAMONC Handoff
described nFA
informing it of a certain MN's upcoming movement from oFA. This type
of trigger is also shown in this draft. That is, the Table 1. The L2 handoff should be completed
after trigger contains
information such as the MN's Registration with IP address identifier and the "new" FA which produces oFA's IP
address identifier.

In a
simultaneous binding at source-triggered handoff, message 2b, the GFA/HA. This Registration may be
transmitted more than once Proxy Router
Advertisement, is sent by oFA to reduce the probability that it MN. Messages 1a and 1b are
exchanged by oFA and nFA before the L2 trigger is lost
due received. Message
2a is not used. In a target-triggered handoff, nFA tunnels an Agent
Advertisement directly 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 initiate the "old" wireless access points, and L3 handoff. The
inner Advertisement is unicast by nFA to
perform MN, thus nFA treats the
target-trigger as a registration with Router Solicitation. This Advertisement is
tunneled to oFA which functions as a normal router, decapsulating the "new" FA through
Advertisement and forwarding it to the "old" wireless
access point. This procedure should be performed before MN.

Figures 2 and 3 contain message timing diagrams describing the layer-2 PRE-
REGISTRATION network-initiated 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 for source 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 target
triggers.

MN initiates an oFA nFA HA/GFA
| |<~~~~~~ L2-Source | |
| | Trigger | |
|<--------------------| | |
| ProxyRtAdv | | |
| | | |
|---------------------------------------->| |
| HA Reg. or | | |
| RegReg (routed | |------------------->|
| via oFA if pre | | HA reg or RegReg |
| L2 handoff
from AP/RN1 Handoff) | | |
| | |<-------------------|
| | | Reg Reply |
| | | |
|<----------------------------------------| |
|<--------------------|<------------------| |
| | Reg Reply | |
| |(sent 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 through| |
oFA 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 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 and cannot send an
advertisement to it. Therefore it is necessary for the 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 procedures
(which must be common Handoff) | | |
| | |<-------------------|
| | | Reg Reply |
| | | |
|<----------------------------------------| |
|<--------------------|<------------------| |
| | Reg Reply | |
| |(sent to AP/RN1 MN | |
tunneled through oFA and AP/RN2) to interwork with Mobile
IP.

Once 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 L2 mobile-initiated handoff is initiated, such that AP/RN2 and AP/RN1 are in
communication, it is possible for AP/RN2 to solicit occurs when an advertisement
from FA2 and transfer it to AP/RN1. Once this L2
trigger is received by the MN, at the MN can perform a registration directed informing it that it will shortly move
to FA2 even though 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
has no data-connection to AP/RN2 yet. the nFA's IP address). The precise definition message timing
diagram is shown in Figure 4.

As a consequence of such the L2 procedures is outside trigger, 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 issues message 1a, the GFA address (last)
Proxy Router Solicitation. The message is either:

- Unicast to nFA's IP address, in which case the Mobility Agent Advertisement
extension of its Agent Advertisements. If there are only two
hierarchical levels, procedure is a foreign
normal agent announces itself and solicitation, apart from having a GFA in
the Agent Advertisement; in the first and last address in the care-of
address field TTL greater than 1.

- Unicast to oFA, in which case the Mobility Agent Advertisement extension. There
must be at least one care-of address solicitation is for a Proxy
Router Advertisement. This solicitation MUST have a TTL=1 as in the Mobility Agent [1].

Proxy Router Advertisement extension. If there is only one care-of address it solicitation is required because the address
amount of the GFA, topological distance between nFA and the MN is connected directly to it.

When the MN receives an Agent Advertisement with could preclude a Mobility Agent
extension and the "I" bit set, as specified
Router Advertisement sent in [2], it should perform
actions according reply prior to the following movement detection mechanisms. In an L2 handoff. This is
different from [1], where a Hierarchical TTL of 1 is mandated.

El Malki (Editor) et. al. [Page 13]

INTERNET-DRAFT Low Latency 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 IPv4 Handoffs May 2001

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 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 which discourage
the use of this FA (e.g. cost of service). through| |
oFA and directly)

Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram
(Mobile-Initiated)

The method by which the MN
determines whether the FA is a "new" FA Proxy Router Advertisement solicitation is described in [1] and may
make use of an FA-NAI agent solicitation
with a special extension. However The solicitation MUST have an extension
containing an IP address idenfifier because the MN MUST NOT release
existing bindings until it no longer receives is soliciting a
specific FA's advertisement from the
relative oFA. This specific FA and is the lifetime of its existing binding expires (Lazy).

It should one
which will be noted that its nFA. The IP address identifier contains the MN may add a Hierarchical FA extension to
Registration Requests in order to identify IP
address of the exact FA path to nFA or an identifier that can be
followed used by the Registration Request. This extension must oFA to
resolve to nFA's IP address. If the identifier is not an IP address,
it may be
removed by regional FAs.

If specific to the MN has at least one existing binding with underlying wireless technology, for
example, an Access Point or Base Station ID. The extension is a FA, additional
simultaneous regional registrations will be performed requesting a
short lifetime. This is done
subtype of the Generalised Link-Layer Address extension described in order
Section 7. Two subtypes have been defined to limit the lifetime of
bindings which contain the MN only needs temporarily nFA's IP
address and therefore limit
bandwidth usage. This is an access point identifier They are called the case when Solicited
Agent IP Address Extension and the MN is moving between FAs Access Point Identifier Extension,
and uses NAMONC Handoffs to achieve loss-less IP mobility. The
lifetime are described in Sections 7.4 and 7.5. Only one of additional "auxiliary" bindings needed for NAMONC
Handoffs is thus limited. This may also the two should
be useful to support eventual present in the MN's "ping-pong" movement between FAs which would otherwise
require continuous registrations and thus handoff delays.

The remaining issue is the choice solicitation.

As a result of the appropriate HA address in MN solicitation message, the Regional Registration Request when oFA sends message 2b,
the MN has at least an
existing active regional binding. Two options follow:

1) Mobility Agent extension advertises FA and GFA address only Proxy Router Advertisement, to the MN. The Proxy Router
Advertisement contains the agent advertisement for the requested nFA.
In this case it is assumed that there is always order to expedite the handoff, the actual nFA advertisement SHOULD
be cached by the oFA following a single path from

MIPv4 Handoffs Design Team previous exchange with nFA, shown in
messages 1a and 1b, and specified in Section 3.5.

El Malki (Editor) et. al. [Page 11] 14]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

the MN to the GFA. The MN will always perform Regional Registrations
using the GFA address as HA address

3.4 Obtaining and Proxying nFA Advertisements

If L2 triggers are involved in initiating PRE-REGISTRATION handoff,
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 trigger timing SHOULD be arranged such that a full L3 PRE-
REGISTRATION handoff can complete before L2 handoff initiates. That
is, the MN and whether L2 handoff should be initiated after the Regional MN's Registration has
with the "S"
bit set to request for simultaneous bindings. If this is true nFA completes and the
Regional Registration is validated by the GFA, these FAs will
activate the produces a simultaneous binding upon receiving at the (successful)
Regional
GFA/HA. The Registration Reply from MAY be transmitted more than once to reduce
the GFA. Therefore probability that it is not
necessary to advertise lost due to errors on 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 wireless link.

A PRE-REGISTRATION handoff in the branch

In specific cases where multiple regional FA levels and multiple
paths from this case requires the MN to receive
agent advertisements from the GFA are present and are advertised, it may
be necessary for nFA through the MN old wireless access
point, and to identify perform a registration with the "common route" FA using nFA through the
complete list old
wireless access point. Three ways of FAs performing this are discussed in
the hierarchical branch. It is assumed following subsections.

3.4.1 Inter-FA Solicitation

Inter-FA solicitation assumes that oFA has access to the GFA advertises only one care-of IP address on all its interfaces
towards
of the MN. 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 must cache in the Mobility Agent Advertisement extensions for its
active bindings. When it receives an advertisement from a "new" FA
which mobile-initiated case (see Section 3.3).

Conceptually, once the oFA has access to the address of the nFA for a different Mobility Agent Adv. extension,
specific MN, it will be eager
to perform MUST send a new binding. unicast agent solicitation to nFA. The MN compares the IP addresses in
nFA replies to the new
Mobility oFA by unicasting an Agent Adv. extension Advertisement with
appropriate extensions. This method removes the ones it has cached TTL limitation of [1]
for its
active binding(s). If there is an Mobile IP address 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 common any case. Security between these
extensions, named "common route" FA or GFA, the MN will use that IP
address as HA address oFA
and destination address of its Regional
Registration Request in which the "S" bit will nFA should be set. The care-of
address in place to ensure that agent solicitations and
advertisements are protected and to enable nFA to determine that oFA
is the advertising FA's address. The MN may add a
Hierarchical FA extension authorised to the Regional Registration Request, solicit agent advertisements.

As a practical matter, oFA SHOULD pre-solicit and cache
advertisements from known FAs topologically near it, in order to identify the regional FA path
prevent having to be followed by perform the Request
up 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 hierarchy. A Regional FA receiving a Regional Registration
Request with it's own address as HA IP
address may return a Regional
Registration Reply to for oFA and the MN.

If there is no These IP addresses are obtained either by
means of the IP address identifiers in common between the extensions, then the
MN must have moved into a new hierarchy and the GFA advertised an L2 trigger at nFA in the
new extension must be different
network-initiated case (see Section 3.2) or by means of the Proxy
Router Solicitation from the one MN in the previously cached
extension(s). When the mobile-initiated case (see
Section 3.3). A solicitation from MN moves between administrative domains (i.e.
changes GFA) then directly to nFA must reach nFA
and identify the MN should use oFA, so the new GFA's solicitation must include an extension
containing an IP address as care-
of identifier. This can be either oFA's IP
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 or an Access Point identifier which may perform a smooth handoff as explained in section 3.4.

The MN is able to perform this option be specific to implement NAMONC Handoffs
only if its binding lifetime with the GFA or HA does not expire

MIPv4 Handoffs Design Team

El Malki (Editor) et. al. [Page 12] 15]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

during

underlying wireless technology. As a result of the period needed by tunneled
solicitation, the MN to complete its handoff.
Intermediate regional FAs are able nFA sends a Router Advertisement tunneled to accept the MN's regional
registration (simultaneous binding) MN
through oFA. This message is effectively message 2b, coming from nFA
instead and only if routed through oFA.

However in [1] the intermediate regional
FA has MN cannot solicit an existing active binding for Advertisement from the nFA
directly (Mobile-Initiated Handoff) since it is not on the same link
as the MN. The resulting
simultaneous binding may therefore have a maximum possible lifetime
equal to This restriction applies if the lifetime remaining in its previously existing active
binding. Once the registration lifetime with the GFA or HA is about
to expire, the MN TTL 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 be 1 on Router
Solicitations. The same would 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 Router Advertisements from the MN's old location,
nFA, which
may include all also affects the FAs in its old regional branch. This Network-Initiated Handoff case. Therefore
tunneling advertisements is necessary
to avoid incorrect routing of packets by only applicable where the "previous" FA(s) in TTL limitation
of [1] can be relaxed. This should be the
old regional branch during case for unicast messages.

3.4.3 Piggy-backing Advertisements on L2 messaging

Piggy-backing advertisements on L2 messaging involves utilizing the interval
L2 messaging involved in which L2 handoff to transmit the MN has moved but Router
Advertisement from the "previous" FA(s)'s regional binding lifetime for nFA to the MN has not
yet expired.

The regional deregistration is performed by a regional FA upon or oFA. When the first time L2
handoff messages are exchanged, it receives a valid Regional Registration Request, without
the "S" bit set, from may be possible to transmit a MN which had previously set
Router Advertisement piggybacked onto L2 messages. Alternatively, the "S" bit in
its regional registration(s). This regional FA
L2 at oFA may respond with a
Registration reply cache nFA's advertisements and may perform the Regional deregistration by
sending a Binding Update with zero lifetime not need to receive
Router Advertisements upon every L2 handoff initiation. Whether this
technique is possible depends on the "next" regional FA
in particulars of the MN's old regional branch, setting L2 technology
and is outside 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 scope of this notification removes
its binding for document.

3.5 Caching Router Advertisements

If done during a handoff, message exchange 1 in Figure 1 imposes an
additional latency penalty on the MN. L3 handoff process. In order to
remove this way, the MN updates all source of latency, the Regional
FAs inter-FA Router Solicitation and
Advertisement exchange SHOULD be performed in advance of handoff. A
process SHOULD be in place at the "old" hierarchical branch between the "common route" FA 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 "old" lowest level FA. It FA Challenge/Response
mechanism in [11] is assumed that GFA/FAs within used then the
same hierarchical domain share a Security Association which can MIN_SOLICITATION_INTERVAL must be
used
set to perform this deregistration.

The MN will be able a value smaller or equal 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 CHALLENGE_WINDOW (in nFA) so
that the GFA.

3.4 Smooth Handoffs between Hierarchies (GFAs)

When nFA challenge does not expire before the MN moves between domains it receives Mobility Agent
extensions containing a new GFA IP address. issues the
Registration Request.

The MN registers with its
HA using oFA SHOULD cache the new GFA IP address as care-of address. In order most recent advertisements from its
neighbouring nFAs. These advertisements should be sent 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 MN in the Regional Registration Request [4]. This results
message 2b with a TTL=1. The oFA SHOULD also have a mechanism in
place to create a
smooth handoff between the domains.

A new flag list of neighbouring nFAs. The minimum support is required in the Binding Update message
to perform manually configure a
smooth handoff while maintaining the existing binding list of nFAs for each FA in the
"previous" FA. This network with
which an L3 handoff is the "S" bit for the simultaneous binding. This
simultaneous binding possible. The list will depend on deployment
and radio coverage. It is necessary in also possible to specify another protocol
to achieve nFA discovery, but it is outside the case in which 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 only
momentarily moves "forward" receives an Agent Advertisement with a Mobility Agent
extension, it should perform actions according to the new domain, then returns back following
movement detection mechanisms. The MN MUST be:

- "Eager" to
the "previous" FA (domain) before its previous binding expires. In
this case the binding for perform new bindings,

- "Lazy" in releasing existing bindings.

The above means that the MN MUST perform Registrations with the "previous" any new
FA must be
maintained. Following from which it receives an advertisement (i.e. MN is Eager), as
long as there are no locally-defined policies in the new Binding Update message with MN that
discourage the "S"
flag added which replaces one bit use of the Reserved space. discovered FA. For example, the MN may have
a policy based on the cost of service. The "S" flag method by which the MN
determines whether the FA is a new FA 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 in [1] and may
make use of an FA-NAI extension. However the MN must be added to
the binding list and MUST NOT replace release
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 until it no longer receives advertisement from the
old FA and wireless access points) MAY use an L2 extension to the Registration messages. Such an extension lifetime of its existing binding expires (i.e. MN is required in Ethernet-
based networks when
Lazy).

If the MN performing a registration has at least one existing binding with an FA, additional
simultaneous Registrations are performed requesting a FA which short lifetime.
This is not its first-hop router needs to communicate its L2 address done to
that FA. Therefore limit the FA must use lifetime of temporary bindings and
therefore limit bandwidth usage. Temporary bindings occur when the L2 address in this extension MN
is moving between FAs and uses PRE-REGISTRATION handoff to communicate with achieve
low loss IP mobility. By limiting the MN instead of lifetime, the L2 source address of Registrations
time out quickly avoiding 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 need for the MN to cancel the wireless
network which allows these networks
registration. Temporary bindings are also useful to resolve the mapping support ping-
ponging between MN
IP address and FAs.

3.7 Simultaneous Bindings

Simultaneous bindings are used by a GFA or HA to decouple L3 handoff
from L2 address without handoff and to reduce packet loss. Simultaneous bindings
allow a GFA or HA to bicast packets destined to the need MN to use these extensions.
Therefore such extensions would not be needed.

3.6 Advantages multiple
potential future MN locations before the MN actually moves there.
Simultaneous bindings and Applicability of NAMONC Handoff Method

The NAMONC Handoff method is applicable bicasting are also useful to scenarios where support ping-
ponging.

Using normal Mobile IP
Registrations are supported by the mobile nodes with an HA only and no GFA, the network. MN MAY perform
registrations with the HA using simultaneous bindings. This
method is compatible with RFC2002
described in [1] and therefore is based on the same
security model including the use of AAA. It is assumed that FAs are
able method to obtain L2 triggers from anticipate MN movement by
interacting with the wireless network which inform the
FA that an L2 handoff procedure is being initated described in Section 3.6.
However, having multiple simultaneous bindings for a certain the MN to
another access point or radio network having a certain ID. The FA
must be able to determine at the IP address of HA
causes the new FA from this ID
using methods which HA to send multiple copies of data packets towards
mutliple FAs that may be specific to topologically distant. Bicasting from the wireless network and are HA
is not considered here. If efficient unless the FA determines that HA is close to the ID FAs in question. Also,
if the round-trip time between the HA and FAs 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 negligible, the L2
MN's new Registration and therefore L3 handoff procedure involves can be delayed.

El Malki (Editor) et. al. [Page 17]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001

If a number of message exchanges before the
effective L2 GFA is present, low loss handoff is performed. Therefore the NAMONC Handoff
method can be initiated at achieved by bicasting
traffic from the beginning of GFA to the L2 handoff procedure oFA and completed before the L2 handoff is completed. It may be necessary
to engineer nFA while the system such that this succession of events MN is
ensured. moving
between them. The NAMONC Handoff method provides advantages MN sets the "S" bit in the following cases:

- Registration Request
[2]. When the MN a Regional Registration Request has locally defined policies the "S" bit set, the
receiving regional FA or GFA that determine a
preference has an existing binding with the MN
adds the relevant new binding for one access over another (e.g. service cost) and
therefore where it is necessary to allow the MN to select but also maintains any
existing bindings it has for the
appropriate FA MN, bicasting traffic to connect to.

- When L3 cannot rely upon L2 security (between the MN and FA) to make
modifications to IP routing and therefore authenticated Mobile IP
messages are required.

In at
both FAs.

If the first case MN has simultaneous active bindings with FAs, it is necessary could (but
preferably should not) receive multiple copies of the same traffic
directed to involve eventual local MN
policies in it. The use of simultaneous bindings does not mean that
the movement detection procedure as described in 3.2.

4. Network Initiated, Mobile Terminated (NIMOT) Handoff Method

As discussed in the Introduction, in MN is receiving packets contemporarily from multiple sources.
This depends on the Network-Assisted Handoff
method, characteristics of the FA makes use access (L2) technology.
The bicasting of information from layer 2 to optimize
handoff by doing packets involves sending a fast "pre-registration" prior to copy of the formal Mobile
IP registration done by data to the MN. The goal of
FA which the Network-Assisted
Handoff design MN is moving to. Until the MN actually completes the L2
handoff 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 new FA and fully establishes the new L2 _triggers_ that link, the new
FA MAY receive packets for a MN to which it does not have a very broad set of
characteristics exhibited by many radio direct
link layer 2 protocols. In RFC
2002, no assumptions are made about connection. The FA MAY:

- drop all packets for the existence of any layer 2
support MN, or

- buffer packets for handoff. In pursuit the MN.

The choice of which action to take may depend on the lowest latency possible given
such layer 2 information, type of traffic
involved, but this is outside the Network-Assisted design proposes taking
maximum advantage scope of any layer 2 information available, and therfore
that RFC 2002 requires enhancement. this document. The Network-Assisted design
proposes new messages that work together with standard Mobile-IP
handoff MN MAY
also in parallel attempt to reduce handoff latency.

In this document, we will assume that the establish a link-layer events are
signaled connection with
the MN. An FA MUST NOT send ICMP Destination Unreachable messages if
it drops packets or is unable to deliver the Foreign Agent as "triggers". We assume that any such
triggers will be sufficient to derive the received IP addresses packets due
to unavailability of direct layer connection with the Foreign
Agents that will receive or send MN.

Appendix A contains more information about GFA considerations for the hand-off.
PRE-REGISTRATION handoff.

3.8 L2 Address Considerations

If such a trigger wired backbone network connects wireless access points and the
wireless network is not available or if bridged (i.e. the MN decides on its own wireless access points are
not acting as routers) so that a hand-off is to
take place, then one of the FAs can often still derive FA is not directly on the identity
(IP address) of same
link as the other from link-layer messages or through
preconfiguration.

In order for MN, the Mobile IP protocol MN MAY use an L2 address extension 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 message when the MN is not typically
considered performing a Hand-Off problem, this proposal assumes registration.
Because the MN is registering with an FA that such a
mechanism is in place.
2. Reducing not its first-hop
router, the latency involved in L2 address of the Mobile Node's movement
detection process.
3. "Bi-casting" frame containing the Mobile Node's traffic MN's registration
packet is not MN's address. The MN must use some means to two (or more) points
of attachment, ensuring that communicate
its L2 address other than the mobile's traffic frame address, which 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 method
specified in [1]. To communicate its L2 address, 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 MN includes a Mobile Node registers
Generalised Link Layer Extension (see Section 7) with
a Foreign Agent, and subsequently its Home Agent, in order to have
its packets delivered to its current point of attachment.
registration. 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 FA uses the L2 address in the extension to be processed by
communicate with the MN. If a Mobility Agent in particular wireless L2 technology has
defined a special L2 interface to the local
domain, eliminating wireless network that allows
the need FA to contact resolve the Home Agent, which MAY be
topologically distant.

MIPv4 Handoffs Design Team mapping between an MN IP address and an L2

El Malki (Editor) et. al. [Page 16] 18]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

4.2 Movement Detection

The Mobile IP protocol [1] and

address without the Regional Registration extension
[2] require Mobile Nodes to listen for, or solicit, advertisements in
order to detect that a movement need to a new IP subnet has occurred. This
movement detection mechanism introduces significant latency into use the
hand-off process, which causes service degradation, especially for
real-time services. Service is further impacted given extension, the additional
latency introduced through extension is not
needed.

3.9 Applicability of PRE-REGISTRATION Handoff

Security for the registration process that follows PRE-REGISTRATION handoff method is based on the
movement detection, since same
security model as [1] including the mobile's traffic can only be delivered
once all use of AAA. A prerequisite for
PRE-REGISTRATION is that the registration has completed.

There have been many solutions proposed FA or MN are able to solve this problem,
including increasing obtain an L2
trigger informing them of a pending L2 handoff procedure. The target
of the advertisement frequency. In networks where
radio spectrum L2 handoff is expensive another access point or bandwidth radio network which is limited,
in the additional
signaling required for increasing advertisement frequency is coverage area of 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 new FA. The L2 trigger information may be
in the Mobile Node
(acting as a surrogate form of sorts). When a Foreign Agent is aware that
a hand-off is occurring at the link-layer, a trigger is sent IP address identifiers which may need to be resolved
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 addresses using methods that is obtained by may be specific to the old
Foreign Agent (oFA) once wireless
network and are not considered here. If, for example, the link layer detects FA
determines that the Mobile Node IP address of the new FA is departing within its coverage area. A target trigger (see Figure 4), on
the other hand, is one that
area (i.e. is obtained by the new Foreign Agent
(nFA) once its own address) the link layer detects that PRE-REGISTRATION handoff should
not be initiated.

The L2 trigger must allow enough time for the Mobile Node is arriving in
its coverage area. Note that both triggers may PRE-REGISTRATION
handoff procedure to be available before performed. In many wireless L2 technologies,
the actual completion L2 handoff procedure involves a number of message exchanges
before 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 effective L2 handoff is performed. For such technologies,
PRE-REGISTRATION handoff can be initiated at the initiator beginning of the Handoff Request message. In
both examples, an optional Gateway Foreign Agent L2
handoff procedure and completed before the L2 handoff is used, which
requires completed.
It may be necessary to engineer the use network such that this succession
of events is ensured.

The PRE-REGISTRATION Handoff method is applicable in the Regional Registration messages [2]. In both following
cases:

- when the source and target triggers, a Foreign Agent obtains link-layer
information, such as power measurements, MN has locally defined policies that indicate the necessity
of determine a handoff
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 new Foreign Agent. In MN to select the event of a source
trigger, oFA transmits a Handoff Request message appropriate FA
with which to nFA. The Handoff
Request MUST include connect,

- when L3 cannot rely upon L2 security between the MN and the FA to
make modifications to IP routing and therefore authenticated
Mobile Node's Home Address, Home Agent
Address, remaining registration lifetime, as well as IP messages are required,

- when the Link-Layer
Address Extension (see Section 5). The GFA's identity MUST also be
present, if one was used for trigger to initiate the Mobile Node's registration. Upon
receipt of handoff is received at the message, nFA MUST create MN.

In the Mobile Node's visitor
entry, and respond with first case it is necessary to involve eventual local MN
policies in the Handoff Reply message.

+-----+
| GFA |
+-----+
^ |
3. Regional | | 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. Regional
Reg Request | | Reg Reply
| v
+-----+ 1. Handoff Request +-----+
| | <----------------- | |
| oFA | | nFA |
| | 2. Handoff Reply | |
+-----+ -----------------> +-----+

+-----+ Movement +-----+
| MN | - - - - - - - - -> | MN |
+-----+ +-----+

Figure 4 - Target Trigger Pro-Active The POST-REGISTRATION Handoff

In target triggers, the trigger occurs Method

The POST-REGISTRATION handoff method is based on nFA, which results in the
transmission of a Handoff Request to oFA. network-initiated
model of handoff. The Handoff Request message
MUST include technique does not require any MN involvement
until the Mobile Node's Link-Layer Address (see Section 5) in
order for actual L2 connection with nFA is completed. The oFA and nFA
perform a message exchange that allows the MN to correctly identify establish a
temporary registration on the nFA until the MN performs a formal
Mobile Node. IP FA registration. The request
message MAY include additional Mobile Node information, if such
information was provided by technique derives its name because the link layer. Upon receipt
registration occurs after L2 handoff is complete. POST-REGISTRATION
makes use of bi-directional edge tunnels (BETs) to smooth packet
delivery while the
request, MN is in transition between 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. nFA. If
a GFA was used the FA
determines that there is no change in the Mobile Node's registration, it's address MUST
be supplied. Regardless of FA, based on the direction of L2 trigger
information, then the Handoff Request, if
nFA receives GFA information within 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 message from oFA, it SHOULD
issue a Regional Registration Request with
framework in [1].

4.1 Operation

In the GFA, which will
respond with POST-REGISTRATION method, the FA issues handoff messages on
behalf of 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 Node, acting as a surrogate of MNs between two FAs.
For example, even though link-layer power measurements may indicate sorts. The FA
becomes aware that a hand-off handoff is necessary, the mobile may fail to attach about to occur at L2 through the
new point use
of attachment, and return almost immediately to its old
point an L2 trigger. An FA can receive two types of attachment. This event is known as triggers, a "ping-pong" effect.

Data +-----+ Data +----+
+-------------| source
trigger at oFA |<--------------------------| HA |
| +-----+ +----+
v ^ |
+----+ Handoff | | Data
| MN | Request | |
+----+ | |
^ v v
| +-----+
+-------------| nFA |
Data +-----+

Figure and a target trigger at nFA. Section 1.1 and Table 1
contain more details about source and target triggers.

Figures 5 - Bi-Casting by and 6 contain message sequences for source and target
triggered POST-REGISTRATION handoff, respectively. Figures 7 and 8
contain message timing diagrams for the Anchor Foreign Agent

Figure message sequences in Figures
5 provides an example of bi-casting a Mobile Node's through
both the old and new Foreign Agents. Bi-casting 6. In Figure 5, a source trigger is established obtained by oFA when L2
detects that the oFA issues a successful Handoff Reply MN is about to nFA, or receives depart its coverage area. In Figure
6, a
successful Handoff Reply from nFA. This causes oFA to forward all of target trigger is obtained by the Mobile Node's traffic to nFA when L2 detects that the nFA, as well as to
MN has just arrived in the Mobile Node,
if a link-layer channel exists.

Figure 6 provides an example where bi-casting is performed on coverage area of the
Gateway Foreign Agent, which is initiated by nFA setting prior to the 'S' bit
(Simultaneous Binding) in
completion of the Regional Registration Request.

Data L2 handoff. Note that both triggers are available
before the actual completion of the link layer handoff.

+-----+ Data
+-------------| 1. Handoff Request +-----+
| | -----------------> | |
0. Source ~~~> | oFA |<-------------+ | +-----+ |
v nFA |
+----+ +-----+ Data +----+
Trigger | MN | 2. Handoff Reply | GFA |<--------| HA |
+----+
+-----+ +----+ <----------------- +-----+
^ |
3. Reg Request | | 4. Reg Reply
| v
+-----+ Movement +-----+
|
+-------------| nFA |<-------------+
Data MN | - - - - - - - - -> | MN |
+-----+ +-----+ Data

Figure 6 5 - 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 Source Trigger POST-REGISTRATION Handoff

El Malki (Editor) et. al. [Page 19] 20]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 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

+-----+ 1. Handoff
message from Request +-----+
| | <----------------- | |
| 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 |<~~~~ 0. Target
| | Req 2. Handoff Reply | | v Trigger
+-----+ -----------------> +-----+
^ | oFA
3. Reg Request | | nFA 4. Reg Reply
|
+-----+ +-----+ v
+-----+ Movement +-----+
| MN | - - - - - - > - - -> | MN |
+-----+ +-----+

Figure 7 6 - Inter-FA communication using AAA

Note that it 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 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 the initiator 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
Handoff Request message. In both the old FA is informed of source and target trigger
cases, an
upcoming link-layer handoff,
- a "target trigger" occurs at the new FA when it is informed obtains link-layer information that indicates the
necessity of a link layer handoff is in progress.

The method by which such triggers occur are link-layer specific, and
are outside to the scope nFA. In the event 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 trigger,
oFA transmits a Handoff
request Request message to nFA. The Handoff Request
MUST include the Foreign Agent MN's home address, HA address, remaining
registration lifetime, and a Generalized Link-Layer Address Extension
(see Section 7) with the mobile is being handed off
to/from. If MN's L2 address. Upon receipt of the message is
message, nFA MUST create the result MN's visitor entry, and respond with the
Handoff Reply message.

In the event of a target trigger, the Type
Of Trigger bit MUST be set 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 5) MUST be present. 7) in order for oFA to correctly identify the
MN. The message's Home Address and Home Agent
Address fields request message MAY be set to NULL include additional MN information, if this
such information is not known at
the time was provided by the message is transmitted. L2. Upon receipt of a Handoff Request message with the Type Of Trigger
bit set, a Foreign Agent request,
oFA MUST respond with the Handoff Reply message.
The Handoff Reply MUST include both the Mobile Node's Home Address
and Home Agent Address in message, including the message header. The MN's
home address, HA address, 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 and a Gateway Foreign Agent was used in
the Mobile's registration, the GFA's identity MUST be included in the
Gateway Foreign Agent
Generalized Link-Layer 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 MN's link layer
address.

El Malki (Editor) et. al. [Page 21]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 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

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 Reply message. If successfully processed, the Foreign
Agent MUST create Message Timing Diagram
(Target-Trigger)

Completion of POST-REGISTRATION handoff requires MN to perform a Visitor Entry for the Mobile Node, full
FA and be
prepared to deliver packets received by HA/GFA registration. A trigger that signals the initiator completion of
the handoff, designated as L2-NHC (Layer-2 Network Handoff
Request destined for the Complete)
or L2-MHC (Layer-2 Mobile Node. The Handoff Reply message MUST
include the Home Address, Home Agent Address, lifetime value, Complete) in Figures 7 and 8,
performs this function. If the
Link-Layer Address Extension (see Section 5).

A Foreign Agent that MN 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, an L2-MHC trigger, it MUST issue
SHOULD send 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. Router Solicitation message. The request's
lifetime field is set Router Solicitation
causes nFA to an administratively configured value. A
successful Regional Registration Reply MUST cause send a Router Advertisement, allowing the Foreign Agent MN to create perform
a visitor entry for the complete Mobile Node.

If a IP or Regional Registration Reply message is received with Registration. Alternatively, if the code
field set to DO_NOT_SERVICE_MN (Section 4.9),
nFA receives the Foreign Agent L2-NHC trigger, nFA 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 send a
point-to- point Link Layer), or simply denying all Registration
Requests with Router
Advertisement, allowing the error code set MN to 65 (Administratively Prohibited)
[1].

Once perform a visitor entry has been created, and the complete Mobile Node
establishes a link layer channel with IP or
Regional Registration. The L2-MHC and L2-NHC triggers are optional.
If they are not available, the Foreign Agent, its traffic
will be immediately delivered, along with a Mobility Advertisement
message [1]. A Mobile Node MN MUST issue a Registration Request when it
receives wait until nFA sends a Mobility
periodic Agent Advertisement from a new Foreign Agent.

MIPv4 Handoffs Design Team and MUST respond by registering with
nFA.

El Malki (Editor) et. al. [Page 22]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

Note that Foreign Agents MAY delay in sending Mobility
Advertisements, especially

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 reduce noticeable service disruption achieve low loss of
traffic to and from the MN during a ping-pong effect. However, when doing so, the Foreign Agent
MAY need handoff and to re-issue a new Handoff Request smooth handoff
when an MN undergoes ping-ponging. The tunnel from nFA back to oFA (and optionally
allows the
Regional Registration message MN to GFA), use its old care of address prior to extend the visitor entry's
lifetime.

Delaying Mobility Advertisements MAY also be done in wireless
technologies that support dormant mobiles. When registering
with nFA. If this tunnel is done, a
Foreign Agent would typically wait to send the advertisement until not established, the mobile old care of address
cannot be used because it is no longer in topologically incorrect and may trigger
egress filtering in nFA's subnet, resulting in the dormant mode. When data MN's packets being
dropped.

Figure 9 provides an example of a BET. The BET is received by placed when the Foreign Agent for oFA
issues 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 successful Handoff
Requests as Reply to nFA, or receives a result of Link-Layer triggers. However, successful
Handoff Reply from nFA. This causes oFA to forward the discovery
of MN's traffic
to the identity of nFA. The nFA forwards the Foreign Agents traffic further to which the Handoff messages
must be sent is outside the scope of this document. MN if an L2
connection exists. In the event that a Foreign Agent handling a particular Mobile Node's
visitor entry is 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 expire, nFA, where they are
detunneled and the forwarded as if they originated through oFA.

El Malki (Editor) et. al. [Page 23]

INTERNET-DRAFT Low Latency Mobile Node has not yet
issued a Registration Request, 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 has the option to transmit SHOULD issue a
new Handoff Request
message to the old Foreign Agent (and the
optional Regional Registration Request FA to which or from which the GFA). Whether the
renewal mobile is performed on behalf of being handed
off.

If the Mobile Node message 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 result of a direct link layer connection. At this point, target trigger, the
Foreign Agent MAY:

1. Drop all packets for Type Of Trigger
bit in the Mobile Node
2. Buffer packets for Handoff Request message MUST be set and the Mobile Node
3. Attempt to establish a link-layer connection with Generalized
Link-Layer Address Extension (see Section 7) MUST be present. The
sender of the mobile
4. Issue a Regional Registration Handoff Request with a zero lifetime

Given that a Mobile Node's packets will is nFA and the handoff is target
triggered. The message's home address and HA address fields MAY be delivered prior
set to
registration, a Mobile Node NULL if this information is free to discard all packets received
from Foreign Agents with which it hasn't registered.

When the new Foreign Agent receives not known at the Mobile Node's Registration
Request [1], its Anchor Foreign Agent (GFA as first-hop router)
changes to time the new Foreign Agent. The Foreign Agent MUST transmit message
is transmitted.

Upon receipt of a Handoff Request message to with the old Foreign Agent 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 set to zero. A Foreign Agent field. Furthermore, the oFA issuing the
Handoff Reply MAY include any security associations that receives were
dynamically created. The oFA that issues a Handoff Request Reply with the lifetime
Code field set to zero is being informed that it is no
longer the anchor point for the mobile. It MAY issue a Handoff
Request success (zero value) MUST bi-cast all packets
destined to the new Foreign Agent in MN to both the future if it wishes L2 to keep
receiving which 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 MN is no longer servicing a
Mobile Node, it SHOULD issue a Regional Registration Request message
with the lifetime field set currently
connected and by tunneling to zero (0). This will cause the visitor
entry associated with the Foreign Agent's Care-Of address on the GFA
to nFA.The oFA must also be deleted. Foreign Agents MAY decide prepared
to not issue this message
immediately when a link-layer trigger is received, receive tunneled packets from the nFA in order to
support smooth service during a ping-pong event.

4.6.2 Gateway Foreign Agent Considerations

Upon receipt which the MN's packets
appear with the old care of address.

The nFA that receives a Regional Registration Request, a GFA MUST create Handoff Reply message with a
visitor entry indicating the Mobile Node's current point of
attachment. In zero value in
the event that Code field creates 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 information found in
the Regional Registration Request, the GFA message. The FA MUST be able prepared to
forward the mobile's deliver packets to all Foreign Agents in the visitor
entries.

When constructing the Regional MN
prior to receiving a Registration Reply, the GFA SHOULD
include Request [1] from the FA-FA authentication extension [2], MN, and set the lifetime
field it
MUST be prepared to tunnel packets sent by the lesser of:

1. number of seconds before MN under the Mobile Node's Registration with
its Home Agent will expire.
2. The lifetime MN's old
care of the locally created Visitor Entry.

In the event address to oFA.

Note that it is possible for the Regional Registration Request's lifetime field
was set encapsulation method used between
oFA and nFA to zero (0), the GFA MUST remove the visitor entry associated
with be different from the Care-Of address in one requested by the message.

Should 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 GFA decide respective FAs MUST
perform encapsulation translation.

An FA that the Foreign Agent is not to provide
service to the Mobile Node, it receives a source trigger MUST issue send a Regional Registration
Reply message, with the code field set to DO_NOT_SERVICE_MN (see
Section 4.9).

4.7 Handoff Request Message
message with the Type Of Trigger bit disabled. The sender of the
Handoff Request message is used to inform a peer that a pro-
active the oFA and the handoff is being initiated. source
triggered. The Handoff Request message can be
used for both source MUST also include the MN's home address, the
HA address and target triggers, through the Type 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
'I' bit in
disabled, the message flags. When sent as a result of nFA MUST process the packet and respond with the
Handoff Reply message. If successfully processed, the nFA MUST create
a target
trigger, visitor entry for the Home Address MN, and Home Agent fields MAY be set prepared to zero
(unless this information was communicated deliver tunneled
packets received by the link layer, which is
outside the scope initiator 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 the Handoff Request destined for
the MN, 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 tunnel packets from the 'S' bit in MN sent under its regional
registration.

I Type of Trigger. A value of zero is a source
trigger (sent by oFA), while a value old care of one is a
target trigger (sent by nFA).

M, G, T As defined in [1,5]. This refers
addres to the
tunnel between oFA oFA. The Handoff Reply message MUST include the home
address, HA address, lifetime value, and nFA, or, if GFA IP
address extension is present, to the parameters Generalized Link-Layer
Address Extension (see Section 7) with the MN's link layer address.

An oFA that should be requested in receives a Handoff Reply with the Regional Reg
Req.

Lifetime The requested Lifetime Code field set to
success (zero value) MUST bi-cast all packets destined for which nFA will serve the MN to
both 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 old L2 and T flags by tunneling to the nFA. The oFA must
also be prepared to receive packets sent and a GRE Key extension must be included.

Home Agent Addr The home agent address by the MN under its old care
of address on the mobile node.

Identification As in defined new L2 that are tunneled by nFA.

Once a visitor entry has been created in [1].

Extensions The Message MUST include LLA (see Section 5),
the FA-FA Authentication Extension [2], nFA, 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 MN establishes
an L2 connection with the Handoff Request message to nFA, its traffic will be sent, this message is sent immediately
delivered, along with a successful code 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 Visitor
Entry was successfully created. When MN will respond to a target trigger caused periodic Agent Advertisement sent
according to [1]. In any case, the
Handoff Request message, receipt MN can continue to use its old
care of this message with a successfuly
code SHOULD cause address without any delay in uplink L3 connectivity until it
is established on the Visitor Entry new L3 since the nFA tunnels its packets back
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| the oFA. An MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home MUST issue a Registration Request when it receives
an Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-

Type TBD (Handoff Reply)

Code A value indicating the result of Advertisement from the Handoff
Request. See below for a list of currently
defined Code values.

Lifetime If nFA, completing the Code field indicates L3 handoff.

Note that the
registration was accepted, nFA MAY delay sending an Agent Advertisement,
especially to reduce noticeable service disruption during a ping-
pong. However, when doing so, the Lifetime field is
set nFA MAY need to re-issue a new
Handoff Request to oFA, to extend the number of seconds remaining before visitor entry's lifetime.

In the registration is considered expired. A value
of zero indicates event that the mobile node visitor entry for an MN at nFA is about to
expire and the MN has been
deregistered. A value of 0xffff indicates
infinity. If not yet issued a Registration Request, the Code field indicates that nFA
has the
registration was denied, option to transmit a new Handoff Request message to the contents of oFA
to renew the
Lifetime field are unspecified and MUST be
ignored registration. Whether the renewal is performed on reception.

S When set, and when no GFA address extension behalf
of the MN 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 policy decision up to the 'S' bit in its regional
registration.

MIPv4 Handoffs Design Team network administrator.

El Malki (Editor) et. al. [Page 26] 25]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

I Type of Trigger. A value of zero is

An FA MAY receive packets for a source
trigger (sent by oFA), while MN to which it does not have a value direct
link layer connection. The FA MAY:

- drop all packets for the MN, or

- buffer packets for the MN.

The choice of one which action to take may depend on the type of traffic
involved, but this is a
target trigger (sent by nFA).

M, G, T As defined outside the scope of this document. The MN MAY
also in [1,5]. This refers parallel attempt to establish a link-layer connection with
the
tunnel between oFA and nFA, or, MN. An FA MUST NOT send ICMP Destination Unreachable messages if GFA IP
address extension
it drops packets or is present, unable to deliver the parameters
that should be requested in the Regional Reg
Req.

MN Home Address The home address received IP packets due
to unavailability of direct layer connection with the mobile node. When using MN. Given that
a private address, the G and T flags must MN's packets will be
sent and delivered prior to a GRE Key extension must be included.

Home Agent Addr The home agent address of proper registration, the mobile node.

Lifetime The requested Lifetime for
MN MAY discard all packets received from FAs with which it has not
registered.

When the nFA will serve receives 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) MN's Registration Request [1] and the FA-FA Authentication Extension [2].

4.9 Error Values

The following table contains HA's
or GFA's successful Registration Reply [1][2], it MUST transmit a
Handoff Request message to the name of Code [6] oFA with the lifetime field set to be returned in
zero. An oFA that receives a
Registration Reply, Handoff Request with the value lifetime field
set to zero is being informed that it is no longer the anchor point
for the Code, mobile. The oFA SHOULD stop bicasting at this point, and tear
down the section in which reverse tunnel from nFA, since the error MN 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 now fully connected
at L3 on the new subnet. The oFA MAY issue a Handoff Request to [2], this specification assumes that the local Foreign
Agent, and
nFA in the GFA inherently trust each other. This MAY 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 achieved used for both source and target triggers, through the use Type of
Trigger 'I' bit in the message flags. When sent as a long lived security association.

This specification introduces result of a new change
target trigger, the home address and HA fields MAY be set to Mobile IP, zero
(unless this information was communicated by the link layer, which is
outside 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 scope of this document).

El Malki (Editor) et. al. [Page 26]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

link layer be sufficiently secure in order to correctly identify a
Mobile Node. Wireless networks

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 do not provide such features both oFA and nFA will
be subjected
attempt to impersonation attacks, where malicious nodes could
cause the Foreign Agents deliver datagrams directly to believe that MN, if
a Mobile Node has moved to
other service areas.

4.11 Advantages and Applicability link-layer connection exists.

I Type of NIMOT Handoff Method

The NIMOT handoff approach allows foreign agents to communicate
directly about Trigger. A value of zero is a pending handoff, and does not require any IP layer
messages to be source
trigger (request sent to or from by oFA), while a mobile node prior value of
one is a target trigger (request sent by nFA).

M, G, T As defined in [1,5]. This refers 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
tunnel between oFA and nFA.

Lifetime The requested Lifetime for handoff is recognized but before the handoff can take place.
This separation is necessary when the link layer (or which nFA will serve
the laws of
physics) imposes hard deadlines MN on behalf of oFA, without requiring a new
registration.

MN Home Address The home address of the time at which MN. When using
a handoff private address, the G and T flags must
occur, such as when be
sent and a mobile node is rapidly moving out GRE Key extension must be included.

HA Addr The HA address 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 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 triggered by some unspecified mechanism
that informs sent in response to the old or new foreign agent that Handoff Request
message. When a handoff is needed, source trigger caused the NIMOT approach is only applicable Handoff Request message to networks where such a
mechanism
be sent, the Handoff Reply message is available. For example, sent with a link layer may provide power
measurements or other indications 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 radio signal quality that the Handoff Reply
message with a successfuly code SHOULD cause the old or new foreign agent Visitor Entry 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.
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 | Length Code | Sub-Type Lifetime | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|x|I|M|G|r|T|x| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-

Type TBD (skippable) [1]

Length

The length (Handoff Reply)

Code A value indicating the result of the Link Layer Address + Handoff
Request. See below for a list of currently
defined Code values.

Lifetime If the one octet Sub-Type Code field

Sub-Type

This indicates that the
registration was accepted, the Lifetime field contains is
set to the Link Layer sub-type identifier

LLA

Contains number of seconds remaining before
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 registration is considered expired. A value
of zero indicates that 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | Length | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

MIPv4 Handoffs Design Team 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 29] 28]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

Type

TBD (skippable) [1]

Length

MN Home Address The length home address of the IMSI field + mobile node. When using
a private address, the one octet Sub-Type field

Sub-Type

IMSI

Contains G and T flags must be
sent and a GRE Key extension must be included.

HA Addr The HA address of the IMSI, in mobile node.

Lifetime The requested Lifetime for which nFA will serve
the form:

Where 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 <IMSI> is an ASCII-based representation 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
International L2 handoff event.
Therefore, it does not place the MN's IP stack or Mobile Station Identifier, most significant digit
first, ":" IP client
implementation on the critical path after a need for handoff is ASCII 0x3a, and
recognized but before the Connection ID handoff can take place. This separation is
necessary when the ASCII
representation 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 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 radio coverage area, but when the 48 bit
Ethernet MAC Address, MN's IP stack is not
implemented 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 a hard real-time system.

Because a POST-REGISTRATION handoff is triggered by an unspecified
mechanism that informs the Sub-Type field)

Sub-Type

MAC

MIPv4 Handoffs Design Team [Page 30]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001

Contains oFA or nFA that an L2 handoff is pending,
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 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
64 bit address, as defined oFA or nFA to send the POST-REGISTRATION handoff messages. Any
such indications must also provide each FA involved in [10].

Type

TBD (skippable) [1]

Length

7 (includes the Sub-Type field)

Sub-Type

MAC

Contains handoff
with the 64-Bit Global Identifier Address.

6. IANA Considerations

The number for identity of the Generalized Link Layer Address Extension in
section 5 is taken from other, so that messages can be sent to the numbering space defined for Mobile
right place. This may involve mapping L2 information onto FA IP
registration extensions defined
addresses. Also, the FAs involved 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 a handoff must have pre-
provisioned security arrangements so that the NIMOT Handoffs method, POST-REGISTRATION
messages can be authenticated. If a handoff is to be completed as a
result of the Code values specified for errors,
listed in section 4.9, MUST NOT conflict with POST-REGISTRATION messaging without continuing to
bicast traffic to both the old and new coverage areas, any other code values
listed 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 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 following cases:

- L2 triggers are available on the network to indicate that L2
handoff is pending.

El Malki (Editor) et. al. [Page 31] 29]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 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

- Pre-provisioned security mechanisms are in RFCs place to Indicate Requirement
Levels". BCP 14. RFC 2119. March 1997.

[4] C. Perkins allow fast
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, secure messaging between the FAs 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 between the MN 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 an FA.

- Access point choice by the MN is not a concern or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission choice requires
user intervention and therefore is not on Ethernet Hardware", RFC 826,
Symbolics,Inc., November 1982.

[10] IEEE, "Guidelines the critical path for 64-bit Global Identifier (EUI-64)
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 Authority",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
March 1997.

[11] C. Perkins, P. Calhoun, 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 Challenge/Response
Extensions. RFC 3012, November 2000.

[12] Montenegro, G. 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 V. Gupta, "Sun's SKIP Firewall Traversal 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 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 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 32] 30]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

8. Authors' Addresses

The authors

technologies may allow the reverse tunnel to be contacted at turned off unless 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
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 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 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 7578162
Fax: +46 9 0 1 2 3 4 5 6 7 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 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

IMSI

Contains the IMSI, in the form:

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].

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

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].

Type

TBD (skippable) [1]

Length

9 (includes the Sub-Type field)

Sub-Type

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

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

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

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 contacted via necessary for 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 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 34] 42]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 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

This document and translations of it may MN adds a Hierarchical FA
extension to the Regional Registration Request, in order to identify
the regional FA path to be copied and furnished 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
others, and derivative works that comment on or otherwise explain it
or assist the
MN.

If there is no IP address in its implementation may be prepared, copied, published common between the extensions, then the
MN has moved into a new hierarchy and distributed, the GFA advertised in whole or the new
extension is different from the one in part, without restriction the previously cached
extensions. When the MN changes GFA, the MN uses the new GFA's IP
address as care of any
kind, provided that address in its new Registration Request to the above copyright notice and this paragraph are
included on all such copies HA
and derivative works. However, 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 itself may
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 be modified in anyway, such as
expire during the period needed by removing the copyright notice or references 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 Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards lifetime remaining in which case its previously existing
active binding. Once the procedures for
copyrights defined in registration lifetime with the Internet Standards process must be
followed, GFA or as required HA is
about to translate it into languages other than
English. The limited permissions granted above are perpetual and will
not be revoked by expire, the Internet Society or its successors or assigns.
This document and MN must perform a new Mobile IP registration
with 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 HA.

El Malki (Editor) et. al. [Page 35] 43]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

Appendix A B - Gateway Foreign Agents

The Mobile IP Regional Registration specification [2] introduces the
Gateway Foreign Agent (GFA), as a mobility agent Low Latency Handoffs for Multiply-Interfaced MNs

For MNs 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 two wireless network interfaces, either on the packets
to same
wireless network or on wireless networks having different wireless L2
technologies, the Foreign Agent servicing techniques discussed in this draft may be
unnecessary if the Mobile Node.

Reg Req +-----+ Reg Req
+----------->| oFA |--------------+
| +-----+ |
| v
+----+ +-----+ Reg Req +----+
| IP stack on the MN | | GFA |<------->| HA |
+----+ +-----+ +----+

+-----+
| nFA |
+-----+ allows switching an IP
address binding between interfaces. This Appendix discusses how
multiple wireless interfaces can aid low latency handoff.

Figure A.1 - Initial Registrations through GFA

In B.1 illustrates the event that normal and hierarchical MIPv4 models. As
shown in the mobile moves to a new Foreign Agent figure, assume that the MN is
serviced by a GFA that connected to Radio Network
1 (RN1) and is common registered with oFA, oFA through which it is receiving
traffic. Suppose MN enters the Mobile Node MAY issue
a Regional Registration Request (see Figure A.2). The Regional
Registration message does not need to be forwarded coverage area of RN2 and nFA and that
it prefers connectivity to this network for reasons beyond the Home Agent,
since scope
of this document (e.g. user preferences, cost, QoS available etc.).
The MN activates the mobile's traffic can still be delivered interface to RN2 but continues communicating
through RN1. The MN may solicit advertisements from nFA through the same GFA.
This optimized approach effectively reduces
interface connected to RN1 to speed up the latency involved in handoff process, provided
there is no TTL restriction, or it can solicit advertisements through
the registration process.

+-----+ interface connected to RN2 if it has been configured for IP
traffic.

+------+ +---------+
| HA |--------| (GFA) |
+------+ +---------+
/ \
/ \
... ...
/ \
/ \
+------+ +------+
| oFA |
+-----+

+----+ +-----+ +----+ | MN nFA |
+------+ +------+
| GFA |
+------+ +------+
| HA RN1 |
+----+ +-----+ +----+ | ^ RN2 |
+------+ +------+

+------+
| +-----+ MN |
+------------>| nFA |-------------+
Regional Reg +-----+ Regional Reg --------->
+------+

Movement

Figure A.2 B.1 - Regional Registration Network Model for Mobile IPv4 With Multi-Access

Once the MN is registered with nFA and is successfully receiving and
transmitting through GFA

Note that the GFA may also be new network, it tears down the MN's first-hop router.

MIPv4 Handoffs Design Team interface to

El Malki (Editor) et. al. [Page 36] 44]

INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February May 2001

Appendix B - Bicasting Applicability Statement

Both NAMONC and NIMOT Handoffs propose using bicasting as a technique
for delivering packets to

RN1. If 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 has enough time to decouple complete this procedure without
incurring degraded service or disconnection, the MN would experience
a seamless multi-access 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 but it may not been fully studied, bicasting should be
considered only possible in cases where layer 2 support is available all
cases, due to co-
ordinate network coverage or for other reasons. Should multiple
interface handoff such that duplicate packet delivery to the MN can be
reduced or avoided, until possible then the interactions between TCP and bicasting
are more clearly understood. Neither low latency handoff technique is
dependent on methods described
in this document are not necessary.

In order to support the use possible failure of bicasting for low-loss handoffs, though a
low-loss handoff technique is required for 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 fully seamless solution.

MIPv4 Handoffs Design Team new binding with nFA.

El Malki (Editor) et. al. [Page 37] 45]

----