idnits 2.17.1 draft-boucadair-sfc-requirements-06.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 (February 13, 2015) is 3360 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-11 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Informational France Telecom 5 Expires: August 17, 2015 Y. Jiang 6 Huawei Technologies Co., Ltd. 7 R. Parker 8 Affirmed Networks 9 K. Naito 10 NTT 11 February 13, 2015 13 Requirements for Service Function Chaining (SFC) 14 draft-boucadair-sfc-requirements-06 16 Abstract 18 This document identifies the requirements for the Service Function 19 Chaining (SFC). 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 17, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. Detailed Requirements List . . . . . . . . . . . . . . . . . 3 64 3.1. Instantiating and Invoking Service Functions . . . . . . 3 65 3.2. Chaining Service Functions . . . . . . . . . . . . . . . 4 66 3.3. MTU Requirements . . . . . . . . . . . . . . . . . . . . 5 67 3.4. Independence from the Underlying Transport Infrastructure 68 Requirements . . . . . . . . . . . . . . . . . . . . . . 6 69 3.5. Traffic Classification Requirements . . . . . . . . . . . 6 70 3.6. Data Plane Requirements . . . . . . . . . . . . . . . . . 7 71 3.7. OAM Requirements . . . . . . . . . . . . . . . . . . . . 8 72 3.8. Recovery and Load Balancing Requirements . . . . . . . . 10 73 3.9. Compatibility with Legacy Service Functions Requirements 11 74 3.10. QoS Requirements . . . . . . . . . . . . . . . . . . . . 11 75 3.11. Security Requirements . . . . . . . . . . . . . . . . . . 11 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 8.2. Informative References . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 This document identifies the requirements for the Service Function 87 Chaining (SFC). 89 The overall problem space is described in 90 [I-D.ietf-sfc-problem-statement]. 92 2. Terminology 94 The reader should be familiar with the terms defined in 95 [I-D.ietf-sfc-problem-statement]. 97 The document makes use of the following terms: 99 o SFC-enabled domain: denotes a network (or a region thereof) that 100 implements SFC. 102 o Service Function Loop: If a Service Function Chain is structured 103 to not invoke Service Functions multiple times, a loop is the 104 error that occurs when the same Service Function is invoked 105 several times when handling data bound to that Service Function 106 Chain. In other words, a loop denotes an error that occurs when a 107 packet handled by a Service Function, forwarded onwards, and 108 arrives once again at that Service Function while this is not 109 allowed by the Service Function Chain it is bound to. 111 o Service Function Spiral: denotes a Service Function Chain in which 112 data is handled by a Service Function, forwarded onwards, and 113 arrives once again at that Service Function. 115 * Note that some Service Functions support built-in functions to 116 accommodate spirals; these service-specific functions may 117 require that the data received in a spiral should differ in a 118 way that will result in a different processing decision than 119 the original data. This document does not make such 120 assumption. 122 * A Service Function Chain may involve one or more Service 123 Function Spirals. 125 * Unlike Service Function loop, spirals are not considered as 126 errors. 128 3. Detailed Requirements List 130 The following set of functional requirements should be considered for 131 the design of the Service Function Chaining solution. 133 3.1. Instantiating and Invoking Service Functions 135 SF_REQ#1: The solution MUST NOT make any assumption on whether 136 Service Functions (SF) are deployed directly on physical 137 hardware, as one or more Virtual Machines, or any 138 combination thereof. 140 SF_REQ#2: The solution MUST NOT make any assumption on whether 141 Service Functions each reside on a separate addressable 142 Network Element, or as a horizontal scaling of Service 143 Functions, or are co-resident in a single addressable 144 Network Element, or any combination thereof. 146 Note: Communications between Service Functions having 147 the same locator are considered implementation- 148 specific. These considerations are therefore out of 149 scope of the SFC specification effort. 151 SF_REQ#3: The solution MUST NOT require any IANA registry for 152 Service Functions. 154 SF_REQ#4: The solution MUST allow multiple instances of a given 155 Service Function ( i.e., instances of a Service Function 156 can be embedded in or attached to multiple Network 157 Elements). 159 A. This is used for load-balancing, load-sharing, to 160 minimize the impact of failures (e.g., by means of a 161 hot or cold standby protection design), to accommodate 162 planned maintenance operations, etc. 164 B. How these multiple devices are involved in the service 165 delivery is deployment-specific. 167 SF_REQ#5: The solution MUST separate SF-specific policy 168 provisioning-related aspects from the actual handling of 169 packets (including forwarding decisions). 171 3.2. Chaining Service Functions 173 SFC_REQ#1: The solution MUST NOT assume any predefined order of 174 Service Functions. In particular, the solution MUST NOT 175 require any IANA registry to store typical Service 176 Function Chains. 178 SFC_REQ#2: The identification of instantiated Service Function 179 Chains is local to each administrative domain; it is 180 policy-based and deployment-specific. 182 SFC_REQ#3: The solution MUST allow for multiple Service Chains to be 183 simultaneously enforced within an administrative domain. 185 SFC_REQ#4: The solution MUST allow the same Service Function to 186 belong to multiple Service Function Chains. 188 SFC_REQ#5: The solution MUST support the ability to deploy multiple 189 SFC-enabled domains within the same administrative 190 domain. 192 SFC_REQ#6: The solution MUST be able to associate the same or 193 distinct Service Function Chains for each direction 194 (inbound/outbound) of the traffic pertaining to a 195 specific service. In particular, unidirectional Service 196 Function Chains, bi-directional Service Function Chains, 197 or any combination thereof MUST be supported. 199 Note, the solution must allow to involve distinct SFC 200 Boundary Nodes for upstream and downstream. Multiple 201 SFC Boundary Nodes may be deployed within an 202 administrative domain. 204 SFC_REQ#7: The solution MUST be able to dynamically enforce Service 205 Function Chains. In particular, the solution MUST allow 206 the update or the withdrawal of existing Service Function 207 Chains, the definition of a new Service Function Chain, 208 the addition of new Service Functions without having any 209 impact on other existing Service Functions or other 210 Service Function Chains. 212 SFC_REQ#8: The solution MUST provide means to control the SF- 213 inferred information to be leaked outside an SFC-enabled 214 domain. In particular, an administrative entity MUST be 215 able to prevent the exposure of the Service Function 216 Chaining logic and its related policies outside the 217 administrative domain. 219 SFC_REQ#9: The solution MUST prevent infinite Service Function 220 Loops. 222 A. Service Functions MAY be invoked multiple times in 223 the same Service Function Chain (denoted as SF 224 Spiral), but the solution MUST prevent infinite 225 forwarding loops. 227 3.3. MTU Requirements 229 Packet fragmentation can be very expensive in SFC environment where 230 fragmented packets have to be reassembled before sending to each SF 231 on the chain. It is also worth noting that IPv6 traffic can only be 232 fragmented by the end systems. 234 MTU_REQ#1: The solution SHOULD minimize fragmentation; in 235 particular, a minimal set of SFC-specific information 236 should be conveyed in the data packet. 238 MTU_REQ#2: Traffic forwarding on a SFC basis MUST be undertaken 239 without relying on dedicated resources to treat 240 fragments. In particular, Out of order fragments MUST be 241 forwarded on a per-SFC basis without relying on any 242 state. 244 MTU_REQ#3: Some SFs (e.g., NAT) may require dedicated resources 245 (e.g., resources to store fragmented packets) or they may 246 adopt a specific behavior (e.g, limit the time interval 247 to accept fragments). The solution MUST NOT interfere 248 with such practices. 250 3.4. Independence from the Underlying Transport Infrastructure 251 Requirements 253 UN_REQ#1: The solution MUST NOT make any assumption on how RIBs 254 (Routing Information Bases) and FIBs (Forwarding 255 Information Bases) are populated. Particularly, the 256 solution does not make any assumption on protocols and 257 mechanisms used to build these tables. 259 UN_REQ#2: The solution MUST be transport independent. 261 A. The Service Function Chaining should operate 262 regardless of the network transport used by the 263 administrative entity. In particular, the solution 264 can be used whatever the switching technologies 265 deployed in the underlying transport infrastructure. 267 B. Techniques such as MPLS are neither required nor 268 excluded. 270 UN_REQ#3: The solution MUST allow for chaining logics where involved 271 Service Functions are not within the same layer 3 subnet. 273 UN_REQ#4: The solution MUST NOT exclude Service Functions to be 274 within the same IP subnet (because this is deployment- 275 specific). 277 3.5. Traffic Classification Requirements 279 TC_REQ#1: The solution MUST NOT make any assumption on how the 280 traffic is to be bound to a given chaining policy. In 281 other words, classification rules are deployment-specific 282 and policy-based. For instance, classification can rely 283 on a subset of the information carried in a received 284 packet such as 5-tuple classification, be subscriber- 285 aware, be driven by traffic engineering considerations, or 286 any combination thereof. 288 Because a large number (e.g., 1000s) of classification 289 policy entries may be configured, means .Means to 290 reduce classification look-up time such as optimizing 291 the size of the classification table (e.g., 292 aggregation) should be supported by the Classifier. 294 TC_REQ#2: The solution MUST NOT require every Service Function to be 295 co-located with a SFC Classifier; this is a deployment- 296 specific decision. 298 TC_REQ#3: The solution MAY allow traffic re-classification at the 299 level of Service Functions (i.e., a Service Function can 300 also be co-located with a Classifier). The configuration 301 of classification rules in such context are the 302 responsibility of the administrative entity that operates 303 the SFC-enabled domain. 305 TC_REQ#4: The solution MUST allow Service Function Nodes to be 306 configured (or pushed) with the detailed policies on which 307 local Service Functions to invoke for packets associated 308 with some Service Function Chains. The solution MUST 309 allow those steering policies to be updated based on 310 demand. 312 3.6. Data Plane Requirements 314 DP_REQ#1: The solution MUST be able to forward traffic between two 315 Service Functions (involved in the same Service Function 316 Chain) without relying upon the destination address field 317 of the a data packet. 319 DP_REQ#2: The solution MUST allow for the association of a context 320 with the data packets. In particular: 322 A. The solution MUST support the ability to invoke 323 differentiated sets of policies for a Service Function 324 (such sets of policies are called Profiles). A 325 profile denotes a set of policies configured to a 326 local Service Function (e.g., content-filter-child, 327 content-filter-adult). 329 a. Few profiles should be assumed per Service 330 Function to accommodate the need for scalable 331 solutions. 333 b. A finer granularity of profiles may be configured 334 directly to each Service Function; there is indeed 335 no need to overload the design of Service Function 336 Chains with policies of low-level granularity. 338 DP_REQ#3: Service Functions may be reachable using IPv4 and/or IPv6. 339 The administrative domain entity MUST be able to define 340 and enforce policies with regards to the address family to 341 be used when invoking a Service Function. 343 A. A Service Function Chain may be composed of IPv4 344 addresses, IPv6 addresses, or a mix of both IPv4 and 345 IPv6 addresses. 347 B. Multiple Service Functions can be reachable using the 348 same IP address. Each of these Service Functions is 349 unambiguously identified with a Service Function 350 Identifier. 352 DP_REQ#4: 354 3.7. OAM Requirements 356 OAM_REQ#1: The solution MUST allow for Operations, Administration, 357 and Maintenance (OAM) features [RFC6291]. In particular, 358 the solution MUST: 360 A. Support means to verify the completion of the 361 forwarding actions until the SFC Border Node is 362 reached (see Section 3.4.1 of [RFC5706]). 364 B. Support means to ensure coherent classification rules 365 are installed in and enforced by all the Classifiers 366 of the SFC domain. 368 C. Support means to correlate classification policies 369 with observed forwarding actions. 371 D. Support in-band liveliness and functionality checking 372 mechanisms for the instantiated Service Function 373 Chains and the Service Functions that belong to these 374 chains. 376 OAM_REQ#2: The solution MUST support means to detect the liveliness 377 of Service Functions of an SFC-enabled domain. In 378 particular, the solution MUST support means to 379 (dynamically) detect that a Service Function instance is 380 out of service and notify the relevant elements 381 accordingly (PDP and Classifiers, for one). 383 OAM_REQ#3: Detailed diagnosis requirements are listed below: 385 A. The solution MUST allow to assess the status of the 386 serviceability of a Service Function (i.e., the 387 Service Function provides the service(s) it is 388 configured for). 390 B. The solution MUST NOT rely only on IP reachability to 391 assess whether a Service Function is up and running. 393 C. The solution MUST allow to diagnose the availability 394 of a Service Function Chain (including the 395 availability of a particular Service Function Path 396 bound to a given Service Function Chain). 398 D. The solution MUST allow to retrieve the set of 399 Service Function Chains that are enabled within a 400 domain. 402 E. The solution MUST allow to retrieve the set of s 403 Service Function Chains in which a given Service 404 Function is involved. 406 F. The solution MUST allow to assess whether an SFC- 407 enabled domain is appropriately configured (including 408 the configured chains are matching what should be 409 configured in that domain). 411 G. The solution MUST allow to assess the output of the 412 classification rule applied on a packet presented to 413 a Classifier of an SFC-enabled domain. 415 H. The solution MUST support the correlation between a 416 Service Function Chain and the actual forwarding path 417 followed by a packet matching that SFC. 419 I. The solution MUST allow to diagnose the availability 420 of a segment of a Service Function Chain, i.e., a 421 subset of Service Functions that belong to the said 422 chain. 424 J. The solution MUST support means to notify the PDPs 425 whenever some events occur (for example, a 426 malfunctioning Service Function instance). 428 K. The solution MUST allow for local diagnostic 429 procedures specific to each Service Function (i.e., 430 SF built-in diagnostic procedures). 432 L. The solution MUST allow for customized service 433 diagnostic. 435 OAM_REQ#4: Liveness status records for all Service Functions 436 (including Service Function instances), Service Function 437 Nodes, Service Function Chains (including the Service 438 Function Paths bound to a given chain) MUST be 439 maintained. 441 OAM_REQ#5: SFC-specific counters and statistics MUST be provided. 442 These data include (but not limited to): 444 * Number of flows ever and currently assigned to a given 445 Service Function Chain and a given Service Function 446 Path. 448 * Number of flows, packets, bytes dropped due to policy. 450 * Number of packets and bytes in/out per Service 451 Function Chain and per Service Function Path. 453 * Number of flows, packets, bytes dropped due to unknown 454 Service Function Chain or Service Function Path (this 455 is valid in particular for a Service Function Node). 457 3.8. Recovery and Load Balancing Requirements 459 LB_REQ#1: The solution MUST allow for load-balancing among multiple 460 instances of the same Service Function. 462 A. Load-balancing may be provided by legacy technologies 463 or protocols (e.g., make use of load-balancers) 465 B. Load-balancing may be part of the Service Function 466 itself. 468 C. Load-balancer may be considered as a Service Function 469 element. 471 D. Because of the possible complications, load balancing 472 SHOULD NOT be driven by the SFC Classifier. 474 LB_REQ#2: The solution MUST separate SF-specific policy 475 provisioning-related aspects from the actual handling of 476 packets (including forwarding decisions). 478 LB_REQ#3: The solution SHOULD support protection of the failed or 479 over-utilized Service Function instances. The protection 480 mechanism can rely on local decisions among the nodes that 481 are connected to both active/standby Service Function 482 instances. 484 3.9. Compatibility with Legacy Service Functions Requirements 486 LEG_REQ#1: The solution MUST allow for gradual deployment in legacy 487 infrastructures, and therefore coexist with legacy 488 technologies that cannot support SFC-specific 489 capabilities, such as Service Function Chain 490 interpretation and processing. The solution MUST be able 491 to work in a domain that may be partly composed of opaque 492 elements, i.e., elements that do not support SFC-specific 493 capabilities. 495 3.10. QoS Requirements 497 QoS_REQ#1: The solution MUST be able to provide different SLAs 498 (Service Level Agreements, [RFC7297]). In particular, 500 A. The solution MUST allow for different levels of 501 service to be provided for different traffic streams 502 (e.g., configure Classes of Service (CoSes)). 504 B. The solution MUST be able to work properly within a 505 Diffserv domain [RFC2475]. 507 C. The solution SHOULD support the two modes defined in 508 [RFC2983]. 510 QoS_REQ#2: ECN re-marking, when required, MUST be performed 511 according to [RFC6040]. 513 3.11. Security Requirements 515 SEC_REQ#1: The solution MUST provide means to prevent any 516 information leaking that would be used as a hint to guess 517 internal engineering practices (e.g., network topology, 518 service infrastructure topology, hints on the enabled 519 mechanisms to protect internal service infrastructures, 520 etc.). 522 The solution MUST support means to protect the SFC 523 domain as a whole against attacks that would lead to 524 the discovery of Service Functions enabled in a SFC 525 domain. 526 In particular, topology hiding means MUST be supported 527 to avoid the exposure of the SFC-enabled domain 528 topology (including the set of the service function 529 chains supported within the domain and the 530 corresponding Service Functions that belong to these 531 chains). 532 SEC_REQ#2: The solution MUST support means to protect the SFC- 533 enabled domain against any kind of denial-of-service and 534 theft of service (e.g., illegitimate access to the 535 service) attack. 537 For example, a user should not be granted access to 538 connectivity services he/she didn't subscribe to 539 (including direct access to some SFs), at the risk of 540 providing illegitimate access to network resources. 541 SEC_REQ#3: The solution MUST NOT interfere with IPsec [RFC4301] (in 542 particular IPsec integrity checks). 544 4. IANA Considerations 546 This document does not require any action from IANA. 548 5. Security Considerations 550 Some security-related requirements to be taken into account when 551 designing the Service Function Chaining solution are listed in 552 Section 3.11. These requirements do not cover the provisioning 553 interface used to enforce policies into the Classifier, Service 554 Functions, and Service Function Nodes. 556 6. Contributors 558 The following individuals contributed text to the document: 560 Hongyu Li 561 Huawei Technologies Co., Ltd. 562 Bantian, Longgang district 563 Shenzhen 518129, 564 China 566 EMail: hongyu.lihongyu@huawei.com 568 Jim Guichard 569 Cisco Systems, Inc. 570 USA 572 EMail: jguichar@cisco.com 574 Paul Quinn 575 Cisco Systems, Inc. 576 USA 578 Email: paulq@cisco.com 580 Linda Dunbar 581 Huawei Technologies 582 5430 Legacy Drive, Suite #175 583 Plano TX 584 USA 586 EMail: linda.dunbar@huawei.com 588 7. Acknowledgements 590 Many thanks to K. Gray, N. Takaya, H. Kitada, H. Kojima, D. 591 Dolson, B. Wright, and J. Halpern for their comments. 593 8. References 595 8.1. Normative References 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, March 1997. 600 8.2. Informative References 602 [I-D.ietf-sfc-problem-statement] 603 Quinn, P. and T. Nadeau, "Service Function Chaining 604 Problem Statement", draft-ietf-sfc-problem-statement-11 605 (work in progress), February 2015. 607 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 608 and W. Weiss, "An Architecture for Differentiated 609 Services", RFC 2475, December 1998. 611 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 612 2983, October 2000. 614 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 615 Internet Protocol", RFC 4301, December 2005. 617 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 618 Management of New Protocols and Protocol Extensions", RFC 619 5706, November 2009. 621 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 622 Notification", RFC 6040, November 2010. 624 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 625 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 626 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 628 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 629 Connectivity Provisioning Profile (CPP)", July 2014. 631 Authors' Addresses 633 Mohamed Boucadair 634 France Telecom 635 Rennes 35000 636 France 638 EMail: mohamed.boucadair@orange.com 640 Christian Jacquenet 641 France Telecom 642 Rennes 35000 643 France 645 EMail: christian.jacquenet@orange.com 646 Yuanlong Jiang 647 Huawei Technologies Co., Ltd. 648 Bantian, Longgang district 649 Shenzhen 518129, 650 China 652 EMail: jiangyuanlong@huawei.com 654 Ron Parker 655 Affirmed Networks 656 Acton, MA 657 USA 659 EMail: Ron_Parker@affirmednetworks.com 661 Kengo Naito 662 NTT 663 Midori-Cho 3-9-11 664 Musashino-shi, Tokyo 180-8585 665 Japan 667 EMail: naito.kengo@lab.ntt.co.jp