MEXT Working Group M. Jeyatharan Internet-Draft C. Ng Intended status: Standards Track Panasonic Expires: September 3, 2010 March 2, 2010 3GPP TFT Reference for Flow Binding draft-jeyatharan-mext-flow-tftemp-reference-00 Abstract This memo describes a reference to third generation partner ship project (3GPP) defined traffic flow template (TFT) as a traffic selector in the flow based routing mechanism described in the flow binding draft [1]. This memo, further specifies a new traffic selector sub-option format to be used with the flow binding mobility option defined in draft [1], in order to transport the TFT reference from the mobile node to its home agent in a 3GPP SAE (service architecture evolution) scenario. 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 September 3, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Jeyatharan & Ng Expires September 3, 2010 [Page 1] Internet-Draft TFT Reference March 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 4.1. Setting up Flow Filters . . . . . . . . . . . . . . . . . 5 4.2. Refreshing Flow Filters . . . . . . . . . . . . . . . . . 5 4.3. Modification of TFTs . . . . . . . . . . . . . . . . . . . 6 4.4. Removal of TFTs . . . . . . . . . . . . . . . . . . . . . 6 5. Modification to Existing Protocol . . . . . . . . . . . . . . 6 5.1. TFT Reference Traffic Selector Sub-option Format . . . . . 6 6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 7 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 9 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Jeyatharan & Ng Expires September 3, 2010 [Page 2] Internet-Draft TFT Reference March 2010 1. Introduction A mobile node which has the ability to manage its mobility as described in RFC-3775 [2], RFC-3963 [8] or RFC-5555 [9] may connect to the operator's core network using multiple interfaces as described in RFC-5648 [3]. After attaching to the core network using multiple interfaces, the mobile node can then set flow based routing rules at its home agent using the method outlined in draft MEXT-FlowBinding [1]. MEXT-FlowBinding [1] specifies a method for the mobile node to send the flow identifier mobility option and the traffic selector sub-option in the binding update mobility header. The flow identifier mobility option is used to specify the routing rules and the traffic selector sub-option is used to characterize the flows to which the routing rules apply. The flow binding mechanism can be used with any traffic selector sub-option format. Currently defined traffic selector is the binary format specified in [4]. In 3GPP evolved packet system (EPS), QoS is provisioned by creating multiple EPS bearer [5]. Each EPS bearer is identified by a EPS bearer identifier (ID) and may be associated with different QoS parameters such as the QoS class indicator (QCI), maximum bit-rate, guaranteed bit rate, etc. All traffic sent along a given EPS bearer will enjoy the same level of QoS. In order to forward flows according to their subscribed QoS classes, the EPS bearers are each associated with Traffic Flow Template (TFT) which contain a list of Packet Filters [6]. Each packet filter describes a flow by parameters such as remote party (correspondent node) IP address, source and destination port numbers, flow label, transport protocol etc. With TFTs, both the network and the mobile node can make the selection of the appropriate EPS bearer to forward a given packet so that correct QoS treatment is used when forwarding the packet. 2. Motivation There is a 3GPP release 10 standardization effort as described in [10] which allows simultaneous 3GPP and non-3GPP accesses and flow mobility for mobile nodes that have client based mobility management protocols. The mobile node may set flow based routing rules using the method outlined in draft MEXT-FlowBinding [1] to select the interface for the delivery of a particular flow. When the flow is directed to the 3GPP interface, the TFT mechanism is then used to select which EPS bearer to deliver the flow so that appropriate QoS treatment can be applied. A likely scenario is for the mobile node to set the non-3GPP Jeyatharan & Ng Expires September 3, 2010 [Page 3] Internet-Draft TFT Reference March 2010 interface as the default interface, and use the 3GPP interface for flows that require QoS treatment. In such cases, it is necessary for the mobile node to set the flow based routing rules correctly so that the flows are routed to the 3GPP interface. The routing rules set in this situation is likely to be identical to the TFTs installed for the EPS bearers. In this memo, the term routing filter refers to flow filter that is described in MEXT-FlowBinding [1] and will be used interchangeably. Additionally, when the TFT is changed (eg. to accommodate additional flows for guaranteed QoS treatment, or an existing flow is no longer qualified to enjoy special QoS treatment), it is expected for the mobile node to modify corresponding routing rules accordingly. Based on the above, it will be beneficial for there to be a mechanism for the mobile node to reference the TFT installed in a particular EPS bearer as the filter description in the binding update message. This reduces the size of binding update messages, reduces the amount of binding update messages needed, and also eliminates the possibility of a flow not getting appropriate QoS treatment due to a mismatch between the routing rules and the installed TFT. With this in mind, the objective of this memo is to introduce mechanism for referencing a TFT installed on an EPS bearer when setting filter rules using the flow binding mechanism as described in MEXT-Binding [1]. Section 4 will first present an overview of installing routing filters using TFT as a reference for flows. Next, Section 5 lists the required protocol changes to carry the reference to TFT as a new traffic selector sub-option called the TFT reference traffic selector sub-option. The mobile node and home agent operations with respect to this new TFT reference traffic selector are then described in Section 6 and Section 7 respectively. Finally, Section 8 discusses the IANA support needed and Section 9 discusses the security considerations. 3. Requirements Notation 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 [7]. 4. Overview of Operation Jeyatharan & Ng Expires September 3, 2010 [Page 4] Internet-Draft TFT Reference March 2010 4.1. Setting up Flow Filters When a mobile node simultaneously attaches to both a 3GPP access and a non-3GPP access, and has TFT installed in one or more EPS Bearer on the 3GPP access, the mobile node will send a binding update (i) to perform a simultaneously at home and away binding as described in RFC-5648 [3] and (ii) to install routing filters corresponding to the TFTs to ensure that flows which are eligible for QoS treatment be routed to the 3GPP access. For example, if there is a TFT containing packet filters which route a video flow to an EPS bearer of EPS bearer ID 1, the mobile node sends a binding update (BU) to ensure that the video flow is routed to the 3GPP access by the home agent. This is done by including a TFT reference traffic selector sub-option to indicate to the home agent that a routing rule should be generated from the TFT associated with the EPS bearer that is referenced in the TFT reference traffic selector sub-option. Figure 1 illustrates the contents of the BU message. The BU mobility header will contain two Binding Identifier (BID) mobility option to bind the 3GPP access as a home binding and the non-3GPP access as a care-of binding. Since non-3GPP access is the default interface, it is set with a low BID priority value (implying high priority). A Flow Identifier (FID) mobility option is included that carries the TFT reference traffic selector sub-option (described in Section 5.1), and will carry a reference to EPS bearer ID 1. IPv6 Header BU Mobility Header Mobility Options BID option [for care-of binding of non-3GPP access] BID option [for home binding of 3GPP access] FID option TFT reference traffic selector sub-option [EPS bearer ID 1] Figure 1: BU packet with TFT reference when non-3GPP is default access Once the home agent receives and successfully process such binding update message with TFT reference traffic selector sub-option, it will install the corresponding simultaneous at home and away registration. The home agent will also locate the packet filters in the TFTs referred to by the TFT reference traffic selector sub-option and install relevant routing rules based on a one-to-one conversion from each located Packet Filter. 4.2. Refreshing Flow Filters Once the routing filters using TFT reference is set, the mobile node can refresh the routing filters the same way as described in MEXT- Jeyatharan & Ng Expires September 3, 2010 [Page 5] Internet-Draft TFT Reference March 2010 Binding [1]. When the home agent receives a refresh binding update that contains a FID that refers to a TFT reference, the home agent should re-generate the routing filters from the referenced TFT in case there is modification in the TFT. 4.3. Modification of TFTs Modification of TFT can happen when a new packet filter is added to a TFT associated with an EPS bearer, or a packet filter is removed from a TFT associated with an EPS bearer. When the mobile node detects such a modification, it can perform a refresh operation by sending a BU message containing a FID option which refers to the modified TFT. When the home agent receives a refresh binding update that contains a FID that refers to a TFT reference, the home agent should re-generate the routing filters from the referenced TFT. 4.4. Removal of TFTs TFT may be removed when the EPS bearer is torn down, or simply de- associated from the EPS bearer. When the mobile node detects the removal of a TFT, it should send a BU message to remove the FID that previously referred to this TFT. This follows the same filter deletion operation as specified in MEXT-Binding [1]. 5. Modification to Existing Protocol A new traffic selector extension to the flow binding process described in MEXT-Binding [1] is described here. It is in parallel to binary format traffic selector sub-option [4]. A new TFT reference traffic selector sub-option is defined. 5.1. TFT Reference Traffic Selector Sub-option Format The TFT Reference Traffic Selector format is used to carry a reference to a TFT. It is included in the FID Option of a Binding Update Mobility Header. 0 1 2 3 4 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-opt Type | Sub-Opt Len | TS Format | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TFT Ref | +-+-+-+-+-+-+-+-+ Figure 2: TFT Reference Traffic Selector Sub-option Jeyatharan & Ng Expires September 3, 2010 [Page 6] Internet-Draft TFT Reference March 2010 Sub-Opt Type A value of 3 is already assigned in draft MEXT-FlowBinding [1]. Sub-Opt Length An 8-bit unsigned integer, representing the length in octets of the TFT reference traffic selector sub-option. This field indicates the length of the sub-option not including the Sub-opt Type and Sub-opt Length fields. The value for the Sub-Opt Len field is 3 for this TFT Reference Traffic Selector Sub-option. TS Format An 8-bit unsigned integer indicating the Traffic Selector Format. Value "0" is reserved and SHOULD NOT be used. The Traffic Selector value needs to be assigned by IANA. Reserved An 8-bit reserved field. It SHOULD be set to zero by the sender and ignored by the receiver. TFT Reference This is an 8 bit field used to carry the EPS bearer ID. 6. Mobile Node Operation When creating a flow binding BU, the needed mobility options in passing routing rules to the home agent, format of the BU tied to ordering of the relevant mobility options and sub-options and alignment requirement MUST follow the considerations given in MEXT- FlowBinding [1]. The create, refresh, modification and delete operations tied to flow filtering MUST follow procedures outlined in MEXT-FlowBinding [1]. The Binding Acknowledgment to the flow binding BU MUST be processed as described in MEXT-FlowBinding [1]. When creating flow binding rules whereby the mobile node wants flows tied to existing TFTs to be sent via 3GPP access or non-3GPP access, it must use flow binding mechanism whereby, the FID option in the BU is attached with a TFT reference traffic selector sub-option. The mobile node MUST set the TFT reference field to the EPS bearer ID for which the TFT is referred from in the TFT reference traffic selector sub-option. Jeyatharan & Ng Expires September 3, 2010 [Page 7] Internet-Draft TFT Reference March 2010 If there are multiple TFTs (i.e. multiple EPS bearers) to refer from, the mobile node MUST use a FID option for each TFT and attach a TFT reference traffic selector sub-option to each such FID option in the initial flow binding set up procedures. Flow binding for multiple TFTs can be performed in an individual manner by means of individual BUs or as a bulk manner as outlined in MEXT-FlowBinding [1]. When a TFT is removed in the 3GPP access, the mobile node MUST send a delete filter message for the FID linked to the TFT as described in MEXT-FlowBinding [1]. When a TFT is modified, the mobile node SHOULD send a refresh BU to request the home agent to re-generate the routing rules from the referred TFT. 7. Home Agent Operation The processing of the create, refresh, modify and delete flow binding update at the home agent will be according to MEXT-FlowBinding [1]. Only when the TFT reference traffic selector sub-option is found in create state, the home agent will use this option to setup flow binding rules. Once the home agent receives and successfully process binding update message with TFT reference traffic selector sub-option it will create the flow routing table as disclosed in MEXT-FlowBinding [1]. The home agent will locate the packet filters in the TFTs referred to by the TFT reference traffic selector sub-option and install relevant routing rules based on a one-to-one conversion from each located Packet Filter. How the home agent can locate the packet filters and generate routing rules from the packet filters is out of scope of this document. 8. IANA Considerations This draft introduces a new value for the traffic selector format field in the traffic selector sub-option. This new traffic selector value for the traffic selector format field needs to be assigned by IANA. 9. Security Considerations This draft does not need any new security mechanism and the security mechanism specified in draft MEXT-FlowBinding [1] is adequate to Jeyatharan & Ng Expires September 3, 2010 [Page 8] Internet-Draft TFT Reference March 2010 carry the flow binding rules with TFT reference as the new traffic selector format for the traffic selector sub-option. 10. References 10.1. Normative Reference [1] Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO Basic Support", draft-ietf-mext-flow-binding-05 (work in progress), February 2010. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. [4] 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. [5] "Technical Specification Group Services and System aspects", 3GPP TS 23.401, December 2009. [6] "Technical Specification Group Core Network and Terminals", 3GPP TS 24.008, December 2009. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative Reference [8] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [9] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. [10] "Technical Specification Group Service and System Aspects", 3GPP TS 23.261, January 2010. [11] "Technical Specification Group Core Network and Terminals", 3GPP TS 29.274, May 2008. Jeyatharan & Ng Expires September 3, 2010 [Page 9] Internet-Draft TFT Reference March 2010 Authors' Addresses 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 Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG Phone: +65 65505420 Email: chanwah.ng@sg.panasonic.com Jeyatharan & Ng Expires September 3, 2010 [Page 10]