One document matched: draft-jeyatharan-netlmm-multi-interface-ps-01.txt
Differences from draft-jeyatharan-netlmm-multi-interface-ps-00.txt
NetLMM Working Group M. Jeyatharan
Internet-Draft C. Ng
Expires: July 4, 2008 J. Hirano
Panasonic
January 2008
Multiple Interfaced Mobile Nodes in NetLMM
draft-jeyatharan-netlmm-multi-interface-ps-01
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 July 4, 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 different unique prefix is given
to each interface of a Mobile Node that is attached to the PMIPv6
domain. However, multihoming can also be provided using single
prefix for all interfaces of MN. This memo explores and highlights
some issues associated with multihoming support in PMIPv6: using
single prefix per MN method or multiple prefixes per MN method.
Jeyatharan, et al. Expires July 4, 2008 [Page 1]
Internet-Draft Multiple Interfaces in NetLMM January 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Multiple Interfaces Support Models in PMIPv6 . . . . . . . . . 4
3. Multiple Interface Problem Analysis for Single Prefix Model . 6
3.1. Problem Analysis for Simultaneous Attachment . . . . . . . 6
3.2. Problem Analysis for Hand-off Scenarios . . . . . . . . . 9
3.3. Problem Analysis for Setting Filter Rule . . . . . . . . . 10
4. Multiple Interface Problem Analysis for Multi Prefix Model . . 11
4.1. Problem Analysis for Simultaneous Attachment . . . . . . . 11
4.2. Problem Analysis for Horizontal Hand-off . . . . . . . . . 12
4.3. Problem Analysis for Vertical Hand-off . . . . . . . . . . 13
5. Problem Analysis for Multiple Care-of address (MCoA)
binding in PMIPv6 . . . . . . . . . . . . . . . . . . . . . . 14
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17
9.2. Informative Reference . . . . . . . . . . . . . . . . . . 17
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. Multihoming Issues in PMIPv6 Single LMA Roaming
Scenario . . . . . . . . . . . . . . . . . . . . . . 19
Appendix C. Multihoming Issues in Multiple LMA Scenario . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Jeyatharan, et al. Expires July 4, 2008 [Page 2]
Internet-Draft Multiple Interfaces in NetLMM January 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 per
each interface of MN. The base draft adopted such a multiple prefix
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 prefix for all interfaces and one need not restrict to unique
prefix per interface type of allocation.
In this memo, the main focus is to analyze and highlight multiple
interface related issues in single prefix model and multiple prefix
model so that one can understand the problems and appropriate
solutions can be seeked to tackle the problems. The analysis is
broken into clusters where issues related to simultaneous attachment
via all MN's interfaces, vertical hand-off (switching from one
interface to another), horizontal hand-off and filter rule setting to
attain the objective of preferred path selection by MN are looked
into in detail. In addition to these, how to support multihoming for
unmodified MN in a single prefix model and how multihoming can be
supported when MN configures multiple care-of addresses for a certain
interface is also explored.
Many Standard Organizations (SDO) such as third generation partner
ship project (3GPP), third generation partner ship project 2 (3GPP2)
and Wimax Forum are very much interested in adapting 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
architecture. Nevertheless, we would not exclude such problem
analysis for other SDO architectures that will adapt the PMIPv6
protocol for multihoming purposes.
In Appendix B and Appendix C, the multihoming problem analysis is
focused on advanced scenarios such as roaming and a scenario that has
multiple local mobility anchors (LMAs). Roaming scenarios in this
memo refers to MN moving away from home domain into foreign domains.
In such roaming scenarios, the need for further work is highlighted
for MNs that have some mobility management functionality. It can be
easily understood that such roaming scenarios is not applicable to
IPv6 nodes that do not have any Client MIPv6 stack implemented.
Jeyatharan, et al. Expires July 4, 2008 [Page 3]
Internet-Draft Multiple Interfaces in NetLMM January 2008
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. Such benefits
have been described elsewhere, such as in [2], and are thus omitted
from this document. It should be noted that some benefits could be
enjoyed by the PMIPv6 domain 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.
There are two main ways multiple interfaces support can be provided
by the PMIPv6 domain. The first way is to offer the MN different
home network prefixes for each of MN's interfaces as described in
[1]. The second way is to offer the MN the same home network prefix
for all its interfaces. In this section, a brief analysis and
principle of these models are given. Further analysis and associated
problems with these multihoming models are given in later sections.
o Different Home Network Prefix for Each Interface
In this case, each interface of MN is allocated an unique Home
Network Prefix. To ensure that each interface of MN gets an
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 MAG and connecting via 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 flags 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.
Since unique prefix is assigned per interface of MN, for practical
Jeyatharan, et al. Expires July 4, 2008 [Page 4]
Internet-Draft Multiple Interfaces in NetLMM January 2008
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. If MN is an IPv6 host using
SHIM6 (Site Multihoming by IPv6 Intermediation) [3] or SCTP
(Stream Control Transport Protocol) [4] or MONAMI6 capable mobile
node [5], then the MN can continue to enjoy multihoming 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 such as SHIM6 or MONAMI6 may
need to be used to achieve multihoming benefits.
Another general issue with this 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.
o Same Home Network Prefix for All Interfaces
In this case, each interface will receive the same Home Network
Prefix. In this scenario, MN SHOULD accept packets 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 single prefix is used for all
interfaces, then all interfaces may configure same address and
thus flows can be routed to MN via all available paths without
introducing any changes to PMIPv6 network entities. However, even
if same address is configured for all interfaces, to attain some
advanced multihoming benefits such as setting flow preference,
some changes to the PMIPv6 network has to be made.
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 some benefits of multihoming. All
MN has to do is to configure each interface with an IP address
from the same prefix. At the LMA, since prefix based routing is
used rather than address based routing, any flow destine for MN
can be routed to MN via any interface. However, we will explain
further in next section that further work is required even in the
case of single prefix model to achieve all the benefits of
multihoming. The main advantage of this model is that complex
prefix allocation mechanism at LMA can be avoided and prefix
resources are not wasted.
Jeyatharan, et al. Expires July 4, 2008 [Page 5]
Internet-Draft Multiple Interfaces in NetLMM January 2008
3. Multiple Interface Problem Analysis for Single Prefix Model
In this section, problem analysis for multihomed nodes when PMIPv6
uses a single prefix per MN model is presented. The assumption in
the analysis regarding to which PMIPv6 entity is mapped to which
entity in 3GPP architecture is based on details provided in documents
such as [6] and [7].
3.1. Problem Analysis for Simultaneous Attachment
+-------------+-----------+--------+-------+
| Home Prefix | CoA | MN-ID | If-ID |
+---------------+ +-------------+-----------+--------+-------+
|LMA/HA/(PDN-GW)| | MN.Prefix | MAG1.Addr | NAI |If1-ID |
+---------------+ | MN.Prefix | 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
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) interface
and MN.If2 is a third generation cellular (3G) interface. It is
further assumed that PMIPv6 protocol is deployed in 3GPP network
where MN.If1 is attached to the evolved packet data network gateway
(ePDG) via a IPSec tunnel and MN.If2 is attached to Serving Gateway
(SGW)/MAG2 which is its first hop router. It is considered that the
ePDG/MAG1 is not the first hop router for MN.If1. In this scenario,
the ePDG is assumed to have the Mobility Access Gateway (MAG)
Jeyatharan, et al. Expires July 4, 2008 [Page 6]
Internet-Draft Multiple Interfaces in NetLMM January 2008
functionality and it acts as a trusted gateway to 3GPP core network.
More information on 3GPP architectural entities and their roles can
be obtained from 3GPP technical specifications [6] and [7].
If such single prefix type of multihoming is supported, then there
needs to be some parameter in the LMA/HA cache to differentiate the
bindings from same MN. This parameter can be the interface ID
(If-ID) or Binding Identifiers (BID) as described in [5]. It is
important to appreciate that in the single prefix 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. 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. This corresponds to the first entry
in the binding cache (BC). When MN powers up MN.If2, 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 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 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
Jeyatharan, et al. Expires July 4, 2008 [Page 7]
Internet-Draft Multiple Interfaces in NetLMM January 2008
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. Furthermore, it is
easier for the MN to provide the initial attachment information to
the network rather than the network identifying this.
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 3 to mitigate this issue. To solve
the issue of flow switch at LMA/HA due to LMA/HA implementing prefix
based routing and MN configuring different addresses for its
interfaces, further work may be required. One possible solution to
this flow switch issue is that the LMA/HA cache can be address based
rather than prefix based. But, in such a case, the PBU registration
has to wait until the MN finishes address configuration which causes
some delay in routing state establishment at LMA/HA.
Jeyatharan, et al. Expires July 4, 2008 [Page 8]
Internet-Draft Multiple Interfaces in NetLMM January 2008
3.2. Problem Analysis for Hand-off Scenarios
Hand-offs are generally classified as horizontal hand-off and
vertical hand-off. In a multiple interface scenario using the single
prefix model, when one of the interface roams 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 hand-off 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 this 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.
For the 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). 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 performed the PBU at LMA/HA. The important point here
is that, MAG2 can readily send the PBU once it knows If2-ID. Unlike
in the multiple prefix model, MAG2 need not get information about If1
at all. Thus, we predict that v.hand-off establishment delay will be
less in the single prefix model. The only problem is that the
address of MN.If2 may be different from address of MN.If1 and MAG2
may discard these packets coming to address of 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 trading off on the quality of
service for flows destined to address of MN.If1. 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. Again, we
like to highlight that the appropriate solution to this issue needs
to be explored.
Jeyatharan, et al. Expires July 4, 2008 [Page 9]
Internet-Draft Multiple Interfaces in NetLMM January 2008
3.3. Problem Analysis for Setting Filter Rule
+---------------------+
| HA/LMA/Home PDN-GW | Flow1: MN.If1 CoA
+---------------------+ Flow2: MN.If2 CoA
|
|
+----------------------------+
| Foreign LMA/Foreign PDN-GW |
+----------------------------+
| BCE at Foreign LMA
+-----------------------+ +-------------+-----------+--------+-------+
| | |Home Prefix | CoA | MN-ID | If-ID |
|Proxy MIPv6 Domain | +------------------------------------------+
| | |MN.LMA Prefix| MAG1.Addr | NAI |If1-ID |
+-----------------------+ |MN.LMA Prefix| 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 and the
LMAs have multihoming functionality. One of the advantages of
multihoming is that flow preference can be set by MN at the
correspondent node (CN) or at the home agent (HA). In Figure 2 we
assume that MN has some functionality such that it can set filter
rules. How to set filters at the above said entities is out of scope
of this memo. Filter rules are generally set by using flow
identifier options (FID) in binding update (BU) message and details
of this mechanism can be found in [8]. 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 (PDN-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 PDN-GW implementing prefix based routing,
flow1 can be routed wrongly and may arrive via the cellular MAG.
Jeyatharan, et al. Expires July 4, 2008 [Page 10]
Internet-Draft Multiple Interfaces in NetLMM January 2008
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
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 Multi 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/(PDN-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. MN has two interfaces and 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
Jeyatharan, et al. Expires July 4, 2008 [Page 11]
Internet-Draft Multiple Interfaces in NetLMM January 2008
attaches to PMIPv6 network, the second BC entry is created. This
multiple prefix model does not create any confusion to an unmodified
IPv6 host that does simultaneous attachment and thus we will not
highlight this point any further as it has been discussed extensively
in the NetLMM mailing list. 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 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 hand-off for If2
| MN |
+-------------+
Figure 4: Horizontal handoff in Multiple Prefix Model
In Figure 4, it is assumed that MN has two interfaces. MN here 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 [6] and [7]. It is
further considered that MN while still connected to 3G network via
MN.If1, will perform a horizontal hand-off for MN.If2. Basically,
MN.If2 will detach from MAG2 and attach at a new MAG3. In such a
Jeyatharan, et al. Expires July 4, 2008 [Page 12]
Internet-Draft Multiple Interfaces in NetLMM January 2008
scenario, the important thing is that the If-ID information in the
PBU sent from MAG3 has to have If2-ID. As discussed previously,
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 hand-off state of MN, then it may
set the hand-off flag to "4" in the access technology option saying
that the hand-off 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 point we
want to highlight 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.
4.3. Problem Analysis for Vertical Hand-off
+-------------------------------------------+
| |
| Proxy Mobile IPv6 Domain |
| |
+-------------------------------------------+
| | |
| MAG1.Addr | MAG2.Addr | MAG3.Addr
+---------+ +-----------+ +----------+
| 3G/MAG1 | | WLAN/MAG2 | | WLAN/MAG3|
+---------+ +-----------+ +----------+
\ / -------/
If1(P1) \ /If2(P2) / If3(P2)
+-------------+/Vertical hand-off for If2
| MN |
+-------------+
Figure 5: Vertical handoff in Multi 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. What is desired by vertical
hand-off 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 hand-off
request information and assign the desired prefix P2 in the above
Jeyatharan, et al. Expires July 4, 2008 [Page 13]
Internet-Draft Multiple Interfaces in NetLMM January 2008
scenario, the PBU sent by MAG3 MUST have If2-ID in addition to
If3-ID. Moreover, as mentioned in [1], the hand-off flag in the
access technology type option should specify that this is a vertical
hand-off. Thus one can clearly see the complexity involved in
getting the correct prefix for vertical hand-off in the multi 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 hand-off flag pointing to "2" (vertical hand-off), it will
assign P2 to MN.If3. This is because LMA have no difficulty in
identifying P2 cache since there are no other entries associated with
MN. Thus, one can appreciate that the vertical hand-off complexity
is high when MN has more than two 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. 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 hand-off is performed
between heterogeneous access network types, context transfer via
heterogeneous networks may take some time and other fast mechansims
may need to taken into consideration to prevent vertical hand-off
establishment delay.
5. Problem Analysis for Multiple Care-of address (MCoA) binding in
PMIPv6
In this section multihoming is analyzed from the perspective of
multiple care-of addresses configured for certain interface of MN.
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 prefix per MN model.
Jeyatharan, et al. Expires July 4, 2008 [Page 14]
Internet-Draft Multiple Interfaces in NetLMM January 2008
+-------------+-----------+--------+-------+-----+
| Prefix/Addr | CoA | MN-ID | If-ID | Flag|
+-------------++-------------+-----------+--------+-------+-----+
|HA/LMA/PDN-GW|| MN.Prefix | MAG1.Addr | MN.NAI |If1-ID | - |
| || MN.Prefix | MAG2.Addr | MN.NAI |If2-ID | - |
+-------------+| MN.HoA | home2 | MN.NAI |BID1 | "H" |
| | MN.HoA | CoA.AR | MN.NAI |BID2 | - |
| +-------------+-----------+--------+-------+-----+
| BCEs at LMA/HA
+--------------------------+
| |
| Proxy Mobile IPv6 Domain |
| |
+--------------------------+
| |
MAG1.Addr| |MAG2.Addr
+---------+ +-----------+
| 3G/MAG1 | | ePDG/MAG2 |
+---------+ +-----------+
| |
If1 | +--------------------------+
| | Non-Trusted WLAN Access |
| +--------------------------+
| |
| +--------+
| | AP/AR |
| +--------+
| |
\ /If2
+-----------+
| MN |
+-----------+
Figure 6: Multihomed MN processing multiple addresses when PMIPv6 is
deployed in 3GPP
Suppose PMIPv6 protocol is deployed in 3GPP, there are many prefixes
a particular interface of MN can receive. It 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 [5] 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. Furthermore, it is assumed that MN has a single home
address. In Figure 6, it is considered that MN.If1 is attached to 3G
Jeyatharan, et al. Expires July 4, 2008 [Page 15]
Internet-Draft Multiple Interfaces in NetLMM January 2008
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. It is further considered that MN.If2 is
connected to PMIPv6/3GPP network via a Non-Trusted WLAN access
network. MN.If2 is directly attached to AR/AP. When MN.If2 makes a
successful IPSec tunnel to ePDG, the second entry in the binding
cache will be created. Again, the If2-ID needs to be different from
If1-ID. Before establishing a tunnel to ePDG, MN.If2 will get a
nomadic address in the Non-trusted WLAN access network and this
nomadic address prefix will be directly associated with AR's prefix.
However, MN may not know that MN.If2 is attached to PMIPv6 network.
If MN knows that this is PMIPv6 network, then it may act differently.
MN not knowing that this is PMIPv6 network, may configure another
address from the home prefix (home2) for MN.If2 to get reachability
or to set filter rules at LMA/HA. MN may want to register these
addresses (nomadic address/on-link CoA, home2) at LMA/HA. When MN
does Multiple CoA binding at LMA/HA for home2 and on-link CoA, then
these CMIPv6 registrations are 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, 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.
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. 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
multiple care-of address processing by a single interface. Finally,
we would like to conclude that multihoming can be provided by either
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
Jeyatharan, et al. Expires July 4, 2008 [Page 16]
Internet-Draft Multiple Interfaces in NetLMM January 2008
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
9.1. Normative Reference
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10
(work in progress), February 2008.
9.2. Informative Reference
[2] Ernst, T., "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-02 (work in
progress), July 2007.
[3] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim
Protocol for IPv6", draft-ietf-shim6-proto-10 (work in
progress), February 2008.
[4] 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.
[5] Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-05 (work in progress),
January 2008.
[6] "3GPP system architecture evolution (SAE)", 3GPP TR 23.882,
Jeyatharan, et al. Expires July 4, 2008 [Page 17]
Internet-Draft Multiple Interfaces in NetLMM January 2008
January 2008.
[7] "Technical Specification Group Services and System aspects",
3GPP TR 23.402, December 2007.
[8] 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.
Appendix A. Change Log
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 July 4, 2008 [Page 18]
Internet-Draft Multiple Interfaces in NetLMM January 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 7: 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 7, 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 7, 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 July 4, 2008 [Page 19]
Internet-Draft Multiple Interfaces in NetLMM January 2008
If multiple prefix model is active in the scenario shown in Figure 7,
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 July 4, 2008 [Page 20]
Internet-Draft Multiple Interfaces in NetLMM January 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 8: PMIPv6 domain with multiple LMAs
Figure 8 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 8. In this case, MN can enjoy
multioming benefits.
Jeyatharan, et al. Expires July 4, 2008 [Page 21]
Internet-Draft Multiple Interfaces in NetLMM January 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 July 4, 2008 [Page 22]
Internet-Draft Multiple Interfaces in NetLMM January 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 July 4, 2008 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-23 20:36:08 |