NETEXT Working Group CJ. Bernardos, Ed. Internet-Draft UC3M Intended status: Standards Track October 25, 2010 Expires: April 28, 2011 Proxy Mobile IPv6 Extensions to Support Flow Mobility draft-bernardos-netext-pmipv6-flowmob-01 Abstract Proxy Mobile IPv6 (PMIPv6) is a network-based localized mobility management protocol that enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing their IP addresses. PMIPv6 basic specification also provides limited multi- homing support to multi-mode mobile devices. The ability of movement of selected flows from one access technology to another is missing in basic PMIPv6. This document describes enhancements to the Proxy Mobile IPv6 protocol that are required to support flow mobility over multiple physical interfaces. 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 April 28, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Bernardos Expires April 28, 2011 [Page 1] Internet-Draft PMIPv6 flow mobility October 2010 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. Prefix model . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Flow mobility scenarios . . . . . . . . . . . . . . . . . . . 5 4.1. Unique prefix per physical interface . . . . . . . . . . . 5 4.1.1. Unique prefix per physical interface, with full flow granularity . . . . . . . . . . . . . . . . . . . 6 4.1.2. Unique prefix per physical interface, with prefix granularity (partial handoff) . . . . . . . . . . . . 9 4.2. Shared prefix across physical interfaces (per-MN HNP set) . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Message formats . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . . 15 5.2. Flow Mobility Acknowledge (FMA) . . . . . . . . . . . . . 17 6. Local Mobility Anchor considerations . . . . . . . . . . . . . 18 6.1. Sending Flow Mobility Initiate messages . . . . . . . . . 18 6.2. Receiving Flow Mobility Acknowledge messages . . . . . . . 19 6.3. Conceptual Data Structures . . . . . . . . . . . . . . . . 20 6.4. Packet Processing considerations . . . . . . . . . . . . . 22 7. Mobile Access Gateway considerations . . . . . . . . . . . . . 22 7.1. Receiving Flow Mobility Initiate messages . . . . . . . . 22 7.2. Sending Flow Mobility Acknowledge messages . . . . . . . . 24 7.3. Conceptual Data Structures . . . . . . . . . . . . . . . . 24 7.4. Packet Processing considerations . . . . . . . . . . . . . 26 8. Mobile Node considerations . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 Bernardos Expires April 28, 2011 [Page 2] Internet-Draft PMIPv6 flow mobility October 2010 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 an MN to connect to the same PMIPv6 domain through different interfaces. The "logical interface" at the IP layer may enable packet transmission and reception over different physical media. This technique can be used to achieve flow mobility, i.e., the movement of selected flows from one access technology to another. It is assumed that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media). This document specifies a protocol between the LMA and MAGs for distributing specific traffic flows on different physical interfaces. This document assumes that a "logical interface" at the Mobile Node is capable of supporting traffic flows from different physical interfaces regardless of the assigned prefixes on those physical interfaces. In particular, this document specifies how to manage "flow mobility" state in the PMIPv6 network (i.e. LMAs and MAGs), namely creation, refresh and cancel operation. Flow mobility is is controlled and initiated by the LMA. The trigger causing the LMA to initiate a flow mobility operation is out of scope of this specification. 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). Bernardos Expires April 28, 2011 [Page 3] Internet-Draft PMIPv6 flow mobility October 2010 LMA Address (LMAA). Proxy Care-of Address (Proxy-CoA). Home Network Prefix (HNP). The following terms are defined and used in this document: FMI (Flow Mobility Initiate). Message sent by the LMA to create, refresh or cancel flow mobility state in the MAG. It conveys the information required to manage the flow mobility in a PMIPv6- Domain. FMA (Flow Mobility Acknowledge). Message sent by the MAG in reply to an FMI message. It provides feedback about the result of a flow mobility creation, refresh or cancel operation requested in the 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. Prefix model Flow mobility assumes simultaneous access to more than one network, in a contrast to a typical handover where connectivity to a physical medium is relinquished, and is re-established with another. There are multiple prefix models under which a flow mobility protocol needs to work: 1. At the time of a new attachment, the MN obtains a new prefix or a new set of prefixes. This is the default behavior with RFC 5213. 2. At the time of a new 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 in RFC 5213, and the LMA needs to be able to provide the same assignment even for the simultaneous attachment (as opposed to the handover scenario only). 3. At the time of a new attachment, the MN obtains a combination of prefix(es) in use and new prefix(es). This is a hybrid of the above two scenarios. 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. Among the above, scenario 2 needs extensions to RFC 5213 signaling at Bernardos Expires April 28, 2011 [Page 4] Internet-Draft PMIPv6 flow mobility October 2010 the time of a new attachment. Subsequently, no further signaling may be necessary between the LMA and the MAG. The scenario 1 requires flow mobility signaling whenever the LMA determines the need for relocating flows between the different attachments. The scenario 3 requires flow mobility signaling whenever the LMA determines the need for relocating flows for the new prefix(es) which are not shared across attachments. In all the scenarios, the MAGs should be aware of the prefixes for which the MN is going to receive traffic. As a result of a flow mobility operation, these prefixes might not be limited to those delegated by the MAG upon attachment of the connected interface, and therefore signalling is required. The extensions described in this document support any of the three aforemention prefix models. 4. Flow mobility scenarios Flow mobility signaling takes place whenever the LMA decides to move a flow from one access to another. At this point, either the prefix corresponding to the flow is already valid on the target MAG, or it needs to be signaled. If the prefix is already valid, then the LMA simply relocates the flow to the target MAG; no specific signaling is required. For convenience, this scenario is called "shared prefix" scenario. If, at the time LMA decides to perform flow handover, the prefix corresponding to the flow is not valid on the target MAG, the LMA decides invoke flow mobility signaling specified in this document. For convenience, this scenario is called "unique prefix" scenario, since the the target prefix was "unique" to begin with. When there is signaling involved, the granularity of the flow mobility by default is at the prefix level. This means, the MAG only needs to be able to support just the signaled prefix for forwarding traffic, and is not involved detailed flow-level inspection. The granularity of flow mobility MAY include detailed flow descriptors beyond the prefix alone, and MAG implementations MAY support flow- level inspection. 4.1. Unique prefix per physical interface In this scenario, each physical interface of the mobile node is assigned a unique prefix (or set of prefixes). This is the default scenario supported by Proxy Mobile IPv6 as specified in RFC 5213 [RFC5213]. The LMA maintains multiple binding cache entries Bernardos Expires April 28, 2011 [Page 5] Internet-Draft PMIPv6 flow mobility October 2010 (multiple mobility sessions) -- one per physical interface -- as well as routing entries -- one per assigned prefix. This scenario is shown in Figure 1. LMA Binding Cache +---+ ======================= |LMA| MN1, if1, pref1, MAG1 +---+ MN1, if2, pref2, MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | +-------+ | | | I P | | | +-------+ | | | lif | | | +---+---+ | |---|if1|if2|----| +---+---+ MN1 Figure 1: Unique prefix per physical interface scenario In Figure 1, a mobile node (MN1) has two different physical interfaces (if1 and if2), grouped in a unique logical interface (lif). Each physical interface is attached to a different MAG, both of them anchored and controlled by the same LMA. Since each physical interface is assigned a different prefix upon attachment (pref1 upon attachment to MAG1 and pref2 upon attachment to MAG2), the mobile node has two different IPv6 addresses configured on the logical interface: pref1::lif and pref2::lif. 4.1.1. Unique prefix per physical interface, with full flow granularity In this particular sub-scenario, full flow mobility management granularity is supported, meaning that the LMA is able to perform per-flow routing through different MAGs (e.g., in the example above, HTTP traffic/particular flow intended to pref1::lif can be routed through MAG1, while VoIP traffic/particular flow intended to the same MN IP addess -- pref1::lif -- can be routed via MAG2). Bernardos Expires April 28, 2011 [Page 6] Internet-Draft PMIPv6 flow mobility October 2010 In this scenario, the LMA controls how flows are routed from the LMA to the MN, and therefore, through which interface the MN receives packets from different flows. If the LMA decides to move a particular flow from its default path (which is determined in this scenario by the destination prefix) to a different one, it constructs a Flow Mobility Initiate (FMI) message. This message is sent to the new target MAG, i.e. the one selected to be the used in the forwarding of the flow. The LMA can decide on which is the best MAG that should be used to forward a particular flow when the flow is initiated (e.g., based on application policy profiles) and/or during the lifetime of the flow upon receiving a trigger either based on network status or based on an event detected at the mobile node. How this decision is taken is out of scope of this specification. The FMI message contains (as explained in further detail in Section 5.1), the MN-Identifier, the Flow Identification Mobility option (specified in [I-D.ietf-mext-flow-binding]) which can convey prefix or full flow information, and the type of flow mobility operation (add flow). +-----+ +------+ +------+ +-----+ Internet | LMA | | MAG1 | | MAG2 | | MN1 | +-----+ +------+ +------+ +-----+ | | | | | | flow X to | flow X to | flow X to | | pref1:lif | pref1:lif | pref1:lif | |<----------->|<--------------->|<-------------------------->if1 | flow Y to | flow Y to | flow Y to | | pref2:lif | pref2:lif | pref2:lif | |<----------->|<------------------------------->|<---------->if2 | | | | | | LMA decision | | | | to move flow Y | | | | | FMI[MN1-ID,flow_info(Y),add] | | | |---------------->| | | | | FMA | | | | |<----------------| | | | LMA moves | | | | flow Y | | | | | (optional) | | | | FMI[MN1-ID,flow_info(Y),del] | | | |-------------------------------->| | | | | FMA | | | |<--------------------------------| | | flow Y to | flow Y to | flow Y to | | pref2:lif | pref2:lif | pref2:lif | |<----------->|<--------------->|<-------------------------->if1 | | | | | Figure 2: Flow mobility signaling for the unique prefix per physical Bernardos Expires April 28, 2011 [Page 7] Internet-Draft PMIPv6 flow mobility October 2010 interface scenario, with full granularity An example of the signaling sequence is shown in Figure 2. At the beginning MN1 has two active flows: flow X going through interface if1 and MAG1, and flow Y going through interface if2 and MAG2. At a certain moment, the LMA decides to move flow Y from interface if2 to if1. To do so, it sends a FMI message to the MAG1 where if2 (the target interface) is attached to, including the MN-ID and a Flow Mobility Option referring to flow Y. This option is defined in [I-D.ietf-mext-flow-binding] as well as the Traffic selector sub- option, which can be used to fully match a particular flow or just the MN prefix information required by the MAG to be able to route packets to the MN (the MAG by default is only aware of the prefixes delegated to the MN by the LMA upon the MN's interface attachment to the MAG, but is not aware of other MN's prefixes assigned to different interfaces). Upon reception of the message, MAG1 checks if it can forward flow Y, adds the required forwarding state so packets belonging to flow Y are delivered via the if1, and replies back to the LMA with an FMA message. Upon reception of this FMA message from MAG1, the LMA moves flow Y towards MAG1. Optionally, the LMA 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. Bernardos Expires April 28, 2011 [Page 8] Internet-Draft PMIPv6 flow mobility October 2010 LMA Binding Cache LMA flowmob state +---+ ======================= =================== |LMA| MN1, if1, pref1, MAG1 MN1, flow X, MAG1 +---+ MN1, if2, pref2, MAG2 MN1, flow Y, MAG1 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ MAG1 routing state +----+ +----+ ================================ |MAG1| |MAG2| (dest) (next hop) +----+ +----+ pref1::/64 p2p-iface-with-MN1 | | ::/0 LMA | +-------+ | pref2::/64 p2p-iface-with-MN1 | | I P | | | +-------+ | MAG2 routing state | | lif | | ================================ | +---+---+ | (dest) (next hop) |---|if1|if2|----| pref2::/64 p2p-iface-with-MN1 +---+---+ ::/0 LMA MN1 Figure 3: Unique prefix per physical interface scenario, with full flow granularity Figure 3 shows the state of the different network entities after moving flow Y in the previous example. 4.1.2. Unique prefix per physical interface, with prefix granularity (partial handoff) In this particular sub-scenario, only prefix mobility management granularity is supported (partial handover), meaning that it involves only transferring one (or some, but not all) of the prefixes that are allocated to an existing interface to a newly powered on interface. This is particularly useful if the second interface is a newly connected interface, since that means there is no need for a new prefix to be allocated to the second interface. It is also useful in deployments where the operator requires only granularity of prefix instead of 5-tuples for flow mobility management, possibily due to it being less complex and having less impact to existing infrastructure. One example of operators needing only prefix granularity is 3GPP. In such partial transfer of prefix(es) scenario (refered to as "partial handoff"), the target MAG will initiate the partial handoff Bernardos Expires April 28, 2011 [Page 9] Internet-Draft PMIPv6 flow mobility October 2010 trigger using the PBU message towards the LMA. The PBU will carry the prefix(es) to be transferred in single or multiple HNP options. The partial handoff PBU message will additionally carry a new handoff indication option to indicate to the LMA that this PBU is for partial handoff of sub set of prefix(es). The LMA upon seeing this PBU from the target MAG with the partial handoff trigger embedded will update its binding cache entries. The LMA will remove the transferred prefix(es) from the binding cache associated with the connected interface and create a new binding cache for the newly powered on interface. The LMA may optionally send a message to source MAG to remove the transferred prefix(es). This message can be a Binding Revocation Indication message [RFC5846] with the P bit set to indicate that this is revocation of PMIP prefix(es). After processing BRI, the source MAG will send a Binding Revocation Acknowledgement (BRA) message back to LMA. An example of the signaling sequence is shown in Figure 4. Bernardos Expires April 28, 2011 [Page 10] Internet-Draft PMIPv6 flow mobility October 2010 +-----+ +------+ +------+ +-----+ Internet | LMA | | MAG1 | | MAG2 | | MN | +-----+ +------+ +------+ +-----+ | | | | | | flow X to | flow X to | flow X to | | pref1:lif | pref1:lif | pref1:lif | |<----------->|<--------------->|<-------------------------->if1 | flow Y to | flow Y to | flow Y to | | pref2:lif | pref2:lif | pref2:lif | |<----------->|<--------------->|<-------------------------->if1 | | | | | | | | | | | | | MN powers on if2 and | | | perform a L2 attachment | | | |<-----------if2 | | PBU(pref2,HI=IANA-1) | | | |<--------------------------------| | | | PBA(pref2,HI=IANA-1) | | | |-------------------------------->| | | LMA moves pref2 to new | | | | binding cache entry for if2 | | | | | | | | | | | | | | | (optional) | | | | | BRI[pref2] | | | | |---------------->| | | | | BRA | | | | |<----------------| | | | flow y to | flow y to | flow y to | | pref2:lif | pref2:lif | pref2:lif | |<----------->|<------------------------------->|<---------->if2 | | | | | Figure 4: Message Sequence for Partial Handoff to a New Interface In Figure 4, MAG1 is considered to proxy/advertise the two prefixes pref1 and pref2 that are assigned to if1 of the mobile node. From Figure 4 it can be seen that 2 flows (flow x, flow y) tied to prefixes pref1 and pref2 respectively are present. When the MN detects the availability of another access (e.g. WLAN access), it performs L2 attachment with MAG2 via this new access. MAG2 may receive a partial handoff trigger together with the L2 attachment. This trigger can be sent by other network entities (e.g. context transfer from MAG1 or a policy server) or sent via a layer 2 (L2) trigger from the MN during attachment. This partial handoff trigger will indicate transfer of pref2. When MAG2 receives the trigger for transfer of pref2, it will send a Bernardos Expires April 28, 2011 [Page 11] Internet-Draft PMIPv6 flow mobility October 2010 PBU message to the LMA with pref2 in the HNP option and a new value IANA-1 for the HI option. This new Handoff Indicator value IANA-1 indicates that this is a partial handoff to a new interface. When the LMA receives this PBU message, it will perform the following actions. The LMA will first locate an existing binding cache entry for mobile node with pref2. If the binding cache entry is present, the LMA will remove the pref2 from this existing entry, and insert the pref2 in the newly created binding cache entry for if2. MAG1 can optionally be informed to stop proxying for the pref2. This can be done by LMA sending a BRI notification to MAG1 to revoke pref2. MAG1 upon receiving the BRI will send a BRA back to the LMA as shown in Figure 4. After the partial handoff is completed, the new binding cache entry created for if2 will have pref2 assigned and the binding cache entry for if1 will have pref1. This is shown in Figure 5. LMA Binding Cache +---+ ======================= |LMA| MN, if1, pref1, MAG1 +---+ MN, if2, pref2, MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ MAG1 routing state +----+ +----+ ================================ |MAG1| |MAG2| (dest) (next hop) +----+ +----+ pref1::/64 p2p-iface-with-MN1 | | ::/0 LMA | +-------+ | | | I P | | | +-------+ | MAG2 routing state | | lif | | ================================ | +---+---+ | (dest) (next hop) |---|if1|if2|----| pref2::/64 p2p-iface-with-MN1 +---+---+ ::/0 LMA MN Figure 5: After Partial Handoff of pref2 Bernardos Expires April 28, 2011 [Page 12] Internet-Draft PMIPv6 flow mobility October 2010 4.2. Shared prefix across physical interfaces (per-MN HNP set) In this scenario, physical interfaces of the mobile node are assigned the same prefix (or set of prefixes). The LMA maintains multiple binding cache entries (multiple mobility session) -- one per physical interface -- but they share the same HNP. How the shared prefix is routed by the LMA when there is no flow-specific state is left up to the implementation. This scenario is shown in Figure 6. Extensions to base PMIPv6 protocol as defined in RFC5213 are required to allow the LMA decide to assign the same prefix to a different interface of an MN already attached to the PMIPv6 domain. There are different options that might be used to enable this scenario. While this is still TBD, one simple approach that can be assumed is the following. The LMA MAY know by using any mechanisms out-of-the-scope of this document that an MN has to be assigned the same prefix upon attachment of different interfaces (e.g. by consulting the MN's profile). LMA Binding Cache +---+ ======================= |LMA| MN1, if1, pref1, MAG1 +---+ MN1, if2, pref1, MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | +-------+ | | | I P | | | +-------+ | | | lif | | | +---+---+ | |---|if1|if2|----| +---+---+ MN1 Figure 6: Shared prefix across physical interfaces scenario In Figure 6, a mobile node (MN1) has two different physical interfaces (if1 and if2), grouped in a unique logical interface (lif). Each physical interface is attached to a different MAG, both Bernardos Expires April 28, 2011 [Page 13] Internet-Draft PMIPv6 flow mobility October 2010 of them anchored and controlled by the same LMA. Since both physical interfaces are assigned the same prefix (pref1) upon attachment to the MAGs, the mobile node has one single IPv6 addresses configured on the logical interface: pref1::lif. In this scenario, the LMA also decides how flows are routed from the LMA to the MN, and therefore, through which interface the MN receives packets from different flows. +-----+ +------+ +------+ +-----+ Internet | LMA | | MAG1 | | MAG2 | | MN1 | +-----+ +------+ +------+ +-----+ | | | | | | flow X to | flow X to | flow X to | | pref1:lif | pref1:lif | pref1:lif | |<----------->|<--------------->|<-------------------------->if1 | flow Y to | flow Y to | flow Y to | | pref1:lif | pref1:lif | pref1:lif | |<----------->|<------------------------------->|<---------->if2 | | | | | | LMA decision | | | | to move flow Y (optional) | | | | FMI[MN1-ID,flow_info(Y),add] | | | |---------------->| | | | | FMA | | | | |<----------------| | | | LMA moves | | | | flow Y | | | | | (optional) | | | | FMI[MN1-ID,flow_info(Y),del] | | | |-------------------------------->| | | | | FMA | | | |<--------------------------------| | | flow Y to | flow Y to | flow Y to | | pref1:lif | pref1:lif | pref1:lif | |<----------->|<--------------->|<-------------------------->if1 | | | | | Figure 7: Flow mobility signaling for the shared prefix across physical interfaces scenario An example of the signaling sequence is shown in Figure 7. The operation is analogous to the case of a unique prefix per physical interface. Note that in this scenario, if the target MAG does not need to perform flow-specific actions (e.g., QoS or accounting), the FMI/FMA signaling could be avoided, as no new routing state is required to forward a moved flow (since the prefix assigned to all physical interfaces is the same). Bernardos Expires April 28, 2011 [Page 14] Internet-Draft PMIPv6 flow mobility October 2010 LMA Binding Cache LMA flowmob state +---+ ======================= =================== |LMA| MN1, if1, pref1, MAG1 MN1, flow X, MAG1 +---+ MN1, if2, pref1, MAG2 MN1, flow Y, MAG1 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ MAG1 routing state +----+ +----+ ================================ |MAG1| |MAG2| (dest) (next hop) +----+ +----+ pref1::/64 p2p-iface-with-MN1 | | ::/0 LMA | +-------+ | | | I P | | MAG2 routing state | +-------+ | ================================ | | lif | | (dest) (next hop) | +---+---+ | pref1::/64 p2p-iface-with-MN1 |---|if1|if2|----| ::/0 LMA +---+---+ MN1 Figure 8: Shared prefix across physical interfaces scenario Figure 8 shows the state of the different network entities after moving flow Y in the previous example. 5. Message formats 5.1. Flow Mobility Initiate (FMI) The LMA sends an FMI message to a MAG to inform about a particular flow movement. It is a Mobility Header message. Bernardos Expires April 28, 2011 [Page 15] Internet-Draft PMIPv6 flow mobility October 2010 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|C|R| 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 acknowledge. 'I' (initiate) flag: Set to 1, indicates it is an FMI message. 'C' (cancel) flag: When set to 1, indicates a request to remove state about the flow (cancel flow mobility). If set to 1, the Lifetime field MUST be set to 0. 'R' (refresh) flag: When set to 1, indicates a request to refresh state about the flow. If the 'C' flag is set to 1, this flag should be set to 0 by the sender and ignored by the receiver. 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. Mobility Options: Bernardos Expires April 28, 2011 [Page 16] Internet-Draft PMIPv6 flow mobility October 2010 MUST contain the MN-ID, followed by one or more Flow Identification Mobility options [I-D.ietf-mext-flow-binding]. 5.2. Flow Mobility Acknowledge (FMA) The MAG sends an FMI message to the LMA as a response to the FMI message. It is a Mobility Header message. 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: 0: Success. 128: Reason unspecified. 129: MN not attached. 130: Sequence number out of window. Bernardos Expires April 28, 2011 [Page 17] Internet-Draft PMIPv6 flow mobility October 2010 131: Traffic Selector format unsupported. 132: No existing Flow Mobility Cache entry. 133: Already 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. Mobility Options: When Status code is 0, MUST contain the MN-ID, followed by one or more Flow Identification Mobility options [I-D.ietf-mext-flow-binding]. 6. Local Mobility Anchor considerations This specification allows the LMA to control the distribution of specific traffic flows on different physical interfaces. This section details the LMA operations necessary to implement this specification. 6.1. Sending Flow Mobility Initiate messages This specification allows the LMA to control and dynamically change the path used to deliver packets belonging to specific flows. This enables the LMA to have different forwarding rules for particular flows, in addition to the routes created upon regular PMIPv6 registration. When creating a new Flow Mobility Cache entry (i.e. adding a new forwarding rule to allow flow traffic follow a different path from the one created upon regular PMIPv6 registration for the same destination prefix), the LMA includes the information needed to match the data packets to a specific flow in a Flow Identification Mobility option. This option MUST be included in an FMI message. This FMI message MUST have the cancel ('C') and refresh ('R') flags set to zero indicate that the FMI refers to a new flow. The FMA message MUST also include the MN-Identifier option of the mobile node the flow information refers to. More than one Flow Identification Mobility options MAY be included in the FMI message, but all of them MUST be subject to the same type of operation (e.g., creation of new mobility state). The LMA MUST create the corresponding Flow Mobility Cache entry upon receiving an FMA message with Status set to Success. Bernardos Expires April 28, 2011 [Page 18] Internet-Draft PMIPv6 flow mobility October 2010 When canceling existing Flow Mobility state in the network (i.e. falling back to the default packet forwarding based solely on per HNP destination tunnels between LMA and MAG), the LMA sends an FMI message including the Flow Identification Mobility option(s) that refer to the flow(s) whose associated state is to be removed. This FMI message MUST have the cancel ('C') flag set to 1, and MUST include the MN-Identifier option. The LMA MAY decide to remove the corresponding Flow Mobility Cache entry at the MAG by sending this explicit signaling or by relying on the expiration of the associated timers. The LMA MUST refresh the flow mobility state (i.e. FMC entry) at the MAG to prevent the MAG to stop forwarding specific flows upon expiration of the associated timers. When refreshing flow mobility state, the LMA sends an FMI message including the Flow Identification Mobility option(s) that refer to the flow(s) whose associated state is to be refreshed. This FMI message MUST have the refresh ('R') flag set to 1, and MUST also include the MN-Identifier option. EDITOR's NOTE: Retransmissions and Rate Limiting considerations TBD. The IPv6 source address of an FMI message MUST be the LMA Address (LMAA). The destination IPv6 address of the FMI message MUST be set to the Proxy-CoA of the MAG which will create/cancel/refresh flow mobility state as indicated in the FMI message. Security considerations stated in Section 4 of [RFC5213] "Proxy Mobile IPv6 Protocol Security" apply also for the signalling specified in this document. EDITOR's NOTE: Additional authentication and security requirements (if any) TBD. 6.2. Receiving Flow Mobility Acknowledge messages Upon receiving a packet carrying a Flow Mobility Acknowledge, an LMA MUST validate the packet according to the following tests: o The packet meets the authentication requirements for Flow Mobility Acknowledges defined in Section XXX (TBD). o The IPv6 source address of the packet corresponds to the address of a MAG known by the LMA (NOTE: this is probably redundant once the security details are included). o The Sequence Number field matches the Sequence Number sent by the LMA to this destination address in an outstanding Flow Mobility Initiate. Bernardos Expires April 28, 2011 [Page 19] Internet-Draft PMIPv6 flow mobility October 2010 Any Flow Mobility Acknowledge not satisfying all of these tests MUST be silently ignored. When an LMA receives a packet carrying a valid Flow Mobility Acknowledge, the LMA MUST examine the Status field as follows: o If the Status field indicates that the Flow Binding Initiate was accepted (the Status field is less than 128), then the LMA MUST update the corresponding entry (or entries) in its Flow Mobility Cache, to indicate that the Flow Mobility Initiate has been acknowledged. The LMA MUST then stop retransmitting the FMI message. In addition, if the value specified in the Lifetime field in the FMA is less than the Lifetime value sent in the FMI being acknowledged, the LMA MUST substract the difference between these two values from the remaining lifetime for the flow binding as maintained in the corresponding Flow Mobility Cache entry. LMAs SHOULD send a new FMI well before the expiration of this period in order to extend the lifetime. This helps to avoid disruptions in communications which might otherwise be caused by network delays or clock drift. o If the Status Field indicates that the flow binding operation was rejected (the Status field is greater than or equal to 128), then the LMA can take steps to correct the cause of the error and retransmit the FMI (with a new Sequence Number value) subject to the rate limiting restrictions specified in Section XXX. If this is decided not to be done or it fails, then the LMA SHOULD record in its Flow Mobility Cache that future FMIs SHOULD NOT be sent to this destination. These considerations are of particular importance in case of creation/refresh of flow mobility state. o Additionally, for those Flow Mobility Cache entries that are newly created (not refreshed), the LMA MUST perform the actions required to ensure that the data packets matching the flow filters carried in the Traffic Selector sub-options are forwarded via the appropriate MAG. How this is done is left up to the implementation of the LMA. 6.3. Conceptual Data Structures Each Local Mobility Anchor MUST maintain a Flow Mobility Cache. The Flow Mobility Cache MAY be implemented in any manner consistent with the external behavior described in this document. When sending a packet, the Flow Mobility Cache is searched before the Neighbor Discovery conceptual Destination Cache. Each Flow Mobility Cache entry conceptually contains the following Bernardos Expires April 28, 2011 [Page 20] Internet-Draft PMIPv6 flow mobility October 2010 fields: o The MN-Identifier of the mobile node for the flow this entry refers to. This field is used as primary key for searching the cache for update operations (deletion, refresh, cancel). o The flow filter information carried in the Traffic Selector sub- option. This information SHOULD be stored in a format that allows the LMA to forward packets matching the filter to the corresponding MAG (as indicated by the Proxy-CoA field stored in the Flow Mobility Cache entry). o The Proxy-CoA for which that the FMI carrying the information about this flow was sent. o The tunnel interface identifier (tunnel-if-id) of the bi- directional between the LMA and the MAG that MUST be used when forwarding packets belonging to the flow this entry refers to. This is internal to the local mobility anchor. The tunnel interface identifier is acquired during the tunnel creation in the standard Proxy Mobile IPv6 registration. o The initial value of the Lifetime field sent in the FMI. o The remaining lifetime of that flow binding. The lifetime value is initialized from the Lifetime field in the FMA that created or last modified this entry and is decremented until it reaches zero, at which time this entry MUST be deleted from the Flow Mobility Cache. o The maximum value of the Sequence Number field received in previous FMAs for this flow. The Sequence Number field is 16 bits long. Sequence Number values MUST be compared modulo 2**16 as explained in Section 9.5.1 of [RFC3775]. o The time at which an FMI was last sent regarding to this flow, as needed to implement the rate limiting restriction for sending FMIs. o The state of any retransmissions needed for FMIs referring to this flow. This state includes the time remaining until the next retransmission attempt for the FMI and the current state of the exponential back-off mechanism for retransmissions. o A flag specifying whether or not future FMIs should be sent to this destination. The Flow Mobility Cache is used to determine whether a particular Bernardos Expires April 28, 2011 [Page 21] Internet-Draft PMIPv6 flow mobility October 2010 packet belongs to a flow which has flow mobility state created -- and therefore needs to be processed separately from the rest of the packets -- or it can just be sent using normal packet processing rules as specified in RFC 5213. 6.4. Packet Processing considerations The LMA MUST be able to forward packets matching the flow filters stored in the Flow Mobility Cache (carried in Traffic Selector sub- options inside the Flow Identification Mobility option carried in the FMIs) via the corresponding bi-directional tunnel. For those packets with no matching Flow Mobility Cache, default PMIPv6 data forwarding considerations MUST be followed. How the LMA ensures per-flow forwarding is left up to the particular implementation of the LMA. 7. Mobile Access Gateway considerations This section details the MAG operations necessary to implement this specification. 7.1. Receiving Flow Mobility Initiate messages This specification allows the MAG to deliver packets whose destination address could not match any destination network hosted at any interface of the MAG (i.e. a connected interface for that prefix) or sent by a mobile node with no matching binding. This enables the MAG to deliver/forward packets to/from IPv6 addresses that would not be known by a MAG not conforming to this specification. Upon receiving a packet carrying a Flow Mobility Initiate, a MAG MUST validate the packet according to the following tests: o The packet meets the authentication requirements for Flow Mobility Initiates defined in Section XXX (TBD). o The IPv6 source address of the packet corresponds to the address of an LMA known by the MAG (NOTE: this is probably redundant once the security details are included). o The FMI contains one and only one MN-Identifier mobility option and one or more Flow Identification Mobility options. Any Flow Mobility Initiate not satisfying all of these tests MUST be silently ignored. Bernardos Expires April 28, 2011 [Page 22] Internet-Draft PMIPv6 flow mobility October 2010 In addition, if there is already a Flow Mobility Cache entry for that flow and the Sequence Number field stored in the entry is the same or greater than the sequence number carried in the FMI, then the MAG MUST send back an FMA with status code 127, and the last accepted sequence number in the Sequence Number field of the FMA. When a MAG receives a packet carrying a valid Flow Mobility Initiate, the MAG MUST perform the following packet examinations: o If the MN-Identifier value carried into the FMI does not match any MN known to be connected to the receiving MAG, the MAG MUST send back an FMA with status code 129. o If the format used in any of the Traffic Selector sub-options is not supported by the receiving MAG, the MAG MUST send back an FMA with status code 131. o If the cancel ('C') flag is set to zero, it indicates that the FMI refers to new flow(s). The MAG SHOULD check in the Flow Mobility Cache if there is an entry referring to the flow(s) carried in the FMI. If there is already an entry for a flow with Lifetime greater than 0, then the the MAG SHOULD send back an FMA with status code 133. The MAG MUST create the corresponding Flow Mobility state entry, and send back an FMA with status code 0 following the rules specified in Section 7.2. o If the refresh ('R') flag is set to 1, it indicates that the FMI refers to existing flow(s) whose state is to be refreshed. The MAG SHOULD check in the Flow Mobility Cache if there is an entry referring to the flow(s) carried in the FMI. If there is no entry, then the the MAG SHOULD send back an FMA with status code 132. The MAG MUST update the corresponding Flow Mobility state entry or entries, and send back an FMA with status code 0 following the rules specified in Section 7.2. o If the cancel ('C') flag is set to 1, it indicates that the FMI refers to existing flow(s) whose state is to be removed. The MAG SHOULD check in the Flow Mobility Cache if there is an entry referring to the flow(s) carried in the FMI. If there is no entry, then the the MAG SHOULD send back an FMA with status code 132. The MAG MUST remove the corresponding Flow Mobility state entry or entries, and send back an FMA with status code 0 following the Bernardos Expires April 28, 2011 [Page 23] Internet-Draft PMIPv6 flow mobility October 2010 rules specified in Section 7.2. 7.2. Sending Flow Mobility Acknowledge messages When constructing a packet carrying a Flow Mobility Acknowledge, the MAG MUST follow the following rules: o Security considerations stated in Section 4 of [RFC5213] "Proxy Mobile IPv6 Protocol Security" apply also for the signalling specified in this document. o EDITOR's NOTE: Additional authentication and security requirements (if any) TBD. o The IPv6 source address of the packet corresponds to the egress interface of the MAG used to send the FMA to the LMA. (NOTE: this is probably redundant once the security details are included). o The IPv6 destination address MUST be set to the source address of the FMI being acknowledged. o The Sequence Number field MUST be copied from the Sequence Number given in the FMI. o The Lifetime field MUST be set to the remaining lifetime for the flow binding and MUST NOT be greater than the Lifetime value specified in the FMI. The MAG MAY decide to include a Lifetime value shorter than the one received in the FMI. o The values of the 'C' and 'R' flags MUST be copied from the values given in the FMI. o The Flow Identification Mobility options MUST be copied from the ones given in the FMI. When a valid FMI is received, the MAG MUST update the Flow Mobility Cache entries accordingly as specified above. In addition, the MAG MUST perform the actions required to allow packets received from the LMA matching the flow filters stored in the Flow Mobility Cache to be delivered to the corresponding connected MN. How this forwarding is performed is up to the implementation of the MAG. Some considerations are included in Section 7.4. 7.3. Conceptual Data Structures Each Mobile Access Gateway MUST maintain a Flow Mobility Cache. The Flow Mobility Cache MAY be implemented in any manner consistent with the external behavior described in this document. When sending a Bernardos Expires April 28, 2011 [Page 24] Internet-Draft PMIPv6 flow mobility October 2010 packet, the Flow Mobility Cache is searched before the Neighbor Discovery conceptual Destination Cache. Each Flow Mobility Cache entry conceptually contains the following fields: o The MN-Identifier of the mobile node for the flow this Flow Mobility Cache entry refers to. This field is used as primary key for searching the cache for update operations (deletion, refresh, cancel). o The flow filter information carried in the Traffic Selector sub- option. This information SHOULD be stored in a format that allows the MAG to deliver packets matching the filter to the corresponding MN (using the right interface where the MN is locally connected). o The Proxy-CoA from which that the FMA carrying the information about this flow was sent. o The tunnel interface identifier (tunnel-if-id) of the bi- directional between the LMA and the MAG that MUST be used when forwarding packets sent by the MN and belonging to the flow this entry refers to. This is internal to the MAG. The tunnel interface identifier is acquired during the tunnel creation in the standard Proxy Mobile IPv6 registration. o The interface identifier of the local interface of the MAG that MUST be used when delivering packets sent to the MN and matching the flow this entry refers to. This is internal to the MAG. o The remaining lifetime of that flow binding. The lifetime value is initialized from the Lifetime field in the FMI that created or last modified this entry and is decremented until it reaches zero, at which time this entry MUST be deleted from the Flow Mobility Cache. o The maximum value of the Sequence Number field received in previous FMIs for this flow. The Sequence Number field is 16 bits long. Sequence Number values MUST be compared modulo 2**16 as explained in Section 9.5.1 of [RFC3775]. The Flow Mobility Cache is used to determine whether a particular packet belongs to a flow which has flow mobility state created -- and therefore needs to be processed separately from the rest of the packets -- or it can just be sent using normal packet processing rules as specified in RFC 5213. Bernardos Expires April 28, 2011 [Page 25] Internet-Draft PMIPv6 flow mobility October 2010 7.4. Packet Processing considerations The MAG MUST be able to forward packets matching the flow filters stored in the Flow Mobility Cache (carried in Traffic Selector sub- options inside the Flow Identification Mobility options carried in the FMIs) via the corresponding bi-directional tunnel. For those packets with no match Flow Mobility Cache, default PMIPv6 data forwarding considerations MUST be followed. How the MAG ensures per-flow forwarding is left up to the particular implementation of the MAG. It might happen that the LMA initiates the movement of a flow, by sending the FMI/FMA signalling, but there is no traffic to the MN. In that case, the MN cannot learn which is the uplink interface that should be used. In order to avoid problems in this particular situation, the MAG SHOULD allow uplink traffic to pass through -- even if it does not match the flow filters stored in the FMC (at least for traffic that would be sent through that MAG in case flow mobility was not enabled). 8. Mobile Node considerations This specification assumes the MN implements the logical interface model. The "logical interface" at the IP layer hides the use of different physical media from the IP stack, enabling the MN to send and receive packets over different interfaces. This document assumes the MN behaves as stated in the applicability statement document [I-D.ietf-netext-logical-interface-support]. In particular, it is assumed that the logical interface at the MN "replicates" the behavior observed for downlink packets on a per-flow basis. This means that if packets belonging to flow X are received from interface if1, then the MN sends packets belonging to that flow (in the uplink) also using if1. It also means that if the LMA moves flow X during its lifetime, the MN will follow that change, upon the reception of packets of flow X via a different interface. This specification only supports flow mobility between different physical interfaces belonging to the same logical interface. If an MN has several logical interfaces, flow mobility across different logical interfaces is not supported. 9. IANA Considerations TBD. Bernardos Expires April 28, 2011 [Page 26] Internet-Draft PMIPv6 flow mobility October 2010 10. Security Considerations TBD. 11. Authors This document reflects contributions from the following authors (in alphabetical order). Kuntal Chowdhury E-mail: Kchowdhu@cisco.com Vijay Devarapalli E-mail: vijay@wichorus.com Sri Gundavelli E-mail: sgundave@cisco.com 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 Bernardos Expires April 28, 2011 [Page 27] Internet-Draft PMIPv6 flow mobility October 2010 Behcet Sarikaya E-mail: sarikaya@ieee.org Frank Xia E-mail: xiayangsong@huawei.com 12. Acknowledgments The authors would like to thank Juan-Carlos Zuniga, Pierrick Seite, Julien Laganier for all the discussions on this topic. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC 5846, June 2010. 13.2. Informative References [I-D.ietf-mext-flow-binding] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO Basic Support", draft-ietf-mext-flow-binding-11 (work in progress), October 2010. [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-01 (work in progress), October 2010. Bernardos Expires April 28, 2011 [Page 28] Internet-Draft PMIPv6 flow mobility October 2010 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 April 28, 2011 [Page 29]