Bonus Class of Service

A JNCIS EXAM OBJECTIVES COVERED IN

THIS CHAPTER:

Identify CoS related functions

Describe methods used to apply CoS parameters to IP traffic

Describe methods used to apply CoS parameters to
MPLS traffic

Define the queuing strategies implemented on a Juniper
Networks router

List the steps involved in configuring a class of service
network
 In this chapter, we briefly examine some concepts surrounding
class of service (CoS) and its application within the JUNOS soft-
ware. We begin with an overview of what CoS actually is and how
to approach the topic. We then discuss some common terminology used in a CoS network and
explore how we associate these abstract concepts with actual data packets. We conclude the
chapter with an examination of how the JUNOS software implements class of service. This dis-
cussion centers around which router components perform specific functions as well as the con-
figuration of the router that accomplishes our CoS administrative goals.

Class of Service Overview

Many network engineers have differing definitions and thoughts when it comes to CoS which,
unfortunately for us, are usually correct. This arises from the fact that many functions and net-
work controls can make use of CoS technologies. For example, an Internet service provider (ISP)
might wish to offer various levels of throughput and packet loss to its customers. This can be
supported through a CoS configuration. In addition, the transport of voice or video traffic
across the network often prompts ISPs to deploy CoS throughout the network. When discussing
CoS in a network, it is important to consider the scope and operation of the configurations. For
example, there is often a macro as well as a micro view of the network.
Figure A.1 shows an ISP network that is deploying a CoS configuration. From a high-level
macro view, the network requires an examination of the traffic entering at the edge from cus-
tomer and peer networks. The edge routers then classify the traffic into defined service groups,
which allow for the special treatment of traffic across the network. For example, voice traffic
may be sent across certain links, whereas data traffic uses other links. In addition, the data traf-
fic streams may be serviced differently along the network path to ensure that higher-paying cus-
tomers receive the service they are paying for. As the traffic leaves the network at the far edge,
the ISP has the option of reclassifying the traffic or leaving it alone.

FIGURE A.1 CoS macro viewpoint

ISP Network
 Terminology 3

FIGURE A.2 CoS micro viewpoint

Sherry Chianti Merlot Chardonnay

Each router in the network needs to be configured to support this macro CoS environment.
This generally requires each router to examine the packets that enter it to determine their par-
ticular CoS settings. These settings then dictate which packets are first transmitted to the next
downstream router. In addition, the routers at the edges of the network also may be required
to alter the CoS settings of the packets that enter the network from the customers or peers.
Figure A.2 shows this micro view of the network, where the Sherry router is receiving traffic
from a customer network. As each packet enters the router, Sherry examines its current CoS set-
tings and classifies the traffic into one of the groupings defined by the ISP. This definition allows
Sherry to prioritize its resources for servicing the traffic streams it’s receiving. In addition, Sherry
may alter the CoS settings of the packets to better match the ISP’s traffic groups. When the packets
are received by Chianti, it simply examines the CoS settings, determines the appropriate traffic
group, and processes the packet according to those settings. It then transmits the packets to the
Merlot router, which performs the same actions. The last router in the path, Chardonnay, also
examines the packets and determines the appropriate group. Because it sits at the far end of the
network, the ISP may decide to once again alter the CoS settings of the packets before Chardonnay
transmits them to the neighboring network.

Terminology
As with all networking topics, we have specialized terms that we use to discuss CoS. Some of these
terms are used directly within the JUNOS software, whereas others are referred to by different
names. In this section, we focus solely on the major terminology. We discuss references to specific
JUNOS software nomenclature in the “Class of Service Associations” section later in the chapter.
Classification Classification refers to the examination of an incoming packet. This function
often associates the packet with a particular CoS servicing level.
Behavior aggregate A behavior aggregate (BA) is a method of classification that operates on
a packet as it enters the router. The packet header contents are examined, and this single field
determines the CoS settings applied to the packet.
Multi-field classifier A multi-field (MF) classifier is a second method for classifying traffic
flows. Unlike a behavior aggregate, an MF classifier has the ability to examine multiple fields
in the packet for applying CoS settings. Examples of some fields that an MF classifier may
examine include the source and destination address of the packet as well as the source and des-
tination port numbers of the packet.
4 Bonus A  Class of Service

Queuing After a packet is sent to the outgoing interface on a router, it is queued for transmission
on the physical media. The amount of time a packet is queued on the router is determined by the
availability of the outgoing physical media as well as the amount of traffic using the interface.
Scheduling An individual router interface may have multiple queues assigned to store packets. The
router then decides which queue to service based on a particular method of scheduling. This process
often involves a determination of which type of packet should be transmitted before another.
Rewrite Rules A rewrite rule sets the appropriate CoS bits in the outgoing packet. This allows
the next downstream router to classify the packet into the appropriate service group.

Classifying the Packets

The classification of incoming packets and their assignment into an appropriate traffic group is
a critical step in applying CoS concepts to a network. The question then becomes, “How do we
actually do this?” The answer lies in the headers of the packets we receive on an interface. Both
IPv4 and MPLS packets have special bits set aside in the header for carrying CoS settings.

Internet Protocol Version 4

Within the header of an IPv4 packet lies a type-of-service byte, which was originally designed
to support CoS networks. The three most significant bits in this field, bits 5 through 7, are used
by routers to classify IPv4 traffic. These IP precedence bits provide eight levels of service for net-
work routers to locate packets and perform specific services upon them. It is these bits that the
JUNOS software uses, by default, to support CoS.
Of course, some administrators feel that providing eight levels of service is not adequate in
today’s networking environment. To that end, new standards provide for 64 levels of service by
using the six most significant bits instead of just three. In addition, several of the bit combina-
tions are predefined and allow network providers and customers alike to utilize their services.
These new standards are collectively known as Diff-Serv Code Points (DSCP). The JUNOS soft-
ware supports the use of DSCP for classifying and servicing IPv4 traffic.

Multiprotocol Label Switching

The use of MPLS in a network today is quite widespread. Whether it supports virtual private net-
works (VPNs) or traffic engineering, IPv4 packets are placed in a label-switched path and forwarded
across the provider network. During this process, the packet is forwarded only using MPLS labels.
More important, the embedded IPv4 packet header is not consulted by the network routers. Clearly,
setting the IP precedence bits in the IP header won’t help the MPLS routers perform CoS in the net-
work. Luckily, the MPLS header itself has some bit positions available for use with CoS.
Technically speaking, each MPLS header has three bits set aside for experimental use. These EXP
bits, however, are commonly used by router vendors to support CoS networking. The JUNOS soft-
ware is no exception to this rule and uses the EXP bits in the MPLS header in a very similar manner
to the IP precedence bits in the IPv4 header.
 JUNOS Software Implementation 5

JUNOS Software Implementation

When discussing CoS within the JUNOS software, we need to keep several important things
in mind. The first involves the components of the Packet Forwarding Engine and what func-
tions they perform on a packet. The second revolves around which CoS functions are avail-
able at each step in the packet’s flow through the router. Finally, we need to actually
configure the router to implement the desired behavior. Let’s see how each issue interacts
with the others.

Packet Flow
When a packet enters an M-series Juniper Networks router, the Physical Interface Connector
(PIC) receiving the packet retrieves it from the network and verifies that the link-layer infor-
mation is valid. The packet is then passed to the Flexible PIC Concentrator (FPC), where the
data-link and network layer information is verified. In addition, the FPC is responsible for
segmenting the packet into 64-byte J-cells. These cells are then written into packet storage
memory while a notification cell is sent to the route lookup engine. The destination address
listed in the notification cell is located in the forwarding table, and the next hop of the packet
is written into the result cell. This result cell is queued on the appropriate outbound FPC until
the outgoing interface is ready to transmit the packet. The FPC then reads the J-cells out of
memory, reforms the original packet, and sends the packet to the outgoing PIC, where it is
transmitted back into the network.

Please consult the JNCIA Study Guide for complete details on packet flow
within a Juniper Networks router.

Class of Service Associations

CoS actions are performed in three main locations in a Juniper Networks router: the incoming
I/O Manager ASIC, the Internet Processor ASIC, and the outgoing I/O Manager ASIC. Let’s see
what functionality each of these locations provides to us.

Incoming I/O Manager ASIC

When a data packet is passed from the receiving interface to its connected FPC, it is received by
the I/O Manager ASIC on that specific FPC. During the processing of the packet by this ASIC,
the information in the packet’s header is examined by a behavior aggregate classifier. This clas-
sification action associates the packet with a particular forwarding class. In addition, the value
of the packet’s loss priority bit is set by this classifier. Both the forwarding class and loss priority
information are placed into the notification cell, which is then transmitted to the Internet Pro-
cessor ASIC.
6 Bonus A  Class of Service

Some interface types have the ability to perform token bucket rate limiting on
the PIC itself. In this situation, this algorithm can set the packet’s loss priority bit
before the packet is sent to the Incoming I/O Manager ASIC.

Internet Processor ASIC

The Internet Processor ASIC receives notification cells representing inbound data packets and
performs route lookups in the forwarding table. This lookup determines the outgoing inter-
face on the router and the next-hop IP address for the data packet. While the packet is being
processed by the Internet Processor ASIC, it may also be evaluated by a firewall filter, which
is configured on either the incoming or outgoing interface. This filter can perform the func-
tions of an MF classifier by matching on multiple elements within the packet and overwriting
the forwarding class and/or loss priority settings within the notification cell. Once the route
lookup and filter evaluations are complete, the notification cell, now called the result cell, is
passed to the I/O manager ASIC on the FPC associated with the outgoing interface.

Outgoing I/O Manager ASIC

When the result cell is received by the I/O Manager ASIC, it is placed into a queue to await trans-
mission on the physical media. The specific queue used by the ASIC is determined by the forwarding
class associated with the data packet. The configuration of the queue itself helps determine the ser-
vice the packet receives while in this queued state. This functionality guarantees that certain packets
deemed important by the network administrator be serviced and transmitted before other less
important packets. In addition, the queue settings and the packet’s loss priority setting determine
which packets may be dropped from the network during periods of congestion and contention.
In addition to queuing the packet, the outgoing I/O manager ASIC is responsible for ensuring
that CoS bits in the packet’s header are correctly set before it is transmitted. This rewrite func-
tion helps the next downstream router perform its CoS function in the network.

Class of Service Configuration

The final component in implementing CoS in a network is actually configuring the routers to sup-
port it. Within the JUNOS software, multiple CoS configuration pieces exist that can be combined
in various ways by the particular network administrator. This abstraction gives the administrator
ultimate control over the router’s functionality to support a CoS network. As we discuss these
individual pieces, we’ll attempt to follow the logical flow of the packet through the router.

FIGURE A.3 A sample CoS network

Chianti Merlot Chardonnay

192.168.20.1 192.168.40.1 192.168.32.1
 JUNOS Software Implementation 7

Figure A.3 shows three routers in a sample network supporting CoS. The Chianti router is
transmitting data packets to Chardonnay using Merlot as a transit router. We’ll be configuring
Merlot to support CoS throughout this section.

Defining Code Points

The JUNOS software allows us to define a code point, which maps a user-friendly name to a
particular set of bit values. This mapping means that our CoS configurations no longer have to
reference the IP precedence bits as 000 but rather as be. In short, we can define names that mean
something to the service in question.
By default, the software contains some predefined code-point values. For IP precedence traf-
fic, these code points include the following:

user@Merlot> show class-of-service code-point-aliases inet-precedence

Code point type: inet-precedence
Alias Bit pattern
af11 001
af21 010
af31 011
af41 100
be 000
cs6 110
cs7 111
ef 101
nc1 110
nc2 111

Within the [edit class-of-service code-point-aliases] configuration hierarchy,

we can define new names for the existing values. In this situation, the newly defined names are
added to the list of default names. On the Merlot router, we define four new code-point aliases
for IP precedence traffic:

user@Merlot> show configuration class-of-service code-point-aliases

inet-precedence {
best-effort 000;
gold 010;
platinum 100;
network-control 110;
}

We can then see these new aliases in the list of defined code points:

user@Merlot> show class-of-service code-point-aliases inet-precedence

Code point type: inet-precedence
8 Bonus A  Class of Service

Alias Bit pattern

af11 001
af21 010
af31 011
af41 100
be 000
best-effort 000
cs6 110
cs7 111
ef 101
gold 010
nc1 110
nc2 111
network-control 110
platinum 100

Forwarding Classes
We have a second CoS configuration tool that we’ll use in multiple places in our configuration.
The forwarding class is referenced in both a classifier and a rewrite rule. In addition, the for-
warding classes are closely aligned with the operation and definitions of the router’s queues. As
such, their creation within the [edit class-of-service forwarding-classes] allocates
the classes to individual queue numbers on the router’s interfaces:

user@Merlot> show configuration class-of-service forwarding-classes

queue 0 best-effort;
queue 1 gold;
queue 2 platinum;
queue 3 network-control;

Behavior Aggregate Classifiers

The function of a behavior aggregate classifier is the examination of the CoS bits in the packet
header and the assignment of that packet to a specific level of service. Within the confines of the
JUNOS software, this means that the classifier should assign a forwarding class to the packet
as well as set the packet’s loss priority value to high or low.
By default, the JUNOS software uses a classifier called ipprec-compatability on all of the
router’s interfaces. We can use the show class-of-service interface command to verify
this default on Merlot’s interface with Chianti:

user@Merlot> show class-of-service interface so-0/1/0

Physical interface: so-0/1/0, Index: 129
Scheduler map: <default>, Index: 1
 JUNOS Software Implementation 9

Logical interface: so-0/1/0.0, Index: 67

Object Name Type Index
Rewrite exp-default exp 2
Classifier ipprec-compatibility ip 5

The show class-of-service classifier command displays the contents of the default
IP precedence classifier. We see that the majority of bit combinations assign packets to the
best-effort forwarding class while assigning a high or low loss priority value:

user@Merlot> show class-of-service classifier type inet-precedence

Classifier: ipprec-default, Code point type: inet-precedence, Index: 4
Code point Forwarding class Loss priority
000 best-effort low
001 assured-forwarding low
010 best-effort low
011 best-effort low
100 best-effort low
101 expedited-forwarding low
110 network-control low
111 network-control high

Classifier: ipprec-compatibility, Code point type: inet-precedence, Index: 5

Code point Forwarding class Loss priority
000 best-effort low
001 best-effort high
010 best-effort low
011 best-effort high
100 best-effort low
101 best-effort high
110 network-control low
111 network-control high

The administrators of the network in Figure A.3 would like to support the best-effort,
gold, platinum, and network-control traffic classes in their network. These inbound code-
point aliases are correlated with their appropriate forwarding classes and loss priorities in the
newly defined classifier called sample-cos-classifier:

user@Merlot> show class-of-service classifier name sample-cos-classifier

Classifier: sample-cos-classifier, Code point type: inet-precedence, Index:
22826
Code point Forwarding class Loss priority
000 best-effort high
10 Bonus A  Class of Service

010 gold high

100 platinum low
110 network-control low

Much like a routing policy, our newly defined classifier must be applied to the appropriate
interfaces before it can perform its functions. After first verifying that the classifier is not oper-
ational, we apply it to the so-0/1/0.0 interface and commit our configuration:

[edit class-of-service interfaces so-0/1/0 unit 0]

user@Merlot# run show class-of-service interface so-0/1/0
Physical interface: so-0/1/0, Index: 129
Scheduler map: <default>, Index: 1

Logical interface: so-0/1/0.0, Index: 67

Object Name Type Index
Rewrite exp-default exp 2
Classifier ipprec-compatibility ip 5

[edit class-of-service interfaces so-0/1/0 unit 0]

user@Merlot# set classifiers inet-precedence sample-cos-classifier

[edit class-of-service interfaces so-0/1/0 unit 0]

user@Merlot# commit and-quit
commit complete
Exiting configuration mode

user@Merlot> show class-of-service interface so-0/1/0

Physical interface: so-0/1/0, Index: 129
Scheduler map: <default>, Index: 1

Logical interface: so-0/1/0.0, Index: 67

Object Name Type Index
Rewrite exp-default exp 2
Classifier sample-cos-classifier ip 22826

Multi-Field Classifiers
Within the JUNOS software, you utilize the functionality of a firewall filter to implement an MF
classifier. This gives you the ability to use any filter match criteria to locate packets that require
further classification. Once the packets are located, you alter the forwarding class or loss priority
settings by using the action statements of then forwarding-class or then loss-priority,
respectively.
 JUNOS Software Implementation 11

In the “Behavior Aggregate Classifiers” section earlier, we created a classifier called sample-
cos-classifier. This classifier assigns all IP packets whose precedence bits arrive as 010 to
the gold forwarding class. However, the network administrators of the network in Figure A.3
would like to ensure that all packets destined for the 10.10.10.0 /24 network are placed into the
platinum forwarding class. This assignment should occur regardless of the received bit values
in the packet. To accomplish this administrative goal, we create a firewall filter called set-FC-
to-gold, which looks like this:

user@Merlot> show configuration firewall

filter set-FC-to-gold {
term match-a-single-route {
from {
destination-address {
10.10.10.0/24;
}
}
then {
forwarding-class platinum;
accept;
}
}
term accept-all {
then accept;
}
}

The filter is applied in an inbound direction on the so-0/1/0 interface, which connects to the
Chianti router:

user@Merlot> show interfaces filters

Interface Admin Link Proto Input Filter Output Filter
so-0/1/0 up up
so-0/1/0.0 up up inet set-FC-to-gold
so-0/1/1 up up
so-0/1/1.0 up up inet
so-0/1/2 up up
so-0/1/2.0 up up inet
so-0/1/3 up up
dsc up up
fxp0 up up
fxp0.0 up up inet
fxp1 up up
12 Bonus A  Class of Service

fxp1.0 up up tnp
gre up up
ipip up up
lo0 up up
lo0.0 up up inet
lo0.16383 up up inet
lsi up up
mtun up up
pimd up up
pime up up
tap up up

This now assigns a forwarding class of platinum to all packets that are received on that
interface and are destined for the 10.10.10.0 /24 subnet.

Output Queues
Once the Internet Processor ASIC performs its route lookup, the result cell is passed to the I/O
manager ASIC on the outgoing FPC, where it is queued for transmission on the physical media.
Multiple functions and configuration options are associated with output queuing within the
JUNOS software. These include drop profiles, schedulers, and servicing of the queue itself.

Drop Profiles
A drop profile is the most basic building block of implementing a random early discard (RED)
configuration. Simply put, the drop profile defines parameters that allow the packet to be
dropped from the network. The two main portions of the drop profile are the queue fullness and
the drop probability.

We discuss RED in greater detail in the “Queue Servicing” section later in

the chapter.

The queue fullness represents a percentage of the memory used to store result cells in relation
to the total amount that has been allocated for that specific queue. Only the result cells sent by
the Internet Processor ASIC are stored in this queue memory. In a similar manner, the drop
probability is a percentage value that correlates to the likelihood that an individual packet is
dropped from the network. These two variables are combined in a graph-like format, which
is represented in Figure A.4.
In Figure A.4, we see both a segmented and an interpolated graph. Although the formation
of these graph lines is quite different, the application of the profile is the same. When a packet
reaches the head of the queue, a random number between 0 and 100 percent is calculated by the
router. This random number is plotted against the drop profile using the current queue fullness
of that particular queue. When the random number falls above the graph line, the packet is
transmitted onto the physical media, but when the number falls below the line, it is dropped
from the network.
 JUNOS Software Implementation 13

FIGURE A.4 Drop profiles

Segmented Interpolated
100 100
Transmit Transmit
Drop Probability (%)

Drop Probability (%)

75 75

50 50

25 25
Drop Drop

0 25 50 75 100 0 25 50 75 100
Fullness (%) Fullness (%)

We create drop profiles within the [edit class-of-service drop-profiles] configu-

ration hierarchy level. By defining multiple fill levels and drop probabilities, we create a seg-
mented drop profile. The following configuration from the Chardonnay router is used to create
the segmented profile in Figure A.4:

user@Chardonnay> show configuration class-of-service drop-profiles

segmented-style-profile {
fill-level 25 drop-probability 25;
fill-level 50 drop-probability 50;
fill-level 75 drop-probability 75;
fill-level 95 drop-probability 100;
}

To actually create the profile’s graph line, the router begins at the bottommost corner rep-
resenting a 0 percent fill level and a 0 percent drop probability. It begins drawing a line directly
to the right until it reaches the first defined fill level, 25 percent in our case. The router then con-
tinues the line directly vertical until the first drop probability is reached. This process is repeated
for all of the defined levels and probabilities until the top-right corner of the graph is reached.
This type of profile provides a very rigid graph line.
On the other hand, we also have the ability to create a smoother graph line by configuring
the profile with the interpolate command. This allows the router to automatically generate
64 data points on the graph beginning at (0, 0) and ending at (100, 100). Along the way, the
graph line intersects specific data points, which we define like this:

user@Chianti> show configuration class-of-service drop-profiles

interpolated-style-profile {
interpolate {
fill-level [ 50 75 ];
drop-probability [ 25 50 ];
}
}
14 Bonus A  Class of Service

The values defined in the configuration are matched together to represent the data points in the
graph line. In our example, we have a drop probability of 25 percent when the queue is 50 percent
full. Likewise, the drop probability increases to 50 percent when the queue is 75 percent full.

The JUNOS software default drop profile begins with a drop probability of
0 percent when the queue is 0 percent full. The profile then plots a drop prob-
ability of 100 percent when the queue is 100 percent full. This profile transmits
all packets until the queue is full. In essence, packets are tail dropped from the
network—they are not placed into the queue at all.

For the purposes of our sample network in Figure A.3, we define two interpolated drop pro-
files called high-drop and low-drop. The configuration of the Merlot router then appears as:

user@Merlot> show configuration class-of-service drop-profiles

high-drop {
interpolate {
fill-level [ 25 50 ];
drop-probability [ 50 90 ];
}
}
low-drop {
interpolate {
fill-level [ 75 95 ];
drop-probability [ 10 40 ];
}
}

While we won’t be creating the drop profile graphs for this configuration, feel
free to draw it on your own to ensure that you accurately grasp the concept.

Much like routing policies, drop profiles are not used until they are applied someplace. Within
a CoS environment the profiles are assigned to a scheduler by a drop profile map, which contains
all of the properties of an individual queue. The drop profile maps take into account the current
loss priority setting of the packet—high, low, or any. In addition, some Layer 4 information is
checked to determine if the packet is associated to tcp, non-tcp, or any forms of traffic.
For our sample network, we associate the drop profiles with the setting of the loss priority
value as so:

user@Merlot> show configuration class-of-service schedulers

best-effort {
drop-profile-map loss-priority low protocol any drop-profile low-drop;
drop-profile-map loss-priority high protocol any drop-profile high-drop;
}
 JUNOS Software Implementation 15

Schedulers
You may have noticed that the drop profile map we used in the previous section was applied to
a piece of configuration called a scheduler. This was no random mistake. The JUNOS software
uses schedulers to define the properties of an individual queue. These include the amount of
interface bandwidth assigned to the queue, the size of the memory buffer allocated for storing
result cells, the priority of the queue, and the drop profiles associated with the queue. Since
we’ve already discussed drop profiles, let’s examine the other attributes at this point.
Each queue is allocated some portion of the bandwidth of the outgoing interface. This band-
width amount can be a hard value, such as 1Mbps, a percentage of the total available bandwidth,
or the rest of the available bandwidth. This variable provides you the control to guarantee that
each queue receives the amount of bandwidth appropriate to its level of service. The best-effort
scheduler on the Merlot router is assigned to use the remainder of the bandwidth on any interface
it is assigned to:

user@Merlot> show configuration class-of-service schedulers

best-effort {
transmit-rate remainder;
drop-profile-map loss-priority low protocol any drop-profile low-drop;
drop-profile-map loss-priority high protocol any drop-profile high-drop;
}

The transmit-rate command correlates the queue bandwidth to the particular scheduler.
By default, each individual queue may burst outside of its defined bandwidth, provided extra
bandwidth is available on the interface. You may limit this default behavior through the addi-
tion of the exact option within the transmit-rate. This strictly limits the queue to just the
bandwidth allocated to it. We now create a network-control scheduler on Merlot, which sets
a strict rate limit of 1Mbps:

user@Merlot> show configuration class-of-service schedulers

best-effort {
transmit-rate remainder;
drop-profile-map loss-priority low protocol any drop-profile low-drop;
drop-profile-map loss-priority high protocol any drop-profile high-drop;
}
network-control {
transmit-rate 1m exact;
}

For the sake of completeness, we also create gold and platinum schedulers and assign them
bandwidth limits:

user@Merlot> show configuration class-of-service schedulers

best-effort {
transmit-rate remainder;
16 Bonus A  Class of Service

drop-profile-map loss-priority low protocol any drop-profile low-drop;

drop-profile-map loss-priority high protocol any drop-profile high-drop;
}
network-control {
transmit-rate 1m exact;
}
gold {
transmit-rate percent 15;
}
platinum {
transmit-rate percent 25;
}

The second attribute we can assign to a scheduler is the amount of memory buffer allocated
to store and queue the result cells. This is configured using the buffer-size command. One
method for setting the buffer size is defining a percentage of the total memory space allocated
on the outgoing FPC. A second method involves setting a time value, expressed in microseconds,
which represents the longest amount of time an individual packet should be queued.

Setting larger values for the buffer-size means a greater possibility exists for
delaying packets in the network. This may not be useful for sensitive traffic such
as voice or video. By default, the buffer-size setting is equal to the transmit-
rate. In fact, this type of configuration is recommended.

Each of the schedulers defined on the Merlot router is now assigned some amount of buffer
space for queuing result cells:

user@Merlot> show configuration class-of-service schedulers

best-effort {
transmit-rate remainder;
buffer-size remainder;
drop-profile-map loss-priority low protocol any drop-profile low-drop;
drop-profile-map loss-priority high protocol any drop-profile high-drop;
}
network-control {
transmit-rate 1m exact;
buffer-size percent 5;
}
gold {
transmit-rate percent 15;
buffer-size percent 50;
}
 JUNOS Software Implementation 17

platinum {
transmit-rate percent 25;
buffer-size temporal 200;
}

The third scheduler attribute is the priority of the queue itself. This allows the JUNOS soft-
ware to service certain high-priority queues before low-priority queues. We define this value
using the priority command within the scheduler. For completeness, we also assign our drop
profiles to each scheduler:

user@Merlot> show configuration class-of-service schedulers

best-effort {
transmit-rate remainder;
buffer-size remainder;
priority low;
drop-profile-map loss-priority low protocol any drop-profile low-drop;
drop-profile-map loss-priority high protocol any drop-profile high-drop;
}
network-control {
transmit-rate 1m exact;
buffer-size percent 5;
priority high;
drop-profile-map loss-priority low protocol any drop-profile low-drop;
drop-profile-map loss-priority high protocol any drop-profile high-drop;
}
gold {
transmit-rate percent 15;
buffer-size percent 50;
priority low;
drop-profile-map loss-priority low protocol any drop-profile low-drop;
drop-profile-map loss-priority high protocol any drop-profile high-drop;
}
platinum {
transmit-rate percent 25;
buffer-size temporal 200;
priority high;
drop-profile-map loss-priority low protocol any drop-profile low-drop;
drop-profile-map loss-priority high protocol any drop-profile high-drop;
}

Now that we’ve created our individual schedulers, we need to associate them with an out-
going interface as well as a forwarding class. These two separate steps both use a scheduler map
within the configuration. We first build the scheduler map, which matches a forwarding class
18 Bonus A  Class of Service

to a scheduler. This is a critical step in the configuration process since the forwarding class is
already assigned a queue number and the scheduler contains the parameters that queue should
use. Because we’ve conveniently named our forwarding classes and schedulers identically, we
now combine them in a scheduler map called sample-cos-scheduler-map:

user@Merlot> show configuration class-of-service scheduler-maps

sample-cos-scheduler-map {
forwarding-class best-effort scheduler best-effort;
forwarding-class gold scheduler gold;
forwarding-class platinum scheduler platinum;
forwarding-class network-control scheduler network-control;
}

The final step of our configuration is the association of the scheduler map to the outgoing
interface on the router. In our case, the so-0/1/2.0 interface connects Merlot to Chardonnay:

user@Merlot> show configuration class-of-service interfaces

so-0/1/0 {
unit 0 {
classifiers {
inet-precedence sample-cos-classifier;
}
}
}
so-0/1/2 {
scheduler-map sample-cos-scheduler-map;
}

user@Merlot> show class-of-service interface so-0/1/2

Physical interface: so-0/1/2, Index: 131
Scheduler map: sample-cos-scheduler-map, Index: 22802

Logical interface: so-0/1/2.0, Index: 69

Object Name Type Index
Rewrite exp-default exp 2
Classifier ipprec-compatibility ip 5

Queue Servicing
Given a large enough traffic load, each individual queue may experience a period of congestion
where the number of result cells queued is greater than the ability of the router to empty the
queue. In this environment, each queue requires a method for determining which result cells
should be dropped from the network. The JUNOS software provides the option of enabling ran-
dom early discard (RED) on the individual queues.
 JUNOS Software Implementation 19

The JUNOS software doesn’t supply an explicit command to enable RED. Rather, the appli-
cation of a drop profile to a scheduler turns on this functionality. Once RED is operational on
an interface, the queue no longer drops result cells from the tail of the queue. Rather, cells are
dropped after they reach the head of the queue. At this point, the router generates a random
number to plot against the drop profile graph. This ultimately determines if the result cell is
dropped from the network or transmitted out the physical interface.
While RED operates efficiently within a single queue, we need another mechanism to ensure
that queues containing important traffic are provided better access to the outgoing interface.
This is accomplished through a procedure of priority queuing, in which the router examines the
priority of the queue. In addition, the router determines if the individual queue is within its
defined bandwidth profile. This binary decision, which is reevaluated on a regular time cycle,
compares the amount of data transmitted by the queue against the amount of bandwidth allo-
cated to it by the scheduler. When the transmitted amount is less than the allocated amount, the
queue is considered to be in profile. A queue is out of profile when its transmitted amount is
larger than its allocated amount.
The JUNOS software performs priority queuing using the following steps:
1. The router first locates all high-priority queues that are currently in profile. These queues
are serviced first in a weighted round-robin fashion.
2. The router then locates all low-priority queues that are currently in profile. These queues
are also serviced using a weighted round-robin scheme.
3. The router then locates all high-priority queues that are currently out of profile and that are
not rate limited. The weighted round-robin algorithm is applied to these queues for servicing.
4. The router finally locates all low-priority queues that are currently out of profile and are
also not rate limited. These queues are serviced last in a weighted round-robin manner.

Rewrite Rules
The final CoS action taken on a packet within a Juniper Networks router is the application of a
rewrite rule. These rules are applied after the data packet is reassembled by the I/O Manager ASIC
on the outgoing FPC and set the value of the CoS bits within the packet’s header. The specific bit
settings are determined by the packet’s forwarding class and loss priority setting. In effect, it per-
forms the opposite function of the behavior aggregate classifier used as the packet enters the
router. In fact, the configuration is extremely similar:

user@Merlot> show configuration class-of-service rewrite-rules

inet-precedence sample-cos-rewrite-rule {
forwarding-class best-effort {
loss-priority high code-point best-effort;
}
forwarding-class gold {
loss-priority high code-point gold;
}
20 Bonus A  Class of Service

forwarding-class platinum {
loss-priority low code-point platinum;
}
forwarding-class network-control {
loss-priority low code-point network-control;
}
}

As an example of how the rewrite rules work, the sample-cos-rewrite-rule we’ve

created on Merlot places the code point of best-effort (000) into all packets whose for-
warding class is best-effort and whose loss priority is set to high. As we saw with the
classifiers, we need to apply our rewrite rule to the outgoing interface on the router. Since
we’re concerned about traffic leaving Merlot to Chardonnay, we apply the rule to the
so-0/1/2.0 interface:

user@Merlot> show configuration class-of-service interfaces

so-0/1/0 {
unit 0 {
classifiers {
inet-precedence sample-cos-classifier;
}
}
}
so-0/1/2 {
scheduler-map sample-cos-scheduler-map;
unit 0 {
rewrite-rules {
inet-precedence sample-cos-rewrite-rule;
}
}
}

user@Merlot> show class-of-service interface so-0/1/2

Physical interface: so-0/1/2, Index: 131
Scheduler map: sample-cos-scheduler-map, Index: 22802

Logical interface: so-0/1/2.0, Index: 69

Object Name Type Index
Rewrite exp-default exp 2
Rewrite sample-cos-rewrite-rule ip 47729
Classifier ipprec-compatibility ip 5
 Exam Essentials 21

Summary
In this chapter, we spent a relatively short amount of time examining the broad topic of CoS. We
saw that a network administrator needs to view CoS from both a macro (the entire network) as
well as a micro (an individual router) point of view. We then discussed some terms commonly
used to express CoS functionality, such as classifiers, queuing, and rewrite rules. We then
explained how to locate CoS information within incoming data packets. We saw that IP packets
used a type-of-service byte and populated either three precedence bits or six Diff-Serv Code Points.
MPLS packets also carry CoS information in their header within a three-bit experimental field.
We concluded the chapter with an exploration of the JUNOS software implementation of
CoS. We saw that CoS functions closely matched the flow of a packet through the Packet For-
warding Engine. We then configured each of the CoS components using a sample network. An
individual router was assigned code points, forwarding classes, classifiers, schedulers, and
rewrite rules.

Exam Essentials
Be able to describe how individual IP data packets can be examined by a router configured
for CoS. Individual IPv4 data packets contain a type-of-service byte in their Layer 3 header.
End-user and network devices can set the three most significant bits to one of eight possible val-
ues. These precedence bits are examined by the JUNOS software by default. The six most sig-
nificant bits in this field are used to define 64 Diff-Serv Code Points.
Be able to identify the queuing methods employed by a Juniper Networks router. The
JUNOS software operates each outbound queue using a tail-drop paradigm. This prevents new
result cells from entering the queue during times of congestion. With the application of a drop
profile, queues begin dropping result cells from the head of the queue using the random early
discard (RED) algorithm. In addition, individual queues may be assigned a priority value, which
assists the router is performing priority queuing. This allows high-priority queues to be serviced
before low-priority ones.
Be able to identify the use of a classifier within a router. A CoS network uses two different
types of classifiers for assigning incoming data packets to a specific level of service. A behavior
aggregate (BA) classifier solely examines the bits in the packet’s header to make its decision. A
multi-field (MF) classifier, on the other hand, permits the administrator to use multiple match
criteria in a firewall filter to select the service level for a packet.
Be able to describe the use of a drop profile in a router. The application of a drop profile to a
queue enables RED functionality on that queue. Each individual profile contains a graph line
that correlates to the fullness of the queue and the probability that the packet will be dropped.
When a result cell is removed from the head of the queue, the router calculates a random num-
ber and plots it against the drop profile. If the number is above the graph line, the packet is
transmitted out the interface and to the network. When the value falls below the graph line,
however, the packet is dropped from the network.
22 Bonus A  Class of Service

Understand the components that are associated with a scheduler. The JUNOS software uses
a scheduler to assign properties to individual queues. These properties include the amount of
bandwidth allocated to the queue, the priority of the queue, and the drop profiles assigned to
service the queue.
Understand the functionality of a rewrite rule. Before a data packet is transmitted by the router
onto the physical media, the CoS bits in the packet’s header must be set. This is the function of a
rewrite rule. Each individual rule examines the forwarding class and loss priority of the packet
about to be transmitted and sets the bits to a value defined in the rule. This allows the next down-
stream router to perform its CoS functions accurately.
 Review Questions 23

Review Questions
1. What component in a Juniper Networks router uses a behavior aggregate classifier?
A. Incoming PIC
B. Incoming I/O Manager ASIC
C. Internet Processor ASIC
D. Outgoing I/O Manager ASIC
E. Outgoing PIC

2. What component in a Juniper Networks router implements queuing?

A. Incoming PIC
B. Incoming I/O Manager ASIC
C. Internet Processor ASIC
D. Outgoing I/O Manager ASIC

3. What component in a Juniper Networks router uses a multi-field classifier?

A. Incoming PIC
B. Incoming I/O Manager ASIC
C. Internet Processor ASIC
D. Outgoing I/O Manager ASIC
E. Outgoing PIC

4. What variable is used by a drop profile to determine whether or not to drop a packet from the
network?
A. Packet size
B. Bandwidth used by the queue
C. Fullness of the queue
D. Outgoing interface speed

5. Which JUNOS software configuration component allows the mapping of human-friendly names
to CoS bits values?
A. Forwarding class
B. Scheduler
C. Rewrite rule
D. Code-point alias
24 Bonus A  Class of Service

6. Which JUNOS software configuration component allows the router to ensure that the proper bit
values are placed in outgoing packets?
A. Forwarding class
B. Scheduler
C. Rewrite rule
D. Code-point alias

7. What queuing algorithm is enabled through the application of a drop profile?

A. Tail dropping
B. Random early discard
C. Weighed round robin
D. Head of line blocking

8. Which two sets of bits can be used by the JUNOS software to classify IPv4 traffic into the appro-
priate service class?
A. Experimental bits
B. IP precedence bits
C. Code-point aliases
D. Diff-Serv Code Points

9. Which set of bits is used by the JUNOS software to classify MPLS traffic into the appropriate
service class?
A. Experimental bits
B. IP precedence bits
C. Code-point aliases
D. Diff-Serv Code Points

10. What JUNOS software configuration component is used in both a classifier and a rewrite rule
and is closely associated with an outgoing interface queue?
A. Scheduler map
B. Drop profile
C. Forwarding class
D. Code point alias
 Answers to Review Questions 25

Answers to Review Questions

1. B. A behavior aggregate classifier examines the bits in the header of the incoming packet to
determine its level of service. Within a Juniper Networks router, this functionality most closely
matches the operation of the I/O manager ASIC on the incoming FPC.

2. D. On an M-series Juniper Networks router, all queuing functions are handled by the I/O
manager ASIC on the outgoing FPC. The ASIC queues the result cells it receives from the Inter-
net Processor ASIC.

3. C. A multi-field classifier examines multiple pieces of information from a received packet to

determine its level of service. This may include the source/destination IP addresses or the source/
destination port numbers. In a Juniper Networks router, this type of packet matching is accom-
plished in a firewall filter operating on the Internet Processor ASIC.

4. C. When the RED algorithm selects a result cell from a queue, it checks the current fullness of
that queue. This fullness is plotted against a drop profile to determine the probability of drop-
ping the packet from the network.

5. D. A code-point alias allows a network administrator to map CoS bit values to names used
throughout the [edit class-of-service] configuration hierarchy.

6. C. After a result cell is removed from a queue and permitted to be transmitted on the interface,
the I/O Manager ASIC consults any configured rewrite rules to determine the exact bit values
that should be placed in the outgoing packet.

7. B. The JUNOS software implements tail-drop queuing by default but enables random early
discard (RED) when a drop profile is configured.

8. B, D. The type-of-service byte in an IPv4 packet has two possible methods of classifying traffic.
The three most significant bits are the IP precedence bits, and the six most significant bits are the
Diff-Serv Code Points.

9. A. Technically speaking, the experimental bits in an MPLS header are just that—experimental.
However, most router vendors, including the JUNOS software, use these bits for CoS.

10. C. Each interface queue in the router is associated with a forwarding class. Incoming packets
are classified into a particular forwarding class by a behavior aggregate classifier. All packets
transmitted from the router use the current forwarding class to rewrite the appropriate CoS
bits in the header.