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