idnits 2.17.1 draft-ietf-sfc-dc-use-cases-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 : ---------------------------------------------------------------------------- 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 21, 2014) is 3567 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: January 22, 2015 Citi 6 S. Majee 7 F5 Networks 8 C. Captari 9 Telstra Corporation 10 S. Homma 11 NTT 12 July 21, 2014 14 Service Function Chaining Use Cases In Data Centers 15 draft-ietf-sfc-dc-use-cases-01 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 January 22, 2015. 46 Copyright Notice 48 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . 22 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 to in order to service 138 it. 140 Servicing of traffic involves directing the traffic through a series 141 of service functions that may be located at different places in the 142 network or within a single device connected to the network or any 143 combination in between. Delivery of multiple service functions in a 144 sequence, in a datacenter or among multiple data centers, thus 145 creates many requirements on the overall service delivery 146 architecture. Such architectures may be termed service function 147 chaining architectures while the list of service functions applied to 148 the traffic is a Service Function Chain (SFC). 150 1.1. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 2. Definition Of Terms 158 Additional terms are defined in [I-D.ietf-sfc-problem-statement], 159 which the reader may find helpful. 161 End Point (EP): A device or an application that is the ultimate 162 origination or destination entity of specific traffic. Mobile 163 devices, desktop or server computers and applications running on 164 them are some examples. 166 Workload (WL): A physical or virtual machine performing a dedicated 167 task that consumes compute, storage, network and other resources. 168 This may include web servers, database servers, storage servers 169 and a variety of application servers. 171 Service Function (SF): A function that is responsible for specific 172 treatment of received packets. A Service Function can act at the 173 network layer or other OSI layers. A Service Function can be a 174 virtual instance or be embedded in a physical network element. 175 One of multiple Service Functions can be embedded in the same 176 network element. Multiple instances of the Service Function can 177 be enabled in the same administrative domain. A non-exhaustive 178 list of Service Functions includes: firewalls, WAN and 179 application acceleration, Deep Packet Inspection (DPI), server 180 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID 181 injection, HTTP Header Enrichment functions, TCP optimizer, etc. 183 Service Node (SN): A virtual or physical device that hosts one or 184 more service functions, which can be accessed via the network 185 location associated with it. 187 Classifier (CF): The entity responsible for selecting traffic as 188 well as a service chain, based on policy, and forwarding the 189 selected traffic on the service chain. 191 Deep Packet Inspection (DPI): service function that performs 192 stateful inspection of traffic, identification of applications 193 and policy enforcement, among others. 195 Intrusion Detection and/or Prevention System (IDS/IPS): Is a DPI SN 196 with additional capabilities to recognize malware and other 197 threats and take corrective action. 199 Edge Firewall (EdgeFW): SN hosting service functions such as VPN, 200 DHCP, NAT, IP-Audit, Protocol Inspection, DPI etc. with policies 201 primarily focusing on threats external to the data center. 203 Segment Firewall (SegFW): SN hosting a subset of the functions in 204 the EdgeFW not including VPN and is deployed to protect traffic 205 crossing segments, such as VLANs. 207 Application Firewall (AppFW): service function that isolates traffic 208 within a segment or protects from application specific threats. 209 This falls into the same class as DPI but deployed much closer to 210 the applications. It is an intra-segment firewall. 212 Application Delivery Controller (ADC): service function that 213 distributes traffic across a pool of servers (applications) for 214 efficient resource utilization, application scaling as well as to 215 provide high availability among others. 217 Web Optimization Control (WOC): SN hosting service functions to 218 optimize the use of WAN link bandwidth, improve effective user 219 throughput and latencies leading to overall improved user 220 experience. WOC includes various optimizers such as compression, 221 de-duplication, congestion control, application specific 222 optimizers, etc. WOC requires peers at either end of the WAN 223 link to perform optimizations. The scope of this document is 224 limited to the DC side of the WAN link. 226 Monitoring (MON): SN hosting service functions to obtain operational 227 visibility into the network to characterize network and 228 application performance, troubleshoot performance issues, 229 optimize resource utilization, etc. 231 Note: The above definitions are generalized. Actual implementations 232 may vary in scope and in a lot of cases the actual service functions 233 hosted on SNs overlap. For instance, DPI function is not only 234 implemented as a standalone service function but is also implemented 235 in EdgeFWs. Likewise EdgeFw functions, such as VPN, are implemented 236 in routers. The terms used are representative of common usage and 237 not absolute deployment. 239 3. Use Cases 241 The following sections highlight some of the most common data center 242 use case scenarios and are in no way exhaustive. 244 3.1. Traffic Types 246 IT assets in an enterprise are consolidated into a few data centers 247 located centrally. This consolidation stems from regulatory 248 compliance regarding security, control on the enterprise assets, 249 operational cost savings, disaster recovery strategies, etc. The 250 data center resources are accessible from any geographic location 251 whether inside or outside the enterprise network. Further, 252 enterprise data centers may be organized along lines of businesses, 253 with each business treated as a tenant, thereby supporting multi- 254 tenancy. 256 Service provider data centers have similar requirements as the 257 enterprise. Data centers may be distributed regionally and globally 258 to support the needs of their tenants. Multi-tenancy underlines 259 every consideration in such data centers: resources and assets are 260 organized & managed on tenant boundaries, policies are organized 261 along tenant boundaries, traffic is segregated and policies enforced 262 on tenant boundaries, etc. This is true in all "as a service" 263 models: IaaS, PaaS and SaaS. 265 This leads to two primary types of traffic: North-South and East- 266 West, both with different service requirements. 268 3.2. North-South Traffic 270 North-South traffic originates from outside the data center and is 271 typically associated with users - onsite, remote and VPN - conducting 272 their jobs. The traffic may also be associated with consumers 273 accessing news, email, social media and other websites. This traffic 274 is typically destined to applications or resources hosted in the data 275 centers. Increasing adoption of BYOD and social networking 276 applications requires traffic be analyzed, application and users be 277 identified, transactions be authorized, and at the same time security 278 threats be mitigated or eliminated. To this end, various service 279 functions, as illustrated in Figure 1, are deployed in different SNs 280 and in many instances of those SNs, at various topological locations 281 in the network. The SNs are selected based on the policy required 282 for the specific use case. 284 [ End Point ] --------+ 285 | 286 | 287 | 288 Border 289 +------ Router 290 | | 291 | | 292 +------- WOC 293 | | 294 | | 295 +------ EdgeFW 296 | | 297 | | 298 +------- MON 299 | | 300 | | 301 +------- ADC 302 | | 303 | | 304 +------ AppFW 305 | 306 | 307 | 308 +-------- [ Workload ] 310 Figure 1: Service functions applied to North-South traffic 312 Figure 1 shows the ordered list of SNs, from top to bottom, 313 representing the flow of traffic from End Point to Workload and vice 314 versa. Traffic does not always strictly flow through all the SNs in 315 that order. Traffic flows through various permutations, of the 316 subsets, of the SNs. The connections from each of the service nodes 317 to every other service node (as depicted by the vertical line to the 318 left) represents the network topology required to achieve such 319 traffic flows. Each permutation represents a service function chain. 321 Certain ordering of the SNs naturally exists due to the nature of the 322 functions applied. For instance, WOC is not effective on VPN traffic 323 - requires VPN termination prior to WOC. Likewise EdgeFW may not be 324 effective on WOC traffic. Vendor implementations of SNs enable 325 choices for various deployments and ordering. For instance EdgeFW 326 detects the presence of WOC through TCP options or explicit 327 configuration and hence WOC may even be deployed on the traffic that 328 has passed through the EdgeFW. Constructing service function chains 329 in the underlay network thus requires complex topology. 331 3.2.1. Sample north-south service function chains 333 SFC-1. EdgeFW 335 SFC-2. EdgeFW : ADC 337 SFC-3. EdgeFW : ADC : AppFW 339 SFC-4. WOC : EdgeFW : ADC : AppFW 341 SFC-5. WOC : EdgeFW : MON : ADC : AppFW 343 3.2.2. Sample north-south SFC description 345 Sample service chains numbered SFC-1 through SFC-5 capture the 346 essence of services required on the north-south traffic. 348 SFC-1: This represents the simplest of use cases where a remote or 349 mobile worker accesses a specific data center server. Traffic 350 comes into the data center on VPN and is terminated on the 351 EdgeFW. EdgeFW subjects the traffic to its policies, which may 352 in turn select other service functions such as DPI, IPS/IDS, 353 hosted on the EdgeFW. As an alternative deployment, some of 354 these service functions may be hosted outside the EdgeFW and 355 reachable via VLAN stitching. EdgeFW policy permitting, traffic 356 is allowed to its destination. 358 SFC-2: This is an extension of SFC-1. Traffic instead of destined 359 to a specific server is destined to a data center application 360 that is front-ended by an ADC. The EdgeFW performs its function 361 as before and the traffic is allowed, policy permitting. This 362 traffic reaches its virtual destination, the ADC. ADC, based on 363 local policy, which includes among other things predictors to 364 select the real destination, determines the appropriate 365 application instance. ADCs are stateful and ensure the return 366 traffic pass through them by performing source NAT. Since many 367 applications require the original source address, ADC preserves 368 the original address in extension headers of the HTTP protocol. 369 Traffic is then forwarded on to the ultimate destination - the 370 real application workload. 372 SFC-3: This extends SFC-2. The segment where the application server 373 resides may be shared with other applications and resources. To 374 segregate these applications and resources further fine grain 375 policies may be required and are enforced via a security 376 appliance such as the AppFW. As a consequence AppFW first 377 services the traffic from the load balancer before it is 378 forwarded to its ultimate destination, the application server. 380 SFC-4: This is a variant of SFC-3 with WOC being part of the chain. 381 This represents the use case where users at a branch office 382 access the data center resources. The WOC SNs located at either 383 end of the WAN optimize the traffic first. The WOC located in 384 the datacenter requires a mechanism to steer traffic to it while 385 not deployed inline with the traffic. This is achieved either 386 with PBR or VLAN stitching. WOC treated traffic is subject to 387 firewall policies, which may lead to the application of SFs such 388 as protocol inspection, DPI, IDS/IPS and then forwarded to its 389 virtual destination, the ADC. 391 SFC-5: This is similar to SFC-4. An additional service - MON, is 392 used to collect and analyze traffic entering and leaving the data 393 center. This monitoring and analysis of traffic helps maintain 394 performance levels of the infrastructure to achieve service level 395 agreements, particularly in SP data centers. 397 3.3. East-West Traffic 399 This is the predominant traffic in data centers today. Server 400 virtualization has led to the new paradigm where virtual machines can 401 migrate from one server to another across the datacenter. This 402 explosion in east-west traffic is leading to newer data center 403 network fabric architectures that provide consistent latencies from 404 one point in the fabric to another. 406 The key difference with east-west from the north-south traffic is in 407 the kind of threats and the security needs thereof. Unlike north- 408 south traffic where security threats may come from outside the data 409 center, any threat to this traffic comes from within the data center. 411 +-- ADC1 --- MON1 --- AppFW1 --- Workload1(Web) 412 / 413 SegFW ---- ADC2 --- MON2 --- AppFW2 --- Workload2(App) 414 \ 415 +-- ADC3 --- MON3 --- AppFW3 --- Workload3(DB) 417 Figure 2: Service functions applied to East-West traffic 419 Service functions applied on the east-west traffic is captured in a 420 generalized fashion in Figure 2. ADCs, although shown as isolated 421 SNs in each of the tiers, is often consolidated into a smaller number 422 of ADC SNs shared among the different tiers. Virtual IPs in such 423 ADCs represent the individual ADC instances. Flows are terminated at 424 the VIPs and re-initiated towards the load balanced 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 501 | | C S 502 +------ EdgeFW E F 503 | | S C 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 536 Access SFCs are focused on servicing traffic entering and leaving the 537 data center while Application SFCs are focused on servicing traffic 538 destined to applications. 540 Service providers deploy a single "Access SFC" and multiple 541 "Application SFCs" for each tenant. Enterprise data center operators 542 on the other hand may not have a need for Access SFCs depending on 543 the size and requirements of the enterprise. Where such Access SFCs 544 are indeed needed, such as large enterprises, the operator may deploy 545 a bare minimum Access SFC instead. Such simple Access SFCs include 546 WOC and VPN SFs to support the branch and mobile user traffic while 547 at the same time utilizing the security policies in the application 548 SFCs. The latter is the case in de-perimetrized network 549 architectures where security policies are enforced close to the 550 resources and applications as opposed to the WAN edge. 552 3.6. Inter-datacenter SFCs 554 In carrier networks, operators may deploy multiple data centers 555 dispersed geographically. Each data center may host different types 556 of service functions. For example, latency sensitive or high usage 557 service functions are deployed in regional data centers while other 558 latency tolerant, low usage service functions are deployed in global 559 or central data centers. In such deployments, SFCs may span multiple 560 data centers and enables operators to deploy services in a flexible 561 and inexpensive way. These SFCs are referred to as the inter- 562 datacenter SFCs in this draft. 564 3.6.1. Methods for inter-datacenter SFCs 566 The following are two methods to construct inter-datacenter SFCs: 568 1. Inter-datacenter SFCs with multiple SFC domains 570 2. Inter-datacenter SFCs with a single SFC domain 571 -----+ 572 [ Workload ]----+ | incoming 573 | V traffic 574 .--. 575 ( )-. 576 .' ) 577 ( Internet ) 578 ( -' 579 '-( ) 580 '---' 581 | 582 +----|--------------------+ 583 | | SFC domain | 584 | | +---------+ | 585 | +-----+ | | | 586 | | C F |---+ DC | | 587 | +-----+ | | | 588 | | +---------+ | 589 +----|--------------------+ 590 | 591 +----|--------------------+ 592 | | SFC domain | 593 | | +---------+ | 594 | +-----+ | | | 595 | | C F |---+ DC | | 596 | +-----+ | | | 597 | | +---------+ | 598 +----|--------------------+ 599 | 600 A | 601 outgoing | +-----------[ End Point ] 602 traffic +------ 604 Figure 4: Inter-datacenter SFC with multiple SFC domains 606 Figure 4 shows inter-datacenter SFC with multiple SFC domains. In 607 this method, services are provided by SFCs spanning multiple 608 independent SFC domains. SFC management is limited to each domain: 609 control plane is constrained to its SFC domain and SFCs are 610 fragmented and initiated in each SFC domain. If both data centers 611 are located in-line, a method of forwarding packets between data 612 centers is required. 614 -----+ 615 [ Workload ]----+ | incoming 616 | V traffic 617 .--. 618 ( )-. 619 .' ) 620 ( Internet ) 621 ( -' 622 '-( ) 623 '---' 624 | 625 +-----+ 626 +------------| C F |-------------+ 627 | SFC domain +-----+ | 628 | | | 629 | +-------------+ | 630 | | | | 631 | | D C | | 632 | | | | 633 | +-------------+ | 634 | | | 635 | | | 636 | | | 637 | +-------------+ | 638 | | | | 639 | | D C | | 640 | | | | 641 | +-------------+ | 642 | | | 643 | +-----+ | 644 +------------| C F |-------------+ 645 +-----+ 646 | 647 A | 648 outgoing | +-----------[ End Point ] 649 traffic +------ 651 Figure 5: Inter-datacenter SFC with single SFC domains 653 Figure 5 shows inter datacenter SFC with a single SFC domain. In 654 this method, services are provided across multiple data centers, 655 which are connected with virtualized paths and grouped into a single 656 SFC domain. 658 In multiple SFC domain case, it is simple to control and manage the 659 SFC domain. However, it is difficult to hand over context data 660 between data centers, whether context data are conveyed out of band - 661 in the control plane or, in band - with traffic. In addition, the 662 cost of classification is high, as it is performed twice in each SFC 663 domain - once in each direction. On the other hand, in the single 664 SFC domain case, it is easy to hand over context data between data 665 centers, but control of SFC domains becomes complex as integrated 666 operation across multiple data centers is required. 668 3.6.2. Considerations for inter-datacenter SFCs 670 Inter-datacenter SFC must consider many design aspects, two important 671 among them are : 673 1. Handing over context data 675 2. Multiple classification points 677 Handing over context data : Metadata sharing among SFC components 678 enables many use cases and services. If context data cannot be 679 passed across data centers, some services provided by SFC would 680 be restricted. For example, it is difficult to create SFCs 681 across multiple data centers because service functions cannot 682 simply share information, with each other, between the data 683 centers. 685 Multiple classification points : In a large SFC domain containing 686 multiple datacenters distributed over large geographies, 687 classification of incoming traffic and outgoing traffic may 688 happen at different points, depending on the deployment model. 689 If classification of incoming traffic and outgoing traffic are 690 forced to happen at the same point, as shown in Figure 6, all 691 traffic may traverse long distances leading to inefficient 692 resource consumption and increased latencies. 694 696 +----+ 697 [ EP ]---------------+ CF +-----------------[ WL ] 698 ++--++ 699 | | 700 +--------+ +--------+ 701 | | 702 +----+----+ +----+----+ 703 | | | | 704 | DC | | DC | 705 | | | | 706 +---------+ +---------+ 708 <-- long distance --> 710 ========================================================= 712 714 [ EP ] [ DC ] [ CF ] [ DC ] [ WL ] 716 *--------------------+ 717 | 718 +----------+ 719 | 720 +---------------------+ 721 | 722 +-----------> 724 |<-------->| 725 traffic turn back 727 Figure 6: Inter-datacenter SFC with single classification point 729 4. Drawbacks Of Existing Service Chaining Methods 731 The above use cases are realized in a traditional fashion and are not 732 viable in the evolving hybrid data centers with virtual and physical 733 assets. The following are some of the obvious short comings of 734 existing SFC methods exposed by the above use cases. 736 DB-1. Policy based purely on VLANs is no longer sufficient. 737 Connecting SNs to each other to construct a service chain 738 thus makes it very static and removes deployment flexibility. 739 As can be seen from the sample north-south service chains, a 740 large number of VLANs not only have to be stitched in a 741 certain fashion to achieve a basic SFC, it is simply not 742 flexible to share the SNs among different SFCs as even simple 743 sharing among a few SNs becomes intractable from basic 744 configuration perspective let alone future changes or 745 manageability aspects. 747 DB-2. Traffic does not always have to be steered through all the 748 SNs of a traditional VLAN stitched service chain. In 749 Figure 1, traffic from the border router is not always 750 necessary to flow through the WOC as remote or mobile worker 751 may not have a WOC peer deployed. Connecting multiple VLANs 752 among service nodes to overcome to achieve this only 753 aggravates the problem of deployment and manageability. 754 Truly, there exists a need for dynamically determining the 755 next sub SFC at such branching points to avoid forcing all 756 traffic through the same SFC. 758 DB-3. Virtual environments require the virtual SNs be migration 759 capable just like the compute workloads. As a consequence it 760 is simply not feasible to continue VLAN stitching in the 761 hybrid data centers. Every time a virtual SN migrates, such 762 as the AppFW in Figure 1 and Figure 2, the operator has to 763 ensure the VLANs are provisioned in the destination. 764 Further, stretching the VLANs across the network may not be 765 an option for the operator or even worse the virtual SN may 766 be L3 hop away from the previous SN. 768 DB-4. Policy Based Routing (PBR) can be used to move traffic to 769 SNs. Although it provides a much better granularity than 770 VLAN stitching it suffers from the requirement to configure 771 such policies all along the path to the SNs. In Figure 1, if 772 WOC is multiple hops away from the border router, all network 773 elements in between border router and WOC need to be 774 configured with consistent policies. 776 DB-5. Source NAT (SNAT) is required by some SNs, such as ADC in 777 Figure 1, in order to ensure traffic sent to the load 778 balanced servers pass through the ADC in reverse direction. 779 However, SNAT removes the ability to detect the originator of 780 the traffic. Using HTTP extension header to pass originator 781 information is not only an overhead but addresses only one 782 specific protocol. 784 DB-6. Static service chains do not allow for modifying the SFCs as 785 they require the ability to add SNs or remove SNs to scale up 786 and down the service capacity. Likewise the ability to 787 dynamically pick one among the many SN instance is not 788 available. For instance, WOC must scale to support the high 789 data rate of traffic flowing to the data center. Likewise, 790 AppFWs must scale up to not impact the workload throughput. 791 Further they may be required to scale within tenant 792 boundaries. 794 DB-7. Static SFCs constructed over the under lay network cannot 795 pass metadata to the SNs. Border Router in Figure 1 cannot 796 pass policy based tags derived locally at the start of the 797 SFC all the way through the SFC. Such metadata is necessary 798 to enforce consistent security policies across the network, 799 as one example. 801 DB-8. In multi-tenant deployments, the segment on which the SN is 802 deployed may not correspond to the segment assigned to the 803 tenant in which the workloads are hosted. In Figure 2, AppFW 804 may be deployed on a different segment than the Workload. As 805 a consequence, it is not viable to derive the tenant segment 806 simply based on the tag associated with the incoming traffic 807 at the AppFW. This ultimately prevents the ability to have 808 the same SN serve multiple tenants. Forcing the SN to be on 809 the same segment as the tenants' workload limits deployment 810 flexibility. 812 DB-9. Traffic may originate in a physical or virtual network or 813 transit these networks before being delivered to the SNs for 814 servicing. The following is very complex to achieve with the 815 existing SFC mechanism, primarily due to very conflicting 816 nature of their environments: physical and static vs. virtual 817 and dynamic. 819 A. Physical SN servicing traffic originating in the virtual 820 access network. 822 B. Virtual SN servicing traffic originating in the physical 823 network. 825 DB-10. Although SNs are purpose built service appliances, it is 826 neither a requirement nor an indication of how service 827 functions are implemented in emerging data centers with 828 commodity compute and storage capabilities. AppFW in 829 Figure 1, for instance, may be built and deployed as a 830 virtual SN. Further, SFCs are limited to exclusively 831 physical or virtual SNs and not a mix. This excludes the 832 ability to combine the benefits offered by physical SNs with 833 the flexibility and agility of the virtual SNs. The EdgeFW 834 in Figure 1, for instance, may be a purpose built SN to take 835 advantage of SFs implemented in hardware while the AppFW may 836 be a virtual SN deployed to be close to the virtual workload 837 and may even move with the workload in the virtual 838 environment. 840 DB-11. Troubleshooting is one of the predominant issues plaguing SFC 841 deployments. The reasons range from misconfiguration at 842 different elements in the network that are responsible for 843 directing traffic to the service nodes, to, tracking the 844 traffic paths starting from the point of entry into the DC to 845 the point of exit to the application through various SNs. 846 When desired services are not effective on certain traffic, 847 determining the reason is simply not viable in a large scale 848 deployment. Figure 3 provides a view of the complexity in 849 terms of the permutations of the SFCs, their paths in the 850 network and the configuration in the network elements 851 required and managed for proper operation. 853 5. General Requirements 855 The above use cases and the drawbacks thereof lead to the following 856 general requirements in today's evolving hybrid datacenters to apply 857 SFCs to traffic. 859 GR1. SFC polices MUST be applicable at the edges - network elements 860 as well as the workloads. 862 GR2. SFC policies MUST be applicable to either Ingress or Egress 863 traffic at network elements as well as workloads. 865 GR3. SFC MUST support virtual as well as physical SNs. 867 GR4. SFC SHOULD support the ability to mix virtual and physical SNs 868 in the same SFC. 870 GR5. SFC SNs MUST be deployable L2 or L3 hop away from the SFC 871 application points - network elements or workloads. 873 GR6. SFC traffic MUST be allowed to follow paths not constrained by 874 the underlying static network topology. 876 GR7. SFC SNs MUST be able identify tenant traffic without being 877 tied to the underlying topology 879 GR8. SFCs MUST support the ability to pass metadata among the SNs 880 or between the SNs and the network elements. 882 GR9. A composite SFC SHOULD be achievable by way of joining sub 883 SFCs, branching to sub SFCs where necessary. 885 GR10. SFCs SHOULD NOT require SNAT inside the SFs to attract traffic 886 back to them 888 GR11. SFCs SHOULD have the ability to choose SN instances 889 dynamically, prior to forwarding traffic to them. 891 GR12. An OAM mechanism to easily troubleshoot as well as validate 892 the paths traversed by the SFCs SHOULD be supported. 894 6. Acknowledgements 896 The authors would like to thank Paul Quinn, Jim Guichard, Jim French, 897 Larry Kreeger and Nagaraj Bagepalli for their review and comments. 899 A special thanks to Abhijit Patra for his guidance. 901 7. Contributors 903 The following people are active contributors to this draft, they have 904 provided content and review feedback : 906 Cesar Obediente 907 Cisco Systems, Inc. 908 Email: cobedien@cisco.com 910 Kengo Naito 911 NTT 912 Email: naito.kengo@lab.ntt.co.jp 914 8. IANA Considerations 916 This memo includes no request to IANA. 918 9. Security Considerations 920 Security of traffic being serviced is very important in the use cases 921 described in this document. The SNs deployed as part of the SFC are 922 expected to include SFs specifically addressing the security aspect 923 either individually or in concert with other SFs. In this regard 924 organizational security policies are expected to drive the security 925 posture adapted in the SFCs. However, securing the traffic moving 926 between the SFs or SNs is not a consideration beyond the methods used 927 for moving such traffic. 929 10. References 931 10.1. Normative References 933 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 934 Requirement Levels", BCP 14, RFC 2119, March 1997. 936 10.2. Informative References 938 [I-D.ietf-sfc-problem-statement] 939 Quinn, P. and T. Nadeau, "Service Function Chaining 940 Problem Statement", draft-ietf-sfc-problem-statement-07 941 (work in progress), June 2014. 943 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 944 Address Translator (Traditional NAT)", RFC 3022, 945 January 2001. 947 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 948 NAT64: Network Address and Protocol Translation from IPv6 949 Clients to IPv4 Servers", RFC 6146, April 2011. 951 Authors' Addresses 953 Surendra Kumar 954 Cisco Systems, Inc. 955 170 W. Tasman Dr. 956 San Jose, CA 95134 958 Email: smkumar@cisco.com 959 Mudassir Tufail 960 Citi 961 238 King George Rd 962 Warren, NJ 07059-5153 964 Email: mudassir.tufail@citi.com 966 Sumandra Majee 967 F5 Networks 968 90 Rio Robles 969 San Jose, CA 95134 971 Email: S.Majee@f5.com 973 Claudiu Captari 974 Telstra Corporation 975 Level 15, 525 Collins Street 976 Melbourne, 3000 978 Email: Claudiu.Captari@team.telstra.com 980 Shunsuke Homma 981 NTT 982 3-9-11, Midori-cho Musashino-shi 983 Tokyo, 180-8585 984 Japan 986 Email: homma.shunsuke@lab.ntt.co.jp