15.4. High Scale QoS IOM Command Reference

This command specifies how the queues within an HSQ queue group associated with the SAP egress policy instance, egress queue group instance, or egress network queue policy instance attaches to the HSQ scheduling classes managed by the port scheduler. On the HSQ IOM, eight queues are allocated per egress SAP or subscriber SLA profile instance (SPI), or per egress (access or network) queue group instance, or per egress network port, numbered 1 through 8. The port scheduler maintains six scheduling classes numbered from 1 through 6 (6 being the highest relative priority and 1 being the lowest). The set of eight queues may also be placed into one of two local Weighted Round Robin (WRR) groups which collapse the member queues into a single scheduling class while providing a weighted fair distribution of scheduling opportunities per member. The attachment policy contains the attachment commands that map the queue IDs and WRR groups to the scheduling classes. The attachment policy also defines the mapping of the scheduling classes to the queue’s aggregate shapers low and high burst limit thresholds.

The no form of the command deletes the HS attachment policy from the system, which is only possible if the policy is not being referenced.

This command specifies which scheduling classes map to the low burst-limit threshold of the queue-level aggregate shaper. Each egress SAP or subscriber SLA profile instance (SPI), per port set of network interface queues and egress queue group template instance has an aggregate shaper that manages the maximum burst limit over a specified shaping rate. Each aggregate shaper supports two thresholds. As the scheduling rate for the set of queues increases, eventually the aggregate rate exceeds the rate limit and the aggregate burst limit starts to be consumed. If this continues, the low burst limit threshold is exceeded and the queues mapped to the scheduling classes associated with low threshold are removed from the scheduler. If the remaining aggregate rate (from the higher scheduling classes) continues to exceed the shaping rate, then the burst limit continues to be consumed and eventually the high burst limit threshold is exceeded. This causes the queues for all scheduling classes to be removed from the scheduler.

The second (high) threshold exists to allow the higher priority classes to continue to forward, thereby mitigating the effects of low priority bursts beyond the aggregate shaping rate. Typically, the higher scheduling class queues are either individually rate-limited so their aggregate allowed throughput is less than the aggregate rate or the expected aggregate unshaped traffic from the individual higher scheduling classes does not exceed the aggregate shaping rate. Determining the value of low-burst-max-class class involves anticipating the proper dividing line between the low and high scheduling classes by evaluating the forwarding behavior and SLA enforcement of each class.

By default, all scheduling classes are mapped to the low burst limit threshold. When mapping scheduling classes to the high burst limit threshold, an adequate value for the card>fp>egress>hs-fixed-high-thresh-delta must be specified. This is due to the fact that the queues associated with the lower classes may burst over the lower threshold in normal operation due to the scheduler forwarding whole packets. Set the hs-fixed-highthresh- delta value to at least two times the maximum frame size to prevent lower threshold class forwarding from also affecting the higher threshold classes when forwarding larger packet sizes. An insufficient high threshold delta defeats the intended purpose of mapping classes to the higher threshold.

The system utilizes the lowest value attainable for each low threshold aggregate burst limit without causing shaper underrun conditions. The high burst limit threshold is determined by adding the hs-fixed-high-thresh-delta value configured in the config>card>fp>egress CLI context to the aggregate’s low burst limit threshold value.

The low-burst-max-class value can be changed at any time in the HS attachment policy. Modifying the setting causes all queue aggregate shapers to reconfigure the scheduling class mappings to the low and high burst limit thresholds to reflect the new value for scheduling class ID.

Scheduling Classes — As described in the queue and wrr-group attachment commands, each queue is either directly or indirectly (through a WRR group) mapped to a scheduling class. Each scheduling class has an inherent priority at the port scheduler. The inherent descending priority is as follows:

Placing scheduling classes into the port level WRR group causes those classes to compete for scheduling opportunities based on their associated weights instead of inherent priority. If higher weights are given to higher scheduling class IDs, then the relative proportional scheduling priority may continue to exhibit the priority level indicated by the class ID.

Setting Low and High Burst Limit Threshold Association — Table 121 demonstrates the effect of the low-burst-max-class command parameters on scheduling class mappings to the low and high burst limit thresholds.

The no form of the command restores the queue aggregate low burst limit threshold maximum scheduling class mapping to the default value. This causes all sets of queues associated with the specified hs-attachment-policy policy-name to have all scheduling classes mapped to the low burst limit threshold.

This command defines how the specified queue-id is attached to the scheduler. A queue may have one of four attachment states:

The following items are rules for attachment:

When an hs-attachment-policy is initially created, all queues and both WRR groups default to the unattached state. Each queue and WRR group attachment state must be explicitly configured.

The no form of the command reverts to the default unattached attachment state for queue ID. The command fails if the specified queue-id is currently in a WRR group and removing the queue from that group causes the queue IDs for that group to become discontinuous.

This command defines how the specified group ID is attached to the scheduler. A WRR group may have one of two attachment states:

A WRR group provides a weighted scheduling context for its member queues, collapsing the queues into a single scheduling class.

The following WRR membership restrictions apply:

The queue queue-id attachment command is used to define WRR group membership.

The no form of the command reverts to the default unattached attachment state for the group ID.

This command enables the context to create HS pool policy parameters. The policy can be assigned to an egress forwarding plane of an HSQ IOM. The policy contains the required parameters to create and size root and mid-tier buffer pools on an HSQ IOM, and apply a slope policy to each. The HS pool policy can be applied using the hs-pool-policy command within the config>card>fp fp-number egress context.

The system supports 63 HS pool policies including the default HS pool policy.

The no form of the command removes the HS pool policy from the system. If the HS pool policy is currently associated with a forwarding plane, the command fails.

This command enables the context to configure HS pool policy parameters. Within the mid-tier context, mid-pools can be associated with a root pool, sized as a percentage of the root pool, have an HS slope policy applied, or be configured with a port bandwidth oversubscription factor parameter used to influence the port-class pool sizes associated with the mid-tier pool.

This command enables the context to configure mid-pool tier parameters for an HS pool policy. Parameters allow for allocating the percentage of the root pool size, defining a mid-tier pool’s root-pool parent, specifying the port bandwidth oversubscription factor, or specifying a slope policy for the specific mid-tier pool.

The no form of the command reverts the parent root pool association to root-pool 1, reverts to the default allocation-percentage value, the default port-bw-oversub-factor, and default slope-policy to the specified mid-pool.

This command sizes the associated mid-pool based on the specified percent of the parent pool. The size is obtained by applying the specified percentage value to the current root-pool size acting as the mid-pool’s parent. Whenever the parent root-pool is changed to a new root-pool or the size of the current parent root-pool is modified, the mid-pool’s size is updated.

The no form of the command reverts to the default.

This command creates a buffer allocation mapping between the associated mid-pool mid-pool-id and the specified parent-root-pool root-pool-id. The specified root pool ID must have a non-zero allocation-weight or the command fails. After a mid-pool is successfully associated with a root-pool, the parent root-pool’s allocation-weight value cannot be set to zero.

When the root-pool-id is set to none, no buffers are assigned to the mid-tier pool.

The no form of the command reverts to the default.

This command modifies the size of the mid-pool when calculating the port-class pool sizes based on port bandwidth ratios. The command does not actually change the size of the mid-pool, only the size reported to the port-class pool sizing function.

Port-class pools can be sized in one of two ways: dynamically (proportionate to the bandwidth of each port) or explicitly (based on a percentage of the parent mid-pool). Explicit percentages require careful determination of the amount to give each pool. The dynamic sizing function attempts to automatically size each pool based on the relative amount of bandwidth each port-class pool is supporting compared to other port’s port-class pools. This is accomplished by determining a dynamic weight for each port with port-class pools mapped to a given mid-pool. As true with any weighted behavior, the mid-pool buffer allocation resource is distributed in a non-oversubscribed manner to its child port-class pools. The port-bw-oversub-factor oversubscription-factor allows this distribution mechanism to become proportionally oversubscribed based on the defined factor. An oversubscription-factor of 1.5 causes the port-class pool dynamic sizes to be 1.5 times bigger, allowing for a potentially more efficient utilization of the buffers represented by mid-pool.

The port-bw-oversub-factor oversubscription-factor for a mid-pool can be modified at any time, causing the corresponding port-class pool dynamic sizes to be recalculated.

A similar behavior can be obtained by increasing the mid-pool’s allocation-percent of its parent root-pool. However, the major difference in using port-bw-oversub-factor is that it provides larger port-class pools without allowing the mid-pool to use a higher number of buffers in the root pool.

The no form of the command reverts to the default.

This command specifies the slope policy to be used to define the high, low, and exceed slopes within the pool. The slope (high, low, or exceed) used on the egress queue for the packet that generated the buffer request is also used in the mid-pool from the applied slope policy. The pool’s current allocation amount is applied to the appropriate slope to derive the buffer rejection probability. The probability value is compared to a randomly-generated number. If the probability decision generates a rejection decision or the buffer pool has no remaining free buffers, the buffer request fails and the arriving packet is discarded. Otherwise, a buffer is allocated as long as the port-class and root-tier buffer pools also honor the buffer request.

The no form of the command restores the default slope policy to the associated pool.

This command enables the context to configure root pool parameters. Within the root-tier context, root pools can be sized using the allocation-weight command or a slope policy can be associated with a root pool.

This command enables the context to configure root tier parameters. Within the root-tier context, root pools can be sized using the allocation-weight command or a slope policy can be associated with a root pool.

The no form of the command restores the default allocation-weight value and default slope policy to the specified root pool. Root pool 1 has a different default weight than root pools 2 through 16. The no root-pool command fails for root pools 2 through 16 if the root pool is currently the parent of a mid-tier pool.

This command specifies the weight that is applied to the root pool and is divided by the sum of all root pool weights to derive the pool’s buffer allocation factor. The amount of buffers remaining after the system-reserve percentage is applied is multiplied by the buffer allocation factor to derive the pool size.

Root pools function as an oversubscription control mechanism. A root pool acts as the root of a hierarchy of buffer pools and queues with respect to buffer allocation. Because the sum of the root pool sizes does not exceed the total number of buffers available, the number of buffers indicated by the root pools size is always be available to the queues within the root pools hierarchy, queues from one hierarchy can never steal buffers from another.

A root pool hierarchy is based on the dynamic parenting of one or more mid-tier pools to a root pool. A mid-tier pool represents the buffering allowed for all port-class pools mapped to the mid-tier pool. Each mid-tier pool is sized as a percentage of the root pool to which it is parented. The sum of the mid-tier pools percentages for a root pool may be greater than 100 percent, which allows the root pool to be oversubscribed. This can be beneficial when large fluctuations in mid-tier buffer utilization are expected and a given mid-tier pool should be allowed to exceed its fair share of buffering.

Through the mapping hierarchy presented above, each queue is mapped to a port-class pool, mid-tier pool, and root pool.

A root pool with an allocation-weight set to “0” is considered inactive and is not allocated buffers. Mid-tier pools cannot be parented to a root pool with a weight set to “0”. After a mid-tier pool is associated with a root pool, the root pool’s weight cannot be set to “0”.

As port classes are mapped to mid-tier pools in a different policy than mid-tier pools are mapped to root pools, a port-class pool can be mapped to a mid-tier pool that is not parented to a root pool. A queue mapped indirectly to a non-parented mid-tier pool has its operational MBS value set to zero and drops all incoming packets.

When a root pool’s allocation weight is modified, all root pools, mid-tier pools, and port class pool sizes are reevaluated and modified when necessary.

The no form of the command restores the default allocation-weight value to the associated root pool. Root pool 1 has a different default weight than root pools 2 through 8. The no allocation-weight command fails for root pools 2 through 8 if the root pool is currently parented to a class pool.

This command defines the amount of HSQ IOM buffers that is set aside for internal system use. By default, 5% of the total buffer space is reserved for system internal queues. The command is provided for the case where the reserved buffer space is either insufficient or excessive. Exercise care when modifying this value.

When the system reserve value is changed, all the provisioned port-class, mid-tier, and root pool sizes are reevaluated and possibly changed.

Use the show hs-pools card-slot-number fp forwarding-plane egress command to display the current buffer allocation and buffer usage conditions on an HSQ IOM.

The no form of the command reverts to the default system reserve value.

This command creates an HS port buffer pool policy. The policy can be assigned to an egress port on an HSQ IOM. The policy contains the required commands to define and size port-class buffer pools on an HSQ IOM. The policy can be applied using the hs-port-pool-policy command within the config>port>ethernet>egress context.

SR OS supports 2047 HS port pool policies including the default HS port pool policy.

HSQ IOM port buffer pools provide buffer control for queues based on the queue’s scheduling class. Two sets of scheduling class pools exist per port: a standard (or default) set and an alternative set. The SAP egress policy, network queue policy, and egress queue group template have a parameter (alt-port-class-pool) that specifies that the queues created by the policy or template uses the alternate port-class pools, as opposed to the default standard port-class pools. Each set has six pools, one for each scheduling class. Based on the alt-port-class-pool setting and the queue’s scheduling class (based on the HS attachment policy configuration), each queue is mapped to a specific port-class pool.

The HS port pool policy defines how each of these pools are parented (mapped) to an FP level mid-pool and how each pool is sized.

The system allows two separate mechanisms to size each port-class pool:

Dynamic Port-Class Pool Sizing — Dynamic port-class pool sizing is a mechanism that provides a fair share of a mid-pool’s size to each of the port-class pools based on the potential bandwidth represented by each port. To understand port-class pool sizing, consider the following:

Explicit Port-Class Pool Sizing — The port-class pool’s allocation explicit-percent percent-of-parent-pool command is used to override the dynamic pool sizing mechanism for a given mid-pool. The specified percentage value is applied to the port-class’s parent mid-pool’s size to derive the port-class pool size.

Explicit and Dynamic Sizing from the Same Mid-Pool Parent — If explicit and dynamic pool sizing are used simultaneously for port-class pools parented to the same mid-pool, unexpected contention or underutilization of the mid-pool’s available buffers may result. While this is not a proscribed condition, it is expected most instances of dual-sizing mechanisms are transitory, based on moving between the two mechanisms.

Port-Class Pool Slope Policy Association — The HS port pool policy also provides the ability to specify a slope policy on each port-class pool. The slope policy is used to define the high, low, and exceed slope parameters used to manage contention within the port-class pool.

Default HS Port Pool Policy — An HS port pool policy with the name default always exists on the system and does not need to be created. The default port pool policy cannot be changed and is used by all HSQ IOMs within the system unless an explicitly created hs-port-pool-policy is associated with an HSQ egress port.

The default policy contains the following parameters:

Standard Port-Class Pools

Port-Class-Pool 1

Parent: Mid-Pool 1

Port-Class-Pool 2

Parent: Mid-Pool 2

Port-Class-Pool 3

Parent: Mid-Pool 3

Port-Class-Pool 4

Parent: Mid-Pool 4

Port-Class-Pool 5

Parent: Mid-Pool 5

Port-Class-Pool 6

Parent: Mid-Pool 6

Port-Class-Pool 1 to 6

Port-Bw-Weight: 1

Slope-Policy: _tmnx_hs_default

Alternate Port-Class Pools

Port-Class-Pool 1 to 6

Parent: None

Port-Bw-Weight: 1

Slope-Policy: _tmnx_hs_default

This command enables the context to configure alternate port class pools parameters. Within this context, the corresponding port-class pools can be associated with a mid-pool, explicitly sized as a percentage of the mid-pool size, dynamically sized based on relative port bandwidth, or have a slope policy applied.

This command enables the context to configure a class pool's parent mid-pool, dynamic port bandwidth weight, explicit percentage of mid-pool size, or a slope policy. Six alternate port-class pools always exist (one for each of the six scheduling classes) and do not need to be created.

The no form of the command restores the default parent-mid-pool association to mid-pool none, restores the default allocation port-bw-weight 1 setting (explicit-percent disabled), and restores the default slope policy to the specified class-pool.

This command sizes the associated class-pool based on either the specified explicit-percent percent-of-parent-pool or based on the dynamic port bandwidth portioning mechanism. Setting an explicit percentage prevents the port-class pool from participating in the dynamic port level bandwidth-based distribution of the mid-pool’s size as the port bandwidth weight of the port-class pool becomes zero (0). Setting a port bandwidth weight causes the explicit percent value to become zero (0) disabling explicit sizing of the port-class pool.

The no form of the command sets the percent-of-parent-pool value to zero (0) and the pool-weight parameter to 1 for the port-class pool, restoring the default settings.

This command creates the buffer allocation mapping between the associated class pool and the specified mid-pool. Use care when selecting a mid-pool in an active state (properly mapped to a root-pool with a non-zero allocation percentage). If a port-class pool is parented by an inactive mid-pool, the queues using the port-class pool are forced into an operational MBS setting of 0, causing all packet to be discarded. A port-class pool can be made inactive (no available buffers) by executing parent-mid-pool none in the port-class pool context.

The no form of the command reverts to the class-pool parenting value. For the standard port-class pools, this default is 1. For alternate port-class pools the default is none.

This command specifies the slope policy that is used to define the high, low, and exceed slopes within the port-class pool. The slope used on the egress queue for the packet that generated the buffer request is also used in the class-pool. The pool’s current allocation amount is applied to the appropriate slope to derive the buffer rejection probability. The probability value is compared to a randomly generated number. If the probability decision generates a rejection or the buffer pool has no remaining free buffers, the buffer request fails and the arriving packet is discarded. Otherwise, a buffer is allocated as long as the mid-tier and root-tier buffer pools also honor the buffer request.

The no form of the command restores the default slope policy to the associated class-pool.

This command enables the context to configure standard port-class pools parameters. Within this context, the corresponding port-class pools can be associated with a mid-pool, explicitly sized as a percentage of the mid-pool size, dynamically-sized based on relative port bandwidth, or have a slope policy applied.

This command enables the context to configure class pool's parent mid-pool, dynamic port bandwidth weight, explicit percentage of mid-pool size, or a slope policy. Six alternate port-class pools always exist (one for each of the six scheduling classes) and do not need to be created.

The no form of the command restores the default parent-mid-pool association to mid-pool 1, restores the default allocation port-bw-weight 1 setting (explicit-percent disabled), and restore the default slope policy to the specified class-pool.

This command configures an HS scheduler policy. The HS scheduler policies are applied to egress HSQ ports in the config>port>ethernet>egress context. The policy contains the required commands to provision the scheduling behavior of the HSQ scheduler classes. When assigned to an HSQ egress port, the policy is used to define the scheduling behavior for all queues associated with the egress port. The values defined in the policy can be overridden on each scheduler instance using the config>port>ethernet>egress>hs-scheduler-overrides command.

HSQ Queue Groups — A fundamental concept on an HSQ IOM is the queue group. Queue groups are not directly managed by the provisioning. Instead, they are indirectly assigned when creating SAPs or subscribers on an HSQ port. A queue group has eight queue members, numbered from 1 through 8. When creating a SAP or subscriber associated on an HSQ egress port, a queue group is allocated to the object. Within the SAP egress policy, network queue policy and egress queue group template, provisioned queue IDs 1 through 8 correspond directly to queue group queue IDs 1 through 8. Each group also allows each queue to be dynamically placed in a scheduling class or on one of two WRR groups local to the queue group.

Each queue within the group has three RED slopes (managed by associating a slope policy to the queue), an MBS defined in bytes, a packet byte offset parameter used to add or subtract bytes to or from each packet handled by the queue for accounting purposes, and a PIR shaper used to rate limit the queue. An HSQ attachment policy associated with the queue group defines how each queue maps either directly to a scheduling class or one of the WRR groups within the queue group. The attachment policy also defines the scheduling class attachments for the WRR groups.

The queue group supports an aggregate shaper used to manage an aggregate rate limit for all queues within the group. Scheduling for queues within the queue group is stopped and started based on the rate set on the shaper.

Scheduling Classes and Scheduling Priorities — HSQ supports six scheduler classes (1 through 6). The scheduler class should not be confused with a QoS policy forwarding class. Forwarding classes within the system are used between the ingress and egress forwarding complexes and help the system to map a packet to per-hop and per-domain behavior. Scheduling classes are slices of scheduling opportunity within a port-scheduling context. Each port scheduler maintains six strict priority levels, where 6 is the highest priority and 1 is the lowest. As a rule, the scheduler services all active queues associated with priority level 6 before moving to queues on priority level 5. This strict behavior continues through priority level 1. Scheduling classes are mapped either to their corresponding scheduling priority level (scheduling class 1 mapped to priority level 1 through scheduling class 6 mapped to priority level 6) or to a single port level WRR group. The WRR group allows collapsing up to 6 of the scheduling classes into a single scheduling priority. The WRR group provides a weighted fair scheduling behavior for its member scheduling classes at that strict priority level.

Strict Priority Level PIR — The scheduler supports a strict scheduling level PIR that limits the amount of bandwidth allowed for the level. The rate is defined in increments of megabits per second and can be set to max (the default setting) which disables the shaping function. The scheduler includes the full Ethernet frame encapsulation overhead when updating the priority level PIR, including the 12-byte inter-frame gap and the 8-byte preamble.

Scheduler Maximum Rate — A maximum scheduling rate can be defined for the scheduler. The rate is specified in megabits per second and the default rate is max which allows the scheduler to operate without a set limit. When the HS scheduling policy is applied to an egress port, the maximum scheduling rate can be used to define a rate less than the available line rate of the port. The scheduler includes the full Ethernet frame encapsulation overhead when updating the scheduler level PIR, including the 12-byte inter-frame gap and the 8-byte preamble.

HS Scheduler Policy Overrides — After an HS scheduler is applied to an egress port, the various parameters can be overridden, allowing an HS scheduler policy to be adapted to changing needs on a port without requiring a new policy to be created.

Default HS Scheduling Policy — An HS scheduling policy with the name default always exists on the system and does not need to be created. The default policy cannot be modified or deleted.

The default policy contains the following parameters:

This command defines the maximum rate allowed for the scheduling classes mapped to the specified group-id. A group is a scheduling component used to combine up to six consecutive scheduling classes into a single strict priority level. Each scheduling class within the group has an associated weight. When the scheduler is servicing the strict level associated with the group, the ratio of bandwidth allocated to each scheduling class within the group during congestion is relative to the ratio of the weight of each active member.

The no form of the command reverts to the default.

This command defines an explicit maximum frame-based bandwidth limit for the HS scheduler policy scheduler context. If a maximum rate is defined that is smaller than the port rate, the port is rate-limited to the configured megabits per second value. This command can be executed at any time for any non-default existing HS scheduler policy.

The no form of the command removes an explicit rate value from the HS scheduler policy. After the explicit rate value is removed, all instances of the scheduler policy on HSQ egress ports are allowed to run at the available line rate unless the instance has a max rate override in place.

This command configures the behavior of a specific scheduling class on all HSQ schedulers associated with the policy. The scheduler-class command performs one of two operations: it configures a maximum rate for the scheduling class or places the scheduling class into the weighted scheduling group. The two operations are mutually exclusive.

By default, none of the scheduling classes are members of the weighted scheduling group and each class is set to a rate limit of max (no rate limit applied).

Specifying Scheduling Class Rate (or Removing the Scheduling Class from Group) — If the scheduling-class command is executed with the rate keyword specified, either max or a specified rate value must follow. If a class-id was previously mapped into the weighted scheduling group, the class is removed from the group. However, if removing the class from the group causes the group to no longer have contiguous class members, the command fails with no effect on the specified class. A “non-contiguous grouping error” is returned. The lowest or highest members within a weighted group must be removed prior to removing the middle members. For example, if scheduling classes 3, 4, and 5 were members of weighted group 1, class 4 cannot be removed first.

This command using the rate keyword also fails when an override for the group weight is in place on the scheduling class within a scheduler associated with the policy. The override expects the class to be associated with a weighted scheduling group and the policy rate definition is attempting to remove the class from the group. An “override mismatch” error is generated, specifying the scheduling object where the override exists.

After a rate has been successfully defined for a scheduling class, the specified rate is automatically updated on all HSQ scheduler instances associated with the scheduling policy. The exception is where the scheduler instance has a local override for the rate on the scheduling class.

Specifying Scheduling Class Weighted Group Membership — If the scheduling-class command is executed with the group keyword specified, the group ID value of 1 must follow. The corresponding optional weight keyword is used to specify the weight of the scheduling class within the group. If weight is not specified, the default weight of 1 is used. If the specified scheduling class is not contiguous with the other scheduling classes in the group, the command fails with no change to the current state of the scheduling class and a “non-contiguous grouping” error is returned, specifying the weighted scheduling group and the current group members.

The scheduling-class command fails using the group keyword when a rate override for the scheduling class exists on an HSQ scheduler instance associated with the policy. The rate override for the scheduling class indicates the class is directly attached to a strict priority level, conflicting with the policy group keyword trying to place the class in the specified group. The command fails without affecting the scheduling class definition on the policy and returns an error specifying the scheduling object where the override exists.

Other Override Constraints — The scheduling overrides cannot change or remove a scheduling class from a policy-defined weighted group membership.

The no form of the command returns the scheduling class represented by class-id to the default behavior. The default behavior for a scheduling class is to not be a member of the weighted scheduling class group and have a rate set to max. The no scheduling-class command fails if the scheduling class is currently a member of the weighted scheduling class group and a weight override is in effect on a scheduling object for the class, in which case an error is returned.

This command associates an existing HS attachment policy with the network queue QoS policy. The HS attachment policy controls how the network queues are attached to scheduler classes or WRR groups, and how WRR groups are attached to the scheduler classes. It also defines the mapping of the scheduling classes to the queues' aggregate shaper's low and high burst limit thresholds.

Only one HS attachment policy can be associated with a network queue policy.

The no form of the command removes the policy name from the configuration and reapplies the default HS attachment policy.

This command enables the context to configure HS WRR group information in the network queue policy. This command provisions the rate and class weight of each of the two WRR scheduling groups that can be utilized by the egress queue-group instance HSQ queues.

The no form of the command reverts the HS WRR group parameters to their default values.

This command specifies how the system should resolve differences between the specified scheduling limit derived from the WRR group’s rate command and the actual operational rate obtainable in hardware. The min, max, and closest mutually exclusive keywords specify whether the next highest rate, next lowest rate, or closest rate should be selected by the system.

The no form of the command reverts to the default value.

This command specifies the class weight of this WRR group at its parent primary shaper, relative to the other queues and WRR groups in different HSQ queue groups in the same scheduling class. This allows the capacity available at the primary shaper scheduling class to be shared in a WRR manner between the HSQ queue group queues and WRR groups attached to that scheduling class. The hs-class-weight weight can be used to give unequal shares of the available capacity to different types of service offerings.

The no form of the command reverts to weight to the default value.

This command specifies the scheduling rate applied to the HS WRR group as a percentage of the port rate, which includes both the egress-rate and HS scheduler policy max-rate, if configured.

The no form of the command reverts to the default.

This command specifies that the HSQ queue group queues use buffers from the HS alternate port class buffer pool.

The no form of the command reverts to the HSQ queue group queues using buffers from HS standard port class pools.

This command specifies the class weight of this queue at its parent primary shaper, relative to the other queues and WRR groups in different HSQ queue groups in the same scheduling class. This allows the capacity available at the primary shaper scheduling class to be shared in a WRR manner between the HSQ queue group queues and WRR groups attached to that scheduling class. The hs-class-weight weight parameter can be used to give unequal shares of the available capacity to different types of service offerings. This command is ignored for egress HSQ queue group queues that are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the hs-class-weight is performed under the hs-wrr-group within the network queue policy.

The no form of the command reverts to the default value.

This command configures the queue size of an HSQ queue group network queue. Its value is calculated based on the specified percentage of one second of the queue PIR converted to bytes (the regular mbs parameter is ignored in the network queue policy).

The no form of the command reverts to the default value.

This command reverts the slope policy applied to the HSQ queue group queue to the default policy. Specifying an existing slope policy applies the named slope policy to the queue.

The no form of the command reverts to the default slope policy.

This command specifies the WRR relative weight, with which this queue should parent into an HSQ WRR group defined within the associated HS attachment policy. The weight of each queue determines how much bandwidth that queue gets out of the total rate for the HSQ WRR group.

The no form of the command reverts to the default value.

This command associates an existing HS attachment policy with the SAP egress QoS policy. The HS attachment policy controls how the SAP egress queues are attached to scheduler classes or WRR groups, and how WRR groups are attached to the scheduler classes. It also defines the mapping of the scheduling classes to the queues' aggregate shaper's low and high burst limit thresholds.

Only one HS attachment policy can be associated with a SAP egress policy.

The no form of the command removes the policy name from the configuration and reapplies the default HS attachment policy.

This command enables the context to configure HS WRR group information in the SAP egress QoS policy. The hs-wrr-group command is used to provision the rate and class weight of each of the two WRR scheduling groups that can be utilized by the SAP egress HSQ queues.

The no form of the command resets the HS WRR group parameters to their default values.

This command specifies how the system resolves differences between the specified scheduling limit derived from the WRR group’s rate command and the actual operational rate obtainable in hardware. The mutually exclusive min, max, and closest keywords specify whether the next highest rate, next lowest, or closest rate should be selected by the system.

The no form of the command reverts to the default value.

This command specifies the class weight of this WRR group at its parent primary shaper, relative to the other queues and WRR groups in different HSQ queue groups in the same scheduling class. This allows the capacity available at the primary shaper scheduling class to be shared in a WRR manner between the HSQ queue group queues and WRR groups attached to that scheduling class. The hs-class-weight parameter can be used to give unequal shares of the available capacity to different types of service offerings.

The no form of the command reverts the weight to the default value.

This command specifies the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress rate and port's HS scheduler policy max-rate, if configured. The percent-rate and rate commands are mutually exclusive.

The no form of the command reverts to the rate max.

This command specifies the scheduling rate applied to the HS WRR group in kb/s. Alternatively, the keyword max can be specified, which removes the bandwidth limitation on the HS WRR group. The rate and percent-rate commands are mutually exclusive.

The no form of the command reverts to the default value.

This command specifies that the HSQ queue group queues use buffers from the HS alternate port class buffer pool.

The no form of the command reverts to the HSQ queue group queues using buffers from HS standard port class pools.

This command specifies the class weight of this queue at its parent primary shaper, relative to the other queues and WRR groups in different HSQ queue groups in the same scheduling class. This allows the capacity available at the primary shaper scheduling class to be shared in a WRR manner between the HSQ queue group queues and WRR groups attached to that scheduling class. The hs-class-weight weight parameter can be used to give unequal shares of the available capacity to different types of service offerings. This command is ignored for egress HSQ queue group queues, which are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the hs-class-weight is performed under the hs-wrr-group within the network queue policy.

The no form of the command reverts to the default value.

This command reverts the slope policy applied to the HSQ queue group queue to the default policy. Specifying an existing slope policy applies the named slope policy to the queue.

The no form of the command reverts to the default slope policy.

This command specifies the WRR relative weight, with which this queue should parent into an HSQ WRR group defined within the associated HS attachment policy. The weight of each queue determines how much bandwidth that queue gets out of the total rate for the HSQ WRR group.

The no form of the command reverts to the default value.

This command associates an existing HS attachment policy with the egress queue group template. The HS attachment policy controls how the egress queue group instance queues are attached to scheduler classes or WRR groups, and how WRR groups are attached to the scheduler classes. It also defines the mapping of the scheduling classes to the queues' aggregate shaper's low and high burst limit thresholds.

Only one HS attachment policy can be associated with an egress queue group template.

The no form of the command removes the policy name from the configuration and reapplies the default HS attachment policy.

This command enables the context to configure HS WRR group information in the egress queue group template. The hs-wrr-group command is used to provision the rate and class weight of each of the two WRR scheduling groups that can be utilized by the egress queue group instance HSQ queues.

The no form of the command resets the HS WRR group parameters to their default values.

This command specifies how the system should resolve differences between the specified scheduling limit derived from the WRR group’s rate command and the actual operational rate obtainable in hardware. The mutually exclusive min, max, and closest keywords specify whether the next highest rate, next lowest rate, or closest rate should be selected by the system.

The no form of the command reverts to the default value.

This command specifies the class weight of this WRR group at its parent primary shaper, relative to the other queues and WRR groups in different HSQ queue groups in the same scheduling class. This allows the capacity available at the primary shaper scheduling class to be shared in a WRR manner between the HSQ queue group queues and WRR groups attached to that scheduling class. The hs-class-weight parameter can be used to give unequal shares of the available capacity to different types of service offerings.

The no form of the command reverts to the default value.

This command specifies the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress-rate and port's HS scheduler policy max-rate, if configured. The percent-rate and rate commands are mutually exclusive.

The no form of the command reverts to the rate max.

This command specifies the scheduling rate applied to the HS WRR group in kb/s. Alternatively, the keyword max can be specified, which removes the bandwidth limitation on the HS WRR group. The rate and percent-rate commands are mutually exclusive.

The no form of the command reverts to the rate max.

This command specifies that the HSQ queue group queues use the class buffers from the HS alternate port class buffer pools.

The no form of the command reverts to the HSQ queue group queues using buffers from HS standard port class pools.

This command specifies the class weight of this queue at its parent primary shaper, relative to the other queues and WRR groups in different HSQ queue groups in the same scheduling class. This allows the capacity available at the primary shaper scheduling class to be shared in a WRR manner between the HSQ queue group queues and WRR groups attached to that scheduling class. The hs-class-weight parameter can be used to give unequal shares of the available capacity to different types of service offerings.

This command is ignored for egress HSQ queue group queues, which are attached to an HS WRR group within an associated HS attachment policy. In this case the configuration of the hs-class-weight is performed under the hs-wrr-group within the egress queue group template.

The no form of the command reverts to the default value.

This command reverts the slope policy applied to the HSQ queue group queue to the default policy. Specifying an existing slope policy applies the named slope policy to the queue.

The no form of the command reverts to the default slope policy.

This command specifies the WRR relative weight, with which this queue should parent into an HSQ WRR group defined within the associated HS attachment policy. The weight of each queue determines how much bandwidth that queue gets out of the total rate for the HSQ WRR group.

The no form of the command reverts to the default value.

This command copies existing QoS policy entries for a QoS policy ID to another QoS policy ID.

The copy command is a configuration-level maintenance tool used to create new policies using existing policies. It also allows bulk modifications to an existing policy with the use of the overwrite keyword.

This command shows the egress pool information relating to an HSQ IOM.

The card and fp output shows the total buffer allocation, the number of allocated buffers, the available buffer allocation, and the buffer high-water marks for the system pools and the hierarchy of user-provisioned root and mid pools on the specified card and FP. The output includes the applied slope policy and the related instantaneous slope drop probabilities (as a percentage) for the user-provisioned pools.

The port output adds the port class pool information to the above hierarchy of user-provisioned pools for the specified port. The queue information for network queues, queue group instances, SAPs, or subscribers on the specified port is included when the associated parameter is added.

This command displays the details of the HS secondary shapers configured on the specified port.

This command displays information about HS attachment policies in the system.

This command displays information about HS pool policies in the system.

This command displays information about HS port pool policies in the system.

This command displays the egress HS scheduler hierarchy for the HS scheduler policy applied to the related port. The output includes the current maximum rate and each scheduling class rate on the port. The parameters allow for the current rates for the scheduling classes for all HS secondary shapers or a specific HS secondary shaper, or for the queue rates in a specified access or network queue group instance, SAP or subscriber to be included in the output.

This command displays information about HS scheduler policies in the system.

This command re-initializes the card in the specified slot. A clear card command (without the soft) is referred to as a Hard Reset. A clear card x soft command (with the soft) is referred to as a Soft Reset.

This command clears port statistics for the specified ports.