[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New I-D on multi-homing
Hi all,
Just to inform you that we have submitted a new I-D on multihoming.
Lot of people have already work on multihoming in individual submissions.
We tried to write a problem statement for multihomed MN in this I-D
and hope that this I-D will initiate some discussions on this topic.
Here is the abstact of the I-D:
Individual solutions have been proposed to extend Mobile IPv6 in order
to allow mobile nodes to be multihomed, but all issues have not been
addressed by a single document. In this document, we thus propose a
taxonomy to classify the situations where a mobile node may be
multihomed. This taxonomy is then used to describe all multihomed
scenarios. Issues preventing mobile nodes to be multihomed while
operating Mobile IPv6 are highlighted. This document doesn't aim at
proposing solutions, however, it is expected to raise discussion in
order to make sure forthcoming solutions will address all the issues.
Nicolas
IETF Mobile IP Working Group N. Montavont
Internet-Draft LSIIT
Expires: April 9, 2004 R. Wakikawa
T. Ernst
WIDE at Keio University
T. Noel
LSIIT
October 10, 2003
Problem Statement for multihomed Mobile Nodes
draft-montavont-mobileip-multihoming-pb-statement-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 9, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Individual solutions have been proposed to extend Mobile IPv6 in
order to allow mobile nodes to be multihomed, but all issues have not
been addressed by a single document. In this document, we thus
propose a taxonomy to classify the situations where a mobile node may
be multihomed. This taxonomy is then used to describe all multihomed
scenarios. Issues preventing mobile nodes to be multihomed while
operating Mobile IPv6 are highlighted. This document doesn't aim at
Montavont, et al. Expires April 9, 2004 [Page 1]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
proposing solutions, however, it is expected to raise discussion in
order to make sure forthcoming solutions will address all the issues.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . 6
4.1 Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 MN connected to home link . . . . . . . . . . . . . . . . . . 8
5. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
Montavont, et al. Expires April 9, 2004 [Page 2]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
1. Introduction
New mobile nodes often integrate several wireless technologies. The
main purpose of this integration is to federate all means of
communications in order to have an ubiquitous mobile node which can
be used to access to the Internet everywhere and at any time.
Permanent Internet connectivity is required by some applications
while a mobile node moves across several access networks (i.e. ISPs,
hotspots, etc). For example, it is desirable to maintain the
Internet connectivity while an automobile running on a freeway
receives voice or video streaming data from different access
networks.
Unfortunately, there is no network interfaces assuring global scale
connectivity. Therefore, a mobile node should use various type of
network interfaces to obtain wide area network connectivity [11]. In
addition, each network interface has different cost, performance,
bandwidth, access range, and reliability. Users should thus be able
to select the most appropriate set of network interface(s) depending
on a visiting network environment, since wireless networks are
mutable and less reliable than wired networks. Users should also be
able to select the most appropriate interface per communication type.
For example, TCP communication is best transmitted over wireless
interface, while UDP communication is sent over a wired interface to
avoid disturbing TCP connections.
Mobile IPv6 [1] is being designed to allow a mobile node to maintain
its IPv6 communications while moving between IPv6 subnets. However,
the current specification does not give any hints nor requirements to
deal with mobile nodes with several points of attachement, i.e. a
multihomed mobile node. We propose to evaluate the behavior of
standard Mobile IPv6 on a multihomed mobile node, and we will try to
identify if modifications or enhancements are required in the
specification.
This document has two goals. The first goal is to define a taxonomy
which helps to represent the different cases of multihoming. Then we
describe scenarios where mobile nodes are multihomed. These
scenarios show the configuration a mobile node may have (number of
interfaces, number of home addresses or number of careof 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 mobile nodes. Different issues will be raised
in order to provide full support of multihomed mobile nodes in MIPv6.
The potentially needed solutions to support new features will be
described in a separate document.
Montavont, et al. Expires April 9, 2004 [Page 3]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
2. Terminology
In this section we define the terms needed to analyse mobile node
with mulitple points of attachment. Some definition are taken from
[1], while other are completed or only defined in this document.
Interface (from [7])
A node's attachment to a link
Multihomed mobile node
A mobile node is said multihomed when it has several IPv6
addresses to choose between. A mobile node has several IPv6
addresses to choose between in the following cases:
multi-prefixed: multiple prefixes are advertised on the link(s)
the mobile node is connected to.
multi-interfaced: multiple interfaces to choose between, on the
same link or not.
multi-linked: multiple links to choose between (just like
multi-interfaced but all interfaces are NOT connected to the
same link)
multi-sited: when using IPv6 site-local address and attached to
different sites
Montavont, et al. Expires April 9, 2004 [Page 4]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
3. Benefits
Several benefits of multihoming can be envisioned:
o Ubiquitous Computing: to provide an extended coverage area.
Multiple interfaces bound to distinct technologies can then be
used to ensure a permanent connectivity is offered.
o Redundancy: to act upon failure of one point of attachment.
o Load Balancing: to balance load between multiple point of
attachments (simultaneously active or not).
o Preference settings: to provide the user or the application the
ability to choose the prefered transmission technology or access
network for reasons of cost, politics, bandwidth requirement,
delay, etc.
Montavont, et al. Expires April 9, 2004 [Page 5]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
4. Multihoming Scenarios
Different scenarios may lead to the fact that a mobile node may be
multihomed. In this section are listed all the configurations where
a mobile node may have multiple points of attachment.
4.1 Taxonomy
To help to refer to a specific scenario, we define the following
scheme: Scenario (x,y,z) where
o x = number of home addresses (HoAs)
o y = number of careof addresses (CoAs)
o z = number of active interfaces
The value of each identifier can be 1 if there is only one parameter,
or n if there are several. The value n does not specify any number,
but indicate that there are more than one parameters. An
illustration of this taxonomy is given in Figure 1.
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 interface)
HoA1 ::= {CoA1, 2, 3} [IF1 and IF2]
HoA2 ::= {CoA3} [IF2]
Mobile Node(x = 2, y = 3, z = 2)
Figure 1. Illustration of the chosen taxonomy
Montavont, et al. Expires April 9, 2004 [Page 6]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
* because number of IPv6 link is equal to the number of CoAs, equal
to y
The variable x indicates the number of HoAs allocated to a MN. A MN
may have multiple HoAs (x=n) when either:
o The MN has only one home link, and all its HoAs are based on the
same IPv6 prefix (e.g. the MN may have multiple interfaces).
o The MN has only one home link, and several home addresses with
distinct prefixes because there are several IPv6 prefixes
advertised on the home link.
o The MN has several home links, and thus has at least two HoAs with
different IPv6 prefixes.
4.2 scenario
1. One HoA, one CoA, one interface (1,1,1)
The MN is not multihomed. The MN has only one interface, with
one HoA and is currently away from its home link.
2. Several HoAs, one CoA, one interface (n,1,1)
The MN is multihomed, since it has several home addresses. Once
the MN is connected to a visited IPv6 subnet, it gets one CoA and
remains simulteneously reachable through all its HoAs.
3. Several HoAs, several CoAs, one interface (n,n,1)
The MN is multihomed, since it has multiple addresses to choose
between. In this case, the MN can be either connected to
different IPv6 links at the same time, with the same interface,
or it can be attached to a single link where several IPv6
prefixes are advertised. In the latter case, it configures a CoA
for each prefix. Then, it may register several of them with
distant nodes to benefit from its multihoming properties.
4. Several HoAs, several CoAs, several interfaces (n,n,n)
The MN is multihomed. Many scenarios may lead to this case. For
example, consider a MN with three interfaces, two of them
connected to their home link(two different home addresses) and
the last one connected to a visited link where two IPv6 prefixes
are advertised.
Montavont, et al. Expires April 9, 2004 [Page 7]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
5. One HoA, several CoAs, one interface (1,n,1)
The MN is multihomed (several CoAs). The case (1,n,1) occurs
when a MN is connected to different IPv6 links with the same
interface: either there are several IPv6 prefixes advertised on
the link, or the interface allows the MN to be connected to
different access point in different IPv6 subnets.
6. One HoA, several CoAs, several interfaces (1,n,n)
The MN is multihomed: the MN has several addresses to choose
between. For example, assume a MN with several interfaces, each
connected to an IPv6 network (the same or not). Then at least
one IPv6 address is configured on each interface. The MN has
only one home link, and only one home agent.
7. One HoA, one CoA, several interfaces (1,1,n)
The MN may be multihomed: if the MN has two interfaces, one
connected to its home link (using its home address) and the other
connected to a visted link (using a careof address), the MN is
multihomed. If the MN is connected to a visited link with one
interface and has no IPv6 connectivity with the other interfaces
(not in the range of an access point or no IPv6 prefix forwarded
on a Layer 2 link), the MN is not multihomed.
4.3 MN connected to home link
When a MN is multihomed, some of its interfaces may be connected to
its home link(s), at any point of time. In all multihoming scenarii
listed in the previous subsection, the MN may be directly connected
to a home link. Sometimes, when a MN is connected to a home link, it
may have an impact on the multihoming management.
For example, in the case (n,n,n), a MN may be connected to its home
link(s) with some interface(s). If we consider the case where a MN
has three interfaces, three HoAs and two CoAs (connected to two
visited IPv6 subnets), the CoAs can not be registered with the home
agent serving to MN on the home link it is connected to. This case
has to be considered when defining the management of multihoming.
Otherwise, the case (n,n,n) can translate into either case (n,1,n) or
(n,0,n) according to the way the MN is connected to the Internet.
Case (n,1,n) only happens when the MN is connected to a visited link
with only one interface and obtain only one CoA. Other interfaces
are connected to the home link(s).
Montavont, et al. Expires April 9, 2004 [Page 8]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
In the case (n,0,n), i.e. several HoAs, no CoA, and several
interfaces, all interfaces of the MN is connected to a home link. If
home links have different prefixes, a HoA can be a CoA regarding
another HoA. Such considerations must be taken into account in a
document which presents a solution for multihomed MN since some MIPv6
features can not be used when the MN is connected to the same link as
its home agent (e.g. home registration). So the fact that a
multihomed MN is connected to a home link must be considered.
Montavont, et al. Expires April 9, 2004 [Page 9]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
5. Open issues
In this section we highlight different points which have to be taken
into account to handle a multihomed MN using Mobile IPv6. These
items constitute the requirements for a Mobile IPv6 node to benefit
from its multihomed configuration in an optimized fashion. Some of
them do not require more processing than those defined in [1] but
management operation, while other requires changes in [1]. Only the
needed requirements are given in this document, the solutions to meet
these requirements will be defined in a separate document.
Issues related to the Mobile IPv6 protocol are the following:
1. How to define a relation between HoAs and CoAs. When a MN has
several HoAs and obtain a new CoA, to which HoA the new CoA will
be bound to ? Moreover, a HoA may be considered as CoA regarding
another home link of the MN.
2. How to identify an entry in the Binding Cache: several CoAs can
be simultaneously used by a mobile node when it has multiple
points of attachments. These CoAs can be bound to the same HoA
on any distant node, such as the home agent whih manages this
mobile node for this particular HoA. Therefore both distant node
and the mobile node need a way to identify an entry in the
Binding Cache.
3. How to manage multiple CoAs bound to a single HoA: a multihomed
MN may have multiple Care-of addresses. The MN must be able to
register all CoAs with a single HoA on a distant node
(Correspondant node or HA).
Issues non-related to the Mobile IPv6 protocol are the following:
1. How to allow a mobile node to simultaneously use several
interfaces: this will be the global purpose of such a solution to
support multiple interfaces on a mobile node. The solution
should bring support to allow a MN, or even a fixed multihomed MN
to simultaneously use several interfaces, whatever the number of
HoAs, of CoAs the mobile node may have and whatever the network
configuration the mobile node is connected to.
2. How to manage multiple HoAs: a mobile node may have several HoAs.
As the taxonomy suggests, the fact that the mobile node has
several HoAs is independant from the fact that the mobile has
multiple interfaces. By the way, the fact that the mobile node
has multiple interfaces does not imply that it has multiple HoAs
and vice-versa. A mechanism should thus be defined to detail how
to bind HoAs to a MN.
Montavont, et al. Expires April 9, 2004 [Page 10]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
3. How a mobile node may redirect flows from one interface to
another, in the different scenarios presented in section 3: this
functionality would allow a mobile node to pursue any
communication began on an interface while this interface becomes
down and another one is available.
4. When a MN has several interfaces, it may want to use each
interface differently. According to some policies and
preferences, a multihomed MN may want to independantly manage
each flow, in order to define which flow would be mapped to which
interface and/or which flow can not use a determined interface.
In order to optimize the global connectivity of a multihomed MN,
a solution may be defined to allow multihomed MN to set filters
on flow on distant nodes, such as mechanisms proposed by [10],
[5] and [4].
Montavont, et al. Expires April 9, 2004 [Page 11]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
References
[1] Perkins, C. and J. Arko, "Mobility Support in IPv6", I-D
draft-ietf-mobileip-ipv6-24.txt, June 2003.
[2] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
protect Mobile IPv6 signaling between Mobile Nodes and Home
Agents", I-D draft-ietf-mobileip-mipv6-ha-ipsec-06.txt, June
2003.
[3] Montavont, N., Noel, T. and M. Kassi, "MIPv6 for Multiple
Interfaces", I-D draft-montavont-mobileip-mmi-01.txt, October
2003.
[4] Koojana, K., Fikouras, N., Koensgen, A. and C. Goerg, "Filters
for Mobile IPv6 Bindings (NOMADv6)", I-D
draft-nomadv6-mobileip-filters-00.txt, July 2003.
[5] Montavont, N. and T. Noel, "Home Agent Filtering For Mobile
IPv6", I-D draft-montavont-mobileip-ha-filtering-v6-00.txt,
July 2003.
[6] Wakikawa, R., Uehara, K., Ernst, T. and K. Nagami, "Multiple
careof Address Registration on Mobile IPv6", I-D
draft-wakikawa-mobileip-multiplecoa-02.txt, September 2003.
[7] Manner, J. and M. Kojo, "Mobility Related Terminology", I-D
draft-ietf-seamoby-mobility-terminology-04.txt, April 2003.
[8] Fikouras, N., Udugama, A., Koensgen, A., Goerg, C., Zirwas, W.
and J. Eichinger, "Filters for Mobile IPv6 Bindings (NOMADv6)",
I-D draft-nomad-mobileip-v6-filters-00.txt, July 2003.
[9] Ernst, T., "Network Mobility Support Terminology", I-D
draft-ietf-nemo-terminology-00.txt, May 2003.
[10] Soliman, H., Elmalki, K. and C. Castelluccia, "Flow Movement in
Mobile IPv6", I-D draft-soliman-mobileip-flow-move-03.txt, June
2003.
[11] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay
Networks", Journal Mobile Networks and Applications, vol. 3,
number 4, pages 335-350, 1998.
Montavont, et al. Expires April 9, 2004 [Page 12]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
Authors' Addresses
Nicolas Montavont
LSIIT - Univerity Louis Pasteur
Ple 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
Jun Murai Lab., Keio University
5322 Endo Fujiwasa
Kanagawa 252-8520
Japan
Phone: +81-466-49-1394
EMail: ryuji@sfc.wide.ad.jp
URI: http://www.mobileip.jp/
Thierry Ernst
Jun Murai Lab.
Keio University K2 Town Campus
1488-8 Ogura, Saiwai-ku, Kawasaki
Kanagawa 212-0054
Japan
Phone: +81-44-580-1600
EMail: ernst@sfc.wide.ad.jp
URI: htpp://www.sfc.wide.ad.jp/~ernst
Thomas Noel
LSIIT - Univerity Louis Pasteur
Ple API, bureau C444
Boulevard Sébastien 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/
Montavont, et al. Expires April 9, 2004 [Page 13]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Montavont, et al. Expires April 9, 2004 [Page 14]
Internet-Draft Problem statement for multihomed Mobile Nodes October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Montavont, et al. Expires April 9, 2004 [Page 15]