One document matched: draft-jeyatharan-netlmm-multi-interface-ps-03.txt
Differences from draft-jeyatharan-netlmm-multi-interface-ps-02.txt
NetLMM Working Group M. Jeyatharan
Internet-Draft C. Ng
Intended status: Informational Panasonic
Expires: May 2, 2009 V. Devarapalli
WiChorus
J. Hirano
Panasonic
October 29, 2008
Multiple Interfaced Mobile Nodes in NetLMM
draft-jeyatharan-netlmm-multi-interface-ps-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 May 2, 2009.
Abstract
The specific mechanism described in the current PMIPv6 draft to
support multihoming is such that a unique prefix is given to each
interface of a Mobile Node (MN) that is attached to the PMIPv6
domain. However, multihoming can also be provided using same unique
prefix for all interfaces of MN similar to the MONAMI6 (Mobile Nodes
and Multiple Interfaces in IPv6) concept. This memo explores and
highlights lack of advanced multihoming support and other hand-off
related issues where appropriate in three different mobility
Jeyatharan, et al. Expires May 2, 2009 [Page 1]
Internet-Draft Multiple Interfaces in NetLMM October 2008
management protocol models for multiple interfaced mobile nodes.
Firstly, when single prefix is allocated for all interfaces of MN in
the PMIPv6 domain. Secondly, when unique prefix is allocated for
each interface as in PMIPv6 standard protocol model. Thirdly, when a
multiple interfaced node uses different mobility management
mechanisms for each of its interfaces.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Multiple Interfaces Support Models in PMIPv6 . . . . . . . . . 4
2.1. Different Home Network Prefix for Each Interface . . . . . 5
2.2. Same Home Network Prefix for Each Interface . . . . . . . 7
3. Multiple Interface Problem Analysis for Single Prefix Model . 9
3.1. Problem Analysis for PMIPv6 with respect to
Simultaneous Attachment Issues . . . . . . . . . . . . . . 9
3.2. Problem Analysis for Hand-off Scenarios . . . . . . . . . 14
3.3. Problem Analysis for Setting Filter Rule . . . . . . . . . 17
4. Multiple Interface Problem Analysis for Multiple Prefix
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Problem Analysis for Simultaneous Attachment . . . . . . . 19
4.2. Problem Analysis for Horizontal Hand-off . . . . . . . . . 20
4.3. Problem Analysis for Vertical Hand-off . . . . . . . . . . 22
5. PMIPv6/CMIPv6 Interaction Issues for Multiple Interfaced MN . 23
5.1. MuIf MN Simultaneous Attachment Issues in
PMIPv6/CMIPv6 mixed Scenario . . . . . . . . . . . . . . . 25
5.2. MuIf MN PMIPv6/CMIPv6 signaling optimization . . . . . . . 28
5.3. PMIPv6 and CMIPv6 Prefix Processing at Home Domain . . . . 28
6. Single Interface Processing Multiple Prefixes . . . . . . . . 30
6.1. PMIPv6 and CMIPv6 Roaming Issues for Home Routed 3GPP
Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Multihoming Issues in Multiple LMA/HA Scenario . . . . . . 33
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 35
10.2. Informative Reference . . . . . . . . . . . . . . . . . . 35
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 39
Jeyatharan, et al. Expires May 2, 2009 [Page 2]
Internet-Draft Multiple Interfaces in NetLMM October 2008
1. Introduction
Proxy Mobile Internet Protocol Version Six (PMIPv6) is a network
based mobility management protocol which provides mobility management
to all type of nodes including multiple interfaced (MuIf) mobile
nodes (MNs) that may or may not have client MIPv6 (CMIPv6)
functionality. Details of protocol operation and related
terminologies are given in [1]. The PMIPv6 draft [1] highlight
multihoming support for MuIf MNs by giving a unique prefix to each
interface of MN. The base draft adopted such a unique prefix per MN
interface model to provide basic multihoming support to an unmodified
MN. The term basic multihoming refers to simultaneous "connection"
support such that a MuIf MN can get connected to PMIPv6 domain and
receive packets via all its interfaces. "Unmodified" MN is generally
understood as nodes that do not have any software changes to obtain
mobility support in the Proxy MIPv6 domain. Although the base PMIPv6
protocol assigns unique prefix for each interface of MN, multihoming
can also be provided in PMIPv6 domain by using single unique prefix
for all interfaces of MN. Assigning same unique prefix for all
interfaces of MN in a PMIPv6 domain is conceptually similar to the
multihoming model outlined in [2].
The multihoming support that is covered in the base PMIPv6 draft is
simply simultaneous connection/attachment support for a multiple
interfaced MN. However, there are many scenarios associated with
multiple interface attachment such as simultaneous "usage" of
multiple interfaces for a single IP flow, preference setting at an
anchoring point to enable a certain flow to traverse via a certain
interface or access technology type associated with MN, optimized
vertical hand-off support when MN has two or more multiple interfaces
connected to the network and MuIf MN performing roaming between home
and foreign domains using one of its interfaces whereas another
interface is still attached to the home domain. These advanced
scenarios need additional mechanisms which require some enhancement/
modification to the current PMIPv6 base protocol.
There are three objectives associated with this memo. The first
objective is to analyze and highlight the problems in these above
mentioned scenarios associated with a multiple interface node and to
highlight the necessity of further enhancement to the basic PMIPv6
protocol. The second objective is to highlight the issues in the
above mentioned multiple interface related scenarios when a single
unique prefix is given to a MuIf mobile node in a PMIPv6 domain. By
showing the operation of single unique prefix model, one can clearly
compare which model of prefix assignment in PMIPv6 domain may be
suited for a certain multiple interface related scenario. Thirdly,
when a multiple interfaced node uses different mobility management
mechanisms via each of its interfaces, different issues are
Jeyatharan, et al. Expires May 2, 2009 [Page 3]
Internet-Draft Multiple Interfaces in NetLMM October 2008
highlighted which requires further work irrespective of the PMIPv6
prefix assignment model. In all the issue analysis for MuIf MN, the
need for terminal involvement when compared to a network based
solution is highlighted where appropriate. There has been some work
for single interface PMIPv6/CMIPv6 issues as outlined in [3].
However, in this memo the focus is on multihoming related issues when
the interfaces uses heterogeneous mobility management protocols. For
example, PMIPv6 mechanism via one interface and CMIPv6 mechanism via
another interface. In addition to the above mentioned analysis for a
MuIf MN, some issues for multiomed MN that uses a single interface is
also highlighted.
Many Standard Organizations (SDO) such as third generation
partnership project (3GPP), third generation partnership project 2
(3GPP2) and WiMAX Forum are very much interested in adopting PMIPv6
as a mobility management protocol. We have done some study on the
3GPP architecture and thus in this memo, wherever appropriate, PMIPv6
multihoming problems pertaining towards the 3GPP service architecture
evolution (SAE) network structure is highlighted. Nevertheless, it
is important to understand that such problem analysis is also
applicable to other SDO architectures as well.
Some of the scenarios where PMIPv6 is considered to be used is
clearly defined in [4]. In document [4], multiple interface related
scenarios considered are only related to vertical hand-off between
3GPP access and non-3GPP access and vertical hand-off between non-
3GPP accesses. Nevertheless, in this memo, many futuristic
multihoming scenarios that may well be adopted by 3GPP are considered
due to the amount of interest for simultaneous usage support in
service architecture two (SA2) WG activities in 3GPP. Basic concepts
and usefulness of multihoming is already well defined in [5] and are
thus omitted from this document. However, in this document, wherever
possible, the benefits of each multihoming scenario being analyzed is
highlighted. Moreover, the validity of each scenario is emphasized
with respect to current 3GPP activities as outlined in [4] and
possibly future 3GPP activities.
2. Multiple Interfaces Support Models in PMIPv6
In this section, the basic principle of two PMIPv6 multihoming models
such as the same unique prefix across all interfaces and per
interface unique prefix are given and the general merits and
tradeoffs of these models are discussed. In addition to this, why
the two models lack some of the advanced multihoming features such as
simultaneous usage support as described in [2] and flow filtering
features as given in [6] are explained. However, there are more
optimization issues that are related to vertical hand-offs when MN
Jeyatharan, et al. Expires May 2, 2009 [Page 4]
Internet-Draft Multiple Interfaces in NetLMM October 2008
has multiple interfaces which will be detailed in other sections of
this memo.
2.1. Different Home Network Prefix for Each Interface
o Operation complexity at LMA/HA to support unique prefix per
interface allocation
In this model, each interface of MN is allocated a unique Home
Network Prefix. To ensure that each interface of MN gets a unique
prefix, the LMA/HA will use the MN interface identifier (ID)
inserted in the Proxy Binding Update (PBU), a hand-off flag in PBU
and its own binding cache entries to allocate such unique prefix
per interface. This unique prefix per interface model is
described in greater detail in [1]. If the interface ID (If-ID)
in PBU is not available at the LMA/HA binding cache, and if the
hand-off flag is set to "1" (implying new connection request), the
LMA/HA will assign a new prefix for the interface. When the
interface ID which is sent in the PBU is matched to an entry in
LMA/HA, then the LMA/HA will treat it as horizontal hand-off (i.e.
one interface disconnecting from a mobile access gateway (MAG) and
connecting to another MAG) and assign the same prefix for session
continuity. For advanced hand-off scenarios such as vertical
hand-off (i.e. one interface shutting down and transferring flows
to a newly powered on interface), the LMA/HA will use more
information such as vertical hand-off flag inserted in the PBU and
set to value "2" and in some cases the disconnected interface's
If-ID, to assign the same prefix of the disconnected interface to
the new interface. Suffice to say, the prefix allocation logic is
pretty complex at LMA/HA for this multiple prefix model because
correct prefixes needs to be assigned based on MN's state such as
new connection, horizontal hand-off and vertical hand-off. In the
base PMIPv6 draft, many modes of prefix allocation are described
and all such variants are not described in this document to redce
the complexity.
o Lack of Simultaneous Usage Support
Since unique prefix is assigned to each interface of MN, for
practical purpose, this model can be treated as multiple MNs each
having a single interface. Thus, in a general sense, LMA/HA will
not be able to perform path switching for packets addressed to a
particular interface. Moreover, from the description given in the
base PMIPv6 draft, the bindings tied to a certain interface of MN
will be considered as separate or independent mobility sessions
and hence no IP flow switching is allowed. For example, if one
considers MN's IF1 is assigned a prefix (P1) and MN's IF2 is
assigned another prefix (P2). When LMA/HA receives a packet
Jeyatharan, et al. Expires May 2, 2009 [Page 5]
Internet-Draft Multiple Interfaces in NetLMM October 2008
addressed to an address configured using P1, LMA/HA would not
route such packet via MN's IF2 path. In some use cases, it is
preferred that an IP flow traverses via all interfaces of MN in
order to achieve load sharing, load balancing and less cost (ex.
flow traversing via cheaper access type) benefits. If MN is an
IPv6 host using SHIM6 (Site Multihoming by IPv6 Intermediation)
[7] or SCTP (Stream Control Transport Protocol) [8] or MN is a
MONAMI6 (Mobile Nodes and Multiple Interfaces in IPv6) capable
node as described in [2], then the MN can continue to enjoy
simultaneous usage benefits such as an IP flow coming towards a MN
address can be reached via one or more of MN interfaces. Unless
some changes are done to PMIPv6 protocol, these external protocols
are needed to achieve multihoming benefits in PMIPv6 domain. The
important question is, whether it is beneficial to have these
external protocols operate or use a mechanism that is more suited
to PMIPv6 domain. Another important question that needs to be
answered is, if 3GPP SDO enforces PMIPv6 mobility management
mechanism for all interfaces of MN that are simultaneously
attached to the 3GPP core network, then, a MN with MONAMI6
implementation cannot trigger the MONAMI6 stack since MONAMI6
stack is a derivative of CMIPv6. Under such circumstances, a
simultaneous usage mechanism that is purely suited for PMIPv6
domain is deemed necessary. Moreover, this mechanism should be a
derivative of the PMIPv6 mechanism.
o Lack of Flow Filtering Support
Setting filter rules (or preference setting) at the home agent
(HA) to set preference of a certain flow to traverse via a certain
care-of address (CoA), when roaming in foreign domain, is a well
understood method and is described in [6]. However, in PMIPv6,
the situation is slightly different. For example, if a MuIf MN is
roaming in a local domain and PMIPv6 is used for mobility
management, then MN will see different prefixes via its different
interfaces and these prefixes will be used for session
establishment with CNs (correspondent nodes). If MN wishes
certain flows to be delivered via a certain access technology due
to cost, quality of service (QoS), bandwidth, preference and
security, then, such filter rules should be set at the local
mobility anchor. However, MN operating in the PMIPv6 mode does
not know its LMA/HA or the packet data network gateway (P-GW)
address (P-GW is equivalent to LMA/HA in 3GPP architecture). In
such a case, MN must pass its flow filtering rules to the MAG to
which it is attached because only the MN can decide which flow is
preferred via a certain access technology type. Such flow
filtering support mechanisms are essential and currently not
supported in PMIPv6 base specifications. If PMIPv6 does not
support a mechanism to set filter rules, then the only way MN can
Jeyatharan, et al. Expires May 2, 2009 [Page 6]
Internet-Draft Multiple Interfaces in NetLMM October 2008
attain the preference setting or flow filtering is by setting the
preference at CN. If the CNs are placed far away from MN, then
setting such filters at CN increases the signaling cost or
signaling load in the fixed infrastructure. Moreover, in order to
establish such preference setting at LMA/HA in a pure PMIPv6 mode,
simultaneous usage support should be enabled in the PMIPv6 system.
As discussed before, flow filtering mechanism that is specifically
designed for PMIPv6 is necessary, if 3GPP restricts PMIPv6
mechanism via all interfaces of MN.
o Prefix Resource Usage
Another general issue with this unique prefix per interface model
is that, prefix resources are wasted. Due to such wastage, in
some cases, a node may not get a prefix via a certain interface in
PMIPv6 domain, if the PMIPv6 domain is supporting numerous MNs
with many active interfaces.
2.2. Same Home Network Prefix for Each Interface
In this model, each interface of MN will receive the same unique Home
Network Prefix. In such a scenario, MN should accept or probably be
configured to accept packets to be received by any interface as long
as the destination address matches the Home Network Prefix regardless
of the actual address configured (or assigned) for that interface.
If PMIPv6 implements such single prefix model, there is no need for
the MN to run separate multihoming enabling protocols (such as SHIM6,
SCTP, MONAMI6) to enjoy benefits of multihoming. The main advantage
of this model is that complex prefix allocation mechanism at LMA/HA
can be avoided and prefix resources are not wasted.
The single unique prefix model can be implemented using three
different methods as mentioned in [9]. These different methods of
implementing the single unique prefix method is next described in
detail with respect to simultaneous usage support and flow filtering
mechanism. The three methods are prefix-based caches at LMA/HA,
different address based caches at LMA/HA and same address based
caches at LMA/HA.
o Prefix Based Caches at LMA/HA
When prefix based caches are maintained at LMA/HA, since the
prefixes are the same, to maintain separation in the cache
entries, interface identifiers (If-ID) or binding identifiers
(BIDs) needs to be used. Binding Identifiers are described in
draft [2]. The main problem with this method of implementing the
caches is that, routing is based on prefixes and there is a
tendency for packets sent to a particular address being routed to
Jeyatharan, et al. Expires May 2, 2009 [Page 7]
Internet-Draft Multiple Interfaces in NetLMM October 2008
a wrong interface if the MN configures different addresses for its
interfaces. When compared to the unique prefix per interface
model, simultaneous usage can be easily achieved with such an
implementation because, a flow can be routed via any of the MN
interfaces. This is because the routing is based on prefix and
there is only a single prefix assigned for all interfaces.
However, to achieve simultaneous usage, the MAGs needs to be
informed of MN other interface address or need to be configured in
such a way that the layer two (L2) reachability of MN interface is
tied to the prefix of MN rather than the IPv6 global address.
From the brief description given above, it should be clear that to
activate this model and achieve simultaneous usage, some terminal
involvement is necessary because only the MN will know its
different addresses across its interfaces. When setting filter
rules, the flow identifier (FID) as described in [6] should be
tied to the Interface identifier or BID rather than the prefix or
address. This is because, the same prefix is assigned to all
interfaces of MN and such variation in flow filtering support
should be considered.
o Different Address Based Caches at LMA/HA
In this method of implementation, MN configures different
addresses for its interfaces and the caches at the LMA/HA are
address based rather than prefix based. When address based caches
are used, interface identifiers need not be used to separate the
bindings. The main drawback of this method is that the routing
path at the LMA/HA cannot be set up until address configuration is
complete and there is a slight delay in routing path set up. The
problem of packets being routed wrongly as described previously in
the prefix based cache method does not occur in this
implementation. This is because, the routing at the LMA/HA is
address based. However, to attain simultaneous usage benefits,
proper mechanisms needs to be activated at the LMA/HA and the
MAGs. For example, the LMA/HA need to identify all MN addresses
belong to same MN and then tunnel packets of a certain address via
other MAGs that have reachability state for MN other addresses.
Furthermore, the MAGs need appropriate mechanisms to allow packets
that are addressed to MN other interfaces that are not directly
connected to it to be routed. In this address based mechanism,
filter rules can be tied to the address associated with the
interface itself similar to that described in the flow filtering
Internet draft [6].
o Same Address Based Caches at LMA/HA
In this method, all MN interfaces configures the same address.
Thus the problems as to packets being routed wrongly or lack of
Jeyatharan, et al. Expires May 2, 2009 [Page 8]
Internet-Draft Multiple Interfaces in NetLMM October 2008
simultaneous usage support does not occur in this implementation.
However, preference or filter rules needs to be set. Since the
caches are separated probably using interface identifiers, the
flow filtering setting needs to tie the flow to the interface
identifier.
3. Multiple Interface Problem Analysis for Single Prefix Model
In this section, problem analysis for multiple interfaced mobile
nodes when PMIPv6 uses a single unique prefix per MN model is
presented. The assumption in the analysis regarding which PMIPv6
functional entity is mapped to which 3GPP architectural entity is
based on details provided in documents such as [4] and [10]. The
issues discussed in this section are issues related to simultaneous
attachment, horizontal and vertical handoff issues and flow filtering
issue in foreign domain. Specifically, the issues discussed under
simultaneous attachment are getting the simultaneous cache set up at
LMA/HA using optimized methods in various types of access network
link models, simultaneous attachment support for unmodified MN and
simultaneous usage support for MN's that can be modified.
3.1. Problem Analysis for PMIPv6 with respect to Simultaneous
Attachment Issues
Jeyatharan, et al. Expires May 2, 2009 [Page 9]
Internet-Draft Multiple Interfaces in NetLMM October 2008
+-------------+-----------+--------+-----------+
| Home Prefix | CoA | MN-ID | If-ID/BID |
+---------------+ +-------------+-----------+--------+-----------+
| LMA/HA/(P-GW) | | MN.P1 | MAG1.Addr | NAI |If1-ID/BID1|
+---------------+ | MN.P1 | MAG2.Addr | NAI |If2-ID/BID2|
| +-------------+-----------+--------+-----------+
| BCEs at LMA/HA
+--------------------------+
| |
| Proxy Mobile IPv6 Domain |
| |
+--------------------------+
| |
MAG2.Addr | | MAG1.Addr
+--------------+ +-----------+
| SGW/MAG2 | | ePDG/MAG1 |
+--------------+ +-----------+
\ /
If2(3G) \ / If1(WLAN)
+------+
| MN |
+------+
Figure 1: Attaching Multiple Interfaces to PMIPv6 that deploys Single
Prefix Model
o Maintaining Simultaneous Bindings at LMA/HA in 3GPP Architecture
Figure 1 shows a multiple interfaced MN, which is simultaneously
attached to a PMIPv6 network (3GPP evolved packet core (EPC)
network) via both its interfaces. It is considered that MN.If1
(i.e. Interface 1 of MN) is a wireless local area network (WLAN)
type of interface and MN.If2 is a third generation cellular (3G)
interface such as the evolved universal terrestrial radio access
network (E-UTRAN) interface. MN.If1 is attached to the evolved
packet data gateway (ePDG) via an IPSec tunnel and MN.If2 is
attached to Serving Gateway S-GW/MAG2, which may be its first hop
router. It is considered that the ePDG/MAG1 is not the first hop
router for MN.If1. It is important to appreciate that MN
accessing both 3G and WLAN services while moving can provide many
multihoming benefits to the MN. Furthermore, having both
interfaces on during inter access technology hand-off is also a
possible optimization scenario for vertical hand-off and thus such
simultaneous usage support is essential.
As highlighted previously, if single prefix type of prefix
allocation is supported at LMA/HA, then, there needs to be some
parameter (If-ID, BID etc) in the LMA/HA cache to differentiate
Jeyatharan, et al. Expires May 2, 2009 [Page 10]
Internet-Draft Multiple Interfaces in NetLMM October 2008
the bindings from same MN, especially for prefix based caches. In
this prefix allocation model, the interface IDs are merely used to
differentiate the binding entries associated with multiple
interfaces of MN. Interface IDs are not used in prefix
assignment. Here, Network Access Identifier (NAI) will be used
for prefix assignment because only a single prefix needs to be
assigned to a multiple interfaced MN.
In Figure 1 it is assumed that MN.If1 roams into the PMIPv6 domain
first and gets attached to MAG1. The routing state created at
LMA/HA due to attachment at MAG1 is shown by the first entry in
the binding cache (BC). When MN.If2 detects 3G and does
association, MAG2 will send a Proxy Binding Update (PBU) to the
LMA/HA, requesting to bind the Home Network Prefix of MN to the
proxy care-of address (CoA), which is MAG2.Addr (see 2nd BCE). It
is further assumed that the PBU has If-ID or BID information
embedded into a mobility option. Interface ID in PBU can be media
access control (MAC) address or interface identifier that MN use
to form global unicast IPv6 address. If latter type of interface
identifiers are used, then it is essential that they are unique
across MN interfaces. This may not be possible if DHCP is used
for address configuration or interface identifiers are randomly
generated. Thus, as mentioned in [1], the use of MAC addresses
for interface IDs is highly favored, due to their uniqueness per
interface and also they are usually shorter than If-ID associated
with an IPv6 address. Such assumption about interface ID being
MAC address is adopted in this memo. If the MAG is a first hop
router with respect to MN, then, using interface ID for cache
separation may be beneficial because MAC address can be readily
obtained at the MAG by means of standard IPv6 neighbor discovery
message exchanges, without any explicit signaling in the system to
inform this to MAG. If MAG1 is collocated at ePDG as shown in
Figure 1, MN needs to set up a virtual point-to-point link, which
is an IPSec tunnel, to access the ePDG/MAG1 (ePDG is usually
multiple hops away from MN). Moreover, in such virtual point-to-
point link scenario, the MAG function at ePDG cannot obtain MN's
MAC address by means of simple neighbor discovery messages. This
is one area where some further work is required. Appropriate
LMA/HA cache separation parameter (If-ID(MAC address) or BID) need
to be conveyed to the target MAG, which is multihops away (at
layer 3 (L3)) from MN. Furthermore, in such scenario, using BID
is beneficial as opposed to If-ID(MAC address) to maintain
multiple caches at LMA/HA. The reason being that, the BID field
size is usually much smaller than the interface ID(MAC address).
From the brief analysis given in this section, in the ePDG
scenario, it is clear that some explicit signaling is essential to
inform the MAG collocated at ePDG about the BID or If-ID(MAC
Jeyatharan, et al. Expires May 2, 2009 [Page 11]
Internet-Draft Multiple Interfaces in NetLMM October 2008
address) value, in order to create PMIPv6 binding at LMA/HA. If
MN use MAC address to form the globally unique interface
identifiers in the stateless mode of address auto configuration,
the ePDG can obtain a unique interface identifier (MAC address)
from the source address of the outer tunnel's IPv6 header. Here
it is considered that the data packets are encapsulated in an
IPSec tunnel from MN to ePDG where the source address (called the
nomadic address) of the outer tunnel is obtained from the
untrusted access network. However, in such a scenario, it is
essential to notify ePDG that this nomadic address was configured
using MAC address.
Next, few approaches of ePDG getting a unique If-ID(MAC address)/
BID is explored. If ePDG does not know the If-ID/BID (assuming no
explicit message from MN to notify), then ePDG in Figure 1 may
generate a random If-ID/BID. If this randomly generated If-ID/BID
is same as MN's some other interface If-ID/BID (ex. MN.If2
identifier or BID associated with MN.If2), then the PBU with the
ePDG generated random If-ID/BID may overwrite an existing If-ID/
BID that is available at LMA/HA cache. Such overwriting at LMA/HA
will cause a loss of a valid routing state and simultaneous
connection support will be lost. Another way for getting If-ID/
BID for simultaneous attachment is for Authentication
Authorization Accounting server (AAA) to generate unique If-IDs/
BIDs for initial attachments across MN interfaces and assume that
If-IDs/BIDs can be transferred via context transfer for hand-off
attachments. Yet another way is for the MAG/ePDG to query nearby
routers for MN's If-IDs/BIDs and then generate a unique interface
ID/BID. With so many approaches, some further analysis needs to
be performed to select the best possible method. Especially, when
one considers all possible scenarios in 3GPP such as home routed
and chained scenarios described in [4], terminal informing the If-
ID/BID to the ePDG via an explicit new message or as an option
integrated with standard messages may be the most appropriate or
efficient way. The above said home routed scenario and chained
scenario as described in [4] is where the PMIPv6 prefix is seen
when MN is roaming or attached to foreign network. In such a
scenario, any network based solution may not be very efficient due
to the long routing delay when network entities are involved in
informing the If-ID/BID at the target ePDG/MAG.
o Simultaneous Access Support for Unmodified MN
Suppose MN is an unmodified host in Figure 1 and performs such a
simultaneous attachment, and if it is given same address as MN.If1
for MN.If2 via statefull address auto configuration method, then
MN.If2 cannot configure a global IPv6 address and that interface
will not be used. This will be according to current
Jeyatharan, et al. Expires May 2, 2009 [Page 12]
Internet-Draft Multiple Interfaces in NetLMM October 2008
implementation of the IPv6 stack. In such a case, MN can only
receive packets via MN.If1 and packets sent to MAG2 will be lost
until MAG2 detects that MN.If2 is not attached and sends a
deregistration PBU to LMA/HA. Thus, simultaneous attachment is
not obtained. On the other hand, if MN configures different
addresses on its interfaces using stateless address auto
configuration, then successful simultaneous attachment can be
obtained. However, packets arriving at LMA/HA to address of
MN.If1 may be sent via MAG2 and MAG2 will drop the packets because
it does not have a neighbor cache entry mapping address of MN.If1
to the layer two (L2) address of MN.If2. Although basic
multihoming or simultaneous attachment support can be achieved
when MN configures different addresses, when LMA/HA routes packets
based on prefix, packets to one address to which a MAG does not
have supporting neighbor cache entry will be lost. The MN cannot
be involved in providing the other interface address to the MAG to
solve the issue, as this is an unmodified host and cannot be
involved in any protocol changes.
From the description given above, it is clear that when an
unmodifed MN is assigned same address to all its interfaces it is
nearly impossible to achieve simultaneous attachment. Some
changes can be done at the network side to prevent activation of
stateful mode of address auto configuration for unmodified host
and thus avoid same address being allocated for its interfaces.
Another possible means is that, the dynamic host configuration
protocol (DHCP) signal can be intercepted by MAGs and MAG could
insert some interface specific options to the DHCP message so that
the DHCP server assigns different addresses across MN interfaces.
From the brief analysis it is clear that, although the problem of
simultaneous attachment can be solved by network based mechanisms
described, there is still the routing issue if prefix based caches
are used at LMA/HA. This issue can be solved by using address
based caches at LMA/HA. However, as described before, address
based caches has its own set of disadvantages. From this
analysis, it can be seen that basic multihoming or simultaneous
attachment support can be achieved in the single prefix model for
unmodified MN as well. However, when compared to the multiple
prefix model, more care should be taken from the network side and
address based cache structure may be necessary. Thus for
unmodified MN, multiple prefix model or unique prefix per
interface model is more suited.
o Simultaneous Usage Support
As explained before, simultaneous usage support can be achieved
when an IP flow is allowed to traverse via all interfaces of MN.
For this to happen, the addresses associated with all MN
Jeyatharan, et al. Expires May 2, 2009 [Page 13]
Internet-Draft Multiple Interfaces in NetLMM October 2008
interfaces needs to be available at all MAGs the MN is attached
to. Which network entity informs this to the MAG, depends on
which cache model is used at LMA/HA. If address based caches are
used, LMA/HA can inform these addresses to MAG. Else, MN has to
inform this to MAG. Such variable solutions needs further
investigation to decide on an appropriate solution.
3.2. Problem Analysis for Hand-off Scenarios
Hand-offs are generally classified as horizontal hand-offs and
vertical hand-offs. The base PMIPv6 draft focuses on session
continuity for a prefix assigned to an interface. However, in [1]
there was no description on mechanisms to support hand-off
optimizations during hand-offs. Hand-off optimization refers to
reduction in delay, packet loss, jitters and reduced hand-off
signaling during the hand-off process. Such optimizations are
essential for next generation networks that wants to provide highly
sophisticated and high quality services to end services.
o Horizontal Hand-off for Multiple Interfaced MN
Horizontal hand-off from L3 perspective means hand-off of a single
interface from current access router(AR)/MAG to another access
router/MAG which results in a change in the L3 routing path to the
LMA/HA. This sub-section describes some additional features that
are required in the system to achieve horizontal hand-off
optimization for a multiple interfaced MN.
In a scenario where one of the interface performs horizontal hand-
off while the other interface is still attached, there are not
many issues with respect to creating simultaneous attachment at
LMA/HA. The reason being the new MAG only needs to know the If-
ID/BID of the interface that is performing the horizontal hand-off
to create the correct routing entry at LMA/HA. Again, the new MAG
can get to know this If-ID/BID by various means. As described
previously, new MAG can get to know If-ID/BID via context transfer
from old MAG, from AAA, from the MN, or obtaining directly from
MAC address.
The horizontal hand-off of a certain interface can be optimized
using another stable interface (i.e. interface that is not
perfoming hand-off), if simultaneous usage support is available in
the system. For example, during the time when there is no routing
state at the LMA/HA associated with an interface (during
horizontal hand-off time), such as the time between MN
deregistration PBU has arrived from old MAG and the new PBU has
not yet arrived from the new MAG, the packets can easily be routed
via another stable interface. Such an optimisation can be easily
Jeyatharan, et al. Expires May 2, 2009 [Page 14]
Internet-Draft Multiple Interfaces in NetLMM October 2008
achieved using the single prefix per MN model and when
simultaneous usage mechansim is deployed in the system. As
mentioned previously, to achieve simultaneous usage support for
the single prefix model, the MAGs can be configured to tie the L2
address of an interface to the MN prefix rather than the L3
address or the MN explicity notifies all its interface addresses
(unicast global) to all the MAGs it is attached with. With such
simultaneous usage support, during hand-off time, LMA/HA can
easily utilize a stable interface to route packets until the hand-
off has been completed. Such a scenario is a very probable
scenario in future evolved 3GPP architecture, where a MuIf MN
performs multiple horizontal hand-offs via the WLAN interface
while still being connected to the 3G interface. In such a
scenario, it can be seen that, using the stable interface and such
simultaneous usage support, packet loss can be reduced.
o Vertical Hand-off for Multiple Interfaced MN
* Vertical Hand-off between two interfaces
For the simplest vertical hand-off case (MN shutting down an
interface and transferring flows to a newly powered on
interface), the same prefix is given to the new interface
(single prefix model and PMIPv6 mobility management mechanism
is used). There need not be any specific mechanism as in
multiple prefix model to get the same prefix via the newly
powered on interface. Basically, if MN's interface 1 shuts
down and there are flows addressed to MN.If1, then when MN.If2
powers on, these flows can be readily received at MAG2 after
MAG2 has established the IP bearer or the routing path at
LMA/HA. The only problem in the vertical hand-off case is that
the address of MN.If2 may be different from address of MN.If1
and MAG2 may discard these packets that are addressed to
MN.If1. Here again, if simultaneous usage support is available
in the system as described previously, the packet loss issue
can be solved. Another issue that needs to be tackled is that,
if MN performs perform address auto configuration, then until
the address is configured and neighbor discovery procedure are
completed, the packets that are received at MAG2 may be dropped
if sufficient buffering resources are not available. Such
issue and solutions for these are described in the following
documents [11] [12]. These above mentioned documents are
looking at transient or secondary caches to solve the buffering
issue mentioned previously and also handling uplink packet loss
via the previous interface during inter technology hand-off.
An alternate way of solving this buffering issue at the new
MAG/target MAG is to use context transfer during vertical hand-
Jeyatharan, et al. Expires May 2, 2009 [Page 15]
Internet-Draft Multiple Interfaces in NetLMM October 2008
off where the MN unique prefix is informed via the context
transfer message to the target MAG. The target MAG has some
validated information (sent by context transfer) about the
validity of the ownership of this prefix by MN. Thus, target
MAG when it receives context transfer signaling, will advertise
router advertisement (RA) and simultaneously send the signaling
to set up the IP bearer path at LMA/HA. When the target MAG
advertises the prefix early, address configuration for the new
interface can be triggered early. When such vertical hand-off
is performed across administrative domains for example in 3GPP,
context transfer may not be efficient considering the routing
delay associated with the context transfer message. In such
scenarios, the MN can get some information from source MAG and
pass it on to target MAG. This information may have the prefix
probably cryptographically signed by a trusted network entity.
* Vertical Hand-off when MN is attached via more than two
interfaces
In this subsection, an advanced vertical hand-off scenario is
considered where MN is performing vertical hand-off involving
two of its interfaces, while the third interface is still
attached. The main advantage of this scenario is that, during
vertical hand-off process, until new interface can get
completely attached, the third non-roaming interface can be
used to receive packets. Again, it is important to understand
that such an optimization is possible only when simultaneous
usage support is available in the system. In the vertical
hand-off process, to combat the address configuration related
buffering issues and hand-off latency, MN can use the third
stable interface to achieve hand-off optimization. When there
is a vertical hand-off in a stable interface scenario, the make
before break kind of hand-off may not be necessary and the
stable interface can be used for hand-off optimization. Make
before make kind of hand-off may not be possible in all
mobility conditions and furthermore it consumes more battery
power and preferably be avoided if possible.
Jeyatharan, et al. Expires May 2, 2009 [Page 16]
Internet-Draft Multiple Interfaces in NetLMM October 2008
3.3. Problem Analysis for Setting Filter Rule
+--------------------+
| LMA/HA/Home P-GW | Flow1: MN.If1 CoA1
+--------------------+ Flow2: MN.If2 CoA2
|
|
+--------------------------+
| LMA/HA/Foreign P-GW |
+--------------------------+
| BCE at Foreign LMA/HA
+---------------------+ +-------------+-----------+-------+------------+
| | | Home Prefix | CoA | MN-ID | If-ID/BID |
| Proxy MIPv6 Domain| +----------------------------------------------+
| | | MN.P1 | MAG1.Addr | NAI | If1-ID/BID1|
+---------------------+ | MN.P1 | MAG2.Addr | NAI | If2-ID/BID2|
| | +----------------------------------------------+
MAG2.Addr | | MAG1.Addr
+---------+ +-----------+
| 3G/MAG2 | | ePDG/MAG1 |
+---------+ +-----------+
\ /
If2(CoA2) \ / If1(CoA1) =>prefix from foreign LMA/HA
+------+
| MN |
+------+
Figure 2: Single Prefix Flow Filter Issue
In this section it is assumed that MN has MONAMI6 type of multihoming
capability. The specific scenario that is considered here is such
that the MN is connected to a foreign domain via both its interfaces.
In such a scenario, unless foreign domain and home domain interwork
such that the home prefix can be seen always via a particular
interface and mobility for home prefix is maintained by PMIPv6
mobility management mechanism, CMIPv6 mechanism is essential when MN
moves to a foreign domain. If MN wants multihoming related advanced
features in foreign domain and CMIPv6 mobility management is used to
sustain session continuity due to mobility in foreign domain, it is
appropriate to use the MONAMI6 type of functionality. It is further
considered that the MN uses a prefix rooted at foreign P-GW as shown
in Figure 2 to configure the care-of address when roaming in the
foreign domain to achieve local mobility management benefits. When
the MuIf MN sets filter rules at home agent and is currently attached
to a foreign domain, there is a specific problem that needs to be
tackled. This problem is explained in detail below.
In Figure 2, MN sets filter rules at home LMA/HA which is the home
Jeyatharan, et al. Expires May 2, 2009 [Page 17]
Internet-Draft Multiple Interfaces in NetLMM October 2008
Packet Data Network Gateway (P-GW) in the 3GPP model. MN prefers
flow1 to traverse the WLAN interface and flow2 to traverse the
cellular/3G interface. Thus, MN sets filter rules accordingly at its
MIPv6 home agent which is LMA/HA at home domain. However, due to
LMA/HA/foreign P-GW implementing prefix based routing, flow1 can be
routed wrongly and may arrive via the cellular MAG. This is
certainly an issue as the filter rules are broken and hence, adequate
mechanisms needs to be in place to rectify this. When MN's flow
preference is broken, MN may need to appropriately set the filter
rules at the correct entity (foreign LMA/HA) or MN should always
adopt the practice of setting the filter rules at foreign LMA/HA (not
at home agent) when roaming in foreign domain. In a general sense,
the MN does not need to know the foreign P-GW address. Thus, to set
the filter rule, the MN could set filter rules at foreign LMA/HA via
the MAGs in foreign domain. However, if the foreign LMA/HA uses an
address based LMA/HA cache, then such an issue of breaking of filter
rules does not arise.
4. Multiple Interface Problem Analysis for Multiple Prefix Model
In this section, problem analysis for multiple interfaced MNs when
PMIPv6 uses a multiple prefixes per MN model is presented. This
model of prefix allocation is identical to that outlined in document
[1]. Similar to section 3, the issues analyzed in this section are
lack of simultaneous usage support, lack of flow filtering support,
horizontal and vertical hand-off optimization related issues.
Jeyatharan, et al. Expires May 2, 2009 [Page 18]
Internet-Draft Multiple Interfaces in NetLMM October 2008
4.1. Problem Analysis for Simultaneous Attachment
+-------------+-----------+--------+------+
| Home Prefix | CoA | MN-ID | If-ID|
+---------------+ +-------------+-----------+--------+------+
|LMA/HA/(P-GW) | | MN.P1 | MAG1.Addr | NAI |If1-ID|
+---------------+ | MN.P2 | MAG2.Addr | NAI |If2-ID|
| +-------------+-----------+--------+------+
| BCEs at LMA/HA
+--------------------------+
| |
| Proxy MIPv6 Domain |
| |
+--------------------------+
| |
MAG2.Addr | | MAG1.Addr
+---------+ +-----------+
| 3G/MAG2 | | ePDG/MAG1 |
+---------+ +-----------+
\ /
If2(P2) \ / If1(P1)
+------+
| MN |
+------+
Figure 3: Attaching Multiple Interfaces to PMIPv6 that deploys
Multiple Prefix Model
In Figure 3, it is considered that MN can be an IPv6 host or CMIPv6
enabled host. When MN does simultaneous attachment, MN receives
different prefixes via each of its interfaces and the binding cache
created by MAGs at LMA/HA is shown in Figure 3. The multiple prefix
model does not create any confusion to an unmodified IPv6 host that
does simultaneous attachment. This is because, as discussed before,
there is no instance where the host has to configure same address to
both its interfaces. However, if MN is having flows with multiple
CNs and a certain CN1 sends packets to address of MN configured from
prefix P1 and another CN2 sends packets to address of MN configured
from prefix P2, simultaneous usage support for CN1 IP flow and CN2 IP
flow cannot be achieved from normal PMIPv6 operation. Thus, as
highlighted previously in section 2, some further work is required in
this area. To achieve simultaneous usage support (i.e. enabling an
IP flow to traverse via all MN interfaces), the MAGs attached to MuIf
MN need to know all MN prefixes. In general, if MN has no preference
regarding which IP flow has to be traversed via which access
technology or interface, and MN and/or network wants this
simultaneous usage feature, this feature can be triggered in the
system. When comparing the simultaneous usage solution for the
Jeyatharan, et al. Expires May 2, 2009 [Page 19]
Internet-Draft Multiple Interfaces in NetLMM October 2008
multiple prefix model with the single prefix model, it is clear that
for the former case, MN needs to give prefixes associated with it to
all MAGs that the MN is directly attached to, with some security
token proving the validity of these prefixes and owner ship of these
prefixes by MN. It is important to understand that the MN prefixes
can be given to the MAGs by the MN or LMA/HA. In most scenarios, it
is beneficial for the MN to provide this information. Even in the
event of LMA/HA notifying MN prefixes to MAGs, MN modification is
essential to accept packets via one interface that are destined to
other MN interfaces.
Next the flow filtering related issues are briefly analyzed. If MN
in Figure 3 wants P1 flow to traverse via MAG2, then it needs to set
filter rules at LMA/HA to send P1 flow via MAG2. In such a case, the
MN can inform MAG2 about the P1 prefix. If MN does not want
simultaneous usage support for P1 and P2 flows, then it can only
update MAG2 about the P1 prefix in order to only support flow
filtering mechanism. The important difference in the multiple
prefixes model when compared to single prefix model is that, in the
multiple prefixes model, simultaneous usage support is not essential
for routing. Moreover, to set filter rules in the multiple prefixes
model, a full fledged simultaneous usage support is not essential.
For example, as described here, when MN wants P1 to traverse via MAG2
but does not want any changes in routing to P2 flow, then it only
needs to inform MAG2 about P1 prefix. However, this is not the case
in the single prefix model that uses prefix based caches. In this
single prefix model, as analyzed in section 2, to solve the routing
issue, simultaneous usage support has to be available in the system
irrespective of MN's preference.
4.2. Problem Analysis for Horizontal Hand-off
+-------------------------------------------+
| |
| Proxy Mobile IPv6 Domain |
| |
+-------------------------------------------+
| | |
| MAG1.Addr | MAG2.Addr | MAG3.Addr
+---------+ +-----------+ +-----------+
| 3G/MAG1 | | WLAN/MAG2 | | WLAN/MAG3 |
+---------+ +-----------+ +-----------+
\ / /
If1(P1) \ / If2(P2) / If2(P2)
+-------------+ / Horizontal
| MN |-----/ hand-off for If2
+-------------+
Jeyatharan, et al. Expires May 2, 2009 [Page 20]
Internet-Draft Multiple Interfaces in NetLMM October 2008
Figure 4: Horizontal Hand-off in Multiple Prefix Model
In Figure 4, it is assumed that MN has two interfaces. MN can be an
IPv6 host or MIPv6 host. Initially, it is assumed that MN is
connected to PMIPv6 network via If1 and If2 at MAG1 and MAG2
respectively. It is further assumed that MN.If1 is connected to 3G
network and MN.If2 is connected to trusted WLAN network. In trusted
WLAN network, the AR will have the MAG functionality and more
information on trusted WLAN can be found in [10]. It is further
considered that MN while still connected to 3G network via MN.If1,
performs a horizontal hand-off for MN.If2. Basically, MN.If2 will
detach from MAG2 and attach at a new MAG3. In such a scenario, the
important operation is that the If-ID information in the PBU sent
from MAG3 has to have If2-ID. This interface ID is essential for
LMA/HA to allocate the correct prefix during horizontal hand-off. As
discussed previously in section 3, various mechanisms are available
for MAG3 to obtain If-ID of MN.If2. In the scenario shown in
Figure 4, there is no major difficulty of getting this interface ID.
This is because, MAG3 is the directly connected access router of MN
and the MN.If2 MAC address can be readily obtained. If MAG3 does not
have interface ID of If2 (in a scenario where MAG3 is not the first
hop router) and it does not know the hand-off state of MN, then it
may set the hand-off flag to "4" in the hand-off indication option
meaning that the hand-off type is unknown. In such a worst case
scenario, the LMA/HA may assign a new prefix for If2 and session
continuity for P2 flows will be disrupted. Thus, these kind of
issues needs to be prevented if multiple prefix model is deployed.
From brief analysis, the main concern here is that, if MAG3 does not
know If2-ID, then getting this information quickly needs to be
explored to prevent horizontal hand-off establishment delay.
Another area to be explored is the horizontal hand-off optimization
related to delay, packet loss and jitter. As described in section 3,
horizontal hand-off delay can possibly be optimized using the stable
3G interface. However, in the multiple prefix model to achieve this
is more difficult. This is because, the prefix of the interface
undergoing hand-off needs to be informed via a trusted entity to the
3G MAG. Furthermore, the LMA/HA also needs to be informed to route
packets for interface undergoing horizontal hand-off via another
interface. These signalings such as MN notifying stable interface of
other interface prefix and notifying LMA/HA of hand-off event, needs
to be done in a timely manner to achieve hand-off delay optimization.
However, it is important to appreciate, if simultaneous usage support
is operating in the PMIPv6 domain, then the horizontal hand-off
optimization support is implicitly available in the system and the MN
need not inform the LMA/HA about hand-off event. This another
benefit of simultaneous usage support can be seen.
Jeyatharan, et al. Expires May 2, 2009 [Page 21]
Internet-Draft Multiple Interfaces in NetLMM October 2008
4.3. Problem Analysis for Vertical Hand-off
+-------------------------------------------+
| |
| Proxy Mobile IPv6 Domain |
| |
+-------------------------------------------+
| | |
| MAG1.Addr | MAG2.Addr | MAG3.Addr
+---------+ +------------+ +-----------+
| 3G/MAG1 | | WiMAX/MAG2 | | WLAN/MAG3 |
+---------+ +------------+ +-----------+
\ / /
If1(P1) \ /If2(P2) / If3(P2)
+-------------+ /Vertical hand-off
| MN |------/ for If2
+-------------+
Figure 5: Vertical Hand-off in Multiple Prefix Model
In Figure 5, it is assumed that MN has three interfaces, such as
MN.If1, MN.If2 and MN.If3. It is further assumed that initially MN
has MN.If1 and MN.If2 connected to the PMIPv6 network. Then, after
some time, MN shuts down MN.If2 and attaches via MN.If3 -- i.e., MN
performs a vertical hand-off for MN.If2. From 3GPP point of view,
this is a very probable scenario where the MN is attached via 3G and
WiMAX and when it detects WLAN may want to transfer the WiMAX flows
to WLAN. If such a vertical hand-off is performed, then what is
desired from MN's point of view is that MN requires flows associated
with prefix P2 to be sent via MN.If3. To achieve this requirement of
session continuity, the LMA/HA should assign prefix P2 to MN.If3. In
order for LMA/HA to process such vertical hand-off request and assign
the desired prefix P2 in the above scenario, the PBU sent by MAG3
need to have If2-ID information in addition to If3-ID and the "HI"
option set to value "2". In [1], there is description about the
prefix (P2) sent in the new PBU from interface 3. However, there was
no description of the interface ID of the shutting down interface
being sent in the new PBU. There can be scenario where there are
multiple prefixes associated with an interface, such as in 3GPP
scenario where the MN is connected to multiple packet data networks
via a single LMA/HA. In such a scenario, rather than sending all the
prefixes associated with interface 2 in the PBU via interface 3
during the vertical hand-off preocess, sending the If2-ID is
beneficial from optimization point of view. It is important to
understand, when there are more than 2 interfaces and vertical hand-
off is being performed, to identify the interface that has shut down,
this interface ID information is useful and such support mechanism is
Jeyatharan, et al. Expires May 2, 2009 [Page 22]
Internet-Draft Multiple Interfaces in NetLMM October 2008
essential.
Next a simple scenario where vertical hand-off is performed is looked
into. In this scenario, it is assumed that MN only has two active
interfaces such as MN.If2 and MN.If3. When MN performs a vertical
hand-off from MN.If2 to MN.If3, If2-ID may not be required in the PBU
sent via interface 3. Once LMA/HA sees the hand-off flag pointing to
"2" (vertical hand-off), it will assign P2 to MN.If3. This is
because, LMA/HA has no difficulty in identifying P2 cache since there
are no other BC entries associated with MN at LMA/HA. Thus, one can
appreciate that the vertical hand-off complexity is high when MN has
more than two active interfaces.
As highlighted previously, when MN does vertical hand-off in a
complex scenario as shown in Figure 5, MAG3 needs If2-ID information
in the PBU. There needs to be an efficient mechanism for MAG3 to
know this. As described previously, MN can provide the If2-ID to
MAG3 via link layer specific triggers or via a L3 message.
Alternatively, MAG3 can get this information via context transfer
from MAG2. If vertical hand-off is performed between heterogeneous
access network types, context transfer via heterogeneous networks may
take some time and contribute to vertical hand-off establishment
delay. In 3GPP, inter access technology hand-off can take place
between home public land mobile network (HPLMN) and visited public
land mobile network (VPLMN). In such a case, getting the If-ID
associated with the shutdown interface using purely network based
mechanisms is not efficient and moreover, may not be possible if
there is no interworking between the domains. Thus, some MN
involvement is definitely useful in scenarios involving inter
technology hand-off within an administrative domain and between
administrative domains.
In the event there is vertical hand-off, to optimize vertical hand-
off delay, packet loss etc, make before break kind of mechanism with
transient binding caches can be used. In the event of a stable
interface available during vertical hand-off, a simultaneous usage
support mechanism in the system can support in improving the hand-off
related QoS parameters. This was explained previously with respect
to horizontal hand-off related analysis and shall not be repeated
again.
5. PMIPv6/CMIPv6 Interaction Issues for Multiple Interfaced MN
In this section, PMIPv6 and CMIPv6 interaction scenarios are analyzed
for MuIf MN that has MONAMI6 type of functionality. For the MuIf MN,
the main interaction issue in a PMIPv6 and CMIPv6 mixed scenario
arises when network takes care of mobility signaling for some
Jeyatharan, et al. Expires May 2, 2009 [Page 23]
Internet-Draft Multiple Interfaces in NetLMM October 2008
interface attachments of MN and the MN takes care of mobility
signaling for certain other interface attachments. The main factor
that causes the issue is that 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. This problem will be explained in
greater detail in this section and where appropriate possible
solution paths will be highlighted.
When MN's mobility for one interface is handled by PMIPv6 and MN's
mobility for another interface is handled by CMIPv6, both the PMIPv6
and CMIPv6 bindings need to coexist at the home agent (LMA/HA) to
achieve simultaneous attachment. Currently, there are solutions to
achieve simultaneous attachment when MN uses PMIPv6 mobility
management mechanism via all MN's interfaces as outlined in [1].
Furthermore, as outlined in [2], there are mechanisms available to
achieve simultaneous attachment when MuIf MN handles mobility for all
its interfaces. However, there are no mechanisms available in such
mixed PMIPv6/CMIPv6 scenario to achieve simultaneous attachment when
the MN configures just one home address from a single home prefix
across its interfaces.
In 3GPP SAE framework, 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 (HPLMN) via both its interfaces and uses CMIPv6 via one
interface and uses PMIPv6 via another interface. Another scenario
could be that, MN is simultaneously attached to home (HPLMN) and
foreign domains (VPLMN) and MN uses PMIPv6 via the home connected
interface and CMIPv6 via the foreign connected interface. The other
scenarios involved are, when one of the interface is connected while
the other interface roams or performs a hand-off between domains in
such a mixed mobility management framework.
Jeyatharan, et al. Expires May 2, 2009 [Page 24]
Internet-Draft Multiple Interfaces in NetLMM October 2008
5.1. MuIf MN Simultaneous Attachment Issues in PMIPv6/CMIPv6 mixed
Scenario
+----------+ BCEs at LMA/HA
| HA/ | +-------------+---------+-------+-------------+
| LMA/P-GW | | MN prefix | MN.CoA | MN-ID | If-ID/BID |
+----------+ +-------------+---------+-------+-------------+
| \ | HoA | CoA.AR | - | BID1 |
| \ | home prefix | MAG2addr| NAI | BID2 |
| \ +-------------+---------+-------+-------------+
| \
| \ HPLMN
+--------------+ +--------------+
| 3G/MAG1/S-GW | |WLAN/ePDG/MAG2|
+--------------+ +--------------+
| |
| If1 | If2
+-------------------+
| MN |
+-------------------+
Figure 6: MuIf MN attaching to HPLMN using PMIPv6/CMIPv6 Mobility
Management Mechanisms
The analysis and problems highlighted in this section applies to both
single prefix per MN PMIPv6 model and multiple prefixes per MN PMIPv6
model.
This scenario as shown in Figure 6 is a 3GPP specific scenario, where
MN chooses CMIPv6 mobility management to be used via the 3G interface
(MN.If1) and PMIPv6 mobility management via the WLAN interface.
Current 3GPP specifications does not fully support CMIPv6 to be used
via 3G interface. Nevertheless, for the analysis such an assumption
is used. However, such a scenario may be valid in future releases of
3GPP (i.e. beyond release 8). MN will use the on-link prefix that is
available in the 3G access network advertised by evolved node B
(eNodeB), or advertised by S-GW that is placed in the core network,
to configure a care-of address for MN.If1. The said on-link prefix
will be topologically rooted at the eNodeB or the S-GW. MN will
perform the CMIPv6 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, 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 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
Jeyatharan, et al. Expires May 2, 2009 [Page 25]
Internet-Draft Multiple Interfaces in NetLMM October 2008
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. The reason for
home prefix to be seen via PMIPv6 mechanism may be a static
configuration that has been hard-coded in LMA/HA or it could be
subscription specific operation which has been requested by MN. When
the home prefix is advertised via MAG2 there are definite advantages
that the MN can enjoy. It can enjoy PMIPv6 mobility management
benefits for home prefix flows. Moreover, in certain configurations
in 3GPP, if CMIPv6 is not allowed via WLAN access, then home prefix
needs to be advertised. This is especially essential in single
interface vertical hand-off scenario (vertical hand-off between
CMIPv6 mode and PMIPv6 mode via different interfaces) for session
continuity.
In order to attain simultaneous attachment in such a scenario, the
PBU sent by MAG2 needs to have some If-ID or BID2 that is different
from BID1. If MAG2 does not have any knowledge about MN's other
interface CMIPv6 binding or MN's some other CMIPv6 mobility binding,
it will send a normal PBU without BID value or an If-ID value that
can be used for cache separation. When such a PBU is sent, it will
overwrite the CMIPv6 binding that has already been registered at
LMA/HA (i.e. entry 1 in BC). Such overwriting without proper binding
specific parameter is already described in [2] for the multiple
interface scenario. Another assumption used in the analysis is that,
a PMIPv6 mobility binding can be replaced by another CMIPv6 binding
if these bindings correspond to the same binding identifier or they
can replace each other when no such binding identifier is provided
(i.e. single binding or single interface MN). If the PMIPv6 binding
and CMIPv6 binding are different mobility bindings arriving from
different interfaces as in Figure 6, then they need to separated by
BID. As mentioned before, either BID or interface identifier fields
can be used to separate the mobility bindings at LMA/HA as shown in
Figure 6. It is assumed that BID/If-ID are used to separate binding
caches belonging to the same prefix/home address in such PMIPv6/
CMIPv6 mixed scenario. As discussed peviously, BID for cache
separation is also used for PMIPv6 single prefix model and the
MONAMI6 model. When unique prefix per interface PMIPv6 model is used
in such mixed PMIPv6/CMIPv6 scenario, another field in the binding
cache such as the BID field is required in addition to the interface
identifier field currently used in the base PMIPv6 specifications.
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
Jeyatharan, et al. Expires May 2, 2009 [Page 26]
Internet-Draft Multiple Interfaces in NetLMM October 2008
to generate the BID that is different from BID1. Another possible
solution can be that MN gives BID2 to ePDG/MAG2, where BID2 is
different from BID1, so that MAG2 can create the correct PMIPv6
binding for interface 2.
In another alternate scenario, if only the MN's WLAN interface in
Figure 6 moves out of the home domain to a VPLMN and decides to
switch to CMIPv6 mode, it needs to know the BID generated by LMA/HA
for interface 2 for the PMIPv6 binding, in the event this BID2 was
not provided by MN. If MN uses a BID when performing CMIPv6 BU for
interface 2 that is different from BID2 that was created previously,
then there is a possibility for three bindings to exist at home P-GW.
Such as the interface 1 CMIPv6 binding, interface 2 PMIPv6 old
binding and the interface 2 correct CMIPv6 binding. Ideally, after
roaming, the second binding entry shown in Figure 6 should have been
overwritten by the new CMIPv6 binding for interface 2. If interface
2 current binding does not overwrite the old PMIPv6 binding
associated with interface 2, packet loss can take place if the LMA/HA
decides to route packets using the second entry in BC shown in
Figure 6. However, if MAG2 can detect MN detachment fast enough,
then possibly it may send a deregistration PBU and solve the above
said issue. However, in the most general case, there needs to be a
way where MN gets the BID2 value before performing the new CMIPv6
binding for interface 2. There are many possible solutions that can
be used. For example, MN could inform LMA/HA to generate the correct
BID by giving information about the PMIPv6 binding that needs to be
over written. Or, MN could query MAG2 about BID2 information before
performing the binding update.
In another variant scenario, it is considered that MN.If1 in Figure 6
is attached to HPLMN and CMIPv6 mobility management is used and
MN.If2 has roamed to VPLMN and uses CMIPv6 mobility management
mechanism. In such a case, bindings at LMA/HA will be MONAMI6 type
of CMIPv6 bindings with BID1 used for interface 1 and BID2 used for
interface 2. If MN.If2 roams back home (HPLMN), and PMIPv6 mobility
management is performed via If2, again the BID2 information has to be
sent to MAG2 by MN. If MN does not send the BID2 information to
MAG2, and the LMA/HA has to generate the BID2 information, the
roaming interface needs to be identified correctly by LMA/HA. Such
information about the roaming interface has to be given by MAG2.
Possibly the MN can provide some parameter to identify the binding
that is undergoing the roaming. Possibly the previous care-of
address can be sent to MAG2 to aid the LMA/HA to create the BID2.
The analysis in this PMIPv6/CMIPv6 mixed scenario has focused mainly
on achieving simultaneous attachment. However, in this mixed
scenario, there is no issue on simultaneous usage support because it
is implicitly obtained when simultaneous attachment support succeeds.
Jeyatharan, et al. Expires May 2, 2009 [Page 27]
Internet-Draft Multiple Interfaces in NetLMM October 2008
Since there are no multiple PMIPv6 caches present in the scenario
described, the simultaneous usage issue that were discussed for pure
PMIPv6 multihoming does not arise here.
5.2. MuIf MN PMIPv6/CMIPv6 signaling optimization
In this section, a signaling optimization that can be performed in
multiple interface scenario when one of the interface performs the
CMIPv6 BU and the other interface performs the PMIPv6 BU is
described. To further understand the optimization that can be
performed, once again Figure 6 is looked into. If for example, MN's
interface 2 does the initial attachment to the HPLMN, there is no
necessity for the MN to know the home P-GW address because the MAG2
handles the PMIPv6 registration. However, since MN's interface 1 is
in the CMIPv6 state, then it needs to know the home P-GW address in
order to perform the CMIPv6 BU. The CMIPv6 BU process can be broken
into steps such as performing Dynamic Home Agent Address Discovery
(DHAAD) to identify the HA address, and then performing the CMIPv6
BU. Such steps are carried out in MN implementations where the home
prefix is statically configured in the MN. To eliminate the DHAAD
signaling and optimize the CMIPv6 BU process, MN can possibly
configure the care-of address for interface 1 and perform the CMIPv6
BU via the interface 2. If such mechanism takes place, the discovery
for home agent address need not be performed because, MAG2 knows the
address of home P-GW which is also the home agent of MN. The MN
possibly can trigger MAG2 via a new message and request MAG2 to
perform the CMIPv6 binding. For such optimization to take place, MN
needs to give the CMIPv6 binding contents to MAG2, so that a PBU with
a new mobility option that carries the CMIPv6 contents can be
generated by MAG2. Such PMIPv6 and CMIPv6 interaction scenarios
where signaling optimization can be performed needs to be identified.
The signaling optimization described in this section is applicable
for both PMIPv6 multihoming models (i.e. single prefix model and
multiple prefixes model).
5.3. PMIPv6 and CMIPv6 Prefix Processing at Home Domain
In this section a multihoming issue is analyzed from the perspective
of multiple care-of addresses configured for a certain interface of
MN when a MuIf MN is in home domain or HPLMN. Furthermore, the
analysis is performed in a system that uses single prefix per MN
PMIPv6 multihoming model at LMA/HA for PMIPv6 binding entries.
However, the problem highlighted in this section is applicable even
if LMA/HA deploys the multiple prefixes per MN model.
Jeyatharan, et al. Expires May 2, 2009 [Page 28]
Internet-Draft Multiple Interfaces in NetLMM October 2008
+-------------+-----------+--------+-------+-----+
| Prefix/Addr | CoA | MN-ID | If-ID | Flag|
+---------+ +-------------+-----------+--------+-------+-----+
| HA/LMA/ | | MN.P1 | MAG1.Addr | MN.NAI |If1-ID | - |
| P-GW | | MN.P1 | MAG2.Addr | MN.NAI |If2-ID | - |
+---------+ | MN.HoA | -- | MN.NAI |BID1 | "H" |
| | MN.HoA | CoA.AR | MN.NAI |BID2 | - |
| +-------------+-----------+--------+-------+-----+
| BCEs at LMA/HA
+----------------------------+
| |
| Proxy Mobile IPv6 Domain |
| |
+----------------------------+
| |
MAG1.Addr | | MAG2.Addr
+--------------+ +-----------+
| 3G S-GW/MAG1 | | ePDG/MAG2 |
+--------------+ +-----------+
| |
| +-------------------------+
| | Untrusted WLAN Access |
| +-------------------------+
| |
| +-------+
| | AP/AR |
| +-------+
\ |
If1 \ / If2
+----------+
| MN |
+----------+
Figure 7: Multihomed MN configuring multiple care-of addresses when
PMIPv6 is deployed in 3GPP
In a 3GPP deployment that uses PMIPv6 protocol, there are many
prefixes a particular interface of MN can receive especially if MN is
connected to Untrusted WLAN. MN may want to configure different
addresses from different prefixes for various reasons. In such a
scenario shown in Figure 7, it is assumed that MN has multihoming
support and can generate BIDs as in [2] and LMA/HA can support
multihoming as well. Generally, when an interface of MN configures
different addresses, MN may prefer to have reachability to all such
configured addresses from the LMA/HA to obtain multihoming benefits.
It is also assumed that this PMIPv6 domain is MN's home PMIPv6 domain
and MN's single home address (MONAMI6/MIPv6 sense) is equal to MN.If1
address. The mechanism by which MN gets the MIPv6 home address can
Jeyatharan, et al. Expires May 2, 2009 [Page 29]
Internet-Draft Multiple Interfaces in NetLMM October 2008
be 3GPP specific or using dynamic bootstrapping mechanism. In
Figure 7, it is considered that MN.If1 is attached to 3G MAG1. When
MN attaches to PMIPv6 network, it is assumed that it connects first
via MN.If1. When such a connection is successful, the first entry in
the BC will appear. The If1-ID can be directly obtained by MAG1
assuming that the S-GW is the first hop router for the data plane.
If the data packet has to be routed via eNodeB that also acts as a
router as described in [13], then MAG1 may not be the first hop
router. It is further considered that MN.If2 is connected to PMIPv6/
3GPP network via Untrusted WLAN access network. MN.If2 is directly
attached to AR/AP. When MN.If2 makes a successful IPSec tunnel to
ePDG as disclosed in [4], the second entry in the binding cache will
be created. Again, the If2-ID needs to be different from If1-ID to
maintain simultaneous binding. Before establishing a tunnel to ePDG,
MN.If2 will get a nomadic address in the Untrusted WLAN access
network and this nomadic address prefix is directly associated with
AR's prefix. As discussed previously, the cache separation
parameters for single prefix model can be BID or interface ID. In
this analysis, it is assumed that If-ID is used for cache separation.
MN may configure another address from the home prefix (home2) for
MN.If2 to get reachability or to set filter rules at LMA/HA without
knowing that this is a PMIPv6 domain. MN may want to register these
addresses (nomadic address/on-link CoA, home2) at LMA/HA. When MN
performs multiple CoA binding at LMA/HA for home2 and on-link CoA,
then these CMIPv6 registrations created at LMA/HA are as shown in the
binding cache by the third and fourth entries respectively. When MN
does CMIPv6 registrations, the BIDs generated must be different from
the PMIPv6 registrations. For example, if MN uses If2-ID value as
BID1 or BID2, then one of the CMIPv6 binding may overwrite the second
PMIPv6 binding. Thus, some MN involvement and some added multihoming
feature is necessary at MN in this scenario to have the desired
binding cache entries at LMA/HA. Moreover, one can clearly see that
when multiple PMIPv6 and CMIPv6 registrations are taking place at the
common anchoring point, there is a signaling storm in the system
although MN has only two physical interfaces. Thus, further work is
required to solve some issues that may arise in this scenario.
Basically, these CMIPv6 registrations via If2 can be combined with
the PMIPv6 registration to reduce the signaling storm in the core
network.
6. Single Interface Processing Multiple Prefixes
Multihoming for a MN in a very generic sense refers to either a MN
with multiple interfaces making simultaneous attachment or a MN that
can process multiple prefixes via its single interface and configures
multiple addresses per interface. Although the main focus of this
Jeyatharan, et al. Expires May 2, 2009 [Page 30]
Internet-Draft Multiple Interfaces in NetLMM October 2008
memo is to look into issues with respect to simultaneous attachment
that a MN performs in pure PMIPv6 and PMIPv6/CMIPv6 scenarios, in
this section, some multihoming related issues for a single interface
node is looked into.
In this section, a 3GPP specific scenario is looked into, where a
single interface MN may possibly see its home and foreign prefixes
via the same interface. Currently in 3GPP specifications, the
mobility management mechanism for a MN is either network based or
node based for a certain interface. However, it is very probable
that a MN will see home and foreign prefixes via the same interface
if the MN wants both mobility management mechanisms such as PMIPv6
and CMIPv6 mechanism for the same interface. In this section, some
issues when the MN wants such dual mobility management mechanism is
looked into. Another scenario that is analyzed is when MN sees
multiple prefixes via its single interface when there are multiple
LMA/HAs in the PMIPv6 domain.
6.1. PMIPv6 and CMIPv6 Roaming Issues for Home Routed 3GPP Scenario
In this section a scenario where both PMIPv6 and CMIPv6 mobility
management operations are performed when MN is in VPLMN is
considered. Such a scenario occurs when the MN is in VPLMN and gets
the home prefix from home P-GW which is placed in the HPLMN and gets
the foreign prefix obtained from P-GW placed in the VPLMN.
Basically, due to such simultaneous usage of home and foreign P-GWs,
MN sees both home and foreign prefixes being advertised. The
assumption here is that MN considers the prefix given by home P-GW as
the MIPv6 home prefix. In the scenario discussed in this section, it
is assumed that the MN prefers to process foreign prefix to achieve
better QoS with some CN.
Jeyatharan, et al. Expires May 2, 2009 [Page 31]
Internet-Draft Multiple Interfaces in NetLMM October 2008
+-----------+ BCEs at home P-GW
| HA/LMA/ | +-------------+----------+-------+--------+
| home P-GW | | MN prefix | MN.CoA | MN-ID | If-ID |
+-----------+ +-------------+----------+-------+--------+
| | Home Prefix | MAG.Addr | NAI | If1-ID | PMIPv6.BCE
| | HoA | CoA@AGW | - | - | CMIPv6.BCE
| HPLMN +-------------+----------+-------+--------+
------|-------
| VPLMN
|
|
+--------------+
| Foreign P-GW |
+--------------+
| s2a(PMIPv6)
+---------------+
| MAG/WiMax/AGW |
+---------------+
| If1 (Home prefix, Foreign prefix)
+------+
| MN |
+------+
Figure 8: Simultaneously at Home and at Foreign for Home Routed 3GPP
The above scenario shown in Figure 8 is a 3GPP scenario where MN gets
to see both home and foreign prefixes via the same interface. The
scenario description was given previously. MN is currently in VPLMN
and connected to MAG which is placed in the WiMAX access network and
the MAG functionality is collocated at the WiMAX access gateway
(AGW). It is further considered that the MAG and the P-GW at HPLMN
is connected via logical interface s2a where the PMIPv6 protocol is
used for mobility management. The routing path for data packets for
home routed case (i.e. packets whose source address obtained from
home P-GW) may be via the foreign P-GW. When MN sees home and
foreign prefixes, it is considered that the MAG would have performed
the PMIPv6 signaling at home P-GW for this home prefix. The binding
entry created at the home P-GW is shown by the first entry in the BC.
However, if MN wishes to use the foreign prefix to communicate with
CN assuming that it gets some information from the network that the
path attained using the foreign prefix to configure source address
gives better QoS, then the MN will generally perform the CMIPv6 BU at
LMA/HA or home P-GW such that it binds the care-of address obtained
from foreign prefix to the home address configured from home prefix.
It is assumed that the MN wishes to manage its mobility fully. If
such a decision is made by MN, then the second entry in the BC in
Figure 8 is created. The second entry will overwrite the first
entry. It can be clearly seen that there is double signaling done
Jeyatharan, et al. Expires May 2, 2009 [Page 32]
Internet-Draft Multiple Interfaces in NetLMM October 2008
(i.e. one by MAG and another by MN) for the same binding. This
problem needs to be solved. A possible solution is that MN could
request the MAG not to perform the PMIPv6 registration at home P-GW
and also inform the MAG that it will handle the binding update to
home P-GW and CN in a pure CMIPv6 mode. The description is this
section highlights an issue where the MN has a specific preferred
mobility management mode where as the network provides all types of
mobility management mechanisms available to the MN and contributes to
redundant signaling.
The problem described in this section is present irrespective of
whether single prefix per MN or multiple prefixes per MN model is
deployed in the system and it is applicable to both the models.
6.2. Multihoming Issues in Multiple LMA/HA Scenario
If there are multiple LMA/HAs in the same PMIPv6 network, then there
is a possibility that a MN sees multiple prefixes being received at
the same interface. In this section this scenario is briefly
analyzed to see whether multihoming issue is present. Again, it is
assumed that MN and HA have MONAMI6 functionality.
Jeyatharan, et al. Expires May 2, 2009 [Page 33]
Internet-Draft Multiple Interfaces in NetLMM October 2008
+-----+------------+------+
+----+ | HoA | CoA | BID |
| HA | +-----+------------+------+
+----+ | HoA |LMA1pref.CoA| BID1 |
| | HoA |LMA2pref.coA| BID2 |
+----------+--------+-----+ +------------+ +-----+------------+------+
| prefix | MN.CoA |MN-ID| | Internet | BCEs at HA
+----------+--------+-----+ +------------+
| LMA1pref | MAGAddr| NAI | / \
+----------+--------+-----+ / \
BCEs at LMA1 +------+ +------+
| LMA1 | | LMA2 |
+------+ +------+
| | +----------+--------+-----+
+-----------------+ | prefix | MN.CoA |MN-ID|
| foreign | +----------+--------+-----+
| PMIPv6 | | LMA2pref | MAGAddr| NAI |
| domain | +----------+--------+-----+
+-----------------+ BCEs at LMA2
|
+-----+
| MAG |
+-----+
LMA1pref | LMA2pref
+-----+
| MN |
+-----+
Figure 9: PMIPv6 domain with multiple LMA/HAs
Figure 9 shows a scenario where MN is attached to a foreign PMIPv6
domain with multiple LMA/HAs. Here, MN may receive two per-MN unique
prefixes (LMA1pref and LMA2pref) and configure two care-of addresses
using these prefixes. As MN is MONAMI6 capable, it will assign
different BID for each of the care-of addresses when binding them to
its home address at its home agent (HA). The binding caches of the
LMA/HAs and the HA are shown in Figure 9. In this case, there is no
forseeable issue and MN can enjoy multioming benefits. Basically,
MN's flows associated with home address will reach MN via both the
foreign LMA/HAs.
7. Conclusion
In this memo, various issues that needs to be addressed when
multihoming is supported in the PMIPv6 domain was analyzed. Issues
were analyzed for single and multiple prefix models separately. MuIf
PMIPv6/CMIPv6 related issues that are common to both the models were
Jeyatharan, et al. Expires May 2, 2009 [Page 34]
Internet-Draft Multiple Interfaces in NetLMM October 2008
analyzed separately. From the analysis as highlighted in this memo,
irrespective of the model used, some further work is required to
solve issues in: simultaneous usage, flow filtering, horizontal and
vertical hand-offs and PMIPv6/CMIPv6 related simultaneous attachment.
Finally, from the analysis done in this memo it can be concluded that
multihoming can be provided by either PMIPv6 multihoming models.
However, how these models are going to be used to achieve advanced
multihoming benefits needs further work. Whether network based
solutions or some terminal involvement deemed necessary has to be
analyzed for each of the problem scenario that was highlighted in the
memo. Considering that the PMIPv6 protocol is designed with the
objective of reducing the signaling from MN, solution space analysis
for these problems should consider solutions where MN involvement is
minimal.
8. IANA Considerations
This is an informational document and does not require any IANA
action.
9. Security Considerations
This document explores the problem of supporting mobile nodes with
multiple interfaces connecting to a PMIPv6 domain. No additional
security threat is identified as of the writing of this memo that is
specific to multiple interfaces support.
10. References
10.1. Normative Reference
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-18
(work in progress), May 2008.
10.2. Informative Reference
[2] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-09 (work in progress),
August 2008.
[3] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios
and related issues", draft-giaretta-netlmm-mip-interactions-02
(work in progress), November 2007.
Jeyatharan, et al. Expires May 2, 2009 [Page 35]
Internet-Draft Multiple Interfaces in NetLMM October 2008
[4] "Technical Specification Group Services and System aspects",
3GPP TR 23.402, December 2007.
[5] 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.
[6] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi,
"Flow Bindings in Mobile IPv6 and Nemo Basic Support",
draft-soliman-monami6-flow-binding-05 (work in progress),
November 2007.
[7] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim
Protocol for IPv6", draft-ietf-shim6-proto-10 (work in
progress), February 2008.
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[9] Devarapalli, V., Kant, N., Lim, H., and C. Vogt, "Multiple
Interface Support with Proxy Mobile IPv6",
draft-devarapalli-netlmm-multihoming-03 (work in progress),
August 2008.
[10] "3GPP system architecture evolution (SAE)", 3GPP TR 23.882,
January 2008.
[11] Muhanna, A., Krishnan, S., Leung, K., and B. Patil, "Proxy
MIPv6 Support of Transient Registration",
draft-muhanna-netlmm-pmipv6-support-transient-coa-01 (work in
progress), February 2008.
[12] Blume, O. and R. Sigle, "Secondary Binding Cache entries for
Proxy MIPv6", draft-blume-netlmm-secondary-bce-proxymip6ho-00
(work in progress), February 2008.
[13] "Technical Specification Group Services and System aspects",
3GPP TS 23.401, March 2008.
Appendix A. Change Log
Jeyatharan, et al. Expires May 2, 2009 [Page 36]
Internet-Draft Multiple Interfaces in NetLMM October 2008
o draft-jeyatharan-netlmm-multi-interface-ps-03:
* Revised draft and focused more on pure PMIPv6 multihoming and
PMIPv6/CMIPv6 multihoming.
* Have split the PMIPv6/CMIPv6 interaction into two sections.
MuIf PMIPv6/CMIP Interaction and Single Interface PMIPv6/CMIPv6
interaction.
* Have removed previous appendix sections. Most of the contents
in the Appendix has been merged with sections 5 and 6.
o draft-jeyatharan-netlmm-multi-interface-ps-02:
* Expanded the section 2 with more description on the multihoming
models.
* Expanded the draft with problem analysis focusing on current
and future 3GPP multiple interface scenarios
* Re-organized and expanded horizontal and vertical handoff
analysis in sections 3 and 4.
* Included a new section on PMIP/CMIP interaction issues for MuIF
nodes
* Removed section 5 from version 1 and included into PMIP/CMIP
interaction section.
o draft-jeyatharan-netlmm-multi-interface-ps-01:
* Expanded the draft into problem analysis for two PMIPv6
multihoming models.
* Expanded the draft with problem analysis focusing on 3GPP
scenarios.
* Modified the draft by cutting down on some appendix scenarios.
* Modified the draft by generalizing the problem analysis for all
types of nodes.
* Included some similar multihoming problem scenario as
highlighted by Vijay Devarapalli in his PMIPv6 multihoming
draft.
Jeyatharan, et al. Expires May 2, 2009 [Page 37]
Internet-Draft Multiple Interfaces in NetLMM October 2008
o draft-jeyatharan-netlmm-multi-interface-ps-00:
* Initial version.
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
Vijay Devarapalli
WiChorus Inc.
3590 North First Street
San Jose CA 95134
USA
Email: vijay@wichorus.com
Jun Hirano
Panasonic Corporation
5-3 Hikarino-oka
Yokosuka, Kanagawa 239-0847
JP
Phone: +81 46 840 5123
Email: hirano.jun@jp.panasonic.com
Jeyatharan, et al. Expires May 2, 2009 [Page 38]
Internet-Draft Multiple Interfaces in NetLMM October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Jeyatharan, et al. Expires May 2, 2009 [Page 39]
| PAFTECH AB 2003-2026 | 2026-04-23 20:36:00 |