idnits 2.17.1 draft-shayman-mpls-ecn-00.txt: ** The Abstract section seems to be numbered -(276): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** 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? == There are 10 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 1) being 59 lines 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (November 15, 2000) is 8564 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CELSP' is mentioned on line 195, but not defined == Unused Reference: 'ECN' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'F94' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'LeF99' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC2481' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'R99' is defined on line 299, but no explicit reference was found in the text -- No information found for draft-ipsec-ecn - is the name correct? ** 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: 7 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tewg/mpls M.Shayman 3 Internet Draft R. Jaeger 4 Document: draft-shayman-mpls-ecn-00.txt University 5 Category: Informational of Maryland 7 November 15, 2000 8 Expires: May 2001 10 Using ECN to Signal Congestion Within an MPLS Domain 12 Status of this Memo 14 This document is an Internet Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet- Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 1. Abstract 35 We propose the addition of Explicit Congestion Notification (ECN) 36 together with congestion signaling back to the ingress in order to 37 provide notification to the ingress label switching router (LSR) if 38 congestion is experienced along a label switched path (LSP). This 39 information could be used by the ingress LSR to mitigate congestion 40 by employing dynamic traffic engineering techniques such as shifting 41 flows to alternate paths. 43 While extending ECN to enable its use for congestion control by the 44 ingress LSR, the proposal retains (with modification) the capability 45 to signal ECN end-to-end as proposed in an earlier IETF draft 46 authored by others. The current proposal incorporates ECN into MPLS 47 in a manner that is coordinated with the use of ECN in IP, is 48 backwards compatible, and provides MPLS with a means of alleviating 49 congestion of flows traversing MPLS tunnels. 51 2. Conventions used in this document 53 Shayman-Jaeger Informational - Expires May 2001 1 54 Using ECN to Signal Congestion within an MPLS Domain Nov. 2000 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 58 this document are to be interpreted as described in RFC-2119. 60 3. Introduction 62 The ECN (Explicit Congestion Notification) concept proposed an 63 alternative to packet drops to indicate congestion to endpoints of a 64 flow. Routers capable of active queue management, e.g., RED 65 [RFC2309, FJ93], can detect congestion before the queues overflow. 66 In response to congestion, routers typically drop packets to 67 indicate congestion to endpoints. Alternatively, they can mark the 68 packets selected by RED by setting a Congestion Experienced (CE) bit 69 in the IP header of packets from ECN-capable transport connections. 70 By separating the queuing policies from those for congestion 71 indications, endpoints may be able to react to congestion indicated 72 in the packet header rather than suffering packet loss for that 73 indication. 75 If an end-to-end path traverses an MPLS tunnel, the IP header, and 76 hence the CE bit, is not accessible to the LSRs for marking. To 77 permit ECN to be used on such paths, it was proposed in draft-ietf- 78 mpls-ecn-00 [RFD99], and summarized in [DR2000], to use one 79 experimental bit in the MPLS shim header for marking. The proposal in 80 that draft considered end-to-end congestion notification; it did not 81 address the distinct issue of how congestion encountered along an LSP 82 can be signaled back to the ingress LSR. If such information were 83 made available, it could permit the ingress to take actions to 84 alleviate the congestion. Such actions might include shifting flows 85 to alternate LSPs or setting up new LSPs. Furthermore, if the ingress 86 determines that some dropping is unavoidable, the dropping could be 87 done at the ingress, thereby conserving network resources. 89 The purpose of the present draft is to propose a mechanism whereby 90 ECN can be used to provide congestion notifications to ingress LSRs 91 when MPLS tunnels become congested. At the same time, the ability to 92 provide end-to-end congestion notifications is retained. These two 93 goals are accomplished by (1) modifying the proposal made in draft- 94 ietf-mpls-ecn-00 for the use of a single experimental bit in the shim 95 header; (2) proposing a new RSVP TUNNEL CONGESTION message which is 96 sent to the ingress LSR and ignored by transit LSRs. 98 The use of ECN to signal congestion to the ingress is complementary 99 to the use of flooding of link loading information via the IGP as 100 proposed in OSPF-OMP [V99a] and MPLS-OMP [V99b]. IGP flooding 101 primarily supports load balancing on a time-scale of minutes or 102 longer; the time interval between flooding is envisioned to be at 103 least 15 seconds. Such an approach can be viewed as proactive in 104 that it seeks to reduce the likelihood of congestion occurring. 105 However, even with load balancing, events such as link failures in 107 Shayman-Jaeger Informational - Expires May 2001 2 108 Using ECN to Signal Congestion within an MPLS Domain Nov. 2000 110 adjacent domains may cause abrupt shifts in traffic patterns that 111 lead to the sudden onset of congestion. Use of ECN can potentially 112 facilitate rapid reaction to such events. 114 4. ECN Overview 116 RFC 2481 specifies the addition of ECN to the IP protocol. Two bits 117 in the IP header form the ECN field. The first bit is referred to as 118 the ECN-capable Transport (ECT) bit. It is set by the source and 119 indicates whether the transport connection can support ECN. The 120 second bit is the Congestion Experienced (CE) bit. This bit is set 121 by a router as a marking to indicate that congestion has been 122 encountered. When the destination host receives a packet with the CE 123 bit set, it echoes this information back to the source by setting a 124 bit in the TCP header. The sender than reacts by decreasing its 125 congestion window. 127 5. MPLS Support for End-to-end ECN 129 The draft-ietf-mpls-ecn-00 [RFD99] offered a proposal for making end- 130 to-end ECN possible when the route crosses an MPLS domain. The 131 proposal is briefly summarized as follows: 133 It is assumed that the protocol used for label distribution (LDP or 134 RSVP) is extended to permit the ingress and egress to signal to all 135 LSRs on the LSP whether or not the LSP is itself ECN-capable. Thus, 136 the ECN-capability of the LSP does not have to be recorded in the 137 shim header. Denote an ECN-capable LSP by ECL; in contrast, ECT 138 denotes an ECN-capable end-to-end transport connection. Let CELSP 139 denote that congestion has been experienced at an LSR along the LSP; 140 in contrast, CE refers to the congestion experienced bit in the IP 141 header which indicates whether congestion has been experienced on 142 the end-to-end path. 144 To make end-to-end ECN possible when packets traverse an MPLS 145 tunnel, one of the three experimental bits in the shim header is 146 used. This bit is overloaded in the sense that one value of the bit 147 indicates [ECT && not CELSP] while the other value indicates [not 148 ECT || CELSP]. If a packet marked as [not ECT || CELSP] is picked 149 out for ECN marking at a congested LSR, it will be dropped. This is 150 done because such a packet may belong to a flow for which end-to-end 151 ECN is not possible. A consequence of this is that if a packet has 152 been marked as having experienced congestion at an LSR and then is 153 picked out for ECN marking at a second congested LSR, the packet 154 will be dropped by the second LSR since it cannot be determined 155 whether the packet has previously experienced congestion or if ECN 156 is not possible end-to-end. 158 The egress LSR folds the indication of congestion experienced along 159 the LSP into the IP header of the packet: If the shim header 160 indicates [not ECT or CELSP] and the IP header indicates [ECT and 162 Shayman-Jaeger Informational - Expires May 2001 3 163 Using ECN to Signal Congestion within an MPLS Domain Nov. 2000 165 not CE], this means that in fact ECN is possible end-to-end and 166 congestion was indeed experienced along the LSP. Thus, the CE bit in 167 the IP header is set. 169 6. MPLS ECN with Ingress LSR Notification 171 The use of the experimental bit as specified in draft-ietf-mpls-ecn- 172 00 does not facilitate congestion notification to the ingress LSR 173 when packets encounter congestion in an LSP. This is illustrated by 174 the following two cases: 176 (1) Suppose the LSP is ECN-capable but ECN is not possible end-to- 177 end�i.e., [not ECT && ECL]. In this case if a packet experiences 178 congestion at an LSR and is selected by the active queue management 179 algorithm, it is dropped. 181 (2) Suppose the LSP is ECN-capable and ECN is possible end-to-end� 182 i.e., [ECT && ECL]. In this case if a packet experiences congestion 183 at two LSR's and is selected (e.g., by RED) at both, it will be 184 dropped. 186 In each of these cases, it is not possible for the ingress LSR to 187 obtain notification that the packet has experienced congestion. 189 We propose modifying the way the single experimental bit is used so 190 that ECN notifications can be echoed to the ingress LSR if 191 congestion is experienced along an LSP. Instead of overloading the 192 experimental bit to take into account end-to-end ECN-capability, we 193 use it solely to indicate whether or not congestion has been 194 experienced along the LSP. Thus, the value of the experimental bit 195 indicates [CELSP] or [not CELSP]. (In particular, a packet that 196 experiences congestion and is selected by RED at multiple LSRs is 197 not dropped.) 199 At the penultimate LSR where the shim header is popped, both the 200 experimental bit and the two-bit ECN field in the IP header are 201 examined. If the experimental bit indicates that congestion was 202 experienced along the LSP, the LSR can then notify the ingress LSR. 203 This notification can occur after some configurable number of ECN 204 packets arrive at the penultimate LSR. The mechanism for 205 notification is a new RSVP TUNNEL CONGESTION message that is sent to 206 the ingress LSR and ignored by transit LSRs. 208 This proposal retains the capability to do ECN end-to-end. When a 209 packet arrives at the penultimate LSR with the experimental bit 210 indicating that congestion was experienced along the LSP�i.e., the 211 shim header indicates [CELSP]--there are three cases to consider: 213 (1) If the ECN field in the IP header indicates that the transport 214 connection between the source and destination is not ECN-capable, 215 then the packet is dropped. 217 Shayman-Jaeger Informational - Expires May 2001 4 218 Using ECN to Signal Congestion within an MPLS Domain Nov. 2000 220 (2) If the transport connection is ECN-capable and the packet has 221 not yet been marked as having experienced congestion (prior to 222 entering the MPLS domain), then it is remarked as having experienced 223 congestion�i.e., the CE bit in the IP header is set. 225 (3) If the source and destination are ECN-capable and the packet has 226 already been marked as having experienced congestion (prior to 227 entering the MPLS domain), then it is forwarded to the egress LSR 228 without change. 230 Note that in case (1) the packet is dropped at the penultimate node, 231 while in draft-ietf-mpls-ecn-00, such a packet would be dropped at 232 the first LSR at which it experienced congestion (and was selected 233 for marking by RED). 235 7. Conclusions / Further Work 237 In this draft we have proposed modifying the way a single 238 experimental bit is used so that ECN notifications can be echoed, 239 via a new RSVP TUNNEL_CONGESTION message, to the ingress LSR if 240 congestion is experienced along an LSP. This information could be 241 used by the ingress LSR to shift flows to alternate LSPs or to set 242 up new LSPs. If the ingress is not able to mitigate the congestion 243 in this way, it can resort to dropping packets. In this case, the 244 notification still has the beneficial effect of enabling the drops 245 to be pushed to ingress, thereby conserving resources within the 246 domain. While enabling ECN to be used to provide notification to the 247 ingress LSRs, the proposal retains the capability to signal ECN end- 248 to-end (provided the transport connection between the source and 249 destination is ECN-capable). 251 The authors of this draft believe that portions of this material 252 should be incorporated into working group drafts within the scope of 253 the MPLS and possibly other working groups. 255 8. References 257 [DR2000] B. Davie and Y. Rekhter, MPLS Technology and Applications, 258 Morgan Kaufmann, San Francisco, 2000. 260 [ECN] The ECN Web Page, URL http://www.aciri.org/floyd/ecn.html". 262 [F94] S. Floyd, "TCP and Explicit Congestion Notification", ACM 263 Computer Communication Review, Vol. 24, October 1994, pp. 10-23. URL 264 "ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z". 266 [FBR99] S. Floyd, D. Black and K. K. Ramakrishnan, IPsec 267 Interactions with ECN, Internet Draft, draft-ipsec-ecn-00.txt, work 268 in progress, April 1999. URL 269 "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ipsec-ecn- 270 00.txt". 272 Shayman-Jaeger Informational - Expires May 2001 5 273 Using ECN to Signal Congestion within an MPLS Domain Nov. 2000 275 [FJ93] S. Floyd and V. Jacobson, �Random Early Detection Gateways 276 for Congestion Avoidance,� IEEE/ACM Transactions on Networking, Vol. 277 1, August 1993, pp. 397-413. URL http://www-nrg.ee.lbl/gov/nrg- 278 papers.html 280 [LeF99] F. Le Faucheur et al., "MPLS Support of Differentiated 281 Services over PPP Links", Internet Draft, draft-lefaucheur-mpls- 282 diff-ppp-00.txt, work in progress, June 1999. URL 283 "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-lefaucheur- 284 mpls-diff-ppp-00.txt" 286 [RFC2309] B. Braden et al., "Recommendations on Queue Management and 287 Congestion Avoidance in the Internet," RFC 2309, April 1998. 289 [RFC2481] K. K. Ramakrishnan and S. Floyd, "A Proposal to Add 290 Explicit Congestion Notification (ECN) to IP," RFC 2481, January 291 1999. URL "ftp://ftp.isi.edu/in-notes/rfc2481.txt". 293 [RFD99] K. K. Ramakrishnan, S. Floyd and B. Davie, �A Proposal to 294 Incorporate ECN in MPLS,� Internet Draft, draft-ietf-mpls-ecn- 295 00.txt, work in progress, June 1999. URL 296 http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-mpls-ecn- 297 00.txt. 299 [R99] E. Rosen, et al., "MPLS Label Stack Encoding", Internet Draft, 300 draft-ietf-mpls-label-encaps-04.txt, work in progress, April 1999. 301 URL "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf- 302 mpls-label-encaps-04.txt". 304 [V99a] C. Villamizar, �OSPF Optimized Multipath,� Internet Draft, 305 draft-ietf-ospf-omp-02, work in progress, February 1999, URL 306 http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-ospf-omp- 307 02.txt. 309 [V99b] C. Villamizar, �MPLS Optimized Multipath,� Internet Draft, 310 draft-villamizar-mpls-omp-01, work in progress, February 1999, URL 311 http://www.fictitious.org/internet-drafts/mpls-omp/mpls-omp.html. 313 9. Security Considerations 314 Security considerations with respect to MPLS ECN are equivalent to 315 those for normal IP ECN and ECN with IPsec, which are discussed in 316 [FBR99]. 318 10. Author's Addresses 320 Mark Shayman 321 Department of Electrical and Computer Engineering 322 University of Maryland 323 College Park, MD 20742 324 Phone +1 (301) 405-3667 325 Email: shayman@glue.umd.edu 327 Shayman-Jaeger Informational - Expires May 2001 6 328 Using ECN to Signal Congestion within an MPLS Domain Nov. 2000 330 Rob Jaeger 331 Department of Computer Science 332 University of Maryland 333 College Park, MD 20742 334 Phone +1 (301) 237-7623 335 Email: rfj@cs.umd.edu 337 Full Copyright Statement 339 Copyright (C) The Internet Society (2000). All Rights Reserved. This 340 document and translations of it may be copied and furnished to others, 341 and derivative works that comment on or otherwise explain it or assist 342 in its implementation may be prepared, copied, published and 343 distributed, in whole or in part, without restriction of any kind, 344 provided that the above copyright notice and this paragraph are 345 included on all such copies and derivative works. However, this 346 document itself may not be modified in any way, such as by removing the 347 copyright notice or references to the Internet Society or other 348 Internet organizations, except as needed for the purpose of developing 349 Internet standards in which case the procedures for copyrights defined 350 in the Internet Standards process must be followed, or as required to 351 translate it into languages other than English. 353 Shayman-Jaeger Informational - Expires May 2001 7