idnits 2.17.1 draft-boucadair-sfc-framework-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 3830 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 (-06) exists of draft-boucadair-sfc-requirements-00 == Outdated reference: A later version (-09) exists of draft-sin-sdnrg-sdn-approach-03 == Outdated reference: A later version (-06) exists of draft-tsou-softwire-bfd-ds-lite-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track France Telecom 5 Expires: April 06, 2014 R. Parker 6 Affirmed Networks 7 D. Lopez 8 Telefonica I+D 9 J. Guichard 10 C. Pignataro 11 Cisco Systems, Inc. 12 October 03, 2013 14 Service Function Chaining: Framework & Architecture 15 draft-boucadair-sfc-framework-00 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 framework to enforce Service Function Chaining (SFC) with minimum 23 requirements on the physical topology of the network. 25 The proposed framework allows for differentiated forwarding: packets 26 are initially classified and marked at the entry point of an SFC- 27 enabled domain, and are then forwarded on a per SF Map Index basis. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 06, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. On the Proliferation of Service Functions . . . . . . . . 3 70 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.3. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3. Functional Elements . . . . . . . . . . . . . . . . . . . . . 7 76 4. SFC Provisioning . . . . . . . . . . . . . . . . . . . . . . 7 77 4.1. Assign Service Function Identifiers . . . . . . . . . . . 7 78 4.2. Service Function Locator . . . . . . . . . . . . . . . . 8 79 4.3. Service Function Discovery . . . . . . . . . . . . . . . 8 80 4.4. Building Service Function Maps . . . . . . . . . . . . . 8 81 4.5. Building Service Function Chaining (SFC) Policy Tables . 9 82 5. Theory Of Operation . . . . . . . . . . . . . . . . . . . . . 11 83 5.1. SFC Boundary Node . . . . . . . . . . . . . . . . . . . . 11 84 5.2. SFC Classifier . . . . . . . . . . . . . . . . . . . . . 11 85 5.3. SFC Ingress Node . . . . . . . . . . . . . . . . . . . . 11 86 5.4. SFC Egress Node . . . . . . . . . . . . . . . . . . . . . 12 87 5.5. SF Node . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 5.6. Intermediate Nodes . . . . . . . . . . . . . . . . . . . 13 89 6. Fragmentation Considerations . . . . . . . . . . . . . . . . 13 90 7. Differentiated Services . . . . . . . . . . . . . . . . . . . 13 91 8. ECN (Explicit Congestion Notification) Considerations . . . . 14 92 9. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 93 9.1. Transmit A SFC Map Index In A Packet . . . . . . . . . . 14 94 9.1.1. SFC Map Index . . . . . . . . . . . . . . . . . . . . 14 95 9.1.2. Why Not Loose Or Strict Source Routing (SSR)? . . . . 14 96 9.1.3. Where To Store SFC Map Indexes In A Packet? . . . . . 15 98 9.2. Steer Paths To Cross Specific SF Nodes . . . . . . . . . 15 99 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 100 10.1. Generic Requirements . . . . . . . . . . . . . . . . . . 15 101 10.2. Deployment Models . . . . . . . . . . . . . . . . . . . 15 102 10.3. On Service Function Profiles (a.k.a., Contexts) . . . . 16 103 10.4. SF Node is also a Classifier . . . . . . . . . . . . . . 17 104 10.5. SFs within the Same Subnet . . . . . . . . . . . . . . . 18 105 10.6. Service Function Loops . . . . . . . . . . . . . . . . . 18 106 10.7. Lightweight SFC Policy Table . . . . . . . . . . . . . . 19 107 10.8. Liveness Detection Of SFs By The PDP . . . . . . . . . 19 108 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 109 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 110 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 111 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 112 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 113 15.1. Normative References . . . . . . . . . . . . . . . . . . 21 114 15.2. Informative References . . . . . . . . . . . . . . . . . 21 116 1. Introduction 118 1.1. On the Proliferation of Service Functions 120 IP networks rely more and more on the combination of advanced 121 functions (besides the basic routing and forwarding functions) for 122 the delivery of added value services. Typical examples of such 123 functions include firewall (e.g., [RFC6092]), DPI (Deep Packet 124 Inspection), LI (Lawful Intercept) module, NAT44 [RFC3022], NAT64 125 [RFC6146], DS-Lite AFTR [RFC6333], NPTv6 [RFC6296], HOST_ID 126 injection, HTTP Header Enrichment function, TCP tweaking and 127 optimization functions, transparent caching, charging function, load- 128 balancer, etc. 130 Such advanced functions are denoted SF (Service Function) in this 131 document. 133 The dynamic enforcement of a SF-derived, adequate forwarding policy 134 for packets entering a network that supports such advanced Service 135 Functions has become a key challenge for operators and service 136 providers. SF-inferred differentiated forwarding is ensured by 137 tweaking the set of Service Functions to be invoked. How to bind a 138 flow of packets that share at least one common characteristic to a 139 forwarding plane is policy-based, and subject to the set of SF 140 functions that need to be solicited for the processing of this 141 specific flow. 143 The overall problem space is described in 144 [I-D.quinn-nsc-problem-statement]. A companion document that lists 145 preliminary requirements is available at 146 [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. 223 o No IANA registry is required to store the SF chaining candidates. 224 o No specific SF chaining is assumed. The description of SF chains 225 is an information that will be processed by the nodes that 226 participate to the delivery of a network service. The set of 227 listed/chained SF functions is generated by each administrative 228 entity operating the network. 229 o SF handling is policy-based: SF chains can be updated or deleted, 230 new SFs can be added without any impact on existing SFs, etc. In 231 particular, this design is compliant with the global framework 232 discussed in [I-D.sin-sdnrg-sdn-approach]. 233 o For the sake of efficiency, policy enforcement is automated (but 234 policies can be statically enforced, for example). 235 o To minimize fragmentation, a minimal set of information needs to 236 be signaled (possibly in data packets). 237 o Advanced features (e.g., load balancing) are also described and 238 may be configured according to policies that can be service- 239 specific. Policy decisions are made by a Policy Decision Point 240 [RFC2753] and the solicited enforcement points are responsible for 241 applying these decisions, whatever the objective to achieve. 242 o SFs can be embedded in nodes that intervene in the transport 243 service or supported by dedicated nodes (e.g., dedicated servers). 244 The decision to implement one of these two models (or a 245 combination thereof) is deployment-specific and it is orthogonal 246 to the overall procedure. 247 o Multiple SFC-enabled domains can be deployed within the same 248 administrative domain. Nodes are provisioned with the policy 249 table of the SFC-enabled domain they belong to. 250 o The overall consistency of the differentiated forwarding policy is 251 ensured by the PDP. 252 o The PDP can be responsible to enforce other policies than those 253 described in the SFC Policy Tables. 255 2. Terminology 257 This document makes use of the following terms: 259 o SF (Service Function): refers to a function which is enabled in 260 the network operated by an administrative entity. One or many 261 Service Functions can be involved in the delivery of added-value 262 services. A non-exhaustive list of Service Functions include: 263 firewall (e.g., [RFC6092]), DPI (Deep Packet Inspection), LI 264 (Lawful Intercept) module, NAT44 [RFC3022], NAT64 [RFC6146], DS- 265 Lite AFTR [RFC6333], NPTv6 [RFC6296], HOST_ID injection, HTTP 266 Header Enrichment function, TCP optimizer, load-balancer, etc. 267 This document does not make any assumption in the OSI Layer on 268 which the Service Function acts on; the exact definition of each 269 Service Function is deployment-specific. 271 o SFC-enabled domain: denotes a network (or a region thereof) that 272 implements SFC. 274 o SF Identifier: is a unique identifier that unambiguously 275 identifies a SF within a SFC-enabled domain. SF Identifiers are 276 assigned, configured and managed by the administrative entity that 277 operates the SFC-enabled domain. SF identifiers can be structured 278 as strings; other formats can be used. SF Identifiers are not 279 required to be globally unique nor be exposed to or used by 280 another SF-enabled domain. 282 o SF Map: refers to an ordered list of SF identifiers. Each SF Map 283 is identified with a unique identifier called SF Map Index. 285 o SFC Policy Table: is a table containing a list of SF Maps, SFC 286 classification rules and Locators for all SF Nodes. A SFC Policy 287 Table may contain a default SF Map. 289 o SF Locator: A SF Node identifier used to reach the said SF node. 290 A locator is typically an IP address or a FQDN. 292 o Legacy Node (Node for short): refers to any node that is not a SF 293 Node nor a SFC Boundary Node. This node can be located within a 294 SFC-enabled domain or outside a SFC-enabled domain. 296 3. Functional Elements 298 The following functional elements are defined in this document: 300 o SFC Boundary Node (or Boundary Node): denotes a node that connects 301 one SFC-enabled domain to a node either located in another SFC- 302 enabled domain or in a domain that is SFC-unaware. 304 o SFC Egress Node (or Egress Node): denotes a SFC Boundary Node that 305 handles traffic which leaves the SFC-enabled domain the Egress 306 Node belongs to. 308 o SFC Ingress Node (or Ingress Node): denotes a SFC Boundary Node 309 that handles traffic which enters the SFC-enabled domain the 310 ingress Node belongs to. 312 o SF Node: denotes any node within an SFC-enabled domain that embeds 313 one or multiple SFs. 315 o SFC Classifier (or Classifier): an entity which classifies packets 316 based on the packet header contents according to classification 317 rules defined in a SFC Policy Table. Packets are then marked with 318 the corresponding SF Map Index. SFC Classifier is embedded in a 319 SFC Boundary Node. A SFC Classifier may be identified by a 320 dedicated SF Identifier. 322 4. SFC Provisioning 324 4.1. Assign Service Function Identifiers 326 The administrative entity that operates a SFC-enabled domain 327 maintains a local repository that lists the enabled SFs. This 328 administrative entity assigns a unique SF identifier for each SF 329 type. 331 SF identifiers are structured as character strings. The main 332 constraint on the format is that two SFs MUST be assigned with 333 different SF identifiers if they do not provide the exact same 334 function, or do provide the same function but are unable to 335 differentiation packets based on policies provisioned to the SF using 336 an appropriate mechanism. SF identifiers are case-sensitive. 338 4.2. Service Function Locator 340 A SF may be embedded in one or several SF Nodes. The SF locator is 341 typically the IP address or the FQDN to reach a given SF Node. 343 The use of an IP address is RECOMMENDED to avoid any extra complexity 344 related to the support of name resolution capabilities in SF Nodes. 345 Resolution capabilities are supported by the PDP (Policy Decision 346 Point). In the rest of the document, we assume a SF locator is 347 structured as an IP address (IPv4 or IPv6). 349 A SF Node can be reached by one or more locators, which may therefore 350 be bound to the same SF. 352 4.3. Service Function Discovery 354 The local repository that lists the enabled SFs within an SFC-enabled 355 domain may be built as a direct input from the administrative entity, 356 or they may be discovered dynamically through appropriate protocol 357 discovery means. 359 Whichever method is selected by the administrative entity is a local 360 decision and is therefore outside the scope of this document. 362 4.4. Building Service Function Maps 364 Added-value services delivered to the end-user rely on the invocation 365 of several SFs. For each of these services, the administrative 366 entity that operates an SFC-enabled domain builds one or several SF 367 Maps. Each of these maps characterizes the list of SFs to be invoked 368 with their exact invocation order. 370 Each SF Map is unambiguously identified with a unique identifier 371 called the SF Map Index. The SF Map Index MUST be described as an 372 unsigned integer. 374 Distinct chains can be applied for inbound and outbound traffic. The 375 directionality of traffic is not included as an attribute of the SF 376 Map, but it may be implicitly described by using two SF Maps 377 installed and maintained in the SFC Policy Table. In such case, 378 incoming packets would be marked with Index_1 for example, while 379 outgoing packets would be forwarded according to a distinct SF Map 380 identified with Index_2. 382 An example of SF Map to handle IPv6 traffic destined to an IPv4 383 remote server is defined as follows: 385 {15, {IPv6_Firewall, HOST_ID_Inject, NAT64}}. 387 To handle incoming packets destined to the same IPv6 host, the 388 following SF Map can be defined: 390 {10, {IPv4_Firewall, NAT64}}. 392 4.5. Building Service Function Chaining (SFC) Policy Tables 394 A PDP (Policy Decision Point, [RFC2753]) is the central entity which 395 is responsible for maintaining SFC Policy Tables (Figure 1), and 396 enforcing appropriate policies in SF Nodes and SFC Boundary Nodes 397 (Figure 1). PDP-made decisions can be forwarded to the participating 398 nodes by using a variety of protocols (e.g., NETCONF [RFC6241]). 400 One or multiple SFC-enabled domains may be under the responsibility 401 of the same PDP. Delimiting the scope of each SFC-enabled domain is 402 under the responsibility of the administrative entity that operates 403 the SF-enabled network. 405 o . . . . . . . . . . . . . . . . . . . . . . . o 406 . SFC Policy Enforcement . 407 . +-------+ . 408 . | |-----------------+ . 409 . +-------| PDP | | . 410 . | | |-------+ | . 411 . | +-------+ | | . 412 o . . | . . . . . | . . . . . | . . . . | . . . o 413 o . . | . . . . . | . . . . . | . . . . | . . . o 414 . | | | | . 415 . v v v v . 416 . +---------+ +---------+ +-------+ +-------+ . 417 . |SFC_BN_1 | |SFC_BN_n | | SF_1 | | SF_m | . 418 . +---------+ +---------+ +-------+ +-------+ . 419 . SFC-enabled Domain . 420 o . . . . . . . . . . . . . . . . . . . . . . . o 422 Figure 1: SFC Policy Enforcement Scheme. 424 The SF Node MUST be provisioned with the following information: 426 o Local SF Identifier(s): This information is required for an SF to 427 identify itself within an SF Map. 429 o List of SF Maps: The PDP may configure the full list (default 430 mode) or only as subset of SF Maps in which SF(s) supported by the 431 SF Node is involved (see Section 10.7). 432 o List of SF Locators: The PDP may configure the full list of 433 locators (default mode) or only the locators of next hop SFs of SF 434 Maps in which SF(s) supported by the local SF node is involved 435 (see Section 10.7). 437 [DISCUSSION NOTE: Discuss if we maintain both forms of the SFC 438 Policy table (full and lite) or select only one of them.] 440 Likewise, the SFC Boundary Node MUST be provisioned with the 441 following information: 443 o List of SF Maps 444 o List of SF Locators 445 o List of SF Map Classification Rules (see Section 5.2). 447 In addition to the SFC Policy Table, other SF-specific policies can 448 be installed by the PDP (e.g., configure distinct user profiles, 449 activate specific traffic filters, configure traffic conditioners, 450 etc.). 452 Policies managed by the PDP may be statically instantiated or 453 dynamically triggered by external means (e.g., a AAA server). 455 In the event of any update (e.g., define a new SF Map, delete an SF 456 Map, add a new SF Locator, update classification policy), the PDP 457 MUST forward the updated policy configuration information in all 458 relevant SF Nodes and SFC Boundary Nodes. 460 Distributing the load among several SF Nodes supporting the same SF 461 can be driven by the PDP. Indeed, the PDP can generate multiple 462 classification rules and SF Maps to meet some load-balancing 463 objectives. 465 Load balancing may also be achieved locally by an SF Node. If the SF 466 Node, SF Classifier, or SF Boundary Node has a table that provides 467 the SF locator(s) of SF Nodes that provide a particular SF then it is 468 possible to make that local load balancing decision. 470 The processing of packets by the nodes that belong to a SFC-enabled 471 domain does not necessarily require any interaction with the PDP, 472 depending on the nature of the SF supported by the nodes and the 473 corresponding policies to be enforced. For example, traffic 474 conditioning capabilities [RFC2475] are typical SF functions that may 475 require additional solicitation of the PDP for the SF node to decide 476 what to do with some out-of-profile traffic. 478 5. Theory Of Operation 480 The behavior of each node of a SFC-enabled domain is specified in the 481 following sections. We assume that the provisioning operations 482 discussed in Section 4 have been successful (i.e., SF functions have 483 been adequately configured according to the (service-specific) policy 484 to be enforced). 486 5.1. SFC Boundary Node 488 SFC Boundary Nodes act both as a SFC Ingress Node and as a SFC Egress 489 Node for the respective directions of the traffic. 491 Traffic enters a SFC-enabled domain at a SFC Ingress Node 492 (Section 5.3) and exits the domain at a SFC Egress Node 493 (Section 5.4). 495 5.2. SFC Classifier 497 The SFC Classifier classifies packets based on (some of) the contents 498 of the packet header. Concretely, it classifies packets based on the 499 possible combination of one or more header fields, such as source 500 address, destination address, DS field, protocol ID, source port and 501 destination port numbers, and any other information. 503 Each SF Map Classification Rule MUST be bound to one single SF Map 504 (i.e., the classification rule must include only one SF Map Index). 506 5.3. SFC Ingress Node 508 When a packet is received through an interface of the SFC Ingress 509 Node that connects to the outside of the SFC domain, the Ingress Node 510 MUST: 512 o Inspect the received packet and check whether any existing SF Map 513 Index is included in the packet. 515 * The SFC Ingress Node SHOULD be configurable with a parameter to 516 indicate whether received SF Map Index is to be preserved or 517 striped. The default behavior is to strip any received SF Map 518 Index. 519 * Unless explicitly configured to trust SF Map index, The SFC 520 Ingress Node MUST strip any existing SF Map Index if the packet 521 is received from an SFC-enabled domain that has not explicitly 522 been designated as "trusted". 523 o Check whether the received packet matches an existing 524 classification rule (see Section 5.2). 526 o If no rule matches, forward the packet to the next hop according 527 to legacy forwarding behavior (e.g., based upon the IP address 528 conveyed in the DA field of the header). 529 o If a rule matches, proceed with the following operations: 531 * Retrieve the locator of the first SF as indicated in the SF Map 532 entry the rule matches. 533 * Check whether the corresponding SF node is an immediate (L3) 534 neighbor. 536 + If so, update the packet with the SF Map Index of SF Map 537 entry it matches and then forward the packet to the 538 corresponding SF Node. 539 + If not, (1) encapsulate the original packet into a new one 540 that will be forwarded to the corresponding SF node, (2) 541 update the encapsulated packet with the SF Map Index of SF 542 Map entry it matches, and (3) forward the packet to the next 543 hop to reach the first SF node. 545 As a result of this process, the packet will be sent to an SF Node or 546 an Intermediate Node. 548 5.4. SFC Egress Node 550 When a packet is received through an interface that connects the SFC 551 Egress Node to its SFC domain, the Egress Node MUST: 553 o Strip any existing SF Map Index. 554 o Forward the packet according to legacy forwarding policies. 556 5.5. SF Node 558 This section assumes the default behavior is each SF Node does not 559 embed a Classifier as discussed in Section 10.4. 561 When a packet is received by a SF Node, the SF Node MUST: 563 o Check whether the packet conveys a SF Map Index. 564 o If no SF Map Index is included, forward the packet according to 565 legacy forwarding policies. 566 o If the packet conveys a SF Map Index, 568 * Retrieve the corresponding SF Map from the SFC Policy Table. 569 If no entry is found in the table, forward the packet according 570 to legacy forwarding policies. 572 [DISCUSSION NOTE: Another design choice is to drop the 573 packet and send a notification to the PDP. The 574 justification for avoiding to drop the packet is that an SF 575 can be part of the forwarding path of an SFC to which it 576 does not belong to.] 577 * If an entry is found in the SFC Policy Table, check whether the 578 local SF Identifier is present in the SF Map: 580 + If not, forward the packet according to legacy forwarding 581 policies. 583 [DISCUSSION NOTE: One would argue the packet should be 584 dropped. The justification for avoiding to drop the 585 packet is that an SF can be part of the forwarding path 586 of an SFC to which it does not belong to + the SF node is 587 provisioned with the full SFC Policy Table.] 588 + If so, the packet is decapsulated (if needed) and then 589 presented as an input to the local SF. In case several SFs 590 are co-located in the same node, the packet is processed by 591 all SFs indicated in the SF Map. Once the packet is 592 successfully handled by local SF(s), the packet is forwarded 593 to the next SF Node in the list or to an intermediate node 594 (if the local SF Node is the last element in the SF Map). 595 If the local SF node is not the last one in the SF Map, it 596 retrieves the next SF Node from the list, retrieve its 597 locator for the SFC Policy Table, and forwards the packet to 598 the next hop. If the local SF Node is the last element in 599 the SF Map, it forwards the packet to the next hop according 600 to legacy forwarding policies. 602 5.6. Intermediate Nodes 604 An Intermediate Node is any node that does not support any Service 605 Function and which is located within a SFC-enabled domain. 607 No modification is required to intermediate nodes to handle incoming 608 packets. In particular, routing and forwarding are achieved using 609 legacy procedures. 611 6. Fragmentation Considerations 613 If adding the Service Chaining Header would result in a fragmented 614 packet, the classifier should include a Service Chaining Header in 615 each fragment. Doing so would prevent SF Nodes to dedicate resource 616 to handle fragments. 618 7. Differentiated Services 619 When encapsulating an IP packet, the Ingress Node and each SF Node 620 SHOULD use its Diffserv Codepoint (DSCP, [RFC2474]) to derive the 621 DSCP (or MPLS Traffic-Class Field) of the encapsulated packet. 623 Generic considerations related to Differentiated Services and tunnels 624 are further detailed in [RFC2983]. 626 8. ECN (Explicit Congestion Notification) Considerations 628 When encapsulating an IP packet, the Ingress Node and each SF Node 629 SHOULD follow [RFC6040] for ECN re-marking purposes. 631 9. Design Considerations 633 This section discusses two main protocol issues to be handled in 634 order to deploy SFC. 636 A detailed design analysis is documented in [I-D.boucadair-sfc- 637 design-analysis]. 639 9.1. Transmit A SFC Map Index In A Packet 641 9.1.1. SFC Map Index 643 A SF Map Index is an integer that points to a SF Map. 645 In order to avoid all nodes of a SFC-enabled domain to be SF-aware, 646 this specification recommends to undertake classifiers at boundary 647 nodes while intermediate nodes forward the packets according to the 648 SF Map Index conveyed in the packet (SF Node) or according to typical 649 forwarding policies (any SF-unaware node). 651 An 8-bit field would be sufficient to accommodate deployment contexts 652 that assume a reasonable set of SF Maps. A 16-bit (or 32-bit) field 653 would be more flexible (e.g., to accommodate the requirement 654 discussed in Section 10.3). 656 9.1.2. Why Not Loose Or Strict Source Routing (SSR)? 658 Instead of injecting a Map Index, an alternate solution would be to 659 use the SSRR/LSRR IPv4 option or any similar solution to indicate a 660 loose or strict explicit route. This alternative was not considered 661 because of the likely dramatic impact on the processing and potential 662 fragmentation issues that may jeopardize the overall performance of 663 the SFC operation. 665 Injecting an 8-bit or a 16-bit field would minimize fragmentation 666 issues. 668 9.1.3. Where To Store SFC Map Indexes In A Packet? 670 SF Map Indexes can be conveyed in various locations of a packet: 672 o At L2 level 673 o Define a new IP option or a new IPv6 extension header 674 o Use IPv6 Flow Label 675 o Re-use an existing field (e.g., DS field) 676 o TCP option 677 o GRE Key 678 o Define a new shim 679 o Etc. 681 9.2. Steer Paths To Cross Specific SF Nodes 683 A SFC Ingress Node or a SF Node MUST be able to forward a packet that 684 matches an existing SF Map to the relevant next hop SF Node. The 685 locator of the next SF is retrieved from the SFC Policy Table. In 686 case the next SF Node in the list is not an immediate (L3) neighbor, 687 a solution to force the packet to cross that SF Node MUST be 688 supported. This document suggests the use of the IP-in-IP 689 encapsulation scheme. Other tunneling solutions can be considered in 690 the future. 692 10. Deployment Considerations 694 10.1. Generic Requirements 696 The following deployment considerations should be taken into account: 698 o Avoid inducing severe path stretch compared to the path followed 699 if no SF is involved. 700 o Minimize path computation delays: due to the enforcement of 701 classification rules in all participating nodes, misconception of 702 Service function chaining, inappropriate choice of nodes elected 703 to embed Service functions, etc., must be avoided. 704 o Avoid SF invocation loops: the design of SF chainings should 705 minimize as much as possible SF invocation loops. 707 10.2. Deployment Models 709 Below are listed some deployment model examples: 711 1. A full marking mechanism: Ingress nodes perform the 712 classification and marking functions. Then, involved SF Nodes 713 process received packets according to their marking. 715 2. SF node mechanism, in which every SF Node embeds also a 716 classifier, and the ingress node only decides the first node to 717 forward to. Packets are forwarded at each node according to 718 local policies. No marking is required when all SFs are co- 719 located with a classifier. This model suffers from some 720 limitations (see Section 10.4). 722 3. A router-based mechanism: All SF Nodes forward packets once 723 processed to their default router. This default routes is 724 responsible for deciding how the packet should be progressed at 725 each step in the chain. One or multiple routers can be involved 726 in the same Service Function Chain. 728 4. A combination thereof. 730 10.3. On Service Function Profiles (a.k.a., Contexts) 732 Service Functions may often enforce multiple differentiated policy 733 sets. These policy sets may be coarsely-grained or fine-grained. An 734 example of coarsely-grained policy sets would be an entity that 735 performs HTTP content filtering where one policy set may be 736 appropriate for child users whereas another is appropriate for adult 737 users. An example of finely-grained policy sets would be PCEF (3GPP 738 Policy Control Enforcement Function) that has a large number of 739 differentiated QoS and charging profiles that are mapped on a per- 740 subscriber basis. 742 The Service Function Chaining mechanism directly support coarsely- 743 grained differentiated policy sets and indirectly support finely- 744 grained differentiated policy sets. 746 From a Service Function Chaining perspective, each coarsely-grained 747 policy set for a Service Function will be considered as a distinct 748 logical instance of that Service Function. Consider the HTTP content 749 filtering example where one physical or virtual entity provides both 750 child and adult content filtering. The single entity is represented 751 as two distinct logical Service Functions, each with their own 752 Service Function Identifier from a chaining perspective. The two 753 (logical) Service Functions may share the same IP address or may have 754 distinct IP addresses. 756 Finely-grained policy sets, on the other hand, would unacceptably 757 explode the number of distinct Service Chains that were required with 758 an administrative domain. For this reason, Service Functions that 759 utilize finely-grained policy sets are represented as a single 760 Service Function that has its own internal classification mechanism 761 in order to determine which of its differentiated policy sets to 762 apply. Doing so avoids from increasing the size of the SFC Policy 763 Table. 765 The threshold, in terms of number of policies, between choosing the 766 coarsely-grained policy or finely-grained policy technique is left to 767 the administrative entity managing a given domain. 769 [DISCUSSION NOTE: This section will be updated to reflect the 770 conclusions of the discussions from the design analysis draft.] 772 10.4. SF Node is also a Classifier 774 If SF Nodes are also configured to behave as Classifiers, the SF Map 775 Index is not required to be explicitly signalled in each packet. 776 Concretely, the SFC Policy Table maintained by the SF Node includes 777 classification rules. These classification rules are enforced to 778 determine whether the local SF must be involved. If an incoming 779 packet matches at least one classification rule pointing to an SF Map 780 in which the SF Identifier is listed, the SF Node retrieves the next 781 hop SF from the SF Map indicated in the classification rule. 783 The packet is then handled by the local SF, and the SF Node 784 subsequently forwards the packet to the next hop SF. If not, the 785 packet is forwarded to the next hop according to a typical IP 786 forwarding policy. 788 Let us consider the example shown in Figure 2. The local SF Node 789 embeds SFa. Once classification rules and the SF Maps are checked, 790 the SF Node concludes SFa must be invoked only when a packet matches 791 Rules 1 and 3. If a packet matches Rule 1, the next SF is SFC. If a 792 packet matches Rule 3, the next SF is SFh. 794 +-----------------------------------------------+ 795 | SFC Policy Table | 796 +-----------------------------------------------+ 797 |Local SF Identifier: SFa | 798 +-----------------------------------------------+ 799 |Classification Rules | 800 | Rule 1: If DEST=IP1; then SFC_MAP_INDEX1 | 801 | Rule 2: If DEST=IP2; then SFC_MAP_INDEX2 | 802 | Rule 3: IF DEST=IP3; then SFC_MAP_INDEX3 | 803 +-----------------------------------------------+ 804 |SF Maps | 805 | SFC_MAP_INDEX1: {SFa, SFc} | 806 | SFC_MAP_INDEX2: {SFd, SFb} | 807 | SFC_MAP_INDEX3: {SFa, SFh} | 808 +-----------------------------------------------+ 810 Figure 2: SFC Policy Table Example. 812 10.5. SFs within the Same Subnet 814 SF Nodes may be enabled in a SFC-enabled domain so that each of them 815 has a direct L3 adjacency with other SF Nodes. In such 816 configuration, no encapsulation scheme is required to exchange 817 traffic between these nodes. 819 10.6. Service Function Loops 821 SF Nodes use the SFC Policy Table to detect whether the local SF was 822 already applied to the received packet (i.e., detect SF Loop). The 823 SF Node MUST invoke the local SF only if the packet is received from 824 a SFC Boundary Node or a SF Node having an identifier listed before 825 the local SF in the SF Map matched by the packet. SF Loop detection 826 SHOULD be a configurable feature. 828 Figure 3 shows an example of a SFC Policy Table of a SF Node 829 embedding SFa. Assume a packet received from Locb that matches Rule 830 2. SFa must not be invoked because SFb is listed after SFa (see the 831 SF Map list). That packet will be forwarded without invoking SFa. 833 +-----------------------------------------------+ 834 | SFC Policy Table | 835 +-----------------------------------------------+ 836 |Local SF Identifier: SFa | 837 +-----------------------------------------------+ 838 |SF Maps | 839 | SFC_MAP_INDEX1: {SFa, SFc} | 840 | SFC_MAP_INDEX2: {SFd, SFa, SFb, SFh} | 841 +-----------------------------------------------+ 842 |SFC Locators | 843 | Locator_SFb: Locb | 844 | Locator_SFC: Locc | 845 | Locator_SFd: Locd | 846 | Locator_SFh: Loch | 847 +-----------------------------------------------+ 849 Figure 3: Dealing With SF Loops. 851 10.7. Lightweight SFC Policy Table 853 If SF loop detection is not activated in an SFC-enabled domain, the 854 PDP may provision SF nodes with a "lightweight" SFC Policy Table. A 855 lightweight SFC Policy Table is a subset of the full SFC Policy Table 856 that includes: 858 o Only the SF Maps in which the local SF is involved. 859 o Only the next hop SF instead of the full SF chain. 861 An example of a lightweight SFC Policy Table is shown in Figure 4. 863 +-----------------------------------------------+ 864 | SFC Policy Table | 865 +-----------------------------------------------+ 866 |Local SF Identifier: SFa | 867 +-----------------------------------------------+ 868 |Lite SF Maps | 869 | SFC_MAP_INDEX1, Next_Hop_SF = SFc | 870 | SFC_MAP_INDEX2, Next_Hop_SF = SFb | 871 +-----------------------------------------------+ 872 |SFC Locators | 873 | Locator_SFb: Locb | 874 | Locator_SFC: Locc | 875 +-----------------------------------------------+ 877 Figure 4: Lightweight SFC Policy Table. 879 10.8. Liveness Detection Of SFs By The PDP 881 The ability of the PDP to check the liveness of each SF invoked in a 882 service chain has several advantages, including: 884 o Enhanced status reporting by the PDP (i.e., an operational status 885 for any given service chain derived from liveness state of its 886 SFs). 887 o Ability to support various resiliency policies (i.e., bypass SF 888 Node, use alternate SF Node, use alternate chain, drop traffic, 889 etc.) . 890 o Ability to support load balancing capabilities to solicit multiple 891 SF instances that provide equivalent functions. 893 In order to determine the liveness of any particular SF Node, 894 standard protocols such as ICMP or BFD (both single-hop [RFC5881] and 895 multi-hop [RFC5883]) may be utilized between the PDP and the SF 896 Nodes. 898 Because an SF Node can be responsive from a reachability standpoint 899 (e.g., IP level) while the function its provides may be broken (e.g., 900 a NAT module may be down), additional means to assess whether an SF 901 is up and running are required. These means may be service-specific 902 (e.g., [RFC6849], [I-D.tsou-softwire-bfd-ds-lite]). 904 For more sophisticated load-balancing support, protocols that allow 905 for both liveness determination and the transfer of application- 906 specific data, such as SNMP and NETCONF may be utilized between the 907 PDP and the SF Nodes. 909 11. IANA Considerations 911 Required IANA actions will be discussed in future versions of the 912 document. 914 12. Security Considerations 916 Means to protect SFC Boundary Nodes and SF Nodes against various 917 forms of DDoS attacks MUST be supported. For example, mutual PDP and 918 SF node authentication should be supported. Means to protect SF 919 nodes against malformed, poorly configured (deliberately or not) SFC 920 Policy Tables should be supported. 922 SFC Boundary Nodes MUST strip any existing SF Map Index when handling 923 an incoming packet. A list of authorized SF Map Indexes are 924 configured in the SFC elements. 926 NETCONF-related security considerations are discussed in [RFC6146]. 928 Means to prevent SF loops should be supported. 930 Nodes involved in the same SFC-enabled domain MUST be provisioned 931 with the same SFC Policy Table. Possible table inconsistencies may 932 result in forwarding errors. 934 13. Contributors 936 The following individuals contributed to the document: 938 Parviz Yegani 939 Juniper Networks 940 1194 N. Mathilda Ave. 941 Sunnyvale, CA 94089 942 USA 943 Email: pyegani@juniper.net 945 Paul Quinn 946 Cisco Systems, Inc. 947 USA 948 Email: paulq@cisco.com 950 14. Acknowledgments 952 Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. Cheng, L. 953 Dunbar, and B. Chatras for their review and comments. 955 15. References 957 15.1. Normative References 959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 960 Requirement Levels", BCP 14, RFC 2119, March 1997. 962 15.2. Informative References 964 [I-D.boucadair-sfc-requirements] 965 Boucadair, M., Jacquenet, C., Jiang, Y., Parker, R., and 966 C. Pignataro, "Requirements for Service Function 967 Chaining", draft-boucadair-sfc-requirements-00 (work in 968 progress), October 2013. 970 [I-D.quinn-nsc-problem-statement] 971 Quinn, P., Guichard, J., Surendra, S., Agarwal, P., Manur, 972 R., Chauhan, A., Leymann, N., Boucadair, M., Jacquenet, 973 C., Smith, M., Yadav, N., Nadeau, T., Gray, K., McConnell, 974 B., and K. Kevin, "Network Service Chaining Problem 975 Statement", draft-quinn-nsc-problem-statement-03 (work in 976 progress), August 2013. 978 [I-D.sin-sdnrg-sdn-approach] 979 Boucadair, M. and C. Jacquenet, "Software-Defined 980 Networking: A Service Provider's Perspective", draft-sin- 981 sdnrg-sdn-approach-03 (work in progress), June 2013. 983 [I-D.tsou-softwire-bfd-ds-lite] 984 Tsou, T., Li, B., Zhou, C., Schoenwaelder, J., Penno, R., 985 and M. Boucadair, "DS-Lite Failure Detection and 986 Failover", draft-tsou-softwire-bfd-ds-lite-05 (work in 987 progress), June 2013. 989 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 990 "Definition of the Differentiated Services Field (DS 991 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 992 1998. 994 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 995 and W. Weiss, "An Architecture for Differentiated 996 Services", RFC 2475, December 1998. 998 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 999 for Policy-based Admission Control", RFC 2753, January 1000 2000. 1002 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 1003 2983, October 2000. 1005 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1006 Address Translator (Traditional NAT)", RFC 3022, January 1007 2001. 1009 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1010 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 1011 2010. 1013 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1014 (BFD) for Multihop Paths", RFC 5883, June 2010. 1016 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 1017 Notification", RFC 6040, November 2010. 1019 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1020 Customer Premises Equipment (CPE) for Providing 1021 Residential IPv6 Internet Service", RFC 6092, January 1022 2011. 1024 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1025 NAT64: Network Address and Protocol Translation from IPv6 1026 Clients to IPv4 Servers", RFC 6146, April 2011. 1028 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1029 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1030 6241, June 2011. 1032 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1033 Translation", RFC 6296, June 2011. 1035 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1036 Stack Lite Broadband Deployments Following IPv4 1037 Exhaustion", RFC 6333, August 2011. 1039 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 1040 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1041 Partnership Project (3GPP) Evolved Packet System (EPS)", 1042 RFC 6459, January 2012. 1044 [RFC6849] Kaplan, H., Hedayat, K., Venna, N., Jones, P., and N. 1045 Stratton, "An Extension to the Session Description 1046 Protocol (SDP) and Real-time Transport Protocol (RTP) for 1047 Media Loopback", RFC 6849, February 2013. 1049 Authors' Addresses 1051 Mohamed Boucadair 1052 France Telecom 1053 Rennes 35000 1054 France 1056 EMail: mohamed.boucadair@orange.com 1058 Christian Jacquenet 1059 France Telecom 1060 Rennes 35000 1061 France 1063 EMail: christian.jacquenet@orange.com 1065 Ron Parker 1066 Affirmed Networks 1067 Acton, MA 1068 USA 1070 EMail: Ron_Parker@affirmednetworks.com 1072 Diego R. Lopez 1073 Telefonica I+D 1074 Don Ramon de la Cruz, 82 1075 Madrid 28006 1076 Spain 1078 Phone: +34 913 129 041 1079 EMail: diego@tid.es 1080 Jim Guichard 1081 Cisco Systems, Inc. 1082 USA 1084 EMail: jguichar@cisco.com 1086 Carlos Pignataro 1087 Cisco Systems, Inc. 1088 USA 1090 EMail: cpignata@cisco.com