One document matched: draft-montavont-mobileip-multihoming-pb-statement-02.txt
Differences from draft-montavont-mobileip-multihoming-pb-statement-01.txt
IETF MIP6 Working Group N. Montavont
Internet-Draft LSIIT - ULP
Expires: April 25, 2005 R. Wakikawa
Keio University
T. Ernst
WIDE at Keio University
T. Noel
LSIIT - ULP
C. Ng
Panasonic Singapore Labs
October 25, 2004
Analysis of Multihoming in Mobile IPv6
draft-montavont-mobileip-multihoming-pb-statement-02.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Montavont, et al. Expires April 25, 2005 [Page 1]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
The use of multiple interface is foreseen to provide ubiquitous,
permanent and fault-tolerant access to the Internet, particularly on
mobile hosts which are more subject to failure or sudden lacks of
connectivity. However, Mobile IPv6 currently lack support for such
multihomed nodes. Individual solutions have been proposed to extend
Mobile IPv6 but all issues have not been addressed in a single
document. The purpose of the present document is thus to fill this
gap and to contribute to raise the discussion in order to make sure
that forthcoming solutions will address all the issues. In this
document, we propose a taxonomy to classify the situations where a
mobile node could be multihomed. This taxonomy is then used to
highlight the issues preventing mobile nodes operating Mobile IPv6 to
be multihomed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Taxonomy definition . . . . . . . . . . . . . . . . . . . 4
2.2 Taxonomy explanation . . . . . . . . . . . . . . . . . . . 5
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 x=1: only onr interface on the host . . . . . . . . . . . 7
3.2 x=n: The host has several interfaces . . . . . . . . . . . 7
4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Issues Related to Mobile IPv6 . . . . . . . . . . . . . . 9
4.2 Issues Not Related to Mobile IPv6 . . . . . . . . . . . . 9
4.3 Issues Related to a Host Connected to Home Link . . . . . 10
4.4 Redirection transparency . . . . . . . . . . . . . . . . . 10
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 15
Montavont, et al. Expires April 25, 2005 [Page 2]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
1. Introduction
Mobile IPv6 [1],[2] is designed to allow a mobile node to maintain
its IPv6 communications while moving between IPv6 subnets. However,
the current specification does not give hints nor requirements to
deal with mobile nodes with multiple points of attachement, i.e. a
multihomed mobile node. The purpose of the present document is to
fill this gap.
This document has two goals. The first goal is to define a taxonomy
which helps to represent the different situations where a mobile host
is multihomed. For each case, we show the configuration a multihomed
host may have (number of interfaces, number of Home Addresses or
number of Care-of Addresses). We also give a concrete illustration
for each scenario.
The second goal of this document is to define the requirements needed
to manage multihomed hosts. Different issues will be raised in order
to provide full support of multihomed hosts in Mobile IPv6. The
potentially needed solutions to support new features will be
described in a separate document.
The reader is assumed to have read our companion document [3] which
outlines the motivations, the goals and the benefits of multihoming
for both fixed and mobile nodes (i.e. generic IPv6 nodes).
Real-life scenarios as illustrated in that document are the base
motivations of the present study. The terms used in this memo are
the same as the ones used in Mobile IPv6 [1].
The document is organized as follows: in the first section, we
propose a taxonomy to classify the different cases where mobile hosts
are multihomed. Then this taxonomy is used to describe the
multihoming scenarios specific to Mobile IPv6. In the next section,
an analysis of each case is given in order to select the most
interesting scenarios highlighted in the previous section. The last
section summarizes the different features needed in Mobile IPv6 to
reach the goals defined in [3].
Montavont, et al. Expires April 25, 2005 [Page 3]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
2. Taxonomy
2.1 Taxonomy definition
0 As detailed in [3], multihoming can provide a number of benefits:
ubiquitous access, redundancy/fault recovery, load sharing, load
balancing, bicasting and preferences settings. In that document, the
multihoming study is split into two main axes: either the node has
only one interface (and several IPv6 addresses) or the node has
several interfaces. In this memo, we follow the same guidelines, but
we conduct this study from the pespective of mobile nodes operating
Mobile IPv6 specifically. However, two more parameters are necessary
to study the feasability of each goal: the multihoming management
will be different according to the number of Home Addresses and the
number of Care-of Addresses the mobile node has. We thus propose the
following taxonomy:
o x = number of active interfaces
o y = number of Home Addresses (HoAs)
o z = number of Care-of Addresses (CoAs)
A value of '1' implies there is a single instance of the parameter,
whereas a value of 'n' indicates that there are multiple instances of
the parameter. An illustration of this taxonomy is given in Figure
1.
Montavont, et al. Expires April 25, 2005 [Page 4]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
Mobile Node
HoA1 HoA2 ... HoAn --> Mobile IP layer (x)
| | |
+-----+--------+ | |
| | | | |
CoA1 +--CoA2 +---CoA3 ... CoAn --> IP layer (y)
| | | |
Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *)
| | | |
+-----+----+ | |
| | |
IF1 IF2 ... IFn --> Physical layer (z)
(z = the number of active interfaces)
HoA1 ::= {CoA1, 2, 3} [IF1 and IF2]
HoA2 ::= {CoA3} [IF2]
Mobile Node(x = 2, y = 3, z = 2)
* because number of IPv6 link is equal to the number of CoAs, equal to y
Figure 1: Illustration of the chosen taxonomy
The variable y indicates the number of HoAs allocated to a host. A
host may have multiple HoAs (x=n) when either:
o The host has only one home link, and all its HoAs are based on the
same IPv6 prefix (e.g. the host may have multiple interfaces).
o The host has only one home link, and multiple HoAs with distinct
prefixes because there are several IPv6 prefixes advertised on the
home link.
o The host has several home links, and thus has at least two HoAs
with different IPv6 prefixes.
As the taxonomy suggests, the fact that the mobile node has several
HoAs is independent from the fact that the mobile node has multiple
interfaces. The fact that the mobile node has multiple interfaces
does not imply that it has multiple HoAs and vice-versa.
2.2 Taxonomy explanation
We propose a taxonomy with three parameters because each of them has
an influence on either the mobile node behavior / management, or the
potential benefits the mobile node may obtain from such
configuration. According to the number of interfaces, a mobile node
Montavont, et al. Expires April 25, 2005 [Page 5]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
can indeed expect different benefits. If several interfaces are
available, they can for instance be used simultaneouly to save
bandwidth. If only one interface is available at a time but the node
is still multihomed, multiple source / destination addresses or
multiple HAs may be used according to the type of traffic. This
feature could also allow load balancing.
The number of HoAs and CoAs help to consider all scenarios of
multihomed nodes. These parameters will have an impact on the way
multihoming is supported. According to the number of HoAs and CoAs,
different policies will be needed, such as which CoA have to be
mapped with which HoA, do all the CoAs need to be mapped with all the
HoAs, etc.
Montavont, et al. Expires April 25, 2005 [Page 6]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
3. Scenarios
This section is split into two parts according to the number of
interfaces on the mobile node. This distinction is made to help the
reader to better understand the different cases, but also because the
benefits for the mobile node will be different according to this
parameter.
3.1 x=1: only onr interface on the host
1. One HoA, one CoA (1,1,1)
The host is not multihomed. The host has only one interface,
with one HoA and is currently away from its home link (one CoA on
the foreign link).
2. Several HoAs, one CoA (1,n,1)
The host is multihomed, since it has several HoAs. This case may
happen when a host is getting access to Internet through
different ISPs and each offers a Mobile IPv6 service to the host.
That way, the host will have a HoA per ISP. Once the host is
connected to a visited IPv6 subnet, it gets one CoA. This CoA
may be registered with all the Home Agents provided by the ISPs,
in order to remain simulteneously reachable through all its HoAs.
3. One HoA, several CoAs (1,1,n)
The host is multihomed since it has several CoAs. This case may
occur when the interface of the host is connected to a link where
multiple IPv6 prefixes are advertised.
4. Several HoAs, several CoAs (1,n,n)
The host is multihomed, since it has multiple addresses. This
case can be viewed as a combination of the two cases described
above: the host has several HoAs (e.g. given by different ISPs)
and several CoAs (e.g. because the host is receiving multiple
IPv6 prefixes).
3.2 x=n: The host has several interfaces
1. One HoA, one CoA (n,1,1)
The host is multihomed: this is a special case of a host with two
interfaces connected to different IPv6 subnets; one of the subnet
is the home network of the host and allows the host to directly
Montavont, et al. Expires April 25, 2005 [Page 7]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
use its HoA (without the MIPv6 mechanisms). The host can build a
temporarily IPv6 address on its other interface but it cannot
register the temporary address with its Home Agent because the
host is using its HoA. If the host decides to update its
location, it will not be able to use its HoA on the interface
connected to its home link.
2. One HoA, several CoAs (n,1,n)
The host is multihomed: the host has several addresses to choose
from. For example, consider a host with several interfaces, each
connected to an IPv6 network (the same or not). In this example,
at least one global IPv6 address is configured on each interface.
The host has only one home link, and only one Home Agent.
3. Several HoA, one CoA (n,n,1)
The host is multihomed. This case extends the case (n,1,1) when
the host has several HoAs, for example from multiple ISPs. The
CoA can be associated with each HoA.
4. Several HoAs, several CoAs (n,n,n)
The host is multihomed. Many scenarios may lead to this case.
For example, consider a host with three interfaces, two of them
connected to their home link (two different HoAs) and the last
one connected to a visited link where two IPv6 prefixes are
advertised.
Montavont, et al. Expires April 25, 2005 [Page 8]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
4. Open Issues
In this section we highlight open issues which have to be taken into
account to handle a multihomed host using Mobile IPv6 and we list the
requirements for a Mobile IPv6 node to benefit from its multihomed
configuration in an optimized fashion. To meet some of these
requirements, specific procedures in the Mobile IPv6 specification
will be required. It's not the purpose of this document to provide
solutions to meet these requirements but we give some hints.
Solutions to meet these requirements shall be defined in a separate
document.
4.1 Issues Related to Mobile IPv6
1. In the (*,n,*) cases when the mobile host obtains a new CoA, it's
not clear to which HoA the new CoA would be bound to. There is
thus a need to define a relationship between HoAs and CoAs. For
example, does the mobile node needs to register each new CoA with
each HoA.
2. In the (*,1,n) cases, several CoAs may be simultaneously used by
a mobile node. In this case, the host must be able to register
all CoAs with a single HoA on a distant node (Correspondent Node
or Home Agent). Also, the MN needs a mechanism to select the
primary CoA to be bound to the HA. Other mechansims may be
needed to define policies to use several CoAs simultaneously,
according to the CN and/or the flow. The issues related to the
multiple CoAs usage are "how to manage multiple CoAs bound to a
single HoA" and "how to identify an entry in the Binding Cache".
Solutions like [4] may be used.
3. In case (*,n,*) cases, a HoA may be seen as a CoA from the
perspective of another home link of a mobile node. For example,
let us assume a mobile node with three interfaces, where each
interface has a home address (HoA1, HoA2 and HoA3 repectively)
determined from three different home links. If we consider that
the mobile node is connected to two of its home links via two
interfaces, and looses its network connection via the third
interface, it may want to register its two other HoAs (i.e. HoA1
and HoA2) as a CoA for HoA3. Thus the definition of a HoA
address may need to be extended in the context of multiple
different HoAs.
4.2 Issues Not Related to Mobile IPv6
1. In the (n,*,*) cases, the solution should bring support to allow
a mobile host to simultaneously use several interfaces,
Montavont, et al. Expires April 25, 2005 [Page 9]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
regardless the number of HoAs and CoAs the mobile node may have
and regardless the network topology the mobile node is connected
to. The simultaneous use of several interfaces would allow a
mobile node to spread its different flows between its interfaces.
2. In the (*,n,*) case, a mechanism should be defined to detail how
to bind multiple HoAs to a host.
3. In the (n,*,*) cases, a mechanism is needed to redirect flows
from one interface to another: this functionality would allow a
mobile node to pursue all communication flows that were initiated
via the old interface via another interface. MIPv6 can be used
to perform redirection between interfaces, as specified in [5].
4. In the (n,1,1) case, the node may want to use each interface
differently according to some policies and preferences that would
define which flow would be mapped to which interface and/or which
flow should not be used over a given interface. In order to
optimize the global connectivity of a multihomed host, a specific
support may allow a multihomed hosts to set filters on flows on
distant nodes (Correspondent Node or Home Agent), such as
mechanisms proposed by [6], [7] and [8].
4.3 Issues Related to a Host Connected to Home Link
In the (n,*,*) cases listed in Section 3, the host may have one of
its interfaces directly connected to a home link. This may have an
impact on the multihoming management.
For example, if we consider the case (n,n,n) with a host having three
interfaces, three HoAs and two CoAs (connected to two visited IPv6
subnets), the CoAs cannot be registered with the Home Agent serving
the host on the home link it is connected to.
Otherwise, the case (n,n,n) can translate into either case (n,n,1) or
(n,n,0) according to the way the host is connected to the Internet.
Case (n,n,1) only happens when the host is connected to a visited
link with only one interface and obtain only one CoA. Other
interfaces are connected to the home link(s). In the case (n,n,0),
i.e. several interfaces, several HoAs, and no CoA, all interfaces of
the host are connected to their respective home links.
4.4 Redirection transparency
When considering the goals/benefits defined in [3], one has to
consider whether these goals can be achieved with transparency or
without transparency. Transparency is achieved when switching
Montavont, et al. Expires April 25, 2005 [Page 10]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
between interfaces does not cause the disruption of on-going
sessions.
In order to achieve transparency, a necessary (may or may not be
sufficient) condition is for the end-point addresses to remain
unchanged. This is in-view of the large amount of Internet traffic
today are carried by TCP, which unlike SCTP, cannot handle multiple
end-point address pairs.
Montavont, et al. Expires April 25, 2005 [Page 11]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
5. Acknowledgments
The authors would like to than all the people who have sent comments
so far, particularly Tobias Kufner for raising a new issues.
6 References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[3] Ernst, T., Montavont, N., Wakikawa, R. and E-K. Paik, "Goals
and Benefits of Multihoming",
draft-ernst-generic-goals-and-benefits-00 (work in progress),
July 2004.
[4] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-03 (work in progress), July
2004.
[5] Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for
Multiple Interfaces", draft-montavont-mobileip-mmi-02 (work in
progress), October 2003.
[6] Soliman, H., Malki, K. and C. Castelluccia, "Per-flow movement
in MIPv6", draft-soliman-mobileip-flow-move-02 (work in
progress), July 2002.
[7] Montavont, N. and T. Noel, "Home Agent Filtering for Mobile
IPv6", draft-montavont-mobileip-ha-filtering-v6-00 (work in
progress), January 2004.
[8] Kuladinithi, K., "Filters for Mobile IPv6 Bindings (NOMADv6)",
draft-nomadv6-mobileip-filters-02 (work in progress), June
2004.
[9] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[10] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-02 (work in progress), October
2004.
[11] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay
Montavont, et al. Expires April 25, 2005 [Page 12]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
Networks", Journal Mobile Networks and Applications, vol. 3,
number 4, pages 335-350, 1998.
Authors' Addresses
Nicolas Montavont
LSIIT - Univerity Louis Pasteur
Pole API, bureau C444
Boulevard Sebastien Brant
Illkirch 67400
FRANCE
Phone: (33) 3 90 24 45 87
EMail: montavont@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~montavont/
Ryuji Wakikawa
Keio University
Jun Murai Lab., Keio University.
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81-466-49-1100
Fax: +81-466-49-1395
EMail: ryuji@sfc.wide.ad.jp
URI: http://www.mobileip.jp/
Thierry Ernst
WIDE at Keio University
Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Phone: +81-44-580-1600
Fax: +81-44-580-1437
EMail: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/
Montavont, et al. Expires April 25, 2005 [Page 13]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
Thomas Noel
LSIIT - Univerity Louis Pasteur
Pole API, bureau C444
Boulevard Sebastien Brant
Illkirch 67400
FRANCE
Phone: (33) 3 90 24 45 92
EMail: noel@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~noel/
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
EMail: cwng@psl.com.sg
Montavont, et al. Expires April 25, 2005 [Page 14]
Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Montavont, et al. Expires April 25, 2005 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 09:52:25 |