idnits 2.17.1 draft-quinn-sfc-arch-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 : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 447: '... These platforms MAY opt to use a tran...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 5, 2014) is 3645 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 882, 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) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 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 J. Halpern, Ed. 5 Expires: November 6, 2014 Ericsson 6 May 5, 2014 8 Service Function Chaining (SFC) Architecture 9 draft-quinn-sfc-arch-05.txt 11 Abstract 13 This document describes an architecture for the specification, 14 creation, and ongoing maintenance of Service Function Chains (SFC) in 15 a network. It includes architectural concepts, principles, and 16 components used in the construction of composite services through 17 deployment of SFCs. This document does not propose solutions, 18 protocols, or extensions to existing 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 November 6, 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 2. Architectural Concepts . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Service Function Chains . . . . . . . . . . . . . . . . . 5 59 2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 6 60 2.3. Service Function Paths . . . . . . . . . . . . . . . . . . 6 61 3. Architecture Principles . . . . . . . . . . . . . . . . . . . 7 62 4. Core SFC Architecture Components . . . . . . . . . . . . . . . 8 63 4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 9 64 4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 9 65 4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . . 9 66 4.3.1. Transport Derived SFF . . . . . . . . . . . . . . . . 11 67 4.4. Network Forwarder (NF) . . . . . . . . . . . . . . . . . . 11 68 4.5. Classification/Re-classification . . . . . . . . . . . . . 11 69 4.6. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 12 70 4.7. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 13 71 4.8. Resource Control . . . . . . . . . . . . . . . . . . . . . 13 72 5. The Role of Policy . . . . . . . . . . . . . . . . . . . . . . 14 73 6. Load Balancing Considerations . . . . . . . . . . . . . . . . 15 74 7. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 8. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 19 76 9. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 79 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 81 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 82 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 83 15.1. Normative References . . . . . . . . . . . . . . . . . . . 27 84 15.2. Informative References . . . . . . . . . . . . . . . . . . 27 85 Appendix A. Existing Service Deployments . . . . . . . . . . . . 28 86 Appendix B. Issues with Existing Deployments . . . . . . . . . . 29 87 Appendix C. SFC Encapsulation Requirements . . . . . . . . . . . 30 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 90 1. Introduction 92 This document describes an architecture used for the creation of 93 Service Function Chains (SFC) in a network. It includes 94 architectural concepts, principles, and components. 96 Service Function Chaining enables the creation of composite services 97 that consist of an ordered set of Service Functions (SF) that must be 98 applied to packets and/or frames selected as a result of 99 classification. Each SF is referenced using an identifier that is 100 unique within an administrative domain. No IANA registry is required 101 to store the identity of SFs. 103 Service Function Chaining is a concept that provides for more than 104 just the application of an ordered set of SFs to selected traffic; 105 rather, it describes a method for deploying SFs in a way that enables 106 dynamic ordering and topological independence of those SFs as well as 107 the exchange of metadata between participating entities. 109 1.1. Scope 111 The architecture described herein is assumed to be applicable to a 112 single network administrative domain. While it is possible for the 113 architectural principles and components to be applied to inter-domain 114 SFCs, these are left for future study. 116 1.2. Definition of Terms 118 Classification: Locally instantiated policy and customer/network/ 119 service profile matching of traffic flows for identification of 120 appropriate outbound forwarding actions. 122 SFC Network Forwarder (NF): SFC network forwarders provide network 123 connectivity for service function forwarders (SFF) and service 124 functions (SF). 126 Service Function Forwarder (SFF): A service function forwarder is 127 responsible for delivering traffic received from the SFC network 128 forwarder to one or more connected service functions via 129 information carried in the SFC encapsulation. 131 Service Function (SF): A function that is responsible for specific 132 treatment of received packets. A Service Function can act at the 133 network layer or other OSI layers. A Service Function can be a 134 virtual instance or be embedded in a physical network element. 135 One of multiple Service Functions can be embedded in the same 136 network element. Multiple instances of the Service Function can 137 be enabled in the same administrative domain. 139 A non-exhaustive list of Service Functions includes: firewalls, 140 WAN and application acceleration, Deep Packet Inspection (DPI), 141 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID 142 injection, HTTP Header Enrichment functions, TCP optimizer, etc. 144 An SF may be SFC encapsulation aware, that is it receives, and 145 acts on information in the SFC encapsulation, or unaware in which 146 case data forwarded to the service does not contain the SFC 147 encapsulation. 149 Service Function Identity (SFID): A unique identifier that 150 represents a service function. SFIDs are unique for each SF 151 within an SFC domain. 153 Service: An offering provided by an operator that is delivered using 154 one or more service functions. This may also be referred to as a 155 composite service. 157 Note: The term "service" is overloaded with varying definitions. 158 For example, to some a service is an offering composed of several 159 elements within the operators network whereas for others a 160 service, or more specifically a network service, is a discrete 161 element such as a firewall. Traditionally, these network services 162 host a set of service functions and have a network locator where 163 the service is hosted. 165 Service Node (SN): Physical or virtual element that hosts one or 166 more service functions and has one or more network locators 167 associated with it for reachability and service delivery. 169 Service Function Chain (SFC): A service Function chain defines an 170 ordered set of service functions that must be applied to packets 171 and/or frames selected as a result of classification. The implied 172 order may not be a linear progression as the architecture allows 173 for nodes that copy to more than one branch. The term service 174 chain is often used as shorthand for service function chain. 176 SFC Proxy: Removes and inserts SFC encapsulation on behalf of a SFC- 177 unaware service function. SFC proxies are logical elements. 179 Service Function Path (SFP): The instantiation of a SFC in the 180 network. Packets follow a service function path from a classifier 181 through the requisite service functions 183 2. Architectural Concepts 185 The following sections describe the foundational concepts of service 186 function chaining and the SFC architecture. 188 2.1. Service Function Chains 190 In most networks services are constructed as a sequence of SFs that 191 represent an SFC. At a high level, an SFC creates an abstracted view 192 of a service and specifies the set of required SFs as well as the 193 order in which they must be executed. Graphs, as illustrated in 194 Figure 1, define each SFC. SFs can be part of zero, one, or many 195 SFCs. A given SF can appear one time or multiple times in a given 196 SFC. 198 SFCs can start from the origination point of the service function 199 graph (i.e.: node 1 in Figure 1), or from any subsequent SF node in 200 the graph. SFs may therefore become branching nodes in the graph, 201 with those SFs selecting edges that move traffic to one or more 202 branches. SFCs can have more than one terminus. 204 ,-+-. ,---. ,---. ,---. 205 / \ / \ / \ / \ 206 ( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) 207 \ / \ / \ / \ / 208 `---' `---' `---' `---' 210 ,-+-. ,---. ,---. ,---. ,---. 211 / \ / \ / \ / \ / \ 212 ( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 ) 213 \ / \ / \ / \ / \ / 214 `---' `---' `---' `---' `---' 216 ,-+-. ,---. ,---. ,---. ,---. 217 / \ / \ / \ / \ / \ 218 ( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 ) 219 \ / \ / \ / \ / \ / 220 `---' `---' `---' `---' `---' 222 Figure 1: Service Function Chain Graphs 224 The architecture allows for two or more SFs to be co-resident on the 225 same service node. In these cases, some implementations may choose 226 to use some form of internal inter-process or inter-VM messaging 227 (communication behind the virtual switching element) that is 228 optimized for such an environment. Implementation details of such 229 mechanisms are considered out-of-scope for this document. 231 2.2. Service Function Chain Symmetry 233 SFCs may be unidirectional or bidirectional. A unidirectional SFC 234 requires that traffic be forwarded through the ordered SFs in one 235 direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a 236 symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1). A hybrid 237 SFC has attributes of both unidirectional and bidirectional SFCs; 238 that is to say some SFs require symmetric traffic, whereas other SFs 239 do not process reverse traffic. 241 SFCs may contain cycles; that is traffic may need to traverse more 242 than once one or more SFs within an SFC. 244 2.3. Service Function Paths 246 When an SFC is instantiated into the network it is necessary to 247 select the specific instances of SFs that will be used, and to create 248 the service topology for that SFC using SF's network locator. Thus, 249 instantiation of the SFC results in the creation of a Service 250 Function Path (SFP) and is used for forwarding packets through the 251 SFC. In other words, an SFP is the instantiation of the defined SFC. 253 This abstraction enables the binding of SFCs to specific instances, 254 or set of like instances of SFs based on a range of policy attributes 255 defined by the operator. For example, an SFC definition might 256 specify that one of the SF elements is a firewall. However, on the 257 network, there might exist a number of instances of the same firewall 258 (that is to say they enforce the same policy) and only when the SFP 259 is created is one of those firewall instances selected. The 260 selection can be based on a range of policy attributes, ranging from 261 simple to more elaborate criteria. 263 3. Architecture Principles 265 Service function chaining is predicated on several key architectural 266 principles: 268 1. Topological independence: no changes to the underlay network 269 forwarding topology - implicit, or explicit - are needed to 270 deploy and invoke SFs or SFCs. 272 2. Consistent policy identifiers: a common identifier is used for SF 273 policy selection. 275 3. Classification: traffic that satisfies classification rules is 276 forwarded according to a specific SFC. For example, 277 classification can be as simple as an explicit forwarding entry 278 that forwards all traffic from one address into the SFC. 279 Multiple classification points are possible within an SFC (i.e. 280 forming a service graph) thus enabling changes/update to the SFC 281 by SFs. 283 4. Shared Metadata: Metadata/context data can be shared amongst SFs 284 and classifiers, between SFs, and between external systems and 285 SFs (e.g. orchestration). 287 Generally speaking, the metadata can be thought of as providing, 288 and sharing the result of classification (that occurs with the 289 SFC domain, or external to it) along an SFP. For example, an 290 external repository might provide user/subscriber information to 291 a service chain classifier. This classifier in turn imposes that 292 information in the SFC encapsulation for delivery to the 293 requisite SFs. The SFs in turn utilize the user/subscriber 294 information for local policy decisions. 296 5. Heterogeneous control/policy points: allowing SFs to use 297 independent mechanisms (out of scope for this document) like IF- 298 MAP or Diameter to populate and resolve local policy and (if 299 needed) local classification criteria. 301 4. Core SFC Architecture Components 303 The following sub-sections provide details on each logical component 304 that form the basis of the SFC architecture. An overview of how each 305 of these components interact is provided in the following figure. 307 +----------------+ +----------------+ 308 | SFC-aware | | SFC-unaware | 309 |Service Function| |Service Function| 310 +-------+--------+ +-------+--------+ 311 | | 312 SFC Encapsulation No SFC Encapsulation 313 | | 314 | +---------+ 315 +------------------+ +-------------|SFC Proxy| 316 \ / +---------+ 317 +-------+--------+ 318 | SF Forwarder| 319 | (SFF) | 320 +-------+--------+ 321 | 322 SFC Encapsulation 323 | 324 +-------+--------+ 325 | SFC Network | 326 | Forwarder (NF) | 327 +----------------+ 328 | 329 Network Overlay Transport 330 | 331 _,....._ 332 ,-' `-. 333 / `. 334 | Network | 335 `. / 336 `.__ _,-' 337 `'''' 339 Figure 2: Service Function Chain Architecture Components 341 4.1. SFC Encapsulation 343 The SFC encapsulation enables service function path selection and the 344 sharing of metadata/context information. 346 The SFC encapsulation provides explicit information used to identify 347 the SFP. However, the SFC encapsulation is not a transport 348 encapsulation itself: it is not used to forward packets within the 349 network fabric. The SFC encapsulation therefore, relies on an outer 350 network transport. Transit nodes -- such as router and switches -- 351 simply forward SFC encapsulated packets based on the outer (non-SFC) 352 encapsulation. 354 One of the key architecture principles of SFC is that the SFC 355 encapsulation remain transport independent and as such any network 356 transport protocol may be used to carry the SFC encapsulation. 358 4.2. Service Function (SF) 360 The concept of a SF evolves; rather than being viewed as a bump in 361 the wire, a SF becomes a resource within a specified administrative 362 domain that is available for consumption as part of a composite 363 service. As such, SFs have one or more network locators through 364 which they are reachable, and a variable set of attributes that 365 describe the function offered. The combination of network locator 366 and attributes are used to construct an SFP. SFs send/receive SFC 367 encapsulated data from one or more SFFs. 369 While the SFC architecture defines a new encapsulation - the SFC 370 encapsulation - and several logical components for the construction 371 of SFCs, existing SF implementations may not have the capabilities to 372 act upon or fully integrate with the new SFC encapsulation. In order 373 to provide a mechanism for such SFs to participate in the 374 architecture a logical SFC proxy function is defined. The SFC proxy 375 acts a gateway between the SFC encapsulation and SFC unaware SFs. 376 The integration of SFC-unaware service function is discussed in more 377 detail in the SFC proxy section. 379 4.3. Service Function Forwarder (SFF) 381 The SFF is responsible for forwarding packets and/or frames received 382 from an NF to one or more SFs associated with a given SFF using 383 information conveyed in the SFC encapsulation. 385 The collection of SFFs creates a service plane using an overlay in 386 which SFC-aware SFs, as well as SFC-unaware SFs reside. Within this 387 service plane, the SFF component connects different SFs that form a 388 service function path. 390 SFFs maintain the requisite SFP forwarding information. SFP 391 forwarding information is associated with a service path identifier 392 that is used to uniquely identify an SFP. The service forwarding 393 state enables an SFF to identify which SF of a given SFC should be 394 applied as traffic flows through the associated SFP. Each SFF need 395 only maintain SFC forwarding information that is relevant locally. 396 The SFC forwarding state at all SFFs collectively represents the SFPs 397 associated with each SFC in the SFC domain. 399 +------+----------------------------------+ 400 | SFP | Ordered Service Functions | 401 |------+----------------------------------+ 402 | ID | order1 | order2 | order3 | ... | 403 +------+--------+--------+--------+-------+ 404 | SFP1 | SFID1 | SFID5 | SFID20 | | 405 +------+--------+--------+--------+-------+ 406 | SFP4 | SFID100| SFID3 | SFID4 | SFID9 | 407 +------+--------+--------+--------+-------+ 408 | ... | | | | | 409 +------+--------+--------+--------+-------+ 411 Figure 3: SFF Table 413 Figure 3 depicts a view of the service forwarding state for two SFPs 414 - SFP1 and SFP4. The SF columns of this table may come from 415 different SFFs. 417 The SFF component has the following primary responsibilities: 419 1. SFP forwarding : Traffic arrives at an SFF from one or more NFs. 420 The SFF determines the appropriate SF the traffic should be 421 forwarded to via information contained in the SFC encapsulation. 422 Post-SF, the traffic is returned to the SFF, and if needed 423 forwarded to another SF associated with that SFF. If there is 424 another hop in the SFP, the SFF, encapsulates the traffic in the 425 appropriate network transport and delivers it to the NF for 426 delivery to the next SFF along the path. 428 2. Terminating SFPs : An SFC is completely executed when traffic has 429 traversed all required SFs in a chain. When traffic arrives at 430 the SFF after the last SF has finished servicing it, SFF fails to 431 find the next SF or knows from the service forwarding state that 432 the SFC is complete. SFF removes the SFC encapsulation and 433 delivers the packet to an NF for forwarding. 435 3. Maintaining flow state: In some cases, the SFF may be stateful. 436 It creates flows and stores flow-centric information. When 437 traffic arrives after being steered through an SFC-unaware SF, 438 the SFF must perform re-classification of traffic to determine 439 the SFP. A state-full SFF simplifies such classification to a 440 flow lookup. 442 4.3.1. Transport Derived SFF 444 Service function forwarding, as described above, directly depends 445 upon the use of the service path information contained in the SFC 446 encapsulation. Existing implementations may not be able to act on 447 the SFC encapsulation. These platforms MAY opt to use a transport 448 mechanism which carries the service path information from the SFC 449 encapsulation, and information derived from the SFC encapsulation, to 450 build transport information. 452 This results in the same architectural behavior and meaning for 453 service function forwarding and service function paths. It is the 454 responsibility of the control components to ensure that the transport 455 path executed in such a case is fully aligned with the path 456 identified by the information in the service chaining encapsulation. 458 4.4. Network Forwarder (NF) 460 This component is responsible for performing the overlay 461 encapsulation/de-capsulation and forwarding of packets on the overlay 462 network. NF forwarding may consult the SFC encapsulation or the 463 inner payload of an incoming packet only in the necessary cases to 464 achieve optimal forwarding in the network. 466 4.5. Classification/Re-classification 468 Traffic that satisfies classification criteria is directed into an 469 SFP and forwarded to the requisite service function(s). 470 Classification is handled by a logical service classification 471 function, and initial classification occurs at the edge of the SFC 472 domain. The granularity of the initial classification is determined 473 by the capabilities of the classifier and the requirements of the SFC 474 policy. For instance, classification might be relatively coarse: all 475 packets from this port are directed into SFP A, or quite granular: 476 all packets matching this 5-tuple are subject to SFP B. 478 As a consequence of the classification decision, the appropriate SFC 479 encapsulation is imposed on the data prior to forwarding along the 480 SFP. 482 The SFC architecture supports reclassification (or non-initial 483 classification) as well. As packets traverse an SFP, 484 reclassification may occur - typically performed by a classification 485 function co-resident with a service function. Reclassification may 486 result in the selection of a new SFP, an update of the associated 487 metadata, or both. 489 For example, an initial classification results in the selection of 490 SFP A: DPI_1 --> SLB_8. However, when the DPI service function is 491 executed "attack" traffic is detected at the application layer. 492 DPI_1 reclassifies the traffic as "attack" and alters the service 493 path, to SFP B, to include a firewall for policy enforcement: 494 dropping the traffic: DPI_1 --> FW_4. In this simple example, the 495 DPI service function reclassified the traffic based on local 496 application layer classification capabilities (that were not 497 available during the initial classification step). 499 4.6. SFC Control Plane 501 The SFC control plane is responsible for constructing the SFPs; 502 translating the SFCs to the forwarding paths and propagating path 503 information to participating nodes - network and service - to achieve 504 requisite forwarding behavior to construct the service overlay. For 505 instance, a SFC construction may be static - using specific SF 506 instances, or dynamic - choosing service explicit SF instances at the 507 time of delivering traffic to the SF. In SFC, SFs are resources; the 508 control plane advertises their capabilities, availability and 509 location. The control plane is also responsible for the creation of 510 the context (see below). The control plane may be distributed (using 511 new or existing control plane protocols), or be centralized, or a 512 combination of the two. 514 The SFC control plane provides the following functionality: 516 1. An administrative domain wide view of all available service 517 function resources as well as the network locator through which 518 they are reachable. 520 2. Uses SFC policy to construct service function chains, and 521 associated service function paths. 523 3. Selection of specific SF instances for a requested SFC, either 524 statically (using specific SF instances) or dynamically (using 525 service explicit SF instances at the time of delivering traffic 526 to the SF). 528 4. Provides requisite SFC data plane information to the SFC 529 architecture components, most notably the SFF. 531 5. Allocation of metadata associated with a given SFP and 532 propagation of metadata syntax to relevant SF instances and/or 533 SFC encapsulation-proxies or their respective policy planes. 535 4.7. Shared Metadata 537 Sharing metadata allows the network to provide network-derived 538 information to the SFs, SF-to-SF information exchange and the sharing 539 of service-derived information to the network. This component is 540 optional. SFC infrastructure enables the exchange of this shared 541 data along the SFP. The shared metadata serves several possible 542 roles within the SFC architecture: 544 o Allows elements that typically operate as ships-in-the-night to 545 exchange information. 547 o Encodes information about the network and/or data for post- 548 service forwarding. 550 o Creates an identifier used for policy binding by SFs. 552 o Context information can be derived in several ways: 554 * External sources 556 * Network node classification 558 * Service function classification 560 4.8. Resource Control 562 The SFC system may be responsible for managing all resources 563 necessary for the SFC components to function. This includes network 564 constraints used to plan and choose the network path(s) between 565 service nodes, characteristics of the nodes themselves such as 566 memory, number of virtual interfaces, routes, etc..., and 567 configuration of the SFs running on the service nodes. 569 5. The Role of Policy 571 Much of the behavior of service chains is driven by operator and 572 customer policy. This architecture is structured to isolate the 573 policy interactions from the data plane and control logic. 575 Specifically, it is assumed that service chaining control plane 576 creates the service paths. The service chaining data plane is used 577 to deliver the classified packets along the service chains to the 578 intended Service Functions. 580 Policy, in contrast interacts with the system in other places. 581 Policies, and policy engines, may monitor service functions to decide 582 if additional (or fewer) instances of services are needed. When 583 applicable, those decisions may in turn result in interactions which 584 direct the control logic to change the service chain placement or the 585 packet classification rules. 587 Similarly, operator service policy, often managed by operational or 588 business support systems (OSS or BSS), will frequently determine what 589 service functions are available. Depending upon operator 590 preferences, these policies may also determine which sequences of 591 functions are valid and to be used or made available. 593 The offering of service chains to customers, and the selection of 594 which service chain a customer wishes to use are driven by a 595 combination of operator and customer policies using appropriate 596 portals in conjunction with the OSS and BSS tools. These selections 597 then drive the service chaining control logic which in turn 598 establishes the appropriate packet classification rules. 600 6. Load Balancing Considerations 602 Supporting function elasticity and high-availability shouldn't overly 603 complicate SFC or lead to unnecessary scalability problems. 605 In the simplest case, where there is only a single function in the 606 chain (the next hop is either the destination address of the flow or 607 the appropriate next hop to that destination), one could argue that 608 there may be no need for SFC. 610 In the case where the classifier is separate from the single function 611 or a function at the terminal address may need sub-prefix or per 612 subscriber metadata, we would have a single chain (the metadata 613 changes but the SFC chain does not), regardless of the number of 614 potential terminal addresses for the flow. This is the case of the 615 simple load balancer. 617 +----+----->web server 618 source+------>|sf1 +----->web server 619 |----+----->web server 620 +----+----->web server 622 Figure 4: Simple Load Balancing 624 By extrapolation, in the case where intermediary functions within a 625 chain had similar "elastic" behaviors, we do not need separate chains 626 to account for this behavior - as long as the traffic coalesces to a 627 common next-hop after the point of elasticity. 629 In the following figure, we have a chain of five service functions 630 between the traffic source and it's destination. 632 +-----+ +-----+ 633 +-->| sf2 +--+ +-->| sf4 +--+ 634 | |-----| | | |-----| | 635 +------+----+ +-----+ +-+>+-----+----+ +-----+ +-+>+-----+ 636 | sf1 | +-----+ | sf3 | +-----+ | sf5 | 637 source+----->|------+----+-->| sf2 |+---+>|-----|----+-->| sf4 |+---+>|-----|+-----> 638 | | |-----| | | |-----| | | 639 +------+----+ +-----+ +-+>+-----+----+ +-----+ +-+>+-----+ 640 | +-----+ | | +-----+ | 641 +-->| sf2 +--+ +-->| sf4 +--+ 642 |-----| |-----| 643 +-----+ +-----+ 645 Figure 5: Load Balancing 647 Either through an imbedded action in sf1 and sf3, or through external 648 control, the service functions sf2 and sf4 are elastically expanded 649 and contracted dynamically. This would be represented as one chain: 650 s1->s2->s3->s4->s5, but with multiple paths (not as a number of 651 chains equal to the factorial combination of potential end-to-end 652 paths). The load distribution decision will be localized (in 653 general, although there might be macro policy controlling that - 654 which is out of scope for the sake of a simple example). In this 655 case, the control entity will push to the sf1 nodes, a table of 656 sorts: sf2 with a series of next hops, and if needed some weighted or 657 other metrics (these could also be decided locally by some policy, 658 but sf1 would need to be aware of expand/contract triggers and 659 actions). sf1 would use local logic -- hash, state table, etc. -- to 660 distribute the chained packets to sf2. 662 The addition of high availability should likewise not require a 663 multitude of new chains. 665 +-----+-+ +-----+-+ 666 +-->| sf2 |-|+ +-->| sf4 |-|+ 667 +------>|-----| || +------>|-----| || 668 +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ 669 | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | 670 +-->|------||------>| sf2 |+---->|-----||------>| sf4 |+---->|-----|---+ 671 | | || +---->|-----|-+ | || +---->|-----|-+ | | | 672 | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | 673 source+--+ | | | +-----+ || | | | +-----+ || +-----> 674 | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | 675 | | sf1' | | +-->|-----| +--->| sf3'| | +-->|-----| +--->| sf5'| | 676 +-->|------|--+ | +-----+----->|-----|--+ | +-----+----->|-----|---+ 677 | | | | | | | | 678 +------+----+ +-----+----+ +-----+ 679 Figure 6: Load Balancing and HA 681 In the figure, sf1, sf3 and sf5 have a redundant counterpart for high 682 availability purposes (typical of stateful appliance/function 683 redundancy strategies, these entities may have private connections 684 for transferring state not shown). Note that the elasticity of sf2 685 and sf4 provide a separate high availability strategy for those 686 functions. In the case where sf1', sf3' and sf5' provide transparent 687 dynamic replacement (they assert the addressing characteristics of 688 their counterparts via an internal or external trigger), there is 689 still a single chain (again, not a factorial explosion). 691 7. SFC Proxy 693 In order for the SFC architecture to support SFC-unaware SF's, an 694 optional, logical SFC proxy function may be used. This proxy removes 695 the SFC encapsulation and then uses a local attachment circuit to 696 deliver packets to SFC unaware SFs. More specifically: 698 For traffic received from a NF or SFF, destined to an SF, the SFC 699 proxy: 701 o Removes the SFC encapsulation from SFC encapsulated packets and/or 702 frames. 704 o Identifies the required SF to be applied based on information 705 carried in the SFC encapsulation. 707 o Selects the appropriate outbound local attachment circuit through 708 which the next SF for this SFP is reachable. This information is 709 derived from the SFC encapsulation or from local configuration. 710 Examples of a local attachment circuit include, but are not 711 limited to, VLANs, IP-in-IP, GRE, VXLAN. 713 o Forwards the original payload via a local attachment circuit to 714 the appropriate SF. 716 When traffic is returned from the SF: 718 o Applies the required SFC encapsulation. The determination of the 719 encapsulation details may be inferred by the local attachment 720 circuit through which the packet and/or frame was received, or via 721 packet classification, or other local policy. In some cases, 722 packet-ordering or modification by the SF may necessitate 723 additional classification in order to re-apply the correct SFC 724 encapsulation. 726 o Imposes the appropriate SFC encapsulation based on the 727 identification of the SFC to be applied. 729 8. MTU Considerations 731 Modern systems are expected to be able to cope gracefully with MTU 732 issues that may arise from the application of additional headers to a 733 packet. Adopting the recommendations of other WG's who have recently 734 tackled this issue (e.g. [RFC6830]), there are several mechanisms 735 for dealing with packets that are too large to transit the path from 736 the point of service classification to the last function (SFn) in the 737 SFC. 739 In the "stateful" approach, the classifier keeps a per-path record of 740 the maximum size allowed, and sends an ICMP Too Big message to the 741 original source when a packet which is too large is seen (where "too 742 large" implies after the imposition of the appropriate SFC 743 encapsulation). 745 In the "stateless" approach, for IPv4, packets without the 'DF' bit 746 set, too-large packets are fragmented, and then the fragments are 747 forwarded; all other packets are discarded and an ICMP Too Big 748 message returned. 750 A recommendation of a specific mechanism and/or its implementation is 751 beyond the scope of this document. 753 9. SFC OAM 755 Operations, Administration, and Maintenance (OAM) tools are an 756 integral part of the architecture. These serve various purposes, 757 including fault detection and isolation, and performance management. 758 Service Function Paths create a services topology, and OAM performs 759 various functions within this service layer. Furthermore, SFC OAM 760 follows the same architectural principles of SFC in general. For 761 example, topological independence (including the ability to run OAM 762 over various overlay technologies) and classification-based policy. 764 We can subdivide the SFC OAM architecture in two parts: 766 o In-band: OAM packets run in-band fate-sharing with the service 767 topology. For this, they also follow the architectural principle 768 of consistent policy identifiers, and use the same path IDs as the 769 service chain data packets. 771 o Out-of-band: reporting beyond the actual dataplane. An additional 772 layer beyond the data-plane OAM, allows for additional alerting 773 and measurements. 775 Some of the detailed functions performed by SFC OAM include fault 776 detection, continuity checks, connectivity verification, service path 777 tracing, diagnostic and fault isolation, alarm reporting, performance 778 measurement, locking and testing of service functions, and also allow 779 for vendor-specific as well as experimental functions. SFC should 780 leverage, and if needed extend relevant existing OAM mechanisms. 782 10. Summary 784 Service function chains enable composite services that are 785 constructed from one or more service functions. This document 786 provides a standard architecture, including architectural concepts, 787 principles, and components, for the creation of Service function 788 chains. 790 11. Security Considerations 792 This document does not define a new protocol and therefore creates no 793 new security issues. 795 12. Contributors 797 The following people are active contributors to this document and 798 have provided review, content and concepts (listed alphabetically by 799 surname): 801 Puneet Agarwal 802 Broadcom 803 Email: pagarwal@broadcom.com 805 Andre Beliveau 806 Ericsson 807 Email: andre.beliveau@ericsson.com 809 Kevin Glavin 810 Riverbed 811 Email: Kevin.Glavin@riverbed.com 813 Ken Gray 814 Cisco Systems, Inc. 815 Email: kegray@cisco.com 817 Jim Guichard 818 Cisco Systems, Inc. 819 Email: jguichar@cisco.com 821 Surendra Kumar 822 Cisco Systems, Inc. 823 Email: smkumar@cisco.com 825 Darrel Lewis 826 Cisco Systems, Inc. 827 Email: darlewis@cisco.com 829 Nic Leymann 830 Deutsche Telekom 831 Email: n.leymann@telekom.de 833 Rajeev Manur 834 Broadcom 835 Email: rmanur@broadcom.com 837 Thomas Nadeau 838 Brocade 839 Email: tnadeau@lucidvision.com 841 Carlos Pignataro 842 Cisco Systems, Inc. 844 Email: cpignata@cisco.com 846 Michael Smith 847 Cisco Systems, Inc. 848 Email: michsmit@cisco.com 850 Navindra Yadav 851 Cisco Systems, Inc. 852 Email: nyadav@cisco.com 854 13. Acknowledgments 856 The authors would like to thank David Ward, Abhijit Patra, Nagaraj 857 Bagepalli, Darrel Lewis, Ron Parker, Lucy Yong and Christian 858 Jacquenet for their review and comments. 860 14. IANA Considerations 862 This document creates no new requirements on IANA namespaces 863 [RFC5226]. 865 15. References 867 15.1. Normative References 869 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 870 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 871 May 2008. 873 15.2. Informative References 875 [NSCprob] "Network Service Chaining Problem Statement", . 879 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 880 September 1981. 882 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 883 (IPv6) Specification", RFC 2460, December 1998. 885 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 886 Address Translator (Traditional NAT)", RFC 3022, 887 January 2001. 889 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 890 NAT64: Network Address and Protocol Translation from IPv6 891 Clients to IPv4 Servers", RFC 6146, April 2011. 893 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 894 Locator/ID Separation Protocol (LISP)", RFC 6830, 895 January 2013. 897 Appendix A. Existing Service Deployments 899 Existing service insertion and deployment techniques fail to address 900 new challenging requirements raised by modern network architectures 901 and evolving technologies such as multi-tenancy, virtualization, 902 elasticity, and orchestration. Networks, servers, storage 903 technologies, and applications, have all undergone significant change 904 in recent years: virtualization, network overlays, and orchestration 905 have increasingly become adopted techniques. All of these have 906 profound effects on network and services design. 908 As network service functions evolve, operators are faced with an 909 array of form factors - virtual and physical - as well as with a 910 range of insertion methods that often vary by vendor and type of 911 service. 913 Such existing services are deployed using a range of techniques, most 914 often associated with topology or forwarding modifications. For 915 example, firewalls often rely on layer-2 network changes for 916 deployment: a VLAN is created for the "inside" interface, and another 917 for the "outside" interface. In other words, a new L2 segment was 918 created simply to add a service function. In the case of server load 919 balancers, policy routing is often used to ensure traffic from 920 server's returns to the load balancer. As with the firewall example, 921 the policy routing serves only to ensure that the network traffic 922 ultimately flows to the service function(s). 924 The network-centric information (e.g. VLAN) is not limited to 925 insertion; this information is often used as a policy identifier on 926 the service itself. So, on a firewall, the layer-2 segment 927 identifies the local policy to be selected. If more granular policy 928 discrimination is required, more network identifiers must be created 929 either per-hop, or communicated consistently to all services. 931 Appendix B. Issues with Existing Deployments 933 Due to the tight coupling of network and service function resources 934 in existing networks, adding or removing service functions is a 935 complex task that is fraught with risk and is tied to 936 operationalizing topological changes leading to massively static 937 configuration procedures for network service delivery or update 938 purposes. The inflexibility of such deployments limits (and in many 939 cases precludes) dynamic service scaling (both horizontal and 940 vertical) and requires hop-by-hop configuration to ensure that the 941 correct service functions, and sequence of service functions are 942 traversed. 944 A non-exhaustive list of existing service deployment and insertion 945 techniques as well as the issues associated with each may be found in 946 [NSCprob]. 948 Appendix C. SFC Encapsulation Requirements 950 TBD 952 Authors' Addresses 954 Paul Quinn (editor) 955 Cisco Systems, Inc. 957 Email: paulq@cisco.com 959 Joel Halpern (editor) 960 Ericsson 962 Email: jmh@joelhalpern.com