idnits 2.17.1 draft-merged-sfc-architecture-00.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 (July 3, 2014) is 3585 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-07 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: January 4, 2015 Cisco 6 July 3, 2014 8 Service Function Chaining (SFC) Architecture 9 draft-merged-sfc-architecture-00 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 January 4, 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 . . . . . . . . . . . . . . . . . 7 62 3. Architecture Principles . . . . . . . . . . . . . . . . . . . 8 63 4. Core SFC Architecture Components . . . . . . . . . . . . . . 9 64 4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 10 65 4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 11 66 4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 11 67 4.3.1. Transport Derived SFF . . . . . . . . . . . . . . . . 12 68 4.4. Network Forwarder (NF) . . . . . . . . . . . . . . . . . 12 69 4.5. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.6. Classification . . . . . . . . . . . . . . . . . . . . . 13 71 4.7. Re-Classification and Branching . . . . . . . . . . . . . 14 72 4.8. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 14 73 4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 15 74 4.10. Resource Control . . . . . . . . . . . . . . . . . . . . 15 75 5. The Role of Policy . . . . . . . . . . . . . . . . . . . . . 16 76 6. Additional Architectural Concepts . . . . . . . . . . . . . . 16 77 6.1. Loop Prevention . . . . . . . . . . . . . . . . . . . . . 16 78 6.2. Load Balancing Considerations . . . . . . . . . . . . . . 16 79 6.3. MTU and Fragmentation Considerations . . . . . . . . . . 18 80 6.4. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 6.5. Operational (and Manageability) Considerations . . . . . 19 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 8. Contributors and Acknowledgments . . . . . . . . . . . . . . 19 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 87 10.2. Informative References . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 This document describes an architecture used for the creation and 93 ongoing maintenance of Service Function Chains (SFC) in a network. 94 It includes architectural concepts, principles, and components. 96 An overview of the issues associated with the deployment of end-to- 97 end service function chains, ordered sets of instances of service 98 functions that create a composite service and the subsequent 99 "steering" of traffic flows through said service functions, is 100 described in [I-D.ietf-sfc-problem-statement]. 102 This architecture presents a model addressing the problematic aspects 103 of existing service deployments, including topological independence 104 and configuration complexity. 106 Service function chains enable composite services that are 107 constructed from one or more service functions. This document 108 provides a standard architecture, including architectural concepts, 109 principles, and components, for service function chains. 111 1.1. Scope 113 This document defines a framework to enforce Service Function 114 Chaining (SFC) with minimum requirements on the physical topology of 115 the network. The proposed solution allows for differentiated 116 forwarding: packets are initially classified at the entry point of an 117 SFC-enabled network, and are then forwarded according to the ordered 118 set of SF functions that need to be activated to process these 119 packets in the SFC-enabled domain. 121 This document does not make any assumption on the deployment context. 122 The proposed framework covers both fixed and mobile networks. 124 The architecture described herein is assumed to be applicable to a 125 single network administrative domain. While it is possible for the 126 architectural principles and components to be applied to inter-domain 127 SFCs, these are left for future study. 129 1.2. Assumptions 131 The following assumptions are made: 133 o Not all SFs can be characterized with a standard definition in 134 terms of technical description, detailed specification, 135 configuration, etc. 137 o There is no global nor standard list of SFs enabled in a given 138 administrative domain. The set of SFs varies as a function of the 139 service to be provided and according to the networking 140 environment. 142 o There is no global nor standard SF chaining logic. The ordered 143 set of SFs that need to be activated to deliver a given 144 connectivity service is specific to each administrative entity. 146 o The chaining of SFs and the criteria to invoke some of them are 147 specific to each administrative entity that operates the SF- 148 enabled network (also called administrative domain). 150 o SF chaining logic and related policies should not be exposed 151 outside a given administrative domain. 153 o Several SF chaining logics can be simultaneously enforced within 154 an administrative domain to meet various business requirements. 156 o No assumption is made on how FIBs and RIBs of involved nodes are 157 populated. 159 o How to bind the traffic to a given SF chaining is policy-based. 161 1.3. Definition of Terms 163 Network Service: An offering provided by an operator that is 164 delivered using one or more service functions. This may also be 165 referred to as a composite service. The term "service" is used 166 to denote a "network service" in the context of this document. 168 Note: The term "service" is overloaded with varying definitions. 169 For example, to some a service is an offering composed of 170 several elements within the operators network whereas for others 171 a service, or more specifically a network service, is a discrete 172 element such as a firewall. Traditionally, these network 173 services host a set of service functions and have a network 174 locator where the service is hosted. 176 Classification: Locally instantiated policy and customer/network/ 177 service profile matching of traffic flows for identification of 178 appropriate outbound forwarding actions. 180 Classifier: An element that performs Classification. 182 Service Function (SF): A function that is responsible for specific 183 treatment of received packets. A Service Function can act at 184 the network layer or other OSI layers. A Service Function can 185 be a virtual instance or be embedded in a physical network 186 element. One of multiple Service Functions can be embedded in 187 the same network element. Multiple instances of the Service 188 Function can be enabled in the same administrative domain. 190 One or more Service Functions can be involved in the delivery of 191 added-value services. A non-exhaustive list of Service 192 Functions includes: firewalls, WAN and application acceleration, 193 Deep Packet Inspection (DPI),a LI (Lawful Intercept) module, 194 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 195 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, 196 TCP optimizer, etc. 198 An SF may be SFC encapsulation aware, that is it receives, and 199 acts on information in the SFC encapsulation, or unaware in 200 which case data forwarded to the service does not contain the 201 SFC encapsulation. 203 SFC Network Forwarder (NF): SFC network forwarders provide network 204 connectivity for service function forwarders (SFF) and service 205 functions (SF). 207 Service Function Forwarder (SFF): A service function forwarder is 208 responsible for delivering traffic received from the SFC network 209 forwarder to one or more connected service functions via 210 information carried in the SFC encapsulation. 212 Service Node (SN): Element within an SFC-enabled domain that hosts 213 one or more service functions and has one or more network 214 locators associated with it for reachability and service 215 delivery. 217 Service Function Chain (SFC): A service Function chain defines an 218 ordered set of service functions that must be applied to packets 219 and/or frames selected as a result of classification. The 220 implied order may not be a linear progression as the 221 architecture allows for nodes that copy to more than one branch. 222 The term service chain is often used as shorthand for service 223 function chain. 225 Service Function Path (SFP): The instantiation of an SFC in the 226 network. Packets follow a service function path from a 227 classifier through the requisite service functions 229 SFC-enabled Domain: A network or region of a network that implements 230 SFC. An SFC-enabled Domain is limited to a single network 231 administrative domain. 233 SFC Proxy: Removes and inserts SFC encapsulation on behalf of an 234 SFC-unaware service function. SFC proxies are logical elements. 236 2. Architectural Concepts 238 The following sections describe the foundational concepts of service 239 function chaining and the SFC architecture. 241 Service Function Chaining enables the creation of composite services 242 that consist of an ordered set of Service Functions (SF) that must be 243 applied to packets and/or frames selected as a result of 244 classification. Each SF is referenced using an identifier that is 245 unique within an administrative domain. No IANA registry is required 246 to store the identity of SFs. 248 Service Function Chaining is a concept that provides for more than 249 just the application of an ordered set of SFs to selected traffic; 250 rather, it describes a method for deploying SFs in a way that enables 251 dynamic ordering and topological independence of those SFs as well as 252 the exchange of metadata between participating entities. 254 2.1. Service Function Chains 256 In most networks services are constructed as a sequence of SFs that 257 represent an SFC. At a high level, an SFC creates an abstracted view 258 of a service and specifies the set of required SFs as well as the 259 order in which they must be executed. Graphs, as illustrated in 260 Figure 1, define each SFC. SFs can be part of zero, one, or many 261 SFCs. A given SF can appear one time or multiple times in a given 262 SFC. 264 SFCs can start from the origination point of the service function 265 graph (i.e.: node 1 in Figure 1), or from any subsequent SF node in 266 the graph. SFs may therefore become branching nodes in the graph, 267 with those SFs selecting edges that move traffic to one or more 268 branches. SFCs can have more than one terminus. 270 ,-+-. ,---. ,---. ,---. 271 / \ / \ / \ / \ 272 ( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) 273 \ / \ / \ / \ / 274 `---' `---' `---' `---' 276 ,-+-. ,---. ,---. ,---. ,---. 277 / \ / \ / \ / \ / \ 278 ( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 ) 279 \ / \ / \ / \ / \ / 280 `---' `---' `---' `---' `---' 282 ,-+-. ,---. ,---. ,---. ,---. 283 / \ / \ / \ / \ / \ 284 ( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 ) 285 \ / \ / \ / \ / \ / 286 `---' `---' `---' `---' `---' 288 Figure 1: Service Function Chain Graphs 290 The architecture allows for two or more SFs to be co-resident on the 291 same service node. In these cases, some implementations may choose 292 to use some form of internal inter-process or inter-VM messaging 293 (communication behind the virtual switching element) that is 294 optimized for such an environment. Implementation details of such 295 mechanisms are considered out-of-scope for this document. 297 2.2. Service Function Chain Symmetry 299 SFCs may be unidirectional or bidirectional. A unidirectional SFC 300 requires that traffic be forwarded through the ordered SFs in one 301 direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a 302 symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1). A hybrid 303 SFC has attributes of both unidirectional and bidirectional SFCs; 304 that is to say some SFs require symmetric traffic, whereas other SFs 305 do not process reverse traffic. 307 SFCs may contain cycles; that is traffic may need to traverse more 308 than once one or more SFs within an SFC. Solutions will need to 309 ensure suitable disambiguation for such situations. 311 2.3. Service Function Paths 313 When an SFC is instantiated into the network it is necessary to 314 select the specific instances of SFs that will be used, and to create 315 the service topology for that SFC using SF's network locator. Thus, 316 instantiation of the SFC results in the creation of a Service 317 Function Path (SFP) and is used for forwarding packets through the 318 SFC. In other words, an SFP is the instantiation of the defined SFC. 320 This abstraction enables the binding of SFCs to specific instances, 321 or set of like instances of SFs based on a range of policy attributes 322 defined by the operator. For example, an SFC definition might 323 specify that one of the SF elements is a firewall. However, on the 324 network, there might exist a number of instances of the same firewall 325 (that is to say they enforce the same policy) and only when the SFP 326 is created is one of those firewall instances selected. The 327 selection can be based on a range of policy attributes, ranging from 328 simple to more elaborate criteria. 330 3. Architecture Principles 332 Service function chaining is predicated on several key architectural 333 principles: 335 1. Topological independence: no changes to the underlay network 336 forwarding topology - implicit, or explicit - are needed to 337 deploy and invoke SFs or SFCs. 339 2. Plane separation: dynamic provisioning of SFPs is separated from 340 packet handling operations (e.g., packet forwarding). 342 3. Classification: traffic that satisfies classification rules is 343 forwarded according to a specific SFC. For example, 344 classification can be as simple as an explicit forwarding entry 345 that forwards all traffic from one address into the SFC. 346 Multiple classification points are possible within an SFC (i.e. 347 forming a service graph) thus enabling changes/update to the SFC 348 by SFs. 350 4. Shared Metadata: Metadata/context data can be shared amongst SFs 351 and classifiers, between SFs, and between external systems and 352 SFs (e.g. orchestration). 354 Generally speaking, the metadata can be thought of as providing, 355 and sharing the result of classification (that occurs with the 356 SFC domain, or external to it) along an SFP. For example, an 357 external repository might provide user/subscriber information to 358 a service chain classifier. This classifier in turn imposes that 359 information in the SFC encapsulation for delivery to the 360 requisite SFs. The SFs in turn utilize the user/subscriber 361 information for local policy decisions. 363 5. Service definition independence: the technical characterization 364 of each SF is not required to design the SFC architecture and SFC 365 data plane operations. Consequently, no IANA registry is 366 required to store the list of SFs. 368 6. Service function chain independence: The creation, modification, 369 or deletion of a service chain have no impact on other service 370 chains. 372 7. Heterogeneous control/policy points: allowing SFs to use 373 independent mechanisms (out of scope for this document) like IF- 374 MAP or Diameter to populate and resolve local policy and (if 375 needed) local classification criteria. 377 4. Core SFC Architecture Components 379 At a very high level, the logical architecture of an SFC-Enabled 380 Domain comprises: 382 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 . +--------------+ +------------------~~~ 384 . | Service | SFC | Service +---+ +---+ 385 . |Classification| Encapsulation | Function |sf1|...|sfn| 386 +---->| Function |+---------------->| Path +---+ +---+ 387 . +--------------+ +------------------~~~ 388 . SFC-enabled Domain 389 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Figure 2: Service Function Chain Architecture 393 The following sub-sections provide details on each logical component 394 that form the basis of the SFC architecture. A detailed overview of 395 how each of these architectural components interact is provided in 396 Figure 3: 398 +----------------+ +----------------+ 399 | SFC-aware | | SFC-unaware | 400 |Service Function| |Service Function| 401 +-------+--------+ +-------+--------+ 402 | | 403 SFC Encapsulation No SFC Encapsulation 404 | | 405 | SFC Encapsulation +---------+ 406 +------------------+ +-------------|SFC Proxy| 407 \ / +---------+ 408 +-------+--------+ 409 | SF Forwarder | 410 | (SFF) | 411 +-------+--------+ 412 | 413 SFC Encapsulation 414 | 415 +-------+--------+ 416 | SFC Network | 417 | Forwarder (NF) | 418 +----------------+ 419 | 420 ... SFC-enabled Domain ... 421 | 422 Network Overlay Transport 423 | 424 _,....._ 425 ,-' `-. 426 / `. 427 | Network | 428 `. / 429 `.__ __,-' 430 `'''' 432 Figure 3: Service Function Chain Architecture Components 434 4.1. SFC Encapsulation 436 The SFC encapsulation enables service function path selection and the 437 sharing of metadata/context information. 439 The SFC encapsulation provides explicit information used to identify 440 the SFP. However, the SFC encapsulation is not a transport 441 encapsulation itself: it is not used to forward packets within the 442 network fabric. The SFC encapsulation therefore, relies on an outer 443 network transport. Transit nodes -- such as router and switches -- 444 simply forward SFC encapsulated packets based on the outer (non-SFC) 445 encapsulation. 447 One of the key architecture principles of SFC is that the SFC 448 encapsulation remain transport independent and as such any network 449 transport protocol may be used to carry the SFC encapsulation. 451 4.2. Service Function (SF) 453 The concept of an SF evolves; rather than being viewed as a bump in 454 the wire, an SF becomes a resource within a specified administrative 455 domain that is available for consumption as part of a composite 456 service. SFs send/receive data from one or more SFFs. SFC aware SFs 457 receive this data with the SFC encapsulation. 459 While the SFC architecture defines a new encapsulation - the SFC 460 encapsulation - and several logical components for the construction 461 of SFCs, existing SF implementations may not have the capabilities to 462 act upon or fully integrate with the new SFC encapsulation. In order 463 to provide a mechanism for such SFs to participate in the 464 architecture a logical SFC proxy function is defined. The SFC proxy 465 acts a gateway between the SFC encapsulation and SFC unaware SFs. 466 The integration of SFC-unaware service function is discussed in more 467 detail in the SFC proxy section. 469 4.3. Service Function Forwarder (SFF) 471 The SFF is responsible for forwarding packets and/or frames received 472 from an NF to one or more SFs associated with a given SFF using 473 information conveyed in the SFC encapsulation. 475 The collection of SFFs creates a service plane using an overlay in 476 which SFC-aware SFs, as well as SFC-unaware SFs reside. Within this 477 service plane, the SFF component connects different SFs that form a 478 service function path. 480 SFFs maintain the requisite SFP forwarding information. SFP 481 forwarding information is associated with a service path identifier 482 that is used to uniquely identify an SFP. The service forwarding 483 state enables an SFF to identify which SF of a given SFC should be 484 applied as traffic flows through the associated SFP. Each SFF need 485 only maintain SFC forwarding information that is relevant locally. 486 The SFC forwarding state at all SFFs collectively represents the SFPs 487 associated with each SFC in the SFC domain. 489 The SFF component has the following primary responsibilities: 491 1. SFP forwarding : Traffic arrives at an SFF from one or more NFs. 492 The SFF determines the appropriate SF the traffic should be 493 forwarded to via information contained in the SFC encapsulation. 494 Post-SF, the traffic is returned to the SFF, and if needed 495 forwarded to another SF associated with that SFF. If there is 496 another hop in the SFP, the SFF, encapsulates the traffic in the 497 appropriate network transport and delivers it to the NF for 498 delivery to the next SFF along the path. 500 2. Terminating SFPs : An SFC is completely executed when traffic has 501 traversed all required SFs in a chain. When traffic arrives at 502 the SFF after the last SF has finished servicing it, SFF fails to 503 find the next SF or knows from the service forwarding state that 504 the SFC is complete. SFF removes the SFC encapsulation and 505 delivers the packet to an NF for forwarding. 507 3. Maintaining flow state: In some cases, the SFF may be stateful. 508 It creates flows and stores flow-centric information. When 509 traffic arrives after being steered through an SFC-unaware SF, 510 the SFF must perform re-classification of traffic to determine 511 the SFP. A state-full SFF simplifies such classification to a 512 flow lookup. 514 4.3.1. Transport Derived SFF 516 Service function forwarding, as described above, directly depends 517 upon the use of the service path information contained in the SFC 518 encapsulation. Existing implementations may not be able to act on 519 the SFC encapsulation. These platforms may opt to use a transport 520 mechanism which carries the service path information from the SFC 521 encapsulation, and information derived from the SFC encapsulation, to 522 build transport information. 524 This results in the same architectural behavior and meaning for 525 service function forwarding and service function paths. It is the 526 responsibility of the control components to ensure that the transport 527 path executed in such a case is fully aligned with the path 528 identified by the information in the service chaining encapsulation. 530 4.4. Network Forwarder (NF) 532 This component is responsible for performing the overlay 533 encapsulation/de-capsulation and forwarding of packets on the overlay 534 network. NF forwarding may consult the SFC encapsulation or the 535 inner payload of an incoming packet only in the necessary cases to 536 achieve optimal forwarding in the network. 538 4.5. SFC Proxy 540 In order for the SFC architecture to support SFC-unaware SF's (e.g., 541 legacy service nodes), an optional, logical SFC proxy function may be 542 used. This proxy removes the SFC encapsulation and then uses a local 543 attachment circuit to deliver packets to SFC unaware SFs. 545 Architecturally, the SFC Proxy along with an SFC-unaware Service 546 Function make up an SF. More specifically: 548 For traffic received from a NF or SFF, destined to an SF, the SFC 549 proxy: 551 o Removes the SFC encapsulation from SFC encapsulated packets and/or 552 frames. 554 o Identifies the required SF to be applied based on information 555 carried in the SFC encapsulation. 557 o Selects the appropriate outbound local attachment circuit through 558 which the next SF for this SFP is reachable. This information is 559 derived from the SFC encapsulation or from local configuration. 560 Examples of a local attachment circuit include, but are not 561 limited to, VLANs, IP-in-IP, L2TPv3, GRE, VXLAN. 563 o Forwards the original payload via a local attachment circuit to 564 the appropriate SF. 566 When traffic is returned from the SF: 568 o Applies the required SFC encapsulation. The determination of the 569 encapsulation details may be inferred by the local attachment 570 circuit through which the packet and/or frame was received, or via 571 packet classification, or other local policy. In some cases, 572 packet-ordering or modification by the SF may necessitate 573 additional classification in order to re-apply the correct SFC 574 encapsulation. 576 o Imposes the appropriate SFC encapsulation based on the 577 identification of the SFC to be applied. 579 Alternatively, a service provider may decide to exclude legacy nodes 580 from an SDC domain. 582 4.6. Classification 584 Traffic that satisfies classification criteria is directed into an 585 SFP and forwarded to the requisite service function(s). 586 Classification is handled by a logical service classification 587 function, and initial classification occurs at the edge of the SFC 588 domain. The granularity of the initial classification is determined 589 by the capabilities of the classifier and the requirements of the SFC 590 policy. For instance, classification might be relatively coarse: all 591 packets from this port are directed into SFP A, or quite granular: 592 all packets matching this 5-tuple are subject to SFP B. 594 As a consequence of the classification decision, the appropriate SFC 595 encapsulation is imposed on the data prior to forwarding along the 596 SFP. 598 4.7. Re-Classification and Branching 600 The SFC architecture supports reclassification (or non-initial 601 classification) as well. As packets traverse an SFP, 602 reclassification may occur - typically performed by a classification 603 function co-resident with a service function. Reclassification may 604 result in the selection of a new SFP, an update of the associated 605 metadata, or both. This is referred to as "branching". 607 For example, an initial classification results in the selection of 608 SFP A: DPI_1 --> SLB_8. However, when the DPI service function is 609 executed "attack" traffic is detected at the application layer. 610 DPI_1 reclassifies the traffic as "attack" and alters the service 611 path, to SFP B, to include a firewall for policy enforcement: 612 dropping the traffic: DPI_1 --> FW_4. In this simple example, the 613 DPI service function reclassified the traffic based on local 614 application layer classification capabilities (that were not 615 available during the initial classification step). 617 4.8. SFC Control Plane 619 The SFC control plane is responsible for constructing the SFPs; 620 translating the SFCs to the forwarding paths and propagating path 621 information to participating nodes - network and service - to achieve 622 requisite forwarding behavior to construct the service overlay. For 623 instance, an SFC construction may be static - using specific SF 624 instances, or dynamic - choosing service explicit SF instances at the 625 time of delivering traffic to the SF. In SFC, SFs are resources; the 626 control plane manages and communicates their capabilities, 627 availability and location in fashions suitable for the transport and 628 SFC operations in use. The control plane is also responsible for the 629 creation of the context (see below). The control plane may be 630 distributed (using new or existing control plane protocols), or be 631 centralized, or a combination of the two. 633 The SFC control plane provides the following functionality: 635 1. An administrative domain wide view of all available service 636 function resources as well as the network locator through which 637 they are reachable. 639 2. Uses SFC policy to construct service function chains, and 640 associated service function paths. 642 3. Selection of specific SF instances for a requested SFC, either 643 statically (using specific SF instances) or dynamically (using 644 service explicit SF instances at the time of delivering traffic 645 to the SF). 647 4. Provides requisite SFC data plane information to the SFC 648 architecture components, most notably the SFF. 650 5. Allocation of metadata associated with a given SFP and 651 propagation of metadata syntax to relevant SF instances and/or 652 SFC encapsulation-proxies or their respective policy planes. 654 4.9. Shared Metadata 656 Sharing metadata allows the network to provide network-derived 657 information to the SFs, SF-to-SF information exchange and the sharing 658 of service-derived information to the network. This component is 659 optional. SFC infrastructure enables the exchange of this shared 660 data along the SFP. The shared metadata serves several possible 661 roles within the SFC architecture: 663 o Allows elements that typically operate as ships-in-the-night to 664 exchange information. 666 o Encodes information about the network and/or data for post- 667 service forwarding. 669 o Creates an identifier used for policy binding by SFs. 671 o Context information can be derived in several ways: 673 * External sources 675 * Network node classification 677 * Service function classification 679 4.10. Resource Control 681 The SFC system may be responsible for managing all resources 682 necessary for the SFC components to function. This includes network 683 constraints used to plan and choose the network path(s) between 684 service nodes, characteristics of the nodes themselves such as 685 memory, number of virtual interfaces, routes, etc..., and 686 configuration of the SFs running on the service nodes. 688 5. The Role of Policy 690 Much of the behavior of service chains is driven by operator and 691 customer policy. This architecture is structured to isolate the 692 policy interactions from the data plane and control logic. 694 Specifically, it is assumed that service chaining control plane 695 creates the service paths. The service chaining data plane is used 696 to deliver the classified packets along the service chains to the 697 intended Service Functions. 699 Policy, in contrast interacts with the system in other places. 700 Policies, and policy engines, may monitor service functions to decide 701 if additional (or fewer) instances of services are needed. When 702 applicable, those decisions may in turn result in interactions which 703 direct the control logic to change the service chain placement or the 704 packet classification rules. 706 Similarly, operator service policy, often managed by operational or 707 business support systems (OSS or BSS), will frequently determine what 708 service functions are available. Depending upon operator 709 preferences, these policies may also determine which sequences of 710 functions are valid and to be used or made available. 712 The offering of service chains to customers, and the selection of 713 which service chain a customer wishes to use are driven by a 714 combination of operator and customer policies using appropriate 715 portals in conjunction with the OSS and BSS tools. These selections 716 then drive the service chaining control logic which in turn 717 establishes the appropriate packet classification rules. 719 6. Additional Architectural Concepts 721 6.1. Loop Prevention 723 This SFC architecture is predicated on topological independence from 724 the underlying forwarding topology. Consequently, a service topology 725 is created by Service Function Paths. Within this service topology, 726 this methods need to support intentioanl, limited loops as described 727 above while detecting, and either resolving or preferably preventing 728 indefinite loops. 730 6.2. Load Balancing Considerations 732 Supporting function elasticity and high-availability shouldn't overly 733 complicate SFC or lead to unnecessary scalability problems. 735 In the simplest case, where there is only a single function in the 736 chain (the next hop is either the destination address of the flow or 737 the appropriate next hop to that destination), one could argue that 738 there may be no need for SFC. 740 In the case where the classifier is separate from the single function 741 or a function at the terminal address may need sub-prefix or per 742 subscriber metadata, we would have a single chain (the metadata 743 changes but the SFC chain does not), regardless of the number of 744 potential terminal addresses for the flow. This is the case of the 745 simple load balancer. See Figure 4. 747 +---+ +---++--->web server 748 source+-->|sff|+-->|sf1|+--->web server 749 +---+ +---++--->web server 751 Figure 4: Simple Load Balancing 753 By extrapolation, in the case where intermediary functions within a 754 chain had similar "elastic" behaviors, we do not need separate chains 755 to account for this behavior - as long as the traffic coalesces to a 756 common next-hop after the point of elasticity. 758 In Figure 5, we have a chain of five service functions between the 759 traffic source and it's destination. 761 +---+ +---+ +---+ +---+ +---+ +---+ 762 |sf2| |sf2| |sf2| |sf4| |sf4| |sf4| 763 +---+ +---+ +---+ +---+ +---+ +---+ 764 | | | | | | 765 +-----+-----+ +-----+-----+ 766 | | 767 + + 768 +---+ +---+ +---+ +---+ +---+ 769 source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination 770 +---+ +---+ +---+ +---+ +---+ 771 + + + 772 | | | 773 +---+ +---+ +---+ 774 |sf1| |sf3| |sf5| 775 +---+ +---+ +---+ 777 Figure 5: Load Balancing 779 This would be represented as one service function path: 780 sf1->sf2->sf3->sf4->sf5. The SFF is a logical element, which may be 781 made up of one or multiple components. In this architecture, the SFF 782 handle load distribution based on policy. 784 6.3. MTU and Fragmentation Considerations 786 Modern systems are expected to be able to cope gracefully with MTU 787 issues that may arise from the application of additional headers to a 788 packet. Adopting the recommendations of other WG's who have recently 789 tackled this issue (e.g. [RFC6830]), there are several mechanisms 790 for dealing with packets that are too large to transit the path from 791 the point of service classification to the last function (SFn) in the 792 SFP. 794 The solution to these issues should result not adversely affect 795 service nodes. A recommendation of a specific mechanism and/or its 796 implementation is beyond the scope of this document. 798 6.4. SFC OAM 800 Operations, Administration, and Maintenance (OAM) tools are an 801 integral part of the architecture. These serve various purposes, 802 including fault detection and isolation, and performance management. 803 For example, there are many advantages of SFP liveness detection, 804 including status reporting, support for resiliency operations and 805 policies, and an enhanced ability to load balance. 807 Service Function Paths create a services topology, and OAM performs 808 various functions within this service layer. Furthermore, SFC OAM 809 follows the same architectural principles of SFC in general. For 810 example, topological independence (including the ability to run OAM 811 over various overlay technologies) and classification-based policy. 813 We can subdivide the SFC OAM architecture in two parts: 815 o In-band: OAM packets run in-band fate-sharing with the service 816 topology. For this, they also follow the architectural principle 817 of consistent policy identifiers, and use the same path IDs as the 818 service chain data packets. 820 o Out-of-band: reporting beyond the actual dataplane. An additional 821 layer beyond the data-plane OAM, allows for additional alerting 822 and measurements. 824 Some of the detailed functions performed by SFC OAM include fault 825 detection, continuity checks, connectivity verification, service path 826 tracing, diagnostic and fault isolation, alarm reporting, performance 827 measurement, locking and testing of service functions, and also allow 828 for vendor-specific as well as experimental functions. SFC should 829 leverage, and if needed extend relevant existing OAM mechanisms. 831 6.5. Operational (and Manageability) Considerations 833 To be provided. 835 7. Security Considerations 837 This document does not define a new protocol and therefore creates no 838 new security issues. 840 Security considerations apply to the realization of this 841 architecture. Such realization ought to provide means to protect the 842 SFC-enabled domain and its borders against various forms of attacks, 843 including DDoS attacks. Additionally, Service Nodes need to provide 844 means of security against malformed, poorly configured (deliberate or 845 not) protocol constructs and loops. 847 8. Contributors and Acknowledgments 849 This "Service Function Chaining (SFC) Architecture" document is the 850 result of merging two previous documents, and this section lists the 851 aggregate of authors, editors, contributors and acknowledgements, all 852 who provided important ideas and text that fed into this 853 architecture. 855 [I-D.boucadair-sfc-framework]: 857 Authors: 859 Mohamed Boucadair 861 Christian Jacquenet 863 Ron Parker 865 Diego R. Lopez 867 Jim Guichard 869 Carlos Pignataro 871 Contributors: 873 Parviz Yegani 875 Paul Quinn 877 Linda Dunbar 879 Acknowledgements: 881 Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. 882 Cheng, R. White, and B. Chatras for their review and 883 comments. 885 [I-D.quinn-sfc-arch]: 887 Authors: 889 Paul Quinn (editor) 891 Joel Halpern (editor) 893 Contributors: 895 Puneet Agarwal 897 Andre Beliveau 899 Kevin Glavin 901 Ken Gray 903 Jim Guichard 905 Surendra Kumar 907 Darrel Lewis 909 Nic Leymann 911 Rajeev Manur 913 Thomas Nadeau 915 Carlos Pignataro 917 Michael Smith 919 Navindra Yadav 921 Acknowledgements: 923 The authors would like to thank David Ward, Abhijit Patra, 924 Nagaraj Bagepalli, Darrel Lewis, Ron Parker, Lucy Yong and 925 Christian Jacquenet for their review and comments. 927 9. IANA Considerations 929 This document creates no new requirements on IANA namespaces 930 [RFC5226]. 932 10. References 934 10.1. Normative References 936 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 937 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 938 May 2008. 940 10.2. Informative References 942 [I-D.boucadair-sfc-framework] 943 Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., 944 Guichard, J., and C. Pignataro, "Service Function 945 Chaining: Framework & Architecture", draft-boucadair-sfc- 946 framework-02 (work in progress), February 2014. 948 [I-D.ietf-sfc-problem-statement] 949 Quinn, P. and T. Nadeau, "Service Function Chaining 950 Problem Statement", draft-ietf-sfc-problem-statement-07 951 (work in progress), June 2014. 953 [I-D.quinn-sfc-arch] 954 Quinn, P. and J. Halpern, "Service Function Chaining (SFC) 955 Architecture", draft-quinn-sfc-arch-05 (work in progress), 956 May 2014. 958 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 959 Address Translator (Traditional NAT)", RFC 3022, January 960 2001. 962 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 963 NAT64: Network Address and Protocol Translation from IPv6 964 Clients to IPv4 Servers", RFC 6146, April 2011. 966 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 967 Translation", RFC 6296, June 2011. 969 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 970 Locator/ID Separation Protocol (LISP)", RFC 6830, January 971 2013. 973 Authors' Addresses 975 Joel Halpern (editor) 976 Ericsson 978 Email: jmh@joelhalpern.com 980 Carlos Pignataro (editor) 981 Cisco Systems, Inc. 983 Email: cpignata@cisco.com