Junos COS

J
)
)
)
)
)
)
')
)
)
)
)
)
)
)
)
)
)
)
)
)
,)
)
)
)
)
)
)
)
)
)
)
~)
~)
Junos Class of Service

10.8
Student Guide
Worldwide Education Services

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Course Number: EDU-JUN-JCOS
This document is produced by Juniper Networks, Inc.

This document or any part thereof may not be reproduced or transmitted In any form under penalty of law, without the prior written permission of Juniper Networks
Education Services.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen. and ScreenOS are registered trademarks of Juniper Networks, Inc. In the United States and other
countries. The Juniper Networks Logo, the Junes logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered
trademarks, or registered service marks arB the property oftheJr respective owners.
Junes Class of Service Student GuIde, RevisIon 10.a

CopyrlghtC 2010 Juniper Networks, Inc. All rights reserved.
PrInted In USA.
Revi:;lon History:
Revision lO.a-November 2010
The Information In this document is current as of the date listed above.
The Information in this document has been carefully verified and is believed to be accurate for software Release 10.3Rl.9. Juniper Networks assumes no
responsIbilitIes for any Inaccuracies that may appear In this document. In no event will Juniper Networks be liable for direct, Indirect, special, exemplary,
incidental, or consequential damages resulting from any defect or omission In this document, even If advised of the possibility of such damages,
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice,
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junas operating system has
no known time-related limitations through the year 2038, However, the NTP application Is known to have some difficulty In the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, In an
agreement executed between you and Juniper Networks, o-r Juniper Networks agent. By using JunIper Networks software, you Indicate that you understand and
agree to be bound by Its license terms and conditions, Generally speaking, the software license restricts the manner In which you are permitted to use the Juniper
Networks software, may contain prohibitions agaInst certain uses, and may state conditions under which the license Is automatically terminated, You should
consult the software license for further detaUs.

~
(]J
Contents
()
e
(lll)
e
.,
.,
.,
..
Chapter 1: Course Introduction ................................................ 1-1

Chapter 2:
CoS Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .. 2-1

CoS History and Evolution ......................................................... 2-3
CoS and DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . ... 2-12
CoS Fields in Packet Headers ........................................ , .......... 2-21
CoS Processing ................................................................. 2-26
())
Chapter 3:
Packet Classification ............................................... 3-1

Classification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .... 3-3
Forwarding Classes and Packet Loss Priority .......................................... 3-7
Fixed Classification .......................................................... 3-14
Multifield Classification ..................................................... _ .. 3-16
Behavior Aggregate Classification ............................................ _ .. 3-21
Lab 1: Configuring Packet Classification ........................................ _ . _.. 3-36
Chapter 4:
Policing ......................................................... 4-1

Policing Overview ....................................................... _ ..... 4-3
Single-Rate Two-Color Policer ................................................ _. .4-10
Tricolor Marking Policers ................................................... _ .... 4-14
Application-Directly on an Interface ............................................... 4-23
Application-Within a Firewall Filter .............................................. .4-27
Lab 2: Configuring Policers ..................................................... 4-42
Chapter 5:
Scheduling ........................................................ 5-1

Scheduling Overview ........................................................... 5-3
Transmission Rate .............................................................. 5-10
Queue Priority ................................................................ 5-15
Delay Buffers ................................................................ 5-23
Orop Profiles and Drop Profile Maps ............................................... 5-32
Scheduling Configuration ......................................................... 5-44
Lab 3: Configuring Schedulers ................................................... , 5-52
CD
Chapter 6:
Hierarchical Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6-1

Hierarchical Scheduling Overview ................................................. 6-3
Scheduler Modes ....... ; ................................................... 6-11
Hierarchical Scheduling Levels .................................................. 6-16
Throughput Example .......................................................... 6-26
Remaining Traffic ............................................................... 6-31
Queue Properties in a Hierarchical Scheduling Context ............................ _ .. 6-36
Putting It All Together ........................................................ _ ... 6-45
Lab 4: Configuring Hierarchical Schedulers ...................................... 6-57
Chapter 7:
Rewrite Rules ..................................................... 7-1

Packet Header Rewrite Overview ..............................................
Rewrite Rules and Tables ...................................................
Rewrite Combinations ......................................................
Lab 5: Configuring Rewrite Rules ..........................................
_ .... 7-3
_ ... 7-7
_ ... 7-16
_ .. 7-22
("nnta>nto;;::
..
iii
"
Chapter 8: CoS-Based Forwarding. ............................................. . 8-1
CSF Overview ................. '" ................................................83
CSF Configuration ....................................................... 8-6
Lab 6: Configuring CSF ...........................................................8-14
Chapter 9:
Case Study . ...................................................... . 9-1

VolP Case Study Overview .................................................. __ .9-3
VolP Case Study: Ingress Node ............................................. _ . 9-5
VolP Case Study: Transit and Egress Nodes .................... _............... 9-19
Appendix A: CoS Processing on M Series. T Series, and MX Series Devices .. ............ A-l
M Series and T Series Architecture ..........................................
M Series and T Series CoS Packet Handling .................... _..............
IQ2 PIC CoS Packet Handling .............................. _.............
MX Series (DPC and MPC/MIC) Architecture and CoS Packet Handling ...............
_ .A-3
_A-16
_A-21
_A-24
Appendix 8: Acronym List ... .................................................... 8-1

Appendix C: Answer Key .. ...................................................... C-l
.
I
QI
(I
.,
I)
jv Cont'3nts
Course Overview
This two-day course provides students with advanced class-of-service (CoS) knowledge and
configuration examples. The course begins with an overview of CoS before going into. classification,
policing, scheduling, and rewriting. The course then covers class-based forwarding and finishes
with a case study. This course is based on Junos operating system Release 10.3RL9.
..
..
..
CD
Through demonstrations and hands-on labs, students will gain experience in configuring and
verifying Junos CoS features.
Objectives
After successfully completing this course, you should be able to:
o
Understand the history and evolution of CoS.
Identify the CoS fields in various packet headers.
List the CoS processing stages on devices running the Junos operating system.
Identify the default CoS settings on Junos devices.
Configure and verify behavior aggregate and multifield (MF) classification.
Configure and verify two-color and tricolor marking policers.
Configure and verify schedulers and their components.
Configure and verify the multiple levels of hierarchical schedulers.
Configure and verify packet header rewriting.
Configure and verify class-based forwarding.
Create a CoS configuration based on a set of design requirements.
Intended Audience
This course benefits individuals responsible for configuring and monitoring devices running the
Junos OS, especially those in a service provider environment. It also benefits individ uals
responsible for designing networks containing Junos devices.
Course Level
Junos Class of Service is an advanced-level course.
Prerequisites
Students should attend the Introduction to the Junos Operating System (IJOS) course, the Junos
Routing Essentials (JRE) course, and the Junos Intermediate Routing (JIR) course, or have
equivalent experience prior to attending this class. General knowledge of CoS concepts is also
helpful .
\..
Course Agenda
Day 1
Chapter 1:
Course Introduction
Chapter 2:
CoS Overview
Chapter 3:
Packet Classification
','>
Lab 1: Configuring Packet Classification

Chapter 4:
()I
~
'-,',
Policing
Lab 2: Configuring Policers
Chapter 5:
'q,
~
,!(it:
~
Scheduling
Lab 3: Configuring Schedulers
Day 2
Chapter 6:
Chapter 7:
Hierarchical Scheduling
Lab 4: Configuring Hierarchical Schedulers
'l:jl;
~
Rewrite Rules
G
"0g&
Lab 5: Configuring Rewrite Rules

Chapter 8:
I
I
CoS-Based Forwarding
Lab 6: Configuring CBF
Chapter 9:
Case Study
"
';;:;
<I
"if
\I
~;p
<iN?
'V
vi Course Mend:=:.
Document Conventions
eLi and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface (CLI)
or a graphical user interface (GUI). To make the language of these documents easi er to read, we
distinguish GUI and CLI text from chapter text according to the following table.
Style
Description
Franklin Gothic
Normal text.
Courier New
Console text:
Screen captures
Noncommand-related
syntax
GUI text elements:
Menu names
Text field entry
Usage Example
Most of what you read in the Lab Guide
and Student Guide.
commit complete
Exiting configuration mode
Select File > Open, a nd then click

Configuration. conf in the
Filename text box.
Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances
will be shown in the context of where you must enter them. We use bold style to distinguish text
that is input versus text that is simply displayed.
Style
Description
Usage Example
Normal CLI
No distinguishing variant
Physical interface: fxpO,

Enabled
Normal GUI
View configuration history by clicking

Configuration> History.
CLI Input
Text that you must enter.
lab@San_Jose> show route

Select File > Save, an d type
config .ini in the Filename field.
GUI Input
Defined and Undefined Syntax Variables

Finally, this course distinguishes between regular text and syntax variables, and it a Iso
distinguishes between syntax variables where the value is already assigned (defined variables) and
syntax variables where you must assign the value (undefined variables). Note that these styles can
be combined with the input style as well.
Style
Description
Usage Example
CLI Variable
Text where variable value is

already assigned.
policy my-peers
GUI Variable
Click on my-peers in theo dialog.

CLI Undefined
GUI Undefined
Text where the variable's value

is the user's discretion and text
where the variable's value as
shown in the lab guide might
differ from the value the user
must input.
Type set pol:i.cy poli.cy-name.

p:i.ng lO.O.!f:.,Y
Select File > Save, a ..... d type
~1.ename in the Filename field.
Additional Information
Education Services Offerings
You can obtain information on the latest Education Services offerings, course dates, an d class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.nel/trainingJeducation/.
About This Publication

The Junos Class of Service Student Guide was developed and tested using software Release
10.3Rl.9. Previous and later versions of software might behave differently so you should always
consult the documentation and release notes for the version of code you are running before
reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety offormats:
Go to http://www.juniper.nel/techpubs/ .
Locate the specific software or hardware release and title you need, and choose the
format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.
Juniper Networks Support

For technical support, contactJuniper Networks at http://www.juniper.nel/customers/supporl/, or
at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).
t
i
I
II
I
II
~
~
Ii
(I
....
(I
(I
(I
(I
....
viii
A.lrlitinn~1
I ...... -t:... ~~~ ... : __
(8

Chapter 1: Course Introduction
Chapter Objectives
After successfully completing this chapter, you will be
able to:
- Get to know one another
-Identify the objectives, prerequisites, fa cHities , and
materialsused durihgthiscourse
- idehtify additionql Education Services courses at Jtmiper
Networks
- Desoribethe Juniper Networks Certification Program
This Chapter Discusses:
Objectives and course content information;
Additional Juniper Networks, Inc. courses; and
The Juniper Networks Certification Program.
Chanter 1-2
COl Trc:.p lntrnrllll"tinn
Junos C lass of Service
Introductions
Before we get started".
- What isyour name?
....
(I
I)
..
Where db yon wqrk?
- What is YoiJJ prjrnaryrple in your

organization?
-What kind of netWork experience
do you hav,.e?
iioAreyoLfcertified on Juniper NER\A!otks?
-What i~ tbe tllostimPortantthtngfot
you to.learn in thip training session1
Introductions
The slide asks several questions for you to answer during class introductions.
. . . .'
._~._
... f'h"""'Tar "I
':)
Course Contents
Contents:
chapter 1: Course Introduction
Chapter 2: CoS Overview
Chapter 3:. Packet Classification
Chapter 4: Policing
Chapter5: Scheduling
Chapter 6: Hierarchical Scheduling
Chapter 7: Rewrite Rules
Chqpter 8: COS-Based Forwarding
Chapter 9: Case Study
Course Contents
The slide lists the topics we discuss in this course.
Chapter 1-4.
Cnllrc.""
InhnM' ....+; ..........
Prerequisites
The prerequisites for this course are the following:
-Thelntroduction to the Junos Operating System (!J08)
course, or equivalent experience
-The)unos ROuting Essentials (JRE) course, or-equivalent
,
eXPerienoe
Th~)unos IntermediqteRouting(JIR) co.uTs,e, orequiValen1
e~<perienoe
General knowledge orcos concepts is helpful
Prerequisites
The slide lists the prerequisites for this course.
www.illninpr Mc.+
rnllr.:::,o IntrnriliMinn ",. r.h;:mtAr 1-t;
lunos Class of Service
Course Administration
The basics:
Sign-in sheet
Schedule
Class times
Breaks
Luhch
Breakand restroom facilities

Fire and safety procedures
Communications
Telephones and wireless devices
Intemetaccess
General Course Administration

The slide documents general aspects of classroom administration.
Chapter 1-6 COUr~A
Intrnrhlr.tinn
www
ill
niner.net
Education Materials
Available materiqls fqr classroom-based
and instructor-led online classes:
~
Vd);1
Lecturetnaterial
I)
.,
.,
Lab gUide
Lab equipment
Self-paced online courSes alsoava'i1able..

c.
http://WWW.juhIpet..net/trainihgltechnical_education/
Training and Study Materials

The slide describes Education Services materials that are available for reference both in the
classroom and online.
,..~
. __
. - ..... _..1 _ ... :__
..
('h~l"\tc.
.. 1_ 7
Additional Resources
Fort\1ose who want more:
-Juniper Networks Technical Assistance Center (JTAC)
http://www.junip~r.net/support/requesting~supportl1trnl
-Juniper Networks books
I
I
http://www.junipeIO;netjtrainingljnbooks/
- Hardware and software technioal

d.ocu mentation
!"
~
(I
(I
fa
Online: I1ttp:j/wwwjuniper.netjtechpub$j
lmagefiles for offline viewing:

http//www.juniper.netjtechpubsjresOurcesjcdrom.html
- Certifica.tion resouroes
http:;jWwW.juniper:netjtn:Jlning;c\!lrtification/resources.html
it
it
<I
<I
Additional Resources
The slide provides links to additional resources available to assist you in the installation,
configuration, and operation of Juniper Networks products.
.,
Chapter 1- 8
COIl rc
Intrnrl, , ... f-inn
@
(iW
~
G)
(iW
Junes Class ef Service
Satisfaction Feedback
Iii!l
I)
Ii!!
Ii!!
Ii!!
Ii!!
Ii!!
Iii!l
Ii!!
(I
I)
Class
Feedbacl<
Ii!!
Iii!l
~I
==
.. To receive yoLir certificate,yoLi must cOl11plete the
survey
Either you will ree.eille a survey tOGompletei:lUh.e eng
of
class; or we will e-mail ittoypu Within two week;;

Completerdsufveyshelp u,sserve YOLI better.!
CD
"
Satisfaction Feedback
Juniper Networks uses an electronic survey system to. cellect and analyze yeur cemments and
feedback. Depending en the class yeu are taking, please cemplete the survey at the end ef the class,
er be sure to. leek for an email abeut two. weeks from class cempletien that directs you to. cemplete
an enline survey ferm. (Be sure to. previde us with your current e-mail address.)
Submitting yeur feedback entitles yeu to. a certificate ef class cempletien. We thank you in advance
fer taking the time to. help us impreve eur educatienal efferings.
Juniper Networks
Curriculum
ces
Formats:
Classroom-based instructor-led technical courses
Online instructor-led technical courses
Hardware installation eLearning courses as well as technical
eLearning courses
Complete list of courses:

http://www.juniper.ne1/training/technical_education/
Juniper Networks Education Services Curriculum

Juniper Networks Education Services can help ensure that you have the knowledge and ski lis to
deploy and maintain costeffective, highperformance networks for both enterprise and service
provider environments. We have expert training staff with deep technical and industry knowledge,
providing you with instructor-led handson courses in the classroom and online, as well as
convenient, self-paced eLearning courses.
Course List
You can access the latest Education Services offerings covering a wide range of platforms at
http://www.ju niper.netjtraining/technical_education/.
(I
II
(I
(I
(I
(i)
@
~.'
w
o
't{JJ
..
..
Juniper Networks Certification Program

Why earn a Juniper Network$
c~rtificati9n?
-)uniper Networks certificatfonmakes yop stand out

U nleashyoll( creativity across the
entire netWork
o Deliveryollr Visioh,qesign,cmd.
architectUre
o
CERTIFICATION
PROGRAM
S:etsyo LI ajJart frdmYour peers
Capitalize on the promfseofthe

New Network
DevelojJand deploy the ser.vices
you need
LeadthewayandincreaseyoLlr value
Unique be.nefitsfor certified individualS
Juniper Networks Certification Program

AJuniper Networks certification is the benchmark of skills and competence on Juniper Networks
technologies,
www.iunioer.np.t
r.nllrc:::a. Intrnrll Irfinn.
c'h;;)ntp.r 1 _11
Juniper Networks Certification Path
Juniper Networks Certification Program Overview

The Juniper Networks Certification Program (JNCP) consists of platform-specific, multitiered tracks
that enable participants to demonstrate competence with Juniper Networks technology through a
combination of written proficiency exams and hands-on configuration and troubleshooting exams.
Successful candidates demonstrate thorough understanding of Internet and security technologies
and Juniper Networks platform configuration and troubleshooting skills.
The JNCP offers the following features:
Multiple tracks;
Multiple certification levels;
Written proficiency exams; and
Hands-on configuration and troubleshooting exams.
Each JNCP track has one to four certification levels-Associate-Ievel, Specialist-level,

Professional-level, and Expert-level. Associate-level and Specialist-level exams are computer-based
exams composed of multiple choice questions administered at Prometric testing' centers worldwide.
Professional-level and Expert-level exams are composed of hands-on lab exercises administered at
select Juniper Networks testing centers. Professional-level and Expert-level exams require that you
first obtain the next lower certification in the track. Please visit the JNCP Web site at
http://www.Juniper.net/certification for detailed exam information, exam pricing, and exam
registration.
Chapter 1-12 Course Introduction
www.iufliper.net
Questions
~
to
~
dill
Gl
C
I
e
I
fiI1l
~
Any Questions?
If you have any questions or concerns about the class you are attending. we suggest that you voice
them now so that your instructor can best address your needs during class.
tI
(I
Chapter 1-14
COlJr5:.p.lntrnrlll~tinn
""
"
""
Certification Preparation
Training and study resourcesz
-Juniper Networks Certification Program Web site
www.juniper.net/certlfication
- Education SerVices training classes
.tvww .luhii2er.het/tra iHing
-Juniper Ne.tworks dqGumenta.tiQnandwhite papers
www.iLmiper.netitechpubs
Preparing for practical exams requires a lot of

h<::ipds-on practice:
.. Qn-the-Job ex,perieppe
- Education Services training.classes
- Equipment access
..
Preparing and Studying

The slide lists some options for those interested in preparing for Juniper Networks certification.
.._-_ .. "'-'---

Chapter 2: CoS Overview
.,.,
.,
..
,.
Chapter Objectives
AftersuccessfuJly completing this chapter, you will be
able to:
DIscuss and understand the history and evolution of class of
service
Definethe characteristics of Differentiated Services
,
'-
-'
"
'
Define qhd list per-hop behaviors

Identify the CoS fields in various packet headers
Ustthe CoS processing stages on devices running the Junos
operating system
e
fJ
The history and evolution of class of service (CoS);
The characteristics of Differentiated Services (DiffServ);
Per-hop behaviors (PHBs);
The CoS fields in various packet headers; and
The CoS processing stages on devices running the Junos operating system_
Chapter 2-2
r.n~
....,,~".,~.--
Agenda: CoS Overview

~CqS
History and Evolution

-Cos. and DiffServ
-CoS Fields in Packet Headers
- CoS Processing
CoS History and Evolution

The slide lists the topics we discuss in this chapter. We discuss the highlighted topic fi rst.
lA/lAllA! illnin.c... .............
i"... c
('\., ...... ,; ...... "
r.h~nttlr
?_ ':l
'--'
C;
CZ
A Historic Perspective
o
\Jj
.. Circuit-switched networks
@
Cll
@
Designed around service levels needed for telephony
Conflectioh'oriented; one user per connectioh
Suitable for real~time, IOss~s!3nsitiveapplications

Overkill for most other telecommunications uses
Low (fixed) d.elay

.. Blockihgof neW connections dUfing c:ohgestion
.. CoS is not required in the historic environment

The network is purpose:...builtto support application
(telephony) requirements
CoS is inherently built~..:i.:.-'--__
(I
@
(I
(I
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 capabiliti es are
not necessary_ For example, circuit-switched networks inherently provide the highest CoS le"els
possible because of the nature of the voice applications that these networks were designed to
support_
n"c.r\lj':nAl
If
~
Circuit-5witched Networks
Chaoter 2-4 ron<=:
I
11
I
I
fa
fa
fa
....
..
..
Network Advances
Packet-switched networks
Developeq to optimIze efficiency for maqhin~-to-maQhine
commlmicatiohs
Basedbn statistical multiplexing
Notconnection-oti~nted;mLlltiple users share a conne.ctibl1
~UnbQunded delays and loss during congestion
COS is.still not applicable

the network is purpose-builtto support applica,tion
requirements
-Applications 00 not reqUire coS
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
illnincl" ...... ~ ...
Network Convergence Drives CoS

Conv~rgence drives the need for CoS
Multiple applications suppOrted over a common network
infrastructu re
Traffic from specific applications mustbe recognized and treated
accordingly
Special handling is necessary to ensurethat unique applications
perform as expected in the face of congestion.or ejueuing delays
USer bandwidth usage must be controlled
IP is the convergenCe technology of chOice

Voi.c9
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 recognize~ speCific application streams, going one step further and offe ring
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 con.cern. To
preserve network resources for time-sensitive traffiC, CoS plays a key role in controlling user' access
to available bandwidth.
'U'A""
i .ninAr
nAt
\01
Definition of CoS Parameters

CoS parameters
Bandwidth: End-to"end information carrying capacity
.. Delay: End-ta-end delay for information delivery
Delay variation Uitter) - Variation inend-ta-end delays
cau.sed b{packet queuing
Loss: Percentage Of paqkE)ts not delivereq, usually rEltated to
CQogestion
Network CoS parametersaftectEi 'user's perception of

performl3!1c.e
An qpplication can perform only as well as the underlying

network that supports it
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:
o
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 c()mmunicating
endpoints. Delay is caused by the propagation delay associated with transmission lines
and the queuing delays associated with buffering in a statistically mUltipl exed 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.
COS Parameters (contd.)
Loss: Information loss can be extremely disruptive to some applications, such as

realtime 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 playa 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 ofthe applications they use.
C
C
C
C
C
G
G
~
II
<I
I
I
41
@ll
eI
""
I
I
(I
- : - - -_.&.
A Brief History of IP Co5-Yype ..of..Serviee

Field
Type-af-service byte in the IP header (circa 1981.)
Defined in RFC 791
3-bit precedence field to prioritize discards
3-bitToS field to indicate whether delay, throughout, or
reliability should be the primary metric
In practice, very little support exists for ToS-based routing
Industry supported precedence bits to minimize loss of networkcontrol packets
MSB
IPTQS
RFC791
:2
IP Precedence
LSB
IPv4 Type-of-5ervice Field in the IP Header

RFC 791, which defines version 4 of the [P protocol, includes the definition of a type-of-service (ToS)
field. The ToS field is broken down into precedence and ToS indication subfie[ds. The precedence
field (bits 0, 1, and 2) is used to prioritize packet discards resulting from congestion while the De[ay
(D), Throughput (T), and Re[iability (R) bits (bits 3, 4, and 5) were planned to be coded with bits that
indicate which routing metric (de[ay, throughput, or reliability) should be used when choosing a
[east-cost path for that packet.
[n practice, ToS-based routing for [Pv4 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 [P precedence handling, primarily to prevent the discard for network control packets,
which were usually set to a precedence of 6.
www.iuniDer.nllO.....
r. ... c-
1"\ __ .: ..... ,
...
("h"' ..... to ..
I')
A Brief History of IP CoS IntServ

Integrated Services (circa 1994):
IETF's first attempt at extending IP for other than best-effort
services
RSVP signaling used to describe specific CoS requirements

to the netw()rk
.Routers reserve resources across the network
Resembled acircuit-switchedcaH setup
Never deployed
Scalapility is.sues
Integrated Services
The Internet Engineering Task Force (lETF) generated several RFCs around 1994 that described an
integrated-services (lntServ) model for the Internet.lntServ, 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.
Chaoter 2-10 ..
,.....n~ nuo:>.ruicoIA/
www.itlnioer.net
DlffServ Em$rges
DiffServ architecture (circa 1998):
Defilled in RFCs 2474 and 24T5
.,
..
I>
.,
.,
.,.,
Redefined the IPv4 10S field to support a 6"bit DiffServcode

point(DSCP)
DiffServ hcl's rJosignaling component
, Operates onhop~by-hQP baSIS
RFC3168
MSBO
OlftServ
RFC~474
j.
7 LSB
- ~- .l. - .~-I--.
:. :~~D--L-$fp----,-,----
:----L-~--,:. . ---L..1---LEfN----II""
1-.--1
(3
CD
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 scala bility 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 originallPv4 loS 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 .
IA/IAIIAI
iI, ... ; .... .,. ...... _ ...

III
~CoS and DiffServ

III
CoS Fields in Packet Headers
III
CoS Processing
COS and DiffServ

The slide highlights the topic we discuss next.
r.h~ntQr,)_1,)
,....~C" I"\ ...... ~.: ......
,,,.. ,, .. : ..... int=or n.::.t
Diffserv Terminology (1 of 2)
Key DiffServ terms:
DiffServ field
;, Origiri<;\IIPv4 ros byte
~
DSCPs
;, SpeCific6-bitvalue In the DSfie.ld
This is theCoSvalLlefor a.packet
Behavior aggregate (BA)

ClassifiCation based on DSCP
Packets with a common DSCP belong to the same SA
DiffServ Terms: Part 1

The slide defines several terms that are critical to a basic understanding of OiffServ:
DiffServfield (DS field): The OS field refers to the originallPv4 ToS field th at is redefined
to carry OSCPs.
.
DSCPs: 6-bit CoS values.
Behavior aggregate (BA): A SA describes the logical grouping of traffic flows into an
aggregate flow that requires similar handling and treatment.
www.junioer.nAt
CJ
@
@
@
~
Cill
DiffServ Terminology (2 of 2)
Key DiffServ terms (contd.):
Per-hop behavidr(PHB)
Forwarding;treatmentassociatedWith a given BA
tfJ?p
~
Packetswith the. same DSCP valLIe haVe the Same PHB
'I
PHS group
Asetof one or tr\orePHBswith rel<lted Jorwatd ing behaVior
EXample: ass\..lred forwarding (A F) is a PHB group, consisting of
PHBsAF1, AF2; AF3, andAF4
G
@I
I
I
DiffServ Terms: Part 2

This list is a continuation from the previous page:
Per-hop behavior (PHB): A node's PHS describes the externally visible manner in which
packets are handled and forwarded for a given SA. For example, a PHS could result in a
node marking all traffic associated with the besteffort class with a common DSCP.
PHB group: A per-hop behavior group defines a set of related PHSs. 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 PHS, while the
AF category defines a perhop grouping.
For more detailed information, refer to section 1.2 of RFC 2475.
www.iuniper.net
"\'1
\:J;J
@J
~
~
@
e
e
e
I)
.,
CoS Domains
CoS domain
-A Qontiguous collection of no.des under a commohpo licy
CommonsetofPHBs
ECfgeq~viCe$defiheandappIY CoS
on Ue'lffic
CoredevicesefficJentlyforwardtraffic ba$edon CoS markings
Core or Internal
.,
.,
",.
EdJ~ec)r B()unc:t~ry
(I
.Domain .A
Domain B
CO$support might. e~istE!(;ross
adh1InlstrE\tiv~..boundElri.~s.
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 1:0 customers
or other domains. In contrast, a core node normally performs only BA-based classifica tion 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.
It
It
D
!l:I.
www.juniper.net
I"<_C' 1"\ _ _
.1_...
"'h ....... +~~...., .....
Per..Hop Behavior (1 of 2)
PHS
A key component of DiffServ architecture
Describes how a node handles packets belonging to a
specific behavior aggregate
PHBsare indexed by DSCPs
The default best-effort PHB is used for unmatched code points
PHS across the network
End-to~endflow
characteristics can be predicted with

consistentPHB support across a DiffServ domain
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 tl1at the
network has appropriate protection in place to guard against unusual traffic patterns that c<luld
negate capacity planning assumptions and jeopardize service-level agreements (SLAs) .
www.jemiper.net
CoS D()mains
CoS domain
A Qontiguous collection of hode$ uhder a common pol icy
CommonsetofPHBs
.. Edge cI.eVic;e$ define.and apply CoS on t~affic;
Core devices efficiently forward trafric baseclon CoS markings
Edlf!e()r Bpundl,iiy
Dorn~in .A.
DOIn!;!ill B
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 cornmon set of
PHBs, expecting that end-to-end performance and service levels can be predicted and met is
reasonable.
\.
Per.Hop Behavior (1 of 2)
PHS
A key component of DiffServ architecture
Describes how a node handles packets belonging to a
specific behaVior aggregate
PHBsare indeXed by DSCPs
The default best-effort PHB is used for unmatched code points
PHS across the network

End'-to-end flow characteristics can be predicted with
consistentPHB support across a DiffServ domain
em
II
~
~
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).
Chapter 2-16 Co!=;
O\lpn/jplA/
"
(I
(I
(I
(I
(I
(I
(I
(I
@
(0
(J
~
~
o
o
o
tl'l!\.i!i
\Uj1
.,..
..
I)
I)
I)
I)
I)
Per-Hop Behavior (2 of 2)
.. PHB specifications identify recol11memded code points
Actual values are left to the DiffServ domain's
administration
.. Backward compatibility
RFC 791. defines the PHB forpSCps coded with zeros in the
leastsignificaptpiis qfthe 0$ field
(xxxOOO)
Grandfathered support for IPprecedence handling

Referredto as cfass se/ectorcode points
PHB Specifications Identify Recommended Code Points

A PHS specification normally includes one or more recommendations detailing the DSCPs
associated with that PHS. Note that these specifications are only recommendations a nd that the
actual code points used to identify a given SA are left to the administrative authority for that domain .
Backward Compatibility with IP Precedence

The PHS for DSCPs with zeros in the three least-significant bits of the DS field is defin ed 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.
(I
f"',...C::
()\It:1n/ipw.
Chaoter 2-17
Standardized DiffServ PHBs (1 of 2)

Expedited forwarding (RFC 3246)
Designedto provide for [ow loss, low delay, and low jitter
services
Example: Voice
Recommended code point: 101110
Assured forwarding (RFC2597)

Primarily concerned with controlling packetloss
Fourclasses:AFi, AF2, AF$,ancf AF4
-Each class supports three dropprobabi/ities;forexarnple, AF11
(JOW),AF12 (med;qm). andAFi3 (high)
Expedited Forwarding
RFC 3246 defines the expedited-forwarding (EF) PHS. This PHS 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) PHS. This PHS 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
toAF43.
Chapter 2-18 CoS
OVP.rviRW
standardized DiffServ PHBs (2 of 2)

ClasS$t3lector oode points (RFC 2474)
Provide IP precE;lc!encE;lcompatibiljty
Typically used for network control traffic
l3.est effort is not specificaJly defined

. ~e$teffdrtf$ thedefpult pHB
Class Selector Code Points

As mentioned earlier, a set of CS code pOints are designated to provide backward compatibility with
the historic use ofthe 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 handl ing as defined
in RFC 1812.
r'nC: ()\1Anlip'J./
Chapter 2-19
(
Recommended DSClPs
lANA maintains a li.st of recommended DSCPs
Based on RFC recommendationsfordefined PHBs
<
1
,
Name
i DSCP
. Name
IDSCP
J
csa
000000
AF11
001010
<
<
<
CSl
001000
AF12.
0011QO
qS2
010000
An3
o011iO
C8;3
OUOOO
/lF21
01bol0
CS4
100000
AF22
010100.
CS5..
101000
AF23
010110
CS6.
110000
AF:;ll
011010
OS?
11~OOO
AF32
011109
AD3
0:1.1110
. AF41
100010
AF42.
100100
.I\F4;3
;1.00110
EF
101.110.
Recommended DSCPs
The specifications that define the known PHSs include one or more recommended DSCPs that
identify the PHBs. The Internet Assigned Numbers Authority (lANA) maintains a list of recom mended
DSCP val ues at: http://www.iana.org/assignments/dscp<registry. The slide shows these
recommended values along with the associated PHS specification. Note that these values are only
recommendations; the actual DSCP-to-forwarding~lass 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-paint-aliases
command:
user@Rl> sho~ class-of-service code-paint-aliases dsep

Code point type: dscp
Alias
Bit pattern
afll
001010
afl2
001100
afl3
001110
af21
010010
af22
010100
af23
Olalla
af31
011010
af32
011100
Chapter 2-20 CoS OverviAw
Junos CI ass of Service
..
.,
....
III
II
CoS and DiffServ
~C.bS FjeldSin Packet Headers

III
CoS Processing
CD
~
w
CD

The slide highlights the topic we discuss next .
CD
~
w
rn~ O\lt:lnliAw.
Chapter 2-21
(
(
~
(
CoS Fields in Packet Headers-lPv4
C
C
ToSjDiffServfield
RFC791
Up to 64 classes of service
(0
~
IP ToS/DiffServ
As discussed earlier, the IP ToS field is an eight-bitfield 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.
Chapter 2-22 CoS Overview
(I
CoS Fields in Packet Headers-lPvl

Traffic class field
'"'
RFC2460
'"' up to 64 classes of service
Traffic Class
IPv6 DiffServ functions much like IPv4 DiffServ, using the traffic class byte in the IPv6 header.
f"n<::' rhll~nlij:l.lM.
Chaoter 2-23
CoS Fields in Packet Headers Ethernet
IEEE 802.1p
fEEEStd 802.1Q-2005
Up to 8 classes.ofservice
,Priority
Code POint
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.
Chapter 2-24 CoS
OVArviAW
II
()
E)
Ci)
Ci)
~
~
.,
..
I>
.,
.,
CoS Fieldtiln Packet: Headers-MPLS
Traffic class fjeld
RFC 5462
..
."
Was originally defined as \::XP field in RFC 3032
Up toB classes ofservice
I::: :::::~H ::::::::I :::~< ::
~.
Fa rjrterly EXP
(I)
(I)
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 .
(I)
r'nC: rhU:.nliaui.
Chaoter 2-25
(
G
(
C
C
III
III
CoS and DiffServ
E.
III
Vi'If),
..
~CoS
~
~
Processing
I
I
f1l
>d"t
(I
.;~A
G
G
v..'
-,-!if.
..
COS Processing
(8
..
(I
(I
y< (I
;;
Chapter 2-26 CoS Overvip.w
TYpical CoS Processing Stages
Fl'om
Header
Fap.ric
-,jl.,.,"'_.
"''':,.
......... Rewrife -+---~
and
PriQritizatibrt
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 en end-to-end
CoS design is contingent on the consistent handling of a given packet by all devices thet 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 t:raffic class (or
queue). Congestion avoidance is normally performed at this stage. Most'bften this av.oidance 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 for'm 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.
,,_t" n ........ ,: ......
C':h::.ntAr ?-?7
CoS Processing on Junos Devices
Ingress
tI
~
~
Egress
~
(i
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 theJlssociatiol1 of a
forwarding class and losspriority 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. Th is
capability enables class-of-servicebased forwarding (CBF).
Chapter 2-28
Cn~ f'hU:lr'\/i""'lA/
Junos CI;;ass 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 fabri-c 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 levei. Congestion avoidance through a weighted RED (WRED)
mechanism is aiso 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 soiely based on exiting CoS values .
f:n!=:. OVArviAW
Chapter 2-29
Traffie Classification
Classifiers map traffic to
c;I
forwarding class at ingress
Can match on existing CoS values

SA classification
Can match on protocol, port, addresses, and so forth
II
-Multifield classification
Supportfor lP precedence, DSCP (IPv4 and IPv6), MPLSEXP,

and IEEE 802;1p
'iid'i
t
<I
'iM'6'
~
~
INC: Network controlclas~J
<I
(JD
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 (lP address, protocol, port, and so forth) using
multifield classification. Junos classifiers support a variety of protocol types, as shown on the slide.
'
..
@
C)
GD
C"'\
Policing
\::;:iJ
CJ)
@
Policing limits traffic "olum~ and burstiness
~
~
Enforcesanc\ Pfotects.CoSSLAs
I)
Excess traffic can be marked or-discarded
.,
.,
..
Functions at ingress, egress, or both
IMF:MlIltifi~ld
Policing Limits Traffic Volume and Burstiness

Policers are often deployed in edge devices to restrict the volume of traffic that is eith er 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.
r.n~ {)\/j::ln,iAW
..
Chapter 2-31
CoS and Forwarding Policy

Policy can select the forwarding next hop for traffic
associated with a particular forwarding class
Facilitates CoS-based forwarding (CBF)
II
CBFin place at R2 for

the BE forwardJngclass
(J
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 CoSbased forwarding (CBF), where traffic associated with the BE
class is directed along a forwarding path that differs from the interior gateway protocol's (IG P's)
preferred route to the destination.
o
o
Q'jJ
@
e
e
e
I>
'.
I>
Schedulers
-Schedulers qefinethe prioritization properties of
forwarding classes (qUeues):
"Transmission rate
-Guaranteedand maximum rates
" QUeue priority

.. $upporUor five priority lE)vels
Delay puffer
Storage spaCE) for traffiC bursts,
.. congestion manager)lent a.ncl avoidance

" Suppbrtfbr RJ5Dfo(equal, rahd6mdropping bftraffic
Support for WREOfQr\il!E)ighted, prefE)rrE)d dropping of traffic
I>
8"'
y
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 Tep sessions, a
condition where multiple sources begin retransmitting and backing off in unison, whioh in turn leads
to oscillations of either too much or too little data.
(
(
"
Rewrite Markers
The packet header rewrite sets CoS values for
outbound traffic
Can be used by SA olassifioation in downstreahl nodes
Supportfor IP precedenoe, DSCP (IPv4and IPv6), MPLS EXP,
and IEEE 802.1p
Thernpoullc{ classifier assi@ts

8 packet toforwardingclass . .
!1ewritese:ts the paqkefs DSGPco:Ung

. / .based on the forwardingClass
~~./'
,
loscp;,ooOooo I
packet
.~
...
loscp= 0001001
Packet
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 OSCP-based marking by an edge router. In this case, traffic arriving
from the customer has an all-zeros OS 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 as supports packet header rewrite actions for several protocols, as shown on the slide.
Chapter 2-34 CoS OVerviAw
..
CoS Is Unidirectional
CoS configuration is unidirectional
You must expliqitly configure settings in both directiol1s
Junos OS allows reuse ofmany OoScomponents
-<}raffic how
CoS [)oma.in
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.
r.n~ n\fp.rviF!W
Chapter 2-35
Summary
In this chapter, we:
Dfsqussed the history and evolution of CoS
Defined the characteristics of DiffServ
Defined and listed PHBs
Identified the CoS fields in various packet headers
Listed the CoS processingstagi:ls on Junos OS-based
platforms
I)
This Chapter Discussed:
The history and evolution of CoS;
The characteristics of DiffServ;
PHBs;
The CoS fields in various packet headers; and
The CoS processing stages on Junos OS-based platforms.
Review Questions
1 ..How many bits make up the DSCP?
2. For theasSl1redforwarding PHS, hoW many classes
anq drop probabilities exist?
3, Ustthe protocols the Junos OS supports for CoS
processing.
4.,Wh,at functions does policing perform?
I)
I)
I)
Review Questions
1.
2.
3.
4.
.,
'"
'"
.,
.,
.,
.,
(I
tit
tit
Chapter 2-38 CoS OVArv;pw

Chapter 3: Packet Classification
Chapter Objectives
able to:
.. Identify the purpose of packet classification
.. Describe and configure forwarding classes
.. Describe and configure fixed, Inultifield, and behavior
aggregate classification
.. Identify and configure default and custom classifiers
The purpose of packet classification;
Describing and configuring forwarding classes;
Describing and configuring fixed, multifield (MF), and behavior aggregate (SA)
claSSification; and
Identifying and configuring default and custom classifiers.
Chapter 3-2 Packet Classification
"--'
C)
()
di'J)
't;:jjJ
@
~
C)
@
<I)
(8
".,.,
.,
.,.,
"".,
"
Agenda: Packet Cla$$iflcation

~ Classification Overview
FQrwardihg Glassesahd Packet Loss Priority.

Fixed Classification
Multifield Classification
Behavior Aggregate Classification
Classification Overview
The slide lists the topics we discuss in this chapter. We discuss the highlighted topic first.
~iJ
D",,,I,,,:,+ f"1,::,,:.dfj,,~ti ... n
ChaDter 3-3
(
"-
C
C
CoS Processing--Packet Classification
I
PJ
\0J
~
@
~
Ingress
e
I
I
Egress
(I
~
COS Processing-Packet Classification

Classification is the first step in the class of service (CoS) process. As packets arrive at a Ju nos
device, they can be put into different queues to receive different treatment as they flow through the
device, and different priority as they egress the device.
(8
.. Role of packet classification:
.. ~a\lline incoming traffIC
Separate packets into different classes of traffic
Associate traffic with a se.rvigelevel
Assign packets to queues

Assigna forwardihgclass and packetlosspriotity
Role of Packet Classification

The primary function of packet classification is to examine traffic as it enters the Junos device.
Based on a variety of parameters, the device can separate the packets into different classes of
traffic and place the packets into queues. Packets are also assigned to a forwarding class and can
be given a packet loss priority value.
. . . . . . . . , ;, ............ -
M'>-
D';:lt"lrct {,l~::u:~_~ifi,...~tinn
Chaoter 3-fi
Classification Methods
Junos classification methods:
Fixed classification
Multifield classification
Behavior aggregate classification
Junos Classification Methods

Junos devices support the three methods of packet classification shown on the slide. We discuss
these three methods throughout this chapter.
Chapter 3-6 Pa eke! Classifioation
......... : .. _i ..... "'r .... 0+
Agenda: Packet Classification

1111
~ Forwarding Classes and Packet Loss Priority

!ill
III
III
Forwarding Classes and Packet Loss Priority

n ..... "l u ...+ ""I..,..:-.:-ifi,..~tinn
Chanter 3-7
Forwarding Classes
Forwarding classes:
Determine the queue to which a packet is assigned
.. Map directly to output queues
Assigned to a packet on ingress

MF.or SA classifier assigns .forwarding claSs
.butpl.lt Queu~
Forwarding Class
Qu~ue2
/l!!!!!!!)'"
~
;-l!!!!!!!J-
...
"
QueUe 1
Data
QljeueO
Forwarding Classes
The main function of forwarding classes is to determine the queue to which a packet is assigned. As
a packet enters a Junos device and passes through multifield or behavior aggregate classification,
the device assigns it to a forwarding class. In actuality, the device is placing the packet in a queue.
You can think offorwarding classes as the configuration component that represents the queues .
Chapter 3-8 Packet
Cln~~ifir.::Itinn
Default Forwarding Classes

Four default classes
- Best effort(BE)
t:xpedited forwarding (EFj
-Assured forwarding (AFJ
Note: Default forwarding classes

do not appear in the configuration
- Netwbrk Qbntrol(NC)
uSEjr@j1.1> '. show clas"~of~,,ervice .fol;wardfng-c1ass
jorw;"rcting Class .
best-'sffort
expedited,- fot;warcl,ing
asspred-fo!:'wacpding
Queue.
O
netwotk~contt;ol
Porwardingclasses m;;lpped to Qutput queues.
Four Default Forwarding Classes

The default CoS settings on Junos devices include four default forwarding classes, as shown on the
slide. Notice in the CLI output how forwarding classes and queues are directly related
www.juniper.net
P;::U"!kFlt
r.1~c::.c::.ifif'~ti{\n
Chaoter :l-Q
Configuring Custom Forwarding Classes

Syntax
Example
[edit]
llser-@R1# show dlass-of-service
forwarding,-classes{
plass llestEffort-data queUe'-nt11l 0;
class Priority-datil., qu\"ue.-nt,lm 1;
class Video queue-null 2;
class Voice queue-nuni 3;
:Glaps NG quelle-pull 4;
[edit class-of-servic.e .forwarding-classes]

class.c1p.."s~l'lame qUeue-rllllll q/,lfj1.le-number;
(I
PI~tform support
MS~r[es: up to 4 forwarding clasSe$

up to 4 queues
M120, M:320, MXSeries, T Series, M7i/M10[ with CFEB:..E:

upto 16 forwarding cfasses.-_ _ _ _ _ _ _.....,....._ _-.
.. Up to 8 queues
~
~
Forwardingclasses are global tothe device.
I
II
eI
(]I
eI
Configuring Custom Forwarding Classes
Four default forwarding classes often are sufficient to support a CoS strategy. However, you might
find that the four default classes are not enough, and that you require more forwarding classes. Or
perhaps you want to change the names of the existing classes.
The slide shows the syntax to configure custom forwarding classes. You can use this configu ration to
create custom names for the existing classes (and leave the queue mappings untouched), or you can
create custom forwarding classes and create new mappings to queues.
On some Junos devices, you can create more forwarding classes than queues. In this situation, you
assign multiple forwarding classes to a single queue.
Note that forwarding classes are a global configuration component; the settings in this secti on apply
to the entire device.
Platform Support
The number of forwarding classes and queues supported varies depending on which Junos device
you are using. The slide provides the details.
Chapter 3-10
www.iuniper.net
I
\I
I
I
I
I
Packet Loss Priority (1 of 2)

Loss priority~
[ejentifies a paqket's drop-eligibility
petermineSitheli.Kelihood ofthe, packetbeing dropped unqer
cohge$!ioh
.'\1
Assigned to a packet on ingress

.ofy1l=or BA ClasSifier assigns PLP
Pol!cer catt also assign PLP
.Alsoknown .asdrop precedence

.. Canassighup to four loss priorities
Low. medium-low, medium-high. high
Defaultseftings USe low and high
Loss Priority
Packet loss priority (PLP), also known as drop precedence, identifies a given packet's drop-eligibility.
In other words, it determines the likelihood that a packet will be dropped under congestion. It is
important to note that having a PLP value assigned does not automatically mean that the packet will
be dropped. The PLP provides you with the option to specify that ifthe device experiences congestion
later in the CoS process, it should drop the packets marked with a higher PLP first.
A Junos device can assign a loss priority value (PLP) to a packet as the packet enters the device
using a multifield or behavior aggregate classifier. A policer can also assign the value sightly later in
the CoS process.
The Junos as allows you to assign up to four PLP values to inbound traffic: low, mediu m-Iow,
medium-high, and high. By default, the system uses only low and high.
www.junioer.nAt
P:=Ir;KPt r.1:=Ic:.c:ifir.:=Itinn.
ChaDter 3-11
Packet Loss Priority (2 of 2)

Use as part of a congestion control strategy
lVIarkIower-priority traffic with higher drop eligibility
Helps policers and schedulers to determine which trafficto
drop first
I
~.'
..
'Ililll
"
Drop last
Vojce
Drop first
Data
Part of a Congestion Control Strategy

PLP can be very helpful when building a strategy to control traffic when congestion occurs. When a
device becomes congested you want to ensure that you have ways of specifying which traffic to drop,
and one of the easiest ways to do this is using PLP values. PLP allows you to specify at ingress the
relative importance of given traffic flows, which provides you with options to control which traffic is
dropped should the device become congested.
Note
When using Juniper Networks M320
Multiservice Edge Routers, Juniper Networks MX
Series 3D Universal Edge Routers, or Juniper
Networks T Series Core Routers, and you do not
have tricolor marking enabled (which is
reasonably likely), you must configure PLP within
a multifield classifier.
--------------------------
www.iul.liper.net
41
ill
Default Loss Priority Values

Dependent on CoS val ue
By default. the least Significant bit ofthe CoS value s~ts PLP
0'" IpW, 1'" high
Note: DefaultPLPvaluesdonot
.appearin the configul"atiort
Based on the dElfault qlassifier
.. 000 = low; 001
=high; 010 =, low; and so on
cii;,.s.sifie ~: ipp r:e c-compatiti:i:ilty, Code pdint 'type: inet--'precedElllCe, Index: 13.
COde pOint .
FO'!:wardillg . class
Losspribdty
000
.bef;t~~e:t;fQr:t
:low
001
best,-e:ffott
high
low
high
.oi:i)
un
'qe st~eito2t
b~:5't,-effdrt
.bsst-:Erffotb
10:0
TO:'I.
no
;111
:low
bes.t~e1:fort
p!'!twork:"conttol
petworl<;-cqnj:r:oJ..
.....
high.
lpw
high
, ~~:........
< ... ;,..
................
,- -
'
............."".'""...."............
-.~-,;,~.-
..
~......
,
Default Loss Priority Values Depend on CoS Value

By default on a Junos device, the default classifier sets the PLP value based on the least significant
bit of an incoming packet's CoS field, If the CoS field ends with a 0, the PLP is set to low; if the CoS
field ends with a 1, the PLP is set to high.
The CLI example on the slide shows the default classifier used by Junos devices (we discuss
classifiers later in this chapter). Notice how the loss priority value relates to the code point setting,
following the 0 = low, 1 = high rule.
Note that these are default values, which you are welcome to alter as you desire, using BA or MF
classifiers, or a policer (as discussed later in this chapter and course) .
Oo:o .... \Lot rl~e.c.ifir:=!tinn
Chapter 3-13
,.,

ill
II!
7 Fixed Classification
III
II!
"AU or nothing" qlassifiqation method

.. Coarse, no .granularity
Associated directly to a logical interface or VLAN
.Assigns>8 sihgleforwardingclass
Applies to all ingress packets
torwardingClasses
us,e~:@Rt>,'}s ho~
'c!1.4s's -o_f'-'ser~i-~~
Fi)tw"t~:l.I1g c;la~p
,be!i,t;~efiort;
,e)<,p"dt;,"B3:'~ o~1Iiar.d ;'llg
ass.ur.ect-. forwarding
't?etwoJ::k;--co'nb:q.J:
-forwardirig~'c_las:s
'Queue
.. '
[edi t)
tiset'@Rl,#",show clas,s'-of-ser'V'.L-C'e
inte,r:fEtces {
:1:e-'%1, b {
.unit, 0 {'
f'Qr~ard':Lng--c:~:~~;t~ ;~~,~u,r_~d7
forW"etrd'1ri,Sl: ;
I
)
Fixed Classification-"AII or Nothing" Method

The simplest way to classify incoming packets is to use fixed classification. With fixed classification,
you assign a single forwarding class to a logical interface or VLAN (under the class-of-se~vice
stanza). The device assigns all traffic arriving at that interface to the defined forwarding class, and by
extension to the related queue.
Fixed classification can be a good approach when you specifically want to assign all inbound traffic
from a neighbor to a specific forwarding class and queue. For example, perhaps you have a customer
attached to a given port, and all ofthat customer's traffic should be treated in a specific way. Fixed
classification provides the easiest way to complete this task.
While fixed classification is simple and efficient, it has no granularity. If you require any
differentiation of traffic ingressing the interface, fixed classification will not meet your needs .
Oo/"'!rc+ r.loo:::dfirotinn.
Chapter 3-15

III
III
iii
~
~
ti
ti
-7 Multifield Classification
iii
61
~.i
~
~
~
<I
CD
@
~
. 0.
tJ5jJ
<lID
I)
48
I)
I)
M u Itifield Classlf. cation

Granular classification method
Based on one or more fields in the packet header
Use to assign forwarding class and loss priority
Associaiedto a logical interface orVLAN
~ CanassigndifferenHraffic typesarrivil'1g at an iriterfaceto
different classes
E~i3l11ples Qf MFappncation~:
Assign CoS treatment per customer (network prefix)
Identify and downgrade Web traffic by matching on port SO
ProVide priority treatment for protocol traffic
Assign fQrwatding ..olas$ based oh MACaddtess
Multifield Classification-Granular Method

When you need granular control to apply CoS values to inbound traffic, use multifield classification.
MF classification allows you to match against a variety of fields in a packet header-a source IP
address, for example. When packets arriving on a given logical interface or VLAN match against the
desired parameters, the device can assign a specific forwarding class and PLP value.
MF Application Examples
The slide provides some examples of where multifield classification can be helpful.
0",,.,1 ... 0+ (,I~c:cifi('~tinn
Chapter 3-17
C
(
(
(
((
Configuring Mf Classifiers
Perform MF classification with firewall filters
1. Use firewall filter to assign traffic to forwarding Glasses
based on any header field
2 , Apply the filterto desired interface
Applytoan interface
Definethefilter
[edit firewall. f a m i l y . i n e t j .
j1set@host# 'show filter apply-cos-lI\arkings
te.t:m l\{
......
from t
~...
sJ::H.irce~ad~l=,eSS
J,'
,10:0'.,O.,1~O/24;
....
[edit. interfaces]
user@hostll show ge_O!O!l
unit 0 {
'family inet_ f
f'1
."........
,~,:t7'r',
" .. "' ..... ~.~ .... I! ............. io... .l.'npu-t
l'
.
k'
.
~p.P' y-cds-rna,r l:Iig::l;
'J
address iOd ,0.1.1/24;
}
thep~,~'____~__~______~~~~__~~~
'J
fo "warding-.class expedi ted-fo.rwarding;

?,c-c.ept;
~
~
~
/I
I
\I
.termall,co the r-.t taf fic

. ,th'eri_, Ei"ccepi';
.
MF Classification Uses Firewall Filters

Junos devices use standard firewall filters to perform MF classification. Firewall filters provide very
granular control, allowing you to match against many fields in a packet header.
The configuration process is the same as if you were performing firewall filtering: create a fi rewall
filter, and then apply it to an interface. In the example on the slide, traffic arriving at interface geO/
0/1.0 passes through a filter named apply-cos-markings. Where this filter differs from a
standard firewall filter is within term A. The term's then statement includes a modifying action that
assigns the matching traffic to a specific forwarding class. Traffic not matching this term is still
accepted (by the next term), but it does not receive any CoS treatment.
Note
Traffic that does not explicitly receive CoS
treatment from the device is assigned to the
best-effort forwarding class.
Chapter 3-18 Pac ket Classification
Where to Use MF Classification

Generally apply atingress to network
Logical poihtto use granular controls to classify traffic
CoS markings on inbound traffic do not existor are "untrusted"
CoS Domain
Configuration for PEl

appearsQh the next page
Apply MF Classification at Network Ingress

In general, the best place to use MF classification is at the network edge. In general, :you should
consider traffic that comes from another network untrusted, and as you have little or no control over
it, you cannot rely on any existing CoS values on the traffic. The network edge is also a logical place
to make use of the granular controls provided by firewall filters, allowing you to collect broad or
narrow amounts of traffic and assign them very specifically to forwarding classes and queues .
PEl Configuration Sample

redi t firewall]
llter tlas's-'voice {
[ Build a filter to classify traffic I
voice {
'te.tm
from
,t
protocol. [ udp tcp ];

port 5060;
}
then (
. forwa-rding-'c:lass exp'edited:....f'orwarcting;
accept:
)
te rm 5uppor.t-rtp
from {
pro,tocol, udp;"
port 163.84-32'767;
2.ApplyinbOl.)nd On PEl il1tedace.
~
~
then {
forwarding-class e.Xped;i.ted,- forwarq.in;g;
a,cc',ept ;-
>
[edit]
,i:i).t,erfa,ces {
te.rni. 1",> t (
then accept;
fe~l/1!l,
h:nit
0, {
famiiy inet {
fflter J
I
I
input
class~vQice;
I
address. ,1,92.168. ]'61,.,29/30;

The command output in the slide shows the relevant configuration components for the PEl device in
the diagram on the previous page. In step 1, the firewall filter contains three terms, two of which
contain modifying actions that assign matching traffic to the expedi ted-forwarding forwarding
class. In step 2, the filter is applied to the fe-l/l/l interface in the inbound direction.
(I
{I
{I
(S

III
II!
III
III
-7 Behavior Aggregate
Cla~ssification


.. CoS marking-based classification method
Based on existing. CbS markings
Simple way to classify CoS-marked traffic
.. Directly maps a CoS valweio a forwarding class and loss priority
MoreeffiQient th.an MF ,classifiers; good fQr high-volume

devices
Associated to a logical interface orVLAN
- Treats all packets with a given CoS markingthe same way
.. Does not distinguish traffic based on other headerfields
.. Examples of BA applications:
tI
ProvidecontinLJity of traffic priority across network
(J
(I
-Identify and downgrC;lde traffic based on CoS value
Behavior Aggregate Classification-CoS Marking-Based Method

When traffic coming from a neighboring node already has CoS markings, you can use SA
classification. SA classification can be applied per logical interface or VLAN, and it provides a simple
way to directly map a marked packet to a forwarding class and PLP value.
SA classification is more efficient than MF classification because it requires less packet analysis.
The efficiency benefit makes SA classification a good choice for devices with high traffic vol urnes,
such as routers in a network core.
SA classification is based entirely on existing CoS markings. It treats all traffic with a given CoS value
in the same way; that is, the Junos device assigns all inbound traffic with a given CoS marking to the
same forwarding class and queue.
BA Application Examples
The slide provides some examples of where multifield classification can be helpful .
Chapter 3-22
p;;;:t,....~o::>t ("beeifi ...... +in ....
....
ED
#I
ED
....
....
..
A
(}
CD
o
o
o
.,
.,
..
~.;,~,
'5!11
6)
SA Classification Options
BAclassifiers can I1J q tch against the following
incoming CoS markings:
-IPv4DSCP
IPV6 DSCP
IP Precedence bits
- MPLS EXP bits

~ IEEE802,1p CoS bits
.. IEEE802,1acfdropeligible indicator (DEI) bit
I)
I)
BA Classifiers Match Against Several Incoming CoS Markings

The slide lists the CoS types you can match against when using BA classification.
CD
CD
..
..
CD
CD
CD
..... -_1._ .. "" ___ :"';" .... +; .......
r.h~ntp.r ~_?~
Default BA Classifiers (1 of 2)
.. Primary default SA classifier
By default. all logical interfaces use IP precedence classifier
MPLS-enabled interfaces use default MPLS EXP classifier
user@Rl> show class-of-service interface
Physical interface: ge-1/%, Index: 130
Queues supported: 8, Queues in use: 4
Scheduler map: <default>1 Index: 2
Logical interface: ge-1/0/o.1oo, Index: 141
Object
Name
Type
Classifier
C.fprec-compatibili::> ip
user@Rl>showclass-of-serviceclassifier
Index
13
" ' -_ _ _ _ _ __
41
Classifier:~prec-compatibili~ Code point type: inet-precedence,

Index: 13
Code point
Forwarding class
Loss
priority
000
001
010
011
100
101
110
111
best-effort
best-effort
best-effort
best-effort
best-effort
best-effort
netwot:k-control
network-control
IJ
I
low
high
low
high
low
high
low
high
J1ln rpHnet I 3-24
Primary Default BA Classifier

SA classifiers, in their simplest form, are mappings of code pOints to forwarding classes and PLP
values. The Junos OS provides several default classifiers, but by default all lOgical interfaces use an
IP precedence classifier named ipprec-compatibili ty. This classifier provides basic
capabilities, with only best-effort and network-control forwarding classes. To assign
inbound traffic to other forwarding classes, you must use a different classifier that supports more
forwarding classes.
Note that when MPLS is enabled on an interface, the interface uses the default MPLS EXP classifier
(except on M Series devices with standard, nonenhanced FPCs).
Chapter 3-24 Par.kp.t r.1;:ao;:,c:;ifif"::ttinn
Default BA Classifiers (2 of 2)
Other default classifiers
Several default classifiers exist, but are not used by default
Must be explicitly enabled on a logical interface
user@Rl> show olass-of-service classifier
Classifier: dscp-default, Code point type: dscp, Index: 7
Classifier: dscp-ipv6-default, Code point type: dscp-ipv6, Index:
Classifier: dscp-ipv6-compatibility, Code point type: dscp-ipv6( Index:

Classifier: exp-default, code point type: exp, Index:
10
Classifier: ieeeB021p-default, Code point type: ieee-B02.1, Index: 11

Classifier: ipprec-default, Code point type: inet-precedence, Index:
12
Classifier: ipprec-compatibility, Code point type: inet-precedence"

Index: 13
Classifier: ieee8021ad-default, Code point type: ieee-aD2.lad, Index:
4~
Classifier: ieee8021p-compatibilitYr Code point type: ieee-802.1( Index:
43
f'JW JuolPer,net 1 3-25
Other Default Classifiers

As mentioned on the previous page, the Junos OS provides several default classifiers. Some
examples are shown in full below.
Classifier: exp-default, Code point type: exp, Index: 10
Loss priority
Code point
Forwarding class
000
best-effort
low
001
best-effort
high
010
low
expedited-forwarding
all
high
100
assured-forwarding
low
101
high
assured-forwarding
110
low
network-control
111
high
network-control
..... -
_ ' __ .L
"1 ___ :"': ........ +1,, ...
r.h:::l.nter 3-?1=i
Junas Class af Service
Other Default Classifiers (contd.)

Classifier: ieee8021p-default, Code point type: ieee-802.1, Index: 11
Code point
Forwarding class
Loss priority
000
001
010
011
best-effort
best-effort
low
high
low
high
100
101
110
assured-forwarding
assured-forwarding
network-control
low
high
low
III
network-control
high
Co
ngBA
Default Classifiers
n-
Perform SA classification under the class-ofservice stanza

1. Apply the classifier to an interface (within the clas s-ofservice stanza)
[edit]
show class-of-service interfaces
g e - 0/ 0/ 0 {
unit 0 {
classifie~s {
dscp default;
dscp-:ipv6 default;
expdefault;
ieee-802.1 default;
use~@Rl#
}
}
}
SA Classification Using Default Classifiers

As mentioned previously, all logical interfaces use the ipprec-compatibility classifier by default. To
use another classifier, apply it to an interface within the class-of-service stanza.
In the example on the slide, the ge-OjOjO.O interface has several classifiers applied to it. As the
device receives traffic with existing CoS values on this interface, the system applies the related
default classifier and automatically assigns a forwarding class (queue) and PLP value .
l.i1onnguring
Class cationCustom Classifiers (1 of 2)
Perform BA classification under the class-ofservice stanza
1. Define a custom classifier
2. Apply the classifier to an interface
Apply to an interface
Definethe custom classifier
(within the class-ofservice stan:za)
[edit class-of-serviceJ
user@Rl# show 'classifiers
dscp custom-ipv4-classifier
forwarding-class BestEffort
loss-priority high code-points 000000;
l?ss-priority low code-points 000001;
[edit class-of-service]
user@Rl# show ~terfaces
ge-O/0/3 {
unit 0 {
clas si fie rs
dscp cllstom-ipv4-classifier;
forward.i,ng-class Priority-data {
loss-priority high code-points 000010;
loss-priority low code-points 000011;
SA Classification Using Custom Classifiers

If the default classifiers do not meet your needs, you can create your own custom classifiers under
the class-of-service classifiers stanza. When the custom classifier is fully defined, apply it to
an interface, again under the class-oi-service stanza.
In the example on the slide, a custom dscp classifier has several forwarding classes defined, each
with one or more PLP values. Each entry is also related to a code point value. In practice the process
works somewhat in reverse. The configuration example on the slide essentially says the following:
when a packet with a dscp code point of, for example, 000000 arrives at interface ge0/0/3, assign
the packet to the BestEffort forwarding class with high PLP. The same process applies for packets
with different dscp code points.
Note
If you do not have tricolor marking enabled when
using M320 Multiservice Edge Routers, MX
Series 3D Universal Edge Routers, or T Series
Core Routers (which is reasonably likely), you
must configure PLP within a multifield classifier.
Chapter 3-28
Prli~I.(/::r.t r:1~c:c:ifi,,:::ttil'ln
..
CD
CD
CD
CD
CD
CD
Con gu ng BA Class ca onCustom Classifiers (2 of 2)

"Import" simplifies the new classifier configuration
Imported classifier acts as a template
Can import default or custom classifier
New entries overwrite corresponding imported values

[edi t]
user@Rl# show class-of-service
'classif'iers '{
, exp custom-exp-cl~ssifier {
import defauit;
forwarding-class bes't~effort {
..
'.
f)
c&
loss-priority high Gode-points DOni
+-.......j
Default EXP classifier has low

loss priority for code point 000
[edit]
user:@Rl# run show class-of-service classi~ier name custom":",exp.classifier
'
Classifier: cU,stom-exp.,-ciassifier, Code point type: exp, Index: 31139
Code point
Forwarding class
Loss pc ioc ity
high
000
best-effort
00'1
best~effort
high
Using "Import" to Simplify Classifier Configuration

When creating a custom classifier, it is common to reuse several of the same settings that are found
in the related default classifier of the same CoS type. Perhaps the default classifier works almost
entirely for your needs, and you need to change just two of the settings. In cases such as this, you
can use an existing classifier as a kind of template to simplify the configuration process.
To configure a new classifier that reuses settings from an existing classifier, use the i.mport
statement under the class-of-service classifier stanza and specify a default or custom
classifier to use as a template, and then define custom entries to create your specific requirements.
The result is a merging of the template with the custom entries, with the new entries overriding the
corresponding values in the underlying template.
In the example on the slide, a custom classifier uses the default EXP classifier as a t",mplate.
(exp-default has PLP set to low for code point 000.) In addition, a custom entry specifies that for
code point ODD, the PLP is low. The resulting custom classifier reuses many of the default EXP
classifier's settings, and the explicit configuration statement overrides the default se1:l:ing for code
point 000.
..
~,
.''0.
_.L'_"_
\:
(
(
C
Where to Use SA Classification
Generally within a network
@
~
C;
Leverage traffic's existing CoS values
o\J1
CoS markings on traffic are "trusted"
II!IIi
...
"'.~
'
. Cos Domain
"
Apply behavIor
"
'
(Ii
41
aggregates toward
domainingr,ess .." ....,'I~i~;,;::::;-~
~
~
~
Apply BA Classification Within a Network

In general, the best place to use BA classification is within a network. Because traffic has already
passed through your edge network device, you can trust any CoS values on packets. Furthermore,
you can leverage the traffic's existing CoS values and use the more efficient BA classification
method to minimize the CoS processing workload on the other devices in the network,
it
PE2 Configuration Sample

1, Definebehailior aggregates to match rewrite rules
..
I>
[edit ,class-,of-serv;Lce]
ciassi,ti,ers {
,
cis c;p voice {
i,mport default;
forwarding-Cla.ss b(ijst-effort {
,loss~pri()rity low code-,points 000 QOO;
loss-pr;Lqr::i,t;y high,' cqde~po;Lnts O(jOOQ1-;
[edit c1-ass-of-servicel
inte!?faces
fe-l/l/l {
unit, Of
C;lassfi'il rs {
d"" ,"p voice;
}
}
}
fe~3/,014
unit 0 {
claSSIfiers {
dscp voice;
Default D8.CP clqssifierhaslow ,

loss priority for code point OOOQOl
2. Apply them to interfaces facing

the CoS domain ingress.
}
}
PE2 Configuration Example

The command output on the slide shows the relevant configuration components for the PE2 device
in the diagram on the previous page. In step i, a custom classifier uses the dscp def;ault classifier
as a template, along with two customized settings. In step 2, the fe-i/i/i and fe-3/0/2 interfaces
perform BA classification using the custom classifier.
Applying Multiple BA Classifiers

.. Guidelines:
Can configure multiple BA classifiers for a logical interface,
but ...
Support for various combinations varies
Highly hardware-dependent
-Based on PIC, FPC. platform capabilities
Referto theJut)os Class of Service Configuration Guide for

detailed information
Guidelines When Applying Multiple BA Classifiers

In general you can configure multiple SA classifiers on a logical interface. However. many variations
and restrictions exist for what is supported on a given platform. Often the hardware installed in a
chassis is also a factor. For detailed information on supported SA classification combinations for a
given platform. refer to the Junos Class of Service Configuration Guide.
Chaoter 3-32 P:::.,....!,.o.+
f'1",~ ...i-Fo ........ +;,.. ....
Mixing MF and .BA Classifiers

@
@
@
(I
.,.,
.,
.,.,
.,.,
.,
.,.,
""
Guidelines:
Oanapply both to
an interface
BAciassification is performed first, then MF classification

If both ciassifiersmatch traffic, MF classifier overrides SA
clasSifier
I>
Guidelines When Mixing MF and SA Classifiers

You can apply both MF and BA classifiers to a logical interface. Because BA ciassifica1:ion is
performed before MF classification, the latter overrides the former if a conflict occurs_
8)
Summary
.. In this chapter, we:
Identified the purpose of packet classification
Described and configured forwarding classes
Described and configured fixed, multifield,and behavior
aggregate classification
Identified and cohfigured default and custom classifiers
I
II
~
I
41
\I
I
et\)
~
iJ
iJ
The purpose of packet classification;
Describing and configuring fixed, multifield, and behavior aggregate classification; and
Identifying and configuring default and custom classifiers.
CD
Chapter 3-34
P.:=Ir-Vot rl-:oC"C"ifi" ....... l" ...
..
(I
Describing and configuring forwarding classes;
Review Questions
1. To what do forwarding classes map?
2. Whatis the benefit of packet loss priority?
3,How do you configure and apply MF classificatiqn?
BA classification?
4. Where do you generally use
01 assification?
MF classification?BA
5. Which occurs first, MF or BAclassification?

6, Which is the primary defaultSAclassifier on Junos
di9vices?
Review Questions
1.
2.
3.
4.
5.
6.

- Configure forwarding classes.
- Configure fixed classification.
-Configure SA classification.
- Configure MF classification.

The slide lists the objectives for this lab.
Chapter 3-36 P:::r, .... I,"'+ 1'"'1 .......... ,4=; ......... : ... _
"
cD
(I)
G
I)
I)
Chapter 4: Policing
''':
Chapter Objectives
able to:
Identify the purpose of policing
Listthe policing methods available on Junos devices
Describe and configure two-color and tricolor marking
policers
Apply policers directly on an interface
Apply policers within a firewall filter
The purpose of policing;
The policing methods available on devices running the Junos operating system;
Describing and configuring two-color and tricolor marking policers;
Applying policers directly on an interface; and
Applying policers within a firewall filter.
Chapter 4-2 Poli,...ind
Agenda: Policing
~ Policing
Overview
Sfngle-RateTwo-Color Policer
Tricolor Marking PoIicers
Application--Directly on an Interface
Application-Within a Firewall Filter
Policing Overview
The slide lists the topics we discuss in this chapter. We discuss the highlighted topic first .
CoS Processing-Policing
Ingress
~.
Egress
,,,,,,,---, "-
........ ,
......
_-'"'
,.
/'
CoS Processing-Policing
Policing follows classification in the CoS process. Once packets receive forwarding class and packet
loss priority (PLP) information, the Junos OS can apply ratelimiting using a policer.
Chapter 4-4 Pnli,..inCf
_ ....
t.
,_~
........ ........ ...
~
'\j
@
@
@
@
cD
cD
Policing Overview (1 of 2)
Role of policing:
Firststage of congestion management
"Pre-emptive" cpngestion management
Apply bandwidth constraints for incoming (or outgoing)

traffic
Traffic conditioning
Enforceservice~l.eVel
agreements
Define traffic as in~profjle .or out-Pf-proffte
Determined by corifigurablethre$ho[ds
.. Alsoknovyn asrate-Hmitlng
PoliCing is disabled by default.
VIII
CD
..
"
Role of Policing
The primary function of pOlicing is to provide a first stage of congestion management. With poliCing,
you can condition incoming or outgoing traffic by applying bandwidth constraints. Policing is an
excellent way to control the amount of traffic entering your network, and allows you to enforce
service-level agreements .
Policers provide configurable thresholds that allow you to create two categories of traffic. Traffic that
is within the threshold limits is referred to as in-profile; traffic that exceeds the thresh old limits is
referred to as out-of-profile.
Policing is sometimes also known as rate-limiting.
Policing Overview (2 of 2)
How policing works:
Uses two primary elements, in combination
.. Bandwidth threshold and maximum burstsize
Can manage traffic that exceeds boththresholds
Uses token-bucket algorithm

.. Accommodates some burstiness before affecting trClffic
Two configuration options
41
.. Apply directly to an interlace
Apply Within a firewall
II
tI
tI
How Policing Works

Policing is based on a token-bucket algorithm. Unlike a leaky-bucket algorithm, the token-bucket
method allows for a certain amount of burstiness before taking action on traffic that exceeds
configured thresholds. Policers on Junos devices generally consist of two primary elements: a
bandwidth threshold and a maximum burst size. The bandwidth threshold defines the acceptable
rate fot a given flow of traffic. When traffic exceeds this rate, it is also allowed to burst beyond the
threshold for a certain period of time. When a sustained burst of traffic exceeds both thresholds, the
device takes action on the out-of-profile traffic.
There are two general configuration options for policers on Junos devices. You can create a policer
and apply it directly to an interface, or you create a policer, use it as an action within a firewall filter,
and apply the filter to an interface.
Chapter 4-6 PoH";nd
CD
CD
(8
.,
(I
....
..
(I
(8
(8
(8
(8
Policing Methods
Soft-policing
Traffiq into PQlicer
When a packet is out-of-profile:

Assign packet to afofwardingclas$
or
Assign a PLP value, whiCh can b.eU$ed
b.y schedulers later in the CoS process
to drop pacKets whE;ncongestiohPc:curs
Soft-policing
Hard-policing
WHenapack\3t is out-of-profile:
Drop it
Ha.,'.,
rd-poljCillg
.
"
Soft-Policing
You can configure the Junos OS to take action on packets that are out-of-profile. One option is to
allow the traffic to enter the device and assign it to a specific (usually less preferable) forwarding
class. Another option is to allow the traffic and give it a specific (usually less prefera bl e) PLP value.
These are examples of soft-policing, as they simply modify traffic.
Hard-Policing
A more harsh policing option is to drop any traffic that exceeds the configured thresholds. This is an
example of hard-policing.
O ... U.....i ... rr
Chaoter 4-7
(
Types of PoUcers
The Junos
as supports the following policer types:
Single-rate two-color
standard policer
.. performssoft-poHcing or hard-policing
C!!
<1i
Single-rate tricolor marking
II
.. Markingpased on burstthresholds
..
(
(
(
(
Perform$soft~policingonly
Two~ratetricolor marking
Marking based on bandwidththreshotds
.. Performs soft-policing only
@
@j
Q
The Junos OS Supports Several Policer Types
The slide lists the policer types supported by Junos devices. Note that not all Junos devices support
tricolor marking. These policer types are explained in more detail later in this chapter.
Chapter 4-8 POlici n"
Policing Parameters
Policing includes up to four parameters:
Committed inform(3tion rate (CIR)
Guaranteed data rate for traffic sentthrough the policer
Measured in bits per second
Peak information rate (PIR)

Maximum data rate for traffic sent through tl,epolicer
Measured in bits per second
Committed burst size (CBS)

.G qaranteed humb.et qfbytepthat can pass througl, the poUGer
durihga lJun~t
Measl.!redih bytes
.. E~cessburst size (EBS)or peak burst size. (PBS)

Maximum number of bytes that can passthrou&h the pollcer during
.a burst
Measured in bytes
Four Parameters for Policing

Policing involved up to four parameters, depending on the policer being used. The committed
information rate (CIR) and peak information rate (PIR) relate to bandwidth thresholds, measured in
bits per second. The committed burst size (CBS), excess burst size (EBS), and peak burst size (PBS)
relate to burst thresholds, measured in bytes. These concepts are discussed in more detail later in
this chapter.
Pnll"ind'
Chapter 4-9
Agenda: Policing
III
Policing Overview
-7SingJe-Rate Two-Color Policer

III
Tricolor Marking Policers
Application-Directly on an Interface
iii Application-Within a Firewall Filter
III
eJ
(I
Single-Hate Two-Color Policer

CIt
Chapter 4-10 POlicin!!
Ai
Single-Rate Two-Color Policer

Standard policer
One rate threshold
CIR....,guaranteed.d<;lta rate: bits per second
One burst size threshold, creates two colors

CBS-guaranteed bytes during a bUrst
TrafficexceedingCIR + CBS can be marked or discarded

Soft-policing or hard~policing
Standard Policer
A single-rate two-color policer is the most commonly used policer. It consists of one rate threshold,
CIR, and one burst size, CBS. When traffic exceeds the configured bandwidth threshold with a
certain amount of burst data, the traffic can be marked or dropped.
.,
....
..
~
Pnlirind
.,
Chapter 4-11
COn'f..I~"",ring a
Single..Rate Two-Color Policer
(1 of 2)
if-exceeding
bandwidth-limit (bps)
Min. = 32 Kbps; max.
= 40 Gbps
Min. 8 Kbps for M120, M320, and MX Series routers
burst-size-limi t (bytes)
Recommended burst size = int. bandwidth x allowable time
for burst traffic / 8
Syntax
Use 5 ms as a starting point
Alternatively, use MTU x 10

Max. = 12.5 MBps (100 Mbps)
[edi t firewall]
policer policer-name {
if-exceeding {
bandwidth-limit ~ps;
burst-size-limit bytes;
}
then {
policer-action;
}
Configuring a Single-Rate Two-Color Policer: Part 1

The slide shows the syntax for a standard pOlicer. The i f -exceeding section contains the CIR and
CBS parameters, while the then section contains the action to carry out if traffic has exceeded the
thresholds. Ranges for the statements are also shown above.
A good way to determine the value to use fortheburst-size-limit is to multiply the bandwidth
of the interface by the amount of time you are willing to allow traffic to burst beyond the CIR.
Because the burst size value is in bytes, you must divide the product by eight. Alternatively, you can
use ten times the MTU of the interface.
The Junos as also supports policers that rate-limit traffic based on a percentage of physical port
speed on an interface. However, there are several limitations with this method: you cannot rate-limit
based on bandwidth percentage for aggregate, tunnel, and software interfaces; the bandwidth
percentage policer cannot be used for forwarding table filters; and bandwidth percentage policers
can be used only for interface-specific filters.
e
e
.,
....
..
....
Chapter 4-12 Policing
~le"K::;m,,...
nfigurlnga
(2 of 2)
TwoColor Po ieer
.. then
Discard
Set forwarding class
Example
Set PLP
[edit firewall]
policer sample-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 62500;
then. {
discard;
}
}
Configuring a Single-Rate Two-Color Policer: Part 2

The slide shows an example of a standard policer. In this example, traffic that exceeds 1 Mbps by an
amount greater than 62.5 kilobytes is discarded by the policer. The slide also shows the action
options for traffic that exceeds the thresholds.
Note
The losspriority action is supported only on
Juniper Networks MX Series 3D Universal Edge
Routers, Juniper Networks M120 and M320
Multiservice Edge Routers, and Juniper
Networks M7i and M10i Multiservice Edge
Routers with the Enhanced CFEB (CFEBE).
D"'li .... intf..
Chanter 4-13
Agenda: POlicing
II
Policing Overview
II
Single-Rate Two-Color Policer
~Tricolor
Marking Polieers
i
41
I
I
II Applioation-Within a Firewall Filter
II
41
CJ
Tricolor Marking Policers

Chapter 4-14
Po/idn~
Single-Rate Tricolor Marking Policer

Marking based on burst thresholds
One rate threshold
CIR~guaranteedc!Glta rate: bits. per second
.,<I
Two burst size thresholds, creating three colors

CBs-guaranteedbytesdurit)ga bllrst
-EBS-maximum I:lytesdufingaburst
MarKings:
BeloW CBS
= green = low PLP
ExceedCBS,belowEBS '" yellow =medium-high PLP

ExceedEBS='red =;highPLp
No packet discard
Marking Based on Burst Thresholds

Single-rate tricolor marking (srTCM) policers are designed to affect traffic based on bu rst thresholds.
Defined in RFC 2697, the policer uses one rate threshold, the CIR, and two burst size thresholds, the
CBS and EBS. If a packet exceeds the CIR, it is evaluated by the CBS. If the packet does not exceed
the CBS threshold, the packet is said to be green, and the device configures the packet with low PLP.
If the packet exceeds the CBS threshold but not the EBS threshold, the packet is said to be yellow,
and the device configures the packet with medium-high PLP. If the packet exceeds the EBS
threshold, the packet is said to be red, and the device configures the packet with high PLP.
Note
To mark packets with medium-low loss priority,
you must configure a two-color policer and apply
it along with the tricolor marking policer.
..... " h ..... : __ _
Two ..Rate Tricolor Marking PoUcer

I(
Marking based on bandwidth thresholds

Two rate thresholds, creating three colors
CI R-guaranteed data rate; bits per second
PI R.,...maximum datg rate; bits per second
Two burst size thresholds

CBS-guaranteed bytes during a burst
PBS-maximum bytes during a burst
Markings:
Below CIR = green= low PLP
ExceedCIR, belowPIR "'yellow = medium-highPLP
Exceed PiR= red = high PLP
No packet discard
Marking Based on Bandwidth Thresholds

Two-rate tricolor marking (trTCM) policers are designed to affect traffic based on bandwidth
thresholds. Defined in RFC 2698, the policer uses two rate thresholds, the CIR and PIR, and two
burst size thresholds, the CBS and EBS.
If a packet exceeds the CIR in a tworate policer, it is evaluated by the ,CBS. If the packet does not
exceed the CIR+CBS threshold, the packet is said to be green, and the device configures the packet
with low PLP. If the packet exceeds the CIR+CBS, it is evaluated against the PIR, and if necessary the
PBS. If the packet does not exceed the PIR+PBS threshold, the packet is said to be yellow, and the
device configures the packet with medium-high PLP. If the packet exceeds the PIR+PBS threshold,
the packet is said to be red, and the device configures the packet with high PLP.
Note
To mark packets with mediumlow loss priority,
you must configure a twocolor policer and apply
it along with the tricolor marking pOlicer.
Chapter 4-16
Pniir.:im:f
..-:~~
. "" ......
'd
CD
G>
{;"i\
.
'li:J
{;"i\
Tricolor Marking Modes (1 of 2)
'\(;.:;J
G>
~
@
.,
.,"
.,
.,.,
.,
..
Color-blind
reM policerqoes not consider any previous packet coloring

~
PEP
Color
I}
CD
CD
-~~
~~
I,
Meaning
I,
Green
low
packetdoesnote)(ceed the CBS.
Yellow
medium-high
Packete)(ceeas the CBS but does notexpeedthe EBS.
.Red
hig,h
Packet exceeds theEBS .
,
I
Color
PEP
I'
I
I
Meaning
Green
loW
Packet does note)(ceed the.C.IR.
Yellow
medlum'high
PaCket e)(Qeeds the CIRbljt does. notexceeq the pi R.
Red
high
Packet exceeds the' PIR.
Color-Blind Mode
When a tricolor marking policer operates in color-blind mode, the policer does not consider any
previous coloring of packets. Any previous settings are ignored, and packets passing through this
policer are given PLP values based only on this policer's settings.
CD
Dnli ...inrl.
Chanter 4-17
(
(
(
Tricolor Marking Modes (2 of 2)
C
~
Color-aware
TeM policer considers previous packet coloring

Policer can increase PLP, but never decrease it
Example: Yellqw packet can stay yellow or become. red,

but never green
. I packet i
i Metered. 1
Incomll1g
I
low
(green)'
CBS and
Packet does-not excBedlhe CBS.
EBS
low
PLP
'AgSlrm
low
-CIR'and
(gre,en>
!='IR
@J
II
Scenanos
PacketdoBS riot'exc~edtlle blR.
outgmng
PLP
1m";'
medlumlow
(Y,BJlOW)
medlum-
medlum-
EBS only
high
hlgJJ
(yellow)'
(y.llow)
Color-Aware Mode
When a tricolor marking pOlicer operates in color-aware mode, the policer considers any existing
coloring on a packet Packets' PLP values are based on a combination of previous values and the
result of passing through this pOlicer.
It is important to note that a color-aware policer can increase the PLP value, but never decrease it A
green packet can stay green or become yellow or red. A yellow packet can become red but never
green. A red packet can only remain a red packet. A packet can never gain better preference when
passing through this policer.
Note
The incoming PLP values shown in the tables on
the slide would have been set at the
classification stage.
Chapter 4-18 Pol; "'n~
Platform Support for Tricolor Marking

TGM is supported on the followingJuniper Netwqrks
devices:
M120 Multiservice Edge Routers
M320 MUltiservice Edge RoutersWith Enhanced II Flexible
prc Concentrators (FPCs)
.. tSeries Core Routers with Enhanced 11 FI.exible PIC
Concentrators (FPCs)
MX Series 3D Universal Eczlge Routers (ttTCM only)
T64Q Core. Routers with Enhanced SQaHhg~ PPC4

.. M7i/M10i Multiservice Edge Routerswith Enhanced CfEB
(CFEB~E)
Platform Support for TCM

The slide lists the platforms that support tricolor marking.
Pnlir.in~.
ChaPter 4-19
Enabling Tricolor Marking

Tricolor marking might or might not be enabled by
default
Enabled by default on M120 and MX Series routers
For other platforms, include the tri -colqr stCltement

[editclai3s-of-service]
t'r'i-c'o'lot'r
Tricolor Marking Might Need to Be Enabled

Tricolor marking is enabled by default on M120 and MX Series routers. However, for the other
platforms mentioned on the previous page, you must explicitly enable tricolor marking using the
tri -color statement.
Chapter 4-20 Policin~
Configuring a Tricolor Marking Policer

Syntax
Ranges
[edit firewall]
t,hree~QPlor~policer: poliGer:~nam~
sin91e~ t'ate {
ebps
Min. ~.1500
(colpt~awaie
IColor-blirrd);
coIilmitt,ed-i\lformortio\l-r-ate bps.;
col\llfd.tt'ld-bll!cst, siz'l bytl's;
e~Gess-bUrl5t-5ize
bytllll;
}
tliro":rorte {
tCQl(Jr.~aw.are
Ico;Lor,b;Lind):;
cOl\llfd.tt'lcl"":inf orm~tion- rat~..bps;

qommitted-Qurst-siz e . .pyte'1;
.. Max. = 100g
e
bytes
Mih. =1500
~.
Max. = 100 g
peak-.informatiot\-rate' bp'1";
.peak-:burst~size byte"'~
}
Configuring a Tricolor Marking Policer

The slide shows the syntax for both single-rate and two-rate tricolor marking policers. Note
that you configure tricolor marking policers under the three-color-policer section of the
firewall stanza.
The ranges displayed on the slide apply to all configuration parameters .
Pnlir.int:r.
Chapter 4-21
Rate-limiting sing a
Policer
ng
cOlorM
Hard-policing option for tricolor marking policers

Option to discard traffic
Requires action and logical-interface-policer
statements
Supported on:
M120
M320 with Enhanced III
FPCs
MX Series with Dense Port
Concentrators (D PCs)
M7ijM10i
Syntax
[edit firewall]
three-color-policer trtcm-l {
actlon {
loss-priority high then dlscard;
logical-interface-policer;
two-rate {
color-blind;
committed-information-rate bps;
committed-burst-size byte 5;
peak-informgtion-rate bps;
peak-burst-size bytes;
}
Discarding Traffic Using a Tricolor Marking Policer

Although tricolor marking pOlicers are generally soft-policing in nature, there is an option to discard
traffic. When you aggregate a pOlicer across an entire logical interface, you can add an action to a
tricolor marking policerthat drops traffic with a PLP value of high. To enable this feature, include the
action statement and the logical-interface-policer statement.
The discard option adds rate-limiting capability to tricolor marking pOlicers.
Chapter 4-22 Policing
C
C
G
C
C
G
@
~
fi
.~
\1J
\1J
<I
<I
Agenda: Policing
Polioing Overview
III Single-Rate Two-Color PoliceI'
III
!IIi
Trioolor Marking Poli.oers
~Application~Directlyon an Interface
III
The slide highlights the topiC we discuss next.
Dnli,..ind _
Chaoter 4-23
Interface Policers
Can apply policers directly to an interface
Not part of a firewall filter
Can be applied per:
Protocol family
I
I
Logical interface
Physical interface
Can apply input and output policers
e
Ell
<I
Applying Policers Directly to an Interface
(I
One method of using policers is to apply them directly to an interface. You can apply policers per
protocol family, logical interface, or physical interface. You can also apply policers in the inbound or
outbound direction.
(I
(I
(I
Chapter 4-24 POlicin!!
standard Interface Policer

.. Standard policer
[edit]
useo@Rl# show firewall
policer int-policer {
i f~ exceed ing {
bl'lndwidth-i;lmit 100m;
o
.,
..
..-..-.I)
I)
Two-color policer (not

tricolor rna rker)
Applied per protocol family
on the interface
burst'~size-ol;lmi:b 2~Ok;
then fOI:VJarding,-cl'ass 'best'-eifort;
[edit]
li$et@~l-
.. Configuration
# s~ow inter~at::es
ge-'O!O/Oo{
unoLtO (
o
fa~ilY inet ('
0
1. Create the policer
pq
:,inp)Jt int'-pqlic;r;
2. Apply to interface; under

protocol familY
~ceo{
J
)
(a!\til,,, in et6 t'

polLcer{o
o
J:n;p~t ~nt,'-;pql,ic,~~';
Bandwiclth tbreshold = 100 Mbp~pe~ protocol family
(I
Standard Policer
The typical two-color policer is fairly easy to configure and apply. Once you create the policer, apply it
directly to the protocol family of the desired interface. In the example on the slide, a policer named
int-policer is applied to two protocol families under the geO/O/O.O interface. Traffic for each
protocol family has a bandwidth threshold of 100 Mbps.
CD
4
4
Ie
Logicallntetface Policer
Aggregate policer
.Two-colorpolicer
Applied per protocol family
on the interface; merged per
logical interface
Aggregates all protocol families
underone policer
[edit]
user@Rl# show firewall
policeI:' int-' eli'cer
logical-interface- olice!:;
~.f-exceedl.ng
bandwidth-limit 100m;
buq,t"size-liinit 250k;
t1)en .fotwarding-class be?5t:--efforti

[edlt]
u$er@~l,
# ,~how interfaoes
g,,-O/O/O {
unit 0 {
family inet {
GonfiglJration
ppll.'ce~
, i'hj:mt irit-P6J'i'cer':;
1. Createthe policer
Include logical-interface}:lolicer statement
int-policer;
2. Apply to interface, under

protocol family
t!
(J
-)
\I
(J
(J
Logical Interface Aggregate Policer

By default, the Junos as creates a separate instance of the pOlicer each time you apply it to a
protocol family. However, you can combine policers together to form a single aggregate policer under
a single logical interface. To use this feature, ad(j the logical-interface-policer statement
to the policer configuration.
In the example on the slide, the policer is again applied directly to the protocol family of the desired
interface. However, because the policer contains the logical-interface-policer statement,
the two policers under ge-OIOIO.O are aggregated into one. Instead of a bandwidth threshold of 100
Mbps per protocol family, the threshold now applies to traffic for both protocol families combined.
Chaoter 4-20
p~,,-,-"
....
<8
<8
<8
<8
<8
Agenda: Policing
.,
III
Policing Overview
III
Single-Rate Two-Color Polioer
III
Trioolor Marking Polioers
Application--Direotly on an Interface
-7Applioation-Within a Firewall Filter
III
I)
frill
m

C
C
C
C
Policing Using a Firewall Filter
Can apply policers using a firewall filter
Qil
Nontermihating action under then statement
Can be applied per protocol family
~
~
Can apply input and output filters
"
(i
tl
~
~
(I
Applying Policers Using a Firewall Filter

Another method of using policers is to reference them within a firewall filter, and then apply the filter
to an interface. You can apply pOlicers per protocol family within a filter, and apply the filter to an
interface in the inbound or outbound direction.
Chapter 4-28 Poli~in~
ngle..
or Po cer
in a
Firewan FUtel\-Hard ..Policing Example
firewall I
pO,licer hard-traff ie-policer
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 3k;
)
then Idiscard ;1
)
fam ily inet {

filter hard-filter
term A {
Out-of-profile
traffic
from {
source-address {
192.168. L 0/2 4;
--t..... I
Discardl
then {
policer hard-trafficpolice!:';
term all-ether-traffic
then accept;
In-profile traffic
IAccept I
Single-Rate Two-Color Policer-Hard-Policing Example

The slide shows an example of hard-policing using a singlerate two-color policer. In the example, a
policer named hard-traffic-policer has a CIR of 1 Mbps and a CBS of 3000 bytes. A firewall
filter named hard-fil ter matches packets from the 192.168.1.0/24 network and sends them to
the policer. If, after going through the policer, a packet is in-profile, the policer returns the packet to
the filter where the packet is accepted. If the packet is out-of-profile, the policer drops the packets .
Dnli"inCf _
Chaoter 4-29
Slngle.. Rate Two-Color Policer Within a

firewall Filter SoftPolicing Example
ficewall {
policer soft-traffic-policee
if-exceeding {
bandwidth-limit 1m;
then Ifocwacding-class best-effoct;1
family inet {
filtec soft-filtec {
term A {
from {
e
Out-of-profile
traffic
source-address {
192.168.1. 0/24;
}
- ...l1li"'1 Best effort]
then {
olicer soft-traffic'- olicer:
forward1ng-class expedited-forwarding;
accep ;
term all-other-traffic
then accept;
In-profile traffic
IExpedited forwarding I
i
I
I
<I
<I
Single-Rate Two-Color Policer-Soft-Policing Example
..
(I
The slide shows an example of softpolicing using a singlerate twocolor policer. In the example, a
policer named soft-traffic-policer has a CIR of 1 Mbps and a CBS of 3000 bytes. A firewall
filter named soft-fil ter matches packets from the 192.168.1.0/24 network and sends them to
the pOlicer. If, after going through the policer, a packet is in-profile, the policer returns the packet to
the filter where the packet is assigned to the expedi ted-forwarding forwarding class and
accepted. If the packet is out-of-profile, the pollcer assigns the packet to the best-effort
forwarding-class.
cD
cD
Chapter 4-30 Poll r.in~
Filter"Specific Policer
[",ditj
tiser@Rl# show firewall

pblicer- int- olice
f~ ter...;s eel 1.
1. ..... exceedl.ng {
):i.'!ndwid1;-h-l~it 100ro;;
Aggregate poUcer
e
.,e
.,
..
~
I)
Two-col.or policer (nottricolor

marker)
-Applied pE;rterm. per protocol
farnlly; merged per filter
;2S0.k;
burst-slZ~.:..:_tl.mlt
then
.. discard;
...
'
family inet, {
. fil,teJ:'" fil~eI>.. ~.pecific {

term A{
'from {
-soutce...;a(~dres's
192.16.8.:L.0/24;
Aggregates all terms with

policer action into one palicer
)
Configur~tion
term 13 f
from {
- -. scnitc:'e,-addtess -{:
1. Create thepoHcer
.' Include fil t:erH3'pecif]:,c
W2,16B'.:Z.0l24;
)
thel'=i~=~=~===
sta~ement
2. Apply to firewCjIl terrns as

needed
renm.'~;PElcitiicPolicer is. defal.Jlt
sel:tihs:f\l~ithlrn
a firewall filter.
polil~ed. terms
\".~ww
Junlptrnel 1 431
Filter-Specific Aggregate Policer

By default, policers used within firewall filters are term'specific, meaning the system creates a
separate instance of the policerfor each term where it is applied. However, you can combine policers
together to form a single aggregate policer under a single filter. To use this feature, add the
f i l ter-specific statement to the pOlicer configuration.
In the example on the slide, the policer is applied as a nonterminating action to two fi Iter terms.
Because the policer contains the filter-specific statement, the two policer references within
the filter are aggregated into one. As a result, instead of a bandwidth threshold of 100 Mbps per
term, the threshold now applies to traffic matching both terms combined.
Applying a Two-Color Policer Within a

firewall filter to an Interface
Assign the firewall filter to an interface
Policers are useless until you apply them
inte r-face 5 {
ge-O/ %
{
unit 0 {
family inet {
filter- {
input har-d-filter;
}
}
}
}
}
Assign the Firewall Filter to an Interface

Once you have finished configuring two-color policers and referencing them in firewall filters. you
must then apply the filter to one or more interfaces. This is a critically important final step. as no
pOlicing occurs unless the filter is applied to the interface.
Chapter 4-32 Pali dn~
Single"Rate Tricolor arking

a Firewall Filter Example
thin
fir:ewall (
.,
..
..
three-color-policer srTCM-A
single-rate)
colot-blind
committed-information-rate 500m;
committed-burst-size 1m;
excess-burst-size Sm;
family inet. {
filter: TCM-filter:
tem A {
then {
.th-ree'-co lor-po licer
sing 1e- rate s rTCM-A;
"I
Traffic> EBS
Traffic < CBS

}
PLP = low
CBS < Traffic
PLP = high
< EBS
PLP = med-high
Single-Rate Tricolor Marking Policer-Example

The slide shows an example of soft-policing using a single-rate tricolor marking policer. In the
example, a threecolor-policer named srTCM-A has a CIR of 500 Mbps, a CBS of 1 M B, and an EBS
of 5 MB. A firewall filter named TCM-fil ter matches all packets and sends them to the policer.
The policer assigns each packet a PLP based on which burst threshold the packet exceeds (if any).
No traffic is discarded; all packets are accepted for further CoS processing.
TwoRate Tricolor Ma ng PoUcer Within a

Firewall FUtel'l-Example
firewall {
three-color-policer trTCM-A
two-rate}
color-blind
committed-information-rate 500m;
committed-burst-size 1m;
peak-inforMation-rate 750m;
peak-burst-size Sm;
E2
t
t
family inet {
filter TCM-filter
term A {
then {
th ree-co lor-po liceT
two-rate trTCM-A;
Traffic < CIR
PLP = low
"
Traffic> PIR
=highl
CIR < Traffic < PIR
PLP = med-high ]
The slide shows an example of soft-policing using a two-rate tricolor marking policer. In the example,
a three-color-policer named trTCM-A has a CIR of 500 Mbps and a PIR of 750 Mbps, as well as a
CBS of 1 MB and a PBS of 5 MB. A firewall filter named TCM-fil ter matches all packets and
sends them to the policer. The policer assigns each packet a PLP based on which bandwidth
threshold the packet exceeds (if any). No traffic is discarded; all packets are accepted for further CoS
processing.
Pol i,..il"'lt'f
~
(I
(I
Two-Rate Tricolor Marking Policer-Example
Chapter 4-34
"
@
CD
CD
(IT)
~
~
~
Applying a
color Marking Policer
Firewall Filter to an Interface
II
na
Assign the firewall filter to an interface
interface s {
ge-O/ %
unit 0 {
family inet {
filter {
linput TCM-filter
)
}
}
}
6)
..
Applying the Firewall Filter to an Interface

Once you have finished configuring tricolor marking policers and referencing them in firewall filters,
you mustthen apply the filter to one or more interfaces. This is a critically important final step. as no
policing occurs unless the filter is applied to the interface.
Onli,..inrl".
r:h:;:mter
4-~fi
C
C
(......::
Physical Interface Policer (1 of 3)
C
-",'
C'.
Aggregate policer
r:\t
Two-color policer or tricolor marking poliGer

Applied per term, per protocol family within a firewall filter;
merged per physical interface
( ..
Aggregates all logical interfaces and protocol families under one
policeI'
Can use across routing instances
t
tI
~
~
Physical Interface Policer Configuration: Part 1

A physical interface policer allows you to combine policers together to form a single aggregate policer
under a single physical interface. This feature is useful when you want to perform aggregate policing
for different protocol families and different logical interfaces on the same physical interface.
Because the policer operates at the physical level, you can also include interfaces from different
routing instances.
Physical interface policers are achieved using firewall filters to reference policers that include the
physical-interface-policer statement.
Chapter 4-36 Pnlil'inc:1
til
<I
.,.,
.,
(I
(I
(I
(I
(I
Physical Interface Policer (2 of 3)

[edit]
Configuration
i. Create the pollcer

olncludephysical-
interface-pOliter
statement
2, Create the filter

InclUdephysical-
usel:'@RliI show fil:ewall
policer int-policer {
phyncal-J..nterface polLeer:;
1., ..... e,xc e In
bandwidth-limit 100m;
burst-size.-limt 25.0k;
}
tpen forwarding-c:lass
best~effort;
.farriily ihet{
filter Ii s-iht-filter '{
physical ~'i:ritetface.'-'filte t;
erm .A .{
interfa.ce-filter
then~~I~~~~~~~~~
pO J..cer:.J..n
statement
acce'pt;
3. ApplY to firewall terms as
}
}
needed
.,.,
.,
'.

In the example on the slide, the policer contains the physical-interface-poli cer
statement, while the filter contains the physical-interface-fil ter statement. The filter
references the policer as a nonterminating action for term A.
c:
Physical Interface PoUcer (3 of 3)
J:
'(:
.. Configuration (contd.)
4. Apply to interface, under
protocol family
[edit]
ll5,e,r@Rl # show interfaces
ge-'O/O/O {
unit 0 {
family ,inet i
f ~lter {
in,put phys-'in1;:-filter:;
}
fanlily inetiS {
f~lter {
input phys-int:... filter';
unit 1
family inet{
filte.r {
.lripu_t 'phys-:irtt- fii ter.;
Bandwidth threshold = 100 Mbpsperphysical interface

famTl inet.6 {
filter ,{
i-n:put phys- int-7- fil tee;.
}
G
~
CE
~
t
tI
I
41
I
.,
.,

As always, once you have finished configuring policers and referencing them in firewall filters, you
must then apply the filter to one or more interfaces. In the example on the slide, the filter is applied
several times, across multiple logical interfaces and multiple protocol families. However, because the
pOlicer contains the physical-interface-policer statement, all policers under interface
ge-OjOjO are aggregated into one_ Instead of a bandwidth threshold of 100 Mbps per protocol
family, the threshold now applies to traffic for all filter references combined.
G
(I
(I
Chapter 4-38 Polid""
Mixing Interface iPolicers and Firewall

iPolicers
Iter
Guidelines:
Can apply both to an interface
Inbound-Interface policer before firewall filter
Outbound-Firewall filter before interface policer
Inbound
Interface
policer
Firewall
filters
Outbou nd
Firewall
filters
Interface
policer
Guidelines for Mixing Pollcers

You can apply both interface and firewall filter policers to an interface. The system evaluates input
interface policers before any input firewall filters, while it evaluates output interface policers after
any output firewall filters.
WUftAl
illninar ..... ~ ...
c
c
c
c
c
c
c
Summary
.. In this chapter, we:
- Identified the purpose of policing
- Listed the policing methods available on Junos platforms
- Described and configured two-color and tricolor marking
policers
c
~
tl
(I
-Applied policers directly on an interface
- Applied pOlicers within a firewall filter
The purpose of policing;
The policing methods available on Junos devices;

Describing and configuring two-color and tricolor marking policers;
Applying policers directly on an interface; and

Applying policers within a firewall filter.
Chaoter 4-40
J;::!,.,.H .... inff
"" ..... :. ,,,,,,;nor nJ:>.t
Review Questions
1. What is the role of policing in the overall CoS
process?
2. Explain soft-policing versllS hard..policing.
3. Explain how a single-rate tricolor marking policer
works.
4.
Compar~
color-blind mode with color-aware mode.
5. Give an exarnple where a filter-specific policerwould

be useful.
6. Which applies first on ingress: interface policersor
firewall filters?
Review Questions
1.
2.
3.
4.
5.
6.
Onli",intl".
Chanter 4-41
Lab 2: Configuring PoUcers

Configure a two-color policer.
Configure a tricolor marking policer.
(I
(I
<I
~
(I
II
Lab 2: Configuring Policers
"
..
(I
(I
(I
..
A.
Chapter 4-42 Polini""
o
@
o
o
~
'V;J;.J
.,I>
..
..
....

Chapter 5: Scheduling
Chapter Objectives
able to:
Identify the purpose of scheduling
Describe the components of scheduling, including
transmission rate, queue priority, delay buffers, and drop
profiles
Configure all components of scheduling
e
(I
The purpose of scheduling;
The components of scheduling. including transmission rate. queue priority. delay

buffers. and drop profiles; and
Configuration of ali components of scheduling.
Chapter 5-2 SChedulin~
,.. " .. ;, ...... i .... ar net
..
....
II
Agenda:Scileduling
~ Scheduling
Overview
- Transmission Rate
-Queue Priority
-Delay Buffers
- Drop Profiles and Drop Profile Maps
.,
.,
.,
.,
'.
- Scheduling ConfIguration
I)
Scheduling Overview
The slide lists the topics we discuss in this chapter. We discuss the highlighted topic fi,rst.
CoS Processing-Schedunng
Ingress
Egress.
(I
CDS Processing-8cheduling
Scheduling occurs toward the end of the class-of-service (CoS) process, on the outbound side. Once
packets have been sent through the fabric to the egress interface, the device puts the traffi c into
queues where it can be scheduled and shaped. Congestion control is performed by a random early
detection, or RED, algorithm.
Chapter 5-4 SChArlllliM
.,
.,
(I
Scheduling Overview
Role of scheduling:
Defines. parameters. for how queues treat traffic
Grdf)r in Whicl1packets are transmitted
Rateatwhich packets are transmitted
Numberof packets thatcanpf) bufferEld
DiffEm~ntiqltreatment
packets in the event of conge$tion
Differential treatment of traffic based on loss-priority
Classification or policing assigns pLP
PLP Jnaps t.o sche.qulingtraffic profiles

Traffic profiles map to drop profiles
Drop profiles detetminelikelihooq of traffic to be dropped
.,
A
.,
Role of Scheduling
The primary function of scheduling is to define the parameters for how queues treat traffic .
Scheduling determines the order in which packets are transmitted, the rate at which packets are
transmitted, the number of packets the system can buffer, and the differential treatm ent of packets
in the event of congestion.
Differential Treatment of Traffic Based on Loss-Priority

Back at the beginning of the CoS process, classification and policing assigned packet loss priority
(PLP) values to packets. Now, at the scheduling stage, you can map the PLP values to scheduling
traffic profiles. You can then map the traffic profiles to drop profiles, which determine the likelihood
of dropping a specific traffic type. The mapping of PLP values to drop profiles gives PL P meaning and
purpose.
C"hONlilinrf
Chaoter 5-5
(
(
(
(
Queuing and Scheduling
G
C
Port-based queuing
up to 8 queues per port
G:
FOl"wardingclasses map to queues
~
~
One or more forwarding classes

can mapto a queue
Ill!
Each queue has its own

scheduling properties
I
I
<m
Hierarchical queuingi~discussed in the next chapter.
Port-Based Queuing
With port-based queuing, the device can have from four to eight queues per port, depending on the
platform. As mentioned in an earlier chapter, forwarding classes map directly to queues. Forwarding
classes are essentially the configurable elements, whereas queues are the underlying traffi c paths.
Because it is possible to configure more forwarding classes than queues, you can assign one or
more forwarding classes to a queue.
Each queue receives its own scheduling parameters, allowing for service differentiation between
queues.
Chapter 5-6 Schedulin~
PortBased Queuing Illustrated
PQ-DWRR: Priority queuedeficitweighted round-ropin

WRED:Weigl;1ted randomearfY detection
.
=====::1
"
""
"
""
Port-Based Queuing Illustrated

The slide provides an overview of how port-based queuing works. Each port supports up to four or
eight queues. All VLANs and logical interfaces share the queues. Queues can have scheduling
parameters assigned to them, such as delay buffers and RED-based schedulers. Shapers might also
be involved. These topics are discussed later in this chapter.
Priority queue deficit weighted round-robin (PQ-DWRR) is the algorithm used to select a queue to
transmit the next packet. Priority queue means that queues are serviced in order based on the
priority configured for each queue. Deficit weighted round-robin refers to the fact that each packet
transmitted from a queue subtracts from that queue's available bandwidth, and the servicing of
queues with the same priority uses a WRR mechanism based on the transmit rate co nfigured for
each queue.
Weighted random early detection (WRED) is the primary mechanism for dropping pacKets. It provides
options to selectively drop packets based on user-configurable drop profiles, as well as a packet's
forwarding class and loss priority. WRED provides a probabilistic way to drop packets to both avoid
and control congestion.
C ..... h .... ,.1. ,Il ... .-("
ChaDter 5- 7
Scheduling Components
Components of scheduling:
Transmission rate
Amountof interface bandwidthailocated to a queue
Priority
Relative importance cfthe queue compared to other queues
Delay buffers
Amountof data that can be stored when congestion occurs
RED drop profiles

" How to drop traffic when congestion occurs
@
fI)
Components of Scheduling
The slide lists the primary components of scheduling. Each ofthese topics is explained in more
detail later in this chapter.
...,
(I
.,
.,.,
.,
.,
Chapter 5-8 Schedlliin"
Scheduling Configuration Components

Configuration components
Syntax
[edit cla,ss-of_service]
5 ch.<l duler 5
sohgd,uler-name {
priority priority-level;
transmit-rate -(rate I percent peroentage remainder) <exact \ .rate--'lmt>;
buffer":siz~(pe17cent peic,mtagel remainder I terrtpoJ;-al mici:;oseconds){
drop-profile-map loss:'pr;iot:iti( (anY r lot.( \rrtBdilim-,.low\medium-O;i;gh. I high)
Prgtocg1 (aDY \ nbn"-tep \ icp) drop-pto~i1B profile-name;
.
}
drop-prof;!:les {
"p;r:ofi,:le-n{1me i
,:(i1:L-J,evel pe.1'cel")tage ~!,op-probab;Llitype!,9(jIltag'F;
iri:terpolate t
dd)p-probability [ 'values] i
fill-level. [ values] /}
}
Configuration Components
The slide displays the command-line interface (eLi) syntax for the relevant configuration components
that support scheduling. These components are discussed throughout this chapter.
Agenda: Scheduling
III
Scheduling Overview
~ Transmission Rate
iii
Queue Priority
III
Delay Buffers
III
Drop Profiles and Drop Profile Maps
III
Scheduling Configuration
(I
Q
~
\I
tB
.,
Transmission Rate
.,
8
8"
p" '
Chapter 5-10 Sr.h I='rllllinCf
\..i.J
o
o
o
~
e
(7'\
.
\d
G
G
.,
..
(I
Transmission Rate
Transmission rate
Amountof interface bandwidth allocatee! to a quel,1e
Similar to CI R
Queue can exoeed transmission rate ifthere is unused

bandwidth
When traffic is within allocated amount, queue is in-profile
When traffic exceeds allocated amount. queue IS out,of-prOfile
Plays a role in how traffic is prioritized

Can affect priority leveJs
Discussed later in this chapter
Transmission Rate
The amount of bandwidth allocated to a queue is called its transmission rate. You can think of a
queue's transmission rate as a committed information rate (CIRl.
By default, a queue can exceed its configured transmission rate if unused interface bandwidth is
available. When traffic is flowing within a queue's transmission rate, the traffic is refe rred to as
"inprofile"; when the traffic exceeds the allocated amount, the traffic is referred to as
"out-of-profile."
Transmission rate plays a role in how a device transmits traffic out of an interface. Specifically, it can
affect the precedence of priority levels. This topic is discussed later in the chapter.
Note
Transmission rate cannot be configured for
8-port, 12-port, and 48-port Fast Ethernet PICs.
Transmission Rate Options

[edit class-of-service schedulers schedul,er-name]
transmit-rate (rate I percent percentage I remainder) <ex.act I rate-limit>;
Configuration options for transmission scheduling:

Fixed rate (in bps)
Percentage of port's total available bandwidth
Rema.inder (remaining available buffer); "whatever is left"
Rate control
fJj
Exact
Buffers traffic exceedingtransmit-rate:Junctions asa queue shaper
Alternatively, you can use scheduler's shaping-rate option to have bufferihg startabol'9 the. transmit'rate,
Rate limit
Drops traffic.exceeding tl'ansmit-rate; functions as a hard poJicer
No .!:letting
Queuecah exceed transmissi.on rate If unusedbandwidthe1<ists
Configuration Options for Transmission Scheduling
Rate Control
You can also optionally configure rate control options on the queue, The exact option limits the
throughput ofthe queue to the configured transmit-rate, and buffers excess traffic, Once the buffer
is full, the system begins droppingtraffic,The rate-limit option performs much the same
function; however, this option has no buffer support-all out-of-profile traffic is immediately dropped,
Note
The exact option is not yet supported on
Enhanced Queuing Dense Port Concentrators
(DPCs) on Juniper Networks MX Series Routers,
--------------------------------Note
The rate-limit option is not yet supported on
Modular Port Concentrators (MPCs) for MX
Series routers,
co
11
~
CO
The slide lists the three main configuration options for transmission scheduling_
Chapter 5-12 Sch"rtillina
Default Schedulers: transmi t-rate

Default scheduler settings
[e~i~ '.cla$s-of-~e-I:\tice]
{
best-eUort :{
scb,edule~s
~ransI'l!1~-rate p~rc_ent,
95;'4"
Transmission rate'" 95%

for qLielle: 0; 5% for qLieue 3
baffe'r-s lze 'percent' 9.5:;

pI: iqt.ity ,l.o:w,';
d.r.. o.,,-p. r,<O)f. ile..-Ilra p :LO.SS-PdPdYy protoco:Lany
drop-pr~fi:Le
ter mina.1;,
J)etyJ,ork-cont,r.ol {
/
transmit-rat'e percent So;
'-bi.t'f_~e,:c..:.:S--ize perceht -:5 ';
,pr i.or',it.y low,;
dtoP~P~ofil;'~m'ap los~bpriority anY' protocol any droli~profi:L"term'inal;
r
droli"profiles (
teriUinal{
fill~ievel 100 dri()p-ptdbai:)ility .100:

r-----~----~--~----,
Thel?esElttii1gs arEllmpl ioit-they dCl

not appear in theconffguratiort.
)
.
Default Scheduler Settings: transmit-rate

The Junos operating system has several default CoS settings, including a default scheduler (shown
on the slide). Each forwarding class has an associated scheduler priority. Because Junos default
classifiers have only two forwarding classes (best effort and network control, queues 0 and 3), the
default scheduler provides settings for only those two classes as well.
As part ofthe default scheduler settings, the best-effort forwarding class (queue 0) receives 95
percent ofthe bandwidth, and the network-control forwarding class (queue 3) receives 5
percent.
c: ....honlllind.
Chanter 5-13
Unallocated Bandwidth
Guidelines:
Queues exceedingtransrni t - rate receive part of
unallocated bandwidth
Queues within transmi t- r.a te d.o not receive extra bandwidtll
Scheduler shares unallocated bandwidth equaUy among

eligible queues
Simple round-robin on a per-packet basis
To eXclude a queue, Use exact or rate-limit
3.0% of port's bandwid~h is unallocated
[edit c-la5s;...6f:--:se,tvit~-]
schedulers {
sched-A {
trail_smit-ra1:;e- percent SO;'
buffer-size percent 50,
sched-B !
transmit-rate percent 2.0;
bUf.fe'r-s ize
per~ept
20;
Unallocated Bandwidth Guidelines

In some circumstances, you might wantto configure transmission rates for an interface's queues but
not use all the interface's bandwidth. When this situation occurs, the unallocated bandwidth is
available to any traffic that is out-of-profile. All queues exceeding their transmission rate at a given
moment can share the unallocated bandwidth equally between them.
If you do not want a queue to use any leftover bandwidth, you must configure its scheduler using the
transmi t -rate statement with the exact or ra te-limi t option. These rate-control options
force the queue to strictly observe their allocated bandwidth.
Chapter 5-14 ScheduliM
Agenda: Scheduling
III
Scheduling Overview
III
Transmission Rate
~ Queue
III!
Priority
Delay Buffers
III
III
Schedl,.lling Configuration
Queue Priority
Q,...ha.r!lliind.
Chapter 5-15
''-.
Queue Priority
.. Priority
Relative importance of the queue compared to other queues
.. Determines the order in which the interface transmits trCjffic from
queUes
Ensures certain queues are served before other queues when
congestion occurs
Queues receive service according to their assigned priority

Generallybasedon WRR algorithm
(I
Queue priority dictates a queue's relative importance in comparison to other queues. It determines
the order in which queues can transmit their packets, and ensures that certain queues get higher
precedence when congestion occurs.
You can configure queues with differing priority values. When this configuration occurs, the queues
receive service according to their priority based on a weighted round robin (WRR) algorithm.
Chapter 5-16 Sch edulim>
..
I)
Priority
fit
o
o
G)
(2)
(2)
o
o
o
....
(I
"
Priority Levels
S4Pported priorities;
Low
Medium-low
Medium-high
High
Strict-high
Supported Priority Levels

The slide lists the priority levels available for schedulers.
www h Inint=lol'" ..........+
c.: ... hc.rhllind.
Ch;:mtp.r!)-17
Priority Queuing Process

Serviced
Ftrst
.. How priority queuing

works:
Strict-high has top
priority
Traffic is always in-profile
Other queues are

serviced using WRR
WRR
High to low priority
Transmission rate
plays a role in serVice
order (except strict-hIgh)
In-profile traffic first. then
.out"of-profiletraffic
How Priority Queuing Works

Queues can transmit packets based on their priority. Strict-high priority is a special setting that
always has highest precedence and provides a queue with unlimited access to the interface's
bandwidth.
The other queues use WRR to allocate bandwidth. Under this model, high priority queues have
highest precedence, followed by medium-high priority queues, and so on. A critical factor that comes
into playas part of this process is the queue's transmission rate, and whether a packet is in-profile
or out-of-profile. Queues with packets that are in-profile get precedence over queues with packets
that are out-of-profile, even if the latter queue has a higher priority value. For example, a queue with
medium-low priority and in-profile traffic gets precedence over a queue with medium-high priority
and out-of-profile traffic.
wwwillniner.net
@
~.\.'.
V
Using St,let-High Priority

-Strict-high priority
eProvideslow-latency qUeue; good for voice traffic
e Has high priority; tr(3ffic is always in-profile
.,
..
By default. queue can expand to use interface'sfull bandwidth
eReQeives precedence overall other queues
exc~pt
high
Sharespackettransmission with high priority queues

Maystarve lowe(priority qUeues
- Usage considerations:
t tansmi t-i:<;! te statetrlenthasno, effect Unless usi ng
.L'at~,...liIli.it option
ra 1:e ~ limit option stops queue from Usi ng enti re interface bandwidth
e GiVe high priorltytQother queues that musthot oestarved

EnsuresshClredtime with c::trIII"'T_nl
(I)
v
(I)
Strict-High Priority
Strict-high priority is a special priority level that allows the Junos as to designate a queue as
lOW-latency. It has the highest precedence and the queue can use up to the full interface's
bandwidth, that is, traffic is always considered in-profile. A strict-high queue is always picked ahead
of queues with lower priority values, with one exception. Strict-high and high priority qu eues share an
underlying hardware queue, which means queues marked strict-high or high actually share
precedence to transmit packets. Note that the unlimited precedence of strict-high can cause
starvation of lower priority queues.
Usage Considerations
Because a queue with strict-high priority gets unlimited access to an interface's band"Width, the
transrni t -rate statement has no effect, regardless of whether or not you include itt. However, yoU
can put controls on a strict-high queue. You can add the ra te-lirni t option to the
transrni t -r ate statement to cap the queue's bandwidth usage and prevent it frorfl consuming
the entire interface's bandwidth.
Usage Considerations
, (contd.)
Another good practice is to give queues with important traffic high priority. Because a strict-high
queue shares packet transmission with high priority queues, you can give important traffic high
priority, which ensures that it will not be starved by the strict-high queue.
Note
The rate-lirni t option is not yet supported on MPCs for MX Series
routers.
Chapter 5-20 SChRdlJliM
Priority Options
.. Configuration optionsfoJ priority scheduling:
low, medium-low, medium-high, high
strict-high
One strict-high priority queueper interface
[edit ,clase-o[-ser"i'Ce schedulers scheduler,-Ilame.]
PPiq,pity pri9ri ty-1e'fJel,.1
Configuration Options for Priority Scheduling

The slide lists the configuration options available when configuring priority. Note that you can
configure only one queue per interface with strict-high priority.
A Note About Software Priority Versus Hardware Priority

The priority levels listed on the slide are Junos software priorities. Software priorities map to
hardware priority levels; however, these mappings depend on the Flexible PIC Concen trator (FPC) or
MPC type in which the PIC or MIC is installed. In some cases, each software priority maps to a
dedicated hardware priority. In other cases, multiple software priorities map to a single hardware
priority. An exa mple of the latter was described on the preceding page, where strict-h i gh and high
share the same hardware priority. Although mappings vary, one constant guideline is -that low and
high software priorities are always different hardware priorities. See the Junos Class of Service
Configuration Guide for more detailed information on mappings between software an d hardware
priorities.
..".....
;"
... ; ......... -
~,...hoNlilinrf..
r:hi=lntp.r fi-?1
Default Schedulers-priori ty
.. Default scheduler settings
[edit class-o.f'-ser'llice]
:sch~du1~rs
.oest-effort (
t,r~:Qsmit.~rat~
percent '90S;
buffe,r:-'s ize _percent 95;
priority .low;
drop-pt:Of:lle-map loss-priority a
network-cbn,trol ':.(
' , .tra. n.,s.m-it-ra-te
Priority for both default forwarding

classes (queue 0 and 3) = low
prot,ocol any ,drop-pro;t:ile
t~rminal~
: /
~erc~nt. 5 i
-'
bufJer:~s
i'ze pe'rcent 5;
.priority'low;
d'rop'~proi.ile-map, lOEi's""'prior.ity any ,Protocol any d,r.op,:",pro'ifJ:e- terminal';
djOop-profil,es (
termJnal ;(
fill-level 100. drop-'!irobability 100;
These settings are implicit-they do

notappear ih.the cqnfigl.n:ation ..
Default Scheduler Settings-priori ty

As part of the default scheduler settings, the priority values for both the best effort and the network
control forwarding classes are set to low.
Chapter 5-22 SchedllliM
......... 1...... i .... ol" not
Agenda: Scheduling
iii
Scheduling Overview
iii
Transmission Rate
III
Queue Priority
~ Delay
!Ill
Buffers
!Ill
Delay Buffers
......... ;, .... 1....... -
__ .,
Delay Buffers
Buffers
-Amount of data that can be stored when congestion ocours
Size bfthe memory buffer fQr a queue
- Determinesmaximum latency of a queue

Large buffer = lTlany packets stored = large supported latency
Buffer size for port-level queuing

Varies from 50 msto 200 ms based on hardware
Discussed in more detail on the nE)xt slid.e
-All port queues share the buffer
Buffers
Delay buffers define the amount of data that can be stored when congestion occurs. The configured
value effectively determines the maximum latency of the queue. The larger the defined buffer size,
the more packets that can be stored, and thus the larger the supported latency.
Buffer Size for Port-Level Queuing

The buffer size for port-level queuing ranges from 50 ms to 200 ms, depending on the hardware
platform. As with transmission rate, all queues on a port share the available buffer.
Buffer Size
Maximum buffer size varies by platform
Factor of port bandwidth
-Example: 1 Q bps port with 100 ms buffer size = 100 M bits. =
12.5 MB buffer size
Maj(irriulti bl,lfferdelaysiZe p
. 6r port
<-
-.
Device
...
M320andTSerieS router FPC;s,
Maximum BufrerSize(Microseexmds)
! . .
' .
80,060
200,000
100
.,.,
.,
.,.,
I.
Maximum Buffer Size Varies Per Platform

The slide lists the maximum buffer sizes for various hardware platforms. Buffer size is ultimately a
factor of port bandwidth. In the example on the slide, a 1 Gbps port with 100 ms maximum buffer
size means a maximum of 12.5 MB of buffer space. But on a platform with a different maximum
buffer size, or with a different interface speed, the maximum buffer space can change significantly.
A Note About Large Buffer Sizes

Congestion and packet dropping occur when large bursts of traffic are received by slo""er interfaces.
This happens when faster interfaces pass traffic to slower interfaces, which often is the case when
edge devices receive traffic from lhe core of the network. Tl, El, and NxDSO interfaces and data-link
connection identifiers (DLCls) configured on channelized Intelligent Queuing (IQ) PICs are limited to
100,000 microseconds of delay buffer, which might not be SUfficient to support these types of traffic
flows. For these interfaces, it might be necessary to configure a larger buffer size to prevent
congestion and packet dropping. You configure large buffers on channelized IQ, 4-port E3 IQ, and
Gigabit Ethernet IQ and IQ2 PICs. See the Junos Class of Service Configulation Guide for detailed
information on enabling large buffers for these interfaces.
Delay Buffer Options

Configuration options for delay buffers:
Percentage of port's total available buffer
.. Buffer is elastic; usesa dynamic memory allocation mechanism
.. Queue's buffer CCln expand when queue exceeds trClnsmit-rate

setti ng
Dynamic memory applies to M320, MX Series, and. TSeries routers only
Temporal;time value relativeto queue's transmission rate

.. Buffer is not elastic: queue's buffer hasstrictupper limit
.. Drops traffic exceedingbLlffersize
41
.. Buffer size is a factor of transmission rate
Remainder
.. Remainingavailable buffer; 'Whatever is left"
[edit c:i<tss-of-.service gchedule):;s sch"duler-ndl1Ie]
bLlffet-size (percent .percen.tage I t"rnporal !1Iicro;3econds I ,remaind"r);
Configuration Options for Delay Buffers

Buffers have two primary configuration options. The first option is to configure the queue's buffer
size as a percentage of the interface's available buffer. When using a the percentage option on
Juniper Networks M320 Multiservice Edge Routers, MX Series routers, and mostJuniper Networks
T Series Core Routers, the buffer is elastic. The queue's buffer can expand, dynamically provisioning
extra delay buffer when a queue is using more bandwidth than it is allocated. This feature is helpful
to absorb bursty traffic as a queue's traffic rate increases.
The other primary configuration option is temporal. With temporal, you configure the buffer as an
amount of time, which is measured against the queue's transmission rate to calculate the buffer's
effective size. When using the temporal option, the queue's buffer has a strict upper limit and cannot
expand, even if the port has unused buffer space.
!I
\I
@
(I
'<'f:J7
~
C1D
@
@
~
~
Configuration Options for Delay Buffers (contd.)

A third configuration option, remainder, exists. A queue using this option simply gets "'hatever buffer
space is not yet allocated to the other queues.
Note
Support for dynamic memory (also known as
memory allocation dynamic [MAD]), is
dependent on the FPC and Packet Forwarding
Engine, not the PIC. All M320, MX Series, and
T Series router FPCs and Packet Forwarding
Engines support MAD, except for the T Series
router ESFPC and Enhanced IV FPC. No IQ, IQ2,
IQ2E, or IQE PICs support MAD.
Calculating Delay Buffer Size (1 of 2)

III
How to calculate effective delay buffer size:

Percentage
Buff~r size
(%) x, IT)qX port buffer size (ms) = effective delay buffer (ms)
Effective delay buffer (s) X interface bandwidth (Mbp$) /8

size (MB)
III
'" bUffer
41
I
Examples
Using MX Series router (100 ms max. buffer size) with a
1 Gbps port
QO/Q1:
Percentage
Not .. factorin calculations.
How to Calculate Effective Delay Buffer Size: Part 1

The slide shows how to calculate effective delay buffer size when you configure a queue's buffer as a
percentage ofthe port's buffer size. Use the first equation to calculate the effective delay buffer in
milliseconds. Use the second equation to convert the effective delay buffer into a buffer size in MB.
Examples
The example on the slide uses an MX Series router, which has a maximum buffer size of 100 ms,
with a 1 Gbps port. Queue 0 and queue 1 are configured with buffers that are based on a
percentage of the overall delay buffer available to the port. Using the equations at the top of the
slide, Ql's 30% buffer allocation equates to 30 ms of the port's 100 ms buffer size, which translates
to a buffer size of 3.75 MB. Q2's 45% buffer allocation equates to 45 ms of the port's 100 ms buffer
size, which translates to a buffer size of 5.625 MB.
Chapter 5-28
Sr.:hAnlllind"
~
~
~
~
..
Calculating Delay Buffer Size (2 012)

How to calculate effective delay buffer size:
-Temporal-fixed transmit rate
Buffer sIze (s))Ci transmit rate (Mbps) /8= buffer size in MB
- Temporal-transmit rate as %
Buffer site (s}X [interface \j/w(Mbps)x transmit rate (%)] (8 =
buffer sizein MB
Examples
- Using MX St3ries router (:tOO ms max, buffefsize) with. a
1 GI::Jps port
Q2/Q3:
T~mpql'8l
How to Calculate Effective Delay Buffer Size: Part 2

The slide shows how to calculate effective delay buffer size when you configure a queue's buffer as
temporal (that is, a proportionate amount of time related to the port's transmission rate). Because
transmission rate has two possible configuration methods (fixed or percentage), two possible
equations exist that you might need to use to calculate the effective buffer size. Use the first
equation to calculate the effective delay buffer when the transmit rate is fixed. Use the second
equation to calculate the effective delay buffer when the transmit rate is a percentage.
Examples
As shown on the previous page, the example on the slide uses an MX Series router, which has a
maximum buffer size of 100 ms, with a 1 Gbps port. Queue 2 and queue 3 are configured with
temporal buffers that are based on the queue's transmit rate. Using the equations at the top of the
slide, Q1's 100 ms of temporal buffer and 100 Mbps of configured transmit rate equate to 10 Mbps
of effective delay buffer, which translates to 1.25 MB (that is, how many bytes a queue can store in
its buffer in 100 ms based on its configured transmit rate). The same process is used to calculate
Q3's effective buffer size.
c::.,..hAntllinp"
Chapter 5-29
elationship Between BU'iI"II"AElhJIII Size and

Transmission Rate
Guidelines:
General best practice is to match values
Parameters are proportionate
Can set buffer size greater (or lower) than transmission rate
Settings are independent
Dynamic memory allocation still applies when traffic exceeds
transmit-rate
tedit class-of-se,vice]
schedulers {
match-transmit-buffer {
transmit-rate percent 50;
buffe r- size percent 50;
CI
I
buffer-()ver-transmit {
buffer-size percent 30;
I
I
"..
(8
Guidelines
In general, matching the transmission rate and buffer size values is a good practice, as doing so
keeps the parameters in proportion to one another. That said, if you want, you can mismatch the
parameters. Buffer size is independent of transmission rate, with each providing its own kin d of CIR.
In the example on the slide, the upper scheduler matches transmit-rate and buffer-size, whereas the
lower scheduler guarantees a transmission rate of 20% and 30% of the buffer space. Both
schedulers function the same way, with each using its configured parameters, and both can
dynamically expand the buffer space (using MAD) when traffic exceeds the transmission rate.
Note
On M Series routers other than the M120 and
M320 routers, do not configure a buffer size
larger than the transmit rate for a rate-limited
queue in a scheduler. However, you can achieve
the same effect by removing the exact option
from the transmit rate or specifying the buffer
size usingthetemporal option.
Chapter 5-30 Scheduling
0.J
~
~
~
\jJ1
Default Schedulers: buffer-size
@
~
@
@
(I
.. Default scheduler settings

Buff~r$ize
b"q,ffE!j-:r'-s-i2;e perC;farit J~S;
.-p r iq'r'ity _low;
dlOOIY-profile-ll\ap losS-j'riodty
any
protocol
network-control :j
tpil.~s~tt~-ra:te_' per.ce~t_
CIt
(I
= 95%.forqueue 0,
5% for queue 3
[edIt class-of-service']
s.chectillei:' {
bes ,-eHo lOt .(
transmit-rate' percent 95;
b':lffer:-~ize
5- ~
,pe:reent' ,5';
'P~idiity
',loW';
d,l::bp_-p~o~il~~\Uap. Ib~,$-'P:t9):-~t.y-_~~y, 1?~o:t6c.Ci). ?-ny- dr:qp;"l?ro_~_::tl,~ __ 'tf!3J:~n,lha.J.);
)
)
4I'op-profiles{
termi(la:l :t
fill-level. 100
drop~prqb"bility ~OO.;
Default Scheduler Settings: buffer-size

As part ofthe default scheduler settings, the buffer sizes for the best-effort and
network-control schedulers match the transmission rate, at 95% and 5%, respectively.
C:,...hArllllind
Chapter 5-31
(,
(
(
(
Agenda:ScheduUng
III
Scheduling Overview
III
Transmission Rate
III
Queue Priority
III
Delay Buffers
(
@
~
(fl,
(I"
,\;:;~
,
-7 Drop Profiles and Drop Profile Maps

III
~tI'"
"I
,,):j
1.'):
(I
<I
..
<I
....
..
..
<I
<I
A
Drop Profiles
II
RED congestion control and avoidance

Action to take when congestion occurs
AffeQts paCKets in buffer
Works directly with delay buffers

Determines how to selectively drop packets as delay buffersfiU
II
Known in the Junos QS asa drop profile

Defines parameters fdr dropping tra{fic when congestion
oCQurs
.. Defines likelihood of traffic being dropped as delay buffer
fills
Puts PLPValuEls td. use
RED Congestion Control and Avoidance

RED is a mechanism that helps determine actions to take when congestion occurs within a device.
RED works directly with delay buffers by determining how to selectively drop packets as the delay
buffers fill.
Drop Profile
In the Junos as, drop profiles perform RED by specifying the parameters for dropping traffic when
congestion occurs. Specifically, drop profiles define the likelihood of a packet being dropped based
on the fullness of its related buffer. In practical terms, drop profiles put PLP values (set on a packet
at ingress) to use.
C:;::,...hp.rilllinl1 _
Chapter 5-33
How Do Drop Profiles Work?

--T--'---'--I
I
J
I
Key drop profile parameters

Fullness
How full tl'le buffer is
75
.g
50
:s
Drop probability
Likelihood a packet will be dropped
III
How it works:
e-
1
1
1
--"'---1-- ___ I
I
Q.
II
--1"--;---,1-I
I
1
I
I
I
I
I
__ .I.
__t
_.
__1___ 1I
25
I
I
Cl
25
J
I
I
I
I
I
50
75
100
Ful/ness (%)
For each packet in the queue,
the router generates a random number between o and. 1.00
The number is plotted against the drop profile, at the current
fullness level
When th.e random number is above the line, the packet is
transmitted
When the random number is below the line, the packetis
dropped
Key Drop Profile Parameters

A drop profile is essentially a dual-threshold mechanism_ One threshold is queue fullness, which
specifies how full the buffer is. The other threshold is drop probability, which is the likelihood a
packet will be dropped. When you configure a drop profile, you are essentially configuring a series of
"if-then" statements. For example, you could specify that if the buffer reaches 50% of its capacity
(fullness), then a 50% chance exists that a packet arriving at that moment will be dropped (drop
probability).
How It Works
When a packet reaches the head of the queue, the system generates a random number between 0
and 100. 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 drop probability value in relation to
the fullness level, the packet is transmitted onto the wire. When the number falls below the drop
probability value, the packet is dropped.
Chapter 5-34 Sch eduliM
..
41
..
..
CD
Using Drop Profiles for wnED

Drop profiles can provide WRED
Create multip[edrop profiles with varying levels of
aggressiveness
Apply per queue and protocol; apply "weight"

Givehigher priority C\ ueues less aggressive drop profile
-Give lowerpriority queues more aggressive drop profile; might
cause traffic loss even before buffer is full
. Medium
Gradual
,BufferFullnE*iS
ID;op Probability
Aggressive
~,
Buffer Fullness
I DropProbabillty
80%
90%
90%
100%
100%
Drop Profiles Can Provide WRED

The Simplest way to implement RED is to configure one drop profile and apply it to all traffic on all
queues. However, this approach essentially treats all traffic the same, dropping it at the same rate
regardless of its queue or protocol type.
A much more powerful approach to drop profiles is to configure multiple profiles, each with its own
degree of aggressiveness. You can then apply the various drop profiles selectively based on the
importance of traffic within each queue. This approach gives more "weight" to certain traffic, and is
the basis of weighted RED (WRED). For example, using the sample drop profiles on th e slide, the
gradual drop profile doesn't affect traffic until the buffer is nearly full, making it a good choice for
traffic of high importance. Conversely, the aggressive drop profile could be a good choice for traffic of
the lowest priority; the drop profile begins to drop packets when the bufferis just 30% full, and
doesn~ even allow the queue to use the full buffer space.
C .... hao ...h .linCf ..
Chanter 5-35
,
lunas Class of Service
Relations
Profiles
1I1!1"11".cr
Size and
nl"lnp
Drop profiles can alter buffer size

Occurs when drop probability is 100% while fill level is less
than 100%
Drop profile specifies that the queue drop packets before the
queue's delay buffer is 100 percent full
Reduces effective maximum buffer size

Aqueue using the relaxed drop profile gets
full access to the buffer, whereas a queue
usingthe aggressive drop profile does not.
class-of-service {
drop-profiles {
aggressive {
fill-level 70 drop-probability 100;
}
relaxed {
}
Cl
~
~
...,
..
~.'
~
Drop Profiles Can Alter Buffer Size

In certain cases, the effective buffer size for a queue is not solely determined by the buffer size
value, but also by the associated drop profile. When a drop profile specifies a drop probability of 100
percent at a fullness of less than 100 percent, the effective maximum buffer latency is smaller than
the buffer size setting. It is perfectly fine-and in some cases specifically desired-to configure drop
profiles in this way. But it is equally important to be aware of the impact of applying such a drop
profile.
Chapter 5-36 Sch edulin~
c.:.J
G
CD
C)
Q])
~
o
e
RED Drop Profile Opiion$

Configuration options for drop profiles
Configuration parameters:
".."
.,
.,
.,
.,
Thresholdmap methods:
<I
.,.,
.,.,
Fullness-howfulithe buffer is
Prop probabilitY'-IiKelil;1090 a pacKet will b,e dropped
segmented (default) orinterpolated
Seethe following slides

Syntax
~edit clCiss-o)O-servicE\]
dr:op-pr:qf.fiE\ S { ' ", '
piof'tle\iIl'me (
,
riH-l:eVel:pe:ro,en,ta.ge db'>,p~pr:obabi1ity .pEu;centag;;,;:
'
iTiter:pcilate ;.1 "
d)Cop-pr:oba,bilit,y (values 1,
H;J,k lE\vei [values 1;
Configuration Options for Drop Profiles

Drop profiles have two main configuration parameters: fullness and drop probability. They also
support two methods of defining the threshold maps that determine when to keep or drop traffic:
segmented (default) and interpolated. The next few pages explain these methods in more detail.
I~
C ... h.o.rh liind
..
Chapter 5-37
Junos Class of SeNice
ersus
Profiles (1 of 2)
Segmented drop profile
Mechanism is segmented, step-by-step

System creates threshold map based on configured values
Drop probability is constant even as fullness level increases,
until next configured threshold
Example: In tllis example, fullness levels of 25% and 45%
both have drop probability of 25%
Segmented
,
class-ofservice {
drop-profiles {
segmehted-style-profile {
fill-level 25 drop-probability
Example
'*
;;,;. 75
25;
50;
75;
100;
}
}
100
--T--'-- -,-J f1
'
When buffer is 95% full.

' - - I drop all traffic. and so on
:s.:g
50
II
--~--~--
:
__
.l. __
_--I
'
Q.
I
I
I
I
___ 1___ 1
~ 25
,
I
25
I
I
,
I
I
I
50
75
I
I
,
100
Fullness (%)
Segmented Drop Profile

A segmented drop profile functions in a sort of step-by-step manner, with the threshold map based
only on your configured values. To create the drop profile's threshold map, the Junos OS begins at
the bottom-left corner in the graph shown on the slide, representing a 0% fill level and a 0% drop
probability. Using the example on the slide, the threshold map remains at 0% drop probability (the
line on the graph moves directly to the right) until it reaches the first defined fill level, 25%. The
system immediately raises the drop probability (the line on the graph moves vertically) to the related
configured value, 25%. The process repeats for all of the defined fill levels and drop probabilities,
ending with the implicit 100% fill level and 100% drop probability setting (the line on the graph
moves to the top-right corner) as the buffer becomes completely full and drops all traffic .
Chapter 5-38 Sch erililinl1
CD
CD
@
CD
CD
.,
.,
ented Versus Interpolated Drop

Profiles (2 of 2)
-Interpolated drop profile
Mechanism is graduated, smooth
System creates threshold map automatically, influenced by
configured values
Generates 64 data pOints between (0,0) and (100,100): includes
configured data pOints
Drop probability is graduated as fullness level increases

Example
Interpolated
claSs-af-service {
drap-prcofiles {
interpolated-style-profile {
interpolate {
flll-level [.50 75 );
dr()p'-probability [ 25 50 1;
100 --'"r-~"--"--I
I
I
e....
l
I
I
I
.... 75 --+---<---,-,
:~
.,
I
. I
i
-
50
Q.
25
J-I
When buffer is 50% full, drop

25% of traffic, and so on
Itt
--'-:---1-- .---:
--t-- ,---:---\
b 25
50 75
100
Interpolated Drop Profile

An interpolated drop profile creates a more gradual threshold map, because it creates the threshold
map automatically, Instead of using the step-wise approach of the segmented method, an
interpolated drop profile uses 64 system-defined threshold points, including your configured values,
to create a threshold map, The result is a smoother threshold map with graduated data pOints from
point (0,0) and (100,100),
Note
You can only specify two fill levels for
interpolated drop profiles on Enhanced Queuing
DPes for MX Series routers,
C: .... harh
lliner ..
Chapter 5-39
(
Default Schedulers: drop-profile
C
(
(
C
\2
Default drop profile settings-taU-drop; no RED

[eeli"!; class,-of-serv'ic::e:]
sphedulers,(
best-effort (
,t,l;"artsmit,-rate percent 95;
buffer~size percent 95f
priority
('
,-------------------,
Drop profile = 100% drop prolJability at

100% bUffer fullness, tllat, is, drop traffic
wllentlle buffer is full>, and not before
low:
dr:op-pro~ile-map.
\t
4i
t
los$-priq.rity any proto.c:;:'O). any drop-profile ter_mina 1.:
network-control {
buffer-size pe,rce-nt 5'r
~ri'ot'i,ty ,low;
drop-PtofiH'-lIiap lo"s~priorlty anyprotoco
(i
,flU-level 100 drop-prdbability 100,;
I
I
II
These settings are implicit-they do. not appear in the configuration
~
'I::ijj)
1
drop,,-profiles {
terminal {.
Default Scheduler Settings: drop-profile
<8
Drop profiles do not fall under the scheduler section ofthe class-of-service stanza. In the
default RED drop profile, when the fill level is 0%, the drop probability is 0%; when the fill level is
100%, the drop probability is 100%. Because the configuration specifies the segmented method, the
drop profile has essentially no effect-it specifies traffic loss only when the buffer is completely full,
which is what the buffer itself does anyway.
Chapter 5-40 Schedulinl!
Implementing RED Drop Profiles

Drop profile maps
Associate drop profiles with a scheduler
41)
""
I}
crt
I)
I)
I)
.. Single queUercan haVe mUltiple drop prQfile maps
Map PLP-marked packets to drop profiles

Apply drop profiles to specific traffiC flows
Gives meaning to pLpva(ues
Can be protocol-specific (TCP or non-TCP)

bropprofi[es db nothing until theyarerefel'enced in aschecluler.
Drop Profile Maps

While a drop profile defines the likelihood of a packet being dropped based on the fullness of its
related buffer, a drop profile is much like a firewall filter-it does not actually do anythi ng until you
apply it somewhere. Drop profile maps put drop profiles to use by associating them with schedulers.
A single queue can, and usually does, have multiple drop profile maps, representing different drop
profiles for different traffic flows.
Drop profile maps make PLP values meaningful. PLP values, on their own, have no meaning. They
are simply attached to packets moving through the device for use later in the CoS process. Drop
profiles define the meanings of the loss priorities.
You can use drop profile maps to apply drop profiles in a protocol-specific way, affecti ng TCP-based
traffic, non-TCP-based traffic, or all traffic.
C."hanillincr
..
Chapter 5-41
Drop Profile Map Options

Configuration options for drop profile maps
Loss priority
Low, medium-low, medium-high, high, any
Protocol
TCP, non-TCP, any
Drop profile
Reference the desired .drop profile
Ee~it cl9.s;s-of,,-'service sched.141ers
scheduler-nameJ
loss-pdodty (any I low I titediul1i~lbW I mediUlli-high I high) protocol
(any I. non-tc;:p. I te;!>) drop"pl:Qfile p:tpfile-narue;
drop-)l~o.file_map
Configuration Options for Drop Profile Maps

A drop profile map is designed to pull together several components, and apply a drop profile to a
specific flow of traffic. Drop profile maps are applied per queue (or forwarding class) and consist of
three configuration components: a PLP, a protocol, and a drop profile. In practice, you are specifying
traffic from a forwarding class, with a specific PLP, using a particular protocol, and applying a drop
profile to that traffic.
Note
MX Series routers support only the any protocol
option.
Chapter 5-42 Scheduline
Junos CLass of Service
Default Schedulers: drop-profile-map

cedi t c.1as s-o f-s~rvd.c~
scliedul~rs{
best-effort {
D(oppl'ofilemap use
tel'minaldrop profileforall traffiC
,transmit-rate percent '95;

bU,ffep:>;.~ize- ,percent 95,;
p~iority 'iow;
d:rop~profile-m:ap
,
drop-px:ofile t-einiinal-:'
1.oss;-pri:or.i,ty any
net-work-contro:L {
traJ?sl;r(;it,'7":ca_t~ 'perqe.Itt,_ ,5;
buf'fer""'s,ize< percent 5.;"
:p~iot:;,it}l
/.
'ienli,;
~:rop~profile"'Ii1ap, ,lps-s;';'p~riority
--any
prQtoc~l
any d:rop,"'p,ro'file
t~in:_J;I1~nal;
drop-profiles {
tei:mirial (
fili-leve.1 .100dl:'op~prob"bllitylO 0;
Default Scheduler Settings: drop-profile-map

Ps part of the default scheduler settings, the drop profile map associates the default drop profile
with the default schedulers. The default configuration is identical for both schedulers, and specifies
that traffic from either or the two default forwarding classes, with any PLP value, using any protocol,
will be subject to the terminal drop profile.
Much like the default drop profile settings, the default drop profile map configuration has essentially
no effect. It effectively assigns all traffic to a drop profile that does nothing different than the buffer
itself.
c::.,..ht:lnillind ..
Chapter 5-43
Agenda:ScheduUng
III
Scheduling Overview
l1li
Transmission Rate
III
Queue Priority
III
Delay Buffers
III
~Scheduling Configuration
Chapter 5-44
Schedulin~
Configuring Scheduling
Configuration steps:
1. Configure scheduler, including drop profiles
TrahsmissiPh Rate
QLleUePriority
Delc:\y Buffers
Drop Profiles
Ii
Drop ProfileMaps
2, Configure scheduler map
3., Apply scheduler mapto an interface
.,
....
....
a
Configuration Steps
The slide lists the configuration steps to implement schedulers on devices running the Junos
operating system. The following pages expand these steps.
I)
C,..horh dinri"
Chaoter 5-45
Configuring Schedulers and Drop Profiles

cJass-oi-service {
dr()!>"" rofires {
agg,ress~ve
Example
(
{
fill-level [50. 75 90 100];
droj>-probability
0 50 75 100 ];
~n erpol,~te
Ifelaxe~ Ii
l.nerpol"te {
fiU-level [ 75 90 .100 ];
droj>-probability r 0 75 100. ];
}
schedu,le~~
sch.-be
"J;:.ransmit:-:rate pe,tceht 70;
bu.ffer.-siz,e,' p,er:cent 70 i
.Niaril'Y low;
drop-p.rofile-inap loss,priority high prot.oco.l any drop-profile a

d~op'-pJ:ofiJ.,e:-,map
Ip?s-prior:ity l.o~" prpto,~91 'any' d'J:op~profll;
reSS1.ve;
re ax~ ;'
sch-pri{
'tl:'ansm:it-rat,e 'pe,rcent, 30;
b'uffer,:""'sJze', pet:c.ent" 30';

priority high;

The slide shows a configuration example using sched ulers and drop profiles. Two schedulers are
configured. Two drop profiles are configured and are referenced within one of the schedulers using a
drop profile map.
Chapter 5-46 Sch dulinf!
cd
~
~
~
..
..
.,
I)
Configuring a Scheduler Map

Scheduler map
Associates a sqheduler with a forwarding class
.. Associates scl1eq Lllei"s to queues
Sohed\llers de> nothirg;until they are referenced ina scheduler map.
Example
c).a,s~"":of,-$ervice,
scheduJ~r"maps.
sched~l!laJl~exampie{
,!prwa:r_9j,-r:tg-",;"cla5'~ be$t-ef,f-clJ:t::-c;:la,:ta, _~'chi;:dule~ seq.... p,e;,
fOl:_ward.ing-.class -priQrity,....data -scheduler sch-pri;
I)
Configuring a Scheduler Map

SChedulers are designed to manage traffic for a particular forwarding class, or queue. However,
schedulers don't actually do anything on their own. Scheduler maps provide the link between
schedulers and forwarding classes (queues).
The slide shows a configuration example using a scheduler map. Each forwarding class is associated
with a scheduler, thus providing each queue with its scheduling parameters.
Note that custom forwarding classes must be defined atthe [edit class-of-se rvice
forwarding-classes] level of the hierarchy.
C;:;,..hcrllllind'.
Chapter 5-47
Applying a Scheduler Map to an Interface

Apply scheduler maps
Apply to outbound interfaces
[edit class-oJ-service int-erfaces] hierarchy
Scheduler maps do not affect traffic until they are applied to an interface,
Example
Apply to physical interface

for port-level queuing
cl~~s-of-s~,~vip=r
{
interfaces (
ge-O/O/O; (
's "hec)uler~map_ schec)~map-example;.
-)
I:
Wildcards such as ge'-* are allowed.
Applying a Scheduler Map

The final configuration step is to apply the scheduler map to an Interface. Scheduling occurs at the
output of an interface, and so scheduler maps are implicitly applied on the specific interface in the
outbound direction.
The slide shows a configuration example applying a scheduler map to an interface.
Note that for port-level queuing, you apply the scheduler map at the physical interface level .
Putting It AU Together
c1ass-of-service {
drop-profiles {
aggressive {
interpolate {
fill-level [ 50 75 90 100 ];
o 50 7S 100 ];
drop-probability
}
re1axed {
interpolate {
fill-level [ 75 90 100 1;
drop-probability [ o 7S 100 ];
}
interfaces {
ge-O!O!O {
scheduler-map sched-mop-example;
)
scheduler-maps {
sched-mop-example (
forwarding-class best-effort scheduler soh-be;
forwarding-class network-control scheduler soh-pri;
)
schedu1ers {
soh-be {
priority low;
drop-profile-map loss-priority high protocol any drop-profile
aggresBive;
drop-pro file-map loss-priority low protocol any drop-profile
relaxed;
}
sch-pri {
priority high;
Putting It All Together

The slide combines the entire configuration scenario onto one page.
q,t"h~(h Ilinl1
Chapter 5-49
Summary
Identified the purpose of scheduling
Described the components of scheduling, including
transmission rate, queue priority, delay buffers, and drop
profiles
Configured all components of scheduling
The purpose of scheduling;
The components of scheduling, including transmission rate, queue priority, delay

buffers, and drop profiles; and
Configuration of all components of scheduling.
Chapter 5-50 Scheduline:
Junas Class of Service
Review Questions
1. What are the components of scheduling?
2. When is traffic "out-ofprofile" with regard to
scheduling?
3, True or false: A queue with strict-high priority can
.starve all other queues.
4, Explain the two configuration options for delay

buffers.
5. How can yoU implement WRED?
6. List the general configUration steps to configure
:scheduling,
Review Questions
1.
2.
3.
4.
5.
6.
C",""n,..{"linrf
".,
Chaoter 5-51

- Configure schedulers, including drop profiles.
-Configure a scheduler map.
- Apply a scheduler map to an interface.

The slide lists the objective for this lab.
Chapter 5-52 SCheeritllino
:D
1D
0.;.
JjJ
,~
V:::J
C}
JunlE:~['
(i)
Chapter 6: Hierarchical Scheduling
I>
"
..
"
I)
6)
!~
(
(
(
Chapter Objectives

able to:
Identify the purpose of hierarchical scheduling
List the two scheduler modes
Describe the characteristicsofthe four levels of hierarchical
scheduling
Configure the four levels of hierarchical scheduling
Q
~
(@
~
~
fl
ti
Manage remaining traffic

Understand hoW hierarchical scheduHng affects queue
properties
e
II
,o\i'i\
The purpose of hierarchical scheduling;
The two scheduler modes;
The characteristics of the four levels of hierarchical scheduling;
The configuration of the four levels of hierarchical scheduling;
The management of remaining traffic; and
How hierarchical scheduling affects queue properties.
(I
(I
(I
(I
(I
a
Chapter 6-2 Hiera rchical Schp.rilllin"
Agenda: Hierarchical Scheduling
-7 Hierarchical Schedu.l ing Overview

- Scheduler Modes
- Hierarchical Scheduling Levels
- Throughput Example
- Remaining Traffic
-Queue Propertie$in a Hierarchical Scheduling Context
ill Putting It All Together
Hierarchical Scheduling Overview

U;or~rl"'hi ... ~1 C::,...h,::,nlliind
Chapter 6-3
CoS Processlng-Hierarchical Scheduling
Ingt!'SS
CoS Processing-Hierarchical Scheduling

Hierarchical scheduling,like port-based scheduling, occurs toward the end of the class of service
(CoS) process, on the outbound side. Once packets have been sent through the fabric to the egress
interface, the device puts the traffic into queues where it can be scheduled and shaped. Congestion
control is performed by a random early detection, or REO, algorithm. With hierarchical scheduling,
the device can provide CoS treatment for multiple subscribers, groups of subscribers, and classes of
traffic within a subscriber at the same time.
Note
Some hardware supports ingress scheduling as
well as egress scheduling.
Chapter 6-4 Hierarr.hir.AI ~r.hprlillind'

Role of hierarchical CoS:
Allows tiered shaping, scheduling, and qUeuing
Provides fine-grained control over CoS treatmentat multiple
levels
Examples: CoS percustomer(VLAN), and per port (physical interface)
Each level is functionally similar toport-IevelCoS
Capabilities vary sornElwhat per level
Centralizes CoS enforcement and configuratioh

~ Provides CoS capabllitiesfordownstreamdevices that lack CoS
functionality
Heduces.ne.edto configure CoS on downstream devices
A-CbS requires specific hardware

-S.ee the fblloWingslide
(I)
..
(I)
Role of Hierarchical Class of Service

Like port-based scheduling, the primary function of hierarchical scheduling (also referred to as
hierarchical class of service, or H-CoS) is to define the parameters for how queues treat traffic.
Scheduling determines the order in which packets are transmitted, the rate at which packets are
transmitted, the number of packets the system can buffer, and differential treatment of packets in
the event of congestion.
However, the difference between port-based scheduling and hierarchical scheduling is that the latter
provides fine-grained control over CoS treatment of packets for multiple subscribers, groups of
subscribers, and classes of traffic within a subscriber at the same time. Each level is functionally
similar to port-based CoS, providing preference, prioritization, and congestion control, although the
specific capabilities at each level vary.
H-CoS can help to centralize COS enforcement and application, managing traffic flows for
downstream devices that lack CoS significant functionality. H-CoS can also help reduce configuration
and management overhead, because it can reduce the need to design and configure complex CoS
features on downstream devices.
H-CoS Requires Specific Hardware

The Junos operating system requires specific hardware to provide H-CoS. More information is
provided on the following page.
(
Hardware Requirements . . ..." ... Hierarchical

ScheduUng
(
(
(
(
Specific hardware is required
C
C
MX Series
a:
Enhanced queuingDPCor MPC
M Series and T Series
CIi
IQ, IQE. IQ2. IQ2E PICs
This chapter is based on EQ-DPC
EQ-MPC and IQ2E PIC have very similar feature sets, with
slight variations
Other PICs have varied subsets of these features
Specific Hardware for H-CoS

On Juniper Networks devices, CoS functionality is generally performed in hardware, using
application-specific integrated circuits (ASICs) on cards that are installed into the chassis. On Juniper
Networks MX Series 3D Universal Edge Routers, enhanced queuing dense port concentrators
(EQ-DPCs) and modular port concentrators (EQ-MPCs) provide H-CoS functionality. On Juniper
Networks M Series Multiservice Edge Routers and Juniper Networks T Series Core Routers, a variety
of queuing-related physical interface cards (PICs) provide enhanced queuing functionality.
EQ-DPC as a Baseline
H-CoS functionality varies slightly across different hardware. For purposes of simplicity and
completeness this chapter is based on the EQ-DPC, which currently provides the most complete
H-CoS feature set. The EQ-MPC and Enhanced Intelligent Queuing 2 (IQ2E) PIC have very similar
functionality, with slight variations, while the other PICs have varied subsets of HCoS features
For detailed information on the differences in

CoS functionality across hardware components,
check the Junos Class of Service Configuration
Guide.
Chapter 6-6 Hiera rchical ~r.hp.r:hllind'
41
11
Refer to the Junes Class of Service Configuration Guide for

detailed information on hardware-based CoS variations.
Note
:D
J
~
~)
GO
~
QID
~
~
>
>
>
.,
.,.,
.,
.,
a
(\)
I)
,
!,
Hierarchical Scheduling Concepts (1 of 2)

Terminology
CustomerVLAN (C-VLAN)
Th~ innerVl,AN tag
of a stacked VlAN; often corresponds to
customerCPE
Scheduling and shaping is often used on a C-VlAN toestabHsh
mitlimum c!nd maximum bandwidth limits for a customer
Service VLAN (S~VLAN)

ThebuterVLAN~ag ofa stackedVlAj\l: often corresponds to a
networkaggregation C\ev!cesuchas a DSlAM
.ScheC\ulingand shaping Is often estaplishedfOJ anS-VLAN tp
provideGoS for downstream deViceswith littlepufferipgapdsimple
schedulers
Terminology: Part 1
A customer VLAN (C-VLAN), defined by IEEE 802.1ad, is a stacked VLAN that contains an outer tag
corresponding to the service VLAN, and an inner tag corresponding to the C-VLAN. A C-VLAN often
corresponds to customer premises equipment (CPE). Scheduling and shaping is often used on a
C-VLAN to establish minimum and maximum bandwidth limits for a customer.
A service VLAN (S-VLAN), defined by IEEE 802.1ad, is the outer tag of a stacked VLAN. It often
corresponds to a network aggregation device such as a digital subscriber line access multiplexer
(DSLAM). Scheduling and shaping is often established for an S-VLAN to provide CoS for downstream
devices with little buffering and simple schedulers.
I)
1.l:~ ........ ,..,hi,.,~l ~ .... h.,:r.rill1inP'
Chapter 6- 7
(
Hierarchical Scheduling Concepts (2 of 2)
(
(
Terminology (contd.)
(
(
Traffic control profile

.. configuration component containing scheduler and queuing
properties
Specifically for H-CoS context; applied at physical interface.
interfaces!9t. and logical interface (V LAN) levels
Interface set
User-defined group of logical interfaces (C-VLAN$) or S-VLANs
Committed information rate (CIR)

.. The guaranteed rate assigned to an interface setor VLAN
.. PeC)k information rate (PIR)

Themaximum rate assigned to a port, interface set or VLAN
Also called the shaping rate
Terminology: Part 2
A traffic control profile is a configuration template used to set CoS parameters on a scheduler. It
provides a flexible and simple mechanism to define scheduling properties of ports, interface sets,
and logical interfaces (VLANs). Once defined, you can assign a traffic control profile to different
entities that have the same CoS profile.
An interface set is a user-defined group of logical interfaces (VLANs) within a port. Interface sets
establish the set and reference a traffic control profile.
The committed information rate (CIR) is a configured guaranteed rate assigned to an interface set or
logical interface (VLAN). Physical interfaces implicitly have a CIR.
The peak information rate (PIR) is a configured maximum rate for a port, interface set, or logical
interface (VLAN). The PIR is also referred to as the shaping rate.
Chapter 6-8 Hierarchical SchP.rllllina
C
t!.
Ju nos CI ass of Service
Queuing and Scheduling

Hierarchical per-VLAN queuing
CoS at up to four levels:
LeVel1-Physical interface (pprt)
Level2-lnteiface set (VLAN or logical interface group)
Le\lel3-Lqgical interface (VLAN)
.,
.,
.,.,
.,
Level4-QueLie
Up to 8 queues per logical interface (VLAN)

Each qUeUe has its own scheduling properties
Transmission rate; priority,delay buffers. RED drop profiles
Hierarchical Per-VLAN Queuing

Hierarchical scheduling provides up to four levels of CoS treatment, as shown on the slide, on a
per-port basis. H-CoS supports up to eight queues per logical interface (VLAN). with each queue
having its own scheduling properties.
fa
'''_~_~_l.-.: ...... I c .... h"'.-I"linrl
Chaoter 6-9
Reference
Model
Hierarchical Scheduling nlustrated

Level 2
Levell
Level 3
Level 4
Tran$mit
DROP
Hierarchical Scheduling Illustrated

The slide shows the various levels of CoS that are available with H-CoS.
Each port can have one or more interface sets_ Ports support shaping, to a reduce bandwidth lower
than its line-rate.
Each interface set can have one or more logical interfaces (VLANs)_ Scheduling among the interface
sets of a port is based on a configured CIR and PIR.
Each VLAN has up to 8 queues. Scheduling among VLANs is based on the CIR and the PIR. The
queues provide scheduling of traffic flows, with transmission based on priority, tunable buffers to
provide the ability to absorb bursts or control latency, as well as weighted random early detection
(WRED) to provide congestion control and avoidance.
Chapter 6-10 H ier;::)rr..hir.::ll
~rh/:)rllllinrr
o
("'I
.......

III
~Scheduler Modes
III
Hierarchical Scheduling Levels
Throughput Example
III Remaining Traffic
III
III
Queue Properties in a Hierarchical Scheduling Context
III
Scheduler Modes
,., _____ t...; ....... 1
c ... "' .... ~"Il,.,M"
r.h~Dter
6-11
\.
C
C
G
G
Scheduler Modes
Scheduler configuration modes-available on a
per'"port basis
\l
~
(i
1. Per-unit scheduler
Port-level shaping
-Logical interface (VLAN) scheduling and queuing
Full queue scheduling
II
tl
I No interface sets I
2. Hierarchical scheduler
~ Port-lever shaping
Interfacesetschedulingand quelling
(I
Logical interface (VLAN) scheduJingand queuing
.. Full queue scheduling
Scheduler Configuration Modes

The Junos OS supports two hierarchical scheduling modes. as shown on the slide. These modes are
illustrated on the following pages.
Chapter 6-12 H ierarchir:r.1 Sr.ht:>rlillind
.,
.,
.1
PerUnit Scheduler Mode

Levell.
Level 3
Level 4
Port configured
with per-unit
scheduler mode
" Shaping per port
Scheduler
allocated to
everyVLAN
under the port
Per-Unit Scheduler Mode

Per-unit scheduler mode is illustrated on the slide. The key difference between this mode and
hierarchical scheduler mode is the lack of interface sets.
u; ......,. ..t"hi .... ~1 C::('hFltillnn~
Chapter 6-13
(
(
(
Hierarchical Scheduler Mode

level 1
level 3
level 2
level 4
(
0:
\8
f3
""
CIR
Transmit
I
I
.,
(I
.. Remain ihg" schedulers are

discussed later in this chaptelL
Hierarchical Scheduler Mode

Hierarchical scheduler mode is illustrated on the slide,
(I
Using hierarchical scheduler mode, the following functionaltty is available:
Shaping per port;
Interface sets;
Shaping per VLAN, and up to 8 queues per VLAN;
Sharing of schedulers and queues among VLANs; and
Fine-grained user control over all levels in the hierarchy.
The key difference between this mode and per-unit scheduler mode is the existence of interface
sets.
(I
CD
8
Chapter 6-14 Hier<lrchical SchArtil/in"
Enabling a Scheduler Mode

Hierarchical scheduling
Per-unitscheduling
[edit]
[edit]
us~r@,Ri# show inte;_fac(!s
User@Rlii show interfaces

ge-o./o/.O 1
hierarchical scheduler;
vlan t&gg l;ng ;
9,,-0./0./0 (
ReF :unit~s.cheduler;
Vlan>-ta9g_~ng ;.
unit 100." (
vlalHid :l00;
famify inet (
adflres"s 192 _1,68 _L 1/24;,
"unit 1no (
"vlan_id100;
f'nnily ine"t '(
addoess 192 _168.:1_"1/24;
unit
unit, 20.0, (
'v'lari~id 20.0;
20Dt
'Vlan~,id
?Oo;
fa;'ily, inet J
addr,ess 192_1,68_".2_1/24;"
tamilyinet (
addte~S, 192_168.2_l/24;
Enabling a Scheduler Mode

To enable scheduler mode, add the appropriate statement (shown on the slide) at the physical
interface level of the configuration hierarchy" You can configure scheduler modes on a per-port basis .
(
(
(

III
III
Scheduler Modes
c:
(
~
~ Hierarchical Scheduling Levels
t
I
III
Throughput Example
III
Remaining Traffic
III
III
@l
~.
\;1IftI

..
..
..
..
fA
Chapter 6-16 Hierarchical SChp.rllllind
S)
J
CD
o
o
Level :L-Port (1 of 2)
A.:.:(
~
()
...
e
.,
.,
e
.,..
.,
.,.,
.,.,
.,
Shaping
PIR
.. Maxill\um rate for phYSical interface
Can "shape down" to less than interface speed
I)
CD
Level1-Shaping
Levell includes the physical interface, or ports. Ports support shaping, which is the maximum rate
for the interface. A shaper permits a port to transmit traffic until the configured PIR, or shaping rate,
is reached. Once a port has exceeded its PIR, it is not allowed to transmit packets until traffic falls
back below the PIR. Packets sent to a port that has exceeded its shaping rate are not dropped, but
are stored in the buffer.
U;"...", .. ,..nj,..~1
~!"'hprllllinO'
..
Chapter 6-17
(
(
(
(
Level1-Pon (2 of 2)
CoS configuration
r"
'G.:
Use a traffic control profile
set PIR (shaping-rate)
~
~
Apply to port
Example
I
C
'
[edit class.-of:"'ser'v:ice]
user ~~l# ,show
traffic-cori.trol'-,profiles .(
Ll-port"ptbflle (
shaping-rat~
100m;
interfaces {
ge-O/O/O {
output-ttaffic-f'0ntrol-profile Ll-port-profile;
}
)
Level1-CoS Configuration
To configure CoS for a port within an HCoS context. use a traffic control profile to set the PI R. Then
apply the profile to a port under the class-of-service stanza using the
output -traff ie-con trol-profile statement.
~
~
@
CD
CD
(I
Chapter 6-18 H ierarchicBI Sr.hPtilllino
Level 2-1nteJface Set (1 of 3)

Example
Interface setconfiguration
Interface set creati.on
.; Sele9t individuall()gical
interfaces (VLANs), or ..
Identify a group of dual-tagged
VLA Nspys-vLAN tag
Ra nges are hotsU pported

CClnnotmix ihterfacesettypes
.,
.,
.,
.,
.,
.a
[edit interfaces 1
user@Riil show
,int-erf'a,c~-set_,-A, {
. interface g,,-%/o .!
unit 1,0'0;
urrit 200;
)
inte:rfElCe-s,et-",~
{
intedacege-O/O!Q {
vJ:an-tags-outer 1234 i'
}
}
ge~O/O/O{
Usage notes;
'
"l1i:e _r~ ~,qhi Ca,1-::5cheq ul{{t ~

flexible-..vlan-tagg ing;
unit 1.00 .{
'.'
. . vJ:an- ~dl0 0;
}
...
oOnephy?ical jnterfClclS per

. interface set
urrit 2'00 'C
A logical ihterfClceor S-VLAN tag

CahOn!ypetOng to onejnterlace
set
unit 10.00 (
. vlan-tags:outer 1234,. inner 1000;.
).
... ,
umt 1100 {
vlan~ta'gs QuteF 1234. ihne,, l1PO;.
vrah~.id2QO;
Level 2-lnterface Set Configuration

Level 2 includes interface sets. Two ways exist to combine logical interfaces or VLANs to form
interface sets: select individual logical interfaces (VLANs), or identify a common group of VLANs by
specifying an S-VLAN tag.
Usage Notes
You cannot use interface ranges within an interface set configuration.
You cannot specify an interface set mixing logical interface and S-VLAN tags.
Members of an interface set cannot span multiple physical interfaces. Only one physical
interface is allowed to appear in an interface set.
A logical interface or S-VLAN tag can only belong to one interface set.
Level 2-1nterface Set (2 of 3)

-Shaping
CIR and PIR
-Q uaranteed and
ma~imum
rates for interface set
- Scheduliqg
CIRand PI Rdetermine relative weight between interface
sets
Bandwidth sharing modes (per-port basis):
CI R mod.El-lf any interface sethas CI R defined, sharing is based on
cm
PIR mode-Jfno interfacesethasCIR defined, sharing i$ based on

PIR
When traffic exceeds PIR, interface set stops transmitting
Level 2-Shaping
The CIR and PIR provide guaranteed and maximum rates for the interface set.
Scheduling
Scheduling at the interface set level is based on CIR and PIR configured for the interface set. The
system uses these values to determine the relative weight of an interface set with respect to the
other interface sets belonging to the same port.
The CI Rand PIR determine bandwidth sharing among the interface sets within a port as follows:
If any interface set within a port has CIR defined, bandwidth sharing among the
interface sets is based on the CIR of the interface sets. This method of sharing is
referred to as CIR mode.
If none ofthe interface sets within a port has CIR defined, bandwidth sharing is based
on the PIR of the interface sets. This method of sharing is referred to.,ilS PIR mode.
The PIR is the maximum bandwidth of the interface set in both modes. Once an interface set has
reached its PIR, it is not picked for transmission.
Chapter 6-20 H ierarchir.~1
!=\r,hl=lriIlJind
..
..
:1
Level 2-1nterface Set (3 of 3)

CoS configuration
set CIR (guaranteed-rate) and PIR (shaping-rate)
Apply to interface set

Example
[edit ,c'las,'s-of-setvice]
US""@f{l# s.how
.
teaf f ic~co n tt;o l~ pr.o 'E.iles
L2c interface:"s;'t~prciflle '{
?h,~p:iJ~g..-';~,~,~ ,1,5m,:{
gUaranteed-,rate. '5 Om;

j
e
e
{nied" ces
'tjlt;-:;#ace7~et; A r. ..
...
.
out'put.... traf'fic.,...control-:.profile L2-ln'terface-set,-prOfl1e:'
}
Level 2-CoS Configuration

To configure CoS for an interface set, use a traffic control profile to set the CIR and PI R. Then apply
the profile to an interface set under the class-ai-service stanza using the
Qutput-traffic-control-profile statement.
.,.
_."-'.'--' t:"o_'-_...l I: .... ...,
r.h:::'tntp.rfi_?1
(
(
\,.
Level 3-Logieallnterfaee (VLAN) (1 of 2)

.. Shaping
CIR and PIR
Scheduler map-references associated queues
.. Sohedulihg
CIRa.nd PIR determine relative weight between VLANs
Bandwidth sharing moqes (per-port basis):
crR mode-lfanyVLAN hasCIR defined, sharing based. on CIR
PIRmode.-lf no VLAN has CIR defined, sharing based on PIR
When traffic exceeds PIR, VLAN stops transmitting

Excess bandwidth (bandwidth not allocated to VLAN
CI Rs) s~aring is also proportionate to CI R by default.
Level 3--Shaping
level 3 includes logical interfaces, or VLANs. The CIR and PIR regulate the bandwidth allocated to a
logical interface (VLAN). Because hierarchical scheduling provides a set of queues for each VLAN, a
scheduler map associates the VLAN with its queues.
Scheduling
Scheduling at the logical interface (VLAN) level is based on CIR and PIR. As with interface sets, the
system uses these values to determine the VLAN's relative weight with respect to the other VLANs on
the same port.
Bandwidth sharing among VLANs within a port is determined in a similar manner as interface sets:
If any VLAN under a port is configured with CIR, bandwidth is shared among the VLANs
in proportion to their CIR. This method of sharing is referred to as CIR mode.
If none of the VLANs under a port is configured with CIR, bandwidth is.shared in
proportion to their PIR. This method of sharing is referred to as PIR mode.
The PIR is the maximum bandwidth of the VLAN in both modes. Once an interface set has reached
its PIR, it is not picked for transmission.
CD
CJ
CD
CJ
~
~
o
G>
o
I)
<I
<I
Level 3 Logical Interface (VLAN) (2 of 2)

CoS cqnfiguration
SetCIR (guaranteed-ra.te) and PIR (shaping-rate)
Apply scheduler map (references\eVel 4 queues)
Apply to logical interface

EXample
[edi t,o las S-,O ~~servJce 1
1>ser@l(llf;'s'how
traf:fic-contr:ol~,profl.les "{
L3~un,i.t-P~pfi.le, {
sche'ciule'I:-:-map" scti"ed-map-;ex'ample;
shapin,g-rate' 30mrgU'$:ta'I}t~,ed-J~at,e:-
? Om;
ihte daces .{
g,e-d/q./O (
oJitput-t.taffic~contra'l~prof;i.le 'L1~pptt,-prqfile;
unit 100 {
.q,utp" t~t.ra j'f ic,-c;ont qil ~p r of i,~eL:l<)lni D+ f! "qf,ile;
}
([1)
To configure CoS for a logical interface or V\J\N, use a traffic control profile to set the CIR and PIR.
Within the profile, specify a scheduler map to associate the V\J\N to its queues, and then apply the
profile to a logical interface under the class-af-service stanza using the
Qutput-traffic-control-profile statement.
Note
If you do not include the guaranteed-rate
statement, the logical interface receives a
minimal bandwidth, equal to two maximum
transmission (MTU)-sized packets.
''' _____ 1..: __ 1 C"h,.,A"liOrf
..
C!h;;toter 6-23
Level 4 Queue (1 of 2)
Scheduling
Standard scheduler
Transmission rate, priority, delay buffers,
RED drop profiles
Same as for port'level queuing
H-CoS slightly affects some functionality

Discussed later in this chapter
~
Queues
....
~
I!
~
Level 4-Scheduling
level 4 includes the actual queues that schedule traffic flows, The schedulers at this level are the
same ones used with port-level scheduling. They support a wide range of configuration options and
scheduling mechanisms to provide fine-grained control over the scheduling, buffering, and
congestion control and avoidance characteristics for a VLAN.
Because H-CoS involves the interaction of multiple levels of CoS treatment. some scheduler
functionality is slightly different than when used for port-level scheduling. These variations are
discussed later in this chapter.
Chapter 6-24 H ierarr:hir:~1
~l"h/!lrilllintf
(I
"
Queue (2 of 2)
Example
CoS configuration
drop-profiles {
aggressive '(
,
it,lterp?):ate
Configure scheduler,.
including drop profiles
Transmission rate
Queue priority
Delay Duffers
Drop profiles
.Dropprofile mElPs
{
ipte,rpola,te {
re~p,.xed
J
)
scl1edu1.e r;"'rnaps.
~-cliEtd-fua:p-ex*ple
~ch-be,;
for-warding-dlass netwoik~contro-l
scheduler sch.... pd.:-{
)
...
schedule rs -{
SCh7""l:>e: ..{
't'r;an!!:md~:-ratfQ- pe-rC;,emt 7QJ
buf;fer-pi,ze ,perGe:n}:-. 70 i -
Cohfigure.scheduler map
"'Apply schedLilermap
I>
I>
"
I>
Sci1edul.er map was already

applied withinthe L3 VLAN's
traffic control profile
+9rwat<;lihg-,class be;st-,ef1;,o;1;, licpeduler
P1:'iq'rity:- towf',
drop-profile-map
aggressi ve;
reA?lxe~d;
drop-prof'le~1'!14p
~"li"pri
transml.t::-ra:be:. percent 3D;

buffe-r-.sfze ',percent 3'0;
pr~o-rity; ~i9hf
CD
To configure queue scheduling, configure one or more schedulers and drop profiles. Include the
transmission rate, queue priority, delay buffers, drop profiles, and drop profile maps, and then
configure a scheduler map to associate the schedulers to the desired forwarding classes on the
device.
I)
With port-level scheduling, you applied the scheduler map to an interface. With hierarchical
scheduling, you apply the scheduler map to a logical interface or VLAN. Note that this step was done
earlier, within the configuration of logical interfaces and VLANs (level 3), by referencing the scheduler
map from within a traffic control profile, and then applying the profile to an interface under the
class-of-service stanza.
C
(
(
C
G
G

Ii!
Ii!
Scheduler Modes
II!
Hierarchical Schedulihg Levels
!.~';
,
t
e:
~ Throughput Example
II!
Remaining Traffic
fill
iii
41
<I
~
~
Throughput Example
Chapter 6-26 Hierarchical Sr.hArl"nm'
H..CoS Throughput Example (1 of 4)

~~hapingRate
VLAN 10
"'Guaranteed Rate
~2(JOMbps
20Mbps
(fi
. . . ,.1:>... 2.20.0.Mbps
Mbps
tIlIllI>
~;.! fl.:.>.
VLAN. 20 . 0.:.:
. ..
200.. M bps
'::: Q,:.4 Mb
II""PS
200Mbps
.~200MbPS
VLAN30
~1lI> 5Mbps
Mbps
vLAN 40
:. .'..
':.' fl:>. 200. Mb... PS
~ 15 t>1 ilps
Ill>
EachVLANhas.3 ql,leues
Queue
Transmtsslon Rate
H-CoS Throughput Example

In the example on the slide, a port is configured with interface sets, VUlNs, and queues as follows:
The port is shaped to 200 Mbps;
The port has two interface sets A and B;
Each interface set has VUlNs configured under it;
The scheduling parameters of the port, interface sets, and VUlNs are shown on the
slide; and
Each VUlN has three queues with transmission rates shown on the slide.
This example is designed to illustrate the relevance and application of CIR and PIR by showing how
the values at one level can affect the values at other levels.

Expected throughput behavior
Reminder: Excessbandwidth,sharing
isP[oportionate to CIR bydefault
-Throughputofthe portis 20b Mbps

Interface sets A and B share the total port bandwidth in a
1:2 ratio
VLANs 10 and 20 share interface setA's bandwidth in a 1:2
ratio
VLANs30 and 40 share interface set B's bandwidth in a 1:3
ratio
At each VLAN level, the queues share the VLAN'sbandWidth
in a 2:3: 5 ratio
41
Expected Throughput Behavior

USing the scenario on the previous page, the slide describes the ratios used to share bandwidth
among interface sets and VLANs.
o
o
\I
<I
<I
Oi
Chapter 6-28 Hierarr.hir.;:tl !=:rhQrllllinrf

ThroL!ghput results
For the port, the interface sets:
Use up their guaranteed bandwidth of60 Mbps
Sharethe excess bancjwidth in the ratio of 20 Mbps: 40 M bps
For interface set A the VLANs:

Use uptheir guaranteed bandwidth of 6 Mbps
Shareth.e excess bandwidth in theratio of2 Mbps : 4 Mbps
Forinterface setB. the VLANs:

Use up their guaranteed bandwidth of 20 Mbps
Share the excess bandwidth in the ratio of 5 Mbps; 15 Mbps
Throughput Results
The slide further describes how bandwidth is used, and how excess bandwidth shared among
interface sets and VLANs. The ratios are displayed as CIR values.
1:_~_~_l.o.l .......... 1 C ..... horl"lil''Ir'l..
Cht=lOter 6-29

Throughput calculations
-Available port throughput: 200 Mbps
-Interface set A: CIR + 1:2 ratio of 140 Mbps (remaining on port)
20 Mbps + 46.7 Mbps == 66.7 Mbps
- VLAN 10: CIR + 1:2 ratio of 60.7 Mbps (remaining on into set)
2Mbps + 202 =; 22.2 Mbps
- Queue 0: 20% of 22.2 Mbps (VLAN 10)

20%x222 = 4.4 Mbps
Throughput Calculations
The bullets on the slide display the full calculation process for queue zero on VLAN 10. You can apply
the same methodology to calculate effective throughput for other VLANs and their queues. The table
provides a complete list of effective throughput for the port, interface sets, VLANs, and queues .
Chapter 6-30 Hip-rBrr.hir:::l1
,~,..hQrllllinrl

III
III
Scheduler Modes
III
III
Throughput Example
-7 Remaining Traffic
III
III
Remaining Traffic
' ' ' - .. ---I..:~ ...1 C ..... k"rt"linl'f
..
Chaoter 6-31
(
(
(
(
Remaining Traffic
.. Remaining traffic
All logical units (VLANs) without a traffic control profile
applied
Grouped per interface set
One group for VLANs not in interface sets
~
@l
~
.. Remaining schedulers
Identical to regular L3 logical interface (VLAN) scheduler

Each remaining traffic group shares one scheduler, one set
ofqueues
Remaining Traffic
So far this chapter has discussed explicitly applying traffic control profiles to interface sets and
individual VLANs. However, the Junos as also provides an efficient way to group VLANs together with
a single configuration statement and implicitly apply a traffic control profile to those groups. The
Junos as groups VLANs with no associated CoS profile on a per'interface set basis, with one
additional group for VLANs not associated with interface sets.
Remaining Schedulers
A remaining scheduler is identical to an independent VLAN scheduler with regard to scheduling
properties and bandwidth sharing. You can configure it with CIR, PIR, delay buffer rate, and queuing
parameters. A VLAN that does not have an associated CoS profile (traffic control profile) is assigned
to a remaining scheduler.
Chapter 6-32 Hier;;}rr.hir.:=!1 C::,...hon"U ... rr
(
(
(
(
f;\
<~:J
W
ED
[J)
CD
CD
Remaining VLANs
Level 1
Level 4
Level 2
Remainingtraffic
for intel'face set
lID
~
.,
VLAN 11
~. PIR
~
.. GIR.
~
VLAN 20
. Remaining;
VLANs 21,22;23
Remaining
traffic for pOl't
I)
Remaining VLANs
The slide illustrates the concept of remaining traffic and remaining schedulers, In the top half of the
slide, groups of VLANs under interface sets share common schedulers and one set of queues, VLANs
12,13, and 14 under interface set A, and VLANs 21, 22, and 23 under interface set B, use their
respective interface set's remaining scheduler. At the bottom of the slide, a group of VLANs not
associated with an interface is set to share one scheduler and one set of queues. VLANs 31 and 32
use the port's remaining scheduler.
Ie
10
"'_-----1..:--1 r::." .... h ..... ~"Hn,..".
.,
Chaoter6-33
(
Junos Class of Sewice
Remaining VLANs-lnterface Set
(
(
CoS configuration
C
(

Same as L3 logical interface (VLAN) configuration
SetCIR UJ\.laran.teed..,..rate) and PIR (shaping-rate)
Apply scheduler-map (references level 4 queues)
Apply to interface set

Useoutput-traffic-c:ontrol-pro.file-remaining
statement
'"
. Example
~
.;
""i!'iiI
\it
~
@
~
~
[,ed'i':t c,~.ass--of-serviceJ
41
user@Rl# .hQw
i:.'raffic--c'onttcH-profiles {
L~- VLl'\N-p rofile'-remaining
sched'ule r-map sChed"':nia'P-exantpJ.e;

shaping-rate 30m;
guar-anteed:.....,ra.te 2,Om}
)
inte rfa,ce'- set- A {

out u -ir f ie-contro...;.
(,
of "''Ie
'2'''''''in erface-set-
of-ile,'
~
~
@
Remaining VLANs-lnterface Set CoS Configuration

You configure CoS for remaining traffic within an interface set much like a logical interface or VLAN.
Use a traffic control profile to set the CIR and PIR for the VLAN group. Within the profile, specify a
scheduler map to associate the VLAN group to its queues, and then apply the profile to the
appropriate interface set under the class-of-service stanza. Note that you must use the
output -tra ffic-control-profile-remaining statement to encompass remaining VLANs
under the interface set.
Note
Without a guaranteed rate, remaining traffic
receives a minimal bandwidth that is equal to
two MTUsized packets.
Chapter 6-34 H ierarchicFlI ~r.h,::..rfllljnr1
LJ
LJ
o
o
~
~
~
4i>
(I
~
I)
Remaining VLANs Pori

CoS configuration
Same as L3 logical interface (VLAN) configuration
Set CI R (guataU teed-ra te) and PIR (spap ing- r: a.te)
Applyschedulermap (referehceslevel4 queues)
Apply to logical interface

Use putput-traffic-control-pro.file-remaining
statem.ent
Example
[edit
,blass~:Qf-se'iv ice]
user@Rl# s'how
. ttaific.~contFoi-ptofil'l~ (
L3~VLAN-ptdfile-,remaining
I
}
'
...
ge-O/O/O {
out trt....,traffic-control"':' 't'ofile Ll..:.... -ort- rofile":
outp'ut-ttEiff'ic-,cont'r,ol 'profile-remaining' L3:"'VLANUn1t lOO t
rofile~;:i:'etnainin'
CD
I)
I)
Remaining VLANs-Port CoS Configuration

Port-level CoS configuration for remaining traffic is largely the same as for interface sets. Use a
traffic control profile to specify CIR, PIR, and a scheduler map for the VLAN group, and then apply the
profile, this time to the appropriate physical interface under the class-of-service stanza. Once
again, note that you must use the output-traffic-control-profile-remai.ning
statement to encompass remaining VLANs under the port that are not part of interface groups.
Note
Without a guaranteed rate, remaining traffic
receives a minimal bandWidth that is equal to
two MTU-sized packets.
..
I)
''' _____ 1...=_-.1
c:.- .... L-. .... rI"li..,.f.
r:hnnter 6-35
\

III
II!
Scheduler Modes
III
II!
Throughput Example
II!
Remaining Traffic
~Queue Properties .in a Hierarchical Scheduling
Context
III

Chapter 6-36 Hi erFlrr.hir.:=!1 .c::;,...hQrjulinr1"
Queue Priority
.. Effect of interface sets and VLANs on queue
scheduling
Queues have two priorities, based on VLAN rate
VLAN < CIR = queue priorities function normally
CIR < VLAN < PIR < '=' all priorities (except strict-high) becbme eXcess
,
I CIR < VlliAN ~~ PIR I
VtAN> PIR
,Strict-High
strictcHigh
(buffered)
High
High
Exce$s
(buff,ered)
Ml'ldium~High
Medium*
'Excess
(buffl'lred)
Medium-Low
M~diurri*'
Excess
(buffered)
J.;ow
Low
Excess
(buffered)
~~
VtAN < CIR
Queue Priority
,~
Strict-High
*On EQ-DPCs, mediutn,high~ndmec\iurn-low

software qlleuessilares. hardwE!reqti~ue.
.
..
.
""
"
,';
,-
-"
'
"
Effect of Interface Sets and VIJl.N$ on Queue Scheduling

With multiple levels of hierarchy, VUlNs compete for a port's bandwidth. This is in contrast to
port-level queuing, where queues compete for a port's bandwidth. In port-level queuing, a queue's
bandwidth utilization determines its priority region. For hierarchical queuing, it is imperative that the
bandwidth utilization of a VUlN influence the priorities of its queues. Queues belonging to VUlNs
using bandwidth below their configured guaranteed rate should be given higher priority over queues
of VUlNs using bandwidth over their configured guaranteed rate. If a VUlN is using bandwidth over
its guaranteed rate, the priority of its queues must be lowered.
Aqueue has two priority levels, based on the bandwidth utilization of its VUlN. When a VUlN has
utilized bandwidth less than its configured guaranteed rate, its queues ope rats with their configured
priority. When a VUlN exceeds its configured guaranteed rate, its queues operate in the excess
priority region.
To ensure that low latency traffic always meets strict latency and jitter requirements, strict-high
queues always operate with strict-high priority regardless of bandwidth utilization of its VUlN. Note,
however, that a strict-high queue is still bounded by the shaping rate of its VUlN. All other queues are
assigned a common excess priority when the VUlN exceeds its guaranteed rate.
Priority Queuing Process for It..CoS
(
(
How priority queuing

works in H-CoS context:
YLANs and interface sets

compete for a port's
ban.dwidth
~
~
4i
Transmitfrom all stricthigh andhigh priority

queues
Transmitfrom medium
priority qUeues
Transmitfrom low
priority queues
~.'"
~
WeigfJtsd
Rou.lJd
Robin
Transmitfrom excess
~
~
~.;
v:a
How Priority Queuing Works in an H-CoS Context

The scheduling algorithm used for H-CoS includes a combination of PQ-DWRR and Intelligent
Prioritization (also referred to as priority propagation). With port-level queuing, if a lower-priority
queue is already transmitting a packet, a high priority queue needs to walt only for that queue to
finish transmitting the packet before it is scheduled again. With intelligent prioritization for H-CoS,
the priority of queues waiting to send packets is considered at all levels in the scheduling hierarchy.
A high priority queue needs to wait only for other high priority queues before being picked for
transmission again.
The priority queuing process for H-CoS includes VLANs and interface sets competing together as
follows:
Transmit packets from all strict-high and high priority queues of all VLANs and interface
sets;
Transmit packets from all medium-high and medium-low priority queues;
Transmit packets from all low priority queues;
Transmit packets from all excess priority queues; and
An interface set or VLAN that has reached its PIR is not eligible to be picked for transmission.
I)
8
8
8J
8
Chapter 6-38 Hierarchic:.::'!1 ~('hp,rhll;nt'f
Transmission Rate (1 of 2)
Excess bandwidth (bandwidth not allocated to VLAN
CIRs)
Shared using one of three modes:
CIR mode-proportional to CIR (default)
.. PIR mode-proportional to PIR
Equalsharing
Can setmode perport

Applies to all tnterfacesets
Can setmode pe(interfaceset

Appliesto.all contained VLANs;o\lerrides portmodesetting
Excess Bandwidth Sharing

Any bandwidth left after all VLANs have used their guaranteed bandwidths is referred to as excess
bandwidth. Excess bandwidth can be shared among the VLANs in proportion to their CIR or PIR, or it
can be shared equally.
You can set the mode per port to configure all the interface sets under the port. You can also
override the port setting by configuring the mode at the interface set level .
Junos Glass of Service
(
(
(
(
Transmission Rate (2 of 2)
Excess bandwidth sharing-configuration

Sharing proportional to CIR or PIR
" Set equal to maximum effective transmission rate among all
queues under a port or interface set
Factor ofVLAN CIR andqueuetl'ansmissionrate
~
~
Use equal option
[edit,_ class-oI-_se.r;,vice int~~tgGes}

(lser@Rllf show
~
.
.
i,nte.rfa.ce:-set__ A {
excess-bandw:l.dth-share equal;
}
)
ge~OJOI 0 i
exc~ss-ba,!dw.i<!th-sh",re
}
proportional .14000qOO;
Excess Bandwidth Sharing Configuration

The default excess bandwidth sharing mode shares bandwidth among VLANs in proportion of GIR. If
no GIR is defined, PIR is used. To provide fine-grained control over the sharing of the bandwidth,
configure maximum queue bandwidth to enable the Junos as to make accurate scheduler
calculations. This configuration allows the Junos as to fine-tune the schedulers to provide a high
degree of accuracy in sharing bandwidth between VLANs.
The maximum queue bandwidth value should be set equal to the maximum effective guaranteed
rate among all the queues under a port or an interface set. To calculate the maximum queue
bandwidth under a port or interface set, identity the queue with the highest transmission rate.
In the example on the slide, the maximum queue bandwidth of the port is 14 Mbps. The interface set
is configured to share excess bandwidth equally among its VLANs.
Note
For enhanced IQ PIGs, use the excess-rate
statement to determine the amount of excess
bandwidth to share.
Chapter 6-40 Hierarchir:i=lJ .C:;r..h~rlillind"
~
~
Sharing equally
Example
C
C
Delay Buffers (1 of 3)
Buffer size
Rate used to determine delay buffer for port-based queuing
is interface bandwidth (implicitly known value)
Rate used to determine delay buffer is VLAN bandwidth
VLAN bandwidth is not implicitly known:must be configured in
VLAN traffic cbntrol profile
Delay buffer rate-configurable parameter, provides reference for
buffersiie calculation
BL,IffetsiZt3 is cah;:uIClted implicitlyusingCIR (ifhO delay b~lffer rate)
or PIR{if rioCIR)
Maximum bUffersilefor EQ-DPC == 500 ms

Variesfor other hardware
No dynamic memory allocation
Buffer Size
The amount of buffer that is allocated to all the queues of a VLAN is defined using the traffic control
profile of the VLAN, Unlike port-level queuing, the bandwidth of a VLAN is not implicitly determinedit needs to be configured,
The rate used to determine the delay buffer allocated to a VLAN is configured as part ofthe traffic
control profile of the VLAN. You can configure the buffer rate explicitly using the
delay-buffer-rate statement, or the system can calculate the rate implicitly based on the
guaranteed rate or shaping rate configured in the VLAN's traffic control profile.
The maximum buffer size for EQDPCs is 500 ms, which is equivalent to 500 Mbps or 62.5 MB. The
maximum buffer size varies based on the hardware used.
Note that in an HCoS context, delay buffers are not elastic; that is, buffers do not su pport dynamic
memory allocation.
''' _____ 1.-.: ......... 1 C"'horlulincr
..
Chaoter 6-41
(
(
Example
'
[edit d.ss-oi"service)
traffic-contro~-profilea
Calculating effective
L3-~t-praf~e
sc'heQUler-map sched,-map,....;,exe.mp~e;
shaping-rate 30m;
buffer size for queues
'guaranteed-'rate 20m;
~ de1 ay-b1.1.f!ter-rate 40m.
~<r
... I
L4 queues' schedulers , ~ ~.:nterfaces {

,,/
. ~e-P/O/q (
use L3 delay buffer
,. I
01.l-tpttt-tr~ffic-controJ,-profil.e. Ll-p,ort-'prof,ile;
I
\
unit 10,0, (
rate as reference
I
\
outp,ut:""traffic-controJ,-profile L3-unit-profile
I
\
bandwidth
\
\)
\
VLAN pahdwidth
\
becomes 'interface , \
'bandwidth' for
'calculating buffer size
Same calculations
as for port-level queuing
If no delay buffer rate,

system uses CI R
~hedulera
sch;o-he
t ailsmit-rat
ercent 7 .
'buffer-s'iie ercenb '-70priorit,Y lO,'W;
dr,op-profile.... m_ap . . . d.i:op-profile a,'gg.ressive;
drop.-profi.le-map . . . _dr_op~'pr,qt:ile rela:xedi
a,c~-pr.i
'"
,
,
{
transmit-rate ercentap
buffer-si.ze ercent 30;
prcr..or.l. Y
g ;
.'
.s~heduler"':'tn~pa
;!:Ichl;d:....ln~p.-exa.mple
{
forwardi,ng-class best-effort scheduler s'ch-bei
forwardin!if-class networ,k-control scheduler
.cl,-p"i;/
If no CIR, system uses PIR
Calculating Effective Buffer Size for Queues

To configure delay buffers, add a buffer delay rate to a traffic control profile. Then apply the profile to
a logical interface (VLAN) under the class-of-service stanza using the
output-traffic-control-profile statement. With the delay buffer rate set, you can
configure schedulers as usual, including buffer size.
I n practice, the logical interface's delay buffer rate becomes the reference point for the schedulers.
In the example on the slide, the logical interface's traffic control profile indicates a reference
bandwidth for buffering purposes of 40 Mbps. The traffic control profile also includes a scheduler
map that associates the two schedulers shown. The schedulers specify that their effective buffer
delays should be 70% and 30% of the maximum buffer size (500 ms), or350 ms and 150 ms. These
values equate to 1.75 MS and 0.75 MS, respectively.
The primary mechanism used to determine the amount of delay buffer allocated to a VLAN is the
delay buffer rate in the traffic control profile of the VLAN. If no delay buffer rate is configured, the
guaranteed rate configured in the traffic control profile ofthe VLAN is used. If no CjR is configured,
the shaping rate configured in the traffic control profile of the VLAN is used.
Note
If you do not include the delay-buffer-rate
statement, the logical interface receives a
minimal delay buffer rate equal to 2 MTU-sized
packets.
II
Allocating buffer space

Levels 1-3 support
delay buffer rate
configuration
(euit; _class~9f'--s~_rvice]
t,raffic-c::ont,r61-profile-s f
Ll-;port--pro,file (
s
in -rate 100m'
del a buffer~rate-200m;
)
L2-inte rfac.9-'set--profi 1e '{
sJ:iapiiig-r.gt~ 75m';
guaranteed-rate
).
SOm-;:
)delay-.buf,fer'-'rate -100m;(
Each level uses level

below as reference
bandwidth
Sum of buffers at each
levellTlust not exceed
level below
Example
L3-unit-profile {
S!ched~l~_r'-_n,tap s'Ched-map-exampl,-~';
_shap.i:~g":"'rate 30m;
guaranteed-rate 2.0m';
I delay
)
inteifad'es
,
buffer- rate,
35m I
-t
interface-set: k (
output-traff.l.c-.control-profile L2~
int~rfaqe-s'~t-pr~file;
.)
90-'2/010 {
,
output-traff.ie~corit):'o'l-"p.r-of:i.le _L1,-poitprofilE:l;
unit 100 (
pi::'o~.:i..le'i
Ql).tput' ....t_r~f'fic-c<?,r:ttroi-proii.~le L~..;.uni:t""
.)
Allocation Buffer Space

Levels 1, 2, and 3 support allocation of buffer space. Each level uses the level below as its
bandwidth reference. However, note that the buffers at each level must not exceed the level below.
The Junos as provides statistical multiplexing when not all VLANs are using their allocated share of
the memory. The amount of delay buffer provisioned can be oversubscribed by configuring the delay
buffer rate to be higher than the guaranteed rate of the VLANs.
,. - ' ___ "'l_~1 e ... hnrllliind
Chapter 6-43
(
(
RED Drop Profiles

Drop profiles
Use segmented, with only two fill levels
Minimum queue depth; below it. drop probability is 0
Maximum queue depth: above it. drop probability is 100
Linear increase in drop probability between min. and max, queue
depth
lO()
Example""
Drop
Probability
tt
o
Min queue
depth
"
[edi t c;:l~:sS-df-s~rvice]
drop-profiles {
s'eglllenteq-s"tyle-profile
fill-level ;25 drop-probability 0;
fill~level 90 drop-probability 90;
)
Maxqueue
dept:Jj
AveragEiQueue Depth
Drop Profiles
The general function of RED drop profiles-to provide congestion control by selectively dropping
packets based on user-configurable drop profiles-is the same as for port-level scheduling.
Configuration is largely the same as well, but with some changes in implementation.
The drop probability is determined by analyzing the queue depth. When the queue buffer utilization
is between 0 and the first configured value (the minimum queue depth), the packet is not dropped.
When the packet is between the minimum queue depth and a second configured value (the
maximum queue depth) the drop probability is linear, from the minimum queue depth up to the
maximum queue depth. Above the maximum queue depth, the drop probability is 100%.
In the example on the slide, when the queue depth is between 0% and 25% full, there is no chance
of a drop. When the fill level is between 25% and 90% a linear increase in drop probability occurs.
When the queue depth reaches 90% full, the drop probability is 90%. When the queue depth is
above 90%, drop probability is immediately 100%.
When configuring drop profiles in an H-CoS context, follow these guidelines:
Use only the segmented configuration method;
Configure only two entries (representing minimum and maximum queue depths); and
In the first entry, configure the drop probability to 0 (the second entry can be whatever
you want).
Chapter 6-44 Hierarchir.;:}/ ~rh.:>rlllli .... <1'
(I
11!1
11!1
Scheduler Modes
II
III
Throughput Example
III
Remaining Traffic
III
-7 Putting It All Together

(I
(I
_.1'
'I/!U
Configuring Hierarchical Scheduling

1. Configure physical interface for H-CoS
Add hiera.rchical-scheduler statement
2. Configure interface sets

3. Configure schedulers, including drop profiles
4. Configure scheduler maps
t
II
t!i
Associate schedulers and forwarding.classes
~
~
5. Configure traffic control profiles
Associate scheduler maps to logical interfaces (VLANs)
6. Apply traffic control profiles to ports,ihterface sets, and

logical interfaces (VLANs)
~
~
@
Hierarchical Scheduling-Configuration Steps

The slide lists the general configuration steps to implement hierarchical schedulers on Junos
devices. The following pages expand these steps.
Chapter 6-46 H iernmhir.:=il !=\r,hAnIIJind
..
.,
.,
.,
.,
~
.J
o
o
o
o
o
o
o
Configuration Example Illustrated

Level.1
Level 2
Plfl200Mbps
CIR20 Mbps
(I
I>
(lD
(J:D
un.it. 0
yLAN 10
Leilel4
-.)1.'.; PIR200 Mbps

\il]~ GIR2Mbps
v~~ti1 !~~::~::;ps
tw ~.PIR200M.
QueueD
20% transmit:-mte
Unit2,3,4
..
'. . . . . 1
...~ Glrl4- Mbpsbps
VLAN 12,13,14
I>
I>
LevelS
PIR'200Mbps
I~.
Unit5
PIR200.M
...bps
fi V-VLAN 30 ll"~.GIR 5Mbps
.Unit~
I
I. . ~
1"1iA
. &l '.
Queue2
~ ~d% iiarisinit-rate
\l!> PIR 200 Mbps
VLAN$1~! ~GIRi5MbPS
Unit7,8,9
VLAN 32.:;33,34
0~! /!lI>
PIR200Mbps
CIR 15Mbps
I>
Configuration Example Illustrated

The slide illustrates the requirements of a configuration scenario. The following pages shows how to
configure a device to meet these requirements.
I>
I>
I>
I>
iL
rl>
~.
F'
10
(
Configuring Physical Interface for HmCoS
(
(
Example
EnCjble H-CoSon
physical interface
[edit interfaces]
ge-O/O/O {
" ' - _ hierarchic;al-scheduleri

vlan-tagging;
unit 0 {
vlan-.id 10;.
}
}
unit 1 {
vlan--'id 11;.
}
}
}
Configuring Physical Interface for H-CoS

The slide shows the configuration of the physical interface. In this case, the ge-OjO/O interface uses
the hierarchical-scheduler statement. Note that without this statement, H-CoS does not
work.
Chapter 6-48 Hierr:lrr.hir.:::I1 !=:,..h.o.n"Ii ........
(
(
Configuring Interface Sets
Example
Config;ure logical units

Within interface set
[edit ,inter-faces]
_ _ _--"" inte['face-set A {
interface ge~O/O/O {
unit 0;
unit 1;
unit, Zt
ul/it 3;
u,nit '4;
}
}
Configuring Interface Sets

The slide shows the configuration of the interface set. In this case, the set contains logical interfaces
(VLANs).
11 _____ \,..,: ........ 1 C,.,I-,,,I'I,,lintf
Chaoter 6-49

Example
[edit class-af-service]
sClledulers {
sched-qO {
trans!1)it-rate percent 20;
Configure properties of
queues using schedulers
sched-ql {
transmit-rate perGent 30;
}
sChed-cj2 {
transmit-rate per.cent 50;
buffer.-size percent .50;
}
}
No drop profiles areconfig'IJred in this example.

The slide shows the configuration of the schedulers (there are no drop profiles in this example).
Three schedulers are configured, reserving 20%,30%, and 50%, respectively, of transmission rate
and buffer size.
Chapter 6-50 H ierFlrr.hir..::I1 ~f"ht:.rh llinrt'
Configuring Scheduler Maps

Schedulers do nothing until they are
referenced in a scheduler map.
Example
, '
Associate schedulers to
queues/forwarding classes
r.....;._ _...:...._......;._...:...._ _ _ _ _ _,
[edit cl;;iss-bf~se~viCe]
5 chedule~-maps {
schec\uler-map-qO-ql-q2 {
'---""0
fo.rwarding~c.lass 'fc,Q schec\uler, sChed-qO,
f'ol:war4ing-claps ,fC;l sche,duler sched-ql;

forWardin9:-class .feZ schedtller sctled-q2,
}
}
Configuring Scheduler Maps

Schedulers are designed to manage traffic for a particular forwarding class, or queue. However,
schedulers don't actually do anything on their own. Scheduler maps provide the link between
schedulers and forwarding classes (queues).
The slide shows the scheduler map configuration. Each forwarding class is associated with a
scheduler, thus providing each queue with its scheduling parameters.
Note that custom forwarding classes must be defined at the [edit class-of-service
forwarding-classes] level of the hierarchy.
,, _____ t...: ....... C .... hoNlllinrf
.,
Chaoter 6-51
(
(
(
Configuring Traffic Control Profiles
(
(
EXample
Coflfigllre traffic oontrol
profilef(j~ iriterface set
E
G
[edit class-of-s'ervice]
traffic-contrql-poofiies
poofile-set":A (
shapin\!- oate 200m;
guaranteed-rate,~Om;
Configure a .200 M, 5 M
scheduler with.3 queues
poofile-PIR-200M-CIR-SM (
sched1l1er~map . scheduleo-m!,p-qO-ql-q2;
shaping- opte 200m;
guaranteed-rate Sm;
Configure a 2QO M,i5M

sch.~dulerwith 3 queues
poofile-PIR-200M-GIR-15M (
scheduleo-map scheduleo-map-qO-ql-q2;
shaping-rate. 2 OOm;
.
gua,ranteed-rate 15m;
COnfigUre Cl 20b M:2M

scheduler with 3 queues
profile-.PIR~200M-CIR-2M
Configure Cl200 M,4 M

scheduler with 3 queues
prpfil'H?IR-200M-CIR-4M (
schedule';cmap schedtiler-map-qO-ql-q2;
shapingcrate; 200m;
guar~nteed'-,ra.te 4m,;
611
selieduler~map scheduler-map-qO-ql_q2;,
sh!,ping-rate 200m;
g,uaran'ie,ed- rate .2m;
..
Configuring Traffic Control Profiles

In an H-CoS context, scheduler ma ps must be associated to a VLAN by being referenced within a
traffic control profile (rather than referenced by an interface, as with port-based queuing).
The slide shows the traffic control profiles configuration. All profiles have a CIR and PIR, and each
VLAN profile specifies a scheduler map, to associate a VLAN with its queues.
(8
Chapter 6-52 H ierarchicAI ~r.h,::.rililind
:)
J
J
P'I
. ,.. '. .
U
Ap
ng
c Control P.,..,.,.. . .mlesPori and Interface Set
CD
CD
Example
Configure excess bandwidth
share for the whole interface
{edit class-ai-service]
interfaces {
~==========~""'Configure scheduling properties

for VLANs 32, 33, 34 that share
a scheduler and don't belong to
any interface-set
9 -0/0/0 {
excess-handwidth-!!5hare proportional 25500000;

output-traffic-control-profile-remaining profile-PIR-200M-CIR-15M;
interface-set A {
Configure excess bandwidth

share for the interface set
excess-bandwidth-share proportional 2550000Q;
output-tr a f f.:Lc-control- p r ofiie pr oiil e- set-Ai
Configure PIR and CIR for

interrace set
Qutput-tr a ffic-c ontrol-pro'file- remaining p rO;.l.,- E'n.-200"-"IR.-4'.1\
Configure scheduling
properties for VlANs 12, 13,
14 that share a schedUler
Applying Traffic Control Profiles-Port and Interface Set

The final configuration step is to apply each traffic control profile to an interface, in the outbound
direction.
The slide shows the port and interface set configuration. The port and interface set have statements
for how to share excess bandwidth. The interface set has a statement associating a traffic control
profile. The port and interface set also each have statements that apply a traffic control profile to
remaining traffic.
,n_~~
..... h; ...,...,l
C ... horlulinrt
Chapter 6-53
Applying Traffic Control ProfilesInterfaces

Example
[edit class-at-service]
intere.ce:!l {
ge-O/O/O (
unit 0 {
~p:ro:p:e:rt:ie:s:fo:r:V:LA=N=10::!:________
Qutput-traffic-control-profile prafil e-PIR-20 OM-eIR-2M;
properties for VLAN 11
1--------...,..
Configure scheduling propertiesforVLAN 30

that has its own scheduler and queues. but
does not belong to any interface set
unit 1. {
output-traic-control-profile profile-PIR-ZOOM-CIR-4M;
unit 5 {
Qutput-traffic-control profile profile-PIR-200M-CIR-SM;
unit 6 {
output-traffic-control profile profile-PIR-2DOM-CIR-15M;
Configure scheduling properties forVlAN 31

that has its own scheduler and queues. but
does not belong to any interface-set
Applying Traffic Control Profiles-Interfaces

This page continues from the previous one, applying traffic control profiles to interfaces in the
outbound direction.
The slide shows the logical interface (VLAN) configuration. Each unit has a statement associating a
traffic control profile to its respective VLAN.
Chapter 6-54 Hierarchical Sr.hArfillinO'
Summary
Identified the purpose of hierarchical scheduling
Listed the two scheduler modes
Described the characteristics of the four levels of
hierarchical scheduling
Configured the four levels of hierarchical scheduling
Managed remaining traffic
Discussed how hierarchical scheduling affects queue
properties

The purpose of hierarchical scheduling;
The two scheduler modes;
The characteristics of the four levels of hierarchical scheduling;
The configuration of the four levels of hierarchical scheduling;
The management of remaining traffic; and
How hierarchical scheduling affects queue properties.
,'l _____ I...: ......... 1 C .... horhllind
Chapter 6-55
(
Review Questions
1. How many CoS levels does H-CoS support? What are
they?
2. What are the two scheduler modes? What is the
difference between them?
3. What are the two ways to populate an interface set?
4. By default, how do interface sets and logical
interfaces share bandwidth?
5. Whcrt is the function of the scheduler map within the
VLAN's traffic cOhtrol profile?
6. What is remaining traffic?
7. How is ql!eue priority affected by H,CoS?
Review Questions
1.
2.
3.
4.
5.
6.
7.
(
(
(
(
C
(
4
@
~
~
til"I
(I
~l
Chapter 6-56 H ierarchicr=l1 Sr.hprililincr

Configure a scheduler mode
Configure schedulers, including drop profiles
Configure scheduler maps
Configure traffic control profiles
Apply traffic control profiles to ports, interface sets,
logical interfaces (VLANs)

The slide lists the objective for this lab.
Chapter 6-58 HierarchicF,l1 Sr.hprirllind
~)
:)
:J
8
Q
GJ
I)
~
~
~
...,
....
I)
..I.
~

Chapter 7: Rewrite Rules
(
(
(
(
Chapter Objectives
able to:
Identify the purpose of rewriting packet headers
Define rewrite rules and tables

Configure and apply default and custom rewrite rules
List supported rewrite combinations
The purpose of rewriting packet headers;
Defining rewrite rules and tables;
Configuring and applying default and custom rewrite rules; and
Listing supported rewrite combinations.
Chapter 7 -2 ReWritp. RillA.
(
(
(
(
Agenda: Packet Header Rewrite

~ Packet
Header Rewrite Overview
.. Rewrite Rules and Tables
Packet Header Rewrite Overview

OOIAlrito Rlllp.~
Chapter 7-3
(
CoS Processing-Packet Header Rewrite
(
(
(
(
(
C
C
Ingress
~
~
COS Processing-Packet Header Rewrite

Rewriting the class of service (CoS) bits in a packet header is the final stage of the CoS process.
Once packets have been scheduled for transmission, the device can mark the header with CoS bits,
which then can be used by the next-hop device. At the next device, the CoS process begins again,
starting with a CoS-marked packet.
Chapter 7-4 Rewrite Rules

.. Role of packet header rewrite:
Convey a packet's CoS profile to the nexthop device
Set the value of the CoS bits within the paCket's header as it leaves
the current device
Assign CoS value based onforwardihg class and PLP
Perform the opposite function of the SA classifier

SA classifier translates ihcoming packet's CoS value t() forwarding
classandPLP
Packet hei'lder reWritetranslates outgoing packet's forwarding
claSs and Pl.,P to CoS va 1\,le
.. Contribute to
network
CQSconsj~tency
and continuity throughout the
Role of Packet Header Rewrite

Forwarding class and loss priority form the CoS profile of a packet in a router, The purpose of packet
rewrite is to efficiently convey a packet's CoS profile to the next-hop router, based on the forwarding
class and packet loss priority (PLP) value,
Rewrite rules essentially perform the opposite function of the behavior aggregate (SA) classifier
(used when a packet enters the router), As the packet leaves the device, the CoS profile can be
communicated to the next-hop router by marking the packet's header with appropriate CoS values,
providing a consistent end-to-end CoS policy for packets traversing the network,
Cou, .. ito RIII,:;lo~
Chapter 7-5
Packet Header Rewrite Options

The Junos operating system supports the following
packet header rewrite markings:
IPv4DSCP
(
(
(
(
<Jli
IPV6DSCP
III
IP precedence bits
tvIP LS EXP bits

e1EEE802,lp CoS bits
eIEEES02.1ad drop eligible indicator (DEI) bit
Packet Header Rewrite Marking Options

The slide lists the COS types you can set on outgoing packets.
Chapter 7 -6 Rewrite Rules

III
~Rewrite
III
Rules and Tables
Rewrite Combinations
Rewrite Rules and Tables

Q~writp
R1I1pc::.
Chapter 7 -7
(
(
(
Rewrite Tables
Rewrite rules and tables
Rewrite rule: Mapping between forwarding class and PLP to
CoS value for a particular protocol
Set of rewrite rules forms a rewrite table
.. Can configure multiple rewrite tables per protocol
Same forwarding class and PLP can map to different CoS values
Apply per interface
Syntax
,[edit-- qla5s-,of-s~rv i~e]
rewrite .... rules {

(dscp f dscp-ipvQ f expf
ieee~802.1
f ,ieee802.1ad I inet,.precedence) .rewrite-name
import ,(rewrite-nilme I default);

forwa)::ding-clas5, ,class-name {
~oss-priority leve'l code-point (alias I bitsL'

A rewrite rule is a mapping that links a forwarding class and PLP to a set of CoS bits for a particular
protocol. A set of rewrite rules forms a rewrite table. Each rewrite rule reads the current forwarding
class and loss priority information associated with the packet, locates the chosen CoS value from a
table, and writes this CoS value into the packet header. You can configure more than one rewrite
table for a protocol, mapping forwarding class and PLP combinations to different CoS values .
Chapter 7 -8 Rewrite RIlIA~
(
(
(
(
(
Default Rewrite Tables

.. Default rewrite tables
Several eXist; most are not used by default
Must be explicitly enabled on a logical interface
Exception: MPLS-enabled interfaces use default MPLS EXP

rewrite ru Ie
'!l.s~r@Rl>
show t;:las$-of-serVice interface ge-2/0/1
""o(,~o:a~ interface:
Index: 10
Type
exp (mpls-anyi
Classifier
Index
. '33
exp
10
ip
lB.
r-----------------~
Default rewrite [ule (Wllell MPLS
user@Rl> show class -'of-service
code pdirit -:-~,...,..--"'"":-:1ls enabled on tbe lih,tArfA"'';)
enabled interfaces, packet header

Y"'WrIT"'. is disabled. by defal,llt,
Default Rewrite Tables
The Junos OS provides several default rewrite tables, for all the protocols listed earlier in this chapter,
but in general they are not applied to interfaces (that is, rewrite rules are generally disabled). One
exception exists, though: MPLS-enabled interfaces implicitly use the default EXP rewrite rule.
The dscp-defaul t rewrite table is the following:
Rewrite rule: dsep-default, Code point type: dsep, Index:

Forwarding class
Loss priority
best-effort
low
best-effort
high
low
high
assured-forwarding
low
assured-forwarding
high
network-control
low
high
network-control
31
Code point
000000
000000
101110
101110
001010
001100
110000
111000.
Oo.lAIritQ Rlllp~
Chapter 7-9
Default Rewrite Rule Mappings
(
(
Default rewrite rule mappings

Based on default bit definitions of DSCP. DSCP IPv6. EXP.
IEEE. and IP CoS
The Junos OS detects packets matching the forwarding class
and PLP values; maps header bits of predefined code-point
aliases
expedited-forwarding 10111
ihg
G
~
~
qj
~
~
ef
ef
low
afll
assured-forwarding
High
af12 (DSCP!DSCP IPv6jEXP)
best-effort
low
be
@
~
~
~
netlllork-control
Default Rewrite Rule Mappings

In default rewrite tables. the mappings from forwarding class and PlP to CoS values is based on the
default bit definitions of DSCP. DSCP IPv6. EXP. IEEE. and IP CoS values. When the Junos OS detects
packets for which the CoS profile matches the forwarding class and PlP values listed in the first two
columns in the table on the slide. it maps the header bits of those packets to the code-point aliases
shown in the table.
..
e"
ct
eO;
Chapter 7 -10 Rewrite Rul~~
CD
CD
CD
CD
CD
o
o
e
Configuring Rewrite Rules Default RAV!l/li"I1';A

Tables
Perform packet header rewrite under the classof-service stanza
1. Apply the rewrite table to an interface (within class-ofservice stanza)
[edit]
user@Rl# show class-of-service interfaces
ge-O/O/O {
unit 0 {
rewlCite-rules {
dscp default;
eJ{p default;
ieee-802.1 default;
}
}
}
Apply rewrite tables with the

rewri te-rules statement.
Packet Header Rewrite Using Default Rewrite Tables

To use a default rewrite table, simply apply itto an interface within the class-of-service
stanza. In the example on the slide, several rewrite rules are applied to the ge-O/O/O.O interface. As
packets arrive at the interface for transmission, the system applies the related default rewrite rUle
based on the packet's protocol.
O ....."' .. i+.o 0 .. 10e-
..
Chanter 7 -11
,,
ng Rewrite
Tables (1 of 2)
Rules~;uil:l~'II'.n.m
Perform packet header rewrite under the classof-service stanza

1. Define a custom rewrite table
2. Apply the rewrite table to an interface
Definethe
custom rewritetable
(edit class-of-serviceJ
llser@Rl# show rewrite-rules
dscp custom-ipv4-rewrite-table {
forwarding-class BestEffort {
loss-p~iocity high code-points 000000;
loss-p~io~ity low code-points 000001,
Apply to an interface
(within class-af-service stanza)
llser@Rl# show interfaces
ge-0/0/3 {
unit 0 {
rewri te- rules {
dscp custom-ipv4-rewr~te-table;
forwarding-class Priority-data {
loss-p~iocity high code-points 000010;
loss-priority low code-poin-ts 000011;
Apply rewrite tables with the

rewri te- rules statement.
Packet Header Rewrite Using Custom Rewrite Tables

If the default rewrite tables do not meet your needs, you can create custom tables under the
class-of-service rewrite-rules stanza. When the custom rewrite table is fully defined,
apply it to an interface, again under the class-of-service stanza.
In the example on the slide, a custom dscp rewrite table has several rewrite rules, with forwarding
classes and PlP values mapping to code paints. This configuration example essentially says the
following: When a packet belonging to, for example, the BestEffort forwarding class with high PlP
arrives at interface ge-0/0/3, assign the dscp code point 000000 before the packet leaves the
interface. The same process applies for packets with different forwarding classes and PlP values .
Chapter 7 -12 Rewrite RIlI~.
Junos Cl ass of Service
Rules Cus
import simplifies new rewrite table configuration
Imported rewrite table acts as a template
Can import default or custom rewrite tables
New entries overwrite corresponding imported values

[edit]
user@Rl# show class-of-service

rewrite-rules {
exp custom-exp-rewrite-table
- - - - I Default EXP rewrite rul~ has code

point 001 for high loss priority
forwarding-class best-effort {
import default;
11.
loss-priority bigbcode-points 000;
Cedi t]
I>
'user@Rl# run show class-of-service rewrite-rules name custom-exp-
I}
~
33
rewrite-table
Rewrite rU,le: custom-exp-rewrite-table f Code point. type: eXpt Index:
.
Fb rwa rding class

best-effort
priority
best-effort
.,
o
I)
I)
I)
fy)
o
e
Using import to Simplify Rewrite Table Configuration

When creating a custom rewrite table, it is common practice to reuse several of the same settings
that are found in the related default table of the same CoS type. Perhaps the default rewrite table
works almost entirely for your needs, and you need to change just two of the settings. In these
instances, you can use an existing rewrite table as a kind of template to simplify the configuration
process.
To configure a new rewrite table that reuses settings from an existing table, use the i:mport
statement under the class-of-service rewrite-rules stanza and specify a default or
custom rewrite table to use as a template. Next, define custom entries to create your specific
requirements. The result is a merging of the template with the custom entries, with the new entries
overriding the corresponding values in the underlying template.
In the example on the slide, a custom rewrite table uses the default EXP rewrite table as a template.
(expdefault has the code point set to 001 for high PLP.) In addition, a custom entry specifies that for
best effort traffic with high PLP, the code point is 000. The resulting custom rewrite table reuses
many ofthe default EXP rewrite table's settings, and the explicit configutation statement overrides
the default code point setting for the best-effort forwarding class with high PLP.
~.
t:
[t!f:}
n ........;+'" 0, ,1o",
..
Chanter 7 -13
(
(
(
(
(
(
Where to Use Packet Header Rewrite

Generally within a network
Push CoS values into network; create trusted markings
Other devices can leverage traffic's existing CoS values
~raffiCflOW
Apply rewrite on PE
CoS Domain
interfaces into CoS domain
Apply Packet Header Rewrite Within a Network

In general, the best place to use rewrite tables is within a network. Because traffic has already
passed through your edge network device, you can push CoS markings onto packets and consider
them trusted. Furthermore, other nodes in the network can leverage the traffic's eXisting CoS values
and use the more efficient BA classification method at ingress to minimize the CoS processing
workload.
Chapter 7 -14 Rewrit.. RillA"
C
C
~
t1
~
~

1. Define rewrite rules
Led;i.t cla~s-of-servicel
rewr;i.tEj.,-rules {
dsC;p voice {
import default;
forwarding-class bes.t-effort {
loss~priority low c;ode-point 000000;
loss-pr;l.Qr;i.ty high code-pqintpOPOOi;
}
}
[editclass-ofservice 1
inter fa cesJ
fe-if 010 {
unit 0 {
.rewrite-rules {
}
}
}
fe-Q10/2 {
unit d {
,i::e1llrite-rille s {
ds!=p "oice;
.Default DSCP rewrite rule has code

pointOdbOOo forhigh loss priority
}
}
;2, Apply them to iote(faces facing

the CoS domain in~ess
PEl Configuration Example

The command output on the slide shows the relevant configuration components for the PEl device
in the diagram on the previous page. In step 1, a custom rewrite table uses the dscp default rewrite
table as a template, along with two customized settings. In step 2, the fe-ljOjO and feOjOj2
interfaces perform packet header rewrite using the custom rewrite table .
DOUlrito. Rilla.~
..
Chaoter7-15
(
(
(
(

III
!iii
G
(
C
41
~ Rewrite Combinations
~
~
~
<!
@
~
~
(i)
Rewrite Combinations
"
CD
(I
Chapter 7 -16 Rewrite Rules
Rewrite Combinations (1 of 2)
Rewrite rules based on protocol
Table apPlied to packetis determined ba$ed on protocol
E~ample:
MPLS packet gets EXP rewrite table
Packets have multiple protocols

Can rewrite one CoS value
Example: IPv4 packet over Ethernet usingVLANs; can set DSCP or
IEE:ES02.ip
Ca.n r~write both CoS values

Example: IPv4 Packet over MPLS; can set DSCP and EXP
simultaneollsly
Rewrite Rules Based on Protocol

The type of rewrite table applied to a packet is determined by the protocol of the outgoing packet. Of
course, the related rewrite table must be configured on the interface as well.
Packets Have Multiple Protocols

Every packet is associated with more than one protocol. For example, an IP packet on a virtual LAN
(VLAN)-based Ethernet network uses two protocols, which means two options for CoS treatment. The
Junos OS generally allows you to configure one CoS value, or both.
o,...u, ..;+o PI doc.
Chaoter 7 -17
Rewrite Combinations (2 of 2)
Options:
O;"";~g . rVLAN~ ~~?.1~ """,,,,,';(Re)W;l1able .. . .
Packet's
Pro~ls~
;
~
tagged
..
~~~?
NatlvelP
NativelP
IPin MPLS
IPinMPLS
CCCfICC
VPlS
.t
.t
.t
.t
~~~-~IP~~~"-
.. J .
IP DSCP
J P~ecedence J
IEEE 802 lp
.t
../
../
.t
.t
.t
.../
V
../
,,/
,,/
.../
Example: Rewriting EXP, IP precedence and 802,1p

[edi~t (::las~,.:...:qf-s;ervice interfp.ce~:;J
Rewrite both IP precedence and

MP.LS EXPto the same value
ge-'D/O/O {
unit 0 [
rewci te-_~ules '{
'exp ,~exp-ip~4- rewrite-p'olicyl protocol mp

ieee-8~02 ~l ,~eee~l?-pol)_cyl
t-both;
vlan-"t:ag puter-'and:-inner;
Apply IEEE 802.1prewrite ru.leto

both outer and innerVLAN tags
Rewrite Combination Options

The table on the slide shows several combinations of marking options based on the packet's
protocol(s).
Example
The example on the slide shows a rewrite rule that performs several tasks at once. The EXP entry
detects MPLS packets with IPv4 headers inside, and uses the related rewrite table's values to set
both the MPLS EXP bits and the IPv4 IP precedence bits. The IEEEB02.1 entry detects VLANtagged
Ethernet packets, and uses the related rewrite table's values to set the CoS values in both the inner
and outer VLAN tags.
Chapter 7 -18 RewritA Rlilj;l.c:.
t
~
~
~
~
~
@
(I
'1i
<
9,
Usage Notes for Rewrite Rules and

Combinations
Guidelines:
Can generally configure multiple rewrite rules for a logical
interface, but ...
Capabilities vary by platform
Highly hardware-dependent
Based on PIC, FPC, platform capabilities
Supported configurations and combinations vary per platform
Some platforms have specific caveats
Check Junos Class ofService Configuration Guide for

detailed information
Guidelines When Applying Rewrite Rules and Combinations

In general, you can configure multiple rewrite rules on a logical interface. However, many variations
and restrictions exist for what is supported on a given platform. Often the hardware installed in a
chassis is also a factor. For detailed information on supported rewrite combinations for a given
platform, refer to the Junos Class of Service Configuration Guide.
O"""'I';to t:)lllce:
...
Chaoter 7 -19
'.
(
(
(
(
Summary
C
C
C

Identified the purpose of rewriting packet headers
Defined rewrite rules and tables
Configured and applied default and custom rewrite rules
~
~
Listed. supported rewrite combinations
i
Cil!
C
(I
e
~.'::)
~
(lID
The purpose of rewriting packet headers;
Defining rewrite rules and tables;
<riD
Configuring and applying default and custom rewrite rules; and

Supported rewrite combinations.
<I
Chapter 7 -20 Rewrite Rul,,,
:J
S)
C)
@
A
t'0.:;1
I@
'\JJJ
ee
C:>
~
~
Review Questions
1. Rewrite rules apply CoS values to packets based on
which two packet attributes?
2. Which rewrite tables does a Junos device use by

default?
3. Which feature can you use to simplify rewrite table
configuration?
4. True or false: To apply a rewrite table to an interface,
use therewri te--tablecommand.
5. When a packet uses multiple protocols, can you set

just one protocol's CoS value? Can you set more
than one protocol's CoS value at the same tim<e?
8)
I)
Review Questions
1.
2.
3.
4.
5.
II
o",\w. it.a
Qlllp.:::
..
Chapter 7 -21

Configure rewrite rules.
Apply rewrite rules
G:
~
(;
~
~
III

.,
.,.,
.,.
(I
"
~l
Chapter 7 -22 Rewrite
RIlIAR

Chapter 8: CoS-Based Forwarding
E)
6)
(I
Chapter Objectives
able to:
Identify the purpose of CBF
Configure CBF

The purpose of class-of-service-based forwarding (CBF); and
Configuring CBF.
Chapter 8-2 COS-B8SP.O FnrwMrlin~
A. '.I
o
CD
G)
CD
CD
CD
i>
.,
o
Agenda: CoS-Based Forwarding

~GBF Overview
CBF Configuration
o
e
CBF Overview
The slide lists the topics we discuss in this chapter. We discuss the highlighted topic first.
I)
""""Co
o ...... "'~ Cnn.,'O..-rlinn'
Chanter 8-~
CoS Processing-CBF
Ingress
Egress
CoS Processing-CBF
Forwarding policy is a tool that allows you to control and affect the path traffic takes through the
network. COS can be integrated with policy by allowing you to select forwarding paths based on a
packet's forwarding class.
Chapter 8-4 COS-Based ForwHrrlin~
Q.......
@
Q
Q
CBF Overview
Q
oQ.........
Role of CBF
1""\
..
\iiJ
Enables routing path selection based on forwarding class

Supports IPv4, lPv6, MPLS
i.PM@M
e
e
RoleofCBF
CBF provides the ability to select a packet's routing path based on its forwarding class. For example,
you might want to specify a particular path to carry high priority traffic, while best-effo rt traffic takes
a less preferred path.
CBF is available for IPv4, IPv6 and MPLS packets.
(I)
(I)
(I)
(I)
(I)
(I)
I)
'.
(
C
C
Agenda: CoS..8ased Forwarding
(
(
(...
CBF Overview
-.?CBF Configuration
C
"":.'
CBF Configuration
Chapter 8-6
COS-R;:a~M I=nrv.l::lrriind'
CBF Configuration
i. Configure routing policy
Identify routes to use CBF
2. Configure CoSforwarding policy

Specify next hops per forwarding class
3, Apply the routing policy

Apply to forwarding tabie
j.72.16.1.1-
CBf,enab[ed router
CBF Configuration Overview

The slide lists the steps to configure CBF. These steps are expanded on the following slides .
"(
(
(
(
(
CBF Configuration Example (1 of 3)
1. Configure routing policy
Identify routes to use CBF
Send to CoS forwarding policy
C
(il
A{l
Cedi tJ
user@R1#, .show policy-options
polic.y-statementsample-c.bf-p,olic.y {
from {
rot.tte-filtelC 172.16 .. 1.0/24 exact;
~
~
o
o
the.n c.os-n.;.xt-hop-map sample-'cbf-map;

}
..
~
CBF Configuration - Configure Routing Policy

The first configuration step involves identifying the traffic that should use CBE Using routing policy.
define the desired routes within route filters. The resulting action for the policy must include the
cos-next-hop-map statement along with the name ofthe next-hop map.
eo
o
o
o
~
~
0,
o
Q
Q
CJ
Q
Q
~
I)
CBIF Configuration Example (2 of 3)

2, Configure CoS forwarding policy
Specify next hops per forwarding class
Use a next-hop map
Define multiple next-hops
[ed'Lt class-of-servicel
....t_o_e_n_a_b_le_10_a,..d_,s_h_8_t_in_g_-_-'I Use (or mix) IPv4 and.
,user@R1/f 'show .forwarding-policy
next- hop-map sample.,cibf-map {
MPLS nextchops
forward:lng<-class BestEffbrt {
next-haR 192,168 _1. 1;
__, r
}
@
~
@
forwarding-clasS! ExFbrwarciing. { ~""'"

next-hop 10.0.'0.1;
___
Isp..,next-hop 101.;
}
172,16,1,1
CBF-enabled router
I)
*
(I
**
**
I)
I)
tl)
CBF Configuration - Configure CoS Forwarding Policy

The next configuration step involves specifying the next hops for each forwarding class_ Create a
next-hop map that specifies one or more next-hops for each forwarding class_ You can optionally
specify more than one next-hop for a forwarding class, creating load balancing across the multiple
paths, You can also mix IP next-hops with MPLS next-hops under a single forwarding class_
CBF Configuration Example (3 of 3)

3. Apply the routing policy
Apply to forwarding table
Cedi t !:Outing-options]
user@Rlii show
forwarding-table {
eKpor-t sa,mple-cbf -policy;
~
~
~
~
@
[I-_C...;B_Fe_,
_n_a_b...;led,-'...;'r_o_ute_''_I'....J._ _)
CBF Configuration - Apply Routing Policy

Much like firewall filters, routing policy on its own does nothing, until you apply it. The final
configuration step involves applying the routing policy to routes exported to the forwarding table.
Chapter 8-10
Cos;,-R::I~j:Iorl I=nnAI~rrlinrt
2)
o
o
o
CBf Usage Notes

..
CBF with OSPF
Must configure nexthop as interface name
..
IP and LSP next-hops
Accommodates point-io-point interfaces
Can configure both for a forwarding class

LSP next-hops are preferred
Incomplete next-hop map

Defa.uIt class ne><t-hop used for forWardingcli3sses hot
specified in next-hop map
Defaultclass = forwarding clasS maPj)ed to qUeue 0

o.
0 efa LI It class'" rahd6mlyselected if QO-pased class flot present
CBF with OSPF

When you configure CBF within a network that uses OSPF as the interior gateway protocol (IGP), you
must specify the next-hop as an interface name (or next-hop alias), not as an IP address. The reason
for this is OSPF adds routes with the interface as the next hop for pOint-to-point interfaces; the next
hop does not contain the IP address.
IP and LSP Next-Hops

When a forwarding class is identified within a next-hop map and configured with both LSP next hops
and IP next hops, the LSP next hops are preferred.
Incomplete Next-Hop Map

If a next-hop map does not specify ali possible forwarding classes, the Junos OS assigns traffic for
the unspecified forwarding classes to a default forwarding class. The default forwarding class is the
class associated with queue O. If the default forwarding class is not specified in the next-hop map,
Junos randomly designates the default class.
,....~C' 0 ........... .4 C"....HI'!:Irriin(S
...
Chaoter 8-11
Summary
In thi.s chapter, we:
Identified the purpose of class~based forwarding (CBF)
Configured CBF
!l
<ID
~
~
III
The purpose of CBF; and
Configuring CBF.
..
..
Crt
Crt
(II
Chapter 8-12 CoS-Bn!=>p.rl
Fnrw:::lrrlincr
Review Questions
1. Which protocols are supported by CBF?
2. How do you identify which traffic should use CBF?
3. What does using OSPF change about how you
configure CBF?
4. When a forwarding class has both IP and MPLS nexthops, which is preferred?
..
.."
Review Questions
1.
2.
3.
4.
(j
(1)
(1)
'(1)
'(1)
kifn
. . . -......... _--..1 r::.........., ..
rlinrt
Chapter 8-13
(

Configure and test CBF.

Chapter 8-14 COS-BnFiP.r:I
F'nml~rrHnrf

Chapter 9: Case Study
(
(
(
(
Chapter Objectives
.. After successfully completing this chapter, you will be
able to:
Determine a CoS network design strategy based on given
requirements
Configure CoS on ingress, transit, and egress nodes to meet
case study requirements
A class-of-service (CoS) network design strategy based on given requirements; and

The configuration of CoS on ingress, transit, and egress nodes to meet case study
requirements.
Chapter 9-2 Case Stllrlv
(
(
C
C
~
(Ill
Agenda: Case study

~VoIP
Case Study Overview
VolP Case Study: Ingress Node

VolP Case Study: Transit and Egress Nodes
..
VolP Case Study Overview

I)
I>
I>
..
t3
r.:::IC:P
~tllrlV
Chapter 9-3
(
(
(
(
VolP Case Study Topology

Service Provider
Amsterdam
(
(
C
C
Handset
PABX
Denver
Data
PABX:private automatic
branch I>Yf"h""
CoS configured in this.direction only!

General Notes:
Goal: roanalyze typical Juhos CoS configurationsforedge.ahd core routers
in thecontextofaVolPapplication
Configl.lration is unidirectional(frOril subscriber to PABX)
Simplifies and reduces the site of config;urationexamples
. ProVides ohe'way CoS~similar set ofconfig;urati.On statements
needed to prbv,ide CoSinthel'eturn direction
VolP Case Study Topology
The slide shows the topology that serves as the basis for the CoS configuration case study. The
overall goal is to analyze typical Junos COS configurations for edge and core routers in the context of
a VolP application.
This case study is based on a unidirectional CoS deployment. In other words, the configurations
shown focus exclusively on moving voice and data traffic from the subscribers on the left to the
server and voice switch (PABX) on the right. While CoS does not mandate symmetric treatment of
data flows, it is rare for only one half of a CoS solution to be deployed in a production network.
The unidirectional approach taken here has the goal of keeping the configuration as simple (and
short) as possible while still providing concrete examples of functional CoS configuration.
Chapter 9-4 Case -Studv
~
~
~
e
~
~
G)
,.
Agenda: Case Study

III
-7VoIP Case Study: Ingress Node

!!II

The slide highlights the topic we discuss next
, .,
\
,~
r~c::p. _~tllrlV
Chapter 9-5
VollP Case study Criteria: Ingress......1 of 2

Use CoS to support VoIP~ conventional Internet, and
control traffic received from a customer
Classification and policing:
~
~
VolPSIP signc;lling usesTCP/UDP port 5060

RTP media channels use UDP withports in the range of 16,000016,500
Classifyall VolP traffic as expedited forwarding
Classify IP precedence 6 or 7 as
ne~work cOntrol
Classifyall remaining IP precedence a traffic 9s best effort

Police BE traffic to 1 Mpps with a 3000-byte burst: mar,kexcess
traffic as high loss priority
Ingress Node Criteria: Part 1

The slide outlines the application specifics and guidelines for the ingress node. The case study
differentiates ingress node processing from transit and egress node processing to emphasize the
different roles typically played by these types of devices. General items to note include the foJlowing:
Classification and poliCing: The Ingress node must use multifield classification to
correctly identify voice over IP (VoIP)-related traffic. The slide lists the protocol and port
information needed to create a multifield classifier. The ingress node must classify
non-VolP traffic with IP precedence 0 as best effort (BE), and it must police BE traffic
with excess data marked with a high loss priority. Ingress classification must also
correctly recognize IP precedence 6 and 7 traffic as network control. Note that you
normally configure a policer's burst size to the larger of eitherten times the medium's
MTU, or to 3-5 milliseconds worth of line rate traffic. In this example, we deploy the
small burst size parameter of 3000 bytes to help demonstrate correct policer operation .
G
<I
~
.,.,
.,.,
~ 1
Chapter 9-6 Cas!'! St"rlu
Ju nos CI ;ass of Service
VolP Case Study Criteria: Ingress 2 of:2

VelP case study (centd.)
Scheduling and congestion control
ScheduleVolP traffic as high priority with at least 20 Mbps of
capacity: limit maximum delay to 200 milliseconds
Schedule BE traTflc with low priority and limit t01 Mbps
COhfigureweighted random early detection (WRED)for the BE
classso that a greater percentage ofhigh loss priority traffic. is
discarded: onlyTCP traffic is SU bjected to WRED
Packet header rewrite

Rewfitethe DSCP marKertoaccommodateBA classification:
ensurethatlosspriority for the EF forwardingclassiscoupled
betWeeh.chassi5\
. .
Ingress Node Criteria: Part 2

The following list is a continuation from the previous page:
Scheduling and congestion control: After classification and policing, you must configure
the ingress node with schedulers for ali supported forwarding classes. In the case of the
BE class, you must configure RED profiles that factor loss priority into discard decisions,
so that BE traffic in excess of the configured policer is more likely to be discarded
during periods of congestion. Note that you must ensure that the BE class cannot
exceed a 1-Mbps transmission rate.
Packet header rewrite: You must configure the ingress node with a DiffServ code point
(DSCP)-based rewrite table that marks traffic with CoS values so that downstream
nodes can use the more efficient behavior aggregate (BA) classification 1:0 classify
inbound traffic. In addition, you must ensure that your rewrite configurati on permits the
distinction of low and high loss priority for the BE class in downstream nodes .
('-=>CQ.
~blrhl
Chapter 9-7
(
(
Ingress Node Classification and Policing
(
(
(
Ingress
Ei
~.11
~gress
~
(I
<I
Ingress Node Classification and Policing

The CoS functional block diagram on the slide shows the CoS processing functionality configured
first. In this case, the diagram shows that multifield classification and policing will be added to the
ingress node. The result of this functionality will identify a packet's forwarding class and loss priority.
..
.,
.,
Chapter 9-8 Case Studv
Ingress Node Multifield Classifier
.,
e
e
e
.,I>
.,
~
I)
(I
(I
I)
I)
I)
I)
(I
Ie
[edit firewall tarpily inet filtermt-classify]

user@san_Josell show
term.1 {
trom {
protocol [udp .tcp ];
port 5060;
Traffic associated with Vo IP is

classified as EF ahd aco~pted
thl3ri forwarding-class expedited-forwarding;

}
term 2 {
tIC'om, {
protocol Udp;
port 16000-1650Q;
}
then forWardirig-class expedited-,forwarding;.

}
~.
teqn
from {
preceoence routine';
}
Precedence 0 traffic is directed to

pol[c;l;lrand c;lassified~.s BE
tji<;ln {
p,?licer: p,?lice-J;le;
torwa:rding-clas~ best-effort;
}
}
texm 4 {
'tlle ri accep.t;
NetworK .control is accepted and classified
byipprec-compabibUi ty
Ingress Node Multifield Classifier

The slide displays a Junos OS firewall filter that correctly classifies traffic received from the customer
site. Terms 1 and 2 classify VolP-related signaling and media as EF in accordance with the case
study criteria. Term 3 matches non-VolP traffic with an IP precedence value of 0 (also known as
routine) and sends it to a policer named police-be and for classification as BE. The final term
simply accepts all remaining traffic, which accommodates the need to classify traffic "-'lith
precedence values of 6 or 7 as network control by virtue of not overwriting the actions of the default
IP precedence classifier that is in effect by default.
('QCQ C:t1lrill
ChaDter 9-9
["
\:.,
Ingress Policer and Filter Application

.. Policer marks excess data as high loss priority
[ecjit firewall]
user@san Jose# Sh9W policer
if-exceeding {
bandwidth-limit 1m;
po~ice-be
C
C
C
G
C
~
t1
then loss-priodty high;
t1
.. mf-classify filter applied inbound on
customer-facing interface
i
i
["dit]
llsEi'r@San Jose# show interfaces fe-O/O/O
utiit O{
family inet {
filter {
input mf-classify;
~
~
adcjress 10.222;29.2/24.
GJ
~
~
Policer Configuration
The top of the slide shows the police-be policer configuration. Traffic in-profile is handed back to
the filter term, where it is classified as BE. Traffic in excess of the policer profile is marked with a high
loss priority and is handed back to the filter term, where it is also classified as BE.
Firewall Filter Application

The mf-classify firewall filter comes into effect when it is applied to the customer-facing
interface. Note that the filter is applied in the input direction so as to correctly classify traffic
received from the customer router as it enters the service provider's network.
fI
(I
(I
fI
(I
A
W
8>
o
o
@
@
@
Ingress Node Scheduling and WRED
Ingress
f.)
f.)
Egress
(ID
(ID
.,
Ingress Node Scheduling and WRED

The CoS functional block diagram on the slide reflects the CoS processing functionality configured
next. The diagram shows that the next item on the configuration check list is ingress node
scheduling and weighted random early detection (WRED). Note that schedulers are defined for each
forwarding class and that WRED can be configured to act on a packet's loss priority.
I)
C)
,-.. .... " .... Cto .rllI
..
Chaoter 9-11
"
Configuring Schedulers
Define a scheduler for all forwarding classes that are
in effect
user@San_Josell show schedulers
be-scheduler {
transmit-rate 1m' e~act;
priority low;
di:op-pi:ofile'-map loss-priority low protocol tep drope-profile low- ted;
drop~prOfile_IiJap loss-priority high protocol tcp drop~prclfile high-red;
}
ef-schedUler {
tr;,nsmit'_rate 2:QIiJ;
buffe~r,",size tempora:!. 200000;
ptiority high;
. . _ - - - - - l l n this case study. buffer depth is

set for the EF class on Iy; delay is
mea$!-Ired in microsecond~
nc-scheduler {
transmit'-rpte petcent 5;
'priority lOw;
You should always con figtJ re a network control schduler

to ensure thatcontrol
not starveq.
Schedulers are a critical component of CoS on Junos platforms, Schedulers control the transmission
weight for a given forwarding class (or queue), the queue's priority, buffer depth, and the set of
WRED profiles that are applied when congestion occurs.
You should define a scheduler for each of the forwarding classes (or queues) on the router. By
applying these schedulers to all possible egress interfaces, you ensure that traffic is always treated
to the expected service level, regardless of which interface traffic happens to egress.
Forgetting to create and assign a scheduler for NCtraffic is a common mistake with potentially
disastrous consequences. The default scheduler provides 5% of the bandwidth to the NC queue
(queue 3). We recommend that you make a similar provision for NC traffic when deploying an explicit
CoS configuration to ensure that NC traffic is not starved for bandwidth. We further recommend that
you set the priority of the NC scheduler to high whenever a strict-high scheduler is also in etrect.
In the example on the slide, the BE scheduler is correctly configured with low priority (the default)
and a 1-Mbps limit that prevent the BE class from using any additional bandwidth,'even when other
classes are idle. The BE class scheduler references two WRED profiles (shown on the next page) and
correctly uses the tcp flag to enable these profiles for TCP traffic only. The NC class is not set to a
high priority because there are no strict-high schedulers defined in this example. As a final note, the
queue depth is set for the EF class only using a temporal value. By default, the BE and NC classes
will have elastic buffer depths that make use of the remaining queuing space. In this example, the
temporal depth is set to 200,000 microseconds, which supports the case study criteria specifying a
per-hop maximum delay of 200 milliseconds.
Chapter 9-12
C.<=l<:::.:l C::tlln\l
C)
CD
Defining WRED Drop Profiles
Two drop profiles are required for the BE class in this

example:
The low- r~d profile affects rcp traffic with low loss priority
10% drop probability at 80% queue fill
The high -red profile affects TCPtraffic with hrgh loss priority
iO% drop probability at 50% queue fill
Drop profiles9re referenced within a scheduler stanza

(previous P9ge)
[edit c;Lass-of-service]
user@san-,Joseif show. drop~profiles
low-red {
fill~level 80 drop-probability 10;
high-red {
fill-level 50 drop-pr-obabil.ity 10;
}
WRED Drop Profiles

The case study criteria require the configuration WRED for the BE class such that a greater
percentage of discards occur for traffic marked with high loss priority. The configuratio n examples on
the slide meet these criteria by defining two WRED profiles with different drop probab i1ity-tofililevel
mappings. In this case, Tep traffic with low loss priority is mapped to the low-red profile (this
mapping is part of the scheduler configuration shown on the previous page) with a :LO% drop
probability at an 80% queue fullness. The high-red profile, on the other hand, has the same 10%
drop probability, but this profile begins dropping packets at a 50% fullness level, whic h leads to a
greater percentage of packet drops when compared to the low-red profile.
Although it is not shown in this example, you could specify the interpolated option when defining the
RED profiles.
(,,,,,,,,a
c.t. tn" ..
Chanter 9-13
l.ink Schedulers to Classes and Interfaces

Define a scheduler map to link forwarding classes to
schedulers
[edit class-af-service]
user@san_Josell show scheduler-maps
voip-cas~ {
forwarding-class best-effort schedUler be-scheduLer;
farwardiQg'-class expedited-forwarding scheduler ef-,schedule r;
fotwa'rding-class network-control scheduler nc-scheduler;
}
Place schedulers into effect on egress interfaces by

linking them toa scheduler map
tec;lit Class-af-service]
user@san.-:Josell show interfaces
fec-O/O/l{
s,chec;luler-map vpip-case,;
}
Link Schedulers to Classes

Use a scheduler map to logically group one or more schedulers together. This grouping makes it easy
to later apply a set of schedulers to one or more egress interfaces. In the example on the sl ide, the
scheduler names reflect the forwarding class to which they are ultimately applied (through the
scheduler map), but this naming is only a convenience; you can map any defined scheduler to any
defined forwarding class with a scheduler map.
Apply Scheduler Maps to Egress Interfaces

Once you have logically bound a set of schedulers to forwarding classes with a scheduler map, you
can put the schedulers into effect for a given interface's egress queues by referencing the scheduler
map by name atthe [edit class-of-service interfaces] hierarchy level. Note that the
scheduler map is applied at the port level, which means the same scheduler map is in effect for all
logical interfaces that might be defined on that port. In this example, the voip-case
scheduler-map is used to provide CoS for all logical units (that is, VLANs) that might be defined on
the fe-O/O/1 interface.
Note that you could apply the same scheduler map to a set of interfaces using a wild-card
expression, such as 50-*.
(
(
(
(
(
(
C
(
j
~
I;l\J
Ingress Node Rewrite Table
Ingress
Ingress Node Packet Header Rewrite

The CoS functional block diagram on the slide indicates the next CoS processing functionality to be
configured. In this case, the diagram shows that rewrite marker functionality is next on the
configuration check list
(''''''''0 t:hlrh,
Chaoter 9-15
Configuring DSCP Rewrite Table

Default DSCP rewrite table does not communicate
loss priority for BE traffic
The voip-dscp-rewrite table imports default settillgs
and defines a code point for BE traffic with high loss priority:
[edit C!lass-ofservice rewrite-rules dscp voip-dsC!p-rewrite J
use r@Qan_J.6sell Sho~W~_ _ _ _ _ _ _'_ _ ___~;;;;::::;::7:=:-:::;-;:;::T.;:-::;::::;;-=:-1
import dE! fault I 4
Prepopulates new table with values
forwEl!Cding~clEls s best-effort {
from the default DSCP rewrite table
losS'~pdority high code-point 000001;
}
Thev-oip-dscp-rewri te tab.le is linked to the egress

interface at the ingress node:
[edit. clas$-of~serviceJ
usei@sEln'-.Jasell show interfaces fe-O/O/l
.schedule i:'-litap vOip- ca se;
U\1it O{
r:ewri te-rules {
d s Opyoip-ds cp-rewii'te;
Defining a Custom DSCP Rewrite Table

A custom DSCP rewrite table is necessary because the default DSCP rewrite table assigns the same
code point to all traffic belonging to the BE class, regardless of its loss-priority status. You must
define a rewrite table that assigns distinct values based upon the traffic's loss priority to ensure that
transit and egress nodes, which will use DSCP-based BA classification, correctly recognize the loss
priority of incoming BE traffic. This paint is critical, because the policing function used to determine
loss priority in this example is performed only at ingress. As a result, loss priority will not have
end-to-end significance if you fail to define a custom code point for EF traffic with a high loss priority.
In this example, the custom voip-dscp-rewri te table imports the default DSCP rewrite settings
through the import default statement. These delaults are then updated with a code-point value
of 000001 for traffic assigned to the BE class with a high loss priority.
With the custom rewrite table configured, apply it as a rewrite-rule at the [edit
class-of-service interfaces interface-name unit unit-number] hierarchy for
the desired interface.
You can also use a wildcard expression to apply a rewrite table to a group of interfaces using the
keyword all and an asterisk (*) for the unit number.
Chapter 9-16
Ca~A Stllrhl
Ingress CoS Configuration-Summary (1 of 2)

[edit clas~-of-'iel:Yicel
user@sanJoseil shOw
drop-profiles {
low~red {
hU-Iewl 80 dr()p-pr:obabi~ity 10;
}
higl}-red {
fiU-level 50 drop-probability
10;
,
}
interfaces {
fe-Oj 0/1 {
scheduler-map voip~9as~;
unit. a {
r:ewi:ite-r,uhls {
dscp voip-dscp~rewdte;
}
}
}
I):'ewr~t!2:-rl!les
. '
{
dscp ',(oip-dsqp-rewdtl'l {
import. de f<J,111t;
forwarding-class besi:~effOl:t {
lbs~~pr'iodty hit:jl) cOde-point 000001;
}
Ingress Node Cos Configuration Summary: Part 1

The slide shows part of the complete CoS-related configuration for the ingress node.
Note that this configuration reflects a unidirectional CoS design, as described in the case study
overview. In most cases, you would expect to also see a CoS configuration in place for traffic moving
in the opposite direction.
('~r::t:>. ~tnrh/.
ChaPter 9-17
Ingress CoS Configuration-5ummary (2 of 2)

scheduler--maps {
voip-case {
fot:warding-class best~effot:t schedule r be-scheduler-;
fon1arding-class expedited-forwarding scheduler ef-scheduler-;
for-warding-class network- control scheduler nc-scheduler;
}
}
scheduLers {
be-scheduler {
transmit-rate 1m exact;
priority Low;
drop-profile~map loss-priority low protocoL tcp drop-profile low-r:ed;
drop-profile-map loss,-priori,t:r high protocoL tcp drop-profile .high-red;
}
ef-schedule r {
transmit-rate 20m,
buffer-size temporal 2000'00;
priority high;
}
{
transmit-ra.te percent 5,
pri.ority low;
nc~schedlJler
Theing)"essnode's rnultifieldclassifierand
policerconfiguration are not shown here.
Ingress Node Cos Configuration Summary: Part 2

The slide completes the display of the ingress node's CoS-related configuration.
Note that the ingress node's multifield classification filter and related policer are not shown .
Agenda: Case Study

III
III
~VoIP Case Study: Transit and Egress Nodes

VolP Case
ria:
Transit and Egress (1 of 2)
Use CoS to support VolP, conventional Internet, and
control traffic received from an upstream node
SA classification
Configure DSCP-based BA classification compatible with ingress
node classification
Scheduling and congestion control

Schedule VolP traffic as high priority with at least 20 Mbps of
capacity
Schedule BE traffic with low priority, and limit this traffic to 1 M bps
Configure RED profiles for BE traffic that discriminate on loss
priority and TCP status flags
Transit and Egress Node Criteria: Part 1

The slide defines the configuration criteria for the transit and egress node that support the YolP CoS
case study requirements and guidelines, Key pOints include the following:
BA classification: Unlike the ingress node, which uses a multifield classifier, transit and
egress nodes must use a DSCPbased SA to classify traffic, By carefully matching an
upstream node's rewrite table to the downstream node's classification table, you
ensure consistent classification through the DiffServ domain.
Scheduling and congestion control: Any node that handles traffic must use a set of
schedulers to correctly service and weight the queues associated with each defined
forwarding class. Because constancy is key, transit and egress nodes should use the
same set of scheduler and WRED parameters as deployed in the ingress node .
Chapter 9-20 Case Swnv
VolP Case Study Criteria:

Transit and Egress (2 of 2)
VolP case study (contd.)
Packet header rewrite
Rewrite the DSCP marker to accommodateBA clasSification in
downstream nodes; ensLlre.thatioss priority for the EFforwarding
class is cOLipledbetween chassis
Transit and Egress Node Criteria: Part 2

The following list is a continuation from the previous page:
Packet header rewrite: Transit nodes need the same DSCP rewrite table that is in effect
at the ingress node to ensure that nodes further downstream make consistent
classification decisions. Note that in some environments. the egress node might use a
different rewrite table to prepare traffic for hand-off to a customer device or another
DiffServ domain. In this case study, such boundary conditioning is not required. While
the egress node could use a default rewrite table, in this case study, the egress node is
configured with the same rewrite table that is in effect at ingress and tra nsit nodes.
("~C:j:>. ~htrlv
..
Chapter 9-21
(
Transit and Egress Node SA Classification
(
(
(
(
(
C
C
~
Egress
Transit and Egress Node Classification

The CoS functional block diagram on the slide indicates the CoS processing functionality configured
first. This diagram shows that configuration of the transit and egress nodes starts with SA
classification. The goal is to achieve a consistent set of classification and loss priority recognition in
transit and egress nodes.
Configuring DSCP Classification Table

.. The voip-dscp~classify table defines code
points for BE traffic with high and low loss priority
.. The DSCP classifiers must match the DSCP rewrite values in
effect at the upstream node
[editclass-of-servi,ce classifier:; ctscp Y0ip-ctscp-classif,ierJ
use,:@DeIwer# show~ -------~------,,.fip;:;;;;;;Iat;;-;;;;;i;t;;;;:i1~~:;;;:_ll
impo,:t default; "
Prepopulates new table .\lith values
fotwa,:ding-cl"s s best-effort {
from the default DSCP classifier table
,lops-priority higlt code-points 000001;
}
el_.ink the voip-ciscp-class'ify table to the ingress

interface ,at transit and egress nodes:
Cedit cla5s-O:t~servicel
us!;,r@Denver!l shoW interfaces fe-O/O/l
unitQ,: {
classifiers {
d stp yoip-ds cp-clas sifie r ;
Defining a Custom DSCP Classification Table

, Recall that a custom DSCP rewrite table was placed into effect at the ingress node to accommodate
the distinction between BE traffic with low and high loss priorities. This configuration step defines a
DSCP classification table that is compatible with the code points set by the ingress node. The
approach here is to define a custom DSCP classifier that is prepopulated with the code points
associated with the default DSCP classifier table. A custom entry for BE traffic with high loss priority
is then added to the table. The voip-dscp-classifier table is placed into effect on ingress
interfaces by applying it as a classifier at the [edit class-of-service interfaces
interface-name unit unit-number] hierarchy.
(''!lea. C:tllrhl
".
Chapter 9-23
(
Trans a
andWRED
cnaoulers
C
(
(
G
(
Ingress
C
~
t
~
~
tf!lQ
Egress
<I
Transit and Egress Node Scheduling and WRED

The CoS functional block diagram on the slide reflects the COS processing functionality configured
next. The diagram indicates that transit and egress node schedulers and WRED are next on the
configuration checklist. Note that schedulers are defined for each forwarding class and that WRED
can be configured to act on a packet's loss priority.
In this case study. the ingress and transiVegress node scheduler and WRED configurations are
identical. The separation of ingress node configuration from that of a transit or egress node is
designed to reinforce the different roles normally associated with edge and core devices.
"
(I
(I
Chapter 9-24 Case Stllnv
Transit and egress nodes use the same scheduler
.configuration as the ingress node
CoS desi~s must ehsure consistent traffic
[edit' class~of-sE)rviceJ
handlingamongall nodes in the path.
user@Oenyerjf, show schedulers
be,-schedtller {
,transmit-rate 1m' exact;
prioritY-lOW;
drop_ptofile-map loss'-priodty low 'pb'ltocol tcpdrop-,prbfile low- red;
d'rop-profile~map loss-prioiityhigh ,protocoltdp ,drop-profile hiwh-red;
}
ef-schedu1er, {
t;ranJlmit~rate 20m;
buf,fer-size tempqrpl iOiJOOO;
pr:l.brityl;l;i.gh;
nec-sChedUler {
priority low;
Transit and Egress Node Schedulers

Transit and egress nodes use a set of scheduler definitions that match those in effect at the ingress
node. This setup is logical and confirms the need for consistent end-toend packet handling in a CoS
design. After all. what advantage could possibly be achieved by having some nodes in the
communications paths affording BE traffic to 30 Mbps of high-priority bandwidth while others
provide only 1 Mbps of low-priority servicing?
('';leo C:tllril,
Chapter 9-25
(
(
(
Defining WRED Drop Profiles

Tram:;it and egress nodes use the same drop profil es
configured at the ingress node
[adit cla:ss-of~servicel
user@DenVer# shoW' drop-prof iles
ldw-red{
flll-level 80 drop-prObability 10;
CdS desig)1s are contingenton

consistent and predictable traffic
handlingamongall nodes in the path.
high-red {
fill-level
~o
drop-probability 10;
Transit and Egress Node Drop Profiles

As was the case with schedulers, transit and egress nodes use the same set of WRED drop profiles
for the BE forwarding class to ensure consistent and predictable end-to-end performance .
Chapter 9-26 Cas .. StllriV
(
(
C
(
~
~
Link Schedulers to Classes and Interfaces

A scheduler map links forwarding classes to
schedulers and to egress interfaces
(I
(I
[edit class-at-service]
Liser@Denverll show schedul'er-l!Iaps
vo;Lp-~ase {
f,brwar:dihg-'class best-MfMt schedLiler: be-,stheduler;
forwarding-,class expedited-forwarding scheduler e,f:-scheduler;
fprwarding-class nltwo,rk,-control schedule,r [lc-scheduler;
}
[edit tlass,-of-serviceJ
show interfaces
fe-,a/,..Pll, {
unit 0 {
"classifiers {
dscp ll.oip-dScp-classif:i.er;
,usel:@DenVer~3#
}
}
so-'0/1/1 {
sdhedulet'~map voip..:case;
Link Schedulers and Apply to an ,Egress Interface

You must use a scheduler map to logically group the BE, EF, and NC schedulers so that they can be
applied on the egress interfaces of transit and egress nodes. The slide highlights how the
voip-case scheduler-map is correctly listed under the transit node's so-O/l/l egress
interface. Note that the fe-O/O/l interface, which functions as an ingress interface for the case
study, is correctly associated with a DSCP BA classifier. A scheduler map is needed to handle egress
traffic only.
r-......... " C+"M"
Chanter 9-27
I;,
l\\
/
Transit Node Marking
"
Ii'
'-
(
{.....
?
I\J
Ingress
C
.:,',
~
~"1
""i
C
@
-K?\
'~d
..
~
,,-}
"of}'
<1J})
't:v
Q
Q
Transit and Egress Packet Header Rewrite

The CoS functional block diagram on the slide reflects the CoS processing functionality configured
next. In this case, the diagram shows that packet header rewrite functionality is next on the
configuration check list.
In this case study, the ingress, transit, and egress node DSCP rewrite tables are identical. The
separation of ingress node configuration from that of a transit or egress node is designed to
reinforce the different roles performed by edge and core devices; however, many aspects of their
configurations are similar.
Note that a DSCP rewrita table is not strictly required on the transit and egress nodes in this
topology, because of their limited role in this case study topology. Also, the lack of an explicit (or
default) DSCP rewrite table results in the incoming DSCP being left unaltered as the packet transits
the router. Equippingtransit and egress routers with a consistent DSCP rewrite table certainly causes
no harm, and this approach is generally considered as a best practice because having the
appropriate rewrite tables in effect allows a node that formally acted as strictly tra'l.5it and egress to
begin accepting ingress traffic as well.
(I
.
0
0
:{>,'
.0
Chapter 9-28 CasE'! Sh 'rlv
Configuring Transit Node Marking

Transit nodes have the same DSCP rewrite table as
the ingress node
..
Applied to transit node's egress interface

[edit cla.ss'-of-setvice]
.user@DE\rlverll show rewrite-rules
dsqp v:olp~dscp~rew'dte {
import defa.ulb
forwarding- class be.st-effort {
ioss-priqdty high code-PQint :000001;
}
}
[edit
cla$$,-of~service]
Used~Denyerll show interface" so-O /1/1

.5 cMdUler:-rnap. vqip'- casla}
uhitO{
reWrlte.-rule$.{
dscpvoip-i::lscp-rewrite;
No egress condition ing is

required in this case study
,~
..
I)
I)
18
'
Transit and Egress Packet Header Rewrite

Transit nodes must rewrite the DSCP of egress traffic in the same manner as the ingress node so
that routers further downstream make consistent classification decisions for ingress traffic. The
slide shows a custom DSCP rewrite table named voip-dscp-rewri te that is appli ed to the
transit node's egress interface.
Egress Conditioning
In some applications, the egress node of a DiffServ domain is expected to condition traffic so that it
makes sense to the device that receives it. This requirement might involve resetting the DSCP or
precedence fields, or it could necessitate the mapping of DSCP/MPLS EXP values into a Layer 2
field, such as the IEEE 802.1p priority field. In the example on the slide, the egress node does not
technically require an explicit rewrite table configuration (recall that only the MPLS EX P rewrite table
is in effect by default) because no specific conditioning is required, and no traffic is destined to the
servers ingresses at the Montreal node. In this example, however, we assume that the egress node is
configured with a copy of the voip-dscp-rewrite table used for both)he ingress and egress
nodes.
f"'o .........
c+ ..,I"
r.h~ntpr
Q_?Q
Transit/Egress Node CoS

Configuralion-Summary (1 of 2)
user@Denver# show
classifiers {
dscp voip-dscp-classifier
import default;
forwarding-class best-effort
loss-priority high code-points
000001;
so-0/1/1
scheduler-map voip-case;
unit 0 {
rewrite-rules {
dscp voip-dscp-rewrite;
drop-profiles
low-red (
)
high-red {
interfaces {
fe-.0/0/1
unit 0 {
classifiers {
dscp voip-dscp-classifier;
Transit and Egress Node CoS Configuration Summary: Part 1

The slide shows the first part of a complete CoS-related configuration for the transit and egress
nodes.
Once again, note that this configuration reflects a unidirectional CoS design, as described in the
case study overview.
Chapter 9-30
C.A~t=I ~tllrlV
....J
:)
:)
o
o
CD
e
.,
I>
"
o
o
e
Configuration-5ummary (2 of 2)
rewrite-rules {
dscp voip-dscp-rewrite
import default;
forwarding-class best-effort {
loss-priority high code-point 000001;
scheduler-maps {
voip-case {
forwarding-class best-effort scheduler be-SCheduler;
forwarding-class expedited-forwarding scheduler ef-scheduler:
forwarding-class network-control SCheduler nc-scheduler;
(I
~
schedulers
be-scheduler (
transmit-rate 1m exact;
priority low;
drop-profile"-map loss-priority low protocol tcp drop-.profile low-red;
drop-profile-map loss-priority high protocol tcp drop-profile high-red;
)
~
@
ef-scheduler {
transmit-rate 20m;
buffer-size temp-oral 200;
priority high;
nc-scheduler {
priority low;
Transit and Egress Node CoS Configuration Summary: Part 2

The slide completes the CoS-related configuration for the transit and egress nodes .
tItf?I
wjJi1
VI:BI
,... ...... n
c+. ,n" ..
C':hFloter 9-31
Summary
Determined a CoS network design strategy based on given
requirements
Configured CoS on ingress, transit, and egress nodes to
meet case study requirements

A CoS network design strategy based on given requirements; and
The configuration of COS on ingress, transit, and egress nodes to meet case study
requirements.
Chapter 9-32 CaR.A S-tllrhl

Appendix A: CoS Processing on M Series, T Se ries,
and MX Series Devices
(
C
(
<2
Appendix Objectives
After successfully completing this appendix, you will
.be able to:
Identify the various components of M Series, T Series, and
MX Series architectures
Deqcribe CoS packet handling for each architecture
This Appendix Discusses:

The various components of M Series, T Series, and MX Series architectures; and
CoS packet handling for each architecture.
Appendix A-2 CoS
Pror.p.,!:;.~inP'
nn M ~&:lri,:::lC: T
C::.:>.ric,,:;~ ~"~
hl\V C ........l .......
r. ...... :---
C
C
'<:.:...
Agenda: CoS Processing on M Series,

T Series and MX Series Devices
-7 M Series and T Series Architecture
M Series and T Series CoS Packet Handling
IQ2 PIC CoS Packet Handling
MX Series (OPC and MPCjMIC) Architecture and CoS
Packet Handling
..
M Series and T Series Architecture

The slide lists the topics We discuss in this appendix. We discuss the highlighted topic first.
(,
t'
M Series and T Series ArchitectureElements (1 of 2)
\..
C
C
C
Physical Cards
Physically contain the control and forwarding plane

elements
(
~
~
Packet Forwarding Engine

Functional element containing (most of) the forwarding
ASICs
Responsible of switching and processing the transit traffic:
Route lookups and other forwarding decisions (label
push/pop/swap. replication. etc.)
COS functions: buffer management. per-port queuing. shaping.
congestion avoidance. etc.
Filtering. accounting. traffic policing. classification. remarking.
mirroring. etc.
Send
packets to the control plane elements
I
II
GIl
e
G
\JID
@
M Series and T Series Architecture-Elements
I
(it
Appendix A-4 CoS Processinf! on M Series. T !=;p.rjp'~ ~nrl
MY
C:cr'icC' 1""1 ...."\,,,.. .....
""
:J
J)
U
U
C)
1'"'\
..
l;;JI
CD
M Series and T Series ArchitectureElements (2 of 2)

II
(.. . . . ....... . ((F..a.. b..
Switching Matrix (Fabric)
','"
",'
r..i.
c..... . .
n
.
,,,'/f
Interconnects PFEs in multi-PFE routers
t\'G.':.
'CJ
Functional element forwarding traffic among PFEs

II
Intelligent Queuing Chips
l..<lQ . .)
[.IQ~]
ATM:II
.. Present in certain access PICs

Provides COS per user (YLAN, DLC!, VP/YC)
II
Control Processors
Main CPUs in the Routing Engines, and microprocessors in
forwarding cards
Handle control and exception traffic, b.ut not transit traffic
M Series and T Series Architecture-Elements
. ~,
"'_~l
............ ""il''''...
Aooendix A-5
(
(
(
(
Ml0i Architecture-IfWhat is Where"

Routing Engine
Redundant 1:1, control only
CFEB (Compact Forwarding Engine Board)
Redundant 1:1
e]
Single activePFE of the router

Contains data and notification buffers
Switches and processes aU traffic
Midplane with built-in FPCs

TWo FPCs per router (4PICs.each)
No "intelHgent" switching there
PICscah have IntemgentQL,eUing
(*) With L2 headers, but noSDH norATM
overhead (e.g. SARperformed by PIC)
MiOi Architecture
@
(I
..
.:
.:
Appendix A-6 CoS
Prnr.l'lccinrf ........
r..n
C'" .. ;~_
...... -
MiOi Architecture-"What is Where n
M10i Architecture
.,..
,....-~:--
........ ,4
!\.1V C:o ..ic).C~ nQ\/if'':>'c:.
..
Appendix A-7
\
M40eArehitecture-H What is Where"

RoutingEngine
Redundantl:l,control only
S/=M (Switching and Forwarding Module)

Redundantl:l
-Centralized sihgle-PFEfunctions:
BUfferlVlClllagernent (h"10st cos functions tlere)
- !11ternet Processor (l"Outlng Clnd

packet"Pl"Ocessing)
FPCs(Flexible PIC Concentrators)

Upto 8 per" router (4 PICs each)
Containdata buffers
Distri!:luted per-FPC I/O manager:
-Layer 2 prooessing
- ConVersion pacl,ets ~ J-oells
- Some COS functions
(coCiepoint handling)
M40e Architecture
Appendix A-8 CoS Processinr! on M
~p.rip.e: T C:"' ..i ................ ...1 ~IIV
,..._ , _.....
Junas CI ass of Service
M40e Architecture-nWhat is Where"
~
VijI
~
~
~
I)
M40e Architecture
.....
.' - -
.,... ..... --:--
....... ..4 P.,JlV Corio.~
n.o."irtlc:: ..
Aooendix A-9
\.
(
(
(
M120 Architecture-nWhat is Where H
(
(
Routing Engine
Redundant 1:1, control only

Control
Traffic
FEBs (Forwarding Engine Boards)

Up to 6per router, each FEB contains 1 PFE and buffers
l2
Static or dynamic mappihgFEB +7 FPC

1:1 (FPC2 and FPC~3) 01' l:N (FPC-I)
FPCs (FleXible PIC Concentrators)

No intelligent processing
L2 frames 81celransparently passed to FEBs
Control B.oard
Redundant 1:1, inM120 als.o part oftheforwardingplane
It ihstantiates a switch fabric that interconnects PFEs:
111 anql1y-to-any. non-blocking way
Ingress PFEs
I~now tile
destination PFE of eacllcell
M120 Architecture
Appendix A-l0 CoS Processing' on M Sp,rj,:>.<;:
T C:::oriac- "' .... .-1 ,,/IV C'~~: __ ,",_ .' . ,
C
IS
~
M120 Architecture-HWhat is Where"
M120 Architecture
(
lunas Class af Service
(
(
M320 and T Series Architecture
(
(
Routing Engine
Red.undant 1:1, control only
FPCs (Flexible PIC Concentrators)

.. up to 8 per router, each FPC contains 1 or 2 PFEs
C1
Static l:N mapping PFEB PIC
fli
G
Contl;lin data .and notification buffers

One single micl'oprocessorper FPC
SIBs (SWitCh Interface Boards)

Upto 4 active, T Series With linerate redundancy
0,
<I
They bui.ld a sWitch fabri.c. til at interconnects PFEs:

In an anytoany. nonclJlockingway
Transit
Cells
(Data &
Notif)
Ingress PFEs kllowtne destinatiDn PFE ofeacllOeil

FalJI'ic jllst.switclles oells; egress PFEJeassehlble tl16m
Ingress PFEs load balance cells. among SIBs
M320 and T Series Architecture
~
~
.. ".
\iifJ
I)
0;
\I
0;
8:
Appendix A-12 CoS Prnr.p.c:.c::.ino nl"'l
I\iI Q"....i .......... T C'_~: __
a:
_ ._."
M320 Architecture-1iWhat is Where"
M320 Architecture
'.
..... __ t __
.,..
'-"'~ ..: ......
......... A
hllV C':.ol"ic.c:: noQ\lir,,:u::,.
Aooendix A-13
(
C
Inside the Packet Forwarding Engine (1 of 2)
III
6+ router models: 2 architectures, 1 framework

Router models differ in the physical location of the functional
components (like PFEs)
There are roughly two architectures: single-PFE and multi-PFE
Multi-PFE routers require more infrastructure to interconnect
This has an effect in the PFE architecture, but the overall
framework remains
There are more points in common than differences!
III
'R'
'M'
~.':;.
~
Queuing/scheduling
WFQ & Priority
Buffer al/ocation
WRED
'N'
~
(I
Internet Processor 1/
Buffer Ma na ger
\.c
I/O Manager
Queuing and Memory

Interface
Each PFE component has a precise COS role

'L'
C
C
C
Switch InterFace
,'un Jper.net
,
Inside the Packet Forwarding Engine
f A-14
Inside the Packet Forwarding Engine (2 of 2)

In all M/T/MX router PFEs:
liLli-type components, responsible for (among other tasks):
Handlingtraffic from/to PICs. processing L2 headers - and
stripping/addingtllem
Segmentingpackets into cells (ingress). and reassembling cells into
packets (egress)
Sendingthe first cell of each packet - called notification - to the "R"
component
"R"-type components, responsible for (among other tasks):

Readingthe notification cells and performing route lookups
Applyingfine-grained filters. rate limiters and forwarding pOlicies to traffic
Changing notification contents: pop/push/swap MPLS labels. flag for
multicast replication. etc.
Sending control and exception traffic to the microprocessor associated to
the PFE
"M"-type components. responsible for (among other tasks):

Managingthe data and notification cell buffers
Queuingthe packets (ingress and egress) accordingto COS policies
Replicating multicast traffic
Inside the Packet Forwarding Engine
~. ,.. ~ -., -- .,... .... -~:--
....... ~ I\t1V co,.ioc nO\lif't:lc:.
Aooendix A-15
Agenda: CoS Processing on M Series,

T Series, and MX Series Devices
-7M Series and T Series CoS Packet Handling
MX Series (DPC and MPCjMIC) Architecture and CoS
Packet Handling

Appendix A-16 CoS Proce!=:sins:r on
M SAri.::lC! T C:::.ori.o.c- "" ... .-.1
p..tv C' __' __
l""-_ '
M Series and T Series CoS Packet Hand ling
(*)Only"access"
PI cspE;rform
COS functions
IQ.IQ2.IQ2E
Per"IFL CpS
(*) Only "access"

PICs perform
COS functions
.Components
'--
---
A .....
_~: _ _ T C- ...... ; ...... "' .... N ftJlY Co.,-ioc:::
nc.\li('lt:lc:::
Aooendix A-17
(
(
(
M Series CoS Architecture
("
'("
(
Classification based on arbitrary

packet filter. includingrate limiting
PIC
PIC
PIC
~
t>m
Internet Processor II
(Route lookup/
Classification)
<::
.[M1
PIC
PIC
M2~
......,
PIC
Shared
Memory
PIC
Classification based on input

interface and/or precedence bits
-
PIC
Queuingbased on previous classification.

WRR. INRED. precedence bits rewrite
M Series CoS Architecture
Appendix A-i8 CoS Processing' on M
~p.ripc: T c:.QriQ~
<:InA ftilV C .......: ....... ,",-.. : - - -
T Series CoS Architecture Ingress PfE
Input L2 Rate
Liinitingand Policing;
(Specific PIGs)
Fabric Strict
Priority Queuing
(All PIGs)
Input L:3 Hard and

Soft policing
(All PIGs)
Switch Fabric
........
T Series CoS Architecture
,..._ ..... '"' .. _____ I ____
"~C'
.....; .......
T~ ......; ............... Mf.ItVc:o .. io~n""\Ii,.,c.e
AnOAndixA-:JQ
T Series CoS Architecture Egress PFE

Output L3 Hard
and Soft Policing
(All PICs)
Output L2
Rate Limiting
(Specific PICs)
Switch FaMe
....
.....
T Series CoS Architecture
Appendix A-20
CoS Processine: on M SArip.~ T SArip,e; ::Inri MV
C::.:>.riQc
(')0";".0.'"
Agenda: CoS Processing on NI Series,

T Series, and NIX Series Devices
~ IQ2 PIC CoS Packet Handling
MX Series (DPC and MPCjMIC) Architecture and CoS

Packet Handling
IQ2 PIC Cos Packet Handling
.... - ._, - -
'T"
l"'_~:_ ...
......... ..-1 ,."V Corioc I")Q\li,...p.c:.
Aooendix A-21
(
(
C
(
(
(
(l:
(j
IQ2 PIC CoS Packet Handling-lngress
Incoming
G
~
~
~
e
(J
41
..
.,
.,
(8
~
va
(I
IQ2 PIC CoS Packet Handling-egress
......... Outgoing
packet
Agenda: CoS Processing on M Series"

T Series, and MX Series Devices
.. M Series and T Series Architecture
.. M Series and T Series CoS Packet Handling
.. IQ2 PIC CoS Packet Handling
~MX Series (DPC and MPCjMIC) Architecture and CoS
Packet Handling
MX Series (OPC and MPC/MIC) Architecture and CoS Packet Handling

Appendix A-24
CoS Processinll on M Series. T Sp.rip.!=;. "mc:! MX ~p.riA~ np."i(';p.~
,anA/HI;' , .... in,::.r
nl=lot
NIX Components
MX960
Redundant RE, Fan, Power, Switch Fabric
Control - - . j : ;
Panel
RE---
Lower - - I >
Fantray
Air ---+,1$ i:jmm
Int"K!'t
;gI;I;I;l;Illlm:Q;!;IJ;IIIJ;I;IJ;IiIlI
.... ........................................ . .
... ................................................ ................................................ .
MX Components
""O"A' i,' ... i ..... "
... __ L
c
c
c
c
c
MXDPCCards
.. I-Chip
(t
-Incorporates L, M, N, R chip functionality; 'PFE on a chip'

- Provides Layer 3 functionality
- Provides queues for ingress and egress streams
.. EZ chip
.. Ethernet Services Engine; NP-2 Network Processor for Layer 2
- Provides traffic managers and classification search engines
.. opes include:
- TwoGE interfaces to send Qontrol information, route
information, and statistics between the Routing Engine and
the CPU on the DPCs
- PacketForwarding Engines - 4 PFE complexes (48 * 10Gbps
* 2)
c
c
~
I
fJ
~
E
~
~
~
~
~
~
Midplane connectors and power circuitry

- Processorsu
.2-GHz CPU
. m controller
SDRAM)
MXDPCCards
.,
(I
\it
"
(I
(I
(I
(I
Appendix A-26
caS Processim! on M Series. T Series. and MX Sp.rip.~ np.viop.~
UnAlIA!
1I1",inAr n.,:lt
NIX Packet Handling Components

L,M,N,R all in I-Chip
PFE
PFE
PFE
e
.,
PFE
(i
CPU on ea"h OPC
for exceplion and RE Processing
MX Packet Handling Components
~
Wf!jjJ
.... , : _1 ___ _
MX DPe Packet Walk-Through-lot 5

ope
Switch Fabric
Pa.cket
In
Marks L2 packets.
tokens
L3 Removes L2
encapsulation
(J1J
Sends the packet

to I-Chip
~
~
CPU on eaell DPC.

for exception anti RE Processing
@l
(fJ
@
MX DPe Packet WalkThrough
..
Appendix A-28 CoS Processim! on M Series. T Series,. ;;lnrt MX ~Aril=l~ nj:l\lir~c:
......... : .. -: ..................
NIX DPe Packet Walk..Through-2 of 5

OPC
Packet .-.
In
CJ
Queue
management
OPC
Send the packet

across the fabric to
the destination
.OPC
r---~~-
Any exception
packets to RE
Token based
lookup including
flooding
MX DPe Packet Walk-Through
MX DPC Packet Walk..Through-3 of 5

OPC
Switch Fabric
DPC
ClQeue
Management
L2
"
f)
Appendix A-30
CoS Processin~ on M Sp.rjp'~" T Sp.riPc:. ~nrl MY
C:,c,yj.oc:- no"i ..... "' ...
NIX DPC Packet Walk..Through-4of 5

DPC
DPC
CPU on eai;!1 OPC
for exception and RE Processing
MX ope Packet Walk-Through
(
(
(
"-
C
C
C
MX DPe Packet Walk..Yhrough-5 of 5

Switch Fabric
OPC
C
C
~
~
~
~
.OPC
Optional
CPU on eac~ PPC
forexception and HE processing
~
~
~
~
CD
cD
cD
CD
cD
(I
<;:)
Appendix A-32 CoS ProcessinE! on M Sip-riA!=:. T SFlri,::r.c:.
~nrl MY c:o .. j..,. ...
r"\", .. :~~ ....
MX Series CoS Packet Handling

-DPG - port-level queuing
-Enhanced Queuing(EQ) DPG -per-VLAN queuing
.,
.,
I)
(*)H-CqScm
EQ-DPConIY
&
ESE NPU :Ethernetservices engine

network processing un it
.
1&
MX Series CoS Packet Handling
CD
..
41)
41)
(';)
c
c
c
c
c
MPC Components
-IXASIC
j>{l WAN connectivity chip (physically located on the MIC)
f?;.i
Interfaces to the MQ (system side & WAN side)

Pre-classification for oversubscription
~
(II
MQASIC
Interconnects will all other Trinity ASICs
,Manages packet data memory and fabric queuing
Interfaces to LU for packet lookup andencapfunctions
iii
LUASIC
-Packet header processing (rol1te lookup, classification, filtering,
policing~ accounting, encapsulationaild stats)
-Supports external TCAM offer accelerated lookup processing
QXASIC
"I
e
- Rich hierarchical queuing, congestion dropping and stats
~
~
ti
(I
MPC Components
Appendix A-34
CoS Processin~ or. M Series. T Sp.rip.~_ Fmn MX SAriA!=:;
np\fj(,j:l.C::
"'U'U' \, 'fiinQ.r n/::lt
MPC Architecture
MPC Architecture
\A" .... ,
;"ni .... "" .. __ ..
MICjMPC CoS Packet HandUng-ingress
MICjMPC Cos Packet Handling-Ingress
Appendix A-36
CoS Processinfl on M Series. T Sp.rip.~. rmrl MX Sp.riA~ np\li,...,:.<=:.
, ... ,,,., i. ,,,..,jn.::>r net
MICjMPC CoS Packet Handling......egress
MIC/MPC Cos Packet Handling-Egress
Summary
In this appendix, we:
Identified the various components of M Series, T Series, and
MX Series architectures
Described CoS packet handling for each architecture
t
~
(I
(i
I
I
I
~
This Appendix Discussed:
The various components of M Series, T Series, and MX Series architectures; and
CoS packet handling for each architecture.
Appendix A-38 CDS ProcessinE!: on M Serres. T Sp.rjp'~
rlnrl M)( C:t:lril!>~ n'O\li ......o..,.
-:-----~
Appendix B: Acronym List

AF ................................................................................. assured forwarding
ASIC .................................................................application-specific integrated circuit
BA ................................................................................. behavior aggregate
CBF .....................................................................class-of-service-based forwarding
CIR ......................................................................... committed information rate
CLI ............................................................................command-line interface
CoS ....................................................................................cl ass-of-service
CPE ........................................................................customer premises equipment
C-VLAN .................................................................................customer VLAN
DiffServ ......................................................................... Differentiated Services
DLCI ...................................................................... data-link connection identifier
DPC......................................................................... Dense Port Concentrator
DSCP .............................................................................. DiffServ code point
DSLAM ......................................... ~ ................. digital subscriber line access multiplexer
EF ................................................................................ expedited forwarding
FPC ........................................................................... Flexible PIG Concentrator
GUI ...........................................................................graphical user interface
lANA .................................................................Internet Assigned Numbers Authority
IEEE ...................................................... Institute of Electrical and Electronics Engineers
IETF................................................................... Internet Engineering Task Force
IGP ...........................................................................interior gateway protocol
IQ .............. : .................................................................. intelligent queuing
JNTCP .................................................... Juniper Networks Technical Certification Program
MAC ..............................................................................media access control
MTU ........................................................................ maximum transmission unit
PFE ...... _ ....................................................................Packet Forwa rding Engine
PHB ................................................................................. per-hop behavior
PIR .............................................................................. peak information rate
PLP ...... _ ..........................................................................packet loss priority
RED ........................................................................... random early detection
SIB ............................................................................. Switch Interface Board
SLA ............................................................................service-Ievel agreement
S-VLAN ...................................................................................service VLAN
ToS ................................................................................... type of service
VLAN .................................................................................... _ . virtual LAN
VolP ..... _ ............................................................................. voice over IP
WRED ................................................................. weighted random early detection
WRR ..............................................................................weighted round-robin
l!.f'I"nnvm List 8-1
f\
(
(
{
"
I
~
~
(J
.~
.~
'~
(I
,0
e:
(I
(8
B-2 Acronym list
Appendix C: Answer Key

Chapter 1:
Course Introduction
This chapter contains no review questions.
Chapter 2:
CoS Overview
1.
The DSCP consists of the six most significant bits ofthe ToS field.
2.
For the assured forwarding PHS, four classes exist, each with three drop probabilities.
3.
The Junos as can process IPv4 DiffServ, IPv6 DiffServ, MPLS EXP, and IEEE 802.1p.
4.
Policing limits traffic volume and burstiness. Excess traffic can be marked or discarded.
Chapter 3:
1.
Forwarding classes map to queues.
2.
PLP provides you with the options to selectively drop one traffic type over another should the device
become congested.
3.
You configure MF classification using a firewall filter, which you then apply to an interface under the
interfaces stanza. You configure SA classification by defining a custom classifier (or using a default
classifier) and applying it to an interface (all within the class-of-service stanza).
4.
You generally use MF classification at the ingress point of the network. You generally use SA classification
within the network.
5.
SA classification occurs first.
6.
The primary default SA classifier is ipprec-compatibility.
Chapter 4:
POlicing
1.
The primary function of policing is to provide a first stage of congestion management. With policing, you
can condition incoming or outgoing traffic by applying bandwidth constraints.
2.
Soft-policing modifies traffic that is outof-profile. Hardpolicing drops out-ofprofile traffic.
3.
Single-rate tricolor marking policers are designed to affect traffic based on burst thresholds. Packets
below the CBS threshold are green and assigned low PLP. Packets exceeding CBS but not EBS are yellow
and assigned mediumhigh PLP. Packets exceeding EBS are red and assigned high PLP.
4.
Color-blind mode does not consider any previous coloring of packets; color-aware mode does. In
color-aware mode, the pOlicer cannot improve exiting PLP values.
5.
A filter-specific policer could be useful when you want to filter several specific types and treat it all as a
single traffic flow for pOlicing purposes.
6.
Interface pOlicers apply before firewall filters.
Chapter 5:
Scheduling
i.
Scheduling components include transmission rate, queue priority, delay buffers, drop profiles, and drop
profile maps.
2.
Traffic is "outofprofile" when it exceeds the queue's allocated transmission rate.
3.
False. A stricthigh queue shares packet transmission with high priority queues, so you can assign high
priority to queues to avoid starvation by the strict-high queue.
4.
One option is to configure the queue's buffer size as a percentage of the interface's available buffer. The
other option is temporal, where you configure the buffer as an amount of time.
5.
To implement WRED, configure multiple drop profiles with varying degrees of aggressiveness, and then
apply the various drop profiles selectively based the importance of traffic within each queue.
6.
The general steps to configure scheduling are the following: 1) configure the scheduler, including drop
profiles; 2) configure the scheduler map; 3) apply the scheduler map to an interface .
C-2 Answer Kev
o
o
o
o
o
o
o
o
Chapter 6:
1.
H-CoS supports up to four CoS levels: port, interface set, logical interface (VLAN), queue.
2.
The two scheduler modes are per-unit and hierarchical. The difference between them is that per-unit
scheduling does not include interface sets.
3.
You can populate interface sets my manually adding specific logical units or by specifying outer VLAN tags.
4.
"e
By default, interface sets and VLANs share bandwidth in proportion to their CIRs.
5.
The VLAN's traffic control profile references a scheduler map in order to link a VLAN with its set of queues.
6.
Remaining traffic is all logical units (VLANs) that do not have a profile applied.
Hierarchical Scheduling
7.
In an H-CoS context, a queue has two priority levels. When a VLAN <= CIR, its queues use their configured
priority. When a VLAN > CIR, its queues (- SoH) have excess priority.
Chapter 7:
Rewrite Rules
1.
(0)
Rewrite rules apply CoS values based on a packet's forwarding class and PLP.
~
~
2.
Junos devices use the MPLS EXP default rewrite table by default on MPLS-enabled interfaces.
"
You can use the import feature to simplify rewrite table configuration.
3.
4.
False. To apply a rewrite table to an interface, use the rewri te-rules command.
5.
Yes, you can configure just one protocol's coS value when a pa.cket uses multiple protocol s, and yes, you
can configure more than one protocol's CoS value at the same time.
I>
'~
\:;1
fmc::.wer Kev C-3
,.
Chapter 8:
CoS-Based Forwarding
1.
CBF supports IPv4, IPv6 and MPLS traffic.
2.
You identify desired traffic using routing policy.
3.
When OSPF is the IGP, you must configure the next-hop using the interface name rather than the IP
address.
Chapter 9:
.~
4.
MPLS next-hops are preferred over IP next-hops.
Case Study
.~
This chapter contains no review questions.
(i
~
'.
..
.(1
~
.()1J
.~
"
'.
e
Ie
e
(I
CD
(8
C-4 Answer Key
('
(;
(
(
(
(
c
c
(
(
(
(
(
f
(
(
(
(
(
(
(
'(
'(
(
(
(
(
(
.(
'"
(
(
(
(
(
(

Junos COS

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Junos COS

Caricato da

Copyright:

Formati disponibili

J

Junos Class of Service

Worldwide Education Services

Course Number: EDU-JUN-JCOS

This document is produced by Juniper Networks, Inc.

Junes Class of Service Student GuIde, RevisIon 10.a

Chapter 1: Course Introduction ................................................ 1-1

CoS Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .. 2-1

Packet Classification ............................................... 3-1

Policing ......................................................... 4-1

Scheduling ........................................................ 5-1

Hierarchical Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6-1

Rewrite Rules ..................................................... 7-1

Case Study . ...................................................... . 9-1

Appendix 8: Acronym List ... .................................................... 8-1

Understand the history and evolution of CoS.

Identify the CoS fields in various packet headers.

Identify the default CoS settings on Junos devices.

Configure and verify behavior aggregate and multifield (MF) classification.

Configure and verify two-color and tricolor marking policers.

Configure and verify schedulers and their components.

Configure and verify the multiple levels of hierarchical schedulers.

Configure and verify packet header rewriting.

Configure and verify class-based forwarding.

Create a CoS configuration based on a set of design requirements.

Lab 1: Configuring Packet Classification

Lab 5: Configuring Rewrite Rules

eLi and GUI Text

GUI text elements:

Text field entry

Select File > Open, a nd then click

Filename text box.

Input Text Versus Output Text

Physical interface: fxpO,

View configuration history by clicking

Text that you must enter.

lab@San_Jose> show route

Defined and Undefined Syntax Variables

Text where variable value is

Click on my-peers in theo dialog.

Text where the variable's value

Type set pol:i.cy poli.cy-name.

About This Publication

Juniper Networks Support

I ...... -t:... ~~~ ... : __

Junos Class of Service

Junos Class of Service

This Chapter Discusses:

Objectives and course content information;

Additional Juniper Networks, Inc. courses; and

The Juniper Networks Certification Program.

COl Trc:.p lntrnrllll"tinn

Junos C lass of Service

Where db yon wqrk?

- What is YoiJJ prjrnaryrple in your

... f'h"""'Tar "I

Junos Class of Service

InhnM' ....+; ..........

Junos Class of Service

General knowledge orcos concepts is helpful

rnllr.:::,o IntrnriliMinn ",. r.h;:mtAr 1-t;

lunos Class of Service

Breakand restroom facilities

General Course Administration