INTERNET DRAFT Youn-Hee Han Expires: December 2002 JinHyeock Choi JiHoon Lee Samsung AIT July 2002 Route Optimization Support for Localized Mobility Management Based on IPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and 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 obsolete by other documents at anytime. 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. Copyright Notice Copyright (c) The Internet Society (2002). All rights reserved. Abstract Using localized mobility management based on IPv6, all packets destined to a mobile node are routed through the local mobility agent in the mobile node's local mobility domain, which then tunnels the packets to the mobile node's current location. Such packet routing mechanism is similar to the triangle routing in Mobile IPv4, which may leave the local mobility agent overloaded and take a longer route thus increasing the network traffic in the local mobility domain. This document specifies a route optimization scheme for localized mobility management based on IPv6 with the help of L2 trigger. Using this, correspondent nodes can cache LCoA of a mobile node if it is actively communicating with the mobile node, and then send their packets for the mobile node directly to the LCoA, bypassing the local mobility agent. This route optimization scheme will result in more efficient localized Han, Choi, Lee Expires December 2002 [Page 1] INTERNET-DRAFT RoLMMv6 July 2002 mobility management. It alleviates the local mobility agent's loads and takes the nearly same handoff delay time as the one in localized mobility management based on IPv6. Table of Contents: Status of this Memo ............................................. 1 Copyright Notice ................................................ 1 Abstract ........................................................ 1 1. Introduction ................................................. 3 1.1 Terminology ............................................ 3 1.2 Problem Description .................................... 4 1.3 L2 Trigger ............................................. 6 2. Route Optimization Overview .................................. 6 3. Mobile Node Operations ....................................... 8 3.1 'CoA' Field in Binding Update List ..................... 8 3.2 L2 State Managment ..................................... 8 3.3 Measurement of Tunneled Packet Arrival Rate ........... 9 3.4 Binding Update using L2 Trigger ........................ 9 4. Security Considerations....................................... 9 5. Notice Regarding Intellectual Property Rights................ 10 6. References................................................... 10 7. Authors' addresses........................................... 10 Han, Choi, Lee Expires December 2002 [Page 2] INTERNET-DRAFT RoLMMv6 July 2002 1. Introduction Localized Mobility Management based on IPv6 (LMMv6) [1] provides a protocol design to reduce the binding update (BU) signaling latency and the signaling load outside the local mobility domain. HMIPv6 [2] has been a typical protocol satisfying the design rules proposed by the LMMv6. The design is an extension to the Mobile IPv6 (MIPv6) protocol [3], and reduces frequent BUs destined to its home agent (HA) and its peer correspondent nodes (CNs). Using LMMv6, however, all packets destined to a mobile node (MN) are routed through the local mobility agent (LMA) in the MN's local mobility domain, which then tunnels the packets to the MN's current location. Such packet routing mechanism is similar to the triangle routing in Mobile IPv4, which may leave the LMA overloaded and take a longer route thus increasing the network traffic in the local mobility domain. This inefficient routing is caused by the peculiar binding cache in CNs. The binding cache entry consists of a home address associated with RCoA. Therefore, a CN cannot help sending packets to the LMA. This document specifies a route optimization scheme with help of L2 trigger [4], which can be applied in LMMv6. The new proposal is mostly executed at an MN and operates in per-CN based manner. For CNs who are not communicating with the MN, it is required to do no additional operations besides the LMMv6. For CNs who are actively communicating with the MN, the MN sends BUs with LCoA to the CNs. From that time, the CNs can send their packets for the MN directly to the LCoA, bypassing the LMA. Before the MN performs a handoff in our proposal, it is supposed to receive L2 trigger which indicates that it is about to move and attache a new point of access. At this moment, the MN sends BUs with RCoA to the CNs, so that packets from the CNs may be routed through the LMA during the MN performs a L3 handoff. That is, the MN makes the LMA transparent from CNs during they are actively communicating with the MN. On the other hand, it utilizes the LMA as an anchor point during performing a handoff. This route optimization proposal will result in a more efficient localized mobility management. It alleviates the LMA's loads and takes the nearly same handoff delay time as the one in the LMMv6. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. This documentation uses the terminology described in [1] and [3]. In addition, new terms are defined below: L2 Handoff Change of MN's link layer connection from one access point (AP) to another. Han, Choi, Lee Expires December 2002 [Page 3] INTERNET-DRAFT RoLMMv6 July 2002 L3 Handoff Change of MN's routable address from one access router (AR) to another. BU(LCoA) Binding Update Message with LCoA of MN. BU(RCoA) Binding Update Message with RCoA of MN. 1.2 Problem Description Although LMMv6 reduces the BU signaling latency and the signaling load outside the local mobility domain, all IP packets addressed to MNs in the domain are routed to the LMA. The LMA intercepts the packets and then tunnels them to the MN's current LCoA. Such packet routing mechanism is similar to the triangle routing in Mobile IPv4 (MIPv4). There has been an effort [5] optimizing the packet routing in MIPv4. In MIPv6, it is built in as a fundamental part of the protocol. However, LMMv6 has no route optimization support, which may leave the LMA overloaded and take a longer route thus increasing the network traffic in the local mobility domain. An example of a typical LMMv6 network entities is as follows (see Figure 1). The example assumes that the local mobility domain includes two Border Routers (BR1 and BR2), and one LMA lies near to a BR. There are two CNs (CN1 and CN2) which are communication with the MN, and the BR1 and BR2 are connected with CN1 and CN2, respectively. The MN already sent BU to two CNs, so that two CNs have known RCoA of the MN. +----------------------------------------+ | Local Mobility Domain | +----+ | +----+ +----+ | | CN1| | +----+ AR |--| AR +-----+ | +-+--+ | | +----+ +----+ | | | | +-+--+ +--+--+ +----+ | +--------+-|BR1 | | LMA +--+BR2 +-+-------+ | +-+--+ +--+--+ +-+--+ | | | | +----+ +----+ | | +-+--+ | +----+ AR +--+ AR +-----+ | | CN2| | +-+--+ +-+--+ | +----+ | | | | AP | | : | | : AP : Access Point | | MN AR : Access Router | | BR : Border Router | +----------------------------------------+ Figure 1. Typical LMMv6 network entities Han, Choi, Lee Expires December 2002 [Page 4] INTERNET-DRAFT RoLMMv6 July 2002 In the above example, only four routing-hops may be required from CN2 to MN. Since the LMA takes its position in the routing path, packets from CN2 are delivered through optimized route. However, packets from CN1 are delivered through a non-optimized route. CN1 knows only RCoA so that packets from CN1 are delivered to the LMA, which sends them to the MN. Therefore, the required total number of routing-hops is six. In their optimized route, however, only two hops are required. This non-optimized packet routing makes LMMv6 unsuitable to real- time multimedia service and overloaded by many packet processing. Particularly, the LMA groans under additional heavy burden for tunnel setup per packet. If the local mobility domain managed by one LMA is large, these problems become very serious. In order to alleviate the LMA overloads, network administrators may make a decision, which incurs costs apparently, to deploy additional LMAs in the administrative domain. In this case, moreover, the local mobility domain may be divided as several sub- domains and the BU signaling may become prevalent. In fact, the LMMv6 is the centralized system architecture. The centralized LMA processes all packet traffic within the managed local mobility domain, so that the number of MNs or ARs per LMA is very critical for quality of service and system performance. In general, LMA will degrade the overall performance since there will be high traffic loads on LMA, which results in a high cost of packet delivery. 1.3 L2 trigger An MN may irregularly change the terrestrial radio 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 the MN to send BU to HA or CNs. In order for L3 handoff to occur, candidate APs must be identified and a target AP must be selected [6]. Once this process has been completed, the handoff process can begin. An L2 trigger is a notification from L2 that a certain event has happened or is about to happen. It is not associated with any specific L2 but rather is based on the kind of L2 information that can be available from a wide variety of radio link technology. By evaluating the state and controlling the behavior of the radio AP, future movements of MNs to other APs can be identified and therefore necessary actions can be taken in due time. The IP entities that can receive the trigger are various; MN, AP or AR. Among the entities, this proposal assumes that the MN receives the L2 trigger as soon as possible. There can be many implementation methods of the L2 trigger received by MN, of which detailed description is beyond the scope of this document. Han, Choi, Lee Expires December 2002 [Page 5] INTERNET-DRAFT RoLMMv6 July 2002 2. Route Optimization Overview Route Optimization provides a means to optimize a MN's communication with CNs. When sending a packet to an MN, if the CN has a binding cache entry for the destination MN, it may send the packet directly to the CoA indicated in the cached mobility binding. In the LMMv6, all MNs always have RCoA as well as LCoA. However, they send only BU(RCoA) to CNs and the binding cache maintained by a CN includes only RCoA. So, packets destined to an MN will be routed to the MN's LMA, and are then tunneled to the MN's current LCoA. With the route optimization scheme proposed in this document, after indirect routing of some packets to a MN, the original CN of the packets is informed of the MN's current mobility binding, giving the CN an opportunity to cache LCoA. The 'CoA' field contained in the binding update list of each MN contains the CoA delivered by that BU. In the LMMv6, the field always contains RCoA for a CN entry to which a BU was sent. This proposal, however, allows the field to contain LCoA as well as RCoA. If the MN does not wish to optimize its own communication with the CN, the field contains RCoA. Otherwise, the field contains LCoA. That is, the field indicates whether the route optimization is setup or not for each CN registered in the binding update list. This proposal also assumes that an MN receives and processes L2 trigger when a handoff occurs. And it is required for an MN to maintain L2 state, which tells layer 2's stability to the MN. The state consists of two different condition of L2: 'stable' and 'unstable'. The existing MIPv6 uses primitive detection of data packet flow for route optimization. Receiving only one tunneled packet from HA, an MN establishes the optimized route with the CN sending the packet. If the CN is supposed to send only two or three packets, however, the route optimization becomes needless. Therefore, this proposal additionally requires an MN to measure the tunneled packet arrival rate. On receiving a tunneled packet from HA or LMA, an MN starts to measure the packet arrival rate. If the rate becomes more than a predefined threshold rate, the MN checks if the L2 state is stable. If it is, it sends BU(LCoA) to the CN sending the packets. The rate measurement and the checking of L2 state are used to reduce the number of BUs and to prevent the unnecessary BUs. If an MN performs a handoff, the MN's L3 receives a L2 trigger prior to the handoff. At this moment, the MN sends BU(RCoA) to the CNs, so that packets from the CNs may be routed through the LMA during the MN performs L3 handoff of LMMv6. That is, MN utilizes LMA as an anchor point during performing a handoff. It is the important requirement for the L2 trigger to take place sufficiently early. Before both L2 and L3 handoffs (e.g., AP switching, the Han, Choi, Lee Expires December 2002 [Page 6] INTERNET-DRAFT RoLMMv6 July 2002 router discovery, the address auto-configuration, and the delivery of BU(LCoA) to LMA) are completed, BU(RCoA) SHOULD reach the CN. To quickly send BU(RCoA) to CN with help of the early L2 trigger can take the nearly same handoff delay time as the one in the LMMv6. The MN excludes LMA from a viewpoint of CNs when they are actively communicating with the MN. On the other hand, it utilizes LMA as an anchor point when performing a handoff. This route optimization proposal will result in a more efficient localized mobility management to alleviate the LMA's loads and take the nearly same handoff delay time as the one in the LMMv6. As a matter of course, this proposal increases BU signaling. While the size of BU is 100 bytes or 120 bytes (if it includes authentication header), however, the size of a data packet is above 1024 bytes generally, so that data packets occupy the most network bandwidth. Also, real network traffic exhibits long-range dependence and high burstiness over a wide range of time scales. While most files have few packets, most packets are in large files. It has further been widely argued that the dominant source of this behavior is due to heavy-tailed Web and other application traffic being streamed out onto the network by TCP to create long-range correlations in packet rates [7]. Therefore, the optimized data packet delivery should be achieved at the expense of the benefits come from BU signaling reduction. 3. Mobile Node Operations This section explains the special processing required at an MN for the route optimization. The following processing MAY be not performed if the MN has decided that the route optimization does not give some benefits at all (e.g., if the velocity of MN is very high or if the MN moves across many subnets very frequently.) 3.1 'CoA' Field in Binding Update List An MN maintains a Binding Update List, which is recording information for each BU sent by this MN, for which the lifetime sent in that BU has not yet expired. The list includes all bindings sent to CNs or to HA by the MN. 'CoA' field contained in the list contains the CoA delivered by the BU. In the MIPv6 and the LMMv6, this value is only necessary for the MN to determine if it has sent a BU giving its new CoA to the destination after changing its CoA. In order to support the route optimization in the LMMv6, however, this value is also required for the MN to determine whether it has sent BU(LCoA) or BU(RCoA). The field contains RCoA for a CN entry to which a BU was sent, if the MN does not wish to optimize its own communication with the CN. Otherwise, the field contains LCoA. That is, the field indicates whether the route optimization is setup or Han, Choi, Lee Expires December 2002 [Page 7] INTERNET-DRAFT RoLMMv6 July 2002 not for each CN registered in the binding update list. When a MN performs a handoff, the MN first searches the binding update list, and sorts out the CNs of which 'CoA' field contains LCoA. For those CNs, the MN sends BU(RCoA), so that packets from the CNs may be routed through the LMA during the MN performs L3 handoff. 3.2 L2 State Managment In this proposal, an MN MUST maintain the L2 state, which tells layer 2's stability to the MN. The state consists of two different condition of L2: [S] and [U]. [S] indicates that the quality of MN's layer 2 connection is stable or above some threshold. In the other hand, [U] indicates that the quality of MN's layer 2 connection is unstable or below some threshold. The change of state is dynamically done according to layer 2 connection quality. A method to determine the quality of L2 connection is diverse from a wide variety of radio link technology. Its implementation issue are beyond the scope of this document. The inherent limitations of mobile environment (e.g., frequent disconnection and low-bandwidth wireless network links) as well as a handoff lead the L2 state to [U]. During this state, an MN MUST NOT send BU(LCoA) to any CN and the LMA is used as the anchor point as before. Therefore, this L2 state management ensures that the route optimization is done only when the quality of L2 connection is stable. 3.3 Measurement of Tunneled Packet Arrival Rate In the LMMv6, all packets are tunneled by HA or LMA. This proposal defines a value of UPPER_TUNNELED_PACKET_ARRIVAL_RATE, and an MN starts to measure the packet arrival rate when it receives a tunneled packet from HA or LMA. If the rate becomes more than UPPER_TUNNELED_PACKET_ARRIVAL_RATE, the MN checks if the L2 state is [S]. If it is, it MUST sends BU(LCoA) to the CN sending the packets. The rate measurement and the checking of L2 state are used to reduce the number of BUs and to prevent the unnecessary BUs. 3.4 Binding Update using L2 Trigger If the MN performs a handoff, MN's L3 receives a L2 trigger prior to the handoff. At this moment, the MN MUST send BU(RCoA) to the CNs, so that packets from the CNs may be routed through the LMA during the MN performs L3 handoff. That is, MN utilizes the LMA as an anchor point during performing a handoff. In order for this proposal to take the nearly same handoff delay Han, Choi, Lee Expires December 2002 [Page 8] INTERNET-DRAFT RoLMMv6 July 2002 time as the one in the LMMv6, the L2 trigger SHOULD bring up sufficiently early so that the MN quickly sends BU(RCoA) to the CN. It is the important requirement for the L2 trigger to take place sufficiently early. Before both L2 and L3 handoffs (e.g., AP switching, the router discovery, the address auto-configuration, and the delivery of BU(LCoA) to LMA) are completed, BU(RCoA) SHOULD reach the CN. This policy makes all conditions equal to those within the LMMv6. 4. Security Considerations In the LMMv6, an MN sends BUs to the LMA it visits currently, and all BUs between the MN and the LMA MUST be authenticated. This requires the security association establishment between the MN and the LMA. In the LMMv6, also, MN sends BU to any CN in order to notify its RCoA. This requires the other security association establishment between the MN and the CN. Because the two security associations are already required in the LMMv6, this route optimization proposal does not introduce more security problems than the MIPv6 and the LMMv6. 5. Notice Regarding Intellectual Property Rights Samsung Electronics is pending patent applications that may be relevant to this Internet-Draft. If this specification is adopted by IETF and any claim of this patent is necessary for practicing this standard, any party will be able to obtain a license from Samsung Electronics to use any such patent claims under openly specified, reasonable, non-discriminatory terms to implement and fully comply with the standard. 6. References [1] Carl Williams, Localized Mobility Management Requirements for IPv6, , Work in Progress. [2] Hesham Soliman, et. al., Hierarchical MIPv6 mobility management (HMIPv6), , Work in Progress. [3] D. B. Johnson, et. al., Mobility Support in IPv6, , Work in Progress. [4] James Kempf, et. al., Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems, , Work in progress. [5] David B. Johnson, et. al., Route Optimization in Mobile IP, , Work in progress. Han, Choi, Lee Expires December 2002 [Page 9] INTERNET-DRAFT RoLMMv6 July 2002 [6] Dirk Trossen, et. al., Issues in candidate access router discovery for seamless IP-level handoffs, , Work in progress. [7] John C. Doyle, et. al., Robustness and the Internet : Theoretical Foundations, rough draft, http://netlab.cal­ tech.edu/pub/papers/RIPartII.pdf. 7. Authors' Addresses Youn-Hee Han i-Networking Lab, Samsung AIT (SAIT) Tel : +82 31 280 9577 Fax : +82 31 280 9587 E-mail : yhhan@sait.samsung.co.kr JinHyeock Choi i-Networking Lab, Samsung AIT (SAIT) Tel : +82 31 280 9233 Fax : +82 31 280 9587 E-mail : athene@sait.samsung.co.kr JiHoon Lee i-Networking Lab, Samsung AIT (SAIT) Tel : +82 31 280 9577 Fax : +82 31 280 9587 E-mail : ezhoon@sait.samsung.co.kr Han, Choi, Lee Expires December 2002 [Page 10]