The MPLS WG Archive

[Curtis Villamizar <curtis@avici.com>]

In message <337055FBC675D311A85D00508B5A9C4F2542C4@u-mail.rd.francetelecom.com>
, CATANZARITI Sergio FTR&D/TI writes:
> 
> 	ECN in an MPLS network is supposed to signal congestion in an
> edge-to-edge fashion (different from end-to-end) where the LERs could
> cooperate on that.

Shahram already pointed to RFC2481 and draft-ietf-mpls-ecn-00.txt but
perhaps a brief explanation will help.

When an LSP is set up as ECN capable, the underlying traffic must be
capable of supporting end-to-end ECN as specified in RFC2481.  This
means the L3PID in the MPLS setup must indicate IPv4 (or IPv6, but let
discuss IPv4 for the moment).  For each IPv4 packet arriving at the
ingress, if the IPv4 header indicates that the packet has the ECT
(ECN-Capable Transport) bit is set and the CE bit is not (Congestion
Experienced), then the MPLS ECN bit is set.

If later an LSR implementing active queue management (for example RED,
Random Early Detection) experiences congestion and would have dropped
a packet, if the MPLS ECN bit is set, then it is cleared.  Note that
at a second congestion point, an actual drop would occur, unlike the
two bit scheme.  At the egress where the POP occurs, if the MPLS ECN
bit is clear and the ECT bit is set in the underlying IP header, then
the CE bit is set in the IP header.

Same would apply to IPv4 or any other protocol that implements a
compatible ECN scheme (currently there are no others).

> 	Absolutely, I want to associate LSPs with congestion dynamics to
> eventually slow them down. How can I do that? That's the question.

ECN != ABR
ECN != EFCI

There is no ABR for MPLS.  To the extent that MPLS differs from ATM,
the differences are (mostly) intentional and IMHO ommision of an ABR
like capability (given that ABR didn't work well in IP networks due to
interactions between the ABR feedback loop and the TCP end-to-end
feedback loop) is also intentional and it should stay that way.

Curtis