idnits 2.17.1 draft-boucadair-network-function-chaining-03.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 (August 21, 2013) is 3900 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 (-02) exists of draft-boucadair-chaining-requirements-00 == Outdated reference: A later version (-03) exists of draft-quinn-nsc-problem-statement-02 == Outdated reference: A later version (-09) exists of draft-sin-sdnrg-sdn-approach-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track France Telecom 5 Expires: February 22, 2014 R. Parker 6 Affirmed Networks 7 D. Lopez 8 Telefonica I+D 9 P. Yegani 10 Juniper Networks 11 J. Guichard 12 P. Quinn 13 Cisco Systems, Inc. 14 August 21, 2013 16 Differentiated Service Function Chaining Framework 17 draft-boucadair-network-function-chaining-03 19 Abstract 21 IP networks rely more and more on the combination of advanced 22 functions (besides the basic routing and forwarding functions). This 23 document defines a solution to enforce Service Function Chaining 24 (SFC) with minimum requirements on the underlying network. 26 The proposed solution allows for Differentiated Forwarding 27 (DiffForward): packets are classified and marked at the entry point 28 of an SFC-enabled network, and are then forwarded on a per SFC map 29 basis. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on February 22, 2014. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. On the Proliferation of Service Functions . . . . . . . . 3 73 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.3. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3. Functional Elements . . . . . . . . . . . . . . . . . . . . . 7 79 4. SFC Provisioning . . . . . . . . . . . . . . . . . . . . . . 7 80 4.1. Assign Service Function Identifiers . . . . . . . . . . . 7 81 4.2. Service Function Locator . . . . . . . . . . . . . . . . 7 82 4.3. Building Service Function Chaining (SFC) Maps . . . . . . 8 83 4.4. Building Service Function Chaining (SFC) Policy Tables . 8 84 5. Theory Of Operation . . . . . . . . . . . . . . . . . . . . . 10 85 5.1. SFC Boundary Node . . . . . . . . . . . . . . . . . . . . 10 86 5.2. SFC Classifier . . . . . . . . . . . . . . . . . . . . . 10 87 5.3. SFC Ingress Node . . . . . . . . . . . . . . . . . . . . 11 88 5.4. SFC Egress Node . . . . . . . . . . . . . . . . . . . . . 11 89 5.5. SF Node . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 5.6. Intermediate Nodes . . . . . . . . . . . . . . . . . . . 12 91 6. Fragmentation Considerations . . . . . . . . . . . . . . . . 12 92 7. Differentiated Services . . . . . . . . . . . . . . . . . . . 12 93 8. Design Considerations . . . . . . . . . . . . . . . . . . . . 13 94 8.1. Transmit A SFC Map Index In A Packet . . . . . . . . . . 13 95 8.1.1. SFC Map Index . . . . . . . . . . . . . . . . . . . . 13 96 8.1.2. Why Not Loose Or Strict Source Routing (SSR)? . . . . 13 97 8.1.3. Where To Store SFC Map Indexes In A Packet? . . . . . 13 98 8.2. Steer Paths To Cross Specific SF Nodes . . . . . . . . . 14 99 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 100 9.1. Generic Requirements . . . . . . . . . . . . . . . . . . 14 101 9.2. Deployment Models . . . . . . . . . . . . . . . . . . . . 14 102 9.3. On Service Function Profiles (a.k.a., Contexts) . . . . . 15 103 9.4. SF Node is also a Classifier . . . . . . . . . . . . . . 16 104 9.5. Direct Adjacency . . . . . . . . . . . . . . . . . . . . 16 105 9.6. Service Function Loops . . . . . . . . . . . . . . . . . 17 106 9.7. Lightweight SFC Policy Table . . . . . . . . . . . . . . 17 107 9.8. Liveness Detection Of SFs By The PDP . . . . . . . . . . 18 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 109 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 110 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 111 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 112 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 113 13.2. Informative References . . . . . . . . . . . . . . . . . 19 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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). 122 Typical examples of such functions include firewall (e.g., 123 [RFC6092]), DPI (Deep Packet Inspection), LI (Lawful Intercept) 124 module, NAT44 [RFC3022], NAT64 [RFC6146], DS-Lite AFTR [RFC6333], 125 NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment function, 126 TCP tweaking and optimization functions, transparent caching, 127 charging function, load-balancer, etc. 129 Such advanced functions are denoted SF (Service Function) in this 130 document. 132 The dynamic enforcement of a SF-derived, adequate forwarding policy 133 for packets entering a network that supports such advanced Service 134 Functions has become a key challenge for operators and service 135 providers. SF-inferred differentiated forwarding is ensured by 136 tweaking the set of Service Functions to be invoked. How to bind a 137 flow of packets that share at least one common characteristic to a 138 forwarding plane is policy-based, and subject to the set of SF 139 functions that need to be solicited for the processing of this 140 specific flow. 142 The overall problem space is described in 143 [I-D.quinn-nsc-problem-statement]. A list of requirements is 144 available at [I-D.boucadair-chaining-requirements]. 146 1.2. Scope 148 This document defines a framework to enforce Service Function 149 Chaining (SFC) with minimum requirements on the underlying network. 150 The proposed solution allows for Differentiated Forwarding 151 (DiffForward): packets are classified at the entry point of an SFC- 152 enabled network, and are then forwarded according to the ordered set 153 of SF functions that need to be activated to process these packets in 154 the SFC-enabled network. 156 This document does not make any assumption on the deployment context. 157 The proposed framework covers both fixed and mobile networks (e.g., 158 to rationalize the proliferation of advanced features at the Gi 159 Interface [RFC6459]). 161 1.3. Objectives 163 The main objectives of the proposed framework are listed below: 165 o Efficiently master the chained activation of Service functions, 166 regardless of the underlying network topology and routing 167 policies. 168 o Allow for differentiated packet forwarding by selecting the set of 169 Service functions to be invoked. 170 o Allow to easily change the chronology of the activation of Service 171 functions to be invoked. 172 o Allow to easily change the set of Service functions to be invoked. 173 o Ease management (including withdrawal) of Service functions and 174 minimize any subsequent topology upgrade. 175 o Automate the overall process of generating and enforcing policies 176 to accommodate a set of network connectivity service objectives. 178 1.4. Assumptions 180 The following assumptions are made: 182 o Not all SFs can be characterized with a standard definition in 183 terms of technical description, detailed specification, 184 configuration, etc. 185 o There is no global nor standard list of SFs enabled in a given 186 administrative domain. The set of SFs varies as a function of the 187 service to be provided and according to the networking 188 environment. 189 o There is no global nor standard SF chaining logic. The ordered 190 set of SFs that need to be activated to deliver a given 191 connectivity service is specific to each administrative entity. 193 o The chaining of SFs and the criteria to invoke some of them are 194 specific to each administrative entity that operates the SF- 195 enabled network (also called administrative domain). 196 o SF chaining logic and related policies should not be exposed 197 outside a given administrative domain. 198 o Several SF chaining logics can be simultaneously enforced within 199 an administrative domain to meet various business requirements. 200 o No assumption is made on how FIBs and RIBs of involved nodes are 201 populated. 202 o How to bind the traffic to a given SF chaining is policy-based. 204 1.5. Rationale 206 Given the assumptions listed in Section 1.4, the rationale of the 207 framework is as follows: 209 o The framework separates the dynamic provisioning of required SF 210 functions from packet handling operations (e.g., forwarding 211 decisions). 212 o SFs are handled as black boxes; the technical characterization of 213 each SF is not required. 214 o No IANA registry is required to store the list of SFs. 215 o No IANA registry is required to store the SF chaining candidates. 216 o No specific SF chaining is assumed. The description of SF chains 217 is an information that will be processed by the nodes that 218 participate to the delivery of a network service. The set of 219 listed/chained SF functions is generated by each administrative 220 entity operating the network. 221 o SF handling is policy-based: SF chains can be updated or deleted, 222 new SFs can be added without any impact on existing SFs, etc. In 223 particular, this design is compliant with the global framework 224 discussed in [I-D.sin-sdnrg-sdn-approach]. 225 o For the sake of efficiency, policy enforcement is automated (but 226 policies can be statically enforced, for example). 227 o To minimize fragmentation, a minimal set of information needs to 228 be signaled (possibly in data packets). 229 o Advanced features (e.g., load balancing) are also described and 230 configured according to policies that can be service-specific. 231 Policy decisions are made by a Policy Decision Point [RFC2753] and 232 the solicited enforcement points are responsible for applying 233 these decisions, whatever the objective to achieve. 234 o SFs can be embedded in nodes that intervene in the transport 235 service or supported by dedicated nodes (e.g., dedicated servers). 236 The decision to implement one of these two models (or a 237 combination thereof) is deployment-specific and it is orthogonal 238 to the overall procedure. 240 o Multiple SFC-enabled domains can be deployed within the same 241 administrative domain. Nodes are provisioned with the policy 242 table of the SFC-enabled domain they belong to. 243 o The overall consistency of the differentiated forwarding policy is 244 ensured by the PDP. 245 o The PDP can be responsible to enforce other policies than those 246 described in the SFC Policy Tables. 248 2. Terminology 250 This document makes use of the following terms: 252 o DiffForward: refers to the differentiated forwarding procedure as 253 specified in this document. 255 o SF (Service Function): refers to a function which is enabled in 256 the network operated by an administrative entity. One or many 257 Service Functions can be involved in the delivery of added-value 258 services. A non-exhaustive list of Service Functions include: 259 firewall (e.g., [RFC6092]), DPI (Deep Packet Inspection), LI 260 (Lawful Intercept) module, NAT44 [RFC3022], NAT64 [RFC6146], DS- 261 Lite AFTR [RFC6333], NPTv6 [RFC6296], HOST_ID injection, HTTP 262 Header Enrichment function, TCP optimizer, load-balancer, etc. 263 This document does not make any assumption in the OSI Layer on 264 which the Service Function acts on; the exact definition of each 265 Service Function is deployment-specific. 267 o SFC-enabled domain: denotes a network (or a region thereof) that 268 implements DiffForward. 270 o SF Identifier: is a unique identifier that unambiguously 271 identifies a SF within a SFC-enabled domain. SF Identifiers are 272 assigned, configured and managed by the administrative entity that 273 operates the SFC-enabled domain. SF identifiers can be structured 274 as strings; other formats can be used. SF Identifiers are not 275 required to be globally unique nor be exposed to or used by 276 another SF-enabled domain. 278 o SFC Map: refers to an ordered list of SF identifiers. Each SFC 279 Map is identified with a unique identifier called SFC Map Index. 281 o SFC Policy Table: is a table containing a list of SFC Maps, SFC 282 classification rules and Locators for all SF Nodes. A SFC Policy 283 Table may contain a default SFC Map. 285 o SF Locator: A SF Node identifier used to reach the said SF node. 286 A locator is typically an IP address or a FQDN. 288 o Legacy Node (Node for short): refers to any node that is not a SF 289 Node nor a SFC Boundary Node. This node can be located within a 290 SFC-enabled domain or outside a SFC-enabled domain. 292 3. Functional Elements 294 The following functional elements are defined in this document: 296 o SFC Boundary Node (or Boundary Node): denotes a node that connects 297 one SFC-enabled domain to a node either located in another SFC- 298 enabled domain or in a domain that is SFC-unaware. 300 o SFC Egress Node (or Egress Node): denotes a SFC Boundary Node that 301 handles traffic which leaves the SFC-enabled domain the Egress 302 Node belongs to. 304 o SFC Ingress Node (or Ingress Node): denotes a SFC Boundary Node 305 that handles traffic which enters the SFC-enabled domain the 306 ingress Node belongs to. 308 o SF Node: denotes any node within an SFC-enabled domain that embeds 309 one or multiple SFs. 311 o SFC Classifier (or Classifier): an entity which classifies packets 312 based on the packet header contents according to classification 313 rules defined in a SFC Policy Table. Packets are then marked with 314 the corresponding SFC Map Index. SFC Classifier is embedded in a 315 SFC Boundary Node. A SFC Classifier may be identified by a 316 dedicated SF Identifier. 318 4. SFC Provisioning 320 4.1. Assign Service Function Identifiers 322 The administrative entity that operates a SFC-enabled domain 323 maintains a local repository that lists the enabled SFs. This 324 administrative entity assigns a unique SF identifier for each SF. 326 SF identifiers can be structured as strings or any other format. The 327 main constraint on the format is that two SFs MUST be assigned with 328 different identifiers. SF identifiers are case-sensitive. 330 4.2. Service Function Locator 332 A SF may be embedded in one or several SF Nodes. The SF locator is 333 typically the IP address or the FQDN to reach a given SF Node. 335 The use of an IP address is RECOMMENDED to avoid any extra complexity 336 related to the support of name resolution capabilities in SF Nodes. 337 Resolution capabilities are supported by the PDP (Policy Decision 338 Point). In the rest of the document, we assume a SF locator is 339 structured as an IP address (IPv4 or IPv6). 341 A SF Node can be reached by one or more locators, which may therefore 342 be bound to the same SF. 344 4.3. Building Service Function Chaining (SFC) Maps 346 Added-value services delivered to the end-user rely on the invocation 347 of several SFs. For each of these services, the administrative 348 entity that operates an SFC-enabled domain builds one or several SFC 349 Maps. Each of these maps characterizes the list of SFs to be invoked 350 with their exact invocation order. 352 Each SFC Map is unambiguously identified with a unique identifier 353 called the SFC Map Index. The SFC Map Index MUST be described as an 354 unsigned integer. 356 Distinct chains can be applied for inbound and outbound traffic. The 357 directionality of traffic is not included as an attribute of the SFC 358 Map, but it may be implicitly described by using two SFC Maps 359 installed and maintained in the SFC Policy Table. In such case, 360 incoming packets would be marked with Index_1 for example, while 361 outgoing packets would be forwarded according to a distinct SFC Map 362 identified with Index_2. 364 An example of SFC Map to handle IPv6 traffic destined to an IPv4 365 remote server is defined as follows: 367 {15, {IPv6_Firewall, HOST_ID_Inject, NAT64}}. 369 To handle incoming packets destined to the same IPv6 host, the 370 following SFC Map can be defined: 372 {10, {IPv4_Firewall, NAT64}}. 374 4.4. Building Service Function Chaining (SFC) Policy Tables 376 A PDP (Policy Decision Point, [RFC2753]) is the central entity which 377 is responsible for maintaining SFC Policy Tables (Figure 1), and 378 enforcing appropriate policies in SF Nodes and SFC Boundary Nodes 379 (Figure 1). PDP-made decisions can be forwarded to the participating 380 nodes by using a variety of protocols (e.g., NETCONF [RFC6241]). 382 One or multiple SFC-enabled domains may be under the responsibility 383 of the same PDP. Delimiting the scope of each SFC-enabled domain is 384 under the responsibility of the administrative entity that operates 385 the SF-enabled network. 387 o . . . . . . . . . . . . . . . . . . . . . . . o 388 . SFC Policy Enforcement . 389 . +-------+ . 390 . | |-----------------+ . 391 . +-------| PDP | | . 392 . | | |-------+ | . 393 . | +-------+ | | . 394 o . . | . . . . . | . . . . . | . . . . | . . . o 395 o . . | . . . . . | . . . . . | . . . . | . . . o 396 . | | | | . 397 . v v v v . 398 . +---------+ +---------+ +-------+ +-------+ . 399 . |SFC_BN_1 | |SFC_BN_n | | SF_1 | | SF_m | . 400 . +---------+ +---------+ +-------+ +-------+ . 401 . SFC-enabled Domain . 402 o . . . . . . . . . . . . . . . . . . . . . . . o 404 Figure 1: SFC Policy Enforcement Scheme. 406 The SF Node MUST be provisioned with the following information: 408 o Local SF Identifier(s): This information is required for an SF to 409 identify itself within an SFC Map. 410 o List of SFC Maps: The PDP may configure the full list (default 411 mode) or only as subset of SFC Maps in which a SF supported by the 412 local SF node is involved (see Section 9.7). 413 o List of SF Locators: The PDP may configure the full list of 414 locators (default mode) or only the locators of next hop SFs of 415 SFC Maps in which a SF supported by the local SF node is involved 416 (see Section 9.7). 418 Likewise, the SFC Boundary Node MUST be provisioned with the 419 following information: 421 o List of SFC Maps 422 o List of SF Locators 423 o List of SFC Map Classification Rules (see Section Section 5.2). 425 In addition to the SFC Policy Table, other SF-specific policies can 426 be installed by the PDP (e.g., configure distinct user profiles, 427 activate specific traffic filters, configure traffic conditioners, 428 etc.). 430 Policies managed by the PDP may be statically instantiated or 431 dynamically triggered by external means (e.g., a AAA server). 433 In the event of any update (e.g., define a new SFC Map, delete an SFC 434 Map, add a new SF Locator, update classification policy), the PDP 435 MUST forward the updated policy configuration information in all 436 relevant SF Nodes and SFC Boundary Nodes. 438 Load-balancing among several SF Nodes supporting the same SF can be 439 driven by the PDP. Indeed, the PDP can generate multiple 440 classification rules and SFC Maps to meet load-balancing objectives. 442 The processing of packets by the nodes that belong to a SFC-enabled 443 domain does not necessarily require any interaction with the PDP, 444 depending on the nature of the SF supported by the nodes and the 445 corresponding policies to be enforced. For example, traffic 446 conditioning capabilities [RFC2475] are typical SF functions that may 447 require additional solicitation of the PDP for the SF node to decide 448 what to do with some out-of-profile traffic. 450 5. Theory Of Operation 452 The behavior of each node of a SFC-enabled domain is specified in the 453 following sections. We assume that the provisioning operations 454 discussed in Section 4 have been successful (i.e., SF functions have 455 been adequately configured according to the (service-specific) policy 456 to be enforced). 458 5.1. SFC Boundary Node 460 SFC Boundary Nodes act both as a SFC Ingress Node and as a SFC Egress 461 Node for the respective directions of the traffic. 463 Traffic enters a SFC-enabled domain at a SFC Ingress Node 464 (Section 5.3) and exits the domain at a SFC Egress Node 465 (Section 5.4). 467 5.2. SFC Classifier 469 The SFC Classifier classifies packets based on (some of) the contents 470 of the packet header. Concretely, it classifies packets based on the 471 possible combination of one or more header fields, such as source 472 address, destination address, DS field, protocol ID, source port and 473 destination port numbers, and any other information. 475 Each SFC Map Classification Rule MUST be bound to one single SFC Map 476 (i.e., the classification rule must include only one SFC Map Index). 478 5.3. SFC Ingress Node 480 When a packet is received through an interface of the SFC Ingress 481 Node that connects to the outside of the SFC domain, the Ingress Node 482 MUST: 484 o Inspect the received packet and strip any existing SFC Map Index. 485 o Check whether the received packet matches an existing 486 classification rule (see Section 5.2). 487 o If no rule matches, forward the packet to the next hop according 488 to legacy forwarding behavior (e.g., based upon the IP address 489 conveyed in the DA field of the header). 490 o If a rule matches, proceed with the following operations: 492 * Retrieve the locator of the first SF as indicated in the SFC 493 Map entry the rule matches. 494 * Check whether the corresponding SF node is an immediate 495 neighbor. 497 + If so, update the packet with the SFC Map Index of SFC Map 498 entry it matches and then forward the packet to the 499 corresponding SF Node. 500 + If not, (1) encapsulate the original packet into a new one 501 that will be forwarded to the corresponding SF node, (2) 502 update the encapsulated packet with the SFC Map Index of SFC 503 Map entry it matches, and (3) forward the packet to the next 504 hop to reach the first SF node. 506 As a result of this process, the packet will be sent to an SF Node or 507 an Intermediate Node. 509 5.4. SFC Egress Node 511 When a packet is received through an interface that connects the SFC 512 Egress Node to its SFC domain, the Egress Node MUST: 514 o Strip any existing SFC Map Index. 515 o Forward the packet according to legacy forwarding policies. 517 5.5. SF Node 519 This section assumes the default behavior is each SF Node does not 520 embed a Classifier as discussed in Section 9.4. 522 When a packet is received by a SF Node, the SF Node MUST: 524 o Check whether the packet conveys a SFC Map Index. 526 o If no SFC Map Index is included, forward the packet according to 527 legacy forwarding policies. 528 o If the packet conveys a SFC Map Index, 530 * Retrieve the corresponding SFC Map from the SFC Policy Table. 531 * Check whether the local SF Identifier is present in the SFC 532 Map: 534 + If not, forward the packet according to legacy forwarding 535 policies. 536 + If so, the packet is decapsulated (if needed) and then 537 presented as an input to the local SF. In case several SFs 538 are co-located in the same node, the packet is processed by 539 all SFs indicated in the SFC Map. Once the packet is 540 successfully handled by local SF(s), the packet is forwarded 541 to the next SF Node in the list or to an intermediate node 542 (if the local SFC Node is the last element in the SFC Map). 543 If the local SF node is not the last one in the SFC Map, it 544 retrieves the next SF Node from the list, retrieve its 545 locator for the SFC Policy Table, and forwards the packet to 546 the next hop. If the local SF Node is the last element in 547 the SFC Map, it forwards the packet to the next hop 548 according to legacy forwarding policies. 550 5.6. Intermediate Nodes 552 An Intermediate Node is any node that does not support any Service 553 Function and which is located within a SFC-enabled domain. 555 No modification is required to intermediate nodes to handle incoming 556 packets. In particular, routing and forwarding are achieved using 557 legacy procedures. 559 6. Fragmentation Considerations 561 If adding the Service Chaining Header would result in a fragmented 562 packet, the classifier should include a Service Chaining Header in 563 each fragment. 565 Other fragmentation considerations will be added in a future version 566 of the document. 568 7. Differentiated Services 570 When encapsulating an IP packet, the Ingress Node and each SF Node 571 SHOULD use its Diffserv Codepoint (DSCP, [RFC2474]) to derive the 572 DSCP (or MPLS Traffic-Class Field) of the encapsulated packet. 574 Generic considerations related to Differentiated Services and tunnels 575 are further detailed in [RFC2983]. 577 8. Design Considerations 579 This section discusses two main protocol issues to be handled in 580 order to deploy DiffForward. 582 A detailed design analysis is documented in [I-D.boucadair-chaining- 583 design-analysis]. 585 8.1. Transmit A SFC Map Index In A Packet 587 8.1.1. SFC Map Index 589 A SFC Map Index is an integer that points to a SFC Map. 591 In order to avoid all nodes of a SFC-enabled domain to be SF-aware, 592 this specification recommends to undertake classifiers at boundary 593 nodes while intermediate nodes forward the packets according to the 594 SFC Map Index conveyed in the packet (SF Node) or according to 595 typical forwarding policies (any SF-unaware node). 597 An 8-bit field would be sufficient to accommodate deployment contexts 598 that assume a reasonable set of SFC Maps. A 16-bit (or 32-bit) field 599 would be more flexible (e.g., to accommodate the requirement 600 discussed in Section 9.3). 602 8.1.2. Why Not Loose Or Strict Source Routing (SSR)? 604 Instead of injecting a Map Index, an alternate solution would be to 605 use the SSRR/LSRR IPv4 option or any similar solution to indicate a 606 loose or strict explicit route. This alternative was not considered 607 because of the likely dramatic impact on the processing and potential 608 fragmentation issues that may jeopardize the overall performance of 609 the DiffForward operation. 611 Injecting an 8-bit or a 16-bit field would minimize fragmentation 612 issues. 614 8.1.3. Where To Store SFC Map Indexes In A Packet? 616 SFC Map Indexes can be conveyed in various locations of a packet: 618 o At L2 level 619 o Define a new IP option or a new IPv6 extension header 620 o Use IPv6 Flow Label 621 o Re-use an existing field (e.g., DS field) 622 o TCP option 623 o GRE Key 624 o Define a new shim 625 o Etc. 627 8.2. Steer Paths To Cross Specific SF Nodes 629 A SFC Ingress Node or a SF Node MUST be able to forward a packet that 630 matches an existing SFC Map to the relevant next hop SF Node. The 631 locator of the next SF is retrieved from the SFC Policy Table. In 632 case the next SF Node in the list is not an immediate neighbor, a 633 solution to force the packet to cross that SF Node MUST be supported. 634 This document suggests the use of the IP-in-IP encapsulation scheme. 635 Other tunneling solutions can be considered in the future. 637 9. Deployment Considerations 639 9.1. Generic Requirements 641 The following deployment considerations should be taken into account: 643 o Avoid inducing severe path stretch compared to the path followed 644 if no SF is involved. 645 o Minimize path computation delays: due to the enforcement of 646 classification rules in all participating nodes, misconception of 647 Service function chaining, inappropriate choice of nodes elected 648 to embed Service functions, etc., must be avoided. 649 o Avoid SF invocation loops: the design of SF chainings should 650 minimize as much as possible SF invocation loops. Note that means 651 to prevent SF loops may be enabled in each SF Node (see 652 Section 9.6). 654 9.2. Deployment Models 656 Below are listed some deployment model examples: 658 1. A full marking mechanism: Ingress nodes perform the 659 classification and marking functions. Then, involved SF Nodes 660 process received packets according to their marking. 662 2. SF node mechanism, in which every SF Node embeds also a 663 classifier, and the ingress node only decides the first node to 664 forward to. Packets are forwarded at each node according to 665 local policies. No marking is required when all SFs are co- 666 located with a classifier. This model suffers from some 667 limitations (see Section 9.4). 669 3. A router-based mechanism: All SF Nodes forward packets once 670 processed to their default router. This default routes is 671 responsible for deciding how the packet should be progressed at 672 each step in the chain. One or multiple routers can be involved 673 in the same Service Function Chain. 675 4. A combination thereof. 677 9.3. On Service Function Profiles (a.k.a., Contexts) 679 Service Functions may often enforce multiple differentiated policy 680 sets. These policy sets may be coarsely-grained or fine-grained. An 681 example of coarsely-grained policy sets would be an entity that 682 performs HTTP content filtering where one policy set may be 683 appropriate for child users whereas another is appropriate for adult 684 users. An example of finely-grained policy sets would be PCEF (3GPP 685 Policy Control Enforcement Function) that has a large number of 686 differentiated QoS and charging profiles that are mapped on a per- 687 subscriber basis. 689 The Service Function Chaining mechanism directly support coarsely- 690 grained differentiated policy sets and indirectly support finely- 691 grained differentiated policy sets. 693 From a Service Function Chaining perspective, each coarsely-grained 694 policy set for a Service Function will be considered as a distinct 695 logical instance of that Service Function. Consider the HTTP content 696 filtering example where one physical or virtual entity provides both 697 child and adult content filtering. The single entity is represented 698 as two distinct logical Service Functions, each with their own 699 Service Function Identifier from a chaining perspective. The two 700 (logical) Service Functions may share the same IP address or may have 701 distinct IP addresses. 703 Finely-grained policy sets, on the other hand, would unacceptably 704 explode the number of distinct Service Chains that were required with 705 an administrative domain. For this reason, Service Functions that 706 utilize finely-grained policy sets are represented as a single 707 Service Function that has its own internal classification mechanism 708 in order to determine which of its differentiated policy sets to 709 apply. Doing so avoids from increasing the size of the SFC Policy 710 Table. 712 The threshold, in terms of number of policies, between choosing the 713 coarsely-grained policy or finely-grained policy technique is left to 714 the administrative entity managing a given domain. 716 9.4. SF Node is also a Classifier 718 If SF Nodes are also configured to behave as Classifiers, the SFC Map 719 Index is not required to be explicitly signalled in each packet. 720 Concretely, the SFC Policy Table maintained by the SF Node includes 721 classification rules. These classification rules are enforced to 722 determine whether the local SF must be involved. If an incoming 723 packet matches at least one classification rule pointing to an SFC 724 Map in which the SF Identifier is listed, the SF Node retrieves the 725 next hop SF from the SF Map indicated in the classification rule. 727 The packet is then handled by the local SF, and the SF Node 728 subsequently forwards the packet to the next hop SF. If not, the 729 packet is forwarded to the next hop according to a typical IP 730 forwarding policy. 732 Let us consider the example shown in Figure 2. The local SF Node 733 embeds SFa. Once classification rules and the SFC Maps are checked, 734 the SF Node concludes SFa must be invoked only when a packet matches 735 Rules 1 and 3. If a packet matches Rule 1, the next SF is SFC. If a 736 packet matches Rule 3, the next SF is SFh. 738 +-----------------------------------------------+ 739 | SFC Policy Table | 740 +-----------------------------------------------+ 741 |Local SF Identifier: SFa | 742 +-----------------------------------------------+ 743 |Classification Rules | 744 | Rule 1: If DEST=IP1; then SFC_MAP_INDEX1 | 745 | Rule 2: If DEST=IP2; then SFC_MAP_INDEX2 | 746 | Rule 3: IF DEST=IP3; then SFC_MAP_INDEX3 | 747 +-----------------------------------------------+ 748 |SFC Maps | 749 | {SFC_MAP_INDEX1, {SFa, SFC} | 750 | {SFC_MAP_INDEX2, {SFd, SFb} | 751 | {SFC_MAP_INDEX3, {SFa, SFh} | 752 +-----------------------------------------------+ 754 Figure 2: SFC Policy Table Example. 756 9.5. Direct Adjacency 758 SF Nodes may be enabled in a SFC-enabled domain so that each of them 759 has a direct adjacency with other SF Nodes. In such configuration, 760 no specific encapsulation scheme is required to exchange traffic 761 between these nodes. 763 9.6. Service Function Loops 765 SF Nodes use the SFC Policy Table to detect whether the local SF was 766 already applied to the received packet (i.e., detect SF Loop). The 767 SF Node MUST invoke the local SF only if the packet is received from 768 a SFC Boundary Node or a SF Node having an identifier listed before 769 the local SF in the SF Map matched by the packet. SF Loop detection 770 SHOULD be a configurable feature. 772 Figure 3 shows an example of a SFC Policy Table of a SF Node 773 embedding SFa. Assume a packet received from Locb that matches Rule 774 2. SFa must not be invoked because SFb is listed after SFa (see the 775 SFC Map list). That packet will be forwarded without invoking SFa. 777 +-----------------------------------------------+ 778 | SFC Policy Table | 779 +-----------------------------------------------+ 780 |Local SF Identifier: SFa | 781 +-----------------------------------------------+ 782 |SFC Maps | 783 | {SFC_MAP_INDEX1, {SFa, SFC} | 784 | {SFC_MAP_INDEX2, {SFd, SFa, SFb, SFh} | 785 +-----------------------------------------------+ 786 |SFC Locators | 787 | Locator_SFb: Locb | 788 | Locator_SFC: Locc | 789 | Locator_SFd: Locd | 790 | Locator_SFh: Loch | 791 +-----------------------------------------------+ 793 Figure 3: Dealing With SF Loops. 795 The support of this feature is OPTIONAL. 797 9.7. Lightweight SFC Policy Table 799 If SF loop detection is not activated in an SFC-enabled domain, the 800 PDP may provision SF nodes with a "lightweight" SFC Policy Table. A 801 lightweight SFC Policy Table is a subset of the full SFC Policy Table 802 that includes: 804 o Only the SFC Maps in which the local SF is involved. 805 o Only the next hop SF instead of the full SF chain. 807 An example of a lightweight SFC Policy Table is shown in Figure 4. 809 +-----------------------------------------------+ 810 | SFC Policy Table | 811 +-----------------------------------------------+ 812 |Local SF Identifier: SFa | 813 +-----------------------------------------------+ 814 |Lite SFC Maps | 815 | SFC_MAP_INDEX1, Next_Hop_SF = SFC | 816 | SFC_MAP_INDEX2, Next_Hop_SF = SFb | 817 +-----------------------------------------------+ 818 |SFC Locators | 819 | Locator_SFb: Locb | 820 | Locator_SFC: Locc | 821 +-----------------------------------------------+ 823 Figure 4: Lightweight SFC Policy Table. 825 9.8. Liveness Detection Of SFs By The PDP 827 The ability of the PDP to check the liveness of each SF invoked in a 828 service chain has several advantages, including: 830 o Enhanced status reporting by the PDP (i.e., an operational status 831 for any given service chain derived from liveness state of its 832 SFs). 833 o Ability to support various resiliency policies (i.e., bypass SF 834 Node, use alternate SF Node, use alternate chain, drop traffic, 835 etc.) . 836 o Ability to support load balancing capabilities to solicit multiple 837 SF instances that provide equivalent functions. 839 In order to determine the liveness of any particular SF Node, 840 standard protocols such as ICMP or BFD (both single-hop [RFC5881] and 841 multi-hop [RFC5883]) may be utilized between the PDP and the SF 842 Nodes. 844 For more sophisticated load-balancing support, protocols that allow 845 for both liveness determination and the transfer of application- 846 specific data, such as SNMP and NETCONF may be utilized between the 847 PDP and the SF Nodes. 849 The support of this feature is OPTIONAL. 851 10. IANA Considerations 853 Required IANA actions will be discussed in future versions of the 854 document. 856 11. Security Considerations 857 Means to protect SFC Boundary Nodes and SF Nodes against various 858 forms of DDoS attacks MUST be supported. For example, mutual PDP and 859 SF node authentication should be supported. Means to protect SF 860 nodes against malformed, poorly configured (deliberately or not) SFC 861 Policy Tables should be supported. 863 SFC Boundary Nodes MUST strip any existing SFC Map Index when 864 handling an incoming packet. A list of authorized SFC Map Indexes 865 are configured in the SFC elements. 867 NETCONF-related security considerations are discussed in [RFC6146]. 869 Means to prevent SF loops should be supported. 871 Nodes involved in the same SFC-enabled domain MUST be provisioned 872 with the same SFC Policy Table. Possible table inconsistencies may 873 result in forwarding errors. 875 12. Acknowledgments 877 Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, and D. Cheng for 878 their review and comments. 880 13. References 882 13.1. Normative References 884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", BCP 14, RFC 2119, March 1997. 887 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 888 Bierman, "Network Configuration Protocol (NETCONF)", RFC 889 6241, June 2011. 891 13.2. Informative References 893 [I-D.boucadair-chaining-requirements] 894 Boucadair, M., Jacquenet, C., and R. Parker, "Requirements 895 for Network Function Chaining", draft-boucadair-chaining- 896 requirements-00 (work in progress), August 2013. 898 [I-D.quinn-nsc-problem-statement] 899 Quinn, P., Guichard, J., Surendra, S., Agarwal, P., Manur, 900 R., Chauhan, A., Leymann, N., Boucadair, M., Jacquenet, 901 C., Smith, M., Yadav, N., Nadeau, T., Gray, K., and B. 902 McConnell, "Network Service Chaining Problem Statement", 903 draft-quinn-nsc-problem-statement-02 (work in progress), 904 July 2013. 906 [I-D.sin-sdnrg-sdn-approach] 907 Boucadair, M. and C. Jacquenet, "Software-Defined 908 Networking: A Service Provider's Perspective", draft-sin- 909 sdnrg-sdn-approach-03 (work in progress), June 2013. 911 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 912 "Definition of the Differentiated Services Field (DS 913 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 914 1998. 916 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 917 and W. Weiss, "An Architecture for Differentiated 918 Services", RFC 2475, December 1998. 920 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 921 for Policy-based Admission Control", RFC 2753, January 922 2000. 924 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 925 2983, October 2000. 927 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 928 Address Translator (Traditional NAT)", RFC 3022, January 929 2001. 931 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 932 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 933 2010. 935 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 936 (BFD) for Multihop Paths", RFC 5883, June 2010. 938 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 939 Customer Premises Equipment (CPE) for Providing 940 Residential IPv6 Internet Service", RFC 6092, January 941 2011. 943 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 944 NAT64: Network Address and Protocol Translation from IPv6 945 Clients to IPv4 Servers", RFC 6146, April 2011. 947 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 948 Translation", RFC 6296, June 2011. 950 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 951 Stack Lite Broadband Deployments Following IPv4 952 Exhaustion", RFC 6333, August 2011. 954 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 955 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 956 Partnership Project (3GPP) Evolved Packet System (EPS)", 957 RFC 6459, January 2012. 959 Authors' Addresses 961 Mohamed Boucadair 962 France Telecom 963 Rennes 35000 964 France 966 Email: mohamed.boucadair@orange.com 968 Christian Jacquenet 969 France Telecom 970 Rennes 35000 971 France 973 Email: christian.jacquenet@orange.com 975 Ron Parker 976 Affirmed Networks 977 Acton, MA 978 USA 980 Email: Ron_Parker@affirmednetworks.com 982 Diego R. Lopez 983 Telefonica I+D 984 Don Ramon de la Cruz, 82 985 Madrid 28006 986 Spain 988 Phone: +34 913 129 041 989 Email: diego@tid.es 991 Parviz Yegani 992 Juniper Networks 993 1194 N. Mathilda Ave. 994 Sunnyvale, CA 94089 995 USA 997 Email: pyegani@juniper.net 998 Jim Guichard 999 Cisco Systems, Inc. 1000 USA 1002 Email: jguichar@cisco.com 1004 Paul Quinn 1005 Cisco Systems, Inc. 1006 USA 1008 Email: paulq@cisco.com