INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-mobileip-proactive-fa-03.txt Tom Hiller
Date: November 2000 Lucent Technologies
James Kempf
Sun Microsystems, Inc.
Peter J. McCann
Lucent Technologies
Chandana Pairla
University of Illinois
Ajoy Singh
Sebastian Thalanany
Motorola
Foreign Agent Assisted Hand-off
Status of this Memo
This document is an individual contribution for consideration by the
Mobile IP Working Group of the Internet Engineering Task Force.
Comments should be submitted to the mobile-
ip@standards.nortelnetworks.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Calhoun et al. expires May 2001 [Page 1]
INTERNET DRAFT November 2000
Copyright (C) The Internet Society 2000. All Rights Reserved.
Abstract
The Mobile IP protocol allows a Mobile Node to continue using the
same home address even after changing its point of attachment to the
Internet. This provides transparency to most existing applications
that assume a fixed address and a fixed point of attachment.
However, new applications, such as voice-over-IP, have additional
real-time requirements such that a change in the point of attachment
will cause a noticeable degradation of service unless additional
steps are taken to reduce the latency of a handoff event.
This specification proposes extensions to the Mobile IP protocol that
may be used by Foreign Agents to set up a Mobile Node's visitor
entry, and forward its packets, prior to receiving a formal
Registration Request from the Mobile Node. This enables a very rapid
establishment of service at the new point of attachment so that the
effect of the handoff on real-time applications is minimized.
Table of Contents
1.0 Introduction
1.1 Requirements language
1.2 Terminology
1.3 Fast handoffs
2.0 Registration Latency
2.1 Gateway Foreign Agents
2.2 Anchor Foreign Agent
3.0 Movement Detection
3.1 Ping-Pong effect
4.0 Reverse Tunneling Support
5.0 Security Relationships
6.0 Power Consumption
7.0 Operation
7.1 Foreign Agent Considerations
7.2 Gateway/Anchor Foreign Agent Considerations
8.0 Handoff Request Message
9.0 Handoff Reply Message
10.0 Link Layer Address NAI
10.1 CDMA 2000 Link Layer Address Extension
10.2 Ethernet Link Layer Address Extension
10.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension
11.0 Error Values
12.0 IANA Considerations
13.0 Security Considerations
14.0 References
Calhoun et al. expires May 2001 [Page 2]
INTERNET DRAFT November 2000
15.0 Acknowledgements
16.0 Authors' Addresses
17.0 Full Copyright Statement
Calhoun et al. expires May 2001 [Page 3]
INTERNET DRAFT November 2000
1.0 Introduction
This specification proposes extensions to the Mobile IP protocol that
may be used by Foreign Agents to set up a Mobile Node's visitor
entry, and forward its packets, prior to receiving a formal
Registration Request from the Mobile Node. This enables a very rapid
establishment of service at the new point of attachment so that the
effect of the handoff on real-time applications is minimized. The
proposed extensions make a few minimal assumptions about support
available from the link layer. These assumptions are fairly broad and
abstract. Although they address the kinds of link layer support
available in existing radio link layers, the assumptions are not
based on any specific radio link protocol.
The extensions handle both intra-domain and inter-domain handoff.
While intra-domain handoff MAY make use of pre-configured security
associations between Mobility Agents, inter-domain handoffs MAY make
use of the AAA infrastructure. In the case of inter-technology
handoff, active involvement by the mobile is necessary to switch from
one network interface to another; however, the delivery of the agent
advertisements, indicating the availability of a mobility agent on a
new network interface, is still controlled by network assisted
handoff.
In summary, this draft covers a hand-off scenario not addressed by
RFC 2002: that of a pro-active, network-controlled, anchor-chained
hand-off.
1.1 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [4].
1.2 Terminology
This document frequently uses the following terms:
AAA
Authentication, accounting and authorization.
Anchor Foreign Agent (AFA)
A foreign agent with publicly routable IP address that acts as
an anchor point when a mobile moves to a new foreign agent.
Upon successful global registration (registration with home
agent) of a mobile node, the anchor foreign agent supports
Calhoun et al. expires May 2001 [Page 4]
INTERNET DRAFT November 2000
local registration when the mobile node changes its point of
attachment to some other neighboring foreign agents.
cdma2000
This is a wide-band radio transmission technology standard,
that uses CDMA(code division multiple access) technology, to
meet the demands of a third-generation wireless communication
system.
Connection ID
A number used to differentiate different link layer connections
originated from the same device.
Dormant mode
Certain wireless technologies support dormancy, which allows
the mobile to go into power saving mode. This typically occurs
when the mobile has been idle for some time, but could be
initiated by the network.
Foreign Agent IP Address Derivation
The derivation of the IP address of a source foreign agent or a
target foreign agent based on the receipt of a link layer
trigger at the target foreign agent or the source foreign agent
respectively.
Gateway Foreign Agent(GFA)
A foreign agent with publicly routable IP address that acts as
a concentration point for other foreign agents within an
administrative domain. Upon successful global registration
(registration with Home agent) of a mobile node, the GFA
supports local registration when the mobile node changes its
point of Attachment to some other foreign agent of the same
administrative Domain.
Home Domain
The domain where the home network [1] and home agent [1] are
located.
International Mobile Subscriber information (IMSI)
A number used for identifying a mobile subscriber station.
Link layer
A link layer specifies a protocol used by communicating nodes
to exchange information over a physical link. A mobile node
attaches itself to a mobile access network, before it can be
served by a foreign agent. A mobile node's link layer address
is the media access control(MAC) address of the mobile node's
network interface.
Calhoun et al. expires May 2001 [Page 5]
INTERNET DRAFT November 2000
Mobility Agent
A foreign agent or a home agent. The foreign agent types
include an anchor foreign agent and a gateway foreign agent.
Mobility Advertisement
An advertisement message constructed by attaching a special
extension to a router advertisement message.
Movement Detection
A detection of a movement in the link layer attachement of the
mobile node to a mobile access network.
Ping-Pong Handoff
The rapid oscillation of a mobile node among coverage area of
two or more foreign agents.
Proactive Foreign agent
A foreign agent that initiates mobile/IP registration on behalf
of a mobile node due to reception of some link layer trigger
event.
Source Trigger
A signal received by the source foreign agent mobile/IP stack,
via the link layer, when the mobile node departs from the
serving area of the source foreign agent.
Target Trigger
A signal received by the target foreign agent mobile/IP stack,
via the link layer, when the mobile node arrives at the serving
area of the target foreign agent.
Trigger
The link layer signal used by wireless link layer to inform
inter foreign agent handoff event to Mobile/IP stack.
Visited Domain
An administrative domain, visited by a Mobile IP client, and
containing the AAA infrastructure needed to carry out the
necessary operations enabling Mobile IP registrations. From
the point of view of the foreign agent, the foreign domain is
the local domain.
1.2 Fast handoffs
MNs connect to FAs via direct, link-layer connections. Because an FA
is directly connected to the link-layer, it may obtain link-layer
information such as power measurements that might indicate the
Calhoun et al. expires May 2001 [Page 6]
INTERNET DRAFT November 2000
necessity of a hand-off to a new FA. The FA can also gain assurance
of the MN's identity through link-layer authentication, and can
authenticate the stream of traffic coming from the MN, including any
power measurements or other indications used for hand-off.
In this document, we will assume that the link-layer events are
signaled to the Foreign Agent as "triggers". The acquisition of a
"trigger" to signal that a hand-off is necessary may be more
difficult when the technologies differ. We assume that any such
triggers will be sufficient to derive the IP addresses of the Foreign
Agents that will receive or send the hand-off. If such a trigger is
not available or if the MN decides on its own that a hand-off is to
take place, then one of the FAs can often still derive the identity
(IP address) of the other from link-layer messages.
In order for the Mobile IP protocol to provide fast hand-off, the
following problems must be addressed:
1. Reducing the latency involved in the registration process.
Although optimization of the Registration process is not
typically considered a Hand-Off problem, this proposal assumes
that such a mechanism is in place.
2. Reducing the latency involved in the Mobile Node's movement
detection process.
3. "Bi-casting" the Mobile Node's traffic to two (or more) points
of attachment, ensuring that the mobile's traffic is delivered
as soon as the link layer hand-off is completed.
4. Support for Reverse Tunneling, which MAY be required for
private addresses.
5. The Security Relationships between the mobility entities for
inter-domain hand-offs.
6. Does not increase mobile power consumption
2.0 Registration Latency
The Mobile IP protocol [1] requires that a Mobile Node registers with
a Foreign Agent, and subsequently its Home Agent, in order to have
its packets delivered to its current point of attachment. The Mobile
IP Regional Registration [6] specification proposes optimized
registration approaches using two different methods:
1. Gateway Foreign Agents (GFA), which are mobility agents that
act as concentration points for Foreign Agents within an
Administrative Domain.
2. Anchor Foreign Agents (AFA), where a previously used Foreign
Agent becomes an anchor point when a mobile moves to a new
Foreign Agent.
Calhoun et al. expires May 2001 [Page 7]
INTERNET DRAFT November 2000
Both GFAs and AFAs allow a Mobile Node's registration message to be
processed by a Mobility Agent in the local domain, eliminating the
need to contact the Home Agent, which MAY be topologically distant.
2.1 Gateway Foreign Agents
The Mobile IP Regional Registration specification introduces the
Gateway Foreign Agent (GFA), as a mobility agent that two Foreign
Agents providing service to a Mobile Node have in common. Figure 1
provides an example of a Mobile's initial registration, through the
GFA. Given this is the first registration message, the message MUST
be forwarded to the Home Agent. All packets destined for the mobile
will be delivered to the GFA, which in turn will forward the packets
to the Foreign Agent servicing the Mobile Node.
Reg Req +-----+ Reg Req
+----------->| oFA |--------------+
| +-----+ |
| v
+----+ +-----+ Reg Req +----+
| MN | | GFA |<------->| HA |
+----+ +-----+ +----+
+-----+
| nFA |
+-----+
Figure 1 - Initial Registrations through GFA
In the event that the mobile moves to a new Foreign Agent that is
serviced by a GFA that is common with oFA, the Mobile Node MAY issue
a Regional Registration Request (see Figure 2). The Regional
Registration message does not need to be forwarded to the Home Agent,
since the mobile's traffic can still be delivered to the same GFA.
This optimized approach effectively reduces the latency involved in
the registration process.
Calhoun et al. expires May 2001 [Page 8]
INTERNET DRAFT November 2000
+-----+
| oFA |
+-----+
+----+ +-----+ +----+
| MN | | GFA | | HA |
+----+ +-----+ +----+
| ^
| +-----+ |
+------------>| nFA |-------------+
Regional Reg +-----+ Regional Reg
Figure 2 - Regional Registration through GFA
2.2 Anchor Foreign Agent
The Mobile IP Regional Registration specification introduces what
this document will call the Anchor Foreign Agent, which is similar to
[7]. The Anchor Foreign Agent operates very similarly to the GFA,
with the exception that the mobile's old Foreign Agent acts as an
anchor point for the Mobile Node.
In order to minimize the latency involved in the registration
process, the Mobile Node MAY issues a Regional Registration message,
setting the old Foreign Agent as the GFA, as shown in Figure 3. Once
completed, the Mobile Node MAY issue an additional RFC 2002 compliant
Registration Messages to eliminate the routing leg through the anchor
Foreign Agent.
+-----+ +----+
| oFA | | HA |
+-----+ +----+
^
+----+ |
| MN | | Regional
+----+ | Reg
| |
| +-----+
+------------>| nFA |
Regional Reg +-----+
Figure 3 - Regional Registrations through an AFA
3.0 Movement Detection
The Mobile IP protocol [1] and the Regional Registration extension
[6] require Mobile Nodes to listen for, or solicit, advertisements in
order to detect that a movement to a new IP subnet has occurred. This
Calhoun et al. expires May 2001 [Page 9]
INTERNET DRAFT November 2000
movement detection mechanism introduces significant latency into the
hand-off process, which causes service degradation, especially for
real-time services. Service is further impacted given the additional
latency introduced through the registration process that follows the
movement detection, since the mobile's traffic can only be delivered
once all of the registration has completed.
There have been many solutions proposed to solve this problem,
including increasing the advertisement frequency. In networks where
radio spectrum is expensive or bandwidth is limited, the additional
signaling required for increasing advertisement frequency is a
serious issue impacting deployability.
In this document, we propose that the Foreign Agent take a pro-active
approach and issue the Handoff messages on behalf of the Mobile Node
(acting as a surrogate of sorts). When a Foreign Agent is aware that
a hand-off is occurring at the link-layer, a trigger is sent to the
Mobile IP protocol stack.
+-----+
| GFA |
+-----+
^ |
3. Regional | | 4. Regional
Reg Request | | Reg Reply
| v
+-----+ 1. Handoff Request +-----+
| | -----------------> | |
| oFA | | nFA |
| | 2. Handoff Reply | |
+-----+ <----------------- +-----+
+-----+ Movement +-----+
| MN | - - - - - - - - -> | MN |
+-----+ +-----+
Figure 4 - Source Trigger Pro-Active Handoff
A source trigger (see Figure 4) is one that is obtained by the old
Foreign Agent (oFA) once the link layer detects that the Mobile Node
is departing its coverage area. A target trigger (see Figure 5), on
the other hand, is one that is obtained by the new Foreign Agent
(nFA) once the link layer detects that the Mobile Node is arriving in
its coverage area. Note that both triggers may be available before
the actual completion of the link layer handoff.
The messages depicted in both Figures 4 and 5 are very similar. The
main difference is the initiator of the Handoff Request message. In
both examples, an optional Gateway Foreign Agent is used, which
Calhoun et al. expires May 2001 [Page 10]
INTERNET DRAFT November 2000
requires the use of the Regional Registration messages [6].
In both the source and target triggers, a Foreign Agent obtains
link-layer information, such as power measurements, that indicate the
necessity of a handoff to the new Foreign Agent.
In the event of a source trigger, oFA transmits a Handoff Request
message to nFA. The Handoff Request MUST include the Mobile Node's
Home Address, Home Agent Address, remaining registration lifetime, as
well as the Link-Layer Address Extension (see Section 10). The GFA's
identity MUST also be present, if one was used for the Mobile Node's
registration. Upon receipt of the message, nFA MUST create the Mobile
Node's visitor entry, and respond with the Handoff Reply message.
+-----+
| GFA |
+-----+
^ |
3. Regional | | 4. Regional
Reg Request | | Reg Reply
| v
+-----+ 1. Handoff Request +-----+
| | <----------------- | |
| oFA | | nFA |
| | 2. Handoff Reply | |
+-----+ -----------------> +-----+
+-----+ Movement +-----+
| MN | - - - - - - - - -> | MN |
+-----+ +-----+
Figure 5 - Target Trigger Pro-Active Handoff
In target triggers, the trigger occurs on nFA, which results in the
transmission of a Handoff Request to oFA. The Handoff Request message
MUST include the Mobile Node's Link-Layer Address (see Section 10) in
order for oFA to correctly identify the Mobile Node. The request
message MAY include additional Mobile Node information, if such
information was provided by the link layer. Upon receipt of the
request, oFA MUST respond with the Handoff Reply message, which
includes the Mobile Node's Home Address, Home Agent Address,
remaining registration lifetime and Link-Layer Address Extension. If
a GFA was used in the Mobile Node's registration, it's address MUST
be supplied.
Regardless of the direction of the Handoff Request, if nFA receives
GFA information within the message from oFA, it SHOULD issue a
Regional Registration Request with the GFA, which will respond with
the Regional Registration Reply.
Calhoun et al. expires May 2001 [Page 11]
INTERNET DRAFT November 2000
3.1 Ping-Pong effect
Some link-layers are subject to rapid motion of MNs between two FAs.
For example, even though link-layer power measurements may indicate
that a hand-off is necessary, the mobile may fail to attach to the
new point of attachment, and return almost immediately to its old
point of attachment. This event is known as a "ping-pong" effect.
Data +-----+ Data +----+
+-------------| oFA |<--------------------------| HA |
| +-----+ +----+
v ^ |
+----+ Handoff | | Data
| MN | Request | |
+----+ | |
^ v v
| +-----+
+-------------| nFA |
Data +-----+
Figure 6 - Bi-Casting by the Anchor Foreign Agent
Figure 6 provides an example of bi-casting a Mobile Node's through
both the old and new Foreign Agents. Bi-casting is established when
the oFA issues a successful Handoff Reply to nFA, or receives a
successful Handoff Reply from nFA. This causes oFA to forward all of
the Mobile Node's traffic to the nFA, as well as to the Mobile Node,
if a link-layer channel exists.
Figure 7 provides an example where bi-casting is performed on the
Gateway Foreign Agent, which is initiated by nFA setting the 'S' bit
(Simultaneous Binding) in the Regional Registration Request.
Data +-----+ Data
+-------------| oFA |<-------------+
| +-----+ |
v |
+----+ +-----+ Data +----+
| MN | | GFA |<--------| HA |
+----+ +-----+ +----+
^ |
| +-----+ |
+-------------| nFA |<-------------+
Data +-----+ Data
Figure 7 - Bi-Casting by the Gateway Foreign Agent
When simultaneous bindings are in effect, and a ping-pong event
Calhoun et al. expires May 2001 [Page 12]
INTERNET DRAFT November 2000
occurs, the mobile's service is guaranteed not to experience any
additional latency beyond that imposed by the link-layer handoff.
4.0 Reverse Tunneling Support
In the event the Mobile Node requested Reverse Tunneling [12]
support, by setting the 'T' bit in its Registration Request, the
Handoff message from oFA (see Sections 8.0 and 9.0) includes the 'T'
bit enabled to inform nFA to establish a bi-directional tunnel for
the visitor entry.
5.0 Security Relationships
The Mobile IP Regional Registration specification [6] 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 8).
+-----+ +-----+
| AAA |-------------->| AAA |
+-----+ +-----+
^ |
| |
| AAA |
| Hand-Off |
| Req |
| v
+-----+ +-----+
| oFA | | nFA |
+-----+ +-----+
+-----+ Movement +-----+
| MN | - - - - - - > | MN |
+-----+ +-----+
Figure 8 - Inter-FA communication using AAA
Note that it is possible for geographically neighboring Foreign
Calhoun et al. expires May 2001 [Page 13]
INTERNET DRAFT November 2000
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.
6.0 Power Consumption
An additional benefit that derives from this proposal is the
potential for tracking mobile nodes while in dormant mode, if the
radio link supports it, allowing significant power saving without
adding additional complexity to the network layer protocol in the
wired network. One of the primary innovations proposed here, namely
to allow the Foreign Agents to set up visitor entries prior to the
Mobile Node's registration, is also useful for power saving. Certain
radio link layers allow the mobile node to enter dormant mode when
idle. Allowing the network to control the handoff ensures that the
mobiles do not have to be removed out of dormant mode in order to
establish a Mobile IP handoff.
Limiting power consumption is a requirement for certain wireless
Standards Defining Organizations (SDOs), and a Mobile IP fast handoff
proposal MUST satisfy this requirement.
7.0 Operation
A Foreign Agent can receive two different types of triggers informing
it of a handoff (The event that causes the trigger may be derived via
link layer messaging assistance from the network or from the mobile):
- a "source trigger" is when the old FA is informed of an
upcoming link-layer handoff,
- a "target trigger" occurs at the new FA when it is informed
that a link layer handoff is in progress.
The method by which such triggers occur are link-layer specific, and
are outside the scope of this document. It is also possible that a
particular kind of link layer technology can support both source and
target triggers.
7.1 Foreign Agent Considerations
Upon receipt of a trigger event, a Foreign Agent MAY issue a Handoff
request message to the Foreign Agent the mobile is being handed off
to/from. If the message is the result of a target trigger, the Type
Calhoun et al. expires May 2001 [Page 14]
INTERNET DRAFT November 2000
Of Trigger bit MUST be set and the Link-Layer Address Extension (see
Section 10) MUST be present. The message's Home Address and Home
Agent Address fields MAY be set to NULL if this information is not
known at the time the message is transmitted.
Upon receipt of a Handoff Request message with the Type Of Trigger
bit set, a Foreign Agent MUST respond with the Handoff Reply message.
The Handoff Reply MUST include both the Mobile Node's Home Address
and Home Agent Address in the message header. The remaining mobile's
registration lifetime MUST be included in the Reply's lifetime field.
Furthermore, the Foreign Agent MAY include any security associations
that were dynamically created, an example of such security
associations are those described in [8]. If a Gateway Foreign Agent
was used in the Mobile's registration, the GFA's identity MUST be
included in the Gateway Foreign Agent Address Extension [6] 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
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 (see [8] for an example). If a Gateway Foreign
Agent was used for the mobile, it's identity MUST be included in the
Gateway Foreign Agent Address Extension [6].
Upon receipt of a Handoff Request with the Type Of Trigger bit
disabled, a Foreign Agent MUST process the packet and respond with
the Handoff Reply message. If successfully processed, the Foreign
Agent MUST create a Visitor Entry for the Mobile Node, and be
prepared to deliver packets received by the initiator of the Handoff
Request destined for the Mobile Node. The Handoff Reply message MUST
Calhoun et al. expires May 2001 [Page 15]
INTERNET DRAFT November 2000
include the Home Address, Home Agent Address, lifetime value, and the
Link-Layer Address Extension (see Section 10).
A Foreign Agent that receives a Handoff Reply with the Code field set
to success (zero value) MUST "bi-cast" all packets destined to the
Mobile Node to both the Mobile Node and to the new Foreign Agent.
If the message received by the new Foreign Agent contained a GFA IP
Address Extension [6], and it shares a security association with the
GFA, it MUST issue a Regional Registration Request to the GFA. The
Regional Registration Request's Care-Of address field MUST be set to
the local Foreign Agent's address, while the GFA IP Address MUST be
set to the address of the recipient of the request. The request's
lifetime field is set to an administratively configured value. A
successful Regional Registration Reply MUST cause the Foreign Agent
to create a visitor entry for the Mobile Node.
If a Regional Registration Reply message is received with the code
field set to DO_NOT_SERVICE_MN (Section 11), the Foreign Agent SHOULD
NOT provide service to the Mobile Node. The Foreign Agent MAY enforce
this by closing the Link-Layer connection (if possible), not issuing
any Mobility Advertisements to the Mobile Node (assuming a point-to-
point Link Layer), or simply denying all Registration Requests with
the error code set to 65 (Administratively Prohibited) [1].
Once a visitor entry has been created, and the Mobile Node
establishes a link layer channel with the Foreign Agent, its traffic
will be immediately delivered, along with a Mobility Advertisement
message [1]. A Mobile Node MUST issue a Registration Request when it
receives a Mobility Advertisement from a new Foreign Agent.
Note that Foreign Agents MAY delay in sending Mobility
Advertisements, especially to reduce noticeable service disruption
during a ping-pong effect. However, when doing so, the Foreign Agent
MAY need to re-issue a new Handoff Request to oFA (and optionally the
Regional Registration message to GFA), to extend the visitor entry's
lifetime.
Delaying Mobility Advertisements MAY also be done in wireless
technologies that support dormant mobiles. When this is done, a
Foreign Agent would typically wait to send the advertisement until
the mobile is no longer in the dormant mode. When data is received by
the Foreign Agent for a dormant Mobile Node, it SHOULD initiate the
link-layer mechanism that causes the mobile to "wake-up" (this is
typically known as paging).
The above procedures require that Foreign Agents issue Handoff
Requests as a result of Link-Layer triggers. However, the discovery
Calhoun et al. expires May 2001 [Page 16]
INTERNET DRAFT November 2000
of the identity of the Foreign Agents to which the Handoff messages
must be sent is outside the scope of this document.
In the event that a Foreign Agent handling a particular Mobile Node's
visitor entry is soon to expire, and the Mobile Node has not yet
issued a Registration Request, the FA has the option to transmit a
new Handoff Request message to the old Foreign Agent (and the
optional Regional Registration Request to the GFA). Whether the
renewal is performed on behalf of the Mobile Node is a policy
decision up to the network administrator.
A Foreign Agent MAY receive packets for a Mobile Node to which it
does not have a direct link layer connection. At this point, the
Foreign Agent MAY:
1. Drop all packets for the Mobile Node
2. Buffer packets for the Mobile Node
3. Attempt to establish a link-layer connection with the mobile
4. Issue a Regional Registration Request with a zero lifetime
Given that a Mobile Node's packets will be delivered prior to
registration, a Mobile Node is free to discard all packets received
from Foreign Agents with which it hasn't registered.
When the new Foreign Agent receives the Mobile Node's Registration
Request [1], its Anchor Foreign Agent changes to the new Foreign
Agent. The Foreign Agent MUST transmit a Handoff Request message to
the old Foreign Agent with the lifetime field set to zero. A Foreign
Agent that receives a Handoff Request with the lifetime field set to
zero is being informed that it is no longer the anchor point for the
mobile. It MAY issue a Handoff Request to the new Foreign Agent in
the future if it wishes to keep receiving the mobile's packets for
possible delivery.
When a Foreign Agent determines that it is no longer servicing a
Mobile Node, it SHOULD issue a Regional Registration Request message
with the lifetime field set to zero (0). This will cause the visitor
entry associated with the Foreign Agent's Care-Of address on the GFA
to be deleted. Foreign Agents MAY decide to not issue this message
immediately when a link-layer trigger is received, in order to
support smooth service during a ping-pong event.
7.2 Gateway Foreign Agent Considerations
Upon receipt of a Regional Registration Request, a GFA MUST create a
visitor entry indicating the Mobile Node's current point of
attachment. In the event that a visitor entry already exists, the
GFA SHOULD be able to create multiple visitor entries for the same
Calhoun et al. expires May 2001 [Page 17]
INTERNET DRAFT November 2000
Mobile Nodes with different Care-Of addresses. If the 'S' bit was
enabled in the Regional Registration Request, the GFA MUST be able to
forward the mobile's packets to all Foreign Agents in the visitor
entries.
When constructing the Regional Registration Reply, the GFA SHOULD
include the FA-FA authentication extension [6], and set the lifetime
field to the lesser of:
1. number of seconds before the Mobile Node's Registration with
its Home Agent will expire.
2. The lifetime of the locally created Visitor Entry.
In the event that the Regional Registration Request's lifetime field
was set to zero (0), the GFA MUST remove the visitor entry associated
with the Care-Of address in the message.
Should the GFA decide that the Foreign Agent is not to provide
service to the Mobile Node, it MUST issue a Regional Registration
Reply message, with the code field set to DO_NOT_SERVICE_MN (see
Section 11).
8.0 Handoff Request Message
The Handoff Request message is used to inform a peer that a pro-
active handoff is being initiated. The Handoff Request message can be
used for both source and target triggers, through the Type of Trigger
'I' bit in the message flags. When sent as a result of a target
trigger, the Home Address and Home Agent fields MAY be set to zero
(unless this information was communicated by the link layer, which is
outside the scope of this document).
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 ...
+-+-+-+-+-+-+-+-
Calhoun et al. expires May 2001 [Page 18]
INTERNET DRAFT November 2000
Type TBD (Handoff Request)
S When set, and when no GFA address extension is
present, it indicates that both oFA and nFA will
attempt to deliver datagrams directly to MN, if
a link-layer connection exists. If a GFA
address extension is present, it implies that
nFA should set the 'S' bit in its regional
registration.
I Type of Trigger. A value of zero is a source
trigger (sent by oFA), while a value of one is a
target trigger (sent by nFA).
M, G, T As defined in [1, 12]. This refers to the
tunnel between oFA and nFA, or, if GFA IP
address extension is present, to the parameters
that should be requested in the Regional Reg
Req.
Lifetime The requested Lifetime for which nFA will serve
the MN on behalf of oFA, without requiring a new
registration.
MN Home Address The home address of the mobile node. When using
a private address, the G and T flags must be
sent and a GRE Key extension must be included.
Home Agent Addr The home agent address of the mobile node.
Identification As in defined in [1].
Extensions The Message MUST include LLA (see Section 10),
the FA-FA Authentication Extension [6], and MAY
include GFA IP address.
9.0 Handoff Reply Message
The Handoff Reply message is sent in response to the Handoff Request
message. When a source trigger caused the Handoff Request message to
be sent, this message is sent with a successful code if the Visitor
Entry was successfully created. When a target trigger caused the
Handoff Request message, receipt of this message with a successfuly
code SHOULD cause the Visitor Entry to be created.
Calhoun et al. expires May 2001 [Page 19]
INTERNET DRAFT November 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|x|I|M|G|r|T|x| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type TBD (Handoff Reply)
Code A value indicating the result of the Handoff
Request. See below for a list of currently
defined Code values.
Lifetime If the Code field indicates that the
registration was accepted, the Lifetime field is
set to the number of seconds remaining before
the registration is considered expired. A value
of zero indicates that the mobile node has been
deregistered. A value of 0xffff indicates
infinity. If the Code field indicates that the
registration was denied, the contents of the
Lifetime field are unspecified and MUST be
ignored on reception.
S When set, and when no GFA address extension is
present, it indicates that both oFA and nFA will
attempt to deliver datagrams directly to MN, if
a link-layer connection exists. If a GFA
address extension is present, it implies that
nFA should set the 'S' bit in its regional
registration.
I Type of Trigger. A value of zero is a source
trigger (sent by oFA), while a value of one is a
target trigger (sent by nFA).
M, G, T As defined in [1, 12]. This refers to the
Calhoun et al. expires May 2001 [Page 20]
INTERNET DRAFT November 2000
tunnel between oFA and nFA, or, if GFA IP
address extension is present, to the parameters
that should be requested in the Regional Reg
Req.
MN Home Address The home address of the mobile node. When using
a private address, the G and T flags must be
sent and a GRE Key extension must be included.
Home Agent Addr The home agent address of the mobile node.
Lifetime The requested Lifetime for which nFA will serve
the MN on behalf of oFA, without requiring a new
registration.
Identification As in defined in [1].
Extensions The Message MUST include LLA (see Section 10)
and the FA-FA Authentication Extension [6].
10.0 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 [13], and each
sub-type of link-layer address defines its own sub-structure. This
draft defines two sub-types, the cdma2000 IMSI and the Ethernet
Address. Future RFCs should allocate their own sub-type and define
their own address formats.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
The length of the Link Layer Address + the one octet Sub-Type field
Sub-Type
Calhoun et al. expires May 2001 [Page 21]
INTERNET DRAFT November 2000
This field contains the Link Layer sub-type identifier
LLA
Contains the Link Layer Address
In this document, two subtypes are defined:
1 cdma2000 International Mobile Station Identity [14]
2 Ethernet 48 bit MAC address [15]
3 64 bit Global ID, EUI-64 [19]
10.1 cdma2000 Link Layer Address Extension
The cdma2000 Link Layer Address Extension contains the International
Mobile Station Identity, as defined in [14].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
The length of the IMSI field + the one octet Sub-Type field
Sub-Type
1
IMSI
Contains the IMSI, in the form:
<IMSI>:<Connection Id>
Where the <IMSI> is an ASCII-based representation of the
International Mobile Station Identifier, most significant digit
first, ":" is ASCII 0x3a, and the Connection ID is the ASCII
representation of a small, decimal number used for
distinguishing different link-layer connections from the same
device.
Calhoun et al. expires May 2001 [Page 22]
INTERNET DRAFT November 2000
10.2 Ethernet Link Layer Address Extension
The Ethernet Link Layer Address Extension contains the 48 bit
Ethernet MAC Address, as defined in [15].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
7 (includes the Sub-Type field)
Sub-Type
2
MAC
Contains the 48 bit Ethernet MAC Address.
10.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 [19].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
7 (includes the Sub-Type field)
Sub-Type
Calhoun et al. expires May 2001 [Page 23]
INTERNET DRAFT November 2000
3
MAC
Contains the 64-Bit Global Identifier Address.
11.0 Error Values
The following table contains the name of Code [9] to be returned in a
Registration Reply, the value for the Code, and the section in which
the error is first mentioned in this specification.
Error Name Value Section of Document
---------------------- ----- -------------------
DO_NOT_SERVICE_MN TBD 7.1
12.0 IANA Considerations
The number for the Generalized Link Layer Address Extension in
section 10 is taken from the numbering space defined for Mobile IP
registration extensions defined in RFC 2002 [1]. These MUST NOT
conflict with any numbers used in RFC 2002[1], RFC 2344 [12], RFC
2356 [16], RFC 2794 [17] and RFC 3012 [18].
The Code values specified for errors, listed in section 11, MUST NOT
conflict with any other code values listed in RFC 2002 [1], RFC 2344
[12], RFC 2356 [16], RFC 2794 [17] and RFC 3012 [18].
Sections 8 and 9 require numbers assigned from the Mobile IP control
message type address space. The numbers assigned MUST NOT conflict
with [1], [6] and [7].
13.0 Security Considerations
Similar to [6] and [7], this specification assumes that the local
Foreign Agent, and the GFA (or AFA) inherently trust each other. This
MAY be achieved through the use of a long lived security association.
This specification introduces a new change to Mobile IP, which is the
ability for a Mobile Node to receive packets from a Foreign Agent to
which it has not yet registered. In the event that the Mobile Node
does not wish to receive packets from unknown Foreign Agents, it MAY
drop them.
Although this document does not specify how Foreign Agents can
Calhoun et al. expires May 2001 [Page 24]
INTERNET DRAFT November 2000
identify, or track, Mobile Nodes, it is assumed that the wireless
link layer be sufficiently secure in order to correctly identify a
Mobile Node. Wireless networks that do not provide such features will
be subjected to impersonation attacks, where malicious nodes could
cause the Foreign Agents to believe that a Mobile Node has moved to
other service areas.
14.0 References
[1] C. Perkins, Editor. "IP Mobility Support". RFC 2002. October
1996.
[2] T. Hiller et al. "Cdma2000 Wireless Data Requirements for AAA".
draft-hiller-cdma2000-AAA-00.txt (work in progress). October
1999.
[3] U. Black. "2nd Generation Wireless Networks". Prentice-Hall.
New York. 1999.
[4] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels". BCP 14. RFC 2119. March 1997.
[5] C. Perkins and D. Johnson. "Route Optimization in Mobile IP".
draft-ietf-mobileip-optim-08.txt (work in progress). February
1999.
[6] E. Gustafsson, A. Jonsson, C. Perkins. "Mobile IP Regional
Registration", draft-ietf-mobileip-reg-tunnel-02.txt (work in
progress), March 2000.
[7] G. Dommety. "Local and Indirect Registration for Anchoring Hand-
offs", draft-dommety-mobileip-anchor-handoff-00.txt (work in
progress), March 2000.
[8] P. Calhoun, H. Akhtar, E. Qaddoura, N. Asokan, "Foreign Agent
Keys Encoded as Opaque Tokens for use in Hand-off Process",
draft-calhoun-mobileip-fa-tokens-00.txt (work in progress),
March 2000.
[9] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing
Encapsulation (GRE). Request for Comments (Informational) 1701,
Internet Engineering Task Force, October 1994.
[10] C. Perkins. Minimal Encapsulation within IP. Request for Com-
ments (Proposed Standard) 2004, Internet Engineering Task Force,
October 1996.
Calhoun et al. expires May 2001 [Page 25]
INTERNET DRAFT November 2000
[11] Mohamed M.Khalil, Emad Qaddoura, Haseeb Akhtar, Pat R. Calhoun,
"Generalized NAI Extension (GNAIE)", draft-ietf-mobileip-gnaie-
00.txt (work in progress), February 2000.
[12] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May
1998.
[13] Khalil, and et. al. Mobile IP Extensions Rationalization (MIER)
draft-ietf-mobileip-mier-00.txt, Dec 1999.
[14] TIA/EIA/IS-95-B
[15] D. Plummer, "An Ethernet Address Resolution Protocol - or - Con-
verting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", RFC 826, Symbolics,
Inc., November 1982.
[16] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
Mobile IP", RFC 2356, June 1998.
[17] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier
Extension", RFC 2794, March 2000.
[18] C. Perkins, P. Calhoun. Mobile IP Challenge/Response Exten-
sions. RFC 3012, November 2000.
[19] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Regis-
tration Authority",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
March 1997.
15.0 Acknowledgements
The authors would like to thank Charles Perkins, George Tsirtsis and
Scott Corson for their valuable feedback.
16.0 Authors' Addresses
Questions about this memo can be directed to:
Calhoun et al. expires May 2001 [Page 26]
INTERNET DRAFT November 2000
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650 786 7733
Fax: +1 650 786 6445
E-mail: pcalhoun@eng.sun.com
Tom Hiller
Lucent Technologies
Rm 2F-218
263 Shuman Blvd
Naperville, IL 60566-7050
USA
Phone: +1 630 979 7673
FAX: +1 630 979 7673
E-Mail: tom.hiller@lucent.com
James Kempf
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650 786 5890
Fax: +1 650 786 6445
E-mail: james.kempf@eng.sun.com
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
Calhoun et al. expires May 2001 [Page 27]
INTERNET DRAFT November 2000
Chandana Pairla
University of Illinois - Urbana Champaign
3315, DCL,
1304, W. Springfield Ave.,
Urbana, IL 61801
USA
Phone: +1 217 244 7117
E-mail: pairla@uiuc.edu
Sebastian Thalanany
Motorola
1475 West Shure Drive
Arlington Heights, IL - 60004
USA
Phone: +1 847 435 9296
E-mail: sthalan1@email.mot.com
Ajoy Singh
Motorola
1501 West Shure Drive
Arlington Heights, IL รด 60004
USA
Phone: +1 847 632 6941
E-mail: asingh1@email.mot.com
17.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing 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 lim-
ited 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 on an "AS IS" basis
Calhoun et al. expires May 2001 [Page 28]
INTERNET DRAFT November 2000
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
CLAIMS 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."
Calhoun et al. expires May 2001 [Page 29]