idnits 2.17.1 draft-quinn-sfc-arch-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 2, 2013) is 3859 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) == Unused Reference: 'RFC2119' is defined on line 494, but no explicit reference was found in the text Summary: 2 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 P. Quinn 3 Internet-Draft J. Guichard 4 Intended status: Standards Track S. Kumar 5 Expires: April 5, 2014 C. Pignataro 6 Cisco Systems, Inc. 7 N. Leymann 8 Deutsche Telekom 9 M. Smith 10 N. Yadav 11 Insieme Networks 12 K. Gray 13 T. Nadeau 14 Juniper Networks 15 October 2, 2013 17 Service Function Chaining (SFC) Architecture 18 draft-quinn-sfc-arch-01.txt 20 Abstract 22 This document describes an architecture for the creation of Service 23 Function Chains. It includes architectural concepts, principles, and 24 components used for the application of services in a network. This 25 document does not propose solutions or protocols. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 5, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 64 1.3. Service Function Chaining . . . . . . . . . . . . . . . . 4 65 2. Architectural Concepts . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Service Function Chains . . . . . . . . . . . . . . . . . 5 67 2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 8 68 2.3. Service Function Paths . . . . . . . . . . . . . . . . . . 8 69 3. Service Function Chaining Architecture . . . . . . . . . . . . 9 70 3.1. Architecture Principles . . . . . . . . . . . . . . . . . 9 71 3.2. Fundamental Components . . . . . . . . . . . . . . . . . . 9 72 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 78 Appendix A. Existing Service Deployments . . . . . . . . . . . . 17 79 Appendix B. Issues with Existing Deployments . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 82 1. Introduction 84 This document describes an architecture for the creation of Service 85 Function Chains. It includes architectural concepts, principles, and 86 components used for the application of services in a network. 88 1.1. Scope 90 The architecture described herein is assumed to be applicable to a 91 single network administrative domain. While it is possible for the 92 principals and architectural components to be applied to inter-domain 93 service function chains, these are left for future study. 95 1.2. Definition of Terms 97 Classification: Locally instantiated policy and customer/network/ 98 service profile matching of traffic flows for identification of 99 appropriate outbound forwarding actions. Classification is 100 performed by a classifier. 102 Network Locator (NL) : A name or address that uniquely identifies a 103 Service Node. Some examples are IPv4, IPv6 or MAC addresses. 105 Service Function (SF): A network or application based packet 106 treatment, application, compute or storage resource, used 107 singularly or in concert with other service functions within a 108 service chain to enable a service offered by an operator. 110 A non-exhaustive list of Service Functions includes: firewalls, 111 WAN and application acceleration, Deep Packet Inspection (DPI), 112 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID 113 injection, HTTP Header Enrichment functions, TCP optimizer, etc. 115 This document does not make any assumption in the OSI Layer on 116 which the Service Function acts; the exact definition of each 117 Service Function is deployment-specific. Further dissection into 118 greater granularity (e.g. for example, sub-functions of the 119 firewall service function) are out of scope for this document. 121 Service: An offering provided by an operator that is delivered using 122 one or more service functions. This may also be referred to as a 123 composite service. 125 Note: The term "service" is overloaded with varying definitions. 126 For example, to some a service is an offering composed of several 127 elements within the operators network whereas for others a 128 service, or more specifically a network service, is a discrete 129 element such as a firewall. Traditionally, these network services 130 host a set of service functions and have a network locator where 131 the service is delivered. 133 Service Node (SN): Physical or virtual element that hosts one or 134 more service functions and has one or more network locators 135 associated with it for reachability and service delivery. 137 Service Function Chain (SFC): The combination of a set of service 138 functions that are to be applied to selected traffic in a specific 139 order. The implied order may not be a linear progression as the 140 architecture will allow for nodes that copy to more than one 141 branch. 143 Service Chain (SC): A short form of Service Function Chain. 145 Service Traffic Recirculation (STR) : When traffic from a forward SN 146 is forwarded back through a previous SF within the SFC in order to 147 facilitate additional processing. Traffic may pass back and forth 148 between SNs many times before being ultimately forwarded. Network 149 operators or SNs must ensure that such configurations can handle 150 infinite packet looping either via explicit configuration, or by 151 enabling protocols that will. 153 1.3. Service Function Chaining 155 Service Function Chaining is a concept that implies more than just an 156 ordered set of service functions, rather it describes a method for 157 deploying service functions that enables not only ordering but 158 topological independence of those service functions. A basic service 159 function chain might simply utilize an existing overlay technology 160 along with service specific forwarding in the network to steer 161 traffic to the necessary service functions. However, additional 162 information that is shared across a subset of service functions 163 enables value added service functions and a richer service function 164 chain. For example, shared information, such as the results of a 165 classification function, may be passed to downstream service 166 functions to enable the offloading of service function processing. 167 As another example, sharing the information derived at one service 168 function to the rest in the service chain would not only obviate the 169 need to re-derive the same information but also simplifies the 170 service as re-deriving may be impractical (for example when the 171 packet may have been encrypted by an intermediate service function.) 173 2. Architectural Concepts 175 The following sections describe the core principles of a service 176 function chaining infrastructure. 178 2.1. Service Function Chains 180 In most networks services are constructed as a sequence of service 181 functions that represent a Service Function Chain. The collection of 182 available service functions within an administrative domain forms a 183 directed graph where the vertices represent an individual service 184 function and the edges form the network connecting those vertices as 185 partially represented in figure 1. 187 ,---. 188 / \ 189 +------->( 5 ) 190 | \ / 191 | `---' 192 | 193 | 194 ,---.+ ,---. ,---. 195 / \ / \ / \ 196 +---->( 2 +------->( 6 )+--------->( 8 ) 197 | \ / \ / \ / 198 | `-+-' `---' `---' 199 | | 200 | | 201 | ,-v-. 202 | / \ ,---. 203 ,-+-. ( 3 + / \ 204 / \ \ /+------------> 7 + 205 ( 1 ) `---'<--------------+ /| 206 \ / `---' | 207 `---' | 208 | 209 ,---. +------->---. 210 / \ / \ 211 ( 4 +---------------------------> 9 ) 212 \ / \ / 213 +--^' `---' 214 | | 215 +--+ 217 Figure 1: Service Function Chain Directed Graph 219 At a high level, service function chaining creates an abstracted view 220 of a service and specifies the set of required service functions as 221 well as the order in which they must be executed. Sub-graphs, from 222 the overall directed graph, define each Service Function Chain. 223 Service functions can be part of zero, one, or many service function 224 chains. 226 Service function chains can start from the origination point of the 227 service (i.e.: SN1 in Figure 1), or from any subsequent SN in the 228 graph. SNs can therefore become branches in the graph, with those 229 SFs performing forwarding decisions that move traffic to one or more 230 branches. It is important to understand that multiple branches 231 between nodes may exist, as with any network, and thus multicast as 232 well as unicast forwarding paradigms are valid. Service function 233 chains can have more than one terminus. 235 ,-+-. ,---. ,---. ,---. 236 / \ / \ / \ / \ 237 ( 1 )+----->( 2 )+------>( 6 )+------> ( 8 ) 238 \ / \ / \ / \ / 239 `---' `---' `---' `---' 241 ,---. 242 / \ 243 +----->( 2 ) 244 | \ / 245 | `---' 246 | + 247 ,-+-. | 248 / \ v 249 ( 1 ) ,---. ,---. ,---. 250 \ / / \ / \ / \ 251 `---' ( 3 )+---->( 7 )+----->( 9 ) 252 \ / \ / \ / 253 `---' `---' `---' 255 +---+ 256 | | 257 | | 258 | v 259 +---. 260 / \ 261 +-----> 4 ) 262 | \ /+ 263 | `---' | 264 | | 265 ,-+-. | 266 / \ | 267 ( 1 ) | ,---. 268 \ / | / \ 269 `---' +------>( 9 ) 270 \ / 271 `---' 273 Figure 2: Service Function Chain Sub-Graphs 275 The cases in which two or more service functions are co-resident on 276 the same service node and wish to implement some sort of internal, 277 inter-process or inter-VM messaging (communication behind the virtual 278 switching element) that is optimized for such an environment are out- 279 of-scope for this document. Together, these entities are expected to 280 handle the externalities of the chain (ingress header and egress 281 header handling) of the service function chain. 283 2.2. Service Function Chain Symmetry 285 Service Function Chains may be unidirectional or bidirectional. A 286 unidirectional service function chain requires traffic to be 287 forwarded through the ordered service functions in one direction (SF1 288 -> SF2 -> SF3), whereas a bidirectional service function chain 289 requires a symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1). 290 A hybrid service function chain has attributes of both bidirectional 291 and unidirectional service function chains: some service functions 292 require symmetric traffic, other service functions do not process 293 reverse traffic. 295 It is important to note that service function chains may point to 296 themselves, effectively forming recursive paths. This is called 297 Service Traffic Recirculation (STR). This therefore allows for loops 298 within the topology. As with normal networks, it is important that 299 nodes participating in the service path be able to detect and 300 mitigate loops. 302 2.3. Service Function Paths 304 Service function chains, when instantiated in the network, lead to 305 the selection of specific instances of service functions at various 306 SNs as well as the creation of the service topology using the network 307 locator of each individual SN. Thus, instantiation of the service 308 function chain results in the creation of a Service Function Path and 309 is used for forwarding packets through the service function chain. 310 In other words, Service Function Path is the instantiation of the 311 defined service function chain. 313 This abstraction enables the binding of service function chains to 314 specific service function instances based on a range of policy 315 attributes defined by the operator. For example, a service function 316 chain definition might specify that one of the service function 317 elements of the chain is a firewall. However, on the network, there 318 might exist a number of instances of the same firewall service 319 function (that is to say they enforce the same policy) and only when 320 the service function path is created is one of those firewall 321 instances selected. The selection can be based on a range of policy 322 attributes, ranging from simple to more elaborate criteria. 324 Classifiers can select the instances in the data path, offloading/ 325 distributing the service instance load distribution functionality and 326 improving the convergence time if there is a service instance 327 failure. criteria. 329 3. Service Function Chaining Architecture 331 3.1. Architecture Principles 333 Service function chaining is predicated on several key architectural 334 principles: 336 1. Topological independence: no changes to the underlay network 337 forwarding topology - implicit, or explicit - are needed to 338 deploy and invoke service functions. 340 2. Consistent policy identifiers: per-service policy leverages 341 policy identifier(s) that are consistent for the service function 342 chain. 344 3. Classification: traffic that satisfies some classification rules 345 may then be forwarded according to a specific SF chain. For 346 example, classification can be as simple as an explicit 347 forwarding entry that forwards all traffic from one address into 348 the service function chain that starts on some interface of a 349 forwarding entity. Multiple classification points are possible 350 within a service function chain (i.e. forming a service graph) 351 thus enabling changes/update to the path by functions. 353 4. Sharing of metadata/context: the network and service functions no 354 longer exist in separate silos. Metadata/context data can be 355 shared amongst all participating nodes. 357 5. No presumption of control point location. For example, the 358 original chain may be described by an external control point to 359 be *.* ---> SF1, where SF1 is a DPI device. This device can, in 360 turn, use an independent mechanism (out of scope for this 361 document) like IF-MAP or Diameter, to "pull the chain" based on 362 the classifier or some integral policy, and select an existing or 363 define a new branch (as described earlier in section 2.1). 365 3.2. Fundamental Components 367 Service function chaining can be divided into several components that 368 together form the basis of the architecture: 370 1. Service Node: This is the embodiment of a service function, and 371 can be instantiated within a physical or virtual element that 372 hosts one or more service functions. These entities may have one 373 or more network locators associated with them for reachability 374 and service delivery. 376 2. Service Functions as Resources: The concept of a service function 377 evolves: rather than being viewed as a bump in the wire, a 378 service function becomes a resource within a specified 379 administrative domain that is available for consumption. As 380 such, service functions have a network locator and a variable set 381 of attributes that describe the function offered. The 382 combination of locator and attributes are used to construct a 383 service function chain. 385 3. Classifier: A component that performs traffic classification. 386 Classification is the precursor to the start of a service 387 function path: traffic that matches classification criteria is 388 forwarded along a given service function path to realize the 389 specifications of a service function chain. The granularity of 390 classification varies based on operator requirements and device 391 capabilities. While initial classification at a network node 392 starts a service function path, subsequent classifications may 393 occur along the service function chain and further alter the 394 service function path. This re-classification may also update 395 the context information (see below). 397 4. Overlay Service Topology: A service topology is created to 398 interconnect the elements used to form the service function path. 399 This overlay topology is specific to the service function path: 400 it is created for the express purpose of steering the service 401 packets through the service functions and optionally passing 402 context data. The overlay topology can be constructed using any 403 existing transport, for example IP, MPLS, etc. 405 5. Control plane: The service function chaining control plane is 406 responsible for constructing the service function paths: 407 translating the service function chains to the forwarding paths 408 and propagating path information to participating nodes - network 409 and service - to achieve requisite forwarding behavior to 410 construct the service overlay. For instance, a service function 411 chain construction may be static - using specific service 412 function instances, or dynamic - choosing service explicit 413 function instances at the time of delivering traffic to the 414 service function. In service function chaining, service 415 functions are resources; the control plane advertises their 416 capabilities, availability and location. The control plane is 417 also responsible for the creation of the context (see below). 418 The control plane may exist within distributed routing elements 419 as in traditional networks, or in a centralized configuration. 421 6. Shared context data: Sharing context data allows the network to 422 provide network-derived information to the service functions, 423 service function to service function information exchange and the 424 sharing of service-derived information to the network. This 425 component is optional. Service function chaining infrastructure 426 enables the exchange of this shared context along the service 427 function path. The shared context serves several key functions 428 within the architecture: 430 * Allows elements that typically operate as ships-in-the-night 431 to exchange information 433 * Encodes information about the network and/or data for post- 434 service forwarding 436 * Creates an identifier used for policy binding by service 437 functions 439 Context information can be derived in several ways: 441 * External sources 443 * Network node classification 445 * Service function classification 447 7. Resource Control: The SFC system may be responsible for managing 448 all resources necessary for the SFC components to function. This 449 includes network constraints used to plan and choose the network 450 path(s) between service nodes, characteristics of the nodes 451 themselves such as memory, number of virtual interfaces, routes, 452 etc..., and configuration of the service functions running on the 453 service nodes. 455 The figure below provides a high level view of the components: 457 +-------+ 458 +---------->|control|<----------+ 459 | |plane | | 460 +-------------->| +---+---+ | 461 | | ^ | 462 | | | | 463 v v v v 464 +----------+ ,---. ,---. ,---. +----------+ 465 |classifier|+---> / \+------->/ \+-------->/ \+-------->|classifier| 466 | | ( 1 )<-----+( 2 )<------+( 3 )<-------+| | 467 +----------+ \ / \ / \ / +----------+ 468 `---' `---' `---' 470 Figure 3: Service Function Chaining Architecture 472 4. Summary 474 Service function chains enable composite services that are 475 constructed from one or more service functions. This document 476 provides a standard architecture, including architectural concepts, 477 principles, and components, for the creation of Service function 478 chains. 480 5. Security Considerations 482 This document does not define a new protocol and therefore creates no 483 new security issues. 485 6. Acknowledgments 487 The authors would like to thank David Ward, Abhijit Patra, Nagaraj 488 Bagepalli, Christian Jacquenet for their review and comments. 490 7. References 492 7.1. Normative References 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 7.2. Informative References 499 [NSCprob] "Network Service Chaining Problem Statement", . 503 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 504 Address Translator (Traditional NAT)", RFC 3022, 505 January 2001. 507 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 508 NAT64: Network Address and Protocol Translation from IPv6 509 Clients to IPv4 Servers", RFC 6146, April 2011. 511 Appendix A. Existing Service Deployments 513 Existing service insertion and deployment techniques fail to address 514 new challenging requirements raised by modern network architectures 515 and evolving technologies such as multi-tenancy, virtualization, 516 elasticity, and orchestration. Networks, servers, storage 517 technologies, and applications, have all undergone significant change 518 in recent years: virtualization, network overlays, and orchestration 519 have increasingly become adopted techniques. All of these have 520 profound effects on network and services design. 522 As network service functions evolve, operators are faced with an 523 array of form factors - virtual and physical - as well as with a 524 range of insertion methods that often vary by vendor and type of 525 service. 527 Such existing services are deployed using a range of techniques, most 528 often associated with topology or forwarding modifications. For 529 example, firewalls often rely on layer-2 network changes for 530 deployment: a VLAN is created for the "inside" interface, and another 531 for the "outside" interface. In other words, a new L2 segment was 532 created simply to add a service function. In the case of server load 533 balancers, policy routing is often used to ensure traffic from 534 server's returns to the load balancer. As with the firewall example, 535 the policy routing serves only to ensure that the network traffic 536 ultimately flows to the service function(s). 538 The network-centric information (e.g. VLAN) is not limited to 539 insertion; this information is often used as a policy identifier on 540 the service itself. So, on a firewall, the layer-2 segment 541 identifies the local policy to be selected. If more granular policy 542 discrimination is required, more network identifiers must be created 543 either per-hop, or communicated consistently to all services. 545 Appendix B. Issues with Existing Deployments 547 Due to the tight coupling of network and service function resources 548 in existing networks, adding or removing service functions is a 549 complex task that is fraught with risk and is tied to 550 operationalizing topological changes leading to massively static 551 configuration procedures for network service delivery or update 552 purposes. The inflexibility of such deployments limits (and in many 553 cases precludes) dynamic service scaling (both horizontal and 554 vertical) and requires hop-by-hop configuration to ensure that the 555 correct service functions, and sequence of service functions are 556 traversed. 558 A non-exhaustive list of existing service deployment and insertion 559 techniques as well as the issues associated with each may be found in 560 [NSCprob]. 562 Authors' Addresses 564 Paul Quinn 565 Cisco Systems, Inc. 567 Email: paulq@cisco.com 569 Jim Guichard 570 Cisco Systems, Inc. 572 Email: jguichar@cisco.com 574 Surendra Kumar 575 Cisco Systems, Inc. 577 Email: smkumar@cisco.com 579 Carlos Pignataro 580 Cisco Systems, Inc. 582 Email: cpignata@cisco.com 584 Nic Leymann 585 Deutsche Telekom 587 Email: n.leymann@telekom.de 589 Michael Smith 590 Insieme Networks 592 Email: michsmit@insiemenetworks.com 594 Navindra Yadav 595 Insieme Networks 597 Email: nyadav@insiemenetworks.com 598 Ken Gray 599 Juniper Networks 601 Email: kgray@juniper.net 603 Thomas Nadeau 604 Juniper Networks 606 Email: tnadeau@juniper.net