idnits 2.17.00 (12 Aug 2021) /tmp/idnits10198/draft-ietf-sfc-long-lived-flow-use-cases-03.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 -- The document date (February 6, 2015) is 2654 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SFC Working Group R. Krishnan 2 Internet Draft Brocade Communications 3 Category: Informational A. Ghanwani 4 Dell 5 J. Halpern 6 S. Kini 7 Ericsson 8 D. R. Lopez 9 Telefonica I+D 11 Expires: August 7, 2015 February 6, 2015 13 SFC Long-lived Flow Use Cases 15 draft-ietf-sfc-long-lived-flow-use-cases-03 17 Abstract 19 Long-lived flows such as file transfers, video streams are common in 20 today's networks. In the context of service function chaining, this 21 draft suggests use cases for dynamic bypass of certain service 22 functions for such flows. The benefit of this approach would be to 23 avoid expensive Layer 7 service function processing for such flows 24 based on dynamic decisions and thus improve overall performance. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with 29 the provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on August, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction...................................................3 67 1.1. Acronyms..................................................4 68 2. Transparent Firewall Use Case..................................4 69 2.1. Event Sequence............................................5 70 3. Long-tail Content CDN Use Case.................................6 71 3.1. Event Sequence............................................6 72 4. IPsec Management in Mobile Environments........................7 73 4.1. Event Sequence............................................8 74 5. Operational Considerations.....................................8 75 6. IANA Considerations............................................8 76 7. Security Considerations........................................9 77 8. Acknowledgements...............................................9 78 9. References.....................................................9 79 9.1. Normative References......................................9 80 9.2. Informative References....................................9 81 Authors' Addresses................................................9 83 1. Introduction 85 In the context of service function chaining (SFC), this draft 86 suggests use cases for dynamic bypass of certain service functions 87 for long-lived flows such as file transfers and video streams. The 88 benefit of this approach would be to avoid expensive Layer 4-7 89 service function processing for such flows and improve overall 90 performance. The focus would be only on long-lived flows which are 91 observable and controllable from a control plane perspective; 92 attempting dynamic bypass for short-lived flows would cause 93 excessive control plane chattiness without any significant 94 performance benefit. 96 For long-lived flows, in order to dynamically bypass certain service 97 functions in the service function chain, the key is to make sure 98 that the Layer 7 flow can be identified using Layer 2/3/4 fields in 99 the packet. Examples of such flows are file transfers (which 100 typically use FTP/SFTP) and video streams (which typically use 101 HTTP/HTTPS) which can be mapped to a unique IP 5 tuple (IP source 102 address, IP destination address, IP protocol, transport protocol 103 source port, transport protocol destination port). We note that it 104 may not always be possible to identify a Layer 7 flow based on 105 L2/L3/L4 fields in the packet header. An example of this could be 106 file transfers under persistent HTTP sessions where multiple files 107 may be transferred using the same values for these fields in the 108 packet headers. 110 There are cases where the transfer of large content may be 111 split across multiple transport protocol connections. In such 112 cases, what may be considered a large flow at the application layer 113 is dealt with using multiple small flows at the network layer. Such 114 cases would not fit the ones described in this document. 116 The definition of long-lived flow in this context can reuse the 117 definition in [I2RS-large-flow] and [OPSAWG-large-flow], where flows 118 are categorized into 4 types - short-lived small flows, short-lived 119 large flows, long-lived small flows and long-lived large flows. In 120 this draft we are concerned with the last 2 types -- long-lived 121 small flows and long-lived large flows -- and we refer to these as 122 long-lived flows. This identification of long-lived flows is based 123 on L2/L3/L4 fields in the packet header that is consistent with that 124 the definition of a flow in IPFIX [RFC 7011]. 126 The criteria used by the service function for identifying a long- 127 lived Layer 4-7 flow can use similar criteria, with appropriate 128 modification to account for long-lived small flows, as the 129 techniques described in [OPSAWG-large-flow] for large flow 130 identification. The mechanics of dynamic bypass are quite different 131 for different service functions and are described in the following 132 sections. 134 For the mechanisms in this draft, our focus is on the following SFC 135 components: 137 . An SFC Control Plane Application which is responsible for 138 implementing the control plane functionality and programming 139 the data plane for SFC. 141 . An SFC edge, which is a switch/router responsible for 142 adding/removing the service chain header to the packets. 144 1.1. Acronyms 146 CDN: Content Delivery Network 148 DNS: Domain Name Service 150 DPI: Deep Packet Inspection 152 eNodeB: Evolved Node B 154 LTE: Long-Term Evolution 156 NAPT: Network Address Port Translation 158 SecGW: Security Gateway 160 SFC: Service Function Chaining 162 2. Transparent Firewall Use Case 164 A transparent firewall may be able to determine that a long-lived 165 flow (e.g. video stream, file transfer) has no security issues. It 166 is desirable to have such a long-lived flow dynamically bypass the 167 firewall service function but continue to execute the other service 168 functions in the chain (e.g. NAPT). The key benefit is overall 169 performance improvement. The event sequence for this use case is 170 detailed below. For this use case, it is assumed that the firewall 171 is transparent and does not perform any packet modification. 173 Note that the firewall functionality is applicable only to Layer 174 2/3/4 headers. 176 2.1. Event Sequence 178 1. The firewall examines packets of a flow and deems that it is 179 benign. While the criteria for how the firewall determines that 180 the flow is benign are beyond the scope of this document, some of 181 the criteria that may be used for this include: 183 a. The packets which are encrypted at the application layer 184 using protocols such as HTTPS [RFC 2660] cannot be decrypted 185 and examined further. 187 b. The packets are from a trusted source. 189 c. The packets are from a trusted application. 191 2. The firewall determines that the flow can be identified using a 192 Layer 2/3/4 rule in the fast path. The firewall moves the flow 193 from the internal slow path (which inspects every packet) to the 194 fast path (which does only switching and skips the detailed 195 inspection of every packet). 197 3. Based on the above criteria and also having identified the flow 198 as a long-lived flow, the firewall determines that the flow is a 199 benign one and does not need to be processed by the firewall any 200 more. 202 4. The firewall signals this information to the SFC Control Plane 203 Application. 205 5. The SFC Control Plane Application assigns the flow to a different 206 service function chain that excludes the firewall. 208 6. The flow continues to be monitored by the SFC edge switch/router 209 for activity. 211 7. Once the flow is detected as having become inactive, the flow is 212 aged out by the SFC edge switch/router. 214 8. The SFC edge switch/router signals a flow age event to the SFC 215 Control Plane Application. 217 9. The SFC Control Plane Application removes the dynamic service 218 chain association created for the flow. 220 3. Long-tail Content CDN Use Case 222 Most popular content is of interest to a number of users; typical 223 examples are newly released movies, latest television episodes, etc. 224 Such content is very amenable to caching. A single copy of the 225 content is delivered to the cache; the content is delivered to 226 multiple users from the cache. 228 Long-tail personalized content is of interest to only a few users; 229 typical examples are documentaries, older movies etc. Long-tail 230 personalized content is typically not shared by many users and is 231 not amenable to caching [CDNI-long-tail]. Caching of such content 232 could cause excessive thrashing of the cache. 234 The idea is to improve performance by identifying such long-tail 235 content and bypassing the CDN cache in the service chain for such 236 content. This would be dynamic in nature, since content that is not 237 popular can later become popular and vice versa. The focus will be 238 on long-lived content such as movies, catch up episodes which 239 generate long-lived flows. The key benefit is overall performance 240 improvement. The event sequence for this use case is detailed below. 242 For the purpose of this draft, our focus is on the following 243 components in the CDN: 245 . CDN Monitoring System: The CDN Monitoring System monitors 246 various aspects of the content such as 248 o Dynamic Content Usage: Number of users simultaneously 249 viewing the same content. 251 o Content Life: If the content is long-lived or short-lived. 252 Examples of long-lived content are movies, catch up 253 episodes, etc., while examples of short-lived content are 254 video clips, advertisements, etc. 256 . CDN Cache: This is the node in the network where the content 257 is cached. 259 For a general overview of CDNs, see [CDN-overview]. 261 3.1. Event Sequence 263 1. The CDN Monitoring System monitors the numbers of users and type 264 of content being accessed. By default, we assume the CDN Cache is 265 bypassed. 267 2. If the number of users viewing the same content exceeds a pre- 268 programmed up-threshold and the content is long-lived, the CDN 269 Monitoring System instructs the SFC Control Plane Application to 270 dynamically switch the any new flows from the existing service 271 chain A to another service chain B which includes a CDN cache for 272 caching the content in addition to all of the service functions in 273 service chain A in the same order. This is done by installing a 274 rule for the flows corresponding to the content in the SFC edge 275 switch/router. 277 3. If the number of users viewing the same content falls below 278 another pre-programmed down-threshold and the content is long- 279 lived, the monitoring server instructs the SFC Control Plane 280 Application to dynamically switch any new flows from the existing 281 service chain B (the one that was used in the previous event) to 282 service chain A (again, which includes all of the service 283 functions in service chain B other than the CDN cache). This is 284 done by removing the previously installed rule for the flows 285 corresponding to the content from the SFC edge switch/router. 287 Note that the CDN use case applies only to new flows; existing flows 288 follow the service chain that they were originally assigned to. 289 Additionally, this use case assumes that the caching is transparent 290 wherein the user does not address the cache explicitly. In other 291 words, the decision of whether or not to retrieve content from the 292 cache is not based on DNS, rather it is accomplished using SFC. The 293 mechanisms described here will apply to encrypted traffic as long 294 the encryption is at the application layer. 296 4. IPsec Management in Mobile Environments 298 Existing security procedures for flow protection in LTE are based on 299 the use of IPsec tunnels between the radio base stations (eNodeBs) 300 and some central node in the core, where a security gateway (SecGW) 301 is deployed. The eNodeB device located on the cell site initiates 302 the IPSec tunnel through the backhaul network to the SecGW, where 303 the tunnel is terminated and the traffic is forwarded towards its 304 final destination. IPsec ESP is the method that LTE standards use 305 for achieving the required levels of security [TS33.401]. 307 To avoid traffic bottlenecks and in order to guarantee a high level 308 of service availability, a recommended practice is the concurrent 309 use of several SecGW devices. The one that is to be used for a 310 given traffic flow may be determined by several criteria such as the 311 origin of the traffic (user traffic vs network control), flows with 312 well-known characteristics, e.g. security properties (HTTPS, secure 313 VPNs), etc. In this way, more critical traffic can be prioritized, 314 and different levels of security can be applied depending of payload 315 characteristics. 317 Such an optimization could be applied as well to long-lived flows in 318 a dynamic way, relaxing security procedures for non-sensitive ones, 319 e.g. it may not be necessary to secure a well-known video stream 320 that is openly available, applying differentiated policies to avoid 321 congestion, or even hardening the security procedures according to 322 the user's data profile. 324 4.1. Event Sequence 326 1. A monitoring element analyzes the new flows arriving at the 327 default SecGW device used by a given eNodeB device according to 328 criteria such as: 330 . Security payload protection; 332 . Application and transport protocol(s) in use including 333 encryption schemes; 335 . Relevant parameters in those protocols (URL, content-transfer 336 declarations, etc.). 338 2. If the monitoring element identifies a long-lived flow that 339 matches its differentiating criteria, it signals the flow to the 340 SFC Control Plane Application. 342 3. The SFC Control Plane Application assigns the flow to a different 343 service function chain that makes the eNodeB device use a 344 different SecGW device. 346 4. Once the flow is becomes inactive, it is aged out by the eNodeB 347 device and signaled as such to the SFC Control Plane Application. 349 5. The SFC Control Plane Application removes the dynamic service 350 chain association that was created for the flow. 352 5. Operational Considerations 354 Any modification to the SFC path (due to insertion or removal of a 355 service function) could result in temporary mis-ordering in the 356 delivery of packets. 358 6. IANA Considerations 360 None. 362 7. Security Considerations 364 This draft specifies a use case for SFC and does not introduce any 365 new security requirements beyond those already under consideration 366 for SFC. 368 8. Acknowledgements 370 The authors would like to thank Qin Wu, Myo Zarny, Reinaldo Penno, 371 and Tiru Reddy for their comments on the document. 373 9. References 375 9.1. Normative References 377 9.2. Informative References 379 [OPSAWG-large-flow] Krishnan, R. et al., "Mechanisms for Optimal 380 LAG/ECMP Component Link Utilization in Networks," February 2014. 382 [I2RS-large-flow] Krishnan, R. et al., "I2RS Large Flow Use Case," 383 November 2013. 385 [CDNI-long-tail] Krishnan, R. et al., "Best practices and 386 Requirements for delivering Long Tail personalized content delivery 387 over CDN Interconnections," work in progress, May 2013. 389 [CDN-overview] Dilley, J. et al., "Globally distributed content 390 delivery," IEEE Internet Computing, September-October 2002. 392 [RFC 7011] Claise, B., "Specification of the IP Flow Information 393 Export (IPFIX) Protocol for the Exchange of Flow Information," 394 September 2013. 396 [TS33.401] 3GPP Technical Specification 33.401, "Security 397 Architecture," December 2013. 399 [RFC 2660] Eric Rescorla et al., "The Secure HyperText Transfer 400 Protocol," August 1999. 402 Authors' Addresses 404 Ram Krishnan 405 Brocade Communications 406 ramk@brocade.com 407 Anoop Ghanwani 408 Dell 409 anoop@alumni.duke.edu 411 Joel Halpern 412 Ericsson 413 joel.halpern@ericsson.com 415 Sriganesh Kini 416 Ericsson 417 Sriganesh.kini@ericsson.com 419 Diego Lopez 420 Telefonica I+D 421 Don Ramon de la Cruz, 82 Street 422 Madrid, 28006, Spain 423 +34 913 129 041 424 diego.r.lopez@telefonica.com