idnits 2.17.1 draft-boucadair-sfc-framework-02.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 3720 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-02 == 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 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: 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-02 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. Where To Store SFC Map Indexes In A Packet? . . . . . 15 94 9.2. Steer Paths To Cross Specific SF Nodes . . . . . . . . . 15 95 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 96 10.1. Generic Requirements . . . . . . . . . . . . . . . . . . 15 97 10.2. Deployment Models . . . . . . . . . . . . . . . . . . . 16 98 10.2.1. 1.1. Proxy Node for Legacy Service Functions . . . . 16 99 10.3. On Service Function Profiles (a.k.a., Contexts) . . . . 17 100 10.4. SF Node is also a Classifier . . . . . . . . . . . . . . 18 101 10.5. SFs within the Same Subnet . . . . . . . . . . . . . . . 19 102 10.6. Service Function Loops . . . . . . . . . . . . . . . . . 19 103 10.7. Lightweight SFC Policy Table . . . . . . . . . . . . . . 20 104 10.8. Liveness Detection Of SFs By The PDP . . . . . . . . . 21 105 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 106 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 107 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 108 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 109 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 110 15.1. Normative References . . . . . . . . . . . . . . . . . . 22 111 15.2. Informative References . . . . . . . . . . . . . . . . . 22 113 1. Introduction 115 1.1. On the Proliferation of Service Functions 117 IP networks rely more and more on the combination of advanced 118 functions (besides the basic routing and forwarding functions) for 119 the delivery of added value services. Typical examples of such 120 functions include firewall (e.g., [RFC6092]), DPI (Deep Packet 121 Inspection), LI (Lawful Intercept) module, NAT44 [RFC3022], NAT64 122 [RFC6146], DS-Lite AFTR [RFC6333], NPTv6 [RFC6296], HOST_ID 123 injection, HTTP Header Enrichment function, TCP tweaking and 124 optimization function, transparent caching, charging function, load- 125 balancer, etc. 127 Such advanced functions are denoted SF (Service Function) in this 128 document. 130 The dynamic enforcement of a SF-derived, adequate forwarding policy 131 for packets entering a network that supports such advanced Service 132 Functions has become a key challenge for operators and service 133 providers. SF-inferred differentiated forwarding is ensured by 134 tweaking the set of Service Functions to be invoked. How to bind a 135 flow of packets that share at least one common characteristic to a 136 forwarding plane is policy-based, and subject to the set of SF 137 functions that need to be solicited for the processing of this 138 specific flow. 140 Service Providers need to rationalize their service delivery logics 141 and master its underlying complexity. 143 The overall problem space is described in 144 [I-D.ietf-sfc-problem-statement]. A companion document that lists a 145 set of requirements is available at [I-D.boucadair-sfc-requirements]. 147 1.2. Scope 149 This document defines a framework to enforce Service Function 150 Chaining (SFC) with minimum requirements on the physical topology of 151 the network. The proposed solution allows for differentiated 152 forwarding: packets are initially classified at the entry point of an 153 SFC-enabled network, and are then forwarded according to the ordered 154 set of SF functions that need to be activated to process these 155 packets in the SFC-enabled domain. 157 This document does not make any assumption on the deployment context. 158 The proposed framework covers both fixed and mobile networks (e.g., 159 to rationalize the proliferation of advanced features at the Gi 160 Interface [RFC6459]). 162 Considerations related to the chaining of Service Functions that span 163 domains owned by multiple administrative entities is out of scope. 164 Note, a single administrative entity may manage multiple domains. 166 1.3. Objectives 168 The main objectives of the proposed framework are listed below: 170 o Create service-inferred forwarding planes. 171 o Efficiently master the chained activation of Service functions, 172 regardless of the network topology and routing policies. 173 o Allow packets to be forwarded to the required Service Functions 174 without changing the network topology or overlay transports 175 necessary for packet delivery to/from Service Functions. 176 o Allow for differentiated packet forwarding by selecting the set of 177 Service functions to be invoked. 178 o Allow to easily change the sequentiality of the activation of 179 Service functions to be invoked. 180 o Allow to easily change the set of Service functions to be invoked. 181 o Ease management (including withdrawal) of Service functions and 182 minimize any subsequent topology update. 183 o Automate the overall process of generating and enforcing policies 184 to accommodate a set of network connectivity service objectives. 186 1.4. Assumptions 188 The following assumptions are made: 190 o Not all SFs can be characterized with a standard definition in 191 terms of technical description, detailed specification, 192 configuration, etc. 193 o There is no global nor standard list of SFs enabled in a given 194 administrative domain. The set of SFs varies as a function of the 195 service to be provided and according to the networking 196 environment. 197 o There is no global nor standard SF chaining logic. The ordered 198 set of SFs that need to be activated to deliver a given 199 connectivity service is specific to each administrative entity. 200 o The chaining of SFs and the criteria to invoke some of them are 201 specific to each administrative entity that operates the SF- 202 enabled network (also called administrative domain). 203 o SF chaining logic and related policies should not be exposed 204 outside a given administrative domain. 205 o Several SF chaining logics can be simultaneously enforced within 206 an administrative domain to meet various business requirements. 207 o No assumption is made on how FIBs and RIBs of involved nodes are 208 populated. 209 o How to bind the traffic to a given SF chaining is policy-based. 211 1.5. Rationale 213 Given the assumptions listed in Section 1.4, the rationale of the 214 framework is as follows: 216 o The framework separates the dynamic provisioning of required SF 217 functions from packet handling operations (e.g., forwarding 218 decisions). 219 o The technical characterization of each SF is not required to 220 design the SFC architecture and SFC operations. 221 o No IANA registry is required to store the list of SFs. In 222 particular, assignment of identifiers, header fields, or any other 223 indication of the Service Function Chain, are all strictly local 224 in scope. An identifier assigned in one administrative domain 225 will not indicate the same set of SFs in another administrative 226 domain. 227 o No IANA registry is required to store the SF chaining candidates. 228 The set of SFCs are local to each administrative domain, and are 229 as such not global. 230 o No specific SF chaining is assumed. The description of SF chains 231 is an information that will be processed by the nodes that 232 participate to the delivery of a network service. The set of 233 listed/chained SF functions is generated by each administrative 234 entity operating the network. 235 o SF handling is policy-based: SF chains can be updated or deleted, 236 new SFs can be added without any impact on existing SFs, etc. In 237 particular, this design is compliant with the global framework 238 discussed in [I-D.sin-sdnrg-sdn-approach]. 239 o For the sake of efficiency, policy enforcement is automated (but 240 policies can be statically enforced, for example). 241 o To minimize fragmentation, a minimal set of information needs to 242 be signaled (possibly in data packets). 243 o Advanced features (e.g., load balancing) are also described and 244 may be configured according to policies that can be service- 245 specific. Policy decisions are made by a Policy Decision Point 246 [RFC2753] and the solicited enforcement points are responsible for 247 applying these decisions, whatever the objective to achieve. 248 o SFs can be embedded in nodes that intervene in the transport 249 service or supported by dedicated nodes (e.g., dedicated servers). 250 The decision to implement one of these two models (or a 251 combination thereof) is deployment-specific and it is orthogonal 252 to the overall procedure. 253 o Multiple SFC-enabled domains can be deployed within the same 254 administrative domain. Nodes are provisioned with the policy 255 table of the SFC-enabled domain they belong to. 256 o The overall consistency of the differentiated forwarding policy is 257 ensured by the PDP. 258 o The PDP can be responsible to enforce other policies than those 259 described in the SFC Policy Tables. 261 2. Terminology 263 This document makes use of the following terms: 265 o SF (Service Function): refers to a function which is enabled in 266 the network operated by an administrative entity. One or many 267 Service Functions can be involved in the delivery of added-value 268 services. A non-exhaustive list of Service Functions include: 269 firewall (e.g., [RFC6092]), DPI (Deep Packet Inspection), LI 270 (Lawful Intercept) module, NAT44 [RFC3022], NAT64 [RFC6146], DS- 271 Lite AFTR [RFC6333], NPTv6 [RFC6296], HOST_ID injection, HTTP 272 Header Enrichment function, TCP optimizer, load-balancer, etc. 273 This document does not make any assumption in the OSI Layer on 274 which the Service Function acts on; the exact definition of each 275 Service Function is deployment-specific. 277 o SFC-enabled domain: denotes a network (or a region thereof) that 278 implements SFC. 280 o SF Identifier: is a unique identifier that unambiguously 281 identifies a SF within a SFC-enabled domain. SF Identifiers are 282 assigned, configured and managed by the administrative entity that 283 operates the SFC-enabled domain. SF identifiers can be structured 284 as strings; other formats can be used. SF Identifiers are not 285 required to be globally unique nor be exposed to or used by 286 another SF-enabled domain. 288 o SF Map: refers to an ordered list of SF identifiers. Each SF Map 289 is identified with a unique identifier called SF Map Index. 291 o SFC Policy Table: is a table containing a list of SF Maps, SFC 292 classification rules and Locators for all SF Nodes. A SFC Policy 293 Table may contain a default SF Map. 295 o SF Locator: A SF Node identifier used to reach the said SF node. 296 A locator is typically an IP address or a FQDN. 298 o Legacy Node (Node for short): refers to any node that is not a SF 299 Node nor a SFC Boundary Node. This node can be located within a 300 SFC-enabled domain or outside a SFC-enabled domain. 302 o SF Proxy Node: a Network Element along the data path, to enforce 303 SFC functions on behalf of legacy SF nodes. 305 3. Functional Elements 307 The following functional elements are defined in this document: 309 o SFC Boundary Node (or Boundary Node): denotes a node that connects 310 one SFC-enabled domain to a node either located in another SFC- 311 enabled domain or in a domain that is SFC-unaware. 313 o SFC Egress Node (or Egress Node): denotes a SFC Boundary Node that 314 handles traffic which leaves the SFC-enabled domain the Egress 315 Node belongs to. 317 o SFC Ingress Node (or Ingress Node): denotes a SFC Boundary Node 318 that handles traffic which enters the SFC-enabled domain the 319 ingress Node belongs to. 321 o SF Node: denotes any node within an SFC-enabled domain that embeds 322 one or multiple SFs. 324 o SFC Classifier (or Classifier): an entity that classifiers packets 325 for service chaining according to classification rules defined in 326 a SFC Policy Table. Packets are then marked with the 327 corresponding SF Map Index. SFC Classifier is embedded in a SFC 328 boundary (Ingress) Node. A SFC Classifier may be considered as a 329 Service Function, and therefore be uniquely identified by a 330 dedicated SF Identifier. 332 4. SFC Provisioning 334 It is out of scope of this document to discuss SF-specific policy 335 enforcement; only SFC considerations are elaborated. 337 4.1. Assign Service Function Identifiers 339 The administrative entity that operates a SFC-enabled domain 340 maintains a local repository that lists the enabled SFs. This 341 administrative entity assigns a unique SF identifier for each SF 342 type. 344 SF identifiers are structured as character strings. SF identifiers 345 are case-sensitive. 347 The main constraint on the format is that two SFs MUST be assigned 348 with different SF identifiers if they do not provide the exact same 349 function, or do provide the same function but are unable to 350 differentiation packets based on policies provisioned to the SF using 351 an appropriate mechanism. 353 4.2. Service Function Locator 355 A SF may be embedded in one or several SF Nodes. The SF locator is 356 typically the IP address or the FQDN to reach a given SF. 358 The use of an IP address is RECOMMENDED to avoid any extra complexity 359 related to the support of name resolution capabilities in SF Nodes. 360 Resolution capabilities are supported by the PDP (Policy Decision 361 Point). In the rest of the document, we assume a SF locator is 362 structured as an IP address (IPv4 or IPv6). 364 A SF can be reached by one or more locators. When multiple SF 365 locators are in use, the locator to be used to reach a given SF can 366 be driven by the PDP, a SF in a SFC, result of a load-balancing 367 heuristic, etc. 369 4.3. Service Function Discovery 371 The local repository that lists the enabled SFs within an SFC-enabled 372 domain may be built as a direct input from the administrative entity, 373 or they may be discovered dynamically through appropriate protocol 374 discovery means. 376 Whichever method is selected by the administrative entity is a local 377 decision and is therefore outside the scope of this document. Any 378 Service Function Discovery solution must comply with the requirements 379 identified in [I-D.boucadair-sfc-requirements]. 381 4.4. Building Service Function Maps 383 Added-value services delivered to the end-user rely on the invocation 384 of several SFs. For each of these services, the administrative 385 entity that operates an SFC-enabled domain builds one or several SF 386 Maps. Each of these maps characterizes the list of SFs to be invoked 387 with their exact invocation order. 389 Each SF Map is unambiguously identified with a unique identifier 390 called the SF Map Index. The SF Map Index MUST be described as an 391 unsigned integer. 393 Distinct chains can be applied for inbound and outbound traffic. The 394 directionality of traffic is not included as an attribute of the SF 395 Map, but it may be implicitly described by using two SF Maps 396 installed and maintained in the SFC Policy Table. In such case, 397 incoming packets would be marked with Index_1 for example, while 398 outgoing packets would be forwarded according to a distinct SF Map 399 identified with Index_2. 401 An example of SF Map to handle IPv6 traffic destined to an IPv4 402 remote server is defined as follows: 404 {15, {IPv6_Firewall, HOST_ID_Inject, NAT64}}. 406 To handle incoming packets destined to the same IPv6 host, the 407 following SF Map can be defined: 409 {10, {IPv4_Firewall, NAT64}}. 411 4.5. Building Service Function Chaining (SFC) Policy Tables 413 A PDP (Policy Decision Point, [RFC2753]) is the central entity which 414 is responsible for maintaining SFC Policy Tables (Figure 1), and 415 enforcing appropriate policies in SF Nodes and SFC Boundary Nodes 416 (Figure 1). PDP-made decisions can be forwarded to the participating 417 nodes by using a variety of protocols (e.g., NETCONF [RFC6241]). 419 One or multiple SFC-enabled domains may be under the responsibility 420 of the same PDP. Delimiting the scope of each SFC-enabled domain is 421 under the responsibility of the administrative entity that operates 422 the SF-enabled network. 424 o . . . . . . . . . . . . . . . . . . . . . . . o 425 . SFC Policy Enforcement . 426 . +-------+ . 427 . | |-----------------+ . 428 . +-------| PDP | | . 429 . | | |-------+ | . 430 . | +-------+ | | . 431 o . . | . . . . . | . . . . . | . . . . | . . . o 432 o . . | . . . . . | . . . . . | . . . . | . . . o 433 . | | | | . 434 . v v v v . 435 . +---------+ +---------+ +-------+ +-------+ . 436 . |SFC_BN_1 | |SFC_BN_n | | SF_1 | | SF_m | . 437 . +---------+ +---------+ +-------+ +-------+ . 438 . SFC-enabled Domain . 439 o . . . . . . . . . . . . . . . . . . . . . . . o 441 Figure 1: SFC Policy Enforcement Scheme. 443 The SF Node MUST be provisioned with the following information: 445 o Local SF Identifier(s): This information is required for an SF to 446 identify itself within an SF Map. 447 o List of SF Maps: The PDP may configure the full list (default 448 mode) or only as subset of SF Maps in which SF(s) supported by the 449 SF Node is involved (see Section 10.7). 450 o List of SF Locators: The PDP may configure the full list of 451 locators (default mode) or only the locators of next hop SFs of SF 452 Maps in which SF(s) supported by the local SF node is involved 453 (see Section 10.7). 455 [DISCUSSION NOTE: Discuss if we maintain both forms of the SFC 456 Policy table (full and lite) or select only one of them.] 458 Likewise, the SFC Boundary Node MUST be provisioned with the 459 following information: 461 o List of SF Maps 462 o List of SF Locators 463 o List of SF Map Classification Rules (see Section 5.2). 465 In addition to the SFC Policy Table, other SF-specific policies can 466 be installed by the PDP (e.g., configure distinct user profiles, 467 activate specific traffic filters, configure traffic conditioners, 468 etc.). 470 Policies managed by the PDP may be statically instantiated or 471 dynamically triggered by external means (e.g., a AAA server). 473 In the event of any update (e.g., define a new SF Map, delete an SF 474 Map, add a new SF Locator, update classification policy), the PDP 475 MUST forward the updated policy configuration information in all 476 relevant SF Nodes and SFC Boundary Nodes. 478 Distributing the load among several SF Nodes supporting the same SF 479 can be driven by the PDP. Indeed, the PDP can generate multiple 480 classification rules and SF Maps to meet some load-balancing 481 objectives. 483 Load balancing may also be achieved locally by an SF Node. If the SF 484 Node, SF Classifier, or SF Boundary Node has a table that provides 485 the SF locator(s) of SF Nodes that provide a particular SF then it is 486 possible to make that local load balancing decision. 488 The processing of packets by the nodes that belong to a SFC-enabled 489 domain does not necessarily require any interaction with the PDP, 490 depending on the nature of the SF supported by the nodes and the 491 corresponding policies to be enforced. For example, traffic 492 conditioning capabilities [RFC2475] are typical SF functions that may 493 require additional solicitation of the PDP for the SF node to decide 494 what to do with some out-of-profile traffic. 496 5. Theory Of Operation 498 The behavior of each node of a SFC-enabled domain is specified in the 499 following sections. We assume that the provisioning operations 500 discussed in Section 4 have been successful (i.e., SF functions have 501 been adequately configured according to the SFC-specific policy to be 502 enforced). 504 5.1. SFC Boundary Node 506 SFC Boundary Nodes act both as a SFC Ingress Node and as a SFC Egress 507 Node for the respective directions of the traffic. 509 Traffic enters a SFC-enabled domain at a SFC Ingress Node 510 (Section 5.3) and exits the domain at a SFC Egress Node 511 (Section 5.4). 513 5.2. SFC Classifier 515 The SFC Classifier classifies packets based on (some of) the contents 516 of the packet. Particularly, it classifies packets based on the 517 possible combination of one or more header fields, such as source 518 address, destination address, DS field, protocol ID, source port and 519 destination port numbers, and any other information. 521 Each SF Map Classification Rule MUST be bound to one single SF Map 522 (i.e., the classification rule must include only one SF Map Index). 524 5.3. SFC Ingress Node 526 When a packet is received through an interface of the SFC Ingress 527 Node that connects to the outside of the SFC domain, the Ingress Node 528 MUST: 530 o Inspect the received packet and check whether any existing SF Map 531 Index is included in the packet. 533 * The SFC Ingress Node SHOULD be configurable with a parameter to 534 indicate whether received SF Map Index is to be preserved or 535 striped. The default behavior is to strip any received SF Map 536 Index. 537 * Unless explicitly configured to trust SF Map index, The SFC 538 Ingress Node MUST strip any existing SF Map Index if the packet 539 is received from an SFC-enabled domain that has not explicitly 540 been designated as "trusted". 541 o Check whether the received packet matches an existing 542 classification rule (see Section 5.2). 543 o If no rule matches, forward the packet to the next hop according 544 to legacy forwarding behavior (e.g., based upon the IP address 545 conveyed in the DA field of the header). 546 o If a rule matches, proceed with the following operations: 548 * Retrieve the locator of the first SF as indicated in the SF Map 549 entry the rule matches. If multiple locators are available, 550 the selection can be based on local criteria (e.g., the closest 551 /best path). 552 * Check whether the corresponding SF node is an immediate (L3) 553 neighbor. 555 + If so, update the packet with the SF Map Index of SF Map 556 entry it matches and then forward the packet to the 557 corresponding SF Node. 558 + If not, (1) encapsulate the original packet into a new one 559 that will be forwarded to the corresponding SF node, (2) 560 update the encapsulated packet with the SF Map Index of SF 561 Map entry it matches, and (3) forward the packet to the next 562 hop to reach the first SF node. 564 As a result of this process, the packet will be sent to an SF Node or 565 an Intermediate Node. 567 5.4. SFC Egress Node 569 When a packet is received through an interface that connects the SFC 570 Egress Node to its SFC domain, the Egress Node MUST: 572 o Strip any existing SF Map Index. 573 o Forward the packet according to legacy forwarding policies. 575 5.5. SF Node 577 This section assumes the default behavior is each SF Node does not 578 embed a Classifier as discussed in Section 10.4. 580 When a packet is received by a SF Node, the SF Node MUST: 582 o Check whether the packet conveys a SF Map Index. 583 o If no SF Map Index is included, forward the packet according to 584 legacy forwarding policies. 585 o If the packet conveys a SF Map Index, 587 * Retrieve the corresponding SF Map from the SFC Policy Table. 588 If no entry is found in the table, forward the packet according 589 to legacy forwarding policies. 591 [DISCUSSION NOTE: Another design choice is to drop the 592 packet and send a notification to the PDP. The 593 justification for avoiding to drop the packet is that an SF 594 can be part of the forwarding path of an SFC to which it 595 does not belong to.] 596 * If an entry is found in the SFC Policy Table, check whether the 597 local SF Identifier is present in the SF Map: 599 + If not, forward the packet according to legacy forwarding 600 policies. 602 [DISCUSSION NOTE: One would argue the packet should be 603 dropped. The justification for avoiding to drop the 604 packet is that an SF can be part of the forwarding path 605 of an SFC to which it does not belong to + the SF node is 606 provisioned with the full SFC Policy Table.] 607 + If so, the packet is decapsulated (if needed) and then 608 presented as an input to the local SF. In case several SFs 609 are co-located in the same node, the packet is processed by 610 all SFs indicated in the SF Map. Once the packet is 611 successfully handled by local SF(s), the packet is forwarded 612 to the next SF Node in the list or to an intermediate node 613 (if the local SF Node is the last element in the SF Map). 614 If the local SF node is not the last one in the SF Map, it 615 retrieves the next SF Node from the list, retrieve its 616 locator for the SFC Policy Table, and forwards the packet to 617 the next hop. If the local SF Node is the last element in 618 the SF Map, it forwards the packet to the next hop according 619 to legacy forwarding policies. 621 5.6. Intermediate Nodes 623 An Intermediate Node is any node that does not support any Service 624 Function and which is located within a SFC-enabled domain. 626 No modification is required to intermediate nodes to handle incoming 627 packets. In particular, routing and forwarding are achieved using 628 legacy procedures. 630 6. Fragmentation Considerations 632 If adding the Service Chaining Header would result in a fragmented 633 packet, the classifier should include a Service Chaining Header in 634 each fragment. Doing so would prevent SF Nodes to dedicate resource 635 to handle fragments. 637 7. Differentiated Services 639 When encapsulating an IP packet, the Ingress Node and each SF Node 640 SHOULD use its Diffserv Codepoint (DSCP, [RFC2474]) to derive the 641 DSCP (or MPLS Traffic-Class Field) of the encapsulated packet. 643 Generic considerations related to Differentiated Services and tunnels 644 are further detailed in [RFC2983]. 646 8. ECN (Explicit Congestion Notification) Considerations 648 When encapsulating an IP packet, the Ingress Node and each SF Node 649 SHOULD follow [RFC6040] for ECN re-marking purposes. 651 9. Design Considerations 653 This section discusses two main protocol issues to be handled in 654 order to deploy SFC. 656 A detailed design analysis is documented in 657 [I-D.boucadair-sfc-design-analysis]. 659 9.1. Transmit A SFC Map Index In A Packet 661 9.1.1. SFC Map Index 663 A SF Map Index is an integer that points to a SF Map. 665 In order to avoid all nodes of a SFC-enabled domain to be SF-aware, 666 this specification recommends to undertake classifiers at boundary 667 nodes while intermediate nodes forward the packets according to the 668 SF Map Index conveyed in the packet (SF Node) or according to typical 669 forwarding policies (any SF-unaware node). 671 An 8-bit field would be sufficient to accommodate deployment contexts 672 that assume a reasonable set of SF Maps. A 16-bit (or 32-bit) field 673 would be more flexible (e.g., to accommodate the requirement 674 discussed in Section 10.3). 676 9.1.2. Where To Store SFC Map Indexes In A Packet? 678 SF Map Indexes can be conveyed in various locations of a packet: 680 o At L2 level 681 o Define a new IP option or a new IPv6 extension header 682 o Use IPv6 Flow Label 683 o Use MPLS Label 684 o Re-use an existing field (e.g., DS field) 685 o TCP option 686 o GRE Key 687 o Define a new shim 688 o Etc. 690 9.2. Steer Paths To Cross Specific SF Nodes 692 A SFC Ingress Node or a SF Node MUST be able to forward a packet that 693 matches an existing SF Map to the relevant next hop SF Node. The 694 locator of the next SF is retrieved from the SFC Policy Table. In 695 case the next SF Node in the list is not an immediate (L3) neighbor, 696 a solution to force the packet to cross that SF Node MUST be 697 supported. 699 10. Deployment Considerations 701 10.1. Generic Requirements 703 The following deployment considerations should be taken into account: 705 o Avoid inducing severe path stretch compared to the path followed 706 if no SF is involved. 708 o Minimize path computation delays: due to the enforcement of 709 classification rules in all participating nodes, misconception of 710 Service function chaining, inappropriate choice of nodes elected 711 to embed Service functions, etc., must be avoided. 712 o Avoid SF invocation loops: the design of SF chainings should 713 minimize as much as possible SF invocation loops. In any case, 714 forwarding loops must be avoided. 716 10.2. Deployment Models 718 Below are listed some deployment model examples: 720 1. A full marking mechanism: Ingress nodes perform the 721 classification and marking functions. Then, involved SF Nodes 722 process received packets according to their marking. 724 2. SF node mechanism, in which every SF Node embeds also a 725 classifier, and the ingress node only decides the first node to 726 forward to. Packets are forwarded at each node according to 727 local policies. No marking is required when all SFs are co- 728 located with a classifier. This model suffers from some 729 limitations (see Section 10.4). 731 3. A router-based mechanism: All SF Nodes forward packets once 732 processed to their default router. This default routes is 733 responsible for deciding how the packet should be progressed at 734 each step in the chain. One or multiple routers can be involved 735 in the same Service Function Chain. 737 4. A combination thereof. 739 10.2.1. 1.1. Proxy Node for Legacy Service Functions 741 It is not uncommon to have multiple legacy service nodes located in 742 close vicinity with a service chain proxy node, or one to two links 743 away. The following figure depicts typical network architecture for 744 chaining those service nodes that are not aware of service layer 745 encapsulation. 747 |1 ----- |n |21 ---- |2m 748 +---+---+ +---+---+ +-+---+ +--+----+ 749 | SF1 | | SF2 | | SF3 | | SF4 | 750 +---+---+ +---+---+ +--+--+ +--+--+-+ 751 : : : : : 752 : : : : : 753 \ / \ / 754 +--------------+ +--------+ +---------+ 755 -- >| SFC | ->| Proxy |---------> | Proxy | ----> 756 | Classifier | | Node-1 | | Node-i | 757 +--------------+ +----+---+ +----+--+-+ 758 |-- | | 759 V +---> 760 +--------+ 761 | Proxy | 762 | -j |-----> 763 +--------+ 765 Various deployment options can be envisaged: 767 1. Upgrade legacy service nodes to support required SFC 768 functionalities. 770 2. Enable Proxy Service Nodes to involve these legacy nodes in 771 instantiated SFCs. 773 3. Exclude legacy service nodes from a SFC domain. 775 It is up to the responsibility of each Service Provider to decide 776 which option to deploy within its networks. 778 10.3. On Service Function Profiles (a.k.a., Contexts) 780 Service Functions may often enforce multiple differentiated policy 781 sets. These policy sets may be coarsely-grained or fine-grained. An 782 example of coarsely-grained policy sets would be an entity that 783 performs HTTP content filtering where one policy set may be 784 appropriate for child users whereas another is appropriate for adult 785 users. An example of finely-grained policy sets would be PCEF (3GPP 786 Policy Control Enforcement Function) that has a large number of 787 differentiated QoS and charging profiles that are mapped on a per- 788 subscriber basis. 790 The Service Function Chaining mechanism directly support coarsely- 791 grained differentiated policy sets and indirectly support finely- 792 grained differentiated policy sets. 794 From a Service Function Chaining perspective, each coarsely-grained 795 policy set for a Service Function will be considered as a distinct 796 logical instance of that Service Function. Consider the HTTP content 797 filtering example where one physical or virtual entity provides both 798 child and adult content filtering. The single entity is represented 799 as two distinct logical Service Functions, each with their own 800 Service Function Identifier from a chaining perspective. The two 801 (logical) Service Functions may share the same IP address or may have 802 distinct IP addresses. 804 Finely-grained policy sets, on the other hand, would unacceptably 805 explode the number of distinct Service Chains that were required with 806 an administrative domain. For this reason, Service Functions that 807 utilize finely-grained policy sets are represented as a single 808 Service Function that has its own internal classification mechanism 809 in order to determine which of its differentiated policy sets to 810 apply. Doing so avoids from increasing the size of the SFC Policy 811 Table. 813 The threshold, in terms of number of policies, between choosing the 814 coarsely-grained policy or finely-grained policy technique is left to 815 the administrative entity managing a given domain. 817 [DISCUSSION NOTE: This section will be updated to reflect the 818 conclusions of the discussions from the design analysis draft.] 820 10.4. SF Node is also a Classifier 822 If SF Nodes are also configured to behave as Classifiers, the SF Map 823 Index is not required to be explicitly signalled in each packet. 824 Concretely, the SFC Policy Table maintained by the SF Node includes 825 classification rules. These classification rules are enforced to 826 determine whether the local SF must be involved. If an incoming 827 packet matches at least one classification rule pointing to an SF Map 828 in which the SF Identifier is listed, the SF Node retrieves the next 829 hop SF from the SF Map indicated in the classification rule. 831 The packet is then handled by the local SF, and the SF Node 832 subsequently forwards the packet to the next hop SF. If not, the 833 packet is forwarded to the next hop according to a typical IP 834 forwarding policy. 836 Let us consider the example shown in Figure 2. The local SF Node 837 embeds SFa. Once classification rules and the SF Maps are checked, 838 the SF Node concludes SFa must be invoked only when a packet matches 839 Rules 1 and 3. If a packet matches Rule 1, the next SF is SFC. If a 840 packet matches Rule 3, the next SF is SFh. 842 +-----------------------------------------------+ 843 | SFC Policy Table | 844 +-----------------------------------------------+ 845 |Local SF Identifier: SFa | 846 +-----------------------------------------------+ 847 |Classification Rules | 848 | Rule 1: If DEST=IP1; then SFC_MAP_INDEX1 | 849 | Rule 2: If DEST=IP2; then SFC_MAP_INDEX2 | 850 | Rule 3: IF DEST=IP3; then SFC_MAP_INDEX3 | 851 +-----------------------------------------------+ 852 |SF Maps | 853 | SFC_MAP_INDEX1: {SFa, SFc} | 854 | SFC_MAP_INDEX2: {SFd, SFb} | 855 | SFC_MAP_INDEX3: {SFa, SFh} | 856 +-----------------------------------------------+ 858 Figure 2: SFC Policy Table Example. 860 10.5. SFs within the Same Subnet 862 SF Nodes may be enabled in a SFC-enabled domain so that each of them 863 has a direct L3 adjacency with other SF Nodes. In such 864 configuration, no encapsulation scheme is required to exchange 865 traffic between these nodes. 867 10.6. Service Function Loops 869 SF Nodes use the SFC Policy Table to detect whether the local SF was 870 already applied to the received packet (i.e., detect SF Loop). The 871 SF Node MUST invoke the local SF only if the packet is received from 872 a SFC Boundary Node or a SF Node having an identifier listed before 873 the local SF in the SF Map matched by the packet. SF Loop detection 874 SHOULD be a configurable feature. 876 Figure 3 shows an example of a SFC Policy Table of a SF Node 877 embedding SFa. Assume a packet received from Locb that matches Rule 878 2. SFa must not be invoked because SFb is listed after SFa (see the 879 SF Map list). That packet will be forwarded without invoking SFa. 881 +-----------------------------------------------+ 882 | SFC Policy Table | 883 +-----------------------------------------------+ 884 |Local SF Identifier: SFa | 885 +-----------------------------------------------+ 886 |SF Maps | 887 | SFC_MAP_INDEX1: {SFa, SFc} | 888 | SFC_MAP_INDEX2: {SFd, SFa, SFb, SFh} | 889 +-----------------------------------------------+ 890 |SFC Locators | 891 | Locator_SFb: Locb | 892 | Locator_SFC: Locc | 893 | Locator_SFd: Locd | 894 | Locator_SFh: Loch | 895 +-----------------------------------------------+ 897 Figure 3: Dealing With SF Loops. 899 10.7. Lightweight SFC Policy Table 901 If SF loop detection is not activated in an SFC-enabled domain, the 902 PDP may provision SF nodes with a "lightweight" SFC Policy Table. A 903 lightweight SFC Policy Table is a subset of the full SFC Policy 904 Table that includes: 906 o Only the SF Maps in which the local SF is involved. 907 o Only the next hop SF instead of the full SF chain. 909 An example of a lightweight SFC Policy Table is shown in Figure 4. 911 +-----------------------------------------------+ 912 | SFC Policy Table | 913 +-----------------------------------------------+ 914 |Local SF Identifier: SFa | 915 +-----------------------------------------------+ 916 |Lite SF Maps | 917 | SFC_MAP_INDEX1, Next_Hop_SF = SFc | 918 | SFC_MAP_INDEX2, Next_Hop_SF = SFb | 919 +-----------------------------------------------+ 920 |SFC Locators | 921 | Locator_SFb: Locb | 922 | Locator_SFC: Locc | 923 +-----------------------------------------------+ 925 Figure 4: Lightweight SFC Policy Table. 927 10.8. Liveness Detection Of SFs By The PDP 929 The ability of the PDP to check the liveness of each SF invoked in a 930 service chain has several advantages, including: 932 o Enhanced status reporting by the PDP (i.e., an operational status 933 for any given service chain derived from liveness state of its 934 SFs). 935 o Ability to support various resiliency policies (i.e., bypass SF 936 Node, use alternate SF Node, use alternate chain, drop traffic, 937 etc.) . 938 o Ability to support load balancing capabilities to solicit multiple 939 SF instances that provide equivalent functions. 941 In order to determine the liveness of any particular SF Node, 942 standard protocols such as ICMP or BFD (both single-hop [RFC5881] and 943 multi-hop [RFC5883]) may be utilized between the PDP and the SF 944 Nodes. 946 Because an SF Node can be responsive from a reachability standpoint 947 (e.g., IP level) while the function its provides may be broken (e.g., 948 a NAT module may be down), additional means to assess whether an SF 949 is up and running are required. These means may be service-specific 950 (e.g., [RFC6849], [I-D.tsou-softwire-bfd-ds-lite]). 952 For more sophisticated load-balancing support, protocols that allow 953 for both liveness determination and the transfer of application- 954 specific data, such as SNMP and NETCONF may be utilized between the 955 PDP and the SF Nodes. 957 11. IANA Considerations 959 This document does not require any IANA actions. 961 12. Security Considerations 963 Means to protect SFC Boundary Nodes and SF Nodes against various 964 forms of DDoS attacks MUST be supported. For example, mutual PDP and 965 SF node authentication should be supported. Means to protect SF 966 nodes against malformed, poorly configured (deliberately or not) SFC 967 Policy Tables should be supported. 969 SFC Boundary Nodes MUST strip any existing SF Map Index when handling 970 an incoming packet. A list of authorized SF Map Indexes are 971 configured in the SFC elements. 973 NETCONF-related security considerations are discussed in [RFC6146]. 975 Means to prevent SF loops should be supported. 977 Nodes involved in the same SFC-enabled domain MUST be provisioned 978 with the same SFC Policy Table. Possible table inconsistencies may 979 result in forwarding errors. 981 13. Contributors 983 The following individuals contributed to the document: 985 Parviz Yegani 986 Juniper Networks 987 1194 N. Mathilda Ave. 988 Sunnyvale, CA 94089 989 USA 990 Email: pyegani@juniper.net 992 Paul Quinn 993 Cisco Systems, Inc. 994 USA 995 Email: paulq@cisco.com 997 Linda Dunbar 998 Huawei Technologies 999 1700 Alma Drive, Suite 500 1000 Plano, TX 75075, USA 1001 Phone: (469) 277 5840 1002 Email: ldunbar@huawei.com 1004 14. Acknowledgments 1006 Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. Cheng, R. 1007 White, and B. Chatras for their review and comments. 1009 15. References 1011 15.1. Normative References 1013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1014 Requirement Levels", BCP 14, RFC 2119, March 1997. 1016 15.2. Informative References 1018 [I-D.boucadair-sfc-design-analysis] 1019 Boucadair, M., Jacquenet, C., Parker, R., and L. Dunbar, 1020 "Service Function Chaining: Design Considerations, 1021 Analysis & Recommendations", draft-boucadair-sfc-design- 1022 analysis-02 (work in progress), February 2014. 1024 [I-D.boucadair-sfc-requirements] 1025 Boucadair, M., Jacquenet, C., Jiang, Y., Parker, R., 1026 Pignataro, C., and K. Kengo, "Requirements for Service 1027 Function Chaining", draft-boucadair-sfc-requirements-03 1028 (work in progress), February 2014. 1030 [I-D.ietf-sfc-problem-statement] 1031 Quinn, P. and T. Nadeau, "Service Function Chaining 1032 Problem Statement", draft-ietf-sfc-problem-statement-00 1033 (work in progress), January 2014. 1035 [I-D.sin-sdnrg-sdn-approach] 1036 Boucadair, M. and C. Jacquenet, "Software-Defined 1037 Networking: A Perspective From Within A Service Provider", 1038 draft-sin-sdnrg-sdn-approach-09 (work in progress), 1039 January 2014. 1041 [I-D.tsou-softwire-bfd-ds-lite] 1042 Tsou, T., Li, B., Zhou, C., Schoenwaelder, J., Penno, R., 1043 and M. Boucadair, "DS-Lite Failure Detection and 1044 Failover", draft-tsou-softwire-bfd-ds-lite-06 (work in 1045 progress), February 2014. 1047 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1048 "Definition of the Differentiated Services Field (DS 1049 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1050 1998. 1052 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1053 and W. Weiss, "An Architecture for Differentiated 1054 Services", RFC 2475, December 1998. 1056 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 1057 for Policy-based Admission Control", RFC 2753, January 1058 2000. 1060 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 1061 2983, October 2000. 1063 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1064 Address Translator (Traditional NAT)", RFC 3022, January 1065 2001. 1067 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1068 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 1069 2010. 1071 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1072 (BFD) for Multihop Paths", RFC 5883, June 2010. 1074 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 1075 Notification", RFC 6040, November 2010. 1077 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1078 Customer Premises Equipment (CPE) for Providing 1079 Residential IPv6 Internet Service", RFC 6092, January 1080 2011. 1082 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1083 NAT64: Network Address and Protocol Translation from IPv6 1084 Clients to IPv4 Servers", RFC 6146, April 2011. 1086 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1087 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1088 6241, June 2011. 1090 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1091 Translation", RFC 6296, June 2011. 1093 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1094 Stack Lite Broadband Deployments Following IPv4 1095 Exhaustion", RFC 6333, August 2011. 1097 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 1098 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1099 Partnership Project (3GPP) Evolved Packet System (EPS)", 1100 RFC 6459, January 2012. 1102 [RFC6849] Kaplan, H., Hedayat, K., Venna, N., Jones, P., and N. 1103 Stratton, "An Extension to the Session Description 1104 Protocol (SDP) and Real-time Transport Protocol (RTP) for 1105 Media Loopback", RFC 6849, February 2013. 1107 Authors' Addresses 1109 Mohamed Boucadair 1110 France Telecom 1111 Rennes 35000 1112 France 1114 EMail: mohamed.boucadair@orange.com 1115 Christian Jacquenet 1116 France Telecom 1117 Rennes 35000 1118 France 1120 EMail: christian.jacquenet@orange.com 1122 Ron Parker 1123 Affirmed Networks 1124 Acton, MA 1125 USA 1127 EMail: Ron_Parker@affirmednetworks.com 1129 Diego R. Lopez 1130 Telefonica I+D 1131 Don Ramon de la Cruz, 82 1132 Madrid 28006 1133 Spain 1135 Phone: +34 913 129 041 1136 EMail: diego@tid.es 1138 Jim Guichard 1139 Cisco Systems, Inc. 1140 USA 1142 EMail: jguichar@cisco.com 1144 Carlos Pignataro 1145 Cisco Systems, Inc. 1146 USA 1148 EMail: cpignata@cisco.com