NETEXT Working Group CJ. Bernardos, Ed. Internet-Draft UC3M Intended status: Standards Track June 13, 2014 Expires: December 15, 2014 Proxy Mobile IPv6 Extensions to Support Flow Mobility draft-ietf-netext-pmipv6-flowmob-09 Abstract Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions described in this document consist on the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 15, 2014. Bernardos Expires December 15, 2014 [Page 1] Internet-Draft PMIPv6 flow mobility June 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of the PMIPv6 flow mobility extensions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Use case scenarios . . . . . . . . . . . . . . . . . . . 4 3.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. MN sharing a common set of prefixes on all MAGs . . . . . . . . . . . . . 5 3.2.2. MN with different sets of prefixes on each MAG . . . . . . . . . . . . 9 3.3. Operation using FMI/FMA signaling . . . . . . . . . . . . 13 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Home Network Prefix . . . . . . . . . . . . . . . . . . . 15 4.2. Proxy Binding Update and Proxy Binding Acknowledgement messages . . . . . . . . . . . . . . . . 15 4.3. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . . . . . . . . 16 4.4. Flow Mobility Acknowledgement (FMA) . . . . . . . . . . . . . . . . . . 17 5. Conceptual Data Structures . . . . . . . . . . . . . . . . . 19 5.1. Multiple Proxy Care-of Address Registration . . . . . . . 19 5.2. Flow Mobility Cache . . . . . . . . . . . . . . . . . . . 20 6. Mobile Node considerations . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 Bernardos Expires December 15, 2014 [Page 2] Internet-Draft PMIPv6 flow mobility June 2014 1. Introduction Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network based mobility management to hosts connecting to a PMIPv6 domain. PMIPv6 introduces two new functional entities, the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the entity detecting Mobile Node's (MN) attachment and providing IP connectivity. The LMA is the entity assigning one or more Home Network Prefixes (HNPs) to the MN and is the topological anchor for all traffic belonging to the MN. PMIPv6 allows a mobile node to connect to the same PMIPv6 domain through different interfaces. This document specifies protocol extensions to Proxy Mobile IPv6 between the local mobility anchor and mobile access gateways to enable "flow mobility" and hence distribute specific traffic flows on different physical interfaces. It is assumed that the mobile node IP layer interface can simultaneously and/or sequentially attach to multiple MAGs, possibly over multiple media. One form to achieve this multiple attachment is described in [I-D.ietf-netext-logical-interface-support], which allows the mobile node supporting traffic flows on different physical interfaces regardless of the assigned prefixes on those physical interfaces. In particular, this document specifies how to enable "flow mobility" in the PMIPv6 network (i.e., local mobility anchors and mobile access gateways). In order to do so, two main operations are required: i) proper prefix management by the PMIPv6 network, ii) consistent flow forwarding policies. This memo analyzes different potential use case scenarios, involving different prefix assignment requirements, and therefore different PMIPv6 network extensions to enable "flow mobility". 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. The following terms used in this document are defined in the Proxy Mobile IPv6 [RFC5213]: Local Mobility Agent (LMA). Mobile Access Gateway (MAG). Proxy Mobile IPv6 Domain (PMIPv6-Domain). LMA Address (LMAA). Bernardos Expires December 15, 2014 [Page 3] Internet-Draft PMIPv6 flow mobility June 2014 Proxy Care-of Address (Proxy-CoA). Home Network Prefix (HNP). The following terms used in this document are defined in the Multiple Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]: Binding Identification Number (BID). Flow Identifier (FID). Traffic Selector (TS). The following terms are defined and used in this document: FMI (Flow Mobility Initiate). Message sent by the LMA to the MAG conveying the information required to enable flow mobility in a PMIPv6-Domain. This message is only needed when the prefixes initially assigned by the different MAGs to the mobile node are different. FMA (Flow Mobility Acknowledgement). Message sent by the MAG in reply to an FMI message. FMC (Flow Mobility Cache). Conceptual data structure maintained by the LMA and the MAG to support the flow mobility management operations described in this document. 3. Overview of the PMIPv6 flow mobility extensions 3.1. Use case scenarios In contrast to a typical handover where connectivity to a physical medium is relinquished and then re-established, flow mobility assumes a mobile node can have simultaneous access to more than one network. In this specification, it is assumed that the local mobility anchor is aware of the mobile node's capabilities to have simultaneous access to both access networks and it can handle the same or a different set of prefixes on each access. How this is done is outside the scope of this specification. There are different flow mobility scenarios. In some of them the mobile node might share a common set of prefixes among all its physical interfaces, whereas in others the mobile node might have a different subset of prefixes configured on each of the physical interfaces. The different scenarios are the following: Bernardos Expires December 15, 2014 [Page 4] Internet-Draft PMIPv6 flow mobility June 2014 1. At the time of a new network attachment, the MN obtains the same prefix or the same set of prefixes as already assigned to an existing session. This is not the default behavior with basic PMIPv6 [RFC5213], and the LMA needs to be able to provide the same assignment even for the simultaneous attachment (as opposed to the handover scenario only). 2. At the time of a new network attachment, the MN obtains a new prefix or a new set of prefixes for the new session. This is the default behavior with basic PMIPv6 [RFC5213]. A combination of the two above-mentioned scenarios is also possible. At the time of a new network attachment, the MN obtains a combination of prefix(es) in use and new prefix(es). This is a hybrid of the two scenarios described before. The local policy determines whether the new prefix is exclusive to the new attachment or it can be assigned to an existing attachment as well. The operational description of how to enable flow mobility in each of these scenarios is provided in Section 3.2.1 and Section 3.2.2. The extensions described in this document support all the aforementioned scenarios. 3.2. Basic Operation This section describes how the PMIPv6 extensions described in this document enable flow mobility support. Both the mobile node and the local mobility anchor MUST have local policies in place to ensure that packets are forwarded coherently for unidirectional and bidirectional communications. The details about how this consistency is ensured are out of the scope of this document. The MN makes the final IP flow mobility decision, and then the LMA follows that decision and update its forwarding state accordingly. Note that this does not prevent network initiated mobility, the network still could trigger mobility on the MN side via out-of-band mechanisms (e.g., 3GPP/ANDSF sends updated routing policies to the MN). In a given scenario and mobile node, the decision on IP flow mobility MUST be taken either by the MN or the LMA, but not by both. 3.2.1. MN sharing a common set of prefixes on all MAGs This scenario corresponds to the first use case scenario described in Section 3.1. Extensions to basic PMIPv6 [RFC5213] signaling at the time of a new attachment are needed to ensure that the same prefix (or set of prefixes) is assigned to all the interfaces of the same Bernardos Expires December 15, 2014 [Page 5] Internet-Draft PMIPv6 flow mobility June 2014 mobile node that are simultaneously attached. Subsequently, no further signaling is necessary between the local mobility anchor and the mobile access gateway and flows are forwarded according to policy rules on the local mobility anchor and the mobile node. If the local mobility anchor assigns a common prefix (or set of prefixes) to the different physical interfaces attached to the domain, then every MAG already has all the routing knowledge required to forward uplink or downlink packets, and the local mobility anchor does not need to send any kind of signaling in order to move flows across the different physical interfaces. The local mobility anchor needs to know when to assign the same set of prefixes to all the different physical interfaces of the mobile node. This can be achieved by different means, such as policy configuration, default policies, etc. In this document a new Handoff Indicator (HI) value ("Attachment over a new interface sharing prefixes", value {IANA-0}) is defined, to allow the mobile access gateway indicate to the local mobility anchor that the same set of prefixes MUST be assigned to the mobile node. The considerations of Section 5.4.1 of [RFC5213] are updated by this specification as follows: o If there is at least one Home Network Prefix option present in the request with a NON_ZERO prefix value, there exists a Binding Cache entry (with one all home network prefixes in the Binding Cache entry matching the prefix values of all Home Network Prefix options of the received Proxy Binding Update message), and the entry matches the mobile node identifier in the Mobile Node Identifier option of the received Proxy Binding Update message, and the value of the Handoff Indicator of the received Proxy Binding Update is equal to "Attachment over a new interface sharing prefixes". 1. If there is an MN-LL-Identifier Option present in the request and the Binding Cache entry matches the Access Technology Type (ATT), and MN-LL-Identifier, the request MUST be considered as a request for updating that Binding Cache entry. 2. If there is an MN-LL-Identifier Option present in the request and the Binding Cache entry does not match the Access Technology Type (ATT), and MN-LL-Identifier, the request MUST be considered as a request for creating a new mobility session sharing the same set of Home Network Prefixes assigned to the existing Binding Cache entry found. 3. If there is not an MN-LL-Identifier Option present in the request, the request MUST be considered as a request for Bernardos Expires December 15, 2014 [Page 6] Internet-Draft PMIPv6 flow mobility June 2014 creating a new mobility session sharing the same set of Home Network Prefixes assigned to the existing Binding Cache entry found. LMA Binding Cache +---+ ======================= |LMA| MN1, if1, pref1, MAG1 +---+ MN1, if2, pref1, MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | +-------+ | | | I P | | | +---+---+ | |---|if1|if2|----| +---+---+ MN1 Figure 1: Shared prefix across physical interfaces scenario Next, an example of how flow mobility works in this case is shown. In Figure 1, a mobile node (MN1) has two different physical interfaces (if1 and if2). Each physical interface is attached to a different mobile access gateway, both of them controlled by the same local mobility anchor. Both physical interfaces are assigned the same prefix (pref1) upon attachment to the MAGs. If the IP layer at the mobile node shows one single logical interface (e.g., as described in [I-D.ietf-netext-logical-interface-support]), then the mobile node has one single IPv6 address configured at the IP layer: pref1::mn1. Otherwise, per interface IPv6 addresses (e.g., pref1::if1 and pref1::if2) would be configured; each address MUST be valid on every interface. We assume the first case in the following example (and in the rest of this document). Initially, flow X goes through MAG1 and flow Y through MAG2. At certain point, flow Y can be moved to also go through MAG1. As shown in Figure 2, no signaling between the local mobility anchor and the mobile access gateways is needed. Note that if different IPv6 addresses are configured at the IP layer, IP session continuity is still possible (for each of the configured Bernardos Expires December 15, 2014 [Page 7] Internet-Draft PMIPv6 flow mobility June 2014 IP addresses). This is achieved by the network delivering packets destined to a particular IP address of the mobile node to the right MN's physical interface where the flow is selected to be moved, and the MN also selecting the same interface when sending traffic back up link. +-----+ +------+ +------+ +-----+ Internet | LMA | | MAG1 | | MAG2 | | MN1 | +-----+ +------+ +------+ +-----+ | | | | | | flow X to | flow X to | flow X to | | pref1::mn1 | pref1::mn1 | pref1::mn1 | |<----------->|<------------->|<-------------------------->if1 | flow Y to | flow Y to | flow Y to | | pref1::mn1 | pref1::mn1 | pref1::mn1 | |<----------->|<----------------------------->|<---------->if2 | | | | | | ============ | | ============ | || flow || | | || flow || | || policy || | | || policy || | || update || | | || update || | ============ | | ============ | | | | | | flow Y to | flow Y to | flow Y to | | pref1::mn1 | pref1::mn1 | pref1::mn1 | |<----------->|<------------->|<-------------------------->if1 | | | | | Figure 2: Flow mobility message sequence with common set of prefixes Figure 3 shows the state of the different network entities after moving flow Y in the previous example. This document re-uses some of the terminology and mechanisms of the flow bindings and multiple care-of address registration specifications. Note, that in this case the BIDs shown in the figure are assigned locally by the LMA, since there is no signaling required in this scenario. In any case, alternative implementations of flow routing at the LMA MAY be used, as it does not impact on the operation of the solution in this case. Bernardos Expires December 15, 2014 [Page 8] Internet-Draft PMIPv6 flow mobility June 2014 LMA Binding Cache LMA flowmob state (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) +---+ ========================== =================== |LMA| 1, MN1, if1, pref1, MAG1 1, flow X +---+ 2, MN1, if2, pref1, MAG2 1, flow Y //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ MAG1 routing state +----+ +----+ ================================ |MAG1| |MAG2| (dest) (next hop) +----+ +----+ pref1::/64 p2p-iface-with-MN1 | | ::/0 LMA | | | | MAG2 routing state | +-------+ | ================================ | | I P | | (dest) (next hop) | +---+---+ | pref1::/64 p2p-iface-with-MN1 |---|if1|if2|----| ::/0 LMA +---+---+ MN1 Figure 3: Data structures with common set of prefixes 3.2.2. MN with different sets of prefixes on each MAG A different flow mobility scenario happens when the local mobility anchor assigns different sets of prefixes to physical interfaces of the same mobile node. This covers the second case, or a combination of scenarios, described in Section 3.1. In this case, additional signaling is required between the local mobility anchor and the mobile access gateway to enable relocating flows between the different attachments, so the MAGs are aware of the prefixes for which the MN is going to receive traffic, and local routing entries are configured accordingly. Two new flags (U) and (F) have been added to basic the PMIPv6 [RFC5213] PBU/PBA signaling to indicate whether the Update Notifications for Proxy Mobile IPv6 (UPN) [RFC7077] are supported or not. When both LMA and MAG set flag (U) to 1, the Update Notifications for Proxy Mobile IPv6 (UPN) [RFC7077] MUST be used. If the LMA and/or the MAG set flag (U) to 0 and both LMA and MAG set flag (F) to 1, flow indication messages MUST be used. In other situations, IP flow mobility SHALL NOT be supported. Bernardos Expires December 15, 2014 [Page 9] Internet-Draft PMIPv6 flow mobility June 2014 Two different, but related, approaches are considered next. The first approach corresponds to the second use case scenario described in Section 3.1, in which a multi-interfaced mobile node obtains a different set of prefixes on each attachment. Signaling is required when a flow is to be moved from its original interface to a new one. Since the local mobility anchor cannot send a PBA message which has not been triggered in response to a received PBU message, the solution defined in this specification makes use of the Update Notifications for Proxy Mobile IPv6 defined in [RFC7077]. The trigger for the flow movement can be on the mobile node (e.g., by using layer-2 signaling with the MAG) or on the network (e.g., based on congestion and measurements) which then notifies the MN for the final IP flow mobility decision (as stated in section 3.1). Policy management function (e.g., 3GPP/ANDSF) can be used for that purpose, however, how the network notify the MN is out of the scope of this document. If the flow is being moved from its default path (which is determined by the destination prefix) to a different one, the local mobility anchor constructs an Update Notification (UPN) message, if supported, of type (2) "UPDATE-SESSION-PARAMETERS" (NOTE from the Editor: a new Notification Reason value might be defined for just flow mobility purposes if it proves to be cleaner). If UPN is not supported, the LMA MAY use dedicated FMI/FMA messages. This message includes a Home Network Prefix for each of the prefixes that requested to be provided with flow mobility support on the new MAG (note that these prefixes are not anchored by the target MAG, and therefore the MAG MUST NOT advertise them on the MAG-MN link), with the off-link bit (L) set to one. This message MUST be sent to the new target mobile access gateway, i.e. the one selected to be used in the forwarding of the flow. This UPN message has the Acknowledgement Requested Flag ('A' Flag) set to 1, so the MAG replies with an Update Notification Acknowledgement (UPA) message. The message sequence is shown in Figure 4. Bernardos Expires December 15, 2014 [Page 10] Internet-Draft PMIPv6 flow mobility June 2014 +-----+ +------+ +------+ +-----+ Internet | LMA | | MAG1 | | MAG2 | | MN1 | +-----+ +------+ +------+ +-----+ | | | | | | flow X to | flow X to | flow X to | | pref1::mn1 | pref1::mn1 | pref1::mn1 | |<----------->|<------------->|<-------------------------->if1 | flow Y to | flow Y to | flow Y to | | pref2::mn1 | pref2::mn1 | pref2::mn1 | |<----------->|<----------------------------->|<---------->if2 | | | | | | ============ | | ============ | || flow || | | || flow || | || policy || | | || policy || | || update || | | || update || | ============ | | ============ | | | | | | | UPN[UPDATE-SESSION-PARAMETERS, MN1-ID, HNPs]| | |-------------->| | | | | UPA | | | | |<--------------| | | | flow Y to | flow Y to | flow Y to | | pref2::mn1 | pref2::mn1 | pref2::mn1 | |<----------->|<------------->|<-------------------------->if1 | | | | | Figure 4: Flow mobility message sequence when the LMA assigns different sets of prefixes per physical interface The state in the network after moving a flow, for the case the LMA assigns a different set of prefixes is shown in Figure 5. Bernardos Expires December 15, 2014 [Page 11] Internet-Draft PMIPv6 flow mobility June 2014 LMA Binding Cache LMA flowmob state (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) +---+ ============================ =================== |LMA| 1, MN1, if1, pref1, 1, flow X +---+ pref2, MAG1 1, flow Y //\\ 2, MN1, if2, pref2, MAG2 +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ MAG1 routing state +----+ +----+ ================================ |MAG1| |MAG2| (dest) (next hop) +----+ +----+ pref1::/64 p2p-iface-with-MN1 | | pref2::/64 p2p-iface-with-MN1 | | ::/0 LMA | | | +-------+ | MAG2 routing state | | I P | | ================================ | +---+---+ | (dest) (next hop) |---|if1|if2|----| pref2::/64 p2p-iface-with-MN1 +---+---+ ::/0 LMA MN1 Figure 5: Data structures when the LMA assigns a different set of prefixes The second approach corresponds to the combination of the two prefix management models described in Section 3.1, in which upon new physical interface attachment, the MN obtains both prefix(es) in use and new prefix(es). Here, the mobile node is already attached to the PMIPv6-Domain via MAG1. At a certain moment, the mobile node attaches a new interface (if2) to MAG2. MAG2 sends a PBU which is then used by the LMA to enable flow mobility. In this case, we consider that flows are moved with a prefix granularity, meaning that flows are moved by moving prefixes among the different MAGs the mobile node is attached to. In this example, flow Y is bound to pref2::/64 and therefore the flow can be moved by just binding pref2::/64 to MAG2. This is done by including the prefix in the PBA message. The scenario is shown in Figure 6. Optionally, a Binding Revocation Indication message [RFC5846] with the P bit set MAY be sent to MAG1 to indicate that this is a revocation of PMIP prefix(es). After processing BRI, the source MAG MUST send a Binding Revocation Acknowledgement (BRA) message back to the LMA. Bernardos Expires December 15, 2014 [Page 12] Internet-Draft PMIPv6 flow mobility June 2014 +-----+ +------+ +------+ +-----+ Internet | LMA | | MAG1 | | MAG2 | | MN | +-----+ +------+ +------+ +-----+ | | | | | | flow X to | flow X to | flow X to | | pref1::mn1 | pref1::mn1 | pref1::mn1 | |<----------->|<--------------->|<-------------------------->if1 | flow Y to | flow Y to | flow Y to | | pref2::mn1 | pref2::mn1 | pref2::mn1 | |<----------->|<--------------->|<-------------------------->if1 | | | | | | | | | | | | | MN powers on if2 and | | | performs L2 attachment | | | |<-----------if2 | | | PBU | | | |<--------------------------------| | | | PBA (pref2) | | | | |-------------------------------->| | | LMA moves pref2 to new | | | | binding cache entry for if2 | | | | | | | | | flow y to | flow y to | flow y to | | pref2::mn1 | pref2::mn1 | pref2::mn1 | |<----------->|<------------------------------->|<---------->if2 | | | | | | | (optional) | | | | | BRI[pref2] | | | | |---------------->| | | | | BRA | | | | |<----------------| | | | | | | | Figure 6: Flow mobility message sequence with different set of prefixes per physical interface (PBU signaling) 3.3. Operation using FMI/FMA signaling The second use case scenario described in Section 3.1 can be implemented with dedicated FMI/FMA signaling if UPN [RFC7077] is not supported. It modifies the message sequence as follows: If the flow is being moved from its default path (which is determined by the destination prefix) to a different one, the local mobility anchor constructs a Flow Mobility Initiate (FMI) message. This message MUST be sent to the new target mobile access gateway, i.e. the one selected to be used in the forwarding of the flow. The FMI Bernardos Expires December 15, 2014 [Page 13] Internet-Draft PMIPv6 flow mobility June 2014 message contains (as explained in further detail in Section 4.3), the MN-Identifier, the Flow Identification Mobility option (specified in [RFC6089]) which can convey prefix or full flow information, and the type of flow mobility operation (add flow). By default, prefix information is provided. Full prefix granularity is non mandatory. Optionally, the local mobility anchor may send another FMI message, this time to remove the flow Y state at MAG2. Otherwise the flow state at MAG2 will be removed upon timer expiration. The message sequence is shown in Figure 7. +-----+ +------+ +------+ +-----+ 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,flow_info(Y),add] | | | |-------------->| | | | | FMA | | | | |<--------------| | | | flow Y to | flow Y to | flow Y to | | pref2::mn1 | pref2::mn1 | pref2::mn1 | |<----------->|<------------->|<-------------------------->if1 | | | | | | | (optional) | | | |FMI[MN1-ID,flow_info(Y),lft=0] | | | |------------------------------>| | | | | FMA | | | |<------------------------------| | | | | | | Figure 7: FMI/FMA signaling All other operations described in Section 3.2.2 apply. Bernardos Expires December 15, 2014 [Page 14] Internet-Draft PMIPv6 flow mobility June 2014 4. Message Formats This section defines modifications to the Proxy Mobile IPv6 [RFC5213] protocol messages. 4.1. Home Network Prefix A new flag (L) is included in the Home Network Prefix mobility option to indicate to the Mobile Access Gateway whether the conveyed prefix has to be hosted on-link or not on the point-to-point interface with the mobile node. A prefix is hosted off-link for the flow mobility purposes defined in this document. The rest of the Home Network Prefix mobility option format remains the same as defined in [RFC5213]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |L| Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Off-link Home Network Prefix Flag (L): The Off-link Home Network Prefix Flag is set to indicate to the Mobile Access Gateway that the Home Network Prefix conveyed in the option is not to be hosted on-link, but has to be considered for flow mobility purposes and therefore added to the Mobile Access Gateway routing table. If the flag is set to 0, the Mobile Access Gateway assumes that the Home Network Prefix has to be hosted on- link. 4.2. Proxy Binding Update and Proxy Binding Acknowledgement messages Two new flags (U) and (F) are included in the PBU message to indicate whether Update Notifications for Proxy Mobile IPv6 (UPN) [RFC7077] is supported or the dedicated Flow indication messages. The flag (U) MUST be set to the value of 1 if UPN is supported, otherwise the flag MUST be set to 0. The flag (F) MUST be set to the value of 1 if Flow indication message is supported, otherwise the flag MUST be set to 0. Bernardos Expires December 15, 2014 [Page 15] Internet-Draft PMIPv6 flow mobility June 2014 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|U|F| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Two new flags (U) and (F) are included in the PBA message to indicate whether Update Notifications for Proxy Mobile IPv6 (UPN) [RFC7077] is supported or not. The flag (U) MUST be set to the value of 1 if UPN is supported, otherwise the flag MUST be set to 0. The flag (F) MUST be set to the value of 1 if Flow indication message is supported, otherwise the flag MUST be set to 0. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |F|U|K|R|P|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The rest of the proxy binding update message format remains the same as defined in [RFC5213]. 4.3. Flow Mobility Initiate (FMI) The LMA sends an FMI message to a MAG to enable flow mobility. It is a Mobility Header message {IANA-1}. Bernardos Expires December 15, 2014 [Page 16] Internet-Draft PMIPv6 flow mobility June 2014 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: A monotonically increasing integer. Set by the LMA sending then initiate message, and used to match a reply in the Acknowledgement. 'I' (initiate) flag: Set to 1, indicates it is an FMI message. Reserved: This field is unused. MUST be set to zero by the sender. Lifetime: The requested time in seconds for which the LMA asks the MAG keep flow-specific state. A value of all one bits (0xffff) represents infinity. If set to 0, it indicates a request to remove state about the flow (cancel flow mobility) Mobility Options: MUST contain the MN-ID, followed by one or more Flow Identification Mobility options [RFC6089]. 4.4. Flow Mobility Acknowledgement (FMA) The MAG sends an FMI message to the LMA as a response to the FMI message. It is a Mobility Header message {IANA-1}. Bernardos Expires December 15, 2014 [Page 17] Internet-Draft PMIPv6 flow mobility June 2014 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| Reserved | Status | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: A monotonically increasing integer. Copied from the value set by the sending LMA in the FMI message being acknowledged by this FMA message. 'I' flag: Set to 0, indicates it is an FMA message. Reserved: This field is unused. MUST be set to zero by the sender. Status (values to be assigned by IANA): {IANA-2}: Success. {IANA-3}: Reason unspecified. {IANA-4}: MN not attached. {IANA-5}: Sequence number out of window. {IANA-6}: Traffic Selector format unsupported. {IANA-7}: No existing Flow Mobility Cache entry. Lifetime: The requested time in seconds for which the MAG keeps flow- specific state. A value of all one bits (0xffff) represents infinity. Bernardos Expires December 15, 2014 [Page 18] Internet-Draft PMIPv6 flow mobility June 2014 Mobility Options: When Status code is 0, MUST contain the MN-ID, followed by one or more Flow Identification Mobility options [RFC6089]. 5. Conceptual Data Structures This section summarizes the extensions to Proxy Mobile IPv6 that are necessary to manage flow mobility. 5.1. Multiple Proxy Care-of Address Registration The binding cache structure of the local mobility anchor is extended to allow multiple proxy care of address (Proxy-CoA) registrations, and support the mobile node use the same address (prefix) beyond a single interface and mobile access gateway. The LMA maintains multiple binding cache entries for an MN. The number of binding cache entries for a mobile node is equal to the number of the MN's interfaces attached to any MAGs. This specification re-uses the extensions defined in [RFC5648] to manage multiple registrations, but in the context of Proxy Mobile IPv6. The binding cache is therefore extended to include more than one proxy care-of addresses and to associate each of them with a binding identifier (BID). Note that the BID is a local identifier, assigned and used by the local mobility anchor to identify which entry of the flow mobility cache is used to decide how to route a given flow. +---------+-----+-------+------+-----------+------------+ | BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | +---------+-----+-------+------+-----------+------------+ | 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) | | 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) | +---------+-----+-------+------+-----------+------------+ Figure 8: Extended Binding Cache Figure 8 shows an example of extended binding cache, containing two binding cache entries (BCEs) of a mobile node MN1 attached to the network using two different access technologies. Both of the two attachments share the same prefix (HNP1) and are bounded to two different Proxy-CoAs (two MAGs). Bernardos Expires December 15, 2014 [Page 19] Internet-Draft PMIPv6 flow mobility June 2014 5.2. Flow Mobility Cache Each local mobility anchor MUST maintain a flow mobility cache (FMC) as shown in Figure 9. The flow mobility cache is a conceptual list of entries that is separate from the binding cache. This conceptual list contains an entry for each of the registered flows. This specification re-uses the format of the flow binding list defined in [RFC6089]. Each enty includes the following fields: o Flow Identifier Priority (FID-PRI). o Flow Identifier (FID). o Traffic Selector (TS). o Binding Identifier (BID). o Action. o Active/Inactive. +---------+-----+-----+------+---------+----------+ | FID-PRI | FID | TS | BIDs | Action | A/I | +---------+-----+-----+------+---------+----------+ | 10 | 2 | TCP | 1 | Forward | Active | | 20 | 4 | UDP | 1,2 | Forward | Inactive | +---------+-----+-----+------+---------+----------+ Figure 9: Flow Mobility Cache The BID field contains the identifier of the binding cache entry which packets matching the flow information described in the TS field will be forwarded to. When a flow is decided to be moved, the affected BID(s) of the table are updated. Similar to flow binding described in [RFC6089], each entry of the flow mobility cache points to a specific binding cache entry identifier (BID). When a flow is moved, the local mobility anchor simply updates the pointer of the flow binding entry with the BID of the interface to which the flow will be moved. The traffic selector (TS) in flow binding table is defined as in [RFC6088]. TS is used to classify the packets of flows basing on specific parameters such as service type, source and destination address, etc. The packets matching with the same TS will be applied the same forwarding policy. FID-PRI is the order of precedence to take action on the traffic. Action may be forward or drop. If a binding entry becomes 'Inactive' it does not affect data traffic. An entry becomes 'Inactive' only if all of the BIDs are deregistered. Bernardos Expires December 15, 2014 [Page 20] Internet-Draft PMIPv6 flow mobility June 2014 The mobile access gateway MAY also maintain a similar data structure. In case no full flow mobility state is required at the MAG, the Binding Update List (BUL) data structure is enough and no extra conceptual data entries are needed. In case full per-flow state is required at the mobile access gateway, it SHOULD also maintain a flow mobility cache structure. 6. Mobile Node considerations This specification assumes that the mobile node IP layer interface can simultaneously and/or sequentially attach to multiple MAGs, possibly over multiple media. The mobile node MUST be able to enforce uplink policies to select the right outgoing interface. One form to achieve this multiple attachment is described in [I-D.ietf-netext-logical-interface-support], which allows the mobile node supporting traffic flows on different physical interfaces regardless of the assigned prefixes on those physical interfaces. 7. IANA Considerations This specification defines a new value for the Handoff Indicator {IANA-0} and a new flag (L) in the Home Network Mobility Option. A new mobility header type {IANA-1} and status code values {IANA-2} to {IANA-7}. 8. Security Considerations The protocol signaling extensions defined in this document share the same security concerns of Proxy Mobile IPv6 [RFC5213] and do not pose any additional security threats to those already identified in [RFC5213] and [RFC7077]. The mobile access gateway and the local mobility anchor MUST use the IPsec security mechanism mandated by Proxy Mobile IPv6 [RFC5213] to secure the signaling described in this document. 9. Authors This document reflects contributions from the following authors (in alphabetical order). Kuntal Chowdhury E-mail: Kchowdhu@cisco.com Vijay Devarapalli E-mail: vijay@wichorus.com Bernardos Expires December 15, 2014 [Page 21] Internet-Draft PMIPv6 flow mobility June 2014 Sri Gundavelli E-mail: sgundave@cisco.com Youn-Hee Han E-mail: yhhan@kut.ac.kr Yong-Geun Hong E-mail: yonggeun.hong@gmail.com Mohana Dahamayanthi Jeyatharan E-mail: mohana.jeyatharan@sg.panasonic.com Rajeev Koodli E-mail: rkoodli@cisco.com Kent Leung E-mail: kleung@cisco.com Telemaco Melia E-mail: Telemaco.Melia@alcatel-lucent.com Bruno Mongazon-Cazavet E-mail: Bruno.Mongazon-Cazavet@alcatel-lucent.com Chan-Wah Ng E-mail: chanwah.ng@sg.panasonic.com Behcet Sarikaya E-mail: sarikaya@ieee.org Tran Minh Trung E-mail: trungtm2909@gmail.com Frank Xia E-mail: xiayangsong@huawei.com Bernardos Expires December 15, 2014 [Page 22] Internet-Draft PMIPv6 flow mobility June 2014 10. Acknowledgments The authors would like to thank Juan-Carlos Zuniga, Pierrick Seite, Julien Laganier for all the useful discussions on this topic. The authors would also like to thank Marco Liebsch and Juan-Carlos Zuniga for their reviews of this document. The work of Carlos J. Bernardos has also been partially supported by the European Community's Seventh Framework Programme under grant agreement n. FP7-317941 (iJOIN project). 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC 5846, June 2010. [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011. [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and J. Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 7077, November 2013. 11.2. Informative References Bernardos Expires December 15, 2014 [Page 23] Internet-Draft PMIPv6 flow mobility June 2014 [I-D.ietf-netext-logical-interface-support] Melia, T. and S. Gundavelli, "Logical Interface Support for multi-mode IP Hosts", draft-ietf-netext-logical- interface-support-09 (work in progress), March 2014. Author's Address Carlos J. Bernardos (editor) Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Bernardos Expires December 15, 2014 [Page 24]