NetExt Working Group M. Jeyatharan
Internet-Draft C. Ng
Intended status: Informational Panasonic
Expires: July 27, 2009 January 23, 2009
Multihoming Problem Statement in NetLMM
draft-jeyatharan-netext-multihoming-ps-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 July 27, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
The base PMIPv6 protocol does not have adequate mechanisms to support
advanced multihoming such as simultaneous usage of all interfaces of
Jeyatharan & Ng Expires July 27, 2009 [Page 1]
Internet-Draft Multihoming PS in NetLMM January 2009
a mobile node (MN) to receive and transmit data packets associated
with a given prefix allocated to MN, and allow flow based routing
according to preference, rules, and policies set by the MN or network
entity. This memo highlights such advanced multihoming related
issues when mobility of the multiple interfaced mobile node (MuIF MN)
is purely managed by PMIPv6 mechanism. It also highlights the issue
of lack of simultaneous attachment support when the mobility of the
MuIF MN is managed by PMIPv6 and CMIPv6 mechanisms.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Advanced Multihoming Issues in PMIPv6 . . . . . . . . . . . . 3
3. Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario . . . . . . 7
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 11
7.2. Informative Reference . . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Jeyatharan & Ng Expires July 27, 2009 [Page 2]
Internet-Draft Multihoming PS in NetLMM January 2009
1. Introduction
The multihoming support that is covered in the base Proxy Mobile IPv6
(PMIPv6) protocol [1] is simply simultaneous attachment support for
multiple interfaced mobile nodes (MuIF MNs) such that a mobile node
(MN) can use all its interfaces for data communication. Although
using multiple interfaces for data communication is one aspect of
multihoming, multihoming has many deeper motivations and scenarios
attached to it as outlined in [2] and the base PMIPv6 protocol [1]
does not have support for such advanced multihoming scenarios.
There are many advanced multihoming scenarios associated with
multiple interface attachment in PMIPv6 domain. One such scenario
can be simultaneous "usage" of multiple interfaces for flows
associated with a prefix given to the MN to achieve load sharing and
load balancing benefits. Another scenario is preference or policy
setting at the local mobility anchor (LMA) to enable a certain flow
to traverse via an interface that is not allocated the prefix
associated with the flow, so as to achieve the benefits of cost,
preference, better quality of service (QoS) and/or security. Such
transferring of flows via a preferred access type is generally
referred as flow mobility. Another such advanced multihoming
scenario can be transferring of certain flows associated with a group
of prefixes from one interface to a newly powered on interface to
satisfy user preference. Finally, one more scenario can be usage of
simultaneous attachment in order to improve handoff performance. To
implement such advanced multihoming scenarios that provides numerous
benefits to data traffic of MN and the network operation and
maintenance, there needs to be modification done to the PMIPv6 base
protocol.
In this memo, the advanced multihoming issues stated above are
highlighted when the MuIF MN is connected to a domain in which only
PMIPv6 is operated. In some network deployments the MuIF MN's
mobility may be managed by different mechanisms such that the
mobility of a certain interface will be managed by PMIPv6 mechanism
and the mobility of another interface will be managed by CMIPv6
mechanism. Thus it is essential that PMIPv6 protocol has adequate
support in such an environment to enable a Multiple Interfaced Mobile
Node to be simultaneously attached to the network via its interfaces.
In this memo, the lack of simultaneous attachment support in this
mixed PMIPv6 and client MIPv6 (CMIPv6) environment is also
highlighted.
2. Advanced Multihoming Issues in PMIPv6
In this section, three classes of issues will be looked into. They
Jeyatharan & Ng Expires July 27, 2009 [Page 3]
Internet-Draft Multihoming PS in NetLMM January 2009
are the simultaneous usage related issues, flow based routing related
issues and issues related to transferring a sub-group of prefixes
associated with an existing interface to a newly powered on
interface. In addition to these, the issue associated with handoff
performance when there is no advanced multihoming support is also
briefly highlighted.
o Issues Related to Simultaneous Usage of Interfaces
The issues related to simultaneous usage of interfaces will be
further split into three sub issues for deeper understanding of
the problem. The first sub-issue occurs when the MuIF MN wants
flows associated with an application to traverse via all its
interfaces, the second sub-issue occurs when the MuIF MN wants
flows associated with a given prefix of MN to traverse via all its
interfaces and the third sub-issue occurs when the MuIF MN wants
flows associated with a given group of prefixes of MN to traverse
via all its interfaces.
+-----+ +-----+
| CN2 |....| CN3 |
+-----+ +-----+
|
| +---------------+-----------+--------+
| | Home Prefix | CoA | IF-ID |
+-----+ +--------+ +---------------+-----------+--------+
| CN1 |-----| LMA | | MN.Prefix1(P1)| MAG1.Addr | IF-ID1 |
+-----+ +--------+ | MN.Prefix2(P2)| MAG2.Addr | IF-ID2 |
| +---------------+-----------+--------+
|
+--------------------------+
| |
| Proxy Mobile IPv6 Domain |
| |
+--------------------------+
| |
MAG2 Address | | MAG1 Address
(MN.IF2 proxy CoA) | | (MN.IF1 proxy CoA)
+------+ +------+
| MAG2 | | MAG1 |
+------+ +------+
\ /
IF2(3G) \ / IF1(WLAN)
+------+
| MN |
+------+
Jeyatharan & Ng Expires July 27, 2009 [Page 4]
Internet-Draft Multihoming PS in NetLMM January 2009
Figure 1: Simultaneous Usage in PMIPv6 Domain
In Figure 1, it is assumed that the MN with two interfaces such as
interface 1 (IF1) and interface 2 (IF2) are attached to Mobile
Access Gateway 1 (MAG1) and MAG2 respectively. These MAGs and the
LMA shown in Figure 1 are all attached to the same Proxy Mobile
IPv6 domain. According to PMIPv6 operation, it is considered that
the IF1 will be assigned prefix P1 and IF2 will be assigned prefix
P2. Thus, all flows addressed to P1 prefix of MN will traverse
via the IF1 irrespective of which application that the flows
belong to or to which CN the flows are associated with. However,
if MN is having video conference with CN1 for example, then, MN
may want the voice flows associated with the application to
traverse via 3G interface for better Quality of Service (QoS) and
want the video flows associated with the application to traverse
via the wireless local area network (WLAN) interface to get a
higher bandwidth. The media flows associated with an application
can be uniquely identified by a combination of parameters such as
flow label, transport protocol numbers and port numbers as
outlined in [3].
If the above mentioned voice and video flows have source or
destination addresses associated with a certain interface such as
interface 1 of MN, then according to standard PMIPv6 operation,
the MN cannot enjoy its flows associated with video conference
application to traverse via both its interfaces. This is because
the standard PMIPv6 operation is such that routing is done only
based on P1 prefix and nothing else. To fully enjoy the benefit
of simultaneous usage, some rules needs to be set at LMA such that
it is given instructions to route voice flows associated with P1
prefix via interface 2 and furthermore, the MAG2 should have
additional support where such traversal of voice flow is possible.
New functionality is essential in LMA, MAG and perhaps even in the
MN to achieve simultaneous usage of its interfaces for traversal
of the multimedia application flows.
In an alternate scenario associated with Figure 1 it is considered
that MN is downloading some data files and also performing some
web browsing and the CNs from which the MN is getting such data
are CN1 and CN2 respectively. It is further considered that the
prefix associated with MN to communicate with CN1 and CN2 is P1
and all the data packets associated with file transfer and web
browsing will traverse via IF1. However, when the 3G interface is
not used much by the MN for other flows, the MN may want all the
data flows sent to P1 prefix from CN1 and CN2 to be sent to both
interfaces of MN to achieve higher bandwidth for web browsing and
file transfer applications. The MN can inform the LMA via the MAG
that it needs P1 flows via both its interfaces and want
Jeyatharan & Ng Expires July 27, 2009 [Page 5]
Internet-Draft Multihoming PS in NetLMM January 2009
simultaneous usage service. As explained previously, base PMIPv6
protocol does not support this simultaneous usage scenario where
simultaneous usage is preferred for a given prefix. For such
simultaneous usage to happen, in case of downlink packets for
example, MAG2 needs to be able to route packets sent to P1 prefix
and LMA needs to be able to route packets sent to P1 prefix via
MAG2 as well as MAG1.
In another scenario associated with Figure 1 , MN may have started
communication with CN1 using P1 and communication with say CN3
using P2. However, due to load balancing feature or function
being implemented in the network, the LMA may send certain P2
flows via IF1 and certain P1 flows via IF2. Such network
initiated load balancing is essential in order to take some
measures to prevent the network segments from being overloaded.
In some cases, the MN may give its preference such as inform the
network which P1 flows it does not mind being sent via interface 2
and which P2 flows it does not mind being sent via interface 1.
Thus in such a scenario, both MAG1 and MAG2 need to know MN other
interface prefixes and flow parameters and also the LMA need to
send some P1 flows via MAG2 and some P2 flows via MAG1. Again,
such simultaneous usage support where simultaneous usage of MN
interfaces for flows associated with multiple prefixes of MN is
not supported by the base PMIPv6 protocol.
o Issues Related to Flow based Routing
The MN in Figure 1 may want flows associated with P1 to be always
routed via interface 2 and flows associated with P2 to be routed
via interface 1. Such a scenario can happen when the MN decides
to swap interfaces for flows based on dynamic state and user
preference. In such a case, simultaneous usage is not activated
but flow based routing needs to be implemented. Again, the
current PMIPv6 protocol does not provide the required support. In
such an environment, again, some modifications have to be done to
the MAG, LMA and MN in order to provide flow based routing.
o Issues Related to Handoff performance When all Interfaces are
connected
If the MN in Figure 1 is simultaneously attached to the PMIPv6
domain, one of the interface undergo handoff while the other
interface remains attached to the same access router. For
example, due to the coverage area differences, the MN may change
its access router for the WLAN interface while the access router
of its 3G interface remains unchanged. In such a case, until the
WLAN interface's routing path is set up, packet loss and delay
will be experience for P1 flows (P1 being assigned to WLAN
Jeyatharan & Ng Expires July 27, 2009 [Page 6]
Internet-Draft Multihoming PS in NetLMM January 2009
interface). To minimize such degradation during handoff, there
needs to be mechanism allowing flows using the P1 prefix to be
temporarily routed via the 3G interface. The base PMIPv6 protocol
does not support this scenario of simultaneous usage during
handoff. To enable such handoff enhancement, the MAG and the LMA
needs to be able to route P1 flows via interface 2 while interface
1 is handing off.
o Issues Related to Flow Mobility during Sudden Disconnection
In Figure 1, it is considered that MN is attached to the PMIPv6
domain via both its interfaces. If suddenly, MN looses connection
to the network via IF1, according to standard PMIPv6 operation,
the MN needs to trigger vertical handoff at the 3G MAG to see P1
flows via IF2 and maintain session continuity. However, this
cannot happen during disconnection, where the MN may not
immediately know a disconnected state to correctly trigger
vertical handoff at 3G MAG. Thus, there needs to be an
appropriate mechanism available to handle this disconnection
scenario as well.
o Issues Related to transfering a sub-group of prefixes during
Simultaneous Attachment
Consider the case where the MN in Figure 1 initially has only its
3G interface active and assigned with multiple prefixes (eg. P1
and P2). When the MN subsequently discovers the WLAN access, it
may want to use the WLAN interface simultaneously to achieve
multihoming benefits. Later, when WLAN interface attaches to the
PMIPv6 domain, according to standard PMIPv6 operation, a new
prefix (say P3) will be assigned. However, MN already has two
prefixes and may want to transfer flows using the prefix P2 to the
WLAN interface due to preference, cost and/or bandwidth etc.
Thus, some mechanisms need to be available such that the MN when
attaching the WLAN interface can select a subset of prefixes
assigned to 3G interface and request it to be assigned via the
WLAN interface. Currently, the base PMIPv6 protocol does not
support this. It only supports the vertical handoff case where
all prefixes assigned to an old interface is transferred to a new
interface when the old interface is shut down and the new
interface turned on.
3. Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario
In this section, PMIPv6 and CMIPv6 interaction scenarios are analyzed
for MuIF MN that has MONAMI6 type of functionality. The MONAMI6 type
of functionality is given in [4]. For the MuIF MN, the main issue in
Jeyatharan & Ng Expires July 27, 2009 [Page 7]
Internet-Draft Multihoming PS in NetLMM January 2009
a PMIPv6 and CMIPv6 mixed scenario arises when the network is not
aware of the simultaneous attachment related parameters used by MN
(i.e. CMIPv6 multihoming parameters) and MN is not aware of the
network parameters (i.e. PMIPv6 multihoming parameters) used for
simultaneous attachment. Such synchronization mismatch between
network entities and terminal entities leads to lack of multihoming
or simultaneous attachment support for the MN.
In third generation partnership project service architecture
evolution (3GPP SAE) framework as outlined in [5], the MN can select
PMIPv6 or CMIPv6 (i.e. Dual stack MIPv6) when attaching via an
interface or the network presets the allowed mobility management
mechanism for certain interface of MN. There are many scenarios
involved with such simultaneous attachments using different mobility
management mechanisms. Some of the possible scenarios are next
outlined. One possible scenario could be that MN (that has two
active interfaces) is connected to home domain (in 3GPP terms, home
public land mobile network, or HPLMN) via both its interfaces. One
interface may be using CMIPv6 for mobility management, while the
other uses PMIPv6 for mobility management. Another scenario could be
that MN is simultaneously attached to home (HPLMN) and foreign
domains (in 3GPP terms, visited public land mobile network, or
VPLMN). Again, MN could be using PMIPv6 for mobility management in
its home domain, while using CMIPv6 for mobility management in the
foreign domain. Although the problem is highlighted in a scenario
that is used in 3GPP standard organization (SDO), this is applicable
in similar scenarios that arises in other SDOs.
+----------+ BCEs at LMA/HA
| LMA/HA | +-------------+---------+-------+-------------+
| (P-GW) | | MN prefix | MN.CoA | MN-ID | If-ID/BID |
+----------+ +-------------+---------+-------+-------------+
| \ | HoA | CoA.AR | - | BID1 |
| \ | home prefix | MAG2addr| NAI | BID2 |
| \ +-------------+---------+-------+-------------+
| \
| \
+-------------+ +---------------+
| MAG1 (AGW) | | MAG2 (ePDG) |
+-------------+ +---------------+
| |
IF1 | (WiMAX) IF2 | (WLAN)
+-------------------+
| MN |
+-------------------+
Figure 2: MuIF MN attaching to HPLMN using PMIPv6/CMIPv6 Mobility
Jeyatharan & Ng Expires July 27, 2009 [Page 8]
Internet-Draft Multihoming PS in NetLMM January 2009
Management Mechanisms
This scenario as shown in Figure 2 is a 3GPP specific scenario, where
MN chooses CMIPv6 mobility management to be used via the WiMAX
interface (MN.IF1) and PMIPv6 mobility management via the WLAN
interface. MN will use the on-link prefix that is available in the
WiMAX access network advertised by Access Gateway (AGW), to configure
a care-of address for interface 1 of MN (MN.IF1). MN will perform
the CMIPv6 binding update (BU) at LMA/HA binding the home address to
the care-of address configured using the on-link prefix. When MN
performs such CMIPv6 BU at the LMA/HA (implemented in 3GPP as a
packet data network gateway, P-GW), the binding created is shown by
the first entry in the cache. As mentioned, since this MN is MONAMI6
capable and it is performing simultaneous attachment, it will use a
binding identifier (BID) option with value BID1 in its BU. It is
further considered that the home address is obtained from a prefix
that is topologically rooted at the home P-GW. It is also assumed
that MN is attaching to WLAN access via its second interface and
chooses PMIPv6 mobility management mechanism to manage mobility for
this interface. It is further assumed that MN sees the home prefix
(CMIPv6 home prefix) when MAG2 performs the PMIPv6 binding at the
LMA/HA. When the home prefix is advertised via MAG2 (which may be an
evolved packet data network gateway, ePDG, in 3GPP) there are
definite advantages that the MN can enjoy. It can enjoy PMIPv6
mobility management benefits for home prefix flows.
In order to attain simultaneous attachment in such a scenario, the
proxy binding update (PBU) sent by MAG2 needs to have some If-ID or
BID2 that is different from BID1. Since such a support is not
available in standard PMIPv6 mechanism, simultaneous attachment in
such a mixed PMIPv6/CMIPv6 scenario is not possible. If MAG2 does
not have any knowledge about MN's other interface CMIPv6 binding, it
will send a normal PBU without BID value. When such a PBU is sent,
it will invalidate the CMIPv6 binding that has already been
registered at LMA/HA (i.e. entry 1 in BC). Such overwriting without
proper binding specific parameter in the BU is already described in
[4] for the multiple interface scenario. If the PMIPv6 binding and
CMIPv6 binding are different mobility bindings arriving from
different interfaces as in Figure 2, then they need to separated by
BID.
From the detail explanation, a mechanism by which MAG2 gets to know
the correct value for BID2 needs to be supported by the system. For
example, MAG2 may be informed by MN that it is performing
simultaneous attachment so that the MAG2 may query the LMA/HA about
interface 1 (BID1) and then perform the PBU at LMA/HA with a BID that
is different from BID1. Alternatively, MAG2 may request the LMA/HA
to generate the BID that is different from BID1. Another possible
Jeyatharan & Ng Expires July 27, 2009 [Page 9]
Internet-Draft Multihoming PS in NetLMM January 2009
solution can be that MN gives BID2 to MAG2, where BID2 is different
from BID1, so that MAG2 can create the correct PMIPv6 binding for
interface 2.
In case the MN in Figure 2 attaches to the network first via IF2 and
the LMA/HA generates the BID2 for IF2's PMIPv6 binding, it is
essential that BID1 needs to be different from BID2 to achieve
simultaneous attachment. In such a scenario, the LMA/HA can provide
a BID1 for IF1 during Internet Key Exchange Signaling with MN. Then,
the MN will use this given BID1 for IF1 during the CMIPv6 signaling
and achieve simultaneous connection. Alternatively, MN can inform
LMA/HA via IF1 that it is simultaneously at home and away, so that
LMA/HA can generate BID1 for the IF1's CMIPv6 binding.
4. Conclusion
In this memo, we looked into two main cases of advanced multihoming
scenario. One in pure PMIPv6 domain, and the other in a mixed PMIPv6
and CMIPv6 enviroment. In both cases, the base PMIPv6 protocol was
found to be inadequate to support advanced multihoming so as to
provide the full benefits of multihoming to a multiple interfaced
mobile node. To summarize, base PMIPv6 protocol needs to be extended
to support the following advanced multihoming scenarios:
o Usage of MN Interfaces, to achieve "simultaneous usage" for flows
associated with single or multiple prefixes given to MN.
o Achieving flow based routing for particluar flows associated with
a prefix given to a multiple interfaced MN.
o Achieving improved handoff performance for multiple interfaced MN
using simultaneous usage support.
o Achieving vertical handoff and session continuity during to
disconnection of one of the interfaces.
o Achieving vertical handoff when a specific subset of prefixes
needs to be transferred to the newly powered on interface.
o Achieving simultaneous attachment for multiple interfaced MN in a
PMIPv6 and CMIPv6 mixed mobility management scenario.
5. IANA Considerations
This is an informational document and does not require any IANA
action.
Jeyatharan & Ng Expires July 27, 2009 [Page 10]
Internet-Draft Multihoming PS in NetLMM January 2009
6. Security Considerations
This document explores the problem of providing advanced multihoming
for mobile nodes with multiple interfaces connecting to a single
PMIPv6 domain. No additional security threat is identified as of the
writing of this memo that is specific to multiple interfaces support.
7. References
7.1. Normative Reference
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
7.2. Informative Reference
[2] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K.
Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-03 (work in
progress), May 2008.
[3] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi,
"Flow Bindings in Mobile IPv6 and Nemo Basic Support",
draft-ietf-mext-flow-binding-00 (work in progress), May 2008.
[4] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-11 (work in progress),
January 2009.
[5] "Technical Specification Group Services and System aspects",
3GPP TR 23.402, December 2007.
Appendix A. Change Log
o draft-jeyatharan-netext-multihoming-ps-00:
* Initial version.
Jeyatharan & Ng Expires July 27, 2009 [Page 11]
Internet-Draft Multihoming PS in NetLMM January 2009
Authors' Addresses
Mohana Dahamayanthi Jeyatharan
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505494
Email: mohana.jeyatharan@sg.panasonic.com
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: chanwah.ng@sg.panasonic.com
Jeyatharan & Ng Expires July 27, 2009 [Page 12]