SFC WG W. Jing Internet-Draft J. Zhao Intended status: Standards Track X. Zhan Expires: January 8, 2017 H. Cai C. Wang ZTE Corporation July 7, 2016 Flow Release Notify draft-jing-sfc-flow-release-notify-00 Abstract Service function chain is the definition of an ordered set of service functions. After instantiated, the service function path is created and the classified traffic is steered through the corresponding service function path and then forwarded to the final destination. SFs and SFC Proxies do not know the termination of a service flow. This document describes a method to notify the SFs and SFC Proxies the termination of a service flow. When one service flow goes through the SFP, there may create some states in some SFs or SFC Proxies. However, when the service flow terminates, the SFs and SFC Proxies are unaware of that and maintain the states as well.This document describes a method to notify the SFs and SFC Proxies the termination of a service flow and release the resources occupied by the flow. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 8, 2017. Copyright Notice Jing, et al. Expires January 8, 2017 [Page 1] Internet-Draft Flow Release Notify July 2016 Copyright (c) 2016 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4 3. Defination of Flow Termination Message . . . . . . . . . . . . 5 4. Defination of Flow Termination Indicator . . . . . . . . . . . 6 4.1. Reserved Bit for FTI . . . . . . . . . . . . . . . . . . . 6 4.2. A bit in mandatory context header for FTI . . . . . . . . 7 4.3. TLV for FTI . . . . . . . . . . . . . . . . . . . . . . . 7 5. Classifier Behavior . . . . . . . . . . . . . . . . . . . . . 8 6. Service Function Forwarder behavior . . . . . . . . . . . . . 9 7. SFC Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 10 8. SFC-aware Service Function Behavior . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Jing, et al. Expires January 8, 2017 [Page 2] Internet-Draft Flow Release Notify July 2016 1. Introduction Service function chain is the definition of an ordered set of service functions. After instantiated, the service function path is created and the classified traffic is steered through the corresponding service function path and then forwarded to the final destination. SFs and SFC Proxies allocate resources (e.g. memory) for service flow in order to process the packets of service flow correctly. Typically, in current SFC deployment, there are many SFC-unaware SFs which need SFC Proxies to assist them to fulfill SFC forwarding. When service flow goes through these SFC Proxies, there are states created which really cost resources to assist the return traffic from the SFC-unaware SFs to retrieve the original NSH encapsulation. When a service flow terminates, the corresponding states/resources should be cleaned up. Unfortunately, SFs and SFC Proxies do not know the termination of a service flow. As a result of that, they cannot release the resources immediately. Maybe one solution is to set lifetime for these states, but how long the lifetime should be set is an issue as well as what if the lifetime is asynchronous between different SFs and SFC Proxies. This document describes a synchronous method to notify the SFC-aware SFs and SFC Proxies the termination of a service flow and then release the resource occupied by the service flow synchronously. Jing, et al. Expires January 8, 2017 [Page 3] Internet-Draft Flow Release Notify July 2016 2. Convention and 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]. The terms are all defined in rfc7665 and [I-D.ietf-sfc-nsh]. Jing, et al. Expires January 8, 2017 [Page 4] Internet-Draft Flow Release Notify July 2016 3. Defination of Flow Termination Message A packet with Flow Termination Indicator is treated as flow termination message. Flow termination message is a NSH encapsulated message. It is generated by Classifier, transported along the SFP and ended at the end of SFP. The original packet part or the original frame part of flow termination message shall have sufficient information to identify the flow that is to be terminated. The information that identify the flow typically refers to IP five tuple. +-------------------------------------------------------------+ | NSH Payload | | (Original L2/L3 frame/packet or other as signaled by NSH) | +-------------------------------------------------------------+ | | | Network Service Header (NSH) with FTI | +-------------------------------------------------------------+ | | | L4 UDP Header | +-------------------------------------------------------------+ | | | L3 (IPv4|IPv6) Header | +-------------------------------------------------------------+ | | | L2 (Ethernet) Header | +-------------------------------------------------------------+ Figure 1: Example of Flow Termination Indicator Format Jing, et al. Expires January 8, 2017 [Page 5] Internet-Draft Flow Release Notify July 2016 4. Defination of Flow Termination Indicator Flow Termination Indicator is a flag in NSH header. There are 3 solutions to allocate Flow Termination Indicator: 1)a reserved bit of the Base header; 2) a bit of the mandatory context header; 3) specify a Variable Context Headers 4.1. Reserved Bit for FTI A T bit of the Base header is allocated for Flow Termination Indicator. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|T|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Reserved Bit for FTI T bit: if set, identifies this is a Flow Termination Message. Jing, et al. Expires January 8, 2017 [Page 6] Internet-Draft Flow Release Notify July 2016 4.2. A bit in mandatory context header for FTI 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: A bit in mandatory context header for FTI T bit: if set, identifies this is a Flow Termination Message. 4.3. TLV for FTI 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| Type |T|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: TLV for FTI T bit: if set, identifies this is a Flow Termination Message. C bit: should always unset. TLV Class: TBD. Type: TBD. Len: always set to 0x0. Jing, et al. Expires January 8, 2017 [Page 7] Internet-Draft Flow Release Notify July 2016 5. Classifier Behavior If classifier acquires the termination of flow, it may generate flow termination message and send it to the SFP of the flow. How the classifier detects the termination of flow is out of the scope of this document. Here are some examples of how to detect the termination of flow: in case of mobile network, classifier can be collocated with PGW. As per 3GPP specification, PGW has interfaces like S5/S8, Gx,Gy,S6b. All interfaces listed above can be used to detect the termination of flow. On the other hand, Classifier may have DPI function, which can observe the TCP FIN packet which is termination signal of TCP flow. Jing, et al. Expires January 8, 2017 [Page 8] Internet-Draft Flow Release Notify July 2016 6. Service Function Forwarder behavior SFF treats flow termination message as normal traffic in service chain and forwards it according to SPI/SI. Jing, et al. Expires January 8, 2017 [Page 9] Internet-Draft Flow Release Notify July 2016 7. SFC Proxy Behavior The proxy accepts packets from the SFF on behalf of the SF. It removes the SFC encapsulation, and then uses a local attachment circuit to deliver packets to SFC-unaware SFs. It also receives packets back from the SF, reapplies the SFC encapsulation, and returns them to the SFF for processing along the service function path. refer to [RFC 7665] Thus, it is necessary for SFC proxy to maintain a state for each IP flows. When traffic is returned from the SFC-unaware SFs, SFC proxy reapplies the SFC encapsulation according to the encapsulation information stored in the state. Such states consume a lot of memory, because millions of states would be maintained. When SFC Proxy receives flow termination message, it should take action to release the resources of the flow, which is identified by the IP five tuple. And then decrements service index and returns the flow termination message back to SFF. Jing, et al. Expires January 8, 2017 [Page 10] Internet-Draft Flow Release Notify July 2016 8. SFC-aware Service Function Behavior When SFC-aware SF receives flow termination message, it should take action to release the resources of the flow, which is identified by the IP five tuple. And then decrements service index and returns the flow termination message back to SFF. Jing, et al. Expires January 8, 2017 [Page 11] Internet-Draft Flow Release Notify July 2016 9. Security Considerations TBD Jing, et al. Expires January 8, 2017 [Page 12] Internet-Draft Flow Release Notify July 2016 10. IANA Considerations TLV Class and Type of MD-type=0x2 NSH header is to be allocated by IANA. TLV Class: TBD. Type: TBD. Jing, et al. Expires January 8, 2017 [Page 13] Internet-Draft Flow Release Notify July 2016 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . 11.2. Informative References [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft-ietf-sfc-nsh-05 (work in progress), May 2016. Jing, et al. Expires January 8, 2017 [Page 14] Internet-Draft Flow Release Notify July 2016 Authors' Addresses WeiDong Jing ZTE Corporation No.6 Huashen Rd, Yuhuatai District Nanjing China Email: jing.weidong1@zte.com.cn Jingbo Zhao ZTE Corporation No.6 Huashen Rd, Yuhuatai District Nanjing China Email: zhao.jingbo@zte.com.cn Xuzhou Zhan ZTE Corporation No.6 Huashen Rd, Yuhuatai District Nanjing China Email: zhan.xuzhou@zte.com.cn Hongbo Cai ZTE Corporation No.6 Huashen Rd, Yuhuatai District Nanjing China Email: cai.hongbo@zte.com.cn Cui Wang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: wang.cui1@zte.com.cn Jing, et al. Expires January 8, 2017 [Page 15]