idnits 2.17.00 (12 Aug 2021) /tmp/idnits53699/draft-parker-sfc-chain-to-path-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 (November 8, 2013) is 3116 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.quinn-sfc-nsh' is defined on line 389, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-boucadair-sfc-framework-00 == Outdated reference: A later version (-07) exists of draft-quinn-sfc-nsh-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SFC R. Parker 2 Internet Draft Affirmed Networks 3 Intended status: Informational November 8, 2013 4 Expires: May 7, 2014 6 Service Function Chaining: Chain to Path Reduction 7 draft-parker-sfc-chain-to-path-00 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on May 8, 2014. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. 44 Abstract 46 The service function chaining concept differentiates between a 47 service function chain and a service function path. A chain is a 48 sequence of service function types whereas a path is a sequence of 49 service function instances that realize each type of service 50 function. 52 This document describes the architectural approach to reducing the 53 abstract service function chain to the concrete service function 54 path. 56 Table of Contents 58 1. Introduction...................................................3 59 1.1. Service Function Chaining Concepts........................3 60 1.2. Scope.....................................................3 61 1.3. Objectives................................................4 62 1.4. Rationale.................................................4 63 2. Conventions used in this document..............................4 64 3. New SFC Functional Entities....................................6 65 3.1. SFC Proxy.................................................6 66 3.1.1. SFC Proxy for Non-last Service Function..............6 67 3.1.2. SFC Proxy for Last Service Function..................6 68 3.2. Service Function Load Balancer............................6 69 3.2.1. Proxy Service Function Load Balancer.................7 70 4. Service Function Path Topologies...............................7 71 4.1. Chain Comprised of Singly-located Service Functions.......7 72 4.1.1. With Non-SFC-aware Service Functions.................7 73 4.2. Chain Comprised of Multiply-located Service Functions.....8 74 4.2.1. With Non-SFC-aware Service Functions.................9 75 4.3. Hybrid Chains.............................................9 76 5. Security Considerations.......................................10 77 6. IANA Considerations...........................................10 78 7. Conclusions...................................................10 79 8. References....................................................11 80 8.1. Normative References.....................................11 81 8.2. Informative References...................................11 82 9. Acknowledgments...............................................11 84 1. Introduction 86 1.1. Service Function Chaining Concepts 88 The service function chain is an abstract sequenced set of service 89 functions, as described in [I-D.boucadair-sfc-framework]. Service 90 functions that participate in SFC are assumed to be transparent 91 "midbox" service functions, where transparent in this usage denotes 92 only that the service function is not explicitly addressed by either 93 communications endpoint. 95 The service function locator, also described in [I-D.boucadair-sfc- 96 framework], is the means to bind the abstract service functions to 97 physical or virtual instantiations. The completed mapping of a 98 service function chain through the locators of its constituent 99 service functions is called a service function path, also described 100 in [I-D.boucadair-sfc-framework]. 102 A service function may have a single locator, or multiple locators. 103 When multiple locators are specified, a load balancing operation is 104 required to select which one of the instances shall be used for any 105 particular service function path. This document describes an 106 approach where the service function path is rendered in real time, 107 on a packet by packet basis, from the service function chain. 109 1.2. Scope 111 This document defines a technique whereby service function chains 112 may be rendered in real time as service function paths. This 113 document does not make any assumptions regarding the behavior of any 114 particular service function or the appropriate technique (i.e., 115 stateless, stateful, etc.) to load balance for a given service 116 function. 118 Load balancing across multiple locators may involve liveness 119 checking or load checking. No assumptions are made regarding the 120 appropriate technique to determine the liveness or load for a 121 particular service function. Such load balancing may also involve 122 other policies, such as location of the service function instance 123 relative to the location of one or both communication endpoints. 124 No assumptions are made regarding the use or type of policy to 125 perform load balancing for a service function. 127 1.3. Objectives 129 . SFC classifier (PDP) actions identical for SFC-aware and non-SFC- 130 aware service functions 131 . SFC classifier (PDP)_actions identical for singly-located and 132 multiply-located service functions 133 . SFC classifier (PDP) actions identical for any service function 134 . Preceding service function actions identical for SFC-aware and 135 non-SFC-aware succeeding service functions 136 . Preceding service function actions identical for singly-located 137 and multiply-located succeeding service functions 138 . Preceding service function actions identical for any succeeding 139 service function 140 . SFC does not specify or limit mechanisms and behaviors for load 141 balancing within a service function 143 1.4. Rationale 145 SFC proxy functionality for non-SFC aware service functions and load 146 balancing for multiply-located service functions (SFC-aware and non- 147 SFC-aware) belongs to the service function domain. It is not 148 possible nor is it desirable to specify, in a practical manner, 149 either proxy functionality or load balancing for any arbitrary 150 service function. 152 2. Conventions used in this document 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC-2119 [RFC2119]. 158 In this document, these words will appear with that interpretation 159 only when in ALL CAPS. Lower case uses of these words are not to be 160 interpreted as carrying RFC-2119 significance. 162 In this document, the characters ">>" preceding an indented line(s) 163 indicates a compliance requirement statement using the key words 164 listed above. This convention aids reviewers in quickly identifying 165 or finding the explicit compliance requirements of this RFC. 167 An abstract service function (i.e., part of a service chain 168 definition) is denoted as ''. 170 A concrete service function instance (i.e. a service function that 171 has been located) is denoted as '.'. 173 An SFC service function proxy, as will be defined later in this 174 document, is denoted as '.p'. 176 A service function load balancer is denoted as '.lb'. 178 A combined service function load balancer and proxy, as will be 179 defined later in this document, is denoted as '.plb'. 181 Unless otherwise specified, the term "Service Function Chain" shall 182 be more broadly interpreted as "Service Function Graph". It is 183 understood that any service function may include a reclassifier 184 (i.e., Policy Decision Point) in order to make dynamic branching 185 decisions along the service function graph. 187 3. New SFC Functional Entities 189 The following SFC functional entities are in addition to those 190 identified in [I-D.boucadair-sfc-framework]. 192 3.1. SFC Proxy 194 An SFC proxy front-ends a legacy service function that is not SFC- 195 aware. 197 3.1.1. SFC Proxy for Non-last Service Function 199 When receiving packets from the preceding service function (or the 200 PDP if this service function is first), the SFC proxy terminates 201 both the transport and SFC service headers. The resulting packets 202 are forwarded to the legacy service function. The legacy service 203 function must be provisioned to return the packets back to the SFC 204 proxy. 206 When receiving returned packets from the legacy service function, 207 the SFC proxy generates appropriate transport and SFC service 208 headers towards the succeeding service function. 210 It is permissible for an SFC Proxy to also act as a reclassifier, 211 thereby making a branching decision on a service function graph. 213 3.1.2. SFC Proxy for Last Service Function 215 It shall be an implementation decision as to whether a non-SFC-aware 216 service function that is the last service function in the chain 217 returns the packets to its proxy or send the packets beyond the end 218 of the chain directly. 220 3.2. Service Function Load Balancer 222 A service function load balancer manages all load balancing duties 223 for its constituent SFC-aware service function instances. How this 224 is accomplished for the given service function is completely outside 225 the scope of this document. 227 The service function load balancer appears to preceding services, or 228 the PDP if the service function is the first in the chain, as a 229 single entity that receives all traffic for that service function 230 within the particular chain. Thus, preceding services and the PDP, 231 itself, never concern themselves with the fact that the succeeding 232 service may have multiple locators. 234 Since the service function load balancer is managing SFC-aware 235 service function instances, it is not, itself eligible to be a 236 reclassifier (Policy Decision Point). 238 3.2.1. Proxy Service Function Load Balancer 240 The proxy service function load balancer is a combination of the 241 service function proxy and the SFC-aware load balancer. Since it 242 terminates the transport and SFC service headers, the proxy service 243 function load balancer is eligible to be a reclassifier (Policy 244 Decision Point). 246 4. Service Function Path Topologies 248 This section provides a number of example topologies that 249 demonstrate the real-time reduction of the service function chain to 250 a specific service function path. 252 4.1. Chain Comprised of Singly-located Service Functions 254 This topology is the simplest since the chain and path have a 1:1 255 correspondence. An example service function path comprised solely 256 of singly-located, SFC-aware service functions is depicted below. 258 +-----+ +-----+ +-----+ +-----+ 259 ----->| PDP |----->| A.1 |----->| B.1 |----->| C.1 |-----> 260 +-----+ +-----+ +-----+ +-----+ 262 4.1.1. With Non-SFC-aware Service Functions 264 In this use case, the service functions require an SFC-proxy to act 265 as front-end. 267 +-----+ +-----+ +-----+ +-----+ 268 ----->| PDP |----->| A.p |----->| B.p |----->| C.p |-----> 269 +-----+ +-----+ +-----+ +-----+ 270 | ^ | ^ | ^ 271 | | | | | | 272 +-----+ +-----+ +-----+ 273 | A.1 | | B.1 | | C.1 | 274 +-----+ +-----+ +-----+ 276 4.2. Chain Comprised of Multiply-located Service Functions 278 This use case supports load balancing across multiple service 279 function instances. For clarity, each load balancer is shown as 280 having picked a particular service instance. The means by which 281 this selection is made is outside the scope of this document. 283 +-----+ +------+ +------+ +------+ 284 --->| PDP |----->| A.lb | +-->| B.lb | +-->| C.lb | 285 +-----+ +------+ | +------+ | +------+ 286 | | | | | 287 | +-----+ | | +-----+ | | +-----+ 288 +-->| A.1 |-+ + | B.1 | | + | C.1 | 289 | +-----+ | +-----+ | | +-----+ 290 | | | | 291 | +-----+ | +-----+ | | +-----+ 292 + | A.2 | +-->| B.2 |-+ + | C.2 | 293 +-----+ +-----+ | +-----+ 294 | 295 | +-----+ 296 +-->| C.3 |---> 297 +-----+ 299 As can be seen from this diagram, the preceding node (PDP or service 300 function) always propagates packets to the responsible load balancer 301 for the next service function in the chain. The load balancer 302 makes a service function appropriate selection for the packet and 303 forwards to one of the service function instances. Since the 304 service function instances are SFC-aware, they directly forward the 305 packet to the next service function load balancer, or out of the 306 chain entirely, if the last service function in the chain. 308 4.2.1. With Non-SFC-aware Service Functions 310 This use case could be achieved by front-ending each service 311 instance with an SFC proxy. Such an approach is entirely valid. 312 However, an alternative approach is also supported by use of the 313 proxy service function load balancer. 315 +-----+ +-------+ +-------+ +-------+ 316 ---->| PDP |--->| A.plb |------->| B.plb |------>| C.plb |-----> 317 +-----+ +-------+ +-------+ +-------+ 318 | ^ | ^ | ^ 319 | | | | | | 320 | | | | | | 321 | +------+ | +------+ | +------+ 322 | | | | | | 323 | +-----+ | | +-----+ | | +-----+ | 324 +-->| A.1 |-+ + | B.1 | | + | C.1 | | 325 | +-----+ | +-----+ | | +-----+ | 326 | | | | | 327 | +-----+ | +-----+ | | +-----+ | 328 + | A.2 | +-->| B.2 |-+ + | C.2 | | 329 +-----+ +-----+ | +-----+ | 330 | | 331 | +-----+ | 332 +-->| C.3 |-+ 333 +-----+ 335 It can be seen that this diagram differs from the previous in that 336 the service functions must return the packets to their respective 337 proxy/load balancer for appropriate transport and SFC service header 338 encapsulation. 340 4.3. Hybrid Chains 342 A chain of service functions may support any combination of service 343 functions that are singly-located SFC-aware, load-balanced SFC- 344 aware, singly-located proxied, and load-balanced proxied. 346 5. Security Considerations 348 All SFC entities must be protected against DDoS attacks, malformed 349 packets, and poorly configured (deliberately or not) service chains 350 and service function locator tables. 352 6. IANA Considerations 354 There are no IANA considerations for this document. 356 7. Conclusions 358 By strictly layering SFC chaining, SFC proxy, and load balancing, a 359 simpler more resilient end-to-end service function chaining 360 architecture is achieved. Handling of failed service function 361 instances as well as static and dynamic expansion and contraction of 362 the service function is localized to an entity that has been 363 designed specifically for that type of service function. 365 Both preceding service functions (or PDP) and succeeding service 366 functions are completely unaware of whether a service function is 367 SFC-aware, multiply instantiated, both, or neither. 369 This architecture provides a unified approach for incorporation of 370 multiple instances of SFC-aware service functions, for incorporation 371 of non-SFC-aware legacy service functions, and for incorporation of 372 multiple instances of non-SFC aware legacy service functions. 374 8. References 376 8.1. Normative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997. 381 8.2. Informative References 383 [I-D.boucadair-sfc-framework] 384 M. Bouadair, C. Jacquenet, R. Parker, D. Lopez, J. Guichard, 385 C. Pignataro, "Service Function Chaining: Framework & 386 Architecture", http://tools.ietf.org/html/draft-boucadair- 387 sfc-framework-00 (work in progress), October 3, 2013 389 [I-D.quinn-sfc-nsh] 390 P. Quinn, et. al., "Network Service Header", 391 http://tools.ietf.org/html/draft-quinn-sfc-nsh-00 (work in 392 progress), October 7, 2013 394 9. Acknowledgments 396 This document was prepared using 2-Word-v2.0.template.dot. 398 Authors' Addresses 400 Ron Parker 401 Affirmed Networks 402 Acton, MA 01720 403 USA 405 Email: ron_parker@affirmednetworks.com