draft-ietf-monami6-multihoming-motivation-scenario-01.txt   draft-ietf-monami6-multihoming-motivation-scenario-02.txt 
Monami6 Working Group T. Ernst Monami6 Working Group T. Ernst
Internet-Draft INRIA Internet-Draft INRIA
Intended status: Informational N. Montavont Expires: January 13, 2008 N. Montavont
Expires: April 26, 2007 GET/ENST-B GET/ENST-B
R. Wakikawa R. Wakikawa
Keio University Keio University
C. Ng C. Ng
Panasonic Singapore Labs Panasonic Singapore Labs
K. Kuladinithi K. Kuladinithi
University of Bremen University of Bremen
October 23, 2006 July 12, 2007
Motivations and Scenarios for Using Multiple Interfaces and Global Motivations and Scenarios for Using Multiple Interfaces and Global
Addresses Addresses
draft-ietf-monami6-multihoming-motivation-scenario-01.txt draft-ietf-monami6-multihoming-motivation-scenario-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2007. This Internet-Draft will expire on January 13, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
In this document, multihoming is investigated from a node point of In this document, multihoming is investigated from an end-node point
view, and not from a site point of view as the term "multihoming" is of view, and not from a site point of view as the term "multihoming"
commonly understood so far. The purpose of this document is to is commonly understood so far. The purpose of this document is to
explain the motivations for fixed and mobile nodes (hosts and explain the motivations for fixed and mobile nodes (hosts and
routers) using multiple interfaces and the scenarios where this may routers) using multiple interfaces and the scenarios where this may
end up using multiple global addresses on their interfaces. Such end up using multiple global addresses on their interfaces. Such
multihoming configurations can bring a number of benefits once multihoming configurations can bring a number of benefits once
appropriate support mechanisms are put in place. Interestingly, this appropriate support mechanisms are put in place. Interestingly, this
analysis is generic, i.e. motivations and benefits of node analysis is generic, i.e. motivations and benefits of node
multihoming apply to both fixed end nodes and mobile end nodes. multihoming apply to both fixed end nodes and mobile end nodes.
Table of Contents Table of Contents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scenarios and Motivations . . . . . . . . . . . . . . . . . . 6 3. Scenarios and Motivations . . . . . . . . . . . . . . . . . . 6
3.1. Need for Ubiquitous Access to the Internet . . . . . . . . 6 3.1. Need for Ubiquitous Access to the Internet . . . . . . . . 6
3.2. Need to Redirect Established Sessions . . . . . . . . . . 6 3.2. Need to Redirect Established Sessions . . . . . . . . . . 6
3.3. Need to Set Up Preferences . . . . . . . . . . . . . . . . 6 3.3. Need to Set Up Preferences . . . . . . . . . . . . . . . . 6
3.4. Need to Select the Best Access Technology . . . . . . . . 7 3.4. Need to Select the Best Access Technology . . . . . . . . 7
3.5. Need to Dispatch Traffic over Distinct Paths . . . . . . . 8 3.5. Need to Dispatch Traffic over Distinct Paths . . . . . . . 8
3.6. Need for Reliability . . . . . . . . . . . . . . . . . . . 8 3.6. Need for Reliability . . . . . . . . . . . . . . . . . . . 8
3.7. Need to Accelerate Transmission . . . . . . . . . . . . . 8 3.7. Need to Accelerate Transmission . . . . . . . . . . . . . 9
4. Goals and Benefits of Multihoming . . . . . . . . . . . . . . 10 4. Goals and Benefits of Multihoming . . . . . . . . . . . . . . 10
4.1. Permanent and Ubiquitous Access . . . . . . . . . . . . . 11 4.1. Permanent and Ubiquitous Access . . . . . . . . . . . . . 11
4.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Flow Redirection . . . . . . . . . . . . . . . . . . . . . 12 4.3. Flow Redirection . . . . . . . . . . . . . . . . . . . . . 12
4.4. Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Load Balancing/Flow Distribution . . . . . . . . . . . . . 12 4.5. Load Balancing/Flow Distribution . . . . . . . . . . . . . 12
4.6. Preference Settings . . . . . . . . . . . . . . . . . . . 12 4.6. Preference Settings . . . . . . . . . . . . . . . . . . . 12
4.7. Aggregate Bandwidth . . . . . . . . . . . . . . . . . . . 12 4.7. Aggregate Bandwidth . . . . . . . . . . . . . . . . . . . 12
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Case 1: One Interface, Multiple Prefixes . . . . . . . . . 13 5.1. Case 1: One Interface, Multiple Prefixes . . . . . . . . . 13
5.2. Case 2: Several Interfaces . . . . . . . . . . . . . . . . 15 5.2. Case 2: Several Interfaces . . . . . . . . . . . . . . . . 15
6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. <!--Source-->Address Selection . . . . . . . . . . . . . . 18 6.1. <!--Source-->Address Selection . . . . . . . . . . . . . . 18
6.2. Failure Discovery and Recovery Delay . . . . . . . . . . . 18 6.2. Failure Discovery and Recovery Delay . . . . . . . . . . . 18
6.3. Change of Traffic Characteristics . . . . . . . . . . . . 19 6.3. Change of Traffic Characteristics . . . . . . . . . . . . 19
6.4. Address Change . . . . . . . . . . . . . . . . . . . . . . 19 6.4. Transparency . . . . . . . . . . . . . . . . . . . . . . . 19
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. Informative References . . . . . . . . . . . . . . . . . . . . 20 10. Informative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 24
skipping to change at page 6, line 22 skipping to change at page 6, line 22
3.1. Need for Ubiquitous Access to the Internet 3.1. Need for Ubiquitous Access to the Internet
Mona is just getting out of a meeting with customers in a building. Mona is just getting out of a meeting with customers in a building.
She calls her head office. This audio communication is initiated via She calls her head office. This audio communication is initiated via
a private wireless local area network (WLAN) link realized over one 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 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 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 drive from here. She walks to a taxi stand, and boards a taxi. The
audio communication is automatically transferred to the public audio communication is automatically transferred to the public
wireless metropolitan area network (WMAN) over the Wi-Max network wireless metropolitan area network (WMAN) over the Wi-Max
deployed in the city, with no interruption of the communication. metropolitan network deployed, with no interruption of the
communication.
This scenario illustrates the need for a mobile user to use multiple This scenario illustrates the need to use multiple types of access
types of access technologies in order to maintain ongoing technologies in order to maintain ongoing communications when a user
communications when a user is moving out of the coverage area of a is moving out of the coverage area of a specific technology.
specific technology.
3.2. Need to Redirect Established Sessions 3.2. Need to Redirect Established Sessions
Oliver is on his way to work waiting at a train station. He uses Oliver is in the passenger lounge waiting at his train. He uses this
this opportunity and the presence of a WLAN hot-spot to download the opportunity and the presence of a WLAN hot-spot to download the news
news from his favorite on-line news channel. While Oliver is from his favorite on-line news channel. While Oliver is downloading
downloading the news, he receives a phone call over a wide area the news, he receives a video call over his wide area 3G cellular
cellular link. Oliver decides to initiate a video flow for this link. The bandwidth and traversal delay of the wide area cellular
communication. The bandwidth and traversal delay of the wide area link is not adequate for high quality video-conference, so both flows
cellular link is not adequate for the video conference, so both flows
(video/audio) are transferred to the WLAN link provided by the hot- (video/audio) are transferred to the WLAN link provided by the hot-
spot. This transfer occurs transparently and without affecting the spot. This transfer occurs transparently and without affecting the
other active flows. other active flows.
This scenario illustrates the need for a nomadic user to dynamically This scenario illustrates the need for a nomadic user to dynamically
redirect flows from one type of access technology to another based on redirect flows from one type of access technology to another based on
some user preferences or traffic requirements. some user preferences or traffic requirements.
3.3. Need to Set Up Preferences 3.3. Need to Set Up Preferences
Nami works at home using her connection to the Internet via ADSL and Nami works at home for a publishing company using her connection to
a public 802.11b WLAN from the street. She is also subscribed to the Internet via a low-speed dial up connection, a public and
digital video broadcasting. Because the public WLAN is not secure, unrealiable 802.11b WLAN from the street and her 3G cellular phone.
she downloads email from her company using the ADSL link even though Because the public WLAN is not secure, and the dial-up connection too
the WLAN service is free. When she is accessing her personal free slow, she checks her company's email using her 3G phone even though
web-mail account, she would then use the WLAN service. She has it is expensive. She uses the WLAN service for non-confidential
noticed the 802.11b link is unstable during the day, so she chooses activities such as web-browsing and video-conferencing. The dial-up
to send requests and periodic refreshments for joining the digital connection is moslty used to transmit her completed work securely and
video broadcasting via ADSL rather than the free WLAN services. synchronizing her file system.
This scenario illustrates the need in a fixed environment to This scenario illustrates the need in a fixed environment to
simultaneously use multiple access technologies and to select the simultaneously use multiple access technologies and to select the
most appropriate one according to user preferences. No assumptions most appropriate one according to user preferences. No assumptions
are made whether flows need to be redirected or not from one access are made whether flows need to be redirected or not from one access
technology to another. These preferences can be dynamic, or as in technology to another. These preferences can be dynamic (e.g. the
the example configured once for each application. 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 3.4. Need to Select the Best Access Technology
Alice is a paramedic. Her ambulance is called to the scene of a car 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 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 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 site of the crash to assess the severity of the accident. It is
identified that one of the passengers has suffered a severe head identified that one of the passengers has suffered a severe head
injury. Alice decides to consult a specialist via video injury. Alice decides to consult a specialist via video
conferencing. This session is initiated from the specialist via the conferencing. This session is initiated from the specialist via the
same wide area cellular link. Meanwhile, Alice requests for the same wide area cellular link. Meanwhile, Alice requests for the
download of the patient medical records from the hospital servers. download of the patient medical records from the hospital servers.
She later decides in mid-session that the wide area cellular link is The wide area cellular link is too slow for this download, so the
too slow for this download, and thus transfers the download to the download is transfered to the ambulance satellite link. Even though
ambulance satellite link. Even though this link provides a this link provides a significantly faster bit rate it has a longer
significantly faster bit rate it has a longer traversal delay and traversal delay and only down-link is available. For this, only the
only down-link is available. For this, only the down-stream of the down-stream of the download is transferred while up-stream proceeds
download is transferred while up-stream proceeds over the wide area over the wide area cellular link. Connectivity between the parametic
cellular link. Connectivity with the ambulance is managed over a and the ambulance is managed over a WLAN link. Even though Alice has
WLAN link between the paramedic and the ambulance. Even though Alice performed a partial hand-off for the transfer of the download down-
has performed a partial hand-off for the transfer of the download stream to the satellite link, the upstream and the video conferencing
down-stream to the satellite link, the upstream and the video session remains on the wide area cellular link. This serves best the
conferencing session remains on the wide area cellular link. This time constraint requirements of the real time communications.
serves best the time constraint requirements of the real time
communications.
This scenario illustrates the need in a mobile environment for both This scenario illustrates the need in a mobile environment for both
ubiquitous access to the Internet using whatever available interface ubiquitous access to the Internet using whatever available interface
and the need to dispatch flows to particular access media according and the need to dispatch flows to particular access media according
to traffic characteristics or preferences. The fact that the actual to traffic characteristics or preferences. It also illustrates that
connection to the Internet is maintained via the ambulance to which flows can be directed to separate media downlink and uplink. The
the paramedic is connected to via a WLAN link illustrates to need to fact that the actual connection to the Internet is maintained via the
express preferences on the path to be taken from a remote computer ambulance to which the paramedic is connected to via a WLAN link
(i.e. a mobile router in the ambulance in this case). 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 3.5. Need to Dispatch Traffic over Distinct Paths
Max drives his car and constantly keeps some sort of Internet Max drives his car and constantly keeps some sort of Internet
connectivity through one of the available access technologies. His connectivity through one of the many available access technologies
car navigator downloads road information from the Internet and his solely managed by a dedicated on-board unit (OBU). Data are further
car-audio plays on-line audio streaming. When his car passes an area transmitted to other on-board units. His car navigator downloads
where both high-data-rate Wi-Max and low-data rate cellular network road information from the Internet and his car-audio plays on-line
are available, it distributes load to the Wi-Max access and the audio streaming while data collected by sensors is transmitted to the
cellular network access. When his car passes an area where only a car manufacturer (e.g. consumption, engine pressure) and safety data
wide coverage-range cellular network is available, the connection is is exchanged between surrounding vehicles (e.g. geographic position,
maintained via the cellular network. 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).
This scenario illustrates the need to save traffic transiting in a When his car passes an area where only a wide coverage-range cellular
particular access network when there is a possibility to send data network is available, safety related sessions are maintained via the
over an alternative route. 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 save
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 designed by ISO TC204 WG16 for Intelligent
Transportations Systems (ITS). The exchange of safety data
illustrates the ongoing work of the car-to-car communication
consortium (C2C-CC)
3.6. Need for Reliability 3.6. Need for Reliability
Dr. Ingrid performs an operation via long-distance medical system. Ingrid, a doctor, performs an operation via long-distance medical
She watches a patient in a battle field over the screen which system. She watches a patient in a battle field over the screen
delivers real-time images of the patient. Sensors on her arms which delivers real-time images of the patient. Sensors on her arms
deliver her operational actions and a robot performs the actual deliver her operational actions and a robot performs the actual
operation in the battle field. Since the operation is critical, the operation in the battle field. Since the operation is critical, the
delivery of patient images and Dr. Ingrid's action is done by bi- delivery of patient images and Dr. Ingrid's action is done by bi-
casting from/to multiple interfaces bound to a distinct technology or casting from/to multiple interfaces bound to a distinct technology or
distinct radio range. So in case packets are delayed or one of the distinct radio range. So in case packets are delayed or one of the
interface fails to maintain connectivity to the network, her distant interface fails to maintain connectivity to the network, her distant
operation can be continued. operation can be continued.
This scenario illustrates the need to use multiple access This scenario illustrates the need to use multiple access
technologies in order to improve reliability upon failure of one of technologies in order to improve reliability upon failure of one of
the access technologies. the access technologies.
3.7. Need to Accelerate Transmission 3.7. Need to Accelerate Transmission
Roku is at the airport waiting to board the plane. She receives a Roku is at the airport waiting to board the plane. She receives a
call from her husband. This audio communication is received via a call from her husband. This audio communication is received via a
WLAN link realized over one of the available hot-spots. She knows 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 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. work. Roku uses a WLAN connection to download the necessary data.
However, there is not enough time and she decides to accelerate the However, there is not enough time before boarding and she decides to
download. Her notebook is equipped with an additional WLAN accelerate the download. Her notebook is equipped with an additional
interface. She decides to use this additional WLAN interface to WLAN interface. This additional WLAN interface is then used to
connect to another access point, and distribute the different connect to another access point, and the different download flows are
download flows between the two wireless interfaces. distributed between the two wireless interfaces.
This scenario illustrates the need to use multiple accesses to the This scenario illustrates the need to use multiple accesses to the
Internet in order to accelerate the amount of data that could be Internet in order to accelerate the amount of data that could be
transmitted over a period of time. transmitted over a period of time.
4. Goals and Benefits of Multihoming 4. Goals and Benefits of Multihoming
The scenarios presented in the previous section are now used to The scenarios presented in the previous section are now used to
highlight the goals and benefits of node multihoming. The goals highlight the goals and benefits of node multihoming. The goals
cannot really be distinguished from the benefits, but there are cannot really be distinguished from the benefits, but there are
several situations where multihomed is either advisable or several situations where multihomed is either advisable or
beneficial. These benefits and goals listed here are by no means beneficial. These benefits and goals listed here are by no means
distinct and separate; most of them overlap with one another. It is distinct and separate; most of them overlap with one another. It is
not the objective here to classify the benefits and goals into not the objective here to classify the benefits and goals into
different non-overlapping consituents. Instead the objective is to different non-overlapping consituents. Instead the objective is to
list the possible benefits and goals different people have when list the possible benefits and goals different people have in mind
deploying a multihomed node. when deploying a multihomed node.
Figure 1 summarizes which goal applies to the scenarios introduced in Figure 1 summarizes which goal applies to the scenarios introduced in
Section 3. Note that all these goals and benefits apply to both Section 3. Note that all these goals and benefits apply to both
fixed end nodes and mobile end nodes, though the scenarios may either fixed end nodes and mobile end nodes, though the scenarios may either
focused on a fixed used (F), or nomadic usage (N), or a mobile usage 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 (M). Nomadic and mobile users are both on the move, while a fixed
user doesn't physically move. The difference between nomadic usages user doesn't physically move. The difference between nomadic usages
and mobile usages is that sessions are not required to be maintained and mobile usages is that sessions are not required to be maintained
when the access network is changed as a result of physical move when the access network is changed as a result of physical move
within the topology. No assumptions are made whether mobility within the topology. No assumptions are made whether mobility
support mechanims may be useful or not in any of the fixed, nomadic 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 and mobile usages in order to maintain sessions. This is out of
scope of the present document. scope of the present document.
+===================================+===========================+ +===================================+===========================+
skipping to change at page 12, line 4 skipping to change at page 12, line 4
unavailable (e.g. failure). Connectivity is guaranteed as long as at unavailable (e.g. failure). Connectivity is guaranteed as long as at
least one connection to the Internet is maintained. least one connection to the Internet is maintained.
A potential means is to duplicate network component, another is to A potential means is to duplicate network component, another is to
duplicate a particular flow simultaneously through different routes. duplicate a particular flow simultaneously through different routes.
This minimizes packet loss typically for real-time communication and This minimizes packet loss typically for real-time communication and
burst traffic. It also minimizes delay of packet delivery caused by burst traffic. It also minimizes delay of packet delivery caused by
congestion and achieves more reliable real-time communication than congestion and achieves more reliable real-time communication than
single-casting. For mobile computing, bi-casting avoids dropping single-casting. For mobile computing, bi-casting avoids dropping
packets when a mobile node changes its interface during communication packets when a mobile node changes its interface during communication
[6]. [7].
4.3. Flow Redirection 4.3. Flow Redirection
To be able to redirect flow from one interface, or one address to To be able to redirect flows from one interface, or one address to
another one, without having to re-initiate the flow. This can be due another one, without having to re-initiate the flow. This can be due
to preference changes or upon network failure. to preference changes or upon network failure.
4.4. Load Sharing 4.4. Load Sharing
To spread network traffic load among several routes. This is To spread network traffic load among several routes. This is
achieved when traffic load is distributed among different connections achieved when traffic load is distributed among different connections
between the node and the Internet [7]. between the node and the Internet [8].
4.5. Load Balancing/Flow Distribution 4.5. Load Balancing/Flow Distribution
To separate a flow between multiple points of attachment To separate a flow between multiple points of attachment
(simultaneously active or not) of a node, usually chosing the less (simultaneously active or not) of a node, usually chosing the less
loaded connection or according to preferences on the mapping between loaded connection or according to preferences on the mapping between
flows and interfaces. flows and interfaces.
4.6. Preference Settings 4.6. Preference Settings
skipping to change at page 13, line 9 skipping to change at page 13, line 9
Bandwidth available to the user or the application may be limited by Bandwidth available to the user or the application may be limited by
the underlying technology (e.g. GSM has scarce bandwidth) or by some the underlying technology (e.g. GSM has scarce bandwidth) or by some
policies (e.g. monthly rate paid by the user). Multiple interfaces policies (e.g. monthly rate paid by the user). Multiple interfaces
connected to different links or ISPs can increase the total bandwidth connected to different links or ISPs can increase the total bandwidth
available to the user or application. available to the user or application.
5. Analysis 5. Analysis
From the definition of a multihomed node it follows that a multihomed From the definition of a multihomed node it follows that a multihomed
node has several IPv6 addresses to choose between. In order to node has several IPv6 addresses to choose between. In order to
expose the goals and benefits to manage multihomed nodes, we propose expose the goals and benefits in managing multihomed nodes, we
to distinguish two main cases: either the node has only one propose to distinguish two main cases: either the node has only one
interface, or the node has several interfaces. In the former case, interface, or the node has several interfaces. In the former case,
the node is multihomed when multilpe prefixes are advertised on the the node is multihomed when multilpe prefixes are advertised on the
link the node is attached to. This distinction is important and link the node is attached to. This distinction is important and
sometimes subtle but the implications are important. sometimes subtle but the implications are important.
5.1. Case 1: One Interface, Multiple Prefixes 5.1. Case 1: One Interface, Multiple Prefixes
The single-interfaced node is multihomed when several prefixes are The single-interfaced node is multihomed when several prefixes are
advertised on its interface. The node must therefore configure advertised on its interface. The node must therefore configure
several IPv6 addresses. several IPv6 addresses.
skipping to change at page 13, line 45 skipping to change at page 13, line 45
o Ubiquitous Access: NO o Ubiquitous Access: NO
Ubiquitous access cannot be guaranteed when the node loses Ubiquitous access cannot be guaranteed when the node loses
Internet connectivity through its sole interface (e.g. the node is Internet connectivity through its sole interface (e.g. the node is
going outside the coverage area of its access point). going outside the coverage area of its access point).
o Flow redirection: YES o Flow redirection: YES
The node might need to redirect a flow from one address to another The node might need to redirect a flow from one address to another
for several reasons. For example, if one of the IPv6 prefix for several reasons. For example, if one of the IPv6 prefix
becomes unavailable, flows using the corresponding prefix need to becomes unavailable, flows using the address from this prefix
be redirected on an address using another prefix could be redirected to the address obtained on the other prefix.
o Reliability: MAYBE o Reliability: MAYBE
In case of failure of one IPv6 prefix, one of the address of the In case of failure of one IPv6 prefix, one of the address of the
node will not be valid anymore. Another available address built node will not be valid anymore. Another available address built
from other prefixes may allow the node to recover this sort of from other prefixes may allow the node to recover this sort of
failure. failure.
Bi-casting can be performed to ensure the delivery of packets on 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 the node. To do so, more than one IPv6 address must be used
simultaneously for one flow. Bi-casting would allow the node to simultaneously for one flow. Bi-casting would allow the node to
seamlessly change the address used on the node. seamlessly change the address used on the node.
o Load sharing: YES o Load sharing: YES
Load Sharing can be performed in the network, according to the Load Sharing can be performed in the network, according to the
address used by the node. The choice of the address used by 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 node and the router selection can be influenced by load sharing
sharing rules. This mostly benefits the network side: if rules. This mostly benefits the network side: if different access
different access routers or routes can be used to forward the routers or routes can be used to forward the node's traffic, the
node's traffic, it will share the traffic load on the network. traffic load will be shared in the network.
o Load balancing/Flow Distribution: NO o Load balancing/Flow Distribution: NO
Load balancing cannot be performed as the node has only one Load balancing cannot be performed when the node has only one
interface. interface.
o Preferences: YES o Preferences: YES
The source address can be chosen according to preferences set up The source address can be chosen according to preferences set up
by the user, or according to preferences set up in the network by the user, or according to preferences set up in the network
(such as with the default router preferences option introduced in (such as with the default router preferences option introduced in
Router Advertisement [8]), or by the ISP. Router Advertisement [9]), or by the ISP.
o Aggregated Bandwidth: MAYBE o Aggregated Bandwidth: MAYBE
With only one interface connected to a link, the node generally With only one interface connected to a link, the node generally
will not be able to benefit from an increased aggregated bandwidth will not be able to benefit from an increased aggregated bandwidth
with multiple prefixes. However, this benefit might be gained with multiple prefixes. However, this benefit might be gained
indirectly. For instance, by alternating between different indirectly. For instance, by alternating between different
addresses, the total throughput may be higher (eg. due to load addresses, the total throughput may be higher (eg. due to load
sharing). Also, some web and file transfer servers limit transfer sharing). Also, some web and file transfer servers limit transfer
bandwidths based on the client's address. By using different bandwidths based on the client's address. By using different
skipping to change at page 18, line 10 skipping to change at page 18, line 10
o Aggregated Bandwidth: YES o Aggregated Bandwidth: YES
With multiple interfaces connected to different links, the node With multiple interfaces connected to different links, the node
generally will be able to benefit from an increased aggregated generally will be able to benefit from an increased aggregated
bandwidth. bandwidth.
6. Issues 6. Issues
In this section, we attempt to list a number of generic issues that 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. will have to be solved in order to meet the multihoming goals.
Figure 2 summarizes which issues apply to each of the case detailed Figure 2 summarizes which issues apply to which case detailed in the
in the previous section. The sign '+', '-' or '=' indicated is the previous section (availability of a single interface or multiple
issue is more important, less important, or equally important to interfaces). The sign '+', '-' or '=' indicates if the issue is more
solve for the case under consideration important, less important, or equally important to solve for the case
under consideration
+====================================+=====+=====+ +====================================+=====+=====+
| | Cases | | | Cases |
| +-----+-----+ | +-----+-----+
| Issues | (1) | (2) | | Issues | (1) | (2) |
+====================================+=====+=====+ +====================================+=====+=====+
| Source Address Selection | o = | o = | | Source Address Selection | o = | o = |
+------------------------------------+-----+-----+ +------------------------------------+-----+-----+
| Recovery Delay | o | o + | | Recovery Delay | o | o + |
+------------------------------------+-----+-----+ +------------------------------------+-----+-----+
| Change of e2e Path Characteristics | o - | o + | | Change of e2e Path Characteristics | o - | o + |
+------------------------------------+-----+-----+ +------------------------------------+-----+-----+
| Address Change | o + | o + | | Transparency | o + | o + |
+====================================+=====+=====+ +====================================+=====+=====+
Figure 2: Issues and their Importance for Each Case Figure 2: Issues and their Importance for Each Case
6.1. <!--Source-->Address Selection 6.1. <!--Source-->Address Selection
The multihomed node has several addresses, which implies the The multihomed node has several addresses, which implies the
appropriate address must be chosen when an IPv6 communication is appropriate address must be chosen when an IPv6 communication is
established (e.g. when a TCP connection is opened). An address established (e.g. when a TCP connection is opened). An address
selection mechanism is therefore needed. selection mechanism is therefore needed.
skipping to change at page 18, line 48 skipping to change at page 18, line 49
The choice of the address can be influenced by many parameters: user The choice of the address can be influenced by many parameters: user
preferences, ingress filtering, preference flag in Router preferences, ingress filtering, preference flag in Router
Advertisement, destination prefix, type of interface, link Advertisement, destination prefix, type of interface, link
characteristics, etc. characteristics, etc.
6.2. Failure Discovery and Recovery Delay 6.2. Failure Discovery and Recovery Delay
A particular access to the Internet may become unavailable while it A particular access to the Internet may become unavailable while it
is being used. The time needed for detecting an address has become is being used. The time needed for detecting an address has become
invalid and the time to redirect communications to one of its other invalid and the time to redirect communications to one of its other
addresses is considered as critical. Efficient failure detection and addresses is considered critical. Efficient failure detection and
recovery mechanisms are therefore required. recovery mechanisms are therefore required.
Note that transport sessions with multihoming capabilies such as SCTP Note that transport sessions with multihoming capabilies such as SCTP
[9] may be able to continue easily since SCTP has built-in [10] may be able to continue easily since SCTP has built-in
transmission rate control mechanims to take into account the transmission rate control mechanims to take into account the
differences between two paths. differences between two paths.
6.3. Change of Traffic Characteristics 6.3. Change of Traffic Characteristics
The change of path for a specific session (e.g. due to change of 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 interface) may cause changes on the end-to-end path characteristics
(higher delay, different PMTU, etc). This could have an impact on (higher delay, different PMTU, etc). This could have an impact on
upper layer protocols such as transport protocols (particularly TCP) upper layer protocols such as transport protocols (particularly TCP)
or applications that are sensitive to changes. or applications that are sensitive to changes.
6.4. Address Change 6.4. Transparency
In some situations, it will be necessary to divert some or all of the 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 sessions from one interface or prefix to another (e.g. due to loss of
network connection or the access router becoming unreachable - this network connection or the access router becoming unreachable - this
could be particularly frequent for mobile nodes). With no support could be particularly frequent for mobile nodes). With no support
mechanism, an address change would cause on-going sessions using the mechanism, an address change would cause on-going sessions using the
invalid former address to terminate, and to be restarted using the invalid former address to terminate, and to be restarted using the
new address. To avoid this, the node needs a recovery mechanism new address. To avoid this, a recovery mechanism allowing the
allowing to redirect all current communications to one of its other redirection of all current communications to one of the other IPv6
IPv6 addresses. addresses is needed.
In the case of a mobile node changing its point of attachment using 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 the same interface, all flows must be redirected to the new location
in order to maintain sessions. A mobility management solution may be in order to maintain sessions. A mobility management solution may be
required, such as Mobile IPv6 [10] for mobile hosts or NEMO Basic required, such as Mobile IPv6 [11] for mobile hosts or NEMO Basic
Support [11] for mobile routers. Additional mechanisms may be needed Support [6] for mobile routers. Additional mechanisms may be needed
if the node was using several addresses on its old link, such as if the node was using several addresses on its previous link, such as
which flow to redirect, which address must be associated with the new which flows shall be to redirected, which address must be associated
address(es). The scalability of the operations involved in the with the new address(es). The scalability of the operations involved
redirection of flows may also be an issue, if we consider that the in the redirection of flows may also be an issue, if we consider that
node had several addresses on the old link and several flows and/or the node had several addresses on the previous link and several flows
correspondents. Issues pertaining to Mobile IPv6 and NEMO Basic and/or correspondents. Issues pertaining to Mobile IPv6 and NEMO
Support are explained in companion drafts [2] and [3] respectively. Basic Support are explained in companion drafts [2] and [3]
respectively.
7. Conclusion 7. Conclusion
In this document we show the concrete need for multihoming at the In this document we studied multihoming at the level of the end node.
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 A node is multihomed in a situation where it has multiple addresses,
needs prevail for mobile nodes (hosts and routers). Goals can only usually due to the availability of multiple interfaces on the node,
be met once some issues are solved. Issues specific to mobile hosts or the announcement of multiple prefixes on the link it is attached
and mobile routers are investigated in documents of the MONAMI6 and to.
NEMO working groups at the IETF.
This fits 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 8. Contributors
This document is based on an earlier document to which Thomas Noel This document is based on an earlier document to which Thomas Noel
(ULP, Strasbourg) and EunKyoung Paik (SNU, Seoul) also participated (ULP, Strasbourg) and EunKyoung Paik (SNU, Seoul) also contributed in
in addition to the authors listed in the present document. addition to the authors listed in the present document.
9. Acknowledgments 9. Acknowledgments
We would like to extend our gratitude to Niko A. Fikouras, Ken We would like to extend our gratitude to Niko A. Fikouras, Ken
Nagami, Pekka Savola, Hesham Soliman, and many others who had Nagami, Pekka Savola, Hesham Soliman, and many others who had
provided valuable comments to this document. provided valuable comments to this document.
10. Informative References 10. Informative References
[1] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- [1] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003. Multihoming Architectures", RFC 3582, August 2003.
[2] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. [2] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-01 (work in progress), draft-ietf-monami6-mipv6-analysis-03 (work in progress),
June 2006. July 2007.
[3] Ng, C., Paik, E., Ernst, T., and M. Bagnulo, "Analysis of [3] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming
Multihoming in Network Mobility Support", in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-06 (work in progress), draft-ietf-nemo-multihoming-issues-06 (work in progress),
June 2006. June 2006.
[4] Fikouras, N., "Mobile IPv4 Flow Mobility Problem Statement", [4] Fikouras, N., "Mobile IPv4 Flow Mobility Problem Statement",
draft-nomad-mip4-flow-mobility-pb-00.txt (work in progress), draft-nomad-mip4-flow-mobility-pb-00.txt (work in progress),
Feb 2004. Feb 2004.
[5] Manner, J. and M. Kojo, "Mobility Related Terminology", [5] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[6] Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile [6] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[7] Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile
IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-06 IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-06
(work in progress), July 2005. (work in progress), July 2005.
[7] Hinden, R. and D. Thaler, "IPv6 Host to Router Load Sharing", [8] Hinden, R. and D. Thaler, "IPv6 Host to Router Load Sharing",
draft-ietf-ipv6-host-load-sharing-04 (work in progress), draft-ietf-ipv6-host-load-sharing-04 (work in progress),
June 2005. June 2005.
[8] Draves, R. and D. Thaler, "Default Router Preferences and More- [9] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", RFC 4191, November 2005. Specific Routes", RFC 4191, November 2005.
[9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [10] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960, Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000. October 2000.
[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [11] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[11] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
Authors' Addresses Authors' Addresses
Thierry Ernst Thierry Ernst
INRIA INRIA
INRIA Rocquencourt INRIA Rocquencourt
Domaine de Voluceau B.P. 105 Domaine de Voluceau B.P. 105
Le Chesnay, 78153 Le Chesnay, 78153
France France
Phone: +33-1-39-63-59-30 Phone: +33-1-39-63-59-30
skipping to change at page 24, line 7 skipping to change at page 24, line 7
Bremen, Bremen 28359 Bremen, Bremen 28359
Germany Germany
Phone: +49-421-218-8264 Phone: +49-421-218-8264
Fax: +49-421-218-3601 Fax: +49-421-218-3601
Email: koo@comnets.uni-bremen.de Email: koo@comnets.uni-bremen.de
URI: http://www.comnets.uni-bremen.de/~koo/ URI: http://www.comnets.uni-bremen.de/~koo/
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 49 change blocks. 
140 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/