Subject: RE: Re: MPLS - ATM interworking?

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Wed, 31 May 2000 12:13:07 -0700

Shahram,

	the draft-ietf-mpls-ecn-00.txt does not say anything about ECN usage
and applications, but only about ECN support and definition in an MPLS
network, the things are quite different. So, I have the same question: where
I can find Ramakrishnan et al., "A Proposal to Incorporate ECN in MPLS",
draft-ietf-mpls-ecn-00.txt?

	Also, I do believe that the ECN in an MPLS network works on resource
types (LSPs) quite different than native IP flows. So, the source address is
not that useful here, albeit in an ECN schema in pure IP networks.
	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.
	Absolutely, I want to associate LSPs with congestion dynamics to
eventually slow them down. How can I do that? That's the question.

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:[email-masked] 
> --------------------------------------------------------------------
> 
> 
> -----Original Message-----
> From:	Shahram Davari [SMTP:[email-masked]]
> Sent:	Wednesday, May 31, 2000 11:34 AM
> To:	'Andrzej Czerczak'; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: Re: MPLS - ATM interworking?
> 
> Andrzej,
> 
> 1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which is attached to
> this email.
> 
> 2)Congestion Notification is and end-to-end signal which is meant to be
> used
> by TCP. You don't need to know the ingress LSR or even the LSP from which
> the congested packet is received. The receiver may send the congestion
> notification to the sender using source IP address, either through another
> LSP or even through normal IP hop-by-hop routing.
> 
> Regards,
> -Shahram
> 
> 
> 
> 
> >-----Original Message-----
> >From: Andrzej Czerczak [mailto:Andrzej_Czerczak/[email-masked]]
> >Sent: Wednesday, May 31, 2000 1:46 PM
> >To: [email-masked]
> >Cc: [email-masked]
> >Subject: Re:Re: MPLS - ATM interworking?
> >
> >
> >
> >Robert,
> >First of all thanks for your comments.
> >
> >>Have you read draft MPLS Support of Differentiated Services
> >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN
> >>(explicit congestion notification) on a per LSP basis using 
> >the EXP bits
> >>in the shim header ? Currently this is the most attractive 
> >option, but I
> >> am not aware of any implementation support this today.
> >
> >
> >
> >a) Document draft-ietf-mpls-diff-ext-04.txt does not not 
> >define the usage
> >of ECN.
> >
> >b) Taking into account label merging capabilites of LSRs, how 
> >can determine
> >to which ingress LSP to to send Congestion Notification?
> >
> >c) Where can I find:
> >
> >Ramakrishnan et al., "A Proposal to Incorporate ECN in
	>   MPLS", draft-ietf-mpls-ecn-00.txt?

> >
> >
> >
> >What I'd like to say is, that at least during first phases of
> >implementations (before entire infrastructure will become IP) 
> >interworking
> >of MPLS core and ATM edge will be important, but I could not find a
> >proposal of how to do interworking between them.
> >
> >
> >
> >Andrzej
> >
> >
> >
> >
> >
> >
>  << File: draft-mpls-ecn-00.txt >>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 31 May 2000 16:40:58 -0400

In message <[email-masked]>
> edge-to-edge fashion (different from end-to-end) where the LERs could

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).

> 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