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]