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