bandwith allocation

Unanswered Question
Oct 31st, 2009
User Badges:

Attached is the simplified digram for the network being talked on. A,B...E refers to the local branches. R1...R5 are respective branch routers. layer2 Switch is the aggregation point & Aggr router is the one connected to the private cloud for interconnection.

Aim is to achieve proper QOS for all branches. All branches have some applications which each of them may access across to other branches. Some of the applications are Voice, business critical application, average application & bulky image applications in order of importance. Considering that each branch will at the minimum have 10 Mbps link, what will be the best QOS configuration for this & where(inbound/outbound) should it be applied.

Please suggest.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Joseph W. Doherty Sat, 10/31/2009 - 14:53
User Badges:
  • Super Bronze, 10000 points or more

What kind of "private cloud"? What kind of logical topology?

suthomas1 Sat, 10/31/2009 - 21:18
User Badges:

It is an mpls cloud network with sort of hub/spoke topology as shown in the the diagram.


Joseph W. Doherty Sun, 11/01/2009 - 02:55
User Badges:
  • Super Bronze, 10000 points or more

Please further clarify "sort of hub/spoke topology". Specifically, can any site communicate directly with anyother site, and if they can, would they? (MPLS support for site-to-site, vs. typical frame-relay or ATM hub-and-spoke cloud topologies, can have a huge impact for an optimal QoS configuration. So, this clarification is very important.)

suthomas1 Sun, 11/01/2009 - 03:44
User Badges:

Yes, each of these sites can communicate with other sites via the mpls cloud. Similar to a any MPLS site to site.


Joseph W. Doherty Sun, 11/01/2009 - 04:40
User Badges:
  • Super Bronze, 10000 points or more

In that case, you need to find out from your MPLS vendor what, if any, QoS support they provide. Usually they offer some traffic class structure that uses DSCP tags to identify traffic. Sometimes there's extra cost for QoS support or cost for different kinds of QoS support. Since you mention voice, you'll be expecially interested in what real-time traffic QoS support is available (this too sometimes has a separate charge).

Assuming "typical" MPLS provider QoS support, four (or more) traffic classes, with a real-time traffic class, you'll classify and mark you're traffic as you pass it off to your provider. Additionally, if you manage the actual CE device, you also organize your queues, and their bandwidth allocations, to correspond with the MPLS provider's QoS model. (NB: strictly speaking, you can model ingress into the MPLS cloud differently from what the provider expects, but's it's crucial you properly tag traffic to utilize the provider's QoS template.)

On a CE router, you might have some CBWFQ policy like this:

policy-map aSample

class VoIP

priority percent 30 (often depends on contracted bandwidth per link)

set ip dscp EF

class busCrit

bandwidth remaining percent 40

set ip dscp AF21

class bulkyStuff

bandwidth remaining percent 5

set ip dscp AF11

class class-default

bandwidth remaining percent 15

set ip dscp 0 (or BE?)

Again, bandwidth percentage would normally correspond to MPLS provider's QoS model. More than 4 classes might be available, depends on provider and what they offer.

The two usual congestion points are your CE interface into the MPLS cloud and the PE interface exiting the MPLS cloud. The former you might control, the latter is generally always controlled by the MPLS provider.

How to classify traffic depends on your service requirements and, also again, what the MPLS provider can deliver for QoS.

MPLS often provides, besides different QoS classes, contracted bandwidth which might be less than link bandwidth. Such contracted bandwidth often interacts with their QoS template. Since there's also often a charge for contracted bandwidth, understanding what it really guarantees, and how it interacts with their QoS model, can allow you to "right size" it.

BTW, a correct QoS implementation, often can go far in avoiding over provisioning of WAN bandwidth (and minimizing WAN costs). Keep in mind, TelCos aren't often interested in you minimizing your WAN costs. I.e. if QoS and MPLS together are new to you, and assuming you haven't already contracted for some services, you might want to retain some consultation in how best to meet your service needs.

suthomas1 Sun, 11/01/2009 - 05:00
User Badges:

Truly appreciate your assistance.Thanks for this great info.

A generic question though, if we consider voice class, how much would be the b/w that is considered fair( from other classes & link perspective as well) to be allocated.

Assuming each of the links will have a minimum 8Mbps b/w & that this voice/video will take up somewhere close to 2 Mbps for a single stream of image.


Joseph W. Doherty Sun, 11/01/2009 - 11:28
User Badges:
  • Super Bronze, 10000 points or more

Cisco suggests not using more than 1/3 of a link's bandwidth for traffic like voice. This mostly to keep from too adversely other traffic as priority traffic preempts other traffic bandwidth. Depending on you other traffic requirements 1/3 might be too much or you might have more leaway. Another consideration is whether such traffic is CBR or VBR. For traffic that's VBR, for real-time bandwidth, you also need to allow for peaks not just averages.


This Discussion