idnits 2.17.1 draft-dolson-sfc-hierarchical-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2016) is 2966 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Virus' is mentioned on line 698, but not defined == Missing Reference: 'Monitor' is mentioned on line 710, but not defined == Missing Reference: 'CF' is mentioned on line 725, but not defined == Outdated reference: A later version (-05) exists of draft-homma-sfc-forwarding-methods-analysis-01 == 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-02 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: September 8, 2016 NTT 6 D. Lopez 7 Telefonica I+D 8 M. Boucadair 9 Orange Group 10 D. Liu 11 Alibaba Group 12 T. Ao 13 ZTE Corporation 14 March 7, 2016 16 Hierarchical Service Function Chaining 17 draft-dolson-sfc-hierarchical-05 19 Abstract 21 Hierarchical Service Function Chaining (hSFC) is a network 22 architecture allowing an organization to compartmentalize a large- 23 scale network into multiple domains of administration. 25 The goals of hSFC are to make a large-scale network easier to reason 26 about, simpler to control and to support independent functional 27 groups within large operators. 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 September 8, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. Hierarchical Service Function Chaining (hSFC) . . . . . . . . 4 66 2.1. Top Level . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 6 68 3. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 7 69 3.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 8 70 3.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 8 71 3.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 9 72 3.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 10 73 3.1.4. Nesting Upper-Level NSH within Lower-Level NSH . . . 10 74 3.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 11 75 3.3. Decrementing Service Index . . . . . . . . . . . . . . . 12 76 4. Sub-domain Classifier . . . . . . . . . . . . . . . . . . . . 12 77 5. Control Plane Elements . . . . . . . . . . . . . . . . . . . 13 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 9.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Appendix A. Examples of Hierarchical Service Function Chaining . 15 85 A.1. Reducing the Number of Service Function Paths . . . . . . 15 86 A.2. Managing a Distributed Data-Center Network . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 Service Function Chaining (SFC) is a technique for prescribing 92 differentiated traffic forwarding policies within the SFC domain. 94 SFC is described in detail in the SFC architecture document 95 [RFC7665], and is not repeated here. 97 In this document we consider the difficult problem of implementing 98 SFC across a large, geographically dispersed network comprised of 99 millions of hosts and thousands of network forwarding elements, 100 involving multiple operational teams (with varying functional 101 responsibilities). We expect asymmetrical routing is inherent in the 102 network, while recognizing that some Service Functions (SFs) require 103 bidirectional traffic for transport-layer sessions (e.g., NATs, 104 firewalls). We assume that some Service Function Paths (SFPs) need 105 to be selected on the basis of application-specific data visible to 106 the network, with transport-layer coordinate (typically, 5-tuple) 107 stickiness to specific Service Function instances. 109 Note: in this document, the notion of the "path" of a packet is the 110 series of SF instances traversed by a packet. The means of 111 delivering packets between SFs (the forwarding mechanisms of the 112 underlay network) is not relevant to the current discussion. 114 Difficult problems are often made easier by decomposing them in a 115 hierarchical (nested) manner. So instead of considering an 116 omniscient SFC Control Plane that can manage (create, withdraw, 117 supervise, etc.) complete SFPs from one end of the network to the 118 other, we decompose the network into smaller sub-domains. Each sub- 119 domain may support a subset of the network applications or a subset 120 of the users. The criteria for determining decomposition into SFC- 121 enabled sub-domains are beyond the scope of this document. 123 Note that decomposing a network into multiple SFC-enabled domains 124 should permit end-to-end visibility of Service Functions and Service 125 Function Paths. Decomposition should also be implemented with 126 special care to ease monitoring and troubleshooting of the network as 127 a whole. 129 An example of simplifying a network by using multiple SF domains is 130 further discussed in [I-D.ietf-sfc-dc-use-cases]. 132 We assume the SF technology uses NSH [I-D.ietf-sfc-nsh] or a similar 133 labeling mechanism. 135 The "domains" discussed in this document are assumed to be under 136 control of a single organization, such that there is a strong trust 137 relationship between the domains. The intention of creating multiple 138 domains is to improve the ability to operate a network. It is 139 outside of the scope of the document to consider domains operated by 140 different organizations. 142 1.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 2. Hierarchical Service Function Chaining (hSFC) 150 A hierarchy has multiple levels. The top-most level encompasses the 151 entire network domain to be managed, and lower levels encompass 152 portions of the network. 154 2.1. Top Level 156 Considering the example in Figure 1, a top-level network domain 157 includes SFC components distributed over a wide area, including: 159 o classifiers (CFs), 161 o Service Function Forwarders (SFFs) and 163 o Sub-domains. 165 For the sake of clarity, components of the underlay network are not 166 shown; an underlay network is assumed to provide connectivity between 167 SFC components. 169 Top-level service function paths carry packets from classifiers 170 through a series of SFFs and sub-domains, with the operations within 171 sub-domains being opaque to the higher levels. 173 We expect the system to include a top-level control-plane having 174 responsibility for configuring forwarding and classification. The 175 top-level Service Chaining control-plane manages end-to-end service 176 chains and associated service function paths from network edge points 177 to sub-domains and configuring top-level classifiers at a coarse 178 level (e.g., based on source or destination host) to forward traffic 179 along paths that will transit appropriate sub-domains. The figure 180 shows one possible service chain passing from edge, through two sub- 181 domains, to network egress. The top-level control plane does NOT 182 configure classification or forwarding within the sub-domains. 184 At this network-wide level, the number of SFPs required is a linear 185 function of the number of ways in which a packet is required to 186 traverse different sub-domains and egress the network. Note that the 187 various paths which may be taken within a sub-domain are not 188 represented by distinct network-wide SFPs; specific policies at the 189 ingress nodes of each sub-domain bind flows to sub-domain paths. 191 Packets are classified at the edge of the network to select the paths 192 by which sub-domains are to be traversed. At the ingress of each 193 sub-domain, paths are reclassified to select the paths by which SFs 194 in the sub-domain are to be traversed. At the egress of each sub- 195 domain, packets are returned to the top-level paths. Contrast this 196 with an approach requiring the top-level classifier to select paths 197 to specify all of the SFs in each sub-domain. 199 It should be assumed that some service functions in the network 200 require bidirectional symmetry of paths (see more in Section 4). 201 Therefore the classifiers at the top level must be configured with 202 policies ensuring server-to-client packets take the reverse path of 203 client-to-server packet through sub-domains. (Recall the "path" 204 denotes the series of service functions; the precise physical network 205 path within the underlay network is not relevant here.) 207 +------------+ 208 |Sub-domain#1| 209 | in DC1 | 210 +----+-------+ 211 | 212 .---- SFF1 ------. +--+ 213 +--+ / / | \--|CF| 214 --->|CF|--/---->' | \ +--+ 215 +--+ / SC#1 | \ 216 | | | 217 | V .------>|---> 218 | / / | 219 \ | / / 220 +--+ \ | / / +--+ 221 |CF|---\ | / /---|CF| 222 +--+ '---- SFF2 ------' +--+ 223 | 224 +----+-------+ 225 |Sub-domain#2| 226 | in DC2 | 227 +------------+ 229 One path is shown from edge classifier to SFF1 to Sub-domain#1 230 (residing in data-center1) to SFF1 to SFF2 (residing in data-center 231 2) to Sub-domain#2 to SFF2 to network egress. 233 Figure 1: Network-wide view of top level of hierarchy 235 2.2. Lower Levels 237 Each of the sub-domains in Figure 1 is an SFC domain. 239 Unlike the top level, however, data packets entering the sub-domain 240 are already encapsulated within SFC transport. Figure 2 shows a sub- 241 domain interfaced with a higher-level domain by means of an Internal 242 Boundary Node (IBN). It is the purpose of the IBN to remove packets 243 from the SFC encapsulation, apply Classification rules, and direct 244 the packets to the selected local service function paths terminating 245 at an egress IBN. The egress IBN finally restores packets to the 246 original SFC transport and hands them off to SFFs. 248 Each sub-domain intersects a subset of the total paths that are 249 possible in the higher-level domain. An IBN is concerned with 250 higher-level paths, but only those traversing the sub-domain. A top- 251 level controller may configure the IBN as an SF (the IBN plays the SF 252 role in the top-level domain). 254 We expect each sub-domain to have a control-plane that can operate 255 independently of the top-level control-plane. The sub-domain 256 control-plane configures the classification and forwarding rules in 257 the sub-domain. The classification rules reside in the IBN, where 258 packets are moved from SFC encapsulation of the top-level domain to 259 and from SFC encapsulation of the lower-level domain. 261 +----+ +-----+ +----------------------+ +-----+ 262 | |SC#1| SFF | | IBN 1 | | SFF | 263 ->| |================* *===============> 264 | | +-----+ | # (in DC 1) # | +-----+ 265 | CF | | V # | 266 | | |+---+ +---+| Top domain 267 | | * * * * *||CF | * * * * * *|SFF|| * * * * * 268 | | * |+---+ +-+-+| * 269 +----+ * | | | | | | Sub * 270 * +-o-o--------------o-o-+ domain* 271 * SC#2 | |SC#1 ^ ^ #1 * 272 * +-----+ | | | * 273 * | V | | * 274 * | +---+ +------+ | | * 275 * | |SFF|->|SF#1.1|--+ | * 276 * | +---+ +------+ | * 277 * V | * 278 * +---+ +------+ +---+ +------+ * 279 * |SFF|->|SF#2.1|->|SFF|->|SF#2.2| * 280 * +---+ +------+ +---+ +------+ * 281 * * * * * * * * * * * * * * * * * * * * * * 283 *** Sub-domain boundary; === top-level chain; --- low-level chain. 285 Figure 2: Sub-domain within a higher-level domain 287 If desired, the pattern can be applied recursively. For example, 288 SF#1.1 in Figure 2 could be a sub-domain of the sub-domain. 290 3. Internal Boundary Node (IBN) 292 A network element termed "Internal Boundary Node" (IBN) bridges 293 packets between domains. It looks like an SF to the higher level, 294 and looks like a classifier and end-of-chain to the lower level. 296 To achieve the benefits of hierarchy, the IBN should be applying more 297 granular traffic classification rules at the lower level than the 298 traffic passed to it. This means that the number of SF Paths within 299 the lower level is greater than the number of SF Paths arriving to 300 the IBN. 302 The IBN is also the termination of lower-level SF paths. This is 303 because the packets exiting lower-level SF paths must be returned to 304 the higher-level SF paths and forwarded to the next hop in the 305 higher-level domain. 307 3.1. IBN Path Configuration 309 An operator of a lower-level SF Domain may be aware of which high- 310 level paths transit their domain, or they may wish to accept any 311 paths. 313 When packets enter the sub-domain, the Service Path Identifier (SPI) 314 and Service Index (SI) are re-marked according to the path selected 315 by the classifier. 317 After exiting a path in the sub-domain, packets can be restored to an 318 original upper-level SF path by these methods: 320 1. Saving SPI and SI in transport-layer flow state, 322 2. Pushing SPI and SI into metadata, 324 3. Using unique lower-level paths per upper-level path coordinates. 326 4. Nesting NSH headers, encapsulating the higher-level NSH headers 327 within the lower-level NSH headers. 329 3.1.1. Flow-Stateful IBN 331 An IBN can be flow-aware, returning packets to the correct higher- 332 level SF path on the basis of the transport-layer coordinates 333 (typically, a 5-tuple) of packets exiting the lower-level SF paths. 335 When packets are received by the IBN on a higher-level path, the 336 encapsulated packets are parsed for IP and transport-layer (TCP, 337 UDP...) coordinates. State is created, indexed by these coordinates 338 (a 5-tuple of {source-IP, destination-IP, source-port, destination- 339 port and transport protocol} in a typical case). The state contains 340 critical fields of the encapsulating SFC header (or perhaps the 341 entire header). 343 The simplest approach has the packets return to the same IBN at the 344 end of the chain that classified the packet at the start of the 345 chain. This is because the required transport-coordinates state is 346 rapidly changing and most efficiently kept locally. If the packet is 347 returned to a different IBN for egress, transport-coordinates state 348 must be synchronized between the IBNs. 350 When a packet returns to the IBN at the end of a chain, the SFC 351 header is removed, the packet is parsed for IP and transport-layer 352 coordinates, and state is retrieved from them. The state contains 353 the information required to forward the packet within the higher- 354 level service chain. 356 State cannot be created by packets arriving from the lower-level 357 chain; when state cannot be found for such packets, they MUST be 358 dropped. 360 This stateful approach is limited to use with SFs that retain the 361 transport coordinates of the packet. This approach cannot be used 362 with SFs that modify those coordinates (e.g., as done by a NAT) or 363 otherwise create packets for new coordinates other than those 364 received (e.g., as an HTTP cache might do to retrieve content on 365 behalf of the original flow). In both cases, the fundamental problem 366 is the inability to forward packets when state cannot be found for 367 the packet transport-layer coordinates. 369 In the stateful approach, there are issues caused by having state, 370 such as how long the state should be maintained (it MUST time out 371 eventually), as well as whether the state needs to be replicated to 372 other devices to create a highly available network. 374 It is valid to consider the state to be disposable after failure, 375 since it can be re-created by each new packet arriving from the 376 higher-level domain. For example, if an IBN loses all flow state, 377 the state is re-created by an end-point retransmitting a TCP packet. 379 If an SFC domain handles multiple network regions (e.g., multiple 380 private networks), the coordinates may be augmented with additional 381 parameters, perhaps using some metadata to identify the network 382 region. 384 In this stateful approach, it is not necessary for the sub-domain's 385 control-plane to modify paths when higher-level paths are changed. 386 The complexity of the higher-level domain does not cause complexity 387 in the lower-level domain. 389 3.1.2. Encoding Upper-Level Paths in Metadata 391 An IBN can push the upper-level Service Path Identifier (SPI) and 392 Service Index (SI) (or encoding thereof) into a metadata field of the 393 lower-level encapsulation (e.g., placing upper-level path information 394 into a metadata field of NSH). When packets exit the lower-level 395 path, the upper-level SPI and SI can be restored from the metadata 396 retrieved from the packet. 398 This approach requires the SFs in the path to be capable of 399 forwarding the metadata and appropriately attaching metadata to any 400 packets injected for a flow. 402 Using new metadata may inflate packet size when variable-length 403 metadata (type 2 from NSH [I-D.ietf-sfc-nsh]) is used. 405 It is conceivable that the MD-type 1 Mandatory Context Header fields 406 of NSH [I-D.ietf-sfc-nsh] are not all relevant to the lower-level 407 domain. In this case, one of the metadata slots of the Mandatory 408 Context Header could be repurposed within the lower-level domain, and 409 restored when leaving. 411 In this metadata approach, it is not necessary for the sub-domain's 412 controller to modify paths when higher-level paths are changed. The 413 complexity of the higher-level domain does not cause complexity in 414 the lower-level domain. 416 3.1.3. Using Unique Paths per Upper-Level Path 418 In this approach, paths within the sub-domain are constrained so that 419 a SPI (of the sub-domain) unambiguously indicates the egress SPI and 420 SI (of the upper domain). This allows the original path information 421 to be restored at sub-domain egress from a look-up table using the 422 sub-domain SPI. 424 Whenever the upper-level domain provisions a path via the lower-level 425 domain, the lower-level domain controller must provision 426 corresponding paths to traverse the lower-level domain. 428 A down-side of this approach is that the number of paths in the 429 lower-level domain is multiplied by the number of paths in the 430 higher-level domain that traverse the lower-level domain. I.e., a 431 sub-path must be created for each combination of upper SPI/SI and 432 lower chain. 434 3.1.4. Nesting Upper-Level NSH within Lower-Level NSH 436 In this approach, when packets arrive at the IBN in the top-level 437 domain, the classifier in the IBN determines the path for the lower- 438 level domain and pushes the new NSH header in front of the original 439 NSH header. 441 As shown in figure Figure 3 the Lower-NSH Header used to forward 442 packets in the lower-level domain precedes the Upper-NSH Header from 443 the top-level domain. 445 +------------------+ 446 | Overlay Header | 447 +------------------+ 448 | Lower-NSH Header | 449 +------------------+ 450 | Upper-NSH Header | 451 +------------------+ 452 | Original Packet | 453 +------------------+ 455 Figure 3: Encapsulation of NSH within NSH 457 The traffic with the above stack of two-layer-NSH header is to be 458 forwarded according to the Lower-NSH header in the lower-level SFC 459 domain. The Upper-NSH header is preserved in the packets but not 460 used for forwarding. At the last SFF of the Service Function Chain 461 of the lower-level domain (which resides in the IBN), the Lower-NSH 462 header is removed from the packet, and then the packet is forwarded 463 by the IBN to an SFF of the upper-level domain, which will be 464 forwarded according to the Upper-NSH header. 466 With such encapsulation, Upper-NSH information is carried along the 467 extent of the lower-level chain without modification. 469 A benefit of this approach is that it does not require state in the 470 IBN or configuration to encode fields in meta-data. 472 However, the down-side is it does require SFs in the lower-level 473 domain to be able to parse multiple layers of NSH. If the SF injects 474 packets, it must also be able to deal with adding appropriate 475 multiple layers of headers to injected packets. 477 This approach requires a new Next Protocol value to be allocated for 478 NSH. 480 3.2. Gluing Levels Together 482 The SPI or metadata on a packet received by the IBN may be used as 483 input to reclassification and path selection within the lower-level 484 domain. 486 In some cases the meanings of the various path IDs and metadata must 487 be coordinated between domains. 489 One approach is to use well-known identifier values in metadata, 490 communicated by some organizational registry. 492 Another approach is to use well-known labels for chain identifiers or 493 metadata, as an indirection to the actual identifiers. The actual 494 identifiers can be assigned by control-plane systems. For example, a 495 sub-domain classifier could have a policy, "if pathID=classA then 496 chain packet to path 1234"; the higher-level controller would be 497 expected to configure the concrete higher-level pathID for classA. 499 3.3. Decrementing Service Index 501 Because the IBN acts as a Service Function to the higher-level 502 domain, it must decrement the Service Index in the NSH headers of the 503 higher-level path. 505 A good strategy seems to be to do this when the packet is first 506 received by the IBN, before applying any of the strategies of 507 Section 3.1, immediately prior to classification. 509 4. Sub-domain Classifier 511 Within the sub-domain (referring to Figure 2), after the IBN removes 512 higher-level encapsulation from incoming packets, it sends the 513 packets to the classifier, which selects the encapsulation for the 514 packet within the sub-domain. 516 One of the goals of the hierarchical approach is to make it easy to 517 have transport-flow-aware service chaining with bidirectional paths. 518 For example, it is desired that for each TCP flow, the client-to- 519 server packets traverse the same SFs as the server-to-client packets, 520 but in the opposite sequence. We call this bidirectional symmetry. 521 If bidirectional symmetry is required, it is the responsibility of 522 the control-plane to be aware of symmetric paths and configure the 523 classifier to chain the traffic in a symmetric manner. 525 Another goal of the hierarchical approach is to simplify the 526 mechanisms of scaling in and scaling out service functions. All of 527 the complexities of load-balancing among multiple SFs can be handled 528 within a sub-domain, under control of the classifier, allowing the 529 higher-level domain to be oblivious to the existence of multiple SF 530 instances. 532 Considering the requirements of bidirectional symmetry and load- 533 balancing, it is useful to have all packets entering a sub-domain to 534 be received by the same classifier or a coordinated cluster of 535 classifiers. There are both stateful and stateless approaches to 536 ensuring bidirectional symmetry. 538 5. Control Plane Elements 540 Controllers have been mentioned in this document without much 541 explanation. Although control protocols have not yet been 542 standardized, from the point of view of hierarchical service function 543 chaining we have these expectations: 545 o Each control-plane instance manages a single level of hierarchy of 546 a single domain. 548 o Each control-plane is agnostic about other levels of hierarchy. 549 This aspect allows humans to reason about the system within a 550 single domain and allows control-plane algorithms to use only 551 domain-local inputs. Top-level control does not need visibility 552 to sub-domain policies, nor does sub-domain control need 553 visibility to higher-level policies. 555 o Sub-domain control-planes are agnostic about control-planes of 556 other sub-domains. This allows both humans and machines to 557 manipulate sub-domain policy without considering policies of other 558 domains. 560 Recall that the IBN acts as an SF in the higher-level domain 561 (receiving SF instructions from the higher-level control-plane) and 562 as a classifier in the lower-level domain (receiving classification 563 rules from the sub-domain control-plane). In this view, it is the 564 IBN that glues the layers together. 566 The above expectations are not intended to prohibit network-wide 567 control. A control hierarchy can be envisaged to distribute 568 information and instructions to multiple domains and sub-domains. 569 Control hierarchy is outside the scope of this document. 571 6. Acknowledgements 573 The concept of Hierarchical Service Path Domains was introduced in 574 draft-homma-sfc-forwarding-methods-analysis-01 575 [I-D.homma-sfc-forwarding-methods-analysis] as a means to improve 576 scalability of service chaining in large networks. 578 The concept of nested NSH headers was introduced in 579 [I-D.ao-sfc-for-dc-interconnect] as a means of creating hierarchical 580 SFC in a data center. 582 The authors would like to thank the following individuals for taking 583 the time to read and provide valuable feedback: 585 Ron Parker 586 Christian Jacquenet 588 Jie Cao 590 7. IANA Considerations 592 This memo includes no request to IANA. 594 8. Security Considerations 596 Hierarchical service function chaining makes use of service chaining 597 architecture, and hence inherits the security considerations 598 described in the architecture document. 600 Furthermore, hierarchical service function chaining inherits security 601 considerations of the data-plane protocols (e.g., NSH) and control- 602 plane protocols used to realize the solution. 604 The systems described in this document bear responsibility for 605 forwarding internet traffic. In some cases the systems are 606 responsible for maintaining separation of traffic in private 607 networks. 609 This document describes systems within different domains of 610 administration that must have consistent configurations in order to 611 properly forward traffic and to maintain private network separation. 612 Any protocol designed to distribute the configurations must be secure 613 from tampering. 615 All of the systems and protocols must be secure from modification by 616 untrusted agents. 618 9. References 620 9.1. Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, 624 DOI 10.17487/RFC2119, March 1997, 625 . 627 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 628 Chaining (SFC) Architecture", RFC 7665, 629 DOI 10.17487/RFC7665, October 2015, 630 . 632 9.2. Informative References 634 [I-D.ao-sfc-for-dc-interconnect] 635 Ao, T. and W. Bo, "Hierarchical SFC for DC 636 Interconnection", draft-ao-sfc-for-dc-interconnect-01 637 (work in progress), October 2015. 639 [I-D.homma-sfc-forwarding-methods-analysis] 640 Homma, S., Kengo, K., Lopez, D., Stiemerling, M., and D. 641 Dolson, "Analysis on Forwarding Methods for Service 642 Chaining", draft-homma-sfc-forwarding-methods-analysis-01 643 (work in progress), January 2015. 645 [I-D.ietf-sfc-dc-use-cases] 646 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 647 Homma, "Service Function Chaining Use Cases In Data 648 Centers", draft-ietf-sfc-dc-use-cases-02 (work in 649 progress), January 2015. 651 [I-D.ietf-sfc-nsh] 652 Quinn, P. and U. Elzur, "Network Service Header", draft- 653 ietf-sfc-nsh-02 (work in progress), January 2016. 655 Appendix A. Examples of Hierarchical Service Function Chaining 657 The advantage of hierarchical service function chaining compared with 658 normal or flat service function chaining is that it can reduce the 659 management complexity significantly. This section discusses examples 660 that show those advantages. 662 A.1. Reducing the Number of Service Function Paths 664 In this case, hierarchical service function chaining is used to 665 simplify service function chaining management by reducing the number 666 of Service Function Paths. 668 As shown in Figure 4, there are two domains, each with different 669 concerns: a Security Domain that selects Service Functions based on 670 network conditions and an Optimization Domain that selects Service 671 Functions based on traffic protocol. 673 In this example there are five security functions deployed in the 674 Security Domain. The Security Domain operator wants to enforce the 675 five different security policies, and the Optimization Domain 676 operator wants to apply different optimizations (either cache or 677 video optimization) to each of these two types of traffic. If we use 678 flat SFC (normal branching), 10 SFPs are needed in each domain. In 679 contrast, if we use hierarchical SFC, only 5 SFPs in Security Domain 680 and 2 SFPs in Optimization Domain will be required, as shown in 681 Figure 5. 683 In the flat model, the number of SFPs is the product of the number of 684 functions in all of the domains. In the hSFC model, the number of 685 SFPs is the sum of the number of functions. For example, adding a 686 "bypass" path in the Optimization Domain would cause the flat model 687 to require 15 paths (5 more), but cause the hSFC model to require one 688 more path in the Optimization Domain. 690 . . . . . . . . . . . . . . . . . . . . . . . . . 691 . Security Domain . . Optimization Domain . 692 . . . . 693 . +-1---[ ]----------------->[Cache ]-------> 694 . | [ WAF ] . . . 695 . +-2-->[ ]----------------->[Video Opt.]----> 696 . | . . . 697 . +-3---[Anti ]----------------->[Cache ]-------> 698 . | [Virus] . . . 699 . +-4-->[ ]----------------->[Video Opt.]----> 700 . | . . . 701 . +-5-->[ ]----------------->[Cache ]-------> 702 [DPI]--->[CF]---| [ IPS ] . . . 703 . +-6-->[ ]----------------->[Video Opt.]----> 704 . | . . . 705 . +-7-->[ ]----------------->[Cache ]-------> 706 . | [ IDS ] . . . 707 . +-8-->[ ]----------------->[Video Opt.]----> 708 . | . . . 709 . +-9-->[Traffic]--------------->[Cache ]-------> 710 . | [Monitor] . . . 711 . +-10->[ ]--------------->[Video Opt.]----> 712 . . . . . . . . . . . . . . . . . . . . . . . . . 714 The classifier must select paths that determine the combination of 715 Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt, 716 3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5: IPS+Cache, 717 6:IPS+VideoOpt, 7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache, 718 10:TrafficMonitor+VideoOpt 720 Figure 4: Flat SFC (normal branching) 722 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723 . Security Domain . . Optimization Domain . 724 . . . . 725 [CF]---->[ [CF] IBN ]---------->[ [CF] IBN ]----> 726 . | ^ . . | ^ . 727 . +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ . 728 . | | . . | | . 729 . +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ . 730 . | | . . . 731 . +----->[ IPS ]-----+ . . . . . . . . . . . . . . . . 732 . | | . 733 . +----->[ IDS ]-----+ . 734 . | | . 735 . +-->[ Traffic ]----+ . 736 . [ Monitor ] . 737 . . . . . . . . . . . . . . . 739 Figure 5: Simplified path management with Hierarchical SFC 741 A.2. Managing a Distributed Data-Center Network 743 Hierarchical service function chaining can be used to simplify inter- 744 data-center SFC management. In the example of Figure 6, shown below, 745 there is a central data center (Central DC) and multiple local data 746 centers (Local DC#1, #2, #3) that are deployed in a geographically 747 distributed manner. All of the data centers are under a single 748 administrative domain. 750 The central DC may have some service functions that the local DC 751 needs, such that the local DC needs to chain traffic via the central 752 DC. This could be because: 754 o Some service functions are deployed as dedicated hardware 755 appliances, and there is a desire to lower the cost (both CAPEX 756 and OPEX) of deploying such service functions in all data centers. 758 o Some service functions are being trialed, introduced or otherwise 759 handle a relatively small amount of traffic. It may be cheaper to 760 manage these service functions in a single central data center and 761 steer packets to the central data center than to manage these 762 service functions in all data centers. 764 +-----------+ 765 |Central DC | 766 +-----------+ 767 ^ ^ ^ 768 | | | 769 .---|--|---|----. 770 / / | | \ 771 / / | \ \ 772 +-----+ / / | \ \ +-----+ 773 |Local| | / | \ | |Local| 774 |DC#1 |--|--. | .----|----|DC#3 | 775 +-----+ | | | +-----+ 776 \ | / 777 \ | / 778 \ | / 779 '----------------' 780 | 781 +-----+ 782 |Local| 783 |DC#2 | 784 +-----+ 786 Figure 6: Simplify inter-DC SFC management 788 For large data center operators, one local DC may have tens of 789 thousands of servers and hundred of thousands of virtual machines. 790 SFC can be used to manage user traffic. For example, SFC can be used 791 to classify user traffic based on service type, DDoS state etc. 793 In such large scale data center, using flat SFC is very complex, 794 requiring a super-controller to configure all data centers. For 795 example, any changes to Service Functions or Service Function Paths 796 in the central DC (e.g., deploying a new SF) would require updates to 797 all of the Service Function Paths in the local DCs accordingly. 798 Furthermore, requirements for symmetric paths add additional 799 complexity when flat SFC is used in this scenario. 801 Conversely, if using hierarchical SFC, each data center can be 802 managed independently to significantly reduce management complexity. 803 Service Function Paths between data centers can represent abstract 804 notions without regard to details within data centers. Independent 805 controllers can be used for the top level (getting packets to pass 806 the correct data centers) and local levels (getting packets to 807 specific SF instances). 809 Authors' Addresses 811 David Dolson 812 Sandvine 813 408 Albert Street 814 Waterloo, ON N2L 3V3 815 Canada 817 Phone: +1 519 880 2400 818 Email: ddolson@sandvine.com 820 Shunsuke Homma 821 NTT, Corp. 822 3-9-11, Midori-cho 823 Musashino-shi, Tokyo 180-8585 824 Japan 826 Email: homma.shunsuke@lab.ntt.co.jp 828 Diego R. Lopez 829 Telefonica I+D 830 Don Ramon de la Cruz, 82 831 Madrid 28006 832 Spain 834 Phone: +34 913 129 041 835 Email: diego.r.lopez@telefonica.com 837 Mohamed Boucadair 838 Orange Group 839 Rennes 35000 840 France 842 Email: mohamed.boucadair@orange.com 844 Dapeng Liu 845 Alibaba Group 846 Beijing 100022 847 China 849 Email: max.ldp@alibaba-inc.com 850 Ting Ao 851 ZTE Corporation 852 No.889,Bibo Rd.,Zhangjiang Hi-tech Park 853 Shanghai 201203 854 China 856 Phone: +86-21-688976442 857 Email: ao.ting@zte.com.cn