The MPLS-OPS Archive

["Eddy Tedjasaputra" <eddyt@sistelindo.com>]

Hi Bruce, 

Thanks for the hints..
As for NAT, it should be no problem (at least in our case) as each customer will be getting a range of legal IP addr; 
and therefore there will be no overlapping of the IP addr.
By the way, do you have a reference on how to rate limiting the traffic ?
I did make multiple classes (1 per customer) 
>>>
class CustA
     police cir 32000 bc 4000 pir 128000 be 4000 conform-action transmit
exceed-action set-prec-transmit 2 violate-action drop
>>>
but seems it doesn't work properly -:)
Any other better way to do a rate limiting ?

Eddy.

----- Forwarded by Eddy Tedjasaputra/Sistelindo Mitralintas/ID on 17/01/2003 07:05 -----

"Bruce" <bruce_reid202@hotmail.com> 16/01/2003 00:51

To:        <mpls-ops@mplsrc.com>, "Eddy Tedjasaputra" <eddyt@sistelindo.com>         cc:                 Subject:        Re: [MPLS-OPS]: QoS

Hello,

You could try this:

1. make multiple classes , 1 per customer for rate limiting them at the
internet gateway router itself..PE-3
2. try making you " CIR bandwidth from Internet GW to other PE routers" as
an ERO constraint in RSVP. You would need RSVP *and* CSPF/TED to work for
the same.

1 ensures that you get guaranteed bandwidth at the "stastical/probablistic
point" X in your network

2 ensures that your core gets the customer sufficient CIR bandwidth, eg:
from the gateway router to the PE routers for the customer A. (asking cisco
people on the list if an ERO "of bandwidth" at the time of setting up the
signalled LSP with RSVP is possible? and if there is standard for the
available EROs in RSVP-TE today)

rate limiting is still required unless there is a refresh mechanism which
ensures each LSP is "getting its constraints". AFAIK, there is no mechanism
for the same as of date.

You might be intrested in the MPLS@UUNET mailing list. There is a talk about
MPLS PING there to check availabililty of the LSP and its constraints at a
given time..

But in my opinion, rate limiting at the internet g/w is the best option.

The advantage 2 does is that it lets u get "any path" with that bandwidth
which helps ensure that the customer bandwidth constraint is met..

There is one thing you must note:

if you are rate limiting, your customer may have overlapping address spaces
etc in MPLS topologies...but nothing in your diagram points to that (no NAT
device shown ). So I presume that is not a problem

in such cases you can look at signalled LSPs coupled with Rate limiting to
each customer. The rate limiting of your internet part will have to be
towards the gateway prior to the NAT, and the LSPs to the PE after then NAT.

So if your NAT is "wobbly" ...too bad :-)

you might also be interested in draft ospf-multiarea-te by Dr. Keerti
Kompella on the ietf site as to how CSPF merges with OSPF.

-Bruce








----- Original Message -----
From: Eddy Tedjasaputra
To: mpls-ops@mplsrc.com
Sent: Thursday, January 16, 2003 11:30 AM
Subject: [MPLS-OPS]: QoS



Hello everybody,

I'm setting up the following configuration.
An MPLS cloud with 3 PEs :
   PE1 is connected to CPE A (customer A)
   PE2 is connected to CPE B (customer B)
   PE3 (Internet Gateway) is connected to an Internet router





I tried to use a policy map below to guarantee the b/w (32K) is available to
Cust A during congestion period.
This policymap is applied on the incoming interface of PE3 (interface X)
>>>
policymap Test
class CustA
     police cir 32000 bc 4000 pir 128000 be 4000 conform-action transmit
exceed-action set-prec-transmit 2 violate-action drop
>>>
Can someone please advise me the best way how to guarantee a minimum thruput
(ie. CIR) for every customer when
a CONGESTION is occured between Internet G/W and Internet router ?

Appreciate for any comments.
Thanks, Eddy

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