>ECN != ABR
>ECN != EFCI
Really? I thought they were the same thing. It is my fault, I should have continued my education, instead of dropping out at the elementary school and play soccer :-)
Seriously, I believe that the ABR difficulties were related to the fact that it was an end-to-end mechanism rather than an edge-to-edge, so it followed the destiny of native end-to-end ATM applications.
But that is "acqua passata", let us move on.
My only point is that as a provider I have to configure, monitor, doing something with my Lisps-based ECN bits at my edge router, without giving me any possibility to act on that, and that does not sound very appealing to me. To an end customer (mine, I mean), that is a different story.
Sergio
--------------------------------------------------------------------
Sergio Catanzariti
Senior Project Manager, Technology Integration
France Telecom R&D
1000 Marina Boulevard Suite 300
Brisbane CA 94005
Tel. 650-875-1526
Fax. 650-875-1505
email:sergio.catanzariti@rd.francetelecom.com
--------------------------------------------------------------------
-----Original Message-----
From: Curtis Villamizar [SMTP:curtis@avici.com]
Sent: Wednesday, May 31, 2000 1:41 PM
To: CATANZARITI Sergio FTR&D/TI
Cc: 'Shahram Davari'; mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com
Subject: Re: MPLS - ATM interworking?
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