Internet DRAFT - draft-xue-netext-flowmo-multilma
draft-xue-netext-flowmo-multilma
NETEXT WG K. Xue
Internet-Draft D. Ni
Intended status: Standards Track P. Hong
Expires: December 22, 2013 USTC
H. Chan
Huawei
June 20, 2013
Flow Mobility In Multi-LMA Environment
draft-xue-netext-flowmo-multilma-02.txt
Abstract
PMIPv6 allows multiple Local Mobility Anchors(LMA) to exist in a
PMIPv6 domain, it MAY cause that different interfaces of a mobile
node(MN) are anchored in different LMAs. This document proposes the
extensions of Proxy Mobile IPv6 protocol to support flow mobility in
multi-LMA environment. Among all the scenarios discussed here, the
scenario in which different interfaces with different MAGs in multi-
LMA environment cannot use traditional ways to realize flow mobility
to an existing interface.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 22, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Xue, et al. Expires December 22, 2013 [Page 1]
Internet-Draft Multi-LMA flow mobility June 2013
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Conventions Used in This Document . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of PMIPv6-based Flow Mobility Extensions in Multi-
LMA Environment . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Different Interfaces with a Shared MAG . . . . . . . 5
3.2.2. Different Interfaces with Different MAGs . . . . . . 7
4. Select the Target Interface . . . . . . . . . . . . . . . . . 13
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Enhanced Flow Mobility Initiate(eFMI) . . . . . . . . . . 14
5.2. Enhanced Flow Mobility Acknowledge(eFMA) . . . . . . . . 15
6. Conceptual Data Structures . . . . . . . . . . . . . . . . . 16
6.1. Multiple Care-of Address Registration . . . . . . . . . . 16
6.2. Flow Mobility Cache . . . . . . . . . . . . . . . . . . . 16
6.3. Mobile Node's policy profile . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Xue, et al. Expires December 22, 2013 [Page 2]
Internet-Draft Multi-LMA flow mobility June 2013
Since single LMA environment MAY cause single point failure, multi-
LMA environment is proposed and some documents have discussed issues
in such environment. In [RFC 6463], runtime LMA assignment is
proposed for the purpose of load sharing in multi-LMA environment.
[I-D.draft-jeyatharan-netlmm-multi-interface-ps] also introduces the
scenario in which MN's multiple interfaces are attached to the same
MAG but anchored in different LMAs.
In the architecture of 3GPP, P-GW plays the role of LMA. There are
two real deployment examples in 3GPP architecture to support multi-
LMA environment. 1) In the flow based mobility scenarios, UE can use
local P-GW to carry new generated flow and home P-GW to carry former
flow simultaneously; 2)UE can use different P-GWs to access different
services.
Also in the discussion of distributed mobility management [I-D.draft-
bernardos-dmm-distributed-anchoring], with mobility different
sessions of a MN MAY be anchored in different D-MAG. This scenario
is similar to multi-LMA environment.
PMIPv6 allows a MN to access Internet services through different
interfaces in the same PMIPv6 domain, and it also allows multiple
LMAs to exist in the same domain. In such environment, MN's multiple
interfaces can be controlled by multiple LMAs. However, the existing
flow mobility technology [I-D.ietf-netext-pmipv6-flowmob] is not
complete, it is only applicable to the scenario with a single LMA.
This document specifies protocol extensions to enable flow mobility
on different physical interfaces in multi-LMA environment. This
document assumes that the mobile node(MN) implements the logical
interface model [I-D.ietf-netext-logical-interface-support], prefixes
of specific flows are transferred on different physical interfaces in
a loose way regardless of the assigned prefixes on these interfaces.
2. Conventions and Terminology
2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.2. Terminology
The following terms used in this document are defined in the Proxy
Mobile IPv6 [RFC 5213]:
Local Mobility Agent (LMA).
Xue, et al. Expires December 22, 2013 [Page 3]
Internet-Draft Multi-LMA flow mobility June 2013
Mobile Access Gateway (MAG).
Proxy Mobile IPv6 Domain (PMIPv6-Domain).
LMA Address (LMAA).
Proxy Care-of Address (Proxy-CoA).
Home Network Prefix (HNP).
The following terms used in this document are defined in the Multiple
Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile
IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]:
Binding Identification Number (BID).
Flow Identifier (FID).
Traffic Selector (TS).
The following terms are defined and used in this document:
eFMI (enhanced Flow Mobility Initiate). Message sent by the LMA to
the MAG, may be forwarded by another LMA managing this MAG, conveying
the information required to enable flow mobility in a PMIPv6-Domain.
eFMA (enhanced Flow Mobility Acknowledge). Message sent by the MAG
in reply to an eFMI message.
FMC(Flow Mobility Cache). Conceptual data structure maintained by
the LMA and the MAG to support the flow mobility management
operations described in this document.
3. Overview of PMIPv6-based Flow Mobility Extensions in Multi-LMA
Environment
3.1. Scenarios
In multi-LMA environment, we assume that traffic flows distributed on
different interfaces can be anchored in different LMAs. Each LMA
logically manages a different group of MAGs, however it is unaware of
the MAGs registered on other LMAs and the corresponding interfaces
attached. Thus, one LMA SHALL NOT communicate with the MAG under
another LMA without the help of this LMA. In this specification,
selected flows after flow mobility SHALL not change the anchored LMA
but MN's interfaces and corresponding MAGs SHOULD adjust accordingly.
Policy Profile SHOULD exist in a PMIPv6 domain implemented in AAA
server, which maintains addresses of all the LMAs in the same domain
Xue, et al. Expires December 22, 2013 [Page 4]
Internet-Draft Multi-LMA flow mobility June 2013
on a per-interface basis. This specification uses the default
behavior in basic PMIPv6[RFC5213], in which the MN obtains a prefix
or a new set of prefixes for the new session at the time of a new
interface attachment.
There are two different scenarios of flow mobility in multi-LMA
environment as the following:
(a) MN's different interfaces are attached to the same MAG, but the
flows through different interfaces are anchored in different LMAs.
(b)The different interfaces of MN are attached to different MAGs, and
anchored in different LMAs.
3.2. Basic Operation
3.2.1. Different Interfaces with a Shared MAG
It is corresponding to Scenario-(a). A MN can access Internet in a
PMIPv6 domain through different interfaces. The sessions of each
interface are anchored in a separate LMA, whereas all different
interfaces are attached to a single shared MAG. An example of this
scenario is showed in Figure 1, where a mobile node (MN) has two
different physical interfaces (if1 and if2), grouped in a logical one
(lif). Both interfaces are attached to the same MAG, and each of
them is anchored in a different LMA. These two interfaces are
assigned with different set of prefixes upon attachment to MAG.
There are 2 cases in this scenario.
Xue, et al. Expires December 22, 2013 [Page 5]
Internet-Draft Multi-LMA flow mobility June 2013
LMA1 Binding Cache
+----+ +----+ ====================
|LMA1| |LMA2| MN, if1, pref1, MAG
+----+ +----+
\\ //
+------\\----------//--------+ LMA2 Binding Cache
( \\ PMIPv6 // ) ====================
( \\domain// ) MN, if2, pref2, MAG
+---------\\----//-----------+
\\ //
\\//
+----+
| MAG|
+----+
| |
|-------| |------|
| +-------+ |
| | I P | |
| +-------+ |
| | lif | |
| +---+---+ |
|---|if1|if2|----|
+---+---+
MN
Figure 1: Different interfaces with single shared MAG and different
LMAs.
Figure 2 shows Case 1 of scenario-(a), in which both different
physical interfaces of the MN are initially both powered on. Flow
X(bound to pref1::/64) goes through if1-MAG-LMA1 and flow Y(bound to
pref2::/64) goes through if2-MAG-LMA2. At a certain time, MAG
detects the congestion of if2, and flow Y is decided to be moved to
if1. Flow Y can be moved just by updating the routing state at MAG
locally, binding pref2 with if1. No signaling exchange between LMA
and MAG is needed. The binding cache entry at LMA SHOULD not make
any change.
+-----+ +-----+ +------+ +-----+
Internet | LMA1| | LMA2| | MAG | | MN |
+-----+ +-----+ +------+ +-----+
| | | | |
| flow X to | flow X to | flow X to |
| pref1::lif | pref1::lif | pref1::lif |
|<----------->|<-------------------------->|<----------->if1
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif | pref2::lif |
|<------------------------->|<------------>|<----------->if2
| | | | |
| ========================================================
| || decision to move flow Y ||
| ========================================================
| | | | |
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif | pref2::lif |
|<------------------------->|<------------>|<----------->if1
| | | | |
Figure2: Flow mobility signaling process of Scenario-(a) when both
interfaces are powered on initially.(no signaling)
Case 2 of Scenario-(a) is showed in Figure 3, flow mobility happens
when a new interface if2 is just powered on. In this case, MAG
Xue, et al. Expires December 22, 2013 [Page 6]
Internet-Draft Multi-LMA flow mobility June 2013
detects L2 attachment of if2 and sends PBU to register in LMA2. LMA2
uses this request as a trigger to enable flow mobility. Flow Y is
bound to pref2::/64, and MAG updates routing state binding the
prefix2 with if2. This is done by including the related prefixes in
the PBU/PBA message.
+-----+ +-----+ +------+ +-----+
Internet | LMA1| | LMA2| | MAG | | MN |
+-----+ +-----+ +------+ +-----+
| | | | |
| flow X to | flow X to | flow X to |
| pref1::lif | pref1::lif | pref1::lif |
|<----------->|<-------------------------->|<----------->if1
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif | pref2::lif |
|<------------------------->|<------------>|<----------->if1
| | | | |
| | | | |
| | | MN powers on if2 and
| | | performs L2 attachment
| | | | |
| | | |<------------if2
| | | PBU | |
| | |<-------------| |
| | | PBA | |
| | |------------->| |
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif | pref2::lif |
|<------------------------->|<------------>|<----------->if2
| | | | |
Figure 3: Flow mobility signaling process of Scenario-(a) when a new
attachment occurs.(PBU/PBA message)
As the prefixes assigned to these sessions are only maintained in
LMA2, the anchor of flow Y MUST not change at all. Both in these two
cases, the path of flow Y between MAG and MN's interfaces is
changeable, meanwhile the tunnel used to transmit the packets of flow
Y between MAG and LMA2 is unaltered. And in both cases, only MAG is
REQUIRED to update routing state, no more signaling exchange between
LMA and MAG is needed. The binding cache entry at LMA SHOULD not
make any change unless a PBU requests it to.
3.2.2. Different Interfaces with Different MAGs
Xue, et al. Expires December 22, 2013 [Page 7]
Internet-Draft Multi-LMA flow mobility June 2013
It is corresponding to Scenario-(b). It happens when different
interfaces are attached to different MAGs and anchored in different
LMAs. Each MAG only has the location knowledge of the interfaces
attached to it, and each LMA only maintains the MAGs registered on
it. In this scenario, source LMA, in which the selected flow is
anchored, needs to send message to the target MAG beyond the charge
to inform flow mobility, thus the LMA in charge of the target MAG can
help forward the message sent by the source LMA. The communication
between LMAs MUST be with the help of Mobile Node's Policy Profile
existing in the PMIPv6 domain, which keeps the storage of Mobile
Node's Identifier and the addresses of the LMAs on a per-interface
basis, the mandatory fields of policy profile here SHOULD be extended
as following:
o The mobile node's identifier (MN-ID).It is unique for MN despite of
the different interfaces.
o The interface identifier (IF-ID). Under a MN-ID, it is unique for
each interface.
o The IPv6 address of the local mobility anchor(LMAA)
When source LMA enables flow mobility, it firstly checks whether MN's
other interfaces under the same LMA can take over these selected
flows. If not, flow mobility in multi-LMA environment is enabled.
Figure 4 shows an example of Scenario 2. MN is implemented with two
different physical interfaces (if1 and if2), grouped in a logical one
(lif).Each physical interface is attached to a different MAG and
anchored in a different LMA. Initially, flow X(bound to pref1::/64)
goes through path if1-MAG1-LMA1 and flow Y(bound to pref2::/64) goes
through path if2-MAG2-LMA2. At a certain time, flow Y needs to be
moved to the path if1-MAG1-LMA2. The anchor MUST not change after
flow mobility. A new tunnel SHOULD be established between LMA2 and
MAG1 to transmit packets of flow Y. But initially the LMA in one path
has no knowledge of the interface and corresponding MAG in another
path, and it needs the help of another LMA. To enable flow mobility,
LMA2 MUST send request to Policy Profile to search for LMA
information of a proper interface under the same MN-ID. LMA2 gets
the address of LMA1 and IF1-ID after REQ-ACK message exchanging with
policy profile.
Xue, et al. Expires December 22, 2013 [Page 8]
Internet-Draft Multi-LMA flow mobility June 2013
LMA1 Binding Cache
+----+ +----+ ====================
|LMA1| |LMA2| MN, if1, pref1, MAG1
+----+ +----+
|| || LMA2 Binding Cache
+----||--------------||----+ ====================
( || PMIPv6 || ) MN, if2, pref2, MAG2
( || domain || )
+----||--------------||----+
|| ||
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| +-------+ |
| | I P | |
| +-------+ |
| | lif | |
| +---+---+ |
|---|if1|if2|----|
+---+---+
MN
Figure4: Different interfaces with different MAGs and different LMAs.
Figure 5 gives the first possible signaling process. LMA2 sends eFMI
to LMA1, eFMI carries mobile node's identifier, interface identifier
and the Flow Identification Mobility option (specified in [RFC6089])
which can convey prefix or full flow information, and the type of
flow mobility operation (add flow). LMA1 picks the entry of Binding
Cache Entry(BCE), matching the MN-ID and IF-ID carried in the
request, and locates the corresponding MAG1. LMA1 simply forwards
eFMI to MAG1. MAG1 constructs the reply eFMA with all the options
that a PBU MUST contain, which is used for a new mobile access
gateway MAG1 to register in LMA2. Optionally, LMA2 sends FMI, which
is defined in[I-D.ietf-netext-pmipv6-flowmob], to remove the flow Y
state at MAG2. Otherwise, the flow state at MAG2 will be removed
upon timer expiration.
Xue, et al. Expires December 22, 2013 [Page 9]
Internet-Draft Multi-LMA flow mobility June 2013
+-----+ +-----+ +------+ +------+ +-----+
Internet | LMA1| | LMA2| | MAG1 | | MAG2 | | MN |
+-----+ +-----+ +------+ +------+ +-----+
| | | | | |
|flow X to | flow X to | flow X to |
|pref1::lif| pref1::lif | pref1::lif |
|<-------->|<---------------------->|<---------------------->if1
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif | pref2::lif|
|<--------------------->|<---------------------->|<--------->if2
| | | |
| ===========================================================
| || decision to move flow Y ||
| ===========================================================
| | | | | |
| |eFMI[MN1-ID,IF-ID,flow_info(Y),add] | |
| |<-----------| | | |
| | eFMI | | |
| |------------------------>| | |
| |eFMA[CoA1,ATT1,LL-ID...] | | |
| |<------------------------| | |
| | eFMA | | | |
| |----------->| | | |
| | | optional | |
| | | FMI[MN1-ID,flow_info(Y),lft=0 |
| | |----------------------->| |
| | | FMA | |
| | |------------------------| |
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif| pref2::lif |
|<--------------------->|<---------->|<-------------------->if1
| | | | | |
Figure5: Flow mobility signaling process 1 of Scenario-(b) when both
interfaces are powered on initially.(eFMI signaling)
Figure 6 gives the second possible signaling process. The LMA2 still
needs to acquire the address of LMA1 and sends eFMI to inform flow
mobility, however eFMA replied by MAG1 is sent to LMA2 straightly
without the help of LMA1. MAG1 SHOULD query for the address of LMA2
from policy profile before it sends back eFMA. Optionally, LMA2
sends FMI, which is defined in[I-D.ietf-netext-pmipv6-flowmob], to
remove the flow Y state at MAG2. Otherwise, the flow state at MAG2
will be removed upon timer expiration.
Xue, et al. Expires December 22, 2013 [Page 10]
Internet-Draft Multi-LMA flow mobility June 2013
+-----+ +-----+ +------+ +------+ +-----+
Internet | LMA1| | LMA2| | MAG1 | | MAG2 | | MN |
+-----+ +-----+ +------+ +------+ +-----+
| | | | | |
|flow X to | flow X to | flow X to |
|pref1::lif| pref1::lif | pref1::lif |
|<-------->|<---------------------->|<---------------------->if1
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif | pref2::lif|
|<--------------------->|<---------------------->|<--------->if2
| | | |
| ============================================================
| || decision to move flow Y ||
| =============================================================
| | | | | |
| | eFMI[MN1-ID,IF1-ID,flow_info(Y),add]| |
| |<-----------| | | |
| | eFMI | | |
| |----------------------->| | |
| | | eFMA[CoA1,ATT1,LL-ID...] |
| | |<----------| | |
| | | optional | |
| | | FMI[MN1-ID,flow_info(Y),lft=0] |
| | |----------------------->| |
| | | FMA | |
| | |<-----------------------| |
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif| pref2::lif |
|<--------------------->|<--------->|<---------------------->if1
| | | | | |
Figure6: Flow mobility signaling process 2 of Scenario-(b) when both
interfaces are powered on initially.(eFMI signaling)
Figure7 gives the third possible signaling process. After acquiring
the address of LMA1 and IF1-ID, LMA2 sends the request to LMA1, LMA1
picks the entry that matches the MN-ID and IF1-ID in the request and
locates MAG1. It replies with the address of MAG1 directly to LMA2.
Then LMA2 can communicate with MAG1 straightly, without the help of
LMA1. Optionally, LMA2 sends FMI, which is defined in[I-D.ietf-
netext-pmipv6-flowmob], to remove the flow Y state at MAG2.
Otherwise, the flow state at MAG2 will be removed upon timer
expiration.
Xue, et al. Expires December 22, 2013 [Page 11]
Internet-Draft Multi-LMA flow mobility June 2013
+-----+ +-----+ +------+ +------+ +-----+
Internet | LMA1| | LMA2| | MAG1 | | MAG2 | | MN |
+-----+ +-----+ +------+ +------+ +-----+
| | | | | |
|flow X to | flow X to | flow X to |
|pref1::lif| pref1::lif | pref1::lif |
|<-------->|<---------------------->|<---------------------->if1
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif | pref2::lif|
|<--------------------->|<---------------------->|<--------->if2
| | | |
| ============================================================
| || decision to move flow Y ||
| ============================================================
| | | | | |
| | eFMI[MN1-ID,IF1-ID] | | |
| |<-----------| | | |
| | eFMA[CoA1]| | | |
| |----------->| | | |
| | | eFMI[MN1-ID,IF1-ID,flow_info(Y),add]|
| | |---------->| | |
| | | eFMA[CoA1,ATT1,LL-ID...] |
| | |<----------| | |
| | | optional | |
| | | FMI[MN1-ID,flow_info(Y),lft=0] |
| | |----------------------->| |
| | | FMA | |
| | |<-----------------------| |
| flow Y to |flow Y to | flow Y to |
| pref2::lif |pref2::lif | pref2::lif |
|<--------------------->|<--------->|<---------------------->if1
| | | | | |
Figure7: Flow mobility signaling process 3 of Scenario-(b)when both
interfaces are powered on initially.(eFMI signaling)
There is another case in Scenario-(b) showed in Figure 8 when a new
interface if2 is powered on. Initially, Flow X goes through
if1-MAG1-LMA1 and flow Y goes through if1-MAG1-LMA2. When MAG2
detects the new attachment, it sends PBU to LMA2 to create a new
binding entry. Since LMA2 manages both MAG1 and MAG2 after the
registration, it becomes the case that already has been discussed in
[I-D.ietf-netext-pmipv6-flowmob].
Xue, et al. Expires December 22, 2013 [Page 12]
Internet-Draft Multi-LMA flow mobility June 2013
+-----+ +-----+ +------+ +------+ +-----+
Internet | LMA1| |LMA2 | | MAG1 | | MAG2 | | MN |
+-----+ +-----+ +------+ +------+ +-----+
| | | | | |
|flow X to | flow X to | flow X to |
|pref1::lif| pref1::lif | pref1::lif |
|<-------->|<---------------------->|<---------------------->if1
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif| pref2::lif |
|<--------------------->|<--------->|<---------------------->if1
| | | | | |
| | | | | |
| | | | MN powers on if2 and
| | | | performs L2 attachment
| | | | |<----------if2
| | | PBU | |
| | |<-----------------------| |
| | | PBA (pref2) | |
| | |----------------------->| |
| | LMA moves pref2 to new| | |
| |binding cache entry for if2 | |
| | | | | |
| | | | | |
| | | (optional)| | |
| | | BRI[pref2]| | |
| | |---------->| | |
| | | BRA | | |
| | |<----------| | |
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif | pref2::lif|
|<--------------------->|<---------------------->|<--------->if2
| | | | | |
Figure 8: Flow mobility signaling process of Scenario-(b)when a new
attachment occurs.(PBU signaling)
4. Select the Target Interface
When MN has more than 2 different interfaces, the policy profile can
selects an available target interface of the same MN for source LMA
according to some rules, here we propose two possible ways:
o Select an interface arbitrarily.
Policy profile selects the first interface of all the other available
interfaces under the same MN-ID as target interface. Source LMA
sends request to the target LMA controlling the selected interface,
the acknowledge contains the status of flow mobility. If the code
indicates failure, then source LMA SHOULD send request to policy
profile to ask for another interface and repeat the steps until find
a proper one.
o Select all the available interfaces as target ones.
Policy profile selects all the other available interfaces under the
same MN-ID as target interfaces. Source LMA sends request to each
target LMA managing each interface, asking for the load information.
The acknowledge MUST contains Load Information Mobility Options to
report the priority and key load information to source LMA. Then
source LMA orders all the available target interfaces and picks a
proper one.
5. Message Format
Xue, et al. Expires December 22, 2013 [Page 13]
Internet-Draft Multi-LMA flow mobility June 2013
5.1. Enhanced Flow Mobility Initiate(eFMI)
The LMA sends an eFMI message to a MAG to enable flow mobility. eFMI
is enhanced FMI, adding new bit M to indicate multi-LMA flow
mobility, and the options it carries are more. It is a Mobility
Header message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|M| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
A monotonically increasing integer. Set by the LMA sending then
initiate message, and used to match a reply in the acknowledge.
'I' (initiate) flag:
Set to 1, indicates it is an eFMI message.
'M' (multiple) flag:
Set to 1, indicates it is multi-LMA flow mobility.
Reserved:
This field is unused. MUST be set to zero by the sender.
Lifetime:
The requested time in seconds for which the LMA asks the MAG keep
flow-specific state. A value of all one bits (0xffff) represent
infinity. If set to 0, it indicates a request to remove state about
the flow (cancel flow mobility).
Xue, et al. Expires December 22, 2013 [Page 14]
Internet-Draft Multi-LMA flow mobility June 2013
Mobility Options:
MUST contain the MN-ID, IF-ID, followed by one or more Flow
Identification Mobility options [RFC6089].
5.2. Enhanced Flow Mobility Acknowledge(eFMA)
The MAG sends an eFMA message to the LMA as a response to the eFMI
message. eFMA is enhanced FMI, adding new bit M to indicate multi-LMA
flow mobility, the status and options are more. It is a Mobility
Header message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|M| Reserved | Status | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
A monotonically increasing integer. Set by the LMA sending then
initiate message, and used to match a reply in the acknowledge.
'I' (initiate) flag:
Set to 0, indicates it is an eFMA message.
'M' (multiple) flag:
Set to 1, indicates it is multi-LMA flow mobility.
Reserved:
This field is unused. MUST be set to zero by the sender.
Status(values to be assigned by IANA):
Xue, et al. Expires December 22, 2013 [Page 15]
Internet-Draft Multi-LMA flow mobility June 2013
Despite of the already defined values in eFMI, the new values defined
in multi-LMA environment are as following:
??: Target LMA not support flow mobility
??: No existing MAG
??: No existing interface
Lifetime:
The requested time in seconds for which the MAG keeps flow-specific
state. A value of all one bits (0xffff) represents infinity.
Mobility Options:
When Status code is 0, MUST contain the MN-ID, followed by one or
more Flow Identification Mobility options [RFC6089], and MUST include
other regular options in a normal PBU.
6. Conceptual Data Structures
6.1. Multiple Care-of Address Registration
The LMA is extended to allow a mobile node to register multiple proxy
care of address (Proxy-CoA). The LMA maintains multiple binding
cache entries for an MN. The number of binding cache entries for an
MN is equal to the number of the MN's interfaces attaching to any
MAGs.
+---------+-----+-------+------+-----------+------------+
| BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA |
+---------+-----+-------+------+-----------+------------+
| 20 | 1 | MN | WiFi | HNP1,HNP2 | IP1 (MAG1) |
| 30 | 2 | MN | 3GPP | HNP1,HNP3 | IP2 (MAG2) |
+---------+-----+-------+------+-----------+------------+
Figure 9: Extended Binding Cache
Figure 9 shows two Binding Cache Entries of the MN when it is
attached to the network using two different access technologies.
Both of the two attachments share HNP1 and are bounded to two
different Proxy-CoAs.
6.2. Flow Mobility Cache
Xue, et al. Expires December 22, 2013 [Page 16]
Internet-Draft Multi-LMA flow mobility June 2013
Each LMA MUST maintain a flow mobility cache (FMC) as shown in Figure
10. This table MUST contain an entry for each flow sent from the MN.
A flow binding entry includes the following fields:
o Flow Identifier Priority (FID-PRI).
o Flow Identifier (FID).
o Traffic Selector (TS).
o Binding Identifier (BID).
o Action.
o Active/Inactive.
+---------+-----+-----+------+---------+----------+
| FID-PRI | FID | TS | BIDs | Action | A/I |
+---------+-----+-----+------+---------+----------+
| 10 | 2 | TCP | 1 | Forward | Active |
| 20 | 4 | UDP | 1,2 | Forward | Inactive |
+---------+-----+-----+------+---------+----------+
Figure 10: Flow Mobility Cache
The BID field contains the identifier of the binding cache entry
which packets matching the flow information described in the TS field
will be forwarded to. When a flow is decided to be moved, the
affected BID(s) of the table are updated.
Similar to flow binding described in [RFC6089], each flow binding
entry points to a specific binding cache entry identifier (BID).
When a flow is moved, the LMA simply updates the pointer of the flow
binding entry with the BID of the interface to which the flow will be
moved. The traffic selector (TS) in flow binding table is defined as
in [RFC6088]. TS is used to classify the packets of flows basing on
specific parameters such as service type, source and destination
address, etc. The packets matching with the same TS will be applied
the same forwarding policy. FID-PRI is the order of precedence to
take action on the traffic. Action may be forward or drop. If a
binding entry becomes 'Inactive' it does not affect data traffic. An
entry becomes 'Inactive' only if all of the BIDs are deregistered.
The Mobile Access Gateway MAY also maintain a similar data structure.
In case no full flow mobility state is required at the MAG, the
Binding Update List (BUL) data structure is enough and no extra
Xue, et al. Expires December 22, 2013 [Page 17]
Internet-Draft Multi-LMA flow mobility June 2013
conceptual data entries are needed. In case full per-flow state is
required at the MAG, it SHOULD also maintain a Flow Mobility Cache
structure.
6.3. Mobile Node's policy profile
There is Mobile Node's policy profile in a PMIPv6-Domain, MAY be
implemented in AAA server. The mandatory fields of it SHOULD be
extended as following:
o The mobile node's identifier (MN-ID).It is unique for MN despite of
the different interfaces.
o The interface identifier (IF-ID). Under a MN-ID, it is unique for
each interface.
o The IPv6 address of the local mobility anchor(LMAA).
7. Security Considerations
Security threats for flow mobility management in multi-LMA
environment comprise the danger of unauthorized signallings launched
by a malicious node. Signaling messages of this protocol between
LMAs, or between MAG and LMA MUST be authenticated by means of IPsec
[RFC4301].
Protection of signaling messages between LMAs uses the mechanisms of
Encapsulating Security Payload (ESP) [RFC4301] in transport mode with
mandatory data origin authentication by means of a non-null payload
authentication algorithm. The use of encryption is optional. A
tunnel needs to be set up between MAG and LMA in Figure 4, which can
follow the process in PMIPv6[RFC5213].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC
5846, June 2010.
Xue, et al. Expires December 22, 2013 [Page 18]
Internet-Draft Multi-LMA flow mobility June 2013
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088, January
2011.
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089, January
2011.
[RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
"Runtime Local Mobility Anchor (LMA) Assignment Support
for Proxy Mobile IPv6", RFC 6463, February 2012.
8.2. Informative References
[I-D.bernardos-dmm-distributed-anchoring]
Bernardos, C. and J. Zuniga, "PMIPv6-based distributed
anchoring", draft-bernardos-dmm-distributed-anchoring-02
(work in progress), April 2013.
[I-D.ietf-netext-logical-interface-support]
Melia, T. and S. Gundavelli, "Logical Interface Support
for multi-mode IP Hosts", draft-ietf-netext-logical-
interface-support-07 (work in progress), April 2013.
[I-D.ietf-netext-pmipv6-flowmob]
Bernardos, C., "Proxy Mobile IPv6 Extensions to Support
Flow Mobility", draft-ietf-netext-pmipv6-flowmob-06 (work
in progress), February 2013.
[I-D.jeyatharan-netlmm-multi-interface-ps]
Jeyatharan, M., Ng, C., Devarapalli, V., and J. Hirano,
"Multiple Interfaced Mobile Nodes in NetLMM", draft-
jeyatharan-netlmm-multi-interface-ps-03 (work in
progress), October 2008.
Authors' Addresses
Kaiping Xue
USTC
Room 305, EEIS Department, USTC West Campus
Shushan District , Hefei 230027
P. R. China
Phone: +86-551-3601334
Email: kpxue@ustc.edu.cn
Xue, et al. Expires December 22, 2013 [Page 19]
Internet-Draft Multi-LMA flow mobility June 2013
Dan Ni
USTC
Room 305, EEIS Department, USTC West Campus
Shushan District , Hefei 230027
P. R. China
Phone: +86-551-3601334
Email: nidan@mail.ustc.edu.cn
Peilin Hong
USTC
Room 305, EEIS Department, USTC West Campus
Shushan District , Hefei 230027
P. R. China
Phone: +86-551-3601334
Email: plhong@ustc.edu.cn
H Anthony Chan
Huawei
5340 Legacy Dr. Building 3
Plano , TX 75024
USA
Email: h.a.chan@ieee.org
Xue, et al. Expires December 22, 2013 [Page 20]
