idnits 2.17.1 draft-ietf-sfc-long-lived-flow-use-cases-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 2, 2014) is 3431 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: June 1, 2015 December 2, 2014 13 SFC Long-lived Flow Use Cases 15 draft-ietf-sfc-long-lived-flow-use-cases-01 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 April, 2014. 49 Copyright Notice 51 Copyright (c) 2014 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 Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC-2119 [RFC 2119]. 70 Table of Contents 72 1. Introduction...................................................3 73 1.1. Acronyms..................................................4 74 2. Transparent Firewall Use Case..................................4 75 2.1. Event Sequence............................................4 76 3. Long-tail Content CDN Use Case.................................5 77 3.1. Event Sequence............................................6 78 4. IPsec Management in Mobile Environments........................7 79 4.1. Event Sequence............................................7 80 5. Operational Considerations.....................................8 81 6. IANA Considerations............................................8 82 7. Security Considerations........................................8 83 8. Acknowledgements...............................................8 84 9. References.....................................................8 85 9.1. Normative References......................................8 86 9.2. Informative References....................................8 87 Authors' Addresses................................................9 89 1. Introduction 91 In the context of service function chaining (SFC), this draft 92 suggests use cases for dynamic bypass of certain service functions 93 for long-lived flows such as file transfers, video streams. The 94 benefit of this approach would be to avoid expensive Layer 4-7 95 service function processing for such flows and improve overall 96 performance. The focus would be only on long-lived flows which are 97 observable and controllable from a control plane perspective; 98 attempting dynamic bypass for short-lived flows would cause 99 excessive control plane chattiness without any significant 100 performance benefit. 102 For long-lived flows, in order to dynamically bypass certain service 103 functions in the service function chain, the key is to make sure 104 that the Layer 7 flow can be identified using Layer 2/3/4 fields in 105 the packet. Examples of such flows are file transfers (which 106 typically use FTP/SFTP) and video streams (which typically use 107 HTTP/HTTPS) which can be mapped to a unique IP 5 tuple (IP source 108 address, IP destination address, IP protocol, transport protocol 109 source port, transport protocol destination port). We note that it 110 may not always be possible to identify a Layer 7 flow based on 111 L2/L3/L4 fields in the packet header. An example of this could be 112 file transfers under persistent HTTP sessions where multiple files 113 may be transferred using the same values for these fields in the 114 packet headers. 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 DPI: Deep Packet Inspection 150 eNodeB: Evolved Node B 152 LTE: Long-Term Evolution 154 NAPT: Network Address Port Translation 156 SecGW: Security Gateway 158 SFC: Service Function Chaining 160 2. Transparent Firewall Use Case 162 A transparent firewall determines that a long-lived flow (e.g. video 163 stream, file transfer) has no security issues. This long-lived flow 164 is made to dynamically bypass the firewall service function but 165 continue to execute the other service functions in the chain (e.g. 166 NAPT). The key benefit is overall performance improvement. The event 167 sequence for this use case is detailed below. Another point to note 168 is that the firewall is transparent and does not perform packet 169 modification. 171 2.1. Event Sequence 173 1. The firewall examines packets of a flow and deems that it is 174 benign. This can be based on many factors such as 176 a. The packets are encrypted packets which cannot be decrypted 177 and examined further 179 b. The packets are from a trusted source 180 c. The packets are from a trusted application 182 2. The firewall determines that the flow can be identified using a 183 Layer 2/3/4 rule in the fast path. The firewall moves the flow 184 from the internal slow path (which inspects every packet) to the 185 fast path (which does only switching and skips the detailed 186 inspection of every packet). 188 3. Based on the above criteria and also having identified the flow 189 as a long-lived flow, the firewall determines that the flow is a 190 benign one and does not need to be processed by the firewall any 191 more. 193 4. The firewall signals this information to the SFC Control Plane 194 Application. 196 5. The SFC Control Plane Application assigns the flow to a different 197 service function chain that excludes the firewall. 199 6. The flow continues to be monitored by the SFC edge switch/router 200 for activity. 202 7. Once the flow is detected as having become inactive, the flow is 203 aged out by the SFC edge switch/router. 205 8. The SFC edge switch/router signals a flow age event to the SFC 206 Control Plane Application. 208 9. The SFC Control Plane Application removes the dynamic service 209 chain association created for the flow. 211 3. Long-tail Content CDN Use Case 213 Most popular content is of interest to a number of users; typical 214 examples are newly released movies, latest television episodes, etc. 215 Such content is very amenable to caching. A single copy of the 216 content is delivered to the cache; the content is delivered to 217 multiple users from the cache. 219 Long-tail personalized content is of interest to only a few users; 220 typical examples are documentaries, older movies etc. Long-tail 221 personalized content is typically not shared by many users and is 222 not amenable to caching [CDNI-long-tail]. Caching of such content 223 could cause excessive thrashing of the cache. 225 The idea is to improve performance by identifying such long-tail 226 content and bypassing the CDN cache in the service chain for such 227 content. This would be dynamic in nature, since content that is not 228 popular can later become popular and vice versa. The focus will be 229 on long-lived content such as movies, catch up episodes which 230 generate long-lived flows. The key benefit is overall performance 231 improvement. The event sequence for this use case is detailed below. 233 For the purpose of this draft, our focus is on the following 234 components in the CDN: 236 . CDN Monitoring System: The CDN Monitoring System monitors 237 various aspects of the content such as 239 o Dynamic Content Usage: Number of users simultaneously 240 viewing the same content. 242 o Content Life: If the content is long-lived or short-lived. 243 Examples of long-lived content are movies, catch up 244 episodes, etc., while examples of short-lived content are 245 video clips, advertisements, etc. 247 . CDN Cache: This is the node in the network where the content 248 is cached. 250 For a general overview of CDNs, see [CDN-overview]. 252 3.1. Event Sequence 254 1. The CDN Monitoring System monitors the numbers of users and type 255 of content being accessed. By default, we assume the CDN Cache is 256 bypassed. 258 2. If the number of users viewing the same content exceeds a pre- 259 programmed threshold and the content is long-lived, the CDN 260 Monitoring System instructs the SFC Control Plane Application to 261 dynamically add a CDN Cache to the service chain for that content. 262 This is done by installing a rule for that flow in the SFC edge 263 switch/router. 265 3. If the number of users viewing the same content falls below a 266 pre-programmed threshold and the content is long-lived, the 267 monitoring server instructs the SFC Control Plane Application to a 268 dynamically remove a CDN Cache from the service chain for the 269 content. This is done by removing the rule for that flow from the 270 SFC edge switch/router. 272 4. IPsec Management in Mobile Environments 274 Existing security procedures for flow protection in LTE are based on 275 the use of IPsec tunnels between the radio base stations (eNodeBs) 276 and some central node in the core, where a security gateway (SecGW) 277 is deployed. The eNodeB device located on the cell site initiates 278 the IPSec tunnel through the backhaul network to the SecGW, where 279 the tunnel is terminated and the traffic is forwarded towards its 280 final destination. IPsec ESP is the method that LTE standards use 281 for achieving the required levels of security [TS33.401]. 283 To avoid traffic bottlenecks and in order to guarantee a high level 284 of service availability, a recommended practice is the concurrent 285 use of several SecGW devices. The one that is to be used for a 286 given traffic flow may be determined by several criteria such as the 287 origin of the traffic (user traffic vs network control), flows with 288 well-known characteristics, e.g. security properties (HTTPS, secure 289 VPNs), etc. In this way, more critical traffic can be prioritized, 290 and different levels of security can be applied depending of payload 291 characteristics. 293 Such an optimization could be applied as well to long-lived flows in 294 a dynamic way, relaxing security procedures for non-sensitive ones, 295 e.g. it may not be necessary to secure a well-known video stream 296 that is openly available, applying differentiated policies to avoid 297 congestion, or even hardening the security procedures according to 298 the user's data profile. 300 4.1. Event Sequence 302 1. A monitoring element such as a DPI appliance analyzes the new 303 flows arriving at the default SecGW device used by a given eNodeB 304 device according to criteria such as: 306 . Security payload protection; 308 . Application and transport protocol(s) in use; 310 . Relevant parameters in those protocols (URL, content-transfer 311 declarations, etc.). 313 2. If the monitoring element identifies a long-lived flow that 314 matches its differentiating criteria, it signals the flow to the 315 SFC Control Plane Application. 317 3. The SFC Control Plane Application assigns the flow to a different 318 service function chain that makes the eNodeB device use a 319 different SecGW device. 321 4. Once the flow is becomes inactive, it is aged out by the eNodeB 322 device and signaled as such to the SFC Control Plane Application. 324 5. The SFC Control Plane Application removes the dynamic service 325 chain association that was created for the flow. 327 5. Operational Considerations 329 Any modification to the SFC path (due to insertion or removal of a 330 service function) could result in temporary mis-ordering in the 331 delivery of packets. 333 6. IANA Considerations 335 None. 337 7. Security Considerations 339 This draft specifies a use case for SFC and does not introduce any 340 new security requirements beyond those already under consideration 341 for SFC. 343 8. Acknowledgements 345 9. References 347 9.1. Normative References 349 9.2. Informative References 351 [OPSAWG-large-flow] Krishnan, R. et al., "Mechanisms for Optimal 352 LAG/ECMP Component Link Utilization in Networks," February 2014. 354 [I2RS-large-flow] Krishnan, R. et al., "I2RS Large Flow Use Case," 355 November 2013. 357 [CDNI-long-tail] Krishnan, R. et al., "Best practices and 358 Requirements for delivering Long Tail personalized content delivery 359 over CDN Interconnections," work in progress, May 2013. 361 [CDN-overview] Dilley, J. et al., "Globally distributed content 362 delivery," IEEE Internet Computing, September-October 2002. 364 [RFC 7011] Claise, B., "Specification of the IP Flow Information 365 Export (IPFIX) Protocol for the Exchange of Flow Information," 366 September 2013. 368 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels," March 1997. 371 [TS33.401] 3GPP Technical Specification 33.401, "Security 372 Architecture," December 2013. 374 Authors' Addresses 376 Ram Krishnan 377 Brocade Communications 378 ramk@brocade.com 380 Anoop Ghanwani 381 Dell 382 anoop@alumni.duke.edu 384 Joel Halpern 385 Ericsson 386 joel.halpern@ericsson.com 388 Sriganesh Kini 389 Ericsson 390 Sriganesh.kini@ericsson.com 392 Diego Lopez 393 Telefonica I+D 394 Don Ramon de la Cruz, 82 Street 395 Madrid, 28006, Spain 396 +34 913 129 041 397 diego@tid.es