idnits 2.17.1 draft-boucadair-sfc-requirements-03.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 12, 2014) is 3725 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-boucadair-connectivity-provisioning-profile-02 == Outdated reference: A later version (-02) exists of draft-boucadair-sfc-framework-00 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-00 Summary: 0 errors (**), 0 flaws (~~), 4 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 16, 2014 Y. Jiang 6 Huawei Technologies Co., Ltd. 7 R. Parker 8 Affirmed Networks 9 C. Pignataro 10 Cisco Systems, Inc. 11 K. Naito 12 NTT 13 February 12, 2014 15 Requirements for Service Function Chaining 16 draft-boucadair-sfc-requirements-03 18 Abstract 20 This document identifies the requirements for the Service Function 21 Chaining (SFC). 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 16, 2014. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Detailed Requirements List . . . . . . . . . . . . . . . . . 3 66 4. Service Function Discovery . . . . . . . . . . . . . . . . . 8 67 5. SFC Diagnosis & Troubleshooting . . . . . . . . . . . . . . . 9 68 6. Scalability Considerations . . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 11.2. Informative References . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 This document identifies the requirements for the Service Function 80 Chaining (SFC). In particular: 82 1. Generic requirements are listed in Section 3. 84 2. Service Function Discovery requirements are discussed in 85 Section 4. 87 3. SFC diagnostic requirements are discussed in Section 5. 89 4. Security-specific requirements are listed in Section 8. 91 The overall problem space is described in 92 [I-D.ietf-sfc-problem-statement]. 94 2. Terminology 96 The reader should be familiar with the terms defined in 97 [I-D.boucadair-sfc-framework] and [I-D.ietf-sfc-problem-statement]. 99 3. Detailed Requirements List 101 The following set of functional requirements should be considered for 102 the design of the Service Function Chaining solution: 104 REQ#1: The solution MUST NOT make any assumption on whether Service 105 Functions (SF) are deployed directly on physical hardware, 106 as one or more Virtual Machines, or any combination thereof. 108 REQ#2: The solution MUST NOT make any assumption on whether Service 109 Functions each reside on a separate addressable Network 110 Element, or as a horizontal scaling of Service Functions, or 111 are co-resident in a single addressable Network Element, or 112 any combination thereof. 114 Note: Communications between co-located Service Functions 115 are considered implementation-specific. These 116 considerations are therefore out of scope of the SFC 117 specification effort. 119 REQ#3: The solution MUST NOT require any IANA registry for Service 120 Functions. 122 REQ#4: The solution MUST NOT assume any predefined order of Service 123 Functions. In particular, the solution MUST NOT require any 124 IANA registry to store typical Service Function Chains. 126 REQ#5: The identification of instantiated Service Function Chains 127 is local to each administrative domain; it is policy-based 128 and deployment-specific. 130 REQ#6: The solution MUST allow multiple instances of a given 131 Service Function ( i.e., a Service Function can be embedded 132 in multiple Network Elements). 134 A. This is used for load-balancing, load-sharing, to 135 minimize the impact of failures (e.g., by means of a hot 136 or cold standby protection design), to accommodate 137 planned maintenance operations, etc. 139 B. How these multiple devices are involved in the service 140 delivery is deployment-specific. 142 REQ#7: The solution MUST allow for multiple Service Chains to be 143 simultaneously enforced within an administrative domain. 145 REQ#8: The solution MUST allow the same Service Function to belong 146 to multiple Service Function Chains. 148 REQ#9: The solution MUST support the ability to deploy multiple 149 SFC-enabled domains within the same administrative domain. 151 REQ#10: The solution MUST be able to associate the same or distinct 152 Service Function Chains for each direction (inbound/ 153 outbound) of the traffic pertaining to a specific service. 154 In particular, unidirectional Service Function Chains, bi- 155 directional Service Function Chains, or any combination 156 thereof MUST be supported. 158 Note, the solution must allow to involve distinct SFC 159 Boundary Nodes for upstream and downstream. Multiple SFC 160 Boundary Nodes may be deployed within an administrative 161 domain. 163 REQ#11: The solution MUST be able to dynamically enforce Service 164 Function Chains. In particular, the solution MUST allow the 165 update or the withdrawal of existing Service Function 166 Chains, the definition of a new Service Function Chain, the 167 addition of new Service Functions without having any impact 168 on other existing Service Functions or other Service 169 Function Chains. 171 REQ#12: The solution MUST provide means to control the SF-inferred 172 information to be leaked outside an SFC-enabled domain. In 173 particular, an administrative entity MUST be able to prevent 174 the exposure of the Service Function Chaining logic and its 175 related policies outside the administrative domain. 177 REQ#13: The solution SHOULD minimize fragmentation; in particular, a 178 minimal set of SFC-specific information should be conveyed 179 in the data packet. 181 A. Traffic forwarding on a SFC basis MUST be undertaken 182 without relying on dedicated resources to treat 183 fragments. In particular, Out of order fragments MUST 184 be forwarded on a per-SFC basis without relying on any 185 state. 187 B. Of course, some SFs (e.g., NAT) may require dedicated 188 resources (e.g., resources to store fragmented packets) 189 or they may adopt a specific behavior (e.g, limit the 190 time interval to accept fragments). The solution MUST 191 NOT interfere with such practices. 193 REQ#14: The solution MUST NOT make any assumption on how RIBs 194 (Routing Information Bases) and FIBs (Forwarding Information 195 Bases) are populated. Particularly, the solution does not 196 make any assumption on protocols and mechanisms used to 197 build these tables. 199 REQ#15: The solution MUST be transport independent. 201 A. The Service Function Chaining should operate regardless 202 of the network transport used by the administrative 203 entity. In particular, the solution can be used 204 whatever the switching technologies deployed in the 205 underlying transport infrastructure. 207 B. Techniques such as MPLS are neither required nor 208 excluded. 210 REQ#16: The solution MUST allow for chaining logics where involved 211 Service Functions are not within the same layer 3 subnet. 213 REQ#17: The solution MUST NOT exclude Service Functions to be within 214 the same IP subnet (because this is deployment-specific). 216 REQ#18: The solution MUST NOT make any assumption on how the traffic 217 is to be bound to a given chaining policy. In other words, 218 classification rules are deployment-specific and policy- 219 based. For instance, classification can rely on a subset of 220 the information carried in a received packet such as 5-tuple 221 classification. 223 REQ#19: The solution MUST support traffic classification 224 capabilities according to the Service Function Chains 225 supported within the SFC domain. 227 REQ#20: The solution MUST NOT require every Service Function to be 228 co-located with a SFC Classifier; this is a deployment- 229 specific decision. 231 REQ#21: The solution MAY allow traffic re-classification at the 232 level of Service Functions (i.e., a Service Function can 233 also be co-located with a classifier). The configuration of 234 classification rules in such context are the responsibility 235 of the administrative entity that operates the SFC-enabled 236 domain. 238 REQ#22: The solution MUST be able to forward traffic between two 239 Service Functions (involved in the same Service Function 240 Chain) without relying upon the destination address field of 241 the a data packet. 243 REQ#23: The solution MUST allow for the association of a context 244 with the data packets. In particular: 246 A. The solution MUST support the ability to invoke 247 differentiated sets of policies for a Service Function 248 (such sets of policies are called Profiles). A profile 249 denotes a set of policies configured to a local Service 250 Function (e.g., content-filter-child, content-filter- 251 adult). 253 a. Few profiles should be assumed per Service Function 254 to accommodate the need for scalable solutions. 256 b. A finer granularity of profiles may be configured 257 directly to each Service Function; there is indeed 258 no need to overload the design of Service Function 259 Chains with policies of low-level granularity. 261 REQ#24: The solution MUST allow for Operations, Administration, and 262 Maintenance (OAM) features [RFC6291]. In particular, the 263 solution MUST: 265 A. Support means to verify the completion of the forwarding 266 actions until the SFC Border Node is reached (see 267 Section 3.4.1 of [RFC5706]). 269 B. Support means to ensure coherent classification rules 270 are installed in and enforced by all the Classifiers of 271 the SFC domain. 273 C. Support means to correlate classification policies with 274 observed forwarding actions. 276 D. Support in-band liveliness and functionality checking 277 mechanisms for the instantiated Service Function Chains 278 and the Service Functions that belong to these chains. 280 REQ#25: The solution MUST prevent the same Service Function to be 281 invoked multiple times within the context of the same 282 Service Function Chain (at the risk of generating Service 283 Function Loop). 285 REQ#26: The solution MUST allow for load-balancing. 287 A. Load-balancing may be provided by legacy technologies or 288 protocols (e.g., make use of load-balancers) 290 B. Load-balancing may be part of the Service Function 291 itself. 293 C. Load-balancer may be considered as a Service Function 294 element. 296 D. Because of the possible complications, load balancing 297 SHOULD NOT be driven by the SFC Classifier. 299 REQ#27: The solution MUST separate SF-specific policy provisioning- 300 related aspects from the actual handling of packets 301 (including forwarding decisions). 303 REQ#28: The solution SHOULD support means to detect the liveliness 304 of involved Service Functions. 306 REQ#29: Means to dynamically discover Service Functions SHOULD be 307 supported. 309 REQ#30: Service Functions may be reachable using IPv4 and/or IPv6. 310 The administrative domain entity MUST be able to define and 311 enforce policies with regards to the address family to be 312 used when invoking a Service Function. 314 A. A SF Map may be composed of IPv4 addresses, IPv6 315 addresses, or a mix of both IPv4 and IPv6 addresses. 317 B. Multiple Service Functions can be reachable using the 318 same IP address. Each of these Service Functions is 319 unambiguously identified with a Service Function 320 Identifier. 322 REQ#31: The solution MUST allow for gradual deployment in legacy 323 infrastructures, and therefore coexist with legacy 324 technologies that cannot support SFC-specific capabilities, 325 such as SFC Map interpretation and processing. The solution 326 MUST be able to work in a domain that may be partly composed 327 of opaque elements, i.e., elements that do not support SFC- 328 specific capabilities. 330 REQ#32: The solution MUST be able to provide different SLAs (Service 331 Level Agreements, 332 [I-D.boucadair-connectivity-provisioning-profile]). In 333 particular, 334 A. The solution MUST allow for different levels of service 335 to be provided for different traffic streams (e.g., 336 configure Classes of Service (CoSes)). 338 B. The solution MUST be able to work properly within a 339 Diffserv domain [RFC2475]. 341 C. The solution SHOULD support the two modes defined in 342 [RFC2983]. 344 REQ#33: ECN re-marking, when required, MUST be performed according 345 to [RFC6040]. 347 4. Service Function Discovery 349 This section lists the set of requirements for the Service Function 350 Discovery procedure (denoted hereafter as "the solution"). 352 DISC_REQ#1: The solution MUST use the Service Function Identifier as 353 a unique identifier that unambiguously distinguishes a 354 Service Function among the set of Service Functions 355 enabled in a given SFC domain. 357 DISC_REQ#2: The solution MUST NOT make any assumption on how a 358 Service Function Identifier is configured and associated 359 to a given Service Function. 361 DISC_REQ#3: The solution MUST allow for the dynamic discovery of all 362 locations where a given Service Function may reside and 363 be invoked for a given SF chain. Particularly, the 364 solution MUST allow for the dynamic discovery of both 365 IPv4 and IPv6 locators of a Service Function instance. 367 DISC_REQ#4: The solution SHOULD allow the dynamic discovery of 368 additional information characterizing a Service 369 Function, including: 371 * The capabilities of the Service Function. 373 * The capacity of the Service Function. For example, 374 this information can refer to the maximum number of 375 binding entries that can be supported by a NAT 376 function, the maximum number of IP-in-IP tunnels that 377 can be established, the maximum link capacity, etc. 379 * The current load of the Service Function. This 380 information may be used for load-balancing purposes 381 for instance. This parameter may reflect the amount 382 of active NAT entries, the number of active IP-in-IP 383 tunnel, the link capacity usage, etc. 385 DISC_REQ#5: The solution MUST support means to protect the SFC 386 domain as a whole against attacks that would lead to the 387 discovery of an illegitimate Service Function. For 388 example, a Service Function that cannot be invoked for a 389 specific SF chain. 391 DISC_REQ#6: The solution MUST support means to dynamically detect 392 that a Service Function instance is out of service and 393 notify the relevant elements accordingly (PDP and 394 classifiers, for one). 396 DISC_REQ#7: The solution MUST allow a Service Function instance to 397 dynamically announce scheduled periods of unavailability 398 (for maintenance purposes, for example). The support of 399 this capability is useful for instance to migrate 400 traffic to another instance of the same Service Function 401 so as to minimize service disruption. Note also that 402 operational teams proceed to regular reboots of 403 operational devices (for major software upgrades, for 404 example). Dynamically advertising such events to inform 405 the PDP that a Service Function instance will not be 406 available during the reboot of the device, would be 407 useful. Means to indicate whether the Service Function 408 will be available immediately after the reboot or not 409 are RECOMMENDED. Indeed, such information will be used 410 as an input to the decision-making process of the PDP to 411 avoid any subsequent traffic forwarding policy changes 412 at the risk of service disruption. 414 DISC_REQ#8: The solution MAY allow for a Service Function to 415 dynamically discover its PDP. 417 5. SFC Diagnosis & Troubleshooting 419 This section lists the set of requirements for the SFC Diagnosis & 420 Troubleshooting procedure (denoted hereafter as "the solution"). 422 DIAG_REQ#1: The solution MUST allow to assess the status of the 423 serviceability of a Service Function (i.e., the 424 Service Function that provides the service(s) it is 425 configured for). 427 DIAG_REQ#2: The solution MUST NOT rely only on IP reachability to 428 assess whether a Service Function is up and running. 430 DIAG_REQ#3: The solution MUST allow to diagnose the availability of 431 a Service Function Chain. 433 DIAG_REQ#4: The solution MUST support the correlation between a 434 Service Function Chain and the actual forwarding path 435 followed by a packet matching that SFC. 437 DIAG_REQ#5: The solution MUST allow to diagnose the availability of 438 a segment of a Service Function Chain, i.e., a subset 439 of service functions that belong to the said chain. 441 DIAG_REQ#6: The solution MUST be able to analyze the outcomes of 442 the processing of a test packet when presented to a 443 given Service Function for diagnosis purposes. 445 DIAG_REQ#7: The solution MUST support the unsolicited notification 446 of signals as a means to notify the PDPs whenever some 447 events occur (for example, a malfunctioning service 448 function instance). 450 DIAG_REQ#8: The solution MUST allow for local diagnostic procedures 451 specific to each Service Function. 453 DIAG_REQ#9: The solution MUST allow to make use of local diagnostic 454 procedures (e.g., regular checks using built-in 455 diagnostic procedures). 457 DIAG_REQ#10: The solution MUST allow for customized service 458 diagnostic. For example, the solution should be able 459 to generate a test packet as per a customer's request 460 who may have observed some service degradation. 462 6. Scalability Considerations 464 Designing the SFC solution to accommodate per-subscriber SFCs rather 465 than SFCs on a per group of subscribers basis, should be conditioned 466 by the outcomes of assessing the validity of use cases requiring such 467 per-subscriber SFC feature. Note, instantiating per-subscriber SFCs 468 would mean that millions of SFCs would need be to handled within an 469 SFC-enabled domain! 471 7. IANA Considerations 473 Authors of this document do not require any action from IANA. 475 8. Security Considerations 477 Below are listed some security-related requirements to be taken into 478 account when designing the Service Function Chaining solution: 480 SEC_REQ#1: The solution MUST provide means to prevent any 481 information leaking that would be used as a hint to guess 482 internal engineering practices (e.g., network topology, 483 service infrastructure topology, hints on the enabled 484 mechanisms to protect internal service infrastructures, 485 etc.). 487 In particular, topology hiding means MUST be supported 488 to avoid the exposure of the SFC-enabled domain 489 topology (including the set of the service function 490 chains supported within the domain and the 491 corresponding Service Functions that belong to these 492 chains). 494 SEC_REQ#2: The solution MUST support means to protect the SFC- 495 enabled domain against any kind of denial-of-service and 496 theft of service (e.g., illegitimate access to the 497 service) attack. 499 For example, a user should not be granted access to 500 connectivity services he/she didn't subscribe to 501 (including direct access to some SFs), at the risk of 502 providing illegitimate access to network resources. 504 SEC_REQ#3: The solution MUST NOT interfere with IPsec [RFC4301] (in 505 particular IPsec integrity checks). 507 9. Contributors 509 The following individuals contributed text to the document: 511 Hongyu Li 512 Huawei Technologies Co., Ltd. 513 Bantian, Longgang district 514 Shenzhen 518129, 515 China 517 EMail: hongyu.lihongyu@huawei.com 519 Jim Guichard 520 Cisco Systems, Inc. 521 USA 523 EMail: jguichar@cisco.com 525 Paul Quinn 526 Cisco Systems, Inc. 527 USA 529 Email: paulq@cisco.com 531 10. Acknowledgements 533 Many thanks to K. Gray, N. Takaya, H. Kitada, and H. Kojima for their 534 comments. 536 11. References 538 11.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, March 1997. 543 11.2. Informative References 545 [I-D.boucadair-connectivity-provisioning-profile] 546 Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS 547 Connectivity Provisioning Profile", draft-boucadair- 548 connectivity-provisioning-profile-02 (work in progress), 549 September 2012. 551 [I-D.boucadair-sfc-framework] 552 Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., 553 Guichard, J., and C. Pignataro, "Service Function 554 Chaining: Framework & Architecture", draft-boucadair-sfc- 555 framework-00 (work in progress), October 2013. 557 [I-D.ietf-sfc-problem-statement] 558 Quinn, P. and T. Nadeau, "Service Function Chaining 559 Problem Statement", draft-ietf-sfc-problem-statement-00 560 (work in progress), January 2014. 562 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 563 and W. Weiss, "An Architecture for Differentiated 564 Services", RFC 2475, December 1998. 566 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 567 2983, October 2000. 569 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 570 Internet Protocol", RFC 4301, December 2005. 572 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 573 Management of New Protocols and Protocol Extensions", RFC 574 5706, November 2009. 576 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 577 Notification", RFC 6040, November 2010. 579 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 580 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 581 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 583 Authors' Addresses 585 Mohamed Boucadair 586 France Telecom 587 Rennes 35000 588 France 590 EMail: mohamed.boucadair@orange.com 592 Christian Jacquenet 593 France Telecom 594 Rennes 35000 595 France 597 EMail: christian.jacquenet@orange.com 598 Yuanlong Jiang 599 Huawei Technologies Co., Ltd. 600 Bantian, Longgang district 601 Shenzhen 518129, 602 China 604 EMail: jiangyuanlong@huawei.com 606 Ron Parker 607 Affirmed Networks 608 Acton, MA 609 USA 611 EMail: Ron_Parker@affirmednetworks.com 613 Carlos Pignataro 614 Cisco Systems, Inc. 615 USA 617 EMail: cpignata@cisco.com 619 Kengo Naito 620 NTT 621 Midori-Cho 3-9-11 622 Musashino-shi, Tokyo 180-8585 623 Japan 625 EMail: naito.kengo@lab.ntt.co.jp