Monami6 Working Group T. Ernst
Internet-Draft INRIA
Expires: November 4, 2008 N. Montavont
IT/Telecom Bretagne
R. Wakikawa
Toyota ITC/Keio Univ.
C. Ng
Panasonic Singapore Labs
K. Kuladinithi
University of Bremen
May 3, 2008
Motivations and Scenarios for Using Multiple Interfaces and Global
Addresses
draft-ietf-monami6-multihoming-motivation-scenario-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 4, 2008.
Ernst, et al. Expires November 4, 2008 [Page 1]
Internet-Draft Multihoming Motivations and Scenarios May 2008
Abstract
In this document, multihoming is investigated from an end-node point
of view, and not from a site point of view as the term "multihoming"
is commonly understood so far. The purpose of this document is to
explain the motivations for fixed and mobile nodes (hosts and
routers) using multiple interfaces and the scenarios where this may
end up using multiple global addresses on their interfaces. Such
multihoming configurations can bring a number of benefits once
appropriate support mechanisms are put in place. Interestingly, this
analysis is generic, i.e. motivations and benefits of node
multihoming apply to both fixed end nodes and mobile end nodes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scenarios and Motivations . . . . . . . . . . . . . . . . . . 4
3.1. Need for Ubiquitous Access to the Internet . . . . . . . . 4
3.2. Need to Redirect Established Sessions . . . . . . . . . . 5
3.3. Need to Set Up Preferences . . . . . . . . . . . . . . . . 5
3.4. Need to Select the Best Access Technology . . . . . . . . 5
3.5. Need to Dispatch Traffic over Distinct Paths . . . . . . . 6
3.6. Need for Reliability . . . . . . . . . . . . . . . . . . . 7
3.7. Need to Accelerate Transmission . . . . . . . . . . . . . 7
4. Goals and Benefits of Multihoming . . . . . . . . . . . . . . 8
4.1. Permanent and Ubiquitous Access . . . . . . . . . . . . . 9
4.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Flow Redirection . . . . . . . . . . . . . . . . . . . . . 9
4.4. Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Load Balancing/Flow Distribution . . . . . . . . . . . . . 9
4.6. Preference Settings . . . . . . . . . . . . . . . . . . . 10
4.7. Aggregate Bandwidth . . . . . . . . . . . . . . . . . . . 10
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Case 1: One Interface, Multiple Prefixes . . . . . . . . . 10
5.2. Case 2: Several Interfaces . . . . . . . . . . . . . . . . 12
6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Address Selection . . . . . . . . . . . . . . . . . . . . 14
6.2. Failure Discovery and Recovery Delay . . . . . . . . . . . 15
6.3. Change of Traffic Characteristics . . . . . . . . . . . . 15
6.4. Transparency . . . . . . . . . . . . . . . . . . . . . . . 15
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. Informative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Ernst, et al. Expires November 4, 2008 [Page 2]
Internet-Draft Multihoming Motivations and Scenarios May 2008
1. Introduction
New equipments shipped on the market now often integrate several
access technologies (both wired and wireless). The main purpose of
this integration is to federate all means of communications in order
to access the Internet ubiquitously (from everywhere and at any time)
as no single technology can be expected to be deployed everywhere.
Flows may thus be redirected from one interface to the other
following the loss of connectivity or change of the network
conditions in different access mediums. Besides enabling ubiquitous
Interent access, integrating several access technologies also allows
increased bandwidth availability and selection of the the most
appropriate technology according to the type of flow or choices of
the user, since each access medium has different cost, performance,
bandwidth, access range, and reliability.
Once multiple accesses are offered, users may want to select the most
appropriate set of network interface(s) depending on the network
environment, particularly in wireless networks which are mutable and
less reliable than wired networks. Users may also want to select the
most appropriate interface per communication type or to combine a set
of interfaces to get sufficient bandwidth.
The purpose of this document is to emphasize the goals and benefits
of multihoming for fixed and mobile hosts and routers in a generic
fashion, i.e. without focusing on issues pertaining to hosts, or
routers, or mobility. There are other documents focusing on these.
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 at IPv6, although our analysis may be
applicable to IPv4 as well. The readers may refer to [4] for a
description of the problem specific to Mobile IPv4.
This document is organized as follows. First, the terms used in the
document are defined before illustrating the motivations by means of
some scenarios in Section 3. These scenarios are then used to
emphasize the goals and benefits of multihoming in Section 4.
Following which, Section 5 provides an analysis of the achievable
goals in two multihoming configurations, i.e. when the node either
has a single interface or when it has multiple interfaces. Section 6
concludes this document with a number of generic issues that will
have to be solved in order to effectively meet multihoming goals and
benefits.
Ernst, et al. Expires November 4, 2008 [Page 3]
Internet-Draft Multihoming Motivations and Scenarios May 2008
2. Terminology
This draft is based on the terminology defined in [5]. For the
purpose of clarity, we remind the definition of interface. Terms
related to multihoming are not known to be defined in existing IETF
RFCs.
Interface
A node's point of attachment to a link (as defined in [5])
Multihomed Node
A node (either a host or a router) is multihomed when it has
several global 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.
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 which are later outlined in Section 4. Although most
scenarios focus on wireless technologies, mobility management may not
be involved (one can use wireless access at office).
3.1. Need for Ubiquitous Access to the Internet
Mona is just getting out of a meeting with customers in a building.
She calls her head office. This audio communication is initiated via
a private wireless local area network (WLAN) link realized over one
of the available Wi-Fi hot-spots in the building. This is going to
be a long call and she must attend another meeting a few minutes
drive from here. She walks to a taxi stand, and boards a taxi. The
audio communication is automatically transferred to the public
wireless metropolitan area network (WMAN) over the Wi-Max
metropolitan network deployed, with no interruption of the
communication.
This scenario illustrates the need to use multiple types of access
technologies in order to maintain ongoing communications when a user
is moving out of the coverage area of a specific technology.
Ernst, et al. Expires November 4, 2008 [Page 4]
Internet-Draft Multihoming Motivations and Scenarios May 2008
3.2. Need to Redirect Established Sessions
Oliver is in the passenger lounge waiting for his train. He uses
this opportunity and the presence of a WLAN hot-spot to download the
news from his favorite on-line news channel. While Oliver is
downloading the news, he receives a video call over his wide area 3G
cellular link. The bandwidth and traversal delay of the wide area
cellular link is not adequate for high quality video-conference, so
both flows (video/audio) are transferred to the WLAN link provided by
the hot-spot. This transfer occurs transparently and without
affecting the other active flows.
This scenario illustrates the need for a nomadic user to dynamically
redirect flows from one type of access technology to another based on
some user preferences or traffic requirements.
3.3. Need to Set Up Preferences
Nami works at home for a publishing company using her connection to
the Internet via a low-speed dial up connection, a public and
unrealiable 802.11b WLAN from the street and her 3G cellular phone.
Since the public WLAN is not secure, and the dial-up connection too
slow, Nami checks her company's email using her 3G phone even though
it is expensive. The WLAN service is used for non-confidential
activities, such as web-browsing and video-conferencing, and the
dial-up connection is moslty used to transmit her completed work
securely and synchronizing her file system.
This scenario illustrates the need in a fixed environment to
simultaneously use multiple access technologies and to select the
most appropriate one according to user preferences. No assumptions
are made whether flows need to be redirected or not from one access
technology to another. These preferences can be dynamic (e.g. the
WLAN link is only used if the signal is good and there is no unusual
latency) or configured once for each application (e.g. applications
exchanging confidential data always over the most secure link).
3.4. Need to Select the Best Access Technology
Alice is a paramedic. Her ambulance is called to the scene of a car
accident. She initiates a communication to a hospital via a wide
area cellular link for the relay of low bit-rate live video from the
site of the crash to assess the severity of the accident. It is
identified that one of the passengers has suffered a severe head
injury. Alice decides to consult a specialist via video
conferencing. This session is initiated from the specialist via the
same wide area cellular link. Meanwhile, Alice requests for the
download of the patient's medical records from the hospital servers.
Ernst, et al. Expires November 4, 2008 [Page 5]
Internet-Draft Multihoming Motivations and Scenarios May 2008
The wide area cellular link is too slow for this download, so the
download is transfered to the ambulance satellite link. Even though
this link provides a significantly faster bit rate it has a longer
traversal delay and only downlink is available. Thus, only the
downstream of the download is transferred while upstream proceeds
over the wide area cellular link. Connectivity between the parametic
and the ambulance is managed over a WLAN link. Even though Alice has
performed a partial hand-off for the transfer of the downstream to
the satellite link, the upstream and the video conferencing session
remains on the wide area cellular link. This serves best the time
constraint requirements of the real time communications.
This scenario illustrates the need in a mobile environment for both
ubiquitous access to the Internet using whatever available interface
and the need to dispatch flows to particular access media according
to traffic characteristics or preferences. It also illustrates that
flows can be directed to separate media downlink and uplink. The
fact that the actual connection to the Internet is maintained via the
ambulance to which the paramedic is connected to via a WLAN link
illustrates to need to express preferences on the path to be taken
from a remote computer (i.e. a mobile router in the ambulance in this
case).
3.5. Need to Dispatch Traffic over Distinct Paths
Max drives his car and constantly keeps some sort of Internet
connectivity through one of the many available access technologies
solely managed by a dedicated on-board unit (OBU). Data are further
transmitted to other on-board units. His car navigator downloads
road information from the Internet and his car-audio plays on-line
audio streaming while data collected by sensors is transmitted to the
car manufacturer (e.g. consumption, engine pressure) and safety data
is exchanged between surrounding vehicles (e.g. geographic position,
speed, brakes on/off, accident alerts). Toll bills are paid
automatically and displayed on his navigation screen, while road sign
transmit information (speed limitation, traffic lights).
When his car passes an area where only a wide coverage-range cellular
network is available, safety related sessions are maintained via the
cellular network whereas infotainment data is buffered and
transmitted over high data rate network access when one becomes
available. Toll bills and road sign data are transmitted over a
dedicated radio interface, whereas data exchanged between vehicles is
transmitted over a preferred media. Time-critical safety sessions
are always given priority.
This scenario illustrates the applicability of multihoming in road
transportation and emphasizes more particularly the need to
Ernst, et al. Expires November 4, 2008 [Page 6]
Internet-Draft Multihoming Motivations and Scenarios May 2008
prioritize traffic transiting in a particular access network when
there is a possibility to send data over an alternative route. The
availability of multiple access medium and the variety of on-board
units illustrates a NEMO [6] scenario as currently considered in the
CALM Architecture [7] designed by ISO TC204 WG16 for Intelligent
Transportations Systems (ITS) [8]. The exchange of safety data
illustrates the ongoing work of the car-to-car communication
consortium (C2C-CC) [9].
3.6. Need for Reliability
Ingrid, a doctor, performs an operation via long-distance medical
system. She watches a patient in a battle field over the screen
which delivers real-time images of the patient. Sensors on her arms
deliver her operational actions and a robot performs the actual
operation in the battle field. Since the operation is critical, the
delivery of patient images and Dr. Ingrid's action is done by bi-
casting from/to multiple interfaces bound to a distinct technology or
distinct radio range. So in case packets are delayed or one of the
interface fails to maintain connectivity to the network, her distant
operation can be continued.
This scenario illustrates the need to use multiple access
technologies in order to improve reliability upon failure of one of
the access technologies.
3.7. Need to Accelerate Transmission
Roku is at the airport waiting to board the plane. She receives a
call from her husband. This audio communication is received via a
WLAN link realized over one of the available hot-spots. She knows
this is going to be a long flight and wishes to catch up on some
work. Roku uses a WLAN connection to download the necessary data.
However, there is not enough time before boarding and she decides to
accelerate the download. Her notebook is equipped with an additional
WLAN interface. This additional WLAN interface is then used to
connect to another access point, and the different download flows are
distributed between the two wireless interfaces.
This scenario illustrates the need to use multiple accesses to the
Internet in order to accelerate the amount of data that could be
transmitted over a period of time.
Ernst, et al. Expires November 4, 2008 [Page 7]
Internet-Draft Multihoming Motivations and Scenarios May 2008
4. Goals and Benefits of Multihoming
From the scenarios presented in the previous section, we can
highlight the goals and benefits of node multihoming. The goals
cannot really be distinguished from the benefits, but there are
several situations where multihomed is either advisable or
beneficial. These benefits and goals listed here are by no means
distinct and separate; most of them overlap with one another. It is
not the objective here to classify the benefits and goals into
different non-overlapping consituents. Instead the objective is to
list the possible benefits and goals different people have in mind
when deploying a multihomed node.
+===================================+===========================+
| | Scenarios |
| +---+---+---+---+---+---+---+
| Goals | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+===================================+===+===+===+===+===+===+===+
| Ubiquitous Access | o | | | o | o | | |
+-----------------------------------+---+---+---+---+---+---+---+
| Flow Redirection | o | o | o | o | o | | |
+-----------------------------------+---+---+---+---+---+---+---+
| Reliability | | | o | o | o | o | |
+-----------------------------------+---+---+---+---+---+---+---+
| Load Sharing | | | | | o | | |
+-----------------------------------+---+---+---+---+---+---+---+
| Load Balancing | | | o | o | | | o |
+-----------------------------------+---+---+---+---+---+---+---+
| Preference Settings | | o | o | o | | | |
+-----------------------------------+---+---+---+---+---+---+---+
| Aggregate Bandwidth | | | | o | | | o |
+===================================+===+===+===+===+===+===+===+
| Usage: F=Fixed N=Nomadic M=Mobile | M | N | F | M | M | F | N |
+===================================+===+===+===+===+===+===+===+
Figure 1: Goals Applying to Each Scenario
Figure 1 summarizes which goal applies to the scenarios introduced in
Section 3. Note that all these goals and benefits apply to both
fixed end nodes and mobile end nodes, though the scenarios may either
focus on a fixed used (F), or nomadic usage (N), or a mobile usage
(M). Nomadic and mobile users are both on the move, while a fixed
user doesn't physically move. The difference between nomadic usages
and mobile usages is that sessions are not required to be maintained
when the access network is changed as a result of physical move
within the topology. No assumptions are made whether mobility
support mechanims may be useful or not in any of the fixed, nomadic
and mobile usages in order to maintain sessions. This is out of
Ernst, et al. Expires November 4, 2008 [Page 8]
Internet-Draft Multihoming Motivations and Scenarios May 2008
scope of the present document.
4.1. Permanent and Ubiquitous Access
To provide an extended coverage area via distinct access
technologies.
Multiple interfaces bound to distinct technologies can be used to
ensure a permanent connectivity is offered, anywhere, anytime, with
anyone.
4.2. Reliability
To act upon failure at one point of attachment, i.e. the functions of
a system component (e.g. interface, access network) are assumed by
secondary system components when the primary component becomes
unavailable (e.g. failure). Connectivity is guaranteed as long as at
least one connection to the Internet is maintained.
A potential means is to duplicate network component, another is to
duplicate a particular flow simultaneously through different routes.
This minimizes packet loss typically for real-time communication and
burst traffic. It also minimizes delay of packet delivery caused by
congestion and achieves more reliable real-time communication than
single-casting. For mobile computing, bi-casting avoids dropping
packets when a mobile node changes its interface during communication
[10].
4.3. Flow Redirection
To be able to redirect flows from one interface (or address) to
another without having to re-initiate the flow. This can be due to
preference changes or upon network failure.
4.4. Load Sharing
To spread network traffic load among several routes. This is
achieved when traffic load is distributed among different connections
between the node and the Internet [11].
4.5. Load Balancing/Flow Distribution
To separate a flow between multiple points of attachment
(simultaneously active or not) of a node, usually chosing the less
loaded connection or according to preferences on the mapping between
flows and interfaces.
Ernst, et al. Expires November 4, 2008 [Page 9]
Internet-Draft Multihoming Motivations and Scenarios May 2008
4.6. Preference Settings
This goal is to provide the user, the application or the ISP the
ability to choose the preferred transmission technology or access
network based on cost, efficiency, policies, bandwidth requirement,
delay, etc.
4.7. Aggregate Bandwidth
This goal is to provide the user or the application with more
bandwidth.
Bandwidth available to the user or the application may be limited by
the underlying technology (e.g. GSM has scarce bandwidth) or by some
policies (e.g. monthly rate paid by the user). Multiple interfaces
connected to different links or ISPs can increase the total bandwidth
available to the user or application.
5. Analysis
From the definition of a multihomed node it follows that a multihomed
node has several IPv6 addresses to choose between. In order to
expose the goals and benefits in managing multihomed nodes, we
propose to distinguish two main cases: either the node has only one
interface, or the node has several interfaces. In the former case,
the node is multihomed when multilpe prefixes are advertised on the
link the node is attached to. This distinction is important and
sometimes subtle but the implications are important.
5.1. Case 1: One Interface, Multiple Prefixes
The single-interfaced node is multihomed when several prefixes are
advertised on its interface. The node must therefore configure
several IPv6 addresses.
A typical example is a node with a 802.11b interface, connected to an
access point. The access point is connected trough an Ethernet link
to two access routers. Each access router is configured to advertise
distinct network prefixes by Router Advertisements on the link and
can be used as default router. Several reasons may lead to configure
two access routers on the same link: for instance, the access points
may be shared between different ISPs, or two access routers may be
used for redundancy or load sharing purposes. The node will then
build two global IPv6 addresses on its interface.
We now analyse which of the goals detailed in Section 4 can be met
with this configuration.
Ernst, et al. Expires November 4, 2008 [Page 10]
Internet-Draft Multihoming Motivations and Scenarios May 2008
o Ubiquitous Access: NO
Ubiquitous access cannot be guaranteed when the node loses
Internet connectivity through its sole interface (e.g. the node is
going outside the coverage area of its access point).
o Flow redirection: YES
The node might need to redirect a flow from one address to another
for several reasons. For example, if one of the IPv6 prefix
becomes unavailable, flows using the address from this prefix
could be redirected to the address obtained on the other prefix.
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 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 load sharing
rules. This mostly benefits the network side: if different access
routers or routes can be used to forward the node's traffic, the
traffic load will be shared in the network.
o Load balancing/Flow Distribution: NO
Load balancing cannot be performed when 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 [12]), 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
Ernst, et al. Expires November 4, 2008 [Page 11]
Internet-Draft Multihoming Motivations and Scenarios May 2008
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
that multiple interfaces are used simultaneously. We also note that
multiple interfaces can be connected to the same link as well as to
different links. These configurations will imply different issues.
All these multihomed configurations may yield different benefits to
the node.
A typical example is a node with two interfaces, each one on a
different technology (e.g. a WLAN 802.11b interface and a 3GPP GPRS
interface), in order to benefit from a better coverage area and the
characteristics of each technology.
We now analyse how each of the goals listed in Section 4 can be met
with such multihomed configuration:
o Ubiquitous Access: MAYBE
It is easier to guarantee ubiquitous access when the node has
multiple interfaces since distinct technologies may be available
at a given time according to the location and administrative
policies.
o Flow redirection: YES
In case of a change in user preferences, or a failure, flows might
need to be redirected from one interface to another one. Flows
can be redirected individually or all flows attached to an
interface might be redirected at once.
o Reliability: YES
Two levels of redundancy can be seen in this case: either one
Ernst, et al. Expires November 4, 2008 [Page 12]
Internet-Draft Multihoming Motivations and Scenarios May 2008
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.
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.
Ernst, et al. Expires November 4, 2008 [Page 13]
Internet-Draft Multihoming Motivations and Scenarios May 2008
o Aggregated Bandwidth: YES
With multiple interfaces connected to different links, the node
generally will be able to benefit from an increased aggregated
bandwidth.
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 which case detailed in the
previous section (availability of a single interface or multiple
interfaces). The sign '+', '-' or '=' indicates if 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 Traffic Characteristics | o - | o + |
+------------------------------------+-----+-----+
| Transparency | o + | o + |
+====================================+=====+=====+
Figure 2: Issues and their Importance for Each Case
6.1. Address Selection
The multihomed node has several addresses, which implies the
appropriate address must be chosen when an IPv6 communication is
established (e.g. when a TCP connection is opened). An address
selection mechanism is therefore needed.
The choice of the address can be influenced by many parameters: user
preferences, ingress filtering, preference flag in Router
Advertisement, destination prefix, type of interface, link
characteristics, etc.
Ernst, et al. Expires November 4, 2008 [Page 14]
Internet-Draft Multihoming Motivations and Scenarios May 2008
6.2. Failure Discovery and Recovery Delay
A particular access to the Internet may become unavailable while it
is being used. The time needed for detecting an address has become
invalid and the time to redirect communications to one of its other
addresses is considered critical. Efficient failure detection and
recovery mechanisms are therefore required.
Note that transport sessions with multihoming capabilies such as SCTP
[13] may be able to continue easily since SCTP has built-in
transmission rate control mechanims to take into account the
differences between two paths.
6.3. Change of Traffic Characteristics
The change of path for a specific session (e.g. due to change of
interface) may cause changes on the end-to-end path characteristics
(higher delay, different MTUs, 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. Transparency
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, a recovery mechanism allowing the
redirection of all current communications to one of the other IPv6
addresses is needed.
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 [14] for mobile hosts or NEMO Basic
Support [6] for mobile routers. Additional mechanisms may be needed
if the node was using several addresses on its previous link, such as
which flows shall be to redirected, 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 previous 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 November 4, 2008 [Page 15]
Internet-Draft Multihoming Motivations and Scenarios May 2008
7. Conclusion
In this document we studied multihoming at the level of an end node.
A node is multihomed in a situation where it has multiple addresses,
usually due to the availability of multiple interfaces on the node,
or the announcement of multiple prefixes on the link the node is
attached to. This satisfies a number of needs and brings a number of
potential benefits. The availability of multiple addresses allows
the use of an alternate address as the replacement of another
(permanent and ubiquitous access to the Internet, reliability) or the
transmission of multiple flows simultaneously over different routes
(flow redirection, load sharing, load balancing/flow distribution,
preference settings or aggregate bandwidth).
This study is motivated for both fixed nodes and mobile nodes, but
the motivation prevails for mobile nodes (hosts and routers). The
benefits of multihoming can only be achieved once some issues are
solved. Generic issues were outlined in the present document,
whereas issues specific to mobile hosts and mobile routers are
investigated in the associated documents [2] and [3] and,
respectively.
8. Contributors
This document is based on an earlier document to which Thomas Noel
(ULP, Strasbourg) and EunKyoung Paik (SNU, Seoul) also contributed in
addition to the authors listed in the present document.
9. Acknowledgments
We would like to extend our gratitude to Niko A. Fikouras, Ken
Nagami, Pekka Savola, Hesham Soliman and many others who had provided
valuable comments to this document.
10. Informative References
[1] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.
[2] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-05 (work in progress),
May 2008.
[3] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of
Ernst, et al. Expires November 4, 2008 [Page 16]
Internet-Draft Multihoming Motivations and Scenarios May 2008
Multihoming in Network Mobility Support", RFC 4980,
October 2007.
[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] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[7] "Official web page of ISO TC 204 Working Group 16",
URI: http://www.calm.hu/.
[8] "CALM - Medium and Long Range, High Speed, Air Interfaces
parameters and protocols for broadcast, point to point,
vehicle to vehicle, and vehicle to point communication in the
ITS sector - Networking Protocol - Complementary Element", ISO
Draft ISO/WD 21210, February 2005.
[9] "Car2Car Communication Consortium Official Website",
URI: http://www.car-2-car.org/.
[10] Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile
IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-06
(work in progress), July 2005.
[11] Hinden, R. and D. Thaler, "IPv6 Host to Router Load Sharing",
draft-ietf-ipv6-host-load-sharing-04 (work in progress),
June 2005.
[12] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", RFC 4191, November 2005.
[13] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[14] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
Ernst, et al. Expires November 4, 2008 [Page 17]
Internet-Draft Multihoming Motivations and Scenarios May 2008
Authors' Addresses
Thierry Ernst
INRIA
INRIA Rocquencourt
Domaine de Voluceau B.P. 105
Le Chesnay, 78153
France
Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91
Email: thierry.ernst@inria.fr
URI: http://www.nautilus6.org/~thierry
Nicolas Montavont
Institut Telecom - Telecom Bretagne
2, rue de la chataigneraie
Cesson Sevigne 35576
France
Phone: (+33) 2 99 12 70 23
Email: nicolas.montavont@telecom-bretagne.eu
URI: http://www.rennes.enst-bretagne.fr/~montavont/
Ryuji Wakikawa
Toyota ITC / Keio University
6-6-20 Akasaka, Minato-ku
Tokyo 107-0052
Japan
Phone: +81-3-5561-8276
Fax: +81-3-5561-8292
Email: ryuji@jp.toyota-itc.com
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
Singapore
Phone: +65 65505420
Email: chanwah.ng@sg.panasonic.com
Ernst, et al. Expires November 4, 2008 [Page 18]
Internet-Draft Multihoming Motivations and Scenarios May 2008
Koojana Kuladinithi
University of Bremen
ComNets-ikom,University of Bremen.
Otto-Hahn-Allee NW 1
Bremen, Bremen 28359
Germany
Phone: +49-421-218-8264
Fax: +49-421-218-3601
Email: koo@comnets.uni-bremen.de
URI: http://www.comnets.uni-bremen.de/~koo/
Ernst, et al. Expires November 4, 2008 [Page 19]
Internet-Draft Multihoming Motivations and Scenarios May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Ernst, et al. Expires November 4, 2008 [Page 20]
