PCC rule-based subscriber services with QoS actions interact with the classification and QoS forwarding mechanisms. This section describes how this affects the parent RADIUS accounting volume counters.
For subscriber service PCC rule QoS actions that do not result in the instantiation of a dynamic policer (such as a change of forwarding class or forward), the PCC rule matched traffic is included in the parent accounting session volume counters. This is shown in Figure: PCC rule-based subscriber service—QoS interaction: no dynamic policer, FC to queue, where the forwarding class is mapped to a subscriber queue, and in Figure: PCC rule-based subscriber service—QoS interaction: no dynamic policer, FC to policer to queue-group where the forwarding class is mapped to a subscriber policer.
For subscriber service PCC rule QoS actions that result in the instantiation of a dynamic policer (such as rate-limit or account), the dynamic policer counters are not included in the aggregate counters nor are they reported as separate detailed policer statistics. Instead, the traffic matching the PCC rules is counted in the output queues that correspond to the forwarding class of the packets.
On ingress, the dynamic policer PCC rule traffic is never included in the parent host, session, or queue instance accounting session counters. Ingress policed traffic always uses the ingress shared policer output queues, as shown in Figure: PCC rule-based subscriber service—QoS interaction: dynamic policer to ingress shared policer output queues.
Figure: PCC rule-based subscriber service—QoS interaction: dynamic policer to ingress shared policer output queues
To include the egress dynamic policer PCC rule traffic in the parent host, session, or queue instance accounting session counters, the dynamic policer must use a local subscriber output queue, as shown in Figure: PCC rule-based subscriber service—QoS interaction: dynamic policer, FC to queue (egress).
Figure: PCC rule-based subscriber service—QoS interaction: dynamic policer, FC to queue (egress)
To exclude the egress dynamic policer PCC rule traffic from the parent host, session, or queue instance accounting session counters, the dynamic policer must use a queue-group output queue, as shown in Figure: PCC rule-based subscriber service—QoS interaction: dynamic policer, FC to policer to policer output queues (egress). The dynamic policer traffic inherits the policer-to-output queue mapping from the static policer that corresponds to the forwarding class of the packet. The following SAP egress configuration example uses the default policer output queue-group:
config>qos sap-egress 10 create sub-insert-shared-pccrule start-entry 200 count 10 dynamic-policer range start-entry 10 count 10 exit policer 1 create exit fc be create policer 1 exit exitIf a packet is classified as FC = Best Effort (BE) and matches a PCC rule with rate-limit action only (no FC change), the traffic hits the PCC rule dynamic policer and then the queue-group queue associated with policer 1 (the static policer for FC = BE).
Figure: PCC rule-based subscriber service—QoS interaction: dynamic policer, FC to policer to policer output queues (egress)
A special case occurs when, at egress, the forwarding class maps to a static policer and then to a local subscriber queue. Traffic for that forwarding class hitting a dynamic policer uses the local subscriber queue as the output queue. In this case, the dynamic policer PCC rule traffic is included in the parent host, sessions or queue instance accounting session counters. This is shown in Figure: PCC rule-based subscriber service—QoS interaction: dynamic policer, FC to policer to local queue (egress).
Figure: PCC rule-based subscriber service—QoS interaction: dynamic policer, FC to policer to local queue (egress)