INTERNET DRAFT James Kempf
Category: Standards Track Pat R. Calhoun
Title: draft-calhoun-mobileip-proactive-fa-01.txt Sun Microsystems, Inc.
Date: June 2000 Chandana Pairla
University of Illinois
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.
Copyright (C) The Internet Society 1999. All Rights Reserved.
Abstract
The Mobile IP WG has been investigating how its protocol can be used
in environments that require fast hand-off, which is especially
important for real-time applications such as voice and video. The
Calhoun, Kempf expires December 2000 [Page 1]
INTERNET DRAFT June 2000
Mobile IP protocol is not currently designed to provide fast hand-off
services to Mobile Nodes.
This specification proposes extensions to the Mobile IP protocol that
may be used by Foreign Agents within a domain in order to setup a
Mobile Node's visitor entry, and forward its packets, prior to the
formal Mobile IP registration process.
Table of Contents
1.0 Introduction
1.1 Requirements language
2.0 Operation
2.1 Foreign Agent Considerations
2.2 Gateway Foreign Agent Considerations
3.0 Mobile Node Hand-Off Request
4.0 Mobile Node Hand-Off Reply
5.0 IANA Considerations
6.0 Security Considerations
7.0 References
8.0 Acknowledgements
9.0 Authors' Addresses
10.0 Full Copyright Statement
1.0 Introduction
The Mobile IP WG has been investigating how its protocol can be used
in environments that require fast hand-off, which is especially
important for real-time applications such as voice and video [2].
This specification provides fast hand-off extensions to the Mobile IP
protocol.
The Mobile IP protocol [1] currently requires that a Mobile Node
listen for, or solicit, advertisements in order to detect that a
hand-off is required, which adds significant latency to the hand-off.
Mobility agents that advertise frequently do minimize the movement
detection delay, but it is questionable whether frequent
advertisements are appropriate in low bandwidth networks, such as
cellular networks.
Calhoun, Kempf expires December 2000 [Page 2]
INTERNET DRAFT June 2000
Reg Req +-----+ Reg Req
/----------->| oFA |--------------\
| +-----+ |
| v
+----+ +-----+ Reg Req +----+
| MN | | GFA |<------->| HA |
+----+ +-----+ +----+
Figure 1 - Initial Mobile Node Registration
The Mobile IP protocol [1] requires that the Mobile Node registers
with the Foreign Agent, and subsequently its Home Agent, in order to
have its packets delivered. Certain optimizations have been proposed,
such as Regional Registration [6] and Anchor Hand-off [7], which
reduces the Registration's round trip time (see Figure 1). These
proposals allow a Mobile Node's registration message to be processed
by a common Mobility Agent in the hierarchy, eliminating the need to
contact the Home Agent (see Figure 2). Of course, this optimization
is only valid as long as the old and new local Foreign Agents have a
common "parent" Foreign Agent in the hierarchy, depicted as Gateway
Foreign Agent (GFA) in Figures 1 and 2.
+-----+
| oFA |
+-----+
+----+ +-----+ +----+
| MN | | GFA | | HA |
+----+ +-----+ +----+
| ^
| +-----+ |
\----------->| nFA |-------------/
Reg Req +-----+ Reg Req
Figure 2 - Registration as a Result of a Hand-off
In order for Mobile IP to be a suitable mobility management protocol
for multimedia protocols, it is necessary for packets to be delivered
to a Mobile Node as soon as it enters a new service area. The added
delays of detecting movement, and the registration process, would
cause significant and noticeable disruptions to the multimedia
stream. Of course, the Mobile Node SHOULD be required to issue a
Mobile IP registration in order to continue to receive service.
In certain networks, it is possible for Mobile Nodes to receive
service from multiple service areas. This is especially important
when the Mobile Node is bouncing back and forth between service
areas. In such cases, it MAY be necessary for the GFA to forward a
Calhoun, Kempf expires December 2000 [Page 3]
INTERNET DRAFT June 2000
Mobile Node's packets to ALL Foreign Agents that have registered that
they are providing service to the Mobile Node
Data +-----+ Data
/------------| oFA |<-------------\
| +-----+ |
v |
+----+ +-----+ Data +----+
| MN | | GFA |<--------| HA |
+----+ +-----+ +----+
^ |
| +-----+ |
\------------| nFA |<-------------/
Data +-----+ Data
Figure 3 - Forwarding the Mobile Node's traffic
This proposal, combined with either [6] or [7], will provide a
complete fast hand-off solution for Mobile IP.
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].
2.0 Operation
When a Foreign Agent detects that a Mobile Node could be serviced by
another FA, it issues a Binding Update message to the new FA. The
method by which a Foreign Agent determines a Mobile Node's current
location and movement patterns MAY be known through an interface with
the underlying link layer or a radio specific protocol, and is
outside the scope of this document.
The Binding Update contains the Mobile Node's home address, Security
Association information [8], as well as the identity of the Gateway
Foreign Agent (GFA) [6], or the Anchor Foreign Agent (AFA) [7].
Upon receipt of the Binding Update, the new Foreign Agent issues a
Hand-off Request to the GFA or the AFA. The Hand-off request is used
by the GFA or the AFA to register the new Foreign Agent as also being
able to deliver traffic to the Mobile Node. The GFA or AFA MAY
forward all packets destined for the Mobile Node through all Foreign
Agents that registered service to the MN (see figure 3).
Calhoun, Kempf expires December 2000 [Page 4]
INTERNET DRAFT June 2000
When the Mobile Node receives the advertisement from the new Foreign
Agent, it SHOULD issue a registration request message. The GFA MAY
decide to time out the entry created by the Hand-off message if the
Mobile Node does not issue a registration within a specific number of
seconds, which is indicated in the lifetime field of the Hand-off
Reply message.
+-----+
| oFA |
+-----+
|
+----+ | 1. Binding +-----+ +----+
| MN | | Update | GFA | | HA |
+----+ | +-----+ +----+
| v ^
3. Reg| +-----+ 2. Hand-Off Req |
Req \----------->| nFA |-----------------/
+-----+ 4. Reg Req
Figure 4 - Mobile Node hand-off
When the Mobile Node enters the new Foreign Agent's service area, the
new FA MAY forward all packets destined for the MN prior to
registration. The Mobile Node MAY discard all packets received from
an unknown Foreign Agent until an authenticated Registration has been
completed.
When a Foreign Agent determines that a Mobile Node is no longer in
its service area, it SHOULD issue a Hand-off Request, with the
lifetime field set to zero, informing the GFA that the Mobile Node is
no longer being serviced.
In wireless technologies that support Mobile Nodes with dormant mode,
this specification does not require that the MN wake up to register
when it detects that it has moved to a new service area. In such
networks, the new Foreign Agent MUST re-issue a Hand-off Request to
the GFA, prior to the expiration of the previous request. This
ensures that the GFA has an up to date list of a Mobile Node's
location. When data is received by the local Foreign Agent, that is
to be delivered to a dormant Mobile Node, it SHOULD send a page to
the MN informing it to wake up.
2.1 Foreign Agent Considerations
When a Foreign Agent detects that a Mobile Node is moving towards
another service area, it issues a Binding Update [5] to the Foreign
Calhoun, Kempf expires December 2000 [Page 5]
INTERNET DRAFT June 2000
Agent servicing the area. The method by which the Foreign Agent
detects the Mobile Node's current location and movement patterns is
outside the scope of this document. The Binding Update message MUST
include the GFA extension [6], SHOULD include the FA-FA
authentication extension [6]. In the event that the local Foreign
Agents MUST process the MN-FA authentication extension [1], the
Binding Update MUST include the MN-Key-Token [8] extension.
Upon receipt of a Binding Update, a Foreign Agent SHOULD issue a
Hand-off Request message to the GFA indicated in the Binding Update
message. The Foreign Agent SHOULD set the lifetime field to be the
interval between router advertisements multiplied by two.
Upon receipt of the Hand-off Reply from the GFA, the Foreign Agent
SHOULD forward the Mobile Node's packets, unless the radio link is
not setup. The Foreign Agent MAY buffer such packets until the radio
link is established. In the event that the Mobile Node does not
issue a Registration Request prior to the number of seconds that was
indicated in the Hand-off Reply's lifetime field, the FA MAY expire
the entry, or attempt to re-issue another Hand-off request to the
GFA.
When a Foreign Agent detects that it is no longer servicing a Mobile
Node, it SHOULD issue a Hand-off Request to the GFA with the lifetime
field set to zero, indicating a deregistration.
If a Hand-off Reply is received from the GFA with the Code field set
to DO_NOT_SERVICE_MN (see section 5.0), the Foreign Agent SHOULD NOT
provide service to the Mobile Node. This COULD be achieved by
refraining from answering any router solicitations. In the event that
the interface between the Mobile Node and the Foreign Agent is
point-to-point, the Foreign Agent COULD refrain from issuing router
advertisements, or close the link layer connection.
2.2 Gateway Foreign Agent Considerations
Upon receipt of a Hand-off 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
register multiple local Foreign Agents servicing the Mobile Node. The
GFA SHOULD be able to forward packets destined for a Mobile Node to
all local Foreign Agents in the visitor entry.
When issuing the Hand-off Reply, the GFA SHOULD include the FA-FA
authentication extension, and set the lifetime field to the number of
seconds that the GFA will expire the visitor entry if no registration
request from the Mobile Node is received.
Calhoun, Kempf expires December 2000 [Page 6]
INTERNET DRAFT June 2000
Upon receipt of a Hand-off Request with the lifetime field set to
zero, the GFA MUST remove the local Foreign Agent from the visitor
entry.
In the event that the GFA does NOT want the local Foreign Agent to
provide service to the Mobile Node, the Hand-off Reply is returned
with the code set to DO_NOT_SERVICE_MN (see section 5.0).
3.0 Mobile Node Hand-Off Request
The Hand-Off Request message is sent by a local Foreign Agent to a
GFA or AFA, to inform it that it is servicing a particular Mobile
Node.
The UDP header is followed by the Mobile IP fields shown 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 |M|G| reseved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Foreign Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type TBD (Hand-off Request)
M If the 'M' (minimal encapsulation) bit is set, datagrams
MAY be tunneled to the mobile node using the minimal
encapsulation protocol [10].
G If the 'G' (Generic Record Encapsulation, or GRE) bit is
set, datagrams MAY be tunneled to the mobile node using
GRE [9].
reserved Reserved bits; sent as zero
Lifetime The number of seconds the GFA or AFA SHOULD keep the
Calhoun, Kempf expires December 2000 [Page 7]
INTERNET DRAFT June 2000
resulting visitor entry active. A value of 0xffff
indicates infinity. A value of zero (0) indicates that
the GFA MUST remove the New Foreign Agent from the Mobile
Node's visitor entry.
Home Address
The IP address of the mobile node.
Home Agent
The IP address of the mobile node's home agent.
New Foreign Agent
The IP address for the new Foreign Agent.
Identification
A 64-bit number used for matching Hand-Off Requests with
Hand-off Replies, and for protecting against replay
attacks of Hand-Off messages. See [1] for more
information.
Extensions
The fixed portion of the Hand-off Request is followed by
one or more Mobile IP Extensions. The GFA Extension [6]
MUST be present in the Hand-off Request. The Generalized
Foreign-Foreign Authentication Extension [6] SHOULD be
included in the Hand-off Request.
4.0 Mobile Node Hand-Off Reply
The Hand-Off Reply is sent by the GFA or AFA as a result of the
Hand-Off Request message.
The UDP header is followed by the Mobile IP fields shown below:
Calhoun, Kempf expires December 2000 [Page 8]
INTERNET DRAFT June 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type TBD (Hand-off Reply)
Code A value indicating the result of the Hand-Off Request.
See [1] for the list of supported codes.
Lifetime If the Code field indicates that the hand-off was
accepted, the Lifetime field is set to the number of
seconds remaining before the entry is considered expired.
A value of zero indicates that the local foreign agent
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.
Home Address
The IP address of the mobile node.
Home Agent
The IP address of the mobile node's home agent.
Identification
A 64-bit number used for matching Hand-Off Requests with
Hand-off Replies, and for protecting against replay
attacks of Hand-Off messages. The value is based on the
Identification field from the Hand-Off Request message
from the mobile node, and on the style of replay
protection used in the security context between the
mobile node and its home agent (defined by the mobility
security association between them, and SPI value in the
Mobile-Home Authentication Extension). See [1] for more
information.
Calhoun, Kempf expires December 2000 [Page 9]
INTERNET DRAFT June 2000
Extensions
The fixed portion of the Hand-Off Reply is followed by
one or more of the Extensions. The Generalized FA-FA
Authentication Extesion [6] SHOULD be present in all
Hand-Off Replies returned by the GFA or AFA.
5.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 2.1
6.0 IANA Considerations
This specification introduces two new values in the Mobile IP type
field. This value MUST NOT conflict with values specified in [1], or
any other Mobile IP extension document.
7.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
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.
8.0 References
Calhoun, Kempf expires December 2000 [Page 10]
INTERNET DRAFT June 2000
[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). Feburary
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.
9.0 Acknowledgements
The authors would like to thank Charles Perkins for his valuable
feedback.
10.0 Authors' Addresses
Questions about this memo can be directed to:
Calhoun, Kempf expires December 2000 [Page 11]
INTERNET DRAFT June 2000
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
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
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
11.0 Full Copyright Statement
Copyright (C) The Internet Society (1999). 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
Calhoun, Kempf expires December 2000 [Page 12]
INTERNET DRAFT June 2000
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
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, Kempf expires December 2000 [Page 13]