path: root/doc/rfc/rfc7864.txt

Internet Engineering Task Force (IETF)                CJ. Bernardos, Ed.
Request for Comments: 7864                                          UC3M
Updates: 5213                                                   May 2016
Category: Standards Track
ISSN: 2070-1721


         Proxy Mobile IPv6 Extensions to Support Flow Mobility

Abstract

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

   This document updates RFC 5213.  The extensions described in this
   document consist of 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.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7864.














Bernardos                    Standards Track                    [Page 1]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


Copyright Notice

   Copyright (c) 2016 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 . . .   6
       3.2.2.  MN with Different Sets of Prefixes on Each MAG  . . .   9
     3.3.  Use of PBU/PBA Signaling  . . . . . . . . . . . . . . . .  11
     3.4.  Use of Flow-Level Information . . . . . . . . . . . . . .  12
   4.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  Home Network Prefix . . . . . . . . . . . . . . . . . . .  13
     4.2.  Flow Mobility Initiate (FMI)  . . . . . . . . . . . . . .  13
     4.3.  Flow Mobility Acknowledgement (FMA) . . . . . . . . . . .  14
   5.  Conceptual Data Structures  . . . . . . . . . . . . . . . . .  14
     5.1.  Multiple Proxy Care-of Address Registration . . . . . . .  14
     5.2.  Flow Mobility Cache (FMC) . . . . . . . . . . . . . . . .  15
   6.  Mobile Node Considerations  . . . . . . . . . . . . . . . . .  16
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19









Bernardos                    Standards Track                    [Page 2]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


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 the Mobile Node's (MN's) 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 an MN to connect to the same PMIPv6 domain through
   different interfaces.  This document specifies protocol extensions to
   Proxy Mobile IPv6 between the LMA and MAGs to enable "flow mobility"
   and, hence, distribute specific traffic flows on different physical
   interfaces.  It is assumed that the MN 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 [RFC7847], which allows the MN supporting traffic flows
   on different physical interfaces, regardless of the assigned prefixes
   on those physical interfaces.  Another alternative is to configure
   the IP stack of the MN to behave according to the Weak ES Model
   (commonly referred to as the weak host model) [RFC1122].

   In particular, this document specifies how to enable "flow mobility"
   in the PMIPv6 network (i.e., LMAs and MAGs).  In order to do so, two
   main operations are required: i) proper prefix management by the
   PMIPv6 network and 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 RFC 2119 [RFC2119].

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

   o  Local Mobility Anchor (LMA)

   o  Mobile Access Gateway (MAG)

   o  Proxy Mobile IPv6 Domain (PMIPv6-Domain)





Bernardos                    Standards Track                    [Page 3]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


   o  LMA Address (LMAA)

   o  Proxy Care-of Address (Proxy-CoA)

   o  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]:

   o  Binding Identification (BID) Number

   o  Flow Identifier (FID)

   o  Traffic Selector (TS)

   The following terms are defined and used in this document:

   o  Flow Mobility Initiate (FMI): Message sent by the LMA to the MAG
      conveying the information required to enable flow mobility in a
      PMIPv6-Domain.

   o  Flow Mobility Acknowledgement (FMA): Message sent by the MAG in
      reply to an FMI message.

   o  Flow Mobility Cache (FMC): Conceptual data structure 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
   that an MN can have simultaneous access to more than one network.  In
   this specification, it is assumed that the LMA is aware of the MN's
   ability to have simultaneous access to both access networks and the
   ability to 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 MN
   might share a common set of prefixes among all its physical
   interfaces; in others, the MN might have a different subset of
   prefixes configured on each of the physical interfaces.  The
   different scenarios are the following:





Bernardos                    Standards Track                    [Page 4]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


   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 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 Sections 3.2.1 and 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 MN and the LMA 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.  Either the MN or
   the LMA can initiate IP flow mobility.  If the MN makes the flow
   mobility decision, then the LMA follows that decision and updates its
   forwarding state accordingly.  The network can also trigger mobility
   on the MN side via out-of-band mechanisms (e.g., 3GPP / Access
   Network Discovery and Selection Function (ANDSF) sends updated
   routing policies to the MN).  In a given scenario and MN, the
   decision on IP flow mobility MUST be taken either by the MN or the
   LMA, but it MUST NOT be taken by both.










Bernardos                    Standards Track                    [Page 5]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


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 MN
   that are simultaneously attached.  Subsequently, no further signaling
   is necessary between the local mobility anchor and the MAG, and flows
   are forwarded according to policy rules on the LMA and the MN.

   If the LMA 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 after the Proxy Binding Update / Proxy Binding
   Acknowledgement (PBU/PBA) registration for each MAG, and the LMA does
   not need to send any kind of signaling in order to move flows across
   the different physical interfaces (because moving flows is a local
   decision of the LMA).  Optionally, signaling MAY be exchanged in case
   the MAG needs to know about flow-level information (e.g., to link
   flows with proper QoS paths and/or inform the MN [RFC7222]).

   The LMA needs to know when to assign the same set of prefixes to all
   the different physical interfaces of the MN.  This can be achieved by
   different means, such as policy configuration, default policies, etc.
   In this document, a new Handoff Indicator (HI) ("Attachment over a
   new interface sharing prefixes" (6) value) is defined that allows the
   MAG to indicate to the LMA that the same set of prefixes MUST be
   assigned to the MN.  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 (BCE) (with all HNPs in the BCE matching the prefix values
      of all Home Network Prefix Options of the received Proxy Binding
      Update message), and the entry matches the MN identifier in the
      Mobile Node Identifier Option of the received Proxy Binding Update
      message, and the value of the HI of the received Proxy Binding
      Update is equal to "Attachment over a new interface sharing
      prefixes".

      1.  If there is a Mobile Node Link-layer Identifier Option present
          in the request, and the BCE matches the Access Technology Type
          (ATT) and the MN-LL-Identifier, then the request MUST be
          considered as a request for updating that BCE.







Bernardos                    Standards Track                    [Page 6]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


      2.  If there is a Mobile Node Link-layer Identifier Option present
          in the request, and the BCE does not match the Access
          Technology Type (ATT) and the MN-LL-Identifier, then the
          request MUST be considered as a request for creating a new
          mobility session sharing the same set of HNPs assigned to the
          existing BCE found.

      3.  If there is not a Mobile Node Link-layer Identifier Option
          present in the request, then the request MUST be considered as
          a request for creating a new mobility session sharing the same
          set of HNPs assigned to the existing BCE found.

                                      LMA Binding Cache
                       +---+       ========================
                       |LMA|        MN1, ATT1, pref1, MAG1
                       +---+        MN1, ATT2, 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 of access technology type ATT1, and if2 of access
   technology type ATT2).  Each physical interface is attached to a
   different MAG, both of them controlled by the same LMA.  Both
   physical interfaces are assigned the same prefix (pref1) upon
   attachment to the MAGs.  If the IP layer at the MN shows one single
   logical interface (e.g., as described in [RFC7847]), 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



Bernardos                    Standards Track                    [Page 7]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


   example (and in the rest of this document).  Initially, flow X goes
   through MAG1 and flow Y through MAG2.  At a certain point, flow Y can
   be moved to also go through MAG1.  Figure 2 shows the scenario in
   which no flow-level information needs to be exchanged, so there is no
   signaling between the LMA and the MAGs.

   Note that if different IPv6 addresses are configured at the IP layer,
   IP-session continuity is still possible (for each of the configured
   IP addresses).  This is achieved by the network delivering packets
   destined to a particular IP address of the MN to the right of MN's
   physical interface where the flow is selected to be moved, and the MN
   also selecting the same interface when sending traffic back uplink.

                 +-----+         +------+        +------+      +-----+
   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 a Common Set of
                                 Prefixes

   Figure 3 shows the state of the different network entities after
   moving flow Y in the previous example.  This document reuses 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 the operation of the solution in this case.





Bernardos                    Standards Track                    [Page 8]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


                           LMA Binding Cache         LMA flowmob state
                      (BID, MN-ID, ATT, HNP, PCoA)       (BID, TS)
                 +---+ ===========================  ===================
                 |LMA|  1, MN1, ATT1, pref1, MAG1       1, flow X
                 +---+  2, MN1, ATT2, 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 a Common Set of Prefixes

3.2.2.  MN with Different Sets of Prefixes on Each MAG

   A different flow mobility scenario happens when the LMA 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 LMA and the MAG 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.

   In this case, signaling is required when a flow is to be moved from
   its original interface to a new one.  Since the LMA cannot send a PBA
   message that has not been triggered in response to a received PBU
   message, the solution defined in this specification makes use of two
   mobility messages: FMI and FMA, which actually use the format of the
   Update Notifications for PMIPv6 defined in [RFC7077].  The trigger
   for the flow movement can be on the MN (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



Bernardos                    Standards Track                    [Page 9]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


   functions (e.g., 3GPP/ANDSF) can be used for that purpose; however,
   how the network notifies 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 LMA constructs a
   FMI message.  This message includes a Home Network Prefix Option for
   each of the prefixes that are 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 MAG, i.e., the one selected to
   be used in the forwarding of the flow.  The MAG replies with an FMA.
   The message sequence is shown in Figure 4.

                 +-----+         +------+        +------+      +-----+
   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









Bernardos                    Standards Track                   [Page 10]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


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

                           LMA Binding Cache          LMA flowmob state
                      (BID, MN-ID, ATT, HNP, PCoA)        (BID, TS)
                 +---+ ============================  ===================
                 |LMA|  1, MN1, ATT1, pref1,              1, flow X
                 +---+                pref2,  MAG1        1, flow Y
                  //\\  2, MN1, ATT2, 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

3.3.  Use of PBU/PBA Signaling

   This specification introduces the FMI/FMA signaling, which allows the
   LMA to exchange required information with the MAG to enable flow
   mobility without waiting to receive a PBU.  However, there are
   scenarios in which the trigger for flow mobility might be related to
   a new MN's interface attachment.  In this case, the PBA sent in
   response to the PBU received from the new MAG can convey the same
   signaling that the FMI does.  In this case, the LMA MUST include a
   Home Network Prefix Option in the PBA for each of the prefixes that
   are requested to be provided with flow mobility support on the new
   MAG with the off-link bit (L) set to one.








Bernardos                    Standards Track                   [Page 11]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


3.4.  Use of Flow-Level Information

   This specification does not mandate flow-level information to be
   exchanged between the LMA and the MAG to provide flow mobility
   support.  It only requires that the LMA keeps a flow-level state
   (Section 5.2).  However, there are scenarios in which the MAG might
   need to know which flow(s) is/are coming within a prefix that has
   been moved, to link it/them to the proper QoS path(s) and optionally,
   inform the MN about it.  This section describes the extensions used
   to include flow-level information in the signaling defined between
   the LMA and the MAG.

   This specification reuses some of the mobility extensions and message
   formats defined in [RFC5648] and [RFC6089], namely the Flow
   Identification Mobility Option and the Flow Mobility Sub-Options.

   If the LMA wants to convey flow-level information to the MAG, it MUST
   include in the FMI (or the PBA) a Flow Identification Mobility Option
   for all the flows that the MAG needs to be aware of with flow
   granularity.  Each Flow Identification Mobility Option MUST include a
   Traffic Selector Sub-Option including such flow-level information.

   To remove a flow-binding state at the MAG, the LMA simply sends an
   FMI (or a PBA, if it is in response to a PBU) message that includes
   flow identification options for all the flows that need to be
   refreshed, modified, or added, and simply omits those that need to be
   removed.

   Note that even if a common set of prefixes is used, providing the MAG
   with flow-level information requires signaling to be exchanged, in
   this case between the LMA and the MAG.  This is done by sending an
   FMI message (or a PBA, if it is sent in response to a PBU).

4.  Message Formats

   This section defines modifications to the PMIPv6 [RFC5213] protocol
   messages.

   This specification requires implementation of Update Notification
   (UPN) [RFC7077] and Update Notification Ack (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                    Standards Track                   [Page 12]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


4.1.  Home Network Prefix

   A new flag (L) is included in the Home Network Prefix Option to
   indicate to the MAG whether the conveyed prefix has to be hosted on-
   link or not on the point-to-point interface with the MN.  A prefix is
   hosted off-link for the flow mobility purposes defined in this
   document.  The rest of the Home Network Prefix 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
      MAG that the HNP 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 MAG routing table.  If the flag is set to
      0, the MAG assumes that the HNP has to be hosted on-link.

4.2.  Flow Mobility Initiate (FMI)

   The FMI message used in this specification is the UPN message
   specified in [RFC7077].  The message format, transport, and security
   considerations are as specified in [RFC7077].  The format of the
   message is specified in Section 4.1 of [RFC7077].  This specification
   does not modify the UPN message; however, it defines the following
   new notification reason value for use in this specification:

   Notification Reason:

      FLOW-MOBILITY (8).  Request to add/refresh the prefix(es) conveyed
      in the Home Network Prefix Options included in the message to the
      set of prefixes for which flow mobility is provided.






Bernardos                    Standards Track                   [Page 13]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


   The Mobility Options field of an FMI MUST contain the MN-ID, followed
   by one or more Home Network Prefix Options.  Prefixes for which flow
   mobility was provided that are not present in the message MUST be
   removed from the set of flow mobility-enabled prefixes.

4.3.  Flow Mobility Acknowledgement (FMA)

   The FMA message used in this specification is the UPA message
   specified in Section 4.2 of [RFC7077].  The message format,
   transport, and security considerations are as specified in [RFC7077].
   The format of the message is specified in Section 4.2 of [RFC7077].
   This specification does not modify the UPA message, however, it
   defines the following new status code values for use in this
   specification:

   Status Code:

      0: Success

      131: Reason unspecified

      132: MN not attached

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

5.  Conceptual Data Structures

   This section summarizes the extensions to PMIPv6 that are necessary
   to manage flow mobility.

5.1.  Multiple Proxy Care-of Address Registration

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

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



Bernardos                    Standards Track                   [Page 14]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


            +---------+-----+-------+------+-----------+------------+
            | 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 6: Extended Binding Cache

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

5.2.  Flow Mobility Cache (FMC)

   Each LMA MUST maintain an FMC as shown in Figure 7.  The FMC 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 reuses the format of the flow-binding list
   defined in [RFC6089].  Each entry includes the following fields:

   o  Flow Identifier Priority (FID-PRI)

   o  Flow Identifier (FID)

   o  Traffic Selector (TS)

   o  Binding Identification (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 7: Flow Mobility Cache

   The BID field contains the identifier of the BCE to which the packets
   matching the flow information described in the TS field will be
   forwarded.  When it is decided that a flow is to be moved, the
   affected BID(s) of the table are updated.



Bernardos                    Standards Track                   [Page 15]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


   Similar to the flow binding described in [RFC6089], each entry of the
   FMC points to a specific 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 TS in the flow-
   binding table is defined in [RFC6088].  TS is used to classify the
   packets of flows based 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.  The action may be
   to 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 de-registered.

   The MAG 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: no extra conceptual data entries are
   needed.  If full per-flow state is required at the MAG, it SHOULD
   also maintain an FMC 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 MN MUST be able to enforce uplink
   policies to select the right outgoing interface.  One alternative to
   achieve this multiple attachment is described in [RFC7847], which
   allows the MN supporting traffic flows on different physical
   interfaces, regardless of the assigned prefixes on those physical
   interfaces.  Another alternative is configuring the IP stack of the
   MN to behave according to the weak host model [RFC1122].

7.  IANA Considerations

   This specification establishes new assignments to the IANA mobility
   parameters registry:

   o  Handoff Indicator Option type: "Attachment over a new interface
      sharing prefixes" has been assigned the value 6 from the "Handoff
      Indicator Option type values" registry defined in
      <http://www.iana.org/assignments/mobility-parameters>.

   o  Update Notification Reason: "FLOW-MOBILITY" has been assigned the
      value 8 from the "Update Notification Reasons Registry" defined in
      <http://www.iana.org/assignments/mobility-parameters>.







Bernardos                    Standards Track                   [Page 16]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


   o  Update Notification Acknowledgement Status: "Reason unspecified"
      has been assigned the value 131 and "MN not attached" has been
      assigned the value 132 from the "Update Notification
      Acknowledgement Status Registry".

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 MAG and the LMA MUST use the IPsec security mechanism mandated by
   Proxy Mobile IPv6 [RFC5213] to secure the signaling described in this
   document.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <http://www.rfc-editor.org/info/rfc5213>.

   [RFC5648]  Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst,
              T., and K. Nagami, "Multiple Care-of Addresses
              Registration", RFC 5648, DOI 10.17487/RFC5648, October
              2009, <http://www.rfc-editor.org/info/rfc5648>.

   [RFC6088]  Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
              "Traffic Selectors for Flow Bindings", RFC 6088,
              DOI 10.17487/RFC6088, January 2011,
              <http://www.rfc-editor.org/info/rfc6088>.

   [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,
              DOI 10.17487/RFC6089, January 2011,
              <http://www.rfc-editor.org/info/rfc6089>.






Bernardos                    Standards Track                   [Page 17]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


   [RFC7077]  Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
              J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
              RFC 7077, DOI 10.17487/RFC7077, November 2013,
              <http://www.rfc-editor.org/info/rfc7077>.

9.2.  Informative References

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <http://www.rfc-editor.org/info/rfc1122>.

   [RFC7222]  Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S.
              Gundavelli, "Quality-of-Service Option for Proxy Mobile
              IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014,
              <http://www.rfc-editor.org/info/rfc7222>.

   [RFC7847]  Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface
              Support for IP Hosts with Multi-Access Support", RFC 7847,
              DOI 10.17487/RFC7847, May 2016,
              <http://www.rfc-editor.org/info/rfc7847>.

Acknowledgments

   The authors would like to thank Vijay Devarapalli, Mohana
   Dahamayanthi Jeyatharan, Kent Leung, Bruno Mongazon-Cazavet, Chan-Wah
   Ng, Behcet Sarikaya, and Tran Minh Trung for their valuable
   contributions, which helped generate this document.

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

   Finally, the authors would like to thank Marco Liebsch, Juan-Carlos
   Zuniga, Dirk von Hugo, Fabio Giust, and Daniel Corujo for their
   reviews of this document.

   The work of Carlos J. Bernardos has been partially performed in the
   framework of the H2020-ICT-2014-2 project 5G NORMA.












Bernardos                    Standards Track                   [Page 18]
^L
RFC 7864                  PMIPv6 Flow Mobility                  May 2016


Contributors

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

   Kuntal Chowdhury
   Email: kc@altiostar.com

   Sri Gundavelli
   Email: sgundave@cisco.com

   Youn-Hee Han
   Email: yhhan@kut.ac.kr

   Yong-Geun Hong
   Email: yonggeun.hong@gmail.com

   Rajeev Koodli
   Email: rajeevkoodli@google.com

   Telemaco Melia
   Email: telemaco.melia@googlemail.com

   Frank Xia
   Email: xiayangsong@huawei.com

Author's Address

   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                    Standards Track                   [Page 19]
^L