idnits 2.17.1 draft-ietf-sfc-hierarchical-00.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 26, 2016) is 2824 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Virus' is mentioned on line 853, but not defined == Missing Reference: 'Monitor' is mentioned on line 865, but not defined == Missing Reference: 'CF' is mentioned on line 880, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-sfc-control-plane-06 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-05 == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-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: January 27, 2017 NTT 6 D. Lopez 7 Telefonica I+D 8 M. Boucadair 9 Orange 10 D. Liu 11 Alibaba Group 12 T. Ao 13 ZTE Corporation 14 V. Vu 15 SSU 16 July 26, 2016 18 Hierarchical Service Function Chaining (hSFC) 19 draft-ietf-sfc-hierarchical-00 21 Abstract 23 Hierarchical Service Function Chaining (hSFC) is a network 24 architecture allowing an organization to compartmentalize a large- 25 scale network into multiple domains of administration. 27 The goals of hSFC are to make a large-scale network easier to reason 28 about, simpler to control and to able support independent functional 29 groups within large operators. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 27, 2017. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Hierarchical Service Function Chaining (hSFC) . . . . . . . . 4 67 2.1. Top Level . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 7 70 3.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 7 71 3.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 7 72 3.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 9 73 3.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 9 74 3.1.4. Nesting Upper-Level NSH within Lower-Level NSH . . . 10 75 3.1.5. Stateful / Metadata Hybrid . . . . . . . . . . . . . 11 76 3.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 12 77 3.3. Decrementing Service Index . . . . . . . . . . . . . . . 12 78 4. Sub-domain Classifier . . . . . . . . . . . . . . . . . . . . 13 79 5. Control Plane Elements . . . . . . . . . . . . . . . . . . . 13 80 6. Extension for Adopting to NSH-Unaware Service Functions . . . 14 81 6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 6.2. Requirements for IBN . . . . . . . . . . . . . . . . . . 16 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 10.2. Informative References . . . . . . . . . . . . . . . . . 18 89 Appendix A. Examples of Hierarchical Service Function Chaining . 18 90 A.1. Reducing the Number of Service Function Paths . . . . . . 18 91 A.2. Managing a Distributed Data-Center Network . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 94 1. Introduction 96 Service Function Chaining (SFC) is a technique for prescribing 97 differentiated traffic forwarding policies within an SFC-enabled 98 domain. SFC is described in detail in the SFC architecture document 99 [RFC7665], and is not repeated here. 101 In this document we consider the difficult problem of implementing 102 SFC across a large, geographically dispersed network comprised of 103 millions of hosts and thousands of network forwarding elements, 104 involving multiple operational teams (with varying functional 105 responsibilities). We expect asymmetrical routing is inherent in the 106 network, while recognizing that some Service Functions (SFs) require 107 bidirectional traffic for transport-layer sessions (e.g., NATs, 108 firewalls). We assume that some Service Function Paths (SFPs) need 109 to be selected on the basis of application-specific data visible to 110 the network, with transport-layer coordinate (typically, 5-tuple) 111 stickiness to specific SF instances. 113 Note: in this document, the notion of the "path" of a packet is the 114 series of SF instances traversed by a packet. The means of 115 delivering packets between SFs (the forwarding mechanisms enforced in 116 the underlying network) is not relevant to the discussion. 118 Difficult problems are often made easier by decomposing them in a 119 hierarchical (nested) manner. So instead of considering an 120 omniscient SFC Control Plane that can manage (create, withdraw, 121 supervise, etc.) complete SFPs from one end of the network to the 122 other, we decompose the network into smaller sub-domains. Each sub- 123 domain may support a subset of the network applications or a subset 124 of the users. The criteria for determining decomposition into SFC- 125 enabled sub-domains are beyond the scope of this document. 127 Note that decomposing a network into multiple SFC-enabled domains 128 should permit end-to-end visibility of SFs and SFPs. Decomposition 129 should also be implemented with special care to ease monitoring and 130 troubleshooting of the network and services as a whole. 132 An example of simplifying a network by using multiple SF domains is 133 further discussed in [I-D.ietf-sfc-dc-use-cases]. 135 We assume the SFC-aware nodes use NSH [I-D.ietf-sfc-nsh] or a similar 136 labeling mechanism. 138 The "domains" discussed in this document are assumed to be under 139 control of a single organization, such that there is a strong trust 140 relationship between the domains. The intention of creating multiple 141 domains is to improve the ability to operate a network. It is 142 outside of the scope of the document to consider domains operated by 143 different organizations. 145 2. Hierarchical Service Function Chaining (hSFC) 147 A hierarchy has multiple levels. The top-most level encompasses the 148 entire network domain to be managed, and lower levels encompass 149 portions of the network. 151 2.1. Top Level 153 Considering the example depicted in Figure 1, a top-level network 154 domain includes SFC data plane components distributed over a wide 155 area, including: 157 o Classifiers (CFs), 159 o Service Function Forwarders (SFFs) and 161 o Sub-domains. 163 For the sake of clarity, components of the underlay network are not 164 shown; an underlay network is assumed to provide connectivity between 165 SFC data plane components. 167 Top-level SFPs carry packets from classifiers through a series of 168 SFFs and sub-domains, with the operations within sub-domains being 169 opaque to the higher levels. 171 We expect the system to include a top-level control-plane having 172 responsibility for configuring forwarding and classification (see 173 [I-D.ietf-sfc-control-plane]). The top-level Service Chaining 174 control-plane manages end-to-end service chains and associated 175 service function paths from network edge points to sub-domains and 176 configuring top-level classifiers at a coarse level (e.g., based on 177 source or destination host) to forward traffic along paths that will 178 transit appropriate sub-domains. Figure 1 shows one possible service 179 chain passing from edge, through two sub-domains, to network egress. 180 The top-level control plane does not configure classification or 181 forwarding within the sub-domains. 183 At this network-wide level, the number of SFPs required is a linear 184 function of the number of ways in which a packet is required to 185 traverse different sub-domains and egress the network. Note that the 186 various paths which may be taken within a sub-domain are not 187 represented by distinct network-wide SFPs; specific policies at the 188 ingress nodes of each sub-domain bind flows to sub-domain paths. 190 Packets are classified at the edge of the network to select the paths 191 by which sub-domains are to be traversed. At the ingress of each 192 sub-domain, paths are reclassified to select the paths by which SFs 193 in the sub-domain are to be traversed. At the egress of each sub- 194 domain, packets are returned to the top-level paths. Contrast this 195 with an approach requiring the top-level classifier to select paths 196 to specify all of the SFs in each sub-domain. 198 It should be assumed that some SFs require bidirectional symmetry of 199 paths (see more in Section 4). Therefore the classifiers at the top 200 level must be configured with policies ensuring outgoing packets take 201 the reverse path of incoming packets through sub-domains. 203 +------------+ 204 |Sub-domain#1| 205 | in DC1 | 206 +----+-------+ 207 | 208 .---- SFF1 ------. +--+ 209 +--+ / / | \--|CF| 210 --->|CF|--/---->' | \ +--+ 211 +--+ / SC#1 | \ 212 | | | 213 | V .------>|---> 214 | / / | 215 \ | / / 216 +--+ \ | / / +--+ 217 |CF|---\ | / /---|CF| 218 +--+ '---- SFF2 ------' +--+ 219 | 220 +----+-------+ 221 |Sub-domain#2| 222 | in DC2 | 223 +------------+ 225 One path is shown from edge classifier to SFF1 to Sub-domain#1 226 (residing in data-center1) to SFF1 to SFF2 (residing in data-center 227 2) to Sub-domain#2 to SFF2 to network egress. 229 Figure 1: Network-wide view of top level of hierarchy 231 2.2. Lower Levels 233 Each of the sub-domains in Figure 1 is an SFC-enabled domain. 235 Unlike the top level, data packets entering the sub-domain are 236 already SFC-encapsulated. Figure 2 shows a sub-domain interfaced 237 with a higher-level domain by means of an Internal Boundary Node 238 (IBN). It is the purpose of the IBN to apply classification rules 239 and direct the packets to the selected local SFPs terminating at an 240 egress IBN. The egress IBN finally restores packets to the original 241 SFC shim 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 its sub-domain. A top- 246 level control element may configure the IBN as an SF (i.e., the IBN 247 plays the SF role in the top-level domain). 249 Each sub-domain is likely 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 SFC encapsulation of the top-level domain is converted to/from SFC 254 encapsulation of the lower-level domain. 256 +----+ +-----+ +----------------------+ +-----+ 257 | | | SFF | | IBN 1 (in DC 1) | | SFF | 258 | |SC#1| | | +----------------+ | | | 259 ->| |===============>| SFF |================> 260 | | +-----+ | +----------------+ | +-----+ 261 | CF | | | ^ | 262 | | | v | | 263 | | |+--------------------+| Top domain 264 | | ||CF, fwd/rev mapping || 265 | | * * * * *|| and "glue" || * * * * * 266 | | * |+--------------------+| * 267 +----+ * | | | | | | Sub * 268 * +-o-o--------------o-o-+ domain* 269 * SC#2 | |SC#1 ^ ^ #1 * 270 * +-----+ | | | * 271 * | V | | * 272 * | +---+ +------+ | | * 273 * | |SFF|->|SF#1.1|--+ | * 274 * | +---+ +------+ | * 275 * V | * 276 * +---+ +------+ +---+ +------+ * 277 * |SFF|->|SF#2.1|->|SFF|->|SF#2.2| * 278 * +---+ +------+ +---+ +------+ * 279 * * * * * * * * * * * * * * * * * * * * * * 281 *** Sub-domain boundary; === top-level chain; --- low-level chain. 283 Figure 2: Sub-domain within a higher-level domain 285 If desired, the pattern can be applied recursively. For example, 286 SF#1.1 in Figure 2 could be a sub-domain of the sub-domain. 288 3. Internal Boundary Node (IBN) 290 A network element termed "Internal Boundary Node" (IBN) bridges 291 packets between domains. It behaves as an SF to the higher level, 292 and looks like a classifier and end-of-chain to the lower level. 294 To achieve the benefits of hierarchy, the IBN should be applying more 295 granular traffic classification rules at the lower level than the 296 traffic passed to it. This means that the number of SFPs within the 297 lower level is greater than the number of SFPs arriving to the IBN. 299 The IBN is also the termination of lower-level SFPs. This is because 300 the packets exiting lower-level SF paths must be returned to the 301 higher-level SF paths and forwarded to the next hop in the higher- 302 level domain. 304 3.1. IBN Path Configuration 306 An operator of a lower-level domain may be aware of which high-level 307 paths transit their domain, or they may wish to accept any paths. 309 When packets enter the sub-domain, the Service Path Identifier (SPI) 310 and Service Index (SI) are re-marked according to the path selected 311 by the classifier. 313 After exiting a path in the sub-domain, packets can be restored to an 314 original upper-level SFP by these methods: 316 1. Saving SPI and SI in transport-layer flow state, 318 2. Pushing SPI and SI into metadata, 320 3. Using unique lower-level paths per upper-level path coordinates, 322 4. Nesting NSH headers, encapsulating the higher-level NSH headers 323 within the lower-level NSH headers, 325 5. Saving upper-level by a flow ID and placing an hSFC flow ID into 326 metadata, 328 3.1.1. Flow-Stateful IBN 330 An IBN can be flow-aware, returning packets to the correct higher- 331 level SFP on the basis of the transport-layer coordinates (typically, 332 a 5-tuple) of packets exiting the lower-level SFPs. 334 When packets are received by the IBN on a higher-level path, the 335 encapsulated packets are parsed for IP and transport-layer (TCP, UDP, 336 etc.) coordinates. State is created, indexed by these coordinates 337 ({source-IP, destination-IP, source-port, destination-port and 338 transport protocol} typically). The state contains at least critical 339 fields of the encapsulating SFC header (or perhaps the entire 340 header). 342 The simplest approach has the packets return to the same IBN at the 343 end of the chain that classified the packet at the start of the 344 chain. This is because the required transport-coordinates state is 345 rapidly changing and most efficiently kept locally. If the packet is 346 returned to a different IBN for egress, transport-coordinates state 347 must be synchronized between the IBNs. 349 When a packet returns to the IBN at the end of a chain, the SFC 350 header is removed, the packet is parsed for IP and transport-layer 351 coordinates, and state is retrieved from them. The state contains 352 the information required to forward the packet within the higher- 353 level service chain. 355 State cannot be created by packets arriving from the lower-level 356 chain; when state cannot be found for such packets, they must be 357 dropped. 359 This stateful approach is limited to use with SFs that retain the 360 transport coordinates of the packet. This approach cannot be used 361 with SFs that modify those coordinates (e.g., NATs) or otherwise 362 create packets for new coordinates other than those received (e.g., 363 as an HTTP cache might do to retrieve content on behalf of the 364 original flow). In both cases, the fundamental problem is the 365 inability to forward packets when state cannot be found for the 366 packet transport-layer coordinates. 368 In the stateful approach, there are issues caused by having state, 369 such as how long the state should be maintained (it must time out 370 eventually), as well as whether the state needs to be replicated to 371 other devices to create a highly available network. 373 It is valid to consider the state to be disposable after failure, 374 since it can be re-created by each new packet arriving from the 375 higher-level domain. For example, if an IBN loses all flow state, 376 the state is re-created by an end-point retransmitting a TCP packet. 378 If an SFC domain handles multiple network regions (e.g., multiple 379 private networks), the coordinates may be augmented with additional 380 parameters, perhaps using some metadata to identify the network 381 region. 383 In this stateful approach, it is not necessary for the sub-domain's 384 control-plane to modify paths when higher-level paths are changed. 385 The complexity of the higher-level domain does not cause complexity 386 in the lower-level domain. 388 Since it doesn't depend on NSH in the lower domain, this flow- 389 stateful approach can be applied to translation methods of converting 390 NSH to other forwarding techniques. (Refer to Section 6.) 392 3.1.2. Encoding Upper-Level Paths in Metadata 394 An IBN can push the upper-level Service Path Identifier (SPI) and 395 Service Index (SI) (or encoding thereof) into a metadata field of the 396 lower-level encapsulation (e.g., placing upper-level path information 397 into a metadata field of NSH). When packets exit the lower-level 398 path, the upper-level SPI and SI can be restored from the metadata 399 retrieved from the packet. 401 This approach requires the SFs in the path to be capable of 402 forwarding the metadata and appropriately attaching metadata to any 403 packets injected for a flow. 405 Using new metadata may inflate packet size when variable-length 406 metadata (type 2 from NSH [I-D.ietf-sfc-nsh]) is used. 408 It is conceivable that the MD-type 1 Mandatory Context Header fields 409 of NSH [I-D.ietf-sfc-nsh] are not all relevant to the lower-level 410 domain. In this case, one of the metadata slots of the Mandatory 411 Context Header could be repurposed within the lower-level domain, and 412 restored when leaving. 414 In this metadata approach, it is not necessary for the sub-domain's 415 control element to modify paths when higher-level paths are changed. 416 The complexity of the higher-level domain does not cause complexity 417 in the lower-level domain. 419 3.1.3. Using Unique Paths per Upper-Level Path 421 In this approach, paths within the sub-domain are constrained so that 422 a SPI (of the sub-domain) unambiguously indicates the egress SPI and 423 SI (of the upper domain). This allows the original path information 424 to be restored at sub-domain egress from a look-up table using the 425 sub-domain SPI. 427 Whenever the upper-level domain provisions a path via the lower-level 428 domain, the lower-level domain controller must provision 429 corresponding paths to traverse the lower-level domain. 431 A down-side of this approach is that the number of paths in the 432 lower-level domain is multiplied by the number of paths in the 433 higher-level domain that traverse the lower-level domain. I.e., a 434 sub-path must be created for each combination of upper SPI/SI and 435 lower chain. 437 3.1.4. Nesting Upper-Level NSH within Lower-Level NSH 439 In this approach, when packets arrive at the IBN in the top-level 440 domain, the classifier in the IBN determines the path for the lower- 441 level domain and pushes the new NSH header in front of the original 442 NSH header. 444 As shown in Figure 3 the Lower-NSH Header used to forward packets in 445 the lower-level domain precedes the Upper-NSH Header from the top- 446 level domain. 448 +------------------+ 449 | Overlay Header | 450 +------------------+ 451 | Lower-NSH Header | 452 +------------------+ 453 | Upper-NSH Header | 454 +------------------+ 455 | Original Packet | 456 +------------------+ 458 Figure 3: Encapsulation of NSH within NSH 460 The traffic with the above stack of two-layer-NSH header is to be 461 forwarded according to the Lower-NSH header in the lower-level SFC 462 domain. The Upper-NSH header is preserved in the packets but not 463 used for forwarding. At the last SFF of the chain of the lower-level 464 domain (which resides in the IBN), the Lower-NSH header is removed 465 from the packet, and then the packet is forwarded by the IBN to an 466 SFF of the upper-level domain, which will be forwarded according to 467 the Upper-NSH header. 469 With such encapsulation, Upper-NSH information is carried along the 470 extent of the lower-level chain without modification. 472 A benefit of this approach is that it does not require state in the 473 IBN or configuration to encode fields in meta-data. 475 However, the down-side is it does require SFs in the lower-level 476 domain to be able to parse multiple layers of NSH. If the SF injects 477 packets, it must also be able to deal with adding appropriate 478 multiple layers of headers to injected packets. 480 3.1.5. Stateful / Metadata Hybrid 482 The basic idea of this approach is for the IBN to save upper domain 483 encapsulation information such that it can be retrieved by a unique 484 identifier, termed an "hSFC Flow ID". An example ID is shown in 485 Table 1. 487 +-----------+-----+-----+----------+----------+----------+----------+ 488 | hSFC Flow | SPI | SI | Context1 | Context2 | Context3 | Context4 | 489 | ID | | | | | | | 490 +-----------+-----+-----+----------+----------+----------+----------+ 491 | 1 | 45 | 254 | 100 | 2112 | 12345 | 7 | 492 +-----------+-----+-----+----------+----------+----------+----------+ 494 Table 1: Example Mapping of an hSFC Flow ID to Upper-Level Header 496 The ID is placed in the metadata in NSH headers of the packet in the 497 lower domain, as shown in Figure 4. When packets exit the lower 498 domain, the IBN uses the ID to retrieve the appropriate NSH 499 encapsulation for returning the packet to the upper domain. 501 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Service Path Identifer | Service Index | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | hSFC Flow ID | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Mandatory Context Header | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Mandatory Context Header | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Mandatory Context Header | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 4: Storing hSFC Flow ID in lower-level metadata 518 Advantages of this approach include: 520 o Does not require state based on 5-tuple, so it works with 521 functions that change the IP addresses or ports of a packet such 522 as NATs, 524 o Does not require all domains to have the same metadata scheme, 526 o Can be used to restore any upper-domain information, not just 527 service path, 529 o The lower domain only requires a single item of metadata 530 regardless of the number of items of metadata used in the upper 531 domain. (For MD-Type 1, this leaves 3 slots for use in the lower 532 domain.) 534 o No special functionality is required of the SF, other than the 535 usual ability to preserve metadata and to apply metadata to 536 injected packets. 538 Disadvantages include those of other stateful approaches, including 539 state timeout and replication mentioned in Section 3.1.1. 541 There may be a large number of unique NSH encapsulations to be 542 stored, given that the hSFC Flow ID must represent all of the bits in 543 the upper-level encapsulation. This might consume a lot of memory or 544 create out-of-memory situations in which IDs cannot be created or old 545 IDs are discarded while still in use. 547 3.2. Gluing Levels Together 549 The SPI or metadata on a packet received by the IBN may be used as 550 input to reclassification and path selection within the lower-level 551 domain. 553 In some cases the meanings of the various path IDs and metadata must 554 be coordinated between domains. 556 One approach is to use well-known identifier values in metadata, 557 communicated by some organizational registry. 559 Another approach is to use well-known labels for chain identifiers or 560 metadata, as an indirection to the actual identifiers. The actual 561 identifiers can be assigned by control-plane systems. For example, a 562 sub-domain classifier could have a policy, "if pathID=classA then 563 chain packet to path 1234"; the higher-level controller would be 564 expected to configure the concrete higher-level pathID for classA. 566 3.3. Decrementing Service Index 568 Because the IBN acts as a Service Function to the higher-level 569 domain, it must decrement the Service Index in the NSH headers of the 570 higher-level path. 572 A good strategy seems to be to do this when the packet is first 573 received by the IBN, before applying any of the strategies of 574 Section 3.1, immediately prior to classification. 576 4. Sub-domain Classifier 578 Within the sub-domain (referring to Figure 2), after the IBN removes 579 higher-level encapsulation from incoming packets, it sends the 580 packets to the classifier, which selects the encapsulation for the 581 packet within the sub-domain. 583 One of the goals of the hierarchical approach is to make it easy to 584 have transport-flow-aware service chaining with bidirectional paths. 585 For example, it is desired that for each TCP flow, the client-to- 586 server packets traverse the same SFs as the server-to-client packets, 587 but in the opposite sequence. We call this bidirectional symmetry. 588 If bidirectional symmetry is required, it is the responsibility of 589 the control-plane to be aware of symmetric paths and configure the 590 classifier to chain the traffic in a symmetric manner. 592 Another goal of the hierarchical approach is to simplify the 593 mechanisms of scaling in and scaling out service functions. All of 594 the complexities of load-balancing among multiple SFs can be handled 595 within a sub-domain, under control of the classifier, allowing the 596 higher-level domain to be oblivious to the existence of multiple SF 597 instances. 599 Considering the requirements of bidirectional symmetry and load- 600 balancing, it is useful to have all packets entering a sub-domain to 601 be received by the same classifier or a coordinated cluster of 602 classifiers. There are both stateful and stateless approaches to 603 ensuring bidirectional symmetry. 605 5. Control Plane Elements 607 Although control protocols have not yet been standardized, from the 608 point of view of hierarchical service function chaining we have these 609 expectations: 611 o Each control-plane instance manages a single level of hierarchy of 612 a single domain. 614 o Each control-plane is agnostic about other levels of hierarchy. 615 This aspect allows humans to reason about the system within a 616 single domain and allows control-plane algorithms to use only 617 domain-local inputs. Top-level control does not need visibility 618 to sub-domain policies, nor does sub-domain control need 619 visibility to higher-level policies. 621 o Sub-domain control-planes are agnostic about control-planes of 622 other sub-domains. This allows both humans and machines to 623 manipulate sub-domain policy without considering policies of other 624 domains. 626 Recall that the IBN acts as an SF in the higher-level domain 627 (receiving SF instructions from the higher-level control-plane) and 628 as a classifier in the lower-level domain (receiving classification 629 rules from the sub-domain control-plane). In this view, it is the 630 IBN that glues the layers together. 632 The above expectations are not intended to prohibit network-wide 633 control. A control hierarchy can be envisaged to distribute 634 information and instructions to multiple domains and sub-domains. 635 Control hierarchy is outside the scope of this document. 637 6. Extension for Adopting to NSH-Unaware Service Functions 639 The hierarchical approach can be used for dividing networks into NSH- 640 aware and NSH-unaware domains by converting NSH encapsulation to 641 other forwarding techniques (e.g., 5-tuple-based routing with 642 OpenFlow), as shown in Figure 5. 644 * * * * * * * * * * * * * * * * * * 645 * NSH-aware domain * 646 * +-------+ +-------+ * 647 * | SF#1 | | SF#5 | * 648 * +-o---o-+ +-o---o-+ * 649 * ^ | ^ | * 650 * +-|---|-+ +-|---|-+ * 651 * | |SFF| | | |SFF| | * 652 * +-|---|-+ +-|---|-+ * 653 * . | | . * 654 * +--+ / | | \ * 655 -->|CF|--' | | '-------> 656 * +--+ v | * 657 * +---o-----------o---+ * 658 .*.*.*.*.| / | IBN | \ |*.*.*. 659 . +-o--o---------o--o-+ . 660 . | | ^ ^ . 661 . | +-+ +-+ | . 662 . +---+ v | +---+ . 663 . | +-o-----o-+ | . 664 . | | SF#2 | | . 665 . | +---------+ | . 666 . +--+ +--+ . 667 . | +---------+ | . 668 . v | v | . 669 . +-o---o-+ +-o---o-+ . 670 . | SF#3 | | SF#4 | . 671 . +-------+ +-------+ . 672 . NSH-unaware domain . 673 . . . . . . . . . . . . . . . . . . 675 SF#1 and SF#5 are NSH-aware and SF#2, SF#3 and SF#4 are NSH-unaware. 676 In the NSH-unaware domain, packets are conveyed in a format supported 677 by SFs which are deployed there. 679 Figure 5: Dividing NSH-aware and NSH-unaware domains 681 6.1. Purpose 683 This approach is expected to facilitate service chaining in networks 684 in which NSH-aware and NSH-unaware SFs coexist. Some examples of 685 such situations are: 687 o In a period of transition from legacy SFs to NSH-aware SFs and 689 o Supporting multi-tenancy. 691 6.2. Requirements for IBN 693 In this usage, an IBN classifier is required to have an NSH 694 conversion table for applying packets to appropriate lower-level 695 paths and returning packets to the correct higher-level paths. For 696 example, the following methods would be used for saving/restoring 697 upper-level path information: 699 o Saving SPI and SI in transport-layer flow state (refer to 700 Section 3.1.1) and 702 o Using unique lower-level paths per upper-level NSH coordinates 703 (refer to Section 3.1.3). 705 Especially, the use of unique paths approach would be good for 706 translating NSH to a different forwarding technique in the lower 707 level. A single path in the upper level may be branched to multiple 708 paths in the lower level such that any lower-level path is only used 709 by one upper-level path. This allows unambiguous restoration to the 710 upper-level path. 712 In addition, an IBN might be required to convert metadata contained 713 in NSH to the format appropriate to the packet in the lower-level 714 path. For example, some legacy SFs identify subscriber based on 715 information of network topology, such as VID, and IBN would be 716 required to create VLAN to packets from metadata if subscriber 717 identifier is conveyed as metadata in higher-level domains. 719 Other fundamental functions required as IBN (e.g., maintaining 720 metadata of upper level or decrementing Service Index) are same as 721 normal usage. 723 7. Acknowledgements 725 The concept of Hierarchical Service Path Domains was introduced in 726 [I-D.homma-sfc-forwarding-methods-analysis] as a means to improve 727 scalability of service chaining in large networks. 729 The concept of nested NSH headers was introduced in 730 [I-D.ao-sfc-for-dc-interconnect] as a means of creating hierarchical 731 SFC in a data center. 733 The authors would like to thank the following individuals for 734 providing valuable feedback: 736 Ron Parker 738 Christian Jacquenet 739 Jie Cao 741 8. IANA Considerations 743 This memo includes no request to IANA. 745 9. Security Considerations 747 Hierarchical service function chaining makes use of service chaining 748 architecture, and hence inherits the security considerations 749 described in the architecture document. 751 Furthermore, hierarchical service function chaining inherits security 752 considerations of the data-plane protocols (e.g., NSH) and control- 753 plane protocols used to realize the solution. 755 The systems described in this document bear responsibility for 756 forwarding internet traffic. In some cases the systems are 757 responsible for maintaining separation of traffic in private 758 networks. 760 This document describes systems within different domains of 761 administration that must have consistent configurations in order to 762 properly forward traffic and to maintain private network separation. 763 Any protocol designed to distribute the configurations must be secure 764 from tampering. 766 All of the systems and protocols must be secure from modification by 767 untrusted agents. 769 Security considerations related to the control plane are discussed in 770 [I-D.ietf-sfc-control-plane]. 772 10. References 774 10.1. Normative References 776 [I-D.ietf-sfc-control-plane] 777 Boucadair, M., "Service Function Chaining (SFC) Control 778 Plane Components & Requirements", draft-ietf-sfc-control- 779 plane-06 (work in progress), May 2016. 781 [I-D.ietf-sfc-nsh] 782 Quinn, P. and U. Elzur, "Network Service Header", draft- 783 ietf-sfc-nsh-05 (work in progress), May 2016. 785 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 786 Chaining (SFC) Architecture", RFC 7665, 787 DOI 10.17487/RFC7665, October 2015, 788 . 790 10.2. Informative References 792 [I-D.ao-sfc-for-dc-interconnect] 793 Ao, T. and W. Bo, "Hierarchical SFC for DC 794 Interconnection", draft-ao-sfc-for-dc-interconnect-01 795 (work in progress), October 2015. 797 [I-D.homma-sfc-forwarding-methods-analysis] 798 Homma, S., Naito, K., Lopez, D., Stiemerling, M., Dolson, 799 D., Gorbunov, A., Leymann, N., Bottorff, P., and d. 800 don.fedyk@hpe.com, "Analysis on Forwarding Methods for 801 Service Chaining", draft-homma-sfc-forwarding-methods- 802 analysis-05 (work in progress), January 2016. 804 [I-D.ietf-sfc-dc-use-cases] 805 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 806 Homma, "Service Function Chaining Use Cases In Data 807 Centers", draft-ietf-sfc-dc-use-cases-02 (work in 808 progress), January 2015. 810 Appendix A. Examples of Hierarchical Service Function Chaining 812 The advantage of hierarchical service function chaining compared with 813 normal or flat service function chaining is that it can reduce the 814 management complexity significantly. This section discusses examples 815 that show those advantages. 817 A.1. Reducing the Number of Service Function Paths 819 In this case, hierarchical service function chaining is used to 820 simplify service function chaining management by reducing the number 821 of Service Function Paths. 823 As shown in Figure 6, there are two domains, each with different 824 concerns: a Security Domain that selects Service Functions based on 825 network conditions and an Optimization Domain that selects Service 826 Functions based on traffic protocol. 828 In this example there are five security functions deployed in the 829 Security Domain. The Security Domain operator wants to enforce the 830 five different security policies, and the Optimization Domain 831 operator wants to apply different optimizations (either cache or 832 video optimization) to each of these two types of traffic. If we use 833 flat SFC (normal branching), 10 SFPs are needed in each domain. In 834 contrast, if we use hierarchical SFC, only 5 SFPs in Security Domain 835 and 2 SFPs in Optimization Domain will be required, as shown in 836 Figure 7. 838 In the flat model, the number of SFPs is the product of the number of 839 functions in all of the domains. In the hSFC model, the number of 840 SFPs is the sum of the number of functions. For example, adding a 841 "bypass" path in the Optimization Domain would cause the flat model 842 to require 15 paths (5 more), but cause the hSFC model to require one 843 more path in the Optimization Domain. 845 . . . . . . . . . . . . . . . . . . . . . . . . . 846 . Security Domain . . Optimization Domain . 847 . . . . 848 . +-1---[ ]----------------->[Cache ]-------> 849 . | [ WAF ] . . . 850 . +-2-->[ ]----------------->[Video Opt.]----> 851 . | . . . 852 . +-3---[Anti ]----------------->[Cache ]-------> 853 . | [Virus] . . . 854 . +-4-->[ ]----------------->[Video Opt.]----> 855 . | . . . 856 . +-5-->[ ]----------------->[Cache ]-------> 857 [DPI]--->[CF]---| [ IPS ] . . . 858 . +-6-->[ ]----------------->[Video Opt.]----> 859 . | . . . 860 . +-7-->[ ]----------------->[Cache ]-------> 861 . | [ IDS ] . . . 862 . +-8-->[ ]----------------->[Video Opt.]----> 863 . | . . . 864 . +-9-->[Traffic]--------------->[Cache ]-------> 865 . | [Monitor] . . . 866 . +-10->[ ]--------------->[Video Opt.]----> 867 . . . . . . . . . . . . . . . . . . . . . . . . . 869 The classifier must select paths that determine the combination of 870 Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt, 871 3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5: IPS+Cache, 872 6:IPS+VideoOpt, 7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache, 873 10:TrafficMonitor+VideoOpt 875 Figure 6: Flat SFC (normal branching) 877 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878 . Security Domain . . Optimization Domain . 879 . . . . 880 [CF]---->[ [CF] IBN ]---------->[ [CF] IBN ]----> 881 . | ^ . . | ^ . 882 . +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ . 883 . | | . . | | . 884 . +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ . 885 . | | . . . 886 . +----->[ IPS ]-----+ . . . . . . . . . . . . . . . . 887 . | | . 888 . +----->[ IDS ]-----+ . 889 . | | . 890 . +-->[ Traffic ]----+ . 891 . [ Monitor ] . 892 . . . . . . . . . . . . . . . 894 Figure 7: Simplified path management with Hierarchical SFC 896 A.2. Managing a Distributed Data-Center Network 898 Hierarchical service function chaining can be used to simplify inter- 899 data-center SFC management. In the example of Figure 8, shown below, 900 there is a central data center (Central DC) and multiple local data 901 centers (Local DC#1, #2, #3) that are deployed in a geographically 902 distributed manner. All of the data centers are under a single 903 administrative domain. 905 The central DC may have some service functions that the local DC 906 needs, such that the local DC needs to chain traffic via the central 907 DC. This could be because: 909 o Some service functions are deployed as dedicated hardware 910 appliances, and there is a desire to lower the cost (both CAPEX 911 and OPEX) of deploying such service functions in all data centers. 913 o Some service functions are being trialed, introduced or otherwise 914 handle a relatively small amount of traffic. It may be cheaper to 915 manage these service functions in a single central data center and 916 steer packets to the central data center than to manage these 917 service functions in all data centers. 919 +-----------+ 920 |Central DC | 921 +-----------+ 922 ^ ^ ^ 923 | | | 924 .---|--|---|----. 925 / / | | \ 926 / / | \ \ 927 +-----+ / / | \ \ +-----+ 928 |Local| | / | \ | |Local| 929 |DC#1 |--|--. | .----|----|DC#3 | 930 +-----+ | | | +-----+ 931 \ | / 932 \ | / 933 \ | / 934 '----------------' 935 | 936 +-----+ 937 |Local| 938 |DC#2 | 939 +-----+ 941 Figure 8: Simplify inter-DC SFC management 943 For large data center operators, one local DC may have tens of 944 thousands of servers and hundred of thousands of virtual machines. 945 SFC can be used to manage user traffic. For example, SFC can be used 946 to classify user traffic based on service type, DDoS state etc. 948 In such large scale data center, using flat SFC is very complex, 949 requiring a super-controller to configure all data centers. For 950 example, any changes to Service Functions or Service Function Paths 951 in the central DC (e.g., deploying a new SF) would require updates to 952 all of the Service Function Paths in the local DCs accordingly. 953 Furthermore, requirements for symmetric paths add additional 954 complexity when flat SFC is used in this scenario. 956 Conversely, if using hierarchical SFC, each data center can be 957 managed independently to significantly reduce management complexity. 958 Service Function Paths between data centers can represent abstract 959 notions without regard to details within data centers. Independent 960 controllers can be used for the top level (getting packets to pass 961 the correct data centers) and local levels (getting packets to 962 specific SF instances). 964 Authors' Addresses 966 David Dolson 967 Sandvine 968 408 Albert Street 969 Waterloo, ON N2L 3V3 970 Canada 972 Phone: +1 519 880 2400 973 Email: ddolson@sandvine.com 975 Shunsuke Homma 976 NTT, Corp. 977 3-9-11, Midori-cho 978 Musashino-shi, Tokyo 180-8585 979 Japan 981 Email: homma.shunsuke@lab.ntt.co.jp 983 Diego R. Lopez 984 Telefonica I+D 985 Don Ramon de la Cruz, 82 986 Madrid 28006 987 Spain 989 Phone: +34 913 129 041 990 Email: diego.r.lopez@telefonica.com 992 Mohamed Boucadair 993 Orange 994 Rennes 35000 995 France 997 Email: mohamed.boucadair@orange.com 999 Dapeng Liu 1000 Alibaba Group 1001 Beijing 100022 1002 China 1004 Email: max.ldp@alibaba-inc.com 1005 Ting Ao 1006 ZTE Corporation 1007 No.889,Bibo Rd.,Zhangjiang Hi-tech Park 1008 Shanghai 201203 1009 China 1011 Phone: +86-21-688976442 1012 Email: ao.ting@zte.com.cn 1014 Vu Anh Vu 1015 Soongsil University 1016 369 Sangdo-ro 1017 Seoul, Dongjak-gu 06978 1018 Korea 1020 Email: vuva@dcn.ssu.ac.kr