Internet Engineering Task Force N. Montavont INTERNET DRAFT T. Noel Expires in February 2003 LSIIT - ULP M. Kassi-Lahlou France Telecom R&D July 2002 MIPv6 for Multiple Interfaces Status of This Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. 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. Distribution of this memo is unlimited. Abstract MIPv6 [MIPv6] allows a MN to maintain its IPv6 communications while moving between subnets. This document presents the problematic for a MN of having multiple network interfaces. It discusses how to perform vertical handovers (flow redirection between interfaces) and propose MMI (MIPv6 for Multiple Interfaces) which describes the use of MIPv6 to support multiple interfaces. These extensions focus on the MN ability to use a backup interface for communications and to redirect flows between its own interfaces. draft-montavont-mobileip-mmi-00.txt [Page 1] INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 Table of contents Status of this memo Abstract 1. Introduction.............................................2 2. Terminology related to multiple interfaces...............3 2.1 Terminology..........................................3 2.2 Network configuration................................4 3. Motivations..............................................5 3.1 Why a MN may want to redirect a flow.................5 3.2 Scenarios............................................5 3.2.1 Two interfaces available at the same time......5 3.2.2 Only one interface available at a given time...6 4. Multiple interfaces management...........................6 4.1 Hypothesis..........................................6 4.2 MMI.................................................7 5. Future Work..............................................8 5.1 Receiving new communications.........................8 5.2 Filtering............................................8 6. References...............................................9 7. Authors' address.........................................10 Appendix A: Local Redirection...............................10 1. Introduction Future MNs will probably have multiple interfaces to be connected to different access technologies. Each technology has its specific characteristics in terms of coverage, bandwidth, reliability, etc. While MIPv6 [1] allows a MN to handover between subnets, there are no requirements to manage mobility into the MN, i.e. between several interfaces. This document presents the problematic of having multiple interfaces and proposes some simple extensions to MIPv6, called MMI (MIPv6 for Multiple Interfaces) to optimize the use of multiple interfaces. Assume a MN with two interfaces. For example, the MN can be connected to the network with only one interface. After a move, it connects to the network with the other interface and looses the network connectivity through the first. Subsequently the MN may want all the flows using the first interface to be automatically redirected on the other available interface. Or, a MN can take advantage of having multiple interfaces by using backup interface. Also, if a MN performs a handover between subnets, it may redirect its flows on another interface while it performs MIPv6 operations. This minimizes the impact of the handover on the applications. draft-montavont-mobileip-mmi-00.txt [Page 2] INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 In this document, the specific operations needed to perform vertical handovers are described. In the next section, some definitions related to multiple interfaces management are given. The section 3 explains why a MN may want to redirect flows between its interfaces and gives two scenarios of a MN with multiple interfaces. Then, MMI operations are described for a generic network configuration. These operations describe the use of MIPv6 to perform vertical handovers. Finally, the document ends on further functionalities which are going to be developped later. 2. Terminology related to multiple interfaces 2.1 Terminology The following terms are introduced in the document. Some definitions are taken from [2]. Available interface An interface that offers to the MN connectivity to the network. The MN can initiate and receive flows through this interface Interface down An interface is down when it is not available for flows. An interface may be down for many reasons (e.g. the interface is deactivated by the user, the interface is physically not inserted in the MN, the interface is not connected to a network) L2 handover The change of access point L3 handover The change of IP subnet Horizontal handover From the IP point of view, a horizontal handover happens if the MN changes of subnet it is connected to Vertical Handover [2] In a vertical handover the MN's network interface to the access network changes. A vertical handover is typically an inter-technology handover draft-montavont-mobileip-mmi-00.txt [Page 3] INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 Source interface During a vertical handover, the source interface is the interface from which flow will be redirected. Target interface During a vertical handover, the target interface is the interface to which flow will be redirected. 2.2 Network configuration This document focuses on the management of multiple network interfaces into a single MN. Each interface is either wireless or wired. This document will detail the operations needed for a MN to redirect flow between its interfaces. In each proposition, we discuss the redirection between two interfaces, but the operations are effective even if a MN has more interfaces. The proposed mechanism proposed works in all the network configurations possible, that is to say all the network configurations to which the MN is connected: - The two interfaces are connected to the same subnet, the home network for each interface - The two interfaces are connected to the same subnet, a visited network for each interface - The two interfaces are connected to the same subnet, the home network for one interface and a visited network for the other - The two interfaces are connected to different subnets, the home network for each interface - The two interfaces are connected to different subnets, a home network for one interface and a visited network for the other interface - The two interfaces are connected to different subnets, a visited network for each interface We will prove that some simple operations described in MMI are sufficient for all the above network configurations. draft-montavont-mobileip-mmi-00.txt [Page 4] INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 3. Motivations 3.1 Why a MN may want to redirect a flow A MN may want to redirect its flows between its available interfaces for many reasons: - An interface in use comes down - The MN can take advantage of having multiple interfaces and redirects some or all flows from the down interface to another available interface - An interface comes up. The MN may decide that the interface which comes up is most suitable for its current flows using another interface - The MN performs a handover on an interface in use for flows. When a MN performs a horizontal handover, the handover latency (the time during which the MN can not send nor receive packets) can be long and the flows can be perturbed. If the MN wants to minimize such perturbation, it can redirect some or all the flows on another available interface. This redirection can be done in advance of the handover by the L2 triggers [3] - The network capabilities change. The MN can observe a degradation of service on one of its interface, or conversely an improvement of capacity on an interface. The MN may then decide to redirect some or all flows on another interface that it considers most suitable for the target flows. 3.2 Scenarios 3.2.1 Two interfaces available at the same time Assume a global network covering wide areas, like third generation network. A MN can access to services like telephony, e-mail and web browser through an interface I1 connected to this wide network. At the same time, the MN has Internet access with a higher rate than the global network on an other interfaces I2, e.g. in WLANs or hot spots. The coverage area of this second technology is smaller than the global network and is also covered by the global network. When the mobile user enters the area covered by the technology with the higher rate (e.g. WLANs), he may want to: - Initiate new flow through I2 - Continue its current flows on I1 - Redirect some or all flows from I1 to I2 to take advantage of the technology with the higher rate draft-montavont-mobileip-mmi-00.txt [Page 5] INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 When the mobile user leaves the coverage area of the technology with the higher rate, he may want to: - Interrupt its flows using I2 - Redirect some or all flows from I2 to I1 3.2.2 Only one interface available at a given time Consider a MN with two interfaces of different technologies. Firstly, the MN is connected to the network with only one interface. Then the MN connects to the network through the other interface, typically after a move, and the MN looses its first connection. For example, assume a company offering an access to network resources like Internet access or intranet. Consider a mobile host with both a wireless and a wired interface. According to company rules, the wireless subnet can or cannot be on the same subnet than the wired subnet. The two interfaces can be used in many ways: keep a backup interface, use each interface for pre-determined traffic... According to the availability of the interfaces, a MN may want to redirect flows between its interfaces. 4. Multiple interfaces management 4.1 Hypothesis In the following, we assume a MN with two interfaces I1 and I2 of different access technologies. Each interface is configured with a global IPv6 address, respectively IP1 and IP2. These two global IPv6 addresses are assigned to the MN in such a way that both addresses can be used to reach the MN. The MN uses Mobile IPv6 on each of its interfaces when it moves between subnets. Then the MN has a home link for each of its interfaces and there is a router acting as a home agent on each home link. The use of MIPv6 to redirect flows between interfaces are highlight for a generic network configuration. The generic network configuration encloses all the cases listed in section 2.2. MMI allows a MN to transparently redirect its ongoing flows from its interface I2 to its interface I1 (vertical handover). draft-montavont-mobileip-mmi-00.txt [Page 6] INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 4.2 MMI MMI allows a MN to register a binding on its home agent (and eventually its CNs) between two IP addresses, each allocated to one of the MN's interfaces. The main mechanism is to send a Binding Update to indicate a new CoA of a source interface through the target interface. MMI works for any configuration network, as when the MN is initially connected to the same subnet with its two interfaces as when the MN is initially connected to different subnet. To make things as clear as possible, this document discusses the flow redirection from (I2, IP2) to (I1, IP1) in order to illustrate MMI. IP1 can be the home address allocated to I1, or the current CoA allocated to I1. The generic solution for the MN to redirect the flows intended to IP2 on I1 (vertical handover from the source interface I2 to the target interfaces I1) is to use the MIPv6 mechanism adapted for multiple interfaces (MMI). The MN sends a Binding Update to its home agent serving the MN for the source interface (and eventually to its CNs). The Binding Update [1] must be sent as follow: - The home address field set to the IP address bound to the source interface (IP2) - The CoA field set to the IP address bound to the target interface (IP1) This Binding Update must be sent through the target interface. When receiving the Binding Update, the home agent registers an association between IP2 and IP1 in its binding cache. Therefore, all new flows with the destination address IP2 will be intercepted by the home agent and forwarded to the current address allocated to target interface (IP1 on I1). This operation does not disturb the initial communications on the target interface I1 using IP1. Thus, MMI allows a MN to send a binding information for a source interface by using another interface, the target interface. draft-montavont-mobileip-mmi-00.txt [Page 7] INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 Afterwards, if the MN moves to a new subnet by using the target interface I1 (horizontal handover on I1), it obtains a new CoA (IP3). Besides the operations required in MIPv6 when a MN changes its point of attachment, the MN has to send a Binding Update to its home agent serving the source interface (and eventually to CNs of its current flows which have a binding between IP2 and IP1 in their binding cache) to update its localization. Now, the binding cache of the home agent records, among others, a binding between the home address IP2 and the CoA IP3. Thus, the movement detected on I1 is indicated to I2. Later, if the MN wants to use the source interface I2 again and had registered an association on its home agent between IP2 and IP1, it needs to update the entry in the binding cache of the home agent. If the MN is connected to a foreign network through the source interface I2 (different from the home link), it sends a Binding Update with the new IPv6 address got on the current link as the new CoA, to update the binding cache of its home agent. If the MN is connected to its home link through I2, it has to send a Binding Update to its home agent to make it invalid the binding cache for it (see returning home in [1]). 5. Further Work In this section, we describe some further operations that can be simply added to MMI framework in order to optimize the multiple interfaces management. 5.1 Receiving new communications Consider a MN which has redirected flows from a source interface (I2, IP2) to a target interface (I1, IP1) as described in MMI (section 4). If the MN receives a new flow forwarded by its home agent, the MN has several possibilities: it might reject the flow (e.g. the flow needs are not adapted to the network capacities provided to the MN); Or if the MN does not reject the flow, it might decide to inform the CN of the flow that its current address is IP1 and that it needs to use routing header [1]. 5.2 Filtering Filtering the current flows When a MN redirects its flows between its own interfaces, MMI requires that the MN sends a Binding Update to its home agent through the target interface (I1, IP1), in order to register a new association for the source interface (I2, IP2). However, the MN may not want to redirect all the flows of the source interface (because the target interface can not support certain flows, or the MN just wants to spread again its flows on all its interfaces to optimize the network capacities). To advertise its home agent (or a CN) to only redirect some flows of the source interface, the MN should add filters in the Binding Update sent for the redirection. The filter indicates which flow is concerned by this binding [5][6]. draft-montavont-mmi-00.txt [Page 8] INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 The flow identification can be the one used in the Flow Label field in the IPv6 header if set [7]. Otherwise, the flow identification can be the quintuplet source and destination ports, source and destination addresses and protocol ID. Filtering future flows Besides redirecting its current flows between its interfaces, a MN may want to advertise its home agent to only redirect a part of the future flows intended to it. We call future flows of the MN, the flows that the MN could receive in the near future, that do not exist when the MN sends the Binding Update for the redirection. If the MN wants that its home agent only redirects some of its future flows, it may add a new filter in the Binding Update sent to its home agent. The new filter in the Binding Update can indicate a protocol ID or an application ID. Therefore, as soon as a new flow is intercepted by the home agent for the MN, it checks if the filter matches with the flow to redirect the flow to the right CoA. 6. References [1] D. Johnson, C. Perkins. "Mobility support in IPv6", draft-ietf-mobileip-ipv6-18.txt, July 2001. [2] J. Manner, M. Kojo, "Mobility related terminology", draft-manner-seamoby-terms-04.txt, May 2002. [3] J. Kempf, et. al, "Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems", draft-manyfolks-l2-mobilereq-02.txt, June 2002. [4] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [5] M. Diagne, T. Noel, "A Protocol for IPv6 Nomadic Communications", 5th IEEE Malaysia International Conference on Communications (MICC'01), Malaysia, October 2001 [6] H. Soliman, K. El Malki, C. Castelluccia, "Per-flow movement in MIPv6", draft-soliman-mobileip-flow-move-01.txt, November 2001. [7] J. Rajahalme, A. Conta, B. Carpenter, S. Deering, "IPv6 Flow Label Specification", draft-ietf-ipv6-flow-label-00.txt, February 2002. draft-montavont-mmi-00.txt [Page 9] INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 7. Authors' address Nicolas Montavont LSIIT - ULP Pole API Boulevard Sebastien Brant 67400 Illkirch France E-mail: montavont@dpt-info.u-strasbg.fr Thomas Noel LSIIT - ULP Pole API Boulevard Sebastien Brant 67400 Illkirch France E-mail: noel@dpt-info.u-strasbg.fr Mohammed Kassi-Lahlou France Telecom R&D 42, rue des Coutures BP 6243 14066 Caen Cedex 4 - France E-mail: mohamed.kassilahlou@francetelecom.com Annexe A: Local Redirection There is an easier mechnanism for the MN to redirect flow between its interfaces when it is connected to the same subnet through its interfaces. The Local Redirection allows a MN to transparently redirect its ongoing flows between its interfaces without using the MIPv6 features. When a MN is connected to the same subnet though both I1 and I2 and wants to redirect all its ongoing flows intended to IP2 (assigned to I2) it can allocate IP2 to I1. The MN has to advertise its neighbors on the link that all packets with the destination address IP2 must now be forwarded to the MAC address of I1. To do so, the MN sends an unsolicited Neighbor Advertisement [4] to all nodes multicast address indicating the association between IP2 and the MAC address of I1. The 'O' bit must be set in the unsolicited Neighbor Advertisement to override the old entry associating IP2 to the MAC address of I2. This causes the neighbor nodes on the link to add the association between the MAC address of I2 with IP1. After, the MN is reachable through I1 by both IP1 and IP2. This redirection is transparent to the distant CNs. draft-montavont-mmi-00.txt [Page 10] Expires: February 2003