One document matched: draft-montavont-mobileip-mmi-00.txt
Internet Engineering Task Force N. Montavont
INTERNET DRAFT T. Noel
Expires in February 2003 LSIIT - ULP
M. Kassi-Lahlou
France Telecom R&D
July 2002
MIPv6 for Multiple Interfaces
<draft-montavont-mobileip-mmi-00.txt>
Status of This Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
This document is an Internet-Draft. 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.
Distribution of this memo is unlimited.
Abstract
MIPv6 [MIPv6] allows a MN to maintain its IPv6 communications
while moving between subnets. This document presents the
problematic for a MN of having multiple network interfaces. It
discusses how to perform vertical handovers (flow redirection
between interfaces) and propose MMI (MIPv6 for Multiple
Interfaces) which describes the use of MIPv6 to support multiple
interfaces. These extensions focus on the MN ability to use a
backup interface for communications and to redirect flows between
its own interfaces.
draft-montavont-mobileip-mmi-00.txt [Page 1]
INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003
Table of contents
Status of this memo
Abstract
1. Introduction.............................................2
2. Terminology related to multiple interfaces...............3
2.1 Terminology..........................................3
2.2 Network configuration................................4
3. Motivations..............................................5
3.1 Why a MN may want to redirect a flow.................5
3.2 Scenarios............................................5
3.2.1 Two interfaces available at the same time......5
3.2.2 Only one interface available at a given time...6
4. Multiple interfaces management...........................6
4.1 Hypothesis..........................................6
4.2 MMI.................................................7
5. Future Work..............................................8
5.1 Receiving new communications.........................8
5.2 Filtering............................................8
6. References...............................................9
7. Authors' address.........................................10
Appendix A: Local Redirection...............................10
1. Introduction
Future MNs will probably have multiple interfaces to be connected
to different access technologies. Each technology has its specific
characteristics in terms of coverage, bandwidth, reliability,
etc. While MIPv6 [1] allows a MN to handover between subnets,
there are no requirements to manage mobility into the MN,
i.e. between several interfaces. This document presents the
problematic of having multiple interfaces and proposes some simple
extensions to MIPv6, called MMI (MIPv6 for Multiple Interfaces) to
optimize the use of multiple interfaces.
Assume a MN with two interfaces. For example, the MN can be
connected to the network with only one interface. After a move, it
connects to the network with the other interface and looses the
network connectivity through the first. Subsequently the MN may
want all the flows using the first interface to be automatically
redirected on the other available interface. Or, a MN can take
advantage of having multiple interfaces by using backup
interface. Also, if a MN performs a handover between subnets, it
may redirect its flows on another interface while it performs
MIPv6 operations. This minimizes the impact of the handover on the
applications.
draft-montavont-mobileip-mmi-00.txt [Page 2]
INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003
In this document, the specific operations needed to perform
vertical handovers are described. In the next section, some
definitions related to multiple interfaces management are
given. The section 3 explains why a MN may want to redirect flows
between its interfaces and gives two scenarios of a MN with
multiple interfaces. Then, MMI operations are described for a
generic network configuration. These operations describe the use
of MIPv6 to perform vertical handovers. Finally, the document ends
on further functionalities which are going to be developped later.
2. Terminology related to multiple interfaces
2.1 Terminology
The following terms are introduced in the document. Some
definitions are taken from [2].
Available interface
An interface that offers to the MN connectivity to the
network. The MN can initiate and receive flows through this
interface
Interface down
An interface is down when it is not available for flows. An
interface may be down for many reasons (e.g. the interface is
deactivated by the user, the interface is physically not inserted
in the MN, the interface is not connected to a network)
L2 handover
The change of access point
L3 handover
The change of IP subnet
Horizontal handover
From the IP point of view, a horizontal handover happens if the MN
changes of subnet it is connected to
Vertical Handover [2]
In a vertical handover the MN's network interface to the access
network changes. A vertical handover is typically an
inter-technology handover
draft-montavont-mobileip-mmi-00.txt [Page 3]
INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003
Source interface
During a vertical handover, the source interface is the interface
from which flow will be redirected.
Target interface
During a vertical handover, the target interface is the interface
to which flow will be redirected.
2.2 Network configuration
This document focuses on the management of multiple network
interfaces into a single MN. Each interface is either wireless or
wired. This document will detail the operations needed for a MN to
redirect flow between its interfaces. In each proposition, we
discuss the redirection between two interfaces, but the operations
are effective even if a MN has more interfaces. The proposed
mechanism proposed works in all the network configurations
possible, that is to say all the network configurations to which
the MN is connected:
- The two interfaces are connected to the same subnet, the home
network for each interface
- The two interfaces are connected to the same subnet, a visited
network for each interface
- The two interfaces are connected to the same subnet, the home
network for one interface and a visited network for the other
- The two interfaces are connected to different subnets, the home
network for each interface
- The two interfaces are connected to different subnets, a home
network for one interface and a visited network for the other
interface
- The two interfaces are connected to different subnets, a visited
network for each interface
We will prove that some simple operations described in MMI are
sufficient for all the above network configurations.
draft-montavont-mobileip-mmi-00.txt [Page 4]
INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003
3. Motivations
3.1 Why a MN may want to redirect a flow
A MN may want to redirect its flows between its available
interfaces for many reasons:
- An interface in use comes down
- The MN can take advantage of having multiple interfaces and
redirects some or all flows from the down interface to another
available interface
- An interface comes up. The MN may decide that the interface
which comes up is most suitable for its current flows using
another interface
- The MN performs a handover on an interface in use for
flows. When a MN performs a horizontal handover, the handover
latency (the time during which the MN can not send nor receive
packets) can be long and the flows can be perturbed. If the MN
wants to minimize such perturbation, it can redirect some or all
the flows on another available interface. This redirection can be
done in advance of the handover by the L2 triggers [3]
- The network capabilities change. The MN can observe a
degradation of service on one of its interface, or conversely an
improvement of capacity on an interface. The MN may then decide to
redirect some or all flows on another interface that it considers
most suitable for the target flows.
3.2 Scenarios
3.2.1 Two interfaces available at the same time
Assume a global network covering wide areas, like third generation
network. A MN can access to services like telephony, e-mail and
web browser through an interface I1 connected to this wide
network. At the same time, the MN has Internet access with a
higher rate than the global network on an other interfaces I2,
e.g. in WLANs or hot spots. The coverage area of this second
technology is smaller than the global network and is also covered
by the global network.
When the mobile user enters the area covered by the technology
with the higher rate (e.g. WLANs), he may want to:
- Initiate new flow through I2
- Continue its current flows on I1
- Redirect some or all flows from I1 to I2 to take advantage of
the technology with the higher rate
draft-montavont-mobileip-mmi-00.txt [Page 5]
INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003
When the mobile user leaves the coverage area of the technology
with the higher rate, he may want to:
- Interrupt its flows using I2
- Redirect some or all flows from I2 to I1
3.2.2 Only one interface available at a given time
Consider a MN with two interfaces of different
technologies. Firstly, the MN is connected to the network with
only one interface. Then the MN connects to the network through
the other interface, typically after a move, and the MN looses its
first connection.
For example, assume a company offering an access to network
resources like Internet access or intranet. Consider a mobile host
with both a wireless and a wired interface. According to company
rules, the wireless subnet can or cannot be on the same subnet
than the wired subnet.
The two interfaces can be used in many ways: keep a backup interface,
use each interface for pre-determined traffic... According to the
availability of the interfaces, a MN may want to redirect flows
between its interfaces.
4. Multiple interfaces management
4.1 Hypothesis
In the following, we assume a MN with two interfaces I1 and I2 of
different access technologies. Each interface is configured with a
global IPv6 address, respectively IP1 and IP2. These two global
IPv6 addresses are assigned to the MN in such a way that both
addresses can be used to reach the MN.
The MN uses Mobile IPv6 on each of its interfaces when it moves
between subnets. Then the MN has a home link for each of its
interfaces and there is a router acting as a home agent on each
home link. The use of MIPv6 to redirect flows between interfaces
are highlight for a generic network configuration. The generic
network configuration encloses all the cases listed in section
2.2. MMI allows a MN to transparently redirect its ongoing flows
from its interface I2 to its interface I1 (vertical handover).
draft-montavont-mobileip-mmi-00.txt [Page 6]
INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003
4.2 MMI
MMI allows a MN to register a binding on its home agent (and
eventually its CNs) between two IP addresses, each allocated to
one of the MN's interfaces. The main mechanism is to send a
Binding Update to indicate a new CoA of a source interface through
the target interface. MMI works for any configuration network, as
when the MN is initially connected to the same subnet with its two
interfaces as when the MN is initially connected to different
subnet.
To make things as clear as possible, this document discusses the
flow redirection from (I2, IP2) to (I1, IP1) in order to
illustrate MMI. IP1 can be the home address allocated to I1, or
the current CoA allocated to I1.
The generic solution for the MN to redirect the flows intended to
IP2 on I1 (vertical handover from the source interface I2 to the
target interfaces I1) is to use the MIPv6 mechanism adapted for
multiple interfaces (MMI). The MN sends a Binding Update to its
home agent serving the MN for the source interface (and eventually
to its CNs). The Binding Update [1] must be sent as follow:
- The home address field set to the IP address bound to the source
interface (IP2)
- The CoA field set to the IP address bound to the target
interface (IP1)
This Binding Update must be sent through the target
interface. When receiving the Binding Update, the home agent
registers an association between IP2 and IP1 in its binding
cache. Therefore, all new flows with the destination address IP2
will be intercepted by the home agent and forwarded to the current
address allocated to target interface (IP1 on I1). This operation
does not disturb the initial communications on the target
interface I1 using IP1. Thus, MMI allows a MN to send a binding
information for a source interface by using another interface, the
target interface.
draft-montavont-mobileip-mmi-00.txt [Page 7]
INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003
Afterwards, if the MN moves to a new subnet by using the target
interface I1 (horizontal handover on I1), it obtains a new CoA
(IP3). Besides the operations required in MIPv6 when a MN changes
its point of attachment, the MN has to send a Binding Update to
its home agent serving the source interface (and eventually to CNs
of its current flows which have a binding between IP2 and IP1 in
their binding cache) to update its localization. Now, the binding
cache of the home agent records, among others, a binding between
the home address IP2 and the CoA IP3. Thus, the movement detected
on I1 is indicated to I2.
Later, if the MN wants to use the source interface I2 again and
had registered an association on its home agent between IP2 and
IP1, it needs to update the entry in the binding cache of the home
agent. If the MN is connected to a foreign network through the
source interface I2 (different from the home link), it sends a
Binding Update with the new IPv6 address got on the current link
as the new CoA, to update the binding cache of its home agent. If
the MN is connected to its home link through I2, it has to send a
Binding Update to its home agent to make it invalid the binding
cache for it (see returning home in [1]).
5. Further Work
In this section, we describe some further operations that can be
simply added to MMI framework in order to optimize the multiple
interfaces management.
5.1 Receiving new communications
Consider a MN which has redirected flows from a source interface
(I2, IP2) to a target interface (I1, IP1) as described in MMI
(section 4). If the MN receives a new flow forwarded by its home
agent, the MN has several possibilities: it might reject the flow
(e.g. the flow needs are not adapted to the network capacities
provided to the MN); Or if the MN does not reject the flow, it
might decide to inform the CN of the flow that its current address
is IP1 and that it needs to use routing header [1].
5.2 Filtering
Filtering the current flows
When a MN redirects its flows between its own interfaces, MMI
requires that the MN sends a Binding Update to its home agent
through the target interface (I1, IP1), in order to register a new
association for the source interface (I2, IP2). However, the MN
may not want to redirect all the flows of the source interface
(because the target interface can not support certain flows, or
the MN just wants to spread again its flows on all its interfaces
to optimize the network capacities). To advertise its home agent
(or a CN) to only redirect some flows of the source interface, the
MN should add filters in the Binding Update sent for the
redirection. The filter indicates which flow is concerned by this
binding [5][6].
draft-montavont-mmi-00.txt [Page 8]
INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003
The flow identification can be the one used in the Flow Label
field in the IPv6 header if set [7]. Otherwise, the flow
identification can be the quintuplet source and destination ports,
source and destination addresses and protocol ID.
Filtering future flows
Besides redirecting its current flows between its interfaces, a MN
may want to advertise its home agent to only redirect a part of
the future flows intended to it. We call future flows of the MN,
the flows that the MN could receive in the near future, that do
not exist when the MN sends the Binding Update for the
redirection. If the MN wants that its home agent only redirects
some of its future flows, it may add a new filter in the Binding
Update sent to its home agent. The new filter in the Binding
Update can indicate a protocol ID or an application ID. Therefore,
as soon as a new flow is intercepted by the home agent for the MN,
it checks if the filter matches with the flow to redirect the flow
to the right CoA.
6. References
[1] D. Johnson, C. Perkins. "Mobility support in IPv6",
draft-ietf-mobileip-ipv6-18.txt, July 2001.
[2] J. Manner, M. Kojo, "Mobility related terminology",
draft-manner-seamoby-terms-04.txt, May 2002.
[3] J. Kempf, et. al, "Supporting Optimized Handover for IP
Mobility - Requirements for Underlying Systems",
draft-manyfolks-l2-mobilereq-02.txt, June 2002.
[4] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[5] M. Diagne, T. Noel, "A Protocol for IPv6 Nomadic
Communications", 5th IEEE Malaysia International Conference on
Communications (MICC'01), Malaysia, October 2001
[6] H. Soliman, K. El Malki, C. Castelluccia, "Per-flow movement
in MIPv6", draft-soliman-mobileip-flow-move-01.txt, November 2001.
[7] J. Rajahalme, A. Conta, B. Carpenter, S. Deering, "IPv6 Flow
Label Specification", draft-ietf-ipv6-flow-label-00.txt, February
2002.
draft-montavont-mmi-00.txt [Page 9]
INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003
7. Authors' address
Nicolas Montavont
LSIIT - ULP
Pole API
Boulevard Sebastien Brant
67400 Illkirch
France
E-mail: montavont@dpt-info.u-strasbg.fr
Thomas Noel
LSIIT - ULP
Pole API
Boulevard Sebastien Brant
67400 Illkirch
France
E-mail: noel@dpt-info.u-strasbg.fr
Mohammed Kassi-Lahlou
France Telecom R&D
42, rue des Coutures
BP 6243
14066 Caen Cedex 4 - France
E-mail: mohamed.kassilahlou@francetelecom.com
Annexe A: Local Redirection
There is an easier mechnanism for the MN to redirect flow between
its interfaces when it is connected to the same subnet through its
interfaces. The Local Redirection allows a MN to transparently
redirect its ongoing flows between its interfaces without using
the MIPv6 features.
When a MN is connected to the same subnet though both I1 and I2 and
wants to redirect all its ongoing flows intended to IP2 (assigned
to I2) it can allocate IP2 to I1. The MN has to advertise its
neighbors on the link that all packets with the destination
address IP2 must now be forwarded to the MAC address of I1. To do
so, the MN sends an unsolicited Neighbor Advertisement [4] to all
nodes multicast address indicating the association between IP2 and
the MAC address of I1. The 'O' bit must be set in the unsolicited
Neighbor Advertisement to override the old entry associating IP2
to the MAC address of I2. This causes the neighbor nodes on the
link to add the association between the MAC address of I2 with
IP1. After, the MN is reachable through I1 by both IP1 and
IP2. This redirection is transparent to the distant CNs.
draft-montavont-mmi-00.txt [Page 10]
Expires: February 2003| PAFTECH AB 2003-2026 | 2026-04-22 07:18:07 |