NETEXT Working Group                                  CJ. Bernardos, Ed.
Internet-Draft                                                      UC3M
Intended status: Standards Track                           July 23, 2014
Expires: January 24, 2015


         Proxy Mobile IPv6 Extensions to Support Flow Mobility
                  draft-ietf-netext-pmipv6-flowmob-11

Abstract

   Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy
   Mobile IPv6 domain through different interfaces.  This document
   describes extensions to the Proxy Mobile IPv6 protocol that are
   required to support network based flow mobility over multiple
   physical interfaces.

   The extensions described in this document consist on the operations
   performed by the local mobility anchor and the mobile access gateway
   to manage the prefixes assigned to the different interfaces of the
   mobile node, as well as how the forwarding policies are handled by
   the network to ensure consistent flow mobility management.

Requirements Language

   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 RFC 2119 [RFC2119].

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 January 24, 2015.






Bernardos               Expires January 24, 2015                [Page 1]


Internet-Draft            PMIPv6 flow mobility                 July 2014


Copyright Notice

   Copyright (c) 2014 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
   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of the PMIPv6 flow mobility
       extensions  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Use case scenarios  . . . . . . . . . . . . . . . . . . .   4
     3.2.  Basic Operation . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  MN sharing a common
               set of prefixes on all MAGs . . . . . . . . . . . . .   5
       3.2.2.  MN with different
               sets of prefixes on each MAG  . . . . . . . . . . . .   9
   4.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .  13
     4.1.  Home Network Prefix . . . . . . . . . . . . . . . . . . .  14
     4.2.  Flow Mobility Initiate (FMI)  . . . . . . . . . . . . . .  14
     4.3.  Flow Mobility Acknowledgement (FMA) . . . . . . . . . . .  15
   5.  Conceptual Data Structures  . . . . . . . . . . . . . . . . .  16
     5.1.  Multiple Proxy Care-of Address Registration . . . . . . .  16
     5.2.  Flow Mobility Cache . . . . . . . . . . . . . . . . . . .  17
   6.  Mobile Node considerations  . . . . . . . . . . . . . . . . .  18
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   9.  Authors . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     11.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21








Bernardos               Expires January 24, 2015                [Page 2]


Internet-Draft            PMIPv6 flow mobility                 July 2014


1.  Introduction

   Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network
   based mobility management to hosts connecting to a PMIPv6 domain.
   PMIPv6 introduces two new functional entities, the Local Mobility
   Anchor (LMA) and the Mobile Access Gateway (MAG).  The MAG is the
   entity detecting Mobile Node's (MN) attachment and providing IP
   connectivity.  The LMA is the entity assigning one or more Home
   Network Prefixes (HNPs) to the MN and is the topological anchor for
   all traffic belonging to the MN.

   PMIPv6 allows a mobile node to connect to the same PMIPv6 domain
   through different interfaces.  This document specifies protocol
   extensions to Proxy Mobile IPv6 between the local mobility anchor and
   mobile access gateways to enable "flow mobility" and hence distribute
   specific traffic flows on different physical interfaces.  It is
   assumed that the mobile node IP layer interface can simultaneously
   and/or sequentially attach to multiple MAGs, possibly over multiple
   media.  One form to achieve this multiple attachment is described in
   [I-D.ietf-netext-logical-interface-support], which allows the mobile
   node supporting traffic flows on different physical interfaces
   regardless of the assigned prefixes on those physical interfaces.

   In particular, this document specifies how to enable "flow mobility"
   in the PMIPv6 network (i.e., local mobility anchors and mobile access
   gateways).  In order to do so, two main operations are required: i)
   proper prefix management by the PMIPv6 network, ii) consistent flow
   forwarding policies.  This memo analyzes different potential use case
   scenarios, involving different prefix assignment requirements, and
   therefore different PMIPv6 network extensions to enable "flow
   mobility".

2.  Terminology

   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 [RFC2119].

   The following terms used in this document are defined in the Proxy
   Mobile IPv6 [RFC5213]:

      Local Mobility Agent (LMA).

      Mobile Access Gateway (MAG).

      Proxy Mobile IPv6 Domain (PMIPv6-Domain).

      LMA Address (LMAA).



Bernardos               Expires January 24, 2015                [Page 3]


Internet-Draft            PMIPv6 flow mobility                 July 2014


      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:

   FMI (Flow Mobility Initiate).  Message sent by the LMA to the MAG
      conveying the information required to enable flow mobility in a
      PMIPv6-Domain.  This message is only needed when the prefixes
      initially assigned by the different MAGs to the mobile node are
      different.

   FMA (Flow Mobility Acknowledgement).  Message sent by the MAG in
      reply to an FMI 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 the PMIPv6 flow mobility extensions

3.1.  Use case scenarios

   In contrast to a typical handover where connectivity to a physical
   medium is relinquished and then re-established, flow mobility assumes
   a mobile node can have simultaneous access to more than one network.
   In this specification, it is assumed that the local mobility anchor
   is aware of the mobile node's capabilities to have simultaneous
   access to both access networks and it can handle the same or a
   different set of prefixes on each access.  How this is done is
   outside the scope of this specification.

   There are different flow mobility scenarios.  In some of them the
   mobile node might share a common set of prefixes among all its
   physical interfaces, whereas in others the mobile node might have a
   different subset of prefixes configured on each of the physical
   interfaces.  The different scenarios are the following:




Bernardos               Expires January 24, 2015                [Page 4]


Internet-Draft            PMIPv6 flow mobility                 July 2014


   1.  At the time of a new network attachment, the MN obtains the same
       prefix or the same set of prefixes as already assigned to an
       existing session.  This is not the default behavior with basic
       PMIPv6 [RFC5213], and the LMA needs to be able to provide the
       same assignment even for the simultaneous attachment (as opposed
       to the handover scenario only).

   2.  At the time of a new network attachment, the MN obtains a new
       prefix or a new set of prefixes for the new session.  This is the
       default behavior with basic PMIPv6 [RFC5213].

   A combination of the two above-mentioned scenarios is also possible.
   At the time of a new network attachment, the MN obtains a combination
   of prefix(es) in use and new prefix(es).  This is a hybrid of the two
   scenarios described before.  The local policy determines whether the
   new prefix is exclusive to the new attachment or it can be assigned
   to an existing attachment as well.

   The operational description of how to enable flow mobility in each of
   these scenarios is provided in Section 3.2.1 and Section 3.2.2.

   The extensions described in this document support all the
   aforementioned scenarios.

3.2.  Basic Operation

   This section describes how the PMIPv6 extensions described in this
   document enable flow mobility support.

   Both the mobile node and the local mobility anchor MUST have local
   policies in place to ensure that packets are forwarded coherently for
   unidirectional and bidirectional communications.  The details about
   how this consistency is ensured are out of the scope of this
   document.  The MN makes the final IP flow mobility decision, and then
   the LMA follows that decision and update its forwarding state
   accordingly.  Note that this does not prevent network initiated
   mobility, the network still could trigger mobility on the MN side via
   out-of-band mechanisms (e.g., 3GPP/ANDSF sends updated routing
   policies to the MN).  In a given scenario and mobile node, the
   decision on IP flow mobility MUST be taken either by the MN or the
   LMA, but not by both.

3.2.1.  MN sharing a common set of prefixes on all MAGs

   This scenario corresponds to the first use case scenario described in
   Section 3.1.  Extensions to basic PMIPv6 [RFC5213] signaling at the
   time of a new attachment are needed to ensure that the same prefix
   (or set of prefixes) is assigned to all the interfaces of the same



Bernardos               Expires January 24, 2015                [Page 5]


Internet-Draft            PMIPv6 flow mobility                 July 2014


   mobile node that are simultaneously attached.  Subsequently, no
   further signaling is necessary between the local mobility anchor and
   the mobile access gateway and flows are forwarded according to policy
   rules on the local mobility anchor and the mobile node.

   If the local mobility anchor assigns a common prefix (or set of
   prefixes) to the different physical interfaces attached to the
   domain, then every MAG already has all the routing knowledge required
   to forward uplink or downlink packets, and the local mobility anchor
   does not need to send any kind of signaling in order to move flows
   across the different physical interfaces.

   The local mobility anchor needs to know when to assign the same set
   of prefixes to all the different physical interfaces of the mobile
   node.  This can be achieved by different means, such as policy
   configuration, default policies, etc.  In this document a new Handoff
   Indicator (HI) value ("Attachment over a new interface sharing
   prefixes", value {IANA-0}) is defined, to allow the mobile access
   gateway indicate to the local mobility anchor that the same set of
   prefixes MUST be assigned to the mobile node.  The considerations of
   Section 5.4.1 of [RFC5213] are updated by this specification as
   follows:

   o  If there is at least one Home Network Prefix option present in the
      request with a NON_ZERO prefix value, there exists a Binding Cache
      entry (with one all home network prefixes in the Binding Cache
      entry matching the prefix values of all Home Network Prefix
      options of the received Proxy Binding Update message), and the
      entry matches the mobile node identifier in the Mobile Node
      Identifier option of the received Proxy Binding Update message,
      and the value of the Handoff Indicator of the received Proxy
      Binding Update is equal to "Attachment over a new interface
      sharing prefixes".

      1.  If there is an MN-LL-Identifier Option present in the request
          and the Binding Cache entry matches the Access Technology Type
          (ATT), and MN-LL-Identifier, the request MUST be considered as
          a request for updating that Binding Cache entry.

      2.  If there is an MN-LL-Identifier Option present in the request
          and the Binding Cache entry does not match the Access
          Technology Type (ATT), and MN-LL-Identifier, the request MUST
          be considered as a request for creating a new mobility session
          sharing the same set of Home Network Prefixes assigned to the
          existing Binding Cache entry found.

      3.  If there is not an MN-LL-Identifier Option present in the
          request, the request MUST be considered as a request for



Bernardos               Expires January 24, 2015                [Page 6]


Internet-Draft            PMIPv6 flow mobility                 July 2014


          creating a new mobility session sharing the same set of Home
          Network Prefixes assigned to the existing Binding Cache entry
          found.

                                     LMA Binding Cache
                       +---+       =======================
                       |LMA|        MN1, if1, pref1, MAG1
                       +---+        MN1, if2, pref1, MAG2
                        //\\
             +---------//--\\-------------+
            (         //    \\             ) PMIPv6 domain
            (        //      \\            )
             +------//--------\\----------+
                   //          \\
                  //            \\
               +----+           +----+
               |MAG1|           |MAG2|
               +----+           +----+
                 |                |
                 |   +-------+    |
                 |   |  I P  |    |
                 |   +---+---+    |
                 |---|if1|if2|----|
                     +---+---+
                        MN1

        Figure 1: Shared prefix across physical interfaces scenario

   Next, an example of how flow mobility works in this case is shown.
   In Figure 1, a mobile node (MN1) has two different physical
   interfaces (if1 and if2).  Each physical interface is attached to a
   different mobile access gateway, both of them controlled by the same
   local mobility anchor.  Both physical interfaces are assigned the
   same prefix (pref1) upon attachment to the MAGs.  If the IP layer at
   the mobile node shows one single logical interface (e.g., as
   described in [I-D.ietf-netext-logical-interface-support]), then the
   mobile node has one single IPv6 address configured at the IP layer:
   pref1::mn1.  Otherwise, per interface IPv6 addresses (e.g.,
   pref1::if1 and pref1::if2) would be configured; each address MUST be
   valid on every interface.  We assume the first case in the following
   example (and in the rest of this document).  Initially, flow X goes
   through MAG1 and flow Y through MAG2.  At certain point, flow Y can
   be moved to also go through MAG1.  As shown in Figure 2, no signaling
   between the local mobility anchor and the mobile access gateways is
   needed.

   Note that if different IPv6 addresses are configured at the IP layer,
   IP session continuity is still possible (for each of the configured



Bernardos               Expires January 24, 2015                [Page 7]


Internet-Draft            PMIPv6 flow mobility                 July 2014


   IP addresses).  This is achieved by the network delivering packets
   destined to a particular IP address of the mobile node to the right
   MN's physical interface where the flow is selected to be moved, and
   the MN also selecting the same interface when sending traffic back up
   link.

                 +-----+         +------+        +------+      +-----+
   Internet      | LMA |         | MAG1 |        | MAG2 |      | MN1 |
                 +-----+         +------+        +------+      +-----+
      |             |               |               |             |
      |  flow X to  |   flow X to   |           flow X to         |
      |  pref1::mn1 |   pref1::mn1  |           pref1::mn1        |
      |<----------->|<------------->|<-------------------------->if1
      |  flow Y to  |           flow Y to           |  flow Y to  |
      |  pref1::mn1 |           pref1::mn1          |  pref1::mn1 |
      |<----------->|<----------------------------->|<---------->if2
      |             |               |               |             |
      |       ============          |               |       ============
      |       ||  flow  ||          |               |       ||  flow  ||
      |       || policy ||          |               |       || policy ||
      |       || update ||          |               |       || update ||
      |       ============          |               |       ============
      |             |               |               |             |
      |  flow Y to  |   flow Y to   |          flow Y to          |
      |  pref1::mn1 |   pref1::mn1  |          pref1::mn1         |
      |<----------->|<------------->|<-------------------------->if1
      |             |               |               |             |

   Figure 2: Flow mobility message sequence with common set of prefixes

   Figure 3 shows the state of the different network entities after
   moving flow Y in the previous example.  This document re-uses some of
   the terminology and mechanisms of the flow bindings and multiple
   care-of address registration specifications.  Note, that in this case
   the BIDs shown in the figure are assigned locally by the LMA, since
   there is no signaling required in this scenario.  In any case,
   alternative implementations of flow routing at the LMA MAY be used,
   as it does not impact on the operation of the solution in this case.













Bernardos               Expires January 24, 2015                [Page 8]


Internet-Draft            PMIPv6 flow mobility                 July 2014


                           LMA Binding Cache        LMA flowmob state
                      (BID, MN-ID, ATT, HNP, PCoA)      (BID, TS)
                 +---+ ==========================  ===================
                 |LMA|  1, MN1, if1, pref1, MAG1       1, flow X
                 +---+  2, MN1, if2, pref1, MAG2       1, flow Y
                  //\\
       +---------//--\\-------------+
      (         //    \\             ) PMIPv6 domain
      (        //      \\            )
       +------//--------\\----------+
             //          \\
            //            \\       MAG1 routing state
         +----+           +----+  ================================
         |MAG1|           |MAG2|     (dest)         (next hop)
         +----+           +----+   pref1::/64   p2p-iface-with-MN1
           |                |         ::/0             LMA
           |                |
           |                |      MAG2 routing state
           |   +-------+    |     ================================
           |   |  I P  |    |        (dest)         (next hop)
           |   +---+---+    |      pref1::/64   p2p-iface-with-MN1
           |---|if1|if2|----|         ::/0             LMA
               +---+---+
                  MN1

           Figure 3: Data structures with common set of prefixes

3.2.2.  MN with different sets of prefixes on each MAG

   A different flow mobility scenario happens when the local mobility
   anchor assigns different sets of prefixes to physical interfaces of
   the same mobile node.  This covers the second case, or a combination
   of scenarios, described in Section 3.1.  In this case, additional
   signaling is required between the local mobility anchor and the
   mobile access gateway to enable relocating flows between the
   different attachments, so the MAGs are aware of the prefixes for
   which the MN is going to receive traffic, and local routing entries
   are configured accordingly.

   Two different, but related, approaches are considered next.

   The first approach corresponds to the second use case scenario
   described in Section 3.1, in which a multi-interfaced mobile node
   obtains a different set of prefixes on each attachment.  Signaling is
   required when a flow is to be moved from its original interface to a
   new one.  Since the local mobility anchor cannot send a PBA message
   which has not been triggered in response to a received PBU message,
   the solution defined in this specification makes use of two mobility



Bernardos               Expires January 24, 2015                [Page 9]


Internet-Draft            PMIPv6 flow mobility                 July 2014


   messages: Flow Mobility Indication and Flow Mobility Acknowledgement,
   which actually use the format of the Update Notifications for Proxy
   Mobile IPv6 defined in [RFC7077].  The trigger for the flow movement
   can be on the mobile node (e.g., by using layer-2 signaling with the
   MAG) or on the network (e.g., based on congestion and measurements)
   which then notifies the MN for the final IP flow mobility decision
   (as stated in section 3.1).  Policy management function (e.g., 3GPP/
   ANDSF) can be used for that purpose, however, how the network notify
   the MN is out of the scope of this document.

   If the flow is being moved from its default path (which is determined
   by the destination prefix) to a different one, the local mobility
   anchor constructs an Flow Mobility Indication (FMI) message.  This
   message includes a Home Network Prefix for each of the prefixes that
   requested to be provided with flow mobility support on the new MAG
   (note that these prefixes are not anchored by the target MAG, and
   therefore the MAG MUST NOT advertise them on the MAG-MN link), with
   the off-link bit (L) set to one.  This message MUST be sent to the
   new target mobile access gateway, i.e. the one selected to be used in
   the forwarding of the flow.  The MAG replies with a Flow Mobility
   Ackwnoledgement (FMA).  The message sequence is shown in Figure 4.






























Bernardos               Expires January 24, 2015               [Page 10]


Internet-Draft            PMIPv6 flow mobility                 July 2014


                 +-----+         +------+        +------+      +-----+
   Internet      | LMA |         | MAG1 |        | MAG2 |      | MN1 |
                 +-----+         +------+        +------+      +-----+
      |             |               |               |             |
      |  flow X to  |   flow X to   |           flow X to         |
      |  pref1::mn1 |   pref1::mn1  |           pref1::mn1        |
      |<----------->|<------------->|<-------------------------->if1
      |  flow Y to  |           flow Y to           |  flow Y to  |
      |  pref2::mn1 |           pref2::mn1          |  pref2::mn1 |
      |<----------->|<----------------------------->|<---------->if2
      |             |               |               |             |
      |       ============          |               |       ============
      |       ||  flow  ||          |               |       ||  flow  ||
      |       || policy ||          |               |       || policy ||
      |       || update ||          |               |       || update ||
      |       ============          |               |       ============
      |             |               |               |             |
      |             | FMI[MN1-ID, HNPs]             |             |
      |             |-------------->|               |             |
      |             |          FMA  |               |             |
      |             |<--------------|               |             |
      |  flow Y to  |   flow Y to   |          flow Y to          |
      |  pref2::mn1 |   pref2::mn1  |          pref2::mn1         |
      |<----------->|<------------->|<-------------------------->if1
      |             |               |               |             |

       Figure 4: Flow mobility message sequence when the LMA assigns
             different sets of prefixes per physical interface

   The state in the network after moving a flow, for the case the LMA
   assigns a different set of prefixes is shown in Figure 5.




















Bernardos               Expires January 24, 2015               [Page 11]


Internet-Draft            PMIPv6 flow mobility                 July 2014


                           LMA Binding Cache          LMA flowmob state
                      (BID, MN-ID, ATT, HNP, PCoA)       (BID, TS)
                 +---+ ============================  ===================
                 |LMA|  1, MN1, if1, pref1,               1, flow X
                 +---+               pref2,  MAG1         1, flow Y
                  //\\  2, MN1, if2, pref2,  MAG2
       +---------//--\\-------------+
      (         //    \\             ) PMIPv6 domain
      (        //      \\            )
       +------//--------\\----------+
             //          \\
            //            \\       MAG1 routing state
         +----+           +----+  ================================
         |MAG1|           |MAG2|     (dest)         (next hop)
         +----+           +----+   pref1::/64   p2p-iface-with-MN1
           |                |      pref2::/64   p2p-iface-with-MN1
           |                |         ::/0             LMA
           |                |
           |   +-------+    |      MAG2 routing state
           |   |  I P  |    |     ================================
           |   +---+---+    |        (dest)         (next hop)
           |---|if1|if2|----|      pref2::/64   p2p-iface-with-MN1
               +---+---+              ::/0             LMA
                  MN1

     Figure 5: Data structures when the LMA assigns a different set of
                                 prefixes

   The second approach corresponds to the combination of the two prefix
   management models described in Section 3.1, in which upon new
   physical interface attachment, the MN obtains both prefix(es) in use
   and new prefix(es).  Here, the mobile node is already attached to the
   PMIPv6-Domain via MAG1.  At a certain moment, the mobile node
   attaches a new interface (if2) to MAG2.  MAG2 sends a PBU which is
   then used by the LMA to enable flow mobility.  In this case, we
   consider that flows are moved with a prefix granularity, meaning that
   flows are moved by moving prefixes among the different MAGs the
   mobile node is attached to.  In this example, flow Y is bound to
   pref2::/64 and therefore the flow can be moved by just binding
   pref2::/64 to MAG2.  This is done by including the prefix in the PBA
   message.  The scenario is shown in Figure 6.

   Optionally, a Binding Revocation Indication message [RFC5846] with
   the P bit set MAY be sent to MAG1 to indicate that this is a
   revocation of PMIP prefix(es).  After processing BRI, the source MAG
   MUST send a Binding Revocation Acknowledgement (BRA) message back to
   the LMA.




Bernardos               Expires January 24, 2015               [Page 12]


Internet-Draft            PMIPv6 flow mobility                 July 2014


                 +-----+           +------+        +------+      +-----+
   Internet      | LMA |           | MAG1 |        | MAG2 |      | MN  |
                 +-----+           +------+        +------+      +-----+
      |             |                 |               |             |
      |  flow X to  |    flow X to    |           flow X to         |
      |  pref1::mn1 |    pref1::mn1   |           pref1::mn1        |
      |<----------->|<--------------->|<-------------------------->if1
      |  flow Y to  |    flow Y to    |           flow Y to         |
      |  pref2::mn1 |    pref2::mn1   |           pref2::mn1        |
      |<----------->|<--------------->|<-------------------------->if1
      |             |                 |               |             |
      |             |                 |               |             |
      |             |                 |            MN powers on if2 and
      |             |                 |           performs L2 attachment
      |             |                 |               |<-----------if2
      |             |                 |          PBU  |             |
      |             |<--------------------------------|             |
      |             |   PBA (pref2)   |               |             |
      |             |-------------------------------->|             |
      |     LMA moves pref2 to new    |               |             |
      |  binding cache entry for if2  |               |             |
      |             |                 |               |             |
      |  flow y to  |             flow y to           |  flow y to  |
      |  pref2::mn1 |             pref2::mn1          |  pref2::mn1 |
      |<----------->|<------------------------------->|<---------->if2
      |             |                 |               |             |
      |             |   (optional)    |               |             |
      |             |   BRI[pref2]    |               |             |
      |             |---------------->|               |             |
      |             |       BRA       |               |             |
      |             |<----------------|               |             |
      |             |                 |               |             |


      Figure 6: Flow mobility message sequence with different set of
              prefixes per physical interface (PBU signaling)

4.  Message Formats

   This section defines modifications to the Proxy Mobile IPv6 [RFC5213]
   protocol messages.

   This specification requires implementation of UPN [RFC7077] and UPA
   [RFC7077] messages with the specific Notification Reason and Status
   Code values as defined by this document.  This document does not
   require implementation of any other aspects of [RFC7077].





Bernardos               Expires January 24, 2015               [Page 13]


Internet-Draft            PMIPv6 flow mobility                 July 2014


4.1.  Home Network Prefix

   A new flag (L) is included in the Home Network Prefix mobility option
   to indicate to the Mobile Access Gateway whether the conveyed prefix
   has to be hosted on-link or not on the point-to-point interface with
   the mobile node.  A prefix is hosted off-link for the flow mobility
   purposes defined in this document.  The rest of the Home Network
   Prefix mobility option format remains the same as defined in
   [RFC5213].

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type     |   Length      |L|  Reserved   | Prefix Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                    Home Network Prefix                        +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Off-link Home Network Prefix Flag (L):

      The Off-link Home Network Prefix Flag is set to indicate to the
      Mobile Access Gateway that the Home Network Prefix conveyed in the
      option is not to be hosted on-link, but has to be considered for
      flow mobility purposes and therefore added to the Mobile Access
      Gateway routing table.  If the flag is set to 0, the Mobile Access
      Gateway assumes that the Home Network Prefix has to be hosted on-
      link.

4.2.  Flow Mobility Initiate (FMI)

   The FMI message (Figure 7) used in this specification is the Update
   Notification (UPN) messages specified in [RFC7077].  The message
   format, transport and security consideration are as specified in
   [RFC7077].  The format of the message is specified in Section 4.1 of
   [RFC7077] and is shown below for completeness.  This specification
   does not modify the UPN message, however, it defines new Notification
   Reason values for use in this specification.








Bernardos               Expires January 24, 2015               [Page 14]


Internet-Draft            PMIPv6 flow mobility                 July 2014


      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 #          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Notification Reason        |A|D|          Reserved         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Mobility options                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 7: Flow Mobility Initiate message format

   This document defines the following new Notification Reason value for
   use in Update Notification message:

   Notification Reason:

      {IANA-1} - FLOW-MOBILITY-ADD.  Request to add the prefix(es)
      conveyed in the home network prefix mobility options included in
      the message to the set of prefixes for which flow mobility is
      provided.

      {IANA-2} - FLOW-MOBILITY-REMOVE.  Request to remove the prefix(es)
      conveyed in the home network prefix mobility options included in
      the message to the set of prefixes for which flow mobility is
      provided.

   The Mobility Options field of an FMI MUST contain the MN-ID, followed
   by one or more Home Network Prefixes Mobility options.

4.3.  Flow Mobility Acknowledgement (FMA)

   The FMA message (Figure 8) used in this specification is the Update
   Notification Ack (UPA) messages specified in Section 4.2 of
   [RFC7077].  The message format, transport and security consideration
   are as specified in [RFC7077].  The format of the message is
   specified in Section 4.2 of [RFC7077] and is shown below here for
   completeness.  This specification does not modify the UPA message,
   however, it defines new Status Code values for use in this
   specification.







Bernardos               Expires January 24, 2015               [Page 15]


Internet-Draft            PMIPv6 flow mobility                 July 2014


      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 #          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Status Code |                   Reserved                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Mobility options                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 8: Flow Mobility Acknowledgement message format

   This document defines the following new status code values for use in
   Update Notification Acknowledgement message.

   Status Code:

      0: Success.

      {IANA-3}: Reason unspecified.

      {IANA-4}: MN not attached.

      {IANA-5}: No existing Flow Mobility Cache entry.

   When Status code is 0. the Mobility Options field of an FMA MUST
   contain the MN-ID, followed by one or more Home Network Prefixes
   Mobility options.

5.  Conceptual Data Structures

   This section summarizes the extensions to Proxy Mobile IPv6 that are
   necessary to manage flow mobility.

5.1.  Multiple Proxy Care-of Address Registration

   The binding cache structure of the local mobility anchor is extended
   to allow multiple proxy care of address (Proxy-CoA) registrations,
   and support the mobile node use the same address (prefix) beyond a
   single interface and mobile access gateway.  The LMA maintains
   multiple binding cache entries for an MN.  The number of binding
   cache entries for a mobile node is equal to the number of the MN's
   interfaces attached to any MAGs.




Bernardos               Expires January 24, 2015               [Page 16]


Internet-Draft            PMIPv6 flow mobility                 July 2014


   This specification re-uses the extensions defined in [RFC5648] to
   manage multiple registrations, but in the context of Proxy Mobile
   IPv6.  The binding cache is therefore extended to include more than
   one proxy care-of addresses and to associate each of them with a
   binding identifier (BID).  Note that the BID is a local identifier,
   assigned and used by the local mobility anchor to identify which
   entry of the flow mobility cache is used to decide how to route a
   given flow.

            +---------+-----+-------+------+-----------+------------+
            | BID-PRI | BID | MN-ID |  ATT |   HNP(s)  | Proxy-CoA  |
            +---------+-----+-------+------+-----------+------------+
            |    20   |  1  |  MN1  | WiFi | HNP1,HNP2 | IP1 (MAG1) |
            |    30   |  2  |  MN1  | 3GPP | HNP1,HNP3 | IP2 (MAG2) |
            +---------+-----+-------+------+-----------+------------+

                     Figure 9: Extended Binding Cache

   Figure 9 shows an example of extended binding cache, containing two
   binding cache entries (BCEs) of a mobile node MN1 attached to the
   network using two different access technologies.  Both of the two
   attachments share the same prefix (HNP1) and are bounded to two
   different Proxy-CoAs (two MAGs).

5.2.  Flow Mobility Cache

   Each local mobility anchor MUST maintain a flow mobility cache (FMC)
   as shown in Figure 10.  The flow mobility cache is a conceptual list
   of entries that is separate from the binding cache.  This conceptual
   list contains an entry for each of the registered flows.  This
   specification re-uses the format of the flow binding list defined in
   [RFC6089].  Each enty 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.







Bernardos               Expires January 24, 2015               [Page 17]


Internet-Draft            PMIPv6 flow mobility                 July 2014


               +---------+-----+-----+------+---------+----------+
               | 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 entry of the
   flow mobility cache points to a specific binding cache entry
   identifier (BID).  When a flow is moved, the local mobility anchor
   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
   conceptual data entries are needed.  In case full per-flow state is
   required at the mobile access gateway, it SHOULD also maintain a flow
   mobility cache structure.

6.  Mobile Node considerations

   This specification assumes that the mobile node IP layer interface
   can simultaneously and/or sequentially attach to multiple MAGs,
   possibly over multiple media.  The mobile node MUST be able to
   enforce uplink policies to select the right outgoing interface.  One
   form to achieve this multiple attachment is described in
   [I-D.ietf-netext-logical-interface-support], which allows the mobile
   node supporting traffic flows on different physical interfaces
   regardless of the assigned prefixes on those physical interfaces.






Bernardos               Expires January 24, 2015               [Page 18]


Internet-Draft            PMIPv6 flow mobility                 July 2014


7.  IANA Considerations

   This specification defines new value for the Handoff Indicator
   {IANA-0} and a new flag (L) in the Home Network Mobility Option.  New
   Notification Reason values for use in Update Notification message
   ({IANA-1} and {IANA-2}) and new Status Values for use in Update
   Acknowledgement message ({IANA-3} to {IANA-5}) are also defined..

8.  Security Considerations

   The protocol signaling extensions defined in this document share the
   same security concerns of Proxy Mobile IPv6 [RFC5213] and do not pose
   any additional security threats to those already identified in
   [RFC5213] and [RFC7077].

   The mobile access gateway and the local mobility anchor MUST use the
   IPsec security mechanism mandated by Proxy Mobile IPv6 [RFC5213] to
   secure the signaling described in this document.

9.  Authors

   This document reflects contributions from the following authors (in
   alphabetical order).

      Kuntal Chowdhury

         E-mail: Kchowdhu@cisco.com

      Vijay Devarapalli

         E-mail: vijay@wichorus.com

      Sri Gundavelli

         E-mail: sgundave@cisco.com

      Youn-Hee Han

         E-mail: yhhan@kut.ac.kr

      Yong-Geun Hong

         E-mail: yonggeun.hong@gmail.com

      Mohana Dahamayanthi Jeyatharan

         E-mail: mohana.jeyatharan@sg.panasonic.com




Bernardos               Expires January 24, 2015               [Page 19]


Internet-Draft            PMIPv6 flow mobility                 July 2014


      Rajeev Koodli

         E-mail: rkoodli@cisco.com

      Kent Leung

         E-mail: kleung@cisco.com

      Telemaco Melia

         E-mail: Telemaco.Melia@alcatel-lucent.com

      Bruno Mongazon-Cazavet

         E-mail: Bruno.Mongazon-Cazavet@alcatel-lucent.com

      Chan-Wah Ng

         E-mail: chanwah.ng@sg.panasonic.com

      Behcet Sarikaya

         E-mail: sarikaya@ieee.org

      Tran Minh Trung

         E-mail: trungtm2909@gmail.com

      Frank Xia

         E-mail: xiayangsong@huawei.com

10.  Acknowledgments

   The authors would like to thank Juan-Carlos Zuniga, Pierrick Seite,
   Julien Laganier for all the useful discussions on this topic.

   The authors would also like to thank Marco Liebsch and Juan-Carlos
   Zuniga for their reviews of this document.

   The work of Carlos J.  Bernardos has also been partially supported by
   the European Community's Seventh Framework Programme under grant
   agreement n.  FP7-317941 (iJOIN project).








Bernardos               Expires January 24, 2015               [Page 20]


Internet-Draft            PMIPv6 flow mobility                 July 2014


11.  References

11.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.

   [RFC5648]  Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
              and K. Nagami, "Multiple Care-of Addresses Registration",
              RFC 5648, October 2009.

   [RFC5846]  Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
              and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC
              5846, June 2010.

   [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.

   [RFC7077]  Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
              J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
              RFC 7077, November 2013.

11.2.  Informative References

   [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-09 (work in progress), March 2014.

Author's Address












Bernardos               Expires January 24, 2015               [Page 21]


Internet-Draft            PMIPv6 flow mobility                 July 2014


   Carlos J. Bernardos (editor)
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es
   URI:   http://www.it.uc3m.es/cjbc/










































Bernardos               Expires January 24, 2015               [Page 22]