[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet Engineering Task Force        K. K. Ramakrishnan, AT&T Research
INTERNET DRAFT                                        Sally Floyd, ACIRI
draft-ietf-mpls-ecn-00.txt                                 Bruce Davie, Cisco
                                                               June 1999
                                                       Expires: Dec 1999

                 A Proposal to Incorporate ECN in MPLS

                          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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   We propose the addition of ECN to MPLS switching.  ECN enables end-
   end congestion control without necessarily depending on packet loss
   as the sole indicator of congestion.  The proposal suggests having a
   single bit in the MPLS header to indicate ECN, and simple signaling
   at the time of setting up the LSP (Label Switched Path) for
   indication of ECN capability. This allows for incorporation of ECN in
   MPLS in a coordinated manner with IP and also in a backwards
   compatible fashion.

Ramakrishnan et. al                                             [Page 1]

draft-mpls-ecn    A Proposal to Incorporate ECN in MPLS        June 1999

1.  Introduction.

   ECN (Explicit Congestion Notification) [ECN] has been proposed as an
   addition to IP to provide an indication of congestion.  With the
   addition of active queue management (e.g., RED [RFC2309]) to the
   Internet infrastructure, where routers detect congestion before the
   queue overflows, routers are no longer limited to packet drops as an
   indication of congestion.  Routers could instead set a Congestion
   Experienced (CE) bit in the IP header of packets from ECN-capable
   transport protocols.

   Active queue management mechanisms in the router may use one of
   several methods for indicating congestion to end-nodes. One is to use
   packet drops, as is currently done.  However, active queue management
   allows the router to separate policies of queueing or dropping
   packets from the policies for indicating congestion.  Thus, active
   queue management allows routers to use the Congestion Experienced
   (CE) bit in a packet header as an indication of congestion, instead
   of relying solely on packet drops.

   Active queue management not only avoids packet losses for congestion
   indication, but also attempts to control the average queue sizes at
   routers by using ECN or packet drops to provide an indication of the
   onset of congestion. With the cooperation of transport protocols, the
   indication of incipient congestion may be used to minimize
   significant queue build-up and thus reduce queueing delays,
   variability in queueing delay and additional packet losses.  With
   ECN-capable routers and transport protocols, packet drops are not
   required for these indications of congestion.

   Applications that are sensitive to the delay or loss of one or more
   individual packets are expected to benefit from the use of ECN.
   Interactive traffic such as telnet, web-browsing, and transfer of
   audio and video data can be sensitive to packet losses (using an
   unreliable data delivery transport such as UDP) or to the increased
   latency of the packet caused by the need to retransmit the packet
   after a loss (for reliable data delivery such as TCP). The use of ECN
   by end-systems and participation of intermediate nodes in the network
   in ECN would potentially help these applications.

1.1.  Motivation for use of ECN with MPLS

   Many of the features of MPLS, such as traffic engineering (to take
   advantage of multiple paths and balance the load on them), explicit
   routing and QoS routing are motivated by the desire to improve the
   overall performance of an IP network. MPLS also aims to support the
   QoS models that are available for IP, such as Integrated Services and
   Differentiated Services.

Ramakrishnan et. al                                             [Page 2]

draft-mpls-ecn    A Proposal to Incorporate ECN in MPLS        June 1999

   Given the motivation to provide better performance and QoS
   assurances, we believe it is desirable that we utilize techniques
   that help manage queueing better, and minimize losses.  Label
   Switched Routers (LSRs) are already expected to incorporate active
   queue management methods such as RED. As a result, the incremental
   effort involved in the addition of ECN is likely to be small in many
   cases. We believe the benefits from ECN of better overall performance
   for a wide range of applications because of reduced packet loss
   (especially those using non-TCP transports) and reduced queueing
   delay is sufficiently significant. Furthermore, there seems to be no
   reasons for LSRs to lack this capability as it becomes available in
   other (non-label switched) IP routers.

2.  Overview of ECN

   This section briefly outlines the addition of ECN to the IP protocol
   as specified in RFC 2481.  RFC 2481 specifies two bits in the ECN
   field in the IP header, the ECN-Capable Transport (ECT) bit and the
   Congestion Experienced (CE) bit.  The ECT bit is set by the data
   sender to indicate that the end-points of the transport protocol are
   ECN-capable.  The CE bit is set by the router to indicate congestion
   to the end nodes.  Routers that have a packet arriving at a full
   queue would drop the packet, just as they do now.

   RFC 2481 also specifies the use of ECN in the TCP transport protocol.
   For an ECN-capable TCP connection, when the TCP receiver receives a
   data packet with the CE bit set, the receiver conveys that
   information to the TCP sender using a bit in the TCP header.  TCP
   senders react to the congestion indication by decreasing their
   congestion window. Thus, the early indication of congestion allows
   the sender TCP to reduce the load placed on the network, without the
   need to drop a packet.  Because the use of ECN at the transport level
   is not affected by the MPLS header, this aspect of ECN is not
   discussed further in this document.

2.1.  Opportunities to take Advantage of ECN

   In the past, it has often been the desire of datalink layers to
   provide a congestion indication to the end-systems, so that end-
   system transport protocols may react by reducing the load. However,
   even though Frame-Relay and ATM have had an indicator for congestion
   indication, the match with the ECN indication has not been ideal. In
   these cases, marking the congestion indication was left to
   implementation or was based on instantaneous queue occupancy. This
   was the case with both Forward Explicit Congestion Notification
   (FECN) in Frame-Relay networks and Explicit Forward Congestion
   Indication (EFCI) in ATM.

Ramakrishnan et. al                                             [Page 3]

draft-mpls-ecn    A Proposal to Incorporate ECN in MPLS        June 1999

   With MPLS LSRs, it is expected that they will implement the
   algorithms needed to determine an average queue size, as specified
   with RED and other active queue management algorithms. Thus, a
   congestion indication in MPLS based on the average queue size will be
   better matched to the ECN semantics. We thus propose that the same
   policies for indicating congestion be used in LSRs. The egress LSR of
   a label switched path (LSP) would then "fold" the congestion
   indication seen in the MPLS header into the forwarded IP packet.
   Thus, each of the LSRs also now has a means of indicating congestion
   to the end-systems.

3.  A One-Bit ECN Field in the MPLS Header

   As described in Section 2, RFC 2481 uses a two-bit ECN field for IP.
   The original ECN proposal in [F94] discussed both a one-bit and a
   two-bit implementation for ECN in the IP header.  This document
   proposes a one-bit ECN field for the MPLS header, because of our
   desire to conserve space in the header, and the ability to use
   signaling at the time of setting up the label switched path (LSP) to
   overcome the need for the second bit. We propose that this bit should
   be one of the three experimental bits defined in [R99]. We note that
   by using only one of these bits, we leave two available for diff-serv
   drop preference, as described in [LeF99].

   The ECN field has to encode three separate states:  not ECT; ECT but
   not CE; and ECT with CE.  The two-bit implementation specified in RFC
   2481 implements these three separate states using two bits in the IP
   ECN field, the ECT bit and the CE bit.  Section 9.2 of [F94] also
   discusses a one-bit approach where the two functions of ECT and CE
   are overloaded in a single bit.  For this bit, one value indicates
   "ECT but not CE", and the other value indicates "either not ECT, or
   ECT with CE".

4.  Role of Ingress and Egress MPLS LSRs

   When the LSP is set up, the ingress and egress LSRs use signaling to
   indicate whether or not to participate in ECN.  We envisage this as
   an extension to any of the existing MPLS label distribution
   mechanisms such as LDP or RSVP. Such signaling allows ingress and
   egress LSRs on an LSP to determine if all LSRs along the LSP are
   capable of supporting ECN.  Details of these signaling mechanisms
   constitute work in progress and will be described in a later version
   of this draft.

   The ingress LSR observes the IP ECN field in a packet to set the MPLS
   ECN field in accordance with the following table (Table 1):

Ramakrishnan et. al                                             [Page 4]

draft-mpls-ecn    A Proposal to Incorporate ECN in MPLS        June 1999

          IP ECN Field     MPLS LSP?           MPLS ECN Field
          ------------     ---------           --------------
      (1) Not ECT             YES             Not ECT, or ECT+CE
      (2) ECT, not CE         YES             ECT, not CE
      (3) ECT, CE             YES             ECT, not CE
      (4) ---                  NO             Not ECT, or ECT+CE

      Table 1.:  Translation from the IP ECN Field to the MPLS ECN Field
      at Ingress.

   An ingress LSR using ECN would set the MPLS ECN field to "ECT but not
   CE" when the IP ECN field indicates "ECT", whether or not the CE bit
   was set in the IP ECN field, and would have to *always* set the MPLS
   ECN field to "either not ECT, or ECT with CE" otherwise.  Similarly,
   an ingress LSR not using ECN would *always* set the MPLS ECN field to
   "either not ECT, or ECT with CE", whether or not the IP ECN field was
   set to "ECT".

   When the packet reaches the end of the LSP, the egress LSR now has to
   "fold" the MPLS ECN field back into the IP ECN header of the packet.
   The egress LSR knows whether the LSP is ECN-Capable or not. On the
   received packet, the MPLS header indicates whether congestion was
   experienced or not. The main row to examine in the following table
   (Table 2) is Row 5. It shows that the received packet has the ECN
   field in the MPLS header indicating congestion or that the packet
   flowed over a non-ECN capable LSP. However, because of the signaling
   at the time the LSP was set up, we know that the MPLS LSP was ECN
   capable.  In addition, the IP ECN field was set to "ECT".  Thus, the
   MPLS ECN field is interpreted as indicating ECT+CE (congestion was
   experienced in the MPLS LSP). The IP ECN field of the packet received
   indicates that the transport is ECN capable (ECT) and that it had not
   experienced congestion earlier (not CE) before entering the LSP.  The
   IP ECN field of the forwarded packet therefore has to be set by the
   egress LSR to indicate congestion (CE). Thus, congestion experienced
   in the MPLS LSP is now successfully carried in the IP ECN field
   onwards to the end-system.

   Row 1 of Table 2 shows that the MPLS ECN field indicates no
   congestion was experienced in the LSP. Thus, the IP ECN field of the
   packet is left unchanged. Similarly, when the original IP ECN field
   indicates the transport is not ECN capable or already indicates
   congestion was experienced, then the the IP ECN field of the packet
   is left unchanged.

Ramakrishnan et. al                                             [Page 5]

draft-mpls-ecn    A Proposal to Incorporate ECN in MPLS        June 1999

          MPLS                 Old IP      ECN-Capable    New IP
          ECN Field            ECN Field    MPLS LSP?     ECN Field
          ------------         ---------      -----       ---------
      (1) ECT, not CE          ---            ---         Unchanged.
      (2) not ECT, or ECT+CE   Not ECT        ---         Unchanged.
      (3) not ECT, or ECT+CE   ECT, CE        ---         Unchanged.
      (4) not ECT, or ECT+CE   ECT, not CE    NO          Not possible.
      (5) not ECT, or ECT+CE   ECT, not CE    YES         ECT, CE

      Table 2.: Translation from MPLS ECN Field back to IP ECN Field at

   The reason that the use of a one-bit ECN field in the MPLS header
   does not introduce ambiguity is that it is accompanied by the
   original two-bit IP ECN field, along with a prior agreement about
   whether the MPLS LSP was or was not ECN-Capable.

5.  Role of Switches in marking ECN

          MPLS ECN Field       ECN-Capable        MPLS
                                MPLS LSP?      Congestion Action
          --------------      -------------    ---------------
      (1) Not ECT, or ECT+CE       No          Packet dropped.
      (2) Not ECT, or ECT+CE      Yes          Packet dropped.
      (3) ECT, not CE             Yes          MPLS ECN Field changed to
                                                 "not ECT, or ECT+CE"
      (4) ECT, not CE              No          Not Possible

      Table 3.: Effect of MPLS ECN Field on Congestion Action at Switch.

   The congestion action taken at an LSR is based on the knowledge at
   the LSR of whether or not the LSP is ECN capable.  This is known
   through signaling. If the LSP is not ECN capable, the packet is
   dropped as per the existing rules followed at the LSR (i.e., based on
   RED). If the LSP is ECN capable, and the MPLS ECN field shows that
   the packet is ECN-capable but has not experienced congestion upstream
   on the LSP, then the MPLS ECN field is changed to indicate congestion
   (i.e., the encoding of "Not ECT, or ECT+CE"). If the packet has
   indeed experienced congestion upstream, the packet is dropped. This
   is an inescapable consequence of the single-bit MPLS ECN field
   combined with internal LSRs not looking at the IP ECN field.

   One functional limitation of the one-bit ECN implementation for MPLS
   is that once an LSR "sets" the CE state in an ECT MPLS packet,
   subsequent LSRs along the MPLS path cannot determine whether the
   packet is or is not ECN-Capable (without using the IP ECN field).
   Although LSRs may be able to look at the IP header (potentially with
   some performance impact), we do not require it.  Thus, subsequent

Ramakrishnan et. al                                             [Page 6]

draft-mpls-ecn    A Proposal to Incorporate ECN in MPLS        June 1999

   LSRs would have to drop that packet in order to indicate congestion
   to the end nodes, rather than using ECN.

6.  Role of Signaling to communicate ECN capability

   One requirement for the one-bit ECN implementation for MPLS is that
   the egress LSR needs information from the ingress LSR in order to
   determine how to interpret the MPLS ECN Field.  In particular, for a
   packet at the egress of the MPLS LSP whose IP ECN field indicates
   "ECT, not CE" and whose MPLS ECN field indicates "not ECT, or
   ECT+CE", the egress LSR of the MPLS LSP has to be able to determine
   whether to set the CE bit in the forwarded packet's IP ECN field upon
   decapsulation.  To do this, the egress LSR has to know whether or not
   the ingress LSR originally set the MPLS ECN field to "ECT but not
   CE".  This can be determined using information in the IP ECN header,
   assuming that the ingress LSR has previously informed the egress LSR
   whether it is or is not using ECN.  Thus, an ingress and egress LSR
   would have to negotiate whether or not they are using ECN-Capability
   for the MPLS tunnel.  Note only the ingress and egress LSRs have to
   examine the IP ECN header of the packet.

   Based on the negotiation at the time the LSP is set up, the ingress
   LSR knows what the MPLS ECN field should be set to on incoming
   packets, especially for downstream allocation of the MPLS LSP: if the
   egress LSR is ECN capable and the LSRs upstream are also ECN capable,
   then the ingress LSR knows to initially set the MPLS ECN field to
   "ECT but not CE" when the IP ECN field indicated "ECT". If the LSRs
   in the MPLS LSP are not ECN capable, then the ingress LSR always sets
   the MPLS ECN bit to "not ECT or ECT+CE". The egress LSR, knowing that
   the LSP is ECN capable through signaling, folds the MPLS ECN field
   into the outgoing IP ECN field according to Table 2.

7.  Summary

   We have proposed that MPLS LSRs exploit the capability provided in
   Explicit Congestion Notification (ECN) to provide an early indication
   of congestion without depending solely on packet dropping as a means
   of congestion indication. Given that MPLS LSRs are likely to use some
   form of active queue management, the use of ECN potentially improves
   the service obtained in an MPLS LSP with respect to packet loss and
   end-end delay. The proposal requires the use of a single bit in the
   MPLS header for indicating congestion, and signaling while setting up
   the LSP. The signaling provides the indication to the ingress and
   egress LSRs the action they need to take with respect to ECN: the
   initialization of the MPLS ECN field at the ingress and the folding
   of the MPLS ECN indication into the forwarded IP packet's ECN field
   at the egress.

Ramakrishnan et. al                                             [Page 7]

draft-mpls-ecn    A Proposal to Incorporate ECN in MPLS        June 1999

8. References

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

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

   [FBR99] Floyd, Black, and Ramakrishnan, IPsec Interactions with ECN,
   internet-draft draft-ipsec-ecn-00.txt, April 1999.  URL

   [LeF99] Le Faucheur, F., et al., "MPLS Support of Differentiated
   Services over PPP links", internet draft, draft-lefaucheur-mpls-diff-
   ppp-00.txt, June 1999.  URL

   [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
   S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C.,
   Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L.
   Zhang, "Recommendations on Queue Management and Congestion Avoidance
   in the Internet", RFC 2309, April 1998.

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

   [R99] Rosen, E., et al., "MPLS Label Stack Encoding", internet draft,
   draft-ietf-mpls-label-encaps-04.txt, April 1999.  URL

9. Security Considerations

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


   Sally Floyd
   AT&T Center for Internet Research at ICSI (ACIRI)
   Phone: +1 (510) 642-4274 x189
   Email: floyd@aciri.org
   URL: http://www-nrg.ee.lbl.gov/floyd/

Ramakrishnan et. al                                             [Page 8]

draft-mpls-ecn    A Proposal to Incorporate ECN in MPLS        June 1999

   K. K. Ramakrishnan
   AT&T Labs. Research
   Phone: +1 (973) 360-8766
   Email: kkrama@research.att.com
   URL: http://www.research.att.com/info/kkrama

   Bruce Davie
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824
   E-mail: bsd@cisco.com

   This draft was created in June 1999.
   It expires December 1999.

Ramakrishnan et. al                                             [Page 9]

Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/