idnits 2.17.1 draft-ietf-sfc-dc-use-cases-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (August 10, 2016) is 2814 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining S. Kumar 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational M. Tufail 5 Expires: February 11, 2017 Citi 6 S. Majee 7 F5 Networks 8 C. Captari 9 Telstra Corporation 10 S. Homma 11 NTT 12 August 10, 2016 14 Service Function Chaining Use Cases In Data Centers 15 draft-ietf-sfc-dc-use-cases-05 17 Abstract 19 Data center operators deploy a variety of layer 4 through layer 7 20 service functions in both physical and virtual form factors. Most 21 traffic originating, transiting, or terminating in the data center is 22 subject to treatment by multiple service functions. 24 This document describes use cases that demonstrate the applicability 25 of Service Function Chaining (SFC) within a data center environment 26 and provides SFC requirements for data center centric use cases, with 27 primary focus on Enterprise data centers. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 11, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 4 66 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Traffic Types . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. North-South Traffic . . . . . . . . . . . . . . . . . . . 6 69 3.2.1. Sample north-south service function chains . . . . . 8 70 3.2.2. Sample north-south SFC description . . . . . . . . . 8 71 3.3. East-West Traffic . . . . . . . . . . . . . . . . . . . . 9 72 3.3.1. Sample east-west service function chains . . . . . . 10 73 3.3.2. Sample east-west SFC description . . . . . . . . . . 10 74 3.4. Multi-tenancy . . . . . . . . . . . . . . . . . . . . . . 11 75 3.5. SFCs in data centers . . . . . . . . . . . . . . . . . . 11 76 3.6. Inter-datacenter SFCs . . . . . . . . . . . . . . . . . . 13 77 3.6.1. Methods for inter-datacenter SFCs . . . . . . . . . . 13 78 3.6.2. Considerations for inter-datacenter SFCs . . . . . . 16 79 4. Drawbacks Of Existing Service Chaining Methods . . . . . . . 17 80 5. General Requirements . . . . . . . . . . . . . . . . . . . . 20 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 87 10.2. Informative References . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 Data centers -- enterprise, cloud or service provider -- deploy 93 service nodes at various points in the network topology. These nodes 94 provide a range of service functions and the set of service functions 95 hosted at a given service node may overlap with service functions 96 hosted at other service nodes. 98 Often, data center topologies follow a hierarchical design with core, 99 aggregation, access and virtual access layers of network devices. In 100 such topologies service nodes are deployed either in the aggregation 101 or access layers. More recent data center designs utilize a folded 102 CLOS topology to improve scale, performance and resilience while 103 ensuring deterministic hop count between end points. In such spine- 104 leaf topologies, service nodes are often deployed at compute or 105 virtual access layers as well as physical access layers. 107 In large scale networks, such as carrier networks, there are many 108 data centers distributed across large geographies. Each data center 109 deploys service nodes and service functions of varied types on a 110 range of hardware. 112 The primary purpose of deploying service functions at different 113 points in the network is to apply service functions to different 114 types of traffic: 116 a. Traffic originating at physical or virtual workloads in the data 117 center and destined to physical or virtual workloads in the data 118 center; for example three-tiered deployment of applications: web, 119 application, and database tiers, with traffic flowing between the 120 adjacent tiers. 122 b. Traffic originating at a location remote to the data center and 123 destined to physical or virtual workloads in the data center; for 124 example traffic originating at a branch or regional office, 125 destined to one of the primary data centers in an Enterprise, or 126 traffic originating at one of the tenants of a Service Provider 127 destined to that tenants applications in the Service Provider 128 data center. Yet another variant of this type of traffic 129 includes third party vendors and partners of the data center 130 operator remotely accessing their applications in the data center 131 over secure connections. 133 c. Traffic that is originating at a location remote to the data 134 center and destined to a location remote to the data center but 135 transiting through the data center; for example traffic 136 originating at a mobile device destined to servers in the 137 Internet routed through the data center in order to service it. 139 Servicing of traffic involves directing the traffic through a series 140 of service functions that may be located at different places in the 141 network or within a single device connected to the network or any 142 combination in between. Delivery of multiple service functions in a 143 sequence, in a datacenter or among multiple data centers, thus 144 creates many requirements on the overall service delivery 145 architecture. Such architectures may be termed service function 146 chaining architectures while the list of service functions applied to 147 the traffic is a Service Function Chain (SFC). 149 1.1. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 2. Definition Of Terms 157 Additional terms are defined in [I-D.ietf-sfc-problem-statement], 158 which the reader may find helpful. 160 End Point (EP): A device or an application that is the ultimate 161 origination or destination entity of specific traffic. Mobile 162 devices, desktop or server computers and applications running on 163 them are some examples. 165 Workload (WL): A physical or virtual machine performing a dedicated 166 task that consumes compute, storage, network and other resources. 167 This may include web servers, database servers, storage servers 168 and a variety of application servers. 170 Service Function (SF): A function that is responsible for specific 171 treatment of received packets. A Service Function can act at the 172 network layer or other OSI layers. A Service Function can be a 173 virtual instance or be embedded in a physical network element. 174 One of multiple Service Functions can be embedded in the same 175 network element. Multiple instances of the Service Function can 176 be enabled in the same administrative domain. A non-exhaustive 177 list of Service Functions includes: firewalls, WAN and 178 application acceleration, Deep Packet Inspection (DPI), server 179 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID 180 injection, HTTP Header Enrichment functions, TCP optimizer, etc. 182 Service Node (SN): A virtual or physical device that hosts one or 183 more service functions, which can be accessed via the network 184 location associated with it. 186 Classifier (CF): The entity responsible for selecting traffic as 187 well as a service chain, based on policy, and forwarding the 188 selected traffic on the service chain. 190 Deep Packet Inspection (DPI): Service Function that performs 191 stateful inspection of traffic, identification of applications 192 and policy enforcement, among others. 194 Intrusion Detection and/or Prevention System (IDS/IPS): DPI SN with 195 additional capabilities to recognize malware and other threats 196 and take corrective action. 198 Edge Firewall (EdgeFW): SN hosting service functions such as VPN, 199 DHCP, NAT, IP-Audit, Protocol Inspection, DPI etc., with policies 200 primarily focusing on threats external to the data center. 202 Segment Firewall (SegFW): SN hosting a subset of the functions in 203 the EdgeFW not including VPN and is deployed to protect traffic 204 crossing segments, such as VLANs. 206 Application Firewall (AppFW): Service Function that isolates traffic 207 within a segment or protects from application specific threats. 208 This falls into the same class as DPI but deployed much closer to 209 the applications. It is an intra-segment firewall. 211 Application Delivery Controller (ADC): Service Function that 212 distributes traffic across a pool of servers (applications) for 213 efficient resource utilization, application scaling as well as to 214 provide high availability among others. 216 Web Optimization Control (WOC): SN hosting service functions to 217 optimize the use of WAN link bandwidth, improve effective user 218 throughput and latencies leading to overall improved user 219 experience. WOC includes various optimizers such as compression, 220 de-duplication, congestion control, application specific 221 optimizers, etc. WOC requires peers at either end of the WAN 222 link to perform optimizations. The scope of this document is 223 limited to the DC side of the WAN link. 225 Monitoring (MON): SN hosting service functions to obtain operational 226 visibility into the network to characterize network and 227 application performance, troubleshoot performance issues, 228 optimize resource utilization, etc. 230 Note: The above definitions are generalized. Actual implementations 231 may vary in scope and in a lot of cases the actual service functions 232 hosted on SNs may overlap. For instance, DPI function is not only 233 implemented as a standalone service function but is also implemented 234 in EdgeFWs. Likewise EdgeFw functions, such as VPN, are implemented 235 in routers. The terms used are representative of common usage and 236 not absolute deployment. 238 3. Use Cases 240 The following sections highlight some of the most common data center 241 use case scenarios and are in no way exhaustive. 243 3.1. Traffic Types 245 IT assets in an enterprise are consolidated into few data centers 246 located centrally. This consolidation stems from regulatory 247 compliance regarding security, control on the enterprise assets, 248 operational cost savings, disaster recovery strategies, etc. The 249 data center resources are accessible from any geographic location 250 whether inside or outside the enterprise network. Further, 251 enterprise data centers may be organized along the lines of 252 businesses, with each business treated as a tenant, thereby 253 supporting multi-tenancy. 255 Service provider data centers have similar requirements as the 256 enterprise. Data centers may be distributed regionally and globally 257 to support the needs of their tenants. Multi-tenancy underlines 258 every consideration in such data centers: resources and assets are 259 organized & managed on tenant boundaries, policies are organized 260 along tenant boundaries, traffic is segregated and policies enforced 261 on tenant boundaries, etc. This is true in all "as a service" 262 models: IaaS, PaaS and SaaS. 264 This leads to two primary types of traffic: North-South and East- 265 West, each with different service requirements. 267 3.2. North-South Traffic 269 North-South traffic originates from outside the data center and is 270 typically associated with users - onsite, remote and VPN - conducting 271 their jobs. The traffic may also be associated with consumers 272 accessing news, email, social media and other websites. This traffic 273 is typically destined to applications or resources hosted in the data 274 centers. Increasing adoption of BYOD and social networking 275 applications requires traffic be analyzed, application and users be 276 identified, transactions be authorized, and at the same time security 277 threats be mitigated or eliminated. To this end, various service 278 functions, as illustrated in Figure 1, are deployed in different SNs 279 and in many instances of those SNs, at various topological locations 280 in the network. The SNs are selected based on the policy required 281 for the specific use case. 283 [ End Point ] --------+ 284 | 285 | 286 | 287 Border 288 +------ Router 289 | | 290 | | 291 +------- WOC 292 | | 293 | | 294 +------ EdgeFW 295 | | 296 | | 297 +------- MON 298 | | 299 | | 300 +------- ADC 301 | | 302 | | 303 +------ AppFW 304 | 305 | 306 | 307 +-------- [ Workload ] 309 Figure 1: Service functions applied to North-South traffic 311 Figure 1 shows the ordered list of SNs, from top to bottom, 312 representing the flow of traffic from End Point to Workload and vice 313 versa. Traffic does not always strictly flow through all the SNs in 314 that order. Traffic flows through various permutations, of the 315 subsets, of the SNs. The connections from each of the service nodes 316 to every other service node (as depicted by the vertical line to the 317 left) represents the network topology required to achieve such 318 traffic flows. Each permutation represents a service function chain. 320 Certain ordering of the SNs naturally exists due to the nature of the 321 functions applied. For instance, WOC is not effective on VPN traffic 322 - requires VPN termination prior to WOC. Likewise EdgeFW may not be 323 effective on WOC traffic. Vendor implementations of SNs enable 324 choices for various deployments and ordering. For instance EdgeFW 325 detects the presence of WOC through TCP options or explicit 326 configuration and hence WOC may even be deployed on the traffic that 327 has passed through the EdgeFW. Constructing service function chains 328 in the underlay network thus requires complex topology. 330 3.2.1. Sample north-south service function chains 332 SFC-1. EdgeFW 334 SFC-2. EdgeFW : ADC 336 SFC-3. EdgeFW : ADC : AppFW 338 SFC-4. WOC : EdgeFW : ADC : AppFW 340 SFC-5. WOC : EdgeFW : MON : ADC : AppFW 342 3.2.2. Sample north-south SFC description 344 Sample service chains numbered SFC-1 through SFC-5 capture the 345 essence of services required on the north-south traffic. 347 SFC-1: This represents the simplest of use cases where a remote or 348 mobile worker accesses a specific data center server. Traffic 349 comes into the data center on VPN and is terminated on the 350 EdgeFW. EdgeFW subjects the traffic to its policies, which may 351 in turn select other service functions such as DPI, IPS/IDS, 352 hosted on the EdgeFW. As an alternative deployment, some of 353 these service functions may be hosted outside the EdgeFW and 354 reachable via VLAN segments. EdgeFW policy permitting, traffic 355 is allowed to its destination. 357 SFC-2: This is an extension of SFC-1. Unlike SFC-1, traffic is 358 destined to a data center application that is front-ended by an 359 ADC. The EdgeFW performs its function as before and the traffic 360 is allowed, policy permitting. This traffic reaches its virtual 361 destination, the ADC. ADC, based on local policy, which includes 362 among other things predictors to select the real destination, 363 determines the appropriate application instance. ADCs are 364 stateful and ensure the return traffic passes through them by 365 performing source NAT. Since many applications require the 366 original source address, ADC preserves the original address in 367 extension headers of the HTTP protocol. Traffic is then 368 forwarded on to the ultimate destination - the real application 369 workload. 371 SFC-3: This extends SFC-2. The segment where the application server 372 resides may be shared with other applications and resources. To 373 segregate these applications and resources further, fine grain 374 policies may be required and are enforced via a security 375 appliance such as the AppFW. As a consequence AppFW first 376 services the traffic from the load balancer before it is 377 forwarded to its ultimate destination, the application server. 379 SFC-4: This is a variant of SFC-3 with WOC being part of the chain. 380 This represents the use case where users at a branch office 381 access the data center resources. The WOC SNs located at either 382 end of the WAN optimize the traffic first. The WOC located in 383 the datacenter requires a mechanism to steer traffic to it while 384 not deployed inline with the traffic. This is achieved either 385 with PBR or VLAN stitching. WOC treated traffic is subject to 386 firewall policies, which may lead to the application of SFs such 387 as protocol inspection, DPI, IDS/IPS and then forwarded to its 388 virtual destination, the ADC. 390 SFC-5: This is similar to SFC-4. An additional service - MON, is 391 used to collect and analyze traffic entering and leaving the data 392 center. This monitoring and analysis of traffic helps maintain 393 performance levels of the infrastructure to achieve service level 394 agreements, particularly in SP data centers. 396 3.3. East-West Traffic 398 This is the predominant traffic in data centers today. Server 399 virtualization has led to the new paradigm where virtual machines can 400 migrate from one server to another across the datacenter. This 401 explosion in east-west traffic is leading to newer data center 402 network fabric architectures that provide consistent latencies from 403 one point in the fabric to another. 405 The key difference with east-west from the north-south traffic is in 406 the kind of threats and the security needs thereof. Unlike north- 407 south traffic where security threats may come from outside the data 408 center, any threat to this traffic comes from within the data center. 410 +-- ADC1 --- MON1 --- AppFW1 --- Workload1(Web) 411 / 412 SegFW ---- ADC2 --- MON2 --- AppFW2 --- Workload2(App) 413 \ 414 +-- ADC3 --- MON3 --- AppFW3 --- Workload3(DB) 416 Figure 2: Service functions applied to East-West traffic 418 Service functions applied on the east-west traffic is captured in a 419 generalized fashion in Figure 2. ADCs, although shown as isolated 420 SNs in each of the tiers, is often consolidated into a smaller number 421 of ADC SNs shared among the different tiers. Virtual IP addresses or 422 VIPs in such ADCs represent the individual ADC instances. Flows are 423 terminated at the VIPs and re-initiated towards the load balanced 424 workloads. 426 As an example, HTTP GET request arriving at ADC1 is load balanced on 427 to a webserver pool represented as Workload1. In order to respond to 428 the GET request, Workload1 generates traffic to an application server 429 in a pool represented as Workload2 through ADC2, which load balances 430 the webserver initiated traffic. Likewise, the application server, 431 as part of processing the webserver's request generates traffic to a 432 DB server pool represented as Workload3 through ADC3, which load 433 balances the application server initiated traffic. The traffic 434 arriving at different ADCs, in this example, can be arriving at 435 different VIPs, instead, each corresponding to its tier but belonging 436 to the same ADC. In this sense, traffic flow across the tiers is VIP 437 centric as opposed to device instance. 439 Traffic traversing between the ADC and the selected server in each 440 tier, is subject to monitoring and one or more application firewalls 441 specializing in different kinds and aspects of threats. These again 442 can be shared just as the ADC due to steering mechanisms although it 443 adds complexity in network configuration. 445 3.3.1. Sample east-west service function chains 447 SFC-6. SegFW : ADC : MON : AppFW 449 3.3.2. Sample east-west SFC description 451 SFC-6: In a typical three tiered architecture, requests coming to a 452 webserver trigger interaction with application servers, which in 453 turn trigger interaction with the database servers. It has to be 454 noted that each of these tiers are deployed in their own segments 455 or zones for isolation, optimization and security. SegFW 456 enforces the security policies between the tiers and facilitates 457 isolation at the segment level or address space re-use via NAT 458 deployment. ADC provides the distribution, scale and resiliency 459 to the applications while the AppFW protects and isolates traffic 460 within the segment in addition to enforcing application specific 461 security policies. Finally, monitoring service enables 462 visibility into application traffic, which in turn is used to 463 maintain application performance levels. 465 3.4. Multi-tenancy 467 Multi-tenancy is relevant in both enterprise as well as service 468 provider data centers although it is the primary differentiator 469 between service provider (SP) and enterprise datacenter. Enterprises 470 treat organizations or business units within the enterprise as 471 tenants and thus require tenant aware service models. 473 Multi-tenant service delivery is achieved in two primary ways: a) SNs 474 themselves are tenant aware - every SN is built to support multiple 475 tenants. b) SN instances are dedicated for each tenant. In both the 476 cases, the SP manages the SNs. 478 To support multi-tenant aware service functions or SNs, traffic being 479 serviced by a service function chain has to be identified by a tenant 480 identifier. A tenant identifier has to be carried along with the 481 traffic to be serviced. It is typical of tenant assets to be 482 deployed in an isolated layer2 or layer3 domain such as VLAN, VXLAN 483 or VRF. It has to be noted that the SNs themselves maybe deployed in 484 different domains to suit the deployment needs of the SP and hence 485 using the domain in which the SN is deployed is not an option. 486 Although such a model is feasible it removes the deployment 487 flexibility for the service providers. 489 3.5. SFCs in data centers 491 [ EP/WL ] 492 | 493 | 494 | 495 Border - 496 +------ Router | 497 | | 498 | | 499 +------- WOC A 500 | | C S 501 | | C F 502 +------ EdgeFW E C 503 | | S s 504 | | S 505 +------- MON 506 | | 507 | | | 508 +------ SegFW - 509 / | \ | 510 / | \ 511 +-------+ | +-------+ A 512 | | | P 513 | | | P 514 ADC ADC ADC L 515 | | | I S 516 | | | C F 517 MON MON MON A C 518 | | | T s 519 | | | I 520 AppFW AppFW AppFW O 521 | | | N 522 | | | 523 | | | | 524 [ WL/Web ] [ WL/App ] [ WL/DB ] - 526 Figure 3: Service function chains in data center 528 Figure 3 shows the global view of SFCs applied in an enterprise or 529 service provider data center. At a high level the SFCs can be 530 broadly categorized into two types: 532 1. Access SFCs 534 2. Application SFCs 535 Access SFCs are focused on servicing traffic entering and leaving the 536 data center while Application SFCs are focused on servicing traffic 537 destined to applications. 539 Service providers deploy a single "Access SFC" and multiple 540 "Application SFCs" for each tenant. Enterprise data center operators 541 on the other hand may not have a need for Access SFCs depending on 542 the size and requirements of the enterprise. Where such Access SFCs 543 are indeed needed, such as large enterprises, the operator may deploy 544 a bare minimum Access SFC instead. Such simple Access SFCs include 545 WOC and VPN SFs to support the branch and mobile user traffic while 546 at the same time utilizing the security policies in the application 547 SFCs. The latter is the case in de-perimetrized network 548 architectures where security policies are enforced close to the 549 resources and applications as opposed to the WAN edge. 551 3.6. Inter-datacenter SFCs 553 In carrier networks, operators may deploy multiple data centers 554 dispersed geographically. Each data center may host different types 555 of service functions. For example, latency sensitive or high usage 556 service functions are deployed in regional data centers while other 557 latency tolerant, low usage service functions are deployed in global 558 or central data centers. In such deployments, SFCs may span multiple 559 data centers and enable operators to deploy services in a flexible 560 and inexpensive way. These SFCs are referred to as the inter- 561 datacenter SFCs in this draft. 563 3.6.1. Methods for inter-datacenter SFCs 565 The following are two methods to construct inter-datacenter SFCs: 567 1. Inter-datacenter SFCs with multiple SFC domains 569 2. Inter-datacenter SFCs with a single SFC domain 570 -----+ 571 [ Workload ]----+ | incoming 572 | V traffic 573 .--. 574 ( )-. 575 .' ) 576 ( Internet ) 577 ( -' 578 '-( ) 579 '---' 580 | 581 +----|--------------------+ 582 | | SFC domain | 583 | | +---------+ | 584 | +-----+ | | | 585 | | C F |---+ DC | | 586 | +-----+ | | | 587 | | +---------+ | 588 +----|--------------------+ 589 | 590 +----|--------------------+ 591 | | SFC domain | 592 | | +---------+ | 593 | +-----+ | | | 594 | | C F |---+ DC | | 595 | +-----+ | | | 596 | | +---------+ | 597 +----|--------------------+ 598 | 599 A | 600 outgoing | +-----------[ End Point ] 601 traffic +------ 603 Figure 4: Inter-datacenter SFC with multiple SFC domains 605 Figure 4 shows inter-datacenter SFC with multiple SFC domains. In 606 this method, services are provided by SFCs spanning multiple 607 independent SFC domains. SFC management is limited to each domain: 608 control plane is constrained to its SFC domain and SFCs are 609 fragmented and initiated in each SFC domain. If both data centers 610 are located in-line, a method of forwarding packets between data 611 centers is required. 613 -----+ 614 [ Workload ]----+ | incoming 615 | V traffic 616 .--. 617 ( )-. 618 .' ) 619 ( Internet ) 620 ( -' 621 '-( ) 622 '---' 623 | 624 +-----+ 625 +------------| C F |-------------+ 626 | SFC domain +-----+ | 627 | | | 628 | +-------------+ | 629 | | | | 630 | | D C | | 631 | | | | 632 | +-------------+ | 633 | | | 634 | | | 635 | | | 636 | +-------------+ | 637 | | | | 638 | | D C | | 639 | | | | 640 | +-------------+ | 641 | | | 642 | +-----+ | 643 +------------| C F |-------------+ 644 +-----+ 645 | 646 A | 647 outgoing | +-----------[ End Point ] 648 traffic +------ 650 Figure 5: Inter-datacenter SFC with single SFC domains 652 Figure 5 shows inter datacenter SFC with a single SFC domain. In 653 this method, services are provided across multiple data centers, 654 which are connected with virtualized paths and grouped into a single 655 SFC domain. 657 In multiple SFC domain case, it is simple to control and manage the 658 SFC domain. However, it is difficult to hand over context data 659 between data centers, whether context data are conveyed out of band - 660 in the control plane or, in band - with traffic. In addition, the 661 cost of classification is high, as it is performed twice in each SFC 662 domain - once in each direction. On the other hand, in the single 663 SFC domain case, it is easy to hand over context data between data 664 centers, but control of SFC domains becomes complex as integrated 665 operation across multiple data centers is required. 667 3.6.2. Considerations for inter-datacenter SFCs 669 Inter-datacenter SFC must consider many design aspects, two important 670 among them are : 672 1. Handing over context data 674 2. Multiple classification points 676 Handing over context data : Metadata sharing among SFC components 677 enables many use cases and services. If context data cannot be 678 passed across data centers, some services provided by SFC would 679 be restricted. For example, it is difficult to create SFCs 680 across multiple data centers because service functions cannot 681 simply share information, with each other, between the data 682 centers. 684 Multiple classification points : In a large SFC domain containing 685 multiple datacenters distributed over large geographies, 686 classification of incoming traffic and outgoing traffic may 687 happen at different points, depending on the deployment model. 688 If classification of incoming traffic and outgoing traffic are 689 forced to happen at the same point, as shown in Figure 6, all 690 traffic may traverse long distances leading to inefficient 691 resource consumption and increased latencies. 693 695 +----+ 696 [ EP ]---------------+ CF +-----------------[ WL ] 697 ++--++ 698 | | 699 +--------+ +--------+ 700 | | 701 +----+----+ +----+----+ 702 | | | | 703 | DC | | DC | 704 | | | | 705 +---------+ +---------+ 707 <-- long distance --> 709 ========================================================= 711 713 [ EP ] [ DC ] [ CF ] [ DC ] [ WL ] 715 *--------------------+ 716 | 717 +----------+ 718 | 719 +---------------------+ 720 | 721 +-----------> 723 |<-------->| 724 traffic turn back 726 Figure 6: Inter-datacenter SFC with single classification point 728 4. Drawbacks Of Existing Service Chaining Methods 730 The above use cases are realized in a traditional fashion and are not 731 viable in the evolving hybrid data centers with virtual and physical 732 assets. The following are some of the obvious short comings of 733 existing SFC methods exposed by the above use cases. 735 DB-1. Policy based purely on VLANs is no longer sufficient. 736 Connecting SNs to each other to construct a service chain 737 thus makes it very static and removes deployment flexibility. 738 As can be seen from the sample north-south service chains, a 739 large number of VLANs not only have to be stitched in a 740 certain fashion to achieve a basic SFC, it is simply not 741 flexible to share the SNs among different SFCs as even simple 742 sharing among a few SNs becomes intractable from basic 743 configuration perspective let alone future changes or 744 manageability aspects. 746 DB-2. Traffic does not always have to be steered through all the 747 SNs of a traditional VLAN stitched service chain. In 748 Figure 1, traffic from the border router is not always 749 necessary to flow through the WOC as remote or mobile worker 750 may not have a WOC peer deployed. Connecting multiple VLANs 751 among service nodes to overcome to achieve this only 752 aggravates the problem of deployment and manageability. 753 Truly, there exists a need for dynamically determining the 754 next sub SFC at such branching points to avoid forcing all 755 traffic through the same SFC. 757 DB-3. Virtual environments require the virtual SNs be migration 758 capable just like the compute workloads. As a consequence it 759 is simply not feasible to continue VLAN stitching in the 760 hybrid data centers. Every time a virtual SN migrates, such 761 as the AppFW in Figure 1 and Figure 2, the operator has to 762 ensure the VLANs are provisioned in the destination. 763 Further, stretching the VLANs across the network may not be 764 an option for the operator or even worse the virtual SN may 765 be L3 hop away from the previous SN. 767 DB-4. Policy Based Routing (PBR) can be used to move traffic to 768 SNs. Although it provides a much better granularity than 769 VLAN stitching it suffers from the requirement to configure 770 such policies all along the path to the SNs. In Figure 1, if 771 WOC is multiple hops away from the border router, all network 772 elements in between border router and WOC need to be 773 configured with consistent policies. 775 DB-5. Source NAT (SNAT) is required by some SNs, such as ADC in 776 Figure 1, in order to ensure traffic sent to the load 777 balanced servers pass through the ADC in reverse direction. 778 However, SNAT removes the ability to detect the originator of 779 the traffic. Using HTTP extension header to pass originator 780 information is not only an overhead but addresses only one 781 specific protocol. 783 DB-6. Static service chains do not allow for modifying the SFCs as 784 they require the ability to add SNs or remove SNs to scale up 785 and down the service capacity. Likewise the ability to 786 dynamically pick one among the many SN instance is not 787 available. For instance, WOC must scale to support the high 788 data rate of traffic flowing to the data center. Likewise, 789 AppFWs must scale up to not impact the workload throughput. 790 Further they may be required to scale within tenant 791 boundaries. 793 DB-7. Static SFCs constructed over the under lay network cannot 794 pass metadata to the SNs. Border Router in Figure 1 cannot 795 pass policy based tags derived locally at the start of the 796 SFC all the way through the SFC. Such metadata is necessary 797 to enforce consistent security policies across the network, 798 as one example. 800 DB-8. In multi-tenant deployments, the segment on which the SN is 801 deployed may not correspond to the segment assigned to the 802 tenant in which the workloads are hosted. In Figure 2, AppFW 803 may be deployed on a different segment than the Workload. As 804 a consequence, it is not viable to derive the tenant segment 805 simply based on the tag associated with the incoming traffic 806 at the AppFW. This ultimately prevents the ability to have 807 the same SN serve multiple tenants. Forcing the SN to be on 808 the same segment as the tenants' workload limits deployment 809 flexibility. 811 DB-9. Traffic may originate in a physical or virtual network or 812 transit these networks before being delivered to the SNs for 813 servicing. The following is very complex to achieve with the 814 existing SFC mechanism, primarily due to very conflicting 815 nature of their environments: physical and static vs. virtual 816 and dynamic. 818 A. Physical SN servicing traffic originating in the virtual 819 access network. 821 B. Virtual SN servicing traffic originating in the physical 822 network. 824 DB-10. Although SNs are purpose built service appliances, it is 825 neither a requirement nor an indication of how service 826 functions are implemented in emerging data centers with 827 commodity compute and storage capabilities. AppFW in 828 Figure 1, for instance, may be built and deployed as a 829 virtual SN. Further, SFCs are limited to exclusively 830 physical or virtual SNs and not a mix. This excludes the 831 ability to combine the benefits offered by physical SNs with 832 the flexibility and agility of the virtual SNs. The EdgeFW 833 in Figure 1, for instance, may be a purpose built SN to take 834 advantage of SFs implemented in hardware while the AppFW may 835 be a virtual SN deployed to be close to the virtual workload 836 and may even move with the workload in the virtual 837 environment. 839 DB-11. Troubleshooting is one of the predominant issues plaguing SFC 840 deployments. The reasons range from misconfiguration at 841 different elements in the network that are responsible for 842 directing traffic to the service nodes, to, tracking the 843 traffic paths starting from the point of entry into the DC to 844 the point of exit to the application through various SNs. 845 When desired services are not effective on certain traffic, 846 determining the reason is simply not viable in a large scale 847 deployment. Figure 3 provides a view of the complexity in 848 terms of the permutations of the SFCs, their paths in the 849 network and the configuration in the network elements 850 required and managed for proper operation. 852 5. General Requirements 854 The above use cases and the drawbacks thereof lead to the following 855 general requirements in today's evolving hybrid datacenters to apply 856 SFCs to traffic. 858 GR1. SFC polices MUST be applicable at the edges - network elements 859 as well as the workloads. 861 GR2. SFC policies MUST be applicable to either Ingress or Egress 862 traffic at network elements as well as workloads. 864 GR3. SFC MUST support virtual as well as physical SNs. 866 GR4. SFC SHOULD support the ability to mix virtual and physical SNs 867 in the same SFC. 869 GR5. SFC SNs MUST be deployable L2 or L3 hop away from the SFC 870 application points - network elements or workloads. 872 GR6. SFC traffic MUST be allowed to follow paths not constrained by 873 the underlying static network topology. 875 GR7. SFC SNs MUST be able identify tenant traffic without being 876 tied to the underlying topology 878 GR8. SFCs MUST support the ability to pass metadata among the SNs 879 or between the SNs and the network elements. 881 GR9. A composite SFC SHOULD be achievable by way of joining sub 882 SFCs, branching to sub SFCs where necessary. 884 GR10. SFCs SHOULD NOT require SNAT inside the SFs to attract traffic 885 back to them 887 GR11. SFCs SHOULD have the ability to choose SN instances 888 dynamically, prior to forwarding traffic to them. 890 GR12. An OAM mechanism to easily troubleshoot as well as validate 891 the paths traversed by the SFCs SHOULD be supported. 893 6. Acknowledgements 895 The authors would like to thank Paul Quinn, Jim Guichard, Jim French, 896 Larry Kreeger and Nagaraj Bagepalli for their review and comments. 898 A special thanks to Abhijit Patra for his guidance. 900 7. Contributors 902 The following people are active contributors to this draft, they have 903 provided content and review feedback : 905 Cesar Obediente 906 Cisco Systems, Inc. 907 Email: cobedien@cisco.com 909 Kengo Naito 910 NTT 911 Email: naito.kengo@lab.ntt.co.jp 913 8. IANA Considerations 915 This memo includes no request to IANA. 917 9. Security Considerations 919 Security of traffic being serviced is very important in the use cases 920 described in this document. The SNs deployed as part of the SFC are 921 expected to include SFs specifically addressing the security aspect 922 either individually or in concert with other SFs. In this regard 923 organizational security policies are expected to drive the security 924 posture adapted in the SFCs. However, securing the traffic moving 925 between the SFs or SNs is not a consideration beyond the methods used 926 for moving such traffic. 928 10. References 930 10.1. Normative References 932 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 933 Requirement Levels", BCP 14, RFC 2119, 934 DOI 10.17487/RFC2119, March 1997, 935 . 937 10.2. Informative References 939 [I-D.ietf-sfc-problem-statement] 940 Quinn, P. and T. Nadeau, "Service Function Chaining 941 Problem Statement", draft-ietf-sfc-problem-statement-13 942 (work in progress), February 2015. 944 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 945 Address Translator (Traditional NAT)", RFC 3022, 946 DOI 10.17487/RFC3022, January 2001, 947 . 949 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 950 NAT64: Network Address and Protocol Translation from IPv6 951 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 952 April 2011, . 954 Authors' Addresses 956 Surendra Kumar 957 Cisco Systems, Inc. 958 170 W. Tasman Dr. 959 San Jose, CA 95134 961 Email: smkumar@cisco.com 963 Mudassir Tufail 964 Citi 965 238 King George Rd 966 Warren, NJ 07059-5153 968 Email: mudassir.tufail@citi.com 969 Sumandra Majee 970 F5 Networks 971 90 Rio Robles 972 San Jose, CA 95134 974 Email: S.Majee@f5.com 976 Claudiu Captari 977 Telstra Corporation 978 Level 15, 525 Collins Street 979 Melbourne 3000 981 Email: Claudiu.Captari@team.telstra.com 983 Shunsuke Homma 984 NTT 985 3-9-11, Midori-cho Musashino-shi 986 Tokyo 180-8585 987 Japan 989 Email: homma.shunsuke@lab.ntt.co.jp