The MPLS-OPS Archive

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



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

Re: Guaranteed QoS using MPLS?

  • From: Robert Raszuk <raszuk@cisco.com>
  • Date: Mon, 28 Jan 2002 20:46:39 +0100
  • CC: Ruyter Hill <Hill.Ruyter@carrier1.com>, "'Dekany,Steven'" <steven.dekany@marconi.com>, "'mpls-ops@mplsrc.com'" <mpls-ops@mplsrc.com>
  • Organization: Signature: http://www.employees.org/~raszuk/sig/
  • Resent-Date: Mon, 28 Jan 2002 15:52:24 -0500
  • To: fraanro <fraanro@arrakis.es>


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