idnits 2.17.1 draft-leymann-banana-ecn-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 (September 12, 2017) is 2418 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3168' is mentioned on line 133, but not defined == Missing Reference: 'RFC 6040' is mentioned on line 152, but not defined == Unused Reference: 'RFC2784' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'RFC2890' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'TSVWG-ECN' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'BANANA-signaling' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'BANANA-attributes' is defined on line 324, but no explicit reference was found in the text -- Duplicate reference: RFC3168, mentioned in 'RFC6040', was also mentioned in 'RFC3168'. ** Downref: Normative reference to an Informational RFC: RFC 8157 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BANANA N. Leymann 3 INTERNET-DRAFT C. Heidemann 4 Intended Category: Standards Track Deutsche Telekom AG 5 J. Shen 6 China Telecom Co., Ltd 7 L. Geng 8 China Mobile 9 L. Chen 10 M. Zhang 11 X. Geng 12 Huawei 13 Expires: March 16, 2018 September 12, 2017 15 BANdwidth Aggregation for interNet Access (BANANA) 16 ECN Operations for Bonding Tunnels 17 draft-leymann-banana-ecn-00 19 Abstract 21 This document specifies a Bonding Tunnel ECN Mechanism that uses 22 Explicit Congestion Notification (ECN) in bonding tunnels to notify 23 congestion of a tunnel so that the load-balancing strategy of the 24 tunnel ingress can be adjusted accordingly. Attributes for the 25 control protocol of BANANA are defined to support this mechanism. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. ECN Features of IP-in-IP Bonding Tunnels . . . . . . . . . . . 3 68 2.1. ECN Features . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.2. ECN Features of IP-in-IP Tunnels . . . . . . . . . . . . . 4 70 2.3. Bonding Tunnel ECN Mechanism . . . . . . . . . . . . . . . 5 71 3. ECN Capability in Bonding Tunnels . . . . . . . . . . . . . . . 6 72 4. Congestion Notification in Bonding Tunnels . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 Conventionally, ECN allows end-to-end notification of network 83 congestion without dropping packets [RFC3168], and the sender reduces 84 its transmission rate when it receives the congestion indication. ECN 85 may be used between two ECN-enabled endpoints when the underlying 86 network infrastructure also supports it. [RFC6040] redefines how the 87 ECN field of the IP header should be constructed on entry to and exit 88 from any IP-in-IP tunnel. 90 This document, however, focuses on load-balancing adjustment between 91 bonding tunnels rather than end-to-end transmission rate adjustment. 92 When establishing the bonding tunnels, the local BANANA box and the 93 remote BANANA box negotiate whether the Bonding Tunnel ECN Mechanism 94 is supported. When this is successfully negotiated, an ECN-aware 95 router may set a mark on the ECN field of the outer IP header of any 96 packets in the tunnel. As soon as the bonding tunnel egress (one of 97 the BANANA boxes) receives the packet with that mark, it will send an 98 Congestion Notification to the bonding tunnel ingress (the other 99 BANANA box) to inform congestion so that the ingress can change the 100 load-balancing strategy accordingly. 102 ECN Capability and Congestion Notification are two attributes for the 103 control protocol of BANANA defined to support the Bonding Tunnel ECN 104 Mechanism. 106 1.1. Terminology 108 AQM: Active Queue Management 110 CE: Congestion Experienced 112 ECN: Explicit Congestion Notification 114 ECT: ECN-Capable Transport 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 2. ECN Features of IP-in-IP Bonding Tunnels 122 2.1. ECN Features 124 The ECN field in the IP header has two bits, making four ECN 125 codepoints, '00' to '11', as shown in Figure 1. The not-ECT (ECN- 126 Capable Transport) codepoint '00' indicates a packet that is not 127 using ECN. The ECT codepoints '10' and '01' are set by the data 128 sender to indicate that the end-points of the transport protocol are 129 ECN-capable. Senders are free to use either the ECT(0) or ECT(1) and 130 routers treat ECT(0) and ECT(1) as equivalent. AQM allows routers to 131 use the CE (Congestion Experienced) codepoint '11' in a packet header 132 as an indication of congestion, instead of relying solely on packet 133 drops. [RFC 3168] 135 +----+----+ 136 |ECN FIELD| 137 +----+----+ 138 0 0 Not-ECT 139 0 1 ECT(1) 140 1 0 ECT(0) 141 1 1 CE 143 Figure 1 The ECN Field in IP 145 2.2. ECN Features of IP-in-IP Tunnels 147 While the outer header of an IP packet can encapsulate one or more IP 148 headers for IP-in-IP tunneling, routers using ECN to signify 149 congestion only mark the immediately visible outer IP header. When 150 the tunnel decapsulator later removes this outer header, it follows 151 rules to propagate congestion markings by combining the ECN fields of 152 the inner and outer IP header into one outgoing IP header. [RFC 6040] 154 Figure 2 shows an example about how ECN works in the IP-in-IP tunnel 155 scenario. 157 Sender reduces rate Receiver reports the CE packet 158 +-------------------- <------------------------------+ 159 | Outer IP +-+-+ +-+-+ +-+-+ | 160 | ECN field |1 0| |1 0| |1 1| | 161 | +-+-+ +-+-+ +-+-+ | 162 v +-------+ +------+ | 163 +------+ |Tunnel | +------+ +------+ |Tunnel| +--------+ 164 |Sender|->-|Ingress|->-|Router|->-|Router|->-|Egress|->-|Receiver| 165 +------+ +-------+ +------+ +------+ +------+ +--------+ 166 +-+-+ +-+-+ +-+-+ ^ +-+-+ +-+-+ 167 ECN |1 0| |1 0| |1 0| | |1 0| |1 1| 168 field +-+-+ +-+-+ +-+-+ | +-+-+ +-+-+ 169 | 170 congestion 172 Figure 2 An IP-in-IP Tunnel ECN example 174 2.3. Bonding Tunnel ECN Mechanism 176 In the IP-in-IP bonding tunnel scenario, the tunnel ingress has an 177 additional load balancing function compared to the single tunnel 178 scenario. Thus, ECN can be used to notify congestion within the 179 bonding tunnels. As Figure 3 shows, the tunnel egress receives a 180 packet with the CE codepoint from Tunnel 2. Then, the tunnel egress 181 reports this situation to the tunnel ingress by sending an Congestion 182 Notification through Tunnel 2 so that the tunnel ingress can change 183 its load balancing strategy, e.g., temporarily reducing the load- 184 balance proportion for Tunnel 2. As the tunnel ingress may receive 185 more than one Congestion Notification during a certain time period, 186 the load-balance strategy of the next time period can be made based 187 on the number of received Congestion Notifications. 189 Outer IP +-+-+ +-+-+ +-+-+ 190 ECN field |1 0| |1 0| |1 0| 191 +-+-+ +-+-+ +-+-+ 192 +------+ +------+ 193 +-->--|Router|-->--|Router|-->--+ Tunnel 1 194 | +------+ +------+ | 195 +-------+ +------+ 196 +------+ |Tunnel | |Tunnel| +--------+ 197 |Sender|->-|Ingress| --<-- Congestion --<-- |Egress|->-|Receiver| 198 +------+ +-------+ Notification +------+ +--------+ 199 | +------+ +------+ | 200 +-->--|Router|-->--|Router|-->--+ Tunnel 2 201 +------+ +------+ 202 Outer IP +-+-+ +-+-+ ^ +-+-+ 203 ECN field |1 0| |1 0| | |1 1| 204 +-+-+ +-+-+ | +-+-+ 205 | 206 congestion 208 Figure 3 An IP-in-IP Bonding Tunnel ECN example 210 At the tunnel ingress, the ECN field of the incoming packets will be 211 copied to the inner IP headers. The outer IP headers will be set to 212 the ECT or not-ECT codepoint, according to whether the bonding tunnel 213 supports the Bonding Tunnel ECN Mechanism or not. 215 At the tunnel egress, if the outer IP headers from Tunnel 1 and 216 Tunnel 2 are both CE and the inner IP headers are ECT, the ECN field 217 of the outgoing packet will be set to CE. Otherwise the ECN field of 218 the outgoing packet will be copied from the inner IP headers. 220 3. ECN Capability in Bonding Tunnels 222 The local BANANA box (could be either the tunnel ingress or the 223 tunnel egress) uses the ECN Capability to notify the remote BANANA 224 box (could be either the tunnel egress or the tunnel ingress) that 225 the local BANANA box supports the Bonding Tunnel ECN Mechanism. The 226 first GRE Tunnel Setup Request message [RFC8157] MAY include the ECN 227 Capability attribute. 229 +-+-+-+-+-+-+-+-+ 230 |Attribute Type | (1 byte) 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Attribute Length | (2 bytes) 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Attribute Type 236 ECN Capability, set to 36. 238 Attribute Length 239 Set to 0 241 If the remote BANANA box receives the GRE Tunnel Setup Request 242 message with the ECN Capability attribute included, the remote BANANA 243 box could use the ECN Capability to inform the local BANANA box that 244 the remote BANANA box supports the Bonding Tunnel ECN Mechanism as 245 well. The first GRE Tunnel Setup Accept message MAY include the ECN 246 Capability attribute. 248 The remote BANANA box activates the Bonding Tunnel ECN Mechanism when 249 it sends out the ECN Capability attribute. The local BANANA box 250 activates the Bonding Tunnel ECN Mechanism when it receives the ECN 251 Capability attribute from the remote BANANA box. 253 4. Congestion Notification in Bonding Tunnels 255 The tunnel egress (could be either the local BANANA box or the remote 256 BANANA box) uses the Congestion Notification to notify congestion on 257 Tunnel 1 or Tunnel 2 to the tunnel ingress. GRE Tunnel Notify 258 messages sent over both Tunnel 1 and Tunnel 2 MAY include the 259 Congestion Notification attribute. 261 +-+-+-+-+-+-+-+-+ 262 |Attribute Type | (1 byte) 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Attribute Length | (2 bytes) 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Attribute Type 267 Congestion Notification, set to 37. 269 Attribute Length 270 Set to 0. 272 5. Security Considerations 274 276 6. IANA Considerations 278 No IANA action is required in this document. RFC Editor: please 279 remove this section before publication. 281 7. References 283 7.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, DOI 287 10.17487/RFC2119, March 1997, . 290 [RFC3168] Ramakrishnan, K., "The Addition of Explicit Congestion 291 Notification (ECN) to IP", RFC3168, DOI 10.17487/RFC3168, 292 September 2001, . 294 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 295 Notification", RFC6040, DOI 10.17487/RFC6040, November 296 2010, . 298 [RFC8157] Leymann, N., "Huawei's GRE Tunnel Bonding Protocol", 299 RFC8157, DOI 10.17487/RFC8157, May 2017, . 302 7.2. Informative References 304 [RFC2784] Farinacci, D., "Generic Routing Encapsulation (GRE)", 305 RFC2784, DOI 10.17487/RFC2784, March 2000, 306 . 308 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 309 RFC2890, DOI 10.17487/RFC2890, September 2000, 310 . 312 [TSVWG-ECN] 313 Briscoe, B., "Layered Encapsulation of Congestion 314 Notification", draft-briscoe-tsvwg-ecn-tunnel-01, 315 . 318 [BANANA-signaling] 319 Leymann, N., Heidemann, C., et al, "BANdwidth Aggregation 320 for interNet Access (BANANA) The Control Protocol of 321 Bonding Tunnels", draft-leymann-banana-signaling, work in 322 progress. 324 [BANANA-attributes] 325 Leymann, N., Heidemann, C., et al, "BANdwidth Aggregation 326 for interNet Access (BANANA) Attributes for the Control 327 Protocol of Bonding Tunnels", draft-leymann-banana- 328 signaling-attributes, work in progress. 330 Authors' Addresses 332 Nicolai Leymann 333 Deutsche Telekom AG 334 Winterfeldtstrasse 21-27 335 Berlin 10781 336 Germany 338 Phone: +49-170-2275345 339 EMail: n.leymann@telekom.de 341 Cornelius Heidemann 342 Deutsche Telekom AG 343 Heinrich-Hertz-Strasse 3-7 344 Darmstadt 64295 345 Germany 347 Phone: +4961515812721 348 EMail:heidemannc@telekom.de 350 Jun Shen 351 China Telecom Co., Ltd 352 109 West Zhongshan Ave, Tianhe District 353 Guangzhou 510630 354 P.R. China 356 EMail: shenjun@gsta.com 357 Liang Geng 358 China Mobile 359 32 Xuanwumen West Street, 360 Xicheng District, Beijing, 100053, 361 P.R. China 363 EMail: gengliang@chinamobile.com 365 Lihao Chen 366 Huawei Technologies 367 No.156 Beiqing Rd. Haidian District, 368 Beijing 100095 369 P.R. China 371 EMail: lihao.chen@huawei.com 373 Mingui Zhang 374 Huawei Technologies 375 No.156 Beiqing Rd. Haidian District, 376 Beijing 100095 377 P.R. China 379 EMail: zhangmingui@huawei.com 381 Xuesong Geng 382 Huawei Technologies 383 No.156 Beiqing Rd. Haidian District, 384 Beijing 100095 385 P.R. China 387 EMail: gengxuesong@huawei.com