[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc4980                               
NEMO Working Group                                                 C. Ng
Internet-Draft                                  Panasonic Singapore Labs
Expires: January 10, 2005                                        E. Paik
                                               Seoul National University
                                                                T. Ernst
                                                 WIDE at Keio University
                                                           July 12, 2004


          Analysis of Multihoming in Network Mobility Support
                 draft-ietf-nemo-multihoming-issues-00

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 January 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document is an analysis of multihoming in the context of network
   mobility (NEMO).  As there are many situations in which mobile
   networks may be multihomed, a taxonomy is proposed to classify the
   possible configurations.  We also describe possible deployment
   scenarios and we attempt to identify issues that arise when mobile
   networks are multihomed while mobility supports is taken care by NEMO



Ng, et al.              Expires January 10, 2005                [Page 1]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   Basic Support.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Classification . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1   (1,1,1): Single MR, Single HA, Single NEMO-Prefix  . . . .  7
     2.2   (1,1,n): Single MR, Single HA, Multiple NEMO-Prefixes  . .  7
     2.3   (1,n,1): Single MR, Multiple HAs, Single NEMO-Prefix . . .  8
     2.4   (1,n,n): Single MR, Multiple HAs, Multiple
           NEMO-Prefixes  . . . . . . . . . . . . . . . . . . . . . .  8
     2.5   (n,1,1): Multiple MRs, Single HA, Single NEMO-Prefix . . .  9
     2.6   (n,1,n): Multiple MRs, Single HA, Multiple
           NEMO-Prefixes  . . . . . . . . . . . . . . . . . . . . . .  9
     2.7   (n,n,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix  . 10
     2.8   (n,n,n): Multiple MRs, Multiple HAs, Multiple
           NEMO-Prefixes  . . . . . . . . . . . . . . . . . . . . . . 11

   3.  Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12
     3.1   Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12
     3.2   Prerequisites  . . . . . . . . . . . . . . . . . . . . . . 13

   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . . 15
     4.1   Path Survival  . . . . . . . . . . . . . . . . . . . . . . 15
     4.2   Path Selection . . . . . . . . . . . . . . . . . . . . . . 15
     4.3   Ingress Filtering  . . . . . . . . . . . . . . . . . . . . 16
     4.4   Failure Detection  . . . . . . . . . . . . . . . . . . . . 17
     4.5   HA Synchronization . . . . . . . . . . . . . . . . . . . . 18
     4.6   MR Synchronization . . . . . . . . . . . . . . . . . . . . 18
     4.7   Prefix Delegation  . . . . . . . . . . . . . . . . . . . . 19
     4.8   Multiple Bindings/Registrations  . . . . . . . . . . . . . 19
     4.9   Source Address Selection . . . . . . . . . . . . . . . . . 19
     4.10  Impact on the Routing Infrastructure . . . . . . . . . . . 20
     4.11  Nested Mobile Networks . . . . . . . . . . . . . . . . . . 20
     4.12  Split Mobile Networks  . . . . . . . . . . . . . . . . . . 20

   5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21

   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21

   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24

   A.  Alternative Classifications Approach . . . . . . . . . . . . . 25
     A.1   Ownership-Oriented Approach  . . . . . . . . . . . . . . . 25
       A.1.1   ISP Model  . . . . . . . . . . . . . . . . . . . . . . 25



Ng, et al.              Expires January 10, 2005                [Page 2]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


       A.1.2   Subscriber/Provider Model  . . . . . . . . . . . . . . 26
     A.2   Problem-Oriented Approach  . . . . . . . . . . . . . . . . 28

   B.  Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 29
     B.1   Detecting Presence of Alternate Routes . . . . . . . . . . 29
     B.2   Re-Establishment of Bi-Directional Tunnels . . . . . . . . 29
       B.2.1   Using Alternate Egress Interface . . . . . . . . . . . 30
       B.2.2   Using Alternate Mobile Router  . . . . . . . . . . . . 30
     B.3   To Avoid Tunneling Loop  . . . . . . . . . . . . . . . . . 31

   C.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32

       Intellectual Property and Copyright Statements . . . . . . . . 33






































Ng, et al.              Expires January 10, 2005                [Page 3]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


1.  Introduction

   The goals and objectives of Network Mobility Support (NEMO) are
   identified in [1] while the terminology is being described in [2] and
   [3].  NEMO Basic Support [4] is the solution proposed by the NEMO
   Working Group to provide continuous Internet connectivity to nodes
   located in a mobile network.  This solutions basically solves the
   problem by setting up bi-directional tunnels between the mobile
   routers (MRs) connecting the mobile network to the Internet and their
   respective Home Agents (HAs), much how this is done in Mobile IPv6
   [5], the solution for host mobility.  NEMO Basic Support is
   transparent to nodes located behind the mobile router (i.e.  the
   mobile network nodes, or MNNs) and as such doesn't require MNNs to
   take any action in the mobility management.

   We note that mobile networks are typically connected by means of
   wireless and thus less reliable links.  In addition, there could be
   many nodes behind the MR, so a loss of connectivity or a failure to
   connect to the Internet has a more significant impact than for a
   single node.  Real-life scenarios as illustrated in [6] demonstrate
   that providing a permanent access to mobile networks such as vehicles
   typically require the use of several interfaces and technologies
   since the mobile network may be moving in distant geographical
   locations where different access technologies are provided and
   governed by distinct access control policies.

   The purpose of this memo is to investigate issues related to such a
   bi-directional tunneling mechanism when mobile networks are
   multihomed, i.e.  when there is more than one point of attachment
   between the mobile network and the Internet.  This arises when the
   mobile network is either associated with multiple HAs, when it has
   multiple MRs, or when an MR has multiple egress interfaces (see
   definitions in [3]).

   As specified by R.12 in section 5 of [1], the NEMO WG must ensure
   that NEMO Basic Support does not prevent mobile networks to be
   multihomed.  Using NEMO Basic Support, this translates into having
   multiple bi-directional tunnels between the mobile network and its
   HA(s), and may result into multiple NEMO-Prefixes being advertised to
   the MNNs.  However, NEMO Basic Support does not specify any
   particular mechanism to manage multiple bi-directional tunnels.  The
   objective of this memo is thus three-folds:

   o  to capture issues for deploying a multihomed mobile network,

   o  to identify which multihoming configurations are useful,

   o  to identify issues that may prevent useful multihomed



Ng, et al.              Expires January 10, 2005                [Page 4]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


      configurations to be supported under the operation of NEMO Basic
      Support.  It doesn't mean that those not supported will not work
      with NEMO Basic Support, just that it is up to the implementors to
      make it work (hopefully issues discussed in this memo will be
      helpful to these implementors).

   For doing so, a taxonomy to classify the possible multihomed
   configurations is described in Section 2.  Deployment scenarios,
   their benefits, and requirements to meet these benefits are
   illustrated in Section 3.  Following this, we study the general
   issues in Section 4, and we conclude with an evaluation of NEMO Basic
   Support for multihomed configurations.  Alternative classifications
   are outlined in the Appendix.

   In order to understand this memo, the reader is expected to be
   familiar with the above cited documents, i.e.  with the NEMO
   terminology as defined in [2] (section 3) and [3], Goals and Benefits
   of Multihoming [6], Goals and Requirements of Network Mobility
   Support [1], and the NEMO Basic Support specification [4].

   Note that goals and benefits for multihoming as discussed in [6] is
   applicable to fixed nodes, mobile nodes, fixed networks and mobile
   networks, so we won't re-state the motivations in the present memo.




























Ng, et al.              Expires January 10, 2005                [Page 5]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


2.  Classification

   Various discussions on the topic of multihoming issues in NEMO have
   been carried out on the mailing list and at IETF meetings.  As there
   are several configurations in which mobile networks are multihomed,
   there is a need to classify them into a clearly defined taxonomy.
   This can be done in various ways.  Three approaches have been
   proposed on the NEMO mailing list.  These are, namely, (i) the
   Configuration-Oriented Approach, (ii) the Ownership-Oriented
   Approach, and (iii) the Problem-Oriented Approach.  As the WG
   consensus seems to have converged to the Configuration-Oriented
   Approach, we only describe this approach here.  The other two
   approaches are outlined in Appendix A.1 and Appendix A.2.

   The Configuration-Oriented Approach

   Multihomed configurations can be classified depending on how many
   mobile routers are present, how many egress interfaces, Care-of
   Address (CoA) and Home Addresses (HoA) the mobile routers have, how
   many prefixes (NEMO-prefixes) are advertised to the mobile network
   nodes, etc.  For doing so, we use three key parameters
   differentiating different multihomed configurations.  With these
   parameters, we can refer to each configuration by the 3-tuple
   (x,y,z), where 'x', 'y', 'z' are defined as follows:

   o  'x' indicates the number of MRs where:

      x=1 implies a mobile network has only a single MR, presumably
         multihomed.

      x=N implies a mobile network has more than one MR.

   o  'y' indicates the number of HAs associated with the entire mobile
      network, where:

      y=1 implies that a single HA is assigned to the mobile network.

      y=N implies that multiple HAs (possibly in different
         administrative domains) are assigned to the mobile network.

   o  'z' indicates the number of NEMO-prefixes announced to MNNs,
      where:

      z=1 implies that a single NEMO-prefix is advertised to the MNNs.

      z=N implies that multiple NEMO-prefixes are advertised to the
         MNNs.




Ng, et al.              Expires January 10, 2005                [Page 6]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   It can be seen that the above three parameters are fairly orthogonal
   to one another.  Thus different values of 'x', 'y' and 'z' give rise
   to different combinations of the 3-tuple (x,y,z).  As described in
   the sub-sections below, a total of 8 possible configurations can be
   identified.

   One thing the reader has to keep in mind is that in each of the
   following 8 cases, the MR may be multihomed if either (i) multiple
   prefixes are advertised on the home link, (ii) multiple prefixes are
   advertised on the visited link, or (iii) the MR is equipped with
   multiple interfaces.  In such a case, the MR would have a combination
   of Home Address / Care-of Address pairs.  Issues pertaining to a
   multihomed MR are also addressed in the companion document [7].

   A simplified analysis of multihoming configuration in NEMO Basic
   Support using the same classification can be found in [8].


2.1  (1,1,1): Single MR, Single HA, Single NEMO-Prefix

   The (1,1,1) mobile network has only one MR advertising a single
   NEMO-prefix.  In addition, the MR is associated with only one HA at
   any one time.  A bi-directional tunnel may be established between
   each pair of Home Address / Care-of address if the MR is itself
   multihomed.

   The MR may be multihomed and MNNs are (usually) not multihomed since
   they would configure a single address on the single NEMO-prefix
   announced on the link they are attached to.

                                   _____
                   _    p      _  |     |
                  |_|-|<-_  |-|_|-|     |-|        _
                   _  |-|_|=|     |_____| |  _  |-|_|
                  |_|-|     |             |-|_|-|
                                                |
                  MNNs   MR   AR  Internet   AR    HA

              Figure 1: (1,1,1): 1 MR, 1 HA, 1 NEMO-prefix


2.2  (1,1,n): Single MR, Single HA, Multiple NEMO-Prefixes

   The (1,1,n) mobile network has only one MR, which is associated to
   only one HA at any one time.  However, two or more NEMO-prefixes are
   advertised to the mobile network nodes.

   The MR may be itself multihomed, and MNNs are multihomed if several



Ng, et al.              Expires January 10, 2005                [Page 7]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   NEMO-Prefixes are advertised on the link they are attached to.  If
   that conditions holds, MNNs would configure an address with each
   NEMO-prefix announced on the link.

                                   _____
                   _   p1,p2   _  |     |
                  |_|-|<-_  |-|_|-|     |-|        _
                   _  |-|_|=|     |_____| |  _  |-|_|
                  |_|-|     |             |-|_|-|
                                                |
                  MNNs   MR   AR  Internet   AR    HA

         Figure 2: (1,1,n): 1 MR, 1 HA, multiple NEMO-prefixes


2.3  (1,n,1): Single MR, Multiple HAs, Single NEMO-Prefix

   The (1,n,1) mobile network has only one MR advertising a single
   NEMO-prefix.  The MR, however, is associated to multiple HAs,
   possibly one HA per Home Address, or one HA per egress interface.  No
   assumption is made on whether or not the HAs belongs to the same
   administrative domain  (it may be justified to locate HAs in distinct
   ISPs according to [Section 5.1.2. Possibly Multihomed, An Identical
   Prefix from a Different Origin] [9])

   The MR may be multihomed whereas MNNs are (usually) not multihomed
   since they would configure a single address on the single NEMO-prefix
   announced on the link they are attached to.

                                          AR    HA2
                                           _  |
                                        |-|_|-|  _
                                 _____  |     |-|_|
                 _    p      _  |     |-|
                |_|-|<-_  |-|_|-|     |
                 _  |-|_|=|     |_____|-|        _
                |_|-|     |             |  _  |-|_|
                                        |-|_|-|
                                              |
                MNNs  MR    AR  Internet  AR    HA1

          Figure 3: (1,n,1): 1 MR, multiple HAs, 1 NEMO-prefix


2.4  (1,n,n): Single MR, Multiple HAs, Multiple NEMO-Prefixes

   The (1,n,n) mobile network has only one MR.  However, the MR is
   associated with multiple HAs, possibly one per Home Address (or one



Ng, et al.              Expires January 10, 2005                [Page 8]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   HA per egress interface), and the MR advertises more than one
   NEMO-prefix on its ingress interfaces.  No assumption is made on
   whether or not the HAs belongs to the same administrative domain.

   The MR may be multihomed, and the MNNs are generally multihomed since
   they would configure an address on each NEMO-prefix announced on the
   link they are attached to.

                                         AR    HA2
                                          _  |  _
                                _____  |-|_|-|-|_|
                _   p1,p2   _  |     |-|     |
               |_|-|<-_  |-|_|-|     |          _
                _  |-|_|=|     |_____|-|  _  |-|_|
               |_|-|     |             |-|_|-|
                                       |     |
               MNNs  MR    AR  Internet  AR    HA1

     Figure 4: (1,n,n): 1 MR, multiple HAs, multiple NEMO-prefixes


2.5  (n,1,1): Multiple MRs, Single HA, Single NEMO-Prefix

   The (n,1,1) mobile network has more than one MR advertising global
   routes.  These MRs, however, advertise the same NEMO-prefix and are
   associated with the same HA.

   Each MR may be itself multihomed, whereas MNNs are (usually) not
   multihomed since they would configure a single address on the single
   NEMO-prefix announced on the link they are attached to.

                        MR2
                      p<-_  |
                   _  |-|_|-|  _____
                  |_|-|     |-|     |
                   _  |       |     |-|        _
                  |_|-|  _  |-|_____| |  _  |-|_|
                      |-|_|-|         |-|_|-|
                      p<-   |               |
                  MNNs  MR1   Internet   AR    HA

          Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 NEMO-prefix


2.6  (n,1,n): Multiple MRs, Single HA, Multiple NEMO-Prefixes

   The (n,1,n) mobile network has more than one MR advertising different
   global routes and different NEMO-prefixes.  However, these MRs are



Ng, et al.              Expires January 10, 2005                [Page 9]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   associated to the same HA.

   Each MR may be itself multihomed, and MNNs are generally multihomed
   since they would configure an address on each NEMO-prefix announced
   on the link they are attached to.

                        MR2
                     p2<-_  |
                   _  |-|_|-|  _____
                  |_|-|     |-|     |
                   _  |       |     |-|        _
                  |_|-|  _  |-|_____| |  _  |-|_|
                      |-|_|-|         |-|_|-|
                     p1<-   |               |
                  MNNs  MR1   Internet   AR    HA

     Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple NEMO-prefixes


2.7  (n,n,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix

   The (n,n,1) mobile network has more than one MR advertising different
   global routes.  The mobile network is associated with multiple HAs at
   any one time.  No assumptions are made on whether or not the HAs
   belongs to the same administrative domain.  However, the MRs
   advertises the same NEMO-prefix.

   Each MR may be itself multihomed whereas MNNs are (usually) not
   multihomed since they would configure a single address on the single
   NEMO-prefix announced on the link they are attached to.

                        MR2             AR    HA2
                        p                _  |
                       <-_  |         |-|_|-|  _
                   _  |-|_|-|  _____  |     |-|_|
                  |_|-|     |-|     |-|
                   _  |       |     |
                  |_|-|  _  |-|_____|-|        _
                      |-|_|-|         |  _  |-|_|
                       <-   |         |-|_|-|
                        p                   |
                  MNNs  MR1   Internet  AR    HA1

      Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 NEMO-prefix







Ng, et al.              Expires January 10, 2005               [Page 10]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


2.8  (n,n,n): Multiple MRs, Multiple HAs, Multiple NEMO-Prefixes

   The (n,n,n) mobile network has multiple MRs advertising different
   global routes and different NEMO-prefixes.  The mobile network is
   associated with more than one HA at any one time.  No assumptions is
   made on whether or not the HA belongs to the same administrative
   domain.

   Each MR may be itself multihomed and MNNs are generally multihomed
   since they would configure an address on each NEMO-prefix announced
   on the link they are attached to

                        MR2             AR    HA2
                        p2               _  |
                       <-_  |         |-|_|-|  _
                   _  |-|_|-|  _____  |     |-|_|
                  |_|-|     |-|     |-|
                   _  |       |     |
                  |_|-|  _  |-|_____|-|        _
                      |-|_|-|         |  _  |-|_|
                       <-   |         |-|_|-|
                        p1                  |
                  MNNs  MR1   Internet  AR    HA1

        Figure 8: (n,n,n): Multiple MRs, HAs, and NEMO-prefixes


























Ng, et al.              Expires January 10, 2005               [Page 11]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


3.  Deployment Scenarios and Prerequisites

   The following generic goals and benefits of multihoming are discussed
   in a companion document [6]:

   1.  Permanent and Ubiquitous Access

   2.  Redundancy/Fault-Recovery

   3.  Load Sharing

   4.  Load Balancing

   5.  Preference Settings

   These benefits are now illustrated from a NEMO perspective with a
   typical instance scenario for each case in the taxonomy.  We then
   discuss the prerequisites to fulfill these.

3.1  Deployment Scenarios

   x=1: Multihomed mobile network with a single MR

      o  Example: an MR with dual/multiple access interfaces (e.g.
         802.11 and GPRS capabilities).  This is a S/P-(1,1,*) if both
         accesses are subscribed to the same ISP.  If the two accesses
         are offered by independent ISPs, this is a S/mP-(1,n,n) [for
         the meaning of this abbreviation, see Appendix A.1].

         Benefits: Ubiquity, Redundancy/Fault-Recovery


   x=N:  Multihomed mobile networks with multiple MRs

      o  Example 1: a train with one MR in each car, all served by the
         same HA, thus a (n,1,*).  Alternatively, the train company
         might be forced to use different ISP when the train go to
         different locations, thus it is a (n,n,n).

         Benefits: Load Sharing

      o  Example 2: W-PAN with a GPRS_enabled phone and a WiFi-enabled
         PDA.  This is a S/mP-(n,n,n) if the two access technologies are
         subscribed separately.

         Benefits: Ubiquity, Redundancy/Fault-Recovery





Ng, et al.              Expires January 10, 2005               [Page 12]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   y=1:  Multihomed mobile networks with a single HA

      o  Most single ISP cases in above examples.


   y=N:  Multihomed mobile networks with multiple HAs

      o  Most multiple ISP cases in above examples.

      o  Example: a transatlantic flight with a HA in each continent.
         This is a (1,n,1) network if there is only one MR.

         Benefits: Ubiquity (reduced delay, shortest path)


   z=1:  Multihomed mobile networks with a single NEMO-prefix

      o  Most single ISP cases in above examples.


   z=N:  Multihomed mobile networks with multiple NEMO-prefixes

      o  Most multiple ISP cases in above examples.

      o  Example: a car with a prefix taken from home (personal traffic
         transit on this prefix and is paid by the owner) and one that
         belongs to the car manufacturer (maintenance traffic is paid by
         the car-manufacturer).  This will typically be a (1,1,n).

         Benefits: preference settings


3.2  Prerequisites

   In this section, we try to define the requirements in order to
   fulfill the expected multihoming benefits as detailed in [6].

   At least one bi-directional tunnel must be available at any point in
   time between the mobile network and the fixed network to meet all
   expectations.  But for most goals to be effective, multiple tunnels
   must be maintained simultaneously:

   o  Permanent and Ubiquitous Access:

      At least one bi-directional tunnel must be available at any point
      in time.

   o  Redundancy and Fault-Recovery:



Ng, et al.              Expires January 10, 2005               [Page 13]


      Both the inbound and outbound traffic must be transmitted or
      diverted over another bi-directional tunnel once a bi-directional
      tunnel is broken or disrupted.

   o  Load Sharing and Load Balancing:

      Multiple tunnels must be maintained simultaneously.

   o  Preference Settings:

      A mechanism must be provided to the user or the application to
      decide which of the available bi-directional tunnel should be
      used.








































Ng, et al.              Expires January 10, 2005               [Page 14]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


4.  Problem Statement

   In order to reach the multihoming benefits, multiple tunnels may be
   maintained simultaneously (e.g.  load balancing, load sharing) or not
   (e.g.  redundancy) between the mobile network and the fixed network.
   In some cases, it may be necessary to divert packets from a (perhaps
   failed) bi-directional tunnel to an alternative (perhaps newly
   established) bi-directional tunnel (i.e.  for matters of fault
   recovery, preferences), or to split traffic between multiple tunnel
   (load sharing, load balancing).

   For doing so, the issues discussed below must be addressed,
   preferably dynamically.  For each issue, we also investigate
   potential ways to solve the problem.

4.1  Path Survival

   Internet connectivity is guaranteed for all MNNs as long as at least
   one bi-directional tunnel is maintained between the mobile network
   and the fixed Internet.  When an alternative tunnel must be found to
   substitute for the failed one, the loss of one tunnel to the Internet
   may result in broken sessions.  In this case, new transport sessions
   will have to be established over the alternate tunnel if no mechanism
   is provided to make this change transparent at layers above layer 3.

   In the (1,1,1) case specifically, packets are always transmitted to/
   from the same MR's ingress interface, i.e.  independently of MR's
   links connectivity status.  The tunnel can be changed transparently
   to the MNNs if mechanisms such as those studied in [10] are brought
   to the MR.

4.2  Path Selection

   When multiple bi-directional tunnels are available and possibly used
   simultaneously, the mode of operation may be either primary-secondary
   (one tunnel is precedent over the others and used as the default
   tunnel, while the other serves as a back-up) or peer-to-peer (no
   tunnel has precedence over one another, they are used with the same
   priority).  This questions which bi-directional tunnel would be
   selected, and based on which parameter (e.g.  type of flow that goes
   into/out of the mobile network).

   A dynamic path selection mechanism is thus needed so that this path
   could be selected by:

   o  The HA: it should be able to select the path based on some
      information recorded in the binding cache.




Ng, et al.              Expires January 10, 2005               [Page 15]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   o  The MR: it should be able to select the path based on router
      advertisements received on both its egress interfaces or on its
      ingress interfaces for the (n,*,*) case.

   o  The MNN: it should be able to select the path based on "Default
      Router Selection" (see [Section 6.3.6. Default Router Selection]
      [11]) in the (n,*,*) case or based on "Source Address Selection"
      in the (*,*,n) cases (see Section 4.9 of the present memo).

   o  The user or the application: e.g.  in case where a user wants to
      select a particular access technology among the available
      technologies for reasons of cost or data rate.

   o  A combination of any of the above: a hybrid mechanism should be
      also available, e.g.  one in which the HA, the MR, and/or the MNNs
      are coordinated to select the path.


4.3  Ingress Filtering

   Ingress filtering mechanisms may drop the outgoing packets when
   multiple bi-directional tunnels end up at different HAs.

   This could occur when different NEMO-prefixes are handled by
   different HAs such as the one illustrated in Figure 9.  In Figure 9,
   the mobile network has two mobile routers MR1 and MR2, with home
   agents HA1 and HA2 respectively.  Two bi-directional tunnels are
   established are established between the two pairs.  Each mobile
   router advertises a different NEMO-prefix (P1 and P2).  NEMO-prefix
   P1 is registered to HA1, and NEMO-prefix P2 is registered to HA2.
   Thus, MNNs should be free to auto-configure their addresses on any of
   P1 or P2.  Ingress filtering could thus happen in two cases:

   o  If the two tunnels are available, MNN cannot forward packet with
      source address equals P1.MNN to MR2.  This would cause ingress
      filtering at HA2 to occur (or even at MR2).  This is contrary to
      normal Neighbor Discovery [11] practice that an IPv6 node is free
      to choose any router as its default router regardless of the
      prefix it chooses to use.  A simple solution is to require all
      MNNs to set their default router to the MR that advertises the
      NEMO-prefix the MNNs configured their addresses from.  If such
      requirement is not placed on mobile network nodes, then a
      multihoming solution for mobile networks must address this
      problem.  For a possible approach, see [12].  However, this is not
      enough to maintain connectivity if a tunnel fails (see Section 4.1
      for a discussion of this issue).

   o  If the tunnel to HA1 is broken, packets would be sent through the



Ng, et al.              Expires January 10, 2005               [Page 16]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


      tunnel to HA1 are diverted through the tunnel to HA2.  If HA2 (or
      some border gateway in the domain of HA2) performs ingress
      filtering, packets with source address configured from NEMO-Prefix
      P1 may be discarded.  It should be noted that this problem may be
      faced by any (*,n,n) mobile network, even if MR1 and MR2 are in
      fact the same entity in Figure 9.

   To avoid ingress filtering mechanisms dropping packets in such
   situations, MR(s) can stop advertising P1.  This would prevent MNNs
   from using the address auto-configured on this prefix.  However, such
   a method suffers from the following two limitations:

   o  Switching addresses is time consuming since nodes have to wait for
      addresses to get deprecated [13].

   o  Switching addresses force transport sessions without multihoming
      capabilities (such as TCP) to terminate, and be re-established
      using the alternative source address.  Transport sessions with
      multihoming capabilities (such as SCTP) may be able to continue
      without disruption (see also Section 4.1)

   It is possible to overcome these limitations by using nested tunnels.
   Appendix B describes one such approach.

               Prefix: P1 +-----+  +----+  +----------+   +-----+
                       +--| MR1 |--| AR |--|          |---| HA1 |
                       |  +-----+  +----+  |          |   +-----+
       IP:    +-----+  |                   |          | Prefix: P1
    P1.MNN or | MNN |--+                   | Internet |
      P2.MNN  +-----+  |                   |          | Prefix: P2
                       |  +-----+  +----+  |          |   +-----+
                       +--| MR2 |--| AR |--|          |---| HA2 |
               Prefix: P2 +-----+  +----+  +----------+   +-----+

                  Figure 9: An (n,n,n) mobile network


4.4  Failure Detection

   It is expected for faults to occur more readily at the edge of the
   network (i.e.  the mobile nodes), due to the use of wireless
   connections.  Efficient fault detection mechanisms are necessary to
   recover in timely fashion.  In order for fault recovery to work, the
   MRs and HAs must first possess a means to detect failures:

   o  On the MR's side, the MR can also rely on router advertisements
      from access routers, or other layer-2 trigger mechanisms to detect
      faults (e.g.  [14] or [15]) .



Ng, et al.              Expires January 10, 2005               [Page 17]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   o  On the HA's side, it is more difficult for HAs to detect tunnel
      failures.  For an ISP deployment model, the HAs and MRs can use
      proprietary methods (such as constant transmission of heartbeat
      signals) to detect failures and check tunnel liveness.  In the S/P
      model (see Appendix A.2), a lack of standardized "tunnel liveness"
      protocol means that it is harder to detect failures.

      A possible method is for the MRs to send binding updates more
      regularly with shorter Lifetime values.  Similarly, HAs can return
      binding acknowledgment messages with smaller Lifetime values, thus
      forcing the MRs to send binding updates more frequently.  These
      binding updates can be used to emulate "tunnel heartbeats".  This
      however may lead to more traffic and processing overhead, since
      binding updates sent to HAs must be protected (and possibly
      encrypted) with security associations.


4.5  HA Synchronization

   In the (*,n,1) mobile networks, a single NEMO-prefix would be
   registered at different HAs.  This gives rise to the following
   issues:

   o  Only one HA may actively advertise a route to the NEMO-prefix.

   o  Multiple HAs at different domains may advertise a route to the
      same NEMO-prefix

   This may pose a problem in the routing infrastructure as a whole.
   The implications of this aspect needs further exploration.  Certain
   level of HA co-ordination may be required.  A possible approach is to
   adopt a HA synchronization mechanism such as that described in [16]
   and [17].  Such synchronization might also be necessary in a (*,n,*)
   mobile network, when a MR sends binding update messages to only one
   HA (instead of all HAs).  In such cases, the binding update
   information might have to be synchronized betweeen HAs.  The mode of
   synchoronization may be either primary-secondary or peer-to-peer.
   See also Section 4.6.

4.6  MR Synchronization

   In the (n,*,*) mobile network, different MRs may need to be
   synchronized in order to take common decisions.  The mode of
   synchoronization may be either primary-secondary or peer-to-peer.
   This may include:

   o  In the (n,*,1) case, advertising the same NEMO-Prefix (see also
      "prefix delegation" in Section 4.7).



Ng, et al.              Expires January 10, 2005               [Page 18]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   o  In the (n,*,n) case, a MR relaying the advertisement of the
      NEMO-Prefix from another failed MR.

   o  In the (n,*,*) cases, relaying between MRs everything that needs
      to be relayed, such as data packets, creating a tunnel from the
      ingress interface, etc.


4.7  Prefix Delegation

   In the (*,*,1) mobile network, the same NEMO-prefix must be
   advertised to the MNNs through different paths.  This questions how
   to perform prefix delegation:

   o  For the (*,n,1) mobile network, how multiple HAs would delegate
      the same NEMO-prefix to the mobile network.  For doing so, the HAs
      may be somehow configured to advertise the same NEMO-prefix.  (see
      also "HA Synchronization" in Section 4.5).

   o  For the (n,*,n) mobile network, how multiple mobile routers would
      be synchronized to advertise the same NEMO-Prefix down the
      NEMO-link.  For doing so, the MRs may be somehow configured to
      advertise the same NEMO-prefix (see also "MR Synchronization" in
      Section 4.6).

   This could be configured manually, or dynamically.  Alternatively,
   prefix delegation mechanisms [18][19] could be used to ensure all
   routers advertise the same NEMO-prefix.

4.8  Multiple Bindings/Registrations

   When a MR is configured with multiple Care-of Addresses, it is often
   necessary for it to bind these Care-of Addresses to the same
   NEMO-Prefix.

   This is a generic issue, since Mobile IPv6 nodes face a similar
   problem if they wish to bind multiple Care-of Addresses to the same
   Home Address".  This is better discussed in [7].  It is sufficient to
   note that solutions like [20] can solve this.

4.9  Source Address Selection

   In the (*,*,n) mobile networks, MNNs would be configured with
   multiple addresses.  Source address selection mechanisms are needed
   to decide which address to choose from.

   It may be desirable for MNN to be able to acquire "preference"
   information on each NEMO-prefix from the MRs.  This allows default



Ng, et al.              Expires January 10, 2005               [Page 19]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   address selection mechanism such as that specified in [13] to be
   used.  Further exploration on setting such "preference" information
   in Router Advertisement based on performance of the bi-directional
   tunnel might prove to be useful.

4.10  Impact on the Routing Infrastructure

   In the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple
   routes directed to the mobile network may be advertised in the
   Internet.  This may provide shorter paths, but this would add a
   burden in routing tables as the route would be published in the
   Internet Router Registry for multiple ASs.  Such issues are
   investigated in the MULTI6 working group at the IETF.

4.11  Nested Mobile Networks

   When a multihomed mobile network is nested within another mobile
   network, it can result in very complex topologies.  For instance, a
   nested mobile network may be attached two different root-MRs, thus
   the aggregated network no longer forms a simple tree structure.  As
   such, a solution to prevent an infinite loop must be provided.

4.12  Split Mobile Networks

   When a (n,*,1) network splits, (i.e.  the two MRs split themselves
   up), the only available NEMO-prefix will then be registered by two
   different MRs on different links.  This cannot be allowed, as the HA
   has no way to know which node with an address configured from that
   NEMO-prefix is attached to which MR.  Some mechanism must be present
   for the NEMO-prefix to either be forcibly removed from one (or all)
   MRs, or the implementors must not allow a (n,*,1) network to split.

   A possible approach to solving this problem is described in [21].


















Ng, et al.              Expires January 10, 2005               [Page 20]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


5.  Conclusion

   This document is an analysis of multihoming in the context of network
   mobility.  The purpose of this memo is to investigate issues related
   to such a bi-directional tunneling mechanism when mobile networks are
   multihomed.

   Several issues that might impact the deployment of NEMO with
   multihoming capabilities were identified in Section 4.  They include:

   1.  Path Survival

   2.  Path Availability

   3.  Ingress Filtering

   4.  Failure Detection

   5.  HA Synchronization

   6.  MR Synchronization

   7.  Prefix Delegation

   8.  Multiple Binding/Registrations

   9.  Source Address Selection

   10.  Imapct on the Routing Infrastructure

   11.  Nested Mobile Networks

   12.  Split Mobile Networks.

   This study is a work in progress and need to be improved by a
   thorough study of each individual issues.  Particularly, this memo
   should be completed by a thorough threat analysis of multihoming
   configurations of mobile network.  We will add security threat issues
   here as and when they are encountered, such as those described in
   [22].  We also encourage interested people to contribute to this
   part.


6.  Acknowledgments

   The authors would like to thank people who have given valuable
   comments on various multihoming issues on the mailing list, and also
   those who have suggested directions in the 56th - 59th IETF Meetings.



Ng, et al.              Expires January 10, 2005               [Page 21]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   The initial evaluation of NEMO Basic Support is a contribution from
   Julien Charbon.


7  References

   [1]   Ernst, T., "Network Mobility Support Goals and Requirements",
         draft-ietf-nemo-requirements-02 (work in progress), February
         2004.

   [2]   Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
         3753, June 2004.

   [3]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         draft-ietf-nemo-terminology-01 (work in progress), February
         2004.

   [4]   Devarapalli, V., "Network Mobility (NEMO) Basic Support
         Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
         June 2004.

   [5]   Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [6]   Ernst, T., "Goals and Benefits of Multihoming",
         draft-multihoming-generic-goals-and-benefits-00 (work in
         progress), February 2004.

   [7]   Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of
         Multihoming in Mobile IPv6",
         draft-montavont-mobileip-multihoming-pb-statement-01 (work in
         progress), Feb 2004.

   [8]   Ernst, T. and J. Charbon, "Multihoming with NEMO Basic
         Support", Proceedings First International Conference on Mobile
         Computing and Ubiquitous Networking (ICMU), January 2004.

   [9]   Savola, P., "Examining Site Multi-homing in Finnish Networks",
         Master's Thesis. , April 2003.

   [10]  Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for
         Multiple Interfaces", draft-montavont-mobileip-mmi-00 (work in
         progress), July 2002.

   [11]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [12]  Draves, R. and D. Thaler, "Default Router Preferences and



Ng, et al.              Expires January 10, 2005               [Page 22]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


         More-Specific Routes", draft-ietf-ipv6-router-selection-04
         (work in progress), June 2004.

   [13]  Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [14]  Yegin, A., "Link-layer Hints for Detecting Network
         Attachments", draft-yegin-dna-l2-hints-01 (work in progress),
         February 2004.

   [15]  Yegin, A., "Supporting Optimized Handover for IP Mobility
         -Requirements for Underlying  Systems",
         draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002.

   [16]  Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home
         Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work
         in progress), February 2004.

   [17]  Koh, B., Ng, C. and J. Hirano, "Dynamic Inter Home Agent
         Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), July
         2004.

   [18]  Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
         Delegation", RFC 3769, June 2004.

   [19]  Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
         draft-droms-nemo-dhcpv6-pd-01 (work in progress), February
         2004.

   [20]  Wakikawa, R., "Multiple Care-of Addresses Registration",
         draft-wakikawa-mobileip-multiplecoa-02 (work in progress),
         September 2003.

   [21]  Kumazawa, M., Watanabe, Y., Matsumoto, T. and S. Narayana,
         "Token based Duplicate Network Detection for split mobile
         network (Token based DND)", draft-kumazawa-nemo-tbdnd-00 (work
         in progress), July 2004.

   [22]  Choi, S., "Threat for Multi-homed Mobile Networks",
         draft-cho-nemo-threat-multihoming-00 (work in progress),
         February 2004.










Ng, et al.              Expires January 10, 2005               [Page 23]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


Authors' Addresses

   Chan-Wah Ng
   Panasonic Singapore Laboratories Pte Ltd
   Blk 1022 Tai Seng Ave #06-3530
   Tai Seng Industrial Estate
   Singapore  534415
   SG

   Phone: +65 65505420
   EMail: cwng@psl.com.sg


   Paik, Eun Kyoung
   Seoul National University
   Multimedia and Mobile communications Lab., Seoul National Univ.
   Shillim-dong, Kwanak-gu
   Seoul  151-744
   Korea

   Phone: +82-2-880-1832
   Fax:   +82-2-872-2045
   EMail: eun@mmlab.snu.ac.kr
   URI:   http://mmlab.snu.ac.kr/~eun/


   Ernst Thierry
   WIDE at Keio University
   Jun Murai Lab., Keio University.
   K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
   Kawasaki, Kanagawa  212-0054
   Japan

   Phone: +81-44-580-1600
   Fax:   +81-44-580-1437
   EMail: ernst@sfc.wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~ernst/














Ng, et al.              Expires January 10, 2005               [Page 24]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


Appendix A.  Alternative Classifications Approach

A.1  Ownership-Oriented Approach

   An alternative approach to classifying multihomed mobile network is
   proposed by Eric Nordmark (Sun Microsystems) by breaking the
   classification of multihomed network based on ownership.  This is
   more of a tree-like top-down classification.  Starting from the
   control and ownership of the HA(s) and MR(s), there are two different
   possibilities: either (i) the HA(s) and MR(s) are controlled by a
   single entity, or (ii) the HA(s) and MR(s) are controlled by separate
   entities.  We called the first possibility the 'ISP Model', and the
   second the 'Subscriber/Provider Model'.

A.1.1  ISP Model

   The case of the HA(s) and MR(s) are controlled by the same entity can
   be best illustrated as an Internet Service Provider (ISP) installing
   mobile routers on trains, ships or planes.  It is up to the ISP to
   deploy a certain configuration of mobile network; all 8
   configurations as described in the Configuration-Oriented Approach
   are possible.  In the remaining portion of this document, when
   specifically referring to a mobile network configuration that is
   controlled by a single entity, we will add an 'ISP' prefix: for
   example: ISP-(1,1,1) or ISP-(1,N,N).

   When the HA(s) and MR(s) are controlled by a single entity (such as
   an ISP), the ISP can decide whether it wants to assign one or
   multiple NEMO-prefixes to the mobile network just like it can make
   the same decision for any other link in its network (wired or
   otherwise).  In any case, the ISP will make the routing between the
   mobile networks and its core routers (such as the HAs) work.  This
   include not introducing any aggregation between the HAs which will
   filter out routing announcements for the NEMO-prefix(es).

   To such ends, the ISP has various means and mechanisms.  For one, the
   ISP can run its Interior Gateway Protocol (IGP) over bi-directional
   tunnels between the MR(s) and HA(s).  Alternatively, static routes
   may be used with the tunnels.  When static routes are used, a
   mechanism  to test "tunnel liveness" might be necessary to avoid
   maintaining stale routes.  Such "tunnel liveness" may be tested by
   sending heartbeats signals from MR(s) to the HA(s).  A possibility is
   to simulate heartbeats using Binding Updates messages by controlling
   the "Lifetime" field of the Binding Acknowledgment message to force
   the MR to send Binding Update messages at regular interval.  However,
   a more appropriate tool might be the Binding Refresh Request message,
   though conformance to the Binding Refresh Request message may be less
   strictly enforced in implementations since it serves a somewhat



Ng, et al.              Expires January 10, 2005               [Page 25]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   secondary role when compared to Binding Update messages.

A.1.2  Subscriber/Provider Model

   The case of the HA(s) and MR(s) are controlled by the separate
   entities can be best illustrated with a subscriber/provider model,
   where the MRs belongs to a single subscriber and subscribes to one or
   more ISPs for HA services.  There is two sub-categories in this case:
   when the subscriber subscribes to a single ISP, and when the
   subscriber subscribes to multiple ISPs.  In the remaining portion of
   this document, when specifically referring to a mobile network
   configuration that is in the subscriber/provider model where the
   subscriber subscribes to only one ISP, we will add an 'S/P' prefix:
   for example: S/P-(1,1,1) or S/P-(1,n,n).  When specifically referring
   to a mobile network configuration that is in the subscriber/provider
   model where the subscriber subscribes to multiple ISPs, we will add
   an 'S/mP' prefix: for example: S/mP-(1,1,1) or S/mP-(1,n,n).

   Not all 8 configurations are likely to be deployed for the S/P and S/
   mP models.  For instance, it is unlikely to foresee a S/mP-(*,1,1)
   mobile network where there is only a single HA.  For the S/P model,
   the following configurations are likely to be deployed:

   o  S/P-(1,1,1): Single Provider, Single MR, Single HA, Single
      NEMO-Prefix

   o  S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple
      NEMO-Prefixes

   o  S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single
      NEMO-Prefix

   o  S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple
      NEMO-Prefixes

   o  S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single
      NEMO-Prefix

   o  S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple
      NEMO-Prefixes

   o  S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single
      NEMO-Prefix

   o  S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple
      NEMO-Prefixes





Ng, et al.              Expires January 10, 2005               [Page 26]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   For the S/mP model, the following configurations are likely to be
   deployed:

   o  S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single
      NEMO-Prefix

   o  S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs,
      Multiple NEMO-Prefixes

   o  S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs,
      Multiple NEMO-Prefixes

   When the HA(s) and MR(s) are controlled by different entities, it is
   more likely the scenario where the MR is controlled by one entity
   (i.e.  the subscriber), and the MR is establishing multiple
   bi-directional tunnels to one or more HA(s) provided by one or more
   ISP(s).  In such case, it is unlikely for the ISP to run IGP over the
   bi-directional tunnel, since ISP would most certainly wish to retain
   full control of its routing domain.
































Ng, et al.              Expires January 10, 2005               [Page 27]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


A.2  Problem-Oriented Approach

   A third approach is proposed by Pascal Thubert (Cisco System).  This
   focused on the problems of multihomed mobile networks rather than the
   configuration or ownership.  With this approach, there is a set of 4
   categories based on two orthogonal parameters: the number of HAs, and
   the number of NEMO-prefixes advertised.  Since the two parameters are
   orthogonal, the categories are not mutually exclusive.  The four
   categories are:

   o  Tarzan: Single HA for Different Care-of Addresses of Same
      NEMO-Prefix

      This is the case where one mobile router registers different
      Care-of Addresses to the same home agent for the same subnet
      prefix.  This is equivalent to the case of y=1, i.e.  the (1,1,n)
      mobile network.

   o  JetSet: Multiple HAs for Different Care-of Addresses of Same
      NEMO-Prefix

      This is the case where the mobile router registers different
      Care-of Addresses to different home agents for the same subnet
      prefix.  This is equivalent to the case of y=n, i.e.  the (1,n,*)
      mobile network.

   o  Shinkansen: Single NEMO-Prefix Advertised by MR(s)

      This is the case where one NEMO-prefix is announced by different
      MRs.  This is equivalent to the case of z=n, i.e.  the (1,*,n)
      mobile network.

   o  DoubleBed: Multiple NEMO-Prefixes Advertised by MR(s)

      This is the case where more than one NEMO-prefixes are announced
      by the different MRs.  This is equivalent to the case of z=n, i.e.
      the (n,*,n) mobile network.














Ng, et al.              Expires January 10, 2005               [Page 28]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


Appendix B.  Nested Tunneling for Fault Tolerance

   In order to utilize the additional robustness provided by
   multihoming, MRs that employ bi-directional tunneling with their HAs
   should dynamically change their tunnel exit points depending on the
   link status.  For instance, if a MR detects that one of its egress
   interface is down, it should detect if any other alternate route to
   the global Internet exists.  This alternate route may be provided by
   any other MRs connected to one of its ingress interfaces that has an
   independent route to the global Internet, or by another active egress
   interface the MR itself possess.  If such an alternate route exists,
   the MR should re-establish the bi-directional tunnel using this
   alternate route.

   In the remaining part of this section, we will attempt to investigate
   methods of performing such re-establishment of bi-directional
   tunnels.  It is not the objective of this memo to specify a new
   protocol specifically tailored to provide this form of re-
   establishments.  Instead, we will limit ourselves to currently
   available mechanisms specified in Mobile IPv6 [5] and Neighbor
   Discovery in IPv6 [11].

B.1  Detecting Presence of Alternate Routes

   To actively utilize the robustness provided by multihoming, a MR must
   first be capable of detecting alternate routes.  This can be manually
   configured into the MR by the administrators if the configuration of
   the mobile network is relatively static.  It is however highly
   desirable for MRs to be able to discover alternate routes
   automatically for greater flexibility.

   The case where a MR possesses multiple egress interface (bound to the
   same HA or otherwise) should be trivial, since the MR should be able
   to "realize" it has multiple routes to the global Internet.

   In the case where multiple MRs are on the mobile network, each MR has
   to detect the presence of other MR.  A MR can do so by listening for
   Router Advertisement message on its *ingress* interfaces.  When a MR
   receives a Router Advertisement message with a non-zero Router
   Lifetime field from one of its ingress interfaces, it knows that
   another MR which can provide an alternate route to the global
   Internet is present in the mobile network.

B.2  Re-Establishment of Bi-Directional Tunnels

   When a MR detects that the link be which its current bi-directional
   tunnel with its HA is using is down, it needs to re-establish the
   bi-directional tunnel using an alternate route detected.  We consider



Ng, et al.              Expires January 10, 2005               [Page 29]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


   two separate cases here: firstly, the alternate route is provided by
   another egress interface that belongs to the MR; secondly, the
   alternate route is provided by another MR connected to the mobile
   network.  We refer to the former case as an alternate route provided
   by an alternate egress interface, and the latter case as an alternate
   route provided by an alternate MR.

B.2.1  Using Alternate Egress Interface

   When an egress interface of a MR loses the connection to the global
   Internet, the MR can make use of its alternate egress interface
   should it possess multiple egress interfaces.  The most direct way to
   do so is for the mobile router to send a binding update to the home
   agent of the failed interface using the Care-of Address assigned to
   the alternate interface in order to re-establish the bi-directional
   tunneling using the Care-of Address on the alternate egress
   interface.  After a successful binding update, the MR encapsulates
   outgoing packets through the bi-directional tunnel using the
   alternate egress interface.

   The idea is to use the global address (most likely a Care-of Address)
   assigned to an alternate egress interface as the new (back-up)
   Care-of Address of the mobile router to re-establish the
   bi-directional tunneling with its home agent.

B.2.2  Using Alternate Mobile Router

   When the MR loses a connection to the global Internet, the MR can
   utilize a route provided by an alternate MR (if one exists) to
   re-establish the bi-directional tunnel with its HA.  First, the MR
   has to obtain a Care-of Address from the alternate MR (i.e.  attaches
   itself to the alternate MR).  Next, it sends binding update to its HA
   using the Care-of Address obtained from the alternate MR.  From then
   on, the MR can encapsulates outgoing packets through the
   bi-directional tunnel using via the alternate MR.

   The idea is to obtain a Care-of Address from the alternate MR and use
   this as the new (back-up) Care-of Address of the MR to re-establish
   the bi-directional tunneling with its HA.

   Note that every packet sent between MNNs and their correspondent
   nodes will experience two levels of encapsulation.  First level of
   tunneling occurs between a MR which the MNN uses as its default
   router and the MR's HA.  The second level of tunneling occurs between
   the alternate MR and its HA.






Ng, et al.              Expires January 10, 2005               [Page 30]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


B.3  To Avoid Tunneling Loop

   The method of re-establishing the bi-directional tunnel as described
   in Appendix B.2 may lead to infinite loops of tunneling.  This
   happens when two MRs on a mobile network lose connection to the
   global Internet at the same time and each MR tries to re-establish
   bi-directional tunnel using the other MR.  We refer to this
   phenomenon as tunneling loop.

   One approach to avoid tunneling loop is for a MR that has lost
   connection to the global Internet to insert an option into the Router
   Advertisement message it broadcasts periodically.  This option serves
   to notify other MRs on the link that the sender no longer provides
   global connection.  Note that setting a zero Router Lifetime field
   will not work well since it will cause MNNs that are attached to the
   MR to stop using the MR as their default router too  (in which case,
   things are back to square one).


































Ng, et al.              Expires January 10, 2005               [Page 31]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


Appendix C.  Change Log

   o  This draft is an update of draft-ng-nemo-multihoming-issues-03.txt
      which is itself a merge of 3 previous drafts
      draft-ng-nemo-multihoming-issues-02.txt,
      draft-eun-nemo-multihoming-problem-statement-00.txt, and
      draft-charbon-nemo-multihoming-evaluation-00.txt

   o  Changes from draft-ng-multihoming-issues-03 to
      draft-ietf-nemo-multihoming-issues-00:

      *  Expanded "Problem Statement" (Section 4)

      *  Merged "Evaluation" Section into "Problem Statement" (Section
         4)

      *  Cleaned up description in "Classification" (Section 2), and
         clearly indicate in each classification, what are the
         multihomed entities

      *  Re-organized "Deployment Scenarios and Prerequisites" (Section
         3), and created the "Prerequisites" sub-section.

   o  Changes from draft-ng-multihoming-issues-02 to
      draft-ng-multihoming-issues-03:

      *  Merged with draft-eun-nemo-multihoming-problem-statement (see
         "Problem Statement" (Section 4))

      *  Included conclusions from
         draft-charbon-nemo-multihoming-evaluation-00

      *  Re-organized some part of "Benefits/Issues of Multhoming in
         NEMO" to "Problem Statement" (Section 4)

      *  Removed lots of text to be in sync with [6].

      *  Title changed from "Multihoming Issues in NEMO Basic Support"
         to "Analysis of Multihoming in NEMO"

      *  Changed (w,x,y) to (x,y,z) in taxonomy.

      *  Moved alternative approaches of classification to Appendix

      *  Creation of this Change-Log itself ;-)






Ng, et al.              Expires January 10, 2005               [Page 32]


Internet-Draft      Analysis of Multihoming in NEMO            July 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Ng, et al.              Expires January 10, 2005               [Page 33]