idnits 2.17.1 draft-dolson-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 25, 2015) is 3253 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-homma-sfc-forwarding-methods-analysis-01 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-07 == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-02 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-00 Summary: 0 errors (**), 0 flaws (~~), 6 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: November 26, 2015 NTT 6 D. Lopez 7 Telefonica I+D 8 May 25, 2015 10 Hierarchical Service Chaining 11 draft-dolson-sfc-hierarchical-00 13 Abstract 15 This document describes a network architecture for deploying service 16 function chaining with multiple levels of administration within an 17 organization. 19 The multiple levels of administration allow operators to 20 compartmentalize a large network into multiple domains of 21 responsibility, with each domain being independently managed and 22 consequently easier to reason about. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 26, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Hierarchical Service Chaining . . . . . . . . . . . . . . . . 3 61 2.1. Top Level . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 5 63 3. SF Domain Gateway . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. SF Domain Gateway Path Configuration . . . . . . . . . . 6 65 3.1.1. Flow-Stateful SF Domain Gateway . . . . . . . . . . . 6 66 3.1.2. Saving Upper-Level Path in Meta-Data . . . . . . . . 7 67 3.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 8 68 3.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 8 69 4. Sub-domain Classifier . . . . . . . . . . . . . . . . . . . . 8 70 5. Controllers . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 10.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Service Function Chaining (SFC) allows an operator to prescribe 83 packet paths taken through their network. SFC is described in detail 84 in the SFC architecture document [I-D.ietf-sfc-architecture], and is 85 not repeated here. 87 In this document we consider the difficult problem of implementing 88 SFC across a large, geographically dispersed network comprised of 89 millions of hosts and thousands of network forwarding elements. We 90 expect asymmetrical routing is inherent in the network, while 91 recognizing that some Service Functions require bidirectional traffic 92 for transport-layer sessions. We expect some paths need to be 93 selected on the basis of application metadata accessible to the 94 network, with 5-tuple stickiness to specific Service Function 95 instances. 97 Difficult problems are often made easier by decomposing them in a 98 hierarchical (nested) manner. So instead of considering an 99 omniscient controller that can create complete paths from one end of 100 the network to the other, we break the network into smaller pieces. 101 Each piece may support a subset of the network applications or a 102 subset of the users. 104 A previous example of simplifying a network by using multiple SF 105 domains can be seen in draft-ietf-sfc-dc-use-cases 106 [I-D.ietf-sfc-dc-use-cases]. 108 We assume the SF technology uses NSH [I-D.ietf-sfc-nsh] or a similar 109 labeling mechanism. 111 The "domains" discussed in this document are assumed to be under 112 control of a single organization, such that here is a strong trust 113 relationship between the domains. The intention of creating multiple 114 domains is to improve the ability to operate a network. It is 115 outside of the scope of the document to consider domains operated by 116 different organizations. 118 1.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2. Hierarchical Service Chaining 126 A hierarchy has multiple conceptual levels. In Hierarchical Service 127 Chaining, the top-most level encompasses the entire network domain to 128 be managed. Lower levels encompass smaller portions of the network. 130 2.1. Top Level 132 Considering example Figure 1, a top-level network domain includes SFC 133 components distributed over a wide area, including 135 o classifiers (CFs), 137 o Service Function Forwarders (SFFs) and 139 o Sub-Domains. 141 For the sake of clarity, components of the underlay network are not 142 shown; an underlay network is assumed to provide connectivity between 143 service function components. 145 Top-level service function paths carry packets from classifiers to 146 egress via SFFs and sub-domains, with the operations within sub- 147 domains being opaque to the higher levels. 149 Network-wide Service Chaining orchestration is only concerned with 150 creating service paths from network edge points to sub-domains within 151 data centers and configuring classifiers at a coarse level (e.g., 152 based on source or destination host) to get traffic onto paths that 153 will arrive at appropriate sub-domains. The figure shows one 154 possible service chain passing from edge, through two sub-domains, to 155 network egress. 157 At this high level, the number of SF Paths required is on the order 158 of the number of ways in which a packet needs to traverse different 159 sub-domains and egress the network. 161 It should be assumed that some service functions in the network 162 require bidirectional symmetry of paths (see more in section 163 Section 4). Therefore the classifiers at the top level need to 164 ensure server-to-client packets take the reverse path of client-to- 165 server packet through sub-domains. 167 +------------+ 168 |Sub-domain#1| 169 | in DC1 | 170 +----+-------+ 171 | 172 .---- SFF1 ------. +--+ 173 +--+ / / | \--|CF| 174 --->|CF|--/---->' | \ +--+ 175 +--+ / SC#1 | \ 176 | | | 177 | V .------>|---> 178 | / / | 179 \ | / / 180 +--+ \ | / / +--+ 181 |CF|---\ | / /---|CF| 182 +--+ '---- SFF2 ------' +--+ 183 | 184 +----+-------+ 185 |Sub-domain#2| 186 | in DC2 | 187 +------------+ 189 One path is shown from edge classifier to SFF1 to Sub-domain#1 to 190 SFF1 to SFF2 to Sub-domain#2 to SFF2 to network egress. 192 Figure 1: Network-wide view of Top Level of Hierarchy 194 2.2. Lower Levels 196 Each of the sub-domains in Figure 1 is an SFC system unto itself. 198 Unlike the top level, however, data packets entering the sub-domain 199 are already encapsulated within SFC transport. Figure 2 shows a sub- 200 domain interfaced to a higher-level domain by means of an SF-Domain 201 Gateway. It is the purpose of the SF Domain Gateway to remove 202 packets from the SFC transport, apply Classification, and direct the 203 packets to the selected local service function paths ending back at 204 the SF Domain Gateway. The SF Domain Gateway finally restores 205 packets to the original SFC transport and hands them off to SFFs. 207 Each sub-domain intersects a subset of the total paths that are 208 possible in the higher-level domain. An SF Domain Gateway is 209 concerned with higher-level paths, but only those traversing the sub- 210 domain. The top-level controller configures top-level paths at the 211 SF Domain Gateway, but the top-level paths are otherwise unknown 212 within the sub-domain. The SF Domain Gateway provides adaptation 213 between the levels. 215 +----+ +-----+ +----------------------+ +-----+ 216 | |SC#1| SFF | | SF Domain Gateway 1 | | SFF | 217 ->| |================* *===============> 218 | | +-----+ | # (in DC 1) # | +-----+ 219 | CF | | V # | 220 | | |+---+ +---+| Top domain 221 | | * * * * *||CF | * * * * * *|SFF|| * * * * * 222 | | * |+---+ +-+-+| * 223 +----+ * | | | | | | Sub * 224 * +-o-o--------------o-o-+ domain* 225 * SC#2 | |SC#1 ^ ^ #1 * 226 * +-----+ | | | * 227 * | V | | * 228 * | +---+ +------+ | | * 229 * | |SFF|->|SF#1.1|--+ | * 230 * | +---+ +------+ | * 231 * V | * 232 * +---+ +------+ +---+ +------+ * 233 * |SFF|->|SF#2.1|->|SFF|->|SF#2.2| * 234 * +---+ +------+ +---+ +------+ * 235 * * * * * * * * * * * * * * * * * * * * * * 237 *** Sub-domain boundary; === top-level chain; --- low-level chain. 239 Figure 2: Sub-domain within a higher-level domain 241 If desired, the pattern can be applied recursively. For example, 242 SF#1.1 in Figure 2 could be a sub-domain of the sub-domain. 244 3. SF Domain Gateway 246 A network element termed "SF Domain Gateway" bridges packets between 247 domains. It looks like an SF to the higher level, and looks like a 248 classifier and end-of-chain to the lower level. 250 To achieve the benefits of hierarchy, the SF Domain Gateway should be 251 making more granular traffic classifications at the lower level than 252 the traffic passed to it. This means that the number of SF Paths 253 within the lower level is larger than the number of SF Paths arriving 254 to the gateway. 256 The SF Domain Gateway is also the termination of lower-level SF 257 paths. This is because the packets exiting lower-level SF paths must 258 be returned to the higher-level SF paths and forwarded to the next 259 hop in the higher-level domain. 261 3.1. SF Domain Gateway Path Configuration 263 An operator of a lower-level SF Domain may be aware of which high- 264 level paths transit their domain, or they may wish to accept any 265 paths. 267 After exiting a path in the sub-domain, packets can be restored to an 268 upper-level SF path by these methods: 270 1. Statefully per flow, 272 2. Pushing path identifier into meta-data, 274 3. Using unique lower-level paths per upper-level path. 276 3.1.1. Flow-Stateful SF Domain Gateway 278 An SF Domain Gateway can be flow-aware, returning packets to the 279 correct higher-level SF path on the basis of 5-tuple of packets 280 exiting the lower-level SF paths. 282 When packets are received by the SF Domain Gateway on a higher-level 283 path, the encapsulated packets are parsed for IP and transport-layer 284 (TCP or UDP) coordinates. State is created, indexed by the 5-tuple 285 of {source-ip, destination-ip, source-port, destination-port and 286 transport protocol}. The state contains critical fields of the 287 encapsulating SFC header (or perhaps the entire header). 289 When a packet returns to the SF Domain Gateway at the end of a chain, 290 the SFC header is removed, the packet is parsed for IP and transport- 291 layer coordinates, and state is retrieved by the 5-tuple of the 292 packet. The state contains the information required to forward the 293 packet within the higher-level service chain. 295 In the stateful approach, there are issues caused by the state, such 296 as how long the state should be retained, as well as whether the 297 state needs to be replicated to other devices to create a highly 298 available network. 300 It is valid to consider the state disposable, since it can be re- 301 created by each new packet arriving from the higher-level domain. 302 For example, if an SF-Domain Gateway loses all flow state, the state 303 is re-created by an end-point retransmitting a TCP packet. 305 If a network handles multiple routing domains, the 5-tuple may be 306 augmented with a 6th parameter, perhaps using some meta-data to 307 identify the routing domain. 309 In this stateful approach, it is not necessary for the sub-domain's 310 controller to modify paths when higher-level paths are changed. The 311 complexity of the higher-level domain does not cause complexity in 312 the lower-level domain. 314 3.1.2. Saving Upper-Level Path in Meta-Data 316 An SF Domain Gateway can push the upper-level service path identifier 317 (SPI) and service index (SI) into a meta-data field of the lower- 318 level NSH encapsulation. When packets exit the lower-level path, the 319 upper-level SPI and SI can be restored from the meta-data retrieved 320 from the packet. 322 This approach requires the SFs in the path to be capable of 323 forwarding the meta-data and to appropriately apply meta-data to any 324 packets injected for a flow. 326 Using new meta-data may inflate packet size when variable-length 327 meta-data (type 2 from NSH [I-D.ietf-sfc-nsh]) is used. 329 It is conceivable that the MD-type 1 Mandatory Context Header fields 330 of NSH [I-D.ietf-sfc-nsh] are not all relevant to the lower-level 331 domain. In this case, one of the meta-data slots of the Mandatory 332 Context Header could be repurposed within the lower-level domain. 333 (And restored when leaving.) 335 In this meta-data approach, it is not necessary for the sub-domain's 336 controller to modify paths when higher-level paths are changed. The 337 complexity of the higher-level domain does not cause complexity in 338 the lower-level domain. 340 3.1.3. Using Unique Paths per Upper-Level Path 342 In this approach, paths within the sub-domain are constrained so that 343 a path identifier (of the sub-domain) unambiguously indicates the 344 egress path (of the upper domain). 346 Whenever the upper-level domain provisions a path via the lower-level 347 domain, the lower-level domain controller must provision 348 corresponding paths to traverse the lower-level domain. 350 A down-side of this approach is that the number of paths in the 351 lower-level domain is multiplied by the number of paths in the 352 higher-level domain that traverse the lower-level domain. (I.e., a 353 sub-path for each combination of upper Path identifier and lower 354 path.) 356 3.2. Gluing Levels Together 358 The path identifier or metadata on a packet received by the SF Domain 359 Gateway may be used as input to reclassification and path selection 360 within the lower-level domain. 362 In some cases the meanings of the various path IDs and metadata must 363 be coordinated between domains. 365 One approach is to use well-known identifier values in meta-data, 366 communicated by some organizational registry. 368 Another approach is to use well-known labels for path identifiers or 369 meta-data, as an indirection to the actual identifiers. The actual 370 identifiers can be assigned by control systems. For example, a sub- 371 domain classifier could have a policy, "if pathID=classA then chain 372 packet to path 1234"; the higher-level controller would be expected 373 to configure the concrete higher-level pathID for classA. 375 4. Sub-domain Classifier 377 Within the sub-domain (referring to Figure 2), after the SF Domain 378 Gateway removes incoming packets from the higher-level encapsulation, 379 it sends the packets to the classifier, which selects the 380 encapsulation for the packet within the sub-domain. 382 One of the goals of the hierarchical approach is to make it tractable 383 to have transport-flow-aware service chaining with bidirectional 384 paths. For example, it is desired that for each TCP flow, the 385 client-to-server packets traverse the same SFs as the server-to- 386 client packets, but in the opposite sequence. We call this 387 bidirectional symmetry. If bidirectional symmetry is required, it is 388 the responsibility of the classifier to be aware of symmetric paths 389 and chain the traffic in a symmetric manner. 391 Another goal of the hierarchical approach is to simplify the 392 mechanisms of scaling in and scaling out service functions. All of 393 the complexities of load-balancing to multiple SFs can be handled 394 within a sub-domain, under control of the classifier, allowing the 395 higher-level domain to be oblivious to the existence of multiple SF 396 instances. 398 Considering the requirements of bidirectional symmetry and load- 399 balancing, it is useful to have all packets entering a sub-domain to 400 be received by the same classifier or a coordinated cluster of 401 classifiers. There are both stateful and stateless approaches to 402 ensuring bidirectional symmetry. 404 5. Controllers 406 Controllers have been mentioned in this document without being 407 explained. Although controllers have not yet been standardized, from 408 the point of view of hierarchical service chaining we have these 409 expectations: 411 Each controller manages a single level of hierarchy. 413 Each controller is agnostic about other levels of hierarchy. 415 Sub-domain controllers are agnostic about controllers of other 416 sub-domains. 418 6. Summary 420 The goals of the hierarchical SFC architecture are to make a large- 421 scale network easier to reason about, simpler to control and allow 422 independent domains of administration. This document has outlined an 423 approach that serves those goals, with some suggested approaches to 424 implementing the SF Domain Gateway. 426 7. Acknowledgements 428 The concept of Hierarchical Service Path Domains was introduced in 429 draft-homma-sfc-forwarding-methods-analysis-01 430 [I-D.homma-sfc-forwarding-methods-analysis] as a means to improve 431 scalability of service chaining in large networks. 433 8. IANA Considerations 435 This memo includes no request to IANA. 437 9. Security Considerations 439 Hierarchical service chaining makes use of service chaining 440 architecture, and hence inherits the security considerations 441 described in the architecture document. 443 Furthermore, hierarchical service chaining inherits security 444 considerations of the data-plane protocols (e.g., NSH) and control- 445 plane protocols used to realize the solution. 447 The systems described in this document bear responsibility for 448 forwarding internet traffic. In some cases the systems are 449 responsible for maintaining separation of traffic in private 450 networks. 452 This document describes systems within different domains of 453 administration that must have consistent configurations in order to 454 properly forward traffic and to maintain private network separation. 455 Any protocol designed to distribute the configurations must be secure 456 from tampering. 458 All of the systems and protocols must be secure from modification by 459 untrusted agents. 461 10. References 463 10.1. Normative References 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, March 1997. 468 10.2. Informative References 470 [I-D.homma-sfc-forwarding-methods-analysis] 471 Homma, S., Kengo, K., Lopez, D., Stiemerling, M., and D. 472 Dolson, "Analysis on Forwarding Methods for Service 473 Chaining", draft-homma-sfc-forwarding-methods-analysis-01 474 (work in progress), January 2015. 476 [I-D.ietf-sfc-architecture] 477 Halpern, J. and C. Pignataro, "Service Function Chaining 478 (SFC) Architecture", draft-ietf-sfc-architecture-07 (work 479 in progress), March 2015. 481 [I-D.ietf-sfc-dc-use-cases] 482 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 483 Homma, "Service Function Chaining Use Cases In Data 484 Centers", draft-ietf-sfc-dc-use-cases-02 (work in 485 progress), January 2015. 487 [I-D.ietf-sfc-nsh] 488 Quinn, P. and U. Elzur, "Network Service Header", draft- 489 ietf-sfc-nsh-00 (work in progress), March 2015. 491 Authors' Addresses 493 David Dolson 494 Sandvine 495 408 Albert Street 496 Waterloo, ON N2L 3V3 497 Canada 499 Phone: +1 519 880 2400 500 Email: ddolson@sandvine.com 502 Shunsuke Homma 503 NTT, Corp. 504 3-9-11, Midori-cho 505 Musashino-shi, Tokyo 180-8585 506 Japan 508 Email: homma.shunsuke@lab.ntt.co.jp 510 Diego R. Lopez 511 Telefonica I+D 512 Don Ramon de la Cruz, 82 513 Madrid 28006 514 Spain 516 Phone: +34 913 129 041 517 Email: diego.r.lopez@telefonica.com