Re: Why MPLS can't Guaranteed QoS?

You mentioned in your response that MPLS can't guarantee QoS. May I ask why?

>From: fraanro

>To: raszuk@cisco.com

>CC: fraanro , Ruyter Hill , "'Dekany,Steven'" , "'mpls-ops@mplsrc.com'"

>Subject: Re: Guaranteed QoS using MPLS?

>Date: Tue, 29 Jan 2002 08:26:52 GMT

>Well, I am sorry if I am wrong but, in my understanding of DS-TE, the

>difference with TE is that you may have more than one bandwitdh pools,

>let us say one for each Diff serv class, but that does not mean any per-

>LSP traffic scheduling (I have never heard that it is supported in the

>current implementation, but probably I may be wrong), which IMHO is

>necessary to have guaranteed QoS. I think "soft" QoS with the right

>priorization for real time traffic (and limitation using for example DS-

>TE) may be enough for almost all the applications over IP, but on the

>other hand, I would not say that MPLS can "guarantee" QoS today.

>Javier.

>----- Mensaje Original -----

>Remitente: Robert Raszuk

>Fecha: Lunes, Enero 28, 2002 7:46 pm

>Asunto: Re: Guaranteed QoS using MPLS?

> >

> > I hope they do.

> >

> > I am also sure you know the difference between the control plane

> > reservation done for TE and actual scheduler's queue reservation

> > done in

> > DS-TE - right :) ? I had a feeling that some of this discussion moves

> > around DS-TE as well.

> >

> > R.

> >

> > > fraanro wrote:

> > >

> > > > What you are

> > > > currently unable

> > > > to do with MPLS VPN which you can do with MPLS-TE is reserve

> > > > bandwidth

> > >

> > > Probably it is not necessary to say it, but for this

> > discussion...every> one is taking into account that currently,

> > MPLS-TE (at least the

> > > implementations of the main vendors like Cisco, Juniper,

> > > Riverstone, ...) does not actually "reserve" any bandwidth, it is

> > > something that just happens in the control plane, not in the

> > forwarding> plane, right?

> > >

> > > Javier.

> > >

> > > ----- Mensaje Original -----

> > > Remitente: Ruyter Hill

> > > Fecha: Lunes, Enero 28, 2002 4:01 pm

> > > Asunto: RE: Guaranteed QoS using MPLS?

> > >

> > > > Hi

> > > >

> > > > Ok I will clarify

> > > >

> > > > >you mentioned that MPLS TE tunnels are not very

> > > > >scalable. Would it be possible to be more specific and point out

> > > > which>aspects of the TE tunnels are not scaling from an SP's point

> > > > of view?

> > > >

> > > > I am not saying MPLS-TE is not scalable as such but that it would

> > > > not be

> > > > scalable to have a separate TE tunnel for each of your classes of

> > > > service

> > > > To have to constantly dimension the available bandwidth on

> > each of

> > > > thosetunnels, as traffic patterns change, would be a management

> > > > headache to say

> > > > the least.

> > > >

> > > > >The second point I am asking is about the need for VPNs. The

> > original> > >question was about guaranteed QOS in MPLS - you seem

> > to be

> > > > suggesting that

> > > > >it is of limited value,

> > > >

> > > > I will clarify the point I was making. If you are to build an

> > MPLS-VPN

> > > > standard COS applies and in fact you can to a certain extent map

> > > > DSCP AF and

> > > > DP into the EXP field of the MPLS shim header. What you are

> > > > currently unable

> > > > to do with MPLS VPN which you can do with MPLS-TE is reserve

> > > > bandwidth

> > > >

> > > > What I was saying would be nice to see is the ability to map the

> > > > DSCP AF and

> > > > DP to the shim header on the MPLS VPN label then in turn map

> > that EXP

> > > > marking to a bandwidth guaranteed tunnel in my MPLS-TE core

> > > >

> > > > I hope this clarifies the issue

> > > >

> > > > Kind Regards

> > > > Hill

> > > >

> > > > -----Original Message-----

> > > > From: Dekany, Steven [mailto:steven.dekany@marconi.com]

> > > > Sent: 28 January 2002 15:07

> > > > To: Ruyter Hill; 'mpls-ops@mplsrc.com'

> > > > Subject: RE: Guaranteed QoS using MPLS?

> > > >

> > > > HI Hill,

> > > >

> > > > I read your comments with interest, since you obviously bring

> > into the

> > > > picture a service provider background and experience. I would like

> > > > to follow

> > > > up on two points from your email.

> > > >

> > > > The first one is, that you mentioned that MPLS TE tunnels are

> > not very

> > > > scalable. Would it be possible to be more specific and point

> > out which

> > > > aspects of the TE tunnels are not scaling from an SP's point of

> > > > view? Where

> > > > would you like to see changes for the better? Ease of

> > provisioning,> > hierarchy?

> > > >

> > > > The second point I am asking is about the need for VPNs. The

> > original> > question was about guaranteed QOS in MPLS - you seem

> > to be

> > > > suggesting that

> > > > it is of limited value, because it does not work with MPLS VPNs.

> > > > Are you

> > > > suggesting that the majority of MPLS QOS services today

> > offered by

> > > > SPs, are

> > > > being offered via VPNs?

> > > >

> > > > Thanks in advance for any further thoughts,

> > > >

> > > > Best Regards,

> > > >

> > > > Steven

> > > >

> > > > -----Original Message-----

> > > > From: Ruyter Hill [mailto:Hill.Ruyter@carrier1.com]

> > > > Sent: Monday, January 28, 2002 8:17 AM

> > > > To: 'mpls-ops@mplsrc.com'

> > > > Subject: FW: Guaranteed QoS using MPLS?

> > > >

> > > > Hi

> > > >

> > > > I would like to comment here briefly

> > > > I had an interest in a similar functionality and found in

> > > > discussion with

> > > > Robert (thanks for the info Rob)

> > > >

> > > > That although you can guarantee bandwidth and pass policed normal

> > > > IP traffic

> > > > on a MPLS-TE tunnel (not hugely scalable)

> > > >

> > > > You cannot at present pass already policed and marked packets

> > > > which are MPLS

> > > > labelled within an MPLS VPN over a specific bandwidth guaranteed

> > > > tunnelbased on EXP field

> > > >

> > > > so if someone wanted to create an MPLS-VPN say for GRX

> > services and

> > > > guarantee SIP across it you would have to rely on normal queuing

> > > > mechanismsand be sure to put enough fat in the network in

> > order to

> > > > guarantee bandwidth

> > > > is available

> > > >

> > > > Lets hope that soon we have the ability to do MPLS-VPN over

> > MPLS-

> > > > TE

> > > >

> > > > Regards

> > > >

> > > > Hill

> > > >

> > > > -----Original Message-----

> > > > From: Christopher Lewis [mailto:chrlewis@cisco.com]

> > > > Sent: 28 January 2002 02:57

> > > > To: saqibj@margallacomm.com

> > > > Cc: mpls-ops@mplsrc.com

> > > > Subject: Re: Guaranteed QoS using MPLS?

> > > >

> > > > With the caveat that the amount of traffic the application will

> > > > send is

> > > > known prior to the network being setup to service that level of

> > > > traffic,yes.

> > > >

> > > > Try

> > http://www.cisco.com/warp/public/732/Tech/mpls/mpls_techdoc.shtml> >

> > > > This link shows how this can be done on Cisco networks by

> > > > combining diff

> > > > serv QoS and MPLS traffic engineering capabilities. This

> > > > combination used

> > > > to be called Guaranteed bandwidth services, but was changed to

> > > > diff-serv

> > > > aware traffic engineering. For this to work properly, a

> > policer at

> > > > ingress

> > > > is necessary for the traffic eningeered tunnels to really function

> > > > as you

> > > > want.

> > > >

> > > > Chris

> > > >

> > > > At 06:36 PM 1/27/2002, Saqib Jang wrote:

> > > >

> > > > >Could MPLS be used to provide "virtual circuits"

> > > > >for IP applications having specific QoS requirements.

> > > > >For example, could MPLS be used to create guaratee QoS

> > > > >across an IP core for an application that requires

> > > > >no more that .1% packet loss? Do existing MPLS routers

> > > > >have such capabilities or would this require implementing

> > > > >a new MPLS standard?

> > > > >

> > > > >Also, how would an MPLS LER classify traffic that uses

> > > > >dynamic port numbers (e.g. SIP)?

> > > > >

> > > > >Saqib

> > > > >

> > > > >Margalla Communications, Inc.

> > > > >3301 El Camino Real, Suite 220

> > > > >Atherton, CA 94027

> > > > >(650) 298-8462 (W)

> > > > >(650) 274 8745 (C)

> > > > >(650) 368-8198 (F)

> > > > >saqibj@margallacomm.com

> > > > >http://www.margallacomm.com

> > > > >

> > > > >-------

> > > > >The MPLS-OPS Mailing List

> > > > >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml

> > > > >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

> > > >

> > > > -------

> > > > The MPLS-OPS Mailing List

> > > > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml

> > > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

> > > >

> > > > -------

> > > > The MPLS-OPS Mailing List

> > > > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml

> > > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

> > > >

> > > > This e-mail and any attachments are confidential. If you are

> > not the

> > > > intended recipient, please notify us immediately by reply e-mail

> > > > and then

> > > > delete this message from your system. Do not copy this e-mail

> > or any

> > > > attachment, use the contents for any purposes, or disclose the

> > > > contents to

> > > > any other person: to do so could be a breach of confidence.

> > > >

> > > > -------

> > > > The MPLS-OPS Mailing List

> > > > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml

> > > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

> > > >

> > > > -------

> > > > The MPLS-OPS Mailing List

> > > > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml

> > > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

> > > >

> > >

> > > -------

> > > The MPLS-OPS Mailing List

> > > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml

> > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

> >

>-------

>The MPLS-OPS Mailing List

>Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml

>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

The MPLS-OPS Archive

Re: Why MPLS can't Guaranteed QoS?