<Course

CoS Overview
Title>
CoS Overview

Circuit-Switched Networks
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 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.
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

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.

2 www.juniper.net
 CoS Overview

Packet-Switched Networks
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 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.
While 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

Despite shortcomings, early packet-switched networks also did not require CoS, but for a different
reason than packet-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 3
CoS Overview

Convergence Drives the Need for Class of Service

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.
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 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.
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.

4 www.juniper.net
 CoS Overview

CoS Parameters
Understanding the terms and parameters used to quantify aspects of a network’s CoS is helpful.
Key network CoS parameters include the following:
• 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).
• 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.
• 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.
Continued on next page.

www.juniper.net 5
CoS Overview
CoS Parameters (contd.)
• 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.

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.

6 www.juniper.net
 CoS Overview

IPv4 Type-of-Service Field in the IP Header

RFC 791, which defines version 4 of the IP protocol, includes the definition of a type-of-service (ToS)
field. The ToS field is broken down into precedence and ToS indication subfields. The precedence
field (bits 0, 1, and 2) is used to prioritize packet discards resulting from congestion while 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.
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.

www.juniper.net 7
CoS Overview

Integrated Services
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 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 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.

8 www.juniper.net
 CoS Overview

Differentiated Services
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 no signaling component.
Under the DiffServ model, nodes are expected to recognize and act only on aggregate flows, as
opposed to the individual 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 to function as a
6-bit DiffServ field. The DS 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.

www.juniper.net 9
CoS Overview

DiffServ Terms: Part 1

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.
• DSCPs: 6-bit CoS values.
• Behavior aggregate (BA): A BA describes the logical grouping of traffic flows into an
aggregate flow that requires similar handling and treatment.

10 www.juniper.net
 CoS Overview

DiffServ Terms: Part 2

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 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.
• PHB group: A per-hop behavior group defines a set of related PHBs. For example, the
assured forwarding 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.

www.juniper.net 11
CoS Overview

CoS Domain
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 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 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 end-to-end performance and service levels can be predicted and met is
reasonable.

12 www.juniper.net
 CoS Overview

Per-Hop Behavior
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 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.

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 against unusual traffic patterns that could
negate capacity planning assumptions and jeopardize service-level agreements (SLAs).

www.juniper.net 13
CoS Overview

PHB Specifications Identify Recommended Code Points

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 the administrative authority for that domain.

Backward Compatibility with IP Precedence

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 points.

14 www.juniper.net
 CoS Overview

Expedited Forwarding
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.

Assured Forwarding
RFC 2597 defines the assured-forwarding (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.

www.juniper.net 15
CoS Overview

Class Selector Code Points

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 historically, IP precedence was used to minimize
packet drops for control traffic. RFC 2474 defines the CS code space.

Best Effort Is Undefined

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.

16 www.juniper.net
 CoS Overview

Recommended DSCPs
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/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.
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
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 17
CoS Overview

IP ToS/DiffServ
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.
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.

18 www.juniper.net
 CoS Overview

Traffic Class
IPv6 DiffServ functions much like IPv4 DiffServ, using the traffic class byte in the IPv6 header.

www.juniper.net 19
CoS Overview

IEEE802.1p
The Institute of Electrical and Electronics Engineers (IEEE) defined a CoS signaling technique using
three bits at the beginning of the 802.1p header. These priority bits can be used to differentiate
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.

20 www.juniper.net
 CoS Overview

MPLS Traffic Class

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) 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.

www.juniper.net 21
CoS Overview

Typical CoS Processing Stages

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 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.
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.
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.

22 www.juniper.net
 CoS Overview

CoS Processing on Junos Devices

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:
• 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.
• 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.
• 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 next page.

www.juniper.net 23
CoS Overview
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 act solely based on exiting CoS values.

24 www.juniper.net
 CoS Overview

Classifiers Map Traffic to a Forwarding Class

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 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.

www.juniper.net 25
CoS Overview

Policing Limits Traffic Volume and Burstiness

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 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 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.

26 www.juniper.net
 CoS Overview

CoS and Forwarding Policy

You can use routing policy to affect the forwarding next hop associated with a given forwarding class.
The slide shows an example of CoS-based forwarding (CBF), where traffic associated with the BE
class is directed along a forwarding path that differs from the interior gateway protocol’s (IGP’s)
preferred route to the destination.

www.juniper.net 27
CoS Overview

Schedulers Define the Prioritization Properties of Forwarding Classes

A scheduler defines a set of parameters, including transmission rate, queue priority, delay buffers,
and congestion management and avoidance, for a specific forwarding class.
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 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 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.

28 www.juniper.net
 CoS Overview

Rewrite Markers
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.
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 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.

www.juniper.net 29
CoS Overview

CoS Configuration Is Unidirectional

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 the Junos OS is modular and template-based, so
you can reuse much of the configuration you originally created.

30 www.juniper.net