One document matched: draft-ietf-mpls-ecn-00.txt
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-
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.
Abstract
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
ECN-Capable
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
Egress
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
"http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ipsec-
ecn-00.txt".
[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
"http://www.ietf.cnri.reston.va.us/internet-drafts/draft-lefaucheur-
mpls-diff-ppp-00.txt"
[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
"http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-mpls-
label-encaps-04.txt".
9. Security Considerations
Security considerations are equivalent to those for normal IP ECN and
ECN with IPsec, which are discussed extensively in [FBR99].
AUTHORS' ADDRESSES
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]
| PAFTECH AB 2003-2026 | 2026-04-22 06:17:36 |