idnits 2.17.1 draft-ietf-sfc-problem-statement-05.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 (April 17, 2014) is 3655 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: October 19, 2014 Brocade 6 April 17, 2014 8 Service Function Chaining Problem Statement 9 draft-ietf-sfc-problem-statement-05.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 instances of such service functions, and the subsequent "steering" 18 of traffic 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 October 19, 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 2.1. Topological Dependencies . . . . . . . . . . . . . . . . . 5 62 2.2. Configuration complexity . . . . . . . . . . . . . . . . . 5 63 2.3. Constrained High Availability . . . . . . . . . . . . . . 6 64 2.4. Consistent Ordering of Service Functions . . . . . . . . . 6 65 2.5. Application of Service Policy . . . . . . . . . . . . . . 6 66 2.6. Transport Dependence . . . . . . . . . . . . . . . . . . . 7 67 2.7. Elastic Service Delivery . . . . . . . . . . . . . . . . . 7 68 2.8. Traffic Selection Criteria . . . . . . . . . . . . . . . . 7 69 2.9. Limited End-to-End Service Visibility . . . . . . . . . . 7 70 2.10. Per-Service (re)Classification . . . . . . . . . . . . . . 7 71 2.11. Symmetric Traffic Flows . . . . . . . . . . . . . . . . . 8 72 2.12. Multi-vendor Service Functions . . . . . . . . . . . . . . 8 73 3. Service Function Chaining . . . . . . . . . . . . . . . . . . 9 74 3.1. Service Overlay . . . . . . . . . . . . . . . . . . . . . 9 75 3.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 9 76 3.3. Service Classification . . . . . . . . . . . . . . . . . . 9 77 3.4. Dataplane Metadata . . . . . . . . . . . . . . . . . . . . 10 78 4. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 11 79 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 83 9. Informative References . . . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 The delivery of end-to-end services often require various service 89 functions including traditional network service functions (for 90 example firewalls and server load balancers), as well as application- 91 specific features. Service functions may be delivered within the 92 context of an isolated user group, or shared amongst many users/user 93 groups. 95 Current service function deployment models are relatively static in 96 that they are tightly coupled to network topology and physical 97 resources. The result of that static nature of existing deployments 98 greatly reduces, and in many cases, limits the ability of an operator 99 to introduce new services and/or service functions. Furthermore 100 there is a cascading effect: service changes affect other services. 102 This document outlines the problems encountered with existing service 103 deployment models for Service Function Chaining (SFC) (often referred 104 to simply as service chaining; in this document the terms will be 105 used interchangeably), as well as the problems of service chain 106 creation, deletion, modification/update, policy integration with 107 service chains, and policy enforcement within the network 108 infrastructure. 110 1.1. Definition of Terms 112 Classification: Locally instantiated policy that results in matching 113 of traffic flows for identification of appropriate outbound 114 forwarding actions. 116 Network Overlay: A logical network built, via virtual links or 117 packet encapsulation, over an existing network (the underlay). 119 Network Service: An externally visible service offered by a network 120 operator; a service may consist of a single service function or a 121 composite built from several service functions executed in one or 122 more pre-determined sequences and delivered by one or more service 123 nodes. 125 Service Function: A function that is responsible for specific 126 treatment of received packets. A Service Function can act at the 127 network layer or other OSI layers. A Service Function can be a 128 virtual instance or be embedded in a physical network element. 129 One of multiple Service Functions can be embedded in the same 130 network element. Multiple instances of the Service Function can 131 be enabled in the same administrative domain. 133 A non-exhaustive list of Service Functions includes: firewalls, 134 WAN and application acceleration, Deep Packet Inspection (DPI), 135 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID 136 injection [RFC6967], HTTP Header Enrichment functions, TCP 137 optimizer, etc. 139 The generic term "L4-L7 services" is often used to describe many 140 service functions. 142 Service Function Chain (SFC): A service Function chain defines an 143 ordered set of service functions that must be applied to packets 144 and/or layer-2 frames selected as a result of classification. The 145 implied order may not be a linear progression as nodes may copy to 146 more than one branch. The term service chain is often used as 147 shorthand for service function chain. 149 Service Function Path (SFP): The instantiation of a service function 150 chain in the network. Packets follow a service function path from 151 a classifier through the required instances of service functions 152 in the network. 154 Service Node (SN): Physical or virtual element that hosts one or 155 more service functions. 157 Service Overlay: An overlay network created for the purpose of 158 forwarding data along a service function path. 160 Service Topology: The service overlay connectivity forms a service 161 topology. 163 2. Problem Space 165 The following points describe aspects of existing service deployments 166 that are problematic, and that the Service Function Chaining (SFC) 167 working group aims to address. 169 2.1. Topological Dependencies 171 Network service deployments are often coupled to network topology, 172 whether it be real or virtualized, or a hybrid of the two. Such 173 dependency imposes constraints on the service delivery, potentially 174 inhibiting the network operator from optimally utilizing service 175 resources, and reduces the flexibility. This limits scale, capacity, 176 and redundancy across network resources. 178 These topologies serve only to "insert" the service function (i.e., 179 ensure that traffic traverses a service function); they are not 180 required from a native packet delivery perspective. For example, 181 firewalls often require an "in" and "out" layer-2 segment and adding 182 a new firewall requires changing the topology (i.e., adding new 183 layer-2 segments). 185 As more service functions are required - often with strict ordering - 186 topology changes are needed before and after each service function 187 resulting in complex network changes and device configuration. In 188 such topologies, all traffic, whether a service function needs to be 189 applied or not, often passes through the same strict order. 191 The topological coupling limits placement and selection of service 192 functions: service functions are "fixed" in place by topology and 193 therefore placement and service function selection taking into 194 account network topology information is not viable. Furthermore, 195 altering the services traversed, or their order, based on flow 196 direction is not possible. 198 A common example is web servers using a server load balancer as the 199 default gateway. When the web service responds to non-load balanced 200 traffic (e.g., administrative or backup operations) all traffic from 201 the server must traverse the load balancer forcing network 202 administrators to create complex routing schemes or create additional 203 interfaces to provide an alternate topology. 205 2.2. Configuration complexity 207 A direct consequence of topological dependencies is the complexity of 208 the entire configuration, specifically in deploying service function 209 chains. Simple actions such as changing the order of the service 210 functions in a service function chain require changes to the 211 topology. Changes to the topology are avoided by the network 212 operator once installed, configured and deployed in production 213 environments fearing misconfiguration and downtime. All of this 214 leads to very static service delivery deployments. Furthermore, the 215 speed at which these topological changes can be made is not rapid or 216 dynamic enough as it often requires manual intervention, or use of 217 slow provisioning systems. 219 2.3. Constrained High Availability 221 An effect of topological dependency is constrained service function 222 high availability. Worse, when modified, inadvertent non-high 223 availability or downtime can result. 225 Since traffic reaches many service functions based on network 226 topology, alternate, or redundant service functions must be placed in 227 the same topology as the primary service. 229 2.4. Consistent Ordering of Service Functions 231 Service functions are typically independent; service function_1 232 (SF1)...service function_n (SFn) are unrelated and there is no notion 233 at the service layer that SF1 occurs before SF2. However, to an 234 administrator many service functions have a strict ordering that must 235 be in place, yet the administrator has no consistent way to impose 236 and verify the ordering of the service functions that are used to 237 deliver a given service. 239 Service function chains today are most typically built through manual 240 configuration processes. These are slow and error prone. With the 241 advent of newer service deployment models the control and policy 242 planes provide not only connectivity state, but will also be 243 increasingly utilized for the creation of network services. Such 244 control/management planes could be centralized, or be distributed. 246 2.5. Application of Service Policy 248 Service functions rely on topology information such as VLANs or 249 packet (re) classification to determine service policy selection, 250 i.e. the service function specific action taken. Topology 251 information is increasingly less viable due to scaling, tenancy and 252 complexity reasons. The topological information is often stale, 253 providing the operator with inaccurate placement that can result in 254 suboptimal resource utilization. Furthermore topology-centric 255 information often does not convey adequate information to the service 256 functions, forcing functions to individually perform more granular 257 classification. 259 2.6. Transport Dependence 261 Service functions can and will be deployed in networks with a range 262 of transports, including under and overlays. The coupling of service 263 functions to topology requires service functions to support many 264 transport encapsulations or for a transport gateway function to be 265 present. 267 2.7. Elastic Service Delivery 269 Given that the current state of the art for adding/removing service 270 functions largely centers around VLANs and routing changes, rapid 271 changes to the service deployment can be hard to realize due to the 272 risk and complexity of such changes. 274 2.8. Traffic Selection Criteria 276 Traffic selection is coarse, that is, all traffic on a particular 277 segment traverse service functions whether the traffic requires 278 service enforcement or not. This lack of traffic selection is 279 largely due to the topological nature of service deployment since the 280 forwarding topology dictates how (and what) data traverses service 281 function(s). In some deployments, more granular traffic selection is 282 achieved using policy routing or access control filtering. This 283 results in operationally complex configurations and is still 284 relatively inflexible. 286 2.9. Limited End-to-End Service Visibility 288 Troubleshooting service related issues is a complex process that 289 involve both network-specific and service-specific expertise. This 290 is especially the case when service function chains span multiple 291 DCs, or across administrative boundaries. Furthermore, the physical 292 and virtual environments (network and service), can be highly 293 divergent in terms of topology and that topological variance adds to 294 these challenges. 296 2.10. Per-Service (re)Classification 298 Classification occurs at each service function independent from 299 previously applied service functions. More importantly, the 300 classification functionality often differs per service function and 301 service functions may not leverage the results from other service 302 functions. 304 2.11. Symmetric Traffic Flows 306 Service function chains may be unidirectional or bidirectional 307 depending on the state requirements of the service functions. In a 308 unidirectional chain traffic is passed through a set of service 309 functions in one forwarding direction only. Bidirectional chains 310 require traffic to be passed through a set of service functions in 311 both forwarding directions. Many common service functions such as 312 DPI and firewall often require bidirectional chaining in order to 313 ensure flow state is consistent. 315 Existing service deployment models provide a static approach to 316 realizing forward and reverse service function chain association most 317 often requiring complex configuration of each network device 318 throughout the SFC. 320 2.12. Multi-vendor Service Functions 322 Deploying service functions from multiple vendors often require per- 323 vendor expertise: insertion models differ, there are limited common 324 attributes and inter- vendor service functions do not share 325 information. 327 3. Service Function Chaining 329 Service Function Chaining aims to address the aforementioned problems 330 associated with service deployment. Concretely, the SFC working 331 group will investigate solutions that address the following elements: 333 3.1. Service Overlay 335 Service function chaining utilizes a service specific overlay that 336 creates the service topology. The service overlay provides service 337 function connectivity and is built "on top" of the existing network 338 topology and allows operators to use whatever overlay or underlay 339 they prefer to create a path between service functions, and to locate 340 service functions in the network as needed. 342 Within the service topology, service functions can be viewed as 343 resources for consumption and an arbitrary topology constructed to 344 connect those resources in a required order. Adding new service 345 functions to the topology is easily accomplished, and no underlying 346 network changes are required. 348 Lastly, the service overlay can provide service specific information 349 needed for troubleshooting service-related issues. 351 3.2. Control Plane 353 Service aware control plane(s) provide information about the 354 available service functions on a network. The information provided 355 by the control plane includes service network location (for topology 356 creation), service type (e.g. firewall, load balancer, etc.) and, 357 optionally, administrative information about the service functions 358 such as load, capacity and operating status. The service aware 359 control plane allows for the formulation of service function chains 360 and exchanges requisite information needed to instantiate the service 361 function chains in the network. 363 Furthermore, the service aware control plane may interact with the 364 topology aware control plane (if separate) to ensure optimal 365 selection (and possibly placement) of service functions within a 366 service function path. 368 3.3. Service Classification 370 Classification is used to select which traffic enters a service 371 overlay. The granularity of the classification varies based on 372 device capabilities, customer requirements, and service offered. 373 Initial classification determines the service function chain required 374 to process the traffic. Subsequent classification can be used within 375 a given service function chain to alter the sequence of service 376 functions applied. Symmetric classification ensures that forward and 377 reverse chains are in place. Similarly, asymmetric -- relative to 378 required service function -- chains can be achieved via service 379 classification. 381 3.4. Dataplane Metadata 383 Data plane metadata provides the ability to exchange information 384 between logical classification points and service functions (and vice 385 versa) and between service functions. As such metadata is not used 386 as forwarding information to deliver packets along the service 387 overlay. 389 Metadata can include the result of antecedent classification and/or 390 information from external sources. Service functions utilize 391 metadata, as required, for localized policy decisions. 393 In addition to sharing of information, the use of metadata addresses 394 several of the issues raised in section 2, most notably the de- 395 coupling of policy from the topology, and the need for per-service 396 classification (and re-classification). 398 A common approach to service metadata creates a common foundation for 399 interoperability between service functions, regardless of vendor. 401 4. Related IETF Work 403 The following subsections discuss related IETF work and are provided 404 for reference. This section is not exhaustive, rather it provides an 405 overview of the various initiatives and how they relate to network 406 service chaining. 408 1. [L3VPN]: The L3VPN working group is responsible for defining, 409 specifying and extending BGP/MPLS IP VPNs solutions. Although 410 BGP/MPLS IP VPNs can be used as transport for service chaining 411 deployments, the SFC WG focuses on the service specific 412 protocols, not the general case of VPNs. Furthermore, BGP/MPLS 413 IP VPNs do not address the requirements for service chaining. 415 2. [LISP]: LISP provides locator and ID separation. LISP can be 416 used as an L3 overlay to transport service chaining data but does 417 not address the specific service chaining problems highlighted in 418 this document. 420 3. [NVO3]: The NVO3 working group is chartered with creation of 421 problem statement and requirements documents for multi-tenant 422 network overlays. NVO3 WG does not address service chaining 423 protocols. 425 4. [ALTO]: The Application Layer Traffic Optimization Working Group 426 is chartered to provide topological information at a higher 427 abstraction layer, which can be based upon network policy, and 428 with application-relevant service functions located in it. The 429 mechanism for ALTO obtaining the topology can vary and policy can 430 apply to what is provided or abstracted. This work could be 431 leveraged and extended to address the need for services 432 discovery. 434 5. [I2RS]: The Interface to the Routing System Working Group is 435 chartered to investigate the rapid programming of a device's 436 routing system, as well as the service of a generalized, multi- 437 layered network topology. This work could be leveraged and 438 extended to address some of the needs for service chaining in the 439 topology and device programming areas. 441 6. [ForCES]: The ForCES working group has created a framework, 442 requirements, a solution protocol, a logical function block 443 library, and other associated documents in support of Forwarding 444 and Control Element Separation. The work done by ForCES may 445 provide a basis for both the separation of SFC elements, as well 446 as provide protocol and design guidance for those elements. 448 5. Summary 450 This document highlights problems associated with network service 451 deployment today and identifies several key areas that will be 452 addressed by the SFC working group. Furthermore, this document 453 identifies four components that are the basis for service function 454 chaining. These components will form the areas of focus for the 455 working group. 457 6. Security Considerations 459 Security considerations are not addressed in this problem statement 460 only document. Given the scope of service chaining, and the 461 implications on data and control planes, security considerations are 462 clearly important and will be addressed in the specific protocol and 463 deployment documents created by the SFC WG. 465 7. Contributors 467 The following people are active contributors to this document and 468 have provided review, content and concepts (listed alphabetically by 469 surname): 471 Puneet Agarwal 472 Broadcom 473 Email: pagarwal@broadcom.com 475 Mohamed Boucadair 476 France Telecom 477 Email: mohamed.boucadair@orange.com 479 Abhishek Chauhan 480 Citrix 481 Email: Abhishek.Chauhan@citrix.com 483 Uri Elzur 484 Intel 485 Email: uri.elzur@intel.com 487 Kevin Glavin 488 Riverbed 489 Email: Kevin.Glavin@riverbed.com 491 Ken Gray 492 Cisco Systems 493 Email: kegray@cisco.com 495 Jim Guichard 496 Cisco Systems 497 Email:jguichar@cisco.com 499 Christian Jacquenet 500 France Telecom 501 Email: christian.jacquenet@orange.com 503 Surendra Kumar 504 Cisco Systems 505 Email: smkumar@cisco.com 507 Nic Leymann 508 Deutsche Telekom 509 Email: n.leymann@telekom.de 511 Darrel Lewis 512 Cisco Systems 513 Email: darlewis@cisco.com 515 Rajeev Manur 516 Broadcom 517 Email:rmanur@broadcom.com 519 Brad McConnell 520 Rackspace 521 Email: bmcconne@rackspace.com 523 Carlos Pignataro 524 Cisco Systems 525 Email: cpignata@cisco.com 527 Michael Smith 528 Cisco Systems 529 Email: michsmit@cisco.com 531 Navindra Yadav 532 Cisco Systems 533 Email: nyadav@cisco.com 535 8. Acknowledgments 537 The authors would like to thank David Ward, Rex Fernando, David 538 Mcdysan, Jamal Hadi Salim, Charles Perkins, Andre Beliveau, Joel 539 Halpern and Jim French for their reviews and comments. 541 9. Informative References 543 [ALTO] "Application-Layer Traffic Optimization (alto)", 544 . 546 [ForCES] "Forwarding and Control Element Separation (forces)", 547 . 549 [I2RS] "Interface to the Routing System (i2rs)", 550 . 552 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)", 553 . 555 [LISP] "Locator/ID Separation Protocol (lisp)", 556 . 558 [NVO3] "Network Virtualization Overlays (nvo3)", 559 . 561 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 562 Address Translator (Traditional NAT)", RFC 3022, 563 January 2001. 565 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 566 NAT64: Network Address and Protocol Translation from IPv6 567 Clients to IPv4 Servers", RFC 6146, April 2011. 569 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 570 "Analysis of Potential Solutions for Revealing a Host 571 Identifier (HOST_ID) in Shared Address Deployments", 572 RFC 6967, June 2013. 574 Authors' Addresses 576 Paul Quinn (editor) 577 Cisco Systems, Inc. 579 Email: paulq@cisco.com 581 Thomas Nadeau (editor) 582 Brocade 584 Email: tnadeau@lucidvision.com