IETF Mobile IP Working Group N. Montavont Internet-Draft LSIIT Expires: April 9, 2004 R. Wakikawa T. Ernst WIDE at Keio University T. Noel LSIIT October 10, 2003 Problem Statement for multihomed Mobile Nodes draft-montavont-mobileip-multihoming-pb-statement-00.txt 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 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. This Internet-Draft will expire on April 9, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Individual solutions have been proposed to extend Mobile IPv6 in order to allow mobile nodes to be multihomed, but all issues have not been addressed by a single document. In this document, we thus propose a taxonomy to classify the situations where a mobile node may be multihomed. This taxonomy is then used to describe all multihomed scenarios. Issues preventing mobile nodes to be multihomed while operating Mobile IPv6 are highlighted. This document doesn't aim at Montavont, et al. Expires April 9, 2004 [Page 1] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 proposing solutions, however, it is expected to raise discussion in order to make sure forthcoming solutions will address all the issues. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . 6 4.1 Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 MN connected to home link . . . . . . . . . . . . . . . . . . 8 5. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Montavont, et al. Expires April 9, 2004 [Page 2] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 1. Introduction New mobile nodes often integrate several wireless technologies. The main purpose of this integration is to federate all means of communications in order to have an ubiquitous mobile node which can be used to access to the Internet everywhere and at any time. Permanent Internet connectivity is required by some applications while a mobile node moves across several access networks (i.e. ISPs, hotspots, etc). For example, it is desirable to maintain the Internet connectivity while an automobile running on a freeway receives voice or video streaming data from different access networks. Unfortunately, there is no network interfaces assuring global scale connectivity. Therefore, a mobile node should use various type of network interfaces to obtain wide area network connectivity [11]. In addition, each network interface has different cost, performance, bandwidth, access range, and reliability. Users should thus be able to select the most appropriate set of network interface(s) depending on a visiting network environment, since wireless networks are mutable and less reliable than wired networks. Users should also be able to select the most appropriate interface per communication type. For example, TCP communication is best transmitted over wireless interface, while UDP communication is sent over a wired interface to avoid disturbing TCP connections. Mobile IPv6 [1] is being designed to allow a mobile node to maintain its IPv6 communications while moving between IPv6 subnets. However, the current specification does not give any hints nor requirements to deal with mobile nodes with several points of attachement, i.e. a multihomed mobile node. We propose to evaluate the behavior of standard Mobile IPv6 on a multihomed mobile node, and we will try to identify if modifications or enhancements are required in the specification. This document has two goals. The first goal is to define a taxonomy which helps to represent the different cases of multihoming. Then we describe scenarios where mobile nodes are multihomed. These scenarios show the configuration a mobile node may have (number of interfaces, number of home addresses or number of careof addresses). We also give a concrete illustration for each scenario. The second goal of this document is to define the requirements needed to manage multihomed mobile nodes. Different issues will be raised in order to provide full support of multihomed mobile nodes in MIPv6. The potentially needed solutions to support new features will be described in a separate document. Montavont, et al. Expires April 9, 2004 [Page 3] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 2. Terminology In this section we define the terms needed to analyse mobile node with mulitple points of attachment. Some definition are taken from [1], while other are completed or only defined in this document. Interface (from [7]) A node's attachment to a link Multihomed mobile node A mobile node is said multihomed when it has several IPv6 addresses to choose between. A mobile node has several IPv6 addresses to choose between in the following cases: multi-prefixed: multiple prefixes are advertised on the link(s) the mobile node is connected to. multi-interfaced: multiple interfaces to choose between, on the same link or not. multi-linked: multiple links to choose between (just like multi-interfaced but all interfaces are NOT connected to the same link) multi-sited: when using IPv6 site-local address and attached to different sites Montavont, et al. Expires April 9, 2004 [Page 4] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 3. Benefits Several benefits of multihoming can be envisioned: o Ubiquitous Computing: to provide an extended coverage area. Multiple interfaces bound to distinct technologies can then be used to ensure a permanent connectivity is offered. o Redundancy: to act upon failure of one point of attachment. o Load Balancing: to balance load between multiple point of attachments (simultaneously active or not). o Preference settings: to provide the user or the application the ability to choose the prefered transmission technology or access network for reasons of cost, politics, bandwidth requirement, delay, etc. Montavont, et al. Expires April 9, 2004 [Page 5] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 4. Multihoming Scenarios Different scenarios may lead to the fact that a mobile node may be multihomed. In this section are listed all the configurations where a mobile node may have multiple points of attachment. 4.1 Taxonomy To help to refer to a specific scenario, we define the following scheme: Scenario (x,y,z) where o x = number of home addresses (HoAs) o y = number of careof addresses (CoAs) o z = number of active interfaces The value of each identifier can be 1 if there is only one parameter, or n if there are several. The value n does not specify any number, but indicate that there are more than one parameters. An illustration of this taxonomy is given in Figure 1. Mobile Node HoA1 HoA2 ... HoAn --> Mobile IP layer (x) | | | +-----+--------+ | | | | | | | CoA1 +--CoA2 +---CoA3 ... CoAn --> IP layer (y) | | | | Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) | | | | +-----+----+ | | | | | IF1 IF2 ... IFn --> Physical layer (z) (z = the number of active interface) HoA1 ::= {CoA1, 2, 3} [IF1 and IF2] HoA2 ::= {CoA3} [IF2] Mobile Node(x = 2, y = 3, z = 2) Figure 1. Illustration of the chosen taxonomy Montavont, et al. Expires April 9, 2004 [Page 6] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 * because number of IPv6 link is equal to the number of CoAs, equal to y The variable x indicates the number of HoAs allocated to a MN. A MN may have multiple HoAs (x=n) when either: o The MN has only one home link, and all its HoAs are based on the same IPv6 prefix (e.g. the MN may have multiple interfaces). o The MN has only one home link, and several home addresses with distinct prefixes because there are several IPv6 prefixes advertised on the home link. o The MN has several home links, and thus has at least two HoAs with different IPv6 prefixes. 4.2 scenario 1. One HoA, one CoA, one interface (1,1,1) The MN is not multihomed. The MN has only one interface, with one HoA and is currently away from its home link. 2. Several HoAs, one CoA, one interface (n,1,1) The MN is multihomed, since it has several home addresses. Once the MN is connected to a visited IPv6 subnet, it gets one CoA and remains simulteneously reachable through all its HoAs. 3. Several HoAs, several CoAs, one interface (n,n,1) The MN is multihomed, since it has multiple addresses to choose between. In this case, the MN can be either connected to different IPv6 links at the same time, with the same interface, or it can be attached to a single link where several IPv6 prefixes are advertised. In the latter case, it configures a CoA for each prefix. Then, it may register several of them with distant nodes to benefit from its multihoming properties. 4. Several HoAs, several CoAs, several interfaces (n,n,n) The MN is multihomed. Many scenarios may lead to this case. For example, consider a MN with three interfaces, two of them connected to their home link(two different home addresses) and the last one connected to a visited link where two IPv6 prefixes are advertised. Montavont, et al. Expires April 9, 2004 [Page 7] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 5. One HoA, several CoAs, one interface (1,n,1) The MN is multihomed (several CoAs). The case (1,n,1) occurs when a MN is connected to different IPv6 links with the same interface: either there are several IPv6 prefixes advertised on the link, or the interface allows the MN to be connected to different access point in different IPv6 subnets. 6. One HoA, several CoAs, several interfaces (1,n,n) The MN is multihomed: the MN has several addresses to choose between. For example, assume a MN with several interfaces, each connected to an IPv6 network (the same or not). Then at least one IPv6 address is configured on each interface. The MN has only one home link, and only one home agent. 7. One HoA, one CoA, several interfaces (1,1,n) The MN may be multihomed: if the MN has two interfaces, one connected to its home link (using its home address) and the other connected to a visted link (using a careof address), the MN is multihomed. If the MN is connected to a visited link with one interface and has no IPv6 connectivity with the other interfaces (not in the range of an access point or no IPv6 prefix forwarded on a Layer 2 link), the MN is not multihomed. 4.3 MN connected to home link When a MN is multihomed, some of its interfaces may be connected to its home link(s), at any point of time. In all multihoming scenarii listed in the previous subsection, the MN may be directly connected to a home link. Sometimes, when a MN is connected to a home link, it may have an impact on the multihoming management. For example, in the case (n,n,n), a MN may be connected to its home link(s) with some interface(s). If we consider the case where a MN has three interfaces, three HoAs and two CoAs (connected to two visited IPv6 subnets), the CoAs can not be registered with the home agent serving to MN on the home link it is connected to. This case has to be considered when defining the management of multihoming. Otherwise, the case (n,n,n) can translate into either case (n,1,n) or (n,0,n) according to the way the MN is connected to the Internet. Case (n,1,n) only happens when the MN is connected to a visited link with only one interface and obtain only one CoA. Other interfaces are connected to the home link(s). Montavont, et al. Expires April 9, 2004 [Page 8] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 In the case (n,0,n), i.e. several HoAs, no CoA, and several interfaces, all interfaces of the MN is connected to a home link. If home links have different prefixes, a HoA can be a CoA regarding another HoA. Such considerations must be taken into account in a document which presents a solution for multihomed MN since some MIPv6 features can not be used when the MN is connected to the same link as its home agent (e.g. home registration). So the fact that a multihomed MN is connected to a home link must be considered. Montavont, et al. Expires April 9, 2004 [Page 9] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 5. Open issues In this section we highlight different points which have to be taken into account to handle a multihomed MN using Mobile IPv6. These items constitute the requirements for a Mobile IPv6 node to benefit from its multihomed configuration in an optimized fashion. Some of them do not require more processing than those defined in [1] but management operation, while other requires changes in [1]. Only the needed requirements are given in this document, the solutions to meet these requirements will be defined in a separate document. Issues related to the Mobile IPv6 protocol are the following: 1. How to define a relation between HoAs and CoAs. When a MN has several HoAs and obtain a new CoA, to which HoA the new CoA will be bound to ? Moreover, a HoA may be considered as CoA regarding another home link of the MN. 2. How to identify an entry in the Binding Cache: several CoAs can be simultaneously used by a mobile node when it has multiple points of attachments. These CoAs can be bound to the same HoA on any distant node, such as the home agent whih manages this mobile node for this particular HoA. Therefore both distant node and the mobile node need a way to identify an entry in the Binding Cache. 3. How to manage multiple CoAs bound to a single HoA: a multihomed MN may have multiple Care-of addresses. The MN must be able to register all CoAs with a single HoA on a distant node (Correspondant node or HA). Issues non-related to the Mobile IPv6 protocol are the following: 1. How to allow a mobile node to simultaneously use several interfaces: this will be the global purpose of such a solution to support multiple interfaces on a mobile node. The solution should bring support to allow a MN, or even a fixed multihomed MN to simultaneously use several interfaces, whatever the number of HoAs, of CoAs the mobile node may have and whatever the network configuration the mobile node is connected to. 2. How to manage multiple HoAs: a mobile node may have several HoAs. As the taxonomy suggests, the fact that the mobile node has several HoAs is independant from the fact that the mobile has multiple interfaces. By the way, the fact that the mobile node has multiple interfaces does not imply that it has multiple HoAs and vice-versa. A mechanism should thus be defined to detail how to bind HoAs to a MN. Montavont, et al. Expires April 9, 2004 [Page 10] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 3. How a mobile node may redirect flows from one interface to another, in the different scenarios presented in section 3: this functionality would allow a mobile node to pursue any communication began on an interface while this interface becomes down and another one is available. 4. When a MN has several interfaces, it may want to use each interface differently. According to some policies and preferences, a multihomed MN may want to independantly manage each flow, in order to define which flow would be mapped to which interface and/or which flow can not use a determined interface. In order to optimize the global connectivity of a multihomed MN, a solution may be defined to allow multihomed MN to set filters on flow on distant nodes, such as mechanisms proposed by [10], [5] and [4]. Montavont, et al. Expires April 9, 2004 [Page 11] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 References [1] Perkins, C. and J. Arko, "Mobility Support in IPv6", I-D draft-ietf-mobileip-ipv6-24.txt, June 2003. [2] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to protect Mobile IPv6 signaling between Mobile Nodes and Home Agents", I-D draft-ietf-mobileip-mipv6-ha-ipsec-06.txt, June 2003. [3] Montavont, N., Noel, T. and M. Kassi, "MIPv6 for Multiple Interfaces", I-D draft-montavont-mobileip-mmi-01.txt, October 2003. [4] Koojana, K., Fikouras, N., Koensgen, A. and C. Goerg, "Filters for Mobile IPv6 Bindings (NOMADv6)", I-D draft-nomadv6-mobileip-filters-00.txt, July 2003. [5] Montavont, N. and T. Noel, "Home Agent Filtering For Mobile IPv6", I-D draft-montavont-mobileip-ha-filtering-v6-00.txt, July 2003. [6] Wakikawa, R., Uehara, K., Ernst, T. and K. Nagami, "Multiple careof Address Registration on Mobile IPv6", I-D draft-wakikawa-mobileip-multiplecoa-02.txt, September 2003. [7] Manner, J. and M. Kojo, "Mobility Related Terminology", I-D draft-ietf-seamoby-mobility-terminology-04.txt, April 2003. [8] Fikouras, N., Udugama, A., Koensgen, A., Goerg, C., Zirwas, W. and J. Eichinger, "Filters for Mobile IPv6 Bindings (NOMADv6)", I-D draft-nomad-mobileip-v6-filters-00.txt, July 2003. [9] Ernst, T., "Network Mobility Support Terminology", I-D draft-ietf-nemo-terminology-00.txt, May 2003. [10] Soliman, H., Elmalki, K. and C. Castelluccia, "Flow Movement in Mobile IPv6", I-D draft-soliman-mobileip-flow-move-03.txt, June 2003. [11] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay Networks", Journal Mobile Networks and Applications, vol. 3, number 4, pages 335-350, 1998. Montavont, et al. Expires April 9, 2004 [Page 12] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 Authors' Addresses Nicolas Montavont LSIIT - Univerity Louis Pasteur Ple API, bureau C444 Boulevard Sebastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 87 EMail: montavont@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~montavont/ Ryuji Wakikawa Jun Murai Lab., Keio University 5322 Endo Fujiwasa Kanagawa 252-8520 Japan Phone: +81-466-49-1394 EMail: ryuji@sfc.wide.ad.jp URI: http://www.mobileip.jp/ Thierry Ernst Jun Murai Lab. Keio University K2 Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki Kanagawa 212-0054 Japan Phone: +81-44-580-1600 EMail: ernst@sfc.wide.ad.jp URI: htpp://www.sfc.wide.ad.jp/~ernst Thomas Noel LSIIT - Univerity Louis Pasteur Ple API, bureau C444 Boulevard S‰bastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 92 EMail: noel@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~noel/ Montavont, et al. Expires April 9, 2004 [Page 13] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Montavont, et al. Expires April 9, 2004 [Page 14] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Montavont, et al. Expires April 9, 2004 [Page 15]