idnits 2.17.1 draft-ietf-sfc-problem-statement-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 28, 2014) is 3739 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6459' is mentioned on line 355, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Quinn, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational T. Nadeau, Ed. 5 Expires: August 1, 2014 Lucidvision 6 January 28, 2014 8 Service Function Chaining Problem Statement 9 draft-ietf-sfc-problem-statement-00.txt 11 Abstract 13 This document provides an overview of the issues associated with the 14 deployment of service functions (such as firewalls, load balancers) 15 in large-scale environments. The term service function chaining is 16 used to describe the definition and instantiation of an ordered set 17 of such service functions, and the subsequent "steering" of traffic 18 flows through those service functions. 20 The set of enabled service function chains reflect operator service 21 offerings and is designed in conjunction with application delivery 22 and service and network policy. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 1, 2014. 41 Copyright 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. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 60 2. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Service Function Chaining . . . . . . . . . . . . . . . . . . 8 62 4. Service Function Chaining Use Cases . . . . . . . . . . . . . 10 63 4.1. Enterprise Data Center Service Chaining . . . . . . . . . 10 64 4.2. 3GPP Gi Interface Service Function Chaining . . . . . . . 10 65 5. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 12 66 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 70 10. Informative References . . . . . . . . . . . . . . . . . . . . 17 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 73 1. Introduction 75 The delivery of end-to-end services often require various Service 76 Functions (SF) including traditional network service functions (for 77 example firewalls and server load balancers), as well as application- 78 specific features. Service functions may be delivered within the 79 context of an isolated user group, or shared amongst many users/user 80 groups 82 Current service function deployment models are relatively static in 83 that they are tightly coupled to network topology and physical 84 resources. The result of that static nature of existing deployments 85 greatly reduces, and in many cases, limits the ability of an operator 86 to introduce new services and/or service functions. Furthermore 87 there is a cascading effect: service changes affect other services. 89 This document outlines the problems encountered with existing service 90 deployment models for Service Function Chaining (SFC) (often referred 91 to simply as service chaining; in this document the terms will be 92 used interchangeably), as well as the problems of service chain 93 creation/ deletion, policy integration with service chains, and 94 policy enforcement within the network infrastructure. 96 1.1. Definition of Terms 98 Classification: Locally instantiated customer/network/service policy 99 used to identify and select traffic flow(s) requiring appropriate 100 outbound forwarding actions. 102 Network Overlay: A logical network built, via virtual links or 103 packet encapsulation, over an existing network (the underlay). 105 Service Function Chain: A service chain defines an ordered set of 106 service functions that must be applied to packets and/or frames 107 selected as a result of classification 109 Service Function: A function that is responsible for specific 110 treatment of received packets. A Service Function can act at the 111 network layer or other OSI layers. A Service Function can be a 112 virtual instance or be embedded in a physical network element. 113 One of multiple Service Functions can be embedded in the same 114 network element. Multiple instances of the Service Function can 115 be enabled in the same administrative domain. 117 A non-exhaustive list of Service Functions includes: firewalls, 118 WAN and application acceleration, Deep Packet Inspection (DPI), 119 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID 120 injection [RFC6967], HTTP Header Enrichment functions, TCP 121 optimizer, etc. 123 The generic term "L4-L7 services" is often used to describe many 124 service functions. 126 Service Node: Physical or virtual element offering one or more 127 Service Functions. 129 Network Service: An externally visible service offered by a network 130 operator; a service may consist of a single service function or a 131 composite built from several service functions executed in one or 132 more pre-determined sequences and delivered by one or more service 133 nodes. 135 2. Problem Space 137 The following points describe aspects of existing service deployments 138 that are problematic, and are being addressed by the Service Function 139 Chaining effort. 141 1. Topological Dependencies: Network service deployments are often 142 coupled to network topology. Such dependency imposes 143 constraints on the service delivery, potentially inhibiting the 144 network operator from optimally utilizing service resources, and 145 reduces the flexibility. This limits scale, capacity, and 146 redundancy across network resources. 148 These topologies serve only to "insert" the service function 149 (i.e., ensure that traffic traverses a service function); they 150 are not required from a native packet delivery perspective. For 151 example, firewalls often require an "in" and "out" layer-2 152 segment and adding a new firewall requires changing the topology 153 (i.e., adding new layer-2 segments). 155 As more service functions are required - often with strict 156 ordering - topology changes are needed before and after each 157 service function resulting in complex network changes and device 158 configuration. In such topologies, all traffic, whether a 159 service function needs to be applied or not, often passes 160 through the same strict order. 162 A common example is web servers using a server load balancer as 163 the default gateway. When the web service responds to non-load 164 balanced traffic (e.g., administrative or backup operations) all 165 traffic from the server must traverse the load balancer forcing 166 network administrators to create complex routing schemes or 167 create additional interfaces to provide an alternate topology. 169 2. Configuration complexity: A direct consequence of topological 170 dependencies is the complexity of the entire configuration, 171 specifically in deploying service function chains. Simple 172 actions such as changing the order of the service functions in a 173 service function chain require changes to the topology. Changes 174 to the topology are avoided by the network operator once 175 installed, configured and deployed in production environments 176 fearing misconfiguration and downtime. All of this leads to 177 very static service delivery deployments. Furthermore, the 178 speed at which these topological changes can be made is not 179 rapid or dynamic enough as it often requires manual 180 intervention, or use of slow provisioning systems. 182 The service itself can contribute to the complexity: it may 183 require an intricate combination of very different capabilities, 184 regardless of the underlying topology. QoS-based, resilient VPN 185 service offerings are a typical example of such complex service 186 offerings. 188 3. Constrained High Availability: An effect of topological 189 dependency is constrained service function high availability. 190 Worse, when modified, inadvertent non-high availability or 191 downtime can result. 193 Since traffic reaches many service functions based on network 194 topology, alternate, or redundant service functions must be 195 placed in the same topology as the primary service. 197 4. Consistent Ordering of Service Functions: Service functions are 198 typically independent; service function_1 (SF1)...service 199 function_n (SFn) are unrelated and there is no notion at the 200 service layer that SF1 occurs before SF2. However, to an 201 administrator many service functions have a strict ordering that 202 must be in place, yet the administrator has no consistent way to 203 impose and verify the ordering of the functions that are used to 204 deliver a given service. 206 5. Service Chain Construction: Service function chains today are 207 most typically built through manual configuration processes. 208 These are slow and error prone. With the advent of newer 209 service deployment models the control/management planes provide 210 not only connectivity state, but will also be increasingly 211 utilized for the creation of network services. Such a control/ 212 management planes could be centralized, or be distributed. 214 6. Application of Service Policy: Service functions rely on 215 topology information such as VLANs or packet (re) classification 216 to determine service policy selection, i.e. the service function 217 specific action taken. Topology information is increasingly 218 less viable due to scaling, tenancy and complexity reasons. The 219 topological information is often stale, providing the operator 220 with inaccurate placement that can result in suboptimal resource 221 utilization. Furthermore topology-centric information often 222 does not convey adequate information to the service functions, 223 forcing functions to individually perform more granular 224 classification. 226 7. Transport Dependence: Service functions can and will be deployed 227 in networks with a range of transports, including under and 228 overlays. The coupling of service functions to topology 229 requires service functions to support many transports or for a 230 transport gateway function to be present. 232 8. Elastic Service Delivery: Given the current state of the art for 233 adding/removing service functions largely centers around VLANs 234 and routing changes, rapid changes to the service deployment can 235 be hard to realize due to the risk and complexity of such 236 changes. 238 9. Traffic Selection Criteria: Traffic selection is coarse, that 239 is, all traffic on a particular segment traverse service 240 functions whether the traffic requires service enforcement or 241 not. This lack of traffic selection is largely due to the 242 topological nature of service deployment since the forwarding 243 topology dictates how (and what) data traverses service 244 function(s). In some deployments, more granular traffic 245 selection is achieved using policy routing or access control 246 filtering. This results in operationally complex configurations 247 and is still relatively inflexible. 249 10. Limited End-to-End Service Visibility: Troubleshooting service 250 related issues is a complex process that involve both network- 251 specific and service-specific expertise. This is especially the 252 case when service function chains span multiple DCs, or across 253 administrative boundaries. Furthermore, the physical and 254 virtual environments (network and service), can be highly 255 divergent in terms of topology and that topological variance 256 adds to these challenges. 258 11. Per-Service (re)Classification: Classification occurs at each 259 service function independent from previously applied service 260 functions. More importantly, the classification functionality 261 often differs per service function and service functions may not 262 leverage the results from other service functions. 264 12. Symmetric Traffic Flows: Service function chains may be 265 unidirectional or bidirectional; unidirectional is one where 266 traffic is passed through a set of service functions in one 267 forwarding direction only. Bidirectional is one where traffic 268 is passed through a set of service functions in both forwarding 269 directions. Existing service deployment models provide a static 270 approach to realizing forward and reverse service function chain 271 association most often requiring complex configuration of each 272 network device throughout the forwarding path. 274 13. Multi-vendor Service Functions: Deploying service functions from 275 multiple vendors often require per-vendor expertise: insertion 276 models differ, there are limited common attributes and inter- 277 vendor service functions do not share information. 279 3. Service Function Chaining 281 Service Function Chaining aims to address the aforementioned problems 282 associated with service deployment. Concretely, SFC will investigate 283 solutions that address the following elements: 285 1. Service Overlay: Service function chaining utilizes a service 286 specific overlay that creates the service topology. The service 287 overlay is independent of the network topology and allows 288 operators to use whatever overlay or underlay they prefer to 289 create a path between Service nodes, and to locate service 290 functions in the network as needed. 292 Within the service topology, service functions can be viewed as 293 resources for consumption and an arbitrary topology constructed 294 to connect those resources in a required order. Adding new 295 service functions to the topology is easily accomplished, and no 296 underlying network changes are required. 298 Lastly, the service overlay can provide service specific 299 information needed for troubleshooting service-related issues. 301 2. Control Plane: Service aware control plane(s) provide information 302 about the available service functions on a network. The 303 information provided by the control plane includes service 304 network location (for topology creation), service type (e.g. 305 firewall, load balancer, etc.) and, optionally, administrative 306 information about the service functions such as load, capacity 307 and operating status. The service aware control plane allows for 308 the formulation of service function chains and exchanges 309 requisite information needed to instantiate the service function 310 chains in the network. 312 3. Service Classification: Classification is used to select which 313 traffic enters a service overlay. The granularity of the 314 classification varies based on device capabilities, customer 315 requirements, and service offered. Initial classification is 316 used to start the service function chain. Subsequent 317 classification can be used within a given service function chain 318 to alter the sequence of service functions applied. Symmetric 319 classification ensures that forward and reverse chains are in 320 place. 322 4. Dataplane Metadata: Data plane metadata provides the ability to 323 exchange information between the network and service functions, 324 between service functions, and service functions and the network. 325 Metadata can include the result of antecedent classification, 326 information from external sources or forwarding related data. 328 For example, service functions utilize metadata, as required, for 329 localized policy decisions. 331 In addition to sharing of information, the use of metadata 332 addresses several of the issues raised in section 2, most notably 333 the de-coupling of policy from the topology, and the need for 334 per-service classification (and re-classification). 336 A common approach to service metadata creates a common foundation 337 for interoperability between service functions, regardless of 338 vendor. 340 4. Service Function Chaining Use Cases 342 The following sections provide high level overviews of several common 343 service chaining deployments. 345 4.1. Enterprise Data Center Service Chaining 347 TBD 349 4.2. 3GPP Gi Interface Service Function Chaining 351 3GPP defines the Gi interface as the reference point between the GGSN 352 (Gateway GPRS Support Node) and an external PDN (Packet Domain 353 Network) [RFC6459]. This interface reference point is called SGi in 354 4G networks (i.e., between the PDN Gateway and an external PDN) 355 [RFC6459]. Note, there is no standard specification of such 356 reference points (i.e., Gi and SGi) in terms of functions to be 357 located in that segment. 359 In light of current deployments, plenty of Service Functions are 360 enabled in the Gi Interface (e.g., DPI, billing and charging, TCP 361 optimization, web optimization, video optimization, header 362 enrichment, etc.). Some of these Service Functions are co-located on 363 the same device while others are enabled in standalone boxes. In 364 order to fulfill new business needs, especially to offer innovative 365 added-value services, the number of enabled Service Functions in the 366 Gi Interface is still growing. 368 Several (S)Gi Interfaces can be deployed within the same PLMN (Public 369 Land Mobile Network). This depends mainly on the number of PDNs and 370 other factors. Each of these interfaces may involve a differentiated 371 set of Service Functions to be involved. 373 The current model that consists of adding new "boxes" to fulfill new 374 business guidelines has shown its limit. Concretely, current 375 deployments suffer from the following problems: 377 o Complexity to introduce new Service Functions because of the 378 constraint on the underlying topology. 380 o Lack of visibility on dependency between Service Functions. 382 o Lack of automated and flexible means to assess the impact of 383 withdrawing a Service Function or a feature offered by a Service 384 Function from the traffic forwarding path. 386 o The connectivity service logic may be stalled because of the 387 dependency on the physical topology. 389 o Lack of deterministic means to: 391 * Improve service provisioning and delivery. 393 * Ease the manageability of the SGi/Gi Interface. 395 5. Related IETF Work 397 The following subsections discuss related IETF work and are provided 398 for reference. This section is not exhaustive, rather it provides an 399 overview of the various initiatives and how they relate to network 400 service chaining. 402 1. [L3VPN]: The L3VPN working group is responsible for defining, 403 specifying and extending BGP/MPLS IP VPNs solutions. Although 404 BGP/MPLS IP VPNs can be used as transport for service chaining 405 deployments, the service chaining WG focuses on the service 406 specific protocols, not the general case of VPNs. Furthermore, 407 BGP/MPLS IP VPNs do not address the requirements for service 408 chaining. 410 2. [LISP]: LISP provides locator and ID separation. LISP can be 411 used as an L3 overlay to transport service chaining data but does 412 not address the specific service chaining problems highlighted in 413 this document. 415 3. [NVO3]: The NVO3 working group is chartered with creation of 416 problem statement and requirements documents for multi-tenant 417 network overlays. NVO3 WG does not address service chaining 418 protocols. 420 4. [ALTO]: The Application Layer Traffic Optimization Working Group 421 is chartered to provide topological information at a higher 422 abstraction layer, which can be based upon network policy, and 423 with application-relevant service functions located in it. The 424 mechanism for ALTO obtaining the topology can vary and policy can 425 apply to what is provided or abstracted. This work could be 426 leveraged and extended to address the need for services 427 discovery. 429 5. [I2RS]: The Interface to the Routing System Working Group is 430 chartered to investigate the rapid programming of a device's 431 routing system, as well as the service of a generalized, multi- 432 layered network topology. This work could be leveraged and 433 extended to address some of the needs for service chaining in the 434 topology and device programming areas. 436 6. Summary 438 This document highlights problems associated with network service 439 deployment today and identifies several key areas that will be 440 addressed by the service chaining working group. Furthermore, this 441 document identifies four components that are the basis for serice 442 chaining. These components will form the areas of focus for the 443 working group. 445 7. Security Considerations 447 Security considerations are not addressed in this problem statement 448 only document. Given the scope of service chaining, and the 449 implications on data and control planes, security considerations are 450 clearly important and will be addressed in the specific protocol and 451 deployment documents created by the service chaining working group. 453 8. Contributors 455 The following people are active contributors to this document and 456 have provided review, content and concepts (listed alphabetically by 457 surname): 459 Puneet Agarwal (pagarwal@broadcom.com), Mohamed Boucadair 460 (mohamed.boucadair@orange.com), Abhishek Chauhan 461 (Abhishek.Chauhan@citrix.com), Uri Elzur (uri.elzur@intel.com), Kevin 462 Glavin (Kevin.Glavin@riverbed.com), Ken Gray (kgray@juniper.net), Jim 463 Guichard (jguichar@cisco.com), Christian Jacquenet 464 (christian.jacquenet@orange.com), Surendra Kumar (smkumar@cisco.com), 465 Nic Leymann (n.leymann@telekom.de), Darrel Lewis 466 (darlewis@cisco.com), Rajeev Manur (rmanur@broadcom.com), Brad 467 McConnell (bmcconne@rackspace.com), Carlos Pignataro 468 (cpignata@cisco.com), Michael Smith (michsmit@insiemenetworks.com), 469 Navindra Yadav (nyadav@insiemenetworks.com). 471 9. Acknowledgments 473 The authors would like to thank David Ward, Rex Fernando and Jim 474 French for their contributions. 476 10. Informative References 478 [ALTO] "Application-Layer Traffic Optimization (alto)", 479 . 481 [I2RS] "Interface to the Routing System (i2rs)", 482 . 484 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)", 485 . 487 [LISP] "Locator/ID Separation Protocol (lisp)", 488 . 490 [NVO3] "Network Virtualization Overlays (nvo3)", 491 . 493 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 494 Address Translator (Traditional NAT)", RFC 3022, 495 January 2001. 497 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 498 NAT64: Network Address and Protocol Translation from IPv6 499 Clients to IPv4 Servers", RFC 6146, April 2011. 501 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 502 "Analysis of Potential Solutions for Revealing a Host 503 Identifier (HOST_ID) in Shared Address Deployments", 504 RFC 6967, June 2013. 506 Authors' Addresses 508 Paul Quinn (editor) 509 Cisco Systems, Inc. 511 Email: paulq@cisco.com 513 Thomas Nadeau (editor) 514 Lucidvision 516 Email: tnadeau@lucidvision.com