NETEXT Working Group CJ. Bernardos, Ed. Internet-Draft UC3M Intended status: Standards Track M. Jeyatharan Expires: January 6, 2011 Panasonic R. Koodli Cisco Systems T. Melia Alcatel-Lucent F. Xia Huawei USA July 5, 2010 Proxy Mobile IPv6 Extensions to Support Flow Mobility draft-bernardos-netext-pmipv6-flowmob-00 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 a mechanism to support flow mobility on a logical interface 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." Bernardos, et al. Expires January 6, 2011 [Page 1] Internet-Draft PMIPv6 flow mobility July 2010 This Internet-Draft will expire on January 6, 2011. Copyright Notice Copyright (c) 2010 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. Bernardos, et al. Expires January 6, 2011 [Page 2] Internet-Draft PMIPv6 flow mobility July 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Flow mobility scenarios . . . . . . . . . . . . . . . . . . . 5 3.1. Unique prefix per physical interface . . . . . . . . . . . 5 3.2. Shared prefix across physical interfaces . . . . . . . . . 8 4. Message formats . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . . 11 4.2. Flow Mobility Acknowledge (FMA) . . . . . . . . . . . . . 13 4.3. Traffic Selector mobility option (TS) . . . . . . . . . . 14 5. Local Mobility Anchor considerations . . . . . . . . . . . . . 15 5.1. Sending Flow Mobility Initiate messages . . . . . . . . . 15 5.2. Receiving Flow Mobility Acknowledge messages . . . . . . . 16 5.3. Conceptual Data Structures . . . . . . . . . . . . . . . . 17 5.4. Packet Processing considerations . . . . . . . . . . . . . 19 6. Mobile Access Gateway considerations . . . . . . . . . . . . . 19 6.1. Receiving Flow Mobility Initiate messages . . . . . . . . 19 6.2. Sending Flow Mobility Acknowledge messages . . . . . . . . 21 6.3. Conceptual Data Structures . . . . . . . . . . . . . . . . 21 6.4. Packet Processing considerations . . . . . . . . . . . . . 23 7. Mobile Node considerations . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Primary contributors . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Bernardos, et al. Expires January 6, 2011 [Page 3] Internet-Draft PMIPv6 flow mobility July 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, et al. Expires January 6, 2011 [Page 4] Internet-Draft PMIPv6 flow mobility July 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. Traffic Selector (TS). Mobility option carrying the flow filters used to match packets with packet flows. 3. Flow mobility scenarios There are two possible scenarios that can be considered: i) unique prefix (or set of prefixes) per physical interface, ii) shared prefix (or set of prefixes) across physical interfaces. We describe next in more detail each of these scenarios and how flow mobility is enabled when using PMIPv6. 3.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 (multiple mobility sessions) -- one per physical interface -- as well as routing entries -- one per assigned prefix. This scenario is shown in Figure 1. Bernardos, et al. Expires January 6, 2011 [Page 5] Internet-Draft PMIPv6 flow mobility July 2010 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. In this scenario, the LMA decides 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 Bernardos, et al. Expires January 6, 2011 [Page 6] Internet-Draft PMIPv6 flow mobility July 2010 FMI message contains (as explained in further detail in Section 4.1), the MN-Identifier, the flow selector (i.e. the n-tuple of parameters that allow to match packets to flows) 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,traffic_spec(Y),add] | | | |---------------->| | | | | FMA | | | | |<----------------| | | | LMA moves | | | | flow Y | | | | | (optional) | | | | FMI[MN1-ID,traffic_spec(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 interface scenario 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 the traffic spec of flow Y. 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 Bernardos, et al. Expires January 6, 2011 [Page 7] Internet-Draft PMIPv6 flow mobility July 2010 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. 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 Figure 3 shows the state of the different network entities after moving flow Y in the previous example. 3.2. Shared prefix across physical interfaces 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 4. How the LMA decides whether to assign the same prefix or a different one is TBD. Bernardos, et al. Expires January 6, 2011 [Page 8] Internet-Draft PMIPv6 flow mobility July 2010 LMA Binding Cache +---+ ======================= |LMA| MN1, if1, pref1, MAG1 +---+ MN1, if2, pref1, MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | +-------+ | | | I P | | | +-------+ | | | lif | | | +---+---+ | |---|if1|if2|----| +---+---+ MN1 Figure 4: Shared prefix across physical interfaces scenario In Figure 4, 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 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. Bernardos, et al. Expires January 6, 2011 [Page 9] Internet-Draft PMIPv6 flow mobility July 2010 +-----+ +------+ +------+ +-----+ 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 | | | | | FMI[MN1-ID,traffic_spec(Y),add] | | | |---------------->| | | | | FMA | | | | |<----------------| | | | LMA moves | | | | flow Y | | | | | (optional) | | | | FMI[MN1-ID,traffic_spec(Y),del] | | | |-------------------------------->| | | | | FMA | | | |<--------------------------------| | | flow Y to | flow Y to | flow Y to | | pref1:lif | pref1:lif | pref1:lif | |<----------->|<--------------->|<-------------------------->if1 | | | | | Figure 5: Flow mobility signaling for the shared prefix across physical interfaces scenario An example of the signaling sequence is shown in Figure 5. 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, et al. Expires January 6, 2011 [Page 10] Internet-Draft PMIPv6 flow mobility July 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 6: Shared prefix across physical interfaces scenario Figure 6 shows the state of the different network entities after moving flow Y in the previous example. 4. Message formats 4.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, et al. Expires January 6, 2011 [Page 11] Internet-Draft PMIPv6 flow mobility July 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, et al. Expires January 6, 2011 [Page 12] Internet-Draft PMIPv6 flow mobility July 2010 MUST contain the MN-ID, followed by one or more Traffic Selector mobility options. 4.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, et al. Expires January 6, 2011 [Page 13] Internet-Draft PMIPv6 flow mobility July 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 Traffic Selector mobility options in the same order as in the FMI message. 4.3. Traffic Selector mobility option (TS) The Traffic Selector is a new mobility option that carries the parameters used to match packets for a specific flow mobility binding. The LMA MUST include 1 or more traffic selector mobility options in an FMI 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Len | TS format | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Selector ... +-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type: To be assigned by IANA. Option Length: Variable. TS format: An 8-bit unsigned integer indicating the Traffic Selector Format. Value "0" is reserved and SHOULD NOT be used. Reserved: Bernardos, et al. Expires January 6, 2011 [Page 14] Internet-Draft PMIPv6 flow mobility July 2010 An 8-bit reserved field. It SHOULD be set to zero by the sender and ignored by the receiver. Traffic Selector: A variable length field, the format and content of which is out of the scope of this specification. The binary formats defined in [I-D.ietf-mext-binary-ts] MAY be used. 5. 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. 5.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 Traffic Selector (TS) mobility option. This TS 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 TS 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. 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 TS 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 Bernardos, et al. Expires January 6, 2011 [Page 15] Internet-Draft PMIPv6 flow mobility July 2010 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 TS 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. 5.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. 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 Bernardos, et al. Expires January 6, 2011 [Page 16] Internet-Draft PMIPv6 flow mobility July 2010 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 options are forwarded via the appropriate MAG. How this is done is left up to the implementation of the LMA. 5.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 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 mobility option. This information SHOULD be stored in a format Bernardos, et al. Expires January 6, 2011 [Page 17] Internet-Draft PMIPv6 flow mobility July 2010 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 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, et al. Expires January 6, 2011 [Page 18] Internet-Draft PMIPv6 flow mobility July 2010 5.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 mobility options inside 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. 6. Mobile Access Gateway considerations This section details the MAG operations necessary to implement this specification. 6.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 Traffic Selector mobility options. Any Flow Mobility Initiate not satisfying all of these tests MUST be silently ignored. 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 Bernardos, et al. Expires January 6, 2011 [Page 19] Internet-Draft PMIPv6 flow mobility July 2010 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 mobility 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 6.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 6.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 rules specified in Section 6.2. Bernardos, et al. Expires January 6, 2011 [Page 20] Internet-Draft PMIPv6 flow mobility July 2010 6.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 Traffic Selector 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 6.4. 6.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 packet, the Flow Mobility Cache is searched before the Neighbor Discovery conceptual Destination Cache. Bernardos, et al. Expires January 6, 2011 [Page 21] Internet-Draft PMIPv6 flow mobility July 2010 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 mobility 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, et al. Expires January 6, 2011 [Page 22] Internet-Draft PMIPv6 flow mobility July 2010 6.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 mobility options inside 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. 7. 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.bernardos-netext-ll-statement]. 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. 8. IANA Considerations TBD. 9. Security Considerations TBD. 10. Primary contributors This document reflects contributions from the following authors (in alphabetical order). Bernardos, et al. Expires January 6, 2011 [Page 23] Internet-Draft PMIPv6 flow mobility July 2010 Kuntal Chowdhury Vijay Devarapalli E-mail: vijay@wichorus.com Kent Leung E-mail: kleung@cisco.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 Sri Gundavelli E-mail: sgundave@cisco.com 11. Acknowledgments TBD. 12. References 12.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. Bernardos, et al. Expires January 6, 2011 [Page 24] Internet-Draft PMIPv6 flow mobility July 2010 12.2. Informative References [I-D.bernardos-netext-ll-statement] Bernardos, C., Zuniga, J., and T. Melia, "Applicability Statement on Link Layer implementation/Logical Interface over Multiple Physical Interfaces", draft-bernardos-netext-ll-statement-01 (work in progress), March 2010. [I-D.ietf-mext-binary-ts] Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", draft-ietf-mext-binary-ts-04 (work in progress), February 2010. Authors' Addresses 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/ Mohana Dahamayanthi Jeyatharan Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG Phone: +65 65505494 Email: mohana.jeyatharan@sg.panasonic.com Rajeev Koodli Cisco Systems USA Email: rkoodli@cisco.com Bernardos, et al. Expires January 6, 2011 [Page 25] Internet-Draft PMIPv6 flow mobility July 2010 Telemaco Melia Alcatel-Lucent Route de Villejust Nozay, Ile de France 91620 FR Email: Telemaco.Melia@alcatel-lucent.com Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Bernardos, et al. Expires January 6, 2011 [Page 26]