QoS and Traffic shaping across MPLS?

I am trying to setup CoS, QoS and queuing across our MPLS network through our service provider. We don't run any MPLS natively; it is all done by them. Most of the materials I have and references on Cisco's web site don't mention MPLS that much, so I'm not quite sure which "kind" of congestion control or avoidance I should implement.

We have a 45Mb DS3 at our datacenter, and multiple smaller sites with either single T1's or dual MLPPP bonded T1's. We are all meshed and everyone routes to everyone equally through OSPF. 'Very nice network, and much better than our old AT&T Frame-relay. My problem is I want to do QoS for VoIP through my network and I'm scratching my head as to the best method given the network.

As everyone here knows, with most direct point-to-point links such as T1, the egress speed is identical to the ingress speed. 1.544 =

1.544. Your only concern is to apply appropriate queuing out of the serial interface to prioritize your favorite packets in whatever order you see fit. LLQ, CBQ, Fair-queueing, FIFO, whatever. It'll simply travel down the pipe and be received in that same order. However, with dissimilar link sizes, like going from a DS3 to a DS1, this can't be easily done! A 45Mb DS3 would never see it as congestion on its' side, although the poor little DS1 certainly would.

My question is -- Do most service provider's MPLS networks apply any traffic shaping or queuing mechanism within the cloud at all? Or does it need to be completely controlled by me? Are packets dropped (I assume so?) when the end node can't receive traffic as fast as the head node can send?

There are a lot of QoS and congestion avoidance mechanisms available in Cisco IOS, but most of them refer to Frame-relay. I was thinking of applying the same traffic-shaping syntax to my own Cisco routers, except that I don't have to worry about any CIR value - only port speed. There is also no MPLS equivalent of BECN's or FECN's that I'm aware of, so I'm not quite sure if the MPLS cloud would send me any feedback if packets were indeed dropped. So can I even use LLQ + CBWFQ to seperate my voice from everything else? Or do I also have to figure out generic traffic shaping and incorporate it into the mix?

Thanks.

-Bob

Reply to
Rob
Loading thread data ...

ours does - if you subscribe to the QoS options (there is a charge for high priority bandwidth), then we push your packets thru the cloud using 3 bits of priority which are part of MPLS.

PE router at the far end uses the markings to decide what to send.

even if you fix this, you need to limit high priority traffic. the IPT system may have some tools to limit bandwidth or number of calls across each pipe.

formatting link
has some info on call manager configs for WANs that explains the Cisco mechanism, but the concepts should be pretty general.

Nope. the access link may run F/Relay encapsulation but i havent seen any mapping to FECN / BECN.

So can I even use LLQ +

Yes - but some of the problems need either a lightly loaded network, or help from the telco.

Or do I also have to

you need to mark the packets so that the MPLS cloud "knows" what priority to work with - so oyu need to fit in with the priority scheme the cloud is set for.

Without that there is probably enough bandwidth in the MPLS that discards and jitter are not a major issue, but you may have problem where the access pipe exits the cloud

you could shape all your traffic to stay inside the bandwidth or you may get discards at the outbound PE interface - and if you shape the traffic that hard you might as well go back to a real F/Relay network.....

Reply to
stephen

My provider is Global Crossing, and they do have different service queues for Basic, Enhanced and Premium. I can setup (with them) whatever IP Precedence or DSCP bits I want to represent each class. They do have a defined priority of 90% / 9% / 1% is there is congestion on their network. I am not so worried about that as what do I do for my side of the QoS and queueing to insure that my datacenter DS3 doesn't flood a remote T1. I know TCP is self sufficient, but UDP is not. I am running VoIP now over those links, but I have not begun to have any congestion issues where I need QoS, but I can see it coming. Is simply having my appropriate voice packets marked as DSCP 'EF' which sends it down the "Premium" pipe good enough? I wouldn't think so. Should I just implement LLQ + CBWFQ, or should I even worry about traffic shaping?

-Bob

Reply to
Rob

its not flooding that is the issue, its limiting high priority traffic.

make sure the Voip is limited so that it doesnt go over the amount of traffic GS will allow at high priority.

so long as they implement QoS on their routers, if there is low priority congestion then they throw low priorty packets in preference to high priority.

I know TCP is self

you need something like LLQ.

i suggest you force some overloads so that you understand how it works before you have to do diagnostics on the fly.

Reply to
stephen

I had a similar problem like yours and it appears like solved for now. I don't have a MPLS cloud between my sites since remote sites are connecting onto central site for accessing corporate web applications using SSL (trough the Internet). So, what I done:

- Let say that you have a central site router (R1) connected with 2 Mbps FR to my ISP. Remote site router (R2) is using 1 mbps ADSL Internet connection. There is always been a problem when R2 router had overloaded it's ADSL by R1 since it has a faster link then R2. To prevent such behavior I simply implemented CB traffic shaping and place that policy-map at the inside R2's interface because you must implement TS for outbound traffic. For TS value use bit rate for about 5% lower than your bw defined with SLA. Now you may place CBWFQ classes as nested in TS to provide prioritization at R2 site for certain traffic classes (downstream traffic from R1 actually). Doing this way you have to sacrifice 5% of your actual SLA bw, but you'll get control (static only, that is without congest. dicovery such as FECN/BECN) over congestion and QoS between remote sites over ISP networks which you don't control. It seems to work for me (actually I run such setup for about a 1 year with no problems discovered yet). Of course, such setup suppose that your ISP's are providing bw defined in SLA... Actually, thanks to this setup I discovered that 1 of my SP's had incorrectly implemented TS since I could never achieve bit rate (to bring my TS active) when I transmitted with bit rate even for 5% lower then my actual SLA. After I presented them such proof they had to correct their ATM TS misconfig. and now it works fine:)

I realize that my explanation could be a little bit unclear, so on your request I'll provide sample topology and configs...

B.R. Igor

Reply to
Igor Mamuzic

Igor, I am familiar with shaping outbound traffic from an ADSL line because of my Vonage use across the Internet. I'm not sure the analogy is the same with my work. My T1's are also not asymetric. My biggest concern is whether or not I have to do traffic shaping or other form of QoS at the DS3 headend.

Did you perform any LLQ or CB queuing on your R1?

Reply to
Rob

Rob,

For your VoIP traffic (this is one of your traffic kind if I understood well your posts) you should implement LLQ (inside CBTS if you follow my advice) since you don't want your VoIP traffic to starve lower priority traffic.

I use CB TS for outbound traffic on R1. I shape it also for the 5 % less then my SLA contracted bw to avoid packet loss in the carrier network if I run over contracted BW. Then inside of the CB TS policy-map I nest CBWFQ classes (for example outbound traffic sourced from my business application www server) to give some priority for this traffic. On this way I hopefully have all eventual packet loss controlled on my R1 and not in the carrier network which I don't control.

In my career once I had a problem with excessive outbound traffic drop at my serial interface (FR) and Cisco TAC engineer advised me to implement any kind of traffic shaping at my R1 better then letting my SP's cloud doing this without my control. In this way if you experience poor transmission performances and your TS seems do be inactive then you know that (if there is no IOS bugs:) ) something is wrong in your carrier's cloud... But, there is a little let say caveat in my approach to this problem: if you don't implement any TS, but only CBWFQ/LLQ then if your interface out queue becomes saturated CBWFQ or LLQ will manage congestion to provide priority... On the other hand, with CBWFQ/LLQ nested inside of the CBTS policy-map your queueing method will never be aware of congestion in the carrier cloud, since it activates only if you exceed TS transfer value, but anyway your carrier should provide you with error free transmission (in ideal world:) ) anyway so you don't have to worry about this "caveat":)

B.R. Igor

Reply to
Igor Mamuzic

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.