summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7864.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7864.txt')
-rw-r--r--doc/rfc/rfc7864.txt1067
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]
+