NETEXT Working Group Rajeev. Koodli Internet-Draft Cisco Systems Intended status: Standards Track Kuntal. Chowdhury Expires: March 2, 2012 August 30, 2011 Policy Signaling for Multi-access Mobility draft-koodli-policy-multiaccess-mobility-01.txt Abstract The mobile nodes are increasingly capable of simultaneous multi-radio connectivity. This allows them to be attached to the Internet through multiple access technologies at the same time. With such multi-access, the mobile node (MN) can make use of the best-available access technology for a particular application at any given time. And, the network may be able to balance the flow of traffic across the available access technologies. The Mobile IPv6 flow binding work provides a mechanism for the MN to signal the Home Agent to balance the flows based on the MN'e needs. This document specifies a simple protocol for a mobile IP gateway (such as a Mobile IP Home Agent or a Proxy Mobile IP Local Mobility Anchor) to signal the MN of gateway's policy for traffic treatment across access technologies. Based on the response and the prevailing network conditions, the gateway then balances the traffic. 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). 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 March 2, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Koodli & Chowdhury Expires March 2, 2012 [Page 1] Internet-Draft Policy-Based Mobility August 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Flow Policy Request (FPRQ) . . . . . . . . . . . . . . . . 6 4.2. Flow Policy Reply (FPRP) . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Koodli & Chowdhury Expires March 2, 2012 [Page 2] Internet-Draft Policy-Based Mobility August 2011 1. Introduction Mobile Nodes are increasingly able to operate multiple radios simultaneously. This capability allows them to be attached to the Internet through multiple access technologies simultaneously. Such multi-access connectivity can provide a Mobile Node (MN) with better experience by binding flows to the best-available access technologies. From the network point of view, it can provide a better traffic balancing across available access technologies. The design priniciple of existing work on flow binding [RFC6089] follows the original Mobile IP design in which an MN signals the Home Agent (HA) when any mobility action is necessary. This design addresses the problem from the "MN's perspective" and works fine whenever the MN is able to inform the network of flow mobility. The corresponding "Network perspective" to traffic balancing across access technologies is missing. There can be times when the network may wish to indicate the desired policy to the MN based on the overall traffic conditions present at the network. The eventual disposition may still be subject to conditions local to the MN, but the network's preference of traffic type and access type may need to be indicated to the MN. For example, consider that a single prefix is advertised on two different access types. At any given time, how does the MN choose one access type over another for a particular flow, and for how long? This is subject to the policy local to the MN, but the network itself has a role to play in establishing and enforcing such a policy. The network may want the MN to use, subject to connectivity conditions, Access Technology Type X (ATTx) for a set of flows until the next Z seconds, and then revert back to Access Technology Type Y (ATTy) for those flows. There is no mechanism in IP mobility that allows the mobile gateway to express its desired policy for mapping a set of flows to a particular access technology for a certain configrauble duration of time. Policy here is a construct that maps flows to access types for a certain duration of time. This document specifies a protocol that enables 1) an HA to express its policy to a MN, and 2) an LMA to express its policy to a Mobility Anchor Gateway (MAG), which may then relay it to the MN through appropriate L2 signaling. The policy signaling is a Request - Response procedure in which the recipient responds to the expressed policy based on the local conditions. This document specifies the access technology, flow filter and duration for the policy for a particular MN. New policy attributes may be defined in the future. Koodli & Chowdhury Expires March 2, 2012 [Page 3] Internet-Draft Policy-Based Mobility August 2011 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: Access Technology Type (ATT): The type of radio access technology used by the MN. The examples include cellular, WiFi and Femto networks. Flow Handover: Network-initiated handover of one or more application flows from one network interface to another. Flow Filter: a parameter set that identifies a flow. An example wildcard Flow Filter is a Prefix. Flow Policy Request (FPRQ): A message sent by the LMA requesting a MAG to establish forwarding for one or more application flows of a MN for the duration specified. It is also a message sent by the HA to the MN. This message contains one or more flow filters, the target Access Technology Type (ATT) for those flow filters and the time in seconds for which the the flow handover is requested to be valid. Flow Policy Reply (FPRP): A reply from the MAG to the LMA containing the resolution of FPRQ message. Prior to accepting the FPRQ message, the MAG may consult any appropriate entity to ensure that the MN has suitable connectivity conditions for the desired flow mobility. The interaction between the MAG and any other entity is outside the scope of this document. An FPRP is also a reply message from a MN to the HA. Flow Forwarding Entry (FFE): A logical data structure used to store the flow forwarding information as a result of processing the FPRQ and FPRP messages. 3. Protocol The session creation at the LMA follows the basic model of RFC 5213. At the time of attach, one or more prefixes are assigned to the MN corresponding to the ATT. Those prefixes may be common across the ATTs the MN is using or they may be unique to each ATT. When the LMA signals the MAG with an FPRQ message, it is essentially requesting if Koodli & Chowdhury Expires March 2, 2012 [Page 4] Internet-Draft Policy-Based Mobility August 2011 the policy for flow mobility is acceptable to the MAG based on the prevailing network conditions. The policy states that the LMA wants the identified flows be supported over the ATT indicated for the duration specified. The target prefix itself may already be valid on the ATT. However, traffic flow corresponding to that prefix may not be best-suited under the prevailing network conditions. Hence, the LMA verfies if the impending flow mobility is acceptable before actually enforcing it. The conditions permitting, the MAG responds with a Status indicating that flow mobility is acceptable in the FPRP message. The MAG may consult any other network element in order to verify that the access network conditions are acceptable for flow mobility. The MAG MAY inform the MN about the network policy through appropriate L2 signaling. When such L2 signaling is unavailable, the MN MUST be prepared to accept packets on any applicable access technology interface, and transmit the return packets back on the same interface [LI-draft]. When conditions are not suitable for flow handover, the MAG responds with an appropriate Status code in the FPRP message. The LMA MUST NOT handover the flow to the ATT indicated in the FPRQ message. The LMA MAY initiate a new FPRQ message at a later time. The behavior of the protocol for Mobile IPv6 is similar. The HA sends an FPRQ message to the MN indicating the policy preference for a flow. The MN responds with its willingness (or not) with the FPRP message. Once the policy is known, the MN may use the protocol specified in [RFC6089] to actually bind a flow to an access technology interface. The signaling may take place any time. The flow treatment policy is valid for the duration agreed in the signaling exchange or until the next round of signaling exchange. The default policy is provided by the network at the time a mobility session is created using the (Proxy) Binding Update and (Proxy) Binding Acknowledge signaling. These messages MUST include one or more Flow Policy Object options specified in this document. The flow treatment policy may be rescinded any time. For instance, the LMA (HA) may send a FPRQ message with a request to terminate an existing flow policy. Such a message may be generated as a result of termination of an application flow. The flow forwarding policy has a default lifetime, upon the expiry of which the forwarding reverts to the default flow forwarding policy. When flow forwarding service ceases, the corresponding logical datastructure entries MUST be removed. At any point in time, a MAG or a MN may send an Unsolicited FPRP (U-FPRP) message to indicate events such as FFE lifetime renewal or a Koodli & Chowdhury Expires March 2, 2012 [Page 5] Internet-Draft Policy-Based Mobility August 2011 MN moving out of coverage. The LMA (HA) sends an FPRQ message to confirm the renewal of FFE lifetime. When the event indicates a MN moving out of coverage, the LMA sends FPRQ to cancel an existing flow forwarding service. In any case, the MAG MUST wait for the FPRQ 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 (P)MIP6 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. 4. Message Formats 4.1. Flow Policy Request (FPRQ) The LMA (HA) sends an FPRQ message to a MAG (MN) to request flow handover of one or more application flows of a MN. The Flow Policy Object present in the message identifies the flows and their target ATT. 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 Policy Request (FPRQ) 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. Koodli & Chowdhury Expires March 2, 2012 [Page 6] Internet-Draft Policy-Based Mobility August 2011 'R' flag: Set to 0, indicates it is an FPRQ 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 the flow policy. Mobility Options: MUST contain the Flow Policy Object, which is a 3-tuple containing the {MN Identifier, Access Technology Type, Traffic Selector} options in that order. The Flow Policy Object forms the flow policy for the duration specified in Lifetime. The Flow Policy Object may be repeated more than once. o Mobile Node Identifier option [RFC5213] o Access Technology Type option [RFC5213] o Traffic Selector option [RFC6089] 4.2. Flow Policy Reply (FPRP) The MAG sends an FPRP message to the LMA as a response to the FPRQ 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 Policy Reply (FPRP) Message Koodli & Chowdhury Expires March 2, 2012 [Page 7] Internet-Draft Policy-Based Mobility August 2011 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 FPRP message. 'U' flag: When set to 1, the FPRP 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 FPRQ message to confirm that the request is acceptable to the LMA. Reserved: This field is unused. MUST be set zero. Status: The following codes are currently defined. New codes may be specified in the future. 0: Success 1: Failure, unable to establish flow policy due to poor connectivity 2: Failure, unable to establish flow policy due to charging limitations Lifetime: The time in seconds for which the flow forwarding is supported. Typically copied from the corresponding field in the FPRQ message. Mobility Options: When Status code is 0, no options may be present. When the Status code is other than 0, the Flow Policy Object for which the flow policy could not be applied MUST be included in the order they were present in the FPRQ message. 5. Security Considerations The protocol specified in this document uses the same security association between the LMA and the MAG to protect the FPRQ and FPRP messages. Similarly, the protocol uses the same security association between the HA and the MN to protect the FPRQ and FPRP signaling messages. No new security risks are identified. Support for integrity protection using IPsec is required, but support for confidentiality is not necessary. Koodli & Chowdhury Expires March 2, 2012 [Page 8] Internet-Draft Policy-Based Mobility August 2011 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. [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. [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011. 7.2. Informative References [LI-draft] Melia, T. and S. Gundavelli, "Logical Interface Support for multi-mode IP Hosts", draft-ietf-netext-logical-interface-support-01.txt, Oct 2010. Authors' Addresses Rajeev Koodli Cisco Systems USA Email: rkoodli@cisco.com Koodli & Chowdhury Expires March 2, 2012 [Page 9] Internet-Draft Policy-Based Mobility August 2011 Kuntal Chowdhury USA Email: Koodli & Chowdhury Expires March 2, 2012 [Page 10]