Informational James Kempf,
Editor
Internet Draft Daichi Funato
Document: draft-manyfolks-l2-mobilereq-01.txt Karim El Malki
Expires: May 2002 Youngjune Gwon
November 2001 Mattias Pettersson
Phil Roberts
Hesham Soliman
Atsushi Takeshita
Alper E. Yegin
Supporting Optimized Handover for IP Mobility - Requirements for
Underlying Systems
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. This is an individual
draft for consideration by the PILC Working Group.
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.
Abstract
A critical factor in achieving good performance for IP mobility
protocols is the design of L2 handover. Handover occurs when a
Mobile Node moves from one radio Access Point to another. If the new
radio Access Point is associated with a new subnet, a change in
routing reachability may occur and require L3 protocol action on the
part of the Mobile Node or Access Routers. If no change in subnet
occurs, the Access Point may still need to take some action to
inform the Access Router about a change in on-link reachability. In
either case, prompt and timely information from L2 to the parties
involved about the sequencing of handover can help optimize handover
at the IP level. This draft discusses requirements for an L2
handover protocol or API to support optimized handover.
Kempf, et. al. Informational - Expires April 2002
[Page 2] Optimized IP Mobility Support November 2001
Table of Contents
1.0 Introduction.................................................2
2.0 Terminology..................................................3
3.0 L2 Trigger Definition........................................3
3.1. What is an L2 Trigger?....................................3
3.2. Information in an L2 Trigger..............................4
4.0 Requirements for L2 Triggers.................................5
4.1. L2 Handovers..............................................5
4.2. L3 Handovers..............................................5
4.3. Context Transfers.........................................6
5.0 L2 Triggers..................................................6
6.0 Benefits of L2 Triggers for Other Systems....................7
7.0 Security Considerations......................................8
8.0 References...................................................8
9.0 Author's Addresses...........................................9
1.0 Introduction
An important consideration in the design of IP mobility protocols is
handover. A moving Mobile Node (MN) may irregularly need to change
the terrestrial radio Access Point (AP) with which it is
communicating. The change in L2 connectivity to a new AP may cause a
change in IP routing reachability, and thus require either the MN or
the Access Routers (ARs) to perform actions that update routing
information for the MN. Even if no change in subnet occurs, the APs
may still need to communicate the change in on-link reachability to
the local AR. In order for handover to occur, candidate APs must be
identified and a target AP must be selected [10]. Once this process
has been complete, the handover process can begin.
Several protocol designs have been advanced for Mobile IP that seek
to reduce the amount of handover latency at L3 [3] [4] [5]. These
protocols depend on obtaining timely information from the L2
protocol about the progress of handover. An additional beneficiary
of timely handover progress information is context transfer [6].
Context transfer involves moving context information (QoS, header
compression, authentication, etc.) from the old AR to the new. By
moving such context information, the ARs can avoid requiring the MN
to set up all the context information from scratch, considerably
reducing the amount of time necessary to set up basic network
service on the new subnet. If handover progress information is
available from L2, context transfer can proceed more quickly.
This document discusses requirements on underlying systems for
supporting optimized IP mobility, in particular, handover. While the
document has been written with existing Mobile IP work in mind, it
should be applicable to any protocol that can benefit from knowledge
Kempf, et. al. Informational - Expires May 2002
[Page 3] Optimized IP Mobility Support November 2001
about handover sequencing to facilitate mobility. Requirements for
assisting in handover between two APs on the same subnet, between
two ARs on different subnets, and for context transfer between ARs
are discussed.
2.0 Terminology
The following terms are used in this document.
Access Point (AP)
A Layer 2 (L2) access entity, e.g. a radio transceiver
station, that is connected to one or more Access Routers. Its
primary function is to provide MNs an L2 wireless link via its
specific air-interface technology.
Access Router (AR)
A Layer 3 (L3) IP router, residing in an access network and
connected to one or more Access Points. An AR is the first hop
router for a MN.
L2 Handover
Change of MN's link layer connection from one AP to another.
No change in off-subnet routing reachability information is
required if both APs are part of the same subnet.
L3 Handover
Change of MN's routable address from one AR to another. An L3
handover results in a change in the MN's routing reachability,
that will require action on the part of the IP mobility
protocol running in the MN and/or ARs.
3.0 L2 Trigger Definition
This section discusses defining L2 triggers that provide information
on the sequencing of handover. An L2 trigger is not associated with
any specific L2 but rather is based on the kind of L2 information
that is or could be available from a wide variety of radio link
protocols.
3.1. What is an L2 Trigger?
An L2 trigger is an abstraction of a notification from L2
(potentially including parameter information) that a certain event
has happened or is about to happen. The trigger may be implemented
in a variety of ways. Some examples are:
Kempf, et. al. Informational - Expires May 2002
[Page 4] Optimized IP Mobility Support November 2001
- The L2 driver may allow the IP stack to register a callback
function that is called when the trigger fires. The parameters
associated with the trigger are delivered to the callback.
- The operating system may allow a thread to call into a system
call for the appropriate trigger or triggers. The system call
blocks until a particular trigger has fired, then it returns
with parameter information available in some way (return value
of the system call, file descriptor, etc.).
- The trigger may consist of a protocol for transferring the
trigger notification and parameter information at either L2 or
L3 between the new AP or AR and the old AP or AR. The parameter
information is included as part of the protocol. This allows
the IP stack on a separate machine to react to the trigger. The
IAPP protocol [7] is an example of such a protocol.
- The trigger information may be available within the operating
system kernel to the IP stack from the driver as an out of band
communication.
In any case, the implementation details of how the information
involved in an L2 trigger are transferred to the IP mobility
protocol are likely to color how the mobility protocol is
implemented on top of that L2, but they should not influence the
specification of the abstract L2 triggers themselves.
3.2. Information in an L2 Trigger
There are three types of information involved in defining an L2
trigger:
1. The event that causes the L2 trigger to fire,
2. The IP entity that receives the trigger,
3. The parameters delivered with the trigger.
The IP entities that can receive the trigger depend on the
particular IP mobility protocol in use. Here are some possible IP
entities, based on work done with L2 triggers and Mobile IP:
MN The MN may receive an L2 trigger allowing it to start
or conclude a mobile controlled handover.
FA In Mobile IPv4, the Foreign Agent (FA) is located on
the last hop before the wireless link. The last hop
can be either an AP or AR or even a separate host.
An FA can make use of triggers to start or conclude
network controlled handover.
AR The AR can obtain an L2 trigger directly from the
Kempf, et. al. Informational - Expires May 2002
[Page 5] Optimized IP Mobility Support November 2001
wireless link if one of its interfaces is on the
link (that is, the AR is also an AP), or it can obtain
an L2 trigger indirectly by L2 or L3 protocol messages
from the AP.
4.0 Requirements for L2 Triggers
L2 handover, L3 handover, and context transfer events and related
protocols would benefit from a collection of L2 triggers. Some of
these protocols directly rely on the existence of certain triggers,
and perform better when others are available. As such, L2 triggers
should be designed to meet these protocolsÆ needs.
4.1. L2 Handovers
On the face of it, specifying requirements for pure L2 handover
(i.e. no change in IP routing reachability) might seem out of scope
for IETF. Existing wireless networks typically have special L2 AP-AR
interfaces with L2 address update built in. For these systems, L2
triggers are unnecessary.
However, current trends in wireless networking suggest that future
wireless networks will consist of a variety of heterogeneous
wireless APs bridged into the wired network, potentially on the same
subnet. A change in wireless AP, either between an AP supporting one
wireless link technology and an AP supporting another, or between
two APs supporting the same wireless technology, necessarily results
in a change in the on-subnet reachability. Packet delivery within
the subnet can be optimized if this information can be propagated to
the AR, so it can update its on-subnet L2 address to IP address
mapping.
In addition, the old AP may benefit from a notification that the MN
has moved in the event it is not involved in the handover (as is the
case with some WLAN radio protocols), by allowing the old AP to more
quickly de-allocate resources dedicated to the moved MN. Some radio
link protocols already define IP-based L2 trigger protocols for this
purpose [7]. When APs supporting multiple radio technologies on a
single subnet are involved, however, interoperability suffers if
there is no L2-independent way of reporting on-link movement.
4.2. L3 Handovers
Low latency handover protocol designs for Mobile IPv4 and Mobile
IPv6 [3] [4] [5] rely on the existence of certain L2 triggers.
Either the MN or the AP/AR needs to receive an indication that the
handoff is imminent for these L3 mobility protocols to work. This
trigger must be received by the MN for mobile-controlled handovers,
and received by the AP/AR for network-controlled handovers. Timely
receipt of this trigger is needed as protocol signaling needs to
take place in parallel with the handoff. Protocol signaling over the
current link should be completed prior to loss of connectivity.
Kempf, et. al. Informational - Expires May 2002
[Page 6] Optimized IP Mobility Support November 2001
Additional triggers that indicate the link tear down and
establishment can be used to indicate departure and arrival of a MN
at AP/ARs. Such indications can replace L3 signal exchange and
therefore expedite the process. An L2 that supports a collection of
such triggers is a good candidate for a high performance Mobile IP
implementation.
4.3. Context Transfers
Context transfer (CT) is a relatively new issue for supporting
seamless mobility between two ARs or FAs that provide access to a
mobile node. Although lacking a "de facto" CT protocol specification
at this time, plausible approaches toward a CT framework are well
described in [8] [9]. Conceptually, CT can take place before,
during, or after handover. Exactly when and how CT takes place is
highly dependent on the type of context being transferred.
L2 triggers are used to initiate the context transfer operation.
Early notification of handovers is essential to having sufficient
time to complete the required protocol signaling. Also link
establishment trigger can be used for activating the state related
to a context.
5.0 L2 Triggers
Based on the L2 handover, L3 handover, and context transfer
protocolsÆ needs, underlying systems are required to implement basic
L2 triggers as outlined in Table 1.
The description for a trigger contains the trigger name, the L2
handover event causing the trigger to fire, what entities receive
the trigger, and parameters, if any. The recipient is qualified by
the IP mobility protocol in which the recipient plays a role. If the
recipient does not have AP functionality (i.e., the recipient does
not have an interface directly on the wireless link), the trigger
information must be conveyed from the AP where it occurs to the
recipient by an L2 or L3 protocol.
Kempf, et. al. Informational - Expires May 2002
[Page 7] Optimized IP Mobility Support November 2001
L2 Event Recipient Parameters
Trigger
+---------+---------------------+--------------+------------------+
|Link Up | When the L2 link | AP/AR/FA | MN L2 address |
| | comes up. | | to AP/AR/FA |
| | | | |
| | | MN | AP/AR/FA L2 |
| | | | address to MN |
+---------+---------------------+--------------+------------------+
| Link | When the L2 link | AP/AR/FA | MN L2 address |
| Down | goes down. | | to AP/AR/FA |
| | | | |
| | | MN | AP/AR/FA L2 |
| | | | address to MN |
| | | | |
| | | | Boolean cause |
| | | | (inadvertent/ |
| | | | deliberate) |
+---------+---------------------+--------------+------------------+
|Source | Sufficiently before | oAP/oAR/oFA | nAP/nAR/nFA L2 |
|Trigger | L2 handover start | | address that can |
| | for pre-handover L3 | | be mapped to an |
| | message exchange | | IP address |
| | across the wired | | |
| | and/or wireless link| | MN L2 address |
+---------+---------------------+--------------+------------------+
|Target | Sufficiently before | nAP/nAR/nFA | oAP/oAR/oFA L2 |
|Trigger | L2 handover finish | | address that can |
| | for pre-handover L3 | | be mapped to an |
| | message exchange | | IP address |
| | across the wired | | |
| | and/or wireless | | MN L2 address |
| | link. | | |
+---------+---------------------+--------------+------------------+
|Mobile | Sufficiently before | MN | nAP/nAR/nFA L2 |
|Trigger | L2 handover start | | address that can |
| | for pre-handover L3 | | be mapped to an |
| | message exchange | | IP address |
| | across the wired | | |
| | and/or wireless link| | |
+---------+---------------------+--------------+------------------+
Table 1. L2 trigger requirements
When a source trigger or target trigger is not followed by a link up
or down trigger, this sequence of events can be interpreted as an
indication of a failed handover.
6.0 Benefits of L2 Triggers for Other Systems
While the primary purpose of L2 triggers described in this draft is
to aid L2 mobility optimization, L2 triggers can also benefit
networks without Mobile IP or other IP mobility protocol support.
Kempf, et. al. Informational - Expires May 2002
[Page 8] Optimized IP Mobility Support November 2001
For example, IP addresses may change due to stateless or stateful
address configuration whenever hosts are unplugged from the network
or re-plugged into a different subnet.
Use of L2 triggers in such situations enables efficient state
management in the AR. The AR can clean up the associated state as
soon as it detects that a host has been disconnected through the L2
Link Down trigger, for example. State clean up includes removal of
ARP or Neighbor Cache entries, and can save bandwidth by inhibiting
incoming data on the link where the host was once connected.
Additionally, faster and more efficient router discovery is possible
if the AR receives a L2 Link Up trigger for a host. When the AR
receives the trigger, it can send an unsolicited unicast router
advertisement to the host. The host can begin the process of
establishing IP connectivity more quickly.
7.0 Security Considerations
The L2 triggers convey information about the link state of the MN
and this information can trigger IP layer changes in routing
reachability. As such, the information in an L2 trigger, if misused
by an adversary or fraudulently propagated, could result in denial
of IP service to the MN or hijacking of the MN's packets to a
hostile third party.
If the L2 trigger is implemented as an API on an AR or AP, then the
operating system and API implementation are required to assure that
only qualified users can call into the API. Normally this involves
denying access through the API unless the process running the API
client has the proper security credentials on the host. If the L2
trigger is implemented as an L2 or L3 protocol, the protocol is
required to protect the trigger messages with the proper
authentication. In particular, if the protocol is an IP-based
protocol, it must include authenticators so the parties that use the
protocol can authenticate each other. If the protocol is intended to
be used on public data networks, the option of encrypting the
traffic must be available, to grant some privacy over the MN
movement information propagated by the protocol messages.
8.0 References
1 Perkins, C., ed., "IP Mobility Support," RFC 2002, October, 1996.
2 Johnson, D., and Perkins, C., "Mobility Support in IPv6,"
draft-ietf-mobileip-ipv6-13.txt, a work in progress.
3 El-Malki, K., et. al., "Low Latency Handoff in Mobile IPv4,"
draft-ietf-mobileip-lowlatencyhandoffs-v4-01.txt, a work in
progress.
Kempf, et. al. Informational - Expires May 2002
[Page 9] Optimized IP Mobility Support November 2001
4 Tsirtsis, G., et. al. "Fast Handovers for Mobile IPv6,"
draft-ietf-mobileip-fast-mipv6-01.txt, a work in progress.
5 Kempf, et. al., "Bidirectional Edge Tunnel Handover for IPv6,"
draft-kempf-beth-ipv6-01.txt, a work in progress.
6 Levkowetz, O.H., et. al., "Problem Description: Reasons for
Performing Context Transfers Between Nodes in an IP Access
Network,"
draft-ietf-seamoby-context-transfer-problem-stat-01.txt,
a work in progress.
7 "Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across
Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std
802.11f/D1, DRAFT.
8 Sayed, H., et. al., "Context Transfer Framework,"
draft-hamid-seamoby-ct-fwk-00.txt, a work in progress
9 Sayed, H., et. al., "General Requirements for a Context Transfer
Framework," draft-hamid-seamoby-ct-reqs-01.txt, a work in
progress
10 Trossen, D., et. al., "Issues in Candidate Access Router
Discovery for Seamless IP Handoffs,"
draft-ietf-seamoby-CARdiscovery-issues-00.txt, a work in
progress.
9.0 Author's Addresses
James Kempf, Editor
DoCoMo USA Labs
181 Metro Drive, Suite 300 Phone: +1 408 451 4711
San Jose, CA 95110 Fax: +1 408 573 1090
USA Email: james@docomolabs-usa.com
Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vag. 8 Phone: +46 8 7195803
126 25 Stockholm Fax: +46 8 7190170
SWEDEN Email: Karim.El-Malki@era.ericsson.se
Daichi Funato
DoCoMo USA Labs
181 Metro Drive, Suite 300 Phone: +1 408 451 4736
San Jose, CA 95110 Fax: +1 408 573 1090
USA Email: funato@docomolabs-usa.com
Kempf, et. al. Informational - Expires May 2002
[Page 10] Optimized IP Mobility Support November 2001
Youngjune Gwon
DoCoMo USA Labs
181 Metro Drive, Suite 300 Phone: +1 408 451 4734
San Jose, CA 95110 Fax: +1 408 573 1090
USA Email: gyj@docomolabs-usa.com
Mattias Pettersson
Ericsson Radio Systems AB Phone: +46 8 585 32 562
Torshamnsgatan 23 Fax: +46 8 404 70 20
SE-164 80 Stockholm E-mail: Mattias.Pettersson@era.ericsson.se
SWEDEN
Phil Roberts
Megisto Systems
20251 Century Blvd, Suite 120 Email: proberts@megisto.com
Germantown, MD 20874-1191
USA
Hesham Soliman
Ericsson Radio Systems
Torshamnsgatan 29, Kista Phone: +46 8 7578162
Stockholm Fax: +46 8 4043630
SWEDEN Email: Hesham.Soliman@era.ericsson.se
Atsushi Takeshita
DoCoMo USA Labs
181 Metro Drive, Suite 300 Phone: +1 408 451 4705
San Jose, CA 95110 Fax: +1 408 573 1090
USA Email: takeshita@docomolabs-usa.com
Alper E. Yegin
DoCoMo USA Labs
181 Metro Drive, Suite 300 Phone: +1 408 451 4743
San Jose, CA 95110 Fax: +1 408 573 1090
USA Email: alper@docomolabs-usa.com
Kempf, et. al. Informational - Expires May 2002