No Specific Working Group                                       T. Ernst
Internet-Draft                                   WIDE at Keio University
Expires: August 25, 2005                                    N. Montavont
                                                             LSIIT - ULP
                                                             R. Wakikawa
                                                         Keio University
                                                                 E. Paik
                                                                      KT
                                                                   C. Ng
                                                Panasonic Singapore Labs
                                                          K. Kuladinithi
                                                    University of Bremen
                                                                 T. Noel
                                                             LSIIT - ULP
                                                       February 21, 2005


                   Goals and Benefits of Multihoming
               draft-ernst-generic-goals-and-benefits-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 25, 2005.

Copyright Notice



Ernst, et al.            Expires August 25, 2005                [Page 1]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


   Copyright (C) The Internet Society (2005).

Abstract

   This document attempts to define the goals and benefits of
   multihoming for fixed and mobile hosts and routers.  Those goals and
   benefits are illustrated with a set of scenarios.

Table of Contents

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

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  Goals and Benefits of Multihoming  . . . . . . . . . . . . . .  5
     3.1   Permanent and Ubiquitous Access  . . . . . . . . . . . . .  5
     3.2   Redundancy/Fault-Recovery  . . . . . . . . . . . . . . . .  5
     3.3   Load Sharing . . . . . . . . . . . . . . . . . . . . . . .  5
     3.4   Load Balancing . . . . . . . . . . . . . . . . . . . . . .  6
     3.5   Bi-casting (n-casting) . . . . . . . . . . . . . . . . . .  6
     3.6   Preference Settings  . . . . . . . . . . . . . . . . . . .  6
     3.7   Increased Bandwidth  . . . . . . . . . . . . . . . . . . .  6

   4.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1   Load Balancing, Increased Bandwidth (no mobility)  . . . .  7
     4.2   Preference Settings and Transparent Flow Handoffs
           (with mobility)  . . . . . . . . . . . . . . . . . . . . .  7
     4.3   Preference Settings for House Networking (fixed) . . . . .  7
     4.4   Load Balancing, Preference Settings, Increased
           Bandwidth (no mobility)  . . . . . . . . . . . . . . . . .  8
     4.5   Ubiquitous Access and Load Sharing (with mobility) . . . .  8
     4.6   Redundancy and Bi-Casting (with no mobility) . . . . . . .  8

   5.  Classification . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1   Case 1: One Interface, Multiple Prefixes . . . . . . . . .  9
     5.2   Case 2: Several Interfaces . . . . . . . . . . . . . . . . 11

   6.  Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1   Router Selection . . . . . . . . . . . . . . . . . . . . . 14
     6.2   Source Address Selection . . . . . . . . . . . . . . . . . 14
     6.3   Flow Redirection and Broken Sessions . . . . . . . . . . . 14
     6.4   Recovery Delay . . . . . . . . . . . . . . . . . . . . . . 14
     6.5   Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 14

   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15




Ernst, et al.            Expires August 25, 2005                [Page 2]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16

   A.  Change Log From Previous Version . . . . . . . . . . . . . . . 18

       Intellectual Property and Copyright Statements . . . . . . . . 19














































Ernst, et al.            Expires August 25, 2005                [Page 3]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


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 due to
   the loss of connectivity or change of the network conditions.

   Several access technologies are also integrated in order to increase
   bandwidth availability or to select the technology the most
   appropriate according to the type of flow or choices of the user.
   Basically, each network interface has different cost, performance,
   bandwidth, access range, and reliability.  Users are also willing 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 should also be
   able 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, or mobility.

   Issues pertaining to site multihoming in fixed networks are discussed
   in [3].  Mobility issues pertaining to mobile nodes and mobile
   networks are respectively discussed in companion drafts [9] and [8].
   Our document is targetted to IPv6, although our analysis may be
   applicable to IPv4 as well.  The readers may refer to [10] for a
   description of the problem specific to Mobile IPv4.

   This document is organized as follows: we first define the terms used
   in the document before emphasizing the goals and benefits of
   multihoming in Section 3.  Then, the needs for multihoming are
   illustrated through a set of scenarios in Section 4.  Next follows an
   analysis in Section 5 of two different cases where a multihomed node
   has either a single interface or multiple interfaces.

2.  Terminology

   This draft is based on the terminology defined in [2].  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.





Ernst, et al.            Expires August 25, 2005                [Page 4]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


   Interface

      A node's point of attachment to a link (from [2])

   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.

   Multihomed Network

      From the above definition, it follows that a network is multihomed
      when either the network is simultaneously connected to the
      Internet via more than one router, or when a router is
      multi-prefixed or multi-interfaced.


3.  Goals and Benefits of Multihoming

   We cannot distinguish the goals from the benefits of multihoming, but
   there are several situations where it is either advisable or
   beneficial to be multihomed:

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

3.2  Redundancy/Fault-Recovery

   To act upon failure of one point of attachment, i.e.  the functions
   of a system component 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.

3.3  Load Sharing

   To spread network traffic load among several routes.  This is
   achieved when traffic load is distributed among different connections



Ernst, et al.            Expires August 25, 2005                [Page 5]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


   between the node and the Internet [7].

3.4  Load Balancing

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

3.5  Bi-casting (n-casting)

   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 [1].

3.6  Preference Settings

   To provide the user or the application or the ISP the ability to
   choose the preferred transmission technology or access network.  for
   matters of cost, efficiency, politics, bandwidth requirement, delay,
   etc.

3.7  Increased Bandwidth

   To provide the user or the application with more bandwidth than is
   available with any one interface.  Multiple interfaces connected to
   different links can increase the total available bandwith.

4.  Scenarios

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

   The first scenario focuses on using two wireless interfaces for the
   purpose of increasing bandwidth while the second shows the usage of
   preference settings.  The third is a combination of the first two.
   The fourth and fifth illustrate how multiple connections can provide
   ubiquitous Internet access and how load can be balanced according to
   some preferences.  The last one illustrates redundancy and
   bi-casting.





Ernst, et al.            Expires August 25, 2005                [Page 6]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


4.1  Load Balancing, Increased Bandwidth (no mobility)

   Alice is at the airport waiting to board the plane.  She receives a
   call from her husband.  This audio communication is received via a
   wireless local area network (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.  Alice uses a WLAN connection to
   download the necessary data.  However, there is not enough time and
   Alice decides to accelerate the download.  Her notebook is equipped
   with an additional WLAN interface.  Alice decides to use this
   additional WLAN interface to connect to another access point, and
   distribute the different download flows between the two wireless
   interfaces.

4.2  Preference Settings and Transparent Flow Handoffs (with mobility)

   Mr.  Smith 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.  His train is announced.
   Mr.  Smith decides to buy a ticket.  However, the ticket reservation
   service is only available via a wide area cellular link of a specific
   provider.  While Mr.  Smith is downloading the news and accessing the
   train ticket reservation service, he receives a phone call over a
   wide area cellular link.  Mr.  Smith decides he wishes 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 any other active flows.

4.3  Preference Settings for House Networking (fixed)

   Mr.  Verne works at home for a publishing company.  He has an
   in-house network and get access to the Internet via ADSL, a public
   802.11b WLAN from the street and satellite.  He has subscribed to the
   lowest ADSL service with limited upward bandwidth.  The satellite
   link he has access to is only downward but is extremely cheap for TV
   broadcasting.  He has noticed the 802.11b is unreliable at some point
   in time during the day, so he chooses to send requests and periodic
   refreshments for joining the TV broadcasting via ADSL rather the
   802.11b although 802.11b in the street is free.  On the other hand,
   he has configured his network to use the 802.11b link at night to
   publish web content comprising video.  Once a week, he communicate
   with overseas peer staff by videoconferencing.  Voice being the most
   important, he has configured his VoIP session over ADSL.  Video is
   sent at maximum rate when 802.11b is working fine, otherwise the
   video is sent at lower rate.




Ernst, et al.            Expires August 25, 2005                [Page 7]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


4.4  Load Balancing, Preference Settings, Increased Bandwidth (no
    mobility)

   An ambulance is called at the scene of a car accident.  A paramedic
   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.  The paramedic
   decides to consult a specialist via video conferencing.  This session
   is initiated from the specialist via the same wide area cellular
   link.  Meanwhile, the paramedic requests for the download of the
   patient medical records from the hospital servers.  The paramedic
   decides in mid-session that the wide area cellular link is too slow
   for this download and 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 the paramedic
   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
   communication.

4.5  Ubiquitous Access and Load Sharing (with mobility)

   Jules 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 WLAN and low-data-rate cellular network are
   available, it distributes load to the WLAN access and the cellular
   network access.  When his car passes an area where only a wide
   coverage-range cellular network is available, it maintains its
   connection via the cellular network.

4.6  Redundancy and Bi-Casting (with no mobility)

   Dr.  Catherine 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 action and a robot performs her operation in
   the battle field.  Since the operation is critical, the delivery of
   patient images and Catherine'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



Ernst, et al.            Expires August 25, 2005                [Page 8]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


   to maintain connectivity to the network, her distant can be
   continued.

5.  Classification

   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.

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.  The node has to choose which address to use
   when an IPv6 communication is established (e.g.  open a TCP
   connection).  This choice can be influenced by many parameters: user
   preference, different price on prefixes, preference flag in Router
   Advertisement, destination prefix, etc.  An address selection
   mechanism is needed.

   A typical example is a node with an IEEE 802.11 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 send
   Router Advertisements on the link and can be used as default router.
   Several reasons may lead to configure two access routers are 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 benefits detailed in Section 3 can be
   attained for this configuration.


   o  Ubiquitous Access

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


   o  Redundancy

      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 should allow the node to recover this sort of



Ernst, et al.            Expires August 25, 2005                [Page 9]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


      failure.  However transparency may not be achieved since on-going
      sessions using the invalid address would have to be terminated,
      and restarted using the new address.  To avoid this, the node
      needs a recovery mechanism allowing to redirect all current
      communication to one of its other IPv6 address.  The time needed
      for the detection of the prefix failure and the time to redirect
      communications to one of its other addresses is considered as
      critical.


   o  Load sharing

      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

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


   o  Bi-casting

      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.  Although packets can not be
      distributed to different interfaces on the node, bi-casting would
      allow the node to seamlessly change the address used on the node
      if such a protocol is used to change address of on-going flow.
      Time synchronization can be an issue in this case.  If we use
      different access technologies or routes for each casting, the
      round trip time (RTT) can differ from casting to casting.  Thus
      the receiver will receive the same contents at different times.


   o  Preference

      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 [6], or by the ISP.





Ernst, et al.            Expires August 25, 2005               [Page 10]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


   o  Increased Bandwidth

      With only one interface connected to a link, the node generally
      will not be able to enjoy increased 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.


5.2  Case 2: Several Interfaces

   In this case, the node may use its multiple interfaces either
   alternatively or simultaneously.  If used alternatively, the node is
   either multihomed if multiple prefixes are advertised on its current
   link (case 1, one interface), or not multihomed if only one prefix is
   advertised on its current link.  We will thus assume that multiple
   interfaces are used simultaneously.  At least one IPv6 address will
   be configured per interface (or several addresses per interface if
   several prefixes are announced on the link(s) it is connected to).
   Also, multiple interfaces can be connected to the same link as well
   as to different links.  These configurations will imply different
   issues.

   An address selection mechanism is also needed, but this time the
   interface on which the address is bound to will be a supplementary
   parameter in the address selection.  The different characteristics of
   each interface may help to decide first which interface to use.

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

   This multihomed configuration may yield different benefits to the
   node.  We now analyse how each of the benefits listed in Section 3
   could be applied:


   o  Ubiquitous Access

      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.  However, the node must be able to use several



Ernst, et al.            Expires August 25, 2005               [Page 11]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


      technologies at the same time and to maintain Internet
      connectivity while a technology can not be used.  It is obvious
      that the node must have the choice to use any of the available
      technologies, and that this choice must not prevent the node to
      redirect a communication to another interface/address.


   o  Redundancy

      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
      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.  In both
      cases, transparency of the addressses switching is an important
      issue.

      Loss of a prefix: If the node loses one of its prefix, it can no
      longer use the corresponding address anymore.  So the node needs a
      recovery mechanism that allows it to transfer all current
      communications to one of its other IPv6 address(es).  The time
      needed for the detection of the prefix failure and the time to
      redirect communications to one of its other addresses may be
      critical.

      Interface failure: If one of the used interface breaks down (loss
      of network connection or access router is not reachable anymore),
      the node must be able to redirect all its flows from that
      interface to one of the alive interfaces.  The time needed to
      discover the failure and to redirect each flow has to be
      considered.  The scalability of such a solution is also an issue.

      Mobility of the node: If the node moves to a new point of
      attachment in another subnet, it will need to change its IPv6
      addresses.  In order to maintain all its previous communications,
      it will need to redirect the flows to its new point of attachment,
      whatever the old address used for the flow.  The scalability of
      the redirection can also be considered here.





Ernst, et al.            Expires August 25, 2005               [Page 12]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


   o  Load Sharing

      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

      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  Bi-casting

      Bi-casting might be used to ensure the packets delivery on the
      node.  It 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  Preferences

      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  Increased Bandwidth

      With multiple interface connected to a link, the node generally
      will be able to enjoy increased bandwidth.







Ernst, et al.            Expires August 25, 2005               [Page 13]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


6.  Issues

   In this section, we attempt to list a number of generic issues
   [[Comment.1: Tentative section under construction --Note]]

6.1  Router Selection

   Each access router the node is connected to might have different
   capacity.  For example, if the network the node is located in (either
   a fixed network or a mobile network) is connected to the Internet via
   2 routers, each path may have very different bandwidth and delay.
   This would have a strong impact on the node behind those routers.
   Therefore, it is desirable for the node to obtain enough information
   so that it can choose its best default router.

6.2  Source Address Selection

   The node has to choose which address to use when an IPv6
   communication is established (e.g.  open a TCP connection).  This
   choice can be influenced by many parameters: user preference,
   different price on prefixes, preference flag in Router Advertisement,
   destination prefix, etc.  An address selection mechanism is needed.

6.3  Flow Redirection and Broken Sessions

   Sessions may break as a result of diverting from one interface or
   prefix to another.  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
   communication to one of its other IPv6 address.

6.4  Recovery Delay

   The time needed for the detection an address has become invalid and
   the time to redirect communications to one of its other addresses is
   considered as critical.

6.5  Mobility

   A node which moves to a new point of attachment in another subnet
   must obtain a new IPv6 address on the new link.  In order to maintain
   sessions, all flows must be redirected to the new location and a
   mobility management solution may be required, such as Mobile IPv6 [4]
   or NEMO Basic Support [5].  More 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



Ernst, et al.            Expires August 25, 2005               [Page 14]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


   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 are explained in companion drafts
   [9] and [8].

7.  Acknowledgments

   We would like to thank all the people who have provided comments on
   this draft, and also co-authors of earlier documents in which authors
   of this present document have been engaged.  As such, we would like
   to thank Niko A.  Figouras, Hesham Soliman, Ken Nagami, and many
   others.

8.  References

   [1]   Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile
         IPv6 Fast Handovers",
         Internet-Draft draft-elmalki-mobileip-bicasting-v6-05, November
         2003.

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

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

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

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

   [6]   Draves, R. and D. Thaler, "Default Router Preferences and
         More-Specific Routes",
         Internet-Draft draft-ietf-ipv6-router-selection-06, October
         2004.

   [7]   Hinden, R., "IPv6 Host to Router Load Sharing",
         Internet-Draft draft-ietf-ipv6-host-load-sharing-03, October
         2004.

   [8]   Ng, C., Paik, E. and T. Ernst, "Analysis of Multihoming in
         Network Mobility Support",
         Internet-Draft draft-ietf-nemo-multihoming-issues-02, February
         2005.

   [9]   Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of



Ernst, et al.            Expires August 25, 2005               [Page 15]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


         Multihoming in Mobile IPv6",
         Internet-Draft draft-montavont-mobileip-multihoming-pb-statement-03
         , January 2005.

   [10]  Fikouras, N., "Mobile IPv4 Flow Mobility Problem Statement",
         Internet-Draft draft-nomad-mip4-flow-mobility-pb-00.txt, Feb
         2004.


Authors' Addresses

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

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


   Nicolas Montavont
   LSIIT - Univerity Louis Pasteur
   Pole API, bureau C444
   Boulevard Sebastien Brant
   Illkirch  67400
   FRANCE

   Phone: (33) 3 90 24 45 87
   Email: montavont@dpt-info.u-strasbg.fr
   URI:   http://www-r2.u-strasbg.fr/~montavont/


   Ryuji Wakikawa
   Keio University
   Jun Murai Lab., 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.mobileip.jp/




Ernst, et al.            Expires August 25, 2005               [Page 16]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


   Eun Kyoung Paik
   KT
   Portable Internet Team, Convergence Lab., KT
   17 Woomyeon-dong, Seocho-gu
   Seoul  137-792
   Korea

   Phone: +82-2-526-5233
   Fax:   +82-2-526-5200
   Email: euna@kt.co.kr
   URI:   http://mmlab.snu.ac.kr/~eun/


   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


   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/


   Thomas Noel
   LSIIT - Univerity Louis Pasteur
   Pole API, bureau C444
   Boulevard Sebastien Brant
   Illkirch  67400
   FRANCE

   Phone: (33) 3 90 24 45 92
   Email: noel@dpt-info.u-strasbg.fr
   URI:   http://www-r2.u-strasbg.fr/~noel/




Ernst, et al.            Expires August 25, 2005               [Page 17]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


Appendix A.  Change Log From Previous Version

   o  Added tentative section "Issues"

   o  Typos, rephrasing, added sub-sections into TOC, updated
      references, added ACK section













































Ernst, et al.            Expires August 25, 2005               [Page 18]


Internet-Draft      Goals and Benefits of Multihoming      February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

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


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

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




Ernst, et al.            Expires August 25, 2005               [Page 19]