Class Fair Hierarchical Policing (CFHP) Policy Command Reference

This command is used to create, delete, or modify policer control policies. The policer-control-policy controls the aggregate bandwidth available to a set of child policers. Once created, the policy can be applied to ingress or egress SAPs. The policy can also be applied to the ingress or egress context of a sub-profile.

The description command is used to define an informational ASCII string associated with the policer control policy. The string value can be defined or changed at any time once the policy exists.

The no form of this command is used to remove an explicit description string from the policer.

The root node contains the policer control policies configuration parameters for the root arbiter. Within the node, the parent policer’s maximum rate limit can be set and the strict priority level shared and fair threshold portions may be defined per priority level.

The root node always exists and does not need to be created.

The max-rate command defines the parent policer’s PIR leaky bucket’s decrement rate. A parent policer is created for each time the policer-control-policy is applied to either a SAP, or subscriber instance for the 7450 ESS and 7750 SR, or multi-service site instance for the 7950 XRS. Packets that are not discarded by the child policers associated with the SAP or subscriber or multi-service site instances are evaluated against the parent policer’s PIR leaky bucket.

For each packet, the bucket is first decremented by the correct amount based on the decrement rate to derive the current bucket depth. The current depth is then compared to one of two discard thresholds associated with the packet. The first discard threshold (discard-unfair) is applied if the FIR (Fair Information Rate) leaky bucket in the packet’s child policer is in the confirming state. The second discard threshold (discard-all) is applied if the child policer's FIR leaky bucket is in the exceed state. Only one of the two thresholds is applied per packet. If the current depth of the parent policer PIR bucket is less than the threshold value, the parent PIR bucket is in the conform state for that particular packet. If the depth is equal to or greater than the applied threshold, the bucket is in the violate state for the packet.

If the result is “conform,” the bucket depth is increased by the size of the packet (plus or minus the per-packet-offset setting in the child policer) and the packet is not discarded by the parent policer. If the result is “violate,” the bucket depth is not increased and the packet is discarded by the parent policer. When the parent policer discards a packet, any bucket depth increases (PIR, CIR and FIR) in the parent policer caused by the packet are canceled. This prevents packets that are discarded by the parent policer from consuming the child policers PIR, CIR and FIR bandwidth.

The policer-control-policy root max-rate setting may be overridden on each SAP or sub-profile where the policy is applied.

The profile-preferred option ensures that the root policer provides a preference to consume its PIR bucket tokens at a given priority level to packets that have their profile state set to in-profile by the output of the child policer CIR bucket.

The priority-mbs-thresholds command contains the root arbiter parent policer’s min-thresh-separation command and each priority level’s mbs-contribution command that is used to internally derive each priority level’s shared-portion and fair-portion values. The system uses each priority level’s shared-portion and fair-portion value to calculate each priority level’s discard-unfair and discard-all MBS thresholds that enforce priority sensitive rate-based discards within the root arbiter’s parent policer.

The priority-mbs-thresholds CLI node always exists and does not need to be created.

The min-thresh-separation command defines the minimum required separation between each in-use discard threshold maintained for each parent policer context associated with the policer-control-policy. The min-thresh-separation value may be overridden on each SAP or sub-profile to which the policy is applied.

The system uses the default or specified min-thresh-separation value in order to determine the minimum separation required between each of the of the parent policer discard thresholds. The system enforces the minimum separation based on the following behavior in two ways. The first is determining the size of the shared-portion for each priority level (when the mbs-contribution command’s optional fixed keyword is not specified):

The second function the system uses the min-thresh-separation value for is determining the value per priority level for the fair-portion:

When the mbs-contribution command’s optional fixed keyword is defined for a priority level within the policy, the system will treat the defined mbs-contribution value as an explicit definition of the priority level’s MBS. While the system will continue to track child policer associations with the parent policer priority levels, the association counters will have no effect. Instead the following rules will be used to determine a fixed priority level’s shared-portion and fair-portion:

min-thresh-separation value

mbs-contribution value less min-thresh-separation value

Each time the min-thresh-separation value is modified, the thresholds for all instances of the parent policer created through association with this policer-control-policy are reevaluated

Determining the Correct Value for the Minimum Threshold Separation Value

The minimum value for min-thresh-separation should be set equal to the maximum size packet that will be handled by the parent policer. This ensures that when a lower priority packet is incrementing the bucket, the size of the increment will not cause the bucket's depth to equal or exceed a higher priority threshold. It also ensures that an unfair packet within a priority level cannot cause the PIR bucket to increment to the discard-all threshold within the priority.

When evaluating maximum packet size, each child policer’s per-packet-offset setting should be taken into consideration. If the maximum size packet is 1518 bytes and a per-packet-offset parameter is configured to add 20 bytes per packet, min-thresh-separation should be set to 1538 due to the fact that the parent policer will increment its PIR bucket using the extra 20 bytes.

In most circumstances, a value larger than the maximum packet size is not necessary. Management of priority level aggregate burst tolerance is intended to be implemented using the priority level mbs-contribution command. Setting a value larger than the maximum packet size will not adversely affect the policer performance, but it may increase the aggregate burst tolerance for each priority level.

Note: A priority level’s shared-portion of the parent policer’s PIR bucket depth is only necessary to provide some separation between a lower priority’s discard-all threshold and this priority’s discard-unfair threshold. It is expected that the burst tolerance for the unfair packets is relatively minimal since the child policers feeding the parent policer priority level all have some amount of fair burst before entering into an FIR exceed or unfair state. The fair burst amount for a priority level is defined using the mbs-contribution command.

The no form of this command returns the policy’s min-thresh-separation value to the default value.

The priority level command contains the mbs-contribution configuration command for a given strict priority level. Eight levels are supported numbered 1 through 8 with 8 being the highest strict priority.

Each of the eight priority CLI nodes always exists and do not need to be created. While parameters exist for each priority level, the parameters are only applied when the priority level within a parent policer instance is currently supporting child policers.

The mbs-contribution command is used to configure the policy-based burst tolerance for a parent policer instance created when the policy is applied to a SAP, or a subscriber context for the 7450 ESS and 7750 SR, or a 7950 XRS multi-service site. The system uses the parent policer’s min-thresh-separation value, the priority level’s mbs-contribution value and the number of child policers currently attached to the priority level to derive the priority level’s shared-portion and fair-portion of burst tolerance within the local priority level. The shared-portion and fair-portions for each priority level are then used by the system to calculate each priority level’s discard-unfair threshold and discard-all threshold. The mbs-contribution is the minimum separation between two adjacent active discard-all thresholds.

The value for a priority level’s mbs-contribution within the policer-control-policy may be overridden on the SAP, or subscriber sub-profile (applies to the 7450 ESS and 7750 SR) or multi-service site (for 7950 XRS) where the policy is applied in order to allow fine tuning of the discard-unfair and discard-all thresholds relevant to the needs of the local child policers on the object.

Accumulative Nature of Burst Tolerance for a Parent Policer Priority Level

When defining mbs-contribution, the specified size may only be a portion of the burst tolerance associated with the priority level. The packets associated with the priority level share the burst tolerance of lower within the parent policer. As the parent policer PIR bucket depth increases during congestion, the lower priority packets eventually experience discard based on each priority’s discard-unfair and discard-all thresholds. Assuming congestion continues once all the lower priority packets have been prevented from consuming bucket depth, the burst tolerance for the priority level will be consumed by its own packets and any packets associated with higher priorities.

The Effect of Fair and Unfair Child Policer Traffic at a Parent Policer Priority Level

The system continually monitors the offered rate of each child policer on each parent policer priority level and detects when the policer is in a congested state (the aggregate offered load is greater than the decrement rate defined on the parent policer). As previously stated, the result of congestion is that the parent policer's bucket depth will increase until it eventually hovers around either a discard-unfair or discard-all threshold belonging to one of the priority levels. This threshold is the point where enough packets are being discarded that the increment rate and decrement rate begin to even out. If only a single child policer is associated to the priority level, the discard-unfair threshold is not used since fairness is only applicable when multiple child policers are competing at the same priority level.

When multiple child policers are sharing the congested priority level, the system uses the offered rates and the parenting parameters of each child to determine the fair rate per child when the parent policer is unable to meet the bandwidth needs of each child. The fair rate represents the amount of bandwidth that each child at the priority level should receive relative to the other children at the same level according to the policer control policy instance managing the child policers. This fair rate is applied as the decrement rate for each child's FIR bucket. Changing a child’s FIR rate does not modify the amount of packets forwarded by the parent policer for the child’s priority level. It simply modifies the forwarded ratio between the children on that priority level. Since each child FIR bucket has some level of burst tolerance before marking its packets as unfair, the current parent policer bucket depth may at times rise above the discard-unfair threshold. The mbs-contribution value provides a means to define how much separation is provided between the priority level’s discard-unfair and discard-all threshold to allow the parent policer to absorb some amount of FIR burst before reaching the priority’s discard-all threshold.

This level of fair aggregate burst tolerance is based on the decrement rate of the parent policer’s PIR bucket while the individual fair bursts making up the aggregate are based on each child’s FIR decrement rate. The aggregate fair rate of the priority level is managed by the system with consideration of the current rate of traffic in higher priority levels. In essence, the system ensures that for each iteration of the child FIR rate calculation, the sum of the child FIR decrement rates plus the sum of the higher priority traffic increment rates equals the parent policers decrement rate. This means that dynamic amounts of higher priority traffic can be ignored when sizing a lower priority’s fair aggregate burst tolerance. Consider the following:

The 12 Mbps of the higher priority traffic and the 8 Mbps of fair traffic equal the 20 Mbps decrement rate of the parent policer.

It is clear that the higher priority traffic is consuming 12 Mbps of the parent policer’s decrement rate, leaving 8 Mbps of decrement rate for the lower priority’s fair traffic.

If all three children burst simultaneously (unlikely), they will consume 30 Kbytes above 8 Mbps. This is the same as the remaining decrement rate after the higher priority traffic.

Parent Policer Total Burst Tolerance and Downstream Buffering

The highest in-use priority level’s discard-all threshold is the total burst tolerance of the parent policer. In some cases the parent policer represents downstream bandwidth capacity and the max-rate of the parent policer is set to prevent overrunning the downstream bandwidth. The burst tolerance of the parent policer defines how much more traffic may be sent beyond the downstream scheduling capacity. In the worst case scenario, when the downstream buffering is insufficient to handle the total possible burst from the parent policer, downstream discards based on lack of buffering may occur. However, in all likelihood, this is not the case.

In most cases, lower priority traffic in the policer will be responsible for the greater part of congestion above the parent policer rate. Since this traffic is discarded with a lower threshold, this lowers the effective burst tolerance even while the highest priority traffic is present.

Configuring a Priority Level's MBS Contribution Value

In the most conservative case, a priority level’s mbs-contribution value may be set to be greater than the sum of child policer’s mbs and one max-size-frame per child policer. This ensures that even in the absolute worst case where all the lower priority levels are simultaneously bursting to the maximum capacity of each child, enough burst tolerance for the priority’s children will exist if they also burst to their maximum capacity.

Since simply adding up all the child policer’s PIR MBS values may result in large overall burst tolerances that are not ever likely to be needed, you should consider some level of burst oversubscription when configuring the mbs-contribution value for each priority level. The amount of oversubscription should be determined based on the needs of each priority level.

Using the Fixed Keyword to Create Deterministic Parent Policer Discard Thresholds

In the default behavior, the system ignores the mbs-contribution values for a priority level on a subscriber for 7450 ESS and 7750 SR, or a multi-service site for 7950 XRS, or SAP parent policer when a child policer is not currently associated with the level. This prevents additional burst tolerance from being added to higher priority traffic within the parent policer.

This does cause fluctuations in the defined threshold values when child policers are added or removed from a parent policer instance. If this behavior is undesirable, the fixed keyword may be used which causes the mbs-contribution value to always be included in the calculation of parent policer’s discard thresholds. The defined mbs-contribution value may be overridden on a subscriber sla-profile for the 7450 ESS and 7750 SR, or on a multi-service site for the 7950 XRS, or on a SAP instance, but the fixed nature of the contribution cannot be overridden.

If the defined mbs-contribution value for the priority level is zero, the priority level will have no effect on the parent policer’s defined discard thresholds. A packet associated with the priority level will use the next lower priority level’s discard-unfair and discard-all thresholds.

This command is used to create, configure, and delete tiered arbiters. Two tiers are supported that always exist specified as tier 1 and tier 2. Tiered arbiters enable you to create a bandwidth control hierarchy for managing child policers in an arbitrary fashion. Each arbiter enables you to parent child policers within eight strict levels of priority and a maximum aggregate rate may be defined for the children that the arbiter will enforce. Arbiters created on tier 1 are automatically parented to the root arbiter which is always present. Arbiters created on tier 2 default to the root arbiter as parent, but can also be explicitly parented to a tier 2 arbiter. Child policers associated with an instance of the policer-control-policy can be parented to any tiered arbiter or to the root arbiter.

This command is used to create an arbiter within the context of tier 1 or tier 2. An arbiter is a child policer bandwidth control object that manages the throughput of a set of child policers. An arbiter allows child policers or other arbiters to parent to one of eight strict levels. Each arbiter is itself parented to either another tiered arbiter or to the root arbiter.

The root arbiter starts with its defined maximum rate and distributes the bandwidth to its directly attached child policers and arbiters beginning with priority 8. As the children at each priority level are distributed bandwidth according to their needs and limits, the root proceeds to the next lower priority until either all children’s needs are met or it runs out of bandwidth. The bandwidth given to a tiered arbiter is then divided between that arbiters children (child policers or a tier 2 arbiter) in the same fashion. A tiered arbiter may also have a rate limit defined that limits the amount of bandwidth it may receive from its parent.

An arbiter that is currently parented by another arbiter cannot be deleted.

Each time the policer-control-policy is applied to either a SAP, or a subscriber (through association with a sub-profile that has the policy applied), or a multi-service site an instance of the parent policer and the arbiters is created.

Any child policer that uses the arbiter’s name in its parenting command will be associated with the arbiter instance. The child policer will also become associated with any arbiter to which its parent arbiter is parented (grandparent). Having child policers parented to an arbiter does not prevent that arbiter from being removed from the policer-control-policy. When removed, the child policers become orphaned.

You can create up to 31 tiered arbiters within the policer-control-policy on either tier 1 or tier 2 (in addition to the arbiter).

The no form of this command is used to remove an arbiter from tier 1 or tier 2. If the specified arbiter does not exist, the command returns without an error. If the specified arbiter is currently specified as the parent for another arbiter, the command will fail. When an arbiter is removed from a policer-control-policy, all instances of the arbiter will also be removed. Any child policers currently parented to the arbiter instance will become orphans and will not be bandwidth managed by the policer control policy instances parent policer.

This command is used to define an informational ASCII string associated with the specified arbiter. The string value may be defined or changed at anytime once the policy exists. The no version of this command is used to remove a description string from the tiered arbiter.

This command is used to define the maximum bandwidth an instance of the arbiter can receive from its parent tier 1 arbiter or the root arbiter. The arbiter instance enforces this limit by calculating the bandwidth each of its child policers should receive relative to their offered loads, parenting parameters and individual rate limits and using that derived rate as a child PIR decrement rate override. The override will not exceed the child policer’s administrative rate limit and the aggregate of all the child PIR decrement rates will not exceed the specified arbiter rate limit.

The arbiter’s policy defined rate value may be overridden at the SAP or sub-profile where the policer-control-policy is applied. Specifying an override prevents the arbiter from being removed from the policer control policy until the override is removed.

The no version of this command is used to remove a rate limit from the arbiter at the policer control policy level. The policy level rate limit for the arbiter will return to the default value of max. The no rate command has no effect on instances of the arbiter where a rate limit override has been defined.

This command is used to define from where the tiered arbiter receives bandwidth. Both tier 1 and tier 2 arbiters default to parenting to the root arbiter. Tier 2 arbiters may be modified to parent to a tier 1 arbiter. The tier 1 arbiter parent cannot be changed. If the no parent command is executed, the arbiter reverts to its root parenting default parameters.

The parent command is also used to define the parenting parameters. Each child arbiter attaches to its parent on one of the parents eight strict levels. Level 1 is the lowest and 8 is the highest. The level attribute is used to define which level the child arbiter uses on its parent. The parent distributes its available bandwidth based on strict priority starting with priority level 8 and proceeding towards level 1.

The weight attribute is used to define how multiple children at the same parent strict level compete when insufficient bandwidth exist on the parent for that level. Each child's weight is divided by the sum of the active children's weights and the result is multiplied by the available bandwidth. If a child cannot receive its entire weighted fair share of bandwidth due to a defined child rate limit, the remainder of its bandwidth is distributed between the other children based on their weights.

The no version of this command is used to return the tiered arbiter to the default parenting behavior. The arbiter will be attached to the root arbiter at priority level 1 with a weight of 1.