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]