The MPLS-OPS Archive

[Christopher Lewis <chrlewis@cisco.com>]

Robin, please see in-line. Goos to see another Brit on the alias.

Cheers

Chris

At 02:57 AM 3/20/2001, Robin Smith wrote:
>Christopher, see inline:
>
>Rgds
>Robin.
>
> > This is not the case. In the days of tag switching, it was thought that
> > lookups based on a fixed length label rather than a variable
> > length prefix
> > would be quicker, but that was before the days of hardware
> > implementations
> > in routers; there is no real performance improvement by adding MPLS to
> > modern routers.
>
>There will be if you do the tag lookup in HW too!

It is and there is not. Have you done any testing? I would love to see the 
test plan and the results if you have.


> > MPLS QoS only copies what is available in the world of IP to
> > begin with, it
> > does not provide any additional QoS mechanisms.
>
>Have you ever heard of IP+ATM CoS(IP enabling an ATM switch and use of ATM
>IP CoS Q'ing)?

Yes. Here we can easily slip in to religious arguments, it is an emotive 
issue. IP+ATM CoS was there before MPLS integration. It has options that 
give you WRED per PVC, or maps PVCs with different service characteristics 
to packets with different IP precedence values. Clarence Filsfil home page 
has excellent presentations on this. IMHO, it is not providing any 
additional functionality on top of IP CoS, it is just a way to patch the 
two different QoS mechanisms together.

Now some ATM proponents will say that ATM QoS gives harder QoS guarantees 
than IP QoS and therefore if you go straight in to an ATM cloud at the edge 
before the IP traffic has experienced any congestion, you can leverage 
ATM  SLAs and get better quality guarantees. To really reap the benefits 
here, the customer edge device also has to be ATM, as the CE to PE link is 
often the one that experiences congestion in the first place, and if the 
area that is experiencing congestion is packet based, this perceived 
additional guarantee from ATM is of no value.

Others will say low latency queuing Deficit Round Robin, CAR, WRED and the 
rest in IP can be configured to give the same net results in a packet only 
network. As I say, I think that's religious and I will not comment any further.

As you say, you can IP enable an ATM switch, but that is only in the 
control plane and therefore has nothing to do with quality of service that 
is executed in the forwarding path. The IP enabling of an ATM switch 
obviously adds IP as the routing algorithm rather than PNNI, but its only 
real advantage to the QoS mechanisms outlined above is that it automates 
some of the otherwise manual config.

For those that cannot get to the internal Cisco pages (like Clarence's home 
page), you can check out 
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/ipatm3.htm 
and 
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t3/ipatmcs2.htm
For the case where MPLS is used in IP QoS 
http://wwwin.cisco.com/cmc/cc/so/neso/vvda/ipatm/tagsp_wi.htm#xtocid513633

Perhaps the most accurate statement is that MPLS adds nothing to IP QoS for 
frame based networks, if you like ATM QoS better, MPLS can enable you to 
take advantage of that by reducing some manual configuration for you when 
you map the two QoS worlds together. Yakhov made the best comment here that 
if you consider TE as part of an overall quality of service scheme, MPLS 
does add something to IP QoS, but that is a matter of semantics and not 
everyone is willing to accept TE as a QoS mechanism.


> > IMHO there are three reasons to consider MPLS
> >
> > 1. To IP enable an ATM network
> > 2. To provide traffic engineering functions to an IP network (PBR has
> > issues when applied on a large scale)
> > 3. Enable traffic separation in IP networks to support VPNs.
>
>Agreed, primary market drivers

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml