idnits 2.17.1 draft-eastlake-sfc-nsh-ecn-support-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2243 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Intended status: Proposed Standard Huawei 3 Bob Briscoe 4 Independent 5 Expires: September 4, 2018 March 5, 2018 7 Network Service Header (NSH) 8 Explicit Congestion Notification (ECN) Support 9 11 Abstract 13 Explicit congestion notification (ECN) allows a forwarding element to 14 notify downstream devices of the onset of congestion without having 15 to drop packets. This can improve network efficiency through better 16 congestion control without packet drops. This document specifies ECN 17 support within Service Function Chaining (SFC) domains through use of 18 the Network Service Header (NSH). 20 Status of This Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Distribution of this document is unlimited. Comments should be sent 26 to the SFC Working Group mailing list . 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 40 Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Table of Contents 45 1. Introduction............................................3 46 1.1 Conventions used in this document......................4 48 2. The NSH ECN Field.......................................5 50 3. ECN Support.............................................7 51 3.1 At Classifier..........................................7 52 3.2 At SFFs and SFs........................................7 53 3.3 At Exit................................................7 55 4. IANA Considerations.....................................8 56 5. Security Considerations.................................9 58 6. Acknowledgements........................................9 60 Normative References......................................10 61 Informative References....................................10 63 Authors' Addresses........................................11 65 1. Introduction 67 The Network Service Header (NSH [RFC8300]) is used to control the 68 propagation of packets through a Service Function Chaining (SFC 69 [RFC7665]) domain as discussed below. The SFC architecture calls for 70 the encapsulation of traffic inside a service function chaining 71 domain with an NSH being added by the "Classifier" on entry to the 72 domain and the NSH being removed on exit from the domain. Thus the 73 NSH is a natural place to note congestion within the SFC domain, 74 avoiding possible confusion due, for example, to changes in the outer 75 transport header in different parts of the SFC domain. 77 | 78 v 79 +----------+ 80 . .|Classifier|. . . . . . . . . . . . . . 81 . +----------+ . 82 . | +----+ . 83 . | --+ SF | Service . 84 . | / +----+ Function . 85 . v --- Chaining . 86 . +-----+/ +----+ domain . 87 . | SFF |--------+ SF | . 88 . +-----+\ +----+ . 89 . | --- . 90 . | \ +----+ . 91 . | --+ SF | . 92 . v +----+ . 93 . +-----+ +----+ . 94 . | SFF |-----------------+ SF | . 95 . +-----+ +----+ . 96 . | +----+ . 97 . | --+ SF | . 98 . | / +----+ . 99 . v --- . 100 . +-----+/ +----+ . 101 . | SFF |--------+ SF | . 102 . +-----+\ +----+ . 103 . | --- . 104 . | \ +----+ . 105 . | --+ SF | . 106 . v +----+ . 107 . +------+ . 108 . . .| Exit |. . . . . . . . . . . . . . . 109 +------+ 110 | 111 v 113 Figure 1. Example Path Forwarding Nodes 115 Figure 1 shows an SFC domain. Traffic passes through a sequence of 116 Service Function Forwarders (SFFs) each of which sends the traffic to 117 one or more Service Functions (SFs). Each SF performs some operation 118 on the traffic, for example firewall or Network Address Translation 119 (NAT), and returns it to the SFF from which it was received. 121 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 122 element (such as a router or an SFC Service Function Forwarder (SFF) 123 or Service Function (SF)) to notify downstream devices of the onset 124 of congestion without having to drop packets. This can be used as an 125 element in active queue management or the like [RFC7567] to improve 126 network efficiency through better flow control without packet drops. 127 The forwarding element can explicitly mark a proportion of packets in 128 an ECN field instead of dropping the packet. For example, a two-bit 129 field is available for ECN marking in IP headers [RFC3168]. 131 The availability of congestion information is a building block for 132 various congestion mitigation methods. 134 1.1 Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119] [RFC8174] 139 when, and only when, they appear in all capitals, as shown here. 141 Acronyms: 143 CE - Congestion Experienced 145 ECN - Explicit Congestion Notification 147 ECT - ECN Capable Transport 149 Not-ECT - Not ECN-Capable Transport 151 SFC - Service Function Chaining [RFC7665] 153 2. The NSH ECN Field 155 Traffic within an SFC domain is encapsulated within an NSH header 156 (see Section 2 of [RFC8300]) as shown in Figure 1. 158 +-----------------------------------+ 159 | Transport Encapsulation | 160 +-----------------------------------+ 161 | Network Service Header (NSH) | 162 | +------------------------------+ | 163 | | Base Header | | 164 | +------------------------------+ | 165 | | Service Path Header | | 166 | +------------------------------+ | 167 | | Metadata (Context Header(s)) | | 168 | +------------------------------+ | 169 +-----------------------------------+ 170 | Original Packet / Frame | 171 +-----------------------------------+ 173 Figure 1. Data Encapsulation in an SFC Domain 175 Two currently unused bits (indicated by "U") in the NSH Base Header 176 (Section 2.2 of [RFC8300]) are allocated for ECN within the SFC 177 domain as shown in Figure 2. 179 0 1 2 3 180 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 ^ ^ 185 | | 186 +-------+ 187 |NSH ECN| 188 | field | 189 +-------+ 191 Figure 2: NSH Base Header 193 Note to RFC Editor: The above figure should be adjusted based on the 194 bits assigned in Section 4 and this note deleted. 196 Table 1 shows the meaning of the codepoints in the SFC ECN field. 197 These have the same meaning as the ECN field codepoints in the IPv4 198 or IPv6 header as defined in [RFC3168]. 200 Binary Name Meaning 201 ------ ------- ----------------------------------- 202 00 Not-ECT Not ECN-Capable Transport 203 01 ECT(1) ECN-Capable Transport 204 10 ECT(0) ECN-Capable Transport 205 11 CE Congestion Experienced 207 Table 1. ECN Field Codepoints 209 3. ECN Support 211 This section describes the required behavior to support ECN covering 212 the SFC domain. 214 3.1 At Classifier 216 When the NSH is added to incoming traffic, the NSH ECN field MUST be 217 set to the ECN-Capable Transport field. 219 3.2 At SFFs and SFs 221 Any SFFs and SFs that provides NSH ECN support, if it detects 222 congestion and the NSH ECN field indicates that ECN is supported, 223 MUST set the NSH EC field to the Congestion Experienced value. 225 3.3 At Exit 227 In addition to whatever other actions are taken based on Congestion 228 Experienced, if the original packet being carried inside the NSH is 229 IP, the NSH ECN field MUST be combined with IP ECN field as specified 230 in Table 2 that was extracted from [RFC6040].. 232 +---------+---------------------------------------------+ 233 |Arriving | Arriving Outer Header | 234 | Inner +---------+-----------+-----------+-----------+ 235 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 236 +---------+---------+-----------+-----------+-----------+ 237 | Not-ECT | Not-ECT |Not-ECT |Not-ECT | | 238 | ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE | 239 | ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE | 240 | CE | CE | CE | CE | CE | 241 +---------+---------+-----------+-----------+-----------+ 243 Table 2. Exit ECN Fields Merger 245 4. IANA Considerations 247 IANA is requested to assign two contiguous bits in the NSH Base 248 Header Bits registry for ECN (bits 16 and 17 suggested) and note this 249 assignment as follows: 251 Bit Description Reference 252 ---------- ----------- --------------- 253 tbd(16-17) NSH ECN [this document] 255 5. Security Considerations 257 TBD 259 For general SFC Security Considerations, see [RFC7665]. 261 6. Acknowledgements 263 TBD 265 Normative References 267 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 269 March 1997, . 271 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 272 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 273 10.17487/RFC3168, September 2001, . 276 [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion 277 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, 278 . 280 [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF 281 Recommendations Regarding Active Queue Management", BCP 197, 282 RFC 7567, DOI 10.17487/RFC7567, July 2015, . 285 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 286 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 287 2017, 289 [RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 290 "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, 291 January 2018, . 293 Informative References 295 [RFC7665] - Halpern, J., Ed., and C. Pignataro, Ed., "Service 296 Function Chaining (SFC) Architecture", RFC 7665, DOI 297 10.17487/RFC7665, October 2015, . 300 Authors' Addresses 302 Donald E. Eastlake, 3rd 303 Huawei Technologies 304 155 Beaver Street 305 Milford, MA 01757 USA 307 Tel: +1-508-333-2270 308 Email: d3e3e3@gmail.com 310 Bob Briscoe 311 Independent 312 UK 314 Email: ietf@bobbriscoe.net 315 URI: http://bobbriscoe.net/ 317 Copyright and IPR Provisions 319 Copyright (c) 2018 IETF Trust and the persons identified as the 320 document authors. All rights reserved. 322 This document is subject to BCP 78 and the IETF Trust's Legal 323 Provisions Relating to IETF Documents 324 (http://trustee.ietf.org/license-info) in effect on the date of 325 publication of this document. Please review these documents 326 carefully, as they describe your rights and restrictions with respect 327 to this document. Code Components extracted from this document must 328 include Simplified BSD License text as described in Section 4.e of 329 the Trust Legal Provisions and are provided without warranty as 330 described in the Simplified BSD License. The definitive version of 331 an IETF Document is that published by, or under the auspices of, the 332 IETF. Versions of IETF Documents that are published by third parties, 333 including those that are translated into other languages, should not 334 be considered to be definitive versions of IETF Documents. The 335 definitive version of these Legal Provisions is that published by, or 336 under the auspices of, the IETF. Versions of these Legal Provisions 337 that are published by third parties, including those that are 338 translated into other languages, should not be considered to be 339 definitive versions of these Legal Provisions. For the avoidance of 340 doubt, each Contributor to the IETF Standards Process licenses each 341 Contribution that he or she makes as part of the IETF Standards 342 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 343 language to the contrary, or terms, conditions or rights that differ 344 from or are inconsistent with the rights and licenses granted under 345 RFC 5378, shall have any effect and shall be null and void, whether 346 published or posted by such Contributor, or included with or in such 347 Contribution.