idnits 2.17.1 draft-ietf-sfc-nsh-ecn-support-05.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 == Line 276 has weird spacing: '... sender doma...' == Line 277 has weird spacing: '...ingress v |...' -- The document date (April 2, 2021) is 1113 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) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Eastlake 2 Intended status: Proposed Standard Futurewei Technologies 3 B. Briscoe 4 Independent 5 Y. Li 6 Huawei Technologies 7 A Malis 8 Malis Consulting 9 X. Wei 10 Huawei Technologies 11 Expires: October 1, 2021 April 2, 2021 13 Explicit Congestion Notification (ECN) and Congestion Feedback 14 Using the Network Service Header (NSH) and IPFIX 15 17 Abstract 19 Explicit congestion notification (ECN) allows a forwarding element to 20 notify downstream devices of the onset of congestion without having 21 to drop packets. Coupled with a means to feed information about 22 congestion back to upstream nodes, this can improve network 23 efficiency through better congestion control, frequently without 24 packet drops. This document specifies ECN and congestion feedback 25 support within a Service Function Chaining (SFC) architecture domain 26 through use of the Network Service Header (NSH, RFC 8300) and IP Flow 27 Information Export (IPFIX, RFC 7011). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Distribution of this document is unlimited. Comments should be sent 35 to the SFC Working Group mailing list or to the 36 authors. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 49 Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Table of Contents 54 1. Introduction............................................4 55 1.1 NSH Background.........................................4 56 1.2 ECN Background.........................................6 57 1.3 Tunnel Congestion Feedback Background..................6 58 1.4 Conventions Used in This Document......................8 60 2. The NSH ECN Field......................................10 62 3. ECN Support in the NSH.................................12 63 3.1 At The Ingress........................................13 64 3.2 At Transit Nodes......................................14 65 3.2.1 At NSH Transit Nodes................................14 66 3.2.2 At an SF/Proxy......................................15 67 3.2.3 At Other Forwarding Nodes...........................15 68 3.3 At Exit/Egress........................................16 69 3.4 Conservation of Packets...............................16 71 4. Tunnel Congestion Feedback Support.....................18 72 4.1 Congestion Level Measurement..........................18 73 4.3 Congestion Information Delivery.......................19 74 4.3 IPFIX Extensions......................................21 75 4.3.1 nshServicePathID....................................21 76 4.3.2 tunnelEcnCeCeByteTotalCount.........................21 77 4.3.3 tunnelEcnEctNectBytetTotalCount.....................22 78 4.3.4 tunnelEcnCeNectByteTotalCount.......................22 79 4.3.5 tunnelEcnCeEctByteTotalCount........................22 80 4.3.6 tunnelEcnEctEctByteTotalCount.......................23 81 4.3.7 tunnelEcnCEMarkedRatio..............................23 83 5. Example of Use.........................................24 85 6. IANA Considerations....................................27 86 6.1 SFC NSH Header ECN Bits...............................27 87 6.2 IPFIX Information Element IDs.........................27 89 7. Security Considerations................................29 90 8. Acknowledgements.......................................29 92 Normative References......................................30 93 Informative References....................................31 95 Authors' Addresses........................................32 97 1. Introduction 99 Explicit Congestion Notification (ECN [RFC3168]) allows a forwarding 100 element to notify downstream devices of the onset of congestion 101 without having to drop packets. Coupled with a means to feed 102 information about congestion back to upstream nodes, this can improve 103 network efficiency through better congestion control, frequently 104 without packet drops. This document specifies ECN and congestion 105 feedback support within a Service Function Chaining (SFC [RFC7665]) 106 architecture domain through use of the Network Service Header (NSH 107 [RFC8300]) and IP Flow Information Export (IPFIX [RFC7011]). 109 It requires that all ingress and egress nodes of the SFC domain 110 implement ECN. While congestion management will be the most effective 111 if all interior nodes of the SFC domain implement ECN, some benefit 112 is obtained even if some interior nodes do not implement ECN. 113 Congestion at any interior bottleneck where ECN marking is not 114 implemented will be unmanaged. 116 The subsections below in this section provide background information 117 on NSH, ECN, congestion feedback, and terminology used in this 118 document. 120 1.1 NSH Background 122 The Service Function Chaining (SFC [RFC7665]) architecture calls for 123 the encapsulation of traffic within a service function chaining 124 domain with a Network Service Header (NSH [RFC8300]) added by the 125 "Classifier" (ingress node) on entry to the domain and the NSH being 126 removed on exit from the domain at the egress node. The NSH is used 127 to control the path of a packet in an SFC domain. The NSH is a 128 natural place, in a domain where traffic is NSH encapsulated, to note 129 congestion, avoiding possible confusion due, for example, to changes 130 in the outer transport header in different parts of the domain. 132 | 133 v 134 +----------+ 135 . .|Classifier|. . . . . . . . . . . . . . 136 . +----------+ . 137 . | +----+ . 138 . | --+ SF | Service . 139 . | / +----+ Function . 140 . v --- Chaining . 141 . +-----+/ +----+ domain . 142 . | SFF |--------+ SF | . 143 . +-----+\ +----+ . 144 . | --- . 145 . | \ +----+ . 146 . | --+ SF | . 147 . v +----+ . 148 . +-----+ +----+ . 149 . | SFF |-----------------+ SF | . 150 . +-----+ +----+ . 151 . | +----+ . 152 . | --+ SF | . 153 . | / +----+ . 154 . v --- . 155 . +-----+/ +----+ . 156 . | SFF |--------+ SF | . 157 . +-----+\ +----+ . 158 . | --- . 159 . | \ +----+ . 160 . | --+ SF | . 161 . v +----+ . 162 . +------+ . 163 . . .| Exit |. . . . . . . . . . . . . . . 164 +------+ 165 | 166 v 168 Figure 1. Example SFC Path Forwarding Nodes 170 Figure 1 shows an SFC domain for the purpose of illustrating the use 171 of the NSH. Traffic passes through a sequence of Service Function 172 Forwarders (SFFs) each of which sends the traffic to one or more 173 Service Functions (SFs). Each SF performs some operation on the 174 traffic, for example firewall or Network Address Translation (NAT) or 175 load balancer, and then returns it to the SFF from which it was 176 received. 178 Logically, during the transit of each SFF, the outer transport header 179 that got the packet to the SFF is stripped (see Figure 3), the SFF 180 decides on the next forwarding step, either adding a new transport 181 header or, if the SFF is the exit/egress, removing the NSH header. 182 The transport headers added may be different in different regions of 183 the SFC domain. For example, IP could be used for some SFF-to-SFF 184 communication and MPLS used for other such communication. 186 1.2 ECN Background 188 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 189 element (such as a router or a Service Function Forwarder (SFF) or 190 Service Function (SF)) to notify downstream devices of the onset of 191 congestion without having to drop packets. This can be used as an 192 element in active queue management (AQM) [RFC7567] to improve network 193 efficiency through better traffic control without packet drops. The 194 forwarding element can explicitly mark some packets in an ECN field 195 instead of dropping the packet. For example, a two-bit field is 196 available for ECN marking in IP headers [RFC3168]. 198 1.3 Tunnel Congestion Feedback Background 200 Tunnels are widely deployed in various networks including data center 201 networks, enterprise network, and the public Internet. A tunnel 202 consists of ingress, egress, and a set of intermediate nodes 203 including routers. Tunnel Congestion Feedback (Section 4) is a 204 building block for congestion mitigation methods. It supports 205 feedback of congestion information from an egress node to an ingress 206 node. This document treats the SFC domain as a tunnel with the 207 initial Classifier node being the ingress; however, the Tunnel 208 Congestion Feedback facilities specified in this document MAY be used 209 in other contexts besides SFC domains. 211 Examples of actions that can be taken by an ingress node when it has 212 knowledge of downstream congestion include those listed below. 213 Details of implementing these traffic control methods, beyond those 214 given here, are outside the scope of this document. 216 Any action by a tunnel ingress to reduce congestion needs to allow 217 sufficient time for the end-to-end congestion control loop to respond 218 first, otherwise the system could go unstable. For instance by the 219 ingress taking a smoothed average of the level of congestion signaled 220 by feedback from the tunnel egress or delaying any action for at 221 least the worst case global round trip time (for example 100 222 milliseconds). 224 (1) Traffic throttling (policing), where the downstream traffic 225 flowing out of the ingress node is limited to reduce or eliminate 226 congestion. 228 (2) Upstream congestion feedback, where the ingress node sends 229 messages upstream to or towards the ultimate traffic source, a 230 function that can throttle traffic generation/transmission. 232 (3) Traffic re-direction, where the ingress node configures the NSH 233 of some future traffic so that it avoids congested paths. Great 234 care must be taken with this option to avoid (a) significant re- 235 ordering of traffic in flows that it is desirable to keep in 236 order and (b) oscillation/instability in traffic paths due to 237 alternate congestion of previously idle paths and the idling of 238 previously congested paths. For example, it is preferable to 239 classify traffic into flows of a sufficiently coarse granularity 240 that the flows are long lived and then use a stable path per 241 flow, sending only newly appearing flows on apparently 242 uncongested paths. 244 Figure 2 shows an example path from an original sender to a final 245 receiver passing through an example chain of service functions 246 between the ingress and egress of an SFC domain. The path is also 247 likely to pass through other network nodes outside the SFC domain 248 (not shown) before entering the SFC domain and after leaving the SFC 249 domain. 251 The figure shows typical congestion feedback that would be expected 252 from the final receiver to the origin sender, which controls the load 253 the origin sender applies to all elements on the path. The figure 254 also shows the congestion feedback from the egress to the ingress of 255 the SFC domain that is described in this document, to control or 256 balance load within the SFC domain. 258 .:= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = :. 259 _||_ End-to-End Congestion Feedback || 260 \ / || 261 \/ || 262 __ Inner Transport Header and Payload __ 263 | | ->- - - - - - - - - - - - - - ->- - - - - -- - - - - - ->- | | 264 | | | | 265 | | .:= = = = = = = = = = = = = = = = = = = = = =:. | | 266 | | _||_ Tunnel Congestion Feedback || | | 267 | | \ / || | | 268 | | \/ || | | 269 | | __ NSH __ | | 270 | | | |-------------------------->--------------| | | | 271 | |. . . | | ___ ___ ___ | |. . .| | 272 | | | | OT1 | | OT4 | | . . . | | OTn | | | | 273 | | | |-->--|SFF|--->---|SFF| |SFF|-->--| | | | 274 |__| |__| |___| |___| |___| |__| |__| 275 origin SFC | ^ | ^ SFC final 276 sender domain OT2| |OT3 OT6| |OT7 domain rcvr 277 ingress v | v | egress 278 +---+ +---+ 279 |SF | |SF | 280 +---+ +---+ 282 Figure 2. Congestion Feedback across an SFC Domain 284 SFC Domain congestion feedback in Figure 2 is shown within the 285 context of an end-to-end congestion feedback loop. Also shown is the 286 encapsulated layering of NSH headers within a series of outer 287 transport headers (OT1, OT2, ... OTn). 289 1.4 Conventions Used in This Document 291 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 292 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 293 "OPTIONAL" in this document are to be interpreted as described in BCP 294 14 [RFC2119] [RFC8174] when, and only when, they appear in all 295 capitals, as shown here. 297 Acronyms: 299 AQM - Active Queue Management [RFC7567] 301 CE - Congestion Experienced [RFC3168] 303 downstream - The direction from ingress to egress 304 ECN - Explicit Congestion Notification [RFC3168] 306 ECT - ECN Capable Transport [RFC3168] 308 IPFIX - IP Flow Information Export [RFC7011] 310 Not-ECT - Not ECN-Capable Transport [RFC3168] 312 NSH - Network Service Header [RFC8300] 314 SF - Service Function [RFC7665] 316 SFC - Service Function Chaining [RFC7665] 318 SFF - Service Function Forwarder [RFC7665] - A type of node that 319 forwards based on the NSH. 321 TLV - Type Length Value 323 upstream - The direction from egress to ingress 325 2. The NSH ECN Field 327 The NSH header is used to encapsulate and control the subsequent path 328 of traffic (see Section 2 of [RFC8300]). The NSH also provides for 329 optional metadata inclusion, as shown in Figure 3. 331 +-----------------------------------+ 332 | Outer Transport Header | 333 +-----------------------------------+ 334 | Network Service Header (NSH) | 335 | +------------------------------+ | 336 | | Base Header | | 337 | +------------------------------+ | 338 | | Service Path Header | | 339 | +------------------------------+ | 340 | | Metadata (Context Header(s)) | | 341 | +------------------------------+ | 342 +-----------------------------------+ 343 | Original Packet / Frame / Payload | 344 +-----------------------------------+ 346 Figure 3. Data Encapsulation with the NSH 348 Two currently unused bits (indicated by "U") in the NSH Base Header 349 (Section 2.2 of [RFC8300]) are allocated for ECN indication as shown 350 in Figure 4. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 ^ ^ 358 | | 359 +-------+ 360 |NSH ECN| 361 | field | 362 +-------+ 364 Figure 4. NSH Base Header 366 Note to RFC Editor: The above figure should be adjusted based on the 367 bits assigned by IANA (see Section 5) and this note deleted. 369 Table 1 shows the meaning of the code points in the NSH ECN field. 370 These have the same meaning as the ECN field code points in the IPv4 371 or IPv6 header as defined in [RFC3168]. 373 Binary Name Meaning 374 ------ ------- -------------------------------- 375 00 Not-ECT Not ECN-Capable Transport 376 01 ECT(1) ECN-Capable Transport 377 10 ECT(0) ECN-Capable Transport 378 11 CE Congestion Experienced 380 Table 1. ECN Field Code Points 382 3. ECN Support in the NSH 384 This section describes the required behavior to support ECN using the 385 NSH. There are two aspects to ECN support: 386 1. ECN propagation during encapsulation or decapsulation 387 2. ECN marking during congestion at bottlenecks. 389 While this section covers all combinations of ECN-aware and ECN- 390 unaware, it is expected that in most cases the NSH domain will be 391 uniform so that, if this document is applicable, all SFFs will 392 support ECN; however, some legacy SFs might not support ECN. 394 ECN Propagation: 396 The specification of ECN tunneling [RFC6040] explains that an 397 ingress must not propagate ECN support into an encapsulating 398 header unless the egress supports correct onward propagation of 399 the ECN field during decapsulation. We define Compliant ECN 400 Decapsulation here as decapsulation compliant with either 401 [RFC6040] or an earlier compatible equivalent ([RFC4301], or the 402 full functionality mode of [RFC3168]). 404 The procedures in Section 3.2.1 ensure that each ingress of the 405 large number of possible transport links within the SFC domain 406 does not propagate ECN support into the encapsulating outer 407 transport header unless the corresponding egress of that link 408 supports Compliant ECN Decapsulation. 410 Section 3.3 requires that all the egress nodes of the SFC domain 411 support Compliant ECN Decapsulation in conjunction with tunnel 412 congestion feedback, otherwise the scheme in this document will 413 not work. 415 ECN Marking: 417 At transit nodes the marking behavior specified in Section 3.2.1 418 is recommended and if not implemented at such transit nodes, there 419 may be unmanaged congestion. 421 Detection of congestion will be most effective if ECN marking is 422 supported by all potential bottlenecks inside the domain in which 423 NSH is being used to route traffic as well as at the ingress and 424 egress. Nodes that do not support ECN marking, or that support 425 AQM but not ECN, will naturally use drop to relieve congestion. 426 The gap in the end-to-end packet sequence will be detected as 427 congestion by the final receiving endpoint, but not by the NSH 428 egress (see Figure 2). 430 3.1 At The Ingress 432 When the ingress/Classifier encapsulates an incoming IP packet with 433 an NSH, it MUST set the NSH ECN field using the "Normal mode" 434 specified in [RFC6040] (i.e., copied from the incoming IP header). 436 Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD 437 set it to ECT(0). This indicates that, even though the end-to-end 438 transport is not ECN-capable, the egress and ingress of the SFC 439 domain are acting as an ECN-capable transport. This approach will 440 inherently support all known variants of ECN, including the 441 experimental L4S capability [RFC8311] [ecnL4S]. 443 Packets arriving at the ingress might not use IP. If the protocol of 444 arriving packets supports an ECN field similar to IP, the procedures 445 for IP packets can be used. If arriving packets do not support an ECN 446 field similar to IP, they MUST be treated as if they are Not-ECT IP 447 packets. 449 Then, as the NSH encapsulated packet is further encapsulated with a 450 transport header, if ECN marking is available for that transport (as 451 it is for IP [RFC3168] and MPLS [RFC5129]), the ECN field of the 452 transport header MUST be set using the "Normal mode" specified in 453 [RFC6040] (i.e., copied from the NSH ECN field). 455 A summary of these normative steps is given in Table 2. 457 +-----------------+---------------+ 458 | Incoming Header | Departing NSH | 459 | (also equal to | and Outer | 460 | departing Inner | Headers | 461 | Header) | | 462 +-----------------+---------------+ 463 | Not-ECT | ECT(0) | 464 | ECT(0) | ECT(0) | 465 | ECT(1) | ECT(1) | 466 | CE | CE | 467 +-----------------+---------------+ 469 Table 2. Setting of ECN fields by an ingress/Classifier 471 The requirements in this section apply to all ingress nodes for the 472 domain in which NSH is being used to route traffic. 474 3.2 At Transit Nodes 476 This section described behavior at nodes that forward based on the 477 NSH such as SFF and other forwarding nodes such as IP routers. Figure 478 5 shows a packet on the wire between forwarding nodes. 480 +-----------------+ 481 | Outer Header | 482 +-----------------+ 483 | NSH | 484 +-----------------+ 485 | Inner Header | 486 +-----------------+ 487 | Payload | 488 +-----------------+ 490 Figure 5. Packet in Transit 492 3.2.1 At NSH Transit Nodes 494 When a packet is received at an NSH based forwarding node such as an 495 SFF, say N1, the outer transport encapsulation is removed and its ECN 496 marking SHOULD be combined into the NSH ECN marking as specified in 497 [RFC6040]. If this is not done, any congestion encountered at non-NSH 498 transit nodes between N1 and the next upstream NSH based forwarding 499 node will be lost and not transmitted downstream. 501 The NSH forwarding node SHOULD use a recognized AQM algorithm 502 [RFC7567] to detect congestion. If the NSH ECN field indicates ECT, 503 it will probabilistically set the NSH ECN field to the Congestion 504 Experienced (CE) value or, in cases of extreme congestion, drop the 505 packet. 507 When the NSH encapsulated packet is further encapsulated for 508 transmission to the next SFF or SF, ECN marking behavior depends on 509 whether or not the node that will decapsulate the outer header 510 supports Compliant ECN Decapsulation (see Section 3). If it does, 511 then the encapsulating node propagates the NSH ECN field to this 512 outer encapsulation using the "Normal Mode" of ECN encapsulation 513 [RFC6040] (the ECN field is copied). If it does not, then the 514 encapsulating node MUST clear ECN in the outer encapsulation to non- 515 ECT (the "Compatibility Mode" of [RFC6040]). 517 3.2.2 At an SF/Proxy 519 If the SF is NSH and ECN-aware, the processing is essentially the 520 same at the SF as at an SFF as discussed in Section 3.2.1. 522 If the SF is NSH-aware but ECN-unaware, then the SFF transmitting the 523 packet to the SF will use Compatibility Mode. Congestion encountered 524 in the SFF to SF and SF to SFF paths will be unmanaged. 526 If the SF is not NSH-aware, then an NSH proxy will be between the SFF 527 and the SF to avoid exposure of the NSH to the SF that does not 528 understand NSHs as shown in Figure 6. This is described in Section 529 4.6 of [RFC7665]. The SF and proxy together look to the SFF like an 530 NSH-aware SF. The behavior at the proxy and SF in this case is as 531 below: 533 If such a proxy is not ECN-aware then congestion in the entire 534 path from SFF to proxy to SF back to proxy to SFF will be 535 unmanaged. 537 | 538 v 539 +----------+ +---------+ 540 | | +-------+ | NSH | 541 | SFF +---->| NSH +---->|un-aware | 542 |(Service | | aware | | SF | 543 | Function |<----+ proxy |<----+(Service | 544 |Forwarder)| +-------+ |Function)| 545 +----------+ +---------+ 546 | 547 v 549 Figure 6. Proxy for NSH Un-aware SFF 551 If the proxy is ECN-aware, the proxy uses an AQM to indicate 552 congestion within the proxy in the NSH that it returns to the SFF. 553 The outer header used for the proxy-to-SF path uses Normal Mode. 554 The outer head used for the proxy-to-SFF path uses Normal Mode 555 based copying of the NSH ECN field to the outer header. Thus 556 congestion in the proxy will be managed. Congestion in the SF will 557 be managed only if the SF is ECN-aware and implements an AQM. 559 3.2.3 At Other Forwarding Nodes 561 Other forwarding nodes, that is non-NSH forwarding nodes between NSH 562 forwarding nodes, such as IP or label switched routers, might also 563 contain potential bottlenecks. If so, they SHOULD implement an AQM 564 algorithm to update the ECN marking in the outer transport header as 565 specified in [RFC3168]. 567 3.3 At Exit/Egress 569 At the SFC domain egress node, first any actions are taken based on 570 Congestion Experienced or other values of ECN marking, such as 571 accumulating statistics to send back to the ingress (see Section 4) 572 or for other uses. If the packet being carried inside the NSH is IP, 573 when the NSH is removed the NSH ECN field MUST be combined with the 574 IP ECN field as specified in Table 3 that was extracted from 575 [RFC6040]. This requirement applies to all egress nodes for the 576 domain in which NSH is being used to route traffic. 578 +---------+---------------------------------------------+ 579 |Arriving | Arriving Outer Header | 580 | Inner +---------+-----------+-----------+-----------+ 581 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 582 +---------+---------+-----------+-----------+-----------+ 583 | Not-ECT | Not-ECT |Not-ECT |Not-ECT | | 584 | ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE | 585 | ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE | 586 | CE | CE | CE | CE | CE | 587 +---------+---------+-----------+-----------+-----------+ 589 Table 3. Exit ECN Fields Merger 591 All the egress nodes of the SFC domain MUST support Compliant ECN 592 Decapsulation as specified in this section. If this is not the case, 593 the scheme described in this document will not work, and cannot be 594 used. 596 3.4 Conservation of Packets 598 The SFC specification permits an SF to absorb packets and to generate 599 new packets as well as simply processing and forwarding the packets 600 it receives. Such actions might appear to be packet loss due to 601 congestion or might mask the loss of packets by generating additional 602 packets. 604 The tunnel congestion feedback approach (Section 4) detects loss by 605 counting payload bytes in at the ingress and counting them out at the 606 egress. This does not work unless nodes conserve the amount of 607 payload bytes. Therefore, it will not be possible to detect loss 608 using this technique if they are not conserved. 610 Nonetheless, if a bottleneck supports ECN marking, it will be 611 possible to detect the very high level of CE markings that are 612 associated with congestion that is so excessive that it leads to 613 loss. However, it will not be possible for the tunnel congestion 614 feedback approach to detect any congestion, whether slight or severe, 615 if it occurs at a bottleneck that does not support ECN marking. 617 4. Tunnel Congestion Feedback Support 619 The collection and storage of congestion information at the egress 620 may be useful for later analysis but, unless it can be fed back to a 621 point which can take action to reduce congestion, it will not be 622 useful in real time. Such congestion feedback to the ingress enables 623 it to take actions such as those listed in Section 1.3. 625 IP Flow Information Export (IPFIX [RFC7011]) provides a standard for 626 communicating traffic flow statistics. As extended by this document, 627 IPFIX messages from the egress to the ingress are used to communicate 628 the extent of congestion between an ingress and egress based on ECN 629 marking in the NSH. 631 4.1 Congestion Level Measurement 633 The congestion level measurement is based on ECN marking in the NSH 634 and packet drop, particularly the fraction of packets that are CE- 635 marked packet and fraction that are dropped. If the congestion level 636 is not high enough, the packets are marked as CE instead of being 637 dropped, and then it is easy to calculate congestion level according 638 to the ratio of CE-marked packets. If the congestion level is so high 639 that ECT packets will be dropped, then the packet loss ratio could be 640 calculated by comparing total packets entering ingress and total 641 packets arriving at egress over the same span of packets. If packet 642 loss is detected, it could be assumed that severe congestion has 643 occurred in the tunnel. 645 The egress calculates the CE-marked packet ratio by counting packets 646 with different ECN markings. The CE-marked packet ratio will be used 647 as an indication of tunnel load level. It is assumed that nodes 648 between the ingress and egress will not drop packets biased towards 649 certain ECN codepoints, so calculating of CE-marked packet ratio is 650 not affect by packet drop. 652 The calculation of volumes of packet drop is by comparing the traffic 653 volumes between ingress and egress. 655 Faked ECN-Capable Transport (ECT) is used at the ingress to defer 656 packet loss to the egress. The basic idea of faked ECT is that, when 657 encapsulating packets, the ingress first marks the tunnel outer 658 header (NSH for an SFC domain) according to [RFC6040], and then 659 remarks the outer header of Not-ECT packets as ECT. (ECT(0) and 660 ECT(1) are treated as the same.) Thus, as transmitted by the ingress 661 node, there will be one of three combinations of outer header ECN 662 field and inner header ECN field: CE|CE, ECT|N-ECT, and ECT|ECT (in 663 the format of outer-ECN|inner-ECN); when decapsulating packets at the 664 egress, [RFC6040] defined decapsulation behavior is used, and 665 according to [RFC6040], the packets marked as CE|N-ECT will be 666 dropped. Faked-ECT is used to shift some drops to the egress in order 667 to allow the egress to calculate the CE-marked packet ratio more 668 precisely. 670 The ingress encapsulates packets and marks their outer header 671 according to faked ECT as described above. The ingress cumulatively 672 counts packet bytes for three types of ECN combination (CE|CE, ECT|N- 673 ECT, and ECT|ECT) and then the ingress regularly sends cumulative 674 bytes counts message of each type of ECN combination to the egress. 676 When each message arrives at the egress, (1) egress calculates the 677 ratio of CE-marked packet; (2) the egress cumulatively counts packet 678 bytes coming from the ingress and adds its own bytes counts of each 679 type of ECN combination (CE|CE, ECT|N-ECT, CE|N-ECT, CE|ECT, and 680 ECT|ECT) to the message for ingress to calculate packet loss. The 681 egress feeds back CE-marked packet ratio and bytes counts information 682 to the ingress for evaluating congestion level in the tunnel. 684 The counting of bytes can be at the granularity of all traffic from 685 the ingress to the egress to learn about the overall congestion 686 status of the path between the ingress and the egress. The counting 687 can also be at the granularity of individual customer's traffic or a 688 specific set of flows to learn about their congestion contribution. 690 For example, the tunnelEcnCEMarkedRatio field (specified below) 691 indicates the fraction of traffic that has been marked in the ECN 692 field of the NSH as Congestion Experienced (CE). 694 4.3 Congestion Information Delivery 696 As described above, the tunnel ingress needs to send a messages 697 containing cumulative bytes counts of packets of each type of ECN 698 combination to the tunnel egress, and the tunnel egress also needs to 699 feed back messages with cumulative bytes counts of packets of each 700 type of ECN combination and CE-marked packet ratio to the ingress. 701 This section specifies how the messages should be conveyed. 703 IPFIX recommends, but does not require, use of SCTP [RFC4960] in 704 partial reliability mode [RFC3758] for the transport of its messages. 705 This mode allows loss of some packets, which is tolerable because 706 IPFIX communicates cumulative statistics. IPFIX over SCTP over IP 707 SHOULD be used directly where there is IP connectivity between the 708 ingress and egress; however, there might be different transport 709 protocols or address spaces used in different regions of an SFC 710 domain that make such direct IP connectivity problematic. The NSH 711 provides the general method of routing traffic within an SFC domain 712 so the encapsulation of the required IPFIX traffic in NSH MUST be 713 implemented and, when IP connectivity is not available, IPFIX over 714 NSH SHOULD be used along with configuration of appropriate SFC paths 715 for the IPFIX over NSH traffic. 717 Typically IPFIX messages could travel along the same path as network 718 data traffic. In any case, an IPFIX message packet may get lost in 719 case of network congestion. Even though the missing information could 720 be recovered because of the use of cumulative counts, the message 721 SHOULD be transmitted at a higher priority than users' traffic flows. 723 The ingress node can do congestion management at different 724 granularity which means both the overall aggregated inner tunnel 725 congestion level and congestion level contributed by certain traffic 726 flows could be measured for different congestion management purpose. 727 For example, if the ingress only wants to limit congestion volume 728 caused by certain traffic flows, such as UDP-based traffic, then 729 congestion volume for that traffic will be fed back; or if the 730 ingress is doing overall congestion management, the aggregated 731 congestion volume will be fed back. 733 When sending IPFIX messages from ingress to egress, the ingress acts 734 as IPFIX exporter and egress acts as IPFIX collector; When feedback 735 congestion level information from egress to ingress, then the egress 736 acts as IPFIX exporter and ingress acts as IPFIX collector. 738 The combination of congestion level measurement and congestion 739 information delivery procedures should be as following: 741 o The ingress node determines the IPFIX template record to be used. 742 The template record can be pre-configured or determined at 743 runtime, the content of template record will be determined 744 according to the granularity of congestion management; if the 745 ingress wants to limit congestion volume contributed by specific 746 traffic flow then the elements such as source IP address, 747 destination IP address, flow id and CE-marked packet volume of the 748 flow, etc., will be included in the template record. 750 o Metering on the ingress measures traffic volume according to 751 template record chosen and then the measurement records are sent 752 to the egress. 754 o Metering on the egress measures congestion level information 755 according to template record which should be the same as the 756 template record sent by the ingress. 758 o The egress sends measurement records together with the measurement 759 records of ingress back to the ingress. 761 4.3 IPFIX Extensions 763 This section specifies new IPFIX Information Elements according to 764 [RFC7013]. 766 4.3.1 nshServicePathID 768 In order to identify SFC flows, so that congestion can be measured 769 and reported at that granularity, it is necessary for IPFIX to be 770 able to classify traffic based on the Service Path Identifier field 771 of the NSH [RFC8300]. Thus an NSH Service Path Identifier 772 (nshServicePathID) IPFIX Information Element [RFC7012] is specified. 774 Name: nshServicePathID 776 Description: Network Service Header [RFC8300] Service Path 777 Identifier. This is a 24-bit value which is left justified in 778 the Information Element. The low order byte MUST be sent as 779 zero and ignored on receipt. 781 Abstract Data Type: unsigned32 783 Data Type Semantics: identifier 785 ElementId: tbd0 787 Status: current 789 4.3.2 tunnelEcnCeCeByteTotalCount 791 Description: The total number of bytes of incoming packets with 792 CE|CE ECN marking combination at the Observation Point since 793 the Metering Process (re-)initialization for this Observation 794 Point. 796 Abstract Data Type: unsigned64 798 Data Type Semantics: totalCounter 800 ElementId: TBD1 802 Statues: current 804 Units: bytes 806 4.3.3 tunnelEcnEctNectBytetTotalCount 808 Description: The total number of bytes of incoming packets with 809 ECT|N-ECT ECN marking combination (ECT(0) and ECT(1) are 810 treated as the same) at the Observation Point since the 811 Metering Process (re-)initialization for this Observation 812 Point. 814 Abstract Data Type: unsigned64 816 Data Type Semantics: totalCounter 818 ElementId: TBD2 820 Statues: current 822 Units: bytes 824 4.3.4 tunnelEcnCeNectByteTotalCount 826 Description: The total number of bytes of incoming packets with 827 CE|N-ECT ECN marking combination at the Observation Point since 828 the Metering Process (re-)initialization for this Observation 829 Point. 831 Abstract Data Type: unsigned64 833 Data Type Semantics: totalCounter 835 ElementId: TBD3 837 Statues: current 839 Units: bytes 841 4.3.5 tunnelEcnCeEctByteTotalCount 843 Description: The total number of bytes of incoming packets with 844 CE|ECT ECN marking combination (ECT(0) and ECT(1) are treated 845 as the same) at the Observation Point since the Metering 846 Process (re-)initialization for this Observation Point. 848 Abstract Data Type: unsigned64 850 Data Type Semantics: totalCounter 851 ElementId: TBD4 853 Statues: current 855 Units: bytes 857 4.3.6 tunnelEcnEctEctByteTotalCount 859 Description: The total number of bytes of incoming packets with 860 ECT|ECT ECN marking combination (ECT(0) and ECT(1) are treated 861 as the same) at the Observation Point since the Metering 862 Process (re-)initialization for this Observation Point. 864 Abstract Data Type: unsigned64 866 Data Type Semantics: totalCounter 868 ElementId: TBD5 870 Statues: current 872 Units: bytes 874 4.3.7 tunnelEcnCEMarkedRatio 876 Description: The ratio of CE-marked Packet at the Observation 877 Point. 879 Abstract Data Type: float32 881 ElementId: TBD6 883 Statues: current 885 5. Example of Use 887 This subsection provides an example of how the solution described in 888 this document could work. 890 First of all, IPFIX template records are exchanged between ingress 891 and egress to negotiate the format of data records. The example here 892 is to measure the congestion level for the overall tunnel caused by 893 all the traffic. After the negotiation is finished, the ingress sends 894 in-band messages to egress containing the number of each kind of ECN- 895 marked packets (i.e.. CE|CE, ECT|N-ECT and ECT|ECT) received until it 896 sent the message. 898 After the egress receives the message, the egress calculates the CE- 899 marked packet ratio and counts the number of different kinds of ECN- 900 marking packets received until it received the message. Then the 901 egress sends a feedback message containing the counts together with 902 the information in the ingress's message back to the ingress. 904 Figures 7 to 10 below show the example procedure between ingress and 905 egress. 907 +---------------------------------+----------------------+ 908 |Set ID=2 Length=40 | 909 |---------------------------------|----------------------| 910 |Template ID=256 Field Count=8 | 911 |---------------------------------|----------------------| 912 |tunnelEcnCeCeByteTotalCount Field Length=8 | 913 |---------------------------------|----------------------| 914 |tunnelEcnEctNectByteTotalCount Field Length=8 | 915 |---------------------------------|----------------------| 916 |tunnelEcnEctEctByteTotalCount Field Length=8 | 917 |---------------------------------|----------------------| 918 |tunnelEcnCeNectByteTotalCount Field Length=8 | 919 |---------------------------------|----------------------| 920 |tunnelEcnCeEctByteTotalCount Field Length=8 | 921 +---------------------------------|----------------------+ 922 |tunnelEcnCEMarkedRatio Field Length=4 | 923 +---------------------------------+----------------------+ 925 Figure 7. Template Record Sent From Egress to Ingress 927 +---------------------------------+----------------------+ 928 |Set ID=2 Length=28 | 929 |---------------------------------|----------------------| 930 |Template ID=257 Field Count=3 | 931 |---------------------------------|----------------------| 932 |tunnelEcnCeCeByteTotalCount Field Length=8 | 933 |---------------------------------|----------------------| 934 |tunnelEcnEctNectByteTotalCount Field Length=8 | 935 |---------------------------------|----------------------| 936 |tunnelEcnEctEctByteTotalCount Field Length=8 | 937 |---------------------------------+----------------------| 939 Figure 8. Template Record Sent From Ingress to Egress 941 +-------+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-------+ 942 | | |M| |P| |P| |P| |M| |P| |P| | | 943 | | +-+ +-+ +-+ +-+ +-+ +-+ +-+ | | 944 | |<---------------------------------------| | 945 | | | | 946 | | | | 947 |egress | +-+ +-+ |ingress| 948 | | |M| |M| | | 949 | | +-+ +-+ | | 950 | |--------------------------------------->| | 951 | | | | 952 | | | | 953 +-------+ +-------+ 955 +-+ 956 |M| : Message Packet 957 +-+ 959 +-+ 960 |P| : User Packet 961 +-+ 963 Figure 9. Traffic flow Between Ingress and Egress 964 Set ID=257, Length=28 965 +------+ A1 +------+ 966 | | B1 | | 967 | | C1 | | 968 | | <----------------------------- | | 969 | | | | 970 | | | | 971 | | SetID=256, Length=72 | | 972 | | A1 | | 973 | | B1 | | 974 |egress| C1 ingress| 975 | | A2 | | 976 | | B2 | | 977 | | C2 | | 978 | | D | | 979 | | E | | 980 | | R | | 981 | | ----------------------------> | | 982 | | | | 983 +------+ +------+ 985 Figure 10. Messages Between Ingress and Egress 987 The following provides an example of how the tunnel congestion level 988 could be calculated: 990 The congestion Level could be divided into two categories: (1) 991 slight congestion (no packets dropped); (2) serious congestion 992 (packets are being dropped). 994 For slight congestion, the congestion level is indicated as the 995 ratio of CE-marked packet: 997 ce_marked = R; 999 For serious congestion, the congestion level is indicated as the 1000 number of volume loss: 1002 total_ingress = (A1 + B1 + C1) 1004 total_egress = (A2 + B2 + C2 + D + E) 1006 volume_loss = (total_ingress - total_egress) 1008 6. IANA Considerations 1010 The following subsections provide IANA assignment considerations. 1012 6.1 SFC NSH Header ECN Bits 1014 IANA is requested to assign two contiguous bits in the NSH Base 1015 Header Bits registry for ECN (bits 16 and 17 suggested) and note this 1016 assignment as follows: 1018 Bit Description Reference 1019 ---------- ----------- ----------------- 1020 tbd(16-17) NSH ECN [this document] 1022 6.2 IPFIX Information Element IDs 1024 IANA is requested to assign IPFIX Information Element IDs as follows: 1026 ElementID: tbd0 1027 Name: nshServicePathID 1028 Data Type: unsigned32 1029 Data Type Semantics: identifier 1030 Status: current 1031 Description: The Network Service Header [RFC8300] Service Path 1032 Identifier. 1034 ElementID: TBD1 1035 Name: tunnelEcnCeCePacketTotalCount 1036 Data Type: unsigned64 1037 Data Type Semantics: totalCounter 1038 Status: current 1039 Description: The total number of bytes of incoming packets with 1040 CE|CE ECN marking combination at the Observation Point since 1041 the Metering Process (re-)initialization for this Observation 1042 Point. 1043 Units: octets 1045 ElementID: TBD2 1046 Name: tunnelEcnEctNectPacketTotalCount 1047 Data Type: unsigned64 1048 Data Type Semantics: totalCounter 1049 Status: current 1050 Description: The total number of bytes of incoming packets with 1051 ECT|N-ECT ECN marking combination at the Observation Point 1052 since the Metering Process (re-)initialization for this 1053 Observation Point. 1055 Units: octets 1057 ElementID: TBD3 1058 Name: tunnelEcnCeNectPacketTotalCount 1059 Data Type: unsigned64 1060 Data Type Semantics: totalCounter 1061 Status: current 1062 Description: The total number of bytes of incoming packets with 1063 CE|N-ECT ECN marking combination at the Observation Point since 1064 the Metering Process (re-)initialization for this Observation 1065 Point. 1066 Units: octets 1068 ElementID: TBD4 1069 Name: tunnelEcnCeEctPacketTotalCount 1070 Data Type: unsigned64 1071 Data Type Semantics: totalCounter 1072 Status: current 1073 Description: The total number of bytes of incoming packets with 1074 CE|ECT ECN marking combination at the Observation Point since 1075 the Metering Process (re-)initialization for this Observation 1076 Point. 1077 Units: octets 1079 ElementID: TBD5 1080 Name: tunnelEcnEctEctPacketTotalCount 1081 Data Type: unsigned64 1082 Data Type Semantics: totalCounter 1083 Status: current 1084 Description: The total number of bytes of incoming packets with 1085 CE|ECT(0) ECN marking combination at the Observation Point 1086 since the Metering Process (re-)initialization for this 1087 Observation Point. 1088 Units: octets 1090 ElementID: TBD6 1091 Name: tunnelEcnCEMarkedRatio 1092 Data Type: float32 1093 Status: current 1094 Description: The ratio of CE-marked Packet at the Observation 1095 Point. 1097 7. Security Considerations 1099 For general NSH security considerations, see [RFC8300]. 1101 For security considerations concerning tampering with ECN signaling, 1102 see [RFC3168]. For security considerations concerning ECN and 1103 encapsulation, see [RFC6040]. 1105 For general IPFIX security considerations, see [RFC7011]. If deployed 1106 in an untrusted environment, the signaling traffic between ingress 1107 and egress can be protected utilizing the security mechanisms 1108 provided by IPFIX (see Section 11 in [RFC7011]). 1110 The tunnel endpoints (the ingress and egress for an SFC domain) are 1111 assumed to be in the same administrative domain, so they will trust 1112 each other. 1114 The solution in this document does not introduce any greater 1115 potential to invade privacy than would have been available without 1116 the solution. 1118 8. Acknowledgements 1120 Most of the material on Tunnel Congestion Feedback was originally in 1121 draft-ietf-twvwg-tunnel-congestion-feedback. After discussion with 1122 the authors of that draft, the authors of this draft, and the Chairs 1123 of the TSVWG and SFC Working Groups, the Tunnel Congestion Feedback 1124 draft was merged into this draft. 1126 The authors wish to thank the following for their comments, 1127 suggestions, and reviews: 1129 David Black, Sami Boutros, Anthony Chan, Lingli Deng, Liang Geng, 1130 Joel Halpern, Jake Holland, John Kaippallimalil, Tal Mizrahi, 1131 Vincent Roca, Lei Zhu 1133 Normative References 1135 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1137 March 1997, . 1139 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1140 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 1141 10.17487/RFC3168, September 2001, . 1144 [RFC3758] - Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1145 Conrad, "Stream Control Transmission Protocol (SCTP) Partial 1146 Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 1147 2004, . 1149 [RFC5129] - Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1150 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, 1151 . 1153 [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion 1154 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, 1155 . 1157 [RFC7011] - Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1158 "Specification of the IP Flow Information Export (IPFIX) 1159 Protocol for the Exchange of Flow Information", STD 77, RFC 1160 7011, DOI 10.17487/RFC7011, September 2013, . 1163 [RFC7013] - Trammell, B. and B. Claise, "Guidelines for Authors and 1164 Reviewers of IP Flow Information Export (IPFIX) Information 1165 Elements", BCP 184, RFC 7013, DOI 10.17487/RFC7013, September 1166 2013, . 1168 [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF 1169 Recommendations Regarding Active Queue Management", BCP 197, 1170 RFC 7567, DOI 10.17487/RFC7567, July 2015, . 1173 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1174 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 1175 2017, 1177 [RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1178 "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, 1179 January 2018, . 1181 Informative References 1183 [RFC4301] - Kent, S. and K. Seo, "Security Architecture for the 1184 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 1185 2005, . 1187 [RFC4960] - Stewart, R., Ed., "Stream Control Transmission Protocol", 1188 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1189 . 1191 [RFC7012] - Claise, B., Ed., and B. Trammell, Ed., "Information Model 1192 for IP Flow Information Export (IPFIX)", RFC 7012, DOI 1193 10.17487/RFC7012, September 2013, . 1196 [RFC7665] - Halpern, J., Ed., and C. Pignataro, Ed., "Service 1197 Function Chaining (SFC) Architecture", RFC 7665, DOI 1198 10.17487/RFC7665, October 2015, . 1201 [RFC8311] - Black, D., "Relaxing Restrictions on Explicit Congestion 1202 Notification (ECN) Experimentation", RFC 8311, DOI 1203 10.17487/RFC8311, January 2018, . 1206 [ecnL4S] - De Schepper, K., and B. Briscoe, "Identifying Modified 1207 Explicit Congestion Notification (ECN) Semantics for Ultra-Low 1208 Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-id, work in 1209 progress. 1211 Authors' Addresses 1213 Donald E. Eastlake, 3rd 1214 Futurewei Technologies 1215 2386 Panoramic Circle 1216 Apopka, FL 32703 USA 1218 Tel: +1-508-333-2270 1219 Email: d3e3e3@gmail.com 1221 Bob Briscoe 1222 Independent 1223 UK 1225 Email: ietf@bobbriscoe.net 1226 URI: http://bobbriscoe.net/ 1228 Yizhou Li 1229 Huawei Technologies 1230 101 Software Avenue, 1231 Nanjing 210012, P. R China 1233 Phone: +86-25-56624584 1234 EMail: liyizhou@huawei.com 1236 Andrew G. Malis 1237 Malis Consulting 1239 Email: agmalis@gmail.com 1241 Xinpeng Wei 1242 Huawei Technologies 1243 Beiqing Rd. Z-park No.156, Haidian District, 1244 Beijing, 100095, P. R. China 1246 EMail: weixinpeng@huawei.com 1248 Copyright and IPR Provisions 1250 Copyright (c) 2021 IETF Trust and the persons identified as the 1251 document authors. All rights reserved. 1253 This document is subject to BCP 78 and the IETF Trust's Legal 1254 Provisions Relating to IETF Documents 1255 (http://trustee.ietf.org/license-info) in effect on the date of 1256 publication of this document. Please review these documents 1257 carefully, as they describe your rights and restrictions with respect 1258 to this document. Code Components extracted from this document must 1259 include Simplified BSD License text as described in Section 4.e of 1260 the Trust Legal Provisions and are provided without warranty as 1261 described in the Simplified BSD License. The definitive version of 1262 an IETF Document is that published by, or under the auspices of, the 1263 IETF. Versions of IETF Documents that are published by third parties, 1264 including those that are translated into other languages, should not 1265 be considered to be definitive versions of IETF Documents. The 1266 definitive version of these Legal Provisions is that published by, or 1267 under the auspices of, the IETF. Versions of these Legal Provisions 1268 that are published by third parties, including those that are 1269 translated into other languages, should not be considered to be 1270 definitive versions of these Legal Provisions. For the avoidance of 1271 doubt, each Contributor to the IETF Standards Process licenses each 1272 Contribution that he or she makes as part of the IETF Standards 1273 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1274 language to the contrary, or terms, conditions or rights that differ 1275 from or are inconsistent with the rights and licenses granted under 1276 RFC 5378, shall have any effect and shall be null and void, whether 1277 published or posted by such Contributor, or included with or in such 1278 Contribution.