The MPLS-OPS Archive

["Robin Smith" <rosmith@cisco.com>]

Hi Chris

I was speculating about the tag lookup being quicker than a prefix lookup
based on the law of physics and all other things being equal. Apologies but
I have no performance data.

About IP+ATM QoS, and trying not to get religous about it cos it takes too
long to explain!... a cell based Q will always be better than a packet based
Q because the Q only has to wait a guaranteed cell time before the next cell
gets serviced. Cisco ATM switches have multiple IP CoS Q's in order to allow
mapping and serving of different IP classes, so interleaving of packets from
differing classes is not an issue. As already discussed on this forum, this
is an advantage for applications with tight delay variation tolerance. There
are several other very convincing arguments for IP+ATM which have nothing to
do with QoS which I will discuss offline if you like.

Careful not to confuse IP+ATM(which has nothing to do with PVC's) with IP
over ATM

Rgds
Robin.
> -----Original Message-----
> From: Christopher Lewis [mailto:chrlewis@cisco.com]
> Sent: 20 March 2001 13:43
> To: Robin Smith
> Cc: Sidnie Feit; Yehuda Wieder; mpls-ops@mplsrc.com
> Subject: RE: Questions about MPLS
>
>
> 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/12
> 0newft/120t/120t5/ipatm3.htm
> and
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12
> 0newft/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