Required Pieces of a CoS Configuration
Class of Service (CoS) is how you control jitter and delay in your network. The basic idea behind CoS is that you examine traffic entering your network to determine what type of traffic it is. Once you know the type of traffic (voice traffic, data traffic, traffic tied to a particular customer, and so on), you can mark that traffic at the packet layer accordingly.
As those packets flow through your network, each router can then identify the traffic and make decisions on how to handle it based on its type. In this manner, all of your delay-sensitive traffic can be forwarded faster, or your critical traffic may be less likely to be dropped in times of congestion.
This will give you an idea of what pieces are required within a CoS configuration so you have a big picture in mind as you read more detail about each component. Let’s start with a few definitions:
Jitter is the variation in delay over time. The primary contributor to jitter is the variability of queuing/scheduling delay over time.
Propagation delay is the time it takes for signals to traverse a link — basically the speed of light.
Switching delay is the time difference between receiving a packet on an incoming interface and the queuing of the packet in the scheduler of its outbound interface.
Serialization delay is the time taken to clock a packet onto a link.
Scheduling/queuing delay is the time difference between enqueueing the packet of the outbound interface scheduler and the start of clocking the packet onto the outbound link.
Now let’s look at the different components that make up a CoS implementation on a Junos OS router.
Here is what each component does:
Classifier. A classifier examines incoming traffic and assigns a forwarding class and loss priority based on one or more fields in the packet header. These forwarding classes are then assigned to input queues.
Policers. Input policers ensure that the incoming bandwidth for each traffic flow is within its configured constraints. If a particular traffic flow exceeds its allocated bandwidth, the router can drop the packets within the flow or mark it such that it’s eligible to be discarded should congestion occur.
If a traffic flow violates the bandwidth set for it, everything that is in violation does not go into another queue, because this practice could lead to out-of-order packets. Instead, you have the option to drop the traffic or tag it so that it can be dropped, if necessary.
Scheduler. On the outbound side of the equation, flows are assigned to output queues. These queues are serviced by the router based on how they’re mapped to a scheduler. The scheduler basically dictates which queues get preferential treatment and which queues are forced to wait before they’re serviced.
Drop profile. As these queues fill up, they may still overflow. If a queue overflows, packets are dropped as per the configured drop profile.
Router rewrite. When the packet is ready to exit the router and head to the next hop along the way to its destination, the router can rewrite the bits in the header associated with CoS so that the next router can examine the header and process the packet based on a new set of CoS rules.