Subject: RE: ATM Switches as LSR encoding techniques

From: Arun Viswanathan <[email-masked]>
Date: Tue, 30 May 2000 21:20:56 -0700

Vikram,

> In the MPLS Architecture document
> (draft-ietf-mpls-arch-06), there are listed three
> encoding techniques for MPLS labels to encoded
> directly into the VPI/VCI fields in an ATM AAL5
> header.
> 1. SVC Encoding
> 2. SVP Encoding
> 3. SVP Multipoint Encoding

Only SVC encoding is spec-ed out as a proposed standard.
See draft-ietf-mpls-atm-03.txt.

The other two scheme didn't move forward for lack of
interest in the community,

> 
> The document also points out that there is no
> interoperability mechanism between ATM LSRs that use
> different kinds of encoding.

and interoperability being the main issue.

Hope that answers your question.

-arun

---

From: "Bilel Jamoussi" <[email-masked]>
Date: Wed, 31 May 2000 17:00:55 -0400

This thread is getting off-balance. There are pros and cons
to every technology. MPLS provides and evolution path from 
today's networks and if implemented right on ATM hardware,
can take advantage of its many advanced capabilities.

a) ATM cell-switching overhead is getting overblown compared
   to other transports. Look at any voice over packet 
   implementation today ATM is still the most efficient 
   transport.

   In addition, when considering the advanced 
   Traffic Management (a.k.a. QOS) capabilities of ATM hardware,
   the cell-tax becomes a very insignificant overhead compared to 
   what you have to do to get to a similar QoS level with other 
   equipment.

b) multipoint-to-point: VC-merge capable ATM LSRs support 
   this today. Most ISP demand for TE-LSPs is point-to-point.

c) n**2 connections: There is a threshold when this becomes
   a significant issue.

d) OA&M and network management: MPLS still has some work to do
   to address these issues. How many implementations are out there
   without a MIB? 

Bilel. 

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Wednesday, May 31, 2000 12:30 PM
To: Eric Gray
Cc: [email-masked]'; David Charlap; [email-masked]
Subject: Re: ATM Switches as LSR encoding techniques

EricGray> All of  these things  are things that  exist and can  be supported
EricGray> using ATM (for  example).  Yet people you're talking  to want them
EricGray> using MPLS.   Perhaps the  unified control plane  issue is  not as
EricGray> orthogonal as you think?

There are  a number of  reasons for preferring  MPLS to ATM that  don't have
much  to do  with the  control plane:  ATM's cell-switching  overhead, ATM's
scalability  problems   having  to  do  with   lack  of  multipoint-to-point
capability,  the scalability  problems of  having to  have  n**2 connections
among the  n routers on  the ATM network,  ATM's dependence on  a particular
data link  layer, the  inability of  most ATM switches  to handle  native IP
packets at  all, etc.  IMHO,  it's the scaling  issues rather than  the more
abstract "unified control plane" issues  which are driving the market.  Many
of the things  which can in theory be  done with ATM are difficult  to do in
practice because of the scaling limitations.

But I would agree  that there are also important reasons that  do have to do
with unifying the control plane: I  think the need to support an ATM routing
and addressing infrastructure  which is independent from the  IP routing and
addressing  infrastructure is  a problem,  one which  MPLS doesn't  have.  I
don't know though how much the customers really care about this. 

Some folks have made a fetish out of this drive for a unified control plane,
arguing that  what is really needed  is the one true  grand unified protocol
that does absolutely everything.  I think what Robert is saying is that this
fetish is not something which derives from customer needs.