Class Fair Hierarchical Policing (CFHP)
Quality of Service Guide 857
• 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.
To Next Page
Loading...
