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