idnits 2.17.1 draft-ietf-sfc-architecture-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 11, 2015) is 3267 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Halpern, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational C. Pignataro, Ed. 5 Expires: November 12, 2015 Cisco 6 May 11, 2015 8 Service Function Chaining (SFC) Architecture 9 draft-ietf-sfc-architecture-08 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, with a focus on those to be standardized in the 18 IETF. This document does not propose solutions, protocols, or 19 extensions to existing protocols. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 12, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 59 2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 6 60 2.1. Service Function Chains . . . . . . . . . . . . . . . . . 7 61 2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 8 62 2.3. Service Function Paths . . . . . . . . . . . . . . . . . 9 63 3. Architecture Principles . . . . . . . . . . . . . . . . . . . 10 64 4. Core SFC Architecture Components . . . . . . . . . . . . . . 11 65 4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 12 66 4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 13 67 4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 13 68 4.3.1. Transport Derived SFF . . . . . . . . . . . . . . . . 15 69 4.4. SFC-Enabled Domain . . . . . . . . . . . . . . . . . . . 15 70 4.5. Network Overlay and Network Components . . . . . . . . . 15 71 4.6. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 16 72 4.7. Classification . . . . . . . . . . . . . . . . . . . . . 17 73 4.8. Re-Classification and Branching . . . . . . . . . . . . . 17 74 4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 18 75 5. Additional Architectural Concepts . . . . . . . . . . . . . . 18 76 5.1. The Role of Policy . . . . . . . . . . . . . . . . . . . 18 77 5.2. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 19 78 5.3. Resource Control . . . . . . . . . . . . . . . . . . . . 20 79 5.4. Infinite Loop Detection and Avoidance . . . . . . . . . . 20 80 5.5. Load Balancing Considerations . . . . . . . . . . . . . . 21 81 5.6. MTU and Fragmentation Considerations . . . . . . . . . . 22 82 5.7. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 5.8. Resilience and Redundancy . . . . . . . . . . . . . . . . 24 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 85 7. Contributors and Acknowledgments . . . . . . . . . . . . . . 25 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 87 9. Informative References . . . . . . . . . . . . . . . . . . . 27 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 90 1. Introduction 92 The delivery of end-to-end services often requires various service 93 functions. These include traditional network service functions such 94 as firewalls and traditional IP Network Address Translators (NATs), 95 as well as application-specific functions. The definition and 96 instantiation of an ordered set of service functions and subsequent 97 'steering' of traffic through them is termed Service Function 98 Chaining (SFC). 100 This document describes an architecture used for the creation and 101 ongoing maintenance of Service Function Chains (SFC) in a network. 102 It includes architectural concepts, principles, and components, with 103 a focus on those to be standardized in the IETF. Service function 104 chains enable composite services that are constructed from one or 105 more service functions. 107 An overview of the issues associated with the deployment of end-to- 108 end service function chains, abstract sets of service functions and 109 their ordering constraints that create a composite service and the 110 subsequent "steering" of traffic flows through said service 111 functions, is described in [RFC7498]. 113 The current service function deployment models are relatively static, 114 coupled to network topology and physical resources, greatly reducing 115 or eliminating the ability of an operator to introduce new services 116 or dynamically create service function chains. This architecture 117 presents a model addressing the problematic aspects of existing 118 service deployments, including topological independence and 119 configuration complexity. 121 1.1. Scope 123 This document defines the architecture for Service Function Chaining 124 (SFC) with minimum requirements on the physical topology of the 125 network, as standardized in the IETF. In this architecture packets 126 are classified on ingress for handling by the required set of Service 127 Functions (SFs) in the SFC-enabled domain and are then forwarded 128 through that set of functions for processing by each function in 129 turn. Packets may be re-classified as a result of this processing. 131 The architecture described in this document is independent of the 132 planned usage of the network and deployment context and thus, for 133 example, is applicable to both fixed and mobile networks as well as 134 being useful in many Data Center applications. 136 The architecture described herein is assumed to be applicable to a 137 single network administrative domain. While it is possible for the 138 architectural principles and components to be applied to inter-domain 139 SFCs, these are left for future study. 141 1.2. Assumptions 143 The following assumptions are made: 145 o There is no standard definition or characterization applicable to 146 all SFs, and thus the architecture considers each SF as an opaque 147 processing element. 149 o There is no global or standard list of SFs enabled in a given 150 administrative domain. The set of SFs enabled in a given domain 151 is a function of the currently active services which may vary with 152 time and according to the networking environment. 154 o There is no global or standard SF chaining logic. The ordered set 155 of SFs that needs to be applied to deliver a given service is 156 specific to each administrative entity. 158 o The chaining of SFs and the criteria to invoke them are specific 159 to each administrative entity that operates an SF-enabled domain. 161 o Several SF chaining policies can be simultaneously applied within 162 an administrative domain to meet various business requirements. 164 o The underlay is assumed to provide the necessary connectivity to 165 interconnect the SFFs, but the architecture places no constraints 166 on how that connectivity is realized other than it have the 167 required bandwidth, latency, and jitter to support the SFC. 169 o No assumption is made on how FIBs and RIBs of involved nodes are 170 populated. 172 o How to bind traffic to a given SF chain is policy-based. 174 1.3. Definition of Terms 176 Network Service: An offering provided by an operator that is 177 delivered using one or more service functions. This may also be 178 referred to as a composite service. The term "service" is used 179 to denote a "network service" in the context of this document. 181 Note: Beyond this document, the term "service" is overloaded 182 with varying definitions. For example, to some a service is an 183 offering composed of several elements within the operator's 184 network, whereas for others a service, or more specifically a 185 network service, is a discrete element such as a "firewall". 186 Traditionally, such services (in the latter sense) host a set of 187 service functions and have a network locator where the service 188 is hosted. 190 Classification: Locally instantiated matching of traffic flows 191 against policy for subsequent application of the required set of 192 network service functions. The policy may be customer/network/ 193 service specific. 195 Classifier: An element that performs Classification. 197 Service Function Chain (SFC): A service function chain defines an 198 ordered set of abstract service functions (SFs) and ordering 199 constraints that must be applied to packets and/or frames and/or 200 flows selected as a result of classification. An example of an 201 abstract service function is "a firewall". The implied order 202 may not be a linear progression as the architecture allows for 203 SFCs that copy to more than one branch, and also allows for 204 cases where there is flexibility in the order in which service 205 functions need to be applied. The term service chain is often 206 used as shorthand for service function chain. 208 Service Function (SF): A function that is responsible for specific 209 treatment of received packets. A Service Function can act at 210 various layers of a protocol stack (e.g., at the network layer 211 or other OSI layers). As a logical component, a Service 212 Function can be realized as a virtual element or be embedded in 213 a physical network element. One or more Service Functions can 214 be embedded in the same network element. Multiple occurrences 215 of the Service Function can exist in the same administrative 216 domain. 218 One or more Service Functions can be involved in the delivery of 219 added-value services. A non-exhaustive list of abstract Service 220 Functions includes: firewalls, WAN and application acceleration, 221 Deep Packet Inspection (DPI), LI (Lawful Intercept), server load 222 balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], 223 HOST_ID injection, HTTP Header Enrichment functions, TCP 224 optimizer. 226 An SF may be SFC encapsulation aware, that is it receives and 227 acts on information in the SFC encapsulation, or unaware, in 228 which case data forwarded to the SF does not contain the SFC 229 encapsulation. 231 Service Function Forwarder (SFF): A service function forwarder is 232 responsible for forwarding traffic to one or more connected 233 service functions according to information carried in the SFC 234 encapsulation, as well as handling traffic coming back from the 235 SF. Additionally, a service function forwarder is responsible 236 for delivering traffic to a classifier when needed and 237 supported, transporting traffic to another SFF (in the same or 238 different type of overlay), and terminating the SFP. 240 Metadata: provides the ability to exchange context information 241 between classifiers and SFs and among SFs. 243 Service Function Path (SFP): The SFP provides a level of indirection 244 between the fully abstract notion of service chain as a sequence 245 of abstract service functions to be delivered, and the fully 246 specified notion of exactly which SFF/SFs the packet will visit 247 when it actually traverses the network. By allowing the control 248 components to specify this level of indirection, the operator 249 may control the degree of SFF/SF selection authority that is 250 delegated to the network. 252 SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP 253 identification, and is used by the SFC-aware functions, such as 254 the SFF and SFC-aware SFs. The SFC Encapsulation is not used 255 for network packet forwarding. In addition to SFP 256 identification, the SFC encapsulation carries metadata including 257 data plane context information. 259 Rendered Service Path (RSP): The Service Function Path is a 260 constrained specification of where packets assigned to a certain 261 service function path must go. While it may be so constrained 262 as to identify the exact locations, it can also be less 263 specific. Packets themselves are of course transmitted from and 264 to specific places in the network, visiting a specific sequence 265 of SFFs and SFs. This sequence of actual visits by a packet to 266 specific SFFs and SFs in the network is known as the Rendered 267 Service Path (RSP). This definition is included here for use by 268 later documents, such as when solutions may need to discuss the 269 actual sequence of locations the packets visit. 271 SFC-enabled Domain: A network or region of a network that implements 272 SFC. An SFC-enabled Domain is limited to a single network 273 administrative domain. 275 SFC Proxy: Removes and inserts SFC encapsulation on behalf of an 276 SFC-unaware service function. SFC proxies are logical elements. 278 2. Architectural Concepts 280 The following sections describe the foundational concepts of service 281 function chaining and the SFC architecture. 283 Service Function Chaining enables the creation of composite (network) 284 services that consist of an ordered set of Service Functions (SF) 285 that must be applied to packets and/or frames and/or flows selected 286 as a result of classification. Each SF is referenced using an 287 identifier that is unique within an SF-enabled domain. 289 Service Function Chaining is a concept that provides for more than 290 just the application of an ordered set of SFs to selected traffic; 291 rather, it describes a method for deploying SFs in a way that enables 292 dynamic ordering and topological independence of those SFs as well as 293 the exchange of metadata between participating entities. 295 2.1. Service Function Chains 297 In most networks, services are constructed as abstract sequences of 298 SFs that represent SFCs. At a high level, an SFC is an abstracted 299 view of a service that specifies the set of required SFs as well as 300 the order in which they must be executed. Graphs, as illustrated in 301 Figure 1, define an SFC, where each graph node represents the 302 required existence of at least one abstract SF. Such graph nodes 303 (SFs) can be part of zero, one, or many SFCs. A given graph node 304 (SF) can appear one time or multiple times in a given SFC. 306 SFCs can start from the origination point of the service function 307 graph (i.e., node 1 in Figure 1), or from any subsequent node in the 308 graph. As shown, SFs may therefore become branching nodes in the 309 graph, with those SFs selecting edges that move traffic to one or 310 more branches. The top and middle graphs depict such a case, where a 311 second classification event occurs after node 2, and a new graph is 312 selected (i.e., node 3 instead of node 6). The bottom graph 313 highlights the the concept of a cycle, in which a given SF (e.g., 314 node 7 in the depiction) can be visited more than once within a given 315 service chain. An SFC can have more than one terminus. 317 ,-+-. ,---. ,---. ,---. 318 / \ / \ / \ / \ 319 ( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) 320 \ / \ / \ / \ / 321 `---' `---' `---' `---' 323 ,-+-. ,---. ,---. ,---. ,---. 324 / \ / \ / \ / \ / \ 325 ( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 ) 326 \ / \ / \ / \ / \ / 327 `---' `---' `---' `---' `---' 329 ,-+-. ,---. ,---. ,---. ,---. 330 / \ / \ / \ / \ / \ 331 ( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 ) 332 \ / \ / \ / \ / \ / 333 `---' `---' `---' `---' `---' 335 Figure 1: Service Function Chain Graphs 337 The concepts of classification, re-classification, and branching are 338 covered in subsequent sections of this architecture (see Section 4.7 339 and Section 4.8). 341 2.2. Service Function Chain Symmetry 343 SFCs may be unidirectional or bidirectional. A unidirectional SFC 344 requires that traffic be forwarded through the ordered SFs in one 345 direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a 346 symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), and in 347 which the SF instances are the same in opposite directions. A hybrid 348 SFC has attributes of both unidirectional and bidirectional SFCs; 349 that is to say some SFs require symmetric traffic, whereas other SFs 350 do not process reverse traffic or are independent of the 351 corresponding forward traffic. 353 SFCs may contain cycles; that is traffic may need to traverse one or 354 more SFs within an SFC more than once. Solutions will need to ensure 355 suitable disambiguation for such situations. 357 The architectural allowance that is made for SFPs that delegate 358 choice to the network for which SFs and/or SFFs a packet will visit 359 creates potential issues here. A solution that allows such 360 delegation needs to also describe how the solution ensures that those 361 service chains that require service function chain symmetry can 362 achieve that. 364 Further, there are state tradeoffs in symmetry. Symmetry may be 365 realized in several ways depending on the SFF and classifier 366 functionality. In some cases, "mirrored" classification (i.e., from 367 Source to Destination and from Destination to Source) policy may be 368 deployed, whereas in others shared state between classifiers may be 369 used to ensure that symmetric flows are correctly identified, then 370 steered along the required SFP. At a high level, there are various 371 common cases. In a non-exhaustive way, there can be for example: 373 o A single classifier (or a small number of classifiers), in which 374 case both incoming and outgoing flows could be recognized at the 375 same classifier, so the synchronization would be feasible by 376 internal mechanisms internal to the classifier. 378 o Stateful classifiers where several classifiers may be clustered 379 and share state. 381 o Fully distributed classifiers, where synchronization needs to be 382 provided through unspecified means. 384 o A classifier that learns state from the egress packets/flows that 385 is then used to provide state for the return packets/flow. 387 o Symmetry may also be provided by stateful forwarding logic in the 388 SFF in some implementations. 390 This is a non-comprehensive list of common cases. 392 2.3. Service Function Paths 394 A service function path (SFP) is a mechanism used by service chaining 395 to express the result of applying more granular policy and 396 operational constraints to the abstract requirements of a service 397 chain (SFC). This architecture does not mandate the degree of 398 specificity of the SFP. Architecturally, within the same SFC-enabled 399 domain, some SFPs may be fully specified, selecting exactly which SFF 400 and which SF are to be visited by packets using that SFP, while other 401 SFPs may be quite vague, deferring to the SFF the decisions about the 402 exact sequence of steps to be used to realize the SFC. The 403 specificity may be anywhere in between these extremes. 405 As an example of such an intermediate specificity, there may be two 406 SFPs associated with a given SFC, where one SFP specifies that any 407 order of SFF and SF may be used as long as it is within data center 408 1, and where the second SFP allows the same latitude, but only within 409 data center 2. 411 Thus, the policies and logic of SFP selection or creation (depending 412 upon the solution) produce what may be thought of as a constrained 413 version of the original SFC. Since multiple policies may apply to 414 different traffic that uses the same SFC, it also follows that there 415 may be multiple SFPs may be associated with a single SFC. 417 The architecture allows for the same SF to be reachable through 418 multiple SFFs. In these cases, some SFPs may constrain which SFF is 419 used to reach which SF, while some SFPs may leave that decision to 420 the SFF itself. 422 Further, the architecture allows for two or more SFs to be attached 423 to the same SFF, and possibly connected via internal means allowing 424 more effective communication. In these cases, some solutions or 425 deployments may choose to use some form of internal inter-process or 426 inter-VM messaging (communication behind the virtual switching 427 element) that is optimized for such an environment. This must be 428 coordinated with the SFF so that the service function forwarding can 429 properly perform its job. Implementation details of such mechanisms 430 are considered out of scope for this document, and can include a 431 spectrum of methods: for example situations including all next-hops 432 explicitly, others where a list of possible next-hops is provided and 433 the selection is local, or cases with just an identifier, where all 434 resolution is local. 436 This architecture also allows the same SF to be part of multiple 437 SFPs. 439 3. Architecture Principles 441 Service function chaining is predicated on several key architectural 442 principles: 444 1. Topological independence: no changes to the underlay network 445 forwarding topology - implicit, or explicit - are needed to 446 deploy and invoke SFs or SFCs. 448 2. Plane separation: dynamic realization of SFPs is separated from 449 packet handling operations (e.g., packet forwarding). 451 3. Classification: traffic that satisfies classification rules is 452 forwarded according to a specific SFP. For example, 453 classification can be as simple as an explicit forwarding entry 454 that forwards all traffic from one address into the SFP. 455 Multiple classification points are possible within an SFC (i.e., 456 forming a service graph) thus enabling changes/updates to the SFC 457 by SFs. 459 Classification can occur at varying degrees of granularity; for 460 example, classification can use a 5-tuple, a transport port or 461 set of ports, part of the packet payload, it can be the result of 462 high-level inspections, or it can come from external systems. 464 4. Shared Metadata: Metadata/context data can be shared amongst SFs 465 and classifiers, between SFs, and between external systems and 466 SFs (e.g., orchestration). 468 One use of metadata is to provide and share the result of 469 classification (that occurs within the SFC-enabled domain, or 470 external to it) along an SFP. For example, an external 471 repository might provide user/subscriber information to a service 472 chain classifier. This classifier could in turn impose that 473 information in the SFC encapsulation for delivery to the 474 requisite SFs. The SFs could in turn utilize the user/subscriber 475 information for local policy decisions. Metadata can also share 476 SF output along the SFP. 478 5. Service definition independence: The SFC architecture does not 479 depend on the details of SFs themselves. 481 6. Service function chain independence: The creation, modification, 482 or deletion of an SFC has no impact on other SFCs. The same is 483 true for SFPs. 485 7. Heterogeneous control/policy points: The architecture allows SFs 486 to use independent mechanisms (out of scope for this document) to 487 populate and resolve local policy and (if needed) local 488 classification criteria. 490 4. Core SFC Architecture Components 492 At a very high level, the logical architecture of an SFC-enabled 493 Domain comprises: 495 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 . +--------------+ +------------------~~~ 497 . | Service | SFC | Service +---+ +---+ 498 . |Classification| Encapsulation | Function |sf1|...|sfn| 499 +---->| Function |+---------------->| Path +---+ +---+ 500 . +--------------+ +------------------~~~ 501 . SFC-enabled Domain 502 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504 Figure 2: Service Function Chain Architecture 506 The following sub-sections provide details on each logical component 507 that form the basis of the SFC architecture. A detailed overview of 508 how each of these architectural components interact is provided in 509 Figure 3: 511 +----------------+ +----------------+ 512 | SFC-aware | | SFC-unaware | 513 |Service Function| |Service Function| 514 +-------+--------+ +-------+--------+ 515 | | 516 SFC Encapsulation No SFC Encapsulation 517 | SFC | 518 +---------+ +----------------+ Encapsulation +---------+ 519 |SFC-Aware|-----------------+ \ +------------|SFC Proxy| 520 | SF | ... ----------+ \ \ / +---------+ 521 +---------+ \ \ \ / 522 +-------+--------+ 523 | SF Forwarder | 524 | (SFF) | 525 +-------+--------+ 526 | 527 SFC Encapsulation 528 | 529 ... SFC-enabled Domain ... 530 | 531 Network Overlay Transport 532 | 533 _,....._ 534 ,-' `-. 535 / `. 536 | Network | 537 `. / 538 `.__ __,-' 539 `'''' 541 Figure 3: Service Function Chain Architecture Components 543 4.1. SFC Encapsulation 545 The SFC encapsulation enables service function path selection. It 546 also enables the sharing of metadata/context information when such 547 metadata exchange is required. 549 The SFC encapsulation carries explicit information used to identify 550 the SFP. However, the SFC encapsulation is not a transport 551 encapsulation itself: it is not used to forward packets within the 552 network fabric. If packets need to flow between separate physical 553 platforms, the SFC encapsulation therefore relies on an outer network 554 transport. Transit forwarders -- such as router and switches -- 555 forward SFC encapsulated packets based on the outer (non-SFC) 556 encapsulation. 558 One of the key architecture principles of SFC is that the SFC 559 encapsulation remain transport independent. As such any network 560 transport protocol may be used to carry the SFC encapsulated traffic. 562 4.2. Service Function (SF) 564 The concept of an SF evolves; rather than being viewed as a bump in 565 the wire, an SF becomes a resource within a specified administrative 566 domain that is available for consumption as part of a composite 567 service. SFs send/receive data to/from one or more SFFs. SFC-aware 568 SFs receive this traffic with the SFC encapsulation. 570 While the SFC architecture defines the concept and specifies some 571 characteristics of a new encapsulation - the SFC encapsulation - and 572 several logical components for the construction of SFCs, existing SF 573 implementations may not have the capabilities to act upon or fully 574 integrate with the new SFC encapsulation. In order to provide a 575 mechanism for such SFs to participate in the architecture, an SFC 576 proxy function is defined (see Section 4.6). The SFC proxy acts as a 577 gateway between the SFC encapsulation and SFC-unaware SFs. The 578 integration of SFC-unaware service functions is discussed in more 579 detail in the SFC proxy section. 581 This architecture allows an SF to be part of multiple SFPs and SFCs. 583 4.3. Service Function Forwarder (SFF) 585 The SFF is responsible for forwarding packets and/or frames received 586 from the network to one or more SFs associated with a given SFF using 587 information conveyed in the SFC encapsulation. Traffic from SFs 588 eventually returns to the same SFF, which is responsible for 589 injecting traffic back onto the network. Some SFs, such as 590 firewalls, could also consume a packet. 592 The collection of SFFs and associated SFs creates a service plane 593 overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside. 594 Within this service plane, the SFF component connects different SFs 595 that form a service function path. 597 SFFs maintain the requisite SFP forwarding information. SFP 598 forwarding information is associated with a service path identifier 599 that is used to uniquely identify an SFP. The service forwarding 600 state enables an SFF to identify which SFs of a given SFP should be 601 applied, and in what order, as traffic flows through the associated 602 SFP. While there may appear to the SFF to be only one available way 603 to deliver the given SF, there may also be multiple choices allowed 604 by the constraints of the SFP. 606 If there are multiple choices, the SFF needs to preserve the property 607 that all packets of a given flow are handled the same way, since the 608 SF may well be stateful. Additionally, the SFF may preserve the 609 handling of packets based on other properties on top of a flow, such 610 as a subscriber, session, or application instance identification. 612 The SFF also has the information to allow it to forward packets to 613 the next SFF after applying local service functions. Again, while 614 there may be only a single choice available, the architecture allows 615 for multiple choices for the next SFF. As with SFs, the solution 616 needs to operate such that the behavior with regard to specific flows 617 (see the Rendered Service Path) is stable. The selection of 618 available SFs and next SFFs may be interwoven when an SFF supports 619 multiple distinct service functions and the same service function is 620 available at multiple SFFs. Solutions need to be clear about what is 621 allowed in these cases. 623 Even when the SFF supports and utilizes multiple choices, the 624 decision as to whether to use flow-specific mechanisms or coarser 625 grained means to ensure that the behavior of specific flows is stable 626 is a matter for specific solutions and specific implementations. 628 The SFF component has the following primary responsibilities: 630 1. SFP forwarding : Traffic arrives at an SFF from the network. The 631 SFF determines the appropriate SF the traffic should be forwarded 632 to via information contained in the SFC encapsulation. Post-SF, 633 the traffic is returned to the SFF, and, if needed, is forwarded 634 to another SF associated with that SFF. If there is another non- 635 local (i.e., different SFF) hop in the SFP, the SFF further 636 encapsulates the traffic in the appropriate network transport 637 protocol and delivers it to the network for delivery to the next 638 SFF along the path. Related to this forwarding responsibility, 639 an SFF should be able to interact with metadata. 641 2. Terminating SFPs : An SFC is completely executed when traffic has 642 traversed all required SFs in a chain. When traffic arrives at 643 the SFF after the last SF has finished processing it, the final 644 SFF knows from the service forwarding state that the SFC is 645 complete. The SFF removes the SFC encapsulation and delivers the 646 packet back to the network for forwarding. 648 3. Maintaining flow state: In some cases, the SFF may be stateful. 649 It creates flows and stores flow-centric information. This state 650 information may be used for a range of SFP-related tasks such as 651 ensuring consistent treatment of all packets in a given flow, 652 ensuring symmetry or for state-aware SFC Proxy functionality (see 653 Section 4.8). 655 4.3.1. Transport Derived SFF 657 Service function forwarding, as described above, directly depends 658 upon the use of the service path information contained in the SFC 659 encapsulation. However, existing implementations may not be able to 660 act on the SFC encapsulation. These platforms may opt to use 661 existing transport information if it can be arranged to provide 662 explicit service path information. 664 This results in the same architectural behavior and meaning for 665 service function forwarding and service function paths. It is the 666 responsibility of the control components to ensure that the transport 667 path executed in such a case is fully aligned with the path 668 identified by the information in the service chaining encapsulation. 670 4.4. SFC-Enabled Domain 672 Specific features may need to be enforced at the boundaries of an 673 SFC-enabled domain, for example to avoid leaking SFC information. 674 Using the term node to refer generically to an entity that is 675 performing a set of functions, in this context, an SFC Boundary Node 676 denotes a node that connects one SFC-enabled domain to a node either 677 located in another SFC-enabled domain or in a domain that is SFC- 678 unaware. 680 An SFC Boundary node can act as egress or ingress. An SFC Egress 681 Node denotes a SFC Boundary Node that handles traffic leaving the 682 SFC-enabled domain the Egress Node belongs to. Such a node is 683 required to remove any information specific to the SFC Domain, 684 typically the SFC Encapsulation. Further, from a privacy 685 perspective, an SFC Egress Node is required to ensure that any 686 sensitive information added as part of SFC gets removed. In this 687 context, information may be sensitive due to network concerns or end- 688 customer concerns. An SFC Ingress Node denotes an SFC Boundary Node 689 that handles traffic entering the SFC-enabled domain. In most 690 solutions and deployments this will need to include a classifier, and 691 will be responsible for adding the SFC encapsulation to the packet. 693 4.5. Network Overlay and Network Components 695 Underneath the SFF there are components responsible for performing 696 the transport (overlay) forwarding. They do not consult the SFC 697 encapsulation or inner payload for performing this forwarding. They 698 only consult the outer-transport encapsulation for the transport 699 (overlay) forwarding. 701 4.6. SFC Proxy 703 In order for the SFC architecture to support SFC-unaware SFs (e.g., 704 legacy service functions) a logical SFC proxy function may be used. 705 This function sits between an SFF and one or more SFs to which the 706 SFF is directing traffic (see Figure 3). 708 The proxy accepts packets from the SFF on behalf of the SF. It 709 removes the SFC encapsulation, and then uses a local attachment 710 circuit to deliver packets to SFC unaware SFs. It also receives 711 packets back from the SF, reapplies the SFC encapsulation, and 712 returns them to the SFF for processing along the service function 713 path. 715 Thus, from the point of view of the SFF, the SFC proxy appears to be 716 part of an SFC aware SF. 718 Communication details between the SFF and the SFC Proxy are the same 719 as those between the SFF and an SFC aware SF. The details of that 720 are not part of this architecture. The details of the communication 721 methods over the local attachment circuit between the SFC proxy and 722 the SFC-unaware SF are dependent upon the specific behaviors and 723 capabilities of that SFC-unaware SF, and thus are also out of scope 724 for this architecture. 726 Specifically, for traffic received from the SFF intended for the SF 727 the proxy is representing, the SFC proxy: 729 o Removes the SFC encapsulation from SFC encapsulated packets. 731 o Identifies the required SF to be applied based on available 732 information including that carried in the SFC encapsulation. 734 o Selects the appropriate outbound local attachment circuit through 735 which the next SF for this SFP is reachable. This is derived from 736 the identification of the SF carried in the SFC encapsulation, and 737 may include local techniques. Examples of a local attachment 738 circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3, 739 GRE, VXLAN. 741 o Forwards the original payload via the selected local attachment 742 circuit to the appropriate SF. 744 When traffic is returned from the SF: 746 o Applies the required SFC encapsulation. The determination of the 747 encapsulation details may be inferred by the local attachment 748 circuit through which the packet and/or frame was received, or via 749 packet classification, or other local policy. In some cases, 750 packet ordering or modification by the SF may necessitate 751 additional classification in order to re-apply the correct SFC 752 encapsulation. 754 o Delivers the packet with the SFC Encapsulation to the SFF, as 755 would happen with packets returned from an SFC-aware SF. 757 4.7. Classification 759 Traffic from the network that satisfies classification criteria is 760 directed into an SFP and forwarded to the requisite service 761 function(s). Classification is handled by a service classification 762 function; initial classification occurs at the ingress to the SFC 763 domain. The granularity of the initial classification is determined 764 by the capabilities of the classifier and the requirements of the SFC 765 policy. For instance, classification might be relatively coarse: all 766 packets from this port are subject to SFC policy X and directed into 767 SFP A, or quite granular: all packets matching this 5-tuple are 768 subject to SFC policy Y and directed into SFP B. 770 As a consequence of the classification decision, the appropriate SFC 771 encapsulation is imposed on the data, and a suitable SFP is selected 772 or created. Classification results in attaching the traffic to a 773 specific SFP. 775 4.8. Re-Classification and Branching 777 The SFC architecture supports re-classification (or non-initial 778 classification) as well. As packets traverse an SFP, re- 779 classification may occur - typically performed by a classification 780 function co-resident with a service function. Reclassification may 781 result in the selection of a new SFP, an update of the associated 782 metadata, or both. This is referred to as "branching". 784 For example, an initial classification results in the selection of 785 SFP A: DPI_1 --> SLB_8. However, when the DPI service function is 786 executed, attack traffic is detected at the application layer. DPI_1 787 re-classifies the traffic as attack and alters the service path to 788 SFP B, to include a firewall for policy enforcement: dropping the 789 traffic: DPI_1 --> FW_4. Subsequent to FW_4, surviving traffic would 790 be returned to the original SFF. In this simple example, the DPI 791 service function re-classifies the traffic based on local application 792 layer classification capabilities (that were not available during the 793 initial classification step). 795 When traffic arrives after being steered through an SFC-unaware SF, 796 the SFC Proxy must perform re-classification of traffic to determine 797 the SFP. The SFC Proxy is concerned with re-attaching information 798 for SFC-unaware SFs, and a stateful SFC Proxy simplifies such 799 classification to a flow lookup. 801 4.9. Shared Metadata 803 Sharing metadata allows the network to provide network-derived 804 information to the SFs, SF-to-SF information exchange and the sharing 805 of service-derived information to the network. Some SFCs may not 806 require metadata exchange. SFC infrastructure enables the exchange 807 of this shared data along the SFP. The shared metadata serves 808 several possible roles within the SFC architecture: 810 o Allows elements that typically operate as ships in the night to 811 exchange information. 813 o Encodes information about the network and/or data for post- 814 service forwarding. 816 o Creates an identifier used for policy binding by SFs. 818 Context information can be derived in several ways: 820 o External sources 822 o Network node classification 824 o Service function classification 826 5. Additional Architectural Concepts 828 There are a number of issues which solutions need to address, and 829 which the architecture informs but does not determine. This section 830 lays out some of those concepts. 832 5.1. The Role of Policy 834 Much of the behavior of service chains is driven by operator and per- 835 customer policy. This architecture is structured to isolate the 836 policy interactions from the data plane and control logic. 838 Specifically, it is assumed that the service chaining control plane 839 creates the service paths. The service chaining data plane is used 840 to deliver the classified packets along the service chains to the 841 intended service functions. 843 Policy, in contrast, interacts with the system in other places. 844 Policies and policy engines may monitor service functions to decide 845 if additional (or fewer) instances of services are needed. When 846 applicable, those decisions may in turn result in interactions that 847 direct the control logic to change the SFP placement or packet 848 classification rules. 850 Similarly, operator service policy, often managed by operational or 851 business support systems (OSS or BSS), will frequently determine what 852 service functions are available. Operator service policies also 853 determine which sequences of functions are valid and are to be used 854 or made available. 856 The offering of service chains to customers, and the selection of 857 which service chain a customer wishes to use, are driven by a 858 combination of operator and customer policies using appropriate 859 portals in conjunction with the OSS and BSS tools. These selections 860 then drive the service chaining control logic, which in turn 861 establishes the appropriate packet classification rules. 863 5.2. SFC Control Plane 865 This is part of the overall architecture but outside the scope of 866 this document. 868 The SFC control plane is responsible for constructing SFPs, 869 translating SFCs to forwarding paths and propagating path information 870 to participating nodes to achieve requisite forwarding behavior to 871 construct the service overlay. For instance, an SFC construction may 872 be static; selecting exactly which SFFs and which SFs from those SFFs 873 are to be used, or it may be dynamic, allowing the network to perform 874 some or all of the choices of SFF or SF to use to deliver the 875 selected service chain within the constraints represented by the 876 service path. 878 In the SFC architecture, SFs are resources; the control plane manages 879 and communicates their capabilities, availability and location in 880 fashions suitable for the transport and SFC operations in use. The 881 control plane is also responsible for the creation of the context 882 (see below). The control plane may be distributed (using new or 883 existing control plane protocols), or be centralized, or a 884 combination of the two. 886 The SFC control plane provides the following functionality: 888 1. An SFC-enabled domain wide view of all available service function 889 resources as well as the network locators through which they are 890 reachable. 892 2. Uses SFC policy to construct service function chains, and 893 associated service function paths. 895 3. Selection of specific SFs for a requested SFC, either statically 896 (using specific SFs) or dynamically (using service explicit SFs 897 at the time of delivering traffic to them). 899 4. Provides requisite SFC data plane information to the SFC 900 architecture components, most notably the SFF. 902 5. Provide the metadata and usage information classifiers need so 903 that they in turn can provide this metadata for appropriate 904 packets in the data plane. 906 6. When needed, provide information including policy information to 907 other SFC elements to be able to properly interpret metadata. 909 5.3. Resource Control 911 The SFC system may be responsible for managing all resources 912 necessary for the SFC components to function. This includes network 913 constraints used to plan and choose network path(s) between service 914 function forwarders, network communication paths between service 915 function forwarders and their attached service functions, 916 characteristics of the nodes themselves such as memory, number of 917 virtual interfaces, routes, and instantiation, configuration, and 918 deletion of SFs. 920 The SFC system will also be required to reflect policy decisions 921 about resource control, as expressed by other components in the 922 system. 924 While all of these aspects are part of the overall system, they are 925 beyond the scope of this architecture. 927 5.4. Infinite Loop Detection and Avoidance 929 This SFC architecture is predicated on topological independence from 930 the underlying forwarding topology. Consequently, a service topology 931 is created by Service Function Paths or by the local decisions of the 932 Service Function Forwarders based on the constraints expressed in the 933 SFP. Due to the overlay constraints, the packet-forwarding path may 934 need to visit the same SFF multiple times, and in some less common 935 cases may even need to visit the same SF more than once. The Service 936 Chaining solution needs to permit these limited and policy-compliant 937 loops. At the same time, the solutions must ensure that indefinite 938 and unbounded loops cannot be formed, as such would consume unbounded 939 resources without delivering any value. 941 In other words, this architecture requires the solution to prevent 942 infinite Service Function Loops, even when Service Functions may be 943 invoked multiple times in the same SFP. 945 5.5. Load Balancing Considerations 947 Supporting function elasticity and high-availability should not 948 overly complicate SFC or lead to unnecessary scalability problems. 950 In the simplest case, where there is only a single function in the 951 SFP (the next hop is either the destination address of the flow or 952 the appropriate next hop to that destination), one could argue that 953 there may be no need for SFC. 955 In the cases where the classifier is separate from the single 956 function or a function at the terminal address may need sub-prefix 957 (e.g., finer grained address information) or per-subscriber metadata, 958 a single SFP exists (i.e., the metadata changes but the SFP does 959 not), regardless of the number of potential terminal addresses for 960 the flow. This is the case of the simple load balancer. See 961 Figure 4. 963 +---+ +---++--->web server 964 source+-->|sff|+-->|sf1|+--->web server 965 +---+ +---++--->web server 967 Figure 4: Simple Load Balancing 969 By extrapolation, in the case where intermediary functions within a 970 chain had similar "elastic" behaviors, we do not need separate chains 971 to account for this behavior - as long as the traffic coalesces to a 972 common next-hop after the point of elasticity. 974 In Figure 5, we have a chain of five service functions between the 975 traffic source and its destination. 977 +---+ +---+ +---+ +---+ +---+ +---+ 978 |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| 979 +---+ +---+ +---+ +---+ +---+ +---+ 980 | | | | | | 981 +-----+-----+ +-----+-----+ 982 | | 983 + + 984 +---+ +---+ +---+ +---+ +---+ 985 source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination 986 +---+ +---+ +---+ +---+ +---+ 987 + + + 988 | | | 989 +---+ +---+ +---+ 990 |sf1| |sf3| |sf5| 991 +---+ +---+ +---+ 993 Figure 5: Load Balancing 995 This would be represented as one service function path: 996 sf1->sf2->sf3->sf4->sf5. The SFF is a logical element, which may be 997 made up of one or multiple components. In this architecture, the SFF 998 may handle load distribution based on policy. 1000 It can also be seen in the above that the same service function may 1001 be reachable through multiple SFFs, as discussed earlier. The 1002 selection of which SFF to use to reach SF3 may be made by the control 1003 logic in defining the SFP, or may be left to the SFFs themselves, 1004 depending upon policy, solution, and deployment constraints. In the 1005 latter case, it needs to be assured that exactly one SFF takes 1006 responsibility to steer traffic through SF3. 1008 5.6. MTU and Fragmentation Considerations 1010 This architecture prescribes additional information being added to 1011 packets to identify service function paths and often to represent 1012 metadata. It also envisions adding transport information to carry 1013 packets along service function paths, at least between service 1014 function forwarders. This added information increases the size of 1015 the packet to be carried by service chaining. Such additions could 1016 potentially increase the packet size beyond the MTU supported on some 1017 or all of the media used in the service chaining domain. 1019 Such packet size increases can thus cause operational MTU problems. 1020 Requiring fragmentation and reassembly in an SFF would be a major 1021 processing increase, and might be impossible with some transports. 1022 Expecting service functions to deal with packets fragmented by the 1023 SFC function might be onerous even when such fragmentation was 1024 possible. Thus, at the very least, solutions need to pay attention 1025 to the size cost of their approach. There may be alternative or 1026 additional means available, although any solution needs to consider 1027 the tradeoffs. 1029 These considerations apply to any generic architecture that increases 1030 the header size. There are also more specific MTU considerations: 1031 Effects on Path MTU Discovery (PMTUD) as well as deployment 1032 considerations. Deployments within a single administrative control 1033 or even a single Data Center complex can afford more flexibility in 1034 dealing with larger packets, and deploying existing mitigations that 1035 decrease the likelihood of fragmentation or discard. 1037 5.7. SFC OAM 1039 Operations, Administration, and Maintenance (OAM) tools are an 1040 integral part of the architecture. These serve various purposes, 1041 including fault detection and isolation, and performance management. 1042 For example, there are many advantages of SFP liveness detection, 1043 including status reporting, support for resiliency operations and 1044 policies, and an enhanced ability to balance load. 1046 Service Function Paths create a services topology, and OAM performs 1047 various functions within this service layer. Furthermore, SFC OAM 1048 follows the same architectural principles of SFC in general. For 1049 example, topological independence (including the ability to run OAM 1050 over various overlay technologies) and classification-based policy. 1052 We can subdivide the SFC OAM architecture in two parts: 1054 o In-band: OAM packets follow the same path and share fate with user 1055 packets, within the service topology. For this, they also follow 1056 the architectural principle of consistent policy identifiers, and 1057 use the same path IDs as the service chain data packets. Load 1058 balancing and SFC encapsulation with packet forwarding are 1059 particularly important here. 1061 o Out-of-band: reporting beyond the actual data plane. An 1062 additional layer beyond the data-plane OAM allows for additional 1063 alerting and measurements. 1065 This architecture prescribes end-to-end SFP OAM functions, which 1066 implies SFF understanding of whether an in-band packet is an OAM or 1067 user packet. However, service function validation is outside of the 1068 scope of this architecture, and application-level OAM is not what 1069 this architecture prescribes. 1071 Some of the detailed functions performed by SFC OAM include fault 1072 detection and isolation in a Service Function Path or a Service 1073 Function, verification that connectivity using SFPs is both effective 1074 and directing packets to the intended service functions, service path 1075 tracing, diagnostic and fault isolation, alarm reporting, performance 1076 measurement, locking and testing of service functions, validation 1077 with the control plane (see Section 5.2), and also allow for vendor- 1078 specific as well as experimental functions. SFC should leverage, and 1079 if needed extend relevant existing OAM mechanisms. 1081 5.8. Resilience and Redundancy 1083 As a practical operational requirement, any service chaining solution 1084 needs to be able to respond effectively, and usually very quickly, to 1085 failure conditions. These may be failures of connectivity in the 1086 network between SFFs, failures of SFFs, or failures of SFs. Per-SF 1087 state, as for example stateful-firewall state, is the responsibility 1088 of the SF, and not addressed by this architecture. 1090 Multiple techniques are available to address this issue. Solutions 1091 can describe both what they require and what they allow to address 1092 failure. Solutions can make use of flexible specificity of service 1093 function paths, if the SFF can be given enough information in a 1094 timely fashion to do this. Solutions can also make use of MAC or IP 1095 level redundancy mechanisms such as VRRP. Also, particularly for SF 1096 failures, load balancers co-located with the SFF or as part of the 1097 service function delivery mechanism can provide such robustness. 1099 Similarly, operational requirements imply resilience in the face of 1100 load changes. While mechanisms for managing (e.g., monitoring, 1101 instantiating, loading images, providing configuration to service 1102 function chaining control, deleting, etc.) virtual machines are out 1103 of scope for this architecture, solutions can and are aided by 1104 describing how they can make use of scaling mechanisms. 1106 6. Security Considerations 1108 Security considerations apply to the realization of this 1109 architecture, in particular to the documents that will define 1110 protocols. Such realization ought to provide means to protect 1111 against security and privacy attacks in the areas hereby described. 1113 Following the categorization of [RFC7498], we can largely divide the 1114 security consdierations in three areas: 1116 Service Overlay: Underneath the Service Function Forwarders, the 1117 components that are responsible for performing the transport 1118 forwarding consult the outer-transport encapsulation for 1119 underlay forwarding. Used transport mechanisms should satisfy 1120 the security requirements of the specific SFC deployment. These 1121 requirements typically include varying degrees of traffic 1122 separation, protection against different attacks (e.g., 1123 spoofing, man-in-the-middle, brute-force, or insertion attacks), 1124 and can also include authenticity and integrity checking, and/or 1125 confidentiality provisions. 1127 Classification: Specific requirements may need to be enforced at the 1128 boundaries of an SFC-enabled domain. These include, for 1129 example, to avoid leaking SFC information, and to protect its 1130 borders against various forms of attacks, including DDoS 1131 attacks. Classification is used at the ingress edge of an SFC- 1132 enabled domain. Policy for this classification is done using a 1133 plurality of methods. Whatever method is used needs to consider 1134 a range of security issues. These include appropriate 1135 authentication and authorization of classification policy, 1136 potential confidentiality issues of that policy, protection 1137 against corruption, and proper application of policy with needed 1138 segregation of application. This includes proper controls on 1139 the policies which drive the application of the SFC 1140 Encapsulation and associated metadata to packets. Similar 1141 issues need to be addressed if classification is performed 1142 within a service chaining domain, i.e., re-classification. 1144 SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP 1145 identification, and carries metadata. An operator may consider 1146 the SFC Metadata as sensitive. From a privacy perspective, a 1147 user may be concerned about the operator revealing data about 1148 (and not belonging to) the customer. Therefore, solutions 1149 should consider whether there is a risk of sensitive information 1150 slipping out of the operators control. Issues of information 1151 exposure should also consider flow analysis. Further, the SFC 1152 Encapsulation includes SFC OAM Functions, which need to not 1153 negatively affect the security considerations of an SFC-enabled 1154 domain. 1156 Finally, all entities (software or hardware) interacting with the 1157 service chaining mechanisms need to provide means of security against 1158 malformed, poorly configured (deliberate or not) protocol constructs 1159 and loops. These considerations are largely the same as those in any 1160 network, particularly an overlay network. 1162 7. Contributors and Acknowledgments 1164 The editors would like to thank Sam Aldrin, Alia Atlas, Nicolas 1165 Bouthors, Stewart Bryant, Linda Dunbar, Alla Goldner, Ken Gray, Barry 1166 Greene, Anil Gunturu, David Harrington, Shunsuke Homma, Dave Hood, 1167 Nagendra Kumar, Hongyu Li, Andrew Malis, Guy Meador III, Kengo Naito, 1168 Thomas Narten, Ron Parker, Reinaldo Penno, Naiming Shen, Xiaohu Xu, 1169 and Lucy Yong for a thorough review and useful comments. 1171 The initial version of this "Service Function Chaining (SFC) 1172 Architecture" document is the result of merging two previous 1173 documents, and this section lists the aggregate of authors, editors, 1174 contributors and acknowledged participants, all who provided 1175 important ideas and text that fed into this architecture. 1177 [I-D.boucadair-sfc-framework]: 1179 Authors: 1181 Mohamed Boucadair 1182 Christian Jacquenet 1183 Ron Parker 1184 Diego R. Lopez 1185 Jim Guichard 1186 Carlos Pignataro 1188 Contributors: 1190 Parviz Yegani 1191 Paul Quinn 1192 Linda Dunbar 1194 Acknowledgements: 1196 Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. 1197 Cheng, R. White, and B. Chatras for their review and 1198 comments. 1200 [I-D.quinn-sfc-arch]: 1202 Authors: 1204 Paul Quinn (editor) 1205 Joel Halpern (editor) 1207 Contributors: 1209 Puneet Agarwal 1210 Andre Beliveau 1211 Kevin Glavin 1212 Ken Gray 1213 Jim Guichard 1214 Surendra Kumar 1215 Darrel Lewis 1216 Nic Leymann 1217 Rajeev Manur 1218 Thomas Nadeau 1219 Carlos Pignataro 1220 Michael Smith 1221 Navindra Yadav 1223 Acknowledgements: 1225 The authors would like to thank David Ward, Abhijit Patra, 1226 Nagaraj Bagepalli, Darrel Lewis, Ron Parker, Lucy Yong and 1227 Christian Jacquenet for their review and comments. 1229 8. IANA Considerations 1231 [RFC Editor: please remove this section prior to publication.] 1233 This document has no IANA actions. 1235 9. Informative References 1237 [I-D.boucadair-sfc-framework] 1238 Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., 1239 Guichard, J., and C. Pignataro, "Service Function 1240 Chaining: Framework & Architecture", draft-boucadair-sfc- 1241 framework-02 (work in progress), February 2014. 1243 [I-D.quinn-sfc-arch] 1244 Quinn, P. and J. Halpern, "Service Function Chaining (SFC) 1245 Architecture", draft-quinn-sfc-arch-05 (work in progress), 1246 May 2014. 1248 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1249 Address Translator (Traditional NAT)", RFC 3022, January 1250 2001. 1252 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1253 NAT64: Network Address and Protocol Translation from IPv6 1254 Clients to IPv4 Servers", RFC 6146, April 2011. 1256 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1257 Translation", RFC 6296, June 2011. 1259 [RFC7498] Quinn, P. and T. Nadeau, "Problem Statement for Service 1260 Function Chaining", RFC 7498, April 2015. 1262 Authors' Addresses 1264 Joel Halpern (editor) 1265 Ericsson 1267 Email: jmh@joelhalpern.com 1269 Carlos Pignataro (editor) 1270 Cisco Systems, Inc. 1272 Email: cpignata@cisco.com