Re: Re: Voice over MPLS

Still exploring,

It could be done exactly the same way it could be done in non-MPLS scenarios (per "VPN" and not shared across VPNs).

Doug Legge <Doug.Legge@berkeleygroup.co.uk> wrote:

Sylvia,

How do you as a service provider support the Enterprise multicast across
your network (say for the VoIP Music On Hold)? Through GRE, mVRF?

Doug
Berkeley

-----Original Message-----
From: Spice Sylvia
To: Eric Osborne
CC: M. ELK ; mpls-ops@mplsrc.com
; dh8@pobox.com
Sent: Tue Jan 13 06:00:26 2004
Subject: Re: [MPLS-OPS]: Re: Voice over MPLS

--- Eric Osborne wrote: > On
Mon, Jan 12, 2004 at 05:10:43PM +0000, Spice
> Sylvia wrote:
> > I am looking at making the policying more
> "granular".
> >
>
> more "granular" than "what"?

..More granular than 64Kbits/sec or as we call it
today:DS0.

>
> > Scheduling methods ! or use of "TOS" bits is fine,
> but consider a typical case.
> >
> > We have say 20 Mb/sec bandwidth.
> >
> > We have more than 10 customers.
> >
> > We need to
> > a. ensure each customer gets his "CIR"
> > b. the customers are allowed to burst into a
> common burst pool
> >
> > The customer caps are more like 3Mb/sec, 5Mb/sec
> etc
> >
> > sum total of all CIR = 20Mb/sec
> >
> > and there are more than 50 customers
> >
> > Now
>
> > a. how do I prevent one customer from hogging away
> all the bandwidth
> > (If I mark all of them with TOS till their
> relative CIRs, eitherways
> > need to pace data to mark them, dont I?)
>
> 1) L2 QoS (ATM/FR)

They do rate limit, do they not? The question you
asked was what does one hope to achieve by the same.
> 2) managed CE and do the shaping/policing yourself

which is again policing somewhere..

> 3) rate-limit after the fact (rx on PE) and charge a
> lot for exceeding
> purchased capacity

definately, its all for the money and billing that we
need it :-)

>
> I'm not sure what 'pace data to mark them' means.
> You really have two
> choices - shape (leaky bucket) or police (token
> bucket). Policing
> tends to be easier on the PE since it eats up less
> buffers, but you
> can do whatever you want; most people I talk to do
> policing, since
> a) VoIP tends to be easy to predict and sell
> queue space for, and
>
> b) most non-VoIP nowadays is TCP, which will
> pretty much shape
> itself if you have something like WRED within
> your token bucket.
>

agreed, not much confident of WRED versus "Shappers"
but yes we could say that. ! Shappers are better in some
cases where close to CBR is needed.

>
> > b. it is very likely that unless there is a cap,
> and a way of measuring the same in the forwarding
> plane that one could control the rate.
> >
>
> Agree. Luckily, we have all these neat QoS
> mechanisms for doing just
> what you seem to want.

cool.

>
> > If it is GMPLS as you said, fair enough it may
> have an answer, unfortunately, as of date, no
> granuality seen so far as I mentioned. But it is a
> possible answer.
> >
>
> GMPLS is not a QoS mechanism, it's really routing
> and a collapsed
> control plane. One of our guys refers to QoS as
> "managed unfairness",
> and that's exactly what it is; you screw the guy who
> pays less. GMPLS
> doesn't do that, at least not in the forwarding
> plane.

Wonder why they have "bandwidth ! encoding then".

>
> > In most cases today, the access speeds to
> customers are much more
> > than their CIRs.
> > Also a typical customer may get , say 1Mb/sec till
> the closest ISP,
> > 5 Mb/sec within my ISP and 3 Mb/sec to a
> particular web server we
> > host for him. How do I handle such scenarios
> without policying?
>
> You don't. The only thing I was trying to say is
> that you need to
> police as close to the customer as possible (on the
> PE, possibly on
> the CE), and that policing on the tx side of a TE
> headend (presumably
> on the PE) is not the right place to do it.

agreed.

>
> Or do you somehow think this sort of stuff is easier
> to do tx on the
> PE than elsewhere?

It is easiest on the multiplexer.

>
> And didn't you want some protocol to count the
> number of regens in ! a
> SONET hop? How does that help here?
>

I am lost here, what is regens?

>
>
> eric
>
> > 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
> >
> > &! gt;
> > > "M. ELK" 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
>
=== message truncated ===

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html

-------
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.shtmlplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

The MPLS-OPS Archive

Re: Re: Voice over MPLS