idnits 2.17.1 draft-ietf-sfc-architecture-02.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 (September 20, 2014) is 3506 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-10 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: Standards Track C. Pignataro, Ed. 5 Expires: March 24, 2015 Cisco 6 September 20, 2014 8 Service Function Chaining (SFC) Architecture 9 draft-ietf-sfc-architecture-02 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 March 24, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.3. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 58 2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 6 59 2.1. Service Function Chains . . . . . . . . . . . . . . . . . 6 60 2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 7 61 2.3. Service Function Paths . . . . . . . . . . . . . . . . . 8 62 3. Architecture Principles . . . . . . . . . . . . . . . . . . . 9 63 4. Core SFC Architecture Components . . . . . . . . . . . . . . 10 64 4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 11 65 4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 12 66 4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 12 67 4.3.1. Transport Derived SFF . . . . . . . . . . . . . . . . 14 68 4.4. SFC-Enabled Domain . . . . . . . . . . . . . . . . . . . 14 69 4.5. Network Overlay and Network Components . . . . . . . . . 14 70 4.6. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.7. Classification . . . . . . . . . . . . . . . . . . . . . 16 72 4.8. Re-Classification and Branching . . . . . . . . . . . . . 16 73 4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 17 74 5. Additional Architectural Concepts . . . . . . . . . . . . . . 17 75 5.1. The Role of Policy . . . . . . . . . . . . . . . . . . . 17 76 5.2. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 18 77 5.3. Resource Control . . . . . . . . . . . . . . . . . . . . 19 78 5.4. Infinite Loop Detection and Avoidance . . . . . . . . . . 19 79 5.5. Load Balancing Considerations . . . . . . . . . . . . . . 20 80 5.6. MTU and Fragmentation Considerations . . . . . . . . . . 21 81 5.7. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 5.8. Resilience and Redundancy . . . . . . . . . . . . . . . . 22 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 7. Contributors and Acknowledgments . . . . . . . . . . . . . . 23 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 86 9. Informative References . . . . . . . . . . . . . . . . . . . 25 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 89 1. Introduction 91 This document describes an architecture used for the creation and 92 ongoing maintenance of Service Function Chains (SFC) in a network. 93 It includes architectural concepts, principles, and components. 95 An overview of the issues associated with the deployment of end-to- 96 end service function chains, abstract sets of service functions and 97 their ordering constraints that create a composite service and the 98 subsequent "steering" of traffic flows through said service 99 functions, is described in [I-D.ietf-sfc-problem-statement]. 101 This architecture presents a model addressing the problematic aspects 102 of existing service deployments, including topological independence 103 and configuration complexity. 105 Service function chains enable composite services that are 106 constructed from one or more service functions. 108 1.1. Scope 110 This document defines a framework to realize Service Function 111 Chaining (SFC) with minimum requirements on the physical topology of 112 the network. The proposed solution relies on initial packet 113 classification. Packets initially classified for handling by a set 114 of Service Functions (SFs) in the SFC-enabled domain are then 115 forwarded to that set of SFs for processing. 117 This document does not make any assumption on the deployment context. 118 The proposed framework covers both fixed and mobile networks. 120 The architecture described herein is assumed to be applicable to a 121 single network administrative domain. While it is possible for the 122 architectural principles and components to be applied to inter-domain 123 SFCs, these are left for future study. 125 1.2. Assumptions 127 The following assumptions are made: 129 o Not all SFs can be characterized with a standard definition in 130 terms of technical description, detailed specification, 131 configuration, etc. 133 o There is no global or standard list of SFs enabled in a given 134 administrative domain. The set of SFs varies as a function of the 135 service to be provided and according to the networking 136 environment. 138 o There is no global or standard SF chaining logic. The ordered set 139 of SFs that needs to be enabled to deliver a given service is 140 specific to each administrative entity. 142 o The chaining of SFs and the criteria to invoke them are specific 143 to each administrative entity that operates an SF-enabled domain. 145 o Several SF chaining policies can be simultaneously applied within 146 an administrative domain to meet various business requirements. 148 o No assumption is made on how FIBs and RIBs of involved nodes are 149 populated. 151 o How to bind traffic to a given SF chain is policy-based. 153 1.3. Definition of Terms 155 Network Service: An offering provided by an operator that is 156 delivered using one or more service functions. This may also be 157 referred to as a composite service. The term "service" is used 158 to denote a "network service" in the context of this document. 160 Note: Beyond this document, the term "service" is overloaded 161 with varying definitions. For example, to some a service is an 162 offering composed of several elements within the operator's 163 network, whereas for others a service, or more specifically a 164 network service, is a discrete element such as a firewall. 165 Traditionally, such services (in the latter sense) host a set of 166 service functions and have a network locator where the service 167 is hosted. 169 Classification: Locally instantiated policy and customer/network/ 170 service profile matching of traffic flows for identification of 171 appropriate outbound forwarding actions. 173 Classifier: An element that performs Classification. 175 Service Function Chain (SFC): A service function chain defines a set 176 of abstract service functions and ordering constraints that must 177 be applied to packets and/or frames selected as a result of 178 classification. The implied order may not be a linear 179 progression as the architecture allows for SFCs that copy to 180 more than one branch, and also allows for cases where there is 181 flexibility in the order in which service functions need to be 182 applied. The term service chain is often used as shorthand for 183 service function chain. 185 Service Function (SF): A function that is responsible for specific 186 treatment of received packets. A Service Function can act at 187 various layers of a protocol stack (e.g., at the network layer 188 or other OSI layers). As a logical component, a Service 189 Function can be realized as a virtual element or be embedded in 190 a physical network element. One or multiple Service Functions 191 can be embedded in the same network element. Multiple 192 occurrences of the Service Function can exist in the same 193 administrative domain. 195 One or more Service Functions can be involved in the delivery of 196 added-value services. A non-exhaustive list of abstract Service 197 Functions includes: firewalls, WAN and application acceleration, 198 Deep Packet Inspection (DPI), LI (Lawful Intercept), server load 199 balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], 200 HOST_ID injection, HTTP Header Enrichment functions, TCP 201 optimizer. 203 An SF may be SFC encapsulation aware, that is it receives and 204 acts on information in the SFC encapsulation, or unaware, in 205 which case data forwarded to the SF does not contain the SFC 206 encapsulation. 208 Service Function Forwarder (SFF): A service function forwarder is 209 responsible for delivering traffic received from the network to 210 one or more connected service functions according to information 211 carried in the SFC encapsulation, as well as handling traffic 212 coming back from the SF. Additionally, a service function 213 forwarder is responsible for delivering traffic to a classifier 214 when needed and supported, mapping out traffic to another SFF 215 (in the same or different type of overlay), and terminating the 216 SFP. 218 Metadata: provides the ability to exchange context information 219 between classifiers and SFs and among SFs. 221 Service Function Path (SFP): The SFP provides a level of indirection 222 between the fully abstract notion of service chain as a sequence 223 of abstract service functions to be delivered, and the fully 224 specified notion of exactly which SFF/SFs the packet will visit 225 when it actually traverses the network. By allowing the control 226 components to specify this level of indirection, the operator 227 may control the degree of SFF/SF selection authority that is 228 delegated to the network. 230 SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP 231 identification, and is used by the SFC-aware functions, such as 232 the SFF and SFC-aware SFs. The SFC Encapsulation is not used 233 for network packet forwarding. In addition to SFP 234 identification, the SFC encapsulation carries data plane context 235 information, also referred to as metadata. 237 Rendered Service Path (RSP): The Service Function Path is a 238 constrained specification of where packets using a certain 239 service chain must go. While it may be so constrained as to 240 identify the exact locations, it can also be less specific. 241 Packets themselves are of course transmitted from and to 242 specific places in the network, visiting a specific sequence of 243 SFFs and SFs. This sequence of actual visits by a packet to 244 specific SFFs and SFs in the network is known as the Rendered 245 Service Path (RSP). This definition is included here for use by 246 later documents, such as when solutions may need to discuss the 247 actual sequence of locations the packets visit. 249 SFC-enabled Domain: A network or region of a network that implements 250 SFC. An SFC-enabled Domain is limited to a single network 251 administrative domain. 253 SFC Proxy: Removes and inserts SFC encapsulation on behalf of an 254 SFC-unaware service function. SFC proxies are logical elements. 256 2. Architectural Concepts 258 The following sections describe the foundational concepts of service 259 function chaining and the SFC architecture. 261 Service Function Chaining enables the creation of composite (network) 262 services that consist of an ordered set of Service Functions (SF) 263 that must be applied to packets and/or frames selected as a result of 264 classification. Each SF is referenced using an identifier that is 265 unique within an SF-enabled domain. No IANA registry is required to 266 store the identity of SFs. 268 Service Function Chaining is a concept that provides for more than 269 just the application of an ordered set of SFs to selected traffic; 270 rather, it describes a method for deploying SFs in a way that enables 271 dynamic ordering and topological independence of those SFs as well as 272 the exchange of metadata between participating entities. 274 2.1. Service Function Chains 276 In most networks, services are constructed as abstract sequences of 277 SFs that represent SFCs. At a high level, an SFC is an abstracted 278 view of a service that specifies the set of required SFs as well as 279 the order in which they must be executed. Graphs, as illustrated in 280 Figure 1, define an SFC, where each graph node represents the 281 required existence of at least one abstract SF. Such graph nodes 282 (SFs) can be part of zero, one, or many SFCs. A given graph node 283 (SF) can appear one time or multiple times in a given SFC. 285 SFCs can start from the origination point of the service function 286 graph (i.e.: node 1 in Figure 1), or from any subsequent node in the 287 graph. SFs may therefore become branching nodes in the graph, with 288 those SFs selecting edges that move traffic to one or more branches. 289 An SFC can have more than one terminus. 291 ,-+-. ,---. ,---. ,---. 292 / \ / \ / \ / \ 293 ( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) 294 \ / \ / \ / \ / 295 `---' `---' `---' `---' 297 ,-+-. ,---. ,---. ,---. ,---. 298 / \ / \ / \ / \ / \ 299 ( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 ) 300 \ / \ / \ / \ / \ / 301 `---' `---' `---' `---' `---' 303 ,-+-. ,---. ,---. ,---. ,---. 304 / \ / \ / \ / \ / \ 305 ( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 ) 306 \ / \ / \ / \ / \ / 307 `---' `---' `---' `---' `---' 309 Figure 1: Service Function Chain Graphs 311 2.2. Service Function Chain Symmetry 313 SFCs may be unidirectional or bidirectional. A unidirectional SFC 314 requires that traffic be forwarded through the ordered SFs in one 315 direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a 316 symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), and in 317 which the SF instances are the same in opposite directions. A hybrid 318 SFC has attributes of both unidirectional and bidirectional SFCs; 319 that is to say some SFs require symmetric traffic, whereas other SFs 320 do not process reverse traffic or are independent of the 321 corresponding forward traffic. 323 SFCs may contain cycles; that is traffic may need to traverse one or 324 more SFs within an SFC more than once. Solutions will need to ensure 325 suitable disambiguation for such situations. 327 The architectural allowance that is made for SFPs that delegate 328 choice to the network for which SFs and/or SFFs a packet will visit 329 creates potential issues here. A solution that allows such 330 delegation needs to also describe how the solution ensures that those 331 service chains that require service function chain symmetry can 332 achieve that. 334 Further, there are state tradeoffs in symmetry. Symmetry may be 335 realized in several ways depending on the SFF and classifier 336 functionality. In some cases, "mirrored" classification (i.e., from 337 Source to Destination and from Destination to Source) policy may be 338 deployed, whereas in others shared state between classifiers may be 339 used to ensure that symmetric flows are correctly identified, then 340 steered along the required SFP. At a high level, there are various 341 common cases. In a non-exhaustive way, there can be for example: a 342 single classifier (or a small number of classifiers), in which case 343 both incoming and outgoing flows could be recognized at the same 344 classifier, so the synchronization would be feasible by internal 345 mechanisms internal to the classifier. Another case is the one of 346 stateful classifiers where several classifiers may be clustered and 347 share state. Lastly, another case entails fully distributed 348 classifiers, where synchronization needs to be provided through 349 unspecified means. This is a non-comprehensive list of common cases. 351 2.3. Service Function Paths 353 A service function path (SFP) is a mechanism used by service chaining 354 to express the result of applying more granular policy and 355 operational constraints to the abstract requirements of a service 356 chain (SFC). This architecture does not mandate the degree of 357 specificity of the SFP. Architecturally, within the same SFC-enabled 358 domain, some SFPs may be fully specified, selecting exactly which SFF 359 and which SF are to be visited by packets using that SFP, while other 360 SFPs may be quite vague, deferring to the SFF the decisions about the 361 exact sequence of steps to be used to realize the SFC. The 362 specificity may be anywhere in between these extremes. 364 As an example of such an intermediate specificity, there may be two 365 SFPs associated with a given SFC, where one SFP says essentially that 366 any order of SFF and SF may be used as long as it is within data 367 center 1, and where the second SFP allows the same latitude, but only 368 within data center 2. 370 Thus, the policies and logic of SFP selection or creation (depending 371 upon the solution) produce what may be thought of as a constrained 372 version of the original SFC. Since multiple policies may apply to 373 different traffic that uses the same SFC, it also follows that there 374 may be multiple SFPs may be associated with a single SFC. 376 The architecture allows for the same SF to be reachable through 377 multiple SFFs. In these cases, some SFPs may constrain which SFF is 378 used to reach which SF, while some SFPs may leave that decision to 379 the SFF itself. 381 Further, the architecture allows for two or more SFs to be attached 382 to the same SFF, and possibly connected via internal means allowing 383 more effective communication. In these cases, some solutions or 384 deployments may choose to use some form of internal inter-process or 385 inter-VM messaging (communication behind the virtual switching 386 element) that is optimized for such an environment. This must be 387 coordinated with the SFF so that the service function forwarding can 388 properly perform its job. Implementation details of such mechanisms 389 are considered out of scope for this document, and can include a 390 spectrum of methods: for example situations including all next-hops 391 explicitly, others where a list of possible next-hops is provided and 392 the selection is local, or cases with just an identifier, where all 393 resolution is local. 395 This architecture also allows the same SF to be part of multiple 396 SFPs. 398 3. Architecture Principles 400 Service function chaining is predicated on several key architectural 401 principles: 403 1. Topological independence: no changes to the underlay network 404 forwarding topology - implicit, or explicit - are needed to 405 deploy and invoke SFs or SFCs. 407 2. Plane separation: dynamic realization of SFPs is separated from 408 packet handling operations (e.g., packet forwarding). 410 3. Classification: traffic that satisfies classification rules is 411 forwarded according to a specific SFP. For example, 412 classification can be as simple as an explicit forwarding entry 413 that forwards all traffic from one address into the SFP. 414 Multiple classification points are possible within an SFC (i.e. 415 forming a service graph) thus enabling changes/updates to the SFC 416 by SFs. 418 Classification can occur at varying degrees of granularity; for 419 example, classification can use a 5-tuple, a transport port or 420 set of ports, part of the packet payload, or it can come from 421 external systems. 423 4. Shared Metadata: Metadata/context data can be shared amongst SFs 424 and classifiers, between SFs, and between external systems and 425 SFs (e.g., orchestration). 427 Generally speaking, metadata can be thought of as providing and 428 sharing the result of classification (that occurs within the SFC- 429 enabled domain, or external to it) along an SFP. For example, an 430 external repository might provide user/subscriber information to 431 a service chain classifier. This classifier could in turn impose 432 that information in the SFC encapsulation for delivery to the 433 requisite SFs. The SFs could in turn utilize the user/subscriber 434 information for local policy decisions. 436 5. Service definition independence: The SFC architecture does not 437 depend on the details of SFs themselves. Additionally, no IANA 438 registry is required to store the list of SFs. 440 6. Service function chain independence: The creation, modification, 441 or deletion of an SFC has no impact on other SFCs. The same is 442 true for SFPs. 444 7. Heterogeneous control/policy points: The architecture allows SFs 445 to use independent mechanisms (out of scope for this document) to 446 populate and resolve local policy and (if needed) local 447 classification criteria. 449 4. Core SFC Architecture Components 451 At a very high level, the logical architecture of an SFC-enabled 452 Domain comprises: 454 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 . +--------------+ +------------------~~~ 456 . | Service | SFC | Service +---+ +---+ 457 . |Classification| Encapsulation | Function |sf1|...|sfn| 458 +---->| Function |+---------------->| Path +---+ +---+ 459 . +--------------+ +------------------~~~ 460 . SFC-enabled Domain 461 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Figure 2: Service Function Chain Architecture 465 The following sub-sections provide details on each logical component 466 that form the basis of the SFC architecture. A detailed overview of 467 how each of these architectural components interact is provided in 468 Figure 3: 470 +----------------+ +----------------+ 471 | SFC-aware | | SFC-unaware | 472 |Service Function| |Service Function| 473 +-------+--------+ +-------+--------+ 474 | | 475 SFC Encapsulation No SFC Encapsulation 476 | SFC | 477 +---------+ +----------------+ Encapsulation +---------+ 478 |SFC-Aware|-----------------+ \ +------------|SFC Proxy| 479 | SF | ... ----------+ \ \ / +---------+ 480 +---------+ \ \ \ / 481 +-------+--------+ 482 | SF Forwarder | 483 | (SFF) | 484 +-------+--------+ 485 | 486 SFC Encapsulation 487 | 488 ... SFC-enabled Domain ... 489 | 490 Network Overlay Transport 491 | 492 _,....._ 493 ,-' `-. 494 / `. 495 | Network | 496 `. / 497 `.__ __,-' 498 `'''' 500 Figure 3: Service Function Chain Architecture Components 502 4.1. SFC Encapsulation 504 The SFC encapsulation enables service function path selection. It 505 also enables the sharing of metadata/context information when such 506 metadata exchange is required. 508 The SFC encapsulation provides explicit information used to identify 509 the SFP. However, the SFC encapsulation is not a transport 510 encapsulation itself: it is not used to forward packets within the 511 network fabric. If packets need to flow between separate physical 512 platforms, the SFC encapsulation therefore relies on an outer network 513 transport. Transit forwarders -- such as router and switches -- 514 simply forward SFC encapsulated packets based on the outer (non-SFC) 515 encapsulation. 517 One of the key architecture principles of SFC is that the SFC 518 encapsulation remain transport independent. As such any network 519 transport protocol may be used to carry the SFC encapsulated traffic. 521 4.2. Service Function (SF) 523 The concept of an SF evolves; rather than being viewed as a bump in 524 the wire, an SF becomes a resource within a specified administrative 525 domain that is available for consumption as part of a composite 526 service. SFs send/receive data to/from one or more SFFs. SFC-aware 527 SFs receive this traffic with the SFC encapsulation. 529 While the SFC architecture defines a new encapsulation - the SFC 530 encapsulation - and several logical components for the construction 531 of SFCs, existing SF implementations may not have the capabilities to 532 act upon or fully integrate with the new SFC encapsulation. In order 533 to provide a mechanism for such SFs to participate in the 534 architecture, an SFC proxy function is defined (see Section 4.6). 535 The SFC proxy acts as a gateway between the SFC encapsulation and 536 SFC-unaware SFs. The integration of SFC-unaware service functions is 537 discussed in more detail in the SFC proxy section. 539 This architecture allows an SF to be part of multiple SFPs and SFCs. 541 4.3. Service Function Forwarder (SFF) 543 The SFF is responsible for forwarding packets and/or frames received 544 from the network to one or more SFs associated with a given SFF using 545 information conveyed in the SFC encapsulation. Traffic from SFs 546 eventually returns to the same SFF, which is responsible for 547 injecting traffic back onto the network. 549 The collection of SFFs and associated SFs creates a service plane 550 overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside. 551 Within this service plane, the SFF component connects different SFs 552 that form a service function path. 554 SFFs maintain the requisite SFP forwarding information. SFP 555 forwarding information is associated with a service path identifier 556 that is used to uniquely identify an SFP. The service forwarding 557 state enables an SFF to identify which SFs of a given SFP should be 558 applied, and in what order, as traffic flows through the associated 559 SFP. While there may appear to the SFF to be only one available way 560 to deliver the given SF, there may also be multiple choices allowed 561 by the constraints of the SFP. 563 If there are multiple choices, the SFF needs to preserve the property 564 that all packets of a given flow are handled the same way, since the 565 SF may well be stateful. Additionally, the SFF may preserve the 566 handling of packets based on other properties on top of a flow, such 567 as a subscriber, session, or application instance identification. 569 The SFF also has the information to allow it to forward packets to 570 the next SFF after applying local service functions. Again, while 571 there may be only a single choice available, the architecture allows 572 for multiple choices for the next SFF. As with SFs, the solution 573 needs to operate such that the behavior with regard to specific flows 574 (see the Rendered Service Path) is stable. The selection of 575 available SFs and next SFFs may be interwoven when an SFF supports 576 multiple distinct service functions and the same service function is 577 available at multiple SFFs. Solutions need to be clear about what is 578 allowed in these cases. 580 Even when the SFF supports and utilizes multiple choices, the 581 decision as to whether to use flow-specific mechanisms or coarser 582 grained means to ensure that the behavior of specific flows is stable 583 is a matter for specific solutions and specific implementations. 585 The SFF component has the following primary responsibilities: 587 1. SFP forwarding : Traffic arrives at an SFF from the network. The 588 SFF determines the appropriate SF the traffic should be forwarded 589 to via information contained in the SFC encapsulation. Post-SF, 590 the traffic is returned to the SFF, and if needed forwarded to 591 another SF associated with that SFF. If there is another non- 592 local (i.e., different SFF) hop in the SFP, the SFF further 593 encapsulates the traffic in the appropriate network transport 594 protocol and delivers it to the network for delivery to the next 595 SFF along the path. Related to this forwarding responsibility, 596 an SFF should be able to interact with metadata. 598 2. Terminating SFPs : An SFC is completely executed when traffic has 599 traversed all required SFs in a chain. When traffic arrives at 600 the SFF after the last SF has finished processing it, the final 601 SFF knows from the service forwarding state that the SFC is 602 complete. The SFF removes the SFC encapsulation and delivers the 603 packet back to the network for forwarding. 605 3. Maintaining flow state: In some cases, the SFF may be stateful. 606 It creates flows and stores flow-centric information. This state 607 information may be used for a range of SFP-related tasks such as 608 ensuring consistent treatment of all packets in a given flow, 609 ensuring symmetry or for state-aware SFC Proxy functionality (see 610 Section 4.8). 612 4.3.1. Transport Derived SFF 614 Service function forwarding, as described above, directly depends 615 upon the use of the service path information contained in the SFC 616 encapsulation. However, existing implementations may not be able to 617 act on the SFC encapsulation. These platforms may opt to use 618 existing transport information if it can be arranged to provide 619 explicit service path information. 621 This results in the same architectural behavior and meaning for 622 service function forwarding and service function paths. It is the 623 responsibility of the control components to ensure that the transport 624 path executed in such a case is fully aligned with the path 625 identified by the information in the service chaining encapsulation. 627 4.4. SFC-Enabled Domain 629 Specific features may need to be enforced at the boundaries of an 630 SFC-enabled domain, for example to avoid leaking SFC information. 631 Using the term node to refer generically to an entity that is 632 performing a set of functions, in this context, an SFC Boundary Node 633 denotes a node that connects one SFC-enabled domain to a node either 634 located in another SFC-enabled domain or in a domain that is SFC- 635 unaware. 637 An SFC Boundary node can act as egress or ingress. An SFC Egress 638 Node denotes a SFC Boundary Node that handles traffic leaving the 639 SFC-enabled domain the Egress Node belongs to. Such a node is 640 required to remove any information specific to the SFC Domain, 641 typically the SFC Encapsulation. An SFC Ingress Node denotes an SFC 642 Boundary Node that handles traffic entering the SFC-enabled domain. 643 In most solutions and deployments this will need to include a 644 classifier, and will be responsible for adding the SFC encapsulation 645 to the packet. 647 4.5. Network Overlay and Network Components 649 Underneath the SFF there are components responsible for performing 650 the transport (overlay) forwarding. They do not consult the SFC 651 encapsulation or inner payload for performing this forwarding. They 652 only consult the outer-transport encapsulation for the transport 653 (overlay) forwarding. 655 4.6. SFC Proxy 657 In order for the SFC architecture to support SFC-unaware SFs (e.g., 658 legacy service functions) a logical SFC proxy function may be used. 660 This function sits between an SFF and one or more SFs to which the 661 SFF is directing traffic. 663 The proxy accepts packets from the SFF on behalf of the SF. It 664 removes the SFC encapsulation, and then uses a local attachment 665 circuit to deliver packets to SFC unaware SFs. It also receives 666 packets back from the SF, reapplies the SFC encapsulation, and 667 returns them to the SFF for processing along the service function 668 path. 670 Thus, from the point of view of the SFF, the SFC proxy appears to be 671 part of an SFC aware SF. 673 Communication details between the SFF and the SFC Proxy are the same 674 as those between the SFF and an SFC aware SF. The details of that 675 are not part of this architecture. The details of the communication 676 methods over the local attachment circuit between the SFC proxy and 677 the SFC-unaware SF are dependent upon the specific behaviors and 678 capabilities of that SFC-unaware SF, and thus are also out of scope 679 for this architecture. 681 Specifically, for traffic received from the SFF intended for the SF 682 the proxy is representing, the SFC proxy: 684 o Removes the SFC encapsulation from SFC encapsulated packets. 686 o Identifies the required SF to be applied based on available 687 information including that carried in the SFC encapsulation. 689 o Selects the appropriate outbound local attachment circuit through 690 which the next SF for this SFP is reachable. This is derived from 691 the identification of the SF carried in the SFC encapsulation, and 692 may include local techniques. Examples of a local attachment 693 circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3, 694 GRE, VXLAN. 696 o Forwards the original payload via the selected local attachment 697 circuit to the appropriate SF. 699 When traffic is returned from the SF: 701 o Applies the required SFC encapsulation. The determination of the 702 encapsulation details may be inferred by the local attachment 703 circuit through which the packet and/or frame was received, or via 704 packet classification, or other local policy. In some cases, 705 packet ordering or modification by the SF may necessitate 706 additional classification in order to re-apply the correct SFC 707 encapsulation. 709 o Delivers the packet with the SFC Encapsulation to the SFF, as 710 would happen with packets returned from an SFC-aware SF. 712 Alternatively, a service provider may decide to exclude legacy 713 service functions from an SFC domain. 715 4.7. Classification 717 Traffic from the network that satisfies classification criteria is 718 directed into an SFP and forwarded to the requisite service 719 function(s). Classification is handled by a service classification 720 function; initial classification occurs at the ingress to the SFC 721 domain. The granularity of the initial classification is determined 722 by the capabilities of the classifier and the requirements of the SFC 723 policy. For instance, classification might be relatively coarse: all 724 packets from this port are subject to SFC policy X and directed into 725 SFP A, or quite granular: all packets matching this 5-tuple are 726 subject to SFC policy Y and directed into SFP B. 728 As a consequence of the classification decision, the appropriate SFC 729 encapsulation is imposed on the data, and a suitable SFP is selected 730 or created. Classification results in attaching the traffic to a 731 specific SFP. 733 4.8. Re-Classification and Branching 735 The SFC architecture supports re-classification (or non-initial 736 classification) as well. As packets traverse an SFP, re- 737 classification may occur - typically performed by a classification 738 function co-resident with a service function. Reclassification may 739 result in the selection of a new SFP, an update of the associated 740 metadata, or both. This is referred to as "branching". 742 For example, an initial classification results in the selection of 743 SFP A: DPI_1 --> SLB_8. However, when the DPI service function is 744 executed, attack traffic is detected at the application layer. DPI_1 745 re-classifies the traffic as attack and alters the service path to 746 SFP B, to include a firewall for policy enforcement: dropping the 747 traffic: DPI_1 --> FW_4. Subsequent to FW_4, surviving traffic would 748 be returned to the original SFF. In this simple example, the DPI 749 service function re-classifies the traffic based on local application 750 layer classification capabilities (that were not available during the 751 initial classification step). 753 When traffic arrives after being steered through an SFC-unaware SF, 754 the SFC Proxy must perform re-classification of traffic to determine 755 the SFP. The SFC Proxy is concerned with re-attaching information 756 for SFC-unaware SFs, and a stateful SFC Proxy simplifies such 757 classification to a flow lookup. 759 4.9. Shared Metadata 761 Sharing metadata allows the network to provide network-derived 762 information to the SFs, SF-to-SF information exchange and the sharing 763 of service-derived information to the network. Some SFCs may not 764 require metadata exchange. SFC infrastructure enables the exchange 765 of this shared data along the SFP. The shared metadata serves 766 several possible roles within the SFC architecture: 768 o Allows elements that typically operate as ships in the night to 769 exchange information. 771 o Encodes information about the network and/or data for post- 772 service forwarding. 774 o Creates an identifier used for policy binding by SFs. 776 Context information can be derived in several ways: 778 o External sources 780 o Network node classification 782 o Service function classification 784 5. Additional Architectural Concepts 786 There are a number of issues which solutions need to address, and 787 which the architecture informs but does not determine. This section 788 lays out some of those concepts. 790 5.1. The Role of Policy 792 Much of the behavior of service chains is driven by operator and per- 793 customer policy. This architecture is structured to isolate the 794 policy interactions from the data plane and control logic. 796 Specifically, it is assumed that the service chaining control plane 797 creates the service paths. The service chaining data plane is used 798 to deliver the classified packets along the service chains to the 799 intended service functions. 801 Policy, in contrast, interacts with the system in other places. 802 Policies and policy engines may monitor service functions to decide 803 if additional (or fewer) instances of services are needed. When 804 applicable, those decisions may in turn result in interactions that 805 direct the control logic to change the SFP placement or packet 806 classification rules. 808 Similarly, operator service policy, often managed by operational or 809 business support systems (OSS or BSS), will frequently determine what 810 service functions are available. Operator service policies also 811 determine which sequences of functions are valid and are to be used 812 or made available. 814 The offering of service chains to customers, and the selection of 815 which service chain a customer wishes to use, are driven by a 816 combination of operator and customer policies using appropriate 817 portals in conjunction with the OSS and BSS tools. These selections 818 then drive the service chaining control logic, which in turn 819 establishes the appropriate packet classification rules. 821 5.2. SFC Control Plane 823 This is part of the overall architecture but outside the scope of 824 this document. 826 The SFC control plane is responsible for constructing SFPs, 827 translating SFCs to forwarding paths and propagating path information 828 to participating nodes to achieve requisite forwarding behavior to 829 construct the service overlay. For instance, an SFC construction may 830 be static; selecting exactly which SFFs and which SFs from those SFFs 831 are to be used, or it may be dynamic, allowing the network to perform 832 some or all of the choices of SFF or SF to use to deliver the 833 selected service chain within the constraints represented by the 834 service path. 836 In the SFC architecture, SFs are resources; the control plane manages 837 and communicates their capabilities, availability and location in 838 fashions suitable for the transport and SFC operations in use. The 839 control plane is also responsible for the creation of the context 840 (see below). The control plane may be distributed (using new or 841 existing control plane protocols), or be centralized, or a 842 combination of the two. 844 The SFC control plane provides the following functionality: 846 1. An SFC-enabled domain wide view of all available service function 847 resources as well as the network locators through which they are 848 reachable. 850 2. Uses SFC policy to construct service function chains, and 851 associated service function paths. 853 3. Selection of specific SFs for a requested SFC, either statically 854 (using specific SFs) or dynamically (using service explicit SFs 855 at the time of delivering traffic to them). 857 4. Provides requisite SFC data plane information to the SFC 858 architecture components, most notably the SFF. 860 5. Allocation of metadata associated with a given SFP and 861 propagation of the metadata to relevant SFs and/or SFC 862 encapsulation-proxies or their respective policy planes. 864 5.3. Resource Control 866 The SFC system may be responsible for managing all resources 867 necessary for the SFC components to function. This includes network 868 constraints used to plan and choose network path(s) between service 869 function forwarders, network communication paths between service 870 function forwarders and their attached service functions, 871 characteristics of the nodes themselves such as memory, number of 872 virtual interfaces, routes, and instantiation, configuration, and 873 deletion of SFs. 875 The SFC system will also be required to reflect policy decisions 876 about resource control, as expressed by other components in the 877 system. 879 While all of these aspects are part of the overall system, they are 880 beyond the scope of this architecture. 882 5.4. Infinite Loop Detection and Avoidance 884 This SFC architecture is predicated on topological independence from 885 the underlying forwarding topology. Consequently, a service topology 886 is created by Service Function Paths or by the local decisions of the 887 Service Function Forwarders based on the constraints expressed in the 888 SFP. Due to the overlay constraints, the packet-forwarding path may 889 need to visit the same SFF multiple times, and in some less common 890 cases may even need to visit the same SF more than once. The Service 891 Chaining solution needs to permit these limited and policy-compliant 892 loops. At the same time, the solutions must ensure that indefinite 893 and unbounded loops cannot be formed, as such would consume unbounded 894 resources without delivering any value. 896 In other words, this architecture prevents infinite Service Function 897 Loops, even when Service Functions may be invoked multiple times in 898 the same SFP. 900 5.5. Load Balancing Considerations 902 Supporting function elasticity and high-availability should not 903 overly complicate SFC or lead to unnecessary scalability problems. 905 In the simplest case, where there is only a single function in the 906 SFP (the next hop is either the destination address of the flow or 907 the appropriate next hop to that destination), one could argue that 908 there may be no need for SFC. 910 In the cases where the classifier is separate from the single 911 function or a function at the terminal address may need sub-prefix or 912 per-subscriber metadata, a single SFP exists (the metadata changes 913 but the SFP does not), regardless of the number of potential terminal 914 addresses for the flow. This is the case of the simple load 915 balancer. See Figure 4. 917 +---+ +---++--->web server 918 source+-->|sff|+-->|sf1|+--->web server 919 +---+ +---++--->web server 921 Figure 4: Simple Load Balancing 923 By extrapolation, in the case where intermediary functions within a 924 chain had similar "elastic" behaviors, we do not need separate chains 925 to account for this behavior - as long as the traffic coalesces to a 926 common next-hop after the point of elasticity. 928 In Figure 5, we have a chain of five service functions between the 929 traffic source and its destination. 931 +---+ +---+ +---+ +---+ +---+ +---+ 932 |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| 933 +---+ +---+ +---+ +---+ +---+ +---+ 934 | | | | | | 935 +-----+-----+ +-----+-----+ 936 | | 937 + + 938 +---+ +---+ +---+ +---+ +---+ 939 source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination 940 +---+ +---+ +---+ +---+ +---+ 941 + + + 942 | | | 943 +---+ +---+ +---+ 944 |sf1| |sf3| |sf5| 945 +---+ +---+ +---+ 947 Figure 5: Load Balancing 949 This would be represented as one service function path: 950 sf1->sf2->sf3->sf4->sf5. The SFF is a logical element, which may be 951 made up of one or multiple components. In this architecture, the SFF 952 may handle load distribution based on policy. 954 It can also be seen in the above that the same service function may 955 be reachable through multiple SFFs, as discussed earlier. The 956 selection of which SFF to use to reach SF3 may be made by the control 957 logic in defining the SFP, or may be left to the SFFs themselves, 958 depending upon policy, solution, and deployment constraints. In the 959 latter case, it needs to be assured that exactly one SFF takes 960 responsibility to steer traffic through SF3. 962 5.6. MTU and Fragmentation Considerations 964 This architecture prescribes additional information being added to 965 packets to identify service function paths and often to represent 966 metadata. It also envisions adding transport information to carry 967 packets along service function paths, at least between service 968 function forwarders. This added information increases the size of 969 the packet to be carried by service chaining. Such additions could 970 potentially increase the packet size beyond the MTU supported on some 971 or all of the media used in the service chaining domain. 973 Such packet size increases can thus cause operational MTU problems. 974 Requiring fragmentation and reassembly in an SFF would be a major 975 processing increase, and might be impossible with some transports. 976 Expecting service functions to deal with packets fragmented by the 977 SFC function might be onerous even when such fragmentation was 978 possible. Thus, at the very least, solutions need to pay attention 979 to the size cost of their approach. There may be alternative or 980 additional means available, although any solution needs to consider 981 the tradeoffs. 983 These considerations apply to any generic architecture that increases 984 the header size. There are also more specific MTU considerations: 985 Effects on Path MTU Discovery (PMTUD) as well as deployment 986 considerations. Deployments within a single administrative control 987 or even a single Data Center complex can afford more flexibility in 988 dealing with larger packets, and deploying existing mitigations that 989 decrease the likelihood of fragmentation or discard. 991 5.7. SFC OAM 993 Operations, Administration, and Maintenance (OAM) tools are an 994 integral part of the architecture. These serve various purposes, 995 including fault detection and isolation, and performance management. 996 For example, there are many advantages of SFP liveness detection, 997 including status reporting, support for resiliency operations and 998 policies, and an enhanced ability to balance load. 1000 Service Function Paths create a services topology, and OAM performs 1001 various functions within this service layer. Furthermore, SFC OAM 1002 follows the same architectural principles of SFC in general. For 1003 example, topological independence (including the ability to run OAM 1004 over various overlay technologies) and classification-based policy. 1006 We can subdivide the SFC OAM architecture in two parts: 1008 o In-band: OAM packets follow the same path and share fate with user 1009 packets, within the service topology. For this, they also follow 1010 the architectural principle of consistent policy identifiers, and 1011 use the same path IDs as the service chain data packets. Load 1012 balancing and SFC encapsulation with packet forwarding are 1013 particularly important here. 1015 o Out-of-band: reporting beyond the actual data plane. An 1016 additional layer beyond the data-plane OAM allows for additional 1017 alerting and measurements. 1019 This architecture prescribes end-to-end SFP OAM functions, which 1020 implies SFF understanding of whether an in-band packet is an OAM or 1021 user packet. However, service function validation is outside of the 1022 scope of this architecture, and application-level OAM is not what 1023 this architecture prescribes. 1025 Some of the detailed functions performed by SFC OAM include fault 1026 detection and isolation in a Service Function Path or a Service 1027 Function, verification that connectivity using SFPs is both effective 1028 and directing packets to the intended service functions, service path 1029 tracing, diagnostic and fault isolation, alarm reporting, performance 1030 measurement, locking and testing of service functions, validation 1031 with the control plane (see Section 5.2), and also allow for vendor- 1032 specific as well as experimental functions. SFC should leverage, and 1033 if needed extend relevant existing OAM mechanisms. 1035 5.8. Resilience and Redundancy 1037 As a practical operational requirement, any service chaining solution 1038 needs to be able to respond effectively, and usually very quickly, to 1039 failure conditions. These may be failures of connectivity in the 1040 network between SFFs, failures of SFFs, or failures of SFs. Per-SF 1041 state, as for example stateful-firewall state, is the responsibility 1042 of the SF, and not addressed by this architecture. 1044 Multiple techniques are available to address this issue. Solutions 1045 can describe both what they require and what they allow to address 1046 failure. Solutions can make use of flexible specificity of service 1047 function paths, if the SFF can be given enough information in a 1048 timely fashion to do this. Solutions can also make use of MAC or IP 1049 level redundancy mechanisms such as VRRP. Also, particularly for SF 1050 failures, load balancers co-located with the SFF or as part of the 1051 service function delivery mechanism can provide such robustness. 1053 Similarly, operational requirements imply resilience in the face of 1054 load changes. While mechanisms for managing (e.g., monitoring, 1055 instantiating, loading images, providing configuration to service 1056 function chaining control, deleting, etc.) virtual machines are out 1057 of scope for this architecture, solutions can and are aided by 1058 describing how they can make use of scaling mechanisms. 1060 6. Security Considerations 1062 This document does not define a new protocol and therefore creates no 1063 new security issues. 1065 Security considerations apply to the realization of this 1066 architecture. Such realization ought to provide means to protect the 1067 SFC-enabled domain and its borders against various forms of attacks, 1068 including DDoS attacks. Further, SFC OAM Functions need to not 1069 negatively affect the security considerations of an SFC-enabled 1070 domain. Additionally, all entities (software or hardware) 1071 interacting with the service chaining mechanisms need to provide 1072 means of security against malformed, poorly configured (deliberate or 1073 not) protocol constructs and loops. These considerations are largely 1074 the same as those in any network, particularly an overlay network. 1076 7. Contributors and Acknowledgments 1078 The editors would like to thank Sam Aldrin, Nicolas Bouthors, Linda 1079 Dunbar, Alla Goldner, Ken Gray, Barry Greene, Anil Gunturu, David 1080 Harrington, Shunsuke Homma, Dave Hood, Nagendra Kumar, Hongyu Li, 1081 Andrew Malis, Guy Meador III, Kengo Naito, Ron Parker, Reinaldo 1082 Penno, Naiming Shen, Xiaohu Xu, and Lucy Yong for a thorough review 1083 and useful comments. 1085 The initial version of this "Service Function Chaining (SFC) 1086 Architecture" document is the result of merging two previous 1087 documents, and this section lists the aggregate of authors, editors, 1088 contributors and acknowledged participants, all who provided 1089 important ideas and text that fed into this architecture. 1091 [I-D.boucadair-sfc-framework]: 1093 Authors: 1095 Mohamed Boucadair 1096 Christian Jacquenet 1097 Ron Parker 1098 Diego R. Lopez 1099 Jim Guichard 1100 Carlos Pignataro 1102 Contributors: 1104 Parviz Yegani 1105 Paul Quinn 1106 Linda Dunbar 1108 Acknowledgements: 1110 Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. 1111 Cheng, R. White, and B. Chatras for their review and 1112 comments. 1114 [I-D.quinn-sfc-arch]: 1116 Authors: 1118 Paul Quinn (editor) 1119 Joel Halpern (editor) 1121 Contributors: 1123 Puneet Agarwal 1124 Andre Beliveau 1125 Kevin Glavin 1126 Ken Gray 1127 Jim Guichard 1128 Surendra Kumar 1129 Darrel Lewis 1130 Nic Leymann 1131 Rajeev Manur 1132 Thomas Nadeau 1133 Carlos Pignataro 1134 Michael Smith 1135 Navindra Yadav 1137 Acknowledgements: 1139 The authors would like to thank David Ward, Abhijit Patra, 1140 Nagaraj Bagepalli, Darrel Lewis, Ron Parker, Lucy Yong and 1141 Christian Jacquenet for their review and comments. 1143 8. IANA Considerations 1145 [RFC Editor: please remove this section prior to publication.] 1147 This document has no IANA actions. 1149 9. Informative References 1151 [I-D.boucadair-sfc-framework] 1152 Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., 1153 Guichard, J., and C. Pignataro, "Service Function 1154 Chaining: Framework & Architecture", draft-boucadair-sfc- 1155 framework-02 (work in progress), February 2014. 1157 [I-D.ietf-sfc-problem-statement] 1158 Quinn, P. and T. Nadeau, "Service Function Chaining 1159 Problem Statement", draft-ietf-sfc-problem-statement-10 1160 (work in progress), August 2014. 1162 [I-D.quinn-sfc-arch] 1163 Quinn, P. and J. Halpern, "Service Function Chaining (SFC) 1164 Architecture", draft-quinn-sfc-arch-05 (work in progress), 1165 May 2014. 1167 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1168 Address Translator (Traditional NAT)", RFC 3022, January 1169 2001. 1171 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1172 NAT64: Network Address and Protocol Translation from IPv6 1173 Clients to IPv4 Servers", RFC 6146, April 2011. 1175 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1176 Translation", RFC 6296, June 2011. 1178 Authors' Addresses 1180 Joel Halpern (editor) 1181 Ericsson 1183 Email: jmh@joelhalpern.com 1184 Carlos Pignataro (editor) 1185 Cisco Systems, Inc. 1187 Email: cpignata@cisco.com