AA policers

The rate limit (policer) policy actions provide the flow control mechanisms that enable rate limiting by application or AA subscribers.

There are six types of policers:

• Flow rate policer monitors a flow setup rate.

• Flow count limits control the number of concurrent active flows.

• Single-rate bandwidth policers monitor bandwidth using a single rate and burst size parameters.

• Dual-rate bandwidth rate policers monitor bandwidth using CIR/PIR and CBS/MBS. These can only be used at the per-subscriber granularity.

• Time of day overrides the default policer values at the specified time of day.

• Congestion override policers apply when the subscriber is in a congestion state.

After a policer is referred to by an AQP action for one traffic direction, the same policer cannot be referred to in the other direction. This also implies that AQP rules with policer actions must specify a traffic direction other than the ‟both” direction.

Table: Policer's hardware rate steps for AA ISA illustrates a policer's hardware rate steps for AA ISA.

Policers are unidirectional and are named with these attributes:

• policer name

• policer type (single or dual bucket bandwidth, flow rate limit, flow count limit)

• granularity (select per-subscriber, system-wide, or ANL)

• parameters for flow setup rate (flows per second rate)

• parameters for flow count (maximum number of flows)

• rate parameters for single-rate bandwidth policer (PIR)

• parameters for two-rate bandwidth policer (CIR, PIR)

• PIR and CIR adaptation rules (min, max, closest)

• burst size (CBS and MBS)

• conformant action (allow) (mark as in-profile)

• non-conformant action (discard, or mark with options being in profile and out of profile)

Policers allow temporary over subscription of rates to enable new sessions to be added to traffic that may already be running at peak rate. Existing flows are impacted with discards to allow TCP backoff of existing flows, while preventing full capacity from blocking new flows.

Policers can be based on an AQP rule configuration to allow per-app-group, per-AA subscriber total, per AA profile policy per application, and per system per app-group enforcement.

Policers are applied with two levels of hierarchy (granularity):

• per individual AA subscriber

  • per-AA subscriber per app group/application or protocol rate

  • per-AA subscriber per application rate limit for a small selection of applications

  • per-AA subscriber PIR/CIR. This allows the AA ISA to emulate IOM ingress policers in from-sub direction

• per system (AA ISA or a group of AA subscribers)

  • total protocol/application rate

  • total app group rate

• Per ANL

  • per-ANL per application group/application or protocol rate

Flows may be subject to multiple policers in each direction (from-subscriber-to-network or from network-to-subscriber).

In Figure: From-AA subscriber application-aware bandwidth policing, AA policers are applied after ingress SAP policers. Configuration of the SAP ingress policers can be set to disable ingress policing or to set PIR/CIR values such that AA ISA ingress PIR/CIR are invoked first. This enables application aware discard decisions, ingress policing at SAP ingress is application blind. However, this is a design/implementation guideline that is not enforced by the node.

Figure: From-AA subscriber application-aware bandwidth policing

In the to-AA subscriber direction (Figure: To-AA subscriber application-aware bandwidth policing), traffic hits the AA ISA policers before the SAP egress queuing and scheduling. This allows application aware flow, AA subscriber and node traffic policies to be implemented before the Internet traffic is mixed with the other services at node egress. AA ISA policers may remark out-of-profile traffic which allows preferential discard at an IOM egress congestion point only upon congestion.

Figure: To-AA subscriber application-aware bandwidth policing