draft-satish-l2-mobilereq-00.txt Informational Satish Jamadagni Shiva Raman Pandey Satish D Sasken Communication Technologies Ltd Internet Draft Document: draft-satish-l2-mobilereq-00.txt February 2002 Optimized 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 seamoby 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 IP mobility protocols have traditionally been designed to be independent of any L2 considerations. 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. Better synchronization between L2 handover and L3 handover becomes still more important when supporting fast handoff between two wireless domains. 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 API support to optimize layer 3 handover. Satish et Al [Page 1] Internet Draft Optimized IP Mobility... Feb 2002 Table of Contents 1.0 Introduction 2.0 Terminology 3.0 L2 Trigger Definition 3.1. Decomposition of the L2 handoff process for identifying L2 triggers 3.1.1. L2 handoff Initiation stage 3.1.2. L2 handoff decision stage 3.1.3. L2 handoff execution stage 3.2. Information in an L2 trigger 4.0 Requirements for L2 Triggers 4.1. L2 triggers for conventional L3 Handover 4.2. L2 triggers for fast L3 Handover 4.3. L2 triggers for Context Transfers 4.4. L2 triggers for Candidate Access Router discovery 5.0 L2 Triggers 6.0 Using L2 Triggers in combination with other triggers 7.0 References 8.0 Author's Addresses 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 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 this requires 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. For a handover to occur, candidate APs must be identified and a target AP must be selected [10]. Once the initial identification and decision are 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 timely information from the L2 protocol about the progress of handover. L2 handover progress information also affects context transfer [6] and candidate access router discovery [10]. 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 Satish et Al [Page 2] Internet Draft Optimized IP Mobility... Feb 2002 should be applicable to any protocol that can benefit from knowledge about L2 handover sequencing to facilitate mobility. L2 requirements for assisting in handover between two APs on the same subnet, between two ARs on different subnets, for context transfer and candidate access router discovery are discussed. 2.0 Terminology The following terms are used in this document [11]. 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. 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. L2 triggers are defined based on a generic decomposition of the L2 handover process. An L2 trigger is 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 provided in [11]. Apart from what is mentioned in [11] An L2 trigger can also be information may be available as an out of band communication signal. 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. Satish et Al [Page 3] Internet Draft Optimized IP Mobility... Feb 2002 3.1 Decomposition of the L2 handoff process for identifying L2 triggers This section deals with identifying the L2 handoff process steps to better understand the L2 triggers that can facilitate better L3 handover. It is assumed that triggers emanating from such decomposition may not be mandatory. Three steps are identified in the L2 handoff process and appropriate triggers will be identified to better serve L3 handoff. The steps identified are 1.The handoff initiation stage, 2.The handoff decision stage and 3.The handoff execution stage. Such decomposition allows the L2 to specify triggers that go beyond the "Link Up" and "Link down" L2 notifications. The identification of Intermediate states in L2 handoff provides for notifications, which span the time between a handoff initiation and an actual L2 handoff. Further it is assumed that the L2 handoff is of a "make before break nature" to allow for service continuity. 3.1.1 L2 handoff Initiation stage The Initiation phase identifies the need for handover and subsequently initiates it. L2 handover initiation triggers can originate from an MN or the AP. The MN L2 initiation may be due to a degradation of perceived QoS. The AP initiation may be to serve any time dependent load factors. The reasons for a handover initiation can be any of the following Availability, Congestion, Effective S/R, Emergency service, Interference, Loading, Macro/Micro/Pico - Operator policy like handover slow moving users to pico and fast moving users to larger cells, Security levels, Network forced maintained, QoS -(BW (bits/s), delay, delay variation, Error rate etc, Service provider influence etc. L2 handoff initiation triggers can be used by L3 for fast handoff initiation. L3 fast handoff initiation may include identification of CAR for handoff. Here L2 handoff initiation trigger is a notification to L3 sent at the start of the L2 handoff initiation. This trigger can be indicative of the L2 handoff threshold crossing. Further initiation start and initiation complete triggers can be specified to accommodate for spurious signal levels. 3.1.2 L2 handoff decision stage The L2 handover decision phase compares information from a variety of sources with recorded user preferences and network policy. It also involves identifying the best available handover taking into consideration user preference and network policy. It then notifies the handoff execution module for an L2 handoff execution. L2 decision stage trigger can be used to achieve a better conventional MIP handoff. Satish et Al [Page 4] Internet Draft Optimized IP Mobility... Feb 2002 3.1.3 L2 handoff Execution stage The objective of the handover execution phase is to change code, technology or network conforming to the details resolved to in the decision phase. This stage typically involves connection changes or radio access node change. Further it also involves control point transfer signaling and security related signaling. The L2 handoff execution trigger can be used to achieve optimized conventional L3 handoff. It can also act as a pre-registration abort signal and fall back on the post registration in case of combined fast handoff method. 3.2. Information in an L2 Trigger There are three types of information involved in defining an L2 trigger: 1. The trigger type and sub type information Ex: Initiation trigger Subtype: Cause 2. The parameters delivered with the trigger. 3. The IP entity that receives the L2 trigger, The L3 handoff initiation module The L3 handoff decision module The L3 execution module The IP entities that can receive the trigger depend on the particular IP mobility protocol in use. Assumption of the decomposition as mentioned above is still valid for any given IP mobility protocol. 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 protocol needs. The need for L2 triggers has been highlighted in [11]. Current trends in wireless networking suggest that future wireless networks will consist of a variety of heterogeneous wireless APs connected into the wired network, may be on the same subnet or may not be 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. Also there is a general perception that interoperability suffers if there is no L2-independent way of reporting on-link movement. Handoffs Satish et Al [Page 5] Internet Draft Optimized IP Mobility... Feb 2002 in most L2s can be decomposed into a sequence of steps as has been highlighted in the previous section. Such a generic decomposition helps in consolidating a set of triggers from an underlying L2 to support better L3 handoff even under diverse L2 considerations. L3 handoff may or may not depend completely on the underlying L2 triggers. L3 handover may depend on a combination of L2 triggers and triggers from other entities. It is to be understood that the availability of additional L2 triggers will only facilitate better L3 handover. 4.1. L2 triggers for conventional L3 Handover L2 triggers like the "link tear down" and "link 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. The L2 handoff execution trigger can be used to achieve optimized conventional L3 handoff. 4.2. L2 triggers for fast L3 handover support 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. L2 handoff initiation triggers can be used by L3 for fast handoff initiation. L3 fast handoff initiation may include CAR discovery for handoff. L2 decision stage trigger can ease the L3 decision process i.e. the target access router can be indicated in the L2 decision stage trigger. It can also be used to achieve a better conventional MIP handoff. The L2 handoff execution trigger can be used to achieve optimized conventional L3 handoff. It can also act as a pre-registration abort signal to fall back on the post registration in case of combined fast handoff method. 4.3. L2 Triggers For Context Transfer Context transfer (CT) is an evolving topic aimed at supporting seamless mobility between two ARs or FAs that provide access to a mobile node. 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. Satish et Al [Page 6] Internet Draft Optimized IP Mobility... Feb 2002 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. L2 handoff execution trigger can be used to achieve better L3 handover with sufficient time for CT, which in the conventional case can become an overhead on the L3 handover time. 4.4. L2 Triggers and Candidate access router discovery Candidate access router discovery is an important issue for fast handoff initiation [10]. L2 triggers are used to initiate the Candidate access router discovery. An L2 decision handoff notification with the decision information (which carries the domain address to which the handover has to occur) can allow L3 handover to proceed with out the CAR discovery process. An L2 initiation trigger can be used as an initiation for CAR discovery operation. 5.0 The L2 Triggers L2 triggers are defined in table 1 based on the L2 handover decomposition, which the underlying systems are required to implement. 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. Satish et Al [Page 7] Internet Draft Optimized IP Mobility... Feb 2002 L2 trigger | Event | Recipient | Parameters -----------|----------------------|---------------|----------------- Link Up | When the L2 link | AP/AR/FA, | AP/AR/FA L2 address | comes up | MN | to MN | | | MN L2 address to | Handoff execution | | AP/AR/FA | complete | | ---------------------------------------------------------------------- Link Down | When the L2 link | AP/AR/FA, MN | MN L2 address to | goes down | | AP/AR/FA | | | | | | AP/AR/FA L2 | | | Address to MN | | | Boolean cause | | (inadvertent/ | | deliberate) ---------------------------------------------------------------------- L2 handoff | Indicates L2 | | Handoff Initiation initiation | handoff | | cause | QoS threshold | AP/AR/FA, MN | Ex: QoS degradation | | | at the MN L2 in | | | case of | crossing | | Mobile trigger | | | | | | Ex: L2 load | | | conditions | | | in the case | | | of Source | | | trigger ---------------------------------------------------------------------- L2 handoff | | | decision | Indicates the | AP/AR/FA, MN | MN L2 address to | decision | | AP/AR/FA | to handoff to a | |AP/AR/FA L2 address | particular | | to MN | AP/AR/FA | | ---------------------------------------------------------------------- L2 handoff | Indicates the | AP/AR/FA, MN | Reconfirm execution | beginning of a | | MN L2 address to | handoff execution | | AP/AR/FA | process | | AP/AR/FA L2 address | | | to MN | | | Approximate L2 | | |execution signals or | | | signaling time | | | information ----------------------------------------------------------------------- The Source trigger, the target trigger and the Mobile trigger as specified in [11] can be indicated according to the L2 handoff decomposition provided above. This only provides implementation flexibility for a host of handoff causes as listed in the handoff initiation section above. Satish et Al [Page 8] Internet Draft Optimized IP Mobility... Feb 2002 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. The time interval between the initiation (for the cases of MN, Source and target trigger) and the final execution can be used for meaningful CAR discovery, CT and fast handoff completion. 6.0 Using L2 Triggers in combination with other triggers In future wireless networks L2 handoff causes can be very many. In such a scenario it is always advantageous to provide as elaborate an L2 trigger as possible. For example the time interval between an L2 initiation trigger to the decision trigger is large such a time can be used by the MN for example to do a CAR discovery for itself. While the L2 triggers as described in [11] seems aimed at being used as the primary triggers to achieve fast handoff, it is visualized that the L2 triggers will be used in combination with a host of other triggers example from L3 location triggers [12] to application level triggers. As such it is asserted in this draft that the L2 triggers will have to be as comprehensive as possible with as much possible generic decomposition as can be possible. 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. 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 Satish et Al [Page 9] Internet Draft Optimized IP Mobility... Feb 2002 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. 11 James Kempf, et. al., "Supporting Optimized handover for IP mobility Requirements for underlying systems, "draft-manyfolks-l2-mobilereq-01.txt, a work in progress. 12 M. Ylianttila, et. al., "Considerations on IP Spatial Location Protocol Requirements, " draft-ylianttila-isl-prot-req-00.txt",a work in progress. 9.0 Author's Addresses Satish Jamadagni, Sasken Communication Technologies Ltd #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone:+91 80 5355501 Ext:3029 Fax: +91 80 5351133 Email: satishj@sasken.com Shiva Raman Pandey, Sasken Communication Technologies Ltd #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone:+91 80 535 5501 Ext 3296 Fax: +91 80 535 1133: Email: shiva@sasken.com Satish D, Sasken Communication Technologies Ltd #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone:+91 80 535 5501 Ext: 3164 Fax: +91 80 535 1133 Email: satishd@sasken.com Satish et Al [Page 10]