Class Fair Hierarchical Policing (CFHP)
In This Section
This section provides information to configure CFHP QoS policies using the command line interface.
Topics in this section include:
Introduction
CFHP merges the benefits of non-delay rate enforcement inherent to policers with the priority and fairness sensitivity of queuing and scheduling. CFHP is implemented as a group of child policers mapped to a parent policer where the rate enforced by the parent both obeys strict priority levels and is class fair within a priority level. At the parent policer, the output of a lower priority child policer cannot prevent forwarding of packets of a higher priority child policer and when multiple child policers share the same priority level, the system maintains a Fair Information Rate (FIR) for each child that is separate from a child’s PIR and CIR rates. Policers can also be used standalone. The parent is optional.
With 9.0R1, multi-service sites support policer-control-policy in the in the ingress and egress in addition to scheduler-policy.
Below are the capabilities and limitations for CFHP under a multi-service-site:
- Support for SAP only (no subscriber support)
- Assignment is for port only (not for card)
- Supported both in Ingress and Egress
- Policer Overrides are not supported under a multi-service-site.
Example of a service using mss is as below:
Here the above mentioned sap-egress qos policy "3" will have policers parented to arbiters which are configured in the policer-control-policy "pcp" as in example above.
Parent Policer Priority and Unfair Sensitive Discard Thresholds
Priority level bandwidth control is managed on the parent policer through the use of progressively higher discard thresholds for each in use priority level. Up to eight priority levels are supported and are individually enabled per parent policer instance based on child policer priority level association. When multiple child policers are associated with a parent policer priority level, two separate discard thresholds are maintained for that priority level. A lower “discard-unfair” threshold ensures that when a child policer has exceeded its FIR rate, its unfair packets are discarded first (assuming the parent policer’s bucket depth has reached the priority level’s “discard-unfair” threshold) protecting the priority level’s fair traffic from the priority level’s unfair traffic.
A second “discard-all” threshold is used to discard all remaining packets associated with the priority level in the case where higher priority traffic exists and the sum of both the priority level’s traffic and the higher priority traffic exceeds the parent policer rate. This protects the higher priority traffic on the parent policer from being discarded due to lower priority traffic. The child and parent policers operate in an atomic fashion, any conform effect on a child policer's bucket depth is canceled when the parent policer discards a packet. See Figure 56 for a description of policer bucket rate and packet flow interaction with bucket depth. See Figure 57 for a description of parent policer bucket and priority thresholds.
Figure 56: Policer Bucket Rate and Packet Flow Interaction with Bucket Depth
Figure 57: Parent Policer Bucket and Priority Thresholds
CFHP Ingress and Egress Use Cases
While ingress CFHP seems a natural fit based on how policers are typically used in today’s networks, CFHP may also be used at egress. The reasons for utilizing egress CFHP may be to provide a non-jitter or latency inducing aggregate SLA for multiple ingress flows or simply to provide higher scale in the number of egress aggregate SLAs supported.
Post-CFHP Queuing and Scheduling
Although CFHP enforces aggregate rate limiting while maintaining sensitivity to strict priority and fair access to bandwidth within a priority, CFHP output packets still require queuing and scheduling to provide access to the switch fabric or to an egress port.
Ingress CFHP Queuing
At ingress, CFHP output traffic is automatically mapped to a unicast or multipoint queue in order to reach the proper switch fabric destinations. In order to manage this automatic queuing function, a shared queue policy has been created or exists by default and is named policer-output-queues. For modifying parameters in this shared-queue policy, refer to Shared-Queue QoS Policy Command Reference.
The unicast queues in the policy are automatically created on each destination switch fabric tap and ingress CFHP unicast packets automatically map to one of the queues based on forwarding class and destination tap. The multipoint queues within the policy are created on the IOM3-XP’s 16/IMM or XMA multicast paths; 16 multicast paths are supported by default with 28 on 7950 XRS systems and the 7750 SR 12-e systems, with the latter having setting “tools perform the system set-fabric-speed fabric-speed-b.” The multicast paths represent an available multicast switch fabric path - the number of each being controlled using the command:
For ingress CFHP multicast packets (Broadcast, Unknown unicast or Multicast—referred to as BUM traffic), the system maintains a conversation hash table per forwarding class and populates the table forwarding class hash result entry with the one of the multicast paths. Best-effort traffic uses the secondary paths, and expedited traffic uses the primary paths.When a BUM packet is output by ingress CFHP, a conversation hash is performed and used along with the packets forwarding class to pick a hash table entry in order to derive the multicast path to be used. Each table entry maintains a bandwidth counter that is used to monitor the aggregate traffic per multicast path. This can be optimized by enabling IMPM on any forwarding complex which allows the system to redistribute this traffic across the IMPM paths on all forwarding complexes to achieve a more even capacity distribution. Be aware that enabling IMPM will cause routed and VPLS (IGMP and PIM) snooped IP multicast groups to be managed by IMPM.
Any discards performed in the ingress shared queues will be reflected in the ingress child policer's discard counters and reported statistics assuming a discard counter capable stat-mode is configured for the child policer.
Egress CFHP Queuing
When CFHP is being performed at egress, queuing of the CFHP output packets is accomplished through egress queue group queues. The system maintains a special egress queue group template (policer-output-queues) that is automatically applied to all Ethernet access ports that are up. The number of queues, queue types (expedite or best-effort), queue parameters and the default forwarding class mappings to the queues are managed by the template. On each Ethernet port, the queue parameters may be overridden.
When a SAP egress QoS policy is applied to an Ethernet SAP and the policy contains a forwarding class mapping to a CFHP child policer, the default behavior for queuing the CFHP output is to use the egress Ethernet port’s policer-output-queues queue group and the forwarding class mapping within the group to choose the egress queue. Optionally, the SAP egress QoS policy may also explicitly define which egress queue to use within the default queue group or even map the policer output to a different, explicitly created queue group on the port.
Any discards performed in the egress queue group queues will be reflected in the egress child policer’s discard counters and reported statistics assuming a discard counter capable stat-mode is configured for the child policer. Exceed profile traffic from the policer will be counted as out-of-profile traffic in the egress queue group queues.
Policer to Local Queue Mapping
Egress policers can be optionally mapped to a local queue instead of a queue group queue where required.
The syntax for assigning one such egress policer mapped to local queue is as below:
To a local queue as in "queue 2" above, both a policer and also a forwarding class can be concurrently mapped as shown below:
A queue resource is allocated whenever there is either an fc or a policer referencing it. The local queue is freed when there are no references to it. The local queue cannot be deleted when it is being referenced. Exceed profile traffic from the policer will be counted as out-of-profile traffic in the egress local queues.
Egress Subscriber CFHP Queuing
When a subscriber packet is mapped to a child policer through the SAP egress QoS policy. The actual egress queue group is derived from the subscriber host identification process within the subscriber management module, otherwise the default queue-group is used. This feature applies to the 7450 ESS only.
Subscriber Destination String Queue Group Identification
When a subscriber is identified, a special destination string may optionally exist for the subscriber that is typically used to identify the subscriber’s destination aggregation node. This feature applies only to the 7450 ESS and 7950 SR.
On the subscriber’s egress Ethernet port, the default policer-output-queues and other explicitly created queue groups may be configured to represent a destination node by defining the same destination string on the queue group. When the subscriber’s destination string is defined, the system will search the subscriber’s egress port for an egress queue group with the same string defined. If found, it will use that matched queue group instead of the default queue group. If a queue-group matching the string is not found, the subscriber identification event will not fail and the subscriber host will be mapped to default policer-output-queues.
The destination node-based queuing model is designed to provide the ability to shape the aggregate subscriber output to a destination aggregation node based on a queue group created for the specific purpose. On the queue group, a scheduling-policy is applied which defines the desired virtual scheduling behavior of the queues and aggregate maximum rate of the queue group. The destination string matching function could be used to represent any arbitrary downstream bandwidth limit, not just an aggregation node. If the destination string is not present (null value), the default policer egress queue group ('policer-output-queues') on the subscriber’s port will be used.
SAP Default Destination String
In order to simplify subscriber destination string provisioning, you can use a def-inter-dest-id command under the sub-sla-mgmt node within a SAP which allows the definition of a default destination string for all subscribers associated with the SAP. The command also accepts the use-top-q flag that automatically derives the string based on the top most delineating Dot1Q tag from the SAP’s encapsulation. This feature applies only to the 7450 ESS and 7750 SR.
The command is also supported within the msap-policy allowing similar provisioning behavior for automatically created managed SAPs.
CFHP Policer Control Policy
Provisioning CFHP entails creating policer control policies (policer-control-policy), applying a policer control policy to the ingress or egress context of a SAP or to the ingress or egress context of a subscriber profile (sub-profile) much the same way scheduler policies (scheduler-policy) are applied.
Applying a policer control policy to a SAP creates an instance of the policy that is used to control the bandwidth associated with the child policers on the SAP. In a similar fashion, an instance of the policy is created when a subscriber profile associated with the policy is applied to a subscriber context. The subscriber policy instance is used to control the bandwidth of the child policers created by the SLA profile instances within the subscriber context.
Policer control policies can only be applied to SAPs created on Ethernet ports. When the policy instance is created, any policers created on the SAP that have an appropriate parent command defined are considered child policers.
Policer Control Policy Root Arbiter
Similar to a scheduler context within a scheduler-policy, the policer-control-policy contains objects called an arbiter that control the amount of bandwidth that may be distributed to a set of child policers. Each policer control policy always contains a root arbiter that represents the parent policer. The max-rate defined for the arbiter specifies the decrement rate for the parent policer that governs the overall aggregate rate of every child policer associated with the policy instance. The root arbiter also contains the parent policers MBS configuration parameters that the system uses to individually configure the priority thresholds for each policer instance.
Child policers may parent directly to the root arbiter or to one of the tier 1 or tier 2 explicitly created arbiters.
Each arbiter provides bandwidth to its children using eight strict levels. Children parented at level 8 are first to receive bandwidth. The arbiter continues to distribute bandwidth until either all of its children's bandwidth requirements are met or until the bandwidth its allowed to distribute is exhausted. The root arbiter is special in that its strict priority levels directly represent the priority thresholds within the parent policer.
Tier 1 and Tier 2 Explicit Arbiters
Other arbiters may be explicitly created in the policy for the purpose of creating an arbitrary bandwidth distribution hierarchy. The explicitly created arbiters must be defined within tier 1 or tier 2 on the policy. Tier 1 arbiters must always be parented by the root arbiter and thus becomes a child of the root arbiter. Any child policers directly parented by a tier 1 policer treat the root arbiter as its grandparent. Inversely, the root arbiter considers the child policers as grandchildren. All grandchild policers inherit the priority level of their parent arbiter (the level that the tier 1 arbiter attaches to the root arbiter) within the parent policer.
An arbiter created on tier 2 may be parented by either an arbiter in tier 1 or by the root arbiter. If the tier 2 arbiter is parented by the root arbiter, it is internally treated the same as a tier 1 arbiter and its child policers have a grandchild to grandparent association with the root arbiter.
When a tier 2 arbiter is parented by a tier 1 arbiter, the child policers parented by a tier 2 arbiter are in a great-grandchild to great-grandparent association with the root arbiter. A great-grandchild policer inherits its indirectly parented tier 1 arbiter’s level association with the root arbiter and thus the parent policer.
A child policer’s priority level on the root arbiter (directly or indirectly) defines which priority level discards thresholds will be associated with packets mapped to the child policer for use in the parent policer (assuming the packet is not discarded by its child policer).
Explicit Arbiter Rate Limits
The bandwidth a tier 1 or tier 2 arbiter receives from its parent may be limited by the use of the rate command within the arbiter. When a rate limit is defined for a root arbiter, the system enforces the aggregate rate by calculating a per child policer PIR rate based on the distributed bandwidth per child. This calculated PIR is used to override the child's defined PIR and is represented as the child's operational PIR. The calculated rate will never be greater than a child policer's provisioned rate.
CFHP with Child Policer Exceed PIR Enabled
A child policer parented to an arbiter can be enabled to forward traffic exceeding its PIR, in which case:
- Traffic exceeding the operational PIR of the child policer is reprofiled to be exceed profile, where the operational PIR is determined by the H-pol algorithm from the configuration of the policer parent and the associated arbiters (root and/or intermediate).
- Traffic exceeding the child policer's operational PIR does not consume capacity from the parent policer (meaning that it does not contribute to the parent policer bucket depth with respect to any of its thresholds).
- Traffic which did not exceed the child policer's operational PIR (when that child is configured with enable-exceed-pir) can exceed its parent rate (max-rate for the root arbiter) in which case the traffic is forwarded and re-profiled to be exceed profile and its affect on the child policer is revoked (meaning that it does not contribute to any of the child policer bucket (PIR, CIR, FIR) depths with respect to any of its thresholds).
CFHP Child Policer Definition and Creation
Policers are created within the context of SAP ingress (sap-ingress) and SAP egress (sap-egress) QoS policies. Policer creation in a QoS policy is defined similar to SAP based queues. A policer is identified using a policer ID. Queues and policers have different ID spaces (both a policer and queue may be defined with ID 1).
The only create time parameter currently available is the unique policer ID within the policy. Policers do not have a scheduling mode (expedite or best-effort), they also do not need to be placed in profile-mode in order to accept traffic from profile in or profile out forwarding classes or sub classes.
All policers within a SAP ingress or egress QoS policy must be explicitly created. No policers are created by default. After a policer is created, forwarding classes or sub-classes may be mapped to the policer within the policy. For ingress, each of the individual forwarding types (unicast, multicast, broadcast and unknown) may be selectively mapped to a policer, policy created queue or to an ingress port queue group queue. At egress, forwarding classes are not divided into forwarding types, so all packets matched to the forwarding class may be mapped to either a policer, policy created queue or egress port queue group queue.
Similar to queues, a policer is not created on the SAPs where the policy is applied until at least one forwarding class is mapped to the policer. When the last forwarding class is unmapped from the policer, all the instances of the policer on the SAPs to which the policy is applied are removed.
Policer Enabled SAP QoS Policy Applicability
Policers are not created on a SAP or subscriber or multi-service site context until at least one forwarding class has been mapped to the policer. Simply creating a policer within a QoS policy does not cause policers to be created on the SAPs or subscribers or multi-service sites where the policy is applied.
SAP QoS policy applicability and policy policer forwarding class mappings are dependent on policer resource availability. Attempting to map the first forwarding class to a policer causes the policer to be created on the SAPs or subscribers or multi-service site where the policy is applied. If the forwarding plane where the SAP or subscriber or multi-service site exists either doesn't support policers or has insufficient resources to create the policer for the object, the forwarding class mapping will fail.
Once a forwarding class is successfully mapped to a policer within the policy, attempting to apply the policy to a SAP or a subscriber or multi-service site where the policer cannot be created either due to lack of policer support or insufficient policer resources will fail.
Policing is supported only on Ethernet SAPs or Ethernet based subscribers. Policing is also only supported on FlexPath2 based systems or IOMs with the exception of CCAG and HSMDA SAPs or subscribers. This feature applies to the 7450 ESS and 7750 SR only.
Child Policer Parent Association
Each policer configured within a SAP ingress or SAP egress QoS policy may be configured to be child policer by defining a parent arbiter association using the parent command. If the command is not executed, the policer operates as a stand-alone policer wherever the policy is applied. If the parent command is executed, but the defined arbiter name does not exist within the SAP context or a subscriber or multi-service site context, the policer is treated as an orphan. The SAP or subscriber or multi-service site context is placed into a degraded state. The system indicates the degraded state by the system setting the ingress-policer-mismatch or egress-policer-mismatch flag for the object. An orphaned policer functions in the same manner as a policer without a parent defined.
An arbiter exists on a SAP when a policer-control-policy containing the arbiter is applied to the appropriate direction (ingress or egress) of the SAP. An arbiter exists on a subscriber when a policer-control-policy containing the arbiter is applied to the subscriber's sub-profile in the appropriate direction as well (applies to the 7450 ESS and 7750 SR).
Profile Capped Policers
Profile capped mode has been introduced to enforce an overall in-profile burst limit to the CIR bucket for ingress undefined, ingress explicit in-profile, egress soft-in-profile and egress explicit in-profile packets. The default behavior when profile-capped mode is not enabled is to ignore the CIR output state when an explicit in-profile packet is handled by an ingress or egress policer. The explicit in-profile packets will consume CIR tokens up to 2xCBS at which point the bucket stops incrementing and the CIR output for that type of packet enters the non-conforming state.
However, the non-conforming state is ignored by the forwarding plane and the packet continues to be handled as in-profile. Thus, the total amount of in-profile traffic can be greater than the configured CIR.
The profile-capped mode makes two changes:
- At egress, soft-in-profile packets (packets received from ingress as in-profile) are treated the same as explicit in-profile (unless explicitly reclassified as out-of-profile) and have an initial policer state of in-profile
- At both ingress and egress, any packet output from the policer with a non-conforming CIR state are treated as out-of-profile (out-of-profile state is ignored for initial in-profile packets when profile capped mode is not enabled)
The idea is that a profile capped policer trusts the in-profile state determined at ingress classification or egress re-classification, the initial in-profile traffic is preferentially handled with the CIR bucket (2xCBS instead of 1xCBS used by undefined or soft-out-of-profile traffic) and the total amount of in-profile traffic output by the policer cannot exceed the CIR (including initial in-profile traffic).
One other aspect to consider with profile-capped mode is the effect on stat-mode behavior. As will be seen below, each stat-mode has a fixed number of counters in the NP and Q. The mapping of packets to a counter is also fixed by the offered packet state (profile in, profile out, undefined, soft-in-profile and soft-out-of-profile) in conjunction with the output state of the policer. The egress policer stat-modes and the behavior of soft-in-profile (from ingress) and profile in (reclassified at egress) packets. In the non-capped mode, soft-in-profile is considered undefined while in capped mode it is considered to be equivalent to profile in. Another aspect that causes issues with ingress and egress stat-modes is the fact that initially green (profile in at ingress and egress as well as soft-in-profile at egress), packets can actually turn yellow in the policer output.
Table 74 demonstrates how the CIR rate and initial profile of each packet affects the output of normal (non-profile-capped) and profile-capped mode policers.
Table 74: Effect of Profile-Capped Mode on CIR Output
CIR Setting | Initial Profile State | Normal Mode | Capped Profile Mode | Notes |
CIR=0 | Ingress Undefined | Always Yellow | Always Yellow | CIR = 0 forces all packets to be yellow when profile-capped mode is enabled. In normal mode, all Profile In related packets are allowed to stay green. |
Ingress Profile In | Always Green | Always Yellow | ||
Ingress Profile Out | Always Yellow | Always Yellow | ||
Egress Soft-In-Profile | Always Green | Always Yellow | ||
Egress Soft-Out-of-Profile | Always Yellow | Always Yellow | ||
Egress Profile In | Always Green | Always Yellow | ||
Egress Profile Out | Always Yellow | Always Yellow | ||
CIR=Max/PIR | Ingress Undefined | Always Green | Always Green | CIR never reaches non-conforming state. |
Ingress Profile In | Always Green | Always Green | ||
Ingress Profile Out | Always Yellow | Always Yellow | ||
Egress Soft-In-Profile | Always Green | Always Green | ||
Egress Soft-Out-Of-Profile | Always Green | Always Green | ||
Egress Profile In | Always Green | Always Green | ||
Egress Profile Out | Always Yellow | Always Yellow | ||
0 < CIR < PIR | Ingress Undefined | Green below CBS Yellow at or above CBS | Green below CBS Yellow at or above CBS | |
Ingress Profile In | Always Green | Green below 2xCBS Yellow at or above 2xCBS | ||
Ingress Profile Out | Always Yellow | Always Yellow | ||
Egress Soft-In-Profile | Green below CBS Yellow at or above CBS | Green below 2xCBS Yellow at or above 2xCBS | ||
Egress Soft-Out-Of-Profile | Green below CBS Yellow at or above CBS | Green below CBS Yellow at or above CBS | ||
Egress Profile In | Always Green | Green below 2xCBS Yellow at or above 2xCBS | ||
Egress Profile Out | Always Yellow | Always Yellow |
Policer Interaction with Initial Profile, Discard Eligibility, and Ingress Priority
Packets that are offered to an ingress policer may have three different states relative to initial profile:
- undefined—Either the forwarding class or sub-class associated with the packet is not explicitly configured as profile in, profile out or de-1-out-profile is enabled and the Dot1P DE bit is set to zero.
- in-profile—The forwarding class or sub-class associated with the packet is configured as profile in.
- out-of-profile—The forwarding class or sub-class associated with the packet is configured as profile out or de-1-out-profile is enabled and the Dot1P DE bit is set to 1.
Ingress policed packets are not subject to ingress queue CIR profiling within the ingress policer output queues. While the unicast and multipoint shared queues used by the system for ingress queuing of policed packets may have a CIR rate defined, this CIR rate is only used for rate based dynamic priority scheduling purposes. The state of the CIR bucket while forwarding a packet from a policer-output-queues shared queue will not alter the packets ingress in-profile or out-of-profile state derived from the ingress policer.
Priority high and low are used in the child policer’s PIR leaky bucket to choose one of two discard thresholds (threshold-be-low and threshold-be-high) which are derived from the child policer’s mbs and high-priority-only parameters. The high threshold is directly generated by the mbs value. The low threshold is generated by reducing the mbs value by the high-priority-only percentage. A packet’s priority is determined while the packet is evaluated against the ingress classification rules in the sap-ingress QoS policy.
Packets that are offered to an egress policer may have four different states relative to initial profile:
- soft-in-profile—The final result at ingress was in-profile and the profile of the packet’s profile has not been reclassified at egress.
- soft-out-of-profile—The final result at ingress was out-of-profile and the packet's profile has not been reclassified at egress.
- hard-in-profile—The profile of the packet has been reclassified at egress as profile in.
- hard-out-of-profile—The profile of the packet has been reclassified at egress as profile out.
When an egress policer’s CIR rate is set to 0 (or not defined), the policer will have no effect on the profile of packets offered to the policer. The soft-in-profile and hard-in-profile packets will remain in-profile while the soft-out-of-profile and hard-out-of-profile packets will remain out-of-profile.
Setting a non-zero rate for the egress policer’s CIR will modify this behavior for DSCP, prec, Dot1P, and DEI egress marking purposes. Both soft-in-profile and hard-in-profile retain their inherent in-profile behavior and the soft-out-of-profile and hard-out-of-profile retain their inherent out-of-profile behavior.
For egress marking decisions, the hard-in-profile and hard-out-of-profile packets ignore the egress policer’s CIR state. When the packet state is hard-in-profile, the in-profile Dot1P marking will be used and when DEI marking is enabled for the packets forwarding class it will be marked 0. When the packet state is hard-out-of-profile, the out-of-profile Dot1P marking will be used and when DEI marking is enabled for the packets forwarding class it will be marked 1.
When the egress packet state is soft-in-profile and soft-out-of-profile and the policer’s CIR is configured as non-zero, the current CIR state of the policer’s CIR bucket will override the packets soft profile state. When the policer’s CIR is currently conforming, the output will be in-profile. When the CIR state is currently exceeding, the output will be out-of-profile. If enable-exceed-pir is configured, when the PIR state is exceeding, the output will be exceed-profile. The Dot1P, outerDot1P, and DEI (when DE marking is configured) will reflect the CIR and PIR derived packet state. If enable-dscp-prec-marking is enabled, the DSCP and prec will reflect the CIR and PIR derived packet state.
Ingress ‘Undefined’ Initial Profile
Access ingress packets have one of three initial profile states prior to processing by the policer:
- Undefined
- profile in
- profile out
The SAP ingress QoS policy classification rules map each packet to either a forwarding class or a sub-class within a forwarding class. The forwarding class or sub-class may be defined as explicit profile in or profile out (the default is no profile). When a packet’s forwarding class or sub-class is explicitly defined as profile in or profile out, the packet’s priority is ignored, and it is not handled by the ingress policer as profile ‘undefined’.
See Table 74 to track the ingress behavior of initial profile and the effect of the CIR bucket on that initial state.
At egress, an ingress policer output of ‘in-profile’ is treated as ‘soft-in-profile’ and an ingress policer output of ‘out-of-profile’ is treated as ‘soft-out-of-profile’. Each may be changed by egress profile reclassification or by an egress policer with a CIR rate defined.
Ingress Explicitly ‘In-Profile’ State Packet Handling without Profile-Capped Mode
Packets that are explicitly ‘in-profile’ remain ‘in-profile’ in the ingress forwarding plane and are not affected by the ingress policer CIR bucket state when profile-capped mode is not enabled. They do not bypass the policer’s CIR leaky bucket but are extended with a greater threshold than the CBS derived ‘threshold-bc’. This allows the ‘undefined’ packets to backfill the remaining conforming CIR bandwidth after accounting for the explicit ‘in-profile’ packets. This does not prevent the sum of the explicit ‘in-profile’ from exceeding the configured CIR rate, but it does cause the ‘undefined’ packets that are marked ‘in-profile’ to diminish to zero once the combined explicit ‘in-profile’ rate and ‘undefined’ rate causes the bucket to reach ‘threshold-bc’.
The policer’s CIR bucket will indicate that the explicit ‘in-profile’ packets should be marked ‘out-of-profile’ once the bucket reaches the greater threshold, but this indication is ignored by the ingress forwarding plane. All explicit ‘in-profile’ packets remain in-profile within the ingress forwarding plane. However, once the packet is received at egress, an ingress ‘in-profile’ packet will be treated as ‘soft-in-profile’ and the profile may be changed either by explicit profile reclassification or by an egress policer with a CIR rate defined.
Explicit in-profile packets do not automatically use the high priority threshold (‘threshold-be-high’) within the child policer’s PIR bucket. If preferential burst tolerance is desired for explicit in-profile packets, the packets should also be classified as priority high.
Ingress Explicitly ‘In-Profile’ State Packet Handling with Profile-Capped Mode
When profile-capped mode is enabled, the packet handling behavior defined in Ingress ‘Undefined’ Initial Profile is altered in one aspect. The CIR output state of yellow at the greater threshold is actually honored and the packet will be treated as out-of-profile. The packet will be sent to egress in the ‘soft-out-of-profile’ state in this case.
Ingress Explicit ‘Out-of-Profile’ State Packet Handling
Packets that are explicitly ‘out-of-profile’ remain ‘out-of-profile in the ingress forwarding plane. Unlike initially ‘in-profile’ packets, they do not consume the policer’s CIR bucket depth (accomplished by setting the ‘threshold-bc’ to 0) and thus do not have an impact on the amount of ‘undefined’ marked as ‘in-profile’ by the policer.
While explicit ‘out-of-profile’ packets remain out-of-profile within the ingress forwarding plane, the egress forwarding plane treats ingress out-of-profile packets as ‘soft-out-of-profile’ and the profile may be changed either by explicit profile reclassification or by an egress policer with a CIR rate defined.
Egress Explicit Profile Reclassification
An egress profile reclassification overrides the ingress derived profile of a packet and may set it to either ‘hard-in-profile’ or ‘hard-out-of-profile’. A packet that has not been reclassified at egress retains its ‘soft-in-profile’ or ‘soft-out-of-profile’ status.
Egress in-profile (including ‘soft-in-profile’ and ‘hard-in-profile’) packets use the child policer’s high ‘threshold-be’ value within the child policer’s PIR bucket while ‘soft-out-of-profile’ and ‘hard-out-of-profile’ packets use the child policer’s low ‘threshold-be’ value.
Preserving Out of Profile State at Egress Policer
Traffic sent through an egress policer with a non zero CIR will be reprofiled by default based on the CIR threshold of the egress policer. To accommodate designs where traffic is set to be out of profile at ingress, and the out of profile state is required to be maintained by an egress policer, the parameter profile-out-preserve can be configured under the egress policer. Explicit egress reclassification to the profile takes precedence over the profile-out-preserve operation.
Egress Policer CIR Packet Handling without Profile Capped Mode
When an egress policer has been configured with a CIR (max or explicit rate other than ‘0’) and profile capped mode is not enabled, the policer’s CIR bucket state will override the ingress ‘soft-in-profile’ or ‘soft-out-of-profile’ state much like the ingress policer handles initial profile ‘undefined’ packets. If the CIR has not been defined or been set to ‘0’ on the egress policer, the egress policer output state will be ‘in-profile’ for ‘soft-in-profile’ packets and ‘out-of-profile’ for ‘soft-out-of-profile’ packets.
If a packet’s profile has been reclassified at egress, the new profile classification is handled similar to the ingress policer handling of initial ‘in-profile’ or ‘out-of-profile’ packets. When a packet has been reclassified as ‘hard-in-profile’, it is applied to the egress policer’s CIR bucket using a ‘threshold-bc’ higher than the ‘threshold-bc’ derived from the policer’s CBS parameter, but the policer output profile state will remain ‘in-profile’ even if the higher threshold is crossed. When a packet has been reclassified as ‘hard-out-of-profile’, it does not consume the egress policer’s CIR bucket depth and the policer output profile state remains ‘out-of-profile’.
Egress Policer CIR Packet Handling with Profile Capped Mode
When profile capped mode is enabled, the egress packet handling described in Egress Policer CIR Packet Handling without Profile Capped Mode is modified in three aspects.
First, the soft-in-profile received from ingress is handled in a similar fashion as egress explicit profile in reclassification unless the packet has been reclassified to profile out at egress.
Second, explicit egress profile in and soft-in-profile that has not been reclassified to profile out at egress are allowed to be marked out-of-profile by an egress policer with CIR not set to 0.
Third, when the policer has a CIR = 0 rate (the default rate), all profile capped packets are treated as out-of-profile independent of the initial profile state.
Forwarding Traffic Exceeding PIR in Egress Policers
An egress policer can be configured to forward traffic which exceeds its oper PIR instead of dropping it. The traffic exceeding the PIR is assigned an exceed profile state. This is supported for any configured (not dynamic) policer in a SAP egress QoS policy, which can be used for both SAPs and subscribers, and in an egress queue group template which can be used on egress network ports.
This is configured using the enable-exceed-pir command and the stat-mode offered-total-cir-exceed provides forward and drop counters for exceed profile traffic, as shown below
The dot1p, outer dot1p, DSCP and precedence can be remarked for the exceed profile traffic.
Ingress Child Policer Stat-Mode
A policer has multiple types of input traffic and multiple possible output states for each input traffic type. These variations differ between ingress and egress.
For ingress policing, each offered packet has a priority and a profile state. The priority is used by the policer to choose either the high or low priority PIR threshold-be. Every offered packet is either priority high or priority low. The offered profile state defines how a packet will interact with the policers CIR bucket state. The combinations of priority and initial profile are as follows:
- Offered priority low, undefined profile
- Offered priority low, explicit profile in
- Offered priority low, explicit profile out
- Offered priority high, undefined profile
- Offered priority high, explicit profile in
- Offered priority high, explicit profile out
Note: When de1out is enabled, DEI = 0 is considered as undefined profile and DEI = 1 is considered the same as profile out
The possible output results for the ingress policer are:
- Output green (in-profile)
- Output yellow (out-of-profile)
- Output red (discard)
In order to conserve counter resources, the system supports a policer stat-mode command that is used to identify what counters are actually needed for the policer. Not every policer will have a CIR defined, so the output green/yellow states will not exist. Also, not every policer will have both high and low priority or explicit in-profile or out-of-profile offered traffic types. Essentially, the stat-mode command allows the counter resources to be allocated based on the accounting needs of the individual policers.
Setting the stat-mode does not modify the packet handling behavior of the policer. For example, if the configured stat-mode does not support in-profile and out-of-profile output accounting, the policer is not blocked from having a configured CIR rate. The CIR rate will be enforced, but the amount of in-profile and out-of-profile traffic output from the policer will not be counted separately (or maybe not at all based on the configured stat-mode).
A policer is created with minimal counters sufficient to provide total offered and total discarded (the total forwarded is computed as the sum of the offered and discarded counters). The stat-mode is defined within the sap-ingress or sap-egress QoS policy in the policer context. When defining the stat-mode, the counter resources needed to implement the mode must be available on all forwarding planes where the policer has been created using the QoS policy unless the policer instance has a stat-mode override defined. You can see the resources used and available by using the tools dump resource-usage card fp command. If insufficient resources exist, the change in the mode will fail without any change to the existing counters currently applied to the existing policers. If the QoS policy is being applied to a SAP or subscriber or multi-service site context and insufficient counter resources exist to implement the configured modes for the policers within the policy, the QoS policy will not be applied. For SAPs, this means the previous QoS policy will stay in effect. For subscribers, it could mean that the subscriber host event where the QoS policy is being applied will fail and the subscriber host may be blocked or removed.
A stat-mode with at least minimal stats is required before the policer can be assigned to a parent arbiter using the parent command.
Successfully changing the stat-mode for a policer causes the counters associated with the policer to reset to zero. Any collected stats on the object the policer is created on will also reset to zero.
The system uses the forwarding plane counters to generate accounting statistics and for calculating the operational PIR and FIR rates for a set of children when they are managed by a policer-control-policy. Only the offered counters are used in hierarchical policing rate management. When multiple offered stats are maintained for a child policer, they are summed to derive the total offered rate for each child policer.
All ingress policers have a default CIR value of 0 meaning that by default, all packets except packets classified as profile in will be output by the policer as out-of-profile. This may have a negative impact on egress marking decisions (if in-profile and out-of-profile have different marking values) and on queue congestion handling (WRED or queue tail drop decisions when out-of-profile is less preferred). The following options exist to address this potential issue:
- If all packets handled by the policer must be output as in-profile by the policer, either the packet's forwarding class or sub-class can be defined as profile in or the CIR on the policer can be defined as max
- If some packets must be output as in-profile while others output as out-of-profile, three options exist
- The CIR may be left at '0' while mapping the packets that must be output as in-profile to a forwarding class or sub-class provisioned as profile in
- The CIR may be set to max while mapping the packets that must be output as out-of-profile to a forwarding class or sub-class provisioned as profile out
- Ignore the CIR on the policer and solely rely on the forwarding class or sub-class profile provisioning to the proper policer CIR output
Egress policers also have a default CIR set to 0, but in the egress case a value of 0 disables policer profiling altogether. Egress packets on a CIR disabled egress policer retain their offered profile state (soft-in-profile, soft-out-of-profile, hard-in-profile or hard-out-of-profile).
Make sure to use the correct stat-mode if the policer’s CIR is explicitly not set or is set to 0. The no-cir version of the stat-mode must be used and when the CIR has a non-zero value. Also when overriding the policer’s cir mode, make sure you override the stat-mode instance (cir override can be performed using snmp access).
Ingress supported stat-modes are:
- no-stats
- minimal - default
- offered-profile-no-cir
- offered-priority-no-cir
- offered-limited-profile-cir
- offered-profile-cir
- offered-priority-cir
- offered-total-cir
- offered-profile-capped-cir
- offered-limited-capped-cir
Egress Child Policer Stat-Mode
Egress policers have fewer stat-mode options due to the fact that they do not deal with offered packets with an undefined profile state. All packets received on the egress forwarding plane have been profiled as either in-profile or out-of-profile. The egress forwarding plane treats the ingress derived profile as a soft state that may be either overridden by an egress profile reclassification or by a CIR rate enforced by an egress policer.
For egress, the possible types of offered packets include:
- Soft offered in-profile (from ingress)
- Soft offered out-of-profile (from ingress)
- Egress explicit in-profile (reclassified at egress)
- Egress explicit out-of-profile (reclassified at egress)
Similar to ingress, the possible output results are:
- Output green (in-profile)
- Output yellow (out-of-profile)
- Output red (discard or exceed-profile)
The stat-mode command follows the same counter resource rules as ingress.
Egress supported stat-modes are:
- no-stats
- minimal - default
- offered-profile-no-cir
- offered-profile-cir
- offered-total-cir
- offered-limited-capped-cir
- offered-profile-capped-cir
- offered-total-cir-exceed
Details of the output showing the stat-modes for ingress and egress child policers can be found in the Class Fair Hierarchical Policing for SAPs section of the SR OS Advanced Configuration Guide.
Profile Preferred Mode Root Policers
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 which have their profile state been set to in-profile by the output of the child policer CIR bucket.
When this option is selected, all child policers parented to a root policer will have their FIR bucket track the state of the CIR bucket. In other words, a green packet will always be blue and a yellow packet will always be orange. When admitting packets from the child policers within a given priority level, orange packets will be allowed up to the "discard-unfair" threshold while blue packets will be allowed up to the "discard-all" threshold. The operation is unchanged if a child policer is configured to forward traffic exceeding its PIR, specifically, the exceed profile traffic is treated in the same way as yellow/orange (out of profile) packets.
HPOL will no longer set the FIR bucket of the child policer based on fair share calculation. Instead, the ‘profile-preferred’ option forces the FIR bucket to track the CIR bucket’s decrement rate and the threshold chosen for the CIR bucket would also be used in the FIR bucket (instead of using the threshold associated with the PIR bucket).
The green/yellow output from the policer would be used for packet marking decisions. The blue/orange child policer input to the parent policer would chose the discard-orange or discard-all thresholds for the child policer’s priority level within the parent policer.
The net result is that explicit in-profile packets stay blue up to the high CBS threshold, undefined profile packets would stay blue up to the low CBS threshold (1x CBS) and explicit out-of-profile packets would always be orange due to a 0 CBS threshold. Orange packets would be discarded by the parent policer within the child policer’s priority level before the blue packets, preferring blue packets over orange once the discard-orange threshold is crossed.
The following is the CLI for the new option. The same option applies to overrides applied to the instances of a policer control policy under a SAP or subscriber or multi-service site context.
The profile-preferred option provides us a way to configure a specific FIR (since it uses the CIR as FIR). In the direct-parented case (no intermediate arbiters present at all) the child policers do not need to have their offered rate polled as each policer will always have PIR equal to the min (child PIR, root PIR) and the FIR and CIR are fixed and equal. The child parenting weights are thus not used. This impacts the show commands, for example offered rate information will not be available. The output of some show commands (show qos policer-hierarchy ... detail) should be adjusted for profile-preferred configurations.
If an intermediate arbiter is present, then polling is offered at different rates since the child policer PIRs will be set based on this information so as to share the intermediate arbiter PIR in proportional to their parenting weight to the intermediate arbiter.