idnits 2.17.1 draft-ietf-mpls-ecn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1999) is 9080 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) == Unused Reference: 'RFC2481' is defined on line 351, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ECN' -- Possible downref: Non-RFC (?) normative reference: ref. 'F94' -- No information found for draft-ipsec-ecn - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FBR99' -- Possible downref: Normative reference to a draft: ref. 'LeF99' ** Obsolete normative reference: RFC 2309 (Obsoleted by RFC 7567) ** Obsolete normative reference: RFC 2481 (Obsoleted by RFC 3168) == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-04 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force K. K. Ramakrishnan, AT&T Research 2 INTERNET DRAFT Sally Floyd, ACIRI 3 draft-ietf-mpls-ecn-00.txt Bruce Davie, Cisco 4 June 1999 5 Expires: Dec 1999 7 A Proposal to Incorporate ECN in MPLS 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 We propose the addition of ECN to MPLS switching. ECN enables end- 33 end congestion control without necessarily depending on packet loss 34 as the sole indicator of congestion. The proposal suggests having a 35 single bit in the MPLS header to indicate ECN, and simple signaling 36 at the time of setting up the LSP (Label Switched Path) for 37 indication of ECN capability. This allows for incorporation of ECN in 38 MPLS in a coordinated manner with IP and also in a backwards 39 compatible fashion. 41 1. Introduction. 43 ECN (Explicit Congestion Notification) [ECN] has been proposed as an 44 addition to IP to provide an indication of congestion. With the 45 addition of active queue management (e.g., RED [RFC2309]) to the 46 Internet infrastructure, where routers detect congestion before the 47 queue overflows, routers are no longer limited to packet drops as an 48 indication of congestion. Routers could instead set a Congestion 49 Experienced (CE) bit in the IP header of packets from ECN-capable 50 transport protocols. 52 Active queue management mechanisms in the router may use one of 53 several methods for indicating congestion to end-nodes. One is to use 54 packet drops, as is currently done. However, active queue management 55 allows the router to separate policies of queueing or dropping 56 packets from the policies for indicating congestion. Thus, active 57 queue management allows routers to use the Congestion Experienced 58 (CE) bit in a packet header as an indication of congestion, instead 59 of relying solely on packet drops. 61 Active queue management not only avoids packet losses for congestion 62 indication, but also attempts to control the average queue sizes at 63 routers by using ECN or packet drops to provide an indication of the 64 onset of congestion. With the cooperation of transport protocols, the 65 indication of incipient congestion may be used to minimize 66 significant queue build-up and thus reduce queueing delays, 67 variability in queueing delay and additional packet losses. With 68 ECN-capable routers and transport protocols, packet drops are not 69 required for these indications of congestion. 71 Applications that are sensitive to the delay or loss of one or more 72 individual packets are expected to benefit from the use of ECN. 73 Interactive traffic such as telnet, web-browsing, and transfer of 74 audio and video data can be sensitive to packet losses (using an 75 unreliable data delivery transport such as UDP) or to the increased 76 latency of the packet caused by the need to retransmit the packet 77 after a loss (for reliable data delivery such as TCP). The use of ECN 78 by end-systems and participation of intermediate nodes in the network 79 in ECN would potentially help these applications. 81 1.1. Motivation for use of ECN with MPLS 83 Many of the features of MPLS, such as traffic engineering (to take 84 advantage of multiple paths and balance the load on them), explicit 85 routing and QoS routing are motivated by the desire to improve the 86 overall performance of an IP network. MPLS also aims to support the 87 QoS models that are available for IP, such as Integrated Services and 88 Differentiated Services. 90 Given the motivation to provide better performance and QoS 91 assurances, we believe it is desirable that we utilize techniques 92 that help manage queueing better, and minimize losses. Label 93 Switched Routers (LSRs) are already expected to incorporate active 94 queue management methods such as RED. As a result, the incremental 95 effort involved in the addition of ECN is likely to be small in many 96 cases. We believe the benefits from ECN of better overall performance 97 for a wide range of applications because of reduced packet loss 98 (especially those using non-TCP transports) and reduced queueing 99 delay is sufficiently significant. Furthermore, there seems to be no 100 reasons for LSRs to lack this capability as it becomes available in 101 other (non-label switched) IP routers. 103 2. Overview of ECN 105 This section briefly outlines the addition of ECN to the IP protocol 106 as specified in RFC 2481. RFC 2481 specifies two bits in the ECN 107 field in the IP header, the ECN-Capable Transport (ECT) bit and the 108 Congestion Experienced (CE) bit. The ECT bit is set by the data 109 sender to indicate that the end-points of the transport protocol are 110 ECN-capable. The CE bit is set by the router to indicate congestion 111 to the end nodes. Routers that have a packet arriving at a full 112 queue would drop the packet, just as they do now. 114 RFC 2481 also specifies the use of ECN in the TCP transport protocol. 115 For an ECN-capable TCP connection, when the TCP receiver receives a 116 data packet with the CE bit set, the receiver conveys that 117 information to the TCP sender using a bit in the TCP header. TCP 118 senders react to the congestion indication by decreasing their 119 congestion window. Thus, the early indication of congestion allows 120 the sender TCP to reduce the load placed on the network, without the 121 need to drop a packet. Because the use of ECN at the transport level 122 is not affected by the MPLS header, this aspect of ECN is not 123 discussed further in this document. 125 2.1. Opportunities to take Advantage of ECN 127 In the past, it has often been the desire of datalink layers to 128 provide a congestion indication to the end-systems, so that end- 129 system transport protocols may react by reducing the load. However, 130 even though Frame-Relay and ATM have had an indicator for congestion 131 indication, the match with the ECN indication has not been ideal. In 132 these cases, marking the congestion indication was left to 133 implementation or was based on instantaneous queue occupancy. This 134 was the case with both Forward Explicit Congestion Notification 135 (FECN) in Frame-Relay networks and Explicit Forward Congestion 136 Indication (EFCI) in ATM. 138 With MPLS LSRs, it is expected that they will implement the 139 algorithms needed to determine an average queue size, as specified 140 with RED and other active queue management algorithms. Thus, a 141 congestion indication in MPLS based on the average queue size will be 142 better matched to the ECN semantics. We thus propose that the same 143 policies for indicating congestion be used in LSRs. The egress LSR of 144 a label switched path (LSP) would then "fold" the congestion 145 indication seen in the MPLS header into the forwarded IP packet. 146 Thus, each of the LSRs also now has a means of indicating congestion 147 to the end-systems. 149 3. A One-Bit ECN Field in the MPLS Header 151 As described in Section 2, RFC 2481 uses a two-bit ECN field for IP. 152 The original ECN proposal in [F94] discussed both a one-bit and a 153 two-bit implementation for ECN in the IP header. This document 154 proposes a one-bit ECN field for the MPLS header, because of our 155 desire to conserve space in the header, and the ability to use 156 signaling at the time of setting up the label switched path (LSP) to 157 overcome the need for the second bit. We propose that this bit should 158 be one of the three experimental bits defined in [R99]. We note that 159 by using only one of these bits, we leave two available for diff-serv 160 drop preference, as described in [LeF99]. 162 The ECN field has to encode three separate states: not ECT; ECT but 163 not CE; and ECT with CE. The two-bit implementation specified in RFC 164 2481 implements these three separate states using two bits in the IP 165 ECN field, the ECT bit and the CE bit. Section 9.2 of [F94] also 166 discusses a one-bit approach where the two functions of ECT and CE 167 are overloaded in a single bit. For this bit, one value indicates 168 "ECT but not CE", and the other value indicates "either not ECT, or 169 ECT with CE". 171 4. Role of Ingress and Egress MPLS LSRs 173 When the LSP is set up, the ingress and egress LSRs use signaling to 174 indicate whether or not to participate in ECN. We envisage this as 175 an extension to any of the existing MPLS label distribution 176 mechanisms such as LDP or RSVP. Such signaling allows ingress and 177 egress LSRs on an LSP to determine if all LSRs along the LSP are 178 capable of supporting ECN. Details of these signaling mechanisms 179 constitute work in progress and will be described in a later version 180 of this draft. 182 The ingress LSR observes the IP ECN field in a packet to set the MPLS 183 ECN field in accordance with the following table (Table 1): 185 ECN-Capable 186 IP ECN Field MPLS LSP? MPLS ECN Field 187 ------------ --------- -------------- 188 (1) Not ECT YES Not ECT, or ECT+CE 189 (2) ECT, not CE YES ECT, not CE 190 (3) ECT, CE YES ECT, not CE 191 (4) --- NO Not ECT, or ECT+CE 193 Table 1.: Translation from the IP ECN Field to the MPLS ECN Field 194 at Ingress. 196 An ingress LSR using ECN would set the MPLS ECN field to "ECT but not 197 CE" when the IP ECN field indicates "ECT", whether or not the CE bit 198 was set in the IP ECN field, and would have to *always* set the MPLS 199 ECN field to "either not ECT, or ECT with CE" otherwise. Similarly, 200 an ingress LSR not using ECN would *always* set the MPLS ECN field to 201 "either not ECT, or ECT with CE", whether or not the IP ECN field was 202 set to "ECT". 204 When the packet reaches the end of the LSP, the egress LSR now has to 205 "fold" the MPLS ECN field back into the IP ECN header of the packet. 206 The egress LSR knows whether the LSP is ECN-Capable or not. On the 207 received packet, the MPLS header indicates whether congestion was 208 experienced or not. The main row to examine in the following table 209 (Table 2) is Row 5. It shows that the received packet has the ECN 210 field in the MPLS header indicating congestion or that the packet 211 flowed over a non-ECN capable LSP. However, because of the signaling 212 at the time the LSP was set up, we know that the MPLS LSP was ECN 213 capable. In addition, the IP ECN field was set to "ECT". Thus, the 214 MPLS ECN field is interpreted as indicating ECT+CE (congestion was 215 experienced in the MPLS LSP). The IP ECN field of the packet received 216 indicates that the transport is ECN capable (ECT) and that it had not 217 experienced congestion earlier (not CE) before entering the LSP. The 218 IP ECN field of the forwarded packet therefore has to be set by the 219 egress LSR to indicate congestion (CE). Thus, congestion experienced 220 in the MPLS LSP is now successfully carried in the IP ECN field 221 onwards to the end-system. 223 Row 1 of Table 2 shows that the MPLS ECN field indicates no 224 congestion was experienced in the LSP. Thus, the IP ECN field of the 225 packet is left unchanged. Similarly, when the original IP ECN field 226 indicates the transport is not ECN capable or already indicates 227 congestion was experienced, then the the IP ECN field of the packet 228 is left unchanged. 230 MPLS Old IP ECN-Capable New IP 231 ECN Field ECN Field MPLS LSP? ECN Field 232 ------------ --------- ----- --------- 233 (1) ECT, not CE --- --- Unchanged. 234 (2) not ECT, or ECT+CE Not ECT --- Unchanged. 235 (3) not ECT, or ECT+CE ECT, CE --- Unchanged. 236 (4) not ECT, or ECT+CE ECT, not CE NO Not possible. 237 (5) not ECT, or ECT+CE ECT, not CE YES ECT, CE 239 Table 2.: Translation from MPLS ECN Field back to IP ECN Field at 240 Egress 242 The reason that the use of a one-bit ECN field in the MPLS header 243 does not introduce ambiguity is that it is accompanied by the 244 original two-bit IP ECN field, along with a prior agreement about 245 whether the MPLS LSP was or was not ECN-Capable. 247 5. Role of Switches in marking ECN 249 MPLS ECN Field ECN-Capable MPLS 250 MPLS LSP? Congestion Action 251 -------------- ------------- --------------- 252 (1) Not ECT, or ECT+CE No Packet dropped. 253 (2) Not ECT, or ECT+CE Yes Packet dropped. 254 (3) ECT, not CE Yes MPLS ECN Field changed to 255 "not ECT, or ECT+CE" 256 (4) ECT, not CE No Not Possible 258 Table 3.: Effect of MPLS ECN Field on Congestion Action at Switch. 260 The congestion action taken at an LSR is based on the knowledge at 261 the LSR of whether or not the LSP is ECN capable. This is known 262 through signaling. If the LSP is not ECN capable, the packet is 263 dropped as per the existing rules followed at the LSR (i.e., based on 264 RED). If the LSP is ECN capable, and the MPLS ECN field shows that 265 the packet is ECN-capable but has not experienced congestion upstream 266 on the LSP, then the MPLS ECN field is changed to indicate congestion 267 (i.e., the encoding of "Not ECT, or ECT+CE"). If the packet has 268 indeed experienced congestion upstream, the packet is dropped. This 269 is an inescapable consequence of the single-bit MPLS ECN field 270 combined with internal LSRs not looking at the IP ECN field. 272 One functional limitation of the one-bit ECN implementation for MPLS 273 is that once an LSR "sets" the CE state in an ECT MPLS packet, 274 subsequent LSRs along the MPLS path cannot determine whether the 275 packet is or is not ECN-Capable (without using the IP ECN field). 276 Although LSRs may be able to look at the IP header (potentially with 277 some performance impact), we do not require it. Thus, subsequent 278 LSRs would have to drop that packet in order to indicate congestion 279 to the end nodes, rather than using ECN. 281 6. Role of Signaling to communicate ECN capability 283 One requirement for the one-bit ECN implementation for MPLS is that 284 the egress LSR needs information from the ingress LSR in order to 285 determine how to interpret the MPLS ECN Field. In particular, for a 286 packet at the egress of the MPLS LSP whose IP ECN field indicates 287 "ECT, not CE" and whose MPLS ECN field indicates "not ECT, or 288 ECT+CE", the egress LSR of the MPLS LSP has to be able to determine 289 whether to set the CE bit in the forwarded packet's IP ECN field upon 290 decapsulation. To do this, the egress LSR has to know whether or not 291 the ingress LSR originally set the MPLS ECN field to "ECT but not 292 CE". This can be determined using information in the IP ECN header, 293 assuming that the ingress LSR has previously informed the egress LSR 294 whether it is or is not using ECN. Thus, an ingress and egress LSR 295 would have to negotiate whether or not they are using ECN-Capability 296 for the MPLS tunnel. Note only the ingress and egress LSRs have to 297 examine the IP ECN header of the packet. 299 Based on the negotiation at the time the LSP is set up, the ingress 300 LSR knows what the MPLS ECN field should be set to on incoming 301 packets, especially for downstream allocation of the MPLS LSP: if the 302 egress LSR is ECN capable and the LSRs upstream are also ECN capable, 303 then the ingress LSR knows to initially set the MPLS ECN field to 304 "ECT but not CE" when the IP ECN field indicated "ECT". If the LSRs 305 in the MPLS LSP are not ECN capable, then the ingress LSR always sets 306 the MPLS ECN bit to "not ECT or ECT+CE". The egress LSR, knowing that 307 the LSP is ECN capable through signaling, folds the MPLS ECN field 308 into the outgoing IP ECN field according to Table 2. 310 7. Summary 312 We have proposed that MPLS LSRs exploit the capability provided in 313 Explicit Congestion Notification (ECN) to provide an early indication 314 of congestion without depending solely on packet dropping as a means 315 of congestion indication. Given that MPLS LSRs are likely to use some 316 form of active queue management, the use of ECN potentially improves 317 the service obtained in an MPLS LSP with respect to packet loss and 318 end-end delay. The proposal requires the use of a single bit in the 319 MPLS header for indicating congestion, and signaling while setting up 320 the LSP. The signaling provides the indication to the ingress and 321 egress LSRs the action they need to take with respect to ECN: the 322 initialization of the MPLS ECN field at the ingress and the folding 323 of the MPLS ECN indication into the forwarded IP packet's ECN field 324 at the egress. 326 8. References 328 [ECN] The ECN Web Page, URL "http://www.aciri.org/floyd/ecn.html". 330 [F94] Floyd, S., "TCP and Explicit Congestion Notification", ACM 331 Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23. 332 URL "ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z". 334 [FBR99] Floyd, Black, and Ramakrishnan, IPsec Interactions with ECN, 335 internet-draft draft-ipsec-ecn-00.txt, April 1999. URL 336 "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ipsec- 337 ecn-00.txt". 339 [LeF99] Le Faucheur, F., et al., "MPLS Support of Differentiated 340 Services over PPP links", internet draft, draft-lefaucheur-mpls-diff- 341 ppp-00.txt, June 1999. URL 342 "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-lefaucheur- 343 mpls-diff-ppp-00.txt" 345 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 346 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., 347 Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. 348 Zhang, "Recommendations on Queue Management and Congestion Avoidance 349 in the Internet", RFC 2309, April 1998. 351 [RFC2481] K. K. Ramakrishnan and Sally Floyd, "A Proposal to add 352 Explicit Congestion Notification (ECN) to IP", RFC 2481, January 353 1999. URL "ftp://ftp.isi.edu/in-notes/rfc2481.txt". 355 [R99] Rosen, E., et al., "MPLS Label Stack Encoding", internet draft, 356 draft-ietf-mpls-label-encaps-04.txt, April 1999. URL 357 "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-mpls- 358 label-encaps-04.txt". 360 9. Security Considerations 362 Security considerations are equivalent to those for normal IP ECN and 363 ECN with IPsec, which are discussed extensively in [FBR99]. 365 AUTHORS' ADDRESSES 367 Sally Floyd 368 AT&T Center for Internet Research at ICSI (ACIRI) 369 Phone: +1 (510) 642-4274 x189 370 Email: floyd@aciri.org 371 URL: http://www-nrg.ee.lbl.gov/floyd/ 372 K. K. Ramakrishnan 373 AT&T Labs. Research 374 Phone: +1 (973) 360-8766 375 Email: kkrama@research.att.com 376 URL: http://www.research.att.com/info/kkrama 378 Bruce Davie 379 Cisco Systems, Inc. 380 250 Apollo Drive 381 Chelmsford, MA, 01824 382 E-mail: bsd@cisco.com 384 This draft was created in June 1999. 385 It expires December 1999.