Subject: ATM Switches as LSR encoding techniques

From: Vikram Venkataraghavan <[email-masked]>
Date: Sun, 28 May 2000 19:09:41 -0700 (PDT)

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

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

Please tell me which kind of encoding is prefered in
the industry and why? (concerning the design of ATM
LSRs)

Thanks in advance,
Vikram Venkataraghavan
NEC America

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

---

From: "Philip Matthews" <[email-masked]>
Date: Tue, 30 May 2000 13:26:04 -0400

ATM switches that I know about use the "SVC Encoding" technique.
(In this technique, the top label is carried in the VPI and VCI
field of the ATM header).

However, there are routers with ATM cards that use a fourth
technique: send all packets over a single VC and use the top
label stack entry to carry the label.

- Philip

---

From: David Charlap <[email-masked]>
Date: Tue, 30 May 2000 14:55:54 -0400

Philip Matthews wrote:
> 
> However, there are routers with ATM cards that use a fourth technique:
> send all packets over a single VC and use the top label stack entry to
> carry the label.

AFAIK, this is not a legal technique.  The only router I know that does
this is only doing so because it doesn't actually claim support MPLS on
ATM interfaces.  What you're seeing is simply a side effect of running
MPLS on an unsupported interface - when you do so, it takes POS-
formatted data and blindly shoves it out a VC, just like it does for
control traffic.

(Note that this technique is not mentioned in the
draft-ietf-mpls-arch-06.txt spec.)

Even if would be legal, this fourth technique will not be very efficient
on many hardware platforms.  ATM backplanes are usually optimized for
forwarding cells based on VP/VC numbers.  They are not deisgned to run
efficiently in a situation where they must reassemble (from the cells)
each and every packet prior to making a forwarding decision.

See also draft-ietf-mpls-atm-03.txt.

-- David

---

From: Eric Rosen <[email-masked]>
Date: Tue, 30 May 2000 16:57:27 -0400

Please note  that routers with ATM  cards are not  ATM switches.  Therefore,
routers with  ATM cards would not  be expected to use  the encodings defined
for ATM switches.  If two routers are connected to each other via an ATM VC,
then of course they use  the generic MPLS encapsulation when sending labeled
packets over that VC, NOT the ATM-specific MPLS encapsulation.

---

From: David Charlap <[email-masked]>
Date: Tue, 30 May 2000 18:47:17 -0400

Eric Rosen wrote:
> 
> Please note  that routers with ATM  cards are not  ATM switches.
> Therefore, routers with  ATM cards would not  be expected to use the
> encodings defined for ATM switches.  If two routers are connected to
> each other via an ATM VC, then of course they use the generic MPLS
> encapsulation when sending labeled packets over that VC, NOT the
> ATM-specific MPLS encapsulation.

Which deliberately makes the interface incompatible with an ATM switch
running MPLS code.

Why in the world would you want to use an ATM interface if it is
incompatible with ATM switches?

OK, so you can tunnel your LSP through an ATM VC.  But why would you
want to?  If you've got ATM, use it.  One of the big points about using
MPLS is to have one unified control plane - if you're going to run MPLS
through an ATM network that doesn't participat in MPLS, then you've just
put back the layer you were trying to get rid of.  Plus you've now added
the overhead of two redundant layers of encapsulation where only one is
necessary.

-- David

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 May 2000 16:31:25 -0700

David,

> through an ATM network that doesn't participat in MPLS, then you've just

I am talking daily to all major ISPs worldwide deploying MPLS and nobody
mentioned "unified control plane" as the reason to introduce MPLS into
their network. The major reason is to be able to use applications which
MPLS offers (Traffic Eng, MPLS-VPNs, Circuit Transport, Hierarchical
Routing etc ...) 

And if you are stuck with ATM switches which don't support MPLS your
only option is to use generic MPLS encaplsulation over PVC to pass the
data through.

Robert.

> David Charlap wrote:

---

From: Jeremy Lawrence <[email-masked]>
Date: Wed, 31 May 2000 10:46:21 +1000

>only option is to use generic MPLS encaplsulation over PVC to pass the

Some of the carriers I talk to do see an IP routing/MPLS control
plane for ATM as an advantage, but not necessarily a dominant one.
So, while their medium-term plans do include use of full ATM MPLS,
use of generic MPLS over PVCs meets their requirements in the short
term.

Jeremy

---

From: "Robert Johnson" <[email-masked]>
Date: Tue, 30 May 2000 20:31:23 -0500

> MPLS offers (Traffic Eng, MPLS-VPNs, Circuit Transport, Hierarchical

How do you find the time? :) Regardless, you forgot the most important
motivator for many ISP MPLS implementations: politics. All of the applications
that you mentioned were possible (note they were possible, not necessarily
easy) using ATM. However, those ISPs that used ATM in this fashion and are now
moving to MPLS, for whatever reasons, need a unified control plane.
Alternatively, I suppose they could just throw away all of their old gear and
buy a completely new network. :)

> only option is to use generic MPLS encaplsulation over PVC to pass the

I would hate to be "stuck" with such switches. :) However, often you are only
"stuck" with the hardware while there is a firmware upgrade path to provide
MPLS functionality. Again, there is always the new network option. :)

Robert Johnson
Director of Network Architecture
Advent Networks
(512) 397-4914

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 31 May 2000 09:29:20 -0400

> Which deliberately makes the interface incompatible with an ATM switch

That's OK?  ;-)  It's actually not a deliberate incompatibility.  It
has not been expressed as a customer requirement, at least for our
customer base.

> incompatible with ATM switches?

Transition from legacy ATM backbones in which the ATM switches just
provide VCs and don't know about MPLS.

Curtis

---

From: "HANSEN CHAN" <[email-masked]>
Date: Wed, 31 May 2000 08:45:44 -0400

Eric,

> packets over that VC, NOT the ATM-specific MPLS encapsulation.

Is there any plan for router vendors to use the encodings defined for ATM
switches in the near future? This will hurt the interoperability of LSRs in the
long run.

Cheers,
Hansen

---

From: Eric Rosen <[email-masked]>
Date: Wed, 31 May 2000 11:35:33 -0400

David> Which  deliberately  makes the  interface  incompatible  with an  ATM
David> switch running MPLS code.

That's a bit  like saying that an ethernet interface  is incompatible with a
token  ring  switch.   That's  true,  but  of  no  consequence.   If  you're
connecting to an ATM-LSR, you use an LC-ATM interface.  If you're connecting
to  an ATM switch  which is  not an  ATM-LSR, you  don't.  (These  terms are
clearly defined in draft-ietf-mpls-atm-03.txt.) 

David> Why in the world would you want to use an ATM interface if it is
David> incompatible with ATM switches?

The real question is  why would you want to use an  ATM interface if the ATM
switch at the other end is not an ATM-LSR.  I think the answer is obvious --
that might be what you have to do to get your connectivity. 

Hansen> Is there  any plan for router  vendors to use  the encodings defined
Hansen> for  ATM   switches  in  the   near  future?  This  will   hurt  the
Hansen> interoperability of LSRs in the long run.

Generally  routers are capable  of handling  different kinds  of interfaces.
Thus one would expect them to be able to handle the generic encapsulation as
well as the ATM-specific encapsulation.