NETLMM Working Group Rajeev. Koodli Internet-Draft Kuntal. Chowdhury Intended status: Standards Track Starent Networks Expires: April 17, 2010 October 14, 2009 Flow Handover for Proxy Mobile IPv6 draft-koodli-netext-flow-handover-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 17, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract With interface multihoming, Mobile Nodes are capable of simultaneous attachment to multiple radio access networks. This enables a network node such as the Local Mobility Anchor to distribute the application Koodli & Chowdhury Expires April 17, 2010 [Page 1] Internet-Draft Flow Handover October 2009 traffic to interfaces that can best serve them. This document specifies a network-controlled protocol to handover application flows from one interface to another. Such control could provide better experience for end users and better traffic management for network operators. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Flow Handover Request (FHRQ) . . . . . . . . . . . . . . . 6 4.2. Flow Handover Reply (FHRP) . . . . . . . . . . . . . . . . 7 4.3. Mobility Options . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. IPv6 Address/Prefix . . . . . . . . . . . . . . . . . 8 4.3.2. IPv4 Address . . . . . . . . . . . . . . . . . . . . . 8 4.3.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . 8 4.3.4. QoS Parameters . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Koodli & Chowdhury Expires April 17, 2010 [Page 2] Internet-Draft Flow Handover October 2009 1. Introduction Interface multihoming is becoming increasingly common. Mobile Nodes are being equipped with multiple Wide Area Network (WAN) radios as well as Local Area Network (LAN) radio (such as WiFi). In a Proxy Mobile IPv6 domain [RFC5213], a single Local Mobility Anchor (LMA) could support a Mobile Node (MN) which is simultaneously attached to multiple Mobility Access Gateways (MAGs) through multiple interfaces. The PMIP6 protocol provides the mobility support in such an enviroment when a MN actually changes its network interfaces. This document specifies a protocol between the LMA and a MAG to handover one or more application flows from an interface to another even when the MN does not physically switch its network interface. Flow handover, in which a network entity induces handover for one or more application flows, could provide better network experience for end users by transparently moving an application flow to the network that can best serve the particular application flow. Flow handover could also enable a network operator to dynamically balance the load appropriately depending on the availability of network capacity. For example, the LMA may induce a handover for "www" application from cellular radio to WiFi, while retaining the VoIP on the cellular network. This document assumes that handover control logic resides at the LMA; however, the trigger for protocol could initiate from the MAG. The LMA maintains appropriate policy profiles that describe the applications and networks that best serve them. The LMA also has access to MN-specific policy information. Details of such policy profiles are beyond the scope of this document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in this document are to be interpreted as described in RFC 2119 [RFC2119]. The document uses the terminology specified in [RFC5213] and in [RFC3775]. In addition, this document defines the following: Flow Handover: Network-initiated handover of one or more application flows from one network interface to another, without necessarily requiring the change of network interface at the MN. Flow Handover Request (FHRQ): A message sent by the LMA requesting a MAG to establish forwarding for one or more application flows of a MN. Koodli & Chowdhury Expires April 17, 2010 [Page 3] Internet-Draft Flow Handover October 2009 Flow Handover Reply (FHRP): A reply from the MAG to the LMA containing the resolution of FHRQ message. Source MAG (S-MAG): The Mobility Access Gateway where a MN originates its application flow. Target MAG (T-MAG): The Mobility Access Gateway to which the LMA relocates one or more application flows (from the S-MAG). 3. Protocol The protocol specified here assumes that a MN has simultaneous connectivity with multiple networks which are anchored at the same LMA. Hence, the LMA maintains multiple PMIP6 session bindings corresponding to each of the attachments, containing unique IPv6 Home Network Prefixes and/or IPv4 Home Addresses. A special case for the protocol specified here is when the same HNP is used across multiple interfaces; the behavior is the same as described in the following. When a new application flow is initiated (e.g., either through out of band signaling or through connection set up as in TCP) the LMA verifies whether the application flow is "best-mapped" to interfaces that could serve them. This verification could be based on the application policy profiles (that could specify the priority ordering of networks best-suited to support the applications) and the MN- specific policy profiles (which are dependent on the subscription records). Both application profiles and MN-specific profiles are operator-configurable, and are not specified in this document. In any case, if the application flows are already best-mapped to their corresponding interfaces, the LMA does nothing. If not, this verification serves as a flow handover trigger for further protocol actions described in the following. As a response to the flow handover trigger, the LMA constructs a Flow Handover Request (FHRQ) message containing the MN-Identifier and a flow tuple (including the IPv6 HNP/IPv4 HoA, transport protocol port numbers and QoS parameters for uplink and downlink) to the target MAG (T-MAG). Note that such a flow tuple is established on the source MAG (S-MAG), and hence is likely to have HNP and IPv4 HoA different from the ones allocated for the MN on the target MAG. The LMA sends the FHRQ message to the T-MAG. The T-MAG verifies that it can support the requested flow. It then creates a Flow Forwarding Entry (FFE) that contains the parameters provided by the LMA in the FHRQ message. The FFE is in addition to Koodli & Chowdhury Expires April 17, 2010 [Page 4] Internet-Draft Flow Handover October 2009 the Binding Update List Entry (BULE) that the MAG may have for the MN. The FFE is used to forward packets for the specified flow only; however, wildcard parameters may be used to identify a set of flows. The flow forwarding is not permanent. For instance, the LMA may send a FHRQ message with a request to terminate an existing FFE. Such a message may be generated as a result of termination of an application flow. The flow forwarding also has a default lifetime, upon the expiry of which the forwarding reverts to the normal PMIP6-based tunneling (involving the LMA and the source MAG). When flow forwarding service ceases, the corresponding FFE entries MUST be removed. The T-MAG provides a resolution of the FHRQ processing in the Flow Handover Reply (FHRP) message. This Mobility Header message includes the MN-IDentifier and flow tuple (including the IPv6 HNP/IPv4 HoA, transport protocol port numbers and QoS parameters for uplink and downlink) as well as an appropriate Status code disposing the outcome of FHRQ processing. Status code 0 indicates flow forwarding is offered by the T-MAG. Any other value for Status code indicates the reason for not offering the flow forwarding service. When Status code in FHRP is 0, the LMA creates its own Flow Forwarding Entry (FFE). The FFE over-rides the BCE for the identified application flow(s). In other words, application traffic matching the flow tuple is forwarded to T-MAG. Only the subset of the application traffic that matches the flow parameters is forwarded to T-MAG; the rest of the traffic is sent to S-MAG according to the BCE. At any point in time, the T-MAG may send an Unsolicited FHRP (U-FHRP) message to indicate events such as FFE lifetime renewal or a MN moving out of coverage. The LMA sends an FHRQ message to confirm the renewal of FFE lifetime. When the event indicates a MN moving out of coverage, the LMA sends FHRQ to cancel an existing flow forwarding service. In any case, the T-MAG MUST wait for the FHRQ message to confirm the corresponding action by the LMA before concluding on its own. When flow forwarding service is cancelled, forwarding takes place according to the normal PMIP6 tunneling. The decision to handover the flow from one interface to another may be conveyed to the MN using access-specific signaling. In the absence of such signaling, the MN needs to be prepared to accept packets on an interface other than the one which initiated the application flow in the first place. Koodli & Chowdhury Expires April 17, 2010 [Page 5] Internet-Draft Flow Handover October 2009 4. Message Formats 4.1. Flow Handover Request (FHRQ) The LMA sends an FHRQ message to a MAG to request flow handover to one or more application flows of a MN. 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 # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|C| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Flow Handover Request (FHRQ) Message Sequence Number: A monotonically increasing integer. Set by a sending node in a request message, and used to match a reply to the request. 'R' flag: Set to 0, indicates it is an FHRQ message. 'C' flag: When set to 1, indicates a request to cease flow forwarding Reserved: This field is unused. MUST be set zero. Lifetime: The requested time in seconds for which the sender wishes to have flow forwarding. Mobility Options: MUST contain the MN-ID, followed by one or more flow tuples. Each flow tuple consists of the following in the specified order: [IP source address, IP destination address, source port number, destination port number, QoS parameters for uplink, QoS parameters for downlink]. Koodli & Chowdhury Expires April 17, 2010 [Page 6] Internet-Draft Flow Handover October 2009 4.2. Flow Handover Reply (FHRP) The MAG sends an FHRP message to the LMA as a response to the FHRQ 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 # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|U| Reserved | Status | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Flow Handover Reply (FHRP) Message Sequence Number: A monotonically increasing integer. Set by a sending node in a request message, and used to match a reply to the request. 'R' flag: Set to 1, indicates it is an FHRP message. 'U' flag: When set to 1, the FHRP message is sent unsolicited. The Lifetime field indicates a new requested value. Lifetime set to zero indicates that the MN is no longer attached to the MAG. The MAG MUST wait for the regular FHRQ message to confirm that the request is acceptable to the LMA. Reserved: This field is unused. MUST be set zero. Status: 0: Success 1: Failure, unable to establish flow forwarding Lifetime: The time in seconds for which the flow forwarding is supported. Typically copied from the corresponding field in the FHRQ message. Koodli & Chowdhury Expires April 17, 2010 [Page 7] Internet-Draft Flow Handover October 2009 Mobility Options: When Status code is 0, MUST contain the MN-ID and flow tuples in the same order as in the FHRQ message. 4.3. Mobility Options 4.3.1. IPv6 Address/Prefix This option is the same as the Home Network Prefix option specified in [RFC5213]. An address is specified with Prefix Length set to 128 bits. This option is used as the source or destination IP address field in the flow tuple. 4.3.2. IPv4 Address This option is used for an IPv4 flow. It has an alignment requirement of 4n. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved (R) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IPv4 Address 4.3.3. Port Numbers This option is part of the flow tuple, and has an alignment requirement of 4n. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved (R) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source port | destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Port Numbers Koodli & Chowdhury Expires April 17, 2010 [Page 8] Internet-Draft Flow Handover October 2009 4.3.4. QoS Parameters A Per-Hop Behavior (PHB) [RFC3140] Class parameter is defined whose format is the same as in [dime-qos]. New QoS parameters may be defined in the future. 5. Security Considerations The protocol specified in this document uses the same security association between the LMA and the MAG to protect the FHRQ and FHRP messages. No new security risks are identified. Support for integrity protection using IPsec is required, but support for confidentiality is not necessary. 6. IANA Considerations The Flow Handover Request, described in Section 4.1 and the Flow Handover Reply, described in Section 4.2 require a single Mobility Header Type from the registry at http://www.iana.org/assignments/mobility-parameters: 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3140] Black, D. and et. al., "Per Hop Behavior Identification Codes", RFC 3140, June 2001. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [dime-qos] Korhonen, J. and H. Tschofenig, "Quality of Service Parameters for Usage with the AAA Framework", May 2008. 7.2. Informative References [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Koodli & Chowdhury Expires April 17, 2010 [Page 9] Internet-Draft Flow Handover October 2009 Authors' Addresses Rajeev Koodli Starent Networks USA Email: rkoodli@starentnetworks.com Kuntal Chowdhury Starent Networks USA Email: kchowdhury@starentnetworks.com Koodli & Chowdhury Expires April 17, 2010 [Page 10]