Monami6 Working Group T. Ernst
Internet-Draft Keio University / WIDE
Expires: April 27, 2006 N. Montavont
ENST-B
R. Wakikawa
Keio University
E. Paik
KT
C. Ng
Panasonic Singapore Labs
K. Kuladinithi
University of Bremen
T. Noel
LSIIT - ULP
October 24, 2005
Goals and Benefits of Multihoming
draft-ernst-generic-goals-and-benefits-02
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 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Ernst, et al. Expires April 27, 2006 [Page 1]
Internet-Draft Goals and Benefits of Multihoming October 2005
Abstract
This document attempts to define the goals and benefits of
multihoming for fixed and mobile nodes (hosts and routers), i.e. from
a node point of view, as investigated in the Monami6 WG, and not from
a site point of view as investigated in the Shim6 WG. Those goals
and benefits are illustrated with a set of scenarios. This document
is generic in the sense that the benefits of node multihoming can be
shared by both fixed end nodes and mobile end nodes. It is intended
to satisfy the first item as specified on the Monami6 charter and as
such, working group approval as a working group document will be
sought.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scenarios and Motivations . . . . . . . . . . . . . . . . . . 6
3.1. Need to Accelerate Transmission . . . . . . . . . . . . . 6
3.2. Need to Redirect Established Sessions . . . . . . . . . . 6
3.3. Need to Set Up Preferences . . . . . . . . . . . . . . . . 6
3.4. Need for Reliability and Ubiquity . . . . . . . . . . . . 7
3.5. Need for Ubiquitous Access . . . . . . . . . . . . . . . . 7
3.6. Need for Reliability . . . . . . . . . . . . . . . . . . . 8
4. Goals and Benefits of Multihoming . . . . . . . . . . . . . . 9
4.1. Permanent and Ubiquitous Access . . . . . . . . . . . . . 9
4.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Load Balancing/Flow Distribution . . . . . . . . . . . . . 10
4.5. Preference Settings . . . . . . . . . . . . . . . . . . . 10
4.6. Aggregate Bandwidth . . . . . . . . . . . . . . . . . . . 10
5. Classification . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Case 1: One Interface, Multiple Prefixes . . . . . . . . . 11
5.2. Case 2: Several Interfaces . . . . . . . . . . . . . . . . 12
6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Source Address Selection . . . . . . . . . . . . . . . . . 15
6.2. Recovery Delay . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Change of Traffic Characteristics . . . . . . . . . . . . 16
6.4. Address Change . . . . . . . . . . . . . . . . . . . . . . 16
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Ernst, et al. Expires April 27, 2006 [Page 2]
Internet-Draft Goals and Benefits of Multihoming October 2005
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log From Previous Version . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Ernst, et al. Expires April 27, 2006 [Page 3]
Internet-Draft Goals and Benefits of Multihoming October 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 the most appropriate
technology 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 [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: we first define the terms used
in the document 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 multihoming configurations according to
two different cases (the node either has a single interface or
multiple interfaces). We conclude in Section 6 with a number of
generic issues that will have to be solved for the node to benefit
effectively from its multihomed configuration.
Ernst, et al. Expires April 27, 2006 [Page 4]
Internet-Draft Goals and Benefits of Multihoming October 2005
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 (from [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 27, 2006 [Page 5]
Internet-Draft Goals and Benefits of Multihoming October 2005
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).
The first scenario focuses on using two wireless interfaces for the
purpose of increasing aggregate 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 reliabilty.
3.1. Need to Accelerate Transmission
Mona 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. Mona uses a WLAN connection to
download the necessary data. However, there is not enough time and
Mona decides to accelerate the download. Her notebook is equipped
with an additional WLAN interface. Mona decides to use this
additional WLAN interface to connect to another access point, and
distribute the different download flows between the two wireless
interfaces.
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. His train is announced.
Oliver decides to buy a ticket. However, the ticket reservation
service is only available via a wide area cellular link of a specific
provider. While Oliver is downloading the news and accessing the
train ticket reservation service, he receives a phone call over a
wide area cellular link. Oliver 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.
3.3. Need to Set Up Preferences
Nami works at home for a publishing company. She has an in-house
Ernst, et al. Expires April 27, 2006 [Page 6]
Internet-Draft Goals and Benefits of Multihoming October 2005
network and get access to the Internet via ADSL, a public 802.11b
WLAN from the street and satellite. She has subscribed to the
cheapest ADSL service with limited uplink bandwidth. Also, the
satellite link she has access to is downlink only, but it is
extremely cheap for TV broadcasting. She has noticed the 802.11b is
unreliable at some point in time during the day, so she chooses to
send requests and periodic refreshments for joining the TV
broadcasting via ADSL rather than the 802.11b although 802.11b in the
street is free. On the other hand, she has configured her network to
use the 802.11b link at night to publish web content comprising
video. Once a week, she communicates with overseas peer staff by
videoconferencing. Voice being the most important, she has
configured her VoIP session over ADSL. Video is sent at maximum rate
when 802.11b is working fine, otherwise the video is sent at lower
rate.
3.4. Need for Reliability and Ubiquity
Alice is a paramedic. Her ambulance is called at 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. 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 communications.
3.5. Need for Ubiquitous Access
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 WLAN and low-data-rate cellular network are
Ernst, et al. Expires April 27, 2006 [Page 7]
Internet-Draft Goals and Benefits of Multihoming October 2005
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.
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.
Ernst, et al. Expires April 27, 2006 [Page 8]
Internet-Draft Goals and Benefits of Multihoming October 2005
4. Goals and Benefits of Multihoming
We cannot really distinguish the goals from the benefits of
multihoming, but there are several situations where it is either
advisable or beneficial to be multihomed. We use the scenarios
presented in the previous section to highlight the goals and benefits
of multihoming. Figure 1 summarizes which goals apply to any of the
scenario introduced in section Section 3.
+========================================+=======================+
| | Scenarios |
| +---+---+---+---+---+---+
| Goals | 1 | 2 | 3 | 4 | 5 | 6 |
+========================================+===+===+===+===+===+===+
| Ubiquitous Access | ? | ? | | o | o | |
+----------------------------------------+---+---+---+---+---+---+
| Reliability | | | o | o | o | o |
+----------------------------------------+---+---+---+---+---+---+
| Flow Redirection | | o | o | o | o | |
+----------------------------------------+---+---+---+---+---+---+
| Load Sharing | | | | | o | |
+----------------------------------------+---+---+---+---+---+---+
| Load Balalancing | o | | o | o | | |
+----------------------------------------+---+---+---+---+---+---+
| Preference Settings | | o | o | o | | |
+----------------------------------------+---+---+---+---+---+---+
| Aggregate Bandwidth | o | | | o | | |
+========================================+===+===+===+===+===+===+
| Usages: F=Fixed N=Nomadic M=Mobile | N | N | F | M | M | F |
+========================================+===+===+===+===+===+===+
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.
Ernst, et al. Expires April 27, 2006 [Page 9]
Internet-Draft Goals and Benefits of Multihoming October 2005
A potential means 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 [6].
4.3. 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.4. 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.5. 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.6. 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 available bandwith.
Ernst, et al. Expires April 27, 2006 [Page 10]
Internet-Draft Goals and Benefits of Multihoming October 2005
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. In the former case,
the node is multihomed when multilpe prefixes are advertised. 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 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 goals detailed in Section 4 can be met
with this configuration.
o Ubiquitous Access: MAYBE
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 Reliability: MAYBE
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
Ernst, et al. Expires April 27, 2006 [Page 11]
Internet-Draft Goals and Benefits of Multihoming October 2005
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.
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
Ernst, et al. Expires April 27, 2006 [Page 12]
Internet-Draft Goals and Benefits of Multihoming October 2005
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 IEEE 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 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
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.
Ernst, et al. Expires April 27, 2006 [Page 13]
Internet-Draft Goals and Benefits of Multihoming October 2005
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
With multiple interfaces connected to a link, the node generally
will be able to benefit from an increased aggregated bandwidth.
Ernst, et al. Expires April 27, 2006 [Page 14]
Internet-Draft Goals and Benefits of Multihoming October 2005
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 + |
+------------------------------------+-----+-----+
| XXXX MORE TO COME
+------------------------------------+-----+-----+
| XXXX MORE TO COME
+====================================+=====+=====+
Figure 2: Issues and their Importance for Each Case
6.1. Source Address Selection
The multihomed node has several addresses. The appropriate address
must be chosen when an IPv6 communication is established (e.g. when a
TCP connection is opened). This choice can be influenced by many
parameters: user preferences, ingress filtering, preference flag in
Router Advertisement, destination prefix, type of interface, link
characteristics, etc. An address selection mechanism is needed for
this.
6.2. Recovery Delay
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.
However, transport sessions with multihoming capabilies such as SCTP
may be able to continue easily since SCTP has built-in transmission
Ernst, et al. Expires April 27, 2006 [Page 15]
Internet-Draft Goals and Benefits of Multihoming October 2005
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 communication 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 [9] for mobile hosts or NEMO Basic
Support [10] 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 27, 2006 [Page 16]
Internet-Draft Goals and Benefits of Multihoming October 2005
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
need 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.
Ernst, et al. Expires April 27, 2006 [Page 17]
Internet-Draft Goals and Benefits of Multihoming October 2005
8. 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. Fikouras, Hesham Soliman, Ken Nagami, and many
others.
9. 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-montavont-mobileip-multihoming-pb-statement-05 (work in
progress), October 2005.
[3] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of
Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-04 (work in progress),
October 2005.
[4] Fikouras, N., "Mobile IPv4 Flow Mobility Problem Statement",
draft-nomad-mip4-flow-mobility-pb-00.txt (work in progress),
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", draft-ietf-ipv6-router-selection-07 (work in
progress), January 2005.
[9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[10] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
Ernst, et al. Expires April 27, 2006 [Page 18]
Internet-Draft Goals and Benefits of Multihoming October 2005
Appendix A. Change Log From Previous Version
o Moved "Scenarios" up into a "Motivations" section
o Added tables to summarizes goals with respect and issues
o Goal "Increased Bandwidth" replaced with "Aggregated Bandwidth"
o Goal "Redundancy/Fault-Recovery replaced with "Reliability"
o Goal "Bicasting" merged with "Reliability"
o Added issue "Change of Traffic Characteristics "
o Added "Conclusion"
o Minor update everywhere to fit the above mentioned changes
Ernst, et al. Expires April 27, 2006 [Page 19]
Internet-Draft Goals and Benefits of Multihoming October 2005
Authors' Addresses
Thierry Ernst
Keio University / WIDE
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
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@nenst-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.net/
Ernst, et al. Expires April 27, 2006 [Page 20]
Internet-Draft Goals and Benefits of Multihoming October 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: 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/
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 April 27, 2006 [Page 21]
Internet-Draft Goals and Benefits of Multihoming October 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 April 27, 2006 [Page 22]