Priority Propagation in Hierarchical Scheduling
Priority propagation is performed for MX Series router output
Interfaces on Enhanced Queuing DPCs, MICs, and MPCs, and for M Series
and T Series router output interfaces on IQ2E PICs. Priority propagation
is useful for mixed traffic environments when, for example, you want
to make sure that the voice traffic of one customer does not suffer
due to the data traffic of another customer. Nodes and queues are
serviced in the order of their priority. The default priority of a
queue is low, and you can explicitly configure a queue priority by
including the priority statement at the [edit class-of-service schedulers scheduler-name] hierarchy level.
You cannot directly configure the priorities of all hierarchical scheduling elements. The priorities of internal nodes, for example, are determined as follows:
The highest priority of an active child, that is, a child currently containing traffic. (Interface sets only take the highest priority of their active children.)
Whether the node is above its configured guaranteed rate (CIR) or not (this is only relevant if the physical interface is in CIR mode).
Each queue has a configured priority and a hardware priority. The usual mapping between the configured priority and the hardware priority is shown in Table 1.
Configured Priority |
Hardware Priority |
|---|---|
Strict-high |
0 |
High |
0 |
Medium-high |
1 |
Medium-low |
1 |
Low |
2 |
MPCs also have configurable
CLI priorities of |
|
In CIR mode, the priority for each internal node depends on whether the highest active child node is above or below the guaranteed rate. The mapping between the highest active child’s priority and the hardware priority below and above the guaranteed rate is shown in Table 2.
Configured Priority of Highest Active Child Node |
Hardware Priority Below Guaranteed Rate |
Hardware Priority Above Guaranteed Rate |
|---|---|---|
Strict-high |
0 |
0 |
High |
0 |
3 |
Medium-high |
1 |
3 |
Medium-low |
1 |
3 |
Low |
2 |
3 |
Excess-priority high* |
N/A |
3 |
Excess-priority medium-high* |
N/A |
3 |
Excess-priority medium-low* |
N/A |
4 |
Excess-priority low* |
N/A |
4 |
* MPCs only |
||
In PIR-only mode, nodes cannot send if they are above the configured shaping rate. The mapping between the configured priority and the hardware priority is for PIR-only mode is shown in Table 3.
Configured Priority |
Hardware Priority |
|---|---|
Strict-high |
0 |
High |
0 |
Medium-high |
1 |
Medium-low |
1 |
Low |
2 |
A physical interface with hierarchical schedulers configured is shown in Figure 1. The configured priorities are shown for each queue at the top of the figure. The hardware priorities for each node are shown in parentheses. Each node also shows any configured shaping rate (PIR) or guaranteed rate (CIR) and whether or not the queues is above or below the CIR. The nodes are shown in one of three states: above the CIR (clear), below the CIR (dark), or in a condition where the CIR does not matter (gray).
In the figure, the strict-high queue for customer VLAN 0 (cvlan 0) receives service first, even though the customer VLAN is above the configured CIR (see Table 2 for the reason: strict-high always has hardware priority 0 regardless of CIR state). Once that queue has been drained, and the priority of the node has become 3 instead of 0 (due to the lack of strict-high traffic), the system moves on to the medium queues next (cvlan 1 and cvlan 3), draining them in a round robin fashion (empty queue lose their hardware priority). The low queue on cvlan 4 (priority 2) is sent next, because that mode is below the CIR. Then the high queues on cvlan 0 and cvlan2 (both now with priority 3) are drained in a round robin fashion, and finally the low queue on cvlan 0 is drained (thanks to svlan 0 having a priority of 3).