Informational James Kempf,
Editor
Internet Draft Daichi Funato
Document: draft-manyfolks-l2-mobilereq-00.txt Karim El Malki
Expires: December 2001 Youngjune Gwon
July 2001 Mattias Pettersson
Phil Roberts
Hesham Soliman
Atsushi Takeshita
Alper Yegin
Requirements for Layer 2 Protocols to Support Optimized Handover for
IP Mobility
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 Mobile IP 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
2 L2 Mobility Handover Optimization Requirements July 2001
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.
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 L2 Handover Requirements for L2 Triggers ......................5
5.0 L3 Handover Requirements for L2 Triggers ......................7
6.0 Context Transfer Requirements for L2 Triggers .................8
6.1. Types of Context Transfer .................................9
6.2. Requirements for L2 Triggers for Context Transfer .........9
7.0 Benefits of L2 Triggers for Other Systems ....................11
8.0 Security Considerations ......................................11
9.0 References ...................................................11
10.0 Author's Addresses .........................................12
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.
3 L2 Mobility Handover Optimization Requirements July 2001
This document discusses requirements for an L2 handover protocol or
API to support optimized L3 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 about L2
events 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.
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 abstracted from 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
4 L2 Mobility Handover Optimization Requirements July 2001
has happened or is about to happen. The trigger may be implemented
in a variety of ways. Some examples are:
- The L2 driver may allow the IP stack to register a callback
that is called when the trigger fires. The parameters
associated with the trigger are delivered to the callback.
- The operating system may allow an application layer thread to
call into a system call for the appropriate trigger or
triggers. The system call returns when a particular trigger has
fired, with parameter information as a return value of the
system call.
- 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.
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
wireless link if one of its interfaces is on the
5 L2 Mobility Handover Optimization Requirements July 2001
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 L2 Handover Requirements for L2 Triggers
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. Table
1 contains a list of L2 handover requirements for L2 triggers.
6 L2 Mobility Handover Optimization Requirements July 2001
L2 Trigger Event Recipient Parameters
---------- ----- --------- ----------
Intra-L2 Before handover Current AR MN's new
Handover Start between two APs downlink L2
supporting the MN address
same radio link
technology. New AP's uplink
L2 address
Inter-L2 Before handover Current AR MN's new
Handover Start between two APs downlink L2
supporting MN address (radio
different radio (optional, only link technology
link supplied if MN specific)
technologies. does not obtain
otherwise) MN's old
downlink L2
address (radio
link technology
specific)
New AP's uplink
L2 address
(radio
technology
specific)
Inter-L2 Old When the old L2 Current AR MN's new
Link Down link is downlink L2
disappearing and MN address (radio
before disabling link technology
the old L2 link. specific)
MN's old
downlink L2
address (radio
link technology
specific)
New AP's uplink
L2 address
(radio
technology
specific)
Table 1 - L2 Handover Requirements
7 L2 Mobility Handover Optimization Requirements July 2001
5.0 L3 Handover Requirements for L2 Triggers
The requirements discussed in this section have proven highly useful
as a device in structuring low latency handover protocol designs for
Mobile IPv4 and Mobile IPv6 [3] [4] [5]. An L2 that supports these
requirements is a good candidate for a performance Mobile IP
implementation. Table 2 contains the requirements for the L2
triggers. 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.
8 L2 Mobility Handover Optimization Requirements July 2001
L2 Event Recipient Parameters
Trigger
-------- ------ --------- ----------
Link Up When the L2 link comes AP/AR MN L2 address to AP/AP
up.
MN AP/AR address to MN
Link When the L2 link goes AP/AR MN L2 address to AP/AR
Down down.
MN AP/AR address to MN
Boolean cause
(inadvertent/deliberate)
Source Sufficiently before L2 MIPv6: nAR or nFA IP address
Trigger handover start for oAR or L2 address that can
pre-handover L3 be mapped to an IP
message exchange MIPv4: address
across the wired oFA
and/or wireless link MN L2 address
Target Sufficiently before L2 MIPv6: oAR or oFA IP address
Trigger handover finish for nAR or L2 address that can
pre-handover L3 be mapped to an IP
message exchange MIPv4: address
across the wired nFA
and/or wireless link. MN L2 address
L2 When L2 handover MIPv6: MN L2 address to oAR/nAR
Handover begins oAR or
Start nAR
MIPv4: MN L2 address to oFA/nFA
oFA or
nFA
MN MIPv6:oAR/nAR address or
MIPv4 oFA/nFA address to
MN
Table 2 - L3 Handover Requirements
6.0 Context Transfer Requirements for L2 Triggers
Context transfer (CT) is a relatively new issue for supporting
seamless mobility between two nodes that provide access to a mobile
node. Although lacking a "de facto" CT protocol specification at
this time, plausible approaches toward CT framework are well
9 L2 Mobility Handover Optimization Requirements July 2001
described in [8] [9]. Conceptually, the CT framework suggests two
distinctive modes of operation, namely, reactive and proactive. In
this section, specific modifications to L2 triggers that suffice
both the reactive and the proactive context transfers are discussed.
6.1. Types of Context Transfer
Reactive CT takes place subsequent to a MN establishing a new link
with the new AR. Thus, the context information required should be
transferred to the new access router after the MN completes the new
link with the new access router. Although this timing requirement is
loosely defined, it is desirable to initiate reactive CT sometime
before (or about the same time as) the L2 handoff initiation. It is
also noteworthy that the old access router is not always restricted
to being the context source, i.e. where the context is transferred
*from*.
Proactive CT requires that the context is present at the new AR
prior to the arrival of MN's packets at the new AR. The timing
requirement for proactive CT is stricter because it may be possible
that some of the context is still in transit when packets begin to
arrive for the MN at the new access router.
6.2. Requirements for L2 Triggers for Context Transfer
Similarly as FMIP L2 triggers (as defined in Section 4.0), L2
triggers for context transfer operating on either reactive or
proactive mode are defined in Table 3.
10 L2 Mobility Handover Optimization Requirements July 2001
L2 Trigger Event Recipient Parameters
---------- ----- --------- ----------
Proactive CT L2 Sufficiently before nAR oAR or Context
Target Trigger L2 handover Transfer Source
initiation that CT (CTS) L2/L3
can be completed address
before route/tunnel identifiers.
for packets to MN
on new AR is set MN identifier
up.
Proactive CT L2 Sufficiently before oAR nAR or Context
Source Trigger L2 handover Transfer Target
initiation that CT (CTT) L2/L3
can be completed address
before route/tunnel identifiers.
for packets to MN
on new AR is set MN identifier
up.
Proactive CT L2 Sufficiently before MN nAR or Context
Mobile Trigger L2 handover Transfer Target
initiation that CT (CTT) L2/L3
can be completed address
before route/tunnel identifiers.
for packets to MN
on new AR is set
up.
Reactive CT L2 Upon completion of nAR oAR or Context
Target Trigger the L2 handover. Transfer Source
(CTS) L2/L3
address
identifiers.
Reactive CT L2 Upon initiation of oAR nAR or Context
Source Trigger L2 handover. Transfer Source
(CTS) L2/L3
address
identifiers.
Reactive CT L2 Upon the initiation MN nAR or Context
Mobile Trigger of L2 handover. Transfer Target
(CTT) L2/L3
address
identifiers
Table 3 - Context Transfer Requirements
11 L2 Mobility Handover Optimization Requirements July 2001
7.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.
For example, IP addresses may change due to stateless or stateful
address configuration whenever hosts are unplugged from the network
or replugged into a different subnet.
Use of L2 triggers in such situations enables efficient state
managment 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.
8.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.
9.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.
12 L2 Mobility Handover Optimization Requirements July 2001
3 El-Malki, K., et. al., "Low Latency Handoff in Mobile IPv4,"
draft-ietf-mobileip-lowlatencyhandoffs-v4-01.txt, a work in
progress.
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-00.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.
10.0 Author's Addresses
James Kempf, Editor
Sun Microsystems Phone: +1 650 336 1684
901 San Antonio Rd, UMTV29-235 Fax: +1 650 691 0893
Palo Alto, CA Email: james.kempf@sun.com
94303
USA
Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vag. 8 Phone: +46 8 7195803
13 L2 Mobility Handover Optimization Requirements July 2001
126 25 Stockholm Fax: +46 8 7190170
SWEDEN Email: Karim.El-Malki@era.ericsson.se
Daichi Funato
NTT DoCoMo, Inc.
3-5, Hikarinooka, Yokosuka-shi Phone: +81 468 40 3025
Kanagawa, 239-8536 Fax: +81 468 40 3726
JAPAN Email: funato@nttdocomo.co.jp
Youngjune Gwon
Mobile Internet Laboratory
DoCoMo Communications
Laboratories USA, Inc.
181 Metro Drive, Suite 300 Phone: +1 408 451 4734
San Jose, CA 95110 Fax: +1 408 573 1090
USA Email: gyj@dcl.docomo-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 Email: proberts@megisto.com
Suite 120
Germantown, MD 20874-1191
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 Communications
Laboratories USA, Inc.
181 Metro Drive, Suite 300 Phone: +1 408 451 4705
San Jose, CA 95110 Fax: +1 408 573 1090
USA Email: takeshita@dcl.docomo-usa.com
Alper Yegin
Sun Microsystems Phone: +1 650 786 4013
901 San Antonio Rd, UMPK17-202 Email: alper.yegin@sun.com
Palo Alto, CA
94303
USA