idnits 2.17.1 draft-dolson-sfc-hierarchical-04.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 (December 14, 2015) is 3049 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Virus' is mentioned on line 626, but not defined == Missing Reference: 'Monitor' is mentioned on line 638, but not defined == Missing Reference: 'CF' is mentioned on line 653, but not defined == Outdated reference: A later version (-05) exists of draft-homma-sfc-forwarding-methods-analysis-01 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-07 == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-02 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-00 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining D. Dolson 3 Internet-Draft Sandvine 4 Intended status: Informational S. Homma 5 Expires: June 16, 2016 NTT 6 D. Lopez 7 Telefonica I+D 8 M. Boucadair 9 Orange Group 10 D. Liu 11 Alibaba Group 12 December 14, 2015 14 Hierarchical Service Function Chaining 15 draft-dolson-sfc-hierarchical-04 17 Abstract 19 Hierarchical Service Function Chaining (hSFC) is a network 20 architecture allowing an organization to compartmentalize a large- 21 scale network into multiple domains of administration. 23 The goals of hSFC are to make a large-scale network easier to reason 24 about, simpler to control and to support independent functional 25 groups within large operators. 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 June 16, 2016. 44 Copyright Notice 46 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Hierarchical Service Function Chaining (hSFC) . . . . . . . . 4 64 2.1. Top Level . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 7 67 3.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 7 68 3.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 7 69 3.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 9 70 3.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 9 71 3.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 10 72 4. Sub-domain Classifier . . . . . . . . . . . . . . . . . . . . 10 73 5. Control Plane Elements . . . . . . . . . . . . . . . . . . . 11 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 9.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Appendix A. Examples of Hierarchical Service Function Chaining . 13 81 A.1. Reducing the Number of Service Function Paths . . . . . . 13 82 A.2. Managing a Distributed Data-Center Network . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 Service Function Chaining (SFC) is a technique for prescribing 88 differentiated traffic forwarding policies within the SFC domain. 89 SFC is described in detail in the SFC architecture document 90 [I-D.ietf-sfc-architecture], and is not repeated here. 92 In this document we consider the difficult problem of implementing 93 SFC across a large, geographically dispersed network comprised of 94 millions of hosts and thousands of network forwarding elements, 95 involving multiple operational teams (with varying functional 96 responsibilities). We expect asymmetrical routing is inherent in the 97 network, while recognizing that some Service Functions (SFs) require 98 bidirectional traffic for transport-layer sessions (e.g., NATs, 99 firewalls). We assume that some Service Function Paths (SFPs) need 100 to be selected on the basis of application-specific data visible to 101 the network, with transport-layer coordinate (typically, 5-tuple) 102 stickiness to specific Service Function instances. 104 Note: in this document, the notion of the "path" of a packet is the 105 series of SF instances traversed by a packet. The means of 106 delivering packets between SFs (the forwarding mechanisms of the 107 underlay network) is not relevant to the current discussion. 109 Difficult problems are often made easier by decomposing them in a 110 hierarchical (nested) manner. So instead of considering an 111 omniscient SFC Control Plane that can manage (create, withdraw, 112 supervise, etc.) complete SFPs from one end of the network to the 113 other, we decompose the network into smaller sub-domains. Each sub- 114 domain may support a subset of the network applications or a subset 115 of the users. The criteria for determining decomposition into SFC- 116 enabled sub-domains are beyond the scope of this document. 118 Note that decomposing a network into multiple SFC-enabled domains 119 should permit end-to-end visibility of Service Functions and Service 120 Function Paths. Decomposition should also be implemented with 121 special care to ease monitoring and troubleshooting of the network as 122 a whole. 124 An example of simplifying a network by using multiple SF domains is 125 further discussed in [I-D.ietf-sfc-dc-use-cases]. 127 We assume the SF technology uses NSH [I-D.ietf-sfc-nsh] or a similar 128 labeling mechanism. 130 The "domains" discussed in this document are assumed to be under 131 control of a single organization, such that there is a strong trust 132 relationship between the domains. The intention of creating multiple 133 domains is to improve the ability to operate a network. It is 134 outside of the scope of the document to consider domains operated by 135 different organizations. 137 1.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 2. Hierarchical Service Function Chaining (hSFC) 145 A hierarchy has multiple levels. The top-most level encompasses the 146 entire network domain to be managed, and lower levels encompass 147 portions of the network. 149 2.1. Top Level 151 Considering the example in Figure 1, a top-level network domain 152 includes SFC components distributed over a wide area, including: 154 o classifiers (CFs), 156 o Service Function Forwarders (SFFs) and 158 o Sub-domains. 160 For the sake of clarity, components of the underlay network are not 161 shown; an underlay network is assumed to provide connectivity between 162 SFC components. 164 Top-level service function paths carry packets from classifiers 165 through a series of SFFs and sub-domains, with the operations within 166 sub-domains being opaque to the higher levels. 168 We expect the system to include a top-level control-plane having 169 responsibility for configuring forwarding and classification. The 170 top-level Service Chaining control-plane manages end-to-end service 171 chains and associated service function paths from network edge points 172 to sub-domains and configuring top-level classifiers at a coarse 173 level (e.g., based on source or destination host) to forward traffic 174 along paths that will transit appropriate sub-domains. The figure 175 shows one possible service chain passing from edge, through two sub- 176 domains, to network egress. The top-level control plane does NOT 177 configure classification or forwarding within the sub-domains. 179 At this network-wide level, the number of SFPs required is a linear 180 function of the number of ways in which a packet is required to 181 traverse different sub-domains and egress the network. Note that the 182 various paths which may be taken within a sub-domain are not 183 represented by distinct network-wide SFPs; specific policies at the 184 ingress nodes of each sub-domain bind flows to sub-domain paths. 186 Packets are classified at the edge of the network to select the paths 187 by which sub-domains are to be traversed. At the ingress of each 188 sub-domain, paths are reclassified to select the paths by which SFs 189 in the sub-domain are to be traversed. At the egress of each sub- 190 domain, packets are returned to the top-level paths. Contrast this 191 with an approach requiring the top-level classifier to select paths 192 to specify all of the SFs in each sub-domain. 194 It should be assumed that some service functions in the network 195 require bidirectional symmetry of paths (see more in Section 4). 196 Therefore the classifiers at the top level must be configured with 197 policies ensuring server-to-client packets take the reverse path of 198 client-to-server packet through sub-domains. (Recall the "path" 199 denotes the series of service functions; the precise physical network 200 path within the underlay network is not relevant here.) 202 +------------+ 203 |Sub-domain#1| 204 | in DC1 | 205 +----+-------+ 206 | 207 .---- SFF1 ------. +--+ 208 +--+ / / | \--|CF| 209 --->|CF|--/---->' | \ +--+ 210 +--+ / SC#1 | \ 211 | | | 212 | V .------>|---> 213 | / / | 214 \ | / / 215 +--+ \ | / / +--+ 216 |CF|---\ | / /---|CF| 217 +--+ '---- SFF2 ------' +--+ 218 | 219 +----+-------+ 220 |Sub-domain#2| 221 | in DC2 | 222 +------------+ 224 One path is shown from edge classifier to SFF1 to Sub-domain#1 225 (residing in data-center1) to SFF1 to SFF2 (residing in data-center 226 2) to Sub-domain#2 to SFF2 to network egress. 228 Figure 1: Network-wide view of top level of hierarchy 230 2.2. Lower Levels 232 Each of the sub-domains in Figure 1 is an SFC domain. 234 Unlike the top level, however, data packets entering the sub-domain 235 are already encapsulated within SFC transport. Figure 2 shows a sub- 236 domain interfaced with a higher-level domain by means of an Internal 237 Boundary Node (IBN). It is the purpose of the IBN to remove packets 238 from the SFC encapsulation, apply Classification rules, and direct 239 the packets to the selected local service function paths terminating 240 at an egress IBN. The egress IBN finally restores packets to the 241 original SFC transport and hands them off to SFFs. 243 Each sub-domain intersects a subset of the total paths that are 244 possible in the higher-level domain. An IBN is concerned with 245 higher-level paths, but only those traversing the sub-domain. A top- 246 level controller may configure the IBN as an SF (the IBN plays the SF 247 role in the top-level domain). 249 We expect each sub-domain to have a control-plane that can operate 250 independently of the top-level control-plane. The sub-domain 251 control-plane configures the classification and forwarding rules in 252 the sub-domain. The classification rules reside in the IBN, where 253 packets are moved from SFC encapsulation of the top-level domain to 254 and from SFC encapsulation of the lower-level domain. 256 +----+ +-----+ +----------------------+ +-----+ 257 | |SC#1| SFF | | IBN 1 | | SFF | 258 ->| |================* *===============> 259 | | +-----+ | # (in DC 1) # | +-----+ 260 | CF | | V # | 261 | | |+---+ +---+| Top domain 262 | | * * * * *||CF | * * * * * *|SFF|| * * * * * 263 | | * |+---+ +-+-+| * 264 +----+ * | | | | | | Sub * 265 * +-o-o--------------o-o-+ domain* 266 * SC#2 | |SC#1 ^ ^ #1 * 267 * +-----+ | | | * 268 * | V | | * 269 * | +---+ +------+ | | * 270 * | |SFF|->|SF#1.1|--+ | * 271 * | +---+ +------+ | * 272 * V | * 273 * +---+ +------+ +---+ +------+ * 274 * |SFF|->|SF#2.1|->|SFF|->|SF#2.2| * 275 * +---+ +------+ +---+ +------+ * 276 * * * * * * * * * * * * * * * * * * * * * * 278 *** Sub-domain boundary; === top-level chain; --- low-level chain. 280 Figure 2: Sub-domain within a higher-level domain 282 If desired, the pattern can be applied recursively. For example, 283 SF#1.1 in Figure 2 could be a sub-domain of the sub-domain. 285 3. Internal Boundary Node (IBN) 287 A network element termed "Internal Boundary Node" (IBN) bridges 288 packets between domains. It looks like an SF to the higher level, 289 and looks like a classifier and end-of-chain to the lower level. 291 To achieve the benefits of hierarchy, the IBN should be applying more 292 granular traffic classification rules at the lower level than the 293 traffic passed to it. This means that the number of SF Paths within 294 the lower level is greater than the number of SF Paths arriving to 295 the IBN. 297 The IBN is also the termination of lower-level SF paths. This is 298 because the packets exiting lower-level SF paths must be returned to 299 the higher-level SF paths and forwarded to the next hop in the 300 higher-level domain. 302 3.1. IBN Path Configuration 304 An operator of a lower-level SF Domain may be aware of which high- 305 level paths transit their domain, or they may wish to accept any 306 paths. 308 When packets enter the sub-domain, the Service Path Identifier (SPI) 309 and Service Index (SI) are re-marked according to the path selected 310 by the classifier. 312 After exiting a path in the sub-domain, packets can be restored to an 313 original upper-level SF path by these methods: 315 1. Saving SPI and SI in transport-layer flow state, 317 2. Pushing SPI and SI into metadata, 319 3. Using unique lower-level paths per upper-level path coordinates. 321 3.1.1. Flow-Stateful IBN 323 An IBN can be flow-aware, returning packets to the correct higher- 324 level SF path on the basis of the transport-layer coordinates 325 (typically, a 5-tuple) of packets exiting the lower-level SF paths. 327 When packets are received by the IBN on a higher-level path, the 328 encapsulated packets are parsed for IP and transport-layer (TCP, 329 UDP...) coordinates. State is created, indexed by these coordinates 330 (a 5-tuple of {source-IP, destination-IP, source-port, destination- 331 port and transport protocol} in a typical case). The state contains 332 critical fields of the encapsulating SFC header (or perhaps the 333 entire header). 335 The simplest approach has the packets return to the same IBN at the 336 end of the chain that classified the packet at the start of the 337 chain. This is because the required transport-coordinates state is 338 rapidly changing and most efficiently kept locally. If the packet is 339 returned to a different IBN for egress, transport-coordinates state 340 must be synchronized between the IBNs. 342 When a packet returns to the IBN at the end of a chain, the SFC 343 header is removed, the packet is parsed for IP and transport-layer 344 coordinates, and state is retrieved from them. The state contains 345 the information required to forward the packet within the higher- 346 level service chain. 348 State cannot be created by packets arriving from the lower-level 349 chain; when state cannot be found for such packets, they MUST be 350 dropped. 352 This stateful approach is limited to use with SFs that retain the 353 transport coordinates of the packet. This approach cannot be used 354 with SFs that modify those coordinates (e.g., as done by a NAT) or 355 otherwise create packets for new coordinates other than those 356 received (e.g., as an HTTP cache might do to retrieve content on 357 behalf of the original flow). In both cases, the fundamental problem 358 is the inability to forward packets when state cannot be found for 359 the packet transport-layer coordinates. 361 In the stateful approach, there are issues caused by having state, 362 such as how long the state should be maintained (it MUST time out 363 eventually), as well as whether the state needs to be replicated to 364 other devices to create a highly available network. 366 It is valid to consider the state to be disposable after failure, 367 since it can be re-created by each new packet arriving from the 368 higher-level domain. For example, if an IBN loses all flow state, 369 the state is re-created by an end-point retransmitting a TCP packet. 371 If an SFC domain handles multiple network regions (e.g., multiple 372 private networks), the coordinates may be augmented with additional 373 parameters, perhaps using some metadata to identify the network 374 region. 376 In this stateful approach, it is not necessary for the sub-domain's 377 control-plane to modify paths when higher-level paths are changed. 378 The complexity of the higher-level domain does not cause complexity 379 in the lower-level domain. 381 3.1.2. Encoding Upper-Level Paths in Metadata 383 An IBN can push the upper-level Service Path Identifier (SPI) and 384 Service Index (SI) (or encoding thereof) into a metadata field of the 385 lower-level encapsulation (e.g., placing upper-level path information 386 into a metadata field of NSH). When packets exit the lower-level 387 path, the upper-level SPI and SI can be restored from the metadata 388 retrieved from the packet. 390 This approach requires the SFs in the path to be capable of 391 forwarding the metadata and appropriately attaching metadata to any 392 packets injected for a flow. 394 Using new metadata may inflate packet size when variable-length 395 metadata (type 2 from NSH [I-D.ietf-sfc-nsh]) is used. 397 It is conceivable that the MD-type 1 Mandatory Context Header fields 398 of NSH [I-D.ietf-sfc-nsh] are not all relevant to the lower-level 399 domain. In this case, one of the metadata slots of the Mandatory 400 Context Header could be repurposed within the lower-level domain, and 401 restored when leaving. 403 In this metadata approach, it is not necessary for the sub-domain's 404 controller to modify paths when higher-level paths are changed. The 405 complexity of the higher-level domain does not cause complexity in 406 the lower-level domain. 408 3.1.3. Using Unique Paths per Upper-Level Path 410 In this approach, paths within the sub-domain are constrained so that 411 a SPI (of the sub-domain) unambiguously indicates the egress SPI and 412 SI (of the upper domain). This allows the original path information 413 to be restored at sub-domain egress from a look-up table using the 414 sub-domain SPI. 416 Whenever the upper-level domain provisions a path via the lower-level 417 domain, the lower-level domain controller must provision 418 corresponding paths to traverse the lower-level domain. 420 A down-side of this approach is that the number of paths in the 421 lower-level domain is multiplied by the number of paths in the 422 higher-level domain that traverse the lower-level domain. I.e., a 423 sub-path must be created for each combination of upper SPI/SI and 424 lower chain. 426 3.2. Gluing Levels Together 428 The SPI or metadata on a packet received by the IBN may be used as 429 input to reclassification and path selection within the lower-level 430 domain. 432 In some cases the meanings of the various path IDs and metadata must 433 be coordinated between domains. 435 One approach is to use well-known identifier values in metadata, 436 communicated by some organizational registry. 438 Another approach is to use well-known labels for chain identifiers or 439 metadata, as an indirection to the actual identifiers. The actual 440 identifiers can be assigned by control-plane systems. For example, a 441 sub-domain classifier could have a policy, "if pathID=classA then 442 chain packet to path 1234"; the higher-level controller would be 443 expected to configure the concrete higher-level pathID for classA. 445 4. Sub-domain Classifier 447 Within the sub-domain (referring to Figure 2), after the IBN removes 448 higher-level encapsulation from incoming packets, it sends the 449 packets to the classifier, which selects the encapsulation for the 450 packet within the sub-domain. 452 One of the goals of the hierarchical approach is to make it easy to 453 have transport-flow-aware service chaining with bidirectional paths. 454 For example, it is desired that for each TCP flow, the client-to- 455 server packets traverse the same SFs as the server-to-client packets, 456 but in the opposite sequence. We call this bidirectional symmetry. 457 If bidirectional symmetry is required, it is the responsibility of 458 the control-plane to be aware of symmetric paths and configure the 459 classifier to chain the traffic in a symmetric manner. 461 Another goal of the hierarchical approach is to simplify the 462 mechanisms of scaling in and scaling out service functions. All of 463 the complexities of load-balancing among multiple SFs can be handled 464 within a sub-domain, under control of the classifier, allowing the 465 higher-level domain to be oblivious to the existence of multiple SF 466 instances. 468 Considering the requirements of bidirectional symmetry and load- 469 balancing, it is useful to have all packets entering a sub-domain to 470 be received by the same classifier or a coordinated cluster of 471 classifiers. There are both stateful and stateless approaches to 472 ensuring bidirectional symmetry. 474 5. Control Plane Elements 476 Controllers have been mentioned in this document without much 477 explanation. Although control protocols have not yet been 478 standardized, from the point of view of hierarchical service function 479 chaining we have these expectations: 481 o Each control-plane instance manages a single level of hierarchy of 482 a single domain. 484 o Each control-plane is agnostic about other levels of hierarchy. 485 This aspect allows humans to reason about the system within a 486 single domain and allows control-plane algorithms to use only 487 domain-local inputs. Top-level control does not need visibility 488 to sub-domain policies, nor does sub-domain control need 489 visibility to higher-level policies. 491 o Sub-domain control-planes are agnostic about control-planes of 492 other sub-domains. This allows both humans and machines to 493 manipulate sub-domain policy without considering policies of other 494 domains. 496 Recall that the IBN acts as an SF in the higher-level domain 497 (receiving SF instructions from the higher-level control-plane) and 498 as a classifier in the lower-level domain (receiving classification 499 rules from the sub-domain control-plane). In this view, it is the 500 IBN that glues the layers together. 502 The above expectations are not intended to prohibit network-wide 503 control. A control hierarchy can be envisaged to distribute 504 information and instructions to multiple domains and sub-domains. 505 Control hierarchy is outside the scope of this document. 507 6. Acknowledgements 509 The concept of Hierarchical Service Path Domains was introduced in 510 draft-homma-sfc-forwarding-methods-analysis-01 511 [I-D.homma-sfc-forwarding-methods-analysis] as a means to improve 512 scalability of service chaining in large networks. 514 The authors would like to thank the following individuals for taking 515 the time to read and provide valuable feedback: 517 Ron Parker 519 Christian Jacquenet 521 Jie Cao 523 7. IANA Considerations 525 This memo includes no request to IANA. 527 8. Security Considerations 529 Hierarchical service function chaining makes use of service chaining 530 architecture, and hence inherits the security considerations 531 described in the architecture document. 533 Furthermore, hierarchical service function chaining inherits security 534 considerations of the data-plane protocols (e.g., NSH) and control- 535 plane protocols used to realize the solution. 537 The systems described in this document bear responsibility for 538 forwarding internet traffic. In some cases the systems are 539 responsible for maintaining separation of traffic in private 540 networks. 542 This document describes systems within different domains of 543 administration that must have consistent configurations in order to 544 properly forward traffic and to maintain private network separation. 545 Any protocol designed to distribute the configurations must be secure 546 from tampering. 548 All of the systems and protocols must be secure from modification by 549 untrusted agents. 551 9. References 553 9.1. Normative References 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, 557 DOI 10.17487/RFC2119, March 1997, 558 . 560 9.2. Informative References 562 [I-D.homma-sfc-forwarding-methods-analysis] 563 Homma, S., Kengo, K., Lopez, D., Stiemerling, M., and D. 564 Dolson, "Analysis on Forwarding Methods for Service 565 Chaining", draft-homma-sfc-forwarding-methods-analysis-01 566 (work in progress), January 2015. 568 [I-D.ietf-sfc-architecture] 569 Halpern, J. and C. Pignataro, "Service Function Chaining 570 (SFC) Architecture", draft-ietf-sfc-architecture-07 (work 571 in progress), March 2015. 573 [I-D.ietf-sfc-dc-use-cases] 574 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 575 Homma, "Service Function Chaining Use Cases In Data 576 Centers", draft-ietf-sfc-dc-use-cases-02 (work in 577 progress), January 2015. 579 [I-D.ietf-sfc-nsh] 580 Quinn, P. and U. Elzur, "Network Service Header", draft- 581 ietf-sfc-nsh-00 (work in progress), March 2015. 583 Appendix A. Examples of Hierarchical Service Function Chaining 585 The advantage of hierarchical service function chaining compared with 586 normal or flat service function chaining is that it can reduce the 587 management complexity significantly. This section discusses examples 588 that show those advantages. 590 A.1. Reducing the Number of Service Function Paths 592 In this case, hierarchical service function chaining is used to 593 simplify service function chaining management by reducing the number 594 of Service Function Paths. 596 As shown in Figure 3, there are two domains, each with different 597 concerns: a Security Domain that selects Service Functions based on 598 network conditions and an Optimization Domain that selects Service 599 Functions based on traffic protocol. 601 In this example there are five security functions deployed in the 602 Security Domain. The Security Domain operator wants to enforce the 603 five different security policies, and the Optimization Domain 604 operator wants to apply different optimizations (either cache or 605 video optimization) to each of these two types of traffic. If we use 606 flat SFC (normal branching), 10 SFPs are needed in each domain. In 607 contrast, if we use hierarchical SFC, only 5 SFPs in Security Domain 608 and 2 SFPs in Optimization Domain will be required, as shown in 609 Figure 4. 611 In the flat model, the number of SFPs is the product of the number of 612 functions in all of the domains. In the hSFC model, the number of 613 SFPs is the sum of the number of functions. For example, adding a 614 "bypass" path in the Optimization Domain would cause the flat model 615 to require 15 paths (5 more), but cause the hSFC model to require one 616 more path in the Optimization Domain. 618 . . . . . . . . . . . . . . . . . . . . . . . . . 619 . Security Domain . . Optimization Domain . 620 . . . . 621 . +-1---[ ]----------------->[Cache ]-------> 622 . | [ WAF ] . . . 623 . +-2-->[ ]----------------->[Video Opt.]----> 624 . | . . . 625 . +-3---[Anti ]----------------->[Cache ]-------> 626 . | [Virus] . . . 627 . +-4-->[ ]----------------->[Video Opt.]----> 628 . | . . . 629 . +-5-->[ ]----------------->[Cache ]-------> 630 [DPI]--->[CF]---| [ IPS ] . . . 631 . +-6-->[ ]----------------->[Video Opt.]----> 632 . | . . . 633 . +-7-->[ ]----------------->[Cache ]-------> 634 . | [ IDS ] . . . 635 . +-8-->[ ]----------------->[Video Opt.]----> 636 . | . . . 637 . +-9-->[Traffic]--------------->[Cache ]-------> 638 . | [Monitor] . . . 639 . +-10->[ ]--------------->[Video Opt.]----> 640 . . . . . . . . . . . . . . . . . . . . . . . . . 642 The classifier must select paths that determine the combination of 643 Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt, 644 3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5: IPS+Cache, 645 6:IPS+VideoOpt, 7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache, 646 10:TrafficMonitor+VideoOpt 648 Figure 3: Flat SFC (normal branching) 650 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651 . Security Domain . . Optimization Domain . 652 . . . . 653 [CF]---->[ [CF] IBN ]---------->[ [CF] IBN ]----> 654 . | ^ . . | ^ . 655 . +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ . 656 . | | . . | | . 657 . +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ . 658 . | | . . . 659 . +----->[ IPS ]-----+ . . . . . . . . . . . . . . . . 660 . | | . 661 . +----->[ IDS ]-----+ . 662 . | | . 663 . +-->[ Traffic ]----+ . 664 . [ Monitor ] . 665 . . . . . . . . . . . . . . . 667 Figure 4: Simplified path management with Hierarchical SFC 669 A.2. Managing a Distributed Data-Center Network 671 Hierarchical service function chaining can be used to simplify inter- 672 data-center SFC management. In the example of Figure 5, shown below, 673 there is a central data center (Central DC) and multiple local data 674 centers (Local DC#1, #2, #3) that are deployed in a geographically 675 distributed manner. All of the data centers are under a single 676 administrative domain. 678 The central DC may have some service functions that the local DC 679 needs, such that the local DC needs to chain traffic via the central 680 DC. This could be because: 682 o Some service functions are deployed as dedicated hardware 683 appliances, and there is a desire to lower the cost (both CAPEX 684 and OPEX) of deploying such service functions in all data centers. 686 o Some service functions are being trialed, introduced or otherwise 687 handle a relatively small amount of traffic. It may be cheaper to 688 manage these service functions in a single central data center and 689 steer packets to the central data center than to manage these 690 service functions in all data centers. 692 +-----------+ 693 |Central DC | 694 +-----------+ 695 ^ ^ ^ 696 | | | 697 .---|--|---|----. 698 / / | | \ 699 / / | \ \ 700 +-----+ / / | \ \ +-----+ 701 |Local| | / | \ | |Local| 702 |DC#1 |--|--. | .----|----|DC#3 | 703 +-----+ | | | +-----+ 704 \ | / 705 \ | / 706 \ | / 707 '----------------' 708 | 709 +-----+ 710 |Local| 711 |DC#2 | 712 +-----+ 714 Figure 5: Simplify inter-DC SFC management 716 For large data center operators, one local DC may have tens of 717 thousands of servers and hundred of thousands of virtual machines. 718 SFC can be used to manage user traffic. For example, SFC can be used 719 to classify user traffic based on service type, DDoS state etc. 721 In such large scale data center, using flat SFC is very complex, 722 requiring a super-controller to configure all data centers. For 723 example, any changes to Service Functions or Service Function Paths 724 in the central DC (e.g., deploying a new SF) would require updates to 725 all of the Service Function Paths in the local DCs accordingly. 726 Furthermore, requirements for symmetric paths add additional 727 complexity when flat SFC is used in this scenario. 729 Conversely, if using hierarchical SFC, each data center can be 730 managed independently to significantly reduce management complexity. 731 Service Function Paths between data centers can represent abstract 732 notions without regard to details within data centers. Independent 733 controllers can be used for the top level (getting packets to pass 734 the correct data centers) and local levels (getting packets to 735 specific SF instances). 737 Authors' Addresses 739 David Dolson 740 Sandvine 741 408 Albert Street 742 Waterloo, ON N2L 3V3 743 Canada 745 Phone: +1 519 880 2400 746 Email: ddolson@sandvine.com 748 Shunsuke Homma 749 NTT, Corp. 750 3-9-11, Midori-cho 751 Musashino-shi, Tokyo 180-8585 752 Japan 754 Email: homma.shunsuke@lab.ntt.co.jp 756 Diego R. Lopez 757 Telefonica I+D 758 Don Ramon de la Cruz, 82 759 Madrid 28006 760 Spain 762 Phone: +34 913 129 041 763 Email: diego.r.lopez@telefonica.com 765 Mohamed Boucadair 766 Orange Group 767 Rennes 35000 768 France 770 Email: mohamed.boucadair@orange.com 772 Dapeng Liu 773 Alibaba Group 774 Beijing 100022 775 China 777 Email: max.ldp@alibaba-inc.com