[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

NEMO Working Group                                                 C. Ng
Internet-Draft                                  Panasonic Singapore Labs
Expires: April 16, 2004                                       J. Charbon
                                       Keio and Louis Pasteur University
                                                                 E. Paik
                                               Seoul National University
                                                        October 17, 2003


             Multihoming Issues in Network Mobility Support
                  draft-ng-nemo-multihoming-issues-02

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 16, 2004.

Copyright Notice

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

Abstract

   This document describes deployment scenario of multihomed mobile
   network and attempts to identify issues that arises when supporting
   multihoming in Network Mobility Support (NEMO. It is also the
   objective of this document to build a full taxonomy covering
   multihomed scenarios in NEMO, and to identify different cases of
   multihomed scenario that is supported by NEMO Basic Support [1].






Ng, et al.               Expires April 16, 2004                 [Page 1]


Internet-Draft         Multihoming Issues in NEMO           October 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Motivations  . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2   Objectives . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3   Organization . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.4   Terms and Abbreviation . . . . . . . . . . . . . . . . . . .  4

   2.    Classification . . . . . . . . . . . . . . . . . . . . . . .  5
   2.1   Configuration-Oriented Approach  . . . . . . . . . . . . . .  5
   2.1.1 (1,1,1): Single MR, Single HA, Single Prefix . . . . . . . .  6
   2.1.2 (1,1,N): Single MR, Single HA, Multiple Prefixes . . . . . .  7
   2.1.3 (1,N,1): Single MR, Multiple HAs, Single Prefix  . . . . . .  7
   2.1.4 (1,N,N): Single MR, Multiple HAs, Multiple Prefixes  . . . .  8
   2.1.5 (N,1,1): Multiple MRs, Single HA, Single Prefix  . . . . . .  9
   2.1.6 (N,1,N): Multiple MRs, Single HA, Multiple Prefixes  . . . .  9
   2.1.7 (N,N,1): Multiple MRs, Multiple HAs, Single Prefix . . . . . 10
   2.1.8 (N,N,N): Multiple MRs, Multiple HAs, Multiple Prefixes . . . 11
   2.2   Ownership-Oriented Approach  . . . . . . . . . . . . . . . . 11
   2.3   Problem-Oriented Approach  . . . . . . . . . . . . . . . . . 13

   3.    Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 15

   4.    Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   4.1   Benefits/Issues of Multihoming in NEMO . . . . . . . . . . . 17
   4.1.1 Fault Tolerance  . . . . . . . . . . . . . . . . . . . . . . 17
   4.1.2 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . 19
   4.2   Ownership-Oriented Approach  . . . . . . . . . . . . . . . . 20
   4.3   Configuration-Oriented Approach  . . . . . . . . . . . . . . 21

   5.    Security Considerations  . . . . . . . . . . . . . . . . . . 26

   6.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 26

         References . . . . . . . . . . . . . . . . . . . . . . . . . 26

         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27

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

         Intellectual Property and Copyright Statements . . . . . . . 31




Ng, et al.               Expires April 16, 2004                 [Page 2]


Internet-Draft         Multihoming Issues in NEMO           October 2003


1. Introduction

1.1 Motivations

   The problem of Network Mobility Support (NEMO) is identified in
   various previous works [2]. In essence, the problem of network in
   motion is to provide continuous Internet connectivity to nodes in a
   network that moves as a whole.  Nodes within the network that moves
   may not be aware of the network changing its point of attachment to
   the Internet.  This differs from the traditional problem of mobility
   support as addressed by Mobile IPv6 [3].

   In Mobile IP, each mobile node has a permanent home domain.  When the
   mobile node is attached to its home network, it is assigned a
   permanent global address known as a home-address (HoA).  When the
   mobile node is away, i.e. attached to some other foreign networks, it
   is usually assigned a temporary global address known as a
   care-of-address (CoA).  The idea of mobility support is such that the
   mobile node can be reached at the home-address even when it is
   attached to other foreign networks.  This is done in [3] with the
   introduction of an entity at the home network known as a home agent
   (HA). Mobile nodes register their care-of-addresses with the home
   agents using messages known as Binding Updates.  The home agent is
   responsible to intercept messages that are addressed to the mobile
   node's home-address, and forward the packet to the mobile node's
   care-of-address using IP-in-IP Tunneling [4].

   Extending the concept of mobility support for individual hosts to
   mobility support for a network of nodes, the objective of a network
   in motion solution is to provide a mechanism where nodes in a mobile
   network can be reached by their permanent addresses, no matter where
   on the Internet the mobile network is attached to. There exist a few
   prior attempts to provide network mobility support, most of them
   based on using bi-directional tunnels between the mobile routers and
   the home agents of the mobile routers [1].

   In bi-directional tunnels between mobile routers and home agents, the
   mobile router controlling a mobile network performs routing of
   packets to and from the mobile network when it is in its home domain.
   When the mobile router and its mobile network move to a foreign
   domain, the mobile router registers its care-of-address with its home
   agent. An IP-in-IP tunnel is then set up between the mobile router
   and the home agent. Every packet going to the mobile network will be
   intercepted by the home agent and forwarded to the mobile router
   through the IP-in-IP tunnel.  The mobile router then forwards the
   packet to a host in its mobile network.  When a node in its mobile
   network wishes to send a packet out of the network, the mobile router
   intercepts the packet and forward the packet to the home agent



Ng, et al.               Expires April 16, 2004                 [Page 3]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   through the IP-in-IP tunnel. The home agent then sends the packet out
   to the intended recipient.

   It is the interest of this memo to investigate if such a
   bi-directional tunneling approach can be extended to a mobile network
   that is multihomed. More specifically, we wish to identify issues
   that may arise in bi-directional tunneling between mobile router and
   home agent when the mobile network is multihomed.


1.2 Objectives

   This document is written with two main objectives in mind:

   o  To capture issues of deploying a multihomed mobile network

   o  To identify which multihoming scenario NEMO basic solution would
      support.  It does not't mean that those not supported will not
      work with NEMO, just that it is up to the implementors to make it
      work (hopefully issues discussed in the document will be helpful
      to these implementors).


1.3 Organization

   In this document, we first look into different classifications of
   multihomed mobile network in Section 2.  This section outlines 3
   different approaches to classifying multihomed mobile network.  Next,
   we described deployment scenarios of multihomed mobile networks in
   Section 3.  In Section 4, we go into detailed analysis of multihomed
   networks.  Benefits and issues of multihoming in network mobility
   support is discussed.


1.4 Terms and Abbreviation

   It is assumed that readers are familiar with the terminologies and
   abbreviations as defined in [5].













Ng, et al.               Expires April 16, 2004                 [Page 4]


Internet-Draft         Multihoming Issues in NEMO           October 2003


2. Classification

   Various discussions on the topic of multihoming issues in NEMO has
   been carried out on the Mailing List.  As there can be a lot of
   different deployments of a multihomed mobile network, there is a need
   for us to classify multihomed mobile network into a clearly defined
   set of taxonomy.

   There are various ways in which multihomed mobile network can be
   classified. We identify three main approach.  These are, namely, (i)
   Configuration-Oriented Approach, (iii) Ownership-Oriented Approach,
   and (ii) Problem-Oriented Approach. These are described in greater
   detail in the following sub-sections.


2.1 Configuration-Oriented Approach

   There are various configurations of a multihomed mobile network,
   depending on how many mobile routers are present, how many egress
   interfaces and home addresses the mobile routers have, how many
   subnet prefixes are advertised to the mobile network nodes, etc. In
   order to facilitate discussions on multihomed mobile network, it is
   necessary to identify what kind of configuration the mobile network
   is in.  Here, we identify three key parameters differentiating
   different multihomed configurations.  With these parameters, we can
   refer to each configuration by the 3-tuple (w,x,y), where 'w', 'x',
   'y' are defined as follows:

   o  'w' differentiates the case of single mobile router (with multiple
      egress interfaces or multiple home addresses) versus the case of
      multiple mobile routers, where

      w=1 implies a mobile network has only a single mobile router. In
         this case, the mobile router either has multiple egress
         interfaces or multiple home addresses bound to a single egress
         interface.

      w=N implies a mobile network has more than one mobile router
         advertising an egress route.

   o  'x' differentiates the case of a single home agent for the mobile
      network   versus the case of multiple home agents for the mobile
      network, where

      x=1 implies that a single home agent is assigned to manage binding
         updates of the mobile network.





Ng, et al.               Expires April 16, 2004                 [Page 5]


Internet-Draft         Multihoming Issues in NEMO           October 2003


      x=N implies that more than one home agents (possibly in different
         administrative domains) manage the binding updates of the
         mobile network.

   o  'y' differentiates the case of single mobile network prefix versus
      multiple mobile network prefixes that is/are advertised to the
      mobile network node, where

      y=1 implies that a single subnet prefix is advertised to the
         mobile network nodes.

      y=N implies that more than one subnet prefixes are advertised to
         the mobile network nodes.

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


2.1.1 (1,1,1): Single MR, Single HA, Single Prefix

   The (1,1,1) mobile network has only one mobile router advertising a
   single subnet prefix.  In addition, the mobile router associates with
   only one home agent at any one time.  This makes the mobile network
   very similar to a non-multihomed mobile network, except for the fact
   that the mobile router has multiple simultaneously active connections
   at the same time, e.g either (i) has multiple active egress links, or
   (ii) multiple active egress addresses.

   Since only one subnet prefix is advertised, the mobile network nodes
   are (usually) not multihomed.


                            _____
            _    p      _  |     |
           |_|-|<-_  |-|_|-|     |-|        _
            _  |-|_|=|     |_____| |  _  |-|_|
           |_|-|     |             |-|_|-|
                                         |

           MNNs   MR   AR  Internet  AR    HA

       Figure 2.1 - (1,1,1) Multihomed Mobile Network






Ng, et al.               Expires April 16, 2004                 [Page 6]


Internet-Draft         Multihoming Issues in NEMO           October 2003


2.1.2 (1,1,N): Single MR, Single HA, Multiple Prefixes

   The (1,1,N) mobile network has only one mobile router, which
   associates to only one home agent at any one time.  However, two or
   more subnet prefixes are advertised to the mobile network nodes.  No
   associations is assumed between the subnet prefixes and the home
   addresses of the mobile router.

   Since a plurality of subnet prefixes are advertised, mobile network
   nodes can generally be multihomed themselves, where each mobile
   network node is allocated one address in each subnet prefix.


                            _____
            _   p1,p2   _  |     |
           |_|-|<-_  |-|_|-|     |-|        _
            _  |-|_|=|     |_____| |  _  |-|_|
           |_|-|     |             |-|_|-|
                                         |

           MNNs   MR    AR Internet  AR    HA

       Figure 2.2 - (1,1,N) Multihomed Mobile Network



2.1.3 (1,N,1): Single MR, Multiple HAs, Single Prefix

   The (1,N,1) mobile network has only one mobile router advertising a
   single subnet prefix.  The mobile router, however, associates to
   multiple home agents, possibly one home agent per home addresses. No
   assumption is made on whether or not the home agents belongs to the
   same administrative domain.

   Since only one subnet prefix is advertised, the mobile network nodes
   are (usually) not multihomed.















Ng, et al.               Expires April 16, 2004                 [Page 7]


Internet-Draft         Multihoming Issues in NEMO           October 2003


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

       Figure 2.3 - (1,N,1) Multihomed Mobile Network



2.1.4 (1,N,N): Single MR, Multiple HAs, Multiple Prefixes

   The (1,n,n) mobile network has only one mobile router.  However, the
   mobile router advertises more than one subnet prefix, and also
   associates to multiple home agents at the same time, possibly one
   home agent per home address.  No assumptions is made on whether or
   not the home agents belongs to the same administrative domain.

   Since a plurality of subnet prefixes are advertised, mobile network
   nodes can generally be multihomed themselves, where each mobile
   network node is allocated one address in each subnet prefix.


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

       Figure 2.4 - (1,N,N) Multihomed Mobile Network









Ng, et al.               Expires April 16, 2004                 [Page 8]


Internet-Draft         Multihoming Issues in NEMO           October 2003


2.1.5 (N,1,1): Multiple MRs, Single HA, Single Prefix

   The (N,1,1) mobile network has more than one mobile router
   advertising global routes.  These mobile routers, however, advertise
   the same subnet prefix and associate to the same home agent.  Since
   only one subnet prefix is advertised, the mobile network nodes are
   (usually) not multihomed.

                 MR2

                 p
                <-_  |
            _  |-|_|-|  _____
           |_|-|     |-|     |
            _  |       |     |-|        _
           |_|-|  _  |-|_____| |  _  |-|_|
               |-|_|-|         |-|_|-|
                <-   |               |
                 p

           MNNs  MR1   Internet  AR    HA

       Figure 2.5 - (N,1,1) Multihomed Mobile Network


2.1.6 (N,1,N): Multiple MRs, Single HA, Multiple Prefixes

   The (N,1,N) mobile network has more than one mobile router
   advertising different global routes and different subnet prefixes.
   However, these mobile routers associate to the same home agents.

   Since a plurality of subnet prefixes are advertised, mobile network
   nodes can generally be multihomed themselves, where each mobile
   network node is allocated one address in each subnet prefix.

















Ng, et al.               Expires April 16, 2004                 [Page 9]


Internet-Draft         Multihoming Issues in NEMO           October 2003


                 MR2

                 p2
                <-_  |
            _  |-|_|-|  _____
           |_|-|     |-|     |
            _  |       |     |-|        _
           |_|-|  _  |-|_____| |  _  |-|_|
               |-|_|-|         |-|_|-|
                <-   |               |
                 p1

           MNNs  MR1   Internet  AR    HA

       Figure 2.6 - (N,1,N) Multihomed Mobile Network



2.1.7 (N,N,1): Multiple MRs, Multiple HAs, Single Prefix

   The (N,N,1) mobile network has more than one mobile router
   advertising different global routes.  The mobile routers are also
   associated to more than one home agents at any one time. No
   assumptions is made on whether or not the home agents belongs to the
   same administrative domain.  However, the mobile routers advertises
   the same subnet prefix.  Since only one subnet prefix is advertised,
   the mobile network nodes are (usually) not multihomed.


                 MR2             AR    HA2

                 p                _  |
                <-_  |         |-|_|-|  _
            _  |-|_|-|  _____  |     |-|_|
           |_|-|     |-|     |-|
            _  |       |     |
           |_|-|  _  |-|_____|-|        _
               |-|_|-|         |  _  |-|_|
                <-   |         |-|_|-|
                 p                   |

           MNNs  MR1   Internet  AR    HA1

       Figure 2.7 - (N,N,1) Multihomed Mobile Network







Ng, et al.               Expires April 16, 2004                [Page 10]


Internet-Draft         Multihoming Issues in NEMO           October 2003


2.1.8 (N,N,N): Multiple MRs, Multiple HAs, Multiple Prefixes

   The (N,N,N) mobile network has more than one mobile router
   advertising different global routes and different subnet prefixes.
   The mobile routers are also associated to more than one home agent at
   any one time.  No assumptions is made on whether or not the home
   agents belongs to the same administrative domain.

   Since a plurality of subnet prefixes are advertised, mobile network
   nodes can generally be multihomed themselves, where each mobile
   network node is allocated one address in each subnet prefix.


                 MR2             AR    HA2

                 p2               _  |
                <-_  |         |-|_|-|  _
            _  |-|_|-|  _____  |     |-|_|
           |_|-|     |-|     |-|
            _  |       |     |
           |_|-|  _  |-|_____|-|        _
               |-|_|-|         |  _  |-|_|
                <-   |         |-|_|-|
                 p1                  |

           MNNs  MR1   Internet  AR    HA1

       Figure 2.8 - (N,N,N) Multihomed Mobile Network



2.2 Ownership-Oriented Approach

   A second approach to classifying multihomed mobile networks is
   proposed by Eric Nordmark (Sun Microsystems) by breaking the
   classifications of multihomed network based on ownership.  This is
   more of a tree-like top-down classifications. 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.

   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



Ng, et al.               Expires April 16, 2004                [Page 11]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   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).

   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 mobile routers belongs to a single subscriber and
   subscribes to one or more ISPs for home agent 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 Prefix

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

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

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

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

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

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

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





Ng, et al.               Expires April 16, 2004                [Page 12]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   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
      Prefix

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

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


2.3 Problem-Oriented Approach

   A third approach to classifying multihomed mobile networks 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 home agents, and
   the number of subnet 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-ofs of Same 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 x=1, i.e. the (1,1,N)
      mobile network.

   o  JetSet: Multiple HA for Different Care-ofs of Same 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 x=N, i.e. the (1,N,*)
      mobile network.

   o  Shinkansen: Single Prefix Advertised by Mobile Router(s)

      This is the case where one subnet prefix is announced by different
      mobile routers.  This is equivalent to the case of y=N, i.e. the
      (1,*,N) mobile network.

   o  DoubleBed: Multiple Prefixes Advertised by Mobile Router(s)

      This is the case where more than one subnet prefixes are announced
      by the different mobile routers.  This is equivalent to the case



Ng, et al.               Expires April 16, 2004                [Page 13]


Internet-Draft         Multihoming Issues in NEMO           October 2003


      of y=N, i.e. the (N,*,N) mobile network.


















































Ng, et al.               Expires April 16, 2004                [Page 14]


Internet-Draft         Multihoming Issues in NEMO           October 2003


3. Deployment Scenarios

   One example of the S/P-(1,1,*) mobile network is that a single ISP
   offers two different wireless public access methods such as IEEE
   802.11 and GPRS. A mobile router with both access interfaces (i.e.
   802.11 and GPRS capabilities) may subscribe to the same ISP and is
   allowed to use both access methods.  The ISP will choose to provide a
   single home agent for the same mobile router for ease of management.

   This configuration is useful for maintaining connectivity between
   several interfaces.  An example will be to use 802.11 in town and
   GPRS in the country side.  In addition, it can also provide some
   multihoming benefits (such as Fault Tolerance / Load Sharing) to MNNs
   without having to involve the MNNs.

   Extending the above example to a S/mP-(1,N,*) mobile network, the
   mobile router may subscribe to different ISPs for different access
   technologies. For instance, it may subscribe to 802.11 public access
   services using one ISP, and subscribe to GPRS services from another
   ISP.  In this case, the two different ISPs will provide two different
   home agents for the same mobile router.  Since the two ISPs are
   independent, under normal situation, each ISP will delegates
   different subnet prefixes to the mobile network, thus forming a S/
   mP-(1,N,N) mobile network.

   An example of the (N,*,*) mobile network is when a mobile network
   contains more than one device with independent routes to the global
   Internet.  An excellent illustration is the Wireless Personal Area
   Network (W-PAN) where a mobile phone on the W-PAN connects to the
   Internet via GPRS services, and a Personal Digital Assistant (PDA) on
   the same W-PAN connects to the Internet via 802.11 public access. If
   the ISPs provide both access technologies, then the subscriber can
   subscribes to a all-in-one package where the ISP provides a single
   home agent to manage the mobile network, and delegates a single
   subnet prefix to the mobile network.  This forms a S/P-(N,1,1) mobile
   network. Alternatively, the subscriber can subscribes to two ISPs for
   each access mechanism, thus giving a S/mP-(N,N,N) mobile network.

   The (N,*,1) configuration provides easily a router redundancy and/or
   HA redundancy for big mobile networks, such as within a train or a
   plane, or critical mobile networks, such as those deployed in
   ambulances, fire engines, or military vehicles.

   Figure 3.1 below illustrate a (1,N,1) mobile network deployed on a
   plane. In this example, the MR sends the same PBU to both HAs in
   different cities, and communicates with both simultaneously. Thus a
   Correspondent Node near Paris can choose the Paris's HA to send its
   packets, and the MR inside the plane should send its packet to the



Ng, et al.               Expires April 16, 2004                [Page 15]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   New York's HA (which is nearer).


                                [The Jet]

         _                      |\_______           _
       -|_|-  <-------------->  |____~___\  <-->  -|_|-

        HA1                     MN inside the      HA2
                                plane.
       Paris                                      New York

          Figure 3.1 - Deployment example for (1,N,1)


   Example for a (*,*,N) mobile network is a car network, where there
   may be different logical subnets:

   o  the User Network which provides Internet connectivity to
      passengers;

   o  the Control Network which exchanges car information (e.g.
      position, movement, intern constants) with the others cars, or
      with the society who use this car; and

   o  the Safeguard Network which shares state information of the car
      with the emergency/repairing companies, or the emergency agencies
      in case of accidents.

   Because of these differences it can be useful to attribute a
   different network prefix for each network to clearly separate each
   entity and each network prefix should be send to a different subnet
   link.


















Ng, et al.               Expires April 16, 2004                [Page 16]


Internet-Draft         Multihoming Issues in NEMO           October 2003


4. Analysis

4.1 Benefits/Issues of Multihoming in NEMO

   Multihoming brings along its benefits and issues to mobile networks.
   These are (1) Fault Tolerance and (2) Load Sharing.  They are
   discussed in greater details below.

4.1.1 Fault Tolerance

   A multihomed mobile network, by definition, has multiple paths to the
   global network (i.e. Internet).  This brings along the obvious
   benefit of having an alternate path to the global network when one of
   path is down.  Used in the context of mobile networks, it means that
   either of the following:

   o  There is a single bi-directional tunnel established between the
      mobile network and a home agent.  When this bi-directional tunnel
      is broken due to one egress link of the mobile network is down,
      the mobile network set up a new bi-directional tunnel.

      This form of multihoming is more appropriate for a dual-mode
      mobile router which has multiple egress interfaces (i.e. the
      (1,*,*) mobile networks).  This is because in this way the mobile
      router is at full control of which bi-directional tunnel to set
      up.  For a mobile network with multiple mobile routers, to use
      only one bi-directional tunnel would require some form of
      co-ordinations between the mobile routers.

   o  There is multiple bi-directional tunnels established between the
      mobile network and one or more home agents.  When any of these
      bi-directional tunnels is broken, packets to and from the mobile
      network can traverse along the other bi-directional tunnels.  This
      form of multihoming can be deployed by any configuration of
      multihomed mobile network.

   In both cases, when a bi-directional tunnel fails and packets are
   diverted to an alternative (perhaps newly established) bi-directional
   tunnel, care has to be taken to prevent ingress filtering from
   dropping the outgoing packets when the two tunnels end at different
   home agents.  Ingress filtering occurs when different mobile network
   prefixes are handled by different home agents. For example, consider
   the case when a mobile network has two tunnel connections to home
   agents HA1 and HA2.  The mobile network prefix P1 is registered to
   HA1, and mobile network prefix P2 is registered to HA2.  Mobile
   network nodes are free to auto-configure their addresses based on any
   of P1 or P2.  When the tunnel to HA1 is broken, packets sent through
   the tunnel to HA1 are diverted to send through the tunnel to HA2.  If



Ng, et al.               Expires April 16, 2004                [Page 17]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   HA2 (or some border gateway in the domain of HA2) performs ingress
   filtering, packets with a source address prefix of P1 may be
   discarded.

   To avoid ingress filtering for such cases, the mobile router(s) can
   stop advertising the network prefix P1.  This will stop mobile
   network node from using source address auto-configured from prefix
   P1.  However, such a method suffers from the following two
   limitations:

   o  Switching of source address is a long process since nodes have to
      wait for source address to get deprecated [6].

   o  In addition, switching of source address will force transport
      sessions without multihoming capabilities (such as TCP) to be
      terminated, and re-established using the new source address.
      Transport sessions with multihoming capabilities (such as SCTP)
      may be able to continue without disruption.

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

   In order for fault tolerance to work, the mobile routers and home
   agents must first possess a means to detect failures.  It is expected
   for faults to occur more readily at the attachment point to the
   Internet of the mobile network, due to the use of wireless
   connections.  The mobile router can then rely on router
   advertisements from access routers, or other layer two trigger
   mechanisms to detect faults.  In comparison, it is more difficult for
   home agents to detect tunnel failures. For an ISP deployment model,
   the home agents and mobile routers can use proprietary methods (such
   as constant transmission of heartbeat signals) to detect failures and
   check tunnel liveness.  In the S/P model, a lack of standardized
   "tunnel liveness" protocol means that it is harder to detect
   failures.

   A possible method is for the mobile routers to send binding updates
   more regularly with shorter Lifetime value.  Similarly the home
   agents can return binding acknowledgment messages with smaller
   Lifetime values as well, thus forcing the mobile routers 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 home
   agents must be encrypted.







Ng, et al.               Expires April 16, 2004                [Page 18]


Internet-Draft         Multihoming Issues in NEMO           October 2003


4.1.2 Load Sharing

   With multiple tunnels simultaneously established to connect the
   mobile network to the global Internet, packets going to and from the
   mobile network can take different paths.  This allows home agents and
   mobile routers to distribute traffic loads among the bi-directional
   tunnels, thus allowing more efficient use of network resources and
   alleviate traffic congestion.  Such is known as load sharing.

   Load sharing can be achieved in various forms and using different
   techniques. Considerations into each individual load sharing methods
   is out of scope of this document.  Instead, we discuss load sharing
   in multihomed mobile networks based on only two broad
   classifications: static load sharing, and dynamic load sharing.

   o  Static Load Sharing

      This means that the distribution of traffic among the
      bi-directional tunnels are configured statically.  This may be
      based on destination address, source address, or even simple round
      robin.

   o  Dynamic Load Sharing

      This means that the distribution of traffic among the
      bi-directional tunnels are configured dynamically.  This usually
      involves a form of policy that is loaded to the mobile routers
      and/or home agents at the time when the bi-directional tunnels are
      established.  Such policy can specify rules for distribution of
      traffic based on a richer set of parameters, such as
      quality-of-service, as well as destination and source addresses.
      The policy may be communicated to the mobile routers using a
      dynamic routing protocol that is run over the bi-direction
      tunnels.  This form of load sharing is more likely to be deployed
      by a ISP multihomed model rather than the S/P model, due to the
      need for the mobile routers and home agents to constantly exchange
      parameters.

   As is the case of fault tolerance, when distributing packets among
   different bi-directional tunnels, there is the issue of address
   filtering to consider. Sending packets with source address belonging
   to a network prefix P1 to a home agent that does not accept P1 as a
   valid ingress prefix will cause the packet to be discarded.   In view
   of this, we expect load sharing to be used for ISP model and the S/P
   model, but less likely in a S/mP model.






Ng, et al.               Expires April 16, 2004                [Page 19]


Internet-Draft         Multihoming Issues in NEMO           October 2003


4.2 Ownership-Oriented Approach

   o  ISP Model

      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 network 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 home agents)
      work. This include not introducing any aggregation between the
      home agents which will filter out routing announcements for the
      mobile 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
      secondary role when compared to Binding Update messages.

   o  Subscriber/Provider Model

      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 April 16, 2004                [Page 20]


Internet-Draft         Multihoming Issues in NEMO           October 2003


4.3 Configuration-Oriented Approach

   This section, we attempt to analyze what are the problems faced in
   each of the 8 categories.  It shouldn't matter if some of the
   categories share the same problem(s).

   [To think about how to merge in Julien's evaluation stuff -- cwng]

   o  (1,1,1) Mobile Network

      The (1,1,1) mobile network has only one mobile router registering
      more than one care-of-addresses to the same home agent, and
      advertising only one prefix.  The mobile router can either have
      more than one care-of-addresses bound to the same home-address, or
      it can have various care-of-address and home-address pairs.

      Either way, this is a MIPv6 problem.  Multiple pairs of different
      care-of-address and home-address is perfectly alright with MIPv6.
      The fact that they specify the same subnet prefix in binding
      updates shouldn't cause a problem either.  Having a home-address
      bound to multiple care-of-address simultaneously may be a problem
      for MIPv6. This will require a solution like [7].

   o  (1,1,N) Mobile Network

      The (1,1,N) mobile network is similar to the (1,1,1) mobile
      network, and thus face the same problem when there is only one
      home-address bound to multiple care-of-addresses.  In addition, it
      is possible for the mobile router to include multiple mobile
      network prefix options in a single binding update, thus having
      multiple network prefixes should not create additional issues.

   o  (1,N,1) Mobile Network

      The (1,N,1) mobile network has one mobile router registering to
      multiple home agents.  There is the question of whether a mobile
      router can register the same home-address to different home agents
      simultaneously with the 'H' bit set.  If not, the mobile router
      can only register different home-address and care-of-address pairs
      to different home agents.  In any case, this is a MIPv6 issue.

      The NEMO-specific problem is the fact that a subnet prefix has a
      care-of in different home agents.  It might be possible that only
      one home-agent will actively advertise a route to the subnet
      prefix.  The case of multiple home agents at different domains
      advertising a route to the same subnet prefix may pose a problem
      in the routing infrastructure as a whole.  The implications of
      this aspect needs further exploration.



Ng, et al.               Expires April 16, 2004                [Page 21]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   o  (1,N,N) Mobile Network

      The (1,N,N) mobile network has one mobile router registering to
      multiple home agents multiple subnet prefixes.  The same question
      of whether the same home-address can be simultaneously registered
      to multiple home agents.

      This (1,N,N) network can avoid the problem of registering care-ofs
      for the same prefix to different home agents by registering
      care-of for one prefix at one home-agent.

   o  (N,1,1) Mobile Network

      The (N,1,1) mobile network has two or more active egress mobile
      routers, registering to same home agents, and advertising the same
      prefix. May not have any problem at all if the mobile routers are
      manually configured to announce the same prefix.  It is also
      possible that prefix delegation is used to ensure all routers
      advertise the same subnet prefix since all routers are handled by
      the same home agent. The home-agent will see multiple HoA-CoA
      pairs taking care of the same subnet prefix.

   o  (N,1,N) Mobile Network

      The (N,1,N) mobile network has multiple active egress mobile
      routers registering to the same home-agent, and advertising
      multiple prefixes. If a mobile router is advertising more than one
      prefix, we have the same situation as (1,1,N), except with an
      additional mobile router. It is possible for the mobile router to
      include multiple mobile network prefix options in a single binding
      update, thus having multiple network prefixes should not create
      additional issues.

      On the other hand, if each mobile router take cares of a separate
      (and only one) subnet prefix, then there should not be any
      NEMO-specific problem.

   o  (N,N,1) Mobile Network

      The (N,N,1) mobile network has multiple mobile routers registering
      to different home agents, but advertising the same prefix.  There
      is the same issues as in (1,N,1) of a subnet prefix having a
      care-of in different home agents.  In addition, there is a
      question how to perform prefix delegation such that two home
      agents will delegate the same prefix to different mobile routers.
      Certain level of home-agent co-ordination may be required here.





Ng, et al.               Expires April 16, 2004                [Page 22]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   o  (N,N,N) Mobile Network

      The (N,N,N) mobile network has multiple mobile routers,
      registering to multiple home-agents and advertising prefixes.
      This may be a case of multiple non-multihomed network superimposed
      together, i.e. each mobile router take cares of one prefix, and
      register to separate home agents.

      On the other hand, if one mobile router takes cares of more than
      one prefix, we have similar problems as (1,1,N) and (N,1,N).  In
      addition, if more than one mobile router takes care of the same
      prefix, we have similar issues as (N,N,1).  In any case, we see
      that the problems within this configurations can be decomposed
      into problems from other configurations.

   From the above analysis, we can identify the following problems
   relating to multihomed mobile network:

   o  Multiple care-of-addresses to one home-address:

      *  How to register two care-of-address binding to one
         home-address?

      *  In single or multiple binding message(s)?

      *  How to selectively update a care-of-address?

      *  MIPv6 specific?

      *  Wakikawa's draft [7] specifically addresses this issue.

   o  Multiple prefixes taken care of by a single home-address:

      *  How to register multiple prefix scope under the same
         home-address?

      *  In single or multiple binding message(s)?

      *  How to selectively update the care-of of a subnet prefix?

      *  Similar to the 'Tarzan' problem illustrated by Thubert.

   o  A single home-address registered to multiple home agents:

      *  Is this allowed?

      *  MIPv6-specific?




Ng, et al.               Expires April 16, 2004                [Page 23]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   o  A single subnet prefix registered to multiple home agents:

      *  Is this allowed?

      *  Is this allowed if the prefix is bound to the same
         home-address?

      *  Any routing issue?

      *  If prefix delegation is used, possibility of requiring home
         agents co-ordination.

      *  Similar to the 'JetSet' problem illustrated by Thubert.

   o  A single prefix advertised by multiple mobile routers from
      multiple home agents:

      *  If prefix delegation is used, possibility of requiring home
         agents co-ordination.

      *  Similar to the 'Shinkansen' problem illustrated by Thubert.

   o  [TBD: anymore]




























Ng, et al.               Expires April 16, 2004                [Page 24]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   [Editor's Notes]

   It is originally intended that the analysis work done by Julien
   Charbon et. al. and Paik Eun Kyoung et. al. to be inserted into this
   portion.  From these analysis work, we can determine which are the
   multihoming scenarios will be supported by the NEMO Basic Support,
   and which are not. This part of the work has yet to be merged in as
   of the publication date of this draft.











































Ng, et al.               Expires April 16, 2004                [Page 25]


Internet-Draft         Multihoming Issues in NEMO           October 2003


5. Security Considerations

   This document is an on-going work to classify the taxonomy in
   multihoming of mobile networks.  There should be a separate draft
   produced by the working group to analyze security threats for network
   in motion.  As such, no special security considerations is listed
   here.  However, since this memo also looks into the analysis of
   problems in a multihomed mobile network, we will add problems related
   to security threat here as and when they are encountered.  We also
   encourage interested readers 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 and 57th IETF
   Meetings.

References

   [1]  Devarapali, V., et al, "Nemo Basic Support Protocol", Internet
        Draft: draft-ietf-nemo-basic-support-01.txt, Work In Progress,
        September 2003.

   [2]  Ernst, T., et al, "Network Mobility Support Goals and
        Requirements", Internet Draft:
        draft-ietf-nemo-requirements-01.txt, Work In Progress, May 2003.

   [3]  Johnson, D.B., Perkins, C.E. and Arkko, J., "Mobility Support in
        IPv6", Internet Draft: draft-ietf-mobileip-ipv6-21.txt, Work In
        Progress, February 2003.

   [4]  Simpson, W., "IP in IP Tunneling", IETF RFC 1853, October 1995.

   [5]  Ernst, T. and Lach, H. Y., "Network Mobility Support
        Terminology", Internet Draft:
        draft-ietf-nemo-terminology-00.txt, Work In Progress, May 2003.

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

   [7]  Wakikawa, R., Uehara, K. and Ernst, T., "Multiple
        Care-of-Address Registration on Mobile IPv6", Internet Draft:
        draft-wakikawa-mobileip-multiplecoa-01.txt, Work In Progress,
        June 2003.

   [8]  Narten, T., Nordmark, E. and Simpson, W., "Neighbour Discovery
        for IPv6", IETF RFC 2461, December 1998.



Ng, et al.               Expires April 16, 2004                [Page 26]


Internet-Draft         Multihoming Issues in NEMO           October 2003


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


   Julien Charbon
   Keio University, Louis Pasteur University
   Keio University.
   5322 Endo
   Fujisawa-shi, Kanagawa  252-8520
   JP

   Phone: +81-466-49-1100
   Fax:   +81-466-49-1395
   EMail: julien@sfc.wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~julien/


   Paik, Eun-Kyoung
   Seoul National University
   Seoul National University
   KR

   EMail: eun@mmlab.snu.ac.kr
   URI:   http://mmlab.snu.ac.kr/~eun/

Appendix A. Nested Tunneling for Fault Tolerance

   In order to utilize the additional robustness provided by multi-
   homing, mobile routers that employ bi-directional tunneling with
   their home agents should dynamically change their tunnel exit points
   depending on the link status.  For instance, if a mobile router
   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 mobile routers connected
   to one of its ingress interfaces that has an independent route to the
   global Internet, or by another active egress interface the mobile
   router it self possess.  If such an alternate route exists, the
   mobile router should re-establish the bi-directional tunnel using
   this alternate route.



Ng, et al.               Expires April 16, 2004                [Page 27]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   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 and Neighbor Discovery
   in IPv6 [8].

A.1 Detecting Presence of Alternate Routes

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

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

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

A.2 Re-Establishment of Bi-Directional Tunnels

   When a mobile router detects that the link be which its current
   bi-directional tunnel with its home agent is using is down, it needs
   to re-establish the bi-directional tunnel using an alternate route
   detected.  We consider two separate cases here: firstly, the
   alternate route is provided by another egress interface that belongs
   to the mobile router; secondly, the alternate route is provided by
   another mobile router 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 mobile router.

A.2.1 Using Alternate Egress Interface

   When an egress interface of a mobile router loses the connection to
   the global Internet, the mobile router can make use of its alternate



Ng, et al.               Expires April 16, 2004                [Page 28]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   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 mobile router 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.

A.2.2 Using Alternate Mobile Router

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

   The idea is to obtain a care-of-address from the alternate mobile
   router and use this as the new (back-up) care-of-address of the
   mobile router to re-establish the bi-directional tunneling with its
   home agent.

   Note that every packet sent from/to mobile network nodes to/from
   their correspondent nodes will experience two levels of
   encapsulation. First level of tunneling is done between a mobile
   router which the mobile network node uses as its default router and
   the mobile router's home agent.  The second level of tunneling is
   done between the alternate mobile router and its home agent.

A.3 To Avoid Tunneling Loop

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




Ng, et al.               Expires April 16, 2004                [Page 29]


Internet-Draft         Multihoming Issues in NEMO           October 2003


   One approach to avoid tunneling loop is for a mobile router 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 mobile routers 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 mobile network
   nodes that are attached to the mobile router to stop using the mobile
   router as an access router too  (in which case, things are back to
   square one).

A.4 Other Considerations

   When a mobile network is multihomed, mobile network nodes may receive
   Router Advertisements that advertise different network prefixes.
   This is usually the case when the multihomed mobile network has two
   or more mobile routers advertising different routes to the global
   Internet.  It may also occur when the mobile network has only one
   mobile router with multiple egress interfaces bound to different home
   agents.  In these situations, mobile network nodes typically only
   select one to form its global (possibly care-of) address.

   In view of this, it may be desirable for mobile network node to be
   able to acquire "preference" information on each mobile network
   prefix from the mobile routers.  This allows default address
   selection mechanism such as that specified in [6] 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.























Ng, et al.               Expires April 16, 2004                [Page 30]


Internet-Draft         Multihoming Issues in NEMO           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



Ng, et al.               Expires April 16, 2004                [Page 31]


Internet-Draft         Multihoming Issues in NEMO           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.











































Ng, et al.               Expires April 16, 2004                [Page 32]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/