[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
Monami6 Working Group                                           T. Ernst
Internet-Draft                                                     INRIA
Intended status: Informational                              N. Montavont
Expires: April 26, 2007                                       GET/ENST-B
                                                             R. Wakikawa
                                                         Keio University
                                                                   C. Ng
                                                Panasonic Singapore Labs
                                                          K. Kuladinithi
                                                    University of Bremen
                                                        October 23, 2006


   Motivations and Scenarios for Using Multiple Interfaces and Global
                               Addresses
       draft-ietf-monami6-multihoming-motivation-scenario-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).






Ernst, et al.            Expires April 26, 2007                 [Page 1]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


Abstract

   In this document, multihoming is investigated from a node point of
   view, and not from a site point of view as the term "multihoming" is
   commonly understood so far.  The purpose of this document is to
   explain the motivations for fixed and mobile nodes (hosts and
   routers) using multiple interfaces and the scenarios where this may
   end up using multiple global addresses on their interfaces.  Such
   multihoming configurations can bring a number of benefits once
   appropriate support mechanisms are put in place.  Interestingly, this
   analysis is generic, i.e. motivations and benefits of node
   multihoming apply to both fixed end nodes and mobile end nodes.


Table of Contents

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

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Scenarios and Motivations  . . . . . . . . . . . . . . . . . .  6
     3.1.  Need for Ubiquitous Access to the Internet . . . . . . . .  6
     3.2.  Need to Redirect Established Sessions  . . . . . . . . . .  6
     3.3.  Need to Set Up Preferences . . . . . . . . . . . . . . . .  6
     3.4.  Need to Select the Best Access Technology  . . . . . . . .  7
     3.5.  Need to Dispatch Traffic over Distinct Paths . . . . . . .  8
     3.6.  Need for Reliability . . . . . . . . . . . . . . . . . . .  8
     3.7.  Need to Accelerate Transmission  . . . . . . . . . . . . .  8

   4.  Goals and Benefits of Multihoming  . . . . . . . . . . . . . . 10
     4.1.  Permanent and Ubiquitous Access  . . . . . . . . . . . . . 11
     4.2.  Reliability  . . . . . . . . . . . . . . . . . . . . . . . 11
     4.3.  Flow Redirection . . . . . . . . . . . . . . . . . . . . . 12
     4.4.  Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 12
     4.5.  Load Balancing/Flow Distribution . . . . . . . . . . . . . 12
     4.6.  Preference Settings  . . . . . . . . . . . . . . . . . . . 12
     4.7.  Aggregate Bandwidth  . . . . . . . . . . . . . . . . . . . 12

   5.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  Case 1: One Interface, Multiple Prefixes . . . . . . . . . 13
     5.2.  Case 2: Several Interfaces . . . . . . . . . . . . . . . . 15

   6.  Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     6.1.  <!--Source-->Address Selection . . . . . . . . . . . . . . 18
     6.2.  Failure Discovery and Recovery Delay . . . . . . . . . . . 18
     6.3.  Change of Traffic Characteristics  . . . . . . . . . . . . 19
     6.4.  Address Change . . . . . . . . . . . . . . . . . . . . . . 19




Ernst, et al.            Expires April 26, 2007                 [Page 2]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20

   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20

   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20

   10. Informative References . . . . . . . . . . . . . . . . . . . . 20

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 24









































Ernst, et al.            Expires April 26, 2007                 [Page 3]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


1.  Introduction

   New equipments shipped on the market now often integrate several
   access technologies (both wired and wireless).  The main purpose of
   this integration is to federate all means of communications in order
   to access the Internet ubiquitously (from everywhere and at any time)
   as no single technology can be expected to be deployed everywhere.
   Flows may thus be redirected from one interface to the other
   following the loss of connectivity or change of the network
   conditions.  Besides providing an Internet access of wide spread and
   reach, integrating several access technologies also allow to increase
   bandwidth availability or to select the the most appropriate
   technology according to the type of flow or choices of the user,
   since each network interface has different cost, performance,
   bandwidth, access range, and reliability.

   Once multiple accesses are offered, users may want to select the most
   appropriate set of network interface(s) depending on the network
   environment, particularly in wireless networks which are mutable and
   less reliable than wired networks.  Users may also want to select the
   most appropriate interface per communication type or to combine a set
   of interfaces to get sufficient bandwidth.

   The purpose of this document is to emphasize the goals and benefits
   of multihoming for fixed and mobile hosts and routers in a generic
   fashion, i.e. without focusing on issues pertaining to hosts, or
   routers, nor mobility.  This document is indeed completing other
   documents focusing on these latter issues: Issues pertaining to site
   multihoming in fixed networks are discussed in [1].  Mobility issues
   pertaining to mobile nodes and mobile networks are respectively
   discussed in companion drafts [2] and [3].  Our document is targetted
   to IPv6, although our analysis may be applicable to IPv4 as well.
   The readers may refer to [4] for a description of the problem
   specific to Mobile IPv4.

   This document is organized as follows: first, the terms used in the
   document are defined before illustrating the motivations by means of
   some scenarios in Section 3.  These scenarios are then used to
   emphasize the goals and benefits of multihoming in Section 4.  Next
   follows in Section 5 an analysis of the achievable goals in two
   multihoming configurations, i.e. when the node either has a single
   interface or when it has multiple interfaces.  Section 6 concludes
   this document with a number of generic issues that will have to be
   solved in order to effectively meet multihoming goals and benefits.







Ernst, et al.            Expires April 26, 2007                 [Page 4]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


2.  Terminology

   This draft is based on the terminology defined in [5].  For the
   purpose of clarity, we remind the definition of interface.  Terms
   related to multihoming are not known to be defined in existing IETF
   RFCs.

   Interface

      A node's point of attachment to a link (as defined in [5])

   Multihomed Node

      A node (either a host or a router) is multihomed when it has
      several IPv6 addresses to choose between, i.e. in the following
      cases when it is either:

      *  multi-prefixed: multiple prefixes are advertised on the link(s)
         the node is attached to, or.

      *  multi-interfaced: the node has multiple interfaces to choose
         between, on the same link or not.





























Ernst, et al.            Expires April 26, 2007                 [Page 5]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


3.  Scenarios and Motivations

   The following real-life scenarios highlight the motivations for
   multihoming.  Each scenario usually yields more than one of the goals
   and benefits outlined in Section 4.  All scenarios focus on wireless
   technologies though no mobility management may be involved (one can
   use wireless access at office).

3.1.  Need for Ubiquitous Access to the Internet

   Mona is just getting out of a meeting with customers in a building.
   She calls her head office.  This audio communication is initiated via
   a private wireless local area network (WLAN) link realized over one
   of the available Wi-Fi hot-spots in the building.  This is going to
   be a long call and she must attend another meeting a few minutes
   drive from here.  She walks to a taxi stand, and boards a taxi.  The
   audio communication is automatically transferred to the public
   wireless metropolitan area network (WMAN) over the Wi-Max network
   deployed in the city, with no interruption of the communication.

   This scenario illustrates the need for a mobile user to use multiple
   types of access technologies in order to maintain ongoing
   communications when a user is moving out of the coverage area of a
   specific technology.

3.2.  Need to Redirect Established Sessions

   Oliver is on his way to work waiting at a train station.  He uses
   this opportunity and the presence of a WLAN hot-spot to download the
   news from his favorite on-line news channel.  While Oliver is
   downloading the news, he receives a phone call over a wide area
   cellular link.  Oliver decides to initiate a video flow for this
   communication.  The bandwidth and traversal delay of the wide area
   cellular link is not adequate for the video conference, so both flows
   (video/audio) are transferred to the WLAN link provided by the hot-
   spot.  This transfer occurs transparently and without affecting the
   other active flows.

   This scenario illustrates the need for a nomadic user to dynamically
   redirect flows from one type of access technology to another based on
   some user preferences or traffic requirements.

3.3.  Need to Set Up Preferences

   Nami works at home using her connection to the Internet via ADSL and
   a public 802.11b WLAN from the street.  She is also subscribed to
   digital video broadcasting.  Because the public WLAN is not secure,
   she downloads email from her company using the ADSL link even though



Ernst, et al.            Expires April 26, 2007                 [Page 6]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


   the WLAN service is free.  When she is accessing her personal free
   web-mail account, she would then use the WLAN service.  She has
   noticed the 802.11b link is unstable during the day, so she chooses
   to send requests and periodic refreshments for joining the digital
   video broadcasting via ADSL rather than the free WLAN services.

   This scenario illustrates the need in a fixed environment to
   simultaneously use multiple access technologies and to select the
   most appropriate one according to user preferences.  No assumptions
   are made whether flows need to be redirected or not from one access
   technology to another.  These preferences can be dynamic, or as in
   the example configured once for each application.

3.4.  Need to Select the Best Access Technology

   Alice is a paramedic.  Her ambulance is called to the scene of a car
   accident.  She initiates a communication to a hospital via a wide
   area cellular link for the relay of low bit-rate live video from the
   site of the crash to assess the severity of the accident.  It is
   identified that one of the passengers has suffered a severe head
   injury.  Alice decides to consult a specialist via video
   conferencing.  This session is initiated from the specialist via the
   same wide area cellular link.  Meanwhile, Alice requests for the
   download of the patient medical records from the hospital servers.
   She later decides in mid-session that the wide area cellular link is
   too slow for this download, and thus transfers the download to the
   ambulance satellite link.  Even though this link provides a
   significantly faster bit rate it has a longer traversal delay and
   only down-link is available.  For this, only the down-stream of the
   download is transferred while up-stream proceeds over the wide area
   cellular link.  Connectivity with the ambulance is managed over a
   WLAN link between the paramedic and the ambulance.  Even though Alice
   has performed a partial hand-off for the transfer of the download
   down-stream to the satellite link, the upstream and the video
   conferencing session remains on the wide area cellular link.  This
   serves best the time constraint requirements of the real time
   communications.

   This scenario illustrates the need in a mobile environment for both
   ubiquitous access to the Internet using whatever available interface
   and the need to dispatch flows to particular access media according
   to traffic characteristics or preferences.  The fact that the actual
   connection to the Internet is maintained via the ambulance to which
   the paramedic is connected to via a WLAN link illustrates to need to
   express preferences on the path to be taken from a remote computer
   (i.e. a mobile router in the ambulance in this case).





Ernst, et al.            Expires April 26, 2007                 [Page 7]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


3.5.  Need to Dispatch Traffic over Distinct Paths

   Max drives his car and constantly keeps some sort of Internet
   connectivity through one of the available access technologies.  His
   car navigator downloads road information from the Internet and his
   car-audio plays on-line audio streaming.  When his car passes an area
   where both high-data-rate Wi-Max and low-data rate cellular network
   are available, it distributes load to the Wi-Max access and the
   cellular network access.  When his car passes an area where only a
   wide coverage-range cellular network is available, the connection is
   maintained via the cellular network.

   This scenario illustrates the need to save traffic transiting in a
   particular access network when there is a possibility to send data
   over an alternative route.

3.6.  Need for Reliability

   Dr. Ingrid performs an operation via long-distance medical system.
   She watches a patient in a battle field over the screen which
   delivers real-time images of the patient.  Sensors on her arms
   deliver her operational actions and a robot performs the actual
   operation in the battle field.  Since the operation is critical, the
   delivery of patient images and Dr. Ingrid's action is done by bi-
   casting from/to multiple interfaces bound to a distinct technology or
   distinct radio range.  So in case packets are delayed or one of the
   interface fails to maintain connectivity to the network, her distant
   operation can be continued.

   This scenario illustrates the need to use multiple access
   technologies in order to improve reliability upon failure of one of
   the access technologies.

3.7.  Need to Accelerate Transmission

   Roku is at the airport waiting to board the plane.  She receives a
   call from her husband.  This audio communication is received via a
   WLAN link realized over one of the available hot-spots.  She knows
   this is going to be a long flight and wishes to catch up on some
   work.  Roku uses a WLAN connection to download the necessary data.
   However, there is not enough time and she decides to accelerate the
   download.  Her notebook is equipped with an additional WLAN
   interface.  She decides to use this additional WLAN interface to
   connect to another access point, and distribute the different
   download flows between the two wireless interfaces.

   This scenario illustrates the need to use multiple accesses to the
   Internet in order to accelerate the amount of data that could be



Ernst, et al.            Expires April 26, 2007                 [Page 8]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


   transmitted over a period of time.


















































Ernst, et al.            Expires April 26, 2007                 [Page 9]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


4.  Goals and Benefits of Multihoming

   The scenarios presented in the previous section are now used to
   highlight the goals and benefits of node multihoming.  The goals
   cannot really be distinguished from the benefits, but there are
   several situations where multihomed is either advisable or
   beneficial.  These benefits and goals listed here are by no means
   distinct and separate; most of them overlap with one another.  It is
   not the objective here to classify the benefits and goals into
   different non-overlapping consituents.  Instead the objective is to
   list the possible benefits and goals different people have when
   deploying a multihomed node.

   Figure 1 summarizes which goal applies to the scenarios introduced in
   Section 3.  Note that all these goals and benefits apply to both
   fixed end nodes and mobile end nodes, though the scenarios may either
   focused on a fixed used (F), or nomadic usage (N), or a mobile usage
   (M).  Nomadic and mobile users are both on the move, while a fixed
   user doesn't physically move.  The difference between nomadic usages
   and mobile usages is that sessions are not required to be maintained
   when the access network is changed as a result of physical move
   within the topology.  No assumptions are made whether mobility
   support mechanims may be useful or not in any of the fixed, nomadic
   and mobile usages in order to maintain sessions.  This is out of
   scope of the present document.


























Ernst, et al.            Expires April 26, 2007                [Page 10]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


   +===================================+===========================+
   |                                   |       Scenarios       |   |
   |                                   +---+---+---+---+---+---+---+
   | Goals                             | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
   +===================================+===+===+===+===+===+===+===+
   | Ubiquitous Access                 | o |   |   | o | o |   |   |
   +-----------------------------------+---+---+---+---+---+---+---+
   | Flow Redirection                  | o | o | o | o | o |   |   |
   +-----------------------------------+---+---+---+---+---+---+---+
   | Reliability                       |   |   | o | o | o | o |   |
   +-----------------------------------+---+---+---+---+---+---+---+
   | Load Sharing                      |   |   |   |   | o |   |   |
   +-----------------------------------+---+---+---+---+---+---+---+
   | Load Balancing                    |   |   | o | o |   |   | o |
   +-----------------------------------+---+---+---+---+---+---+---+
   | Preference Settings               |   | o | o | o |   |   |   |
   +-----------------------------------+---+---+---+---+---+---+---+
   | Aggregate Bandwidth               |   |   |   | o |   |   | o |
   +===================================+===+===+===+===+===+===+===+
   | Usage: F=Fixed N=Nomadic M=Mobile | M | N | F | M | M | F | N |
   +===================================+===+===+===+===+===+===+===+

                 Figure 1: Goals Applying to Each Scenario

4.1.  Permanent and Ubiquitous Access

   To provide an extended coverage area via distinct access
   technologies.

   Multiple interfaces bound to distinct technologies can be used to
   ensure a permanent connectivity is offered, anywhere, anytime, with
   anyone.

4.2.  Reliability

   To act upon failure at one point of attachment, i.e. the functions of
   a system component (e.g. interface, access network) are assumed by
   secondary system components when the primary component becomes
   unavailable (e.g. failure).  Connectivity is guaranteed as long as at
   least one connection to the Internet is maintained.

   A potential means is to duplicate network component, another is to
   duplicate a particular flow simultaneously through different routes.
   This minimizes packet loss typically for real-time communication and
   burst traffic.  It also minimizes delay of packet delivery caused by
   congestion and achieves more reliable real-time communication than
   single-casting.  For mobile computing, bi-casting avoids dropping
   packets when a mobile node changes its interface during communication



Ernst, et al.            Expires April 26, 2007                [Page 11]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


   [6].

4.3.  Flow Redirection

   To be able to redirect flow from one interface, or one address to
   another one, without having to re-initiate the flow.  This can be due
   to preference changes or upon network failure.

4.4.  Load Sharing

   To spread network traffic load among several routes.  This is
   achieved when traffic load is distributed among different connections
   between the node and the Internet [7].

4.5.  Load Balancing/Flow Distribution

   To separate a flow between multiple points of attachment
   (simultaneously active or not) of a node, usually chosing the less
   loaded connection or according to preferences on the mapping between
   flows and interfaces.

4.6.  Preference Settings

   This goal is to provide the user, the application or the ISP the
   ability to choose the preferred transmission technology or access
   network based on cost, efficiency, policies, bandwidth requirement,
   delay, etc.

4.7.  Aggregate Bandwidth

   This goal is to provide the user or the application with more
   bandwidth.

   Bandwidth available to the user or the application may be limited by
   the underlying technology (e.g.  GSM has scarce bandwidth) or by some
   policies (e.g. monthly rate paid by the user).  Multiple interfaces
   connected to different links or ISPs can increase the total bandwidth
   available to the user or application.













Ernst, et al.            Expires April 26, 2007                [Page 12]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


5.  Analysis

   From the definition of a multihomed node it follows that a multihomed
   node has several IPv6 addresses to choose between.  In order to
   expose the goals and benefits to manage multihomed nodes, we propose
   to distinguish two main cases: either the node has only one
   interface, or the node has several interfaces.  In the former case,
   the node is multihomed when multilpe prefixes are advertised on the
   link the node is attached to.  This distinction is important and
   sometimes subtle but the implications are important.

5.1.  Case 1: One Interface, Multiple Prefixes

   The single-interfaced node is multihomed when several prefixes are
   advertised on its interface.  The node must therefore configure
   several IPv6 addresses.

   A typical example is a node with a 802.11b interface, connected to an
   access point.  The access point is connected trough an Ethernet link
   to two access routers.  Each access router is configured to advertise
   distinct network prefixes by Router Advertisements on the link and
   can be used as default router.  Several reasons may lead to configure
   two access routers on the same link: for instance, the access points
   may be shared between different ISPs, or two access routers may be
   used for redundancy or load sharing purposes.  The node will then
   build two global IPv6 addresses on its interface.

   We now analyse which of the goals detailed in Section 4 can be met
   with this configuration.


   o  Ubiquitous Access: NO

      Ubiquitous access cannot be guaranteed when the node loses
      Internet connectivity through its sole interface (e.g. the node is
      going outside the coverage area of its access point).


   o  Flow redirection: YES

      The node might need to redirect a flow from one address to another
      for several reasons.  For example, if one of the IPv6 prefix
      becomes unavailable, flows using the corresponding prefix need to
      be redirected on an address using another prefix


   o  Reliability: MAYBE




Ernst, et al.            Expires April 26, 2007                [Page 13]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


      In case of failure of one IPv6 prefix, one of the address of the
      node will not be valid anymore.  Another available address built
      from other prefixes may allow the node to recover this sort of
      failure.

      Bi-casting can be performed to ensure the delivery of packets on
      the node.  To do so, more than one IPv6 address must be used
      simultaneously for one flow.  Bi-casting would allow the node to
      seamlessly change the address used on the node.


   o  Load sharing: YES

      Load Sharing can be performed in the network, according to the
      address used by the node.  The choice of the address used by the
      node and the router selection can be influenced by the load
      sharing rules.  This mostly benefits the network side: if
      different access routers or routes can be used to forward the
      node's traffic, it will share the traffic load on the network.


   o  Load balancing/Flow Distribution: NO

      Load balancing cannot be performed as the node has only one
      interface.


   o  Preferences: YES

      The source address can be chosen according to preferences set up
      by the user, or according to preferences set up in the network
      (such as with the default router preferences option introduced in
      Router Advertisement [8]), or by the ISP.


   o  Aggregated Bandwidth: MAYBE

      With only one interface connected to a link, the node generally
      will not be able to benefit from an increased aggregated bandwidth
      with multiple prefixes.  However, this benefit might be gained
      indirectly.  For instance, by alternating between different
      addresses, the total throughput may be higher (eg. due to load
      sharing).  Also, some web and file transfer servers limit transfer
      bandwidths based on the client's address.  By using different
      addresses to connect to the same server, the node may also see an
      increase in file transfer rate.





Ernst, et al.            Expires April 26, 2007                [Page 14]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


5.2.  Case 2: Several Interfaces

   In this case, the node may use its multiple interfaces either
   alternatively or simultaneously.  If used simultaneously, the node
   uses several IPv6 addresses at the same time (at least one address
   per interface, or several if several prefixes are announced on the
   link(s) it is connected to).  If used alternatively, the node may
   switch between its interfaces (e.g, one at a time), which is the case
   described above in Section 5.1.  In the paragraphs below, we assume
   that multiple interfaces are used simultaneously.  We also note that
   multiple interfaces can be connected to the same link as well as to
   different links.  These configurations will imply different issues.
   All these multihomed configurations may yield different benefits to
   the node.

   A typical example is a node with two interfaces, each one on a
   different technology (e.g. a WLAN 802.11b interface and a 3GPP GPRS
   interface), in order to benefit from a better coverage area and the
   characteristics of each technology.

   We now analyse how each of the goals listed in Section 4 can be met
   with such multihomed configuration:


   o  Ubiquitous Access: MAYBE

      It is easier to guarantee ubiquitous access when the node has
      multiple interfaces since distinct technologies may be available
      at a given time according to the location and administrative
      policies.


   o  Flow redirection: YES

      In case of a change in user preferences, or a failure, flows might
      need to be redirected from one interface to another one.  Flows
      can be redirected individually or all flows attached to an
      interface might be redirected at once.


   o  Reliability: YES

      Two levels of redundancy can be seen in this case: either one
      address of one interface is not valid anymore (e.g. because the
      corresponding prefix is not advertised on the link), or the node
      loses its internet connectivity through one interface.  In the
      former case, another IPv6 address available on the interface would
      allow the node to switch addresses for on-going flows.  In the



Ernst, et al.            Expires April 26, 2007                [Page 15]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


      latter case, another connection to the internet through another
      interface would allow it to redirect on-going flow from the
      previous interface to the new one.  In either cases the node needs
      to change the IPv6 address for on-going sessions from the no
      longer valid address to one of the address available on the target
      interface.  The redirection will trigger a decision process to
      choose the best target interface to redirect the flow to.

      Bi-casting might be used to ensure the packets delivery on the
      node.  It would also allow seamless redirection between two
      addresses / interfaces with zero packets loss.  Bi-casting can be
      performed if several IPv6 addresses can be simultaneously used for
      one flow.  One entity between the CN (included) and the node
      (excluded) must duplicate the traffic to the destination node.


   o  Load Sharing: YES

      This benefit is mainly for the network side: if different access
      routers or routes can be used to forward traffic going into and
      out of the node, they can share the traffic load on the network.
      If the node uses several addresses at the same time for its on-
      going sessions, load sharing can be performed in the network.
      This goal can be a parameter that helps the source address
      selection.


   o  Load balancing/Flow Distribution: YES

      Load balancing can be achieved on the node if several interfaces
      are used simultaneously.  Several interfaces can be used to spread
      the traffic load on the node.  This implies the choice of the IPv6
      address to use for each flow and the ability to choose a different
      address for each flow.


   o  Preferences: YES

      Interface and address selection is required.  The problem can be
      seen exactly as in the first case (the node has only one
      interface) if we consider that the interface preference is a
      parameter for the address selection.  Therefore in this case, the
      interface selection/preference is a supplementary parameter in the
      address selection algorithm.


   o  Aggregated Bandwidth: YES




Ernst, et al.            Expires April 26, 2007                [Page 16]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


      With multiple interfaces connected to different links, the node
      generally will be able to benefit from an increased aggregated
      bandwidth.
















































Ernst, et al.            Expires April 26, 2007                [Page 17]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


6.  Issues

   In this section, we attempt to list a number of generic issues that
   will have to be solved in order to meet the multihoming goals.

   Figure 2 summarizes which issues apply to each of the case detailed
   in the previous section.  The sign '+', '-' or '=' indicated is the
   issue is more important, less important, or equally important to
   solve for the case under consideration

   +====================================+=====+=====+
   |                                    |   Cases   |
   |                                    +-----+-----+
   | Issues                             | (1) | (2) |
   +====================================+=====+=====+
   | Source Address Selection           | o = | o = |
   +------------------------------------+-----+-----+
   | Recovery Delay                     | o   | o + |
   +------------------------------------+-----+-----+
   | Change of e2e Path Characteristics | o - | o + |
   +------------------------------------+-----+-----+
   | Address Change                     | o + | o + |
   +====================================+=====+=====+

            Figure 2: Issues and their Importance for Each Case

6.1.  <!--Source-->Address Selection

   The multihomed node has several addresses, which implies the
   appropriate address must be chosen when an IPv6 communication is
   established (e.g. when a TCP connection is opened).  An address
   selection mechanism is therefore needed.

   The choice of the address can be influenced by many parameters: user
   preferences, ingress filtering, preference flag in Router
   Advertisement, destination prefix, type of interface, link
   characteristics, etc.

6.2.  Failure Discovery and Recovery Delay

   A particular access to the Internet may become unavailable while it
   is being used.  The time needed for detecting an address has become
   invalid and the time to redirect communications to one of its other
   addresses is considered as critical.  Efficient failure detection and
   recovery mechanisms are therefore required.

   Note that transport sessions with multihoming capabilies such as SCTP
   [9] may be able to continue easily since SCTP has built-in



Ernst, et al.            Expires April 26, 2007                [Page 18]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


   transmission rate control mechanims to take into account the
   differences between two paths.

6.3.  Change of Traffic Characteristics

   The change of path for a specific session (e.g. due to change of
   interface) may cause changes on the end-to-end path characteristics
   (higher delay, different PMTU, etc).  This could have an impact on
   upper layer protocols such as transport protocols (particularly TCP)
   or applications that are sensitive to changes.

6.4.  Address Change

   In some situations, it will be necessary to divert some or all of the
   sessions from one interface or prefix to another (e.g. due to loss of
   network connection or the access router becoming unreachable - this
   could be particularly frequent for mobile nodes).  With no support
   mechanism, an address change would cause on-going sessions using the
   invalid former address to terminate, and to be restarted using the
   new address.  To avoid this, the node needs a recovery mechanism
   allowing to redirect all current communications to one of its other
   IPv6 addresses.

   In the case of a mobile node changing its point of attachment using
   the same interface, all flows must be redirected to the new location
   in order to maintain sessions.  A mobility management solution may be
   required, such as Mobile IPv6 [10] for mobile hosts or NEMO Basic
   Support [11] for mobile routers.  Additional mechanisms may be needed
   if the node was using several addresses on its old link, such as
   which flow to redirect, which address must be associated with the new
   address(es).  The scalability of the operations involved in the
   redirection of flows may also be an issue, if we consider that the
   node had several addresses on the old link and several flows and/or
   correspondents.  Issues pertaining to Mobile IPv6 and NEMO Basic
   Support are explained in companion drafts [2] and [3] respectively.
















Ernst, et al.            Expires April 26, 2007                [Page 19]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


7.  Conclusion

   In this document we show the concrete need for multihoming at the
   level of the end node.  We emphasized the needs and goals of having
   multiple interfaces at the communicating end node.  Such interfaces
   could be used as one as the replacement of the other (ubiquitous
   access to the Internet, reliability) or simultaneously (load sharing,
   load balancing/flow distribution, preference settings or aggregate
   bandwidth).

   Such goals are motivated for fixed nodes and mobile nodes, but the
   needs prevail for mobile nodes (hosts and routers).  Goals can only
   be met once some issues are solved.  Issues specific to mobile hosts
   and mobile routers are investigated in documents of the MONAMI6 and
   NEMO working groups at the IETF.


8.  Contributors

   This document is based on an earlier document to which Thomas Noel
   (ULP, Strasbourg) and EunKyoung Paik (SNU, Seoul) also participated
   in addition to the authors listed in the present document.


9.  Acknowledgments

   We would like to extend our gratitude to Niko A. Fikouras, Ken
   Nagami, Pekka Savola, Hesham Soliman, and many others who had
   provided valuable comments to this document.


10.  Informative References

   [1]   Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
         Multihoming Architectures", RFC 3582, August 2003.

   [2]   Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
         Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
         draft-ietf-monami6-mipv6-analysis-01 (work in progress),
         June 2006.

   [3]   Ng, C., Paik, E., Ernst, T., and M. Bagnulo, "Analysis of
         Multihoming in Network Mobility Support",
         draft-ietf-nemo-multihoming-issues-06 (work in progress),
         June 2006.

   [4]   Fikouras, N., "Mobile IPv4 Flow Mobility Problem Statement",
         draft-nomad-mip4-flow-mobility-pb-00.txt (work in progress),



Ernst, et al.            Expires April 26, 2007                [Page 20]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


         Feb 2004.

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

   [6]   Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile
         IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-06
         (work in progress), July 2005.

   [7]   Hinden, R. and D. Thaler, "IPv6 Host to Router Load Sharing",
         draft-ietf-ipv6-host-load-sharing-04 (work in progress),
         June 2005.

   [8]   Draves, R. and D. Thaler, "Default Router Preferences and More-
         Specific Routes", RFC 4191, November 2005.

   [9]   Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
         H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
         Paxson, "Stream Control Transmission Protocol", RFC 2960,
         October 2000.

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

   [11]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
         "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
         January 2005.
























Ernst, et al.            Expires April 26, 2007                [Page 21]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


Authors' Addresses

   Thierry Ernst
   INRIA
   INRIA Rocquencourt
   Domaine de Voluceau B.P. 105
   Le Chesnay,   78153
   France

   Phone: +33-1-39-63-59-30
   Fax:   +33-1-39-63-54-91
   Email: thierry.ernst@inria.fr
   URI:   http://www.nautilus6.org/~thierry


   Nicolas Montavont
   Ecole Nationale Superieure des telecommunications de Bretagne
   2, rue de la chataigneraie
   Cesson Sevigne  35576
   France

   Phone: (+33) 2 99 12 70 23
   Email: nicolas.montavont@enst-bretagne.fr
   URI:   http://www-r2.u-strasbg.fr/~montavont/


   Ryuji Wakikawa
   Keio University
   Department of Environmental Information, Keio University.
   5322 Endo
   Fujisawa, Kanagawa  252-8520
   Japan

   Phone: +81-466-49-1100
   Fax:   +81-466-49-1395
   Email: ryuji@sfc.wide.ad.jp
   URI:   http://www.wakikawa.org/














Ernst, et al.            Expires April 26, 2007                [Page 22]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


   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: chanwah.ng@sg.panasonic.com


   Koojana Kuladinithi
   University of Bremen
   ComNets-ikom,University of Bremen.
   Otto-Hahn-Allee NW 1
   Bremen, Bremen  28359
   Germany

   Phone: +49-421-218-8264
   Fax:   +49-421-218-3601
   Email: koo@comnets.uni-bremen.de
   URI:   http://www.comnets.uni-bremen.de/~koo/





























Ernst, et al.            Expires April 26, 2007                [Page 23]


Internet-Draft    Multihoming Motivations and Scenarios     October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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.

   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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Ernst, et al.            Expires April 26, 2007                [Page 24]