idnits 2.17.1 draft-kumar-sfc-offloads-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2016) is 2743 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) == Missing Reference: 'NSH' is mentioned on line 394, but not defined ** Downref: Normative reference to an Informational draft: draft-ietf-sfc-architecture (ref. 'I-D.ietf-sfc-architecture') == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining S. Kumar 3 Internet-Draft J. Guichard 4 Intended status: Standards Track P. Quinn 5 Expires: April 23, 2017 Cisco Systems, Inc. 6 J. Halpern 7 Ericsson 8 S. Majee 9 F5 Networks 10 October 20, 2016 12 Service Function Simple Offloads 13 draft-kumar-sfc-offloads-03 15 Abstract 17 Service Function Chaining (SFC) enables services to be delivered by 18 selective traffic steering through an ordered set of service 19 functions. Once classified into an SFC, the traffic for a given flow 20 is steered through all the service functions of the SFC for the life 21 of the traffic flow even though this is often not necessary. 22 Steering traffic to service functions only while required and not 23 otherwise, leads to shorter SFC forwarding paths with improved 24 latencies, reduced resource consumption and better user experience. 26 This document describes the rationale, techniques and necessary 27 protocol extensions to achieve such optimization, with focus on one 28 such technique termed "simple offloads". 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 23, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 3 67 3. Service Function Path Reduction . . . . . . . . . . . . . . . 4 68 3.1. Bypass . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Simple Offload . . . . . . . . . . . . . . . . . . . . . 5 70 3.2.1. Stateful SFF . . . . . . . . . . . . . . . . . . . . 7 71 3.2.2. Packet Re-ordering . . . . . . . . . . . . . . . . . 7 72 3.2.3. Race Conditions . . . . . . . . . . . . . . . . . . . 8 73 3.2.4. Policy Implications . . . . . . . . . . . . . . . . . 8 74 3.2.5. Capabilities Exchange . . . . . . . . . . . . . . . . 8 75 4. Methods For SFP Reduction . . . . . . . . . . . . . . . . . . 9 76 4.1. SFP In-band Offload . . . . . . . . . . . . . . . . . . . 9 77 4.1.1. Progression Of SFP Reduction . . . . . . . . . . . . 11 78 4.2. Service Controller Offload . . . . . . . . . . . . . . . 12 79 5. Simple Offload Data-plane Signaling . . . . . . . . . . . . . 13 80 5.1. Offload Flags Definition . . . . . . . . . . . . . . . . 14 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 7.1. Standard Class Registry . . . . . . . . . . . . . . . . . 15 84 7.1.1. Simple Offloads TLV . . . . . . . . . . . . . . . . . 15 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 9.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 Service function chaining involves steering traffic flows through a 94 set of service functions in a specific order. Such an ordered list 95 of service functions is called a Service Function Chain (SFC). The 96 actual forwarding path used to realize an SFC is called the Service 97 Function Path (SFP). 99 Service functions forming an SFC are hosted at different points in 100 the network, often co-located with different types of service 101 functions to form logical groupings. Applying a SFC thus requires 102 traffic steering by the SFC infrastructure from one service function 103 to the next until all the service functions of the SFC are applied. 104 Service functions know best what type of traffic they can service and 105 how much traffic needs to be delivered to them to achieve complete 106 delivery of service. As a consequence any service function may 107 potentially request, within its policy constraints, traffic no longer 108 be delivered to it or its function be performed by the SFC 109 infrastructure, if such a mechanism is available. 111 While there are several possible means to achieve this, one of the 112 most flexible, directly connected to functional semantics, is based 113 on allowing service functions themselves to evaluate a particular 114 flow and reflect the result of this evaluation back to the SFC 115 infrastructure. 117 This document outlines the "simple offloads" mechanism that avoids 118 steering traffic to service functions on flow boundary, on request 119 from the service functions, while still ensuring compliance to the 120 instantiated policy that mandates the SFC. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. Definition Of Terms 130 This document uses the following terms. Additional terms are defined 131 in [RFC7498], [I-D.ietf-sfc-architecture] and [I-D.ietf-sfc-nsh]. 133 Service Controller (SC): The entity responsible for managing the 134 service chains, including create/read/update/delete actions as 135 well as programming the service forwarding state in the network - 136 SFP distribution. 138 Classifier (CF): The entity, responsible for selecting traffic as 139 well as SFP, based on policy, and forwarding the selected traffic 140 on the SFP after adding the necessary encapsulation. Classifier 141 is implicitly an SFF. 143 Offload: A request or a directive from the SF to alter the SFP so as 144 to remove the requesting SF from the SFP while maintaining the 145 effect of the removed SF on the offloaded flow. 147 3. Service Function Path Reduction 149 The packet forwarding path of a SFP involves the classifier, one or 150 more SFFs and all the SFs that are part of the SFP. Packets of a 151 flow are forwarded along this path to each of the SFs, for the life 152 of the flow, whether SFs perform the full function in treating the 153 packet or reapply the cached result, from the last application of the 154 function, on the residual packets of the flow. In other words, every 155 packet on the flow incurs the same latency and the end-to-end SFP 156 latency remains more or less constant subject to the nature of the 157 SFs involved. If an SF can be removed from the SFP, for a specific 158 flow, traffic steering to the SF is avoided for that flow; thus 159 leading to a shorter SFP for the flow. When multiple SFs in a SFP 160 are removed, the SFP starts to converge towards the optimum path, 161 incurring a fraction of the latency associated with traversing the 162 SFP. 164 Although SFs are removed from the SFP, the corresponding SFC is not 165 changed - this is subtle but an important characteristic of this 166 mechanism. In other words, this mechanism does not alter the SFC and 167 still uses the SFP associated with the SFC. 169 There are two primary approaches to removing an SF from the SFP. 170 Namely, 172 o Bypass: Mechanism that alters the SFC. Described in this draft 173 for completeness. 175 o Simple Offload: Mechanism that alters the SFP alone, does not 176 affect the SFC. This is the primary focus of this draft. 178 3.1. Bypass 180 Many service functions do not deliver service to certain types of 181 traffic. For instance, typical WAN optimization service functions 182 are geared towards optimizing TCP traffic and add no value to non-TCP 183 traffic. Non-TCP traffic thus can bypass such a service function. 184 Even in the case of TCP, a WAN optimization SF may not be able to 185 service the traffic if the corresponding TCP flow is not seen by it 186 from inception. In such a situation a WAN optimization SF can avoid 187 the overhead of processing such a flow or reserving resources for it, 188 if it had the ability to request such flows not be steered to it. In 189 other words such service functions need the ability to request they 190 be bypassed for a specified flow from a certain time in the life of 191 that flow. 193 A seemingly simple alternative is to require service functions pre 194 specify the traffic flow types they add value to, such as the one- 195 tuple: IP protocol-type described above. A classifier built to use 196 such data exposed by SFs, may thus enable bypassing such SFs for 197 specific flows by way of selecting a different SFC that does not 198 contain the SF being removed. 200 Although knowledge of detailed SF profiles helps SFC selection at the 201 classifier starting the SFC, it leads to shortcomings. 203 o It adds to the overhead of classification at that classifier as 204 all SF classification requirements have to be met by the 205 classifier. 207 o It leads to conflicts in classification requirements between the 208 classifier and the SFs. Classification needs of different SFs in 209 the same SFC may vary. A classifier thus cannot classify traffic 210 based on the classification of one of the SFs in the chain. For 211 instance, even though a flow is uninteresting to one SF on an SFC, 212 it may be interesting to another SF in the same SFC. 214 o The trigger for bypassing an SF may be dynamic as opposed to the 215 static classification at the classifier - it may originate at the 216 SFs themselves and involve the control and policy planes. The 217 policy and control planes may react to such a trigger by 218 instructing the classifier to select a different SFC for the flow, 219 thereby achieving SF bypass. 221 3.2. Simple Offload 223 Service delivery by a class of service functions involves inspecting 224 the initial portion of the traffic and determining whether traffic 225 should be permitted or dropped. In some service functions, such an 226 inspection may be limited to just the five tuple, in some others it 227 may involve protocol headers, and in yet others it may involve 228 inspection of the byte stream or application content based on the 229 policy specified. Firewall service functions fall into such a class, 230 for example. In all such instances, servicing involves determining 231 whether to permit the traffic to proceed onwards or to deny the 232 traffic from proceeding onwards and drop the traffic. In some cases, 233 dropping of the traffic may be accompanied with the generation of a 234 response to the originator of traffic or to the destination or both. 235 Once the service function determines the result - permit or deny (or 236 drop), it simply applies the same result to the residual packets of 237 the flow by caching the result in the flow state. 239 In essence, the effect of service delivery is a PERMIT or a DENY 240 action on the traffic of a flow. This class of service functions can 241 avoid all the overhead of processing such traffic at the SF, by 242 simply requesting another entity in the SFP, to assume the function 243 of performing the action determined by the service function. Since 244 PERMIT and DENY are very simple actions, other entities in the SFP 245 are very likely to be able to perform them on behalf of the 246 requesting SF. A service function can thus offload simple functions 247 to other entities in the SFP. 249 As with PERMIT and DENY actions, there are others which are simple 250 enough to be supported. Some are listed here for illustration. 252 Unidirectional Offload: Client-Server communication, typical of HTTP 253 request-response transactions, imposes higher cost on SFs in one 254 direction. Reponses often carry more bytes, sometimes orders of 255 mangnitude more, as compared to requests. SFs could avoid the 256 cost of moving the bits in the response direction to which it may 257 add no value, once the policy is satisfied, if the response flow 258 can be offloaded. Hence Offloads must be requestable on a 259 unidirectional flow boundary. 261 TCP Control Exception Offload: Most SFs maintain flow state and 262 would like to know when a flow terminates, so SFs can cleanup the 263 flow state and associated resources. Such SFs need to receive 264 the TCP control packets, the ones with control flags [RFC0793] 265 set, on the flow even when the flow itself is offloaded, in order 266 to perform such activity. Hence Offloads must be predicatable to 267 offload all but the TCP control packets of a flow. 269 Time Limited Offload: SF policy may dictate flows be limited to 270 certain period of time among other reasons to optimize SF load. 271 SFs can request a flow be offloaded for a specific time duration 272 after which, all traffic on that flow gets redirected to the SF 273 as was done before the offload was initiated. Hence Offloads 274 must be requestable on a time limit. 276 Volume Limited Offload: As with time limited offlaods, SF policy may 277 dictate flows be limited to certain volume of data. SFs can 278 request a flow be offloaded until a specified number of bytes 279 traverse the flow. Hence Offloads must be requestable on a 280 volume limit. 282 Since SFF is the one steering traffic to the SFs and hence is on the 283 SFP, it is a natural entity to assume the offload function. A SF not 284 interested in traffic being steered to it can simply perform a simple 285 offload by indicating a PERMIT action along with an OFFLOAD request. 286 The SFF responsible for steering the traffic to the SF takes note of 287 the ACTION and offload request. The OFFLOAD directive and the ACTION 288 received from the requesting SF are cached against the SF for that 289 flow. Once cached, residual packets on the flow are serviced by the 290 cached directive and action as if being serviced by the corresponding 291 SF. 293 3.2.1. Stateful SFF 295 SFFs are the closest SFC infrastructure entities to the service 296 functions. SFFs may be state-full and hence can cache the offload 297 and action in both of the unidirectional flows of a connection. As a 298 consequence, action and offload become effective on both the flows 299 simultaneously and remain so until cancelled or the flow terminates. 301 SFFs may not always honor the offload requests received from SFs. 302 This does not affect the correctness of the SFP in any way. It 303 implies that the SFs can expect traffic to arrive on a flow, which it 304 offloaded, and hence must service them, which may involve requesting 305 an offload again. It is natural to think of an acknowledgement 306 mechanism to provide offload guarantees to the SFs but such a 307 mechanism just adds to the overhead while not providing significant 308 benefit. Offload serves as a best effort mechanism. 310 3.2.2. Packet Re-ordering 312 The simple offload mechanism creates short time-windows where packet 313 re-ordering may occur. While SFs request flows be offloaded to SFFs, 314 packets may still be in flight at various points along the SFP, 315 including some between the SFF and the SF. Once the offload decision 316 is received and committed into the flow entry at the SFF, any packets 317 arriving after and destined to the offloading SF are treated to the 318 offload decision and forwarded along (if it is a PERMIT action). 319 Inflight packets to the offloading SF may arrive at the SFF after one 320 or more packets are already treated to the offload decision and 321 forwarded along. 323 This is a transitional effect and may not occur in all cases. For 324 instance, if the decision to offload a flow by an SF is based on the 325 first packet of TCP flow, a reasonable time window exists between the 326 offload action being committed into the SFF and arrival of subsequent 327 packet of the same flow at that SFF. Likewise, request/response 328 based protocols such as HTTP may not always be subject to the re- 329 ordering effects. 331 3.2.3. Race Conditions 333 The tuple that make up an end-to-end flow or connection, such as a 334 five tuple TCP connection, may be reused in a very short span of time 335 when very high performing end points are involved. A very remote 336 manifestation of this behavior may involve the wrong incarnation of a 337 flow at the SFF receiving the flow offload request from a SF. 339 Implementations of simple offloads must thus be aware of such a 340 possibility and include appropriate measures to address it. It is 341 important to note that a SFF must maintain correctness and hence it 342 is acceptable to not honor a simple offloads request to resolve such 343 an occurrence. After all SFs exist with right security posture to 344 protect against malicious traffic. 346 A simple and widely used method to serialize reuse of tuples is to 347 use an incarnation number in addition to the five-tuple. The 348 steering SFF can pass an opaque cookie, which in its simplest form 349 could be the incarnation number, that is preserved by the SF and 350 passed along with the simple offload request. SFF can thus correctly 351 identify the right incarnation of the flow. SYN detection at the SFF 352 to take corrective action is another option. The SFF implementations 353 may employ any technique deemed appropriate. 355 3.2.4. Policy Implications 357 Offload mechanism may be controlled by the policy layer. The SFs 358 themselves may have a static policy to utilize the capability offered 359 by the SFC infrastructure. They could also be dynamic and controlled 360 by the specific policy layer under which the SFs operate. 362 Similarly, the SFC infrastructure, specifically the classifiers and 363 the SFFs, may be under the SFC infrastructure control plane policy 364 controlling the decision to honor offloads from an SF. This policy 365 in turn may be coarse-grain, at the SF level, and hence static. It 366 can also be fine grain and hence dynamic but it adds to the overhead 367 of policy distribution. 369 Policy model related to offloads is out of scope of this document. 371 3.2.5. Capabilities Exchange 373 Simple offloads can be exposed and negotiated a priori as a 374 capability between the SFFs and the SFs or the corresponding control 375 layers. In the simplest of the implementations, this is provided by 376 the SFC infrastructure and the SFs are statically configured to 377 utilize them without capabilities negotiation, within the constraints 378 of the SF specific policies. 380 Capabilities exchange is outside the scope of this document. 382 4. Methods For SFP Reduction 384 There are a number of different models that may be used to facilitate 385 SFP shortening. 387 The methods discussed in the following sections require signaling 388 among the participant components to communicate offload and permit/ 389 deny actions. The signaling may be performed in the data-plane or in 390 the control plane. 392 a. Data-plane: A SFC specific communication channel is needed for 393 SFs to communicate the offload request along with the SF treated 394 packet. [NSH] defines a header specifically for carrying SFP 395 along with metadata and provides such a channel for use with 396 offloads. Necessary bits need to be allocated in NSH to convey 397 the action as well as the offload directive. This signaling may 398 be limited to SF and SFF or may continue from one SFF to another 399 SFF or the classifier. It may also involve signaling directly 400 from the SF to the classifier. 402 b. Control-plane: Messages are required between the SF and the 403 service controller as well as between the SFF and the service 404 controller. Service controller messaging is out of scope of this 405 document and it is assumed to be service controller specific, 406 which may include open or standard interfaces. 408 4.1. SFP In-band Offload 410 SFs receive traffic on an overlay from the SFF. SFs service the 411 traffic and turn them back to the SFF on an overlay or forward the 412 traffic on the underlay. In the former case, along with returning 413 the traffic to SFF, they can perform simple offload by signaling 414 OFFLOAD and ACTION to the SFF. SFF caches the OFFLOAD and ACTION 415 while forwarding the serviced packet onwards to the next service hop 416 on the SFP or dropping it as per the ACTION. This may continue from 417 one hop to the next on the SFP. SFF can now enforce the OFFLOAD and 418 ACTION on the residual packets of the flow. 420 By performing such hop-by-hop offloads, SFP can be reduced from its 421 original length, steering traffic to only the SFFs and the SFs that 422 really need to see the traffic. 424 Figure 1 to Figure 3 show an example of SF and SFF performing offload 425 operations, with PERMIT action, and the effect thereafter on the SFP. 427 SFID(1) SFID(2) SFID(3) 428 +------+ +------+ +------+ 429 ....| SF1 |.... ....| SF2 |.... ....| SF3 |.... 430 . +------+ . . +------+ . . +------+ . 431 . | . . | . . | . 432 . | . . | . . | . 433 . | . . | . . | . 434 . | . . | . . | . 435 . | . . | . . | . 436 +----+ . +------+ . . +------+ . . +------+ . 437 | CF |------| SFF1 |-----------| SFF2 |-----------| SFF3 |------ Net 438 +----+ . +------+ . . +------+ . . +------+ . 439 . . . . . . 440 SFP1 ... ..... ..... ... > 442 SFC1 = {SF1, SF2, SF3} 443 SFC1 -> SFP1 445 Where, 446 SFC1 is a service function chain 447 SF1, SF2 and SF3 are three service functions 448 SFP1 is the servcie function path for SFC1 449 CF is the classifier starting SFP1 based on policy 451 Note: Network forwarders are omitted from the figure for simplicity 453 Figure 1: SFC1 with corresponding SFP1 454 O 455 f 456 SFID(1) f +- SFID(2) SFID(3) 457 +------+ l | +------+ +------+ 458 ....| SF1 |.... o | | SF2 | ....| SF3 |.... 459 . +------+ . a | +------+ . +------+ . 460 . | . d | | . | . 461 . | . | | . | . 462 . | . | | . | . 463 . | . v | . | . 464 . | . | . | . 465 +----+ . +------+ . +------+ . +------+ . 466 | CF |------| SFF1 |-----------| SFF2 |-----------| SFF3 |----- Net 467 +----+ . +------+ . +------+ . +------+ . 468 . . . . 469 SFP1 ... ........................ ... > 471 Figure 2: SFP1 after SFID(2) performs an Offload 473 O O 474 f f 475 f +- SFID(1) SFID(2) f +- SFID(3) 476 l | +------+ +------+ l | +------+ 477 o | | SF1 | | SF2 | o | | SF3 | 478 a | +------+ +------+ a | +------+ 479 d | | | d | | 480 | | | | | 481 | | | | | 482 v | | v | 483 | | | 484 +----+ +------+ +------+ +------+ 485 | CF |------| SFF1 |-----------| SFF2 |-----------| SFF3 |----- Net 486 +----+ +------+ +------+ +------+ 487 SFP1 .......................................................... > 489 Figure 3: SFP1 after SFID(1) and SFID(3) perform Offloads 491 4.1.1. Progression Of SFP Reduction 493 SFP reduction happens one SFF at a time: by collapsing the SFF-to-SF 494 hops into the SFF or the SFC infrastructure. 496 Figure 1 to Figure 3 show one sequence of offload events that lead to 497 a shorter SFP. 499 Corresponding transformation of the actual forwarding path is 500 captured by the states below. 502 Stage-1: Prior to any offloads, service function path SFP1 503 (corresponding to SFC1) has the following actual forwarding path 504 as shown in Figure 1: 505 CF -> 506 SFF1 -> SF1 -> SFF1 -> 507 SFF2 -> SF2 -> SFF2 -> 508 SFF3 -> SF3 -> SFF3 -> 510 Stage-2: After SF2 performs a simple offload, service function path 511 SFP1 changes to the one represented below, as also shown in 512 Figure 2: 513 CF -> 514 SFF1 -> SF1 -> SFF1 -> 515 SFF2 -> 516 SFF3 -> SF3 -> SFF3 -> 518 Stage-3: After SF1 and SF3 both perform simple offloads, service 519 function path SFP1 changes to the one represented below, as also 520 show in Figure 3: 521 CF -> 522 SFF1 -> 523 SFF2 -> 524 SFF3 -> 526 When all the SFs in a SFP perform offloads the forwarding path is 527 reduced to pass through just the SFFs. 529 4.2. Service Controller Offload 531 Each SF signals the service controller of the OFFLOAD and ACTION via 532 control plane messaging for a specific flow. The service controller 533 then signals the appropriate SFFs to offload the requested SFs, there 534 by achieving the hop-by-hop offload behavior. 536 The service controller has full knowledge of all the SFs of the SFP 537 offloading the flow and hence can determine the optimum SFP within 538 the Service Controller and program the appropriate SFFs to achieve 539 SFP optimization. 541 5. Simple Offload Data-plane Signaling 543 Since Offload and action are signaled at the time of returning the 544 traffic to SFF, post servicing the traffic, such signaling can be 545 integrated into the SFC service header of the packet. 547 Figure 4 and Figure 5 show the bits necessary to achieve the 548 signaling using the SFC encapsulation as described in 549 [I-D.ietf-sfc-nsh]. In particular, for NSH MD-Type1 header format, 550 the offload bits are communicated via the flags field in the very 551 first byte of the fixed context headers. For NSH MD-Type2 header 552 format, the offload bits are communicated via a new standard TLV - 553 Simple Offload TLV. The standard TLV is requested to be allocated 554 from the TLV Class, "Standard Class", from the IANA. 556 By integrating the signaling with the packets, the simple offloads 557 scale with the traffic in the data plane. 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 |D| F |X| Context Header 1 | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 |B|U|T|D|R|R|R|R| Context Header 2 | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Context Header 3 | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Context Header 4 | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 X : Extend flags into first byte of "Context Header 2" 571 B : Bidirectional Offload 572 U : Unidirectional Offload 573 T : TCP-control Exception Offload 574 D : Drop Offload 576 Figure 4: NSH Type-1 Offload Bits shown for DC Allocation 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | STANDARD CLASS | SimpleOffload |0|0|0| 0x2 | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 |B|U|T|D|S|V|R|R|R|R|R|R| Offload-data | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 B : Bidirectional Offload 586 U : Unidirectional Offload 587 T : TCP-control Exception Offload 588 D : Drop Offload 589 S : Time Limited Offload 590 V : Volume Limited Offload 592 Figure 5: NSH Type-2 Offload Bits 594 5.1. Offload Flags Definition 596 Offload Control Flags: 598 B, Bidirectional Offload: SF requests both flows in the connection, 599 described by the payload, be offloaded, by setting B=1. B=0 600 otherwise. 602 U, Unidirectional Offload: SF requests only the current flow in the 603 connection, described by the payload, be offloaded, by setting 604 U=1. U=0 otherwise. 606 One and only one of 'B' and 'U' MUST be specified to indicate 607 offload. In the event a NSH encapsulated packet is received with 608 both 'B' and 'U' offload flags set to 1, 'B' MUST take precedence. 610 Offload Function Flags: 612 B|U, Permit Offload: When either B=1 or U=1, the implicit function 613 is to PERMIT or allow all packets on the flow(s) to traverse 614 along the SFP, unless over-ridden by other functional flags. 616 D, Drop Offload: Setting D=1, requests packets on the offloaded 617 flow(s) be dropped; D MUST be set to 0 otherwise. D=1 modifies 618 the default PERMIT behavior of 'B' and 'U' flags. 620 T, TCP-control Exception Offload: Setting T=1 requests TCP control 621 packets to be exempted from Offload behavior. TCP control 622 packets MUST continue to be forwarded to the SF while the rest of 623 the packets must be allowed to bypass the SF contingent upon the 624 application of other offload flags. T MUST be set to 0 625 otherwise. 627 S, Time Limited Offload: Setting S=1 requests the flow(s) to be 628 offloaded for the duration specified, in seconds, in offload-data 629 field. After that duration, offload behavior must be cancelled 630 and affected flow(s) MUST be redirected to the SF. S MUST be set 631 to 0 otherwise. 633 V, Volume Limited Offload: Setting V=1 requests the flow(s) to be 634 offloaded until the volume of data specified, in Kilo Bytes, in 635 offload-data field has traversed the flow(s). After that volume 636 of data has traversed, offload behavior must be cancelled and 637 affected flow(s) MUST be redirected to the SF. V MUST be set to 638 0 otherwise. 640 6. Acknowledgements 642 The authors would like to thank Abhjit Patra, Nagaraj Bagepalli, Kent 643 Leung, Erik Nordmark, Diego Lopez for their comments, thoughtful 644 questions and suggestions, review, etc. 646 7. IANA Considerations 648 7.1. Standard Class Registry 650 IANA is requested to allocate a "STANDARD" class from the TLV Class 651 registry. Allocation of the registry values under this class shall 652 follow the "IETF Review" policy defined in RFC 5226 [RFC5226]. 654 7.1.1. Simple Offloads TLV 656 IANA is requested to allocate TLV type with value 0x1 from the 657 STANDARD TLV class registry. The format of the "Simple Offloads" TLV 658 is as defined in this draft. 660 +------+-----------------+------------------------+---------------+ 661 | TLV# | Name | Description | Reference | 662 +------+-----------------+------------------------+---------------+ 663 | 1 | Simple Offloads | SF Flow Offload to SFF | This document | 664 +------+-----------------+------------------------+---------------+ 666 Table 1: Standard Class Registry 668 8. Security Considerations 670 Security of the offload signaling mechanism is very important. This 671 document does not advocate any additional security mechanisms beyond 672 the data plane and control plane signaling security mechanisms. 674 9. References 676 9.1. Normative References 678 [I-D.ietf-sfc-architecture] 679 Halpern, J. and C. Pignataro, "Service Function Chaining 680 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 681 in progress), July 2015. 683 [I-D.ietf-sfc-nsh] 684 Quinn, P. and U. Elzur, "Network Service Header", draft- 685 ietf-sfc-nsh-10 (work in progress), September 2016. 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, 689 DOI 10.17487/RFC2119, March 1997, 690 . 692 9.2. Informative References 694 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 695 RFC 793, DOI 10.17487/RFC0793, September 1981, 696 . 698 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 699 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 700 DOI 10.17487/RFC5226, May 2008, 701 . 703 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 704 Service Function Chaining", RFC 7498, 705 DOI 10.17487/RFC7498, April 2015, 706 . 708 Authors' Addresses 710 Surendra Kumar 711 Cisco Systems, Inc. 712 170 W. Tasman Dr. 713 San Jose, CA 95134 715 Email: smkumar@cisco.com 716 Jim Guichard 717 Cisco Systems, Inc. 719 Email: jguichar@cisco.com 721 Paul Quinn 722 Cisco Systems, Inc. 724 Email: paulq@cisco.com 726 Joel Halpern 727 Ericsson 729 Email: joel.halpern@ericsson.com 731 Sumandra Majee 732 F5 Networks 733 90 Rio Robles 734 San Jose, CA 735 US 737 Email: S.Majee@F5.com