draft-ietf-monami6-multihoming-motivation-scenario-00.txt   draft-ietf-monami6-multihoming-motivation-scenario-01.txt 
Monami6 Working Group T. Ernst Monami6 Working Group T. Ernst
Internet-Draft Keio University / WIDE Internet-Draft INRIA
Expires: August 5, 2006 N. Montavont Intended status: Informational N. Montavont
GET/ENST-B Expires: April 26, 2007 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
February 2006 October 23, 2006
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-00 draft-ietf-monami6-multihoming-motivation-scenario-01.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 August 5, 2006. This Internet-Draft will expire on April 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
In this document, multihoming is investigated from a node point of In this document, multihoming is investigated from a node point of
view, and not from a site point of view as the term "multihoming" is 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 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.
skipping to change at page 2, line 33 skipping to change at page 2, line 36
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 . . . . . . . . . . . . . 8
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. Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Flow Redirection . . . . . . . . . . . . . . . . . . . . . 12
4.4. Load Balancing/Flow Distribution . . . . . . . . . . . . . 11 4.4. Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Preference Settings . . . . . . . . . . . . . . . . . . . 11 4.5. Load Balancing/Flow Distribution . . . . . . . . . . . . . 12
4.6. Aggregate Bandwidth . . . . . . . . . . . . . . . . . . . 12 4.6. Preference Settings . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 14 5.2. Case 2: Several Interfaces . . . . . . . . . . . . . . . . 15
6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. <!--Source-->Address Selection . . . . . . . . . . . . . . 17
6.2. Failure Discovery and Recovery Delay . . . . . . . . . . . 17
6.3. Change of Traffic Characteristics . . . . . . . . . . . . 18
6.4. Address Change . . . . . . . . . . . . . . . . . . . . . . 18
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. <!--Source-->Address Selection . . . . . . . . . . . . . . 18
6.2. Failure Discovery and Recovery Delay . . . . . . . . . . . 18
6.3. Change of Traffic Characteristics . . . . . . . . . . . . 19
6.4. Address Change . . . . . . . . . . . . . . . . . . . . . . 19
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. Informative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Introduction 1. Introduction
New equipments shipped on the market now often integrate several New equipments shipped on the market now often integrate several
access technologies (both wired and wireless). The main purpose of access technologies (both wired and wireless). The main purpose of
this integration is to federate all means of communications in order this integration is to federate all means of communications in order
to access the Internet ubiquitously (from everywhere and at any time) to access the Internet ubiquitously (from everywhere and at any time)
skipping to change at page 6, line 18 skipping to change at page 6, line 18
multihoming. Each scenario usually yields more than one of the goals multihoming. Each scenario usually yields more than one of the goals
and benefits outlined in Section 4. All scenarios focus on wireless and benefits outlined in Section 4. All scenarios focus on wireless
technologies though no mobility management may be involved (one can technologies though no mobility management may be involved (one can
use wireless access at office). use wireless access at office).
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 WIMAX network wireless metropolitan area network (WMAN) over the Wi-Max network
deployed in the city, with no interruption of the communication. deployed in the city, with no interruption of the communication.
This scenario illustrates the need for a mobile user to use multiple This scenario illustrates the need for a mobile user to use multiple
types of access technologies in order to maintain ongoing types of access technologies in order to maintain ongoing
communications when a user is moving out of the coverage area of a communications when a user 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 on his way to work waiting at a train station. He uses
this opportunity and the presence of a WLAN hot-spot to download the this opportunity and the presence of a WLAN hot-spot to download the
news from his favorite on-line news channel. While Oliver is news from his favorite on-line news channel. While Oliver is
downloading the news, he receives a phone call over a wide area downloading the news, he receives a phone call over a wide area
cellular link. Oliver decides he wishes to initiate a video flow for cellular link. Oliver decides to initiate a video flow for this
this communication. The bandwidth and traversal delay of the wide communication. The bandwidth and traversal delay of the wide area
area cellular link is not adequate for the video conference, so both cellular link is not adequate for the video conference, so both flows
flows (video/audio) are transferred to the WLAN link provided by the (video/audio) are transferred to the WLAN link provided by the hot-
hot-spot. This transfer occurs transparently and without affecting spot. This transfer occurs transparently and without affecting the
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 for a publishing company. She has an in-house Nami works at home using her connection to the Internet via ADSL and
network and get access to the Internet via ADSL, a public 802.11b a public 802.11b WLAN from the street. She is also subscribed to
WLAN from the street and satellite. She has subscribed to the digital video broadcasting. Because the public WLAN is not secure,
cheapest ADSL service with limited uplink bandwidth. Also, the she downloads email from her company using the ADSL link even though
satellite link she has access to is downlink only, but it is the WLAN service is free. When she is accessing her personal free
extremely cheap for TV broadcasting. She has noticed the 802.11b web-mail account, she would then use the WLAN service. She has
link is unreliable at some point in time during the day, so she noticed the 802.11b link is unstable during the day, so she chooses
chooses to send requests and periodic refreshments for joining the TV to send requests and periodic refreshments for joining the digital
broadcasting via ADSL rather than 802.11b although it is free. On video broadcasting via ADSL rather than the free WLAN services.
the other hand, she has configured her network to use the 802.11b
link at night to publish web content comprising video. Once a week,
she communicates with overseas peer staff by videoconferencing.
Voice being the most important, she has configured her VoIP session
over ADSL. Video is sent at maximum rate when 802.11b is working
fine, otherwise the video is sent at lower rate.
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. technology to another. These preferences can be dynamic, or as in
the example configured once for each application.
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 at 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. The paramedic 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, the paramedic requests for same wide area cellular link. Meanwhile, Alice requests for the
the download of the patient medical records from the hospital download of the patient medical records from the hospital servers.
servers. The paramedic decides in mid-session that the wide area She later decides in mid-session that the wide area cellular link is
cellular link is too slow for this download and transfers the too slow for this download, and thus transfers the download to the
download to the ambulance satellite link. Even though this link ambulance satellite link. Even though this link provides a
provides a significantly faster bit rate it has a longer traversal significantly faster bit rate it has a longer traversal delay and
delay and only down-link is available. For this, only the down- only down-link is available. For this, only the down-stream of the
stream of the download is transferred while up-stream proceeds over download is transferred while up-stream proceeds over the wide area
the wide area cellular link. Connectivity with the ambulance is cellular link. Connectivity with the ambulance is managed over a
managed over a WLAN link between the paramedic and the ambulance. WLAN link between the paramedic and the ambulance. Even though Alice
Even though the paramedic has performed a partial hand-off for the has performed a partial hand-off for the transfer of the download
transfer of the download down-stream to the satellite link, the down-stream to the satellite link, the upstream and the video
upstream and the video conferencing session remains on the wide area conferencing session remains on the wide area cellular link. This
cellular link. This serves best the time constraint requirements of serves best the time constraint requirements of the real time
the real time communications. 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. The fact that the actual
connexion to the Internet is maintained via the ambulance to which connection to the Internet is maintained via the ambulance to which
the paramedic is connected to via a WLAN link illustrates to need to 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 express preferences on the path to be taken from a remote computer
(i.e. a mobile router in the ambulance in this case). (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 available access technologies. His
car navigator downloads road information from the Internet and his car navigator downloads road information from the Internet and his
car-audio plays on-line audio streaming. When his car passes an area car-audio plays on-line audio streaming. When his car passes an area
where both high-data-rate WLAN and low-data rate cellular network are where both high-data-rate Wi-Max and low-data rate cellular network
available, it distributes load to the WLAN access and the cellular are available, it distributes load to the Wi-Max access and the
network access. When his car passes an area where only a wide cellular network access. When his car passes an area where only a
coverage-range cellular network is available, the connection is wide coverage-range cellular network is available, the connection is
maintained via the cellular network. maintained via the cellular network.
This scenario illustrates the need to save traffic transiting in a This scenario illustrates the need to save traffic transiting in a
particular access network when there is a possibility to send data particular access network when there is a possibility to send data
over an alternative route. over an alternative route.
3.6. Need for Reliability 3.6. Need for Reliability
Dr. Ingrid performs an operation via long-distance medical system. Dr. Ingrid performs an operation via long-distance medical system.
She watches a patient in a battle field over the screen which She watches a patient in a battle field over the screen which
skipping to change at page 8, line 45 skipping to change at page 8, line 42
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
wireless local area network (WLAN) link realized over one of the WLAN link realized over one of the available hot-spots. She knows
available hot-spots. She knows this is going to be a long flight and this is going to be a long flight and wishes to catch up on some
wishes to catch up on some work. Roku uses a WLAN connection to work. Roku uses a WLAN connection to download the necessary data.
download the necessary data. However, there is not enough time and However, there is not enough time and she decides to accelerate the
she decides to accelerate the download. Her notebook is equipped download. Her notebook is equipped with an additional WLAN
with an additional WLAN interface. She decides to use this interface. She decides to use this additional WLAN interface to
additional WLAN interface to connect to another access point, and connect to another access point, and distribute the different
distribute the different download flows between the two wireless download flows between the two wireless interfaces.
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. 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 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 focused 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
skipping to change at page 10, line 39 skipping to change at page 11, line 18
| Goals | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | Goals | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+===================================+===+===+===+===+===+===+===+ +===================================+===+===+===+===+===+===+===+
| Ubiquitous Access | o | | | o | o | | | | Ubiquitous Access | o | | | o | o | | |
+-----------------------------------+---+---+---+---+---+---+---+ +-----------------------------------+---+---+---+---+---+---+---+
| Flow Redirection | o | o | o | o | o | | | | Flow Redirection | o | o | o | o | o | | |
+-----------------------------------+---+---+---+---+---+---+---+ +-----------------------------------+---+---+---+---+---+---+---+
| Reliability | | | o | o | o | o | | | Reliability | | | o | o | o | o | |
+-----------------------------------+---+---+---+---+---+---+---+ +-----------------------------------+---+---+---+---+---+---+---+
| Load Sharing | | | | | o | | | | Load Sharing | | | | | o | | |
+-----------------------------------+---+---+---+---+---+---+---+ +-----------------------------------+---+---+---+---+---+---+---+
| Load Balalancing | | | o | o | | | o | | Load Balancing | | | o | o | | | o |
+-----------------------------------+---+---+---+---+---+---+---+ +-----------------------------------+---+---+---+---+---+---+---+
| Preference Settings | | o | o | o | | | | | Preference Settings | | o | o | o | | | |
+-----------------------------------+---+---+---+---+---+---+---+ +-----------------------------------+---+---+---+---+---+---+---+
| Aggregate Bandwidth | | | | o | | | o | | Aggregate Bandwidth | | | | o | | | o |
+===================================+===+===+===+===+===+===+===+ +===================================+===+===+===+===+===+===+===+
| Usage: F=Fixed N=Nomadic M=Mobile | M | N | F | M | M | F | N | | Usage: F=Fixed N=Nomadic M=Mobile | M | N | F | M | M | F | N |
+===================================+===+===+===+===+===+===+===+ +===================================+===+===+===+===+===+===+===+
Figure 1: Goals Applying to Each Scenario Figure 1: Goals Applying to Each Scenario
skipping to change at page 11, line 31 skipping to change at page 12, line 6
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]. [6].
4.3. Load Sharing 4.3. Flow Redirection
To be able to redirect flow from one interface, or one address to
another one, 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 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 [7].
4.4. 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.5. Preference Settings 4.6. Preference Settings
This goal is to provide the user, the application or the ISP the This goal is to provide the user, the application or the ISP the
ability to choose the preferred transmission technology or access ability to choose the preferred transmission technology or access
network based on cost, efficiency, policies, bandwidth requirement, network based on cost, efficiency, policies, bandwidth requirement,
delay, etc. delay, etc.
4.6. Aggregate Bandwidth 4.7. Aggregate Bandwidth
This goal is to provide the user or the application with more This goal is to provide the user or the application with more
bandwidth. bandwidth.
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.
skipping to change at page 13, line 37 skipping to change at page 13, line 37
two access routers on the same link: for instance, the access points two access routers on the same link: for instance, the access points
may be shared between different ISPs, or two access routers may be may be shared between different ISPs, or two access routers may be
used for redundancy or load sharing purposes. The node will then used for redundancy or load sharing purposes. The node will then
build two global IPv6 addresses on its interface. build two global IPv6 addresses on its interface.
We now analyse which of the goals detailed in Section 4 can be met We now analyse which of the goals detailed in Section 4 can be met
with this configuration. with this configuration.
o Ubiquitous Access: NO o Ubiquitous Access: NO
Ubiquitous access cannot be guaranteed when the node looses 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 Reliability: MAYBE 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 corresponding prefix need to
be redirected on an address using another prefix
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.
skipping to change at page 14, line 25 skipping to change at page 14, line 33
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 as 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 [8]), 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 15, line 25 skipping to change at page 15, line 35
We now analyse how each of the goals listed in Section 4 can be met We now analyse how each of the goals listed in Section 4 can be met
with such multihomed configuration: with such multihomed configuration:
o Ubiquitous Access: MAYBE o Ubiquitous Access: MAYBE
It is easier to guarantee ubiquitous access when the node has It is easier to guarantee ubiquitous access when the node has
multiple interfaces since distinct technologies may be available multiple interfaces since distinct technologies may be available
at a given time according to the location and administrative at a given time according to the location and administrative
policies. 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 o Reliability: YES
Two levels of redundancy can be seen in this case: either one Two levels of redundancy can be seen in this case: either one
address of one interface is not valid anymore (e.g. because the address of one interface is not valid anymore (e.g. because the
corresponding prefix is not advertised on the link), or the node corresponding prefix is not advertised on the link), or the node
loses its internet connectivity through one interface. In the loses its internet connectivity through one interface. In the
former case, another IPv6 address available on the interface would former case, another IPv6 address available on the interface would
allow the node to switch addresses for on-going flows. In the allow the node to switch addresses for on-going flows. In the
latter case, another connection to the internet through another latter case, another connection to the internet through another
interface would allow it to redirect on-going flow from the interface would allow it to redirect on-going flow from the
skipping to change at page 16, line 33 skipping to change at page 17, line 4
o Preferences: YES o Preferences: YES
Interface and address selection is required. The problem can be Interface and address selection is required. The problem can be
seen exactly as in the first case (the node has only one seen exactly as in the first case (the node has only one
interface) if we consider that the interface preference is a interface) if we consider that the interface preference is a
parameter for the address selection. Therefore in this case, the parameter for the address selection. Therefore in this case, the
interface selection/preference is a supplementary parameter in the interface selection/preference is a supplementary parameter in the
address selection algorithm. address selection algorithm.
o Aggregated Bandwidth: YES o Aggregated Bandwidth: YES
With multiple interfaces connected to different links, the node
With multiple interfaces connected to a link, the node generally generally will be able to benefit from an increased aggregated
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 each of the case detailed
in the previous section. The sign '+', '-' or '=' indicated is the in the previous section. The sign '+', '-' or '=' indicated is the
issue is more important, less important, or equally important to issue is more important, less important, or equally important to
solve for the case under consideration solve for the case under consideration
skipping to change at page 17, line 52 skipping to change at page 18, line 52
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 as 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
may be able to continue easily since SCTP has built-in transmission [9] may be able to continue easily since SCTP has built-in
rate control mechanims to take into account the differences between transmission rate control mechanims to take into account the
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. Address Change
skipping to change at page 18, line 30 skipping to change at page 19, line 30
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, the node needs a recovery mechanism
allowing to redirect all current communications to one of its other allowing to redirect all current communications to one of its other
IPv6 addresses. IPv6 addresses.
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 [9] for mobile hosts or NEMO Basic required, such as Mobile IPv6 [10] for mobile hosts or NEMO Basic
Support [10] for mobile routers. Additional mechanisms may be needed Support [11] 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 old link, such as
which flow to redirect, which address must be associated with the new which flow to redirect, which address must be associated with the new
address(es). The scalability of the operations involved in the address(es). The scalability of the operations involved in the
redirection of flows may also be an issue, if we consider that the redirection of flows may also be an issue, if we consider that the
node had several addresses on the old link and several flows and/or node had several addresses on the old link and several flows and/or
correspondents. Issues pertaining to Mobile IPv6 and NEMO Basic correspondents. Issues pertaining to Mobile IPv6 and NEMO Basic
Support are explained in companion drafts [2] and [3] respectively. Support are explained in companion drafts [2] and [3] respectively.
7. Conclusion 7. Conclusion
skipping to change at page 20, line 9 skipping to change at page 20, line 25
Such goals are motivated for fixed nodes and mobile nodes, but the Such goals are motivated for fixed nodes and mobile nodes, but the
needs prevail for mobile nodes (hosts and routers). Goals can only needs prevail for mobile nodes (hosts and routers). Goals can only
be met once some issues are solved. Issues specific to mobile hosts be met once some issues are solved. Issues specific to mobile hosts
and mobile routers are investigated in documents of the MONAMI6 and and mobile routers are investigated in documents of the MONAMI6 and
NEMO working groups at the IETF. NEMO working groups at the IETF.
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 participated
in the addition to the authors listed in the present document. in addition to the authors listed in the present document.
9. Acknowledgments 9. Acknowledgments
We would like to thank all the people who have provided comments on We would like to extend our gratitude to Niko A. Fikouras, Ken
this draft, and also co-authors of earlier documents in which authors Nagami, Pekka Savola, Hesham Soliman, and many others who had
of this present document have been engaged. As such, we would like provided valuable comments to this document.
to thank Niko A. Fikouras, Hesham Soliman, Ken Nagami, and many
others.
10. 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-00 (work in progress), draft-ietf-monami6-mipv6-analysis-01 (work in progress),
February 2006. June 2006.
[3] Ng, C., "Analysis of Multihoming in Network Mobility Support", [3] Ng, C., Paik, E., Ernst, T., and M. Bagnulo, "Analysis of
draft-ietf-nemo-multihoming-issues-05 (work in progress), Multihoming in Network Mobility Support",
February 2006. draft-ietf-nemo-multihoming-issues-06 (work in progress),
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] 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", [7] 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- [8] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", RFC 4191, November 2005. Specific Routes", RFC 4191, November 2005.
[9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [9] 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.
[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[10] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [11] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
Authors' Addresses Authors' Addresses
Thierry Ernst Thierry Ernst
Keio University / WIDE INRIA
Jun Murai Lab., Keio University. INRIA Rocquencourt
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku Domaine de Voluceau B.P. 105
Kawasaki, Kanagawa 212-0054 Le Chesnay, 78153
Japan France
Phone: +81-44-580-1600 Phone: +33-1-39-63-59-30
Fax: +81-44-580-1437 Fax: +33-1-39-63-54-91
Email: ernst@sfc.wide.ad.jp Email: thierry.ernst@inria.fr
URI: http://www.sfc.wide.ad.jp/~ernst/ URI: http://www.nautilus6.org/~thierry
Nicolas Montavont Nicolas Montavont
Ecole Nationale Superieure des telecommunications de Bretagne Ecole Nationale Superieure des telecommunications de Bretagne
2, rue de la chataigneraie 2, rue de la chataigneraie
Cesson Sevigne 35576 Cesson Sevigne 35576
France France
Phone: (+33) 2 99 12 70 23 Phone: (+33) 2 99 12 70 23
Email: nicolas.montavont@enst-bretagne.fr Email: nicolas.montavont@enst-bretagne.fr
URI: http://www-r2.u-strasbg.fr/~montavont/ URI: http://www-r2.u-strasbg.fr/~montavont/
skipping to change at page 22, line 39 skipping to change at page 22, line 39
Ryuji Wakikawa Ryuji Wakikawa
Keio University Keio University
Department of Environmental Information, Keio University. Department of Environmental Information, Keio University.
5322 Endo 5322 Endo
Fujisawa, Kanagawa 252-8520 Fujisawa, Kanagawa 252-8520
Japan Japan
Phone: +81-466-49-1100 Phone: +81-466-49-1100
Fax: +81-466-49-1395 Fax: +81-466-49-1395
Email: ryuji@sfc.wide.ad.jp Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.net/ URI: http://www.wakikawa.org/
Chan-Wah Ng Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530 Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate Tai Seng Industrial Estate
Singapore 534415 Singapore 534415
SG SG
Phone: +65 65505420 Phone: +65 65505420
Email: chanwah.ng@sg.panasonic.com Email: chanwah.ng@sg.panasonic.com
skipping to change at page 24, line 5 skipping to change at page 24, line 5
ComNets-ikom,University of Bremen. ComNets-ikom,University of Bremen.
Otto-Hahn-Allee NW 1 Otto-Hahn-Allee NW 1
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/
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 24, line 29 skipping to change at page 24, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 48 change blocks. 
133 lines changed or deleted 157 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/