Different from conventional QoS that performs queue scheduling based on interfaces, HQoS identifies different users and different services of the same user on a single interface.
Hierarchical Quality of Service (HQoS) is a technology that uses a queue scheduling mechanism to guarantee the bandwidth of multiple services of multiple users in the DiffServ model.
Traditional QoS performs 1-level traffic scheduling. The device can distinguish services on an interface but cannot identify users. Packets of the same priority are placed into the same queue on an interface and compete for the same queue resources. HQoS uses multi-level scheduling to distinguish user-specific or service-specific traffic and provide differentiated bandwidth management.
Figure 1 shows class queues (CQs) and port schedulers. NetEngine 8000 Fs not configured with HQoS have only CQs and port schedulers.
As shown in Figure 2, when HQoS is configured, a router specifies a buffer for flow queues that require hierarchical scheduling and performs a round of multi-layer scheduling for these flow queues. After that, the router puts HQoS traffic and non-HQoS traffic together into the CQ for unified scheduling.
A leaf node is used to buffer data flows of one priority for a user. Data flows of each user can be classified into one to eight priorities. Each user can use one to eight FQs. Different users cannot share FQs. A traffic shaping value can be configured for each FQ to restrict the maximum bandwidth.
FQs and CQs share the following configurable attributes:
Transit node: subscriber queue
An SQ indicates a user (for example, a VLAN, LSP, or PVC). You can configure the CIR and PIR for each SQ.
Each SQ corresponds to eight FQ priorities, and one to eight FQs can be configured. If an FQ is idle, other FQs can consume the bandwidth of the FQ, but the bandwidth that can be used by an FQ cannot exceed the PIR of the FQ.
An SQ functions as both a scheduler and a virtual queue to be scheduled.
To simplify operation, you can define multiple users as a GQ, which is similar to a BGP peer group that comprises multiple BGP peers. For example, all users that require the same bandwidth or all premium users can be configured as a GQ.
A GQ can be bound to multiple SQs, but an SQ can be bound only to one GQ.
A GQ schedules SQs. DRR is used to schedule the traffic within CIR between SQs. If any bandwidth is remaining after the first round, DRR is used to schedule the EIR traffic. The bandwidth of CIR is preferentially provided, and the burst traffic exceeded the PIR is dropped. Therefore, if the bandwidth of a GQ reaches the PIR, the CIR of each SQ in the GQ can be guaranteed, and the maximum bandwidth that each SQ can obtain is its own PIR.
In addition, a GQ, as a root node, can be configured with a PIR attribute to restrict the sum rate of multiple member users of the GQ. All users in this GQ are restricted by the PIR. The PIR of a GQ is used for rate limit but does not provide bandwidth guarantee. The PIR of a GQ is recommended to be greater than the sum of CIRs of all its member SQs. Otherwise, a user (SQ) cannot obtain sufficient bandwidth.
The following example illustrates the relationship between an FQ, SQ, and GQ.
In an example, 20 residential users live in a building. Each residential user purchases the bandwidth of 20 Mbit/s. To guarantee the bandwidth, an SQ with both the CIR and PIR of 20 Mbit/s is created for each residential user. The PIR here also restricts the maximum bandwidth for each residential user. With the subscription of VoIP and IPTV services as well as the HSI services, carriers promote a new bandwidth package with the value-added services (including VoIP and IPTV) added but the bandwidth 20 Mbit/s unchanged. Each residential user can use VoIP, IPTV, and HSI services.
To meet such bandwidth requirements, HQoS is configured as follows:
The hierarchy model is as follows:
FQs enable bandwidth allocation among services. SQs distinguish each user. GQs enable the CIR of each user to be guaranteed and all member users to share the bandwidth.
The bandwidth exceeds the CIR is not guaranteed because it is not paid by users. The CIR must be guaranteed because the CIR has been purchased by users. As shown in Figure 2, the CIR of users is marked, and the bandwidth is preferentially allocated to guarantee the CIR. Therefore, the bandwidth of CIR will not be preempted by the burst traffic exceeded the service rates.
On NetEngine 8000 Fs, HQoS uses different architectures to schedule upstream or downstream queues.