idnits 2.17.1 draft-ietf-sfc-nsh-ecn-support-04.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 256 has weird spacing: '... sender doma...' == Line 257 has weird spacing: '...ingress v |...' -- The document date (December 6, 2020) is 1231 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 Independent 7 Expires: June 5, 2021 December 6, 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 information about 18 congestion back to upstream nodes, this can improve network 19 efficiency through better congestion control, frequently without 20 packet drops. This document specifies ECN and congestion feedback 21 support within a Service Function Chaining (SFC) architecture domain 22 through use of the Network Service Header (NSH, RFC 8300) and IP Flow 23 Information Export (IPFIX, 24 draft-ietf-tsvwg-tunnel-congestion-feedback). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Distribution of this document is unlimited. Comments should be sent 32 to the SFC Working Group mailing list or to the 33 authors. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 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 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 47 Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 Table of Contents 52 1. Introduction............................................3 53 1.1 NSH Background.........................................3 54 1.2 ECN Background.........................................5 55 1.3 Tunnel Congestion Feedback Background..................5 56 1.4 Conventions Used in This Document......................7 58 2. The NSH ECN Field.......................................8 60 3. ECN Support in the NSH.................................10 61 3.1 At The Ingress........................................11 62 3.2 At Transit Nodes......................................12 63 3.2.1 At NSH Transit Nodes................................12 64 3.2.2 At an SF/Proxy......................................13 65 3.2.3 At Other Forwarding Nodes...........................13 66 3.3 At Exit/Egress........................................13 67 3.4 Conservation of Packets...............................14 69 4. Tunnel Congestion Feedback Support.....................15 71 5. IANA Considerations....................................16 72 5.1 SFC NSH Header ECN Bits...............................16 73 5.2 IPFIX Information Element ID..........................16 75 6. Security Considerations................................17 77 7. Acknowledgements.......................................17 79 Normative References......................................18 80 Informative References....................................18 82 Authors' Addresses........................................20 84 1. Introduction 86 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 87 element to notify downstream devices of the onset of congestion 88 without having to drop packets. Coupled with a means to feed 89 information about congestion back to upstream nodes, this can improve 90 network efficiency through better congestion control, frequently 91 without packet drops. This document specifies ECN and congestion 92 feedback support within a Service Function Chaining (SFC [RFC7665]) 93 architecture domain through use of the Network Service Header (NSH 94 [RFC8300]) and IP Flow Information Export (IPFIX 95 [TunnelCongFeedback]). 97 It requires that all ingress and egress nodes of the SFC domain 98 implement ECN. While congestion management will be the most effective 99 if all interior nodes of the SFC domain implement ECN, some benefit 100 is obtained even if some interior nodes do not implement ECN. 101 Congestion at any interior bottleneck where ECN marking is not 102 implemented will be unmanaged. 104 The subsections below in this section provide background information 105 on NSH, ECN, congestion feedback, and terminology used in this 106 document. 108 1.1 NSH Background 110 The Service Function Chaining (SFC [RFC7665]) architecture calls for 111 the encapsulation of traffic within a service function chaining 112 domain with a Network Service Header (NSH [RFC8300]) added by the 113 "Classifier" (ingress node) on entry to the domain and the NSH being 114 removed on exit from the domain at the egress node. The NSH is used 115 to control the path of a packet in an SFC domain. The NSH is a 116 natural place, in a domain where traffic is NSH encapsulated, to note 117 congestion, avoiding possible confusion due, for example, to changes 118 in the outer transport header in different parts of the domain. 120 | 121 v 122 +----------+ 123 . .|Classifier|. . . . . . . . . . . . . . 124 . +----------+ . 125 . | +----+ . 126 . | --+ SF | Service . 127 . | / +----+ Function . 128 . v --- Chaining . 129 . +-----+/ +----+ domain . 130 . | SFF |--------+ SF | . 131 . +-----+\ +----+ . 132 . | --- . 133 . | \ +----+ . 134 . | --+ SF | . 135 . v +----+ . 136 . +-----+ +----+ . 137 . | SFF |-----------------+ SF | . 138 . +-----+ +----+ . 139 . | +----+ . 140 . | --+ SF | . 141 . | / +----+ . 142 . v --- . 143 . +-----+/ +----+ . 144 . | SFF |--------+ SF | . 145 . +-----+\ +----+ . 146 . | --- . 147 . | \ +----+ . 148 . | --+ SF | . 149 . v +----+ . 150 . +------+ . 151 . . .| Exit |. . . . . . . . . . . . . . . 152 +------+ 153 | 154 v 156 Figure 1. Example SFC Path Forwarding Nodes 158 Figure 1 shows an SFC domain for the purpose of illustrating the use 159 of the NSH. Traffic passes through a sequence of Service Function 160 Forwarders (SFFs) each of which sends the traffic to one or more 161 Service Functions (SFs). Each SF performs some operation on the 162 traffic, for example firewall or Network Address Translation (NAT) or 163 load balancer, and then returns it to the SFF from which it was 164 received. 166 Logically, during the transit of each SFF, the outer transport header 167 that got the packet to the SFF is stripped (see Figure 3), the SFF 168 decides on the next forwarding step, either adding a new transport 169 header or, if the SFF is the exit/egress, removing the NSH header. 170 The transport headers added may be different in different regions of 171 the SFC domain. For example, IP could be used for some SFF-to-SFF 172 communication and MPLS used for other such communication. 174 1.2 ECN Background 176 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 177 element (such as a router or a Service Function Forwarder (SFF) or 178 Service Function (SF)) to notify downstream devices of the onset of 179 congestion without having to drop packets. This can be used as an 180 element in active queue management (AQM) [RFC7567] to improve network 181 efficiency through better traffic control without packet drops. The 182 forwarding element can explicitly mark some packets in an ECN field 183 instead of dropping the packet. For example, a two-bit field is 184 available for ECN marking in IP headers [RFC3168]. 186 1.3 Tunnel Congestion Feedback Background 188 Tunnel Congestion Feedback [TunnelCongFeedback] is a building block 189 for various congestion mitigation methods. It supports feedback of 190 congestion information from an egress node to an ingress node. This 191 document treats the SFC domain as a tunnel with the initial 192 Classifier node being the ingress. 194 Examples of actions that can be taken by an ingress node when it has 195 knowledge of downstream congestion include those listed below. 196 Details of implementing these traffic control methods, beyond those 197 given here, are outside the scope of this document. 199 Any action by a tunnel ingress to reduce congestion needs to allow 200 sufficient time for the end-to-end congestion control loop to respond 201 first, for instance by the ingress taking a smoothed average of the 202 level of congestion signalled by feedback from the tunnel egress. 204 (1) Traffic throttling (policing), where the downstream traffic 205 flowing out of the ingress node is limited to reduce or eliminate 206 congestion. 208 (2) Upstream congestion feedback, where the ingress node sends 209 messages upstream to or towards the ultimate traffic source, a 210 function that can throttle traffic generation/transmission. 212 (3) Traffic re-direction, where the ingress node configures the NSH 213 of some future traffic so that it avoids congested paths. Great 214 care must be taken with this option to avoid (a) significant re- 215 ordering of traffic in flows that it is desirable to keep in 216 order and (b) oscillation/instability in traffic paths due to 217 alternate congestion of previously idle paths and the idling of 218 previously congested paths. For example, it is preferable to 219 classify traffic into flows of a sufficiently coarse granularity 220 that the flows are long lived and then use a stable path per 221 flow, sending only newly appearing flows on apparently 222 uncongested paths. 224 Figure 2 shows an example path from an origin sender to a final 225 receiver passing through an example chain of service functions 226 between the ingress and egress of an SFC domain. The path is also 227 likely to pass through other network nodes outside the SFC domain 228 (not shown) before entering the SFC domain and after leaving the SFC 229 domain. 231 The figure shows typical congestion feedback that would be expected 232 from the final receiver to the origin sender, which controls the load 233 the origin sender applies to all elements on the path. The figure 234 also shows the congestion feedback from the egress to the ingress of 235 the SFC domain that is described in this document, to control or 236 balance load within the SFC domain. 238 .:= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = :. 239 _||_ End-to-End Congestion Feedback || 240 \ / || 241 \/ || 242 __ Inner Transport Header and Payload __ 243 | | ->- - - - - - - - - - - - - - ->- - - - - -- - - - - - ->- | | 244 | | | | 245 | | .:= = = = = = = = = = = = = = = = = = = = = =:. | | 246 | | _||_ Tunnel Congestion Feedback || | | 247 | | \ / || | | 248 | | \/ || | | 249 | | __ NSH __ | | 250 | | | |-------------------------->--------------| | | | 251 | |. . . | | ___ ___ ___ | |. . .| | 252 | | | | OT1 | | OT4 | | . . . | | OTn | | | | 253 | | | |-->--|SFF|--->---|SFF| |SFF|-->--| | | | 254 |__| |__| |___| |___| |___| |__| |__| 255 origin SFC | ^ | ^ SFC final 256 sender domain OT2| |OT3 OT6| |OT7 domain rcvr 257 ingress v | v | egress 258 +---+ +---+ 259 |SF | |SF | 260 +---+ +---+ 262 Figure 2: Congestion Feedback across an SFC Domain 264 SFC Domain congestion feedback in Figure 2 is shown within the 265 context of an end-to-end congestion feedback loop. Also shown is the 266 encapsulated layering of NSH headers within a series of outer 267 transport headers (OT1, OT2, ... OTn). 269 1.4 Conventions Used in This Document 271 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 273 document are to be interpreted as described in [RFC2119] [RFC8174] 274 when, and only when, they appear in all capitals, as shown here. 276 Acronyms: 278 AQM - Active Queue Management [RFC7567] 280 CE - Congestion Experienced [RFC3168] 282 downstream - The direction from ingress to egress 284 ECN - Explicit Congestion Notification [RFC3168] 286 ECT - ECN Capable Transport [RFC3168] 288 IPFIX - IP Flow Information Export [RFC7011] 290 Not-ECT - Not ECN-Capable Transport [RFC3168] 292 NSH - Network Service Header [RFC8300] 294 SF - Service Function [RFC7665] 296 SFC - Service Function Chaining [RFC7665] 298 SFF - Service Function Forwarder [RFC7665] - A type of node that 299 forwards based on the NSH. 301 TLV - Type Length Value 303 upstream - The direction from egress to ingress 305 2. The NSH ECN Field 307 The NSH header is used to encapsulate and control the subsequent path 308 of traffic (see Section 2 of [RFC8300]). The NSH also provides for 309 optional metadata inclusion, as shown in Figure 3. 311 +-----------------------------------+ 312 | Outer Transport Header | 313 +-----------------------------------+ 314 | Network Service Header (NSH) | 315 | +------------------------------+ | 316 | | Base Header | | 317 | +------------------------------+ | 318 | | Service Path Header | | 319 | +------------------------------+ | 320 | | Metadata (Context Header(s)) | | 321 | +------------------------------+ | 322 +-----------------------------------+ 323 | Original Packet / Frame / Payload | 324 +-----------------------------------+ 326 Figure 3. Data Encapsulation with the NSH 328 Two currently unused bits (indicated by "U") in the NSH Base Header 329 (Section 2.2 of [RFC8300]) are allocated for ECN indication as shown 330 in Figure 4. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 ^ ^ 338 | | 339 +-------+ 340 |NSH ECN| 341 | field | 342 +-------+ 344 Figure 4: NSH Base Header 346 Note to RFC Editor: The above figure should be adjusted based on the 347 bits assigned by IANA (see Section 5) and this note deleted. 349 Table 1 shows the meaning of the code points in the NSH ECN field. 350 These have the same meaning as the ECN field code points in the IPv4 351 or IPv6 header as defined in [RFC3168]. 353 Binary Name Meaning 354 ------ ------- -------------------------------- 355 00 Not-ECT Not ECN-Capable Transport 356 01 ECT(1) ECN-Capable Transport 357 10 ECT(0) ECN-Capable Transport 358 11 CE Congestion Experienced 360 Table 1. ECN Field Code Points 362 3. ECN Support in the NSH 364 This section describes the required behavior to support ECN using the 365 NSH. There are two aspects to ECN support: 366 1. ECN propagation during encapsulation or decapsulation 367 2. ECN marking during congestion at bottlenecks. 369 While this section covers all combinations of ECN-aware and ECN- 370 unaware, it is expected that in most cases the NSH domain will be 371 uniform so that, if this document is applicable, all SFFs will 372 support ECN; however, some legacy SFs might not support ECN. 374 ECN Propagation: 376 The specification of ECN tunneling [RFC6040] explains that an 377 ingress must not propagate ECN support into an encapsulating 378 header unless the egress supports correct onward propagation of 379 the ECN field during decapsulation. We define Compliant ECN 380 Decapsulation here as decapsulation compliant with either 381 [RFC6040] or an earlier compatible equivalent ([RFC4301], or the 382 full functionality mode of [RFC3168]). 384 The procedures in Section 3.2.1 ensure that each ingress of the 385 large number of possible transport links within the SFC domain 386 does not propagate ECN support into the encapsulating outer 387 transport header unless the corresponding egress of that link 388 supports Compliant ECN Decapsulation. 390 Section 3.3 requires that all the egress nodes of the SFC domain 391 support Compliant ECN Decapsulation in conjunction with tunnel 392 congestion feedback, otherwise the scheme in this document will 393 not work. 395 ECN Marking: 397 At transit nodes the marking behavior specified in Section 3.2.1 398 is recommended and if not implemented at such transit nodes, there 399 may be unmanaged congestion. 401 Detection of congestion will be most effective if ECN marking is 402 supported by all potential bottlenecks inside the domain in which 403 NSH is being used to route traffic as well as at the ingress and 404 egress. Nodes that do not support ECN marking, or that support 405 AQM but not ECN, will naturally use drop to relieve congestion. 406 The gap in the end-to-end packet sequence will be detected as 407 congestion by the final receiving endpoint, but not by the NSH 408 egress (see Figure 2). 410 3.1 At The Ingress 412 When the ingress/Classifier encapsulates an incoming IP packet with 413 an NSH, it MUST set the NSH ECN field using the "Normal mode" 414 specified in [RFC6040] (i.e., copied from the incoming IP header). 416 Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD 417 set it to ECT(0). This indicates that, even though the end-to-end 418 transport is not ECN-capable, the egress and ingress of the SFC 419 domain are acting as an ECN-capable transport. This approach will 420 inherently support all known variants of ECN, including the 421 experimental L4S capability [RFC8311] [ecnL4S]. 423 Packets arriving at the ingress might not use IP. If the protocol of 424 arriving packets supports an ECN field similar to IP, the procedures 425 for IP packets can be used. If arriving packets do not support an ECN 426 field similar to IP, they MUST be treated as if they are Not-ECT IP 427 packets. 429 Then, as the NSH encapsulated packet is further encapsulated with a 430 transport header, if ECN marking is available for that transport (as 431 it is for IP [RFC3168] and MPLS [RFC5129]), the ECN field of the 432 transport header MUST be set using the "Normal mode" specified in 433 [RFC6040] (i.e., copied from the NSH ECN field). 435 A summary of these normative steps is given in Table 2. 437 +-----------------+---------------+ 438 | Incoming Header | Departing NSH | 439 | (also equal to | and Outer | 440 | departing Inner | Headers | 441 | Header) | | 442 +-----------------+---------------+ 443 | Not-ECT | ECT(0) | 444 | ECT(0) | ECT(0) | 445 | ECT(1) | ECT(1) | 446 | CE | CE | 447 +-----------------+---------------+ 449 Table 2. Setting of ECN fields by an ingress/Classifier 451 The requirements in this section apply to all ingress nodes for the 452 domain in which NSH is being used to route traffic. 454 3.2 At Transit Nodes 456 This section described behavior at nodes that forward based on the 457 NSH such as SFF and other forwarding nodes such as IP routers. Figure 458 5 shows a packet on the wire between forwarding nodes. 460 +-----------------+ 461 | Outer Header | 462 +-----------------+ 463 | NSH | 464 +-----------------+ 465 | Inner Header | 466 +-----------------+ 467 | Payload | 468 +-----------------+ 470 Figure 5. Packet in Transit 472 3.2.1 At NSH Transit Nodes 474 When a packet is received at an NSH based forwarding node such as an 475 SFF, say N1, the outer transport encapsulation is removed and its ECN 476 marking SHOULD be combined into the NSH ECN marking as specified in 477 [RFC6040]. If this is not done, any congestion encountered at non-NSH 478 transit nodes between N1 and the next upstream NSH based forwarding 479 node will be lost and not transmitted downstream. 481 The NSH forwarding node SHOULD use a recognized AQM algorithm 482 [RFC7567] to detect congestion. If the NSH ECN field indicates ECT, 483 it will probabilistically set the NSH ECN field to the Congestion 484 Experienced (CE) value or, in cases of extreme congestion, drop the 485 packet. 487 When the NSH encapsulated packet is further encapsulated for 488 transmission to the next SFF or SF, ECN marking behavior depends on 489 whether or not the node that will decapsulate the outer header 490 supports Compliant ECN Decapsulation (see Section 3). If it does, 491 then the encapsulating node propagates the NSH ECN field to this 492 outer encapsulation using the "Normal Mode" of ECN encapsulation 493 [RFC6040] (the ECN field is copied). If it does not, then the 494 encapsulating node MUST clear ECN in the outer encapsulation to non- 495 ECT (the "Compatibility Mode" of [RFC6040]). 497 3.2.2 At an SF/Proxy 499 If the SF is NSH and ECN-aware, the processing is essentially the 500 same at the SF as at an SFF as discussed in Section 3.2.1. 502 If the SF is NSH-aware but ECN-unaware, then the SFF transmitting the 503 packet to the SF will use Compatibility Mode. Congestion encountered 504 in the SFF to SF and SF to SFF paths will be unmanaged. 506 If the SF is not NSH-aware, then an NSH proxy will be between the SFF 507 and the SF to avoid exposure of the NSH to the SF that does not 508 understand NSHs. This is described in Section 4.6 of [RFC7665]. The 509 SF and proxy together look to the SFF like an NSH-aware SF. The 510 behavior at the proxy and SF in this case is as below: 512 If such a proxy is not ECN-aware then congestion in the entire 513 path from SFF to proxy to SF back to proxy to SFF will be 514 unmanaged. 516 If the proxy is ECN-aware, the proxy uses an AQM to indicate 517 congestion within the proxy in the NSH that it returns to the SFF. 518 The outer header used for the proxy to SF path uses Normal Mode. 519 The outer head used for the proxy return to SFF path uses Normal 520 Mode based copying of the NSH ECN field to the outer header. Thus 521 congestion in the proxy will be managed. Congestion in the SF will 522 be managed only if the SF is ECN-aware implementing an AQM. 524 3.2.3 At Other Forwarding Nodes 526 Other forwarding nodes, that is non-NSH forwarding nodes between NSH 527 forwarding nodes, such as IP or label switched routers, might also 528 contain potential bottlenecks. If so, they SHOULD implement an AQM 529 algorithm to update the ECN marking in the outer transport header as 530 specified in [RFC3168]. 532 3.3 At Exit/Egress 534 First, any actions are taken based on Congestion Experienced or other 535 values of ECN marking, such as accumulating statistics to forward 536 back to the ingress (see Section 4). If the packet being carried 537 inside the NSH is IP, when the NSH is removed the NSH ECN field MUST 538 be combined with the IP ECN field as specified in Table 3 that was 539 extracted from [RFC6040]. This requirement applies to all egress 540 nodes for the domain in which NSH is being used to route traffic. 542 +---------+---------------------------------------------+ 543 |Arriving | Arriving Outer Header | 544 | Inner +---------+-----------+-----------+-----------+ 545 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 546 +---------+---------+-----------+-----------+-----------+ 547 | Not-ECT | Not-ECT |Not-ECT |Not-ECT | | 548 | ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE | 549 | ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE | 550 | CE | CE | CE | CE | CE | 551 +---------+---------+-----------+-----------+-----------+ 553 Table 3. Exit ECN Fields Merger 555 All the egress nodes of the SFC domain MUST support Compliant ECN 556 Decapsulation as specified in this section. If this is not the case, 557 the scheme described in this document will not work, and cannot be 558 used. 560 3.4 Conservation of Packets 562 The SFC specification permits an SF to absorb packets and to generate 563 new packets as well as simply processing and forwarding the packets 564 it receives. Such actions might appear to be packet loss due to 565 congestion or might mask the loss of packets by generating additional 566 packets. 568 The tunnel congestion feedback approach [TunnelCongFeedback] detects 569 loss by counting payload bytes in at the ingress and counting them 570 out at the egress. This does not work unless nodes conserve the 571 amount of payload bytes. Therefore, it will not be possible to detect 572 loss using this technique if they are not conserved. 574 Nonetheless, if a bottleneck supports ECN marking, it will be 575 possible to detect the very high level of CE markings that are 576 associated with congestion that is so excessive that it leads to 577 loss. However, it will not be possible for the tunnel congestion 578 feedback approach to detect any congestion, whether slight or severe, 579 if it occurs at a bottleneck that does not support ECN marking. 581 4. Tunnel Congestion Feedback Support 583 The collection and storage of congestion information at the egress 584 may be useful for later analysis but, unless it can be fed back to a 585 point which can take action to reduce congestion, it will not be 586 useful in real time. Such congestion feedback to the ingress enables 587 it to take actions such as those listed in Section 1.3. 589 IP Flow Information Export (IPFIX [RFC7011]) provides a standard for 590 communicating traffic flow statistics. As extended by 591 [TunnelCongFeedback] and herein, IPFIX messages from the egress to 592 the ingress are used to communicate the extent of congestion between 593 an ingress and egress based on ECN marking in the NSH. For example, 594 the tunnelEcnCEMarkedRatio field, specified in [TunnelCongFeedback], 595 indicates tha fraction of traffic that has been marked in the ECN 596 field of the NSH as Congestion Experienced (CE). 598 In order to identify SFC flows, so that congestion can be measured 599 and reported at that granularity, it is necessary for IPFIX to be 600 able to classify traffic based on the Service Path Identifier field 601 of the NSH [RFC8300]. Thus an NSH Service Path Identifier 602 (nshServicePathID) IPFIX Information Element [RFC7012] is specified 603 as follows for use in this application of IPFIX: 605 Name: nshServicePathID 607 Description: Network Service Header [RFC8300] Service Path 608 Identifier. This is a 24-bit value which is left justified in 609 the Information Element. The low order byte MUST be sent as 610 zero and ignored on receipt. 612 Abstract Data Type: unsigned32 614 Data Type Semantics: identifier 616 ElementID: tbd 618 Status: current 620 IPFIX recommends, but does not require, use of SCTP [RFC4960] in 621 partial reliability mode for the transport of its messages. This mode 622 allows loss of some packets, which is tolerable because IPFIX 623 communicates cumulative statistics. IPFIX over SCTP SHOULD be used 624 directly where there is IP connectivity between the ingress and 625 egress; however, there might be different transport protocols or 626 address spaces used in different regions of an SFC domain that make 627 such direct IP connectivity problematic. The NSH provides the general 628 method of routing traffic within such an SFC domain so the IPFIX 629 traffic MUST be encapsulated in NSH when IP connectivity is not 630 available. 632 5. IANA Considerations 634 5.1 SFC NSH Header ECN Bits 636 IANA is requested to assign two contiguous bits in the NSH Base 637 Header Bits registry for ECN (bits 16 and 17 suggested) and note this 638 assignment as follows: 640 Bit Description Reference 641 ---------- ----------- --------------- 642 tbd(16-17) NSH ECN [this document] 644 5.2 IPFIX Information Element ID 646 IANA is request to assign an IPFIX Information Element ID as follows: 648 ElementID: tbd 649 Name: nshServicePathID 650 Data Type: unsigned32 651 Data Type Semantics: identifier 652 Status: current 653 Description: The Network Service Header [RFC8300] Service Path 654 Identifier. 656 6. Security Considerations 658 For general NSH security considerations, see [RFC8300]. 660 For security considerations concerning tampering with ECN signaling, 661 see [RFC3168]. For security considerations concerning ECN and 662 encapsulation, see [RFC6040]. 664 For general IPFIX security considerations, see [RFC7011]. If deployed 665 in an untrusted environment, the signaling traffic between ingress 666 and egress can be protected utilizing the security mechanisms 667 provided by IPFIX (see Section 11 in [RFC7011]). 669 The solution in this document does not introduce any greater 670 potential to invade privacy than would have been available without 671 the solution. 673 7. Acknowledgements 675 The authors wish to thank the following for their comments and 676 suggestion: 678 Joel Halpern, Tal Mizrahi, Xinpeng Wei 680 Normative References 682 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 684 March 1997, . 686 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 687 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 688 10.17487/RFC3168, September 2001, . 691 [RFC5129] - Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 692 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, 693 . 695 [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion 696 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, 697 . 699 [RFC7011] - Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 700 "Specification of the IP Flow Information Export (IPFIX) 701 Protocol for the Exchange of Flow Information", STD 77, RFC 702 7011, DOI 10.17487/RFC7011, September 2013, . 705 [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF 706 Recommendations Regarding Active Queue Management", BCP 197, 707 RFC 7567, DOI 10.17487/RFC7567, July 2015, . 710 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 711 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 712 2017, 714 [RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 715 "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, 716 January 2018, . 718 [TunnelCongFeedback] - Wei, X., Li, Y., Boutros, S., and L. Deng, 719 "Tunnel Congestion Feedback", draft-ietf-tsvwg-tunnel- 720 congestion-feedback, work in progress. 722 Informative References 724 [RFC4301] - Kent, S. and K. Seo, "Security Architecture for the 725 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 726 2005, . 728 [RFC4960] - Stewart, R., Ed., "Stream Control Transmission Protocol", 729 RFC 4960, DOI 10.17487/RFC4960, September 2007, 730 . 732 [RFC7665] - Halpern, J., Ed., and C. Pignataro, Ed., "Service 733 Function Chaining (SFC) Architecture", RFC 7665, DOI 734 10.17487/RFC7665, October 2015, . 737 [RFC7012] - Claise, B., Ed., and B. Trammell, Ed., "Information Model 738 for IP Flow Information Export (IPFIX)", RFC 7012, DOI 739 10.17487/RFC7012, September 2013, . 742 [RFC8311] - Black, D., "Relaxing Restrictions on Explicit Congestion 743 Notification (ECN) Experimentation", RFC 8311, DOI 744 10.17487/RFC8311, January 2018, . 747 [ecnL4S] - De Schepper, K., and B. Briscoe, "Identifying Modified 748 Explicit Congestion Notification (ECN) Semantics for Ultra-Low 749 Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-id, work in 750 progress. 752 Authors' Addresses 754 Donald E. Eastlake, 3rd 755 Futurewei Technologies 756 2386 Panoramic Circle 757 Apopka, FL 32703 USA 759 Tel: +1-508-333-2270 760 Email: d3e3e3@gmail.com 762 Bob Briscoe 763 Independent 764 UK 766 Email: ietf@bobbriscoe.net 767 URI: http://bobbriscoe.net/ 769 Andrew G. Malis 770 Independent 772 Email: agmalis@gmail.com 774 Copyright and IPR Provisions 776 Copyright (c) 2020 IETF Trust and the persons identified as the 777 document authors. All rights reserved. 779 This document is subject to BCP 78 and the IETF Trust's Legal 780 Provisions Relating to IETF Documents 781 (http://trustee.ietf.org/license-info) in effect on the date of 782 publication of this document. Please review these documents 783 carefully, as they describe your rights and restrictions with respect 784 to this document. Code Components extracted from this document must 785 include Simplified BSD License text as described in Section 4.e of 786 the Trust Legal Provisions and are provided without warranty as 787 described in the Simplified BSD License. The definitive version of 788 an IETF Document is that published by, or under the auspices of, the 789 IETF. Versions of IETF Documents that are published by third parties, 790 including those that are translated into other languages, should not 791 be considered to be definitive versions of IETF Documents. The 792 definitive version of these Legal Provisions is that published by, or 793 under the auspices of, the IETF. Versions of these Legal Provisions 794 that are published by third parties, including those that are 795 translated into other languages, should not be considered to be 796 definitive versions of these Legal Provisions. For the avoidance of 797 doubt, each Contributor to the IETF Standards Process licenses each 798 Contribution that he or she makes as part of the IETF Standards 799 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 800 language to the contrary, or terms, conditions or rights that differ 801 from or are inconsistent with the rights and licenses granted under 802 RFC 5378, shall have any effect and shall be null and void, whether 803 published or posted by such Contributor, or included with or in such 804 Contribution.