idnits 2.17.1 draft-boucadair-sfc-design-analysis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (February 12, 2014) is 3719 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-boucadair-intarea-host-identifier-scenarios-03 == Outdated reference: A later version (-02) exists of draft-boucadair-sfc-framework-00 == Outdated reference: A later version (-06) exists of draft-boucadair-sfc-requirements-02 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-00 == Outdated reference: A later version (-08) exists of draft-liu-sfc-use-cases-01 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Informational France Telecom 5 Expires: August 16, 2014 R. Parker 6 Affirmed Networks 7 L. Dunbar 8 Huawei Technologies 9 February 12, 2014 11 Service Function Chaining: Design Considerations, Analysis & 12 Recommendations 13 draft-boucadair-sfc-design-analysis-02 15 Abstract 17 This document aims at analyzing the various design options and 18 providing a set of recommendations for the design of Service Function 19 Chaining solution(s). Note: 21 o The analysis does not claim to be exhaustive. The list includes a 22 preliminary set of potential solutions; other proposals can be 23 added to the analysis if required. 25 o The analysis is still ongoing. The analysis text will be updated 26 to integrate received comments and inputs. 28 o Sketched recommendations are not frozen. These recommendations 29 are provided as proposals to kick-off the discussion and to 30 challenge them. 32 o The analysis does not cover any application-specific solution 33 (e.g., HTTP header) because of the potential issues inherent to 34 (TLS) encrypted traffic. 36 o The analysis will be updated to take into account the full set of 37 SFC requirements. 39 Requirements Language 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC 2119 [RFC2119]. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on August 16, 2014. 62 Copyright Notice 64 Copyright (c) 2014 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 81 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 82 4. Service Function Chaining Header . . . . . . . . . . . . . . 4 83 4.1. Why a Subscriber Identifier Does Not Need to be part of 84 the Header? . . . . . . . . . . . . . . . . . . . . . . . 4 85 4.2. Fixed vs. Variable Length of the SFC Map Index . . . . . 5 86 4.3. Recommended Length . . . . . . . . . . . . . . . . . . . 6 87 4.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 88 5. Format of the Service Function Chaining Header . . . . . . . 6 89 5.1. Format 1: Single Marking Code Point . . . . . . . . . . . 7 90 5.2. Format 2: Marking Code Point & Profile Index . . . . . . 7 91 5.3. Format 3: Explicit Route List . . . . . . . . . . . . . . 8 92 5.4. Format 4: Compact Explicit Route List . . . . . . . . . . 9 93 5.5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9 94 6. Where To Convey the Chaining Marking Information In A Packet? 10 95 6.1. Use IPv6 Flow Label . . . . . . . . . . . . . . . . . . . 10 96 6.2. Use the DS Field . . . . . . . . . . . . . . . . . . . . 11 97 6.3. Use IP Identification Field . . . . . . . . . . . . . . . 11 98 6.4. Use IPv4 SSRR/LSRR Option . . . . . . . . . . . . . . . . 12 99 6.5. Define a new IPv4 Option and IPv6 Extension Header . . . 13 100 6.6. Define a New TCP Option . . . . . . . . . . . . . . . . . 14 101 6.7. Use the GRE Key . . . . . . . . . . . . . . . . . . . . . 15 102 6.8. Define a New IP-in-IP Scheme . . . . . . . . . . . . . . 15 103 6.9. MAC-based SFC Forwarding . . . . . . . . . . . . . . . . 16 104 7. Steer Paths To Cross Specific SF Nodes . . . . . . . . . . . 18 105 7.1. Need for a Mandatory Encapsulation Scheme . . . . . . . . 18 106 7.2. Candidate Solutions . . . . . . . . . . . . . . . . . . . 18 107 7.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 18 108 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 110 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 114 12.2. Informative References . . . . . . . . . . . . . . . . . 21 116 1. Introduction 118 This document aims at analyzing the various design options and 119 providing a set of recommendations for the design of Service Function 120 Chaining solution(s). The conclusions of this analysis, once stable, 121 will be recorded in the framework document. 123 The overall problem space is described in 124 [I-D.ietf-sfc-problem-statement]. A list of requirements is 125 available at [I-D.boucadair-sfc-requirements]. 127 2. Terminology 129 The reader should be familiar with the terms defined in 130 [I-D.boucadair-sfc-framework]. 132 3. Scope 134 This document identifies potential solutions to fulfill the design 135 requirements documented in [I-D.boucadair-sfc-requirements]. 136 Particularly, it focuses on the following design objectives: 138 1. Which information to include in the SFC header? (see Section 4) 139 2. How to mark packets to indicate they belong to a given Service 140 Function Chain (SFC) (see Section 5) and in which channel the SFC 141 header is to be conveyed (see Section 6)? 143 3. How to select a differentiated set of policies at a given Service 144 Function (SF)? (see Section 5) 146 4. How to select the forwarding path of a given flow that needs to 147 be processed according to a set of Service Functions which must 148 be invoked in a given order? (see Section 7) 150 Other design issues will be documented in future versions if 151 required. 153 4. Service Function Chaining Header 155 This section identifies the main design points to be agreed upon so 156 as to guide the forthcoming specification effort of the Service 157 Function Chaining Header. 159 4.1. Why a Subscriber Identifier Does Not Need to be part of the 160 Header? 162 Current deployment practices rely on per-subscriber policies 163 enforcement on few service nodes (especially in the access network 164 segment). If the same design approach is preserved when SFC is in 165 use, per-subscriber policies are likely to not be supported by all 166 involved (SF) nodes. 168 Conveying the SF Map Index, that is an unique value to represent 169 different service chains, is sufficient to guide specific sequence of 170 Service Functions for a given packet that belongs to a flow. Some of 171 involved Service Functions may enforce a per-subscriber policy. The 172 enforcement of such policies can be driven by a subset of the 173 information contained in the packets (e.g., source IP address, IPv6 174 prefix, etc.). 176 In some deployment contexts implying a correlation between the 177 assigned IP address and a subscriber identifier, complications may 178 arise in the following cases: 180 o Overlapping IP address pools are in use. In such context, 181 multiple subscribers will be allocated the same internal IP 182 address: an extra identifier is needed to distinguish the traffic 183 belonging to each of these subscribers or enable multi instances 184 of the same service nodes (i.e., subscribers assigned with the 185 same internal IP address will be serviced by distinct service 186 nodes). 188 o NAT function is not collocated with the GGSN or BNG. The NAT 189 function will need an extra identifier to distinguish packets 190 belonging to a given subscriber. 192 Enforcing for instance per-subscriber port quota requires an 193 additional information to uniquely disambiguate hosts having the same 194 address (called HOST_ID, [RFC6967]). This problem is not specific to 195 the Service Function Chaining, but it is encountered in many other 196 use cases ([I-D.boucadair-intarea-host-identifier-scenarios]). 198 Within the context of SFC, two solutions can be adopted: 200 1. Implement a solution similar to what is specified in [RFC6674]. 201 This means that the subscriber-ID is passed only to the node that 202 enforces the per-subscriber policies without leaking it to other 203 downstream SFs. In such case, the node that inserts the 204 subscriber-ID is not part of the SFC-enabled domain. This 205 solution does not require the insertion of the subscriber-ID in 206 the SFC header. 208 2. Define a subscriber-ID optional field in the SFC header. This 209 optional field can be defined as an optional 64-bit field to 210 accommodate the mobile case (e.g., inject an IMSI (International 211 Mobile Subscriber Identity) identifier as a subscriber-ID). 213 +-------------------------------------------------------------------+ 214 | Proposed Recommendation | 215 +-------------------------------------------------------------------+ 216 | It is NOT RECOMMENDED to encode a subscriber-ID | 217 | as a mandatory field of the SFC header. | 218 +-------------------------------------------------------------------+ 220 4.2. Fixed vs. Variable Length of the SFC Map Index 222 The number of Service Chains to be instantiated is deployment- 223 specific. It depends on the business context and engineering 224 practices that are internal to each administrative entity. To ensure 225 a better flexibility as a function of the service chains that are 226 theoretically supported, a first design consideration is to decide 227 whether there is a need for a fixed field or a variable length field. 229 A field with a variable length is flexible enough to accommodate as 230 many Service Function Chains as required for each deployment context. 231 An administrative entity will need to tweak the length of this field 232 to meet its own deployment requirements (e.g., set the length in all 233 involved nodes to 8 bits, 16 bits, 32 bits or even more). 235 A field with a fixed length would lead to a better performance 236 (mainly because of a simplified processing). 238 4.3. Recommended Length 240 An 8-bit field would be sufficient to accommodate deployment contexts 241 that assume a reasonable set of SF Maps. A 16-bit field would be 242 more flexible and would allow to enable large service chains (e.g., 243 to accommodate the requirement discussed in 244 [I-D.boucadair-sfc-requirements]). A 32-bit field would fulfill the 245 needs for deployments with very large Service Function Chains. 247 +-------------------------------------------------------------------+ 248 | Proposed Recommendation | 249 +-------------------------------------------------------------------+ 250 | It is RECOMMENDED to use a 32-bit field to encode | 251 | the SF Map Index | 252 +-------------------------------------------------------------------+ 254 4.4. Extensibility 256 The header can be extended in the future, based on the experience 257 that will be gained during operational deployments. As such, the 258 header does not need to include any protocol version field nor any 259 reserved bits to disambiguate between two variants of the header. 261 Implementations supporting the service chaining solution can be 262 upgraded following current best practices in the field. 264 +-------------------------------------------------------------------+ 265 | Proposed Recommendation | 266 +-------------------------------------------------------------------+ 267 | It is NOT RECOMMENDED to reserve bits to anticipate future | 268 | extension needs. Backward compatibility between two versions of | 269 | the header can be ensured by consistent system | 270 | setup & configuration. | 271 +-------------------------------------------------------------------+ 273 5. Format of the Service Function Chaining Header 275 This section proposes and discusses some formats to encode the 276 Service Chaining Header. An analysis is also included in this 277 section. 279 [NOTE: Other proposals may be added to this section.] 281 5.1. Format 1: Single Marking Code Point 283 The RBNF format [RFC5511] of the header is shown in Figure 1: 285 ::= 287 Figure 1: Single Marking Code Point 289 This format is characterized as follows: 291 o The necessary information on how to steer data packets associated 292 with the SF Map Index has to be provisioned to each SF Node either 293 by in-band messages or out-of-band messages. For a SF Node that 294 contains multiple service functions, the detailed list and the 295 specific sequence of Service Functions associated with the SF Map 296 Index have to be provisioned to the SF node. If the SF node is 297 connected to multiple SF nodes, the next hop SF node for the 298 packets associated with SF Map Index has to be provisioned. This 299 provisioning can be implemented using a SFC policy table. This 300 SFC policy table includes the locator(s) of the possible SF next 301 hop and the SF Map Index list to help detect any Service Function 302 Loop. 304 o Classifiers are provisioned with classification rules to decide 305 which code point to use for a received packet. 307 o Fragmentation risk is minimized because the header is compacted. 309 o Multiple profiles can be supported per SF Node; each profile is 310 identified with a Service Function Identifier. 312 o The classifier behavior is simplified. 314 o Separating the policies channel from the marking behavior prevents 315 potential DDoS (e.g., common to any source routing scheme.) 317 o The lookup in the SFC Policy Table is not a concern because it is 318 not expected to provision SFC Policy Tables with an amount of 319 information (e.g., like the size of the global routing table). 321 5.2. Format 2: Marking Code Point & Profile Index 323 The RBNF format of the header is shown in Figure 2: 325 ::= 326 328 ::= ... 330 ::= 331 333 Figure 2: Marking Code Point & Profile Index 335 This format is characterized as follows: 337 o The list of SF Locator(s) is provisioned out of band to each SF 338 Node. 340 o Classifiers are provisioned with classification rules to decide 341 which code point is to be used for a received packet. 343 o Fragmentation risks are not minimized. 345 o The classifier needs to be configured with a list of profiles/ 346 contexts per Service Function. 348 o The classifier behavior is not simplified since it must also 349 encode in each incoming packet the full list of functions to be 350 performed by each Service Function hop. 352 5.3. Format 3: Explicit Route List 354 The RBNF format of the header is shown in Figure 3: 356 ::= 357 358 360 ::= ... 362 ::= 363 365 Figure 3: Explicit Route List 367 The procedure at a non-reclassifying node is to validate that the IP 368 address of the SF at the current index matches one of the SF's own IP 369 addresses and then to find the profile identifier by its indicated 370 identifier. Once the local Service Function is invoked, if the 371 packet needs to be forwarded to the next Service Function hop, the 372 local node simply increments the current hop index and rewrites the 373 outer IP header with the next hop's IP address. 375 This format is characterized as follows: 377 o Classifiers are provisioned with classification rules to decide 378 which code point is to be used for a received packet. 380 o Fragmentation risks are not minimized. 382 o The classifier needs to be configured with a list of profiles/ 383 contexts per Service Function. 385 o The classifier is also responsible for load balancing. This makes 386 the classifier more complex. 388 o The classifier behavior is not simplified since it must also 389 encode in each incoming packet the full list of policies to be 390 performed by each Service Function node. 392 5.4. Format 4: Compact Explicit Route List 394 A variant of the previous format is depicted in the RBNF format of 395 the header shown in Figure 4. Instead of including the explicit 396 route list (Figure 3), IP addresses of SFs are configured out of band 397 but each of these addresses is identified with a unique identifier. 398 These identifiers are indicated in the Service Chaining Header. 400 ::= 401 402 404 ::= ... 406 ::= 407 409 Figure 4: Compact Explicit Route List 411 This proposal suffers from the same drawbacks as the previous format. 413 5.5. Analysis 415 Given the design motto that says: 417 "A protocol design is complete not when you can't think of any 418 more things to add, but when you have removed everything you can 419 and you can't see how to remove any more", 421 the proposed format must be as simple as possible while meeting the 422 requirements discussed in [I-D.boucadair-sfc-requirements]. The 423 simplicity argument is further discussed in [RFC3439] and [Robust]. 425 Based on the above analysis, the proposal that is simple, minimizes 426 fragmentation, optimizes the behavior of the classifier and SF Nodes, 427 and that prevents potential DDoS attacks is the one discussed in 428 Section 5.1. 430 6. Where To Convey the Chaining Marking Information In A Packet? 432 This section lists a set of candidate solutions to convey the Service 433 Chaining Header. 435 6.1. Use IPv6 Flow Label 437 The use of the 20-bit Flow Label field in the IPv6 header [RFC6437] 438 can be considered as a candidate solution to convey the SF Map Index. 440 The following comments can be made for this candidate solution: 442 o This proposal requires all packets are transported over IPv6. 443 This should not be considered as a limitation for some 444 deployments. 445 o Intermediate Nodes must not alter the content of the Flow Label 446 field. 447 o This proposal can apply to any transport protocol. 448 o The use of the IPv6 Flow Label may interfere with other usages of 449 the flow label such as Equal Cost Multipath (ECMP) or Link 450 Aggregation (LAG) [RFC6438]. The Flow Label bits need to be 451 combined at least with bits from other sources within the packet, 452 so as to produce a constant hash value for each flow and a 453 suitable distribution of hash values across flows [RFC6437]. 454 o A 20-bit field to convey the SF Map Index allows to enable Service 455 Function Chains of a large size range. 456 o This proposal does not allow to convey additional information than 457 the SF Map Index (if needed). 458 o The Flow Label is present in all fragments, SF Nodes do not need 459 to maintain any state to handle a fragmented packet. 460 o Altering the value of the Flow Label field does not interfere with 461 the use of IPsec [RFC6438]. 462 o Carrying the SF Map Index in the IPv6 Flow Label allows to: 464 * De-correlate packet marking from forwarding constraints. 465 * Avoid requiring an internal tagging mechanism to each SF Node 466 to preserve the same marking in the outgoing interface as the 467 one received in an incoming interface. 469 +-------------------------------------------------------------------+ 470 | Proposed Recommendation | 471 +-------------------------------------------------------------------+ 472 | It is tempting to use the Flow Label, but the 20-bit length of | 473 | the Flow Label field is conflicting with the recommended 32-bit | 474 | length discussed in Section 4.3. | 475 | | 476 | The use of Flow Label is NOT RECOMMENDED. | 477 +-------------------------------------------------------------------+ 479 6.2. Use the DS Field 481 Another alternative to convey the SF Map Index is to use the 482 Differentiated Services (DS) field [RFC2474] [RFC2475] (for both IPv4 483 and IPv6). 485 The following comments can be made for this proposal: 487 o This proposal overloads the semantics of the DS field. 488 o Having 64 possible values may not accommodate deployments with a 489 large number of service chains (see Section 4.3). 490 o This proposal can apply to any transport protocol. 491 o The use of the DS field for service chaining purposes may 492 interfere with other usages such as Traffic Engineering (TE) or 493 Quality of Service (QoS). 495 * This issue can be mitigated by fragmenting the DS space into to 496 distinct set of values; each set dedicated for a specific 497 usage. An administrative entity can use the first bits for 498 service chaining and other remaining bits for QoS for instance. 499 * Splitting the DS space reduces the number of possible service 500 chains to be configured per administrative domain. 502 +-------------------------------------------------------------------+ 503 | Proposed Recommendation | 504 +-------------------------------------------------------------------+ 505 | The use of DS field is NOT RECOMMENDED. | 506 +-------------------------------------------------------------------+ 508 6.3. Use IP Identification Field 510 The IPv4 ID (Identification field of IP header, i.e., IP-ID) can be 511 used to insert the SF Map Index. The classifier rewrites the IP-ID 512 field to insert the SF Map Index (16 bits). The classifier must 513 follow the rules defined in [RFC6864]; in particular, the same SF Map 514 Index is not reassigned during a given time interval. Note: 516 o This usage is not consistent with the fragment reassembly use of 517 the Identification field [RFC0791] or the updated handling rules 518 for the Identification field [RFC6864]. 519 o Complications may arise if the packet is fragmented before 520 reaching the Classifier. To appropriately handle those packet 521 fragments, the classifier will need to maintain a lot of state. 522 o Preserving the same value when crossing all intermediate SFs may 523 be difficult (e.g., an invoked SF can be a NAT). 524 o This proposal assumes packets are transported over IPv4 (plain or 525 encapsulated mode). This may not be considered as a limitation 526 for some deployments. 528 +-------------------------------------------------------------------+ 529 | Proposed Recommendation | 530 +-------------------------------------------------------------------+ 531 | Using the IP-ID as a channel to convey the SF Map Index is NOT | 532 | RECOMMENDED. | 533 +-------------------------------------------------------------------+ 535 6.4. Use IPv4 SSRR/LSRR Option 537 Another candidate channel to convey the Service Chaining Header is to 538 use the IPv4 SSRR/LSRR options [RFC0791]. These options can be 539 inserted by the classifier following the pre-configured 540 classification rules. Note: 542 o Some general recommendations documented in 543 [I-D.ietf-opsec-ip-options-filtering] and [RFC6192] need to be 544 taken into account. 545 o This proposal assumes packets are transported over IPv4 (plain or 546 encapsulated mode). This may not be considered as a limitation 547 for some deployments. 548 o This proposal can apply to any transport protocol. 549 o Encoding the full list of intermediate SF Nodes will exacerbate 550 fragmentation issues. 551 o Injecting an additional IP option by the classifier introduces 552 some implementation complexity in the following cases: The packet 553 has the MTU size (or is close to it), and the option space is 554 exhausted. 555 o Legacy nodes must be configured to not strip this option. 556 o Processing the IP option may degrade the performance of involved 557 SF nodes. 559 +-------------------------------------------------------------------+ 560 | Proposed Recommendation | 561 +-------------------------------------------------------------------+ 562 | Using the IPv4 SSRR/LSRR options as a channel to convey | 563 | the Service Chaining Header is NOT RECOMMENDED. | 564 +-------------------------------------------------------------------+ 566 6.5. Define a new IPv4 Option and IPv6 Extension Header 568 Another candidate solution to convey the Service Chaining Header is 569 to define a new IPv4 option [RFC0791] and a new IPv6 extension header 570 [RFC6564]. The IPv4 option/IPv6 extension header can be inserted by 571 the classifier following the pre-configured classification rules. 572 Note: 574 o This proposal is valid for any transport protocol. 575 o This proposal offers the same functionality in both IPv4 and IPv6. 576 o Some general recommendations documented at 577 [I-D.ietf-opsec-ip-options-filtering], [RFC6192], and 578 [I-D.ietf-6man-ext-transmit] are to be taken into account. 579 Nevertheless, these security threats do not apply for this usage 580 since the Ingress Node is the entity that is responsible for 581 injecting the new option. Therefore, malicious usage of this 582 option is unlikely. 583 o Injecting an additional IP option by the classifier introduces 584 some implementation complexity in the following cases: The packet 585 is at or close to the MTU size, and the option space is exhausted. 586 o The option can be designed to be compact and therefore avoid 587 inducing fragmentation. 588 o Despite it is widely known that routers and middleboxes filter IP 589 options (e.g., drop IP packets with unknown IP options, strip 590 unknown IP options, etc.), this concern does not apply for the 591 Service Function Chaining case because the support of new IP 592 options can be enabled within a domain operated by the same 593 administrative domain. 594 o Intermediary Nodes must not strip this IPv4 option/IPv6 extension 595 header. 596 o The use of an IPv4 option or IPv6 Extension Header to drive the 597 processing of an incoming packet may alter the performance of SF 598 Nodes. 600 * Some vendors claim the use of Extension Headers (other than 601 Hop-by-Hop) does not impact the overall performance of their 602 IPv6 implementation (e.g., [Report]). 603 * Some studies revealed an increase of the single-hop delay when 604 IP options are included (e.g., [Delay]). 605 * The severity of the overall performance degradation is to be 606 further assessed ([RFC5180]). 608 o Carrying the Service Chaining Header as an IPv4 option/IPv6 609 extension header allows to: 611 * De-correlate packet marking from forwarding constraints. 612 * Avoid requiring an internal tagging mechanism to each SF Node 613 to preserve the same marking in the outgoing interface as the 614 one received through the incoming interface. 616 +-------------------------------------------------------------------+ 617 | Proposed Recommendation | 618 +-------------------------------------------------------------------+ 619 | Define a new IPv4 option and IPv6 extension header | 620 | as an Experimental track RFC document. This approach is pragmatic,| 621 | assuming further experiments can be conducted to: | 622 | | 623 | 1. Assess the impact on performance. | 624 | | 625 | 2. Compare the impact of using the IPv4 option and the IPv6 | 626 | extension header vs. an encapsulation mode (i.e., in contexts | 627 | where no encapsulation is required to reach the next SF hop). | 628 | | 629 | 3. Assess to what extent the use of an IPv4 option/IPv6 extension | 630 | header simplify internal tagging mechanisms specific to each SF| 631 +-------------------------------------------------------------------+ 633 6.6. Define a New TCP Option 635 This proposal consists in defining a new TCP option to convey the 636 Service Chaining Header. The drawbacks of this proposal are listed 637 below: 639 o Encapsulating every received packet in TCP SYN messages may impact 640 the performance of SF nodes. 642 o Injecting a TCP option by intermediate nodes will interfere with 643 end-to-end (E2E) issues. One example of such interference would 644 be terminating and re-originating TCP connections not belonging to 645 the transit device. 647 o Injecting this TCP option introduces some implementation 648 complexity if the options space is exhausted. TCP option space is 649 limited and might be consumed by the TCP client. 651 o SF Nodes may need to maintain a lot of state entries to handle 652 fragments. 654 +-------------------------------------------------------------------+ 655 | Proposed Recommendation | 656 +-------------------------------------------------------------------+ 657 | Defining a new TCP option as a channel to convey the Service | 658 | Chaining Header is NOT RECOMMENDED. | 659 +-------------------------------------------------------------------+ 661 6.7. Use the GRE Key 663 [RFC2890] defines key and security extensions to GRE (Generic Routing 664 Encapsulation, [RFC2784]). GRE Key and sequence number fields are 665 optional. This section investigates how a GRE Key optional field can 666 be used to convey a 32-bit SF Map Index. 668 o GRE Checksum and Sequence Number fields are not required. These 669 fields must not be included. 670 o Relying on GRE optional field to drive the processing of received 671 packets may impact the performance of SF Nodes. 672 o This proposal does not allow to convey additional information than 673 the SF Map Index (if needed). 674 o In cases where GRE would already have been used, it is preferable 675 to rely on this scheme and avoid yet another encapsulation 676 overhead. 677 o An SF Node must rely on an internal tagging procedure to preserve 678 the same header be positioned at the outgoing interface of an SF 679 node. 680 o Further experiments may be required to compare the performance 681 that would result in activating this solution vs. the performance 682 observed when an IPv4 option or IPv6 extension header is used 683 jointly with IP-in-IP encapsulation [RFC2003]. 685 +-------------------------------------------------------------------+ 686 | Proposed Recommendation | 687 +-------------------------------------------------------------------+ 688 | To be completed | 689 +-------------------------------------------------------------------+ 691 6.8. Define a New IP-in-IP Scheme 693 This proposal is compliant with [RFC1853]. It consists in adding a 694 fixed header as shown in Figure 5: 696 +---------------------------+ 697 | Outer IP Header | 698 +---------------------------+ 699 | SFC Header | 700 +---------------------------+ +---------------------------+ 701 | IP Header | | Inner IP Header | 702 +---------------------------+ ====> +---------------------------+ 703 | | | | 704 | IP Payload | | IP Payload | 705 | | | | 706 +---------------------------+ +---------------------------+ 708 Figure 5 710 The following comments can be made: 712 o This proposal covers both IPv4 and IPv6 deployment cases. 714 o An SF Node must rely on an internal tagging procedure to preserve 715 the same header be positioned at the outgoing interface of an SF 716 node. 718 o This header can be extended easily to accommodate new 719 requirements. 721 o Because the SFC Header is part of the mandatory header, the 722 performance are likely to not be severely impacted compared to 723 other tunneling modes such as the joint use of IP-in-IP and an 724 IPv4 option/IPv6 extension header. 726 +-------------------------------------------------------------------+ 727 | Proposed Recommendation | 728 +-------------------------------------------------------------------+ 729 | To be completed | 730 +-------------------------------------------------------------------+ 732 6.9. MAC-based SFC Forwarding 734 The SFC Classifier capability introduced in 735 [I-D.boucadair-sfc-framework] can be for instance supported by a GGSN 736 node of a mobile network that also embeds the PCEF (Policy Charging 737 Enforcement Function) function. A generic description of the related 738 Gi Interface use case is discussed in [I-D.liu-sfc-use-cases]. 740 This candidate solution assumes the following: 742 o The SFC Classifier node is connected to various SF Nodes via a 743 tunnel (e.g., VxLAN or L2VPN tunnel). 745 o A large block of MAC addresses are allocated to the SFC Classifier 746 node. 748 o The SFC Classifier node can use different MAC addresses in the 749 Source Address field of the data frame to identify different SFCs. 751 o Out-of-band message(s) can be exchanged between a SFC Classifier 752 node and SF Nodes to signal the SFC associated to each Source MAC 753 address. 755 This proposal is a particular case of the "Router-based mechanism" 756 defined in Section 10.2 of [I-D.boucadair-sfc-framework]. 758 The following comments can be made for this candidate solution: 760 o It can apply to any transport protocol. 761 o A large block of MAC addresses has to be allocated to the SFC 762 Classifier node. The SFC Classifier node must have the extra 763 logic of using different MAC addresses for different SF chains. 764 o Each SF node needs to be provisioned with instructions or policies 765 provided to and relayed by the classifier on where to send a 766 packet based on the source MAC address associated to a specific 767 SFC. 768 o It is designed for topologies where Classifier and SF nodes can be 769 connected by tunnels to maintain their Layer 2 connections. In 770 particular, these tunnels are used to convey SFC-specific 771 instructions and policies to the SF nodes. From that standpoint, 772 the proposal is only applicable to such topologies. 773 o The proposed scheme requires that all traffic traverses the 774 Classifier node first. The return path doesn't have to go back to 775 the SFC Classifier node because all the SF Nodes forward traffic 776 based on the instructions and policies provided to and relayed by 777 the Classifier, instead of making forwarding decisions based upon 778 the destination addresses. 779 o When multiple SFs that are part of a given SFC are co-located in 780 the same device, the SFC Classifier may have trouble to decide 781 which SF needs to be invoked in which order. A solution to avoid 782 such complication is to use different source addresses to indicate 783 which SFs and in which order. SF nodes (or Proxy Nodes) may need 784 policies from the PDP, classification nodes, or control plane on 785 how to steer packets based on source address to their designated 786 SFs. 787 o The mechanism may be exposed to an overlapping MAC address 788 situation whenever some of these MAC addresses need to be locally 789 administered. 791 +-------------------------------------------------------------------+ 792 | Proposed Recommendation | 793 +-------------------------------------------------------------------+ 794 | The MAC-based SFC forwarding is designed for specific topologies | 795 | and assumes strong requirements on the SFC Classifier Node. | 796 | | 797 | The use of MAC-based SFC forwarding is NOT RECOMMENDED as a | 798 | generic SFC mechanism that would remove dependency on the | 799 | underlying physical topology. | 800 +-------------------------------------------------------------------+ 802 7. Steer Paths To Cross Specific SF Nodes 804 7.1. Need for a Mandatory Encapsulation Scheme 806 For interoperability reasons, one encapsulation mode MUST be defined. 807 Refer to [RFC3439] for more discussion on the design principles. 809 7.2. Candidate Solutions 811 Given the requirements identified in 812 [I-D.boucadair-sfc-requirements], IP-based encapsulation schemes 813 should be considered. From this standpoint, the following 814 encapsulation candidate solutions are identified so far: 816 1. Simple IP-in-IP & a SFC header in the inner packet (e.g., IPv4 817 option, IPv6 extension header) 818 2. IP-in-IP with a fixed SFC header (Section 6.8). 819 3. GRE & GRE Key as a channel to convey the SF Map Index 820 (Section 6.7) 822 7.3. Discussion 824 The following table summarizes the main characteristics for each 825 mode: 827 +-----------------------+--------------------+--------------+-------+ 828 | Mode | Simple IP-in-IP & | IP-in-IP | GRE & | 829 | | a SFC header in | with a fixed | GRE | 830 | | the inner packet | SFC header | Key | 831 +-----------------------+--------------------+--------------+-------+ 832 | Encapsulation | No | Yes | Yes | 833 | overhead when the | | | | 834 | next hop SF is in the | | | | 835 | same subnet | | | | 836 +-----------------------+--------------------+--------------+-------+ 837 | A proprietary | No | Yes | Yes | 838 | internal tagging | | | | 839 | mechanism is required | | | | 840 +-----------------------+--------------------+--------------+-------+ 841 | Natural extensibility | Yes | Yes | No | 842 +-----------------------+--------------------+--------------+-------+ 843 | Risk to strip the | Yes | No | No | 844 | header by | | | | 845 | intermediate nodes | | | | 846 +-----------------------+--------------------+--------------+-------+ 847 | Possible Impact on | Med to High | Low to Med | Med | 848 | Performance | | | | 849 +-----------------------+--------------------+--------------+-------+ 851 The following comments can be made: 853 o Both "IP-in-IP with a fixed SFC header" and "GRE & GRE Key" 854 present almost the same characteristics except "IP-in-IP with a 855 fixed SFC header" can be easily extended. Note, "GRE & GRE Key" 856 can also be extended with new optional fields but this may induce 857 some performance degradation. 858 o "Simple IP-in-IP & a SFC header in the inner packet" is more 859 flexible: 861 * It allows to convey the SFC header separately from the 862 encapsulation header. 863 * It allows to avoid encapsulation overhead when adjacent SFs in 864 a SFC sequence are in the same subnet. 865 * No internal tagging is needed within a SF Node. 866 * The SFC header can be extended in the future (if needed). 867 o Indicated values for "Possible Impact on Performance" are 868 hypothetical. These values are inspired from some experiments 869 such as [Delay]. Ideally, further testing should be conducted to 870 better qualify the impact on performance of these proposals under 871 the same configuration and setup. 873 +-------------------------------------------------------------------+ 874 | Proposed Recommendations | 875 +-------------------------------------------------------------------+ 876 | (1) Adopt the IP-in-IP with a fixed SFC header solution (Section | 877 | 6.8). This mode is to be used as the MANDATORY encapsulation | 878 | scheme for service chaining purposes. The main selection criteria | 879 | for this proposed recommendation is to minimize performance | 880 | impacts on involved nodes. | 881 | | 882 | (2) To accommodate deployment cases where encapsulation is not | 883 | required, allow to rely exclusively on a dedicated tagging field | 884 | in the inner packet. This extension is to be defined in the | 885 | EXPERIMENTAL track (e.g., Section 6.5). | 886 | | 887 | (3) Experimental specifications can be obsoleted or promoted to | 888 | be in the Standard Tracks based on the conclusions from | 889 | significant experiments. | 890 +-------------------------------------------------------------------+ 892 8. Summary 894 As a consequence of the above analysis, the following recommendations 895 are made: 897 o **** TO BE COMPLETED ONCE THE ANALYSIS IS STABLE **** 899 9. IANA Considerations 901 Authors of this document do not require any action from IANA. 903 10. Security Considerations 905 Security considerations related to Service Function Chaining are 906 discussed in [I-D.boucadair-sfc-framework]. 908 11. Acknowledgements 910 Thanks to J. Halpern and P.Chuong for the coments on the subscriber- 911 ID. 913 12. References 915 12.1. Normative References 917 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 918 1981. 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, March 1997. 923 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 924 Used to Form Encoding Rules in Various Routing Protocol 925 Specifications", RFC 5511, April 2009. 927 12.2. Informative References 929 [Delay] Papagiannaki, K., Moon, S., Fraleigh, C., Thiran, P., and 930 C. Diot, "Measurement and Analysis of Single-Hop Delay on 931 an IP Backbone Network", August 2003. 933 [I-D.boucadair-intarea-host-identifier-scenarios] 934 Boucadair, M., Binet, D., Durel, S., Chatras, B., Reddy, 935 T., and B. Williams, "Host Identification: Use Cases", 936 draft-boucadair-intarea-host-identifier-scenarios-03 (work 937 in progress), March 2013. 939 [I-D.boucadair-sfc-framework] 940 Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., 941 Guichard, J., and C. Pignataro, "Service Function 942 Chaining: Framework & Architecture", draft-boucadair-sfc- 943 framework-00 (work in progress), October 2013. 945 [I-D.boucadair-sfc-requirements] 946 Boucadair, M., Jacquenet, C., Jiang, Y., Parker, R., and 947 C. Pignataro, "Requirements for Service Function 948 Chaining", draft-boucadair-sfc-requirements-02 (work in 949 progress), February 2014. 951 [I-D.ietf-6man-ext-transmit] 952 Carpenter, B. and S. Jiang, "Transmission and Processing 953 of IPv6 Extension Headers", draft-ietf-6man-ext- 954 transmit-05 (work in progress), October 2013. 956 [I-D.ietf-opsec-ip-options-filtering] 957 Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 958 on filtering of IPv4 packets containing IPv4 options.", 959 draft-ietf-opsec-ip-options-filtering-07 (work in 960 progress), December 2013. 962 [I-D.ietf-sfc-problem-statement] 963 Quinn, P. and T. Nadeau, "Service Function Chaining 964 Problem Statement", draft-ietf-sfc-problem-statement-00 965 (work in progress), January 2014. 967 [I-D.liu-sfc-use-cases] 968 Will, W., Li, H., Huang, O., Boucadair, M., Leymann, N., 969 Cao, Z., and J. Hu, "Service Function Chaining (SFC) Use 970 Cases", draft-liu-sfc-use-cases-01 (work in progress), 971 February 2014. 973 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. 975 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 976 October 1996. 978 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 979 "Definition of the Differentiated Services Field (DS 980 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 981 1998. 983 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 984 and W. Weiss, "An Architecture for Differentiated 985 Services", RFC 2475, December 1998. 987 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 988 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 989 March 2000. 991 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 992 RFC 2890, September 2000. 994 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 995 Guidelines and Philosophy", RFC 3439, December 2002. 997 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 998 Dugatkin, "IPv6 Benchmarking Methodology for Network 999 Interconnect Devices", RFC 5180, May 2008. 1001 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1002 Router Control Plane", RFC 6192, March 2011. 1004 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1005 "IPv6 Flow Label Specification", RFC 6437, November 2011. 1007 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1008 for Equal Cost Multipath Routing and Link Aggregation in 1009 Tunnels", RFC 6438, November 2011. 1011 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 1012 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 1013 RFC 6564, April 2012. 1015 [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, 1016 "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, 1017 July 2012. 1019 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 1020 RFC 6864, February 2013. 1022 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 1023 "Analysis of Potential Solutions for Revealing a Host 1024 Identifier (HOST_ID) in Shared Address Deployments", RFC 1025 6967, June 2013. 1027 [Report] Cisco, "IPv6 Extension Headers Review and Considerations", 1028 . 1031 [Robust] Walter Willinger, W. and J. Doyle, "Robustness and the 1032 Internet: Design and evolution", March 2002, 1033 . 1036 Authors' Addresses 1038 Mohamed Boucadair 1039 France Telecom 1040 Rennes 35000 1041 France 1043 EMail: mohamed.boucadair@orange.com 1045 Christian Jacquenet 1046 France Telecom 1047 Rennes 35000 1048 France 1050 EMail: christian.jacquenet@orange.com 1052 Ron Parker 1053 Affirmed Networks 1054 Acton, MA 1055 USA 1057 EMail: Ron_Parker@affirmednetworks.com 1058 Linda Dunbar 1059 Huawei Technologies 1060 5430 Legacy Drive, Suite #175 1061 Plano TX 1062 USA 1064 EMail: linda.dunbar@huawei.com