idnits 2.17.00 (12 Aug 2021) /tmp/idnits16106/draft-wei-sfc-re-classification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 208 has weird spacing: '...another servi...' == Line 225 has weird spacing: '...able to assu...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 30, 2014) is 2882 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PS' is mentioned on line 81, but not defined == Missing Reference: 'RFC2119' is mentioned on line 143, but not defined == Unused Reference: 'KEYWORDS' is defined on line 415, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT X.Wei 3 Intended Status: Proposed Standard Huawei Technologies 4 Expires: January 1, 2015 June 30, 2014 6 Re-classification analysis in SFC 7 draft-wei-sfc-re-classification-00 9 Abstract 11 Service Function Chaining (SFC) provides the ability to classify and 12 steer a flow via some network service(s). Some traffic flows require 13 re-classification to a new service chain. This may be, for example, 14 the result of further analysis of initial packets, or detection of 15 multiple types of media. This document discusses re-classification 16 scenarios in SFC, and several deployment models for the re-classifier 17 and relevant analysis are provided. The proposal will recommend some 18 architectural constraints for the SFC design. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1 Case 1: Classifier lacks information about the traffic . . 4 62 2.2 Case 2: Traffic bypasses certain SF . . . . . . . . . . . . 5 63 2.3 Case 3: Multiple content types in the same flow . . . . . . 5 64 3 Deployment models of re-classifier . . . . . . . . . . . . . . 6 65 3.1 Classifier plays the role of re-classifier . . . . . . . . 6 66 3.2 Re-classifier deployed independent from classifier . . . . 7 67 3.2.1 Re-classifier integrated with SF . . . . . . . . . . . 7 68 3.2.2 Re-classifier independent from SF . . . . . . . . . . . 8 69 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 70 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 71 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.1 Normative References . . . . . . . . . . . . . . . . . . . 10 74 7.2 Informative References . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 77 1 Introduction 79 Service Function Chaining (SFC) provides flexible configuration of 80 services that are connected through the network. The requirements and 81 problem space have been widely discussed in [PS], and several 82 different SFC frameworks have been proposed in [Quinn],[Boucadair] 83 and [Jiang] etc. These frameworks can be divided into four logical 84 components: a centralized SFC controller, classifier, Service 85 Function (SF) instance and SFC forwarding entity. The SFC controller 86 is in charge of constructing service function chain for network 87 traffic and certain network configurations; classifier is used to 88 perform traffic classification, it classifies packets and adds a SFC 89 ID, which is used to steer the packet along certain service chain, 90 for each packet; SF instances are deployed to provide network service 91 functions to traffics; SFC forwarding entities are in charge of 92 forwarding packets to specific SF instances according to SFC ID 93 contained in packets. 95 The concept of SFC ID is used to steering traffic along different 96 service function chain, and additional information named as 97 'metadata' could also be used to convey information between SF 98 instances or between classifier and SF instance. 100 In SFC network, classifier maintains < match rule, service chain > 101 pairs for classifying traffic to different service chain, and two of 102 the most important role of classifier is classifying packets based on 103 matching rules and tagging the packets with appropriate service chain 104 ID according to the classification result. 106 The criteria to classify traffic could be based on different kinds of 107 information, including simple information such as 5-tuple in IP 108 header field, or complex information such as the processing result of 109 DPI function. Because the classifier functional entity is located at 110 the entrance of SFC domain and all of the traffic enters SFC domain 111 through classifier, and it's possible for classifier to deal with a 112 large amount of traffic, so in order to reduce the load of classifier 113 and to accelerate the processing speed, the match ruling used by 114 classifier should be simple, for example using 5-tuple of packet 115 header as match rule. It would be better for classifier only to 116 implement network logic in dealing with traffic; and leave other 117 specific SFs to implement service logic. 119 Normally, classifier is deployed at the boundary of SFC domain, and 120 traffic is classified when it enters the SFC domain. But in some 121 cases, it is not possible to classify the traffic properly the first 122 time traffic enters the SFC domain, because the classifier might not 123 get sufficient information about the traffic and could only classify 124 traffic coarsely based on some simple information. In other cases, 125 the traffic flow might need to be steered to a different service 126 chain, for example, due to the processing result of a certain SF, 127 after it first classified at the entrance of SFC domain. In these 128 cases, a re-classification of the traffic flow is needed. By re- 129 classification, it is meant that the service chain ID of the traffic 130 is changed to a new one, after it enters SFC domain. 132 We name the classifier that implements re-classification action as 133 re-classifier here. 135 In this document we discuss re-classification scenarios and related 136 re-classifier deployment models in SFC domain. 138 1.1 Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 Match rule: The rule that used by classifier to match the traffic to 145 a specific service chain. For example, match rule 146 could be in the form of 5-tuple in IP header. 147 SFE: Service Forwarding Entity. Forwarding entity in SFC domain, 148 which forwards traffic along the service chain based 149 on service chain ID. 150 SFC domain: A network that implements SFC. 152 2. Scenarios 154 This section provides several re-classification scenarios in SFC 155 domain. Based on the scenarios discussed here, analysis of impacts of 156 re-classification on SFC framework will be provided in the following 157 section. 159 2.1 Case 1: Classifier lacks information about the traffic 161 When a flow enters SFC domain for the first time, SFC domain may have 162 little or coarse-grained information, about the flow, e.g. which 163 subscriber the flow belongs to, and more detailed, fine-grained 164 information such as application type, security status or others may 165 not be known. So classifier first classifies the packet according to 166 coarse-grained information to a service chain, and the processing 167 result of certain SF along the service chain could provide fine- 168 grained information about the traffic, and then the re-classifier 169 steers the traffic to another service chain based on the fine-grained 170 information. 172 There are different SFs that could provide fine-grained information 173 about the traffic, for instance, DPI (Deep Packet Inspection) can 174 analyze the content of packet and determine the application type of 175 the traffic, and then different kind of application traffic for the 176 same subscriber could be steered to different service chain. 178 2.2 Case 2: Traffic bypasses certain SF 180 The use case of long-lived flow is introduced in [Krishnan]. B. 181 After the long-lived flow has been processed by certain expensive or 182 highly specialized SF, subsequent packets could be steered to bypass 183 this SF in order to save processing resource. [Krishnan] also 184 provides several examples of this kind of SF such as transparent FW, 185 CDN (Content Delivery Network). 187 When traffic has to bypass a SF of the service chain, it means the 188 traffic should go through a different service chain. It thus means 189 that re-classification of the traffic is needed. Figure 1 shows an 190 example for this scenario. 192 service chain 2 193 +------------+ 194 | | 195 +----------+ +---+ | +--+ | +---+ 196 traffic| |------| |--+ | | +---| |----- 197 ====> |classifier| |SF1| |FW| |SF3| 198 | |------| |------| |---------| |----- 199 +----------+ +---+ +--+ +---+ 200 service chain 1 201 Figure 1 Traffic bypasses certain SF 203 In Figure 1, after a long-lived traffic flow enters the SFC domain 204 for the first time, it is classified to service chain 1, which 205 consists of a Firewall (FW). When the FW inspects the traffic and 206 determines that it is from a trusted source, the traffic can 207 subsequently bypass the FW. This requires re-classification that 208 allows the flow to go through another service chain, e.g. service 209 chain 2. 211 2.3 Case 3: Multiple content types in the same flow 213 In some applications, such as Web services using HTTP, different 214 types of content may be transmitted in the same flow, i.e. belonging 215 to the same TCP session. For example, when a user starts a TCP 216 connection to YouTube and gets content using HTTP, there will be 217 different kinds of media such as text, audio and video transmitted 218 over the same TCP session. 220 For such flows, the content of different kinds might benefit from 221 different network services, i.e. go through different service chain, 222 for instance, in the same HTTP session, video may go through video 223 optimizer, while text doesn't need any optimization. Though the 224 classifier may determine the application type, e.g., based on port 225 number, it not viable to assume that the classifier can distinguish 226 different contents in traffic. 228 video 229 +----------+ +---+ +---+ +----------+ +---+ 230 traffic| |--| |--| |-----| |----| |-- 231 ====> |classifier| |SF1| |SF3| |video opt.| |SF2| 232 | |--| |--| |--+ | | +-| |-- 233 +----------+ +---+ +---+ | +----------+ | +---+ 234 +----------------+ 235 non-video 236 Figure 2 Example of re-classification of HTTP traffic 238 3 Deployment models of re-classifier 240 There are two different deployment models for the re-classification 241 function, and this section will discuss these two models in detail. 243 3.1 Classifier plays the role of re-classifier 245 When traffic enters SFC domain through classifier, it will be 246 classified to certain service chain based on matching rule configured 247 in classifier. And then traffic is steered to specific SF instances 248 along the service chain. In this sub-section, we discuss the re- 249 classification mechanism that classifier plays the role of re- 250 classifier and used to re-classify traffic to a different service 251 chain, according to the procession result. 253 An overview description of this mechanism is depicted in Figure 3. If 254 the processing result of certain SF would affect the service chain of 255 a traffic flow, the SF reports processing result to controller to 256 provide more detailed information about the traffic; after receiving 257 traffic information from SF, controller could choose to form a new 258 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 262 3, when traffic passes through classifier at the first time, it is 263 classified to service chain 1 consisting SF1, SF2 and SF3 by 264 classifier, the processing result of the traffic by SF2 would affect 265 the classification behavior of classifier, and then classifier 266 classifies the traffic to a different service chain 2 consisting of 267 SF4 and SF5. 269 update +----------+ 271 +-------------|controller| 272 | +----------+ 273 | ^reporting of processing 274 | | result 275 V | 276 +----------+ +---+ +---+ +---+ 277 traffic | |---|SF1|----|SF2|----|SF3|--- 278 ======>|classifier| +---+ +---+ +---+ 279 | |--+ service chain 1 280 +----------+ | 281 | 282 | +---+ +---+ 283 +-|SF4|-------|SF5|-------- 284 +---+ +---+ 285 service chain 2 286 Figure 3: Classifier plays the role of re-classifier 288 Analysis: 289 - In this case, SF2 could be any kind of Service Function, such as 290 Firewall, DPI etc, whose processing result of traffic flow could 291 change the service chain of the traffic. 292 - This mechanism needs an interface to convey SF's processing result 293 from SF to controller. The information conveyed from the SF to 294 controller should at least include flow information and the 295 processing result information. The protocol used in this interface 296 could based on the existing protocols, such NetConf [RFC6241], 297 Diameter [RFC6733] etc, or a new protocol might be needed. 298 - After the traffic flow is re-classified, the SF that cause the re- 299 classification, i.e. SF2 in Figure 3, might not be included any 300 more in the new service chain, so if the SF maintains state for the 301 traffic flows state information, there should be a mechanism to 302 release the state. 304 3.2 Re-classifier deployed independent from classifier 306 Besides the scheme described in sub-section 3.1, this sub-section 307 provides another re-classification scheme in which re-classifier 308 functionality is deployed independent from classifier which is 309 deployed at the boundary of the SFC domain. 311 3.2.1 Re-classifier integrated with SF 313 In this case, the re-classifier is integrated with specific SF, 314 e.g. FW, DPI etc, and it could re-classify traffic to a different 315 service chain according to the processing result of traffic by the 316 SF. 318 The traffic is first classified by classifier at the boundary of 319 SFC domain, and then forwarded to specific SFs according to service 320 chain ID encapsulated in traffic. When traffic goes through a SF 321 which is integrated with re-classifier functionality, and the 322 traffic needs to go through a different service chain, re- 323 classifier could re-tag a new service chain ID in the traffic. 325 traffic---------+ +---+ +---+-------------+ +---+ +---+ 326 ==>|classifier|--|SF1|---|SF2|re-classifier|--|SF3|--|SF4|-- 327 +----------+ +---+ +---+-------------+ +---+ +---+ 328 | 329 | 330 +---+ +---+ 331 |SF5|----|SF6|-------------- 332 +---+ +---+ 333 Figure 4 Re-classifier integrated with SF 335 Analysis: 336 - In this case, an interface between SFC controller and the SF that 337 integrated with re-classifier functionality is needed to configure 338 re-classifier with pair. The protocol 339 used in this interface could be the same as the interface between 340 SFC controller and classifier. 341 - The re-classification in this deployment model only impacts the 342 path that behind the SF which implements re-classification 343 functionality. 344 - This scheme provides a more flexible choice to implement traffic 345 re-classification, one or more re-classifier could be deployed in a 346 SFC domain. 348 3.2.2 Re-classifier independent from SF 350 In cases that SF, which could impact service chain that the traffic 351 goes through, is not integrated with a re-classifier, especially for 352 legacy SF, a re-classifier independent from SF could be deployed. 354 For the re-classifier independent from SF there are also several 355 deployment choices, for example, re-classifier could be deployed as 356 an independent entity and attach to the output interface of specific 357 SF; or re-classifier could be integrated with SFE. 359 When the traffic is processed by SF, the re-classifier could re- 360 classify the traffic according to the output interface of SF or 361 according to processing result information taken in the traffic, e.g. 363 the information in metadata. 365 service chain 1 366 traffic---------+ +---+ +---+ +---+ +---+ 367 ===>|classifier|->|SF1|-->|SF2| |SF3|--|SF4|---- 368 +----------+ +---+ +-|-+ +|--+ +---+ 369 | | 370 +----------|--------|------------+ 371 | +-|--------|-+ | 372 | SFE | classifier| | 373 | +-----|------+ | 374 +--------------|-----------------+ 375 | 376 +-|-+ +---+ 377 |SF5|----|SF6|-------- 378 +---+ +---+ 379 service chain 2 380 Figure 5: Re-classifier integrated with SFE 381 Analysis: 382 - In this case, SF is not required to support re-classification 383 functionality. 384 - When integrated with SFE, the re-classifier could be shared by more 385 than one SF. 386 - The processing result of SF should be conveyed in certain method to 387 re-classifier, as discuss above the method used here could be 388 judging from the output interface of SF or according to processing 389 result information taken in the traffic, e.g. the information in 390 metadata (in-band signal). 391 - An interface between SFC controller and re-classifier is needed to 392 provision the re-classifier, if the re-classifier is integrated 393 with SFE, then the interface between SFC controller and SFE could 394 be used to exchange information between SFC controller and re- 395 classifier; otherwise an independent interface between SFC 396 controller and re-classifier should be exist. 398 4 IANA Considerations 400 This document requires no requirement for IANA. 402 5 Security Considerations 404 Security related issues is not involved. 406 6 Acknowledgments 408 Many thanks to John Kaippallimalil and Chunshan Xiong (Sam) for their 409 valuable comments. 411 7 References 413 7.1 Normative References 415 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 419 and A. Bierman, Ed., "Network Configuration Protocol 420 (NETCONF)", RFC 6241, June 2011. 422 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 423 Ed., "Diameter Base Protocol", RFC 6733, October 2012. 425 7.2 Informative References 427 [Krishnan] R. Krishnan et al. "draft-krishnan-sfc-long-lived-flow- 428 use-cases", April 21, 2014 429 [Quinn] P. Quinn et al. "draft-quinn-sfc-arch-05", May 5, 2014 430 [Boucadair] M. Boucadair et al. "draft-boucadair-sfc-framework-02", 431 February 12, 2014 432 [Jiang] Y. Jiang. "draft-jiang-sfc-arch-01", February 14, 2014 434 Authors' Addresses 436 Xinpeng Wei 437 EMail: weixinpeng@huawei.com