Previous

Content  

Next

2.2.- Creating a Traffic Policy

  

The next step to implement a Differentiated Service Domain using Cisco is to learn what Traffic Policies are, and how to create them using the router.
Just as a Traffic Class specifies a mechanism which can be used to match incoming and/or outgoing packets on a router's interface, Traffic Policy is used to:
  1. To collect Traffic Classes together in one object called Traffic Policy. It's easier to associate a Traffic Policy with an object because this way we can manipulate it with flexibility.
     
  2. To apply to each Traffic Class component the PHB (Per-Hop Behavior) corresponding to it. Have a look to the Differentiated Service Theory to understand exactly what PHB means.
     
  3. To mark or re-mark packets belonging to a selected Traffic Class before they are forwarding to their next hop. When we talk about "marking" we, originally, refer to the packet's DS field to print on it the selected DSCP, but Cisco extends this capability permiting to us to mark some other packet's fields too.
     
  4. And finally, to assign the complete object, i.e., the Traffic Policy, to one or more interfaces of the Cisco router in such a way that our definitions implemented in the object will be applied to traffic crossing the router through the selected interface(s).
 
To define a new Traffic Policy we start our work by naming it; again, a name you like that has some meaningful relationship with the object you are trying to represent. We will continue using our previous example of our router and its companion domain. Have a look to Figure 1 in previous section just here.
 
Again, trying to be practical, let's enter immediately in one example requiring to use a Traffic Policy. In the previous section we created a Traffic Class called "domain" to select packets coming from our example domain. The class was a very "crude" attempt to identify packets coming to our router from the domain's networks 212.29.13/24, 201.30.16/24 and 204.30.21/24. Okay, it doesn't matter; we are just learning and because of this we can be as an elephant in a crystal shop. We will have enough time later to refine our great ideas.
 
Assuming that we have already created the Traffic Class "domain" as was explained in the previous section, we start this second part typying as follows to entering the router in policy-map configuration mode:
 

 
   

 
With this command we got two things: a.- we have put our router in policy-map configuration mode; b.- we have created the policy pdomain to represent what we want to do with flows coming from this domain.
Having our router in policy-map configuration mode, we continue the work by populating the recently created policy with some previously created classes; but, because we only have one of these monsters, our policy will have only one class; to include the class into the policy we type:

When we type the command class followed by the class name of a class previously created, Cisco includes this class into the policy object we are working to and enters immediately in policy-map class configuration mode. Being in this mode, all following commands you type in your router will be applied to packets belonging to this class (the last class you include or invoke being in policy-map configuration mode). After you configure the current class you can select another one by typing again the command class and a new class name (the class must previously exist), and then begining from here, all new commands will be applied to packets belonging to the new selected class. A policy object can contain as many classes as you want.

Okay, but, having selected a class being in policy-map configuration mode, what can we do next? Just type commands to policying our selected class, or better said, to policying packets belonging to that class. Being this clear it would be good enough to bring here a list of these possible commands. Let's get to work. 

Really Cisco has more commands but we are going to concentrate on these which are that better apply to implementing differentiated services. Last two command are for marking or re-marking packets; the other are for applying PHBs. Well, my friends, let's go little by little beginning with the first command.
bandwidth
This command is for specifiying the minimum bandwidth to be guaranteed to a traffic class in period of congestion. The command is invoked as follows:

Observe here that the router is in policy-map class configuration mode. The command has one argument. It can be an absolute value given the minimum bandwidth guarantee in Kbps, or in the absence of, the sub-command percent followed by the percentage share of the total bandwidth to be guaranteed to the class being configurated.
Following the same path previously used to explain the concept of Traffic Class, let's type all the commands required to create a Traffic Police that guaranteed 2 Mbps to traffic from the domain flowing through our router. Then, being in global configuration mode, we type:

I have repeated the commands to create the class to help you to understand better the global process. You can check more about how to use these command in the previous section. After finishing, the Policy Class "pdomain" will be prepared to guarantee 2 Mbps to packets from the three network belonging to this domain. I say, will be prepared, because eventually we have to apply this policy to some of the router's interfaces, but, don't go hurry, more about this below.
A different alternative could have been to assign to the class domain a percentage of the interface bandwidth. This approach is even more resilient because the policy can be later applied to some interfaces having different bandwidth capabilities. In this case the policy creation commands are as follows:

In this case 15% of the interface bandwidth is guaranteed to the class domain in the policy pdomain.
fair-queue
When we use WFQ queuing discipline in one interface (in fact, this is the Cisco's default queuing discipline) we can set the number of packets permited per queue and the number of queues to be implemented per discipline. Have a look at WFQ queuing discipline in this site for more information. The command we are studying now is used to set the number of queues to be reserved for the class we are working to. The command is invoked as follows:

And a very simple example using the same previous domain, traffic class and traffic policy, is as follows:

In this example we configured the serial interface 3/0 with a WFQ queuing discipline having 512 queues, each one with a capability for 128 packets. Next we open the traffic policy "pdomain", the previous existing traffic class "domain", and we set to this class the 50% of available queues in the interface's queuing discipline.
police
This is one of the most important command for implementing differentiated services. It allows us to create a police that, normally, is used to control traffic entering one domain we are interested to protect from misbehaved flows. The police is normally implemented on edge routers belonging to the domain being protected. The command is invoked as follows:

The command must be typed in one large single line. The command uses a token bucket algorithm to police the traffic flowing through the traffic class over which it is applied. More about the token bucket algorithm in this site at TBF queuing discipline. Explanation about parameters of the command above is as follows:
  1. bps:  average rate to be commited with this traffic class.
     
  2. burst-normal:  normal burst size, in bytes.
     
  3. burst-max:  excess burst size, in bytes.
     
  4. action: action to be taken when an event occurs.

    Events are:
     
     
    1. conform-action:  Traffic on this class conforms the rate limit, i.e., traffic's rate is equal or less than the selected average rate limit bps.
       
    2. exceed-action:  Traffic on this class exceeds the rate limit, i.e., traffic's rate is more than the selected average rate limit bps.
       
    3. violate-action:  Traffic on this class violates the normal burst size burst-normal and the maximum burst size burst-max.
    		  

    Actions are (there are more but we present here those that are of interest to differentiated services):

     
    1. drop:  drops the packet.
       
    2. set-dscp-transmit dscp:  sets the packet's differentiated services code point (dscp) value to dscp and transmits the packet.
       
    3. transmit:  sends the packet.
    		 
Events above are a little bit complicated than they appear in this simple definition. When can we say an event is fulfilled? It is good enough leaves Cisco to explain this better with some examples. Have a look to these examples I took directly from the Cisco site.
Going back again to our previous example, now we want to define a traffic policy to protect the domain to the left of our friendly router of aggresive traffic coming from the domain to the right of it. Our router is going to act as some kind of edge router for the domain to its left.

Our problem is UDP traffic coming from the aggresive neighbor domain. We know this traffic is unabled to implement adequately congestion control, then we want to police it before entering our domain. Our SLA (Service Level Agreement) with the neighbor domain is as follows:
  1. We will accept UDP traffic up to 1 Mbps and a burst size up to 2KB (assuming a 10ms link) with no restrictions. This traffic will be marked on entrance as Expedited Forwarding (EF) traffic to be transported and dispatched through and from our domain ASAP.
     
  2. UDP traffic above 1Mbps will be accepted but will be marked as Best Effort (BE) when entering our domain. There is no guarantees that this traffic will be respected when crossing the domain's networks. In case of congestion packets from this traffic will be the first to be selected by core routers to be destroyed.
     
  3. Burst of UDP traffic will be accepted up to 4KB; above this, packets will be dropped to protect our domain.
Okay, let's start by configuring our router as follows:

Decimal 46 correspond to the DSCP value for EF PHB; have a look to the previous section where a table containing DSCP values was presented. Finally, do not forget that the policy-map command must be entered in a single long line.
priority
This option or command permits to us to give priority to a class within a policy map. It acts by configuring a low latency queue (LLQ) to provide strict priority queuing (called PQ) for the Cisco CBWFQ discipline. If you want more information about PQ and CBWFQ have a look in this site at PRIO queuing discipline and WFQ queuing discipline.
Low Latency Queues are generally used to prioritize realtime traffic consistent of small size UDP packets ahead of bulk traffic consistent of big size TCP packets. This is very important to give better response and lower latency to realtime traffic which is very sensible to this metric. I wrote something about this problem in this site at Voice over IP. VoIP traffic consists of a constant bit rate (cbr) stream of this kind of small UDP packets.
The command is invoked as follows:

Arguments are bandwidth-kbps (an absolute value) which guaranteed allowed bandwidth, in kbps, for the selected class, or by specifying a share of the interface available bandwidth using the keyword percent and the percentage value to be assigned to the class; this value can be a number from 1 to 100. 
 
When the device is not congested, the priority class traffic is allowed to exceed its allocated bandwidth. When the device is congested, the assigned bandwidth is guaranteed but any traffic above the allocated value is discarded. Observe that this policy is very different than we saw before when using the command police. This, more flexible command, allows for just marking, re-marking or dropping a packet when the assigned bandwidth is surpassed.
 
The burst argument is optional and is used to specify the burst size allowing to accomodate some temporary burst of traffic. The default burst value is configured automatically by computing 200ms of traffic at the configured bandwidth rate.
 
Very important: bandwidth command (see above) and priority command are mutually exclusive and cannot be used in the same class, within the same policy map. However, the commands can be used together in the same policy map when they are applied to different classes. Within the same policy map you can give to different classes the priority status. When this occurs all traffic from all these classes are enqueued into the same, single priority queue.
 
Let's see now how we can use this discipline to implement some differentiated services. Our goal this time is to protect VoIP traffic travelling out from our domain to some other domains through a PTP serial link. First we create the class to represent the VoIP traffic and then we applied the priority command to this class. Type in your router:
 

 
   

 
 
This configuration assigns 128 kbps to traffic that is matched by the class voip; in this case just UDP traffic. The default burst will be 3276 bytes. Unless you have a very good reason to use absolute values (and there are a lot, believe me), it's better to use a configuration based in some shared value. For example,

This configuration assigns 20% of the interface's available bandwidth to the class voip with a burst of 5000 bytes.
queue-limit
This command is used to specify or modify the maximum number of packets that can hold a queue assigned to a traffic class belonging to a policy map. Normally Cisco assigns a default queue-limit of 64 packets for most routers. For routers belonging to the VIP-platform (more expensive routers) the queue-limt value is equal to (using Cisco words): the number of 250-byte packets  that would lead to a latency of 500 milliseconds (ms) when the packets are delivered at the configured rate. For example, if two 250-byte packets are required to lead to a latency of 500 ms, the default number-of-packets value would be 2.
Okay, let's clear this a little. when you assign traffic classes to a policy map a queue is created in WFQ discipline for every class assigned. More about WFQ is in WFQ queuing discipline. Then, packets arriving to the router and belonging to one traffic class (those that satisfy the match criteria for the class) are accumulated in the queue reserved for the class until they are sent, which occurs when the queue is serviced by the fair queueing process. When the maximum packet threshold (defined by default or using the command queue-limit) for the class is reached, further packets for the class are dropped. This way adjusting the queue-limit parameter you can allow a traffic class for having a higher buffer to receive packets and avoid dropping them. But, beware, do not forget that increasing buffering too much increase also latency in periods of congestion. Then, selecting the right buffer is a compromise selection. Have a look to the document Flows: how they compete for network resources where I explain this a little bit better.
The queue-limit command is invoked as follows:

Argument is simply the number of packets that should be assigned to the queue in question.
Let's see now how we can use this command to guarantee a maximum latency of 60ms @ 2000kbps in the egress router for TCP traffic going from our domain to a neighbor domain; maximum packet size will be 1500 bytes (ethernet). First, we create the class to represent this kind of TCP traffic and then we applied the bandwidth and queue-limit commands to this class. Type in your router:

Okay, one 1500-byte packet last 6ms at 2000kbps to be forwarded (2000kbps = 250000 bytes/sec; for one packet, time is 1500 bytes/250000 bytes/sec = 6ms). Then, having a queue of 10 x 1500-byte packets our maximum latency in this queue will be 60ms when traffic begins to be congested and the queue becomes full. For smaller packets latency will be always less than 60ms.
random-detect
Commands in this section are based in the famous RED queuing discipline. It is very important to have a previous reading to this document to understand better this section. random-detect has many flavours to be configured. Here we are going to concentrate in those closer to differentiated services implementation.
This command is used to change the minimum and maximum packet thresholds and drop probability in a RED queuing discipline for packets marked with an specific DSCP value.  All these terms can be studied having a look to the document indicated above where RED is explained.
For this command to be effective packets should be previously marked before entering or leaving throughout the interface where the traffic policy is applied. There are two ways of doing this: 1.- Having some kind of SLA with your neighbor domains where differentiated service implementation is allowed.  Some agreements where they previously classify and mark their packets before sending them to your domain and viceversa.  When you receive the packets they are already marked. 2.- Normally this kind of queuing discipline is implemented in core routers rather than edge routers.  Then your edge routers will be in charge of classifying and marking entering packets before being forwarded inside the domain.  In both cases, over the already marked packets and using the random-detect command you can configure different PHBs for them based on RED queuing discipline behavior.
The random-detect command (the flavor interesting for us to implement differentiated services) is invoked as follows:

The command must be entered in a single long line.
Arguments are: dscpvalue which specifies the DSCP value of the packets to be matched. It can be a number from 0 to 63 but the router accepts and it's better to use the following keywords representing the differentiated service classes:  ef, af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43;  min-threshold which represents the minimum threshold in number of packets. This value ranges from 1 to 4096 packets;  max-threshold which represents the maximum threshold in number of packets. This value ranges from min-threshold to 4096 packets; mark-probability-denominator (an optional setting) which represents the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 10 (the default value), 1 out of every 10 packets is dropped when the average queue is at the maximum threshold. The value ranges from 1 to 65536.
Because Cisco didn't assign a keyword for best-effort traffic (something like be) then I suppose we should use 0 to represent this value.
To be as practical as we can, let's suppose you have an agreement with some friend as crazy as you are and both of you are trying to implement a differentiated service implementation between your domains.  Okay, let's suppose also that after discussing things a little you agreed to recognize three different differentiated service classes; in fact, they will be: AF21 for flows that you consider yourself as being Bronze-class flows; AF11 for flows you consider as being Silver-class flows; and EF for flows you consider as being Gold-class flows.
You and your friend invest some of your precious time to study carefully the RED queuing discipline and after a conscientious analysis you decided to use the setting on the following table that you think are the best that applied to your particular case:

Next step is that you have to prepare a traffic policy in your routers to fulfill this agreement.  Okay, let's get to work, type in your router.

Ready!!  AF11, AF21 and EF marked packets will be fed to a RED queuing discipline and depending on each DS class different thresholds and marking probabilities will be applied to them.
shape
With some flows that are disrespectful first alternative is to shape them and if it doesn't work next step is policing. For example, TCP is a very good citizen and dropping one or two packets is good enough for it to understand very quickly who is the boss and adjust itself to the available bandwidth.  But some others, like UDP, need a strong hand to be controlled; in these cases shaping is the first thing we have to do.
Let's first to refresh our concepts; then:
     
  Shaping: the process of delaying packets within a traffic stream to cause it to conform to some defined traffic profile.  Shaper: a device that performs shaping.  
Fine...  Diving now into the Cisco queueing disciplines, the shape command permit us to specify an average or peak rate traffic shaping.  Let's have a look how it is used:

Where average specifies average rate shaping and peak specifies peak rate shiping.  cir specifies the commited information rate (CIR) in bits per seconds (bps).   bc is an optional parameter that specifies the Commited Burst Size (CBS) in bits and be is also an optional parameter that specifies the Excess Burst Size (EBS) in bits.
I'm not going to write more about the technical aspects of this command.  Those of you more curious can have a look here where Cisco explains very well, much better than me, the life and behavior of its child. Let's go inmediately to our router and type as follows:

Ready !! Now the udpcontrol policy limits the UDP traffic to an average of 1 Mbps.  I prefer to use the average instead of the peak flavor of the command.  You know, squeeze my neck but let me breath. Some peaks always are present and there are indispensable to go right.  Then, our mainly interest is to control the average throughput and this is just what we did.
set ip dscp
It's time for a command to convert our router in a marker device; just remember RFC 2475 (did you read the DS theory?):
 
Marking: the process of setting the DS codepoint in a packet based on defined rules; pre-marking, re-marking.
Marker: a device that performs marking.
Pre-mark: to set the DS codepoint of a packet prior to entry into a downstream DS domain.
Re-mark: to change the DS codepoint of a packet, usually performed by a marker in accordance with a TCA.
 
A very important feature to implement DS domains.  Cisco did this process very, very simple for us. Just create a traffic class to identify packets to be marked, then assign the class to a policy-map and apply the set ip dscp command and it's over.
It's a pitty they didn't include reserved words for all DS classes, just only for EF, AF11 and AF12 classes. Why?  Ask them, I really don't know why.
The command, when applied, mark a packet by setting its DSCP.  Let's see a description of the command:

Ohh Cisco... ohh Pancho..  You don't know how much I love you!!  Have a look somewhere in this humble site all you have to do to do the same thing you are doing in just one line but using Linux and you will begin to love yourself as much as I love you !!!
ip-dscp-value is a number from 0 to 63 that sets the IP DSCP value. Reserved keywords EF (expedited forwarding), AF11 (assured forwarding class AF11), and AF12 (assured forwarding class AF12) can be specified instead of numeric values. Cisco dixit.  No reserved words for the rest of DS classes. Then to use them you have to go to the DS table and make your hex to decimal conversions.
Time to type; just in your router write as follows:

Ready...  policy-map udpmarking marks all UDP packets with the EF DSCP. Let's have a bear. See you next week.
set mpls experimental
When you use MPLS to route your traffic and at the same time you are enough bold to want DiffServ too it is not possible to use the DSCP field in packets because they are encapsulated by MPLS to include an special piece of information called "mpls label".  Those of you interested in this exciting field of networking can begin this long trip by having a read to my Some MPLS related notes in this site. There is over here a very simple explanation, but very complete too, about what MPLS is and how it works.
An MPLS label is a 32 bits piece of information inserted by the router between Layer 2 and Layer 3 of the packet's IP header.  A sequence of diagrams is better to ilustrate this; this is the original packet's IP header with no label:

After the router insert the label we have something like this:

And the MPLS label is something like this:

The label is really the 20 rightmost bits.  There is a very interesting field just to the left called "Experimental" or simply EXP for the buddies, having 3 bits long.  This field, having 3 bits, permit us to map up to 8 different integers (0-7) and why not to associate them with 8 classes, and better enough, with 8 different DS classes?
Of course, DS classes are more than eight but because it's better hurt than dead we can select eight (what we want) and map them to this field.  For example, we could imagine:

Nice, isn't it?  We use 0 for BE to avoid touching best effort traffic packets.
Now let's talk about the command.  This command, when applied, mark a MPLS packet by setting its EXP field  Let's see a description of the command:

Very easy!!  value is a number from 0 to 7 that sets the EXP field value.
 
Okay... let's suppose that our neighbor and us have implemented DS domains.  But because we have more money than they have we have implemented MPLS too.  But we want to work with DS to continue our SLA with the neighbor.  Then, what to do?  Very simple; first we have to agree with them to forward 8 classes; for example, like the Table 4 above.  Then our edge routers are going to receive DS marked packets and they will be in charge to inject them into our domain but using MPLS.  When switching the EXP field will be marked using the Table 4 mapping above.
 
Well, let's first define our DS classes, then type in your router:
 

 
These classes match entering DS marked packets from our neighbor.
 
Now the policy-map to mark the packets accordingly; type in your router:
 
   

Ready!!  Based on the DSCP each packet will be marked in its EXP field using our mapping above.
 

 
Previous

Content  

Next