A hardware aggregate shaper scheduler policy is an alternative to a port scheduler. A hardware aggregate shaper policy can only be assigned at the vport level.
A virtual vport scheduler is added to implement a bandwidth-distribution software algorithm to handle traffic oversubscription by subscriber hardware aggregate shapers at a vport.
The vport represents a downstream bandwidth constraint and therefore the algorithm enforces a maximum rate, which is an Ethernet on-the-wire rate. This algorithm also implements the logic to distribute the available bandwidth at the vport to its child hardware aggregate shapers.
The algorithm performs a similar function to the existing HQoS port scheduler, however, instead of modifying the oper-PIRs of queues, policers, or schedulers, it modifies the oper-PIR of the hardware aggregate shapers connected to it, and consequently triggers recalculation of the individual queue’s FIR, if required.
Figure: Vport bandwidth distribution shows the functionality of a hardware aggregate shaper scheduler, including all parameters which the user can set. This architecture allows the user full flexibility to define SLA models.
The generic design in Figure: Vport bandwidth distribution can be mapped into two SLA models as shown in Figure: SLA models . Both SLA models show two subscriber categories for simplicity, but this model can be extended to any number of subscriber categories.
The SLA model (a) in Figure: SLA models shows the overall vport bandwidth distribution between gold and white categories in a ratio of 8:1 regardless of the number of subscribers in either category, and assuming that traffic passing through queue 7 for both subscriber categories is delay-critical but not significant in terms of volume.
The SLA model (b) in Figure: SLA models guarantees that the ratio between any gold and any white subscriber is 8:1. The overall bandwidth distribution between gold and white categories, however, it depends on the number of subscribers in each category.
SLA models are a design goal and must be tested to guarantee the expected behavior. SR OS configuration allows a user to construct other models by combining concepts and parameters in other ways. The resulting behavior is subject to a specific configuration and offered load.
When alternative SLA models are configured, the following considerations apply:
If a group is used to enforce weighting between different scheduling classes, all queues attached to a specific hardware aggregate shaper must have the same scheduling class. This is because the software algorithm enforcing the hardware aggregate scheduler policy only controls the rate of the hardware aggregate shaper and not the rate of individual queues. If this recommendation is not followed, weights enforced at the group level may contradict weights enforced between queues within a single hardware aggregate shaper.
Elevation-weight and groups for any set of queues are mutually exclusive.
The hardware aggregate scheduler policy implements a congestion threshold that is used to trigger software recalculation. If the overall offered load for a specific vport is below this threshold (expressed as a percentage of the vport aggregate rate), the software recalculation of all parameters is not performed to save CPU resources because it is assumed that all offered traffic passes through.
Similarly to a port scheduler policy, a hardware aggregate rate scheduler policy supports a monitor threshold that detects congestion. The configuration and operation are identical as described in Scheduler QoS policies.
The following example hardware aggregate shaper scheduler policy describes the SLA model from Figure: SLA models (a).
Classic CLI example:
*A:SR-1s-test>config>qos>hw-agg-shap-sched-plcy# info
----------------------------------------------
max-rate percent 80.00
group "g1" create
exit
sched-class 3 group "g1" weight 1
sched-class 4 group "g1" weight 8
----------------------------------------------
*A:SR-1s-test# /configure port 1/1/1/c1/1 ethernet access egress
*A:SR-1s-test>config>port>ethernet>access>egress# info
----------------------------------------------
vport "dslam-a" create
hw-agg-shaper-scheduler-policy "trial"
exit
----------------------------------------------
MD-CLI example:
*(ex)[configure qos hw-agg-shaper-scheduler-policy "trial"]
A:admin@SR1-s# info
max-percent-rate 80.0
group "g1" { }
sched-class 3 {
group "g1"
weight 1
}
sched-class 4 {
group "g1"
weight 8
}
*(ex)[configure port 1/1/1/c1/1 ethernet access egress]
A:admin@SR1-s# info
virtual-port "dslam-a" {
hw-agg-shaper-scheduler-policy "trial"
}