One document matched: draft-jeyatharan-netext-multihoming-ps-01.txt
Differences from draft-jeyatharan-netext-multihoming-ps-00.txt
NetExt Working Group M. Jeyatharan
Internet-Draft C. Ng
Intended status: Informational Panasonic
Expires: September 10, 2009 March 9, 2009
Multihoming Problem Statement in NetLMM
draft-jeyatharan-netext-multihoming-ps-01
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 September 10, 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The Proxy Mobile Internet Protocol version 6 (PMIPv6) supports
multihoming whereby a mobile node (1) gets assigned prefixes by the
local mobility anchor which are associated with an interface of a
Jeyatharan & Ng Expires September 10, 2009 [Page 1]
Internet-Draft Multihoming PS in NetLMM March 2009
mobile node and are managed by the PMIPv6 elements as a single IP
mobility session, and (2) can connect to a Proxy Mobile IPv6 domain
through multiple interfaces for simultaneous access and get assigned
a different set of prefix(es) per interface, since being each
interface managed via an independent mobility session. However,
PMIPv6 needs multihoming enhancements such that it needs the ability
to instantiate additional IP mobility sessions associated with an
already active interface or a secondary interface of the mobile node
which has an established IP mobility session at a local mobility
anchor (LMA), the ability to selectively share home network
prefix(es) across access technology types and extended support for
multiple IP mobility sessions in a scenario where multiple interfaces
of the mobile node are connected to a single mobile access gateway
(MAG). This memo highlights such required enhancements to PMIPv6
multihoming with respect to improved operations and extended
applicability to different deployment scenarios.
Jeyatharan & Ng Expires September 10, 2009 [Page 2]
Internet-Draft Multihoming PS in NetLMM March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Needed Enhancement to Create Dynamic Mobility Sessions . . . . 4
2.1. Needed Enhancement to Create Dynamic Mobility Sessions
via an Interface . . . . . . . . . . . . . . . . . . . . . 4
2.2. Needed Enhancement to Create Dynamic Mobility Sessions
Between Interfaces . . . . . . . . . . . . . . . . . . . . 5
3. Using the Same HNPs across Multiple Interfaces . . . . . . . . 6
4. Enhanced Support to Attach Interfaces to a Single MAG . . . . 7
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 10
9.2. Informative Reference . . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Use Case analysis if simultaneous usage and
PMIPv6 Flow filering . . . . . . . . . . . . . . . . 10
Appendix C. Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario . 13
Appendix D. Multihoming Issues with Respect to Handoff . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Jeyatharan & Ng Expires September 10, 2009 [Page 3]
Internet-Draft Multihoming PS in NetLMM March 2009
1. Introduction
The Proxy Mobile Internet Protocol version 6 (PMIPv6) [1] supports
three different multihoming operations. Firstly, a mobile node (MN)
can receive home network prefix(es) via a certain interface and all
assigned prefixes are managed under a single mobility session.
Secondly, the mobile node is able to attach multiple interfaces to
the PMIPv6 domain and receive different home network prefixes via
each interface. Hence, the mobile node is able to communicate using
all interfaces. Thirdly, the mobile node is able to transfer all its
home network prefixes from a mobility session associated with an
interface to a new mobility session created for a newly attached
interface (i.e. vertical handoff). However, these multihoming
operations need further enhancements -- either to increase their
efficiency in operations or to be applicable to different deployment
scenarios. This memo highlights such multihoming enhancements
required, the need for such enhancements, and where applicable, the
possible solution approaches.
The required enhancements to PMIPv6 protocol with respect to
multihoming support are described in three main sections. Section 2
describes the enhancement required with respect to the ability to
dynamically create mobility sessions associated with an interface.
Section 2 describes dynamically modifying the set of prefixes
allocated to an interface, either by adding new prefixes or by
transferring some prefixes from one interface to another. Section 3
describes multihoming enhancement needed to use the same home network
prefix(es) across multiple interfaces to achieve benefits such as
load sharing, load balancing, aggregated bandwidth and flow based
routing. Section 4 highlights enhancement needed to PMIPv6 protocol
operations and some optimizations that can be done to the PMIPv6
protocol, when applied to a scenario where multiple interfaces of a
mobile node are attached to the PMIPv6 domain via a single MAG. In
addition, other multihoming related issues that may need to be
considered as part of PMIPv6 extensions in the future are described
in Appendix C and Appendix D.
2. Needed Enhancement to Create Dynamic Mobility Sessions
2.1. Needed Enhancement to Create Dynamic Mobility Sessions via an
Interface
o Problem
In PMIPv6 protocol, all the home network prefixes assigned to an
interface are established when the mobility session is first
created for a given interface. There is no support for adding
Jeyatharan & Ng Expires September 10, 2009 [Page 4]
Internet-Draft Multihoming PS in NetLMM March 2009
home network prefix(es) to the same interface in a dynamic manner.
Thus, creating multiple mobility sessions or binding cache entries
for a given interface is not possible according to the PMIPv6
protocol.
o Motivation
Such support is required especially in the cases where a mobile
node wants to get appropriate home network prefixes to access
services from the packet data networks (PDNs) in a 3GPP evolved
packet core at different points in time rather than getting all
the home network prefixes to access services at the same time.
For example, a mobile node may want prefixes P1 and P2 to access
services from packet data networks PDN1 and PDN2 respectively at
time instance T1. Later at time instance T2, it needs to access
services from PDN3 (thus requiring a prefix P3 to be assigned).
o Possible Approaches
To support this use case, PMIPv6 mechanism should be extended to
support multiple mobility sessions associated with a given
interface, each having a different group of prefixes assigned and
may have different binding lifetime attached.
2.2. Needed Enhancement to Create Dynamic Mobility Sessions Between
Interfaces
o Problem
In PMIPv6 protocol, when a mobile node powers on a new interface,
the new mobile access gateway sets the handoff indication option
value to '2'. All the prefixes that are assigned to the
previously attached interface are then transferred to the new
interface. When such transfer takes place, the binding cache
entry of one interface is updated with the new binding cache entry
created for the new interface. This is inflexible, as it cannot
support the case where only some (but not all) prefixes that are
assigned to one interface are transferred to a newly powered on
interface, or transferred to an already connected interface.
o Motivation
Such dynamic management of mobility sessions whereby a subset of
prefixes are removed from one interface and transferred to another
interface is useful to support load balancing of flows across
different interfaces of the mobile node. It also enable the flows
tied to the transferred prefixes to traverse via a preferred or
suitable access technology type for want of a better quality of
Jeyatharan & Ng Expires September 10, 2009 [Page 5]
Internet-Draft Multihoming PS in NetLMM March 2009
service (QoS) or cheaper service.
o Possible Approaches
To support this type of prefix transfer, new signalling mechanisms
may be required in PMIPv6 to allow (a) the removal of one or more
(but not all) home network prefixes from an interface of the
mobile node, (b) the addition of one or more home network prefixes
to a connected interface of the mobile node, and (c) the handoff
of one or more (but not all) home network prefixes from an
existing interface to a newly connected interface.
3. Using the Same HNPs across Multiple Interfaces
o Problem
PMIPv6 protocol operation is such that different home network
prefixes are assigned to different interfaces of the mobile node.
PMIPv6 does not support selectively using the same home network
prefix across multiple interfaces of the mobile node. Benefits of
doing this is thus not enjoyed with RFC5213.
o Motivation
If the flows associated with home network prefix(es) are allowed
to traverse via multiple interfaces of the mobile node by allowing
the same home network prefix to be assigned to multiple interfaces
of the mobile node, then the mobile node can achieve higher
aggregated bandwidth for flows tied to the home network prefix as
well as achieve load balancing of traffic across its interfaces.
Additionally, it is not only the mobile node that will enjoy
benefits from sharing the same prefix among multiple interfaces,
the network side can also benefit from it as well. For instance,
when the local mobility anchor receives a packet destined for a
home network prefix, it can choose among multiple routes to
different interfaces of the mobile node to forward the packet.
Such choice allows better utilization of the network resources and
the network can avoid congested region of the local network
domain. Furthermore, with the same home network prefix assigned
to multiple interfaces, flow based routing can be achieved. For
instance, the mobile node can choose to install filters on the
network to route packets of realtime interactive application
through its cellular interface which offers QoS assurance, and
packets of other non-realtime application through other
interfaces. A 3GPP operator can also have routing policy which
route VoIP packets over the cellular radio network, while file
transfer packets are routed over the WLAN network.
Jeyatharan & Ng Expires September 10, 2009 [Page 6]
Internet-Draft Multihoming PS in NetLMM March 2009
o Possible Approaches
There are two requisites associated with selective usage of same
home network prefix across multiple interfaces of the mobile node.
The first requisite is being able to selectively use the same home
network prefix across multiple interfaces and being able to
receive flows tied to the home network prefix via any interface of
the mobile node. This allows improved load balancing and
aggregated bandwidth. The second requisite is is to be able to
specify which flows are expected to traverse via which selected or
preferred interface(es). This allows flow filtering in PMIPv6
based on user's preference or operator policy.
To achieve the first requisite, it might be necessary for the
mobile access gateway to be informed of which home network
prefixes are shared between multiple interfaces. This can be
informed by the mobile node or the local mobility anchor. It is
also necessary for multiple routing paths to be enabled for a
shared home network prefix among the affected mobile access
gateways and the local mobility anchor. The mobile node should
also accepts data packet sent to a shared home network prefix via
any of its connected interfaces.
To achieve the second requisite, it should be possible for the
local mobility anchor to route packets based on explicitly
specified flow filters. Such filters may be dynamically installed
(and modified) by the network operator or the mobile node. To
further understand the different simultaneous usage scenario and
flow filtering scenarios more elaborate explanation is given in
Appendix B.
4. Enhanced Support to Attach Interfaces to a Single MAG
o Problem
The PMIPv6 protocol supports simultaneous attachment to PMIPv6
network via multiple interfaces of a mobile node but with the
assumption that each of the interfaces is attached to different
mobile access gateways. However, in some deployment scenarios, a
mobile access gateway may be handling different access technology
types and may results in the mobile node attaching to the same
mobile access gateway via multiple interfaces, such as illustrated
in Figure 1. In section 5.3.1 of RFC5213, it is mentioned that if
the Proxy-CoA in the binding cache entry matches the source
address of the binding cache entry update request, considerations
associated with binding lifetime extension (No handoff) MUST be
applied. Thus it is clear that the PMIPv6 protocol does not
Jeyatharan & Ng Expires September 10, 2009 [Page 7]
Internet-Draft Multihoming PS in NetLMM March 2009
handle inter technology handoff where the mobile node is connected
simultaneously to the same mobile access gateway. In addition,
since the same mobile access gateway will be sending multiple PBU
messages for the same mobile node, it will be desirable if these
can be combined into one PBU message.
+---------------+-----------+--------+
| Home Prefix | CoA | IF-ID |
+--------+ +---------------+-----------+--------+
| LMA | | MN.Prefix1(P1)| MAG1.Addr | IF-ID1 |
+--------+ | MN.Prefix2(P2)| MAG1.Addr | IF-ID2 |
| +---------------+-----------+--------+
|
+--------------------------+
| |
| Proxy Mobile IPv6 Domain |
| |
+--------------------------+
|
MAG1 Address |
(MN.IF2/MN.IF1 proxy CoA) |
+-------------+
| MAG1 |
+-------------+
\ /
IF2(3G) \ / IF1(WLAN)
+------+
| MN |
+------+
Figure 1: Multiple Interfaces attaching to same MAG
o Motivation
There are valid scenarios in some standard organizations where a
single mobile access gateway may handle multiple attachments of a
mobile node. For instance in 3GPP, it is possible for a Serving
Gateway (S-GW) to be serving as the mobile access gateway for both
the cellular and wireless-LAN access of a mobile node (e.g. the
LTE access and the I-WLAN access are both connected to the same
S-GW). In such scenarios, the PMIPv6 operation needs to be
extended such that inter access technology handoff can be
correctly and efficiently performed.
o Possible Approaches
In order to be able to support a scenario where the same mobile
access gateway is proxying for multiple attachments of a single
Jeyatharan & Ng Expires September 10, 2009 [Page 8]
Internet-Draft Multihoming PS in NetLMM March 2009
mobile node, operation of the local mobility anchor should be
modified. For instance, the local mobility anchor should rely
only on the proxy care-of address when updating the binding cache
entries. Other factors, such as the hand off indication option,
should also be taken into account.
To improve signalling efficiency, one possible approach is to
allow the mobile access gateway to send a single PBU message when
creating (or refreshing) multiple mobility sessions for the mobile
node. well.
5. Conclusion
In this memo, we highlighted additional work that has to be done with
respect to multihoming for the PMIPv6 protocol. The main categories
of additional work is dynamically creating mobility sessions tied to
an interface, ability to use same home network prefixes across
multiple interfaces of a mobile node, and extended ability to support
a scenario where a mobile node attaches to the same mobile access
gateway via multiple interfaces.
6. IANA Considerations
This is an informational document and does not require any IANA
action.
7. 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.
8. Acknowledgements
The authors would like to express their gratitude to (in alphabetical
order) Carlos Jesus Bernados Cano, Basavaraj Patil, Yungui Wang and
Hidetoshi Yokota for their gracious comments which have helped
improve this draft.
9. References
Jeyatharan & Ng Expires September 10, 2009 [Page 9]
Internet-Draft Multihoming PS in NetLMM March 2009
9.1. Normative Reference
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
9.2. Informative Reference
[2] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi,
"Flow Bindings in Mobile IPv6 and Nemo Basic Support",
draft-ietf-mext-flow-binding-01 (work in progress),
February 2009.
[3] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-11 (work in progress),
January 2009.
[4] "Technical Specification Group Services and System aspects",
3GPP TR 23.402, December 2007.
Appendix A. Change Log
o draft-jeyatharan-netext-multihoming-ps-01:
* Added two new sections: One about dynamic creation of mobility
sessions and another about supporting multiple interfaces via a
single MAG.
* Improved the same HNP usage across multiple interfaces by
highlighting mor on solution space.
* Moved the PMIP/CMIP interaction section and some scenarios that
are more tied to handoff to appendix.
o draft-jeyatharan-netext-multihoming-ps-00:
* Initial version.
Appendix B. Use Case analysis if simultaneous usage and PMIPv6 Flow
filering
To further understand the need for having the same home network
prefix across multiple interfaces of the mobile node, consider the
scenario depicted in Figure 2.
Jeyatharan & Ng Expires September 10, 2009 [Page 10]
Internet-Draft Multihoming PS in NetLMM March 2009
+-----+ +-----+
| 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 |
+------+
Figure 2: Simultaneous Usage in PMIPv6 Domain
In Figure 2, it is assumed that the mobile node MN has two interfaces
IF1 (3G cellular) and IF2 (WLAN) which are attached to mobile access
gateway MAG1 and MAG2 respectively. 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 prefix P1 will
traverse via IF1 only and all flows addressed to prefix P2 will
traverse only via IF2. Suppose MN is having video conference with
correspondent node CN1, then MN may want the audio flows to traverse
via 3G interface for better quality of service and the video flows to
traverse via 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 [2].
Normally, the audio and video flows of the same application will have
the same pair of endpoint addresses. Thus, with current PMIPv6 as
specified in RFC5213, the mobile node MN cannot split the video
conference flows to traverse via different interfaces. This is
Jeyatharan & Ng Expires September 10, 2009 [Page 11]
Internet-Draft Multihoming PS in NetLMM March 2009
because the prefix P1 is tied to IF1 only and there is no mechanism
available to set PMIPv6 filter or flow based routing. To fully enjoy
the benefit of simultaneous usage of interfaces for such video
conference application, it must be possible for prefix P1 to be used
by multiple interfaces. LMA should have support such that same home
network prefix or P1 should be tied to multiple interfaces, MAG2
should be aware of other interface prefix P1 and some filter rules
needs to be set at LMA such that it is given instructions to route
above mentioned voice flows associated with prefix P1 via interface 2
only and above mentioned video flows associated with prefix P1 via
IF1 only. The requirement for same home network prefix usage across
MN interfaces and filter rule setting may need MN involvement. It is
clear that new functionality is essential in LMA, MAG and even in the
MN to achieve simultaneous usage of MN interfaces for traversal of
such multimedia application flows. This use case specifically
highlights a need for a HNP being used via multiple interfaces and
the need to set filter rules in the PMIPv6 network.
In an alternate scenario associated with Figure 2 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
prefix P1 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 associated with above mentioned applications via both its
interfaces. In this use case for same HNP(es) across MN interfaces,
MN does not specify flow based routing preference. Instead MN needs
to indicate to LMA that any interface can be used for the flows
associated with the above mentioned web browsing and file transfer
applications. As explained previously, PMIPv6 protocol does not
support same home network prefix(es) usage across its interfaces.
For such same home network prefix usage to happen, in case of
downlink packets for example, MAG2 needs to be able to route packets
sent to prefix P1, LMA needs to be able to route packets sent to
prefix P1 via MAG2 as well as MAG1 and MN needs to know that this is
PMIPv6 network and be able to configure prefix P1 for IF2 or be able
to accept packet addressed to IF1 via IF2. All these changes needs
to be done to get the benefits attached to this use case.
In another scenario associated with Figure 2, MN may have started
communication with CN1 using prefix P1 and communication with say CN3
using P2. However, due to load balancing feature or function being
implemented in the PMIPv6 network, the LMA may send certain P2 flows
Jeyatharan & Ng Expires September 10, 2009 [Page 12]
Internet-Draft Multihoming PS in NetLMM March 2009
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, this use case highlights the need to support
same multiple home network prefixes P1 and P2 across MN interfaces
and be able to set flow based routing rules associated with multiple
prefixes at LMA.
Appendix C. Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario
One other potential problem which should be consider in the future is
when there are PMIPv6 and CMIPv6 interactions for a mobile node with
Monami6 capability as described in [3]. The main issue in a PMIPv6
and CMIPv6 mixed scenario arises when the network is not aware of the
simultaneous attachment related parameters used by the mobile node
(i.e. CMIPv6 multihoming parameters) and mobile node 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 mobile node. This is
illustrated with a specific example below.
In third generation partnership project service architecture
evolution (3GPP SAE) framework as outlined in [4], the mobile node
can select PMIPv6 or DSMIPv6 (i.e. Dual stack MIPv6) when attaching
via an interface or the network presets the allowed mobility
management mechanism for certain interfaces of the mobile node.
There are many scenarios involved with such simultaneous attachments
using different mobility management mechanisms. One possible
scenario could be that the mobile node (which 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 DSMIPv6 for mobility management, while the
other uses PMIPv6 for mobility management. Another scenario could be
that the mobile node is simultaneously attached to home (HPLMN) and
foreign domains (in 3GPP terms, visited public land mobile network,
or VPLMN). Again, the mobile node could be using PMIPv6 for mobility
management in its home domain, while using DSMIPv6 for mobility
management in the foreign domain. Although the problem is
highlighted using a 3GPP-specific deployment scenario, this is
applicable in other similar scenarios as well.
Jeyatharan & Ng Expires September 10, 2009 [Page 13]
Internet-Draft Multihoming PS in NetLMM March 2009
+----------+ 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 3: MuIF MN attaching to HPLMN using PMIPv6/CMIPv6 Mobility
Management Mechanisms
Figure 3 shows a 3GPP specific scenario, where the mobile node MN
chooses DSMIPv6 mobility management to be used via the WiMAX
interface (IF1) and PMIPv6 mobility management via the WLAN interface
(IF2). 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 IF1. MN will perform the DSMIPv6 binding update
at LMA/HA binding the home address to the care-of address configured
using the on-link prefix. When MN performs such DSMIPv6 binding 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 mobile node is MONAMI6 capable and it is
performing simultaneous attachment, it will use a binding identifier
(BID) option with value BID1 in its binding update. 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 IF2 and chooses
PMIPv6 mobility management mechanism to manage mobility for this
interface. It is further assumed that MN sees the home network
prefix (same as the DSMIPv6 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 mobile node can enjoy,
such as ability to direct flows to either of its interfaces.
In order to attain simultaneous attachment in such a scenario, the
proxy binding update sent by MAG2 needs to have an identifier to
differentiate it from the BID of IF1. Since such a support is not
Jeyatharan & Ng Expires September 10, 2009 [Page 14]
Internet-Draft Multihoming PS in NetLMM March 2009
available in standard PMIPv6, simultaneous attachment in this mixed
PMIPv6/CMIPv6 scenario is not possible. If MAG2 does not have any
knowledge about the other interface of the mobile node, it will send
a normal Proxy Binding Update without BID value. This will
invalidate the DSMIPv6 binding that has already been registered at
LMA/HA (i.e. entry 1 in binding cache). To avoid this, the PMIPv6
binding and CMIPv6 binding updates need to be differentiated by using
different BID values.
For example, MAG2 may be informed by the mobile node that it is
performing simultaneous attachment so that the MAG2 may query the
LMA/HA about interface 1 (which uses BID1). MAG2 can then use a
different BID value when sending Proxy Binding Updates.
Alternatively, MAG2 may request the LMA/HA to generate a BID value
that is different from BID1. Another possible solution is for the
mobile node to inform MAG2 what BID value to use for the PMIP
binding.
In case the mobile node in Figure 3 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 (IKE) Signaling with the
mobile node. Then, the mobile node will use this given BID1 for IF1
during the DSMIPv6 signaling and achieve simultaneous connection.
Alternatively, the mobile node can inform LMA/HA via IF1 that it is
simultaneously at home and away, so that LMA/HA can generate a BID1
for the IF1's DSMIPv6 binding.
Appendix D. Multihoming Issues with Respect to Handoff
In Figure 2, it is considered that the mobile node MN is attached to
the PMIPv6 domain via both its interfaces. When one of the interface
undergo handoff, the other interface might still be attached to the
same access router. For example, due to the coverage area
differences, the mobile node may change its access router for the
WLAN interface while the access router of its 3G interface remains
unchanged. If the mobile node suddenly loses connection to the
network via the WLAN interface, according to standard PMIPv6
operation, the mobile node needs to trigger vertical handoff at the
3G MAG so as to maintain session continuity via its cellular
interface. However, in some cases of disconnection, the mobile node
may not have enough time to trigger vertical handoff at 3G MAG
without suffering packet loss. Thus, there should be a fast handover
binding mechanism to re-route flows to another interface when one
interface has lost its connection with the shortest possible delay.
Such fast handover binding can be installed beforehand in the mobile
Jeyatharan & Ng Expires September 10, 2009 [Page 15]
Internet-Draft Multihoming PS in NetLMM March 2009
access gateways, but remains dormant until a trigger activates it
(such as when disconnection takes place).
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 September 10, 2009 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 20:42:35 |