Junos Class of Service

LY
Chapter 2: Class of Service Overview

N
O
SE
U
AL
N
R
TE
IN
Junos Class of Service

LY
N
O
SE
U
AL

Circuit-Switched Networks
N

Historically, telecommunications networks have been based on circuit-switched technologies. In these networks, a physical
path (or dedicated time slot) is allocated to each connection. The allocation of dedicated resources to each connection
R

means that delays are small and fixed, and that congestion-related loss cannot occur. To prevent congestion, this type of
network blocks new connection attempts when insufficient resources are available for all potential users.
TE

The inherent CoS associated with a circuit-switched network is very high, because these networks were designed to support
loss-sensitive and delay-sensitive applications, such as voice.

CoS Is Not Required in Traditional Networks

IN

Designing a network around a specific application means that explicit CoS-related capabilities are not necessary. For
example, circuit-switched networks inherently provide the highest CoS levels possible because of the nature of the voice
applications that these networks were designed to support.

Chapter 2–2 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

Packet-Switched Networks
N

Packet-switched networks are designed around the concept of statistical multiplexing, which makes them very efficient for
most data communications uses. Rather than blocking new users, packet-switched networks buffer excess traffic during
R

periods of peak activity, using the principals of statistical multiplexing. The obvious drawback to this approach is that large
buffers equal potentially large queuing delays. Because no buffer is infinite, the potential for information loss due to
discarded packets during periods of chronic congestion always exists.
TE

Although a packet-switched network is extremely efficient and well adapted to most machine-to-machine applications, the
variable delays and potential for loss makes these networks problematic for real-time and loss-sensitive applications.

CoS Is Not Required

IN

Despite shortcomings, early packet-switched networks also did not require CoS, but for a different reason than
circuit-switched networks. Early packet-switched networks supported applications that could tolerate delayed or lost
packets. Guaranteed real-time delivery of packets simply was not of high importance.

www.juniper.net Class of Service Overview • Chapter 2–3

Junos Class of Service

LY
N
O
SE
U
AL

Convergence Drives the Need for Class of Service

N

The conclusion quickly became obvious that merging networks to support multiple services would be less expensive, even
though this multi-purpose network might not support any single application as efficiently as a purpose-built network.
R

As noted on the previous pages, CoS was not necessary in purpose-built networks that were only expected to support the
application for which they were built. However, in a converged network, CoS plays a critical role, because such a network is
TE

expected to be flexible in its support of a wide number of application types.

The most basic function of CoS is to simply recognize traffic from one application versus another. However, once CoS
recognizes specific application streams, going one step further and offering special handling for the data generated by one
application over another is easy.
IN

As new networks provide more open access to users, bandwidth usage also becomes a concern. To preserve network
resources for time-sensitive traffic, CoS plays a key role in controlling user access to available bandwidth.

Chapter 2–4 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

CoS Parameters
N

Understanding the terms and parameters used to quantify aspects of a network’s CoS is helpful.
Key network CoS parameters include the following:
R

• Bandwidth: This parameter defines end-to-end information capacity. One approach to solving network
congestion is to increase bandwidth (the theory being that with enough bandwidth, CoS is not necessary).
TE

• Delay: This parameter defines the typical (or worst case) delay between communicating endpoints. Delay is
caused by the propagation delay associated with transmission lines and the queuing delays associated with
buffering in a statistically multiplexed network. Reducing queuing delay for certain traffic types is a key goal of
CoS.
IN

• Delay Variation: While a long delay is certainly undesirable, having delays that vary over a wide range is often
even more disruptive to a user’s application than a relatively long, but fixed, delay. Controlling delay variation,
also known as jitter, is therefore important for some applications.
• Loss: Information loss can be extremely disruptive to some applications, such as real-time applications like
video or voice, where a retransmission is often more disruptive than the initial packet loss. For most data
communications applications, packet loss leads to retransmissions and a resulting increase in overall
transaction time. Packet loss can occur due to bit errors or equipment failures, or it can result from the need to
discard when the buffers in a statistically multiplexed network begin to overflow.
Continued on the next page.

www.juniper.net Class of Service Overview • Chapter 2–5

Junos Class of Service
Network CoS Parameters Affect Perception
CoS can play a crucial role in network performance, but application performance is equally important. Because users use
applications, they perceive the performance of the network through the performance of the applications they use.

LY
N
O
SE
U
AL
N
R
TE
IN

Chapter 2–6 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

IPv4 Type-of-Service Field in the IP Header

N

RFC 791, which defines version 4 of the IP protocol, includes the definition of a type-of-service (ToS) octet. The ToS octet is
broken down into precedence and ToS indication subfields. The precedence field (bits 0, 1, and 2) is used to prioritize packet
R

discards resulting from congestion, whereas the Delay (D), Throughput (T), and Reliability (R) bits (bits 3, 4, and 5) were
planned to be coded with bits that indicate which routing metric (delay, throughput, or reliability) should be used when
choosing a least-cost path for that packet.
TE

In practice, ToS-based routing for IPv4 never really occurred, and this lack of ToS-based routing served to negate any real use
or benefit to the ToS field’s DTR bits. The industry did implement support for IP precedence handling, primarily to prevent the
discard for network control packets, which were usually set to a precedence of 6.
IN

www.juniper.net Class of Service Overview • Chapter 2–7

Junos Class of Service

LY
N
O
SE
U
AL

Integrated Services
N

The Internet Engineering Task Force (IETF) generated several RFCs around 1994 that described an integrated-services
(IntServ) model for the Internet. IntServ, as the effort became known, was based on the use of RSVP signaling to reserve
R

resources across network elements for individual flows.

While the intentions were good, concerns about the ability to scale an RSVP signaling plane to support the global Internet
TE

and whether routers could actually maintain the state associated with the resulting path and reservation state blocks for
each microflow, quickly killed any deployment plans for IntServ.
IN

Chapter 2–8 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

Differentiated Services
N

With IntServ stalled, the IETF took a different approach and released several RFCs that described a new model for IP CoS,
named Differentiated Services or DiffServ. The differences between DiffServ and IntServ relate to the fact that DiffServ has
R

no signaling component.
Under the DiffServ model, nodes are expected to recognize and act only on aggregate flows, as opposed to the individual
TE

flows (or microflows) that the IntServ model tracked. An aggregate flow is referred to as a behavior aggregate (BA) in DiffServ
terminology, because the node’s behavior is identical for all traffic associated with a flow aggregate. A key aspect of DiffServ
scalability is that a node must recognize only the class of a particular packet, as opposed to individual application flows.
The slide shows how the DiffServ architecture redefines the original IPv4 ToS field (and the IPv6 Traffic Class field) to
IN

function as a 6-bit DiffServ field. The Differentiated Services field carries a DiffServ code point (DSCP) that identifies the BA
for each packet. With 6 bits available, a total of 64 DSCPs are possible.
The last two bits of the DSCP field were originally unused. However, RFC 3168 enables the last two bits and specifies that
they be used for explicit congestion notification (ECN).

www.juniper.net Class of Service Overview • Chapter 2–9

Junos Class of Service

LY
N
O
SE
U
AL

DiffServ Terms: Part 1

N

The slide defines several terms that are critical to a basic understanding of DiffServ:
• DiffServ field (DS field): The DS field refers to the original IPv4 ToS field that is redefined to carry DSCPs;
R

• DSCPs: 6-bit CoS values; and

TE

• Behavior aggregate (BA): A BA describes the logical grouping of traffic flows into an aggregate flow that requires
similar handling and treatment.
IN

Chapter 2–10 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

DiffServ Terms: Part 2

N

This list is a continuation from the previous page:

• Per-hop behavior (PHB): A node’s PHB describes the externally visible manner in which packets are handled
R

and forwarded for a given BA. For example, a PHB could result in a node marking all traffic associated with the
best-effort class with a common DSCP.
TE

• PHB group: A per-hop behavior group defines a set of related PHBs. For example, the assured forwarding (AF)
group consists of four separate classes, AF1, AF2, AF3, and AF4, each with three possible drop profiles. The AF1
class defines a particular PHB, while the AF category defines a per-hop grouping.
For more detailed information, refer to section 1.2 of RFC 2475.
IN

www.juniper.net Class of Service Overview • Chapter 2–11

Junos Class of Service

LY
N
O
SE
U
AL

CoS Domain
N

A CoS domain is a collection of nodes under a common administrative control with a common set of PHBs. A domain is made
up of edge, or boundary, nodes as well as internal (core) nodes. This distinction is a critical point because the role of a given
R

device varies based on its designation.

In general terms, edge nodes tend to have more complex data handling and manipulation functions when compared to a
TE

core node. For example, policing, shaping, metering (accounting), and complex multifield classification functions are
normally performed by nodes that are attached to customers or other domains. In contrast, a core node normally performs
only BA-based classification and transmission scheduling based on defined PHBs.
Because all nodes in a CoS domain are under common control and make use of a common set of PHBs, expecting that
IN

end-to-end performance and service levels can be predicted and met is reasonable.

Chapter 2–12 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

Per-Hop Behavior
N

A key component of the DiffServ architecture is the concept of a PHB that describes the externally visible way in which a
DiffServ node handles traffic belonging to a given forwarding class (or BA). The particular PHB applied to a packet is a
R

function of ingress classification using the DSCP. A DiffServ node must have a default PHB available for use when handling
unclassified traffic. The default PHB is equivalent to conventional best-effort forwarding.
TE

PHB Across the Network

Because all the nodes in a DiffServ domain implement a common set of PHBs, the end-to-end performance of the network
can be accurately modeled. This modeling normally assumes that the network has appropriate protection in place to guard
IN

against unusual traffic patterns that could negate capacity planning assumptions and jeopardize service-level agreements
(SLAs).

www.juniper.net Class of Service Overview • Chapter 2–13

Junos Class of Service

LY
N
O
SE
U
AL

PHB Specifications Identify Recommended Code Points

N

A PHB specification normally includes one or more recommendations detailing the DSCPs associated with that PHB. Note
that these specifications are only recommendations and that the actual code points used to identify a given BA are left to
R

the administrative authority for that domain.

Backward Compatibility with IP Precedence

TE

The PHB for DSCPs with zeros in the three least-significant bits of the DS field is defined as being compatible with the
historic treatment of IP precedence, as outlined in RFC 791. The eight code points associated with IP precedence
compatibility are not officially given a forwarding class designation; they are simply referred to as class selector (CS) code
IN

points.

Chapter 2–14 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

Expedited Forwarding
N

RFC 3246 defines the expedited-forwarding (EF) PHB. This PHB is designed to provide low loss, low latency, and low jitter
services to support delay-sensitive and loss-sensitive applications such as voice or video conferencing.
R

Assured Forwarding
TE

RFC 2597 defines the AF PHB. This PHB is primarily concerned with packet loss, because no delay-related parameters are
defined. Within the AF category, four classes exist: AF1, AF2, AF3, and AF4. Within each category, three classes are defined
that differ based upon their loss probability. Put another way, AF11 should have a lower percentage of packet drops when
compared to AF43.
IN

www.juniper.net Class of Service Overview • Chapter 2–15

Junos Class of Service

LY
N
O
SE
U
AL

Class Selector Code Points

N

As mentioned earlier, a set of CS code points are designated to provide backward compatibility with the historic use of the IP
precedence field. While not mandated, the CS code points are normally used to support the network control class, because
R

historically, IP precedence was used to minimize packet drops for control traffic. RFC 2474 defines the CS code space.

Best Effort Is Undefined

TE

A PHB for the best-effort (BE) class is not defined, because the PHB for the BE class, or for traffic that cannot be classified,
should equate to conventional (that is, no CoS) packet handling as defined in RFC 1812.
IN

Chapter 2–16 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

Recommended DSCPs
N

The specifications that define the known PHBs include one or more recommended DSCPs that identify the PHBs. The
Internet Assigned Numbers Authority (IANA) maintains a list of recommended DSCP values at: http://www.iana.org/
R

assignments/dscp-registry. The slide shows these recommended values along with the associated PHB specification. Note
that these values are only recommendations; the actual DSCP-to-forwarding-class mappings used within a domain are left to
that domain’s administrative authority.
TE

The Junos OS provides support for the recommended DSCP values through the use of code-point aliases. To view these
aliases, use the show class-of-service code-point-aliases command:
user@R1> show class-of-service code-point-aliases dscp
IN

Code point type: dscp

Alias Bit pattern
af11 001010
af12 001100
af13 001110
af21 010010
af22 010100
af23 010110
af31 011010
af32 011100
. . .

www.juniper.net Class of Service Overview • Chapter 2–17

Junos Class of Service

LY
N
O
SE
U
AL

IP ToS/DiffServ
N

As discussed earlier, the IP ToS field is an eight-bit field that includes three precedence bits for traffic prioritization. In
practice, ToS has remained largely unused.
R

The DSCP also occupies the ToS byte, using the first six bits for traffic prioritization. The DSCP field supersedes the ToS field,
but provides backward compatibility.
TE
IN

Chapter 2–18 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

Traffic Class
N

IPv6 DiffServ functions much like IPv4 DiffServ, using the traffic class byte in the IPv6 header.
R
TE
IN

www.juniper.net Class of Service Overview • Chapter 2–19

Junos Class of Service

LY
N
O
SE
U
AL

IEEE802.1p
N

The Institute of Electrical and Electronics Engineers (IEEE) defined a CoS signaling technique using three bits at the
beginning of the Tag Control Information (TCI) field of the 802.1p header. These priority bits can be used to differentiate
R

between service levels at the data link or media access control (MAC) layer.
The 802.1p standard provides eight levels of priority that are defined in ways similar to those of the IP ToS field.
TE
IN

Chapter 2–20 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

MPLS Traffic Class

N

The MPLS header has three bits that were originally defined as experimental (EXP). However, once MPLS came into common
use, the field was designated for CoS purposes. In February 2009, RFC 5462 redefined the EXP field as the traffic class (TC)
R

field, in support of the standardization of the usage of these bits across the industry.
The MPLS EXP field occupies three bits, providing eight classes of service.
TE
IN

www.juniper.net Class of Service Overview • Chapter 2–21

Junos Class of Service

LY
N
O
SE
U
AL

Typical CoS Processing Stages

N

The slide shows the typical CoS stages on a modern router.

The first stage is ingress processing, where received traffic is policed (rate limited). The policing function protects the
R

network from unusual traffic patterns that might otherwise lead to congestion and possible disruption of SLAs associated
with other users. In most cases, policing and rate-limiting actions occur only at the network’s edge.
TE

After policing, traffic classification occurs. Classification is a critical stage because being able to recognize different
application streams is the foundation of being able to offer varying levels of service. Classification is necessary within all
devices that handle the traffic because an end-to-end CoS design is contingent on the consistent handling of a given packet
by all devices that interact with it.
IN

After transiting the switch fabric, a packet is normally placed into an outgoing queue, as identified during ingress
classification. This queue is then subjected to some form of weighted round-robin (WRR) servicing that factors in the
bandwidth and priority levels associated with each traffic class (or queue). Congestion avoidance is normally performed at
this stage. Most often this avoidance takes the form of a random early detection (RED) algorithm that performs strategic
discards to help prevent congestion.
The final stage of CoS processing involves the rewriting of the CoS field within the packet header, which enables downstream
nodes to recognize traffic based on CoS values. Some form of output shaping (not shown on the slide) might be used to
reduce the transmission speed of the traffic, and the resulting need for buffer space in downstream nodes.

Chapter 2–22 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

CoS Processing on Junos Devices

N

The slide displays the primary CoS processing stages in Juniper Networks M Series Multiservice Edge Routers, T Series Core
Routers, and MX Series 3D Universal Edge Routers. The stages are as follows:
R

• Code point classifier: The first CoS processing stage occurs at ingress when traffic is classified according to a
BA code point value in the form of IP precedence, DSCPs, MPLS EXP bits, or IEEE 802.1P priority values.
TE

• Policing: Ingress policing limits the amount of traffic that can ingress the router, while egress policing shapes
and limits the traffic volume that leaves the router. In most cases, ingress policing is deployed only on
customer-facing edge routers. Policers can alter the packet’s forwarding class or loss-priority settings when the
policer’s traffic profile is exceeded.
IN

• Multifield classifier: This processing stage provides multifield classification capabilities based on a firewall filter.
The net result of traffic classification is the association of a forwarding class and loss-priority value for a
particular packet.
• Forwarding policy: Junos policy can alter the forwarding next hop for a particular packet based on its associated
forwarding class and route-filter type match criteria. This capability enables class-of-service-based forwarding
(CBF).
Continued on the next page.

www.juniper.net Class of Service Overview • Chapter 2–23

Junos Class of Service
CoS Processing on Junos Devices (contd.)
• Fabric priority: T Series routers incorporate one or more complete Packet Forwarding Engine (PFE) complexes
on each Flexible PIC Concentrator (FPC). Traffic is switched between PFEs using a nonblocking cross-bar switch
fabric instantiated by the system’s Switch Interface Boards (SIBs). The default behavior sets the switch fabric
priority to match the priority assigned to traffic during ingress classification. This default behavior minimizes
jitter for high-priority traffic by providing consistent traffic handling during ingress PFE processing, transit across
the switch fabric, and during egress PFE processing. We do not recommend modifying the default switch fabric
priority.
• Scheduling and weighted RED: Schedulers are used to service the queues associated with each forwarding
class. Schedulers make use of WRR techniques to service each queue based on priority level. Congestion
avoidance through a weighted RED (WRED) mechanism is also performed at this stage.
• Rewrite marker: The final CoS stage involves rewriting CoS fields in the packet header so that the next node can

LY
act solely based on exiting CoS values.
The CoS processing described on the slide represents the concept of egress CoS processing, which is similarly supported on
most Junos OS devices. With the appropriate hardware installed, an MX Series 3D Universal Edge Router can also perform
ingress CoS processing. Ingress CoS processing is not covered in this content.

N
O
SE
U
AL
N
R
TE
IN

Chapter 2–24 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

Classifiers Map Traffic to a Forwarding Class

N

As traffic arrives at the device, it is classified as belonging to one of the forwarding classes defined on that device. The
device can match traffic based on existing CoS values using BA classification, or it can match on a variety of fields in a
R

packet’s header (IP address, protocol, port, and so forth) using multifield classification. Junos classifiers support a variety of
protocol types, as shown on the slide.
TE
IN

www.juniper.net Class of Service Overview • Chapter 2–25

Junos Class of Service

LY
N
O
SE
U
AL

Policing Limits Traffic Volume and Burstiness

N

Policers are often deployed in edge devices to restrict the volume of traffic that is either accepted from, or delivered to, that
site. In most cases, policers are deployed as part of a CoS design to protect the network from abnormal traffic levels that
R

might jeopardize SLAs for other customers.

Traffic that exceeds a policer’s profile can be discarded or tagged with a higher loss priority, making it drop-eligible in the
TE

event of congestion.
Shaping and policing are similar concepts. Policers limit the volume of traffic while allowing bursting. A shaper, on the other
hand, limits and spaces the packets to control both rate and burstiness. Reducing bursts reduces the need for buffers in
downstream devices.
IN

Chapter 2–26 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

CoS and Forwarding Policy

N

You can use routing policy to affect the forwarding next hop associated with a given forwarding class. The slide shows an
example of CBF, where traffic associated with the BE class is directed along a forwarding path that differs from the interior
R

gateway protocol’s (IGP’s) preferred route to the destination.

TE
IN

www.juniper.net Class of Service Overview • Chapter 2–27

Junos Class of Service

LY
N
O
SE
U
AL

Schedulers Define the Prioritization Properties of Forwarding Classes

N

A scheduler defines a set of parameters, including transmission rate, queue priority, delay buffers, and congestion
management and avoidance, for a specific forwarding class.
R

You measure the transmission rate in either bits per second or as a percentage of interface speed.
You can specify a priority setting that influences how the WRR algorithm services the queue for that forwarding class. In
TE

other words, the device services a high-priority queue before a low-priority queue.
You can set the buffer depth using either a percentage or a maximum temporal value.
The RED algorithm works to control congestion by performing packet drops when congestion is detected. WRED algorithms
IN

can factor criteria such as traffic type or loss priority into the discard decision. The goal of congestion avoidance is to prevent
global synchronization of TCP sessions, a condition where multiple sources begin retransmitting and backing off in unison,
which in turn leads to oscillations of either too much or too little data.

Chapter 2–28 • Class of Service Overview www.juniper.net

 Junos Class of Service

LY
N
O
SE
U
AL

Rewrite Markers
N

Marker rewrite is a key edge device function. The goal is to mark traffic in a consistent manner at the network edge to
facilitate BA classification in core devices.
R

The slide shows an example of DSCP-based marking by an edge router. In this case, traffic arriving from the customer has an
all-zeros DS field. The multifield classification actions of the edge router classify the traffic, and the packet travels through
TE

the device. Before the device transmits the packet, it writes a value into the packet’s CoS field according to the packet’s
forwarding class and loss priority.
The Junos OS supports packet header rewrite actions for several protocols, as shown on the slide.
IN

www.juniper.net Class of Service Overview • Chapter 2–29

Junos Class of Service

LY
N
O
SE
U
AL

CoS Configuration Is Unidirectional

N

Note that when you complete a CoS configuration across a network, you have generally configured it in only one direction. To
support CoS in both directions, you must configure the nodes in the other direction as well. Fortunately, CoS configuration in
R

the Junos OS is modular and template-based, so you can reuse much of the configuration you originally created.
TE
IN

Chapter 2–30 • Class of Service Overview www.juniper.net