The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2004-Jan> msg00015



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

Re: Re: Voice over MPLS

  • From: Eric Osborne <eosborne@cisco.com>
  • Date: Mon, 12 Jan 2004 11:32:53 -0500
  • Cc: "M. ELK" <elkou141061@hotmail.com>, eosborne@cisco.com, mpls-ops@mplsrc.com, dh8@pobox.com
  • Resent-Date: Mon, 12 Jan 2004 11:58:43 -0500
  • To: Spice Sylvia <falsesylvia@yahoo.co.uk>
  • User-Agent: Mutt/1.2.5i
  • X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562

On Mon, Jan 12, 2004 at 06:06:06AM +0000, Spice Sylvia wrote:
> Hi,
>  
> Just to add a thought to the topic and ask some questions and comments,
>  
> For other SONET/SDH based mechanisms, one could look at other ways, like signalling the Multiplexers on the path to the customer.
>  

What problem do you think this solves?

> There can also be a possibility where one could:
>  
> a. signal the intermediate Multiplexer components to setup a constrained channel to the end point.
>  
> b. bind each signaled association to a sort of interface (like channelized interfaces today, but a lot more grannular as the records of G.729a,b,c,d show) and use that signaled resource for that customer's traffic.
> 

Isn't this GMPLS?

> Ofcourse, since the signalling plane is not there today (or rather havent seen it deployed commercially), the policer seems to be the best option.
>  
> Either way, to implement a and b above, one would need a "policer" inside the routing device, would they not? 
>  
>
> Do channelized interfaces not treat themselves as seperate entities "policed" by the line clock?
>

Any policing is done on the access to the TDM link.  But where are you
going with this?




eric
  
> 
> "M. ELK" <elkou141061@hotmail.com> wrote:
> 
> Eric
> 
> Reg
> 
> Quote
> 
> Keep in mind that no matter what bandwidth pool you reserve from, it's a 
> control
> plane reservation only.
> 
> Unquote
> 
> This is a well noted point but it also raise the following enquiry :
> why their is no (separate) mechanism to police the b.w used by a TE tunnel 
> ,at least at
> the head-end .
> 
> say in CSCO implem , is it possible at the head-end to apply a policer to a 
> TE tunnel ??
> (the logic : a policer could be applied to an interface , a TE tunnel is 
> treated as an interface at
> the head-end so : a policer could be applied to a TE-Tunnel at the 
> head-end ) .
> 
> Brgds
> 
> 
> >From: Eric Osborne 
> >To: dh8@pobox.com
> >CC: Eric Osborne , mpls 
> >Subject: [MPLS-OPS]: Re: Voice over MPLS
> >Date: Thu, 8 Jan 2004 09:11:29 -0500
> >
> >On Wed, Jan 07, 2004 at 10:38:00PM -0500, Dennis J. Hartmann wrote:
> > > Is the MPLS TE Automatic Bandwidth Adjustment feature compatible 
> >with
> > > the Guaranteed Bandwidth feature?
> >
> >Not sure what "Guaranteed Bandwidth feature" is; if you mean
> >DiffServ-aware TE (DS-TE), yes, you can use this with auto-bw.
> >They're orthogonal; auto-bw changes the bandwidth request on a tunnel,
> >but other stuff you configure on that tunnel is independant of the
> >amount of BW you reserve.
> >
> > > I'm looking at an implementation on a
> > > 7301 router. On the CE - PE link, we'll be setting the DSCP to EF 
> >(using
> > > the Priority Queue) for all of the Voice over IP and using WDRR 
> >(Weighted
> > > Deficit Round Robin) as a congestion avoidance mechanism. We'd rather 
> >not
> > > use Traffic Engineering, but we will if we have to. The issue we have 
> >is
> > > that we don't want to pre-allocate tunnels that may not be utilized. 
> >This
> > > is the reason we're looking into the Automatic Bandwidth Adjustment. 
> >Any
> > > reccomendations?
> >
> >Like Rajiv said, you have to build tunnels even if they're not in
> >use. Whether TE will help you or not isn't clear to me. Keep in mind
> >that no matter what bandwidth pool you reserve from, it's a control
> >plane reservation only. You can reserve 10Mb from a DS-TE sub-pool
> >that is set to the same size as your EF queue, but you can send 100Mb
> >down the tunnel that's made that reservation, or overload the queue
> >with non-TE traffic. In order to get some sort of bandwidth guarantee
> >(not a feature, but an architecture), you need:
> >
> >- admission control (make sure you don't let more onto your network
> > than you've contracted/designed to handle)
> >
> >- proper reservation (if you're going to send X Mbps of traffic,
> > reserve X Mbps of queue space, modulo any over/underprovisioning you
> > want to do )
> >
> >- proper enforcement (don't reserve 25Mb for a TE tunnel intending to
> > carry voice if you only have 10Mb of EF queue space, for example)
> >
> >Add these things together and you can probably get what you're asking
> >for, but it's more than just setting up a tunnel reservation.
> >
> >
> >
> >eric
> >
> > >
> > > Sincerely,
> > >
> > > Dennis Hartmann
> >
> >-------
> >The MPLS-OPS Mailing List
> >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
> >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online 
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 
> ---------------------------------
>   Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now

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