HSMDA Command Reference

This command creates a text description stored in the configuration file for a configuration context.

The no form of this command removes any description string from the context.

This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.

The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

Services are created in the administratively down (shutdown) state. When a no shutdown command is entered, the service becomes administratively up and then tries to enter the operationally up state. Default administrative states for services and service entities is described below in Special Cases.

The no form of this command places the entity into an administratively enabled state.

This command enables the context to configure a HSMDA pool policy parameters. Each policy must be uniquely named within the system. Names of up to 32 ASCII characters are supported with the normal character restrictions. A policy must be defined prior to applying the policy name to an HSMDA entity.

The no form of the command removes the specified HSMDA pool policy from the configuration. If the HSMDA pool policy is associated with an HSMDA, the command will fail.

This class enables the context to configure class pool tier parameters. Within the class-tier context, class pools may be associated with a root pool and are sized as a percentage of the root pool’s size.

This command specifies a class pool’s root pool parent and define the buffer allocation percentage used for sizing the class pool relative to the parent pool’s size. Eight class pools exist and do not need to be created.

Class pools function as a scheduling class aggregate buffer control mechanism and define the total number of buffers a given scheduling class may consume for all ports. Each class pool must be placed in a root pool hierarchy. This is accomplished by the root-parent keyword and root-pool-id parameter. A class pool cannot be parented by a root pool that currently has an allocation-weight parameter set to 0. Once a class pool is parented by a root pool, that root pool will not allow the allocation-weight to be set to 0.

The allocation-percent keyword and associated percent-of-parent-pool parameter indirectly specifies the size of the class pool. The percent value is multiplied by the size of the root pool to derive the class pool size. If the percent value is changed, or the size of the root pool changes, the class pool and port class pools associated with the class pool must be resized. The sum percent values for the class pools associated with a root pool may exceed 100%, allowing the class pools to oversubscribe the root pool. In this case, it is possible for the class pool to indicate that buffers remain when the root pool has exhausted its available buffers.

When queues associated with the class pool’s scheduling class request buffers due to packet arrival, the port class pool, class pool and root pool must all have sufficient buffers available to place the packet into the queue. If sufficient buffers are not available, the packet will be discarded by the queue.

The no form of the command restores the default root-parent and allocation-percent value for a class pool. Based on the class pool, the restored default values may differ.

This command enables the root pool tier context of an HSMDA pool policy. Within the root-tier context, root pools may be sized by defining each root pool’s weight.

This command defines the buffer allocation weight for a specific root pool. Eight root pools exist and do not need to be created. The allocation-weight parameter is used to specify the weight that will be applied to the 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. Since the sum of the root pool sizes will not exceed the total number of buffers available, the number of buffers indicated by the root pools size will 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 a root pool to one or more class pools. A class pool represents the buffering allowed for a given scheduling class. Each class pool is sized as a percentage of the root pool to which it is parented. The sum of the class pools percentages for a root pool may be greater than 100 percent which allows the root pool to be oversubscribed. This may be beneficial when large fluctuations in class based buffer utilization are expected and a given class should be allowed to exceed its fair share of buffering.

Port queues are tied to root pools through the scheduling class of the queue (indicated by the queue-ID). A queue on scheduling class 3 will be mapped to class pool 3 and indirectly tied to the root pool associated with class pool 3.

A root pool with an allocation-weight set to 0 is considered inactive and will not be allocated buffers. Class pools cannot be parented to a root pool with a weight equal set to 0. Once a class pool is associated with a root pool, the root pool’s weight cannot be set to 0.

When a root pool’s allocation weight is modified, all root pools, class 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 a root pool. Root pool 1 has a different default weight than root pools 2 through 8. The no root-pool command will fail for root pools 2 through 8 if the root pool is currently parented to a class pool.

This command defines the amount of HSMDA buffers that will be set aside for internal system use. By default, 10% 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. Use care when modifying this value. When the system reserve value is changed, all the provisioned port class, class and root pool sizes will be re-evaluated and possibly changed.

The no form of the command restores the default system reserve value.

This command configures HSMDA scheduler policy parameters. HSMDA scheduler policies can be assigned to an egress HSMDA port or as the ingress control scheduler between the HSMDA and the ingress forwarding plane. The policy contains commands to provision the scheduling behavior of a set of HSMDA scheduler classes. When assigned to an HSMDA egress port, the policy defines the scheduling behavior for all queues associated with the egress port. When assigned to the ingress path of an ESDMA, the policy defines the scheduling behavior for all ingress queues on the HSMDA (regardless of ingress port).

Up to 1000 HSMDA scheduler policies can be configured per system

The no form of the command removes an HSMDA scheduler policy from the system. If the policy is associated with an egress port or ingress HSMDA, the command will fail.

This command defines the maximum rate allowed for the scheduling classes mapped to the specified group-id. A group is a scheduling entity used to combine up to three consecutive scheduling classes into a single strict priority level. Each scheduling class within the group has an associated weight. When the scheduler is operating at the strict level associated with the group, the ratio of bandwidth allocated to each scheduling class within the group during congestion at that strict level is relative to the ratio of the weight of each member. The bandwidth is allocated in a work conserving fashion and is sensitive to packet size up to the maximum rate defined for the group.

The no form of the command reverts the specified weighted scheduling class group rate limit to the default setting.

This command defines an explicit maximum frame-based bandwidth limit for the HSMDA scheduler policy scheduler. If a max-rate is defined that is smaller than the port rate, the port will be rate limited to the expressed megabits-per-second value. This command should be used with caution if the policy may be applied on ingress for an HSMDA as the total port ingress rate will be limited to the defined maximum rate.

This command can be executed at any time for any non-default existing HSMDA scheduler policy. When a new maximum rate is given for a policy, the system evaluates all instances of the policy to see if the configured rate is smaller than the available port bandwidth. If the rate is smaller and the maximum rate is not currently overridden on the scheduler instance, the scheduler instance is updated with the new maximum rate value.

The maximum rate value defined in the policy can be overridden on each scheduler instance. If the maximum rate is explicitly defined as an override on a port or ingress HSMDA, the policy’s max-rate value has no effect.

The no form of the command removes an explicit rate value from the HSMDA scheduler policy. Once removed, all instances of the scheduler policy on egress ports or ingress HSMDAs 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 HSMDA schedulers associated with the policy. The scheduling-class command performs one of two operations, configure a maximum rate for the scheduling class or place the scheduling class into one of the two available weighted scheduling groups. The two operations are mutually exclusive.

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

Specifying Scheduling Class Rate (or Removing Class from Group)

If the scheduling-class command is executed with the rate keyword specified, either max or a specified megabits-per-second rate must follow. If class-id had previously been mapped into one of the two weighted scheduling groups, the class will be removed. However, if removing the class from the group will cause the group to no longer have contiguous class members, the command will fail with no effect on the specified class. A non-contiguous grouping error will be returned specifying the weighted group. The lowest or highest members within a weighted group must be removed prior to removing the middle member. For example, if scheduling classes 3, 4 and 5 were members of weighted group 1, class 4 can not be removed first.

The scheduling-class command using the rate keyword will also fail in the event where an override for the group weight is in place on the scheduling class within a scheduler associated with the policy. The override command is expecting 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 will be generated specifying the scheduling object where the override exists (SAP, subscriber or ingress HSMDA).

Once a rate has been successfully defined for a scheduling class, the specified rate is automatically updated on all HSMDA 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, group-id must follow. Two weighted scheduling groups are allowed, numbered 1 and 2. Along with the group, the weight keyword is used to specify the weight the scheduling class within the group. If weight is not specified, the default weight of 1 will be used. Similar to the rate action of the command, the group version will fail if the scheduling class ID is not consecutive with the class members currently members of the weighted scheduling group. The command will have no effect on the current scheduling class settings and a non-contiguous grouping error will be returned specifying the weighted scheduling group and the current group members.

The scheduling-class command will also fail using the group keyword when a rate override for the scheduling class exists on an HSMDA 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 will fail without effecting the scheduling class definition on the policy and return an override-mismatch error specifying the scheduling object where the override exists.

The configured priority level rate limits may be overridden at the egress port or channel using the egress-scheduler-override level priority-level command. When a scheduler instance has an override defined for a priority level, both the rate and cir values are overridden even when one of them is not explicitly expressed in the override command. For instance, if the cir kilobits-per-second portion of the override is not expressed, the scheduler instance defaults to not having a CIR rate limit for the priority level even when the port scheduler policy has an explicit CIR limit defined.

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 either weighted scheduling class groups and have a rate set to max. The no form of the command will fail if the scheduling class is currently a member of one of the weighted scheduling class groups and a weight override is in effect on a scheduling object for the class. An override mismatch error will be returned specifying the scheduling object where the override exists.

This command creates an HSMDA RED slope policy. The policy may be assigned to an ingress or egress HSMDA queue. The policy contains the Maximum Buffer Size (MBS) that will be applied to the queue and the high and low priority RED slope definitions. The function of the MBS and RED slopes is to provide congestion control for an HSMDA queue. The MBS parameter defines the maximum depth a queue may reach when accepting packets. The low and high priority RED slopes provides for random early detection of congestion and slope based discards based on queue depth.

An HSMDA slope policy can be applied to queues defined in the SAP ingress and SAP egress QoS policy HSMDA queues context. Once an HSMDA slope policy is applied to a SAP QoS policy queue, it cannot be deleted. Any edits to the policy are updated to all HSMDA queues indirectly associated with the policy.

Default HSMDA Slope Policy

An HSMDA slope policy named “default” always exists on the system and does not need to be created. The default policy is automatically applied to all HSMDA queues unless another HSMDA slope policy is specified for the queue. The default policy cannot be modified or deleted. Attempting to execute the no hsmda-slope-policy default command results in an error.

The no form of the command removes the specified HSMDA slope policy from the configuration. If the HSMDA slope policy is currently associated with an HSMDA queue, the command will fail.

Table 65 displays the default slope policy parameters.

This command enables the high priority RED slope context of an HSMDA slope policy. Within the high-slope context, the high priority RED slope configuration commands defining the start of slope, end of slope and maximum probability points may be executed.

For ingress, packets classified as priority high or profile in are mapped to the high priority RED slope for queue congestion management.

At egress, packets received from ingress as in-profile are mapped to the high priority RED slope for queue congestion management. In-profile is derived at ingress either from within-CIR profiling or from explicit profile in classification.

This command defines the starting point for a slope relative to the maximum depth of the queue-mbs value of the HSMDA slope policy. At the point the slope starts, it rises from a discard probability of zero until it reaches the max-depth and max-prob points defining where the slope rises directly to a discard probability of 100%.

As packets arrive at the queue, a random number is generated that is ranged from 0 to 100% discard probability. The packet will be associated with either the high priority slope or the low priority slope. The current queue depth plots the position where the slope will be evaluated. If the random number is equal to or greater than the slope’s discard probability at the current depth, the packet is eligible to enter the queue. If the random number is less than the slope discard probability, the packet is discarded.

The defined percent-of-queue-depth value for the start-depth command is defined as a percentage of the queue-mbs value. The value defined for the start depth must be less than or equal to the current percentage value for max-depth. If the defined value is greater than max-depth, the start-depth command will fail with no change to the current value. If the max-depth value is less than the desired start-depth value, first change max-depth to a value equal to or greater than the desired start-depth.

The no form of the command restores the default start point percentage value for the slope. The low and high slopes have different default values. If the default value is greater than the current max-depth value, the no start-depth command will fail.

This command enables the low priority RED slope context of an HSMDA slope policy. Within the low-slope context, the low priority RED slope configuration commands defining the start of slope, end of slope and maximum probability points may be executed.

For ingress, packets classified as priority low or profile out are mapped to the low priority RED slope for queue congestion management.

At egress, packets received from ingress as out-of-profile are mapped to the low priority RED slope for queue congestion management. Out-of-profile is derived at ingress either from above-CIR profiling or from explicit profile out classification.

This command defines the ending queue depth point for a slope relative to the maximum depth of the queue-mbs value of the HSMDA slope policy. At the point the slope ends, it has risen from the starting queue depth value with a discard probability of zero. At max-depth, the slope will have risen to the discard probability defined by max-depth at which point the slope rises directly to a discard probability of 100%.

If the queue depth has reached the point defined by max-depth, all packets associated with the slope will be discarded.

The defined percent-of-queue-depth for max-depth is defined as a percentage of the queue-mbs value. The value defined as the maximum depth must be greater than or equal to the current percentage value for start-depth. If the defined value is less than start-depth, the max-depth command will fail with no change to the current value. If the start-depth value is greater than the desired max-depth value, first change start-depth to a value equal to or less than the desired max-depth.

The no form of the command restores the default ending point percentage value for the slope. The low and high slopes have different default values. If the default value is less than the current start-depth value, the no max-depth command will fail.

The no form of the command restores the default maximum probability percentage value for the end of the slope.

This command defines the slopes maximum probability point where the slope ends and the discard probability rises directly to 100%. Together with the max-depth command, the max-prob value defines the end of the slope.

The defined percent-of-discard-probability for max-prob is defined as a percentage of a 100% discard probability. If a value of 75% is defined, near the end of the slope close to 75% of the packets will be discarded. At the end of the slope, the discard probability rises to 100% and all packets are discarded.

This command creates an HSMDA weighed-round-robin (WRR) scheduling loop policy. The policy may be assigned to an egress HSMDA queue.

The no form of the command removes the specified HSMDA WRR policy from the configuration. If the HSMDA WRR policy is currently associated with an HSMDA queue, the command will fail.

This command includes either the first two (1 and 2) queues or the first three (1, 2, and 3) queues into the HSMDA WRR scheduling loop policy. This command defines how many queues are members of the scheduling loop.

The no form of the command removes an explicit queues from the HSMDA WRR policy.

This command specifies the scheduling class for the HSMDA WRR scheduling loop policy. This command specifies which scheduling class the scheduling loop will participate with on the system.

The no form of the command removes an explicit scheduling class value from the HSMDA WRR policy.

This command specifies the aggregate weight within the scheduling class for the HSMDA WRR scheduling loop policy.

The no form of the command removes an explicit aggregate weight value from the HSMDA WRR policy.

This command displays HSMDA pool policy information.

This command displays HSMDA pool information.

This command displays HSMDA scheduler hierarchy information.

This command displays HSMDA scheduler policy information.

This command displays HSMDA slope policy information.