NetLMM Working Group M. Jeyatharan
Internet-Draft C. Ng
Expires: December 19, 2008 J. Hirano
Panasonic
June 17, 2008
Multiple Interfaced Mobile Nodes in NetLMM
draft-jeyatharan-netlmm-multi-interface-ps-02
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 December 19, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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 (multiple unique prefixes per MN) that is
attached to the PMIPv6 domain. However, multihoming can also be
provided using same unique prefix for all interfaces of MN (single
unique prefix per MN). This memo explores and highlights some issues
associated with multihoming support in PMIPv6: using single unique
Jeyatharan, et al. Expires December 19, 2008 [Page 1]
Internet-Draft Multiple Interfaces in NetLMM June 2008
prefix per MN method or unique prefix per each interface of MN
method.
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 . . . . . . . 6
3. Multiple Interface Problem Analysis for Single Prefix Model . 8
3.1. Problem Analysis for Simultaneous Attachment . . . . . . . 9
3.2. Problem Analysis for Handoff Scenarios . . . . . . . . . . 12
3.3. Problem Analysis for Setting Filter Rule . . . . . . . . . 15
4. Multiple Interface Problem Analysis for Multiple Prefix
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Problem Analysis for Simultaneous Attachment . . . . . . . 16
4.2. Problem Analysis for Horizontal Handoff . . . . . . . . . 17
4.3. Problem Analysis for Vertical Handoff . . . . . . . . . . 18
5. PMIPv6/CMIPv6 Interaction issues for Multihomed MN . . . . . . 19
5.1. Single Interface Processing Multiple Prefixes . . . . . . 20
5.1.1. PMIPv6 and CMIPv6 prefix processing at home domain . . 20
5.1.2. PMIPv6 and CMIPv6 roaming issues for home routed
3GPP Scenario . . . . . . . . . . . . . . . . . . . . 22
5.2. MuIf MN PMIPv6/CMIPv6 roaming issues . . . . . . . . . . . 24
5.3. MuIf MN PMIP/CMIP signaling optimization . . . . . . . . . 26
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 28
9.2. Informative Reference . . . . . . . . . . . . . . . . . . 28
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Multihoming Issues in PMIPv6 Single LMA Roaming
Scenario . . . . . . . . . . . . . . . . . . . . . . 30
Appendix C. Multihoming Issues in Multiple LMA Scenario . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
Jeyatharan, et al. Expires December 19, 2008 [Page 2]
Internet-Draft Multiple Interfaces in NetLMM June 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 where a unique prefix is given to
each interface of MN. The base draft adopted such a multiple unique
prefixes per MN model or unique prefix per MN interface model to
provide basic multihoming support and connectivity to an unmodified
MN. "Unmodified" MN is generally understood as mobile nodes that do
not have any software changes to attain network based mobility
management. However, multihoming can also be provided using single
unique prefix for all interfaces of MN and one need not restrict to
unique prefix per interface type of allocation.
The multihoming support that is covered in the base PMIPv6 draft is
simply simultaneous 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 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, vertical hand-off support when MN has two or
more multiple interfaces connected to the network, 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 specific solutions which require some
enhancement/modification to the current PMIPv6 protocol. In this
memo we also analyze a case where MN sees multiple prefixes via a
single interface and configures different addresses and requires both
PMIPv6 and CMIPv6 states at the anchoring point. We also analyze a
case where MN sees both home and foreign prefixes via its single
interface and chooses a preferred prefix, and, as a result, requires
some changes to the PMIPv6 protocol operation.
The main objective of this memo is to analyze and highlight the
problems in these above mentioned advanced multihoming scenarios and
to highlight the necessity of further work that is required for the
basic PMIPv6 protocol to support the above described multihoming
scenarios. We perform scenario analysis for two different type of
PMIPv6 multihoming models which are the single unique prefix per MN
model and multiple unique prefixes per MN model so that one can
understand the problems and also one can see which model is preferred
for a certain multihoming scenario. In addition to the above
mentioned analysis, how to support multihoming for an unmodified MN
when PMIPv6 deploys a single unique prefix per MN model. Finally, in
Jeyatharan, et al. Expires December 19, 2008 [Page 3]
Internet-Draft Multiple Interfaces in NetLMM June 2008
Appendix B and Appendix C, the multihoming problem analysis is
focused on an advanced scenario such as roaming and multiple local
mobility anchors (LMAs). It is considered that the LMA can also
operate as a MIPv6 home agent. Thus LMA/HA or LMA will denote a
collocated PMIPv6 and CMIPv6 anchoring point.
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, we are
highlighting PMIPv6 multihoming problems pertaining towards the 3GPP
service architecture evolution (SAE) network structure.
Nevertheless, we would not exclude such problem analysis for other
SDO architectures that will adopt the PMIPv6 protocol for multihoming
purposes. Some of the scenarios where PMIPv6 is considered to be
used is clearly defined in [2]. In document [2], 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, we have considered
many futuristic multihoming scenarios that may well be adapted by
3GPP and other SDOs. Basic concepts and usefulness of multihoming is
already well defined in [3] 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 [2] and possibly future 3GPP activities.
2. Multiple Interfaces Support Models in PMIPv6
When a node with multiple interfaces is roaming in a PMIPv6 domain,
there are various benefits it can enjoy if the PMIPv6 domain allows
more than one interfaces to be used simultaneously. As mentioned
previously, these benefits can be found in other documents [3]. It
should be noted that some benefits could be enjoyed by the PMIPv6
domain or the operator as well. For instance, when the LMA receives
a packet destined for a multiple interfaced MN, the LMA may be able
to choose amongst the multiple routes to better utilize the network
resources of the PMIPv6 domain or to avoid congested region of the
PMIPv6 domain.
In this section, a brief analysis and principle of the two PMIPv6
multihoming models (same unique prefix across all interfaces and per
interface unique prefix) are given. Furthermore for each of the
models, the lack of support for simultaneous usage of all interfaces
for a certain flow and the lack of support for setting filter rules
are outlined. These are issues related to classic multihoming.
Jeyatharan, et al. Expires December 19, 2008 [Page 4]
Internet-Draft Multiple Interfaces in NetLMM June 2008
However, there are more issues that are related to vertical hand-offs
when MN has multiple interfaces which will be detailed in other
sections.
2.1. Different Home Network Prefix for Each Interface
o Operation complexity at LMA/HA to support unique prefix per
interface allocation
In this case, each interface of MN is allocated a unique Home
Network Prefix. To ensure that each interface of MN gets a unique
prefix, the LMA will use a 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 multiple prefix model is described in greater
detail in [1]. If the interface ID (If-ID) in PBU is not
available at the LMA binding cache, and if the hand-off flag is
set to "1" (implying new connection request), the LMA 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, then the LMA 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 will use more information such as vertical
hand-off flag inserted in the PBU, as well as 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 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.
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 will not
be able to perform path switching for packets addressed to a
particular interface. For example, MN's IF1 is assigned a prefix
(P1) and MN's IF2 is assigned another prefix (P2). When LMA
receives a packet addressed to an address configured using P1, LMA
would not route such packet via MN's IF2 path. In some use cases,
it is preferred that a flow traverses via all interfaces of MN for
example to achieve load sharing and load balancing benefits and
where possible using a less costly wireless access for the flows
whenever simultaneous access via different interfaces can be
Jeyatharan, et al. Expires December 19, 2008 [Page 5]
Internet-Draft Multiple Interfaces in NetLMM June 2008
achieved (ex. hierarchical cell structures). If MN is an IPv6
host using SHIM6 (Site Multihoming by IPv6 Intermediation) [4] or
SCTP (Stream Control Transport Protocol) [5] or MN is a MONAMI6
capable node [6], then the MN can continue to enjoy simultaneous
usage benefits such as a 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.
o Lack of Flow Filtering Support
Setting filter rules 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 [7]. 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 needs to pass its flow
filtering rules to the MAG to which it is attached. As described,
such flow filtering support mechanisms are essential even when
PMIPv6 is used and currently not supported in PMIPv6. If PMIPv6
does not support a mechanism to set filter rules, then the only
way MN can attain the preference setting 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.
o Prefix Resource Usage
Another general issue with this multiple prefixes model is that
prefix resources are wasted and in some cases, a node may not get
a prefix 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 case, each interface will receive the same 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
Jeyatharan, et al. Expires December 19, 2008 [Page 6]
Internet-Draft Multiple Interfaces in NetLMM June 2008
of the actual address configured (or assigned) for that interface.
When PMIPv6 implements this 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 prefix model can be implemented using three different
mechanisms. We next briefly describe these methods and discuss the
merits and drawbacks of each of these methods and furthermore compare
against the multiple prefixes model.
o Prefix Based Caches
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 [6]. The main problem with this method is that, routing is
based on prefixes and there is a tendency for packets sent to a
particular address being routed to a wrong interface if the MN
configures different addresses for its interfaces. When compared
to the multiple prefixes model, simultaneous usage can be easily
achieved 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. Furthermore, when setting filter rules,
the flow parameters can be tied with the interface identifier or
BID that is available in the cache.
o Different Address Based Caches
Here the 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 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 does not occur since the routing at the LMA/HA is address
based. However, to attain simultaneous usage benefits proper
mechanisms needs to be in place 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.
Jeyatharan, et al. Expires December 19, 2008 [Page 7]
Internet-Draft Multiple Interfaces in NetLMM June 2008
Furthermore, the MAGs need appropriate mechanisms to allow packets
that are addressed to 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. Basically, MN will set filter rules by tying
the flow parameters to the address of the interface.
o Same Address Based Caches
In this method, all MN interfaces configures the same address.
Thus the problems described as to packets being routed wrongly or
the simultaneous usage issue 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 multihomed nodes such as
multiple interfaced nodes when PMIPv6 uses a single unique prefix per
MN model is presented. The assumption in the analysis regarding to
which PMIPv6 functional entity is mapped to which entity in 3GPP
architecture is based on details provided in documents such as [8]
and [2].
Jeyatharan, et al. Expires December 19, 2008 [Page 8]
Internet-Draft Multiple Interfaces in NetLMM June 2008
3.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.P1 | MAG2.Addr | NAI |If2-ID |
| +-------------+-----------+--------+-------+
| BCEs at LMA/HA
+--------------------------+
| |
| Proxy Mobile IP Domain |
| |
+--------------------------+
| |
MAG2.Addr | | MAG1.Addr
+--------------+ +-----------+
| 3G(SGW)/MAG2 | | ePDG/MAG1 |
+--------------+ +-----------+
\ /
If2 \ / If1
+------+
| MN |
+------+
Figure 1: Attaching multiple interfaces to PMIPv6 that deploys single
prefix model
o Maintaining simultaneous bindings at LMA/HA in 3GPP architecture
We first explore some fundamental issues if PMIPv6 uses single
prefix per MN type of multihoming support. Figure 1 shows a
multiple interfaced MN, which is simultaneously attached to a
PMIPv6 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. It is further assumed that
PMIPv6 protocol is deployed in 3GPP evolved packet core (EPC)
network where MN.If1 is attached to the evolved packet data
gateway (ePDG) via a IPSec tunnel and MN.If2 is attached to
Serving Gateway (S-GW)/MAG2 which is its first hop router. It is
considered that the ePDG/MAG1 is not the first hop router for
MN.If1. More information on 3GPP architectural entities and their
roles can be obtained from 3GPP technical specifications [8] and
[2]. 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
Jeyatharan, et al. Expires December 19, 2008 [Page 9]
Internet-Draft Multiple Interfaces in NetLMM June 2008
access technolgy hand-off is also a possible optimization scenario
for vertical hand-off.
If such single prefix type of multihoming is supported, then there
needs to be some parameter (If-ID, BID etc) in the LMA/HA cache to
differentiate the bindings from same MN. It is important to
appreciate that in the single prefix model, as shown in Figure 1,
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. In such single prefix model,
the Network Access Identifier (NAI) will be used for prefix
assignment because only a single prefix needs to be assigned to a
multiple interface 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 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 new 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 information in an option.
Basically these interface IDs can be media access control (MAC)
addresses or these can be interface identifiers that MN use to
form global unicast address. If the latter type of interface
identifiers are used, then it is extremely important that they are
unique across MN interfaces. Thus, as advised in [1], the use of
MAC addresses are preferred for interface IDs, due to their
uniqueness per interface. These interface IDs (assuming MAC
address) can be readily obtained by MAGs if they are first hop
routers. Since MAG1 is an ePDG as shown in Figure 1, then, using
simple MAC addresses may not work as the MAC address cannot be
obtained from IPSec tunnel establishment signal.
In such a problematic case of an ePDG being a MAG, proper
mechanisms should be in place to get the correct If-ID. There can
be a case where ePDG in Figure 1 does not know If-ID and generates
a random If-ID. If this If-ID is same as MN's some other
interface If-ID (ex. MN.If2 identifier), then this may overwrite
an existing If-ID that is available at LMA/HA cache. Such
overwriting at LMA/HA will cause a loss of a valid routing state.
In such a scenario where MAG is an ePDG, one possible way is for
MN to generate an If-ID and explicitly inform the ePDG during
IPSec tunnel establishment. Alternatively, MN can simply inform
ePDG its MAC address during tunnel establishment. Another way is
for Authentication Authorization Accounting server (AAA) to
generate If-IDs for initial attachments and assume that If-IDs can
be transferred via context transfer for hand-off attachments. Yet
Jeyatharan, et al. Expires December 19, 2008 [Page 10]
Internet-Draft Multiple Interfaces in NetLMM June 2008
another way is for the MAG/ePDG to query nearby routers for MN's
If-IDs and then generate a unique interface ID. With so many
approaches, some further analysis needs to be performed to select
the best possible method. We feel some MN involvement may be
required to attain this objective because only the MN will know
its unique interfaces and its identifiers in all scenarios
(initial attacment, hand-off and bootup).
o Simultaneous access support for unmodified MN
Suppose we consider 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 configuration
method, then MN.If2 may not be able to configure a global address
(perhaps a Duplicate Address Detection (DAD failure)) and that
interface will not be used. 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, ideal multihoming is not
obtained. On the other hand, if MN configures different addresses
on its interfaces using stateless address configuration (assuming
different interface identifier for each interface), 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
neighbour cache entry mapping address of MN.If1 to the layer two
(L2) address of MN.If2. Thus, it can be clearly seen that,
although multihoming support is available at LMA/HA, when LMA/HA
routes packets based on prefix, packets to one address to which a
MAG does not have supporting neighbour cache entry will be lost.
To solve the above mentioned problem for an unmodified host when
it configures same address for both its interfaces may be
difficult. We feel that some changes can be done at the network
side to prevent activation of stateful mode of address
configuration for unmodified host and thus avoid same address
being configured 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. Or, as discussed in the NetLMM mailing list,
the unmodified host can be configured with a single virtual
interface at layer three (L3) to mitigate this issue.
Jeyatharan, et al. Expires December 19, 2008 [Page 11]
Internet-Draft Multiple Interfaces in NetLMM June 2008
3.2. Problem Analysis for Handoff Scenarios
o Horizontal Handoff for Multiple Interfaced MN
Handoffs are generally classified as horizontal handoff and
vertical handoff. Horizontal handoff from L3 perspective means
handoff 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. In this sub-section, for a multiple
interfaced MN involved in horizontal handoff, we focus on MuIf MN
creating the correct routing state at LMA/HA during horizontal
handoff and horizontal handoff optimization by means of using
multiple interfaces.
In a multiple interface scenario using the single prefix model,
when one of the interface performs horizontal handoff while the
other interface is still attached, the problem is not very
complex. The reason being the new MAG only needs to know the
If-ID of the interface that is performing the horizontal handoff
to create the correct routing entry at LMA/HA. Again, the new MAG
can get to know this If-ID by various means. New MAG can get to
know If-ID via context transfer from old MAG, from AAA, from the
MN, or obtaining directly from MAC address. For horizontal hand-
off case, we do not foresee any issue as long as there are
appropriate mechanisms in the system for the new MAG to know the
If-ID.
Another area of interest is horizontal handoff delay optimization
and thus preventing packet loss during handoff. In the multiple
interface case, the horizontal handoff of a certain interface can
be optimized using another stable interface (i.e. interface that
is not perfoming handoff). For example, during the time when
there is no routing state at the LMA/HA associated with an
interface, such as the time between MN dereg PBU has arrived from
old MAG and the new PBU has not arrived from the new MAG, the
packets can easily be routed via another stable interface. Such
an optimisation can be easily achieved using the single prefix per
MN model. This is because all the routing states associated with
MN is based on a single prefix. Thus LMA can easily utilize a
stable interface to route packets during horizontal handoff.
Probably the only change that has to be done in the system is that
the MN needs to notify the address of the interface that is
undergoing handoff to the MAG that is attached to its stable
interface. Horizontal handoff event that will result in access
router change should be detected using L2 specific mechanisms and
notified to the L3 of the protocol stack of MN. Once such
triggers received at L3, MN should perform such triggering to the
stable MAG. Such a scenario is a very probable scenario in 3GPP
Jeyatharan, et al. Expires December 19, 2008 [Page 12]
Internet-Draft Multiple Interfaces in NetLMM June 2008
where a MN can be roaming in such a manner where one interface is
connected to 3G interface and the other interface is connected to
WLAN. Since WLAN cells are smaller, MN will go through many
horizontal handoffs for the WLAN interface while still being
attached to the same cellular cell. Thus, by using the stable
interface, packet loss can be reduced and this scenario very
clearly shows that horizontal handoff optimization can be obtained
using the single prefix model and multiple interface usage. In
some cases, the MN may want all its data flows to come via WLAN
interface due to cost consideration, but may want to keep the
cellular interface active just to achieve horizontal handoff
optimization just described. Alternatively, when MN moves through
WLAN cells, then MN way want to power on 3G interface for
horizontal handoff optimization.
o Vertical Handoff for Multiple Interfaced MN
* Vertical Handoff between two interfaces
First we will analyse vertical handoff between two interfaces.
For the vertical handoff 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 MM 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 handoff 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. In such a case, appropriate mechanism should be in
place. For example, the MN may need to inform MAG2 about
address of MN.If1, so that MAG2 can transfer packets to MN.If2
without dropping the packets. Again, to solve the above
mentioned issue, some terminal involvement may be required.
Perhaps a link layer (L2) trigger from MN may be sufficient if
MAG2 is directly attached to MN. This said L2 trigger could be
such that MN informs the address of MN.If1 to MAG2.
Alternatively, MN.If2 can configure the same address as MN.If1
to solve this issue. Another issue that needs to be tackled is
that, if MN is going to perform address autoconfiguration, then
until the address is configured and neighbour discovery
procedure are completed, the packets that are received at MAG2
may be dropped if sufficient buffering resources are not
available. Such issues are being looked into in the following
Jeyatharan, et al. Expires December 19, 2008 [Page 13]
Internet-Draft Multiple Interfaces in NetLMM June 2008
documents [9] [10]. These said 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 handoff. One
way of solving this buffering issue at the new MAG can be using
context transfer during vertical handoff where the 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
signalling, will advertise router advertisement (RA) and
simultaneously send the signaling to set up the IP bearer path
at LMA/HA.
* Vertical Handoff when MN is attached via more than two
interfaces
Here we consider a scenario where vertical handoff is
associated with two interfaces, while there is still a
connection available via a third stable interface. The main
advantage of this scenario is that, during vertical handoff
process until new interface address configuration is complete,
the third non-romaing interface can be used to receive packets.
Since in vertical hand-off, the address configuration delay is
present, the MN can use the third stable interface for this
purpose. Basically, the MN can inform LMA about the address
configuring state and use the third interface rather than
performing the make before break kind of handoff for the
interface that is performing the vertical handoff. This
scenario highlights some further work that may be done for MuIf
terminals involved in vertical handoff.
Jeyatharan, et al. Expires December 19, 2008 [Page 14]
Internet-Draft Multiple Interfaces in NetLMM June 2008
3.3. Problem Analysis for Setting Filter Rule
+--------------------+
| HA/LMA/Home P-GW | Flow1: MN.If1 CoA1
+--------------------+ Flow2: MN.If2 CoA2
|
|
+--------------------------+
| Foreign LMA/Foreign P-GW |
+--------------------------+
| BCE at Foreign LMA
+-----------------------+ +-------------+-----------+-------+--------+
| | | Home Prefix | CoA | MN-ID | If-ID |
| Proxy MIPv6 Domain | +------------------------------------------+
| | | MN.P1 | MAG1.Addr | NAI | If1-ID |
+-----------------------+ | MN.P1 | MAG2.Addr | NAI | If2-ID |
| | +------------------------------------------+
MAG2.Addr | | MAG1.Addr
+---------+ +-----------+
| 3G/MAG2 | | ePDG/MAG1 |
+---------+ +-----------+
\ /
If2 \ / If1
+------+
| MN |
+------+
Figure 2: Single Prefix Flow Filter Issue
In this section we assume that MN has multihoming capability. In the
single prefix multiple interface scenario, there is a specific
problem that needs to be tackled when MN sets filter rules at home
agent and is currently attached to a foreign domain. This is
explained in detail below.
In Figure 2, MN sets filter rules at HA which is the 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 HA. However,
due to foreign LMA/foreign P-GW implementing prefix based routing,
flow1 can be routed wrongly and may arrive via the cellular MAG.
This is certainly an issue and 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). It is further assumed that in Figure 2, MN gets the
foreign prefix (local breakout prefix in 3GPP jargon) in the foreign
domain. Foreign prefix can be used for route optimization without
trading off the advantage of network based mobility management PMIPv6
Jeyatharan, et al. Expires December 19, 2008 [Page 15]
Internet-Draft Multiple Interfaces in NetLMM June 2008
offers. If in another scenario, MN is directly connected to home
PMIPv6 domain, then MN may need to set filter rules at HA.
4. Multiple Interface Problem Analysis for Multiple Prefix Model
In this section, problem analysis for multihomed nodes when PMIPv6
uses a multiple prefixes per MN model is presented.
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. It is also considered that MN is attached to PMIPv6
domain and wants PMIPv6 MM mechanism via both its access technology
type using 3GPP specific mobility selection mechanism. MN receives
different prefixes via each of its interfaces. Basically, when
MN.If1 attaches to PMIPv6 network, the first BC entry will be
created. When MN.If2 attaches to PMIPv6 network, the second BC entry
will be created. The prefixes are sufficient to separate the caches.
However, these If-IDs are required for prefix assignment purposes.
The multiple prefix model does not create any confusion to an
unmodified IPv6 host that does simultaneous attachment because there
Jeyatharan, et al. Expires December 19, 2008 [Page 16]
Internet-Draft Multiple Interfaces in NetLMM June 2008
is no possibility that a multi-link subnet will be experienced by the
MN. However, if MN is having flows with multiple CNs and a certain
CN sends packets to address of MN configured from prefix P1 and
another CN sends packets to address of MN configured from prefix P2,
then multihoming benefits such as these said flows coming via all MN
interfaces cannot be achieved. Thus, some further work is required
in this area. For example, LMA/HA can identify using the NAI that
both entries belong to the same MN. But the MAGs are not aware of MN
other interface prefixes. Thus, if LMA/HA decides to send packets
configured from P1 to MAG2, MAG2 will drop it. If a MAG has
knowledge of MN's other interface(interfaces not attached to MAG)
prefixes, then definitely, MN can enjoy some advanced multihoming
benefits.
4.2. Problem Analysis for Horizontal Handoff
+-------------------------------------------+
| |
| Proxy Mobile IPv6 Domain |
| |
+-------------------------------------------+
| | |
| MAG1.Addr | MAG2.Addr | MAG3.Addr
+---------+ +-----------+ +-----------+
| 3G/MAG1 | | WLAN/MAG2 | | WLAN/MAG3 |
+---------+ +-----------+ +-----------+
\ / /
If1(P1) \ / If2(P2) / If2(P2)
+-------------+ / Horizontal
| MN |-----/ handoff for If2
+-------------+
Figure 4: Horizontal Handoff 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 [8]. It is further
considered that MN while still connected to 3G network via MN.If1,
performs a horizontal handoff for MN.If2. Basically, MN.If2 will
detach from MAG2 and attach at a new MAG3. In such a scenario, the
important thing is that the If-ID information in the PBU sent from
MAG3 has to have If2-ID. This interface ID is essential for LMA to
allocate the correct prefix during horizontal handoff. As discussed
Jeyatharan, et al. Expires December 19, 2008 [Page 17]
Internet-Draft Multiple Interfaces in NetLMM June 2008
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 big problem of getting this interface ID because MAG3 is the
directly connected access router of MN and the MN.If2 MAC address can
be readily obtained (assuming MAC address is used as MN If-ID). The
only danger in this scenario is that, if MAG3 does not have interface
ID of If2 (for some reason) and it does not know the handoff state of
MN, then it may set the handoff flag to "4" in the handoff indication
option saying that the handoff is unknown. In such a worst case
scenario, the LMA may assign a new prefix for If2 and session
continuity for prefix P2 flows will be disrupted. Thus, these kind
of issues needs to be prevented if multiple prefix model is deployed.
The main concern is that if MAG3 does not know If2-ID, then getting
this information quickly needs to be explored to prevent horizontal
handoff establishment delay. Alternatively, the handoff state has to
be explicitly informed to MAG3.
Another area to be explored is the handoff delay optimization. As
described in section 3, horizontal handoff delay can possibly be
optimized using the stable 3G interface. However, in the multiple
prefix model to achieve this is more difficult because the prefix of
the interface undergoing handoff needs to be informed via a trusted
entity to the 3G MAG. The LMA also needs to be informed to route
packets for interface undergoing handoff via another interface.
These signalings need to be done in a timely manner to achieve the
benefits of handoff delay optimization.
4.3. Problem Analysis for Vertical Handoff
+-------------------------------------------+
| |
| Proxy Mobile IPv6 Domain |
| |
+-------------------------------------------+
| | |
| MAG1.Addr | MAG2.Addr | MAG3.Addr
+---------+ +------------+ +-----------+
| 3G/MAG1 | | WiMAX/MAG2 | | WLAN/MAG3 |
+---------+ +------------+ +-----------+
\ / /
If1(P1) \ /If2(P2) / If3(P2)
+-------------+ /Vertical handoff
| MN |------/ for If2
+-------------+
Figure 5: Vertical Handoff in Multiple Prefix Model
Jeyatharan, et al. Expires December 19, 2008 [Page 18]
Internet-Draft Multiple Interfaces in NetLMM June 2008
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 handoff 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 handoff is performed, then what is
desired by vertical handoff from MN's point of view is that MN
requires flows for prefix P2 to be sent via MN.If3. To achieve this,
the LMA should assign prefix P2 to MN.If3. For LMA to process such
vertical handoff request information and assign the desired prefix P2
in the above scenario, the PBU sent by MAG3 need to have If2-ID in
addition to If3-ID. Moreover, as mentioned in [1], the handoff flag
in the handoff indication option should specify that this is a
vertical handoff. Thus one can clearly see the complexity involved
in getting the correct prefix for vertical handoff in the multiple
prefix model.
Let us consider another scenario where MN did not have MN.If1 but
only had MN.If2 and MN.If3. When MN performs a vertical handoff from
MN.If2 to MN.If3, If2-ID may not be required in the PBU. Once LMA
sees the handoff flag pointing to "2" (vertical hand-off), it will
assign P2 to MN.If3. This is because LMA has no difficulty in
identifying P2 cache since there are no other entries associated with
MN. Thus, one can appreciate that the vertical handoff complexity is
high when MN has more than two interfaces.
As highlighted previously, when MN does vertical handoff in a complex
scenario as shown in Figure 5, MAG3 needs If2-ID information in the
PBU. The question is how such information can be obtained by MAG3.
Suppose MAG3 is ePDG. Then, as mentioned previously, MN can supply
the If2-ID to MAG3. Another option is that MAG3 can get it via
context transfer from MAG2. If vertical handoff is performed between
heterogeneous access network types, context transfer via
heterogeneous networks may take some time and other fast mechanisms
may need to taken into consideration to prevent vertical handoff
establishment delay. In 3GPP inter access technology handoff 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 of the shutdown interface using purely network based
mechanisms is not efficient and may not be possible. Thus, some
terminal involvement is definitely useful in this scenario.
5. PMIPv6/CMIPv6 Interaction issues for Multihomed MN
In this section, PMIPv6 and CMIPv6 interaction scenarios are analyzed
Jeyatharan, et al. Expires December 19, 2008 [Page 19]
Internet-Draft Multiple Interfaces in NetLMM June 2008
for MuIf terminal and also for a single interface terminal that is
capable of processing different prefixes as a result of being capable
of multihoming. In 3GPP SAE framework, the MN can select PMIPv6 or
CMIPv6 (i.e. Dual stack MIPv6) when connecting to a network of a
particular access technology. Thus, there are many scenarios where
such heterogeneous mobility management mechanisms will be used for a
MuIf terminal considering that a MN can be attached to home, foreign
or simultaneously at home and foreign. PMIPv6/CMIPv6 interaction
issues for a single interface terminal can be found in the document
[11]. However, for futuristic use cases in 3GPP where the MN is
attached via multiple interfaces, these advanced scenarios need to be
looked into in depth.
5.1. Single Interface Processing Multiple Prefixes
In this section, we look at a 3GPP specific scenario where the 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 we look at specific multihoming
related issues when the MN wants such dual mobility management
mechanisms, in two different scenarios. The first scenario is when
MN is in the home domain or HPLMN and wants such dual mobility
management operation. The second scenario is when MN is in the
foreign or VPLMN and wants such dual mobility management operation.
5.1.1. PMIPv6 and CMIPv6 prefix processing at home domain
In this section multihoming is analyzed from the perspective of
multiple care-of addresses configured for a certain interface of MN
when MN is in the HPLMN. Furthermore, the analysis is performed in a
system that uses single prefix multihoming model at LMA/HA. We would
like to highlight that the problem highlighted in this section is
applicable even if LMA/HA deploys the multiple prefixes per MN model.
Jeyatharan, et al. Expires December 19, 2008 [Page 20]
Internet-Draft Multiple Interfaces in NetLMM June 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 6: Multihomed MN processing multiple 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 6, it is assumed that MN has multihoming
support and can generate BIDs as in [6] 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 home address (MONAMI6/MIPv6 sense) is equal to MN.If1 address.
The mechanism by which MN gets the MIPv6 home address can be 3GPP
Jeyatharan, et al. Expires December 19, 2008 [Page 21]
Internet-Draft Multiple Interfaces in NetLMM June 2008
specific or using dynamic bootstrapping mechanism. In Figure 6, 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, then 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 evolved node B (eNodeB) that also
acts as a router as described in [12], 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 [2], 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.
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. 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 ot reduce the signaling storm in the core
network.
5.1.2. PMIPv6 and CMIPv6 roaming issues for home routed 3GPP Scenario
In this section we consider a scenario where both PMIPv6 and CMIPv6
mobility management operations are performed when MN is in VPLMN.
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. The assumption here is that MN
Jeyatharan, et al. Expires December 19, 2008 [Page 22]
Internet-Draft Multiple Interfaces in NetLMM June 2008
considers the prefix given by home P-GW as the MIPv6 home prefix.
Usually, from MIPv6 point of view, when a node sees the home and
foreign prefixes via a certain interface it will not engage in
mobility related signaling. However, in the specific scenario, we
assume that the MN can process foreign prefix although it sees home
prefix and in that sense it is multihomed.
+-----------+ 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 7: Simultaneously at home and at foreign for home routed 3GPP
The above scenario shown in Figure 7 is the 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, then 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
Jeyatharan, et al. Expires December 19, 2008 [Page 23]
Internet-Draft Multiple Interfaces in NetLMM June 2008
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.
This is shown by the second entry in the BC in Figure 7. The second
entry will overwrite the first entry. It can be clearly seen that
there is double signaling done (i.e. one by MAG and another by MN)
for the same binding. This problem needs to be solved. MN could
possibly decide to use the PMIPv6 binding created by MAG to get
reachability for the home prefix and then only use the care-of
address configured from foreign P-GW to communicate with CN directly
(i.e. dual mobility management mode). Another 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 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.
5.2. MuIf MN PMIPv6/CMIPv6 roaming issues
In this section, the focus is on analyzing the issues when a MuIf MN
does a simultaneous attachment via heterogeneous mobility management
modes such as PMIPv6 and CMIPv6 to the common anchoring point. As
described in [2], even when MN (assuming two interfaces) is in the
HPLMN, the MN mobility management for the first interface can be
performed via PMIPv6 mechanism and the mobility management for the
second interface can be performed by CMIPv6 mechanism. In 3GPP
roaming scenarios where the MN moves away from HPLMN, there can be
specific intermediate scenarios where the MN has one interface
attached to home domain (HPLMN) and the other interface attached to
foreign domain (VPLMN). In such intermediate roaming scenarios also,
MN may again be involved in different management mechanisms via its
different interfaces. In this section, such scenarios are analyzed
and some issues are highlighted that definitely need some MN
involvement and some modifications to PMIPv6 protocol to support
simultaneous usage in a PMIPv6 and CMIPv6 mixed mobility management
environment as considered in the 3GPP framework.
Jeyatharan, et al. Expires December 19, 2008 [Page 24]
Internet-Draft Multiple Interfaces in NetLMM June 2008
+----------+ 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 8: MuIf MN attaching to HPLMN by using PMIPv6/CMIPv6 Mobility
Management mechanisms
This scenario as shown in Figure 8 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.
Basically, MN will use the on-link prefix that is available in the 3G
access network advertised by eNodeB or advertised by S-GW which is
placed in the core network to configure a care-of address. 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. It is further considered that
the home address is obtained from a prefix that is topologically
rooted at the home P-GW. It is assumed that MN is attached to WLAN
access via its second interface and chooses PMIPv6 mobility
management mechanism to manage mobility for this interface. It is
further assumed that MN sees the same home prefix when MAG2 performs
the PMIPv6 binding at the LMA/HA. To maintain such simultaneous
attachment, the PBU sent by MAG2 needs to have some If-ID or BID2
that is different from BID1. The mechanism by which MAG2 gets to
know the correct value for BID2 needs to be supported by the system.
Otherwise, MAG2 may use a BID that is of same value as BID1 and may
overwrite the CMIPv6 entry and delete the reachability to cellular
interface. There can be many mechanisms by which this problem can be
solved. 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
Jeyatharan, et al. Expires December 19, 2008 [Page 25]
Internet-Draft Multiple Interfaces in NetLMM June 2008
the LMA/HA to generate the BID that is different from BID1. For MAG2
to make such a request it needs to know that MN other interface is
attached to the LMA/HA and this information needs to be given by MN.
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 so that simultaneous binding
using CMIPv6 and PMIPv6 can be obtained. The problem and solution
described in this section is applicable to either PMIPv6 multihoming
models (i.e. the single prefix per MN and multiple prefixes per MN
model).
In another alternate scenario, if only the MN's WLAN interface in
Figure 8 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, 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. It is important to understand
that since the interface 2 PMIPv6 prefix and the home address prefix
are the same, only when the BIDs are the same the old PMIPv6 entry
can be overwritten by the new CMIPv6 entry for the same interface.
Ideally, the second binding entry shown in Figure 8 should have been
overwritten by the CMIPv6 binding for interface 2 due to roaming. If
interface 2 current binding does not overwrite the old PMIPv6 binding
for interface 2, packet loss can take place if the LMA/HA decides to
route packets using the second entry in BC shown in Figure 8.
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 CMIPv6 binding.
5.3. MuIf MN PMIP/CMIP signaling optimization
In this section, we consider a signaling optimization that can be
performed in multiple interface case when one of the interface
performs the CMIPv6 BU and the other interface performs the PMIPv6
BU. To further understand the optimization issue we again consider
Figure 8. 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. 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. Basically, the CMIPv6 BU can be broken into
steps such as bootstrapping to identify the HA address and then
performing the CMIPv6 BU. To optimize the bootstrapping signaling
part, if MN knows that the PMIPv6 binding is via HPLMN, then it can
possibly configure the care-of address for interface 1 and perform
Jeyatharan, et al. Expires December 19, 2008 [Page 26]
Internet-Draft Multiple Interfaces in NetLMM June 2008
the CMIPv6 BU via the interface 2. In such a case, the discovery for
home agent address need not be performed because, the MAG2 knows the
address of home P-GW. The MN possibly can trigger MAG2 and request
the MAG2 to perform the CMIPv6 binding. The MN needs to give the
CMIPv6 binding contents to MAG2 so that PMIPv6 and CMIPv6 signaling
optimization can be achieved. Such signaling optimization issues
needs to be identified for PMIPv6 and CMIPv6 interaction scenarios.
again we would like to highlight that the issue described in this
section is applicable for both PMIPv6 multihoming models(i.e. single
prefix and multiple prefixes)
6. 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 seperately. MuIf
PMIP/CMIP related issues that are common to both the models were
analyzed seperately. From the analysis as highlighted in the draft,
irrespective of the model used, some further work is required to
solve issues in: simultaneous attachment, flow filtering, horizontal
and vertical hand-offs and PMIPv6/CMIPv6 related issues. Finally, we
would like to conclude 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, we
suggest that solution space analysis for these problems should
consider solutions where MN involvement is minimal.
7. IANA Considerations
This is an informational document and does not require any IANA
action.
8. 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.
9. References
Jeyatharan, et al. Expires December 19, 2008 [Page 27]
Internet-Draft Multiple Interfaces in NetLMM June 2008
9.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.
9.2. Informative Reference
[2] "Technical Specification Group Services and System aspects",
3GPP TR 23.402, December 2007.
[3] 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.
[4] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim
Protocol for IPv6", draft-ietf-shim6-proto-10 (work in
progress), February 2008.
[5] 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.
[6] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008.
[7] 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.
[8] "3GPP system architecture evolution (SAE)", 3GPP TR 23.882,
January 2008.
[9] 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.
[10] Blume, O. and R. Sigle, "Secondary Binding Cache entries for
Proxy MIPv6", draft-blume-netlmm-secondary-bce-proxymip6ho-00
(work in progress), February 2008.
[11] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios
Jeyatharan, et al. Expires December 19, 2008 [Page 28]
Internet-Draft Multiple Interfaces in NetLMM June 2008
and related issues", draft-giaretta-netlmm-mip-interactions-02
(work in progress), November 2007.
[12] "Technical Specification Group Services and System aspects",
3GPP TS 23.401, March 2008.
Appendix A. Change Log
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.
o draft-jeyatharan-netlmm-multi-interface-ps-00:
* Initial version.
Jeyatharan, et al. Expires December 19, 2008 [Page 29]
Internet-Draft Multiple Interfaces in NetLMM June 2008
Appendix B. Multihoming Issues in PMIPv6 Single LMA Roaming Scenario
+-----+ BCEs at LMA/HA for single prefix model
| HA/ | +---------+---------+-------+----------+------+
| LMA | |MN prefix| MN.CoA | MN-ID | If-ID |Flag |
+-----+ +---------+---------+-------+----------+------+
| | prefix | MAGaddr | NAI | If1-ID | |
+----------------+ | HoA | CoA | NAI | BID2 |"H" |
| Home PMIP | +---------+---------+-------+----------+------+
| domain |
+----------------+
|
+-----+
| MAG | MAG Address
+-----+
|
| +-----------+
| | foreign |
| | domain |
| +-----------+
| |
HoA | If1 |
+--------------+ If2 +-----+
| Monami6 MN |-------------| AR |
+--------------+ CoA +-----+
Figure 9: Simultaneously at home and at foreign
In this section some issues associated with MN when it roaming away
from home domain is analyzed. In Figure 9, it is assumed that MN can
be a MONAMI6 node. It is assumed that MN.If1 is attached to home
domain, which is also a PMIPv6 domain. The entry created at LMA/HA
due to MN.If1 attachment is shown by the first entry. If MN.If2 is
attached to foreign domain, MN will configure a CoA for MN.If2 and
will want to send a CMIPv6 binding to LMA/HA either using a "H" flag
or will send a CMIPv6 binding using BID2 in the binding update. If
such an action is performed by MONAMI6 MN, then the binding cache
created is shown by the second entry. The important point here is
that, if 'H" flag is used, then there is no problem because both MN
interfaces reachability states are available at LMA/HA. However, if
MONAMI6 nodes decides to put BID2, instead of "H" flag, and if BID2
sent in CMIPv6 BU is same as If1-ID, then there is a danger of
overwriting the first PMIPv6 entry and thus loosing the simultaneous
at home and away benefits. Furthermore, if MN is a MIPv6 node in
Figure 9, then MN may not insert BID or "H" flag in CMIPv6 BU and
this CMIPv6 BU will overwrite the first PMIPv6 PBU and multihoming
benefits will be lost.
Jeyatharan, et al. Expires December 19, 2008 [Page 30]
Internet-Draft Multiple Interfaces in NetLMM June 2008
If multiple prefix model is active in the scenario shown in Figure 9,
then such a roaming scenario does not pose any issue for a MIPv6 host
that has two home addresses (one for each interface configured from 2
different home prefixes). This is because, the first entry in BCE
will have P1 prefix (PMIPv6 entry) and the second entry will have a
CMIPv6 entry tying MN HoA(configured from P2 prefix) to a care-of
address configured in foreign domain. Thus, the caches from both
interfaces are clearly separated by means of prefixes. In this
multiple prefix roaming case, If-ID need not be attached in the
CMIPv6 BU to separate the bindings. Thus, roaming is not a issue for
an unmodified MIPv6 host.
Appendix C. Multihoming Issues in Multiple LMA Scenario
If there are multiple LMAs 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 December 19, 2008 [Page 31]
Internet-Draft Multiple Interfaces in NetLMM June 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 10: PMIPv6 domain with multiple LMAs
Figure 10 shows a scenario where MN is attached to a foreign PMIPv6
domain with multiple LMAs. 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
LMAs and the HA are shown in Figure 10. In this case, MN can enjoy
multioming benefits.
Jeyatharan, et al. Expires December 19, 2008 [Page 32]
Internet-Draft Multiple Interfaces in NetLMM June 2008
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
Jun Hirano
Matsushita Electric Industrial Co., Ltd. (Panasonic)
5-3 Hikarino-oka
Yokosuka, Kanagawa 239-0847
JP
Phone: +81 46 840 5123
Email: hirano.jun@jp.panasonic.com
Jeyatharan, et al. Expires December 19, 2008 [Page 33]
Internet-Draft Multiple Interfaces in NetLMM June 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jeyatharan, et al. Expires December 19, 2008 [Page 34]