JUNOS QoS

 What JUNOS QoS supports

Classifiers Forwarding classes & Loss Priority Scheduling and Queues Rewriting Dropping Fabric Scheduler

Components of JUNOS QoS

JUNOS CoS applications supports

Differentiated Services
DiffServ as well as six-bit IPv4 and IPv6 header ToS byte settings. DiffServ code points (DSCPs) in the IP and IPv6 ToS fields used to determine the forwarding class of a packet. Layer 2 to Layer 3 CoS mapping Mapping of Layer 2 (IEEE 802.1p) packet headers to routing platform forwarding class and loss-priority values.
Layer 2 to Layer 3 CoS mapping involves setting the forwarding class and loss priority based on information in the Layer 2 header. Output involves mapping the forwarding class and loss priority to a Layer 2-specific marking. You can mark the Layer 2 and Layer 3 headers simultaneously.

MPLS EXP Mapping of MPLS experimental (EXP) bit settings to routing platform forwarding classes and vice versa. VPN outer-label marking Setting of outer-label EXP bits, also known as CoS bits, based on MPLS EXP mapping.

Classifiers

Classifiers
Associate incoming packets with a forwarding class and loss priority and, based on the associated forwarding class, assign packets to output queues.
Behavior aggregate (BA) or code point traffic classifiers
Code points determine each packets forwarding class and loss priority. BA classifiers allow you to set the forwarding class and loss priority of a packet based on DiffServ code point (DSCP) bits, DSCP IPv6, IP precedence bits, MPLS EXP bits, and IEEE 802.1p bits. The default classifier is based on IP precedence bits.

Multifield (MF) traffic classifiers

Allow you to set the forwarding class and loss priority of a packet based on firewall filter rules.

BA Classifier
Allows you to set FC and PLP:
For incoming IPv4 and IPv6 packets, based on the value of the entire 6-bit DSCP field. For incoming MPLS packets, based on the value of the MPLS EXP field. For incoming Ethernet packets, based on the value of the 802.1p bits. For incoming ATM traffic, the ATM2 PIC can be configured to set the assembled packet notifications PLP-bit based on the ATM cell loss priority (CLP) bit.

Classification Defaults
Default no-config classification:
Only ipprec-compatibility classification table is active 000-101 go to queue0, plp=least significant bit 110-111 go to queue3, plp=least significant bit All other unclassified packets are placed in queue0 Incoming MPLS packets are placed in output queue 0 Incoming IEEE 802.1p is ignored

8
Copyright 2004 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net

BA Classifier Configuration
1.

Create a dscp, exp, ieee-802.1p or ip precedence classifier:

[edit] class-of-service { classifiers { [dscp | exp | ieee-802.1 | inet-precedence] classifier-name { import [classifier-name | default]; forwarding-class class-name { loss-priority [low | high] code-points [alias | bits];

>>BA Classifier Configuration

2. Bind the classifier to an incoming logical interface:
[edit] class-of-service { interfaces { interface-name { unit unit-number { classifiers { [dscp | exp | ieee-802.1 | inet-precedence] [classifier-name |

default];

10

MF Classifier
Allows to use an arbitrary input firewall filter to set the FC and/or PLP fields in the packet notification. Working for incoming and outgoing packets MF-classifier overrides BA-classifier if conflict MF filters are applied per-logical interface and the number of MF classifiers that can be configured on an interface is virtually unlimited, since it is solely bounded by memory.
11

MF classifier example # 1

Map all traffic coming into an interface to a particular forwarding-class (queue#)

[edit] class-of-service { interfaces { interface-name { unit unit-number { forwarding-class class-name;

12

MF classifier example # 2

Map destination IP addresses to specific forwarding classes

1.Define a policy class to override the default packet classification. [edit] class-of-service { forwarding-policy { class class-name { classification-override { forwarding-class fc-class-name;
13

>>MF classifier example # 2

2. Create a policy to identify the IP addresses to which the policy class should be applied.
[edit] policy-options { policy-statement policy-name { term term-name { from route-filter destination-prefix match-type; then class class-name;

14

>>MF classifier example # 2

3. Export the policy to the forwarding table.
[edit] routing-options { forwarding-table { export policy-name Note:
this essentially tags the matching forwarding table entries with a queue#, so that packets forwarded using those entries get placed into the specified queue.

15

MF classifier example # 3
Configuring classification based on a firewall filter:
1. Define the firewall filter:
[edit] firewall { filter foo { term term-1 { from { match-conditions; (see previous slide) } then { forwarding-class class-name; loss-priority [low|high]; accept; term default { then accept; }

16

>>MF classifier example # 3

2. Apply the firewall filter to an interface:
[edit] interfaces interface-name { unit logical-unit-number { family inet { filter { input foo;

Notes:
Can only apply 1 input and/or output firewall filter to an interface

17

Forwarding Classes

18

Forwarding Classes: ordered aggregates

Affect the forwarding, scheduling, and marking policies applied to packets as they transit a routing platform. The forwarding class plus the loss priority define the per-hop behavior.
Best effort, Assured forwarding, Expedited forwarding, Network control.

19

Forwarding Classes: ordered aggregates

M-series, except M320, routing platforms,
four forwarding classes are supported;

M320 and T-series platforms,

eight forwarding classes are supported,
For example, multiple classes of EF traffic: EF, EF1, and EF2.

20

Loss Priority
Internal mechanism. Typically mark packets exceeding some service level with a high loss priority. Loss priority affects the scheduling of a packet without affecting the packets relative ordering. Loss priority is set by configuring a classifier or a policer.

21

Scheduling and rate Control

22

Transmission Scheduling and rate control

Manages traffic flows: Schedulers
Define the priority, bandwidth, delay buffer size, rate control status, and RED drop profiles to be applied to a particular forwarding class for packet transmission.

Fabric schedulers
For M320 and T-series platforms only, fabric schedulers allow you to identify a packet as high or low priority based on its forwarding class, and to associate schedulers with the fabric priorities.

Policers for traffic classes

limits traffic of a certain class to a specified bandwidth and burst size. Packets exceeding the policer limits can be discarded, or can be assigned to a different forwarding class or to a different loss priority, or to both. You define policers with filters that can be associated with input or output interfaces.
23

Output Queue Scheduling,

Each FC has three parameters:
The buffer-size:
Maximum queue length as a % of the output interfaces total buffer capacity or a temporal value from 1 to 200,000 ms. Define maximum buffer delay.

The transmit-rate:
Bandwidth allocated to a FC. Each FC is assigned transmission bandwidth credits by the DWRR scheduler every 200 microseconds, based on the configured transmit-rate. The transmission bandwidth assigned to each queue can be rate limited to the exact value specified, or it can exceed the configured rate and borrow surplus bandwidth if it is unused by other FCs. This is basically traffic shaping per queue.

The priority:
identifies the scheduling priority assigned to the FC. The scheduling priority can be configured as low, high, or strictly-high. High-priority FCs are allowed to transmit packets ahead of low-priority FCs as long as the high-priority FC retains enough bandwidth credits. A Strictly-high priority FC has precedence over all other FCs as long as there is strictly-high priority traffic waiting to be sent.

24

Queues: Define forwardingclasses

Queue numbers are now abstracted to forwarding-classes Default Forwarding-classes:
be -> queue0 ef -> queue1 af -> queue2 nc -> queue3

25

Queues: Define forwardingclasses

Assign forwarding-classes to queues:
[edit] class-of-service { forwarding-classes { queue queue-number class-name; queue queue-number class-name; queue queue-number class-name; queue queue-number class-name;

26

Queues: Size
Large queues may increase latency during congestion smaller queues may be more appropriate for delay sensitive traffic The default configuration has queue 0 with 95% of queue memory and queue 3 with 5%

27

Queues: Size Configuration

Queue size configuration:
[edit] class-of-service { schedulers { scheduler-name { buffer-size [temporal|percent percentage|remainder];

Bind the scheduler to a queue and interface Can specify queue size in time for time-sensitive traffic
{master}[edit class-of-service] juniper@t640_RE0# set schedulers test buffer-size temporal 8000

28

Queues: Transmit Rate

Determines the actual traffic bandwidth
Rate is specified in bits per second
Limit the transmission bandwidth to the exact value Allow it to exceed the configured rate if additional bandwidth is available from other queues.

Also referred to as WRR%

The default configuration has queue 0 with 95% of queue bandwith and queue 3 with 5%

29

Queues: Transmit Rate

Transmit rate configuration:
[edit] class-of-service { schedulers { scheduler-name { transmit-rate [rate | percent percentage | remainder] <exact>;

Bind the scheduler to a queue and interface

30

Queues: Priority
Determines the order in which an output interface transmits traffic from the queues JUNOS supports:
Low priority, Medium-low priority, Medium-high priority, High priority, Strict-high priority

31

Queues: Priority
The order by which the DWRR queuescheduling algorithm services queues is:
High priority with positive credit Medium High priority with positive credit Medium Low priority with positive credit Low priority with positive credit High priority with negative credit Medium High priority with negative credit Medium Low priority with negative credit Low priority with negative credit.
32

Combination of PQ and DWRR

M-series and T-series platforms can have max one queue per interface with strict-high priority, which works the same as high priority, but provides unlimited transmission bandwidth. As long as the queue with strict-high priority has traffic to send, it receives precedence over all other queues, except queues with high priority. Queues with strict-high and high priority take turns transmitting packets until the strict-high queue is empty, the high priority queues are empty, or the high priority queues run out of bandwidth credit. Only when these conditions are met can lower priority queues send traffic.
33

Combination of PQ and DWRR

If you do configure a transmission rate on a strict-high priority queue, it does not affect the WRR operation. The transmission rate only serves as a placeholder in the output of commands such as the show interface queue command. Strict-high priority queues might starve low priority queues. The high priority allows you to protect traffic classes from being starved by traffic in a strict-high queue.

34

Queues: Priority Configuration

[edit]
class-of-service { schedulers { scheduler-name { priority priority-level;

Bind the scheduler to a queue and interface

Default no-config settings:

All queues are low priority

35

Congestion Management
1. Configure the RED profiles:
[edit] class-of-service { drop-profiles { profile-name { fill-level percentage1 drop-probability probability1; fill-level percentage2 drop-probability probability2; up to 64 times, OR interpolate { drop-probability [ p1 p2 p3 p4 p5 ]; fill-level [ f1 f2 f3 f4 f5 ] ;

fill-level creates a series of steps interpolate creates a series of line segments from (0,0) to (f1,p1), then (f1,p1) to (f2,p2), then (f2,p2) to (f3,p3), etc.

36

Congestion Management
2. map the drop-profile to a scheduler:
[edit] class-of-service { schedulers { scheduler-name { drop-profile-map loss-priority [low|high] protocol [non-tcp|tcp|any] dropprofile profile-name;

Bind the scheduler to a queue and interface

Default no-config settings:

100% drop probability at 100% full (drop from head of queue) 0% drop probability for other levels of fullness
37

Scheduling Configuration
1. Configure schedulers;
[edit] class-of-service { schedulers { scheduler-name { transmit-rate [rate|percent percentage|remainder] <exact>; WRR config buffer-size [milliseconds|percent percentage|remainder]; queue size config priority [low|high]; queue priority config drop-profile-map loss-priority [low|high] protocol [non-tcp|tcp|any] drop-profile profile-name; RED profile assignment

38

>> Scheduling Configuration

2. Assign schedulers to a scheduler-map:
[edit] class-of-service { scheduler-maps { map-name { forwarding-class class-name1 scheduler scheduler-name1; forwarding-class class-name2 scheduler scheduler-name2; forwarding-class class-name3 scheduler scheduler-name3; forwarding-class class-name4 scheduler scheduler-name4;

3. Bind the scheduler map to a physical interface:

[edit] class-of-service { interfaces { interface-name { scheduler-map map-name;

39

Scheduling in Summary
Default no-config settings:
WRR%:
Queue0 gets 95% Queue3 gets 5%

Queue size:
Queue0 gets 95% of buffer space Queue3 gets 5% of buffer space

Priority:
Low

RED:
100+% full then drop, otherwise dont
Note: A queues WRR% and queue size % should be kept similar in value

40

DWWR Example
Queue 3 is asigned HP,
control traffic, 5% of the interfaces buffer capacity, 5% of the interfaces bandwidth, Can borrow surplus bandwidth from other queues if it is available.

Queue 2 is assigned a HP, gold traffic,

20% of the interfaces buffer capacity, 45% of the interfaces bandwidth, Can borrow surplus bandwidth from other queues if it is available.

Queue 1 is assigned a LP, silver traffic,

30% of the interfaces buffer capacity, 30% of the interfaces bandwidth Can borrow surplus bandwidth from other queues if it is available.

Queue 0 is assigned a LP, best-effort traffic,

50% of the interfaces buffer capacity, 20% of the interfaces bandwidth, Can borrow surplus bandwidth from other queues even if it is available.

41

DWRR Example

42

Combination of PQ and DWRR

Queue 3 strictly-high priority, latency and jitter-sensitive voice traffic,
5% of the interfaces buffer capacity, Can borrow surplus bandwidth from other queues if it is available. BW has no meaning

Queue 2 Low priority, gold traffic,

30% of the interfaces buffer capacity, 30% of the interfaces bandwidth, Can borrow surplus bandwidth from other queues if it is available.

Queue 1 low priority, silver traffic,

30% of the interfaces buffer capacity, 30% of the interfaces bandwidth, Can borrow surplus bandwidth from other queues if it is available.

Queue 0 low priority, best-effort traffic,

35% of the interfaces buffer capacity, 20% of the interfaces bandwidth, Can borrow surplus bandwidth from other queues even if it is available.

43

Combination of PQ and DWRR

44

Rewrite

45

Rewrite Markers
Rewrite markers
Redefines the code-point value of outgoing packets.

46

Rewriting Configuration
1. Configure rewrite-rule;
[edit] class-of-service { schedulers { rewrite-rules { dscp|exp|ieee-802.1|inet-precedence <table-name> { import [<table-name>|default]; (default=exp-default) forwarding-class <class-name1> { loss-priority [low|high] code-point [<alias>|bits]; } forwarding-class <class_name2> { loss-priority [low|high] code-point [<alias>|bits]; } forwarding-class <class-name3> { loss-priority [low|high] code-point [<alias>|bits]; } forwarding-class <class_name4> { loss-priority [low|high] code-point [<alias>|bits]; }

47

>>Rewriting Configuration
2. Apply rewrite-rule to outgoing logical interface;
[edit] class-of-service { interfaces { interface-name { unit <unit-number> { rewrite-rules [dscp|exp|ieee-802.1|inet-precedence] [rewrite-name |default] ;

48

Rewriting Configuration, MPLS

[edit] protocols { mpls { label-switched-path lsp-name { (user defined name) class-of-service value; (0-7)

ALL traffic forwarded down the LSP will have EXP=value

49

Rewriting Classification
No-config Default: exp-default rewrite-rule active on all interfaces:
Rewrite rule: exp-default, Code point type: exp, Index: 2 exp- default, Forwarding class best-effort bestbest-effort bestexpedited-forwarding expeditedexpedited-forwarding expeditedassured-forwarding assuredassured-forwarding assurednetwork-control networknetwork-control networkLoss priority low high low high low high low high Code point point 000 001 010 011 100 101 110 111

50

Default no-config Summary

Classification: only ipprec-compatibility classifier is active Queue Properties: (size, RED, scheduling)
WRR%:
Queue0 gets 95% Queue3 gets 5%

Queue size:
Queue0 gets 95% of notification memory space Queue3 gets 5% of notification memory space

Priority:
Low

RED:
100% full then drop with 100% probability, otherwise dont

Rewriting: only exp-default rewrite-rule is active

51

Drop profile

52

Drop Profiles
E-FPC can have 16 unique drop profiles, vs 32 in T sereis. Each queue has four pointers into this global pool of drop profiles One pointer for permutations of the TCP and PLP bits {(TCP=0, PLP=0), (0,1), (1,0), and (1,1)} for packets placed in the given queue. Pointers identifies the WRED drop profile in the global pool.

53

Queues: Drop Profile

Defines the drop probabilities across the range of delay-buffer occupancy, thereby supporting the RED process For each scheduler, you can configure four separate drop profiles, one for each combination of loss priority (low or high) and IP transport protocol (TCP/IP or non-TCP/IP)
Maximum of 32 different drop profiles

54

Queues: Drop Profiles

Drop profile configuration:
[edit] class-of-service { schedulers { scheduler-name { drop-profile-map loss-priority [any | high | medium | low] protocol [any | non-tcp | tcp] drop-profile profile-name;

Then bind the scheduler to a queue and interface Default no-config settings:
100+% full then drop, otherwise dont
55

Mapping queued packets to WRED profile

56

T & M320 Switch Fabric Scheduler

Separate queues on the ingress PFE facing the fabric. Separate paths through the fabric for high and low priority cells. This means that a low priority cell never blocks a high priority cell. Default behavior is fabric priority queuing on egress interfaces to match the scheduling priority you assign. High-priority egress traffic is automatically assigned to high-priority fabric queues. Likewise, low-priority egress traffic is automatically assigned to low-priority fabric queues.
57

Thank You

58