SFC WG W. Jing Internet-Draft C. Wang Intended status: Standards Track ZTE Corporation Expires: May 3, 2017 C. FONTAINE Qosmos October 30, 2016 Flow Release Notify draft-jing-sfc-flow-release-notify-01 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 May 3, 2017. Jing, et al. Expires May 3, 2017 [Page 1] Internet-Draft Flow Release Notify October 2016 Copyright Notice 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Convention and Terminology . . . . . . . . . . . . . . . . . 3 3. Defination of Flow Termination Message . . . . . . . . . . . 3 3.1. Data Plane Approach . . . . . . . . . . . . . . . . . . . 3 3.2. Control Plane Approach . . . . . . . . . . . . . . . . . 4 4. Controller Behavior . . . . . . . . . . . . . . . . . . . . . 5 5. Classifier Behavior . . . . . . . . . . . . . . . . . . . . . 5 6. Service Function Forwarder behavior . . . . . . . . . . . . . 6 7. SFC Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 6 8. SFC-aware Service Function Behavior . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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 cost resources to assist the return traffic from the Jing, et al. Expires May 3, 2017 [Page 2] Internet-Draft Flow Release Notify October 2016 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 tries to disclose this issue and 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. 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]. 3. Defination of Flow Termination Message A message with Flow Termination Indicator is treated as flow termination message. And also, the termination flow's identifier is also included in flow termination message. As what is the flow's identifier and how to define flow's identifier depends on specific scenarioes. for example, flow's identifier could be 5-tuple in the packet, or the Flow ID, or the session ID, or something else which exclusively identify the flow. When SFC components receive flow termination message, they MUST abstract the flow's identifier field in the receiving message and release the corresponding resource occupied by the flow. As how SFC components receive the flow termination message, there have different approaches, including data plane approaches and control plane approaches. Here elaborates these approaches as follow. 3.1. Data Plane Approach Here flow termination message is a NSH encapsulated message. It is generated by Classifier, and transported along the SFP and ended at Jing, et al. Expires May 3, 2017 [Page 3] Internet-Draft Flow Release Notify October 2016 the end of SFP. An example of flow termination message is as figure 1. +-------------------------------------------------------------+ | NSH Payload | | (flow's identifier) | +-------------------------------------------------------------+ | | | Network Service Header (NSH) with FTI | +-------------------------------------------------------------+ | | | L4 UDP Header | +-------------------------------------------------------------+ | | | L3 (IPv4|IPv6) Header | +-------------------------------------------------------------+ | | | L2 (Ethernet) Header | +-------------------------------------------------------------+ Figure 1: Example of Flow Termination Message The flow's identifier field in the NSH Payload of the flow termination message should have sufficient information to uniquely identify the flow that is terminated. Specifically, IP five tuples is a typical flow's identifier. The FTI means Flow Termination Indicator. It is encapsulted in NSH. There are several solutions to carry Flow Termination Indicator to indicate this message is an flow termination message, such as: 1)use a reserved bit in the Base header; 2)use a bit in the mandatory context header when MD type=1; 3)specify a Variable Context Headers when MD type=2. 3.2. Control Plane Approach One of the control plane approaches here is that SFC controller should assist in triggering flow termination message through interfaces defined in [I-D.ietf-sfc-control-plane] to nofify SFC components to release the resource. Another control plane approach here is that SFC Classifier triggers a new SFC OAM message as flow termination message along the SFP. Jing, et al. Expires May 3, 2017 [Page 4] Internet-Draft Flow Release Notify October 2016 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 | OAM Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |FTI Msg Type | Length | Flow's Identifier(available | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: SFC OAM message as flow termination message FTI Msg Type: TBD. Len: depends on the length of Flow's Identifier. Flow's Identifier: idenitifer the flow uniquely. 4. Controller Behavior Under SFC controller scenario, if controller acquires the termination of flow, it may generate flow termination message and send it to the SFC components related to the flow. How the controller detects the termination of flow is out of the scope of this document. 5. Classifier Behavior Under other scenarioes, 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: 1)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. Specifically, Gx interface can be used by PGW to get online/ offline information from PCRF. Jing, et al. Expires May 3, 2017 [Page 5] Internet-Draft Flow Release Notify October 2016 2)Classifier may have DPI function, which can observe the TCP FIN packet which is termination signal of TCP flow. And so on. 6. Service Function Forwarder behavior SFF treats flow termination message as normal traffic in service chain and forwards it according to SPI/SI. But, unders some circumstances, there may be some states maintained in the SFFs related to the flow. then, these states need to be released as well if such kind of SFFs receive flow termination message. 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 flow. When traffic is returned from the SFC-unaware SFs, SFC proxy reapplies the SFC encapsulation according to the encapsulation information stored in the states table. 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 flow's identifier abstracted in the flow termination message. And then decrements service index and returns the flow termination message back to SFF. 8. SFC-aware Service Function Behavior When SFC-aware SF receives flow termination message, it should take action to release the resources occupied the flow, which is identified by the flow's identifier. And then decrements service index and returns the flow termination message back to SFF. 9. Security Considerations TBD Jing, et al. Expires May 3, 2017 [Page 6] Internet-Draft Flow Release Notify October 2016 10. Acknowledgement The editors would like to thank David Dolson for a thorough review and useful comments. 11. IANA Considerations TBD 12. References 12.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, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . 12.2. Informative References [I-D.ietf-sfc-control-plane] Boucadair, M., "Service Function Chaining (SFC) Control Plane Components & Requirements", draft-ietf-sfc-control- plane-08 (work in progress), October 2016. [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft- ietf-sfc-nsh-10 (work in progress), September 2016. Authors' Addresses WeiDong Jing ZTE Corporation No.6 Huashen Rd, Yuhuatai District Nanjing China Email: jing.weidong1@zte.com.cn Jing, et al. Expires May 3, 2017 [Page 7] Internet-Draft Flow Release Notify October 2016 Cui Wang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: wang.cui1@zte.com.cn Christophe FONTAINE Qosmos 8 rue Bernard-Buffet 75017 Paris France Email: christophe.fontaine@qosmos.com Jing, et al. Expires May 3, 2017 [Page 8]