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

Versions: 00 draft-ernst-generic-goals-and-benefits

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


                   Goals and Benefits of Multihoming
            draft-multihoming-generic-goals-and-benefits-00

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 August 9, 2004.

Copyright Notice

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

Abstract

   This document attempts to define the goals and benefits of



Ernst, et al.            Expires August 9, 2004                 [Page 1]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


   multihoming for fixed and mobile hosts and routers. Those goals and
   benefits are illustrated with a set of real-life scenarios.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3

   2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .   3

   3. Goals and Benefits of Multihoming  . . . . . . . . . . . . . .   4

   4. Cases  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5

   5. Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .   7

   6. Configurations . . . . . . . . . . . . . . . . . . . . . . . .   9

   7. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  12

      References . . . . . . . . . . . . . . . . . . . . . . . . . .  12

      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  12

      Intellectual Property and Copyright Statements . . . . . . . .  15



























Ernst, et al.            Expires August 9, 2004                 [Page 2]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


1. Introduction

   New equipments shipped on the market now often integrate several
   wireless technologies.

   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) since a permanent Internet connectivity
   is now required by some applications. Unfortunately, there is no
   network interfaces assuring global scale connectivity. Nodes must
   thus use various type of network interfaces to obtain wide area
   network connectivity [8].

   New equipments also integrate several access technologies 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 should thus be able
   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 show real-life scenarios in order
   to illustrate 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. Specific
   mobility issues pertaining to mobile nodes and mobile networks are
   discussed in companion drafts [6], [5] and [7].

   This document is organized as follows: we first define the terms used
   in the document before emphasizing the goals and benefits of
   multihoming. Next follows a differentiation between cases where a
   multihomed node has a single interface and the cases where it has
   multiple interfaces. Then, we describe some real-life scenarios to
   illustrate the goals and benefits of multihoming and we conclude with
   the description of possible configurations at the network layer.

2. Terminology

   In this section we define terms related to multihoming:

   Interface (from [2])

      A node's attachment to a link





Ernst, et al.            Expires August 9, 2004                 [Page 3]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


   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:

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

         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 of multihoming from the benefits of
   being multihomed, but we can identify several situations where it is
   either advisable or beneficial to be multihomed:

   Ubiquitous Access:

      To provide an extended coverage area. Multiple interfaces bound to
      distinct technologies can be used to ensure a permanent
      connectivity is offered.

   Redundancy/Fault-Recovery:

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

   Load Sharing:

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






Ernst, et al.            Expires August 9, 2004                 [Page 4]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


   Load Balancing:

      To balance load between multiple point of attachments
      (simultaneously active or not), usually chosing the lest loaded
      connection.

   Bi-casting:

      Bi-casting (n-casting) duplicates a particular flow for
      simultaneous transmission through different routes. It minimizes
      packet loss typically for real-time communication and burst
      traffic. It also minimizes delay of packet delivery caused by
      congestions and achieves more reliable real-time communication
      than single-casting. For mobile computing, bi-casting is useful
      not to drop packets when a mobile node changes its interface
      during communication [1].

   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.

   When considering these goals/benefits, one has to consider whether
   these goals can be achieved with transparency or without
   transparency.  Transparency is achieved when switching to a different
   point of attachment does not cause on-going sessions to break.

   For instance, ubiquity with transparency is achieved when switching
   between two different access mechanism does not cause on-going
   sessions to be disrupted.

   In order to achieve transparency, a necessary (may or may not be
   sufficient) condition is for the end-point addresses to remain
   unchanged.  This is in-view of the large amount of Internet traffic
   today are carried by TCP, which unlike SCTP, cannot handle multiple
   end-point address pairs.

4. Cases

   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. A rough analysis of these two
   cases is detailed below.




Ernst, et al.            Expires August 9, 2004                 [Page 5]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


   Case 1: One Interface

      The node has one interface. It is multihomed when several prefixes
      are advertised on its interface. The node must therefore configure
      several IPv6 addresses. An address selection mechanism is needed.

      This multihomed configuration may yield the following benefits for
      the node:

      *  Load sharing can be performed in the network

      *  Redundancy: In case of failure of one IPv6 prefix, one of the
         address of the node will not be valid anymore. The fact that
         the node has another address built with other prefixes should
         allow it to recover this sort of failure, however transparency
         may not achieved since on-going sessions using the invalid
         address would have to be terminated, and restarted using the
         new address.  It is also to be noted that all sessions on the
         node will be disrupted if all prefixes fail to be announced
         (e.g. all were announced by the same router and this router
         broke down).

      *  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 [3], or by ISP.

   Case 2: Several Interfaces

      The node has more than one interface. The node must therefore
      configure several IPv6 addresses (one on each interface). An
      address selection mechanism is needed.

      This multihomed configuration may yield the following benefits for
      the node:

      *  Load balancing: between the interfaces

      *  Redundancy: another interface can be used if one fails

      *  Ubiquity: it is more likely to have access to another
         technology if a technology cannot be used

      *  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



Ernst, et al.            Expires August 9, 2004                 [Page 6]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


         supplementary parameter in the address selection algorithm.


5. Scenarios

   The following scenarios highlight the usage of several interfaces and
   the benefit of such configuration. Each scenario usually yields more
   than one benefit. The first scenario focuses on using two wireless
   interfaces for the purpose of balancing the load while 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.

   Scenario 1: Load Balancing

      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 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 wireless LAN 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 wireless local area network interface. Alice
      decides to distribute the different download flows between the
      wireless interfaces to accelerate the download.

   Scenario 2: Preference Settings and Transparent Flow Handoffs

      Mr. Smith is on his way to work waiting at a train station. He
      uses this opportunity and the presence of a wireless LAN 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 a wireless local area link
      via a hot-spot. This transfer occurs transparently and without
      affecting any other active flows.

   Scenario 3: Preference Settings for House Networking





Ernst, et al.            Expires August 9, 2004                 [Page 7]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


      Mr. Vernes 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. The satellite link he
      has access to is only downward but is extremely cheap for TV
      broadcasting. He chooses to send requests for joining the TV
      broadcasting via ADSL rather the 802.11b although 802.11b in the
      street is free. He has noticed the 802.11b is unreliable at some
      point in time during the day. 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 one
      picture every 5 sec over ADSL.

   Scenario 4: Ubiquitous Access, Load Balancing, Preference Setting

      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 wireless local area 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.

   Scenario 5: Ubiquitous Access and Load Sharing

      Jules drives his car to a new place and constantly keeps some sort
      of Internet access through one the access technology. His car
      navigator downloads road information from the internet and his
      car-audio serves on-line audio streaming. When his car passes an
      area where both high-data-rate WLAN and low-data-rate cellular
      network available, it distributes load to WLAN and cellular



Ernst, et al.            Expires August 9, 2004                 [Page 8]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


      connection. When his car passes an area where only
      wide-coverage-range cellular network is available, it maintains
      its connection via the cellular network.  When Bob passes an area
      where even cellular networks can not be reached, he can switch to
      the expensive satellite network with multiple interfaces that his
      car support.

   Scenario 6: Redundancy and Bi-Casting

      Catherine performs an operation via long-distance medical system.
      She watches a patient in a battle field over the screen which
      delivers real-time image 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 image and Catherine's action is done by bi-casting
      from/to multiple interface. So in case of one of the interface
      failed, Catherine can continue her long-distance operation.


6. Configurations

   This section details the possible network configurations that are
   considered important. Possible configurations may involve either a
   fixed host, a mobile host, a fixed router or a mobile router.

   Case 1: One Interface

      A typical case of this scenario 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 Advertisement on the
      link and can be used as default router. Several reasons may lead
      to the fact that 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.

      In that case, the node will build two global IPv6 addresses on its
      interface. When the node establishes an IPv6 communication (e.g.
      open a TCP connection), it has to choose which address to use.
      This choice can be influenced by many parameters: user preference,
      different price on prefixes, preference flag in Router
      Advertisement, destination prefix...

      The critical points that can be highlighted here are the
      following:

      *  Choice of the router: each access router the node is be



Ernst, et al.            Expires August 9, 2004                 [Page 9]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


         connected to might have different capacity. As an example, if
         the node is inside a mobile network and is connected to two
         mobile routers, each mobile router may implement different
         technology on their egress interface. This would have a strong
         impact on the node traffic.

      *  Load Sharing: This benefit is mainly for the network side: if
         different access routers or routes can be used to forward the
         node traffic, it will share the traffic load on the network.

      *  Lost of a prefix: If the node looses one of its prefix, it can
         not use the corresponding address anymore. So the node needs a
         recovery mechanism allowing to remove 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.

      *  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 communication,
         it will need to redirect the flows to its new location,
         whatever the old address used for the flow. The scalability of
         the redirection can also be considered here.

   Case 2: Multiple Interfaces

      The typical case of this scenario is a node that has two
      interfaces, each on a different technology, in order to benefit a
      better coverage area (ubiquitous access) and the capacity and
      specification of each technology. Such an example is to have a
      WLAN interface (e.g. IEEE 802.11b) and a 3GPP interface (e.g.
      GPRS). In this case, the node may use its two interfaces either
      alternatively or simultaneously. If it alternatively uses its two
      interfaces, the node falls into case one (multiple prefixes and
      one interface) and is multihomed or the node is not multihomed. In
      the following, we thus consider that the node simultaneously uses
      its two interfaces.

      In this case, the node will have one or several addresses per
      interface according to the number of prefixes announced on the
      link(s) it is connected to. Also, the two interfaces can be
      connected to the same link as well as to different link. When
      considering such a multihoming management, it might imply
      different issues. Once more this node will have to make a choice
      between its different addresses, but the interface on which the
      address is bound to will be a supplementary parameter in the
      address selection. The different characteristics of each interface



Ernst, et al.            Expires August 9, 2004                [Page 10]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


      may help to decide first which interface to use.

      The critical points that can be highlighted here are the
      following:

      *  Choice of the router: each access router the node is be
         connected to might have different capacity. As an example, if
         the node is inside a mobile network and is connected to two
         mobile routers, each mobile router may implement different
         technology on their egress interface. This would have a strong
         impact on the node traffic.

      *  Load Balancing: As the node has several available interfaces at
         the same time, it is interesting to simultaneously use them for
         different flows. To do so, the node must be able to choose a
         different interface for each new communication (through the
         address selection).

      *  Load Sharing: This benefit is mainly for the network side: if
         different access routers or routes can be used to forward the
         node traffic, it will share the traffic load on the network.

      *  Lost of a prefix: If the node looses one of its prefix, it can
         not use the corresponding address anymore. So the node needs a
         recovery mechanism allowing to remove 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.

      *  Interface failure: If one of the used interface breaks down
         (lost of network connection of access router is not reachable
         anymore), the node must be able to redirect all its flows from
         that interface to one of the alive interface. 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 communication,
         it will need to redirect the flows to its new localization,
         whatever the old address used for the flow. The scalability of
         the redirection can also be considered here.







Ernst, et al.            Expires August 9, 2004                [Page 11]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


7. Acknowledgments

References

   [1]  Elmalki, K. and H. Soliman, "Simultaneous Bindings for Mobile
        IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-05.txt
        (work in progress), October 2003.

   [2]  Manner, J. and M. Kojo, "Mobility Related Terminology",
        draft-ietf-seamoby-terminology-04 (work in progress), April
        2003.

   [3]  Draves, R. and D. Thaler, "Default Router Preferences,
        More-Specific Routes, and Load Sharing",
        draft-ietf-ipv6-router-selection-03 (work in progress), December
        2003.

   [4]  Hinden, R. and D. Thaler, "IPv6 Host to Router Load Sharing",
        draft-ietf-ipv6-host-load-sharing-01 (work in progress), January
        2004.

   [5]  Ng, C., "Multihoming Issues in Network Mobility Support",
        draft-xxx-nemo-multihoming-00 (work in progress), Feb 2004.

   [6]  Montavont, N., "Analysis of Multihoming in Mobile IPv6",
        draft-xxx-nemo-multihoming-00 (work in progress), Feb 2004.

   [7]  Fikouras, N., "Mobile IPv4 Flow Mobility",
        draft-nomad-mip4-flow-mobility-problem-statement-00.txt (work in
        progress), Feb 2004.

   [8]  Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay
        Networks", Journal Mobile Networks and Applications, vol. 3,
        number 4, pages 335-350, 1998.

















Ernst, et al.            Expires August 9, 2004                [Page 12]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


Authors' Addresses

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

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


   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/


   Wakikawa Ryuji
   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 9, 2004                [Page 13]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


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

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


   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 9, 2004                [Page 14]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


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



Ernst, et al.            Expires August 9, 2004                [Page 15]

Internet-Draft     Goals and Benefits of Multihoming       February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Ernst, et al.            Expires August 9, 2004                [Page 16]


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