NetExt Working Group M. Jeyatharan
Internet-Draft C. Ng
Intended status: Informational Panasonic
Expires: September 10, 2010 March 9, 2010
Multihoming Problem Statement in NetLMM
draft-jeyatharan-netext-multihoming-ps-02
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
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, the ability to perform
flow mobility tied to a subset of prefixes associated with an access
technology to another access technology 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.
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."
Jeyatharan & Ng Expires September 10, 2010 [Page 1]
Internet-Draft Multihoming PS in NetLMM March 2010
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, 2010.
Copyright Notice
Copyright (c) 2010 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Jeyatharan & Ng Expires September 10, 2010 [Page 2]
Internet-Draft Multihoming PS in NetLMM March 2010
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. Adding Prefixes to stable interface due to disconnection
via unstable interface . . . . . . . . . . . . . . . . . . . . 7
5. Enhanced Support to Attach Interfaces to a Single MAG . . . . 8
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 11
10.2. Informative Reference . . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Use Case analysis if simultaneous usage and
PMIPv6 Flow filering . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Jeyatharan & Ng Expires September 10, 2010 [Page 3]
Internet-Draft Multihoming PS in NetLMM March 2010
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 perform flow
mobility tied to all prefixes of an existing interface to a newly
attached interface. 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 or subset of prefixes from one interface to
another. The draft [2] highlights a solution to achieve such flow
movement tied to subset of prefixes. 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. The drafts
[3] and [4] highlights a solution for the usage of same home network
prefix(es) across multiple interfaces. Section 4 highlights the
needed work in fast handoff when one of the interface suddenly looses
connection and flows need to be transferred via a stable or connected
interface. Section 5 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.
All the enhancements highlighted in this memo are targeted towards a
MN that cannot manage its mobility on its own.
2. Needed Enhancement to Create Dynamic Mobility Sessions
2.1. Needed Enhancement to Create Dynamic Mobility Sessions via an
Interface
Jeyatharan & Ng Expires September 10, 2010 [Page 4]
Internet-Draft Multihoming PS in NetLMM March 2010
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
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 current 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
Jeyatharan & Ng Expires September 10, 2010 [Page 5]
Internet-Draft Multihoming PS in NetLMM March 2010
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
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. The draft [2]
highlights the motivation and signaling interactions between MAG
and LMA to achieve such flow mobility of subset of prefixes.
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
Jeyatharan & Ng Expires September 10, 2010 [Page 6]
Internet-Draft Multihoming PS in NetLMM March 2010
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.
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. Adding Prefixes to stable interface due to disconnection via
unstable interface
In Figure 2, it is considered that the mobile node MN is attached to
the PMIPv6 domain via both its interfaces.
Jeyatharan & Ng Expires September 10, 2010 [Page 7]
Internet-Draft Multihoming PS in NetLMM March 2010
o Problem
In PMIPv6 protocol, 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. Furthermore, according to PMIPv6 protocol, prefixes cannot
be dynamically assigned to a connected interface and the mobile
node may not be able to transfer the prefix tied to the interface
that suddenly looses connection to a connected interface by simply
using the HI value of "2" in the handoff PBU.
o Motivation
For real time transmission, it is essential that packet loss
should be reduced or avoided for the user to enjoy high user
perceived QoS. 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.
o Possible Approaches
A possible approach to solve this issue will be such that a
binding to flows tied to an interface via which disconnection will
happen to a stable interface needs to be present and stored in the
system whereby, when disconnection happens packet loss can be
prevented. Such mechanism is highlighted in [5].
5. 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
Jeyatharan & Ng Expires September 10, 2010 [Page 8]
Internet-Draft Multihoming PS in NetLMM March 2010
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
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.
Jeyatharan & Ng Expires September 10, 2010 [Page 9]
Internet-Draft Multihoming PS in NetLMM March 2010
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
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.
6. 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 are summarized as follows:
o Being able to use same HNP across multiple interfaces of the MN so
that flows tied to a given HNP can reach the MN via a plurality of
interfaces.
o Achieving flow mobility when a subset of prefixes needs to be
transferred to the newly powered on interface or connected
interface.
o Achieving flow based routing to interface(s) for particluar flows
associated with a prefix given to a multiple interfaced MN.
o Achieving fast vertical handoff and session continuity during
disconnection of one of the interfaces.
o Achieving dynamic prefix addition to an interface.
o Extending PMIPv6 operation in scenarios where multiple interfaces
are attached to the same MAG.
7. IANA Considerations
This is an informational document and does not require any IANA
action.
Jeyatharan & Ng Expires September 10, 2010 [Page 10]
Internet-Draft Multihoming PS in NetLMM March 2010
8. 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.
9. Acknowledgements
The authors would like to express their gratitude to (in alphabetical
order) Carlos Jesus Bernados Cano, Basavaraj Patil, David Cypher,
Yungui Wang and Hidetoshi Yokota for their gracious comments which
have helped improve the draft.
10. References
10.1. Normative Reference
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
10.2. Informative Reference
[2] Jeyatharan, M., Ng, C., Gundavelli, S., Leung, K., and V.
Devarapalli, "Partial Handoff Support in PMIPv6",
draft-jeyatharan-netext-pmip-partial-handoff-02 (work in
progress), February 2010.
[3] Koodli, R. and K. Chowdhury, "Flow Handover for Proxy Mobile
IPv6", draft-koodli-netext-flow-handover-01 (work in progress),
October 2009.
[4] Hui, M. and H. Deng, "PMIPv6 Multihoming Extension and
Synchronization in LMA and MAG", draft-hui-netext-multihoming-00
(work in progress), October 2009.
[5] Jeyatharan, M. and C. Ng, "Fast Handoff using Dormant Bindings
in PMIPv6", draft-jeyatharan-netext-pmip-dormant-binding-00
(work in progress), October 2009.
[6] Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K.
Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO Basic
Support", draft-ietf-mext-flow-binding-05 (work in progress),
February 2010.
[7] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K.
Jeyatharan & Ng Expires September 10, 2010 [Page 11]
Internet-Draft Multihoming PS in NetLMM March 2010
Nagami, "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-14 (work in progress), May 2009.
[8] "Technical Specification Group Services and System aspects",
3GPP TR 23.402, December 2007.
Appendix A. Change Log
o draft-jeyatharan-netext-multihoming-ps-02:
* Added one new section 4: Fast handoff support when sudden
disconnection happens and flows needs to be transferred via
existing interface.
* Modified the conclusion and have added new summary bullets.
* Removed the PMIP/CMIP interaction section from draft.
* Added more solution drafts and highlighted the problems they
are trying to solve.
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, 2010 [Page 12]
Internet-Draft Multihoming PS in NetLMM March 2010
+-----+ +-----+
| 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 [6].
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, 2010 [Page 13]
Internet-Draft Multihoming PS in NetLMM March 2010
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, 2010 [Page 14]
Internet-Draft Multihoming PS in NetLMM March 2010
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.
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, 2010 [Page 15]