idnits 2.17.1 draft-boucadair-sfc-framework-01.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 3697 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) == Outdated reference: A later version (-03) exists of draft-boucadair-sfc-design-analysis-01 == Outdated reference: A later version (-06) exists of draft-boucadair-sfc-requirements-03 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-00 == Outdated reference: A later version (-06) exists of draft-tsou-softwire-bfd-ds-lite-05 Summary: 0 errors (**), 0 flaws (~~), 5 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: Standards Track France Telecom 5 Expires: August 16, 2014 R. Parker 6 Affirmed Networks 7 D. Lopez 8 Telefonica I+D 9 J. Guichard 10 C. Pignataro 11 Cisco Systems, Inc. 12 February 12, 2014 14 Service Function Chaining: Framework & Architecture 15 draft-boucadair-sfc-framework-01 17 Abstract 19 IP networks rely more and more on the combination of advanced 20 functions (besides the basic routing and forwarding functions) for 21 the delivery of added value services. This document defines a 22 reference architecture and a framework to enforce Service Function 23 Chaining (SFC) with minimum requirements on the physical topology of 24 the network. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 16, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. On the Proliferation of Service Functions . . . . . . . . 3 68 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3. Functional Elements . . . . . . . . . . . . . . . . . . . . . 7 74 4. SFC Provisioning . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Assign Service Function Identifiers . . . . . . . . . . . 8 76 4.2. Service Function Locator . . . . . . . . . . . . . . . . 8 77 4.3. Service Function Discovery . . . . . . . . . . . . . . . 8 78 4.4. Building Service Function Maps . . . . . . . . . . . . . 9 79 4.5. Building Service Function Chaining (SFC) Policy Tables . 9 80 5. Theory Of Operation . . . . . . . . . . . . . . . . . . . . . 11 81 5.1. SFC Boundary Node . . . . . . . . . . . . . . . . . . . . 11 82 5.2. SFC Classifier . . . . . . . . . . . . . . . . . . . . . 11 83 5.3. SFC Ingress Node . . . . . . . . . . . . . . . . . . . . 12 84 5.4. SFC Egress Node . . . . . . . . . . . . . . . . . . . . . 13 85 5.5. SF Node . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 5.6. Intermediate Nodes . . . . . . . . . . . . . . . . . . . 14 87 6. Fragmentation Considerations . . . . . . . . . . . . . . . . 14 88 7. Differentiated Services . . . . . . . . . . . . . . . . . . . 14 89 8. ECN (Explicit Congestion Notification) Considerations . . . . 14 90 9. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 91 9.1. Transmit A SFC Map Index In A Packet . . . . . . . . . . 15 92 9.1.1. SFC Map Index . . . . . . . . . . . . . . . . . . . . 15 93 9.1.2. Why Not Loose Or Strict Source Routing (SSR)? . . . . 15 94 9.1.3. Where To Store SFC Map Indexes In A Packet? . . . . . 15 95 9.2. Steer Paths To Cross Specific SF Nodes . . . . . . . . . 15 96 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 16 97 10.1. Generic Requirements . . . . . . . . . . . . . . . . . . 16 98 10.2. Deployment Models . . . . . . . . . . . . . . . . . . . 16 99 10.2.1. 1.1. Proxy Node for Legacy Service Functions . . . . 17 100 10.3. On Service Function Profiles (a.k.a., Contexts) . . . . 17 101 10.4. SF Node is also a Classifier . . . . . . . . . . . . . . 18 102 10.5. SFs within the Same Subnet . . . . . . . . . . . . . . . 19 103 10.6. Service Function Loops . . . . . . . . . . . . . . . . . 19 104 10.7. Lightweight SFC Policy Table . . . . . . . . . . . . . . 20 105 10.8. Liveness Detection Of SFs By The PDP . . . . . . . . . 21 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 107 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 108 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 109 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 110 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 111 15.1. Normative References . . . . . . . . . . . . . . . . . . 22 112 15.2. Informative References . . . . . . . . . . . . . . . . . 22 114 1. Introduction 116 1.1. On the Proliferation of Service Functions 118 IP networks rely more and more on the combination of advanced 119 functions (besides the basic routing and forwarding functions) for 120 the delivery of added value services. Typical examples of such 121 functions include firewall (e.g., [RFC6092]), DPI (Deep Packet 122 Inspection), LI (Lawful Intercept) module, NAT44 [RFC3022], NAT64 123 [RFC6146], DS-Lite AFTR [RFC6333], NPTv6 [RFC6296], HOST_ID 124 injection, HTTP Header Enrichment function, TCP tweaking and 125 optimization function, transparent caching, charging function, load- 126 balancer, etc. 128 Such advanced functions are denoted SF (Service Function) in this 129 document. 131 The dynamic enforcement of a SF-derived, adequate forwarding policy 132 for packets entering a network that supports such advanced Service 133 Functions has become a key challenge for operators and service 134 providers. SF-inferred differentiated forwarding is ensured by 135 tweaking the set of Service Functions to be invoked. How to bind a 136 flow of packets that share at least one common characteristic to a 137 forwarding plane is policy-based, and subject to the set of SF 138 functions that need to be solicited for the processing of this 139 specific flow. 141 Service Providers need to rationalize their service delivery logics 142 and master its underlying complexity. 144 The overall problem space is described in 145 [I-D.ietf-sfc-problem-statement]. A companion document that lists a 146 set of requirements is available at [I-D.boucadair-sfc-requirements]. 148 1.2. Scope 150 This document defines a framework to enforce Service Function 151 Chaining (SFC) with minimum requirements on the physical topology of 152 the network. The proposed solution allows for differentiated 153 forwarding: packets are initially classified at the entry point of an 154 SFC-enabled network, and are then forwarded according to the ordered 155 set of SF functions that need to be activated to process these 156 packets in the SFC-enabled domain. 158 This document does not make any assumption on the deployment context. 159 The proposed framework covers both fixed and mobile networks (e.g., 160 to rationalize the proliferation of advanced features at the Gi 161 Interface [RFC6459]). 163 Considerations related to the chaining of Service Functions that span 164 domains owned by multiple administrative entities is out of scope. 165 Note, a single administrative entity may manage multiple domains. 167 1.3. Objectives 169 The main objectives of the proposed framework are listed below: 171 o Create service-inferred forwarding planes. 172 o Efficiently master the chained activation of Service functions, 173 regardless of the network topology and routing policies. 174 o Allow packets to be forwarded to the required Service Functions 175 without changing the network topology or overlay transports 176 necessary for packet delivery to/from Service Functions. 177 o Allow for differentiated packet forwarding by selecting the set of 178 Service functions to be invoked. 179 o Allow to easily change the sequentiality of the activation of 180 Service functions to be invoked. 181 o Allow to easily change the set of Service functions to be invoked. 182 o Ease management (including withdrawal) of Service functions and 183 minimize any subsequent topology update. 184 o Automate the overall process of generating and enforcing policies 185 to accommodate a set of network connectivity service objectives. 187 1.4. Assumptions 189 The following assumptions are made: 191 o Not all SFs can be characterized with a standard definition in 192 terms of technical description, detailed specification, 193 configuration, etc. 194 o There is no global nor standard list of SFs enabled in a given 195 administrative domain. The set of SFs varies as a function of the 196 service to be provided and according to the networking 197 environment. 198 o There is no global nor standard SF chaining logic. The ordered 199 set of SFs that need to be activated to deliver a given 200 connectivity service is specific to each administrative entity. 201 o The chaining of SFs and the criteria to invoke some of them are 202 specific to each administrative entity that operates the SF- 203 enabled network (also called administrative domain). 204 o SF chaining logic and related policies should not be exposed 205 outside a given administrative domain. 206 o Several SF chaining logics can be simultaneously enforced within 207 an administrative domain to meet various business requirements. 208 o No assumption is made on how FIBs and RIBs of involved nodes are 209 populated. 210 o How to bind the traffic to a given SF chaining is policy-based. 212 1.5. Rationale 214 Given the assumptions listed in Section 1.4, the rationale of the 215 framework is as follows: 217 o The framework separates the dynamic provisioning of required SF 218 functions from packet handling operations (e.g., forwarding 219 decisions). 220 o The technical characterization of each SF is not required to 221 design the SFC architecture and SFC operations. 222 o No IANA registry is required to store the list of SFs. In 223 particular, assignment of identifiers, header fields, or any other 224 indication of the Service Function Chain, are all strictly local 225 in scope. An identifier assigned in one administrative domain 226 will not indicate the same set of SFs in another administrative 227 domain. 228 o No IANA registry is required to store the SF chaining candidates. 229 The set of SFCs are local to each administrative domain, and are 230 as such not global. 231 o No specific SF chaining is assumed. The description of SF chains 232 is an information that will be processed by the nodes that 233 participate to the delivery of a network service. The set of 234 listed/chained SF functions is generated by each administrative 235 entity operating the network. 236 o SF handling is policy-based: SF chains can be updated or deleted, 237 new SFs can be added without any impact on existing SFs, etc. In 238 particular, this design is compliant with the global framework 239 discussed in [I-D.sin-sdnrg-sdn-approach]. 240 o For the sake of efficiency, policy enforcement is automated (but 241 policies can be statically enforced, for example). 242 o To minimize fragmentation, a minimal set of information needs to 243 be signaled (possibly in data packets). 244 o Advanced features (e.g., load balancing) are also described and 245 may be configured according to policies that can be service- 246 specific. Policy decisions are made by a Policy Decision Point 247 [RFC2753] and the solicited enforcement points are responsible for 248 applying these decisions, whatever the objective to achieve. 249 o SFs can be embedded in nodes that intervene in the transport 250 service or supported by dedicated nodes (e.g., dedicated servers). 251 The decision to implement one of these two models (or a 252 combination thereof) is deployment-specific and it is orthogonal 253 to the overall procedure. 254 o Multiple SFC-enabled domains can be deployed within the same 255 administrative domain. Nodes are provisioned with the policy 256 table of the SFC-enabled domain they belong to. 257 o The overall consistency of the differentiated forwarding policy is 258 ensured by the PDP. 259 o The PDP can be responsible to enforce other policies than those 260 described in the SFC Policy Tables. 262 2. Terminology 264 This document makes use of the following terms: 266 o SF (Service Function): refers to a function which is enabled in 267 the network operated by an administrative entity. One or many 268 Service Functions can be involved in the delivery of added-value 269 services. A non-exhaustive list of Service Functions include: 270 firewall (e.g., [RFC6092]), DPI (Deep Packet Inspection), LI 271 (Lawful Intercept) module, NAT44 [RFC3022], NAT64 [RFC6146], DS- 272 Lite AFTR [RFC6333], NPTv6 [RFC6296], HOST_ID injection, HTTP 273 Header Enrichment function, TCP optimizer, load-balancer, etc. 274 This document does not make any assumption in the OSI Layer on 275 which the Service Function acts on; the exact definition of each 276 Service Function is deployment-specific. 278 o SFC-enabled domain: denotes a network (or a region thereof) that 279 implements SFC. 281 o SF Identifier: is a unique identifier that unambiguously 282 identifies a SF within a SFC-enabled domain. SF Identifiers are 283 assigned, configured and managed by the administrative entity that 284 operates the SFC-enabled domain. SF identifiers can be structured 285 as strings; other formats can be used. SF Identifiers are not 286 required to be globally unique nor be exposed to or used by 287 another SF-enabled domain. 289 o SF Map: refers to an ordered list of SF identifiers. Each SF Map 290 is identified with a unique identifier called SF Map Index. 292 o SFC Policy Table: is a table containing a list of SF Maps, SFC 293 classification rules and Locators for all SF Nodes. A SFC Policy 294 Table may contain a default SF Map. 296 o SF Locator: A SF Node identifier used to reach the said SF node. 297 A locator is typically an IP address or a FQDN. 299 o Legacy Node (Node for short): refers to any node that is not a SF 300 Node nor a SFC Boundary Node. This node can be located within a 301 SFC-enabled domain or outside a SFC-enabled domain. 303 o SF Proxy Node: a Network Element along the data path, to enforce 304 SFC functions on behalf of legacy SF nodes. 306 3. Functional Elements 308 The following functional elements are defined in this document: 310 o SFC Boundary Node (or Boundary Node): denotes a node that connects 311 one SFC-enabled domain to a node either located in another SFC- 312 enabled domain or in a domain that is SFC-unaware. 314 o SFC Egress Node (or Egress Node): denotes a SFC Boundary Node that 315 handles traffic which leaves the SFC-enabled domain the Egress 316 Node belongs to. 318 o SFC Ingress Node (or Ingress Node): denotes a SFC Boundary Node 319 that handles traffic which enters the SFC-enabled domain the 320 ingress Node belongs to. 322 o SF Node: denotes any node within an SFC-enabled domain that embeds 323 one or multiple SFs. 325 o SFC Classifier (or Classifier): an entity that classifiers packets 326 for service chaining according to classification rules defined in 327 a SFC Policy Table. Packets are then marked with the 328 corresponding SF Map Index. SFC Classifier is embedded in a SFC 329 boundary (Ingress) Node. A SFC Classifier may be considered as a 330 Service Function, and therefore be uniquely identified by a 331 dedicated SF Identifier. 333 4. SFC Provisioning 335 It is out of scope of this document to discuss SF-specific policy 336 enforcement; only SFC considerations are elaborated. 338 4.1. Assign Service Function Identifiers 340 The administrative entity that operates a SFC-enabled domain 341 maintains a local repository that lists the enabled SFs. This 342 administrative entity assigns a unique SF identifier for each SF 343 type. 345 SF identifiers are structured as character strings. SF identifiers 346 are case-sensitive. 348 The main constraint on the format is that two SFs MUST be assigned 349 with different SF identifiers if they do not provide the exact same 350 function, or do provide the same function but are unable to 351 differentiation packets based on policies provisioned to the SF using 352 an appropriate mechanism. 354 4.2. Service Function Locator 356 A SF may be embedded in one or several SF Nodes. The SF locator is 357 typically the IP address or the FQDN to reach a given SF. 359 The use of an IP address is RECOMMENDED to avoid any extra complexity 360 related to the support of name resolution capabilities in SF Nodes. 361 Resolution capabilities are supported by the PDP (Policy Decision 362 Point). In the rest of the document, we assume a SF locator is 363 structured as an IP address (IPv4 or IPv6). 365 A SF can be reached by one or more locators. When multiple SF 366 locators are in use, the locator to be used to reach a given SF can 367 be driven by the PDP, a SF in a SFC, result of a load-balancing 368 heuristic, etc. 370 4.3. Service Function Discovery 372 The local repository that lists the enabled SFs within an SFC-enabled 373 domain may be built as a direct input from the administrative entity, 374 or they may be discovered dynamically through appropriate protocol 375 discovery means. 377 Whichever method is selected by the administrative entity is a local 378 decision and is therefore outside the scope of this document. Any 379 Service Function Discovery solution must comply with the requirements 380 identified in [I-D.boucadair-sfc-requirements]. 382 4.4. Building Service Function Maps 384 Added-value services delivered to the end-user rely on the invocation 385 of several SFs. For each of these services, the administrative 386 entity that operates an SFC-enabled domain builds one or several SF 387 Maps. Each of these maps characterizes the list of SFs to be invoked 388 with their exact invocation order. 390 Each SF Map is unambiguously identified with a unique identifier 391 called the SF Map Index. The SF Map Index MUST be described as an 392 unsigned integer. 394 Distinct chains can be applied for inbound and outbound traffic. The 395 directionality of traffic is not included as an attribute of the SF 396 Map, but it may be implicitly described by using two SF Maps 397 installed and maintained in the SFC Policy Table. In such case, 398 incoming packets would be marked with Index_1 for example, while 399 outgoing packets would be forwarded according to a distinct SF Map 400 identified with Index_2. 402 An example of SF Map to handle IPv6 traffic destined to an IPv4 403 remote server is defined as follows: 405 {15, {IPv6_Firewall, HOST_ID_Inject, NAT64}}. 407 To handle incoming packets destined to the same IPv6 host, the 408 following SF Map can be defined: 410 {10, {IPv4_Firewall, NAT64}}. 412 4.5. Building Service Function Chaining (SFC) Policy Tables 414 A PDP (Policy Decision Point, [RFC2753]) is the central entity which 415 is responsible for maintaining SFC Policy Tables (Figure 1), and 416 enforcing appropriate policies in SF Nodes and SFC Boundary Nodes 417 (Figure 1). PDP-made decisions can be forwarded to the participating 418 nodes by using a variety of protocols (e.g., NETCONF [RFC6241]). 420 One or multiple SFC-enabled domains may be under the responsibility 421 of the same PDP. Delimiting the scope of each SFC-enabled domain is 422 under the responsibility of the administrative entity that operates 423 the SF-enabled network. 425 o . . . . . . . . . . . . . . . . . . . . . . . o 426 . SFC Policy Enforcement . 427 . +-------+ . 428 . | |-----------------+ . 429 . +-------| PDP | | . 430 . | | |-------+ | . 431 . | +-------+ | | . 432 o . . | . . . . . | . . . . . | . . . . | . . . o 433 o . . | . . . . . | . . . . . | . . . . | . . . o 434 . | | | | . 435 . v v v v . 436 . +---------+ +---------+ +-------+ +-------+ . 437 . |SFC_BN_1 | |SFC_BN_n | | SF_1 | | SF_m | . 438 . +---------+ +---------+ +-------+ +-------+ . 439 . SFC-enabled Domain . 440 o . . . . . . . . . . . . . . . . . . . . . . . o 442 Figure 1: SFC Policy Enforcement Scheme. 444 The SF Node MUST be provisioned with the following information: 446 o Local SF Identifier(s): This information is required for an SF to 447 identify itself within an SF Map. 448 o List of SF Maps: The PDP may configure the full list (default 449 mode) or only as subset of SF Maps in which SF(s) supported by the 450 SF Node is involved (see Section 10.7). 451 o List of SF Locators: The PDP may configure the full list of 452 locators (default mode) or only the locators of next hop SFs of SF 453 Maps in which SF(s) supported by the local SF node is involved 454 (see Section 10.7). 456 [DISCUSSION NOTE: Discuss if we maintain both forms of the SFC 457 Policy table (full and lite) or select only one of them.] 459 Likewise, the SFC Boundary Node MUST be provisioned with the 460 following information: 462 o List of SF Maps 463 o List of SF Locators 464 o List of SF Map Classification Rules (see Section 5.2). 466 In addition to the SFC Policy Table, other SF-specific policies can 467 be installed by the PDP (e.g., configure distinct user profiles, 468 activate specific traffic filters, configure traffic conditioners, 469 etc.). 471 Policies managed by the PDP may be statically instantiated or 472 dynamically triggered by external means (e.g., a AAA server). 474 In the event of any update (e.g., define a new SF Map, delete an SF 475 Map, add a new SF Locator, update classification policy), the PDP 476 MUST forward the updated policy configuration information in all 477 relevant SF Nodes and SFC Boundary Nodes. 479 Distributing the load among several SF Nodes supporting the same SF 480 can be driven by the PDP. Indeed, the PDP can generate multiple 481 classification rules and SF Maps to meet some load-balancing 482 objectives. 484 Load balancing may also be achieved locally by an SF Node. If the SF 485 Node, SF Classifier, or SF Boundary Node has a table that provides 486 the SF locator(s) of SF Nodes that provide a particular SF then it is 487 possible to make that local load balancing decision. 489 The processing of packets by the nodes that belong to a SFC-enabled 490 domain does not necessarily require any interaction with the PDP, 491 depending on the nature of the SF supported by the nodes and the 492 corresponding policies to be enforced. For example, traffic 493 conditioning capabilities [RFC2475] are typical SF functions that may 494 require additional solicitation of the PDP for the SF node to decide 495 what to do with some out-of-profile traffic. 497 5. Theory Of Operation 499 The behavior of each node of a SFC-enabled domain is specified in the 500 following sections. We assume that the provisioning operations 501 discussed in Section 4 have been successful (i.e., SF functions have 502 been adequately configured according to the SFC-specific policy to be 503 enforced). 505 5.1. SFC Boundary Node 507 SFC Boundary Nodes act both as a SFC Ingress Node and as a SFC Egress 508 Node for the respective directions of the traffic. 510 Traffic enters a SFC-enabled domain at a SFC Ingress Node 511 (Section 5.3) and exits the domain at a SFC Egress Node 512 (Section 5.4). 514 5.2. SFC Classifier 516 The SFC Classifier classifies packets based on (some of) the contents 517 of the packet. Particularly, it classifies packets based on the 518 possible combination of one or more header fields, such as source 519 address, destination address, DS field, protocol ID, source port and 520 destination port numbers, and any other information. 522 Each SF Map Classification Rule MUST be bound to one single SF Map 523 (i.e., the classification rule must include only one SF Map Index). 525 5.3. SFC Ingress Node 527 When a packet is received through an interface of the SFC Ingress 528 Node that connects to the outside of the SFC domain, the Ingress Node 529 MUST: 531 o Inspect the received packet and check whether any existing SF Map 532 Index is included in the packet. 534 * The SFC Ingress Node SHOULD be configurable with a parameter to 535 indicate whether received SF Map Index is to be preserved or 536 striped. The default behavior is to strip any received SF Map 537 Index. 538 * Unless explicitly configured to trust SF Map index, The SFC 539 Ingress Node MUST strip any existing SF Map Index if the packet 540 is received from an SFC-enabled domain that has not explicitly 541 been designated as "trusted". 542 o Check whether the received packet matches an existing 543 classification rule (see Section 5.2). 544 o If no rule matches, forward the packet to the next hop according 545 to legacy forwarding behavior (e.g., based upon the IP address 546 conveyed in the DA field of the header). 547 o If a rule matches, proceed with the following operations: 549 * Retrieve the locator of the first SF as indicated in the SF Map 550 entry the rule matches. If multiple locators are available, 551 the selection can be based on local criteria (e.g., the closest 552 /best path). 553 * Check whether the corresponding SF node is an immediate (L3) 554 neighbor. 556 + If so, update the packet with the SF Map Index of SF Map 557 entry it matches and then forward the packet to the 558 corresponding SF Node. 559 + If not, (1) encapsulate the original packet into a new one 560 that will be forwarded to the corresponding SF node, (2) 561 update the encapsulated packet with the SF Map Index of SF 562 Map entry it matches, and (3) forward the packet to the next 563 hop to reach the first SF node. 565 As a result of this process, the packet will be sent to an SF Node or 566 an Intermediate Node. 568 5.4. SFC Egress Node 570 When a packet is received through an interface that connects the SFC 571 Egress Node to its SFC domain, the Egress Node MUST: 573 o Strip any existing SF Map Index. 574 o Forward the packet according to legacy forwarding policies. 576 5.5. SF Node 578 This section assumes the default behavior is each SF Node does not 579 embed a Classifier as discussed in Section 10.4. 581 When a packet is received by a SF Node, the SF Node MUST: 583 o Check whether the packet conveys a SF Map Index. 584 o If no SF Map Index is included, forward the packet according to 585 legacy forwarding policies. 586 o If the packet conveys a SF Map Index, 588 * Retrieve the corresponding SF Map from the SFC Policy Table. 589 If no entry is found in the table, forward the packet according 590 to legacy forwarding policies. 592 [DISCUSSION NOTE: Another design choice is to drop the 593 packet and send a notification to the PDP. The 594 justification for avoiding to drop the packet is that an SF 595 can be part of the forwarding path of an SFC to which it 596 does not belong to.] 597 * If an entry is found in the SFC Policy Table, check whether the 598 local SF Identifier is present in the SF Map: 600 + If not, forward the packet according to legacy forwarding 601 policies. 603 [DISCUSSION NOTE: One would argue the packet should be 604 dropped. The justification for avoiding to drop the 605 packet is that an SF can be part of the forwarding path 606 of an SFC to which it does not belong to + the SF node is 607 provisioned with the full SFC Policy Table.] 608 + If so, the packet is decapsulated (if needed) and then 609 presented as an input to the local SF. In case several SFs 610 are co-located in the same node, the packet is processed by 611 all SFs indicated in the SF Map. Once the packet is 612 successfully handled by local SF(s), the packet is forwarded 613 to the next SF Node in the list or to an intermediate node 614 (if the local SF Node is the last element in the SF Map). 615 If the local SF node is not the last one in the SF Map, it 616 retrieves the next SF Node from the list, retrieve its 617 locator for the SFC Policy Table, and forwards the packet to 618 the next hop. If the local SF Node is the last element in 619 the SF Map, it forwards the packet to the next hop according 620 to legacy forwarding policies. 622 5.6. Intermediate Nodes 624 An Intermediate Node is any node that does not support any Service 625 Function and which is located within a SFC-enabled domain. 627 No modification is required to intermediate nodes to handle incoming 628 packets. In particular, routing and forwarding are achieved using 629 legacy procedures. 631 6. Fragmentation Considerations 633 If adding the Service Chaining Header would result in a fragmented 634 packet, the classifier should include a Service Chaining Header in 635 each fragment. Doing so would prevent SF Nodes to dedicate resource 636 to handle fragments. 638 7. Differentiated Services 640 When encapsulating an IP packet, the Ingress Node and each SF Node 641 SHOULD use its Diffserv Codepoint (DSCP, [RFC2474]) to derive the 642 DSCP (or MPLS Traffic-Class Field) of the encapsulated packet. 644 Generic considerations related to Differentiated Services and tunnels 645 are further detailed in [RFC2983]. 647 8. ECN (Explicit Congestion Notification) Considerations 649 When encapsulating an IP packet, the Ingress Node and each SF Node 650 SHOULD follow [RFC6040] for ECN re-marking purposes. 652 9. Design Considerations 654 This section discusses two main protocol issues to be handled in 655 order to deploy SFC. 657 A detailed design analysis is documented in 658 [I-D.boucadair-sfc-design-analysis]. 660 9.1. Transmit A SFC Map Index In A Packet 662 9.1.1. SFC Map Index 664 A SF Map Index is an integer that points to a SF Map. 666 In order to avoid all nodes of a SFC-enabled domain to be SF-aware, 667 this specification recommends to undertake classifiers at boundary 668 nodes while intermediate nodes forward the packets according to the 669 SF Map Index conveyed in the packet (SF Node) or according to typical 670 forwarding policies (any SF-unaware node). 672 An 8-bit field would be sufficient to accommodate deployment contexts 673 that assume a reasonable set of SF Maps. A 16-bit (or 32-bit) field 674 would be more flexible (e.g., to accommodate the requirement 675 discussed in Section 10.3). 677 9.1.2. Why Not Loose Or Strict Source Routing (SSR)? 679 Instead of injecting a Map Index, an alternate solution would be to 680 use the SSRR/LSRR IPv4 option or any similar solution to indicate a 681 loose or strict explicit route. This alternative was not considered 682 because of the likely dramatic impact on the processing and potential 683 fragmentation issues that may jeopardize the overall performance of 684 the SFC operation. 686 Injecting an 8-bit or a 16-bit field would minimize fragmentation 687 issues. 689 9.1.3. Where To Store SFC Map Indexes In A Packet? 691 SF Map Indexes can be conveyed in various locations of a packet: 693 o At L2 level 694 o Define a new IP option or a new IPv6 extension header 695 o Use IPv6 Flow Label 696 o Re-use an existing field (e.g., DS field) 697 o TCP option 698 o GRE Key 699 o Define a new shim 700 o Etc. 702 9.2. Steer Paths To Cross Specific SF Nodes 704 A SFC Ingress Node or a SF Node MUST be able to forward a packet that 705 matches an existing SF Map to the relevant next hop SF Node. The 706 locator of the next SF is retrieved from the SFC Policy Table. In 707 case the next SF Node in the list is not an immediate (L3) neighbor, 708 a solution to force the packet to cross that SF Node MUST be 709 supported. This document suggests the use of the IP-in-IP 710 encapsulation scheme. Other tunneling solutions can be considered in 711 the future. 713 10. Deployment Considerations 715 10.1. Generic Requirements 717 The following deployment considerations should be taken into account: 719 o Avoid inducing severe path stretch compared to the path followed 720 if no SF is involved. 721 o Minimize path computation delays: due to the enforcement of 722 classification rules in all participating nodes, misconception of 723 Service function chaining, inappropriate choice of nodes elected 724 to embed Service functions, etc., must be avoided. 725 o Avoid SF invocation loops: the design of SF chainings should 726 minimize as much as possible SF invocation loops. In any case, 727 forwarding loops must be avoided. 729 10.2. Deployment Models 731 Below are listed some deployment model examples: 733 1. A full marking mechanism: Ingress nodes perform the 734 classification and marking functions. Then, involved SF Nodes 735 process received packets according to their marking. 737 2. SF node mechanism, in which every SF Node embeds also a 738 classifier, and the ingress node only decides the first node to 739 forward to. Packets are forwarded at each node according to 740 local policies. No marking is required when all SFs are co- 741 located with a classifier. This model suffers from some 742 limitations (see Section 10.4). 744 3. A router-based mechanism: All SF Nodes forward packets once 745 processed to their default router. This default routes is 746 responsible for deciding how the packet should be progressed at 747 each step in the chain. One or multiple routers can be involved 748 in the same Service Function Chain. 750 4. A combination thereof. 752 10.2.1. 1.1. Proxy Node for Legacy Service Functions 754 It is not uncommon to have multiple legacy service nodes located in 755 close vicinity with a service chain proxy node, or one to two links 756 away. The following figure depicts typical network architecture for 757 chaining those service nodes that are not aware of service layer 758 encapsulation. 760 |1 ----- |n |21 ---- |2m 761 +---+---+ +---+---+ +-+---+ +--+----+ 762 | SF1 | | SF2 | | SF3 | | SF4 | 763 +---+---+ +---+---+ +--+--+ +--+--+-+ 764 : : : : : 765 : : : : : 766 \ / \ / 767 +--------------+ +--------+ +---------+ 768 -- >| SFC | ->| Proxy |---------> | Proxy | ----> 769 | Classifier | | Node-1 | | Node-i | 770 +--------------+ +----+---+ +----+--+-+ 771 |-- | | 772 V +---> 773 +--------+ 774 | Proxy | 775 | -j |-----> 776 +--------+ 778 Various deployment options can be envisaged: 780 1. Upgrade legacy service nodes to support required SFC 781 functionalities. 783 2. Enable Proxy Service Nodes to involve these legacy nodes in 784 instantiated SFCs. 786 3. Exclude legacy service nodes from a SFC domain. 788 It is up to the responsibility of each Service Provider to decide 789 which option to deploy within its networks. 791 10.3. On Service Function Profiles (a.k.a., Contexts) 793 Service Functions may often enforce multiple differentiated policy 794 sets. These policy sets may be coarsely-grained or fine-grained. An 795 example of coarsely-grained policy sets would be an entity that 796 performs HTTP content filtering where one policy set may be 797 appropriate for child users whereas another is appropriate for adult 798 users. An example of finely-grained policy sets would be PCEF (3GPP 799 Policy Control Enforcement Function) that has a large number of 800 differentiated QoS and charging profiles that are mapped on a per- 801 subscriber basis. 803 The Service Function Chaining mechanism directly support coarsely- 804 grained differentiated policy sets and indirectly support finely- 805 grained differentiated policy sets. 807 From a Service Function Chaining perspective, each coarsely-grained 808 policy set for a Service Function will be considered as a distinct 809 logical instance of that Service Function. Consider the HTTP content 810 filtering example where one physical or virtual entity provides both 811 child and adult content filtering. The single entity is represented 812 as two distinct logical Service Functions, each with their own 813 Service Function Identifier from a chaining perspective. The two 814 (logical) Service Functions may share the same IP address or may have 815 distinct IP addresses. 817 Finely-grained policy sets, on the other hand, would unacceptably 818 explode the number of distinct Service Chains that were required with 819 an administrative domain. For this reason, Service Functions that 820 utilize finely-grained policy sets are represented as a single 821 Service Function that has its own internal classification mechanism 822 in order to determine which of its differentiated policy sets to 823 apply. Doing so avoids from increasing the size of the SFC Policy 824 Table. 826 The threshold, in terms of number of policies, between choosing the 827 coarsely-grained policy or finely-grained policy technique is left to 828 the administrative entity managing a given domain. 830 [DISCUSSION NOTE: This section will be updated to reflect the 831 conclusions of the discussions from the design analysis draft.] 833 10.4. SF Node is also a Classifier 835 If SF Nodes are also configured to behave as Classifiers, the SF Map 836 Index is not required to be explicitly signalled in each packet. 837 Concretely, the SFC Policy Table maintained by the SF Node includes 838 classification rules. These classification rules are enforced to 839 determine whether the local SF must be involved. If an incoming 840 packet matches at least one classification rule pointing to an SF Map 841 in which the SF Identifier is listed, the SF Node retrieves the next 842 hop SF from the SF Map indicated in the classification rule. 844 The packet is then handled by the local SF, and the SF Node 845 subsequently forwards the packet to the next hop SF. If not, the 846 packet is forwarded to the next hop according to a typical IP 847 forwarding policy. 849 Let us consider the example shown in Figure 2. The local SF Node 850 embeds SFa. Once classification rules and the SF Maps are checked, 851 the SF Node concludes SFa must be invoked only when a packet matches 852 Rules 1 and 3. If a packet matches Rule 1, the next SF is SFC. If a 853 packet matches Rule 3, the next SF is SFh. 855 +-----------------------------------------------+ 856 | SFC Policy Table | 857 +-----------------------------------------------+ 858 |Local SF Identifier: SFa | 859 +-----------------------------------------------+ 860 |Classification Rules | 861 | Rule 1: If DEST=IP1; then SFC_MAP_INDEX1 | 862 | Rule 2: If DEST=IP2; then SFC_MAP_INDEX2 | 863 | Rule 3: IF DEST=IP3; then SFC_MAP_INDEX3 | 864 +-----------------------------------------------+ 865 |SF Maps | 866 | SFC_MAP_INDEX1: {SFa, SFc} | 867 | SFC_MAP_INDEX2: {SFd, SFb} | 868 | SFC_MAP_INDEX3: {SFa, SFh} | 869 +-----------------------------------------------+ 871 Figure 2: SFC Policy Table Example. 873 10.5. SFs within the Same Subnet 875 SF Nodes may be enabled in a SFC-enabled domain so that each of them 876 has a direct L3 adjacency with other SF Nodes. In such 877 configuration, no encapsulation scheme is required to exchange 878 traffic between these nodes. 880 10.6. Service Function Loops 882 SF Nodes use the SFC Policy Table to detect whether the local SF was 883 already applied to the received packet (i.e., detect SF Loop). The 884 SF Node MUST invoke the local SF only if the packet is received from 885 a SFC Boundary Node or a SF Node having an identifier listed before 886 the local SF in the SF Map matched by the packet. SF Loop detection 887 SHOULD be a configurable feature. 889 Figure 3 shows an example of a SFC Policy Table of a SF Node 890 embedding SFa. Assume a packet received from Locb that matches Rule 891 2. SFa must not be invoked because SFb is listed after SFa (see the 892 SF Map list). That packet will be forwarded without invoking SFa. 894 +-----------------------------------------------+ 895 | SFC Policy Table | 896 +-----------------------------------------------+ 897 |Local SF Identifier: SFa | 898 +-----------------------------------------------+ 899 |SF Maps | 900 | SFC_MAP_INDEX1: {SFa, SFc} | 901 | SFC_MAP_INDEX2: {SFd, SFa, SFb, SFh} | 902 +-----------------------------------------------+ 903 |SFC Locators | 904 | Locator_SFb: Locb | 905 | Locator_SFC: Locc | 906 | Locator_SFd: Locd | 907 | Locator_SFh: Loch | 908 +-----------------------------------------------+ 910 Figure 3: Dealing With SF Loops. 912 10.7. Lightweight SFC Policy Table 914 If SF loop detection is not activated in an SFC-enabled domain, the 915 PDP may provision SF nodes with a "lightweight" SFC Policy Table. A 916 lightweight SFC Policy Table is a subset of the full SFC Policy 917 Table that includes: 919 o Only the SF Maps in which the local SF is involved. 920 o Only the next hop SF instead of the full SF chain. 922 An example of a lightweight SFC Policy Table is shown in Figure 4. 924 +-----------------------------------------------+ 925 | SFC Policy Table | 926 +-----------------------------------------------+ 927 |Local SF Identifier: SFa | 928 +-----------------------------------------------+ 929 |Lite SF Maps | 930 | SFC_MAP_INDEX1, Next_Hop_SF = SFc | 931 | SFC_MAP_INDEX2, Next_Hop_SF = SFb | 932 +-----------------------------------------------+ 933 |SFC Locators | 934 | Locator_SFb: Locb | 935 | Locator_SFC: Locc | 936 +-----------------------------------------------+ 938 Figure 4: Lightweight SFC Policy Table. 940 10.8. Liveness Detection Of SFs By The PDP 942 The ability of the PDP to check the liveness of each SF invoked in a 943 service chain has several advantages, including: 945 o Enhanced status reporting by the PDP (i.e., an operational status 946 for any given service chain derived from liveness state of its 947 SFs). 948 o Ability to support various resiliency policies (i.e., bypass SF 949 Node, use alternate SF Node, use alternate chain, drop traffic, 950 etc.) . 951 o Ability to support load balancing capabilities to solicit multiple 952 SF instances that provide equivalent functions. 954 In order to determine the liveness of any particular SF Node, 955 standard protocols such as ICMP or BFD (both single-hop [RFC5881] and 956 multi-hop [RFC5883]) may be utilized between the PDP and the SF 957 Nodes. 959 Because an SF Node can be responsive from a reachability standpoint 960 (e.g., IP level) while the function its provides may be broken (e.g., 961 a NAT module may be down), additional means to assess whether an SF 962 is up and running are required. These means may be service-specific 963 (e.g., [RFC6849], [I-D.tsou-softwire-bfd-ds-lite]). 965 For more sophisticated load-balancing support, protocols that allow 966 for both liveness determination and the transfer of application- 967 specific data, such as SNMP and NETCONF may be utilized between the 968 PDP and the SF Nodes. 970 11. IANA Considerations 972 This document does not require any IANA actions. 974 12. Security Considerations 976 Means to protect SFC Boundary Nodes and SF Nodes against various 977 forms of DDoS attacks MUST be supported. For example, mutual PDP and 978 SF node authentication should be supported. Means to protect SF 979 nodes against malformed, poorly configured (deliberately or not) SFC 980 Policy Tables should be supported. 982 SFC Boundary Nodes MUST strip any existing SF Map Index when handling 983 an incoming packet. A list of authorized SF Map Indexes are 984 configured in the SFC elements. 986 NETCONF-related security considerations are discussed in [RFC6146]. 988 Means to prevent SF loops should be supported. 990 Nodes involved in the same SFC-enabled domain MUST be provisioned 991 with the same SFC Policy Table. Possible table inconsistencies may 992 result in forwarding errors. 994 13. Contributors 996 The following individuals contributed to the document: 998 Parviz Yegani 999 Juniper Networks 1000 1194 N. Mathilda Ave. 1001 Sunnyvale, CA 94089 1002 USA 1003 Email: pyegani@juniper.net 1005 Paul Quinn 1006 Cisco Systems, Inc. 1007 USA 1008 Email: paulq@cisco.com 1010 Linda Dunbar 1011 Huawei Technologies 1012 1700 Alma Drive, Suite 500 1013 Plano, TX 75075, USA 1014 Phone: (469) 277 5840 1015 Email: ldunbar@huawei.com 1017 14. Acknowledgments 1019 Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. Cheng, R. 1020 White, and B. Chatras for their review and comments. 1022 15. References 1024 15.1. Normative References 1026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1027 Requirement Levels", BCP 14, RFC 2119, March 1997. 1029 15.2. Informative References 1031 [I-D.boucadair-sfc-design-analysis] 1032 Boucadair, M., Jacquenet, C., Parker, R., and L. Dunbar, 1033 "Service Function Chaining: Design Considerations, 1034 Analysis & Recommendations", draft-boucadair-sfc-design- 1035 analysis-01 (work in progress), November 2013. 1037 [I-D.boucadair-sfc-requirements] 1038 Boucadair, M., Jacquenet, C., Jiang, Y., Parker, R., 1039 Pignataro, C., and K. Kengo, "Requirements for Service 1040 Function Chaining", draft-boucadair-sfc-requirements-03 1041 (work in progress), February 2014. 1043 [I-D.ietf-sfc-problem-statement] 1044 Quinn, P. and T. Nadeau, "Service Function Chaining 1045 Problem Statement", draft-ietf-sfc-problem-statement-00 1046 (work in progress), January 2014. 1048 [I-D.sin-sdnrg-sdn-approach] 1049 Boucadair, M. and C. Jacquenet, "Software-Defined 1050 Networking: A Perspective From Within A Service Provider", 1051 draft-sin-sdnrg-sdn-approach-09 (work in progress), 1052 January 2014. 1054 [I-D.tsou-softwire-bfd-ds-lite] 1055 Tsou, T., Li, B., Zhou, C., Schoenwaelder, J., Penno, R., 1056 and M. Boucadair, "DS-Lite Failure Detection and 1057 Failover", draft-tsou-softwire-bfd-ds-lite-05 (work in 1058 progress), June 2013. 1060 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1061 "Definition of the Differentiated Services Field (DS 1062 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1063 1998. 1065 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1066 and W. Weiss, "An Architecture for Differentiated 1067 Services", RFC 2475, December 1998. 1069 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 1070 for Policy-based Admission Control", RFC 2753, January 1071 2000. 1073 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 1074 2983, October 2000. 1076 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1077 Address Translator (Traditional NAT)", RFC 3022, January 1078 2001. 1080 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1081 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 1082 2010. 1084 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1085 (BFD) for Multihop Paths", RFC 5883, June 2010. 1087 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 1088 Notification", RFC 6040, November 2010. 1090 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1091 Customer Premises Equipment (CPE) for Providing 1092 Residential IPv6 Internet Service", RFC 6092, January 1093 2011. 1095 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1096 NAT64: Network Address and Protocol Translation from IPv6 1097 Clients to IPv4 Servers", RFC 6146, April 2011. 1099 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1100 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1101 6241, June 2011. 1103 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1104 Translation", RFC 6296, June 2011. 1106 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1107 Stack Lite Broadband Deployments Following IPv4 1108 Exhaustion", RFC 6333, August 2011. 1110 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 1111 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1112 Partnership Project (3GPP) Evolved Packet System (EPS)", 1113 RFC 6459, January 2012. 1115 [RFC6849] Kaplan, H., Hedayat, K., Venna, N., Jones, P., and N. 1116 Stratton, "An Extension to the Session Description 1117 Protocol (SDP) and Real-time Transport Protocol (RTP) for 1118 Media Loopback", RFC 6849, February 2013. 1120 Authors' Addresses 1122 Mohamed Boucadair 1123 France Telecom 1124 Rennes 35000 1125 France 1127 EMail: mohamed.boucadair@orange.com 1128 Christian Jacquenet 1129 France Telecom 1130 Rennes 35000 1131 France 1133 EMail: christian.jacquenet@orange.com 1135 Ron Parker 1136 Affirmed Networks 1137 Acton, MA 1138 USA 1140 EMail: Ron_Parker@affirmednetworks.com 1142 Diego R. Lopez 1143 Telefonica I+D 1144 Don Ramon de la Cruz, 82 1145 Madrid 28006 1146 Spain 1148 Phone: +34 913 129 041 1149 EMail: diego@tid.es 1151 Jim Guichard 1152 Cisco Systems, Inc. 1153 USA 1155 EMail: jguichar@cisco.com 1157 Carlos Pignataro 1158 Cisco Systems, Inc. 1159 USA 1161 EMail: cpignata@cisco.com