tewg/mpls                                                     M.Shayman
Internet Draft                                                R. Jaeger
Document: draft-shayman-mpls-ecn-00.txt                      University
Category: Informational                                     of Maryland

                                                      November 15, 2000
                                                      Expires: May 2001


          Using ECN to Signal Congestion Within an MPLS Domain


Status of this Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.


1. Abstract

   We propose the addition of Explicit Congestion Notification (ECN)
   together with congestion signaling back to the ingress in order to
   provide notification to the ingress label switching router (LSR) if
   congestion is experienced along a label switched path (LSP). This
   information could be used by the ingress LSR to mitigate congestion
   by employing dynamic traffic engineering techniques such as shifting
   flows to alternate paths.

   While extending ECN to enable its use for congestion control by the
   ingress LSR, the proposal retains (with modification) the capability
   to signal ECN end-to-end as proposed in an earlier IETF draft
   authored by others. The current proposal incorporates ECN into MPLS
   in a manner that is coordinated with the use of ECN in IP, is
   backwards compatible, and provides MPLS with a means of alleviating
   congestion of flows traversing MPLS tunnels.


2. Conventions used in this document

Shayman-Jaeger     Informational - Expires May 2001                  1

Using ECN to Signal Congestion within an MPLS Domain         Nov. 2000




   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119.


3. Introduction

   The ECN (Explicit Congestion Notification) concept proposed an
   alternative to packet drops to indicate congestion to endpoints of a
   flow.  Routers capable of active queue management, e.g., RED
   [RFC2309, FJ93], can detect congestion before the queues overflow.
   In response to congestion, routers typically drop packets to
   indicate congestion to endpoints. Alternatively, they can mark the
   packets selected by RED by setting a Congestion Experienced (CE) bit
   in the IP header of packets from ECN-capable transport connections.
   By separating the queuing policies from those for congestion
   indications, endpoints may be able to react to congestion indicated
   in the packet header rather than suffering packet loss for that
   indication.

   If an end-to-end path traverses an MPLS tunnel, the IP header, and
   hence the CE bit, is not accessible to the LSRs for marking. To
   permit ECN to be used on such paths, it was proposed in draft-ietf-
   mpls-ecn-00 [RFD99], and summarized in [DR2000], to use one
   experimental bit in the MPLS shim header for marking. The proposal in
   that draft considered end-to-end congestion notification; it did not
   address the distinct issue of how congestion encountered along an LSP
   can be signaled back to the ingress LSR. If such information were
   made available, it could permit the ingress to take actions to
   alleviate the congestion. Such actions might include shifting flows
   to alternate LSPs or setting up new LSPs. Furthermore, if the ingress
   determines that some dropping is unavoidable, the dropping could be
   done at the ingress, thereby conserving network resources.

   The purpose of the present draft is to propose a mechanism whereby
   ECN can be used to provide congestion notifications to ingress LSRs
   when MPLS tunnels become congested. At the same time, the ability to
   provide end-to-end congestion notifications is retained. These two
   goals are accomplished by (1) modifying the proposal made in draft-
   ietf-mpls-ecn-00 for the use of a single experimental bit in the shim
   header; (2) proposing a new RSVP TUNNEL CONGESTION message which is
   sent to the ingress LSR and ignored by transit LSRs.

   The use of ECN to signal congestion to the ingress is complementary
   to the use of flooding of link loading information via the IGP as
   proposed in OSPF-OMP [V99a] and MPLS-OMP [V99b]. IGP flooding
   primarily supports load balancing on a time-scale of minutes or
   longer; the time interval between flooding is envisioned to be at
   least 15 seconds. Such an approach can be viewed as proactive in
   that it seeks to reduce the likelihood of congestion occurring.
   However, even with load balancing, events such as link failures in

Shayman-Jaeger     Informational - Expires May 2001                  2

Using ECN to Signal Congestion within an MPLS Domain         Nov. 2000


   adjacent domains may cause abrupt shifts in traffic patterns that
   lead to the sudden onset of congestion. Use of ECN can potentially
   facilitate rapid reaction to such events.

4. ECN Overview

   RFC 2481 specifies the addition of ECN to the IP protocol. Two bits
   in the IP header form the ECN field. The first bit is referred to as
   the ECN-capable Transport (ECT) bit. It is set by the source and
   indicates whether the transport connection can support ECN. The
   second bit is the Congestion Experienced (CE) bit. This bit is set
   by a router as a marking to indicate that congestion has been
   encountered. When the destination host receives a packet with the CE
   bit set, it echoes this information back to the source by setting a
   bit in the TCP header. The sender than reacts by decreasing its
   congestion window.



5. MPLS Support for End-to-end ECN

   The draft-ietf-mpls-ecn-00 [RFD99] offered a proposal for making end-
   to-end ECN possible when the route crosses an MPLS domain. The
   proposal is briefly summarized as follows:

   It is assumed that the protocol used for label distribution (LDP or
   RSVP) is extended to permit the ingress and egress to signal to all
   LSRs on the LSP whether or not the LSP is itself ECN-capable. Thus,
   the ECN-capability of the LSP does not have to be recorded in the
   shim header. Denote an ECN-capable LSP by ECL; in contrast, ECT
   denotes an ECN-capable end-to-end transport connection. Let CELSP
   denote that congestion has been experienced at an LSR along the LSP;
   in contrast, CE refers to the congestion experienced bit in the IP
   header which indicates whether congestion has been experienced on
   the end-to-end path.

   To make end-to-end ECN possible when packets traverse an MPLS
   tunnel, one of the three experimental bits in the shim header is
   used. This bit is overloaded in the sense that one value of the bit
   indicates [ECT && not CELSP] while the other value indicates [not
   ECT || CELSP]. If a packet marked as [not ECT || CELSP] is picked
   out for ECN marking at a congested LSR, it will be dropped. This is
   done because such a packet may belong to a flow for which end-to-end
   ECN is not possible. A consequence of this is that if a packet has
   been marked as having experienced congestion at an LSR and then is
   picked out for ECN marking at a second congested LSR, the packet
   will be dropped by the second LSR since it cannot be determined
   whether the packet has previously experienced congestion or if ECN
   is not possible end-to-end.

   The egress LSR folds the indication of congestion experienced along
   the LSP into the IP header of the packet: If the shim header
   indicates [not ECT or CELSP] and the IP header indicates [ECT and

Shayman-Jaeger     Informational - Expires May 2001                  3

Using ECN to Signal Congestion within an MPLS Domain         Nov. 2000


   not CE], this means that in fact ECN is possible end-to-end and
   congestion was indeed experienced along the LSP. Thus, the CE bit in
   the IP header is set.


6.  MPLS ECN with Ingress LSR Notification

   The use of the experimental bit as specified in draft-ietf-mpls-ecn-
   00 does not facilitate congestion notification to the ingress LSR
   when packets encounter congestion in an LSP. This is illustrated by
   the following two cases:

   (1) Suppose the LSP is ECN-capable but ECN is not possible end-to-
   endùi.e., [not ECT && ECL].  In this case if a packet experiences
   congestion at an LSR and is selected by the active queue management
   algorithm, it is dropped.

   (2) Suppose the LSP is ECN-capable and ECN is possible end-to-endù
   i.e., [ECT && ECL]. In this case if a packet experiences congestion
   at two LSR's and is selected (e.g., by RED) at both, it will be
   dropped.

   In each of these cases, it is not possible for the ingress LSR to
   obtain notification that the packet has experienced congestion.

   We propose modifying the way the single experimental bit is used so
   that ECN notifications can be echoed to the ingress LSR if
   congestion is experienced along an LSP. Instead of overloading the
   experimental bit to take into account end-to-end ECN-capability, we
   use it solely to indicate whether or not congestion has been
   experienced along the LSP. Thus, the value of the experimental bit
   indicates [CELSP] or [not CELSP]. (In particular, a packet that
   experiences congestion and is selected by RED at multiple LSRs is
   not dropped.)

   At the penultimate LSR where the shim header is popped, both the
   experimental bit and the two-bit ECN field in the IP header are
   examined. If the experimental bit indicates that congestion was
   experienced along the LSP, the LSR can then notify the ingress LSR.
   This notification can occur after some configurable number of ECN
   packets arrive at the penultimate LSR. The mechanism for
   notification is a new RSVP TUNNEL CONGESTION message that is sent to
   the ingress LSR and ignored by transit LSRs.

   This proposal retains the capability to do ECN end-to-end. When a
   packet arrives at the penultimate LSR with the experimental bit
   indicating that congestion was experienced along the LSPùi.e., the
   shim header indicates [CELSP]--there are three cases to consider:

   (1) If the ECN field in the IP header indicates that the transport
   connection between the source and destination is not ECN-capable,
   then the packet is dropped.


Shayman-Jaeger     Informational - Expires May 2001                  4

Using ECN to Signal Congestion within an MPLS Domain         Nov. 2000


   (2) If the transport connection is ECN-capable and the packet has
   not yet been marked as having experienced congestion (prior to
   entering the MPLS domain), then it is remarked as having experienced
   congestionùi.e., the CE bit in the IP header is set.

   (3) If the source and destination are ECN-capable and the packet has
   already been marked as having experienced congestion (prior to
   entering the MPLS domain), then it is forwarded to the egress LSR
   without change.

   Note that in case (1) the packet is dropped at the penultimate node,
   while in draft-ietf-mpls-ecn-00, such a packet would be dropped at
   the first LSR at which it experienced congestion (and was selected
   for marking by RED).


7. Conclusions / Further Work

   In this draft we have proposed modifying the way a single
   experimental bit is used so that ECN notifications can be echoed,
   via a new RSVP TUNNEL_CONGESTION message, to the ingress LSR if
   congestion is experienced along an LSP. This information could be
   used by the ingress LSR to shift flows to alternate LSPs or to set
   up new LSPs.  If the ingress is not able to mitigate the congestion
   in this way, it can resort to dropping packets. In this case, the
   notification still has the beneficial effect of enabling the drops
   to be pushed to ingress, thereby conserving resources within the
   domain. While enabling ECN to be used to provide notification to the
   ingress LSRs, the proposal retains the capability to signal ECN end-
   to-end (provided the transport connection between the source and
   destination is ECN-capable).

   The authors of this draft believe that portions of this material
   should be incorporated into working group drafts within the scope of
   the MPLS and possibly other working groups.


8. References

   [DR2000] B. Davie and Y. Rekhter, MPLS Technology and Applications,
   Morgan Kaufmann, San Francisco, 2000.

   [ECN] The ECN Web Page, URL http://www.aciri.org/floyd/ecn.html".

   [F94] S. Floyd, "TCP and Explicit Congestion Notification", ACM
   Computer Communication Review, Vol. 24, October 1994, pp. 10-23. URL
   "ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z".

   [FBR99] S. Floyd, D. Black and K. K. Ramakrishnan, IPsec
   Interactions with ECN, Internet Draft, draft-ipsec-ecn-00.txt, work
   in progress, April 1999.  URL
   "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ipsec-ecn-
   00.txt".

Shayman-Jaeger     Informational - Expires May 2001                  5

Using ECN to Signal Congestion within an MPLS Domain         Nov. 2000



   [FJ93] S. Floyd and V. Jacobson, ôRandom Early Detection Gateways
   for Congestion Avoidance,ö IEEE/ACM Transactions on Networking, Vol.
   1, August 1993, pp. 397-413. URL http://www-nrg.ee.lbl/gov/nrg-
   papers.html

   [LeF99] F. Le Faucheur et al., "MPLS Support of Differentiated
   Services over PPP Links", Internet Draft, draft-lefaucheur-mpls-
   diff-ppp-00.txt, work in progress, June 1999. URL
   "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-lefaucheur-
   mpls-diff-ppp-00.txt"

   [RFC2309] B. Braden et al., "Recommendations on Queue Management and
   Congestion Avoidance in the Internet," RFC 2309, April 1998.

   [RFC2481] K. K. Ramakrishnan and S. Floyd, "A Proposal to Add
   Explicit Congestion Notification (ECN) to IP," RFC 2481, January
   1999.  URL "ftp://ftp.isi.edu/in-notes/rfc2481.txt".

   [RFD99] K. K. Ramakrishnan, S. Floyd and B. Davie, ôA Proposal to
   Incorporate ECN in MPLS,ö Internet Draft, draft-ietf-mpls-ecn-
   00.txt, work in progress, June 1999. URL
   http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-mpls-ecn-
   00.txt.

   [R99] E. Rosen, et al., "MPLS Label Stack Encoding", Internet Draft,
   draft-ietf-mpls-label-encaps-04.txt, work in progress, April 1999.
   URL "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-
   mpls-label-encaps-04.txt".

   [V99a] C. Villamizar, ôOSPF Optimized Multipath,ö Internet Draft,
   draft-ietf-ospf-omp-02, work in progress, February 1999, URL
   http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-ospf-omp-
   02.txt.

   [V99b] C. Villamizar, ôMPLS Optimized Multipath,ö Internet Draft,
   draft-villamizar-mpls-omp-01, work in progress, February 1999, URL
   http://www.fictitious.org/internet-drafts/mpls-omp/mpls-omp.html.


9. Security Considerations
   Security considerations with respect to MPLS ECN are equivalent to
   those for normal IP ECN and ECN with IPsec, which are discussed in
   [FBR99].

10. Author's Addresses

   Mark Shayman
   Department of Electrical and Computer Engineering
   University of Maryland
   College Park, MD 20742
   Phone +1 (301) 405-3667
   Email: shayman@glue.umd.edu

Shayman-Jaeger     Informational - Expires May 2001                  6

Using ECN to Signal Congestion within an MPLS Domain         Nov. 2000



   Rob Jaeger
   Department of Computer Science
   University of Maryland
   College Park, MD 20742
   Phone +1 (301) 237-7623
   Email: rfj@cs.umd.edu


Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved. This
document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist
in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.






























Shayman-Jaeger     Informational - Expires May 2001                  7