idnits 2.17.1 draft-beliveau-sfc-architecture-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 (October 16, 2013) is 3842 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6092' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'I-D.boucadair-sfc-framework' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'I-D.boucadair-sfc-requirements' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'I-D.quinn-sfc-problem-statement' is defined on line 375, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Downref: Normative reference to an Informational RFC: RFC 6092 == Outdated reference: A later version (-02) exists of draft-boucadair-sfc-framework-00 == Outdated reference: A later version (-06) exists of draft-boucadair-sfc-requirements-00 == Outdated reference: A later version (-02) exists of draft-quinn-sfc-problem-statement-00 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Beliveau 3 Internet-Draft Ericsson 4 Intended status: Standards Track October 16, 2013 5 Expires: April 19, 2014 7 Service Function Chaining Architecture 8 draft-beliveau-sfc-architecture-00 10 Abstract 12 This document describes an architecture for Service Function 13 Chaining. It addresses operational aspects of Service Function 14 Chaining such administration of Service Function Chains, network and 15 forwarding principles. It also covers architectural principles to 16 support scale-in and scale-out of Service Functions. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 April 19, 2014. 41 Copyright Notice 43 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Architecture principles . . . . . . . . . . . . . . . . . . . 4 61 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Service Function Chain . . . . . . . . . . . . . . . . . . 4 63 3.3. Service Chaining Infrastructure . . . . . . . . . . . . . 5 64 3.4. Service Function scaling . . . . . . . . . . . . . . . . . 7 65 3.5. Service Function Classification . . . . . . . . . . . . . 7 66 3.6. Service Chaining Controller . . . . . . . . . . . . . . . 7 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 This document describes an architecture for Service Function Chaining 78 (SFC). It describes components and architecture principles to 79 provide Service Function Chaining in a network. 81 2. Terminology 83 This document makes use of the following terms: 85 Service Function(SF): An application or service which performs 86 specific treatments when packets traverses it. A non-exhaustive 87 list of Service Functions include: firewall (e.g.,[RFC6092]), DPI 88 (Deep Packet Inspection), NAT44 [RFC3022], NAT64 [RFC6146], 89 HOST_ID injection, HTTP Header Enrichment function, load-balancer, 90 etc. The exact definition of each Service Function is specifc to 91 each Service Function provider. 93 Service Function Identity(SF-ID): A unique identifier which 94 represents each SF in a network. SF-ID is unique within each SFC 95 network and does not need to be globally unique. Even if multiple 96 instances of the same Service Function are available in an SFC 97 network, the same SF-ID is used to identify the Service Function. 99 Service Function Locator(SF-Loc): A unique name or address which 100 identifies each Service Function. When multiple instances of the 101 same Service Function are available in an SFC network, each 102 instance has its own Service Function Locator. 104 Service Function Chain (SFC): An ordered list of SF which should be 105 traversed. 107 Service Function Chain Identity (SC-ID): A unique identifier which 108 represents each SFC in a network. SC-ID is unique within each SFC 109 network and does not need to be globally unique. 111 Service Function Chain Enforcement Point (SCEP): A node which is 112 able to guarantee that a list of SF will be traversed in a 113 specific order for flows which are associated with such SF chain. 115 Service Chaining Infrastructure Network (SC-IN): is formed by a one 116 or more SCEP nodes connected together. 118 Service Chaining Classification Function (SC-CL): A logical function 119 part of a SCEP node. SC-CL is mandatory to execute when packets 120 enter the SC-IN (ingress). 122 Service Chaining Forwarding Function (SC-FWD): A logical function 123 part of a SCEP node. It is responsible for forwarding packets to 124 SF, forwarding packets to other SCEP nodes and to remove SC-IN 125 specific information from packets when exiting (egress) SC-IN. 126 SC-FWD is mandatory in all SCEP nodes. 128 Service Function Path: Specific path taken by packets through SC-IN. 129 Service Function Path includes specific SCEP nodes and SF nodes 130 traversed by an individual flow. 132 3. Architecture principles 134 3.1. Introduction 136 The concept of Service Function Chaining consists of applying a 137 number of Service Functions in a specific order. The proposed 138 architecture for Service Function Chaining ties together four 139 different mechanisms to guarantee the execution of Service Functions 140 in a specifc order. 142 Those four separate mechanisms are: 144 o A mechanism to specify a Service Function Chain (SFC) as an 145 ordered list of Service Functions. 147 o A mechanism to deliver packets between SF instances in the 148 specified order: Service Chaining Infrastructure (SC-IN). 150 o A mechanism to specify which packets should be associated with a 151 specific Service Function Chain: SFC classification. 153 o A mechanism to support scaling in/out the number of instances of 154 each SF. 156 3.2. Service Function Chain 158 A Service Function Chain (SFC) consists of an ordered list of Service 159 Function (SF). Each SF is defined by an identifier which is unique 160 within an administrative domain (SF-ID). No IANA registry is 161 required to store the identity of SFs. 163 Multiple Service Function Chains can exist in the same administrative 164 domain. Each Service Function Chain (SFC) is defined by an 165 identifier which is unique within an administrative domain (SC-ID). 166 No IANA registry is required to store the identity of Service 167 Function Chains. 169 As no information about topology, SF classification or SF scaling is 170 represented in the SF chain definition therefore, Service Function 171 Chains are independent from changes in topology, classification or 172 scaling instances of a Service Function. 174 Here is a some examples of Service Function Chains: 176 +----------+ +----------+ +----------+ +----------+ 177 | Load | | Web | | Fire | | | 178 SFC-ID=1 | Balancer |--| Proxy |--| wall |--| NAT44 | 179 | SF-ID=1 | | SF-ID=2 | | SF-ID=3 | | SF-ID=4 | 180 +----------+ +----------+ +----------+ +----------+ 182 +----------+ +----------+ +----------+ 183 | | | Header | | Fire | 184 SFC-ID=2 | DPI |--| enrichm. |--| wall | 185 | SF-ID=6 | | SF-ID=5 | | SF-ID=3 | 186 +----------+ +----------+ +----------+ 188 Figure 1: Service Function Chain examples 190 3.3. Service Chaining Infrastructure 192 The Service Chaining Infrastructure (SC-IN) consists of Service 193 Chaining Enforcement Points (SCEP) and Service Functions 194 interconnected as a network. An SCEP node contains a forwarding 195 function (SC-FWD) and optionally a classification function (SC-CL). 197 Service Chaining Infrastructure (SC-IN) is illustrated in Figure 2. 199 +..................................................................+ 200 . +------------+ +------------+ +------------+ +------------+ . 201 . | Service | | Service | | Service | | Service | . 202 . |Function(SF)| |Function(SF)| |Function(SF)| |Function(SF)| . 203 . +------------+ +------------+ +------------+ +------------+ . 204 . \ / \ / . 205 . \ / \ / . 206 . \ / \ / . 207 . +------------+ +------------+ . 208 . | SCEP | | SCEP | . 209 . | (SC-FWD) | | (SC-FWD) | . 210 . +------------+ +------------+ . 211 . \ / . 212 . \ / . 213 . \ .--. / . 214 . +------------+ \ ( )-. / +------------+ . 215 . |SCEP-Ingress| .' ' | SCEP-Egress| . 216 . |(SC-CL,FWD) |-------( Network )------| (SC-FWD) | . 217 . +------------+ ( -' +------------+ . 218 . / '-( ) \ . 219 . / '---' \ . 220 . / Service Chaining Infrastructure \ . 221 +......../..............................................\..........+ 222 / \ 223 .--. .--. 224 ( )-. ( )-. 225 .' Ingress' .' Egress ' 226 ( Network ) ( Network ) 227 ( -' ( -' 228 '-( ) '-( ) 229 '---' '---' 231 Figure 2: Service Chaining Infrastructure 233 SCEP can directly reach other SCEP nodes within the SC-IN. Service 234 Functions (SF) are directly connected to an SCEP. To enforce the 235 execution of SF in the specified order, Service Functions (SF) cannot 236 communicate directly between eachother without going through an SCEP. 237 One or many SFs can be attached to the same SCEP. 239 When entering an SC-IN, an ingress SCEP which contains an SC-CL will 240 map packets into a specific Service Function Path. Once this mapping 241 is done, the SC-FWD will determine the locator for the next SF on the 242 Service Function Path and forward the packet to the SF to be invoked. 244 3.4. Service Function scaling 246 Multiple instances of the same Service Function can exist in the 247 SC-IN. Each new instances of a SF, when created, will be attached to 248 an SCEP in the SC-IN and a unique locator (SF-Loc) will be allocated 249 to it. 251 When instances of a Service Function needs to be removed, the Service 252 Function Controller will ensure that no packet can be forwarded to 253 the instance of Service Function to be removed. Once done, the 254 Service Function instance can be removed. 256 3.5. Service Function Classification 258 In order to direct specific packets to follow a certain Service 259 Function Path, SC-CL will analyse the packet headers and determine 260 which Service Function Path should be followed. A Service Function 261 Path is a list of Service Function locators (SF-Loc) for the specific 262 instances of SF which constitutes a SFC. 264 Once the Service Function Path is determined, the Service Chaining 265 Forwarding function (SC-FWD) will determine the next Service Function 266 and forward the traffic to it. 268 3.6. Service Chaining Controller 270 The Service Function Chaining Controller is responsible to configure 271 SCEP nodes in the Service Chaining Infrastructure. It is the 272 controller which ties together Service Function Chains/Paths, the 273 topology of the Service Chaining Infrastructure, the locating 274 information of SF instances as they are being scaled in/out and 275 Service Chaining Classification rules. 277 It is responsible to guarantee the consistency of the configuration 278 of SCEP across the SC-IN. Service Chaining Controller is illustrated 279 in Figure 3. 281 +-----------------+ 282 | Service | 283 | Chaining |..................... 284 | Controller | . 285 +-----------------+ . 286 . . . 287 +..................................................................+ 288 . . . . . 289 . . +------------+ . . 290 . . | SCEP | . . 291 . . | (SC-FWD) | . . 292 . . +------------+ . . 293 . . \ . . 294 . . \ . . 295 . . \ .--. . . 296 . +------------+ \ ( )-. +------------+ . 297 . |SCEP-Ingress| .' ' | SCEP-Egress| . 298 . |(SC-CL,FWD) |-------( Network )------| (SC-FWD) | . 299 . +------------+ ( -' +------------+ . 300 . '-( ) . 301 . '---' . 302 . Service Chaining Infrastructure . 303 +..................................................................+ 305 Figure 3: Service Chaining Controller 307 4. Acknowledgements 309 This template was derived from an initial version written by Pekka 310 Savola and contributed by him to the xml2rfc project. 312 5. IANA Considerations 314 This document has no IANA actions. 316 6. Security Considerations 318 SFC must address at least the following security considerations: 320 o Secure and authenticate communication between controller and SCEP 321 nodes 323 o Authenticate communication between SF and SCEP node. 325 o Isolate SC-IN network when infrastructure is shared with nodes 326 which are not SCEP nodes. 328 o Protect interface at border of SC-IN (ingress/egress SCEP) against 329 fraudulent usage. 331 o Protect SFC specific protocol/metadata information against 332 fraudulent usage. 334 o When an SCEP participate in multiple networks, isolation between 335 them. 337 o Protect interface between SF and SCEP node against fraudulent 338 usage. 340 7. References 342 7.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 348 Address Translator (Traditional NAT)", RFC 3022, 349 January 2001. 351 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 352 Customer Premises Equipment (CPE) for Providing 353 Residential IPv6 Internet Service", RFC 6092, 354 January 2011. 356 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 357 NAT64: Network Address and Protocol Translation from IPv6 358 Clients to IPv4 Servers", RFC 6146, April 2011. 360 7.2. Informative References 362 [I-D.boucadair-sfc-framework] 363 Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., 364 Guichard, J., and C. Pignataro, "Service Function 365 Chaining: Framework & Architecture", 366 draft-boucadair-sfc-framework-00 (work in progress), 367 October 2013. 369 [I-D.boucadair-sfc-requirements] 370 Boucadair, M., Jacquenet, C., Jiang, Y., Parker, R., and 371 C. Pignataro, "Requirements for Service Function 372 Chaining", draft-boucadair-sfc-requirements-00 (work in 373 progress), October 2013. 375 [I-D.quinn-sfc-problem-statement] 376 Quinn, P., Guichard, J., Surendra, S., Agarwal, P., Manur, 377 R., Chauhan, A., Leymann, N., Boucadair, M., Jacquenet, 378 C., Smith, M., Yadav, N., Nadeau, T., Gray, K., McConnell, 379 B., and K. Kevin, "Service Function Chaining Problem 380 Statement", draft-quinn-sfc-problem-statement-00 (work in 381 progress), October 2013. 383 Author's Address 385 Andre Beliveau 386 Ericsson 387 8400 Decarie Blvd. 388 Town of Mount Royal, QC 389 Canada 391 Phone: +1 514 345 2708 392 Email: andre.beliveau@ericsson.com