idnits 2.17.1 draft-kumar-sfc-nsh-forwarding-01.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 19, 2016) is 2806 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 (-28) exists of draft-ietf-sfc-nsh-05 == Outdated reference: A later version (-03) exists of draft-kumar-sfc-offloads-02 == Outdated reference: A later version (-03) exists of draft-kumar-sfc-nsh-udp-transport-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining S. Kumar 3 Internet-Draft K. Leung 4 Intended status: Standards Track P. Bosch 5 Expires: February 20, 2017 Cisco Systems, Inc 6 D. Lee 7 SK Telecom 8 R. Manur 9 Broadcom 10 A. Dolganow 11 P. Muley 12 Nokia Corp 13 S. Majee 14 F5 Networks 15 J. Halpern 16 Ericsson 17 August 19, 2016 19 Infrastructure Service Forwarding For NSH 20 draft-kumar-sfc-nsh-forwarding-01 22 Abstract 24 This draft describes the separation of service forwarding function 25 and service delivery function abstractions, along with the mechanics 26 of NSH encapsulated packet forwarding with such separation, in SFC 27 deployments. 29 This separation frees the service functions from making forwarding 30 decisions and the necessary control plane integration, thereby 31 keeping the service functions simple and focused on service delivery. 32 Further, this separation fully contains the forwarding decisions in 33 forwarding functions, thereby allowing implementations to enforce 34 integrity of the forwarding state carried in NSH which in turn is 35 required for correctly forwarding NSH encapsulated packets. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on February 20, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 73 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 3 74 3. NSH And Forwarding . . . . . . . . . . . . . . . . . . . . . 4 75 3.1. NSH Background . . . . . . . . . . . . . . . . . . . . . 4 76 3.2. NSH Forwarding . . . . . . . . . . . . . . . . . . . . . 5 77 3.3. NSH Forwarding Shortcomings . . . . . . . . . . . . . . . 5 78 4. SFC Service Forwarding And Service Delivery Separation . . . 6 79 4.1. Forwarding Function And Service Function Separation . . . 7 80 4.2. NSH Infrastructure Flag . . . . . . . . . . . . . . . . . 8 81 4.3. Rules For Infrastructure Flag Usage . . . . . . . . . . . 8 82 4.4. Service Header Integrity Check . . . . . . . . . . . . . 9 83 4.5. SF Considerations for Reverse Service Path Packets . . . 10 84 4.6. SF Considerations for Spontaneous Packets . . . . . . . . 12 85 5. Infrastructure Forwarding Example . . . . . . . . . . . . . . 12 86 6. Infrastructure Forwarding Advantages . . . . . . . . . . . . 13 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 10.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 SFC involves steering user or application traffic on a service 98 overlay network through a list of ordered service functions before 99 forwarding onwards to its destination, in the process servicing the 100 traffic as per policies in the service functions as well as the SFC 101 infrastructure. 103 NSH is the encapsulation designed to carry SFC specific forwarding 104 state as well as metadata relevant to service delivery. The 105 forwarding state in the NSH dictates how to forward the encapsulated 106 packet or frame while the metadata aids service delivery by having 107 one SFC entity produce it and the other consume it. 109 NSH in its current form, as described in [I-D.ietf-sfc-nsh], blurs 110 the lines between service delivery and service forwarding. This 111 leads to complexities in SFC deployment and operation as the SFC 112 control plane has to deal with a large number of forwarding touch 113 points further challenging the scalability of the deployment. 114 Requiring forwarding decisions be made in the service functions 115 violates operational environment policies due to errors or unintended 116 modification of forwarding state by service functions. 118 This draft describes the separation of SFC overlay network into a 119 service infrastructure overlay and service function overlay, thereby 120 clearly demarking the boundaries between the two distinct 121 architecture functions. This allows infrastructure components to 122 create and manage the forwarding state as per control plane policy 123 while freeing the service functions to focus on service delivery and 124 not participate in forwarding decisions. 126 This draft further describes the forwarding process in SFC to achieve 127 such separation that is not only architecturally clean but is 128 friendly to software as well as hardware implementations of SFC 129 infrastructure components. 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 2. Definition Of Terms 139 This document uses some terms defined in SFC architecture 140 [I-D.ietf-sfc-architecture] and NSH [I-D.ietf-sfc-nsh] drafts for 141 ease of understanding and the reader is advised to refer to those 142 documents for up to date and additional information. 144 SFC Infrastructure : A general term used to refer to, collectively, 145 the SFC control plane entity, the classifier, the SFFs. As used 146 freely in the rest of this document, it refers to the 147 infrastructure data plane components - classifiers and SFFs. 149 Service Infrastructure Overlay : The overlay network extending 150 between SFC infrastructure data plane components. In particular, 151 the overlay network between the SFFs or Classifiers and SFFs 153 Service Function Overlay : The overlay network extending between the 154 SFF and SF 156 3. NSH And Forwarding 158 3.1. NSH Background 160 NSH encapsulation is comprised of three parts as specified in 161 [I-D.ietf-sfc-nsh]; namely a base header, a service path header and 162 one or more context headers predicated on MD-type in the base header. 163 The base and service path headers are reproduced in Figure 1 for ease 164 of reading. 166 1. The base header provides the structure to NSH with code points to 167 signal the payload carried in addition to control bits in the 168 form of flags. 170 2. The service path header is the forwarding state carried in NSH 171 and consists of a "Service Path ID" (SPI) and a "Service Index" 172 (SI). 174 3. The context headers carry the metadata produced or consumed by 175 the SFC infrastructure or the service functions. 177 Figure 1 reproduces the base and service path headers from 178 [I-D.ietf-sfc-nsh], which are relevant to this discussion. 180 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Service Path ID (SPI) | Service Index | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 1: NSH Base and Service Path Headers 189 3.2. NSH Forwarding 191 Traffic requiring servicing is forwarded on a network overlay 192 constructed using NSH and an outer transport. The forwarding of 193 traffic on this overlay is specified by the NSH. In particular, NSH 194 asserts the following as described in the NSH Actions section of 195 [I-D.ietf-sfc-nsh]. 197 1. Mandates service functions to update the service index (SI). 199 2. Mandates the service function forwarders to make forwarding 200 decisions based on the contents in the service path header, 201 namely SPI and SI. 203 These assertions essentially require the modification of the service 204 path header in NSH by the SFs. The SFs are required to control the 205 packet forwarding by making those decisions for the SFFs to use and 206 forward NSH encapsulated packets on. 208 3.3. NSH Forwarding Shortcomings 210 NSH's inability to separate packet forwarding and service delivery 211 leads to the following disadvantages. 213 o NSH is based on a model where SFs are fully trusted to maintain 214 the integrity of the encapsulation, thereby allowing SFFs to 215 forward on the decision made by SFs. However, this may not be 216 acceptable in all network environments. Strict infrastructure and 217 application boundaries in operators' environments essentially 218 disallow such a method of packet forwarding. 220 o Since forwarding decisions are made at SFs, including non- 221 classifier SFs, by way of SI updates in NSH, the control plane has 222 to program the SFs with information to aid such updates. This 223 includes the SI updates corresponding to each SPI the SF belongs 224 to. This approach impacts scalability as the number of SFs are 225 significantly greater in number as compared to SFFs in a typical 226 deployment. 228 o Since non-classifier SFs require forwarding information programmed 229 as described above and the SFs can be from any vendor or third 230 party, with even their own control and management planes in some 231 cases, programming SFs and SFC infrastructure leads to increased 232 control plane complexity. This in turn impacts scalability of SFC 233 deployment, weakening the SFC architecture. 235 o Since service forwarding is required at the SFFs, which in turn is 236 solely based on the SPI and SI fields in the NSH encapsulation 237 header, it leaves SFFs vulnerable to forwarding on decisions not 238 made by itself. These decisions are made by SFs as listed in the 239 assertions. If an SF is buggy or compromised or doing incorrect 240 manipulation of the service index, it may lead to many issues 241 including, packet loop(when SF does not update SI), bypass SF(when 242 SF over decrements or increments SI), etc. 244 o Forwarding decisions at SFF cannot be avoided as many use cases 245 require that decision to be performed in the SFF, making it 246 inconsistent. For instance, when flows are offloaded to SFF by an 247 SF, as described in [I-D.kumar-sfc-offloads] SFF MUST update the 248 service path header as the SF will be bypassed. 250 o Inspecting service path header in NSH on the wire, it is not 251 possible to determine what service function the packet is 252 associated with and where along the path it is at any moment, due 253 to the fact that SFs update the SI and hence the Service Path 254 Header. For instance, the SI inside NSH of a packet being 255 serviced, points to one SF while inflight from SFF to SF and 256 another when it is inflight from that same SF back to SFF. In 257 other words, additional context is required to make such an 258 assertion making troubleshooting cumbersome. 260 4. SFC Service Forwarding And Service Delivery Separation 262 This section describes the separation of the forwarding and service 263 delivery functions into separate abstract planes in the context of 264 NSH but is generally applicable to the SFC architecture. Figure 2 265 depicts the separation of the service plane into service 266 infrastructure and service function overlays. For the sake of 267 simplicity SFC Proxy function is not shown as it is equivalent of an 268 NSH aware SF in its handling of NSH encapsulation. The network 269 connectivity between Classifier and SFF or SFFs or SFF and SF(or SFC 270 Proxy) can be any network overlay over which NSH encapsulation can be 271 transported, such as [I-D.kumar-sfc-nsh-udp-transport]. 273 ( SF ) ( SF ) ( SF ) ^ 274 . . . | 275 . . . Service 276 . . . Function 277 . . . Overlay 278 +------------+ +------+ +---- | 279 net]==| Classifier |==[net]==| SFF |==[net]==| SFF | 280 +------------+ +------+ +---- v 282 <------------Service Infrastructure-----------> 283 Overlay 285 Figure 2: SFC Network Overlay Separation 287 4.1. Forwarding Function And Service Function Separation 289 o We propose the separation of forwarding and servicing planes in 290 NSH encapsulation to render the SFC architecture cleanly. This 291 enables forwarding from Classifier to SFF or one SFF to another or 292 SFF to SF(or SFC Proxy) to be fully owned and controlled by the 293 service chaining infrastructure while service delivery is the sole 294 responsibility of SFs. This allows for scaling the service plane 295 independent of the forwarding plane while avoiding forwarding 296 conflicts that may otherwise arise. In other words, SFC 297 forwarding is fully controlled by the SFFs and any forwarding- 298 state carried in NSH, be in NSH service context header or meta- 299 data context header, is fully opaque to the SFs. 301 o We propose the overlay network be separated into infrastructure 302 overlay and the service overlays as depicted in Figure 2. 303 Infrastructure overlay extends between SFFs or Classifier and SFFs 304 while the service overlay extends between SFFs and SFs. 306 o We propose that only the SFFs and Classifiers update the service 307 path header. This restriction limits the forwarding decisions to 308 SFC infrastructure components. These steps make the service path 309 header (or SPI and SI) opaque to SFs and immutable as it passes 310 through an SF. Since SFs performing re-classification do so 311 within the purview of the SFC control plane, re-classification SFs 312 are an exception to maintaining this immutable property and are 313 allowed to update the service path header. 315 o We propose the update operation on service index in NSH service 316 path header at the SFFs be controlled by the presence of a signal 317 or a flag that indicates whether the packet is on the 318 Infrastructure overlay or the Service overlay. Section 4.2 319 describes the allocation specifics in NSH to achieve this, which 320 is software as well hardware friendly. 322 o We further propose that SFFs verify the integrity of the service 323 path header every time a NSH packet is received from a SF. A 324 simple approach to such verification is described in Section 4.4. 326 4.2. NSH Infrastructure Flag 328 Figure 3 shows the format of the NSH encapsulation with the I flag in 329 the base header. 331 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |Ver|O|C|I|R|R|R|R|R| Length | MD Type | Next Protocol | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Service Path ID | Service Index | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 3: NSH Base and Service Path Header with 'I' Flag 340 I Bit: Infrastructure overlay flag 342 I = 1: Packet or frame is on the infrastructure overlay 344 I = 0: Packet or frame is on the service-function overlay 346 4.3. Rules For Infrastructure Flag Usage 348 The 'I' flag acts as a discriminator identifying the sender of the 349 NSH encapsulated packet as SFC infrastructure component or service 350 function. This becomes essential architecturally, as the same 351 interface at a SFF may receive NSH encapsulated packets from both the 352 SFC infrastructure components and the service functions. 354 The following rules MUST be observed by the SFC components in 355 updating the 'I' flag and the service path header in NSH 356 encapsulation header. 358 1. Classifier MUST set the 'I' flag to '1' when sending the NSH 359 encapsulated packet or frame to the next SFF (or SFF) 361 2. SFF MUST set the 'I' flag to '1' when sending the NSH 362 encapsulated packet to the next SFF 364 3. Classifier and SFF MUST set the 'I' flag to '0' in all other 365 circumstances when forwarding NSH encapsulated packet 367 4. SF and SFC Proxy MUST NOT set the I flag 369 5. SFF MUST update the Service Index in NSH only when a packet with 370 NSH is received with the 'I' flag set to '0' before making the 371 next forwarding decision. 373 In addition to the above rules guiding the I flag usage, the 374 following constraints must be met. 376 o When more than one classifier exists in the deployment, all 377 classifiers MUST adhere to the above rules. 379 o Non-classifier SFs MUST NOT update the NSH service path header 381 o Control plane or static configuration at SFs and SFFs (outside the 382 scope of this draft) MUST control the use of I flag and the 383 overall behavior described in this draft. This is recommended as 384 the default behavior of SFFs and SFs. 386 4.4. Service Header Integrity Check 388 The separation of service function and forwarding function 389 responsibilities with respect to forwarding state, allows the service 390 function forwarders to enforce integrity checks to verify the 391 immutable aspect of the service path header. Implementations are 392 recommended to use an appropriate method to verify the integrity of 393 the service path header. 395 There are many approaches to performing the integrity checks. Actual 396 method is out of scope for this document. A few methods are briefly 397 summarized here as mere examples and implementations must devise 398 their own. 400 o Every NSH packet received from a SF, 'I=0' in NSH base header, is 401 checked against the three tuple: 402 programmed in the SFF, by the control plane, for that SF. This 403 method is simple and works well when a SF appears only once across 404 all service paths. 406 o SFFs compute a hash of a n-tuple or a pseudo header and transport 407 this hash, as opaque metadata in NSH, through the SFs on a service 408 path. When SFF receives the opaque metadata back, post servicing 409 of the packet, re-computes the hash of the same n-tuple and checks 410 against the hash received in NSH. The n-tuple may include inner 411 payload, outer transport, service path header and SFF local data 412 among others. Implementations must determine the n-tuple based on 413 the SFC deployment requirements. 415 o SFFs that are stateful, use flow state to record SPI and SIs and 416 validate the same when the packet is received back from a SF. 417 This works well as long as an SF appears only once in a given SPI. 418 If multiple instances of the same SF within the same SPI is 419 needed, additional check to protect the SI must be used. 421 o As a generalized approach, control plane programs a mask to be 422 applied to the NSH header to select the bits to perform integrity 423 checks against. In the simplest case, the mask represents just 424 the service path header. 426 These methods do not protect against threats such as packet replay or 427 spoofing attacks, which do not violate the integrity of the service 428 path header. These methods protect only against modification of the 429 NSH service path header accidentally or otherwise thus ensuring the 430 integrity of the same. 432 4.5. SF Considerations for Reverse Service Path Packets 434 Service functions are essentially applications servicing the traffic 435 steered to them over NSH. Some service functions simply service the 436 traffic received, by transmitting every packet along the path, in the 437 same direction as received, after servicing it. Some service 438 functions on the other hand, for instance service functions that act 439 as proxies, often terminate the TCP flows locally before re- 440 originating them towards the ultimate destination. Termination of a 441 TCP flow locally at the SF requires completion of the TCP handshake, 442 which further requires responding to the first sign of life packet or 443 the TCP SYN packet. 445 SFs must be able to generate a NSH payload packet, in response to one 446 received from a SFF, that flows in the opposite direction of the 447 received payload packet. These response packets must thus traverse 448 the service chain in the reverse direction of the one received from 449 the SFF. However, NSH has provision to carry only one service path 450 in the service path header; a SFF cannot convey both the forward and 451 the reverse SPIs to the SFs, to enable SFs to use the reverse SPIs in 452 such scenarios. SFs that need to send a packet on the reverse 453 service path must thus know how to fill the service path header with 454 the correct SPI and SI. One approach is to have the control plane 455 provision such information for SFs to use. However, this requires 456 SFs to integrate with control plane leading to all the issues as 457 discussed in Section 3.3. Moreover, as discussed in this draft, SFs 458 benefit from focusing on service delivery while leaving the service 459 forwarding decisions to SFFs. 461 This draft requires the service path header to be not updated by non- 462 classifier SFs. In order to enable the SFs to send packets on 463 reverse path while not modifying the service path header, we propose 464 the SF request the SFF to move the packet to the appropriate service 465 path. This is achieved by the use of the critical flag in NSH Base 466 Header and a critical flag in the context header or TLV as shown in 467 Figure 4 and Figure 5. 469 SF that wants to send a packet on the reverse path MUST insert a new 470 CriticalFlags TLV and set the 'C' flag in the NSH Base Header to 1, 471 in case of MD Type-2. The SF MUST set the 'B' flag to 1 to request 472 forwarding of the packet on the reverse path. 474 SFF that receives a NSH packet with 'B' flag set to 1 in case of MD 475 Type-1 or 'C' and 'B' flags set in case of MD Type-2 MUST transition 476 the packet to the reverse path associated with the service path in 477 the received NSH service path header. This transitioning involves 478 SFF updating the NSH service path header to the right SPI and SI 479 based on SFF configuration, policy or state. 481 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 |R|R|B|R|R|R|R|R| Context Header 1 | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Context Header 2 | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Context Header 3 | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Context Header 4 | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 B : Backwards Flag; 493 SF requests packet to be sent on the reverse service path 495 Figure 4: Reverse Path Request Messages with NSH Type-1 497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | STANDARD CLASS |1|CriticalFlags|0|0|0| 0x2 | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 |B| Reserved | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 B : Backwards Flag; 505 SF requests packet to be sent on the reverse service path 507 Figure 5: Reverse Path Request Messages with NSH Type-2 509 4.6. SF Considerations for Spontaneous Packets 511 SFs in most cases process and service NSH packets inline and in 512 direction as a response to receiving the NSH packet from a SFF. 513 However, some SFs generate packets in the middle of a flow 514 spontaneously without receiving any NSH packet from a SFF. This is 515 typical in SFs terminating TCP or proxies that need to act on a timer 516 or an internal event. 518 In order for SFF to process these spontaneous packets, the SFs MUST 519 encapsulate them in NSH, which in turn requires the service path 520 header to be filled with the right SPI and SI. 522 Stateful SFs MUST cache the service path header in the flow state, 523 received in each direction from the SFF, and use the appropriate 524 cached service path header in the NSH encapsulation for sending 525 spontaneous packets. SFs MUST treat the service path header as 526 opaque metadata while caching or encapsulating with NSH. 528 SFs that have no flow-state MUST host a classifier or interact with 529 one to obtain the right content for the service path header. 531 5. Infrastructure Forwarding Example 533 (SFa) (SFb) (SFc) (SFd) 534 . : : . 535 . : : . 536 . : : . 537 . : : . 538 +-------------+ +------+ +------+ 539 [net1]==| Classifier1 |==[net]==| SFF1 |==[net]==| SFF2 |==[net2] 540 +-------------+ +------+ +------+ 542 Figure 6: SFC Infrastructure Overlay Separation Example 544 This section outlines a typical packet flow to show the working of 545 this behavior through an example SPI1 = SFa@SFF1,SFb@SFF1,SFc@SFF2 546 with the topology depicted in Figure 6. 548 1. Packet enters the system via the SFC ingress network (net1) 549 reaching the classifier function 551 2. Classifier determines the SPI and SI as part of classification 553 3. Classifier formulates the NSH infrastructure overlay packet, 554 sets the 'I' flag among other header updates and forwards it 555 onwards to SFF1 557 4. SFF receives the NSH infrastructure overlay packet, skips the 558 decrement operation due to I=1, performs a forwarding lookup to 559 determine the next-hop 561 5. SFF1 determines SFa as the next-hop, formulates the NSH service 562 overlay packet, clears the 'I' flag among other header updates 563 and forwards it onwards to SFa 565 6. SFa services the packet by consuming metadata or producing 566 metadata and forwards the packet back to SFF1 568 7. SFF1 receives the NSH service overlay packet and decrements the 569 SI, due to I=0, before performing a forwarding lookup 571 8. SFF1 determines the next-hop as SFb and the process repeats with 572 SFb as before with SFa, with I=0 574 9. SFF1 receives the SFb serviced packet, decrements the SI due to 575 I=0 and determines the next-hop to be SFc. It sets I=1 and 576 forwards the packet to SFF2 on NSH infrastructure overlay. 578 10. SFF2 receives the packet from SFF1 and repeats the process 579 through SFc similar to the steps for SFa performed by SFF1, by 580 setting I=0 582 11. SFF2 receives the SFc serviced packet, decrements the SI due to 583 I=0 and determines SPI1 is fully executed and proceeds with 584 forwarding on the SFC egress network (net2) 586 6. Infrastructure Forwarding Advantages 588 The following are some of the benefits of separating the SFC overlay 589 into infrastructure overlay and service function overlay. 591 o Constrains the SFC forwarding decisions to SFFs where it belongs, 592 providing meaning to the last 'F' in 'SFF' 594 o Frees the SFs to focus purely on service delivery and avoid 595 complexities associated with forwarding decisions 597 o Enables validation of forwarding state carried in NSH, thereby 598 maintaining the integrity of the forwarding state used to forward 599 the packets along the service path. This removes issues arising 600 from incorrect updates to service path header by SFs, accidentally 601 or otherwise 603 o Allows the service index in NSH packet to be always associated 604 with the service function as indicated by the service index, 605 whether the packet is in transit from SFF to the SF or from SF to 606 the SFF 608 o Allows additional security polices to be enforced between the 609 infrastructure and the service functions by the network operators 611 o Allows snooping tools or any type of middle boxes to clearly tell 612 whether the NSH encapsulated packet is going between SFFs or 613 between SFF and SF (without relying on the source and destination 614 locators), due to the 'I' flag, which is useful in tracing and 615 debugging, especially in cloud deployments 617 o Allows the service chaining control plane to scale independent of 618 the number of service functions 620 7. Acknowledgements 622 The authors would like to thank Abhijit Patra for his guidance and 623 Mike Leske for his review comments. 625 8. IANA Considerations 627 IANA is requested to allocate a "STANDARD" class from the TLV Class 628 registry as already requested in [I-D.kumar-sfc-offloads]. 630 IANA is requested to allocate TLV type with value 0x2 from the 631 STANDARD class TLV registry. The format of the "CriticalFlags" TLV 632 is as defined in this draft, which can further be extended to define 633 new flags in other drafts. 635 +------+-------------+---------------------------------+------------+ 636 | TLV# | Name | Description | Reference | 637 +------+-------------+---------------------------------+------------+ 638 | 2 | Critical | Flags that are critical to SFC | This | 639 | | Flags | functionality | document | 640 +------+-------------+---------------------------------+------------+ 642 Table 1: New TLV in Standard Class Registry 644 9. Security Considerations 646 Separating forwarding decisions from service functions allows for 647 additional constraints to be enforced by the infrastructure 648 controlling the forwarding decisions. This separation enables 649 additional security methods in the infrastructure and does not itself 650 mandate any new security considerations. 652 10. References 654 10.1. Normative References 656 [I-D.ietf-sfc-nsh] 657 Quinn, P. and U. Elzur, "Network Service Header", draft- 658 ietf-sfc-nsh-05 (work in progress), May 2016. 660 [I-D.kumar-sfc-offloads] 661 Surendra, S., Guichard, J., Quinn, P., and J. Halpern, 662 "Service Function Simple Offloads", draft-kumar-sfc- 663 offloads-02 (work in progress), March 2016. 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, 667 DOI 10.17487/RFC2119, March 1997, 668 . 670 10.2. Informative References 672 [I-D.ietf-sfc-architecture] 673 Halpern, J. and C. Pignataro, "Service Function Chaining 674 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 675 in progress), July 2015. 677 [I-D.kumar-sfc-nsh-udp-transport] 678 Surendra, S., Kreeger, L., Majee, S., Haeffner, W., Manur, 679 R., and D. Melman, "UDP Transport for Network Service 680 Header", draft-kumar-sfc-nsh-udp-transport-02 (work in 681 progress), February 2016. 683 Authors' Addresses 685 Surendra Kumar 686 Cisco Systems, Inc 687 170 W. Tasman Dr. 688 San Jose, CA 95134 689 US 691 Email: smkumar@cisco.com 693 Kent Leung 694 Cisco Systems, Inc 695 170 W. Tasman Dr. 696 San Jose, CA 95134 697 US 699 Email: kleung@cisco.com 701 Peter Bosch 702 Cisco Systems, Inc 703 Haarlerbergpark Haarlerbergweg 13-19 704 Amesterdam, NOORD-HOLLAND 1101 CH 705 Netherlands 707 Email: pbosch@cisco.com 709 Dongkee Lee 710 SK Telecom 711 9-1 Sunae-dong, Pundang-gu 712 Sungnam-si, Kyunggi-do 713 South Korea 715 Email: dongkee.lee@sk.com 717 Rajeev Manur 718 Broadcom 720 Email: rmanur@broadcom.com 721 Andrew Dolganow 722 Nokia Corp 723 Block 750 Dune, #06-06 Chai Chee Road 724 Technopark@Chai Chee, Singapore 469004 725 Singapore 727 Email: andrew.dolganow@nokia.com 729 Praveen Muley 730 Nokia Corp 732 Email: praveen.muley@nokia.com 734 Sumandra Majee 735 F5 Networks 736 90 Rio Robles 737 San Jose, CA 95134 738 US 740 Email: S.Majee@F5.com 742 Joel Halpern 743 Ericsson 745 Email: joel.halpern@ericsson.com