The MPLS-OPS Archive

["Shailendra Gupta" <shailendra.gupta@estelcom.com>]

Dear Sylvia

 

It is possible to achieve, if you could define the CIR & max. limit of for each customer. You may use following method to provide the CIR & Burst from Common BW Pool, using Cisco CAR(this will required dual CAR statements) or Dual-Rate Policer(MQC).

 

1. Color all CIR traffic with defined Precedence Value say "5" and transmit this.

2. Color all Traffic beyond CIR but below the defined Burst Limit of individual customer, with a precedence say 1 and Transmit or continue[as per the case ]

3. Drop all traffic beyond defined Burst Limit of  individual Customer at ingress itself.

4. Now suitable apply Rate-Limit/Police for such a Burst Traffic marked with Precedence 1 on a suitable common Interface. You may allocate the BW to such a Pool based on your Network usage Pattern,amount of active customer at a given points and their application requirement.

 

My inputs are generalized and would need fine tuning/customization, as per your requirement.

 

Rgds

 

Shailendra

 

----- Original Message -----

From: Spice Sylvia

To: Eric Osborne

Cc: M. ELK ; eosborne@cisco.com ; mpls-ops@mplsrc.com ; dh8@pobox.com

Sent: Monday, January 12, 2004 10:40 PM

Subject: Re: [MPLS-OPS]: Re: Voice over MPLS

I am looking at making the policying more "granular".

 

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 i need to pace data to  mark them, dont I?)

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.

 

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.

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?

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 h! avent 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" 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 i! mplem , 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. W! hether 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 yo! u 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
&! gt;
> ---------------------------------
> 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

---

Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now