idnits 2.17.1 draft-quinn-sfc-arch-04.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. 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 3734 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 525, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 A. Beliveau, Ed. 5 Expires: August 1, 2014 Ericsson 6 January 28, 2014 8 Service Function Chaining (SFC) Architecture 9 draft-quinn-sfc-arch-04.txt 11 Abstract 13 This document describes an architecture used for the creation of 14 Service Function Chains (SFC). It includes architectural concepts, 15 principles, and components used in the construction of composite 16 services through deployment of SFCs in a network. This document does 17 not propose solutions, protocols, or extensions to existing 18 protocols. 20 Status of this Memo 22 This Internet-Draft is submitted 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). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on August 1, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 57 1.3. Service Function Chaining . . . . . . . . . . . . . . . . 4 58 2. Architectural Concepts . . . . . . . . . . . . . . . . . . . . 6 59 2.1. Service Function Chains . . . . . . . . . . . . . . . . . 6 60 2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 7 61 2.3. Service Function Paths . . . . . . . . . . . . . . . . . . 7 62 3. Service Function Chaining Architecture . . . . . . . . . . . . 8 63 3.1. Architecture Principles . . . . . . . . . . . . . . . . . 8 64 3.2. Fundamental Components . . . . . . . . . . . . . . . . . . 8 65 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 73 Appendix A. Existing Service Deployments . . . . . . . . . . . . 19 74 Appendix B. Issues with Existing Deployments . . . . . . . . . . 20 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 77 1. Introduction 79 This document describes an architecture used for the creation of 80 Service Function Chains (SFC). It includes architectural concepts, 81 principles, and components to provide SFCs in a network. 83 1.1. Scope 85 The architecture described herein is assumed to be applicable to a 86 single network administrative domain. While it is possible for the 87 principles and architectural components to be applied to inter-domain 88 SFCs, these are left for future study. 90 1.2. Definition of Terms 92 Classification: Locally instantiated policy and customer/network/ 93 service profile matching of traffic flows for identification of 94 appropriate outbound forwarding actions. 96 SFC Network Forwarder: SFC network forwarders provide network 97 connectivity for service functions forwarders and service 98 functions. SFC network forwarders participate in the network 99 overlay used for service function chaining as well as in the SFC 100 encapsulation. 102 Service Function Forwarder (SFF): A service function forwarder is 103 responsible for delivering traffic received from the SFC network 104 forwarder to one or more connected service functions. 106 Service Function (SF): A function that is responsible for specific 107 treatment of received packets. A Service Function can act at the 108 network layer or other OSI layers. A Service Function can be a 109 virtual instance or be embedded in a physical network element. 110 One of multiple Service Functions can be embedded in the same 111 network element. Multiple instances of the Service Function can 112 be enabled in the same administrative domain. 114 A non-exhaustive list of Service Functions includes: firewalls, 115 WAN and application acceleration, Deep Packet Inspection (DPI), 116 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID 117 injection, HTTP Header Enrichment functions, TCP optimizer, etc. 119 Service Function Identity (SFID): A unique identifier that 120 represents a service function. SFIDs are unique for each SF 121 within an SFC domain. 123 Service: An offering provided by an operator that is delivered using 124 one or more service functions. This may also be referred to as a 125 composite service. 127 Note: The term "service" is overloaded with varying definitions. 128 For example, to some a service is an offering composed of several 129 elements within the operators network whereas for others a 130 service, or more specifically a network service, is a discrete 131 element such as a firewall. Traditionally, these network services 132 host a set of service functions and have a network locator where 133 the service is hosted. 135 Service Node (SN): Physical or virtual element that hosts one or 136 more service functions and has one or more network locators 137 associated with it for reachability and service delivery. 139 Service Function Chain (SFC): A service Function chain defines an 140 ordered set of service functions that must be applied to packets 141 and/or frames selected as a result of classification. The implied 142 order may not be a linear progression as the architecture allows 143 for nodes that copy to more than one branch. The term service 144 chain is often used as shorthand for service function chain. 146 Service Function Path (SFP): The instantiation of a SFC in the 147 network. Packets follow a service function path from a classifier 148 through the requisite service functions 150 1.3. Service Function Chaining 152 Service chaining enables creation of composite services that consist 153 of an ordered set of Service Functions (SF) that must be applied to 154 packets and/or frames selected as a result of classification. Each 155 SF is referenced using an identifier (SFID) that is unique within an 156 administrative domain. No IANA registry is required to store the 157 identity of SFs. 159 Service Function Chaining is a concept that provides for more than 160 just the application of an ordered set of SFs to selected traffic; 161 rather, it describes a method for deploying SFs in a way that enables 162 ordering and topological independence of those SFs. 164 A basic SFC may utilize an existing overlay technology alongside 165 service specific forwarding in the network to steer traffic through 166 the ordered set of SFs. However, additional information that is 167 shared across a subset of SFs within an SFC may enable value-added 168 services with a richer set of functionality. For example, shared 169 information, such as the results of a classification function, may be 170 passed to downstream SFs to enable the offloading of service function 171 processing. As another example, sharing of information derived at 172 one SF with the rest of the SFs in the SFC would obviate the need to 173 re-derive the same information and simplify the service. 175 2. Architectural Concepts 177 The following sections describe the foundational concepts of service 178 function chaining and the SFC architecture. 180 2.1. Service Function Chains 182 In most networks services are constructed as a sequence of SFs that 183 represent an SFC. As previously stated a SF can be a virtual 184 instance or be embedded in a physical network element, and one or 185 more SFs may be deployed within the same physical network element. 187 At a high level, an SFC creates an abstracted view of a service and 188 specifies the set of required SFs as well as the order in which they 189 must be executed. Graphs, as illustrated in Figure 1, define each 190 SFC. SFs can be part of zero, one, or many SFCs. A given SF can 191 appear one time or multiple times in a given SFC. 193 SFCs can start from the origination point of the service function 194 graph (i.e.: node 1 in Figure 1), or from any subsequent SF node in 195 the graph. SFs may therefore become branching nodes in the graph, 196 with those SFs selecting edges that move traffic to one or more 197 branches. SFCs can have more than one terminus. 199 ,-+-. ,---. ,---. ,---. 200 / \ / \ / \ / \ 201 ( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) 202 \ / \ / \ / \ / 203 `---' `---' `---' `---' 205 ,-+-. ,---. ,---. ,---. ,---. 206 / \ / \ / \ / \ / \ 207 ( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 ) 208 \ / \ / \ / \ / \ / 209 `---' `---' `---' `---' `---' 211 ,-+-. ,---. ,---. ,---. ,---. 212 / \ / \ / \ / \ / \ 213 ( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 ) 214 \ / \ / \ / \ / \ / 215 `---' `---' `---' `---' `---' 216 Figure 1: Service Function Chain Graphs 218 The architecture allows for two or more SFs to be co-resident on the 219 same service node. In these cases, some implementations may choose 220 to use some form of internal inter-process or inter-VM messaging 221 (communication behind the virtual switching element) that is 222 optimized for such an environment. Implementation details of such 223 mechanisms are considered out-of-scope for this document. 225 2.2. Service Function Chain Symmetry 227 SFCs may be unidirectional or bidirectional. A unidirectional SFC 228 requires that traffic be forwarded through the ordered SFs in one 229 direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a 230 symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1). A hybrid 231 SFC has attributes of both unidirectional and bidirectional SFCs; 232 that is to say some SFs require symmetric traffic, whereas other SFs 233 do not process reverse traffic. 235 SFCs may contain cycles; that is traffic may need to traverse more 236 than once one or more SFs within an SFC. 238 2.3. Service Function Paths 240 When an SFC is instantiated into the network it is necessary to 241 select the specific instances of SFs that will be used, and to create 242 the service topology for that SFC using SF's network locator. Thus, 243 instantiation of the SFC results in the creation of a Service 244 Function Path (SFP) and is used for forwarding packets through the 245 SFC. In other words, an SFP is the instantiation of the defined SFC. 247 This abstraction enables the binding of SFCs to specific instances of 248 SFs based on a range of policy attributes defined by the operator. 249 For example, an SFC definition might specify that one of the SF 250 elements is a firewall. However, on the network, there might exist a 251 number of instances of the same firewall (that is to say they enforce 252 the same policy) and only when the SFP is created is one of those 253 firewall instances selected. The selection can be based on a range 254 of policy attributes, ranging from simple to more elaborate criteria. 256 3. Service Function Chaining Architecture 258 3.1. Architecture Principles 260 Service function chaining is predicated on several key architectural 261 principles: 263 1. Topological independence: no changes to the underlay network 264 forwarding topology - implicit, or explicit - are needed to 265 deploy and invoke SFs or SFCs. 267 2. Consistent policy identifiers: a common identifier is used for SF 268 policy selection. 270 3. Classification: traffic that satisfies classification rules is 271 forwarded according to a specific SFC. For example, 272 classification can be as simple as an explicit forwarding entry 273 that forwards all traffic from one address into the SFC. 274 Multiple classification points are possible within an SFC (i.e. 275 forming a service graph) thus enabling changes/update to the SFC 276 by SFs. 278 4. SFC Encapsulation: The SFC encapsulation enables the sharing of 279 metadata/context: the network and SFs no longer exist in separate 280 silos. Metadata/context data can be shared amongst SF and 281 classifiers. In addition to metadata, the encapsulation provides 282 information used to identify the SFP. Transit nodes -- such as 283 router and switches -- simply forward SFC encapsulated packets 284 based on the outer (non-SFC) encapsulation. 286 5. Heterogeneous control/policy points: allowing SFs to use 287 independent mechanisms (out of scope for this document) like IF- 288 MAP or Diameter to populate and resolve local policy and (if 289 needed) local classification criteria. 291 3.2. Fundamental Components 293 The following logical components form the basis of the SFC 294 architecture: 296 1. SF: the concept of a SF evolves; rather than being viewed as a 297 bump in the wire, a SF becomes a resource within a specified 298 administrative domain that is available for consumption. As 299 such, SFs have one or more network locators and a variable set of 300 attributes that describe the function offered. The combination 301 of network locator and attributes are used to construct an SFC. 302 SF send/receive SFC encapsulated data from one or more Service 303 Function Forwarders. 305 2. Service Function Forwarder (SFF): a service function forwarder 306 provides service layer forwarding. An SFF receives packets from 307 a SFC Network Forwarder (see below) and forwards the traffic to 308 the required associated SF(s). 310 3. SFC Network Forwarder (SNF): This component is responsible for 311 forwarding traffic flows along the SFPs they belong to based on 312 information contained in the SFC encapsulation. Since SFCs 313 straddle both the service layer (via the SFC encapsulation) and 314 the network layer (via the network transport), SNFs can provide 315 service path load distribution and failover functionality. For 316 example, SNFs might have two network paths between SF1 and SF2 317 and utilize local metrics for path selection. Similarly, if a 318 path fails, the SFC can utilize local failover to select 319 alternate path(s). 321 +----------------+ 322 |Service Function| 323 | (SF) | 324 +-------+--------+ 325 | 326 SFC Encapsulation 327 | 328 +-------+--------+ 329 | SF Forwarder| 330 | (SFF) | 331 +-------+--------+ 332 | 333 SFC Encapsulation 334 | 335 +-------+--------+ 336 | SFC Network | 337 | Forwarder (SNF)| 338 +----------------+ 339 | 340 Network Overlay Transport 341 | 342 _,....._ 343 ,-' `-. 344 / `. 345 | Network | 346 `. / 347 `.__ _,-' 348 `'''' 350 Figure 2: Service Function Components 352 Classifier: A component that performs traffic classification. 353 Classification is the precursor to the start of an SFP: traffic that 354 matches classification criteria is forwarded along a given SFP to 355 realize the specifications of an SFC. The granularity of 356 classification varies based on operator requirements and device 357 capabilities. While initial classification at a network node starts 358 an SFP, subsequent classifications may occur along the SFC and 359 further alter the SFP. This re-classification may also update the 360 context information (see below). 362 Overlay Service Topology: A service topology is created to 363 interconnect the elements used to form the SFP. This overlay 364 topology is specific to the SFP: it is created for the express 365 purpose of steering packets or frames through the SFs and optionally 366 passing context data. The overlay is formed between SNF elements. 367 The overlay topology can be constructed using any existing transport, 368 for example IP, MPLS, etc. 370 Control plane: The SFC control plane is responsible for constructing 371 the SFPs; translating the SFCs to the forwarding paths and 372 propagating path information to participating nodes - network and 373 service - to achieve requisite forwarding behavior to construct the 374 service overlay. For instance, a SFC construction may be static - 375 using specific SF instances, or dynamic - choosing service explicit 376 SF instances at the time of delivering traffic to the SF. In SFC, 377 SFs are resources; the control plane advertises their capabilities, 378 availability and location. The control plane is also responsible for 379 the creation of the context (see below). The control plane may exist 380 within distributed routing elements as in traditional networks, or in 381 a centralized configuration. 383 Shared context data: Sharing context data allows the network to 384 provide network-derived information to the SFs, SF to SF information 385 exchange and the sharing of service-derived information to the 386 network. This component is optional. SFC infrastructure enables the 387 exchange of this shared context along the SFP. The shared context 388 serves several possible roles within the SFC architecture: 390 o Allows elements that typically operate as ships-in-the-night to 391 exchange information. 393 o Encodes information about the network and/or data for post- 394 service forwarding. 396 o Creates an identifier used for policy binding by SFs. 398 o Context information can be derived in several ways: 400 * External sources 402 * Network node classification 404 * Service function classification 406 o Resource Control: The SFC system may be responsible for managing 407 all resources necessary for the SFC components to function. This 408 includes network constraints used to plan and choose the network 409 path(s) between service nodes, characteristics of the nodes 410 themselves such as memory, number of virtual interfaces, routes, 411 etc..., and configuration of the SFs running on the service nodes. 413 The figure below provides a high level view of the components: 415 +-------+ 416 +---------->|control|<----------+ 417 | |plane | | 418 +-------------->| +---+---+ | 419 | | ^ | 420 | | | | 421 v v v v 422 +----------+ ,---. ,---. ,---. +----------+ 423 |classifier|+---> / \+------->/ \+-------->/ \+-------->|classifier| 424 | | ( 1 )<-----+( 2 )<------+( 3 )<-------+| | 425 +----------+ \ / \ / \ / +----------+ 426 `---' `---' `---' 428 Figure 3: Service Function Chaining Architecture 430 4. Summary 432 Service function chains enable composite services that are 433 constructed from one or more service functions. This document 434 provides a standard architecture, including architectural concepts, 435 principles, and components, for the creation of Service function 436 chains. 438 5. Security Considerations 440 This document does not define a new protocol and therefore creates no 441 new security issues. 443 6. Contributors 445 The following people are active contributors to this document and 446 have provided review, content and concepts (listed alphabetically by 447 surname): 449 Puneet Agarwal 450 Broadcom 451 Email: pagarwal@broadcom.com 453 Kevin Glavin 454 Riverbed 455 Email: Kevin.Glavin@riverbed.com 457 Ken Gray 458 Cisco Systems, Inc. 459 Email: kegray@cisco.com 461 Jim Guichard 462 Cisco Systems, Inc. 463 Email: jguichar@cisco.com 465 Surendra Kumar 466 Cisco Systems, Inc. 467 Email: smkumar@cisco.com 469 Nic Leymann 470 Deutsche Telekom 471 Email: n.leymann@telekom.de 473 Rajeev Manur 474 Broadcom 475 Email: rmanur@broadcom.com 477 Thomas Nadeau 478 Lucidvision 479 Email: tnadeau@lucidvision.com 481 Carlos Pignataro 482 Cisco Systems, Inc. 483 Email: cpignata@cisco.com 485 Michael Smith 486 Cisco Systems, Inc. 487 Email: michsmit@cisco.com 489 Navindra Yadav 490 Cisco Systems, Inc. 492 Email: nyadav@cisco.com 494 7. Acknowledgments 496 The authors would like to thank David Ward, Abhijit Patra, Nagaraj 497 Bagepalli, Darrel Lewis, Ron Parker and Christian Jacquenet for their 498 review and comments. 500 A special thank you goes to Joel Halpern for his thoughtful, detailed 501 review and guidance. 503 8. IANA Considerations 505 This document creates no new requirements on IANA namespaces 506 [RFC5226]. 508 9. References 510 9.1. Normative References 512 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 513 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 514 May 2008. 516 9.2. Informative References 518 [NSCprob] "Network Service Chaining Problem Statement", . 522 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 523 September 1981. 525 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 526 (IPv6) Specification", RFC 2460, December 1998. 528 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 529 Address Translator (Traditional NAT)", RFC 3022, 530 January 2001. 532 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 533 NAT64: Network Address and Protocol Translation from IPv6 534 Clients to IPv4 Servers", RFC 6146, April 2011. 536 Appendix A. Existing Service Deployments 538 Existing service insertion and deployment techniques fail to address 539 new challenging requirements raised by modern network architectures 540 and evolving technologies such as multi-tenancy, virtualization, 541 elasticity, and orchestration. Networks, servers, storage 542 technologies, and applications, have all undergone significant change 543 in recent years: virtualization, network overlays, and orchestration 544 have increasingly become adopted techniques. All of these have 545 profound effects on network and services design. 547 As network service functions evolve, operators are faced with an 548 array of form factors - virtual and physical - as well as with a 549 range of insertion methods that often vary by vendor and type of 550 service. 552 Such existing services are deployed using a range of techniques, most 553 often associated with topology or forwarding modifications. For 554 example, firewalls often rely on layer-2 network changes for 555 deployment: a VLAN is created for the "inside" interface, and another 556 for the "outside" interface. In other words, a new L2 segment was 557 created simply to add a service function. In the case of server load 558 balancers, policy routing is often used to ensure traffic from 559 server's returns to the load balancer. As with the firewall example, 560 the policy routing serves only to ensure that the network traffic 561 ultimately flows to the service function(s). 563 The network-centric information (e.g. VLAN) is not limited to 564 insertion; this information is often used as a policy identifier on 565 the service itself. So, on a firewall, the layer-2 segment 566 identifies the local policy to be selected. If more granular policy 567 discrimination is required, more network identifiers must be created 568 either per-hop, or communicated consistently to all services. 570 Appendix B. Issues with Existing Deployments 572 Due to the tight coupling of network and service function resources 573 in existing networks, adding or removing service functions is a 574 complex task that is fraught with risk and is tied to 575 operationalizing topological changes leading to massively static 576 configuration procedures for network service delivery or update 577 purposes. The inflexibility of such deployments limits (and in many 578 cases precludes) dynamic service scaling (both horizontal and 579 vertical) and requires hop-by-hop configuration to ensure that the 580 correct service functions, and sequence of service functions are 581 traversed. 583 A non-exhaustive list of existing service deployment and insertion 584 techniques as well as the issues associated with each may be found in 585 [NSCprob]. 587 Authors' Addresses 589 Paul Quinn (editor) 590 Cisco Systems, Inc. 592 Email: paulq@cisco.com 594 Andre Beliveau (editor) 595 Ericsson 597 Email: andre.beliveau@ericsson.com