idnits 2.17.1 draft-boucadair-sfc-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 03, 2013) is 3829 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 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: April 06, 2014 Y. Jiang 6 Huawei Technologies Co., Ltd. 7 R. Parker 8 Affirmed Networks 9 C. Pignataro 10 Cisco Systems, Inc. 11 October 03, 2013 13 Requirements for Service Function Chaining 14 draft-boucadair-sfc-requirements-00 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 April 06, 2014. 44 Copyright Notice 46 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . 2 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 8.2. Informative References . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 This document identifies the requirements for the Service Function 75 Chaining (SFC). 77 The overall problem space is described in 78 [I-D.quinn-nsc-problem-statement]. The Service Function Chaining 79 Framework is documented in 80 [I-D.boucadair-service-chaining-framework]. 82 2. Terminology 84 The reader should be familiar with the terms defined in 85 [I-D.boucadair-service-chaining-framework] and 86 [I-D.quinn-nsc-problem-statement]. 88 3. Detailed Requirements List 90 The following set of functional requirements should be considered for 91 the design of the Service Function Chaining solution: 93 REQ#1: The solution MUST NOT make any assumption on whether Service 94 Functions (SF) are deployed directly on physical hardware, 95 as one or more Virtual Machines, or any combination thereof. 97 REQ#2: The solution MUST NOT make any assumption on whether Service 98 Functions each reside on a separate addressable Network 99 Element, horizontal scaling of Service Functions, are co- 100 resident on a single addressable Network Element, or any 101 combination thereof. 103 Note: Communications between Service Functions co- 104 resident on same Network Element are considered 105 implementation-specific. These considerations are out of 106 scope of the SFC specification effort. 108 REQ#3: The solution MUST NOT require any IANA registry for Service 109 Functions. 111 REQ#4: The solution MUST NOT assume predefined order of Service 112 Functions. In particular, the solution MUST NOT require any 113 IANA registry to store typical Service Function Chains. 115 REQ#5: The identification of instantiated Service Function Chains 116 is local to each administrative domain; it is policy-based 117 and deployment-specific. 119 REQ#6: The solution MUST allow multiple instances of a given 120 Service Function ( i.e., a Service Function can be embedded 121 in multiple Network Elements). 123 a. This is used for load-balancing, load-sharing, prevent 124 from failures (e.g., hot or cold standby protection 125 mechanism), accommodate planned maintenance operations, 126 etc. 128 b. How these multiple devices are involved in the service 129 delivery is deployment-specific. 131 REQ#7: The solution MUST allow for multiple Service Chains to be 132 simultaneously enforced within an administrative domain. 134 REQ#8: The solution MUST allow the same Service Function to be 135 involved in multiple Service Function Chains. 137 REQ#9: The solution MUST support multiple SFC-enabled domains be 138 deployed within the same administrative domain. 140 REQ#10: The solution MUST be able to associate the same or distinct 141 Service Function Chains for each direction (inbound/ 142 outbound) of the traffic. In particular, unidirectional 143 Service Function Chains, bi-directional Service Function 144 Chains, or any combination thereof MUST be supported. 146 REQ#11: The solution MUST be able to dynamically enforce Service 147 Function Chains. In particular, the solution MUST allow the 148 update or the withdrawal of existing Service Function 149 Chains, the definition of a new Service Function Chain, the 150 addition of new Service Functions without having any impact 151 on other existing Service Functions or other Service 152 Function Chains. 154 REQ#12: The solution MUST provide means to control the SF-inferred 155 information to be leaked outside an SFC-enabled domain. In 156 particular, an administrative entity MUST be able to prevent 157 Service Function Chaining logic and related policies from 158 being exposed outside its administrative domain. 160 REQ#13: The solution SHOULD minimize fragmentation; in particular a 161 minimal set of SFC-specific information should be conveyed 162 in the data packet. 164 a. The per-SF Map forwarding MUST be undertaken without 165 relying on dedicated resources to treat fragments. In 166 particular, Out of order fragments MUST be forwarded on 167 a per-SF Map basis without relying on any state. 169 b. Of course, some SFs (e.g., NAT) may require dedicated 170 resources (e.g., resources to store fragmented packets) 171 or specific behavior (e.g, limit the time interval to 172 accept fragments). The solution MUST NOT interfere with 173 such practices. 175 REQ#14: The solution MUST NOT make any assumption on how RIBs 176 (Routing Information Bases) and FIBs (Forwarding Information 177 Bases) are populated. Particularly, the solution does not 178 make any assumption on protocols and mechanisms used to 179 build these tables. 181 REQ#15: The solution MUST be transport independent. 183 a. The Service Function Chaining should operate regardless 184 of the network transport used by the administrative 185 entity. In particular, the solution can be used 186 whatever the switching technologies deployed in the 187 underlying transport infrastructure. 189 b. Techniques such as MPLS are neither required nor 190 excluded. 192 REQ#16: The solution MUST allow for chaining logics where involved 193 Service Functions are not within the same layer 3 subnet. 195 REQ#17: The solution MUST NOT exclude Service Functions to be within 196 the same IP subnet (this is deployment-specific). 198 REQ#18: An administrative entity, grouping its Service Functions 199 within the same IP subnet, SHOULD be able to avoid 200 encapsulation overhead . 202 REQ#19: The solution MUST NOT make any assumption on how the traffic 203 is to be bound to a given chaining policy. In other words, 204 classification rules are deployment-specific and policy- 205 based. For instance, classification can rely on a subset of 206 the information carried in a received packet such as 5-tuple 207 classification. 209 REQ#20: The solution MUST support classifying traffic into Service 210 Function Chains. 212 REQ#21: The solution MUST NOT require every Service Function be co- 213 located with a SFC Classifier; this is a deployment-specific 214 decision. 216 REQ#22: The solution MAY allow reclassification at the Service 217 Functions (i.e., a Service Function can also be co-located 218 with a classifier). The configuration of classification 219 rules in such context are the responsibility of the 220 administrative entity managing that SFC-enabled domain. 222 REQ#23: The solution MUST be able to forward the traffic between two 223 Service Functions (involved in the same Service Function 224 Chain) without relying on the original destination address 225 in a data packet. 227 REQ#24: The solution MUST allow for the association of a context 228 with the data packets. In particular: 230 a. The solution MUST support the ability to invoke 231 differentiated sets of policies for a Service Function 232 (called Profiles). A profile denotes a set of policies 233 configured to a local Service Function (e.g., content- 234 filter-child, content-filter-adult). 236 a. Few profiles should be assumed per Service Function 237 to accommodate the need for scalable solutions. 239 b. Finer-grained of policies should be configured 240 directly to each Service Function; no need to 241 overload the design of Service Function Chains with 242 policies of low-level granularity. 244 REQ#25: The solution MUST allow for Operations, Administration, and 245 Maintenance (OAM) features [RFC6291]. In particular, 247 a. Support means to verify the completion of the forwarding 248 actions derived from the contents of the SF Map until 249 the Border Node is reached (see Section 3.4.1 of 250 [RFC5706]). 252 b. Support means to ensure coherent classification rules 253 are installed to all SFC Classifiers. 255 c. Support means to correlate between the classification 256 policies and observed forwarding actions. 258 d. Support in-band liveness and functionality checking of 259 instantiated Service Function Chains. 261 REQ#26: The solution MUST prevent the same Service Function to be 262 invoked multiple times in the context of the same Service 263 Function Chain (at the risk of generating Service Function 264 Loop). 266 REQ#27: The solution MUST allow for load-balancing. 268 a. Load-balancing may be provided by legacy technologies or 269 protocols (e.g., make use of load-balancers) 271 b. Load-balancing may be part of the Service Function 272 itself. 274 c. Load-balancer may be considered as a Service Function 275 element. 277 d. Because of the possible complications, load balancing 278 SHOULD NOT be driven by the SFC Classifier. 280 REQ#28: The solution MUST separate provisioning-related aspects from 281 the actual handling of packets (including forwarding 282 decisions). 284 REQ#29: The solution SHOULD means to detect the liveness of involved 285 Service Functions. 287 REQ#30: Means to dynamically discover Service Functions SHOULD be 288 supported. 290 REQ#31: Service Functions may be reachable using IPv4 and/or IPv6. 291 The administrative domain entity MUST be able to define and 292 enforce policies with regards to the address family to be 293 used when invoking a Service Function. 295 a. A SF Map may be composed of IPv4 addresses, IPv6 296 addresses, or a mix of both IPv4 and IPv6 addresses. 298 b. Multiple Service Functions can be reachable using the 299 same IP address. Each of these Service Functions is 300 unambiguously identified with a Service Function 301 Identifier. 303 REQ#32: The solution MUST allow for gradual deployment in legacy 304 infrastructures, and therefore coexist with legacy 305 technologies that cannot support SFC-specific capabilities, 306 such as SFC Map interpretation and processing. The solution 307 MUST be able to work in a domain that may be partly composed 308 of opaque elements, i.e., elements that do not support SFC- 309 specific capabilities. 311 REQ#33: The solution MUST be able to provide different SLAs (Service 312 Level Agreements, 313 [I-D.boucadair-connectivity-provisioning-profile]). In 314 particular, 316 a. The solution MUST allow for different levels of service 317 to be provided for traffic streams (e.g., configure 318 Classes of Service (CoSes)). 320 b. The solution MUST be compatible with Diffserv [RFC2475]. 322 c. The solution SHOULD support the two modes defined in 323 [RFC2983]. 325 REQ#34: ECN re-marking, when required, MUST be performed according 326 to [RFC6040]. 328 4. IANA Considerations 330 Authors of this document do not require any action from IANA. 332 5. Security Considerations 334 Below are listed some security-related requirements to be taken into 335 account when designing the Service Function Chaining solution: 337 SEC_REQ#1: The solution MUST provide means to prevent leaking any 338 information that would be used as a hint to guess 339 internal engineering practices (e.g., network topology, 340 service infrastructure topology, hints on the enabled 341 mechanisms to protect internal service infrastructures, 342 etc.). 344 In particular, topology hiding means MUST supported to 345 avoid exposing the topology of an SFC-enabled domain 346 (including the set of involved Service Functions). 348 SEC_REQ#2: The solution MUST support means to defend against denial- 349 of-service and theft of service (e.g., illegitimate 350 access to the service). 352 For example, a user should not be granted access to 353 connectivity services it didn't subscribed to such as 354 illegitimate access to network resources. 356 SEC_REQ#3: The solution MUST NOT interfere with IPsec [RFC4301] (in 357 particular IPsec integrity checks). 359 6. Contributors 361 The following individuals contributed text to the document: 363 Hongyu Li 364 Huawei Technologies Co., Ltd. 365 Bantian, Longgang district 366 Shenzhen 518129, 367 China 369 EMail: hongyu.lihongyu@huawei.com 371 Jim Guichard 372 Cisco Systems, Inc. 373 USA 375 EMail: jguichar@cisco.com 377 Paul Quinn 378 Cisco Systems, Inc. 379 USA 380 Email: paulq@cisco.com 382 7. Acknowledgements 384 Many thanks to K. Gray for his review. 386 8. References 388 8.1. Normative References 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, March 1997. 393 8.2. Informative References 395 [I-D.boucadair-connectivity-provisioning-profile] 396 Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS 397 Connectivity Provisioning Profile", draft-boucadair- 398 connectivity-provisioning-profile-02 (work in progress), 399 September 2012. 401 [I-D.boucadair-service-chaining-framework] 402 Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., 403 Guichard, J., and C. Pignataro, "Differentiated Service 404 Function Chaining Framework", draft-boucadair-service- 405 chaining-framework-00 (work in progress), August 2013. 407 [I-D.quinn-nsc-problem-statement] 408 Quinn, P., Guichard, J., Surendra, S., Agarwal, P., Manur, 409 R., Chauhan, A., Leymann, N., Boucadair, M., Jacquenet, 410 C., Smith, M., Yadav, N., Nadeau, T., Gray, K., McConnell, 411 B., and K. Kevin, "Network Service Chaining Problem 412 Statement", draft-quinn-nsc-problem-statement-03 (work in 413 progress), August 2013. 415 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 416 and W. Weiss, "An Architecture for Differentiated 417 Services", RFC 2475, December 1998. 419 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 420 2983, October 2000. 422 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 423 Internet Protocol", RFC 4301, December 2005. 425 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 426 Management of New Protocols and Protocol Extensions", RFC 427 5706, November 2009. 429 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 430 Notification", RFC 6040, November 2010. 432 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 433 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 434 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 436 Authors' Addresses 438 Mohamed Boucadair 439 France Telecom 440 Rennes 35000 441 France 443 EMail: mohamed.boucadair@orange.com 445 Christian Jacquenet 446 France Telecom 447 Rennes 35000 448 France 450 EMail: christian.jacquenet@orange.com 452 Yuanlong Jiang 453 Huawei Technologies Co., Ltd. 454 Bantian, Longgang district 455 Shenzhen 518129, 456 China 458 EMail: jiangyuanlong@huawei.com 460 Ron Parker 461 Affirmed Networks 462 Acton, MA 463 USA 465 EMail: Ron_Parker@affirmednetworks.com 466 Carlos Pignataro 467 Cisco Systems, Inc. 468 USA 470 EMail: cpignata@cisco.com