idnits 2.17.1 draft-dolson-sfc-hierarchical-02.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 6, 2015) is 3216 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Virus' is mentioned on line 615, but not defined == Missing Reference: 'Monitor' is mentioned on line 627, 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 (~~), 7 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: January 7, 2016 NTT 6 D. Lopez 7 Telefonica I+D 8 M. Boucadair 9 Orange Group 10 July 6, 2015 12 Hierarchical Service Chaining 13 draft-dolson-sfc-hierarchical-02 15 Abstract 17 Hierarchical Service Function Chaining (hSFC) is a network 18 architecture allowing an organization to compartmentalize a large- 19 scale network into multiple domains of administration. 21 The goals of hSFC are to make a large-scale network easier to reason 22 about, simpler to control and to support independent functional 23 groups within large operators. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 7, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Hierarchical Service Function Chaining (hSFC) . . . . . . . . 3 62 2.1. Top Level . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 6 65 3.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 7 66 3.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 7 67 3.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 8 68 3.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 9 69 3.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 9 70 4. Sub-domain Classifier . . . . . . . . . . . . . . . . . . . . 10 71 5. Control Plane Elements . . . . . . . . . . . . . . . . . . . 10 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 9.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Appendix A. Examples of Hierarchical Service Function Chaining . 13 79 A.1. Simplify SFC management . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 Service Function Chaining (SFC) is a technique for prescribing 85 differentiated traffic forwarding policies within the SFC domain. 86 SFC is described in detail in the SFC architecture document 87 [I-D.ietf-sfc-architecture], and is not repeated here. 89 In this document we consider the difficult problem of implementing 90 SFC across a large, geographically dispersed network comprised of 91 millions of hosts and thousands of network forwarding elements, 92 involving multiple operational teams (with varying functional 93 responsibilities). We expect asymmetrical routing is inherent in the 94 network, while recognizing that some Service Functions (SFs) require 95 bidirectional traffic for transport-layer sessions (e.g., NATs, 96 firewalls). We assume that some paths need to be selected on the 97 basis of application-specific data visible to the network, with 98 5-tuple stickiness to specific Service Function instances. 100 Note: in this document, the notion of the "path" of a packet is the 101 series of SF instances traversed by a packet. The means of 102 delivering packets between SFs (the forwarding mechanisms of the 103 underlay network) is not relevant to the current discussion. 105 Difficult problems are often made easier by decomposing them in a 106 hierarchical (nested) manner. So instead of considering an 107 omniscient SFC Control Plane that can manage (create, withdraw, 108 supervise, etc.) complete paths from one end of the network to the 109 other, we decompose the network into smaller sub-domains. Each sub- 110 domain may support a subset of the network applications or a subset 111 of the users. The criteria for determining decomposition into SFC- 112 enabled sub-domains are beyond the scope of this document. 114 Note that decomposing a network into multiple SFC-enabled domains 115 should permit end-to-end visibility of Service Functions and Service 116 Function Paths. Decomposition should also be implemented with 117 special care to ease monitoring and troubleshooting of the network as 118 a whole. 120 An example of simplifying a network by using multiple SF domains is 121 further discussed in [I-D.ietf-sfc-dc-use-cases]. 123 We assume the SF technology uses NSH [I-D.ietf-sfc-nsh] or a similar 124 labeling mechanism. 126 The "domains" discussed in this document are assumed to be under 127 control of a single organization, such that here is a strong trust 128 relationship between the domains. The intention of creating multiple 129 domains is to improve the ability to operate a network. It is 130 outside of the scope of the document to consider domains operated by 131 different organizations. 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 2. Hierarchical Service Function Chaining (hSFC) 141 A hierarchy has multiple levels. The top-most level encompasses the 142 entire network domain to be managed, and lower levels encompass 143 portions of the network. 145 2.1. Top Level 147 Considering the example in Figure 1, a top-level network domain 148 includes SFC components distributed over a wide area, including: 150 o classifiers (CFs), 152 o Service Function Forwarders (SFFs) and 154 o Sub-domains. 156 For the sake of clarity, components of the underlay network are not 157 shown; an underlay network is assumed to provide connectivity between 158 SFC components. 160 Top-level service function paths carry packets from classifiers 161 through a series of SFFs and sub-domains, with the operations within 162 sub-domains being opaque to the higher levels. 164 We expect the system to include a top-level control-plane having 165 responsibility for configuring forwarding and classification. The 166 top-level Service Chaining control-plane manages end-to-end service 167 chains and associated service function paths from network edge points 168 to sub-domains and configuring top-level classifiers at a coarse 169 level (e.g., based on source or destination host) to forward traffic 170 along paths that will transit appropriate sub-domains. The figure 171 shows one possible service chain passing from edge, through two sub- 172 domains, to network egress. The top-level control plane does NOT 173 configure classification or forwarding within the sub-domains. 175 At this network-wide level, the number of SFPs required is a linear 176 function of the number of ways in which a packet is required to 177 traverse different sub-domains and egress the network. Note that the 178 various paths which may be taken within a sub-domain are not 179 represented by distinct network-wide SFPs; specific policies at the 180 ingress nodes of each sub-domain bind flows to sub-domain paths. 182 Packets are classified at the edge of the network to select the paths 183 by which sub-domains are to be traversed. At the ingress of each 184 sub-domain, paths are reclassified to select the paths by which SFs 185 in the sub-domain are to be traversed. At the egress of each sub- 186 domain, packets are returned to the top-level paths. Contrast this 187 with an approach requiring the top-level classifier to select paths 188 to specify all of the SFs in each sub-domains. 190 It should be assumed that some service functions in the network 191 require bidirectional symmetry of paths (see more in Section 4). 192 Therefore the classifiers at the top level must be configured with 193 policies ensuring server-to-client packets take the reverse path of 194 client-to-server packet through sub-domains. (Recall the "path" 195 denotes the series of service functions; the precise physical network 196 path within the underlay network is not relevant here.) 198 +------------+ 199 |Sub-domain#1| 200 | in DC1 | 201 +----+-------+ 202 | 203 .---- SFF1 ------. +--+ 204 +--+ / / | \--|CF| 205 --->|CF|--/---->' | \ +--+ 206 +--+ / SC#1 | \ 207 | | | 208 | V .------>|---> 209 | / / | 210 \ | / / 211 +--+ \ | / / +--+ 212 |CF|---\ | / /---|CF| 213 +--+ '---- SFF2 ------' +--+ 214 | 215 +----+-------+ 216 |Sub-domain#2| 217 | in DC2 | 218 +------------+ 220 One path is shown from edge classifier to SFF1 to Sub-domain#1 221 (residing in data-center1) to SFF1 to SFF2 (residing in data-center 222 2) to Sub-domain#2 to SFF2 to network egress. 224 Figure 1: Network-wide view of Top Level of Hierarchy 226 2.2. Lower Levels 228 Each of the sub-domains in Figure 1 is an SFC domain. 230 Unlike the top level, however, data packets entering the sub-domain 231 are already encapsulated within SFC transport. Figure 2 shows a sub- 232 domain interfaced with a higher-level domain by means of an Internal 233 Boundary Node (IBN). It is the purpose of the IBN to remove packets 234 from the SFC encapsulation, apply Classification rules, and direct 235 the packets to the selected local service function paths terminating 236 at an egress IBN. The egress SFC Domain Gateway finally restores 237 packets to the original SFC transport and hands them off to SFFs. 239 Each sub-domain intersects a subset of the total paths that are 240 possible in the higher-level domain. An IBN is concerned with 241 higher-level paths, but only those traversing the sub-domain. A top- 242 level controller may configure the IBN as an SF (the IBN plays the SF 243 role in the top-level domain). 245 We expect each sub-domain to have a control-plane that can operate 246 independently of the top-level control-plane. The sub-domain 247 control-plane configures the classification and forwarding rules in 248 the sub-domain. The classification rules reside in the IBN, where 249 packets are moved from SFC encapsulation of the top-level domain to 250 and from SFC encapsulation of the lower-level domain. 252 +----+ +-----+ +----------------------+ +-----+ 253 | |SC#1| SFF | | IBN 1 | | SFF | 254 ->| |================* *===============> 255 | | +-----+ | # (in DC 1) # | +-----+ 256 | CF | | V # | 257 | | |+---+ +---+| Top domain 258 | | * * * * *||CF | * * * * * *|SFF|| * * * * * 259 | | * |+---+ +-+-+| * 260 +----+ * | | | | | | Sub * 261 * +-o-o--------------o-o-+ domain* 262 * SC#2 | |SC#1 ^ ^ #1 * 263 * +-----+ | | | * 264 * | V | | * 265 * | +---+ +------+ | | * 266 * | |SFF|->|SF#1.1|--+ | * 267 * | +---+ +------+ | * 268 * V | * 269 * +---+ +------+ +---+ +------+ * 270 * |SFF|->|SF#2.1|->|SFF|->|SF#2.2| * 271 * +---+ +------+ +---+ +------+ * 272 * * * * * * * * * * * * * * * * * * * * * * 274 *** Sub-domain boundary; === top-level chain; --- low-level chain. 276 Figure 2: Sub-domain within a higher-level domain 278 If desired, the pattern can be applied recursively. For example, 279 SF#1.1 in Figure 2 could be a sub-domain of the sub-domain. 281 3. Internal Boundary Node (IBN) 283 A network element termed "Internal Boundary Node" (IBN) bridges 284 packets between domains. It looks like an SF to the higher level, 285 and looks like a classifier and end-of-chain to the lower level. 287 To achieve the benefits of hierarchy, the IBN should be applying more 288 granular traffic classification rules at the lower level than the 289 traffic passed to it. This means that the number of SF Paths within 290 the lower level is greater than the number of SF Paths arriving to 291 the IBN. 293 The IBN is also the termination of lower-level SF paths. This is 294 because the packets exiting lower-level SF paths must be returned to 295 the higher-level SF paths and forwarded to the next hop in the 296 higher-level domain. 298 3.1. IBN Path Configuration 300 An operator of a lower-level SF Domain may be aware of which high- 301 level paths transit their domain, or they may wish to accept any 302 paths. 304 When packets enter the sub-domain, the Path Identifier and Path Index 305 are re-marked according to the path selected by the classifier. 307 After exiting a path in the sub-domain, packets can be restored to an 308 upper-level SF path by these methods: 310 1. Stateful per flow, 312 2. Pushing path identifier into metadata, 314 3. Using unique lower-level paths per upper-level path. 316 3.1.1. Flow-Stateful IBN 318 An IBN can be flow-aware, returning packets to the correct higher- 319 level SF path on the basis of 5-tuple of packets exiting the lower- 320 level SF paths. 322 When packets are received by the IBN on a higher-level path, the 323 encapsulated packets are parsed for IP and transport-layer (TCP or 324 UDP) coordinates. State is created, indexed by the 5-tuple of 325 {source-IP, destination-IP, source-port, destination-port and 326 transport protocol}. The state contains critical fields of the 327 encapsulating SFC header (or perhaps the entire header). 329 The simplest approach has the packets return to the same IBN at the 330 end of the chain that classified the packet at the start of the 331 chain. This is because the required 5-tuple state is rapidly 332 changing and most efficiently kept locally. If the packet is 333 returned to a different IBN for egress, 5-tuple state must be 334 synchronized between the IBNs. 336 When a packet returns to the IBN at the end of a chain, the SFC 337 header is removed, the packet is parsed for IP and transport-layer 338 coordinates, and state is retrieved by the 5-tuple of the packet. 339 The state contains the information required to forward the packet 340 within the higher-level service chain. 342 State cannot be created by packets arriving from the lower-level 343 chain; when state cannot be found for such packets, they MUST be 344 dropped. 346 This stateful approach is limited to use with SFs that retain the 347 5-tuple of the packet. This approach cannot be used with SFs that 348 modify the 5-tuple (e.g., as done by a NAT) or otherwise create 349 packets for new 5-tuples other than those received (e.g., as an HTTP 350 cache might do to retrieve content on behalf of the original flow). 351 In both cases, the fundamental problem is the inability to forward 352 packets when state cannot be found for the packet 5-tuples. 354 In the stateful approach, there are issues caused by the state, such 355 as how long the state should be maintained (it MUST time out 356 eventually), as well as whether the state needs to be replicated to 357 other devices to create a highly available network. 359 It is valid to consider the state disposable after failure, since it 360 can be re-created by each new packet arriving from the higher-level 361 domain. For example, if an IBN loses all flow state, the state is 362 re-created by an end-point retransmitting a TCP packet. 364 If an SFC domain handles multiple network regions (e.g., multiple 365 private networks), the 5-tuple may be augmented with a 6th parameter, 366 perhaps using some metadata to identify the network region. 368 In this stateful approach, it is not necessary for the sub-domain's 369 control-plane to modify paths when higher-level paths are changed. 370 The complexity of the higher-level domain does not cause complexity 371 in the lower-level domain. 373 3.1.2. Encoding Upper-Level Paths in Metadata 375 An IBN can push the upper-level service path identifier (SPI) and 376 service index (SI) (or encoding thereof) into a metadata field of the 377 lower-level encapsulation (e.g., placing upper-level path information 378 into a metadata field of NSH). When packets exit the lower-level 379 path, the upper-level SPI and SI can be restored from the metadata 380 retrieved from the packet. 382 This approach requires the SFs in the path to be capable of 383 forwarding the metadata and appropriately attaching metadata to any 384 packets injected for a flow. 386 Using new metadata may inflate packet size when variable-length 387 metadata (type 2 from NSH [I-D.ietf-sfc-nsh]) is used. 389 It is conceivable that the MD-type 1 Mandatory Context Header fields 390 of NSH [I-D.ietf-sfc-nsh] are not all relevant to the lower-level 391 domain. In this case, one of the metadata slots of the Mandatory 392 Context Header could be repurposed within the lower-level domain, and 393 restored when leaving. 395 In this metadata approach, it is not necessary for the sub-domain's 396 controller to modify paths when higher-level paths are changed. The 397 complexity of the higher-level domain does not cause complexity in 398 the lower-level domain. 400 3.1.3. Using Unique Paths per Upper-Level Path 402 In this approach, paths within the sub-domain are constrained so that 403 a path identifier (of the sub-domain) unambiguously indicates the 404 egress path (of the upper domain). This allows the original path 405 information to be restored at sub-domain egress from a look-up table 406 using the sub-domain path identifier. 408 Whenever the upper-level domain provisions a path via the lower-level 409 domain, the lower-level domain controller must provision 410 corresponding paths to traverse the lower-level domain. 412 A down-side of this approach is that the number of paths in the 413 lower-level domain is multiplied by the number of paths in the 414 higher-level domain that traverse the lower-level domain. I.e., a 415 sub-path must be created for each combination of upper Path 416 identifier and lower path. 418 3.2. Gluing Levels Together 420 The path identifier or metadata on a packet received by the IBN may 421 be used as input to reclassification and path selection within the 422 lower-level domain. 424 In some cases the meanings of the various path IDs and metadata must 425 be coordinated between domains. 427 One approach is to use well-known identifier values in metadata, 428 communicated by some organizational registry. 430 Another approach is to use well-known labels for path identifiers or 431 metadata, as an indirection to the actual identifiers. The actual 432 identifiers can be assigned by control-plane systems. For example, a 433 sub-domain classifier could have a policy, "if pathID=classA then 434 chain packet to path 1234"; the higher-level controller would be 435 expected to configure the concrete higher-level pathID for classA. 437 4. Sub-domain Classifier 439 Within the sub-domain (referring to Figure 2), after the IBN removes 440 higher-level encapsulation from incoming packets, it sends the 441 packets to the classifier, which selects the encapsulation for the 442 packet within the sub-domain. 444 One of the goals of the hierarchical approach is to make it easy to 445 have transport-flow-aware service chaining with bidirectional paths. 446 For example, it is desired that for each TCP flow, the client-to- 447 server packets traverse the same SFs as the server-to-client packets, 448 but in the opposite sequence. We call this bidirectional symmetry. 449 If bidirectional symmetry is required, it is the responsibility of 450 the control-plane to be aware of symmetric paths and configure the 451 classifier to chain the traffic in a symmetric manner. 453 Another goal of the hierarchical approach is to simplify the 454 mechanisms of scaling in and scaling out service functions. All of 455 the complexities of load-balancing among multiple SFs can be handled 456 within a sub-domain, under control of the classifier, allowing the 457 higher-level domain to be oblivious to the existence of multiple SF 458 instances. 460 Considering the requirements of bidirectional symmetry and load- 461 balancing, it is useful to have all packets entering a sub-domain to 462 be received by the same classifier or a coordinated cluster of 463 classifiers. There are both stateful and stateless approaches to 464 ensuring bidirectional symmetry. 466 5. Control Plane Elements 468 Controllers have been mentioned in this document without much 469 explanation. Although control protocols have not yet been 470 standardized, from the point of view of hierarchical service chaining 471 we have these expectations: 473 o Each control-plane instance manages a single level of hierarchy of 474 a single domain. 476 o Each control-plane is agnostic about other levels of hierarchy. 477 This aspect allows humans to reason about the system within a 478 single domain and allows control-plane algorithms to use only 479 domain-local inputs. Top-level control does not need visibility 480 to sub-domain policies, nor does sub-domain control need 481 visibility to higher-level policies. 483 o Sub-domain control-planes are agnostic about control-planes of 484 other sub-domains. This allows both humans and machines to 485 manipulate sub-domain policy without considering policies of other 486 domains. 488 Recall that the IBN acts as an SF in the higher-level domain 489 (receiving SF instructions from the higher-level control-plane) and 490 as a classifier in the lower-level domain (receiving classification 491 rules from the sub-domain control-plane). In this view, it is the 492 IBN that glues the layers together. 494 The above expectations are not intended to prohibit network-wide 495 control. A control hierarchy can be envisaged to distribute 496 information and instructions to multiple domains and sub-domains. 497 Control hierarchy is outside the scope of this document. 499 6. Acknowledgements 501 The concept of Hierarchical Service Path Domains was introduced in 502 draft-homma-sfc-forwarding-methods-analysis-01 503 [I-D.homma-sfc-forwarding-methods-analysis] as a means to improve 504 scalability of service chaining in large networks. 506 The authors would like to thank the following individuals for taking 507 the time to read and provide valuable feedback: 509 Ron Parker 511 Christian Jacquenet 513 Dapeng Liu 515 7. IANA Considerations 517 This memo includes no request to IANA. 519 8. Security Considerations 521 Hierarchical service chaining makes use of service chaining 522 architecture, and hence inherits the security considerations 523 described in the architecture document. 525 Furthermore, hierarchical service chaining inherits security 526 considerations of the data-plane protocols (e.g., NSH) and control- 527 plane protocols used to realize the solution. 529 The systems described in this document bear responsibility for 530 forwarding internet traffic. In some cases the systems are 531 responsible for maintaining separation of traffic in private 532 networks. 534 This document describes systems within different domains of 535 administration that must have consistent configurations in order to 536 properly forward traffic and to maintain private network separation. 537 Any protocol designed to distribute the configurations must be secure 538 from tampering. 540 All of the systems and protocols must be secure from modification by 541 untrusted agents. 543 9. References 545 9.1. Normative References 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 9.2. Informative References 552 [I-D.homma-sfc-forwarding-methods-analysis] 553 Homma, S., Kengo, K., Lopez, D., Stiemerling, M., and D. 554 Dolson, "Analysis on Forwarding Methods for Service 555 Chaining", draft-homma-sfc-forwarding-methods-analysis-01 556 (work in progress), January 2015. 558 [I-D.ietf-sfc-architecture] 559 Halpern, J. and C. Pignataro, "Service Function Chaining 560 (SFC) Architecture", draft-ietf-sfc-architecture-07 (work 561 in progress), March 2015. 563 [I-D.ietf-sfc-dc-use-cases] 564 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 565 Homma, "Service Function Chaining Use Cases In Data 566 Centers", draft-ietf-sfc-dc-use-cases-02 (work in 567 progress), January 2015. 569 [I-D.ietf-sfc-nsh] 570 Quinn, P. and U. Elzur, "Network Service Header", draft- 571 ietf-sfc-nsh-00 (work in progress), March 2015. 573 Appendix A. Examples of Hierarchical Service Function Chaining 575 The advantage of hierarchical service function chaining compared with 576 normal or flat service function chaining is that it can reduce the 577 management complexity significantly. This section discusses examples 578 that show the advantage of hierarchical service chaining. 580 A.1. Simplify SFC management 582 In this use case, hierarchical service chaining is used to simplify 583 service function chaining management by reducing the number of 584 Service Function Paths. 586 As shown in Figure 3, there are two domains each with different 587 concerns: a Security Domain that selects Service Functions based on 588 network conditions and an Optimization Domain that selects Service 589 Functions based on traffic protocol. 591 There are five security functions deployed in the Security Domain. 592 The Security Domain operator wants to enforce the five different 593 security policies, and the Optimization Domain operator wants to 594 apply different optimization (either cache or video optimization to 595 each of these two types of traffic. If we use flat SFC (normal 596 branching), 10 SFPs are needed in each domain. In contrast, if we 597 use hierarchical SFC, only 5 SFPs in Security Domain and 2 SFPs in 598 Optimization Domain will be required, as shown in Figure 4. 600 In the flat model, the number of SFPs is the product of the number of 601 functions in all of the domains. In the hSFC model, the number of 602 SFPs is the sum of the number of functions. For example, adding a 603 "bypass" path in the Optimization Domain would cause the flat model 604 to require 15 paths (5 more), but cause the hSFC model to require one 605 more path in the Optimization Domain. 607 . . . . . . . . . . . . . . . . . . . . . . . . . 608 . Security Domain . . Optimization Domain . 609 . . . . 610 . +-1---[ ]----------------->[Cache ]-------> 611 . | [ WAF ] . . . 612 . +-2-->[ ]----------------->[Video Opt.]----> 613 . | . . . 614 . +-3---[Anti ]----------------->[Cache ]-------> 615 . | [Virus] . . . 616 . +-4-->[ ]----------------->[Video Opt.]----> 617 . | . . . 618 . +-5-->[ ]----------------->[Cache ]-------> 619 [DPI]--->[CF]---| [ IPS ] . . . 620 . +-6-->[ ]----------------->[Video Opt.]----> 621 . | . . . 622 . +-7-->[ ]----------------->[Cache ]-------> 623 . | [ IDS ] . . . 624 . +-8-->[ ]----------------->[Video Opt.]----> 625 . | . . . 626 . +-9-->[Traffic]--------------->[Cache ]-------> 627 . | [Monitor] . . . 628 . +-10->[ ]--------------->[Video Opt.]----> 629 . . . . . . . . . . . . . . . . . . . . . . . . . 631 The classifier must select paths that determine the combination of 632 Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt, 633 3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5: IPS+Cache, 634 6:IPS+VideoOpt, 7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache, 635 10:TrafficMonitor+VideoOpt 637 Figure 3: Flat SFC (Normal Branching) 639 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640 . Security Domain . . Optimization Domain . 641 . . . . 642 [CF]---->[ DPI(Sub-domain GW)]------[CF]->[ Sub-domain GW ]----> 643 . | ^ . . | ^ . 644 . +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ . 645 . | | . . | | . 646 . +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ . 647 . | | . . . 648 . +----->[ IPS ]-----+ . . . . . . . . . . . . . . . . 649 . | | . 650 . +----->[ IDS ]-----+ . 651 . | | . 652 . +-->[ Traffic ]----+ . 653 . [ Monitor ] . 654 . . . . . . . . . . . . . . . 656 Figure 4: Simplified Path Management with Hierarchical SFC 658 Authors' Addresses 660 David Dolson 661 Sandvine 662 408 Albert Street 663 Waterloo, ON N2L 3V3 664 Canada 666 Phone: +1 519 880 2400 667 Email: ddolson@sandvine.com 669 Shunsuke Homma 670 NTT, Corp. 671 3-9-11, Midori-cho 672 Musashino-shi, Tokyo 180-8585 673 Japan 675 Email: homma.shunsuke@lab.ntt.co.jp 677 Diego R. Lopez 678 Telefonica I+D 679 Don Ramon de la Cruz, 82 680 Madrid 28006 681 Spain 683 Phone: +34 913 129 041 684 Email: diego.r.lopez@telefonica.com 685 Mohamed Boucadair 686 Orange Group 687 Rennes 35000 688 France 690 Email: mohamed.boucadair@orange.com