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