INTERNET-DRAFT X.Wei Intended Status: Proposed Standard Huawei Technologies Expires: January 1, 2015 June 30, 2014 Re-classification analysis in SFC draft-wei-sfc-re-classification-00 Abstract Service Function Chaining (SFC) provides the ability to classify and steer a flow via some network service(s). Some traffic flows require re-classification to a new service chain. This may be, for example, the result of further analysis of initial packets, or detection of multiple types of media. This document discusses re-classification scenarios in SFC, and several deployment models for the re-classifier and relevant analysis are provided. The proposal will recommend some architectural constraints for the SFC design. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. X.Wei Expires January 1, 2015 [Page 1] INTERNET DRAFT Re-classification analysis in SFC June 30, 2014 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 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Case 1: Classifier lacks information about the traffic . . 4 2.2 Case 2: Traffic bypasses certain SF . . . . . . . . . . . . 5 2.3 Case 3: Multiple content types in the same flow . . . . . . 5 3 Deployment models of re-classifier . . . . . . . . . . . . . . 6 3.1 Classifier plays the role of re-classifier . . . . . . . . 6 3.2 Re-classifier deployed independent from classifier . . . . 7 3.2.1 Re-classifier integrated with SF . . . . . . . . . . . 7 3.2.2 Re-classifier independent from SF . . . . . . . . . . . 8 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 10 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 Normative References . . . . . . . . . . . . . . . . . . . 10 7.2 Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 X.Wei Expires January 1, 2015 [Page 2] INTERNET DRAFT Re-classification analysis in SFC June 30, 2014 1 Introduction Service Function Chaining (SFC) provides flexible configuration of services that are connected through the network. The requirements and problem space have been widely discussed in [PS], and several different SFC frameworks have been proposed in [Quinn],[Boucadair] and [Jiang] etc. These frameworks can be divided into four logical components: a centralized SFC controller, classifier, Service Function (SF) instance and SFC forwarding entity. The SFC controller is in charge of constructing service function chain for network traffic and certain network configurations; classifier is used to perform traffic classification, it classifies packets and adds a SFC ID, which is used to steer the packet along certain service chain, for each packet; SF instances are deployed to provide network service functions to traffics; SFC forwarding entities are in charge of forwarding packets to specific SF instances according to SFC ID contained in packets. The concept of SFC ID is used to steering traffic along different service function chain, and additional information named as 'metadata' could also be used to convey information between SF instances or between classifier and SF instance. In SFC network, classifier maintains < match rule, service chain > pairs for classifying traffic to different service chain, and two of the most important role of classifier is classifying packets based on matching rules and tagging the packets with appropriate service chain ID according to the classification result. The criteria to classify traffic could be based on different kinds of information, including simple information such as 5-tuple in IP header field, or complex information such as the processing result of DPI function. Because the classifier functional entity is located at the entrance of SFC domain and all of the traffic enters SFC domain through classifier, and it's possible for classifier to deal with a large amount of traffic, so in order to reduce the load of classifier and to accelerate the processing speed, the match ruling used by classifier should be simple, for example using 5-tuple of packet header as match rule. It would be better for classifier only to implement network logic in dealing with traffic; and leave other specific SFs to implement service logic. Normally, classifier is deployed at the boundary of SFC domain, and traffic is classified when it enters the SFC domain. But in some cases, it is not possible to classify the traffic properly the first time traffic enters the SFC domain, because the classifier might not get sufficient information about the traffic and could only classify traffic coarsely based on some simple information. In other cases, X.Wei Expires January 1, 2015 [Page 3] INTERNET DRAFT Re-classification analysis in SFC June 30, 2014 the traffic flow might need to be steered to a different service chain, for example, due to the processing result of a certain SF, after it first classified at the entrance of SFC domain. In these cases, a re-classification of the traffic flow is needed. By re- classification, it is meant that the service chain ID of the traffic is changed to a new one, after it enters SFC domain. We name the classifier that implements re-classification action as re-classifier here. In this document we discuss re-classification scenarios and related re-classifier deployment models in SFC domain. 1.1 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]. Match rule: The rule that used by classifier to match the traffic to a specific service chain. For example, match rule could be in the form of 5-tuple in IP header. SFE: Service Forwarding Entity. Forwarding entity in SFC domain, which forwards traffic along the service chain based on service chain ID. SFC domain: A network that implements SFC. 2. Scenarios This section provides several re-classification scenarios in SFC domain. Based on the scenarios discussed here, analysis of impacts of re-classification on SFC framework will be provided in the following section. 2.1 Case 1: Classifier lacks information about the traffic When a flow enters SFC domain for the first time, SFC domain may have little or coarse-grained information, about the flow, e.g. which subscriber the flow belongs to, and more detailed, fine-grained information such as application type, security status or others may not be known. So classifier first classifies the packet according to coarse-grained information to a service chain, and the processing result of certain SF along the service chain could provide fine- grained information about the traffic, and then the re-classifier steers the traffic to another service chain based on the fine-grained information. X.Wei Expires January 1, 2015 [Page 4] INTERNET DRAFT Re-classification analysis in SFC June 30, 2014 There are different SFs that could provide fine-grained information about the traffic, for instance, DPI (Deep Packet Inspection) can analyze the content of packet and determine the application type of the traffic, and then different kind of application traffic for the same subscriber could be steered to different service chain. 2.2 Case 2: Traffic bypasses certain SF The use case of long-lived flow is introduced in [Krishnan]. B. After the long-lived flow has been processed by certain expensive or highly specialized SF, subsequent packets could be steered to bypass this SF in order to save processing resource. [Krishnan] also provides several examples of this kind of SF such as transparent FW, CDN (Content Delivery Network). When traffic has to bypass a SF of the service chain, it means the traffic should go through a different service chain. It thus means that re-classification of the traffic is needed. Figure 1 shows an example for this scenario. service chain 2 +------------+ | | +----------+ +---+ | +--+ | +---+ traffic| |------| |--+ | | +---| |----- ====> |classifier| |SF1| |FW| |SF3| | |------| |------| |---------| |----- +----------+ +---+ +--+ +---+ service chain 1 Figure 1 Traffic bypasses certain SF In Figure 1, after a long-lived traffic flow enters the SFC domain for the first time, it is classified to service chain 1, which consists of a Firewall (FW). When the FW inspects the traffic and determines that it is from a trusted source, the traffic can subsequently bypass the FW. This requires re-classification that allows the flow to go through another service chain, e.g. service chain 2. 2.3 Case 3: Multiple content types in the same flow In some applications, such as Web services using HTTP, different types of content may be transmitted in the same flow, i.e. belonging to the same TCP session. For example, when a user starts a TCP connection to YouTube and gets content using HTTP, there will be different kinds of media such as text, audio and video transmitted over the same TCP session. X.Wei Expires January 1, 2015 [Page 5] INTERNET DRAFT Re-classification analysis in SFC June 30, 2014 For such flows, the content of different kinds might benefit from different network services, i.e. go through different service chain, for instance, in the same HTTP session, video may go through video optimizer, while text doesn't need any optimization. Though the classifier may determine the application type, e.g., based on port number, it not viable to assume that the classifier can distinguish different contents in traffic. video +----------+ +---+ +---+ +----------+ +---+ traffic| |--| |--| |-----| |----| |-- ====> |classifier| |SF1| |SF3| |video opt.| |SF2| | |--| |--| |--+ | | +-| |-- +----------+ +---+ +---+ | +----------+ | +---+ +----------------+ non-video Figure 2 Example of re-classification of HTTP traffic 3 Deployment models of re-classifier There are two different deployment models for the re-classification function, and this section will discuss these two models in detail. 3.1 Classifier plays the role of re-classifier When traffic enters SFC domain through classifier, it will be classified to certain service chain based on matching rule configured in classifier. And then traffic is steered to specific SF instances along the service chain. In this sub-section, we discuss the re- classification mechanism that classifier plays the role of re- classifier and used to re-classify traffic to a different service chain, according to the procession result. An overview description of this mechanism is depicted in Figure 3. If the processing result of certain SF would affect the service chain of a traffic flow, the SF reports processing result to controller to provide more detailed information about the traffic; after receiving traffic information from SF, controller could choose to form a new service chain for the traffic, and then controller updates the pair in classifier; after updating of pair, classifier uses the new pair to classify the traffic. For example, in Figure 3, when traffic passes through classifier at the first time, it is classified to service chain 1 consisting SF1, SF2 and SF3 by classifier, the processing result of the traffic by SF2 would affect the classification behavior of classifier, and then classifier classifies the traffic to a different service chain 2 consisting of X.Wei Expires January 1, 2015 [Page 6] INTERNET DRAFT Re-classification analysis in SFC June 30, 2014 SF4 and SF5. update +----------+ +-------------|controller| | +----------+ | ^reporting of processing | | result V | +----------+ +---+ +---+ +---+ traffic | |---|SF1|----|SF2|----|SF3|--- ======>|classifier| +---+ +---+ +---+ | |--+ service chain 1 +----------+ | | | +---+ +---+ +-|SF4|-------|SF5|-------- +---+ +---+ service chain 2 Figure 3: Classifier plays the role of re-classifier Analysis: - In this case, SF2 could be any kind of Service Function, such as Firewall, DPI etc, whose processing result of traffic flow could change the service chain of the traffic. - This mechanism needs an interface to convey SF's processing result from SF to controller. The information conveyed from the SF to controller should at least include flow information and the processing result information. The protocol used in this interface could based on the existing protocols, such NetConf [RFC6241], Diameter [RFC6733] etc, or a new protocol might be needed. - After the traffic flow is re-classified, the SF that cause the re- classification, i.e. SF2 in Figure 3, might not be included any more in the new service chain, so if the SF maintains state for the traffic flows state information, there should be a mechanism to release the state. 3.2 Re-classifier deployed independent from classifier Besides the scheme described in sub-section 3.1, this sub-section provides another re-classification scheme in which re-classifier functionality is deployed independent from classifier which is deployed at the boundary of the SFC domain. 3.2.1 Re-classifier integrated with SF In this case, the re-classifier is integrated with specific SF, e.g. FW, DPI etc, and it could re-classify traffic to a different X.Wei Expires January 1, 2015 [Page 7] INTERNET DRAFT Re-classification analysis in SFC June 30, 2014 service chain according to the processing result of traffic by the SF. The traffic is first classified by classifier at the boundary of SFC domain, and then forwarded to specific SFs according to service chain ID encapsulated in traffic. When traffic goes through a SF which is integrated with re-classifier functionality, and the traffic needs to go through a different service chain, re- classifier could re-tag a new service chain ID in the traffic. traffic---------+ +---+ +---+-------------+ +---+ +---+ ==>|classifier|--|SF1|---|SF2|re-classifier|--|SF3|--|SF4|-- +----------+ +---+ +---+-------------+ +---+ +---+ | | +---+ +---+ |SF5|----|SF6|-------------- +---+ +---+ Figure 4 Re-classifier integrated with SF Analysis: - In this case, an interface between SFC controller and the SF that integrated with re-classifier functionality is needed to configure re-classifier with pair. The protocol used in this interface could be the same as the interface between SFC controller and classifier. - The re-classification in this deployment model only impacts the path that behind the SF which implements re-classification functionality. - This scheme provides a more flexible choice to implement traffic re-classification, one or more re-classifier could be deployed in a SFC domain. 3.2.2 Re-classifier independent from SF In cases that SF, which could impact service chain that the traffic goes through, is not integrated with a re-classifier, especially for legacy SF, a re-classifier independent from SF could be deployed. For the re-classifier independent from SF there are also several deployment choices, for example, re-classifier could be deployed as an independent entity and attach to the output interface of specific SF; or re-classifier could be integrated with SFE. When the traffic is processed by SF, the re-classifier could re- classify the traffic according to the output interface of SF or according to processing result information taken in the traffic, e.g. X.Wei Expires January 1, 2015 [Page 8] INTERNET DRAFT Re-classification analysis in SFC June 30, 2014 the information in metadata. service chain 1 traffic---------+ +---+ +---+ +---+ +---+ ===>|classifier|->|SF1|-->|SF2| |SF3|--|SF4|---- +----------+ +---+ +-|-+ +|--+ +---+ | | +----------|--------|------------+ | +-|--------|-+ | | SFE | classifier| | | +-----|------+ | +--------------|-----------------+ | +-|-+ +---+ |SF5|----|SF6|-------- +---+ +---+ service chain 2 Figure 5: Re-classifier integrated with SFE Analysis: - In this case, SF is not required to support re-classification functionality. - When integrated with SFE, the re-classifier could be shared by more than one SF. - The processing result of SF should be conveyed in certain method to re-classifier, as discuss above the method used here could be judging from the output interface of SF or according to processing result information taken in the traffic, e.g. the information in metadata (in-band signal). - An interface between SFC controller and re-classifier is needed to provision the re-classifier, if the re-classifier is integrated with SFE, then the interface between SFC controller and SFE could be used to exchange information between SFC controller and re- classifier; otherwise an independent interface between SFC controller and re-classifier should be exist. X.Wei Expires January 1, 2015 [Page 9] INTERNET DRAFT Re-classification analysis in SFC June 30, 2014 4 IANA Considerations This document requires no requirement for IANA. 5 Security Considerations Security related issues is not involved. 6 Acknowledgments Many thanks to John Kaippallimalil and Chunshan Xiong (Sam) for their valuable comments. 7 References 7.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, October 2012. 7.2 Informative References [Krishnan] R. Krishnan et al. "draft-krishnan-sfc-long-lived-flow- use-cases", April 21, 2014 [Quinn] P. Quinn et al. "draft-quinn-sfc-arch-05", May 5, 2014 [Boucadair] M. Boucadair et al. "draft-boucadair-sfc-framework-02", February 12, 2014 [Jiang] Y. Jiang. "draft-jiang-sfc-arch-01", February 14, 2014 Authors' Addresses Xinpeng Wei EMail: weixinpeng@huawei.com X.Wei Expires January 1, 2015 [Page 10]