doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc7864.txt b/doc/rfc/rfc7864.txt
new file mode 100644
index 0000000..9bee27b
--- /dev/null
+++ b/doc/rfc/rfc7864.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+