idnits 2.17.1 draft-ietf-sfc-nsh-ecn-support-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 240 has weird spacing: '... sender doma...' == Line 241 has weird spacing: '...ingress v |...' -- The document date (January 1, 2020) is 1570 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) ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-tunnel-congestion-feedback (ref. 'TunnelCongFeedback') -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Intended status: Proposed Standard Futurewei Technologies 3 Bob Briscoe 4 Independent 5 Andrew Malis 6 Futurewei Technologies 7 Expires: June 31, 2020 January 1, 2020 9 Explicit Congestion Notification (ECN) and Congestion Feedback 10 Using the Network Service Header (NSH) 11 13 Abstract 15 Explicit congestion notification (ECN) allows a forwarding element to 16 notify downstream devices of the onset of congestion without having 17 to drop packets. Coupled with a means to feed back information about 18 congestion to upstream nodes, this can improve network efficiency 19 through better congestion control, frequently without packet drops. 20 This document specifies ECN and congestion feedback support within a 21 Service Function Chaining (SFC) domain through use of the Network 22 Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, 23 draft-ietf-tsvwg-tunnel-congestion-feedback). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Distribution of this document is unlimited. Comments should be sent 31 to the SFC Working Group mailing list or to the 32 authors. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 46 Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 Table of Contents 51 1. Introduction............................................3 52 1.1 NSH Background.........................................3 53 1.2 ECN Background.........................................5 54 1.3 Tunnel Congestion Feedback Background..................5 55 1.4 Conventions Used in This Document......................7 57 2. The NSH ECN Field.......................................8 59 3. ECN Support in the NSH.................................10 60 3.1 At The Ingress........................................11 61 3.2 At Transit Nodes......................................12 62 3.2.1 At NSH Transit Nodes................................12 63 3.2.2 At an SF/Proxy......................................13 64 3.2.3 At Other Forwarding Nodes...........................13 65 3.3 At Exit/Egress........................................13 66 3.4 Conservation of Packets...............................14 68 4. Tunnel Congestion Feedback Support.....................15 70 5. IANA Considerations....................................16 71 6. Security Considerations................................17 72 7. Acknowledgements.......................................17 74 Normative References......................................18 75 Informative References....................................19 77 1. Introduction 79 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 80 element to notify downstream devices of the onset of congestion 81 without having to drop packets. Coupled with a means to feed back 82 information about congestion to upstream nodes, this can improve 83 network efficiency through better congestion control, frequently 84 without packet drops. This document specifies ECN and congestion 85 feedback support within a Service Function Chaining (SFC [RFC7665]) 86 domain through use of the Network Service Header (NSH [RFC8300]) and 87 IP Flow Information Export (IPFIX [TunnelCongFeedback]). 89 It requires that all ingress and egress nodes of the SFC domain 90 implement ECN. While congestion management will be the most effective 91 if all interior nodes of the SFC domain implement ECN, some benefit 92 is obtained even if some interior nodes do not implement ECN. In 93 particular, congestion at any bottleneck where ECN marking is not 94 implemented will be unmanaged. 96 The subsections below in this is section provide background 97 information on NSH, ECN, congestion feedback, and terminology used in 98 this document. 100 1.1 NSH Background 102 The Service Function Chaining (SFC [RFC7665]) architecture calls for 103 the encapsulation of traffic within a service function chaining 104 domain with a Network Service Header (NSH [RFC8300]) added by the 105 "Classifier" (ingress node) on entry to the domain and the NSH being 106 removed on exit from the domain at the egress node. The NSH is used 107 to control the path of a packet in an SFC domain. The NSH is a 108 natural place, in a domain where traffic is NSH encapsulated, to note 109 congestion, avoiding possible confusion due, for example, to changes 110 in the outer transport header in different parts of the domain. 112 | 113 v 114 +----------+ 115 . .|Classifier|. . . . . . . . . . . . . . 116 . +----------+ . 117 . | +----+ . 118 . | --+ SF | Service . 119 . | / +----+ Function . 120 . v --- Chaining . 121 . +-----+/ +----+ domain . 122 . | SFF |--------+ SF | . 123 . +-----+\ +----+ . 124 . | --- . 125 . | \ +----+ . 126 . | --+ SF | . 127 . v +----+ . 128 . +-----+ +----+ . 129 . | SFF |-----------------+ SF | . 130 . +-----+ +----+ . 131 . | +----+ . 132 . | --+ SF | . 133 . | / +----+ . 134 . v --- . 135 . +-----+/ +----+ . 136 . | SFF |--------+ SF | . 137 . +-----+\ +----+ . 138 . | --- . 139 . | \ +----+ . 140 . | --+ SF | . 141 . v +----+ . 142 . +------+ . 143 . . .| Exit |. . . . . . . . . . . . . . . 144 +------+ 145 | 146 v 148 Figure 1. Example SFC Path Forwarding Nodes 150 Figure 1 shows an SFC domain for the purpose of illustrating the use 151 of NSH. Traffic passes through a sequence of Service Function 152 Forwarders (SFFs) each of which sends the traffic to one or more 153 Service Functions (SFs). Each SF performs some operation on the 154 traffic, for example firewall or Network Address Translation (NAT), 155 and then returns it to the SFF from which it was received. 157 Logically, during the transit of each SFF, the outer transport header 158 that got the packet to the SFF is stripped, the SFF decides on the 159 next forwarding step, either adding a transport header or, if the SFF 160 is the exit/egress, removing the NSH header. The transport headers 161 added may be different in different regions of the SFC domain. For 162 example, IP could be used for some SFF-to-SFF communication and MPLS 163 used for other such communication. 165 1.2 ECN Background 167 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 168 element (such as a router or a Service Function Forwarder (SFF) or 169 Service Function (SF)) to notify downstream devices of the onset of 170 congestion without having to drop packets. This can be used as an 171 element in active queue management (AQM) [RFC7567] to improve network 172 efficiency through better traffic control without packet drops. The 173 forwarding element can explicitly mark some packets in an ECN field 174 instead of dropping the packet. For example, a two-bit field is 175 available for ECN marking in IP headers [RFC3168]. 177 1.3 Tunnel Congestion Feedback Background 179 Tunnel Congestion Feedback [TunnelCongFeedback] is a building block 180 for various congestion mitigation methods. It supports feedback of 181 congestion information from an egress node to an ingress node. 182 Examples of actions that can be taken by an ingress node when it has 183 knowledge of downstream congestion include those listed below. 184 Details of implementing these traffic control methods, beyond those 185 given here, are outside the scope of this document. 187 Any action by the ingress to reduce congestion needs to allow 188 sufficient time for the end-to-end congestion control loop to respond 189 first, for instance by the ingress taking a smoothed average of the 190 level of congestion signalled by feedback from the tunnel egress. 192 (1) Traffic throttling (policing), where the downstream traffic 193 flowing out of the ingress node is limited to reduce or eliminate 194 congestion. 196 (2) Upstream congestion feedback, where the ingress node sends 197 messages upstream to or towards the ultimate traffic source, a 198 function that can throttle traffic generation/transmission. 200 (3) Traffic re-direction, where the ingress node configures the NSH 201 of some future traffic so that it avoids congested paths. Great 202 care must be taken to avoid (a) significant re-ordering of 203 traffic in flows that it is desirable to keep in order and (b) 204 oscillation/instability in traffic paths due to alternate 205 congestion of previously idle paths and the idling of previously 206 congested paths. For example, it is preferable to classify 207 traffic into flows of a sufficiently coarse granularity that the 208 flows are long lived and use a stable path per flow, then send 209 only newly appearing flows on apparently uncongested paths. 211 Figure 2 shows an example path from an origin sender to a final 212 receiver passing through an example chain of service functions 213 between the ingress and egress of an SFC domain. The path is also 214 likely to pass through other network nodes outside the SFC domain 215 (not shown). The figure shows typical congestion feedback that would 216 be expected from the final receiver to the origin sender, which 217 controls the load the origin sender applies to all elements on the 218 path. The figure also shows the congestion feedback from the egress 219 to the ingress of the SFC domain that is described in this document, 220 to control or balance load within the SFC domain. 222 .:= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = :. 223 _||_ End-to-End Congestion Feedback || 224 \ / || 225 \/ || 226 Inner Transport Header and Payload __ 227 | | - - - - - - - - - - - - - - - ->- - - - - -- - - - - - - - | | 228 | | | | 229 | | .:= = = = = = = = = = = = = = = = = = = = = =:. | | 230 | | _||_ Tunnel Congestion Feedback || | | 231 | | \ / || | | 232 | | \/ || | | 233 | | __ NSH __ | | 234 | | | |-------------------------->--------------| | | | 235 | |. . . | | ___ ___ ___ | |. . .| | 236 | | | | OT1 | | OT4 | | . . . | | OTn | | | | 237 | | | |-->--|SFF|--->---|SFF| |SFF|-->--| | | | 238 |__| |__| |___| |___| |___| |__| |__| 239 origin SFC | ^ | ^ SFC final 240 sender domain OT2| |OT3 OT6| |OT7 domain rcvr 241 ingress v | v | egress 242 +---+ +---+ 243 |SF | |SF | 244 +---+ +---+ 246 Figure 2: Congestion Feedback across an SFC Domain 248 SFC Domain congestion feedback in Figure 2 is shown within the 249 context of an end-to-end congestion feedback loop. Also shown is the 250 encapsulated layering of NSH headers within a series of outer 251 transport headers (OT1, OT2, ... OTn). 253 1.4 Conventions Used in This Document 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 256 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 257 document are to be interpreted as described in [RFC2119] [RFC8174] 258 when, and only when, they appear in all capitals, as shown here. 260 Acronyms: 262 AQM - Active Queue Management [RFC7567] 264 CE - Congestion Experienced [RFC3168] 266 downstream - The direction from ingress to egress 268 ECN - Explicit Congestion Notification [RFC3168] 270 ECT - ECN Capable Transport [RFC3168] 272 IPFIX - IP Flow Information Export [RFC7011] 274 Not-ECT - Not ECN-Capable Transport [RFC3168] 276 NSH - Network Service Header [RFC8300] 278 SF - Service Function [RFC7665] 280 SFC - Service Function Chaining [RFC7665] 282 SFF - Service Function Forwarder [RFC7665] - A type of node that 283 forwards based on the NSH. 285 TLV - Type Length Value 287 upstream - The direction from egress to ingress 289 2. The NSH ECN Field 291 The NSH header is used to encapsulate and control the subsequent path 292 of traffic (see Section 2 of [RFC8300]). The NSH also provides for 293 metadata inclusion, as shown in Figure 3. 295 +-----------------------------------+ 296 | Transport Encapsulation | 297 +-----------------------------------+ 298 | Network Service Header (NSH) | 299 | +------------------------------+ | 300 | | Base Header | | 301 | +------------------------------+ | 302 | | Service Path Header | | 303 | +------------------------------+ | 304 | | Metadata (Context Header(s)) | | 305 | +------------------------------+ | 306 +-----------------------------------+ 307 | Original Packet / Frame | 308 +-----------------------------------+ 310 Figure 3. Data Encapsulation with the NSH 312 Two currently unused bits (indicated by "U") in the NSH Base Header 313 (Section 2.2 of [RFC8300]) are allocated for ECN as shown in Figure 314 4. 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 ^ ^ 322 | | 323 +-------+ 324 |NSH ECN| 325 | field | 326 +-------+ 328 Figure 4: NSH Base Header 330 Note to RFC Editor: The above figure should be adjusted based on the 331 bits assigned by IANA (see Section 5) and this note deleted. 333 Table 1 shows the meaning of the code points in the NSH ECN field. 334 These have the same meaning as the ECN field code points in the IPv4 335 or IPv6 header as defined in [RFC3168]. 337 Binary Name Meaning 338 ------ ------- -------------------------------- 339 00 Not-ECT Not ECN-Capable Transport 340 01 ECT(1) ECN-Capable Transport 341 10 ECT(0) ECN-Capable Transport 342 11 CE Congestion Experienced 344 Table 1. ECN Field Code Points 346 3. ECN Support in the NSH 348 This section describes the required behavior to support ECN using the 349 NSH. There are two aspects to ECN support: 350 1. ECN propagation during encapsulation or decapsulation 351 2. ECN marking during congestion at bottlenecks. 353 While this section covers all combinations of ECN-aware and not ECN- 354 aware, it is expected that in most cases the NSH domain will be 355 uniform so that, if this document is applicable, all SFFs will 356 support ECN; however, some legacy SFs might not support ECN. 358 ECN Propagation: 360 The specification of ECN tunneling [RFC6040] explains that an 361 ingress must not propagate ECN support into an encapsulating 362 header unless the egress supports correct onward propagation of 363 the ECN field during decapsulation. We define Compliant ECN 364 Decapsulation here as decapsulation compliant with either 365 [RFC6040] or an earlier compatible equivalent ([RFC4301], or the 366 full functionality mode of [RFC3168]). 368 The procedures in Section 3.2.1 ensure that each ingress of the 369 large number of possible transport links within the SFC domain 370 does not propagate ECN support into the encapsulating outer 371 transport header unless the corresponding egress of that link 372 supports Compliant ECN Decapsulation. 374 Section 3.3 requires that all the egress nodes of the SFC domain 375 support Compliant ECN Decapsulation in conjunction with tunnel 376 congestion feedback, otherwise the scheme in this document will 377 not work. 379 ECN Marking: 381 At transit nodes the marking behavior specified in Section 3.2.1 382 is recommended and if not implemented at such transit nodes, there 383 may be unmanaged congestion. 385 Detection of congestion will be most effective if ECN marking is 386 supported by all potential bottlenecks inside the domain in which 387 NSH is being used to route traffic as well as at the ingress and 388 egress. Nodes that do not support ECN marking, or that support 389 AQM but not ECN, will naturally use drop to relieve congestion. 390 The gap in the end-to-end packet sequence will be detected as 391 congestion by the final receiving endpoint, but not by the NSH 392 egress (see Figure 2). 394 3.1 At The Ingress 396 When the ingress/Classifier encapsulates an incoming IP packet with 397 an NSH, it MUST set the NSH ECN field using the "Normal mode" 398 specified in [RFC6040] (i.e., copied from the incoming IP header). 400 Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD 401 set it to ECT(0). This indicates that, even though the end-to-end 402 transport is not ECN-capable, the egress and ingress of the SFC 403 domain are acting as an ECN-capable transport. This approach will 404 inherently support all known variatns of ECN, including the 405 experimental L4S capability [RFC8311], [ecnL4S]. 407 Packets arriving at the ingress might not use IP. If the protocol of 408 arriving packets supports an ECN field similar to IP, the procedures 409 for IP packets can be used. If arriving packets do not support an ECN 410 field similar to IP, they MUST be treated as if they are Not-ECT IP 411 packets. 413 Then, as the NSH encapsulated packet is further encapsulated with a 414 transport header, if ECN marking is available for that transport (as 415 it is for IP [RFC3168] and MPLS [RFC5129]), the ECN field of the 416 transport header MUST be set using the "Normal mode" specified in 417 [RFC6040] (i.e., copied from the NSH ECN field). 419 A summary of these normative steps is given in Table 2. 421 +-----------------+---------------+ 422 | Incoming Header | Departing NSH | 423 | (also equal to | and Outer | 424 | departing Inner | Headers | 425 | Header) | | 426 +-----------------+---------------+ 427 | Not-ECT | ECT(0) | 428 | ECT(0) | ECT(0) | 429 | ECT(1) | ECT(1) | 430 | CE | CE | 431 +-----------------+---------------+ 433 Table 2. Setting of ECN fields by an ingress/Classifier 435 The requirements in this section apply to all ingress nodes for the 436 domain in which NSH is being used to route traffic. 438 3.2 At Transit Nodes 440 This section described behavior at nodes that forward based on the 441 NSH such as SFF and other forwarding nodes such as IP routers. Figure 442 5 shows a packet on the wire between forwarding nodes. 444 +-----------------+ 445 | Outer Header | 446 +-----------------+ 447 | NSH | 448 +-----------------+ 449 | Inner Header | 450 +-----------------+ 451 | Payload | 452 +-----------------+ 454 Figure 5. Packet in Transit 456 3.2.1 At NSH Transit Nodes 458 When a packet is received at an NSH based forwarding node N1, such as 459 an SFF, the outer transport encapsulation is removed and its ECN 460 marking SHOULD be combined into the NSH ECN marking as specified in 461 [RFC6040]. If this is not done, any congestion encountered at non-NSH 462 transit nodes between N1 and the next upstream NSH based forwarding 463 node will be lost and not transmitted downstream. 465 The NSH forwarding node SHOULD use a recognized AQM algorithm 466 [RFC7567] to detect congestion. If the NSH ECN field indicates ECT, 467 it will probabilistically set the NSH ECN field to the Congestion 468 Experienced (CE) value or, in cases of extreme congestion, drop the 469 packet. 471 When the NSH encapsulated packet is further encapsulated for 472 transmission to the next SFF or SF, ECN marking behavior depends on 473 whether or not the node that will decapsulate the outer header 474 supports Compliant ECN Decapsulation (see Section 3). If it does, 475 then the ingress node propagates the NSH ECN field to this outer 476 encapsulation using the "Normal Mode" of ECN encapsulation [RFC6040] 477 (it copies the ECN field). If it does not, then the ingress MUST 478 clear ECN in the outer encapsulation to non-ECT (the "Compatibility 479 Mode" of [RFC6040]). 481 3.2.2 At an SF/Proxy 483 If the SF is NSH and ECN-aware, the processing is essentially the 484 same at the SF as at an SFF as discussed in Section 3.2.1. 486 If the SF is NSH-aware but not ECN-aware, then the SFF transmitting 487 the packet to the SF will use Compatibility Mode. Congestion 488 encountered in the SFF to SF and SF to SFF paths will be unmanaged. 490 If the SF is not NSH-aware, then an NSH proxy will be between the SFF 491 and the SF to avoid exposure of the NSH at the SF that does not 492 understand NSHs. This is described in Section 4.6 of [RFC7665]. The 493 SF and proxy together look to the SFF like an NSH-aware SF. The 494 behavior at the proxy and SF in this case is as below: 496 If such a proxy is not ECN-aware then congestion in the entire 497 path from SFF to proxy to SF back to proxy to SFF will be 498 unmanaged. 500 If the proxy is ECN-aware the proxy uses an AQM to indicate 501 congestion in the proxy itself in the NSH that it returns to the 502 SFF. The outer header used for the proxy to SF path uses Normal 503 Mode. The outer head used for the proxy return to SFF path uses 504 Normal Mode based copying the NSH ECN field to the outer header. 505 Thus congestion in the proxy will be managed. Congestion in the SF 506 will be managed only if the SF is ECN-aware implementing an AQM. 508 3.2.3 At Other Forwarding Nodes 510 Other forwarding nodes, that is non-NSH forwarding nodes between NSH 511 forwarding nodes, such as IP routers, might also contain potential 512 bottlenecks. If so, they SHOULD implement an AQM algorithm to update 513 the ECN marking in the outer transport header as specified in 514 [RFC3168]. 516 3.3 At Exit/Egress 518 First, any actions are taken based on Congestion Experienced, such as 519 forwarding statistics back to the ingress (see Section 4). If the 520 packet being carried inside the NSH is IP, when the NSH is removed 521 the NSH ECN field MUST be combined with IP ECN field as specified in 522 Table 3 that was extracted from [RFC6040]. This requirement applies 523 to all egress nodes for the domain in which NSH is being used to 524 route traffic. 526 +---------+---------------------------------------------+ 527 |Arriving | Arriving Outer Header | 528 | Inner +---------+-----------+-----------+-----------+ 529 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 530 +---------+---------+-----------+-----------+-----------+ 531 | Not-ECT | Not-ECT |Not-ECT |Not-ECT | | 532 | ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE | 533 | ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE | 534 | CE | CE | CE | CE | CE | 535 +---------+---------+-----------+-----------+-----------+ 537 Table 3. Exit ECN Fields Merger 539 All the egress nodes of the SFC domain MUST support Compliant ECN 540 Decapsulation as specified in this section. If this is not the case, 541 the scheme described in this document will not work, and cannot be 542 used. 544 3.4 Conservation of Packets 546 The SFC specification permits an SF to absorb packets and to generate 547 new packets as well as to process and forward the packets it 548 receives. Such actions might appear to be packet loss due to 549 congestion or might mask the loss of packets by generating additional 550 packets. 552 The tunnel congestion feedback approach [TunnelCongFeedback] detects 553 loss by counting payload bytes in at the ingress and counting them 554 out at the egress. This does not work unless nodes conserve the 555 amount of payload bytes. Therefore, it will not be possible to detect 556 loss using this technique if they are not conserved. 558 Nonetheless, if a bottleneck supports ECN marking, it will be 559 possible to detect the very high level of CE markings that are 560 associated with congestion that is so excessive that it leads to 561 loss. However, it will not be possible for the tunnel congestion 562 feedback approach to detect any congestion, whether slight or severe, 563 if it occurs at a bottleneck that does not support ECN marking. 565 4. Tunnel Congestion Feedback Support 567 The collection and storage of congestion information may be useful 568 for later analysis but, unless it can be fed back to a point which 569 can take action to reduce congestion, it will not be useful in real 570 time. Such congestion feedback to the ingress enables it to take 571 actions such as those listed in Section 1.3. 573 IP Flow Information Export (IPFIX [RFC7011]) provides a standard for 574 communicating traffic flow statistics. As extended by 575 [TunnelCongFeedback], IPFIX can be used to determine the extent of 576 congestion between an ingress and egress. 578 IPFIX recommends use of SCTP [RFC4960] in partial reliability mode. 579 This mode allows loss of some packets, which is tolerable because 580 IPFIX communicates cumulative statistics. IPFIX over SCTP SHOULD be 581 used directly where there is IP connectivity between the ingress and 582 egress; however, there might be different transport protocols or 583 address spaces used in different regions of an SFC domain that make 584 such direct IP connectivity problematic. The NSH provides the general 585 method of routing of traffic within such domain so the IPFIX over 586 SCTP over IP traffic should be encapsulated in NSH when necessary. 588 5. IANA Considerations 590 IANA is requested to assign two contiguous bits in the NSH Base 591 Header Bits registry for ECN (bits 16 and 17 suggested) and note this 592 assignment as follows: 594 Bit Description Reference 595 ---------- ----------- --------------- 596 tbd(16-17) NSH ECN [this document] 598 6. Security Considerations 600 For general NSH security considerations, see [RFC8300]. 602 For security considerations concerning tampering with ECN signaling, 603 see [RFC3168]. For security considerations concerning ECN 604 encapsulation, see [RFC6040]. 606 For general IPFIX security considerations, see [RFC7011]. If deployed 607 in an untrusted environment, the signaling traffic between ingress 608 and egress can be protected utilizing the security mechanisms 609 provided by IPFIX (see Section 11 in [RFC7011]). 611 The solution in this document does not introduce any greater 612 potential to invade privacy than would have been possible without the 613 solution. 615 7. Acknowledgements 617 The authors wish to thank the following for their comments and 618 suggestion: 620 Joel Halpern, Tal Mizrahi, Xinpeng Wei 622 Normative References 624 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 626 March 1997, . 628 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 629 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 630 10.17487/RFC3168, September 2001, . 633 [RFC5129] - Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 634 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, 635 . 637 [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion 638 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, 639 . 641 [RFC7011] - Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 642 "Specification of the IP Flow Information Export (IPFIX) 643 Protocol for the Exchange of Flow Information", STD 77, RFC 644 7011, DOI 10.17487/RFC7011, September 2013, . 647 [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF 648 Recommendations Regarding Active Queue Management", BCP 197, 649 RFC 7567, DOI 10.17487/RFC7567, July 2015, . 652 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 653 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 654 2017, 656 [RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 657 "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, 658 January 2018, . 660 [TunnelCongFeedback] - Wei, X., Li, Y., Boutros, S., and L. Deng, 661 "Tunnel Congestion Feedback", draft-ietf-tsvwg-tunnel- 662 congestion-feedback, work in progress. 664 Informative References 666 [RFC4301] - Kent, S. and K. Seo, "Security Architecture for the 667 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 668 2005, . 670 [RFC4960] - Stewart, R., Ed., "Stream Control Transmission Protocol", 671 RFC 4960, DOI 10.17487/RFC4960, September 2007, 672 . 674 [RFC7665] - Halpern, J., Ed., and C. Pignataro, Ed., "Service 675 Function Chaining (SFC) Architecture", RFC 7665, DOI 676 10.17487/RFC7665, October 2015, . 679 [RFC8311] - Black, D., "Relaxing Restrictions on Explicit Congestion 680 Notification (ECN) Experimentation", RFC 8311, DOI 681 10.17487/RFC8311, January 2018, . 684 [ecnL4S] - De Schepper, K., and B. Briscoe, "Identifying Modified 685 Explicit Congestion Notification (ECN) Semantics for Ultra-Low 686 Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-id, work in 687 progress. 689 Authors' Addresses 691 Donald E. Eastlake, 3rd 692 Futurewei Technologies 693 2386 Panoramic Circle 694 Apopka, FL 32703 USA 696 Tel: +1-508-333-2270 697 Email: d3e3e3@gmail.com 699 Bob Briscoe 700 Independent 701 UK 703 Email: ietf@bobbriscoe.net 704 URI: http://bobbriscoe.net/ 706 Andrew G. Malis 707 Futurewei Technologies 709 Email: agmalis@gmail.com 711 Copyright and IPR Provisions 713 Copyright (c) 2020 IETF Trust and the persons identified as the 714 document authors. All rights reserved. 716 This document is subject to BCP 78 and the IETF Trust's Legal 717 Provisions Relating to IETF Documents 718 (http://trustee.ietf.org/license-info) in effect on the date of 719 publication of this document. Please review these documents 720 carefully, as they describe your rights and restrictions with respect 721 to this document. Code Components extracted from this document must 722 include Simplified BSD License text as described in Section 4.e of 723 the Trust Legal Provisions and are provided without warranty as 724 described in the Simplified BSD License. The definitive version of 725 an IETF Document is that published by, or under the auspices of, the 726 IETF. Versions of IETF Documents that are published by third parties, 727 including those that are translated into other languages, should not 728 be considered to be definitive versions of IETF Documents. The 729 definitive version of these Legal Provisions is that published by, or 730 under the auspices of, the IETF. Versions of these Legal Provisions 731 that are published by third parties, including those that are 732 translated into other languages, should not be considered to be 733 definitive versions of these Legal Provisions. For the avoidance of 734 doubt, each Contributor to the IETF Standards Process licenses each 735 Contribution that he or she makes as part of the IETF Standards 736 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 737 language to the contrary, or terms, conditions or rights that differ 738 from or are inconsistent with the rights and licenses granted under 739 RFC 5378, shall have any effect and shall be null and void, whether 740 published or posted by such Contributor, or included with or in such 741 Contribution.