No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE20E-S V800R010C10SPC500 Feature Description - QoS 01

This is NE20E-S V800R010C10SPC500 Feature Description - QoS
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
HQoS

HQoS

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.

Basic Scheduling Model

The scheduling model consists of two components: scheduler and scheduled object.



  • Scheduler: schedules multiple queues. The scheduler performs a specific scheduling algorithm to determine the order in which packets are forwarded. The scheduling algorithm can be Strict Priority (SP) or weight-based scheduling. The weight-based scheduling algorithms include Deficit Round Robin (DRR), Weighted Round Robin (WRR), Deficit Weighted Round Robin (WDRR), and Weighted Fair Queuing (WFQ). For details about scheduling algorithms, see Queues and Congestion Management.

    The scheduler performs one action: selecting a queue. After a queue is selected by a scheduler, the packets in the front of the queue are forwarded.

  • Scheduled object: refers to a queue. Packets are sequenced in queues in the buffer.

    Three configurable attributes are delivered to a queue:

    (1) Priority or weight

    (2) PIR

    (3) Drop policy, including tail drop and Weighted Random Early Detection (WRED)

    Packets may enter or leave a queue:

    (1) Entering a queue: The device determines whether to drop a received packet based on the drop policy. If the packet is not dropped, it enters the tail of the queue.

    (2) Leaving a queue: After a queue is selected by a scheduler, the packets in the front of the queue are shaped and then forwarded out of the queue.

Hierarchical Scheduling Model

HQoS uses a tree-shaped hierarchical scheduling model. As shown in Figure 8-18, the hierarchical scheduling model consists of three types of nodes:

  • Leaf node: is located at the bottom layer and identifies a queue. The leaf node is a scheduled object and can only be scheduled.
  • Transit node: is located at the medium layer and refers to both a scheduler and a scheduled object. When a transit node functions as a scheduled object, the transit node can be considered a virtual queue, which is only a layer in the scheduling architecture but not an actual queue that consumes buffers.
  • Root node: is located at the top layer and identifies the top-level scheduler. The root node is only a scheduler but not a scheduled object. The PIR is delivered to the root node to restrict the output bandwidth.
Figure 8-18 Hierarchical scheduling model

A scheduler can schedule multiple queues or schedulers. The scheduler can be considered a parent node, and the scheduled queue or scheduler can be considered a child node. The parent node is the traffic aggregation point of multiple child nodes.

Traffic classification rules and control parameters can be specified on each node to classify and control traffic. Traffic classification rules based on different user or service requirements can be configured on nodes at different layers. In addition, different control actions can be performed for traffic on different nodes. This ensures multi-layer/user/service traffic management.

HQoS Hierarchies

In HQoS scheduling, one-layer transit node can be used to implement three-layer scheduling architecture, or multi-layer transit nodes can be used to implement multi-layer scheduling architecture. In addition, two or more hierarchical scheduling models can be used together by mapping a packet output from a scheduling model to a leaf node in another scheduling model, as shown in Figure 8-19. This provides flexible scheduling options.

Figure 8-19 Flexible HQoS hierarchies

HQoS hierarchies supported by devices of different vendors may be different. HQoS hierarchies supported by different chips of the same vendor may also be different.

Scheduling Architecture of NE20Es

Figure 8-20 shows class queues (CQs) and port schedulers. NE20Es not configured with HQoS have only CQs and port schedulers.

Figure 8-20 Scheduling architecture without HQoS

A CQ has the following configurable attributes:

  • Queue priority and weight
  • PIR
  • Drop policy, including tail drop and WRED

As shown in Figure 8-21, 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.

Figure 8-21 HQoS scheduling

  • Leaf node: flow queue (FQ)

    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:

    • Queue priority and weight
    • PIR
    • Drop policy, including tail drop and WRED
  • 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.

    • As a scheduler: schedules multiple FQs. Priority queuing (PQ), Weighted Fair Queuing (WFQ), or low priority queuing (LPQ) applies to an FQ. The FQs with the service class EF, CS6, and CS7 use SP scheduling by default. The flow queues with the service class BE, AF1, AF2, AF3, and AF4 use WFQ scheduling by default, with the weight 10:10:10:15:15.
    • As a virtual queue to be scheduled: is allocated two attributes, CIR and PIR. Using metering, the SQ traffic is divided into two parts, the part within the CIR and the burst part within the PIR. The former part is paid by users, and the latter part is also called the excess information rate (EIR). The EIR can be calculated using this format: EIR = PIR - CIR. The EIR refers to the burst traffic rate, which can reach a maximum of PIR.
    • Root node: group queue (GQ)

      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 a GQ obtains the bandwidth of PIR, each SQ in the GQ can obtain a minimum bandwidth of CIR or even a maximum bandwidth of 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 packages 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:

    • Three FQs are configured for the three services (VoIP, IPTV, and HSI).
    • Altogether 20 SQs are configured for 20 residential users. The CIR and PIR are configured for each SQ.
    • One GQ is configured for the whole building and corresponds to 20 residential users. The sum bandwidth of the 20 residential users is actually the PIR of the GQ. Each of the 20 residential users uses services individually, but the sum bandwidth of them is restricted by the PIR of the GQ.

    The hierarchy model is as follows:

    • FQs are used to distinguish services of a user and control bandwidth allocation among services.
    • SQs are used to distinguish users and restrict the bandwidth of each user.
    • GQs are used to distinguish user groups and control the traffic rate of twenty SQs.

    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 8-21, 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 NE20Es, HQoS uses different architectures to schedule upstream or downstream queues.

HQoS Scheduling for Upstream Queues

Figure 8-22 Scheduling architecture for upstream queues

The scheduling path of upstream HQoS traffic is FQ -> SQ -> GQ, and then joins the non-HQoS traffic for the following two-layer scheduling:

  • Target Blade (TB) scheduling

    TB scheduling is also called Virtual Output Queue (VOQ) scheduling.

    On a crossroad shown in the following figure, three vehicles (car, pallet trunk, and carriage truck) come along crossing A and are bound for crossing B, C, and D respectively. If crossing B is jammed at this time, the car cannot move ahead and stays in the way of the pallet trunk and carriage truck, although crossing C and D are clear.



    If three lanes destined for crossing B, C, and D are set on crossing A, the problem is resolved.



    Switched network on a router is similar to crossing A, B, C, and D. If each board allocates queues to packets destined for different switched network module, such queues are called VOQs, which allow packets destined for different boards to pass when one board is congested.

    A device automatically specifies VOQs. Users cannot modify the attributes of VOQs.

    NOTE:

    Upstream multicast traffic has not been duplicated and does not show a destination. Therefore, multicast traffic is put into a separate VOQ.

    For unicast traffic, a VOQ is configured for a destination board.

    DRR is implemented between unicast VOQs and then between unicast and multicast VOQs.

  • Class queue (CQ) scheduling

    Four CQs, COS0 for CS7, CS6, and EF services, COS1 for AF4 and AF3 services, COS2 for AF2 and AF1 services, and COS3 for BE services, are used for upstream traffic.

    SP scheduling applies to COS0, which is preferentially scheduled. WFQ scheduling applies to COS1, COS2, and COS3, with the WFQ weight of 1, 2, and 4 respectively.

    Users cannot modify the attributes of upstream CQs and schedulers.

    Non-HQoS traffic directly enters four upstream CQs, without passing FQs. HQoS traffic passes FQs and CQs.

The process of upstream HQoS scheduling is as follows:

  1. Entering a queue: An HQoS packet enters an FQ. When a packet enters an FQ, the system checks the FQ status and determines whether to drop the packet. If the packet is not dropped, it enters the tail of the FQ.
  2. Applying for scheduling: After entering the FQ, the packet reports the queue status change to the SQ scheduler and applies for scheduling. The SQ scheduler reports the queue status change to the GQ scheduler and applies for scheduling. Therefore, the scheduling request path is FQ -> SQ -> GQ.
  3. Hierarchical scheduling: After receiving a scheduling request, a GQ scheduler selects an SQ, and the SQ selects an FQ. Therefore, the scheduling path is GQ -> SQ -> FQ.
  4. Leaving a queue: After an FQ is selected, packets in the front of the FQ leave the queue and enters the VOQ tail. The VOQ reports the queue status change to the CQ scheduler and applies for scheduling. After receiving the request, the CQ selects a VOQ. Packets in the front of the VOQ leave the queue and are sent to a switch network.

Therefore, the scheduling process is (FQ -> SQ -> GQ) + (VOQ -> CQ).

Table 8-1 Parameters for upstream scheduling
Queue/Scheduler Queue Attribute Scheduler Attribute
FQ
  • Queue priority and weight, which can be configured.
  • PIR, which can be configured. The PIR is not configured by default.
  • Drop policy, which can be configured as WRED. The drop policy is tail drop by default.
-
SQ
  • CIR, which can be configured.
  • PIR, which can be configured.
  • To be configured.
  • PQ and WFQ apply to FQs. By default, PQ applies to EF, CS6, and CS7 services; WFQ applies to BE, AF1, AF2, AF3 and AF4 services.
GQ
  • PIR, which can be configured. The PIR is used to restrict the bandwidth but does not provide any bandwidth guarantee.
  • Not to be configured.
  • 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.
VOQ
  • Not to be configured.
  • Not to be configured.
  • DRR is implemented between unicast VOQs and then between unicast and multicast VOQs.
CQ
  • Not to be configured.
  • Not to be configured.
  • SP scheduling applies to COS0, which is preferentially scheduled. Weight-based scheduling applies to COS1, COS2, and COS3, with the WFQ weight of 1, 2, and 4 respectively.

This function applies only to incoming traffic of user queues. The application scenario is the same as that of common HQoS.

This function is implemented by replacing FQ queues with CAR token buckets. The scheduling at other layers is the same as that of common HQoS. In this case, the forwarding chip notifies the eTM chip of the status of the token bucket, and then the eTM chip adds tokens and determines whether to discard or forward the packets.

HQoS Scheduling for Downstream Queues

On NE20Es, some Physical Interface Cards (PICs) are equipped with a Traffic Manager (TM) chip, which is called an egress Traffic Manager (eTM) subcard.

If the PIC is equipped with an eTM subcard, downstream scheduling is implemented on the eTM subcard. If the PIC is not equipped with an eTM subcard, downstream scheduling is implemented on the downstream TM chip. The scheduling processes vary in the two cases.

  • Downstream TM scheduling

    Figure 8-23 TM Scheduling architecture for downstream queues

    Downstream TM scheduling includes the scheduling paths FQ -> SQ -> GQ and CQ -> port. There are eight CQs for downstream traffic, CS7, CS6, EF, AF4, AF3, AF2, AF1, and BE. Users can modify the queue parameters and scheduling parameters.

    The process of downstream TM scheduling is as follows:

    1. Entering a queue: An HQoS packet enters an FQ.
    2. Applying for scheduling: The downstream scheduling application path is (FQ -> SQ -> GQ) + (GQ -> destination port).
    3. Hierarchical scheduling: The downstream scheduling path is (destination port -> CQ) + (GQ -> SQ -> FQ).
    4. Leaving a queue: After an FQ is selected, packets in the front of the FQ leave the queue and enters the CQ tail. The CQ forwards the packet to the destination port.

    Non-HQoS traffic directly enters eight downstream CQs, without passing FQs.

    Table 8-2 Parameters for downstream TM scheduling
    Queue/Scheduler Queue Attribute Scheduler Attribute
    FQ
    • Queue priority and weight, which can be configured.
    • PIR, which can be configured. The PIR is not configured by default.
    • Drop policy, which can be configured as WRED. The drop policy is tail drop by default.
    -
    SQ
    • CIR, which can be configured.
    • PIR, which can be configured.
    • To be configured.
    • PQ and WFQ apply to FQs. By default, PQ applies to EF, CS6, and CS7 services; WFQ applies to BE, AF1, AF2, AF3 and AF4 services.
    GQ
    • PIR, which can be configured. The PIR is used to restrict the bandwidth but does not provide any bandwidth guarantee.
    • Not to be configured.
    • 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.
    CQ
    • Queue priority and weight, which can be configured.
    • PIR, which can be configured. The PIR is not configured by default.
    • Drop policy, which can be configured as WRED. The drop policy is tail drop by default.
    -
    Port
    • PIR, which can be configured.
    • To be configured.
    • PQ and WFQ apply to FQs. By default, PQ applies to EF, CS6, and CS7 services; WFQ applies to BE, AF1, AF2, AF3 and AF4 services.
  • Downstream eTM scheduling

    Figure 8-24 eTM scheduling architecture for downstream queues

    Unlike downstream TM scheduling, downstream eTM scheduling is a five-level scheduling architecture. Downstream eTM scheduling uses only FQs but not CQs. In addition to the scheduling path FQ -> SQ -> GQ, a parent GQ scheduling, also called a virtual interface (VI) scheduling, is implemented.

    NOTE:
    The VI is only a name of a scheduler but not a real virtual interface. In actual applications, a VI corresponds to a sub-interface or a physical interface. The VI refers to different objects in different applications.

    The differences between downstream TM scheduling and downstream eTM scheduling are as follows:

    • Downstream TM scheduling uses two scheduling architectures. The five-level scheduling consists of two parts, (FQ -> SQ -> GQ) + (CQ -> port). HQoS traffic is scheduled in the path of FQ -> SQ -> GQ, and enters a CQ with non-HQoS traffic in the scheduling path of CQ -> port.
    • Downstream eTM, an entity queue scheduling method, uses the scheduling path of FQ -> SQ -> GQ -> VI -> port. The system sets a default SQ for eight CQs configured for non-HQoS traffic. The SQ directly participates in the port scheduling.
    Table 8-3 Parameters for downstream eTM scheduling
    Queue/Scheduler Queue Attribute Scheduler Attribute
    FQ
    • Queue priority and weight, which can be configured.
    • PIR, which can be configured. The PIR is not configured by default.
    • Drop policy, which can be configured as WRED. The drop policy is tail drop by default.
    -
    SQ
    • CIR, which can be configured.
    • PIR, which can be configured.
    • To be configured.
    • PQ and WFQ apply to FQs. By default, PQ applies to EF, CS6, and CS7 services; WFQ applies to BE, AF1, AF2, AF3 and AF4 services.
    GQ
    • PIR, which can be configured. The PIR is used to restrict the bandwidth but does not provide any bandwidth guarantee.
    • Not to be configured.
    • 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.
    Parent GQ/VI
    • PIR, which can be configured. The PIR is used to restrict the bandwidth but does not provide any bandwidth guarantee.
    • Different scheduling algorithms, such as DRR and WFQ, are used on different boards.
    Port
    • PIR, which can be configured.
    • To be configured.
    • PQ and WFQ apply to FQs. By default, PQ applies to EF, CS6, and CS7 services; WFQ applies to BE, AF1, AF2, AF3 and AF4 services.
  • Difference Between Downstream TM Scheduling and eTM Scheduling

    Table 8-4 Difference between downstream TM scheduling and eTM scheduling
    Difference Downstream TM Scheduling Downstream eTM Scheduling
    port-queue command This command takes effect for traffic of a specific priority on an interface. This command takes effect for traffic of a specific priority in a non-flow queue.
    GQ bandwidth share The GQ bandwidth can be shared by its member SQs on a TM chip if the same GQ profile is used. The GQ bandwidth can be shared by its member SQs only on the same interface, even if the same GQ profile is used.
    SQ bandwidth share Multiple SQs in the same GQ on different physical interfaces share the bandwidth. Multiple SQs in the same GQ on different sub-interfaces but not physical interfaces share the bandwidth.
    Trunk and member interfaces The port-queue command can be configured on a trunk interface or its member interfaces. The command configuration on a member interface takes effect preferentially and schedules all traffic on the member interface. The port-queue command can be configured on a trunk interface or its member interfaces, but the command configuration takes effect only for non-flow queues.

    Use traffic shaping as an example to illustrate the difference between downstream TM scheduling and eTM scheduling. Assume that traffic shaping is configured for port queues on an interface and for flow queues or user queues on a sub-interface.

    flow-queue FQ
      queue ef shaping 10M
    
    interface gigabitethernet1/0/0
      port-queue ef shaping 100M
    
    interface gigabitethernet1/0/0.1
      user-queue cir 50m pir 50m flow-queue FQ
    
    interface gigabitethernet1/0/0.2
       //Note: user-queue and qos-profile are not configured on gigabitethernet1/0/0.2.
    
    • For downstream TM scheduling, the traffic shaping rate configured using the port-queue command determines the sum bandwidth of both HQoS and non-HQoS traffic. Based on the preceding configuration:
      • The rate of EF traffic sent from GE 1/0/0.1 does not exceed 10 Mbit/s.
      • The rate of EF traffic sent from GE 1/0/0 (including GE 1/0/0, GE 1/0/0.1, and GE 1/0/0.2) does not exceed 100 Mbit/s.
    • For downstream eTM scheduling, the traffic shaping rate configured using the port-queue command determines the sum bandwidth of non-HQoS traffic (default SQ bandwidth). Based on the preceding configuration:
      • The rate of EF traffic sent from GE 1/0/0 and GE 1/0/0.2 (non-HQoS traffic) does not exceed 100 Mbit/s.
      • The rate of EF traffic sent from GE 1/0/0.1 does not exceed 10 Mbit/s.
      • The rate of EF traffic sent from GE 1/0/0 can reach a maximum of 110 Mbit/s.

HQoS Scheduling Tree Split on a Trunk Interface

When traffic on a trunk interface is scheduled using HQoS based on the TM, if a trunk member interface is congested, traffic on other member interfaces is affected. After the HQoS scheduling tree on a trunk interface is split, a scheduling tree is created based on each trunk member interface. HQoS scheduling can be performed for traffic on a trunk interface based on the trunk member interfaces.

When three interfaces of one TM are added to a trunk interface, the HQoS scheduling tree of the trunk interface is as follows:

Figure 8-25 HQoS scheduling tree model of a trunk interface

When HQoS is used, HQoS needs to apply for bandwidth based on a trunk's member interfaces. Each member interface applies for a resource and performs HQoS scheduling independently.

HQoS Priority Mapping

Both upstream HQoS scheduling and downstream HQoS scheduling use two entity queues: eight FQs and four CQs for upstream scheduling, and eight FQs and eight CQs for downstream scheduling. Packets enter an FQ based on the service class. After that, packets in the front of the FQ queue leave the queue and enter a CQ based on the mapping.

The mapping from FQs to CQs can be in Uniform or Pipe mode.

  • Uniform: The system defines a fixed mapping. Upstream scheduling uses the uniform mode.
  • Pipe: Users can modify the mapping. The original priorities carried in packets will not be modified in pipe mode.

By default, in the downstream HQoS, the eight priority queues of an FQ and eight CQs are in one-to-one mapping. In the upstream HQoS, COS0 corresponds to CS7, CS6, and EF, COS1 corresponds to AF4 and AF3, COS2 corresponds to AF2 and AF1, and COS3 corresponds to BE.

Share Shaping

Share shaping, also called Flow Group Queue shaping (FGQ shaping), implements traffic shaping for a group that two or more flow queues (FQs) in a subscriber queue (SQ) constitute. This ensures that other services in the SQ can obtain bandwidths.

For example, a user has HSI, IPTV, and VoIP services, and IPTV services include IPTV unicast and multicast services. To ensure the CIR of IPTV services and prevent IPTV services from preempting the bandwidth reserved for HIS and VoIP services, you can configure four FQs, each of which is specially used for HSI, IPTV unicast, and IPTV multicast, and VoIP services. As shown in Figure 8-26, share shaping is implemented for IPTV unicast and multicast services, and then HQoS is implemented for all services.

Figure 8-26 Share shaping

Currently, a maximum of two share shaping configurations can be configured for eight FQs on each SQ, as shown by the first two modes in Figure 8-27. The third share shaping mode shown in Figure 8-27 is not available on the NE20E.

Figure 8-27 Share shaping modes not yet supported on a NE20E

Share shaping can be implemented in either of the following modes on a NE20E:

  • Mode A: Share shaping only shapes but not schedule traffic, and queues to which share shaping applies can use different scheduling algorithms.

  • Mode B: Queues to which share shaping applies must share the same scheduling algorithm. These share-shaping-capable queues are scheduled in advance, and then scheduled with other queues in the SQ as a whole. When share-shaping-capable queues are scheduled with other queues in the SQ, the highest priority of the share-shaping-capable queues becomes the priority of the share-shaping-capable queues as a whole, and the sum of weights of the share-shaping-capable queues become the weight of the share-shaping-capable queues as a whole.

Example 1: As shown in Figure 8-28, the traffic shaping rate of the BE, EF, AF1, AF2, and AF3 queues is 90 Mbit/s, and the sum bandwidth of the SQ is 100 Mbit/s. All queues use the strict priority (SP) scheduling. After share shaping is configured, the sum bandwidth of the AF1 and AF3 queues is set to 80 Mbit/s.

Figure 8-28 SP scheduling for share shaping

Assume that the PIR is ensured for the SQ. The input rate of the EF queue is 10 Mbit/s, and that of each other queue is 70 Mbit/s. Share shaping allocates bandwidths to the queues in either of the following modes:

  • Mode A: SP scheduling applies to all queues.

    • The EF queue obtains the 10 Mbit/s bandwidth, and the remaining bandwidth is 90 Mbit/s.
    • The bandwidth allocated to the AF3 queue is calculated in the following format: Min { AF3 PIR, share-shaping PIR, SQ PIR, remaining bandwidth} = Min {90 Mbit/s, 80 Mbit/s, 100 Mbit/s, 90 Mbit/s} = 80 Mbit/s. The traffic rate of the AF3 queue, however, is only 70 Mbit/s. Therefore, the AF3 queue actually obtains the 70 Mbit/s bandwidth, leaving the 20 Mbit/s bandwidth available for other queues.
    • The bandwidth allocated to the AF2 queue is calculated in the following format: Min { AF2 PIR, SQ PIR, remaining bandwidth}= Min {90 Mbit/s, 100 Mbit/s, 20 Mbit/s} = 20 Mbit/s. Therefore, the AF2 queue obtains the 20 Mbit/s bandwidth, and no bandwidth is remaining.
    • The AF1 and BE queues obtain no bandwidth.
  • Mode B: The EF is scheduled first, and then AF3 and AF1 are scheduled as a whole, and then BE is scheduled.

    • The EF queue obtains the 10 Mbit/s bandwidth, and the remaining bandwidth is 90 Mbit/s.
    • The bandwidth allocated to the AF3 queue is calculated in the following format: Min { AF3 PIR, share-shaping PIR, SQ PIR, remaining bandwidth} = Min {90 Mbit/s, 80 Mbit/s, 100 Mbit/s, 90 Mbit/s} = 80 Mbit/s. The input rate of the AF3 queue, however, is only 70 Mbit/s. Therefore, the AF3 queue actually obtains the 70 Mbit/s bandwidth, leaving the 20 Mbit/s bandwidth available for other queues.
    • The bandwidth allocated to the AF2 queue is calculated in the following format: Min { AF1 PIR, share-shaping PIR - AF3 bandwidth, SQ PIR, remaining bandwidth } = Min {90 Mbit/s, 10 Mbit/s, 20 Mbit/s} = 10 Mbit/s. Therefore, the AF1 queue obtains the 10 Mbit/s bandwidth, and the remaining bandwidth becomes 10 Mbit/s.
    • The bandwidth allocated to the AF2 queue is calculated in the following format: Min { AF2 PIR, SQ PIR, remaining bandwidth } = Min { 90 Mbit/s, 100 Mbit/s, 10 Mbit/s } = 10 Mbit/s. Therefore, the AF2 queue obtains the 10 Mbit/s bandwidth, and no bandwidth is remaining.
    • The BE queue obtains no bandwidth.

    The following table shows the bandwidth allocation results.

Queue Scheduling Algorithms Input Bandwidth (Mbit/s) PIR (Mbit/s) Output Bandwidth (Mbit/s)
Mode A Mode B
EF SP 10 90 10 10
AF3 SP 70 90 70 70
AF2 SP 70 90 20 10
AF1 SP 70 90 0 10
BE SP 70 Not configured 0 0

Example 2: Assume that the WFQ scheduling applies to the EF, AF1, AF2, and AF3 queues with the weight ratio as 1:1:1:2 (EF:AF3:AF2:AF1) in example 1. The LPQ scheduling applies to the BE queue. The PIR 100 Mbit/s is ensured for the SQ. The input rate of the EF and AF3 queues is 10 Mbit/s, and that of each other queue is 70 Mbit/s. Share shaping allocates bandwidths to the queues in either of the following modes:

  • Mode A: The WFQ scheduling applies to all queues.

    First-round WFQ scheduling:

    • The bandwidth allocated to the EF queue is calculated as follows: 1/(1 + 1 + 1 + 2) x 100 Mbit/s=20 Mbit/s. The input rate of the EF queue, however, is only 10 Mbit/s. Therefore, the remaining bandwidth is 90 Mbit/s.
    • The bandwidth allocated to the AF3 queue is calculated as follows: 1/(1 + 1 + 1 + 2) x 100 Mbit/s=20 Mbit/s. The input rate of the AF3 queue, however, is only 10 Mbit/s. Therefore, the remaining bandwidth is 80 Mbit/s.
    • The bandwidth allocated to the AF2 queue is calculated as follows: 1/(1 + 1 + 1 + 2) x 100 Mbit/s=20 Mbit/s. Therefore, the AF2 queue obtains the 20 Mbit/s bandwidth, and the remaining bandwidth becomes 60 Mbit/s.
    • The bandwidth allocated to the AF1 queue is calculated as follows: 2/(1 + 1 + 1 + 2) x 100 Mbit/s=40 Mbit/s. Therefore, the AF2 queue obtains the 40 Mbit/s bandwidth, and the remaining bandwidth becomes 20 Mbit/s.

    Second-round WFQ scheduling:

    • The bandwidth allocated to the AF2 queue is calculated as follows: 1/(1 + 2) x 20 Mbit/s = 6.7 Mbit/s.
    • The bandwidth allocated to the AF1 queue is calculated as follows: 2/(1 + 2) x 20 Mbit/s = 13.3 Mbit/s.

    No bandwidth is remaining, and the BE queue obtains no bandwidth.

  • Mode B: The AF3 and AF1 queues, as a whole, are scheduled with the EF and AF2 queues using the WFQ scheduling. The weight ratio is calculated as follows: EF:(AF3+AF1):AF2 = 1:(1+2):1 = 1:3:1.

    First-round WFQ scheduling:

    • The bandwidth allocated to the EF queue is calculated as follows: 1/(1 +3 + 1) x 100 Mbit/s=20 Mbit/s. The input rate of the EF queue, however, is only 10 Mbit/s. Therefore, the EF queue actually obtains the 10 Mbit/s bandwidth, and the remaining bandwidth is 90 Mbit/s.
    • The bandwidth allocated to the AF3 and AF1 queues, as a whole, is calculated as follows: 3/(1 + 3 + 1) x 100 Mbit/s = 60 Mbit/s. Therefore, the remaining bandwidth becomes 30 Mbit/s. The 60 Mbit/s bandwidth allocated to the AF3 and AF1 queues as a whole are further allocated to each in the ratio of 1:2. The 20 Mbit/s bandwidth is allocated to the AF3 queue. The input rate of the AF3 queue, however, is only 10 Mbit/s. Therefore, the AF3 queue actually obtains the 10 Mbit/s bandwidth, and the remaining 50 Mbit/s bandwidth is allocated to the AF1 queue.
    • The bandwidth allocated to the AF2 queue is calculated as follows: 1/(1 +3 + 1) x 100 Mbit/s=20 Mbit/s. Therefore, the AF2 queue obtains the 20 Mbit/s bandwidth, and the remaining bandwidth becomes 10 Mbit/s.

    Second-round WFQ scheduling:

    • The bandwidth allocated to the AF3 and AF1 queues as a whole is calculated as follows: 3/(3 + 1) x 10 Mbit/s=7.5 Mbit/s. The 7.5 Mbit/s bandwidth, not exceeding the share shaping bandwidth, can be all allocated to the AF3 and AF1 queues as a whole. The PIR of the AF3 queue has been ensured. Therefore, the 7.5 Mbit/s bandwidth is allocated to the AF1 queue.
    • The bandwidth allocated to the AF2 queue is calculated as follows: 1/(3 + 1 ) x 10 Mbit/s = 2.5 Mbit/s.

    No bandwidth is remaining, and the BE queue obtains no bandwidth.

    The following table shows the bandwidth allocation results.

    Queue Scheduling Algorithms Input Bandwidth (Mbit/s) PIR (Mbit/s) Output Bandwidth (Mbit/s)
    Mode A Mode B
    EF SP 10 90 10 10
    AF3 SP 70 90 10 70
    AF2 SP 70 90 26.7 22.5
    AF1 SP 70 90 53.3 57.5
    BE SP 70 Not configured 0 0

HQoS Applications and Classification

Use the following HQoS applications as examples:

  • No QoS configuration: If QoS is not configured on an outbound interface and the default configuration is used, the scheduling path is 1 port queue -> 1 VI queue -> 1 GQ -> 1 SQ -> 1 FQ. Only one queue is scheduled at each layer. Therefore, the scheduling path can be considered an FIFO queue.
  • Distinguishing only service priorities: If an outbound interface is configured only to distinguish service priorities, the scheduling path is 1 port queue -> 1 VI queue -> 1 GQ -> 1 SQ -> 8 FQs. Therefore, the scheduling path can be considered port->FQ.
  • Distinguishing service priorities + users: As shown in the following figure, an L3 gateway is connected to an RTN that has three base stations attached. To distinguish the three base stations on GE 1/0/0 of the L3 gateway and services of different priorities from the three base stations, configure the hierarchy architecture as port -> base station -> base station service, corresponding to the scheduling path: port -> 1 VI queue -> 1 GQ -> 3 SQs -> 8 FQs.



  • Distinguishing priorities + users + aggregation devices: As shown in the following figure, an L3 gateway is connected to two RTNs (aggregation devices) that each has three base stations attached. To distinguish the two RTNs on GE 1/0/0 of the L3 gateway, three base stations on each RTN, and services of different priorities on the three base stations, configure the hierarchy architecture as port -> RTN -> base station -> base station services, corresponding to the scheduling path: 1 port -> 1 VI queue -> 2 GQs -> 3 SQs -> 8 FQs.



HQoS is configured by Qos profile.

  • Class-based HQoS

    Class-based HQoS uses multi-field (MF) classification to classify packets that require HQoS scheduling and treats all packets that match the classification rule as a user.

    An SQ is configured in the traffic behavior view, then a traffic policy that defines the traffic behavior is applied to an interface.

    Class-based HQoS takes effect only for upstream queues.

    As shown in Figure 8-29, two interfaces on a router connect to RTNs, and each RTN has three base stations attached, each of which runs services of different priorities. The router, as an L3 gateway, is required to distinguish the three base stations and services of different priorities on the three base stations.

    Figure 8-29 Class-based HQoS

    You can configure class-based HQoS to meet the preceding requirements. An interface has two user groups (two RTNs), one user group has three users (three base stations), and one base station runs multiple services. The hierarchical architecture is configured as port -> RTN -> base station -> base station services, corresponding to the scheduling path: port -> GQ -> SQ ->FQ.

  • Profile-based HQoS

    Traffic that enters different interfaces can be scheduled in an SQ.

    Profile-based HQoS implements QoS scheduling management for access users by defining various QoS profiles and applying the QoS profiles to interfaces. A QoS profile is a set of QoS parameters (such as the queue bandwidth and flow queues) for a specific user queue.

    Profile-based HQoS supports upstream and downstream scheduling.

    As shown in Figure 8-30, the router, as an edge device on an ISP network, accesses a local area network (LAN) through E-Trunk 1. The LAN houses 1000 users that have VoIP, IPTV, and common Internet services. Eth-Trunk 1.1000 accesses VoIP services; Eth-Trunk 1.2000 accesses IPTV services; Eth-Trunk 1.3000 accesses other services. The 802.1p value in the outer VLAN tag is used to identify the service type (802.1p value 5 for VoIP services and 802.1p value 4 for IPTV services). The VID that ranges from 1 to 1000 in the inner VLAN tag identifies the user. The VIDs of Eth-Trunk 1.1000 and Eth-Trunk 1.2000 are respectively 1000 and 2000. It is required that the sum bandwidth of each user be restricted to 120 Mbit/s, the CIR be 100 Mbit/s, and the bandwidth allocated to VoIP and IPTV services of each user are respectively 60 Mbit/s and 40 Mbit/s. Other services are not provided with any bandwidth guarantee.

    Figure 8-30 Profile-based HQoS

    You can configure profile-based HQoS to meet the preceding requirements. Only traffic with the same inner VLAN ID enters the same SQ. Therefore, 1000 SQs are created. Traffic with the same inner VLAN ID but different outer VLAN IDs enter different FQs in the same SQ.

HQoS Implementation on a Low-speed Links Interface

Interface-based HQoS allows an interface to function as a user. It means that all packets on an interface belong to an SQ.

Interface-based HQoS supports upstream and downstream scheduling.

HQoS Scheduling for Common Users

HQoS for common users identifies services by priority and then performs uniform scheduling.

HQoS Scheduling for Family Users

A family may use multiple terminals to demand various services, such as VoIP, IPTV, and HSI. These services have different requirements for delay, jitter, and bandwidth. In addition, requirements of high-priority services must be satisfied preferentially when network resources are insufficient. QoS scheduling must be performed based on a family rather than on each separate terminal.

Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055126

Views: 7329

Downloads: 17

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next