idnits 2.17.1 draft-ietf-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 (January 13, 2017) is 2659 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Virus' is mentioned on line 918, but not defined == Missing Reference: 'Monitor' is mentioned on line 930, but not defined == Missing Reference: 'CF' is mentioned on line 945, 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: July 17, 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 Soongsil University 16 January 13, 2017 18 Hierarchical Service Function Chaining (hSFC) 19 draft-ietf-sfc-hierarchical-02 21 Abstract 23 Hierarchical Service Function Chaining (hSFC) is a network 24 architecture allowing an organization to decompose a large-scale 25 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 support independent functional 29 groups within large network 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 July 17, 2017. 48 Copyright Notice 50 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 7 70 3.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 8 71 3.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 8 72 3.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 10 73 3.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 10 74 3.1.4. Nesting Upper-Level NSH within Lower-Level NSH . . . 11 75 3.1.5. Stateful / Metadata Hybrid . . . . . . . . . . . . . 12 76 3.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 13 77 3.3. Decrementing Service Index . . . . . . . . . . . . . . . 14 78 4. Sub-domain Classifier . . . . . . . . . . . . . . . . . . . . 14 79 5. Control Plane Elements . . . . . . . . . . . . . . . . . . . 14 80 6. Extension for Adapting to NSH-Unaware Service Functions . . . 15 81 6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 6.2. Requirements for IBN . . . . . . . . . . . . . . . . . . 17 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 9.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 19 87 9.2. Infinite Forwarding Loops . . . . . . . . . . . . . . . . 19 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 90 10.2. Informative References . . . . . . . . . . . . . . . . . 19 91 Appendix A. Examples of Hierarchical Service Function Chaining . 20 92 A.1. Reducing the Number of Service Function Paths . . . . . . 20 93 A.2. Managing a Distributed Data-Center Network . . . . . . . 22 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 96 1. Introduction 98 Service Function Chaining (SFC) is a technique for prescribing 99 differentiated traffic forwarding policies within an SFC-enabled 100 domain. SFC is described in detail in the SFC architecture document 101 [RFC7665], and is not repeated here. 103 This document focuses on the difficult problem of implementing SFC 104 across a large, geographically dispersed network, potentially 105 comprised of millions of hosts and thousands of network forwarding 106 elements, and which may involve multiple operational teams (with 107 varying functional responsibilities). We recognize that some Service 108 Functions (SFs) require bidirectional traffic for transport-layer 109 sessions (e.g., NATs, firewalls). We assume that some Service 110 Function Paths (SFPs) need to be selected on the basis of 111 application-specific data visible to the network, with transport- 112 layer coordinate (typically, 5-tuple) stickiness to specific SF 113 instances. 115 Note: in this document, the notion of the "path" of a packet is 116 the series of SF instances traversed by a packet. The means of 117 delivering packets between SFs (i.e., the forwarding mechanisms 118 enforced in the underlying network) are not relevant to the 119 discussion. 121 Difficult problems are often made easier by decomposing them in a 122 hierarchical (nested) manner. So instead of considering a single SFC 123 Control Plane ([I-D.ietf-sfc-control-plane]) that can manage (create, 124 withdraw, supervise, etc.) complete SFPs from one end of the network 125 to the other, we decompose the network into smaller domains operated 126 by as many SFC control plane components. Coordination between such 127 components is further discussed in the document. Each sub-domain may 128 support a subset of the network applications or a subset of the 129 users. Decomposing a network into multiple SFC-enabled domains 130 should permit end-to-end visibility of SFs and SFPs. Also, 131 decomposing should be done with care to ease monitoring and 132 troubleshooting of the network and services as a whole. The criteria 133 for decomposition a domain into multiple SFC-enabled sub-domains are 134 beyond the scope of this document. These criteria are deployment- 135 specific. 137 An example of simplifying a network by using multiple SFC-enabled 138 domains is further discussed in [I-D.ietf-sfc-dc-use-cases]. 140 We assume the SFC-aware nodes use NSH [I-D.ietf-sfc-nsh] or a similar 141 labeling mechanism. Sample examples are described in Appendix A. 143 The "domains" discussed in this document are assumed to be under 144 control of a single organization, such that there is a strong trust 145 relationship between the domains. The intention of creating multiple 146 domains is to improve the ability to operate a network. It is 147 outside of the scope of the document to consider domains operated by 148 different organizations. 150 2. Hierarchical Service Function Chaining (hSFC) 152 A hierarchy has multiple levels: the top-most level encompasses the 153 entire network domain to be managed, and lower levels encompass 154 portions of the network. These levels are discussed in the following 155 sub-sections. 157 2.1. Top Level 159 Considering the example depicted in Figure 1, a top-level network 160 domain includes SFC data plane components distributed over a wide 161 area, including: 163 o Classifiers (CFs), 165 o Service Function Forwarders (SFFs) and 167 o Sub-domains. 169 For the sake of clarity, components of the underlay network are not 170 shown; an underlay network is assumed to provide connectivity between 171 SFC data plane components. 173 Top-level SFPs carry packets from classifiers through a set of SFFs 174 and sub-domains, with the operations within sub-domains being opaque 175 to the higher levels. 177 We expect the system to include a top-level control plane having 178 responsibility for configuring forwarding policies and traffic 179 classification rules (see [I-D.ietf-sfc-control-plane]). The top- 180 level Service Chaining control plane manages end-to-end service 181 chains and associated service function paths from network edge points 182 to sub-domains and configures top-level classifiers at a coarse level 183 (e.g., based on source or destination host) to forward traffic along 184 paths that will transit across appropriate sub-domains. 186 Figure 1 shows one possible service chain passing from edge, through 187 two sub-domains, to network egress. The top-level control plane does 188 not configure traffic classification rules or forwarding policies 189 within the sub-domains. 191 At this network-wide level, the number of SFPs required is a linear 192 function of the number of ways in which a packet is required to 193 traverse different sub-domains and egress the network. Note that the 194 various paths which may be followed within a sub-domain are not 195 represented by distinct network-wide SFPs; specific policies at the 196 ingress nodes of each sub-domain bind flows to sub-domain paths. 198 Packets are classified at the edge of the network to select the paths 199 by which sub-domains are to be traversed. At the ingress of each 200 sub-domain, packets are reclassified to paths directing them to the 201 required SFs of the sub-domain. At the egress of each sub-domain, 202 packets are returned to the top-level paths. Contrast this with an 203 approach requiring the top-level classifier to select paths to 204 specify all of the SFs in each sub-domain. 206 It should be assumed that some SFs require bidirectional symmetry of 207 paths (see more in Section 4). Therefore the classifiers at the top 208 level must be configured with policies ensuring outgoing packets take 209 the reverse path of incoming packets through sub-domains. 211 +------------+ 212 |Sub-domain#1| 213 | in DC1 | 214 +----+-------+ 215 | 216 .---- SFF1 ------. +--+ 217 +--+ / / | \--|CF| 218 --->|CF|--/---->' | \ +--+ 219 +--+ / SC#1 | \ 220 | | | 221 | V .------>|---> 222 | / / | 223 \ | / / 224 +--+ \ | / / +--+ 225 |CF|---\ | / /---|CF| 226 +--+ '---- SFF2 ------' +--+ 227 | 228 +----+-------+ 229 |Sub-domain#2| 230 | in DC2 | 231 +------------+ 233 One path is shown from edge classifier to SFF1 to Sub-domain#1 234 (residing in data-center1) to SFF1 to SFF2 (residing in data-center 235 2) to Sub-domain#2 to SFF2 to network egress. 237 Figure 1: Network-wide view of top level of hierarchy 239 2.2. Lower Levels 241 Each of the sub-domains in Figure 1 is an SFC-enabled domain. 243 Unlike the top level, data packets entering the sub-domain are 244 already SFC-encapsulated. Figure 2 shows a sub-domain interfaced 245 with a higher-level domain by means of an Internal Boundary Node 246 (IBN). It is the purpose of the IBN to apply classification rules 247 and direct the packets to the selected local SFPs terminating at an 248 egress IBN. The egress IBN finally restores packets to the original 249 SFC shim and hands them off to SFFs. 251 Each sub-domain intersects a subset of the total paths that are 252 possible in the higher-level domain. An IBN is concerned with 253 higher-level paths, but only those traversing its sub-domain. A top- 254 level control element may configure the IBN as an SF (i.e., the IBN 255 plays the SF role in the top-level domain). 257 Each sub-domain is likely to have a control plane that can operate 258 independently of the top-level control plane, managing 259 classification, forwarding paths, etc. within the level of the sub- 260 domain, with the details being opaque to the upper-level control 261 elements. Section 3 provides more details about the behavior of an 262 IBN. 264 The sub-domain control plane configures the classification rules in 265 the IBN, where SFC encapsulation of the top-level domain is converted 266 to/from SFC encapsulation of the lower-level domain. The sub-domain 267 control plane also configures the forwarding rules in the SFFs of the 268 sub-domain. 270 +----+ +-----+ +----------------------+ +-----+ 271 | | | SFF | | IBN 1 (in DC 1) | | SFF | 272 | |SC#1| | | +----------------+ | | | 273 ->| |===============>| SFF |================> 274 | | +-----+ | +----------------+ | +-----+ 275 | CF | | | ^ | 276 | | | v | | 277 | | |+--------------------+| Top domain 278 | | ||CF, fwd/rev mapping || 279 | | * * * * *|| and "glue" || * * * * * 280 | | * |+--------------------+| * 281 +----+ * | | | | | | Sub * 282 * +-o-o--------------o-o-+ domain* 283 * SC#2 | |SC#1 ^ ^ #1 * 284 * +-----+ | | | * 285 * | V | | * 286 * | +---+ +------+ | | * 287 * | |SFF|->|SF#1.1|--+ | * 288 * | +---+ +------+ | * 289 * V | * 290 * +---+ +------+ +---+ +------+ * 291 * |SFF|->|SF#2.1|->|SFF|->|SF#2.2| * 292 * +---+ +------+ +---+ +------+ * 293 * * * * * * * * * * * * * * * * * * * * * * 294 Legend: 295 *** Sub-domain boundary 296 === top-level chain 297 --- low-level chain 299 Figure 2: Sub-domain within a higher-level domain 301 If desired, the pattern can be applied recursively. For example, 302 SF#1.1 in Figure 2 could be a sub-domain of the sub-domain. 304 3. Internal Boundary Node (IBN) 306 As mentioned in the previous section, a network element termed 307 "Internal Boundary Node" (IBN) is responsible for bridging packets 308 between higher and lower layers of SFC-enabled domains. It behaves 309 as an SF to the higher level (Section 2.1), and looks like a 310 classifier and end-of-chain to the lower level (Section 2.2). 312 To achieve the benefits of hierarchy, the IBN should be applying more 313 granular traffic classification rules at the lower level than the 314 traffic passed to it. This means that the number of SFPs within the 315 lower level is greater than the number of SFPs arriving to the IBN. 317 The IBN is also the termination of lower-level SFPs. This is because 318 the packets exiting lower-level SF paths must be returned to the 319 higher-level SF paths and forwarded to the next hop in the higher- 320 level domain. 322 When different metadata schemes are used at different levels, the IBN 323 has further responsibilities: when packets enter the sub-domain, the 324 IBN translates upper-level metadata into lower-level metadata; and 325 when packets leave the sub-domain at the termination of lower-level 326 SFPs, the IBN translates lower-level metadata into upper-level 327 metadata. 329 Appropriately configuring IBNs is key to ensure the consistency of 330 the overall SFC operation within a given domain that enables hSFC. 331 Classification rules (or lack thereof) in the IBN classifier can of 332 course impact higher levels. 334 3.1. IBN Path Configuration 336 The lower-level domain may be provisioned with valid high-level paths 337 or may allow any high-level paths. 339 When packets enter the sub-domain, the Service Path Identifier (SPI) 340 and Service Index (SI) are re-marked according to the path selected 341 by the (sub-domain) classifier. 343 At the termination of an SFP in the sub-domain, packets can be 344 restored to an original upper-level SFP by implementing one of these 345 methods: 347 1. Saving SPI and SI in transport-layer flow state (Section 3.1.1). 349 2. Pushing SPI and SI into a metadata header (Section 3.1.2). 351 3. Using unique lower-level paths per upper-level path coordinates 352 (Section 3.1.3). 354 4. Nesting NSH headers, encapsulating the higher-level NSH headers 355 within the lower-level NSH headers (Section 3.1.4). 357 5. Saving upper-level by a flow identifier (ID) and placing an hSFC 358 flow ID into a metadata header (Section 3.1.5). 360 3.1.1. Flow-Stateful IBN 362 An IBN can be flow-aware, returning packets to the correct higher- 363 level SFP on the basis, for example, of the transport-layer 364 coordinates (typically, a 5-tuple) of packets exiting the lower-level 365 SFPs. 367 When packets are received by the IBN on a higher-level path, the 368 encapsulated packets are parsed for IP and transport-layer (TCP, UDP, 369 etc.) coordinates. State is created, indexed by some or all 370 transport-coordinates ({source-IP, destination-IP, source-port, 371 destination-port and transport protocol} typically). The state 372 contains at least critical fields of the encapsulating SFC header; 373 additional information carried in the packet may also be extracted to 374 state creation. Note, that the some fields of a packet may be 375 altered by an SF of the sub-domain (e.g., source IP address). 377 One approach is to ensure that packets are returned back to the same 378 IBN at the end of the chain that classified the packet at the start 379 of the chain. If the packet is returned to a different egress IBN, 380 state must be synchronized between the IBNs. 382 When a packet returns to the IBN at the end of a chain, the SFC 383 header is removed, the packet is parsed for IP and transport-layer 384 coordinates, and state is retrieved from them. The state contains 385 the information required to forward the packet within the higher- 386 level service chain. 388 State cannot be created by packets arriving from the lower-level 389 chain; when state cannot be found for such packets, they must be 390 dropped. 392 This stateful approach is limited to use with SFs that retain the 393 transport coordinates of the packet. This approach cannot be used 394 with SFs that modify those coordinates (e.g., NATs) or otherwise 395 create packets for new coordinates other than those received (e.g., 396 as an HTTP cache might do to retrieve content on behalf of the 397 original flow). In both cases, the fundamental problem is the 398 inability to forward packets when state cannot be found for the 399 packet transport-layer coordinates. 401 In the stateful approach, there are issues caused by having state, 402 such as how long the state should be maintained, as well as whether 403 the state needs to be replicated to other devices to create a highly 404 available network. 406 It is valid to consider the state to be disposable after failure, 407 since it can be re-created by each new packet arriving from the 408 higher-level domain. For example, if an IBN loses all flow state, 409 the state is re-created by an end-point retransmitting a TCP packet. 411 If an SFC domain handles multiple network regions (e.g., multiple 412 private networks), the coordinates may be augmented with additional 413 parameters, perhaps using some metadata to identify the network 414 region. 416 In this stateful approach, it is not necessary for the sub-domain's 417 control plane to modify paths when higher-level paths are changed. 418 The complexity of the higher-level domain does not cause complexity 419 in the lower-level domain. 421 Since it doesn't depend on NSH in the lower domain, this flow- 422 stateful approach can be applied to translation methods of converting 423 NSH to other forwarding techniques (refer to Section 6). 425 3.1.2. Encoding Upper-Level Paths in Metadata 427 An IBN can push the upper-level SPI and SI (or encoding thereof) into 428 a metadata field of the lower-level encapsulation (e.g., placing 429 upper-level path information into a metadata field of NSH). When 430 packets exit the lower-level path, the upper-level SPI and SI can be 431 restored from the metadata retrieved from the packet. 433 This approach requires the SFs in the path to be capable of 434 forwarding the metadata and appropriately attaching metadata to any 435 packets injected for a flow. 437 Using new metadata header may inflate packet size when variable- 438 length metadata (type 2 from NSH [I-D.ietf-sfc-nsh]) is used. 440 It is conceivable that the MD-type 1 Mandatory Context Header fields 441 of NSH [I-D.ietf-sfc-nsh] are not all relevant to the lower-level 442 domain. In this case, one of the metadata slots of the Mandatory 443 Context Header could be repurposed within the lower-level domain, and 444 restored when leaving. 446 In this metadata approach, it is not necessary for the sub-domain's 447 control element to modify paths when higher-level paths are changed. 448 The complexity of the higher-level domain does not increase 449 complexity in the lower-level domain. 451 3.1.3. Using Unique Paths per Upper-Level Path 453 This approach assumes that paths within the sub-domain are 454 constrained so that a SPI (of the sub-domain) unambiguously indicates 455 the egress SPI and SI (of the upper domain). This allows the 456 original path information to be restored at sub-domain egress from a 457 look-up table using the sub-domain SPI. 459 Whenever the upper-level domain provisions a path via the lower-level 460 domain, the lower-level domain control plane must provision 461 corresponding paths to traverse the lower-level domain. 463 A down-side of this approach is that the number of paths in the 464 lower-level domain is multiplied by the number of paths in the 465 higher-level domain that traverse the lower-level domain. I.e., a 466 sub-path must be created for each combination of upper SPI/SI and 467 lower chain. 469 3.1.4. Nesting Upper-Level NSH within Lower-Level NSH 471 When packets arrive at an IBN in the top-level domain, the classifier 472 in the IBN determines the path for the lower-level domain and pushes 473 the new NSH header in front of the original NSH header. 475 As shown in Figure 3 the Lower-NSH header used to forward packets in 476 the lower-level domain precedes the Upper-NSH header from the top- 477 level domain. 479 +------------------+ 480 | Overlay Header | 481 +------------------+ 482 | Lower-NSH Header | 483 +------------------+ 484 | Upper-NSH Header | 485 +------------------+ 486 | Original Packet | 487 +------------------+ 489 Figure 3: Encapsulation of NSH within NSH 491 The traffic with the above stack of two NSH headers is to be 492 forwarded according to the Lower-NSH header in the lower-level SFC 493 domain. The Upper-NSH header is preserved in the packets but not 494 used for forwarding. At the last SFF of the chain of the lower-level 495 domain (which resides in the IBN), the Lower-NSH header is removed 496 from the packet, and then the packet is forwarded by the IBN to an 497 SFF of the upper-level domain. The packet will be forwarded in the 498 top-level domain according to the Upper-NSH header. 500 With such encapsulation, Upper-NSH information is carried along the 501 extent of the lower-level chain without modification. 503 A benefit of this approach is that it does not require state in the 504 IBN or configuration to encode fields in meta-data. 506 However, the down-side is it does require SFC-aware SFs in the lower- 507 level domain to be able to parse multiple NSH layers. If an SFC- 508 aware SF injects packets, it must also be able to deal with adding 509 appropriate multiple layers of headers to injected packets. 511 By increasing packet overhead, nesting may lead to fragmentation or 512 decreased MTU in some networks. 514 3.1.5. Stateful / Metadata Hybrid 516 The basic idea of this approach is for the IBN to save upper domain 517 encapsulation information such that it can be retrieved by a unique 518 identifier, termed an "hSFC Flow ID". An example is shown in 519 Table 1. 521 +-----------+-----+-----+----------+----------+----------+----------+ 522 | hSFC Flow | SPI | SI | Context1 | Context2 | Context3 | Context4 | 523 | ID | | | | | | | 524 +-----------+-----+-----+----------+----------+----------+----------+ 525 | 1 | 45 | 254 | 100 | 2112 | 12345 | 7 | 526 +-----------+-----+-----+----------+----------+----------+----------+ 528 Table 1: Example Mapping of an hSFC Flow ID to Upper-Level Header 530 The ID is placed in the metadata in NSH headers of the packet in the 531 lower domain, as shown in Figure 4. When packets exit the lower 532 domain, the IBN uses the ID to retrieve the appropriate NSH 533 encapsulation for returning the packet to the upper domain. 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Service Path Identifer | Service Index | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | hSFC Flow ID | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Mandatory Context Header | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Mandatory Context Header | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Mandatory Context Header | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Figure 4: Storing hSFC Flow ID in lower-level metadata 552 Advantages of this approach include: 554 o Does not require state based on 5-tuple, so it works with SFs that 555 change the IP addresses or ports of a packet such as NATs. 557 o Does not require all domains to have the same metadata scheme. 559 o Can be used to restore any upper-domain information, not just 560 service path. 562 o The lower domain only requires a single item of metadata 563 regardless of the number of items of metadata used in the upper 564 domain. (For MD-Type 1, this leaves 3 slots for use in the lower 565 domain.) 567 o No special functionality is required to be supported by an SFC- 568 aware SF, other than the usual ability to preserve metadata and to 569 apply metadata to injected packets. 571 Disadvantages include those of other stateful approaches, including 572 state timeout and replication mentioned in Section 3.1.1. 574 There may be a large number of unique NSH encapsulations to be 575 stored, given that the hSFC Flow ID must represent all of the bits in 576 the upper-level encapsulation. This might consume a lot of memory or 577 create out-of-memory situations in which IDs cannot be created or old 578 IDs are discarded while still in use. 580 3.2. Gluing Levels Together 582 The SPI or metadata included in a packet received by the IBN may be 583 used as input to reclassification and path selection within a lower- 584 level domain. 586 In some cases the meanings of the various path IDs and metadata must 587 be coordinated between domains for the sake of proper end-to-end SFC 588 operation. 590 One approach is to use well-known identifier values in metadata, 591 maintained in a global registry. 593 Another approach is to use well-known labels for chain identifiers or 594 metadata, as an indirection to the actual identifiers. The actual 595 identifiers can be assigned by control-plane systems. For example, a 596 sub-domain classifier could have a policy, "if pathID=classA then 597 chain packet to path 1234"; the higher-level controller would be 598 expected to configure the concrete higher-level pathID for classA. 600 3.3. Decrementing Service Index 602 Because the IBN acts as an SFC-aware SF to the higher-level domain, 603 it must decrement the Service Index in the NSH headers of the higher- 604 level path. This operation should be undertaken when the packet is 605 first received by the IBN, before applying any of the strategies of 606 Section 3.1, immediately prior to classification. 608 4. Sub-domain Classifier 610 Within the sub-domain (referring to Figure 2), once the IBN removes 611 higher-level encapsulation from incoming packets, it sends the 612 packets to the classifier, which selects the encapsulation for the 613 packet within the sub-domain. 615 One of the goals of the hierarchical approach is to make it easy to 616 have transport-flow-aware service chaining with bidirectional paths. 617 For example, it is desired that for each TCP flow, the client-to- 618 server packets traverse the same SF instances as the server-to-client 619 packets, but in the opposite sequence. We call this bidirectional 620 symmetry. If bidirectional symmetry is required, it is the 621 responsibility of the control plane to be aware of symmetric paths 622 and configure the classifier to chain the traffic in a symmetric 623 manner. 625 Another goal of the hierarchical approach is to simplify the 626 mechanisms of scaling in and scaling out SFs. All of the 627 complexities of load-balancing among multiple SFs can be handled 628 within a sub-domain, under control of the classifier, allowing the 629 higher-level domain to be oblivious to the existence of multiple SF 630 instances. 632 Considering the requirements of bidirectional symmetry and load- 633 balancing, it is useful to have all packets entering a sub-domain to 634 be received by the same classifier or a coordinated cluster of 635 classifiers. There are both stateful and stateless approaches to 636 ensuring bidirectional symmetry. 638 5. Control Plane Elements 640 Although SFC control protocols have not yet been standardized (2016), 641 from the point of view of hierarchical service function chaining we 642 have these expectations: 644 o Each control-plane instance manages a single level of hierarchy of 645 a single domain. 647 o Each control plane is agnostic about other levels of hierarchy. 648 This aspect allows humans to reason about the system within a 649 single domain and allows control-plane algorithms to use only 650 domain-local inputs. Top-level control does not need visibility 651 to sub-domain policies, nor does sub-domain control need 652 visibility to higher-level policies. (Top-level control considers 653 a sub-domain as though it were an SF.) 655 o Sub-domain control planes are agnostic about control planes of 656 other sub-domains. This allows both humans and machines to 657 manipulate sub-domain policy without considering policies of other 658 domains. 660 Recall that the IBN acts as an SFC-aware SF in the higher-level 661 domain (receiving SF instructions from the higher-level control 662 plane) and as a classifier in the lower-level domain (receiving 663 classification rules from the sub-domain control plane). In this 664 view, it is the IBN that glues the layers together. 666 The above expectations are not intended to prohibit network-wide 667 control. A control hierarchy can be envisaged to distribute 668 information and instructions to multiple domains and sub-domains. 669 Control hierarchy is outside the scope of this document. 671 6. Extension for Adapting to NSH-Unaware Service Functions 673 The hierarchical approach can be used for dividing networks into NSH- 674 aware and NSH-unaware domains by converting NSH encapsulation to 675 other forwarding techniques (e.g., 5-tuple-based routing with 676 OpenFlow), as shown in Figure 5. 678 * * * * * * * * * * * * * * * * * * 679 * NSH-aware domain * 680 * +-------+ +-------+ * 681 * | SF#1 | | SF#5 | * 682 * +-o---o-+ +-o---o-+ * 683 * ^ | ^ | * 684 * +-|---|-+ +-|---|-+ * 685 * | |SFF| | | |SFF| | * 686 * +-|---|-+ +-|---|-+ * 687 * . | | . * 688 * +--+ / | | \ * 689 -->|CF|--' | | '-------> 690 * +--+ v | * 691 * +---o-----------o---+ * 692 .*.*.*.*.| / | IBN | \ |*.*.*. 693 . +-o--o---------o--o-+ . 694 . | | ^ ^ . 695 . | +-+ +-+ | . 696 . +---+ v | +---+ . 697 . | +-o-----o-+ | . 698 . | | SF#2 | | . 699 . | +---------+ | . 700 . +--+ +--+ . 701 . | +---------+ | . 702 . v | v | . 703 . +-o---o-+ +-o---o-+ . 704 . | SF#3 | | SF#4 | . 705 . +-------+ +-------+ . 706 . NSH-unaware domain . 707 . . . . . . . . . . . . . . . . . . 709 SF#1 and SF#5 are NSH-aware and SF#2, SF#3 and SF#4 are NSH-unaware. 710 In the NSH-unaware domain, packets are conveyed in a format supported 711 by SFs which are deployed there. 713 Figure 5: Dividing NSH-aware and NSH-unaware domains 715 6.1. Purpose 717 This approach is expected to facilitate service chaining in networks 718 in which NSH-aware and NSH-unaware SFs coexist. Some examples of 719 such situations are: 721 o In a period of transition from legacy SFs to NSH-aware SFs, and 723 o Supporting multi-tenancy. 725 6.2. Requirements for IBN 727 In this usage, an IBN classifier is required to have an NSH 728 conversion table for applying packets to appropriate lower-level 729 paths and returning packets to the correct higher-level paths. For 730 example, the following methods would be used for saving/restoring 731 upper-level path information: 733 o Saving SPI and SI in transport-layer flow state (refer to 734 Section 3.1.1) and 736 o Using unique lower-level paths per upper-level NSH coordinates 737 (refer to Section 3.1.3). 739 Especially, the use of unique paths approach would be good for 740 translating NSH to a different forwarding technique in the lower 741 level. A single path in the upper level may be branched to multiple 742 paths in the lower level such that any lower-level path is only used 743 by one upper-level path. This allows unambiguous restoration to the 744 upper-level path. 746 In addition, an IBN might be required to convert metadata contained 747 in NSH to the format appropriate to the packet in the lower-level 748 path. For example, some legacy SFs identify subscriber based on 749 information of network topology, such as VID, and IBN would be 750 required to create VLAN to packets from metadata if subscriber 751 identifier is conveyed as metadata in higher-level domains. 753 Other fundamental functions required as IBN (e.g., maintaining 754 metadata of upper level or decrementing Service Index) are same as 755 normal usage. 757 It is useful to permit metadata to be transferred between levels of a 758 hierarchy. Metadata from a higher level may be useful within a sub- 759 domain and a sub-domain may augment metadata for consumption in an 760 upper domain. However, allowing uncontrolled metadata between 761 domains may lead to forwarding failures. 763 In order to prevent SFs of low-level SFC-enabled domains from 764 supplying (illegitimate) metadata, IBNs may be instructed to 765 permit specific metadata types to exit the sub-domain. Such 766 control over the metadata in the upper level is the responsibility 767 of the upper-level control plane. 769 To limit unintentional metadata reaching SFs of low-level SFC- 770 enabled sub-domains, IBNs may be instructed to permit specific 771 metadata types into the sub-domain. Such control of metadata in 772 the low-level domain is the responsibility of the lower-level 773 control plane. 775 7. Acknowledgements 777 The concept of Hierarchical Service Path Domains was introduced in 778 [I-D.homma-sfc-forwarding-methods-analysis] as a means to improve 779 scalability of service chaining in large networks. 781 The concept of nested NSH headers was introduced in 782 [I-D.ao-sfc-for-dc-interconnect] as a means of creating hierarchical 783 SFC in a data center. 785 The authors would like to thank the following individuals for 786 providing valuable feedback: 788 Ron Parker 790 Christian Jacquenet 792 Jie Cao 794 8. IANA Considerations 796 This memo includes no request to IANA. 798 9. Security Considerations 800 Hierarchical service function chaining makes use of service chaining 801 architecture, and hence inherits the security considerations 802 described in the architecture document [RFC7665]. 804 Furthermore, hierarchical service function chaining inherits security 805 considerations of the data-plane protocols (e.g., NSH) and control- 806 plane protocols used to realize the solution. 808 The systems described in this document bear responsibility for 809 forwarding Internet traffic. In some cases the systems are 810 responsible for maintaining separation of traffic in private 811 networks. 813 This document describes systems within different domains of 814 administration that must have consistent configurations in order to 815 properly forward traffic and to maintain private network separation. 816 Any protocol designed to distribute the configurations must be secure 817 from tampering. 819 All of the systems and protocols must be secure from modification by 820 untrusted agents. 822 9.1. Control Plane 824 Security considerations related to the control plane are discussed in 825 [I-D.ietf-sfc-control-plane]. These considerations apply for both 826 high-level and low-level domains. 828 9.2. Infinite Forwarding Loops 830 Distributing policies among multiple domains may lead to forwarding 831 loops. It is acknowledged that NSH supports the ability to detect 832 loops (Section 3.3), but means to ensure the consistency of the 833 policies should be enabled at all levels of a domain. Within the 834 context of hSFC, it is the responsibility of the Control Elements at 835 all levels to prevent such (unwanted) loops. 837 10. References 839 10.1. Normative References 841 [I-D.ietf-sfc-control-plane] 842 Boucadair, M., "Service Function Chaining (SFC) Control 843 Plane Components & Requirements", draft-ietf-sfc-control- 844 plane-06 (work in progress), May 2016. 846 [I-D.ietf-sfc-nsh] 847 Quinn, P. and U. Elzur, "Network Service Header", draft- 848 ietf-sfc-nsh-05 (work in progress), May 2016. 850 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 851 Chaining (SFC) Architecture", RFC 7665, 852 DOI 10.17487/RFC7665, October 2015, 853 . 855 10.2. Informative References 857 [I-D.ao-sfc-for-dc-interconnect] 858 Ao, T. and W. Bo, "Hierarchical SFC for DC 859 Interconnection", draft-ao-sfc-for-dc-interconnect-01 860 (work in progress), October 2015. 862 [I-D.homma-sfc-forwarding-methods-analysis] 863 Homma, S., Naito, K., Lopez, D., Stiemerling, M., Dolson, 864 D., Gorbunov, A., Leymann, N., Bottorff, P., and d. 865 don.fedyk@hpe.com, "Analysis on Forwarding Methods for 866 Service Chaining", draft-homma-sfc-forwarding-methods- 867 analysis-05 (work in progress), January 2016. 869 [I-D.ietf-sfc-dc-use-cases] 870 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 871 Homma, "Service Function Chaining Use Cases In Data 872 Centers", draft-ietf-sfc-dc-use-cases-02 (work in 873 progress), January 2015. 875 Appendix A. Examples of Hierarchical Service Function Chaining 877 The advantage of hierarchical service function chaining compared with 878 normal or flat service function chaining is that it can reduce the 879 management complexity significantly. This section discusses examples 880 that show those advantages. 882 A.1. Reducing the Number of Service Function Paths 884 In this case, hierarchical service function chaining is used to 885 simplify service function chaining management by reducing the number 886 of Service Function Paths. 888 As shown in Figure 6, there are two domains, each with different 889 concerns: a Security Domain that selects Service Functions based on 890 network conditions and an Optimization Domain that selects Service 891 Functions based on traffic protocol. 893 In this example there are five security functions deployed in the 894 Security Domain. The Security Domain operator wants to enforce the 895 five different security policies, and the Optimization Domain 896 operator wants to apply different optimizations (either cache or 897 video optimization) to each of these two types of traffic. If we use 898 flat SFC (normal branching), 10 SFPs are needed in each domain. In 899 contrast, if we use hierarchical SFC, only 5 SFPs in Security Domain 900 and 2 SFPs in Optimization Domain will be required, as shown in 901 Figure 7. 903 In the flat model, the number of SFPs is the product of the number of 904 functions in all of the domains. In the hSFC model, the number of 905 SFPs is the sum of the number of functions. For example, adding a 906 "bypass" path in the Optimization Domain would cause the flat model 907 to require 15 paths (5 more), but cause the hSFC model to require one 908 more path in the Optimization Domain. 910 . . . . . . . . . . . . . . . . . . . . . . . . . 911 . Security Domain . . Optimization Domain . 912 . . . . 913 . +-1---[ ]----------------->[Cache ]-------> 914 . | [ WAF ] . . . 915 . +-2-->[ ]----------------->[Video Opt.]----> 916 . | . . . 917 . +-3---[Anti ]----------------->[Cache ]-------> 918 . | [Virus] . . . 919 . +-4-->[ ]----------------->[Video Opt.]----> 920 . | . . . 921 . +-5-->[ ]----------------->[Cache ]-------> 922 [DPI]--->[CF]---| [ IPS ] . . . 923 . +-6-->[ ]----------------->[Video Opt.]----> 924 . | . . . 925 . +-7-->[ ]----------------->[Cache ]-------> 926 . | [ IDS ] . . . 927 . +-8-->[ ]----------------->[Video Opt.]----> 928 . | . . . 929 . +-9-->[Traffic]--------------->[Cache ]-------> 930 . | [Monitor] . . . 931 . +-10->[ ]--------------->[Video Opt.]----> 932 . . . . . . . . . . . . . . . . . . . . . . . . . 934 The classifier must select paths that determine the combination of 935 Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt, 936 3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5: IPS+Cache, 937 6:IPS+VideoOpt, 7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache, 938 10:TrafficMonitor+VideoOpt 940 Figure 6: Flat SFC (normal branching) 942 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943 . Security Domain . . Optimization Domain . 944 . . . . 945 [CF]---->[ [CF] IBN ]---------->[ [CF] IBN ]----> 946 . | ^ . . | ^ . 947 . +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ . 948 . | | . . | | . 949 . +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ . 950 . | | . . . 951 . +----->[ IPS ]-----+ . . . . . . . . . . . . . . . . 952 . | | . 953 . +----->[ IDS ]-----+ . 954 . | | . 955 . +-->[ Traffic ]----+ . 956 . [ Monitor ] . 957 . . . . . . . . . . . . . . . 959 Figure 7: Simplified path management with Hierarchical SFC 961 A.2. Managing a Distributed Data-Center Network 963 Hierarchical service function chaining can be used to simplify inter- 964 data-center SFC management. In the example of Figure 8, shown below, 965 there is a central data center (Central DC) and multiple local data 966 centers (Local DC#1, #2, #3) that are deployed in a geographically 967 distributed manner. All of the data centers are under a single 968 administrative domain. 970 The central DC may have some service functions that the local DC 971 needs, such that the local DC needs to chain traffic via the central 972 DC. This could be because: 974 o Some service functions are deployed as dedicated hardware 975 appliances, and there is a desire to lower the cost (both CAPEX 976 and OPEX) of deploying such service functions in all data centers. 978 o Some service functions are being trialed, introduced or otherwise 979 handle a relatively small amount of traffic. It may be cheaper to 980 manage these service functions in a single central data center and 981 steer packets to the central data center than to manage these 982 service functions in all data centers. 984 +-----------+ 985 |Central DC | 986 +-----------+ 987 ^ ^ ^ 988 | | | 989 .---|--|---|----. 990 / / | | \ 991 / / | \ \ 992 +-----+ / / | \ \ +-----+ 993 |Local| | / | \ | |Local| 994 |DC#1 |--|--. | .----|----|DC#3 | 995 +-----+ | | | +-----+ 996 \ | / 997 \ | / 998 \ | / 999 '----------------' 1000 | 1001 +-----+ 1002 |Local| 1003 |DC#2 | 1004 +-----+ 1006 Figure 8: Simplify inter-DC SFC management 1008 For large data center operators, one local DC may have tens of 1009 thousands of servers and hundred of thousands of virtual machines. 1010 SFC can be used to manage user traffic. For example, SFC can be used 1011 to classify user traffic based on service type, DDoS state etc. 1013 In such large scale data center, using flat SFC is very complex, 1014 requiring a super-controller to configure all data centers. For 1015 example, any changes to Service Functions or Service Function Paths 1016 in the central DC (e.g., deploying a new SF) would require updates to 1017 all of the Service Function Paths in the local DCs accordingly. 1018 Furthermore, requirements for symmetric paths add additional 1019 complexity when flat SFC is used in this scenario. 1021 Conversely, if using hierarchical SFC, each data center can be 1022 managed independently to significantly reduce management complexity. 1023 Service Function Paths between data centers can represent abstract 1024 notions without regard to details within data centers. Independent 1025 controllers can be used for the top level (getting packets to pass 1026 the correct data centers) and local levels (getting packets to 1027 specific SF instances). 1029 Authors' Addresses 1031 David Dolson 1032 Sandvine 1033 408 Albert Street 1034 Waterloo, ON N2L 3V3 1035 Canada 1037 Phone: +1 519 880 2400 1038 Email: ddolson@sandvine.com 1040 Shunsuke Homma 1041 NTT, Corp. 1042 3-9-11, Midori-cho 1043 Musashino-shi, Tokyo 180-8585 1044 Japan 1046 Email: homma.shunsuke@lab.ntt.co.jp 1048 Diego R. Lopez 1049 Telefonica I+D 1050 Don Ramon de la Cruz, 82 1051 Madrid 28006 1052 Spain 1054 Phone: +34 913 129 041 1055 Email: diego.r.lopez@telefonica.com 1057 Mohamed Boucadair 1058 Orange 1059 Rennes 35000 1060 France 1062 Email: mohamed.boucadair@orange.com 1064 Dapeng Liu 1065 Alibaba Group 1066 Beijing 100022 1067 China 1069 Email: max.ldp@alibaba-inc.com 1070 Ting Ao 1071 ZTE Corporation 1072 No.889,Bibo Rd.,Zhangjiang Hi-tech Park 1073 Shanghai 201203 1074 China 1076 Phone: +86-21-688976442 1077 Email: ao.ting@zte.com.cn 1079 Vu Anh Vu 1080 Soongsil University 1081 369 Sangdo-ro 1082 Seoul, Dongjak-gu 06978 1083 Korea 1085 Email: vuva@dcn.ssu.ac.kr