The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2002-Jan> msg00242



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: Guaranteed QoS using MPLS?

  • From: fraanro <fraanro@arrakis.es>
  • Date: Tue, 29 Jan 2002 08:26:52 GMT
  • Cc: fraanro <fraanro@arrakis.es>, Ruyter Hill<Hill.Ruyter@carrier1.com>, "'Dekany,Steven'"<steven.dekany@marconi.com>, "'mpls-ops@mplsrc.com'"<mpls-ops@mplsrc.com>
  • Resent-Date: Tue, 29 Jan 2002 04:26:14 -0500
  • To: raszuk@cisco.com

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 <raszuk@cisco.com>
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 <Hill.Ruyter@carrier1.com>
> > 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