Application Assurance — App-Profile, ASO and Control Policies

ASOs can be statically assigned in the app-profile; this type of ASO characteristic assignment is typically reserved to the default service options enabled on a large number of subscribers.

Service tier example using ASO, app-profile and AQP shows an example of AA service definition (ASO and app-profile) for a Gold and Bronze service tier definition with the following characteristics:

• Two app-profiles Gold and Bronze

• Gold app-profile — No specific policy actions or ASO characteristics are configured statically in the app-profile.

• Bronze app-profile — A specific ASO characteristic and value is assigned to the profile to limit peer to peer download traffic to 1Mbps (this example does not show the app-qos-policy nor policer configuration, this will be described later).

  

Each app-profile inherits the default values of all the ASO characteristics defined in a AA group-partition; in the preceding example, this is the reason why the app-profile Gold inherits ‟Parental control disabled” and ‟P2P-Sub-DL unlimited”. The app-profile Bronze inherits ‟Parental control disabled” while ‟P2P-Sub-DL 1M” is assigned to this profile statically.

The operator can identify per app-profile which characteristics values are inherited from their default value and which are statically assigned using the following show command:

*A:BNG# show application-assurance group 1:1 policy app-profile "Gold" 
    app-profile "Gold" create
        divert
        characteristic "P2P-Sub-DL" inherits default-value "unlimited"
        characteristic "Parental Control" inherits default-value "disabled"
    exit

A:BNG# show application-assurance group 1:1 policy app-profile "Bronze"            
    app-profile "Bronze" create
        divert
        characteristic "P2P-Sub-DL" value "1M"
        characteristic "Parental Control" inherits default-value "disabled"
    exit

App-profiles enable application assurance services for a given AA-subscriber. Each app-profile is unique in the system and defines the service that the AA subscriber will receive.

To determine which control policies need to be applied to an AA-subscriber, a number of service characteristics (ASO) are associated with each AA-subscriber.

As described earlier, these service characteristics can either be configured directly within the app-profile or assigned using overrides and they are then used as match criteria in AQP policy rules to determine which application policy rules to apply.

The app-qos-policy (AQP) is an ordered list of entries defining policy actions for flows diverted to Application Assurance. Each AQP entry is composed of match criteria and action(s).

Flows are evaluated against all entries of the AA QoS policy defined in the AA group partition that the subscriber app-profile belongs to (in case of a partitioned AA group).

App-Profile, ASO, AQP workflow summary provides a configuration example summary with app-profile, ASO, AQP and policers:

Multiple match criteria can be specified per AQP entry in which case the action will only apply to flows that match all criteria. The most common match criteria are: characteristic, application, app-group and charging-group.

The following AA match criteria can be used in an AQP:

• app-group {eq | neq} <app-group name>

• application {eq | neq} <app name>

• charging-group {eq | neq} <charging-group-name>

• traffic-direction {subscriber-to-network | network-to-subscriber | both}

• characteristic <characteristic-name> eq <value-name>: up to 4 characteristics and values per AQP

• ip-protocol-num {eq | neq} <protocol-id>

• src-ip {eq | neq} <ip-address> or ip-prefix-list <ip-prefix-list-name>

• dst-ip {eq | neq} <ip-address> or ip-prefix-list <ip-prefix-list-name>

• src-port {eq | neq} <port-num> or range <start-port-num> <end-port-num>

• dst-port {eq | neq} <port-num> or range <start-port-num> <end-port-num>

• dscp {eq | neq} <dscp-name>

• aa-sub <aa-sub-name>

AQP actions

The following AA traffic control policies can be specified in an AQP:

• drop

• bandwidth-policer <policer-name>

• flow-count-limit <policer-name>

• flow-rate-limit <policer-name>

• remark dscp in-profile <dscp-name> out-profile <dscp-name>

• remark fc <fc-name>

• remark priority <priority-level>

• http-error-redirect <redirect-name>

• http-redirect <redirect-name> flow-type <flow-type> — Redirect traffic to a landing page

• mirror-source [all-inclusive] <mirror-service-id>

• session-filter <session-filter-name> — Session filter firewall

• url-filter <url-filter-name>: category-based URL filtering using ICAP

• http-notification <http-notification-name>

• Additional drop actions:

  • error-drop: configure a drop action for packets cut-through due to IP packet errors (bad IP checksums, tcp/udp port 0, etc.)

  • overload-drop: configure a drop action for packets cut-through due to overload

  • fragment-drop: configure a drop action for IP fragmented packets

It usually requires the examination of a few packets to identify the protocol/application of a flow. When AQP entries are defined to match on IP header criteria (IP address, IP prefix list, TCP/UDP port number, IP protocol, DSCP) or application criteria (application, app-group or charging group), the AQP action will only be applied to matching application flows after a flow has been classified as a given application.

If the AQP entry does not include match criteria against application (application, app-group and charging-group) or IP header information (IP address, IP prefix list, TCP/UDP port number, IP protocol, DSCP) then the AQP policy will be applied to all matching flows starting with the first packet of a flow before protocol and application identification is complete. Such AQPs are called default subscriber policies.

For an AQP to be qualified as a default subscriber policy, the match criteria must be limited to any combination of ASO characteristic values, traffic direction and optional AA subscriber name.

AQP match and actions for the default QoS policy and application QoS policy are summarized in Default QoS policy, application QoS policy table :

To ensure fair access to the ISA-AA bandwidth and flow resources, it is recommended to configure default AQP policy entries limiting bandwidth and flow resources per AA sub.

Default downstream bandwidth policing shows a default subscriber policy limiting the downstream bandwidth (network-to-subscriber direction) to 25Mbps per subscriber:

Session-filter, url-filter, overload-drop, fragment-drop and error-drop can only be used as part of a default subscriber policy; therefore these actions are not compatible with application or IP header match criteria within the same AQP.

A single flow can match multiple AQP entries, in which case multiple actions can be selected based on the AQP entry’s order (the lowest number entry has the highest priority); the drop action takes precedence over any other AQP entry. The maximum numbers of actions that can be applied on a single flow are:

• 1 drop action

• Any combination of (applied only if no drop action is selected)

  • Up to 1 mirror action

  • Up to 1 FC, 1 priority and 1 DSCP remark action

  • Up to 4 BW policers (1 single rate AA-sub, 1 dual rate AA-sub, 2 single rate system level)

  • Up to 12 flow policers (3 subscriber flow-count, 3 subscriber flow-rate, 3 system flow-count, 3 system flow-rate)

  • Up to 1 HTTP redirect

  • Up to 1 HTTP error redirect

  • Up to 1 HTTP enrichment

  • Up to 1 URL-filter

  • Up to 1 HTTP-notification

  • Up to 1 session-filter firewall

• 1 error drop

• 1 overload drop

• 1 fragment drop

An AQP entry match that would cause the preceding limits to be exceeded is ignored (no actions from that rule are selected) and the conflict counter for this AQP is incremented.

The operator can display hits and potential conflicts per AQP entry using the following show command:

A:BNG# show application-assurance group 1:1 policy app-qos-policy 
===============================================================================
Application QOS Policy Table
===============================================================================
Entry         Admin State                     Flow Hits          Flow Conflicts
-------------------------------------------------------------------------------
30            in-service                              0                       0
-------------------------------------------------------------------------------
No. of AQP entries: 1
===============================================================================

Flows are evaluated against all entries of the AA QoS policy at different steps during the lifetime of the flow:

• Flow creation — The default subscriber policy AQP entries for matching flows are applied starting with the first packet of a flow so before application identification completes.

• Application identification completion— The application QoS policies are applied once flow identification has been completed.

  Note:

  The default QoS policy entries are applied to the subscriber’s flows for packets received before and after application identification is completed.

• Policy change — When a configuration change is applied to the AA policy by executing the commit command on the AA group:partition policy, all diverted flows for subscribers using this policy partition will be evaluated again against all AQP entries. This re-evaluation happens as a paced background task; hence AQP control changes may not be applied immediately to all existing flows.

AA policer templates are configured as part of the AA group configuration by specifying the policer name, type and granularity. Policers are unidirectional by definition so that separate policers must be defined per flow direction if the traffic needs to be policed in both directions (a separate AQP for each flow direction is therefore required as well).

The operator can configure the following types of policers:

• Bandwidth policers

  • Single bucket system level

  • Single bucket flow level

  • Single bucket AA subscriber level

  • Dual bucket AA subscriber level

• Flow count policer: system or AA subscriber level

• Flow setup-rate policer: system or AA subscriber level

Subscriber level policers are instantiated per AA sub, meaning:

• The system automatically uses a dedicated policer for every single subscriber, even when multiple subscribers match the same AQP entry.

• The same policer can be referenced in different AQP entries; in this case all subscribers’ flows matching any of these AQP entries are policed by the same subscriber policer. Example: if the same subscriber level policer ‛1Mbps’ is referenced in AQP entry 100 matching application BitTorrent and in AQP entry 110 matching application EDonkey, then the sum of both the BitTorrent and EDonkey traffic cannot exceed 1Mbps.

System level policers on the other hand are shared by all AA subscribers matching a given AQP entry. These policers are typically used in residential and Wi-Fi service deployments to limit the total bandwidth for an application or application group, for all subscribers or for a group of subscribers on the system or partition. An example would be a system level 500Mbps policer to limit the aggregated downstream bandwidth of peer-to-peer applications for all subscribers with a ‟Bronze” app-profile to 500Mbps.

Single bucket policers police the matching traffic against a configured peak information rate (PIR). Traffic above the PIR can be marked as out of profile or dropped.

The configuration template for a single rate bandwidth policer is as follows:

BNG>config>app-assure# group 1 
    policer <policer-name> type single-bucket-bandwidth 
                                    granularity {subscriber|system} create
        description <string>
        rate <pir-rate-in-Kbps>
        mbs <max-burst-size-in-Kbytes>
        adaptation-rule pir {max|min|closest}
        tod-override <tod-override-id>
        action permit-deny|priority-mark

where:

• action — defines the action that must be taken by the policer for non-conforming traffic.

• permit-deny — non-conforming packets will be dropped.

• priority-mark — non-conforming traffic will be marked as out of profile (increasing the chances that non-conforming packets will be discarded in case of congestion on the egress queues).

• rate — peak information rate in Kbps.

• mbs — maximum burst size in Kbytes.

• adaptation-rule pir <max|min|closest> — The policers work at discrete operational rates supported by the hardware. The adaptation rule specifies how the actual operational policer rate (supported by the hardware) must be selected as compared to the configured PIR. During operation, both the operational and configured rate can be displayed using the operational show application-assurance group <n> policer <policer-name> detail command.

• tod-override — defines a time of day override policy applicable to a policer, this is described in more detail at the end of the policing section.

The following shows a single bucket subscriber level policer configuration example:

BNG>config>app-assure# group 1
    policer "P2P-Sub-DL-1M" type single-bucket-bandwidth granularity subscriber create
        rate 1000
        mbs 19
    exit 

The following shows a single bucket system level policer configuration example:

BNG>config>app-assure# group 1
    policer "P2P-Sys-DL-100M" type single-bucket-bandwidth granularity system create
        rate 100000
        mbs 1875
    exit 

Dual-bucket policers police the matching traffic against a configured peak information rate (PIR) and committed information rate (CIR). Traffic below CIR is marked in profile, traffic between CIR and PIR is marked as out of profile, and traffic above the PIR is dropped.

Dual-bucket policers can only be used as subscriber policers; system policers cannot be defined as dual-bucket policers.

The configuration is similar to the single-bucket policer, but adds the configuration of a CIR and a committed burst size (CBS), and the action cannot be configured:

BNG>config>app-assure# group 1 
    policer <policer-name> type dual-bucket-bandwidth 
                                    granularity {subscriber|system} create
        description <string>
        rate <pir-rate-in-Kbps> cir <cir-rate-in-Kbps>
        mbs <max-burst-size-in-Kbytes>
        cbs <committed-burst-size-in-Kbytes>
        adaptation-rule pir {max|min|closest} cir {max|min|closest}

The following shows a dual-bucket subscriber level policer configuration example:

BNG>config>app-assure# group 1
    policer "P2P-Sub-DL-2M-DB" type dual-bucket-bandwidth granularity subscriber create
        rate 2000 cir 1000
        cbs 19
        mbs 38
    exit 

The default MBS/CBS value of a bandwidth policer is set to 0, but the operator must modify this value to allow proper interworking with TCP-based applications. The network operator must carefully consider the values to be used in production networks based on the applications in the network and several other factors like traffic patterns,traffic volume, bursts, and so on. Nokia recommends to configure a minimum MBS for a bandwidth policer, as follows:

The formula to calculate the MBS or CBS buffer size, as documented in RFC 6349 is:

For Internet applications it is recommended to use a common Round Trip Time (RTT) of 150 msec.

An example using a single bucket subscriber level policer rate of 1000 Kbps:

The default MBS/CBS value of a flow rate limit policer is set to 0, but Nokia recommends to configure a non-zero MBS value for a flow rate limit policer.

Flow rate limit policers police the maximum number of new flows that are accepted per second for matching traffic. The configuration is similar to the single-bucket bandwidth policer, with the rate and MBS now expressed in flows/sec and flows, respectively.

BNG>config>app-assure# group 1
    policer <policer-name> type flow-rate-limit granularity {subscriber|system} create 
        description <string>
        rate <flow-rate-in-flows/sec>
        mbs <max-burst-size-in-flows>
        adaptation-rule pir  {max|min|closest}
        action permit-deny|priority-mark

This type of policer is primarily used for the default subscriber AQP policy in order to limit the maximum number of flow/seconds allocated per AA subscriber.

Flow count limit policers police the maximum number of concurrent flows for matching traffic:

BNG>config>app-assure# group 1
    policer <policer-name> type flow-count-limit granularity {subscriber|system} create  
        description <string>
        action permit-deny|priority-mark 
        flow-count <max-number-of-flows>

This type of policer is primarily used for the default subscriber AQP policy in order to limit the maximum number of concurrent flows allocated per AA subscriber.

For time-of-day (ToD) policer override, up to 8 override rates with time of day specifications can be defined per policer, this time of day override using the system local time.

ToD overrides are supported for all policer types described in the previous section (bandwidth, flow count, and flow rate) and can be configured using either daily or weekly patterns.

The configuration of ToD override on daily or weekly basis is shown in the following template:

BNG>config>app-assure# group 1
    policer "P2P-Sub-DL-1M-TOD" type single-bucket-bandwidth 
                                           granularity subscriber create
        action permit-deny
        rate 1000
        mbs 19
        adaptation-rule pir closest
        tod-override <override-id>
            description <string>
            time-range daily start <start-time> end <end-time> 
                                        [on <day> [<day>...(upto 7 max)]]
            time-range weekly start <day,start-time> end <day,end-time>
            rate 2000
            mbs 38

where:

• tod-override <override-id> — up to 8 override IDs (with value 1-255) can be configured per policer.

• time-range — can be configured to be triggered.

  • On a daily basis at the indicated start/end-time on the specified days.

  • On a weekly basis at the indicated start day and time and end day and time.

  • Times can be indicated as <hh>:<mm> with a 15-minute granularity for the minutes (mm = 0 | 15 | 30 | 45).

A configuration example for a single bucket system level bandwidth policer with the following ToD-override patterns follows:

• Default rate limit: 300Mbps

• Rate limit override to 100Mbps between 5PM and 10PM

• Rate limit override to 200Mbps between 10PM and 12PM

  
  BNG>config>app-assure# group 1
       policer "P2P-Sys-DL-300M-TOD" type single-bucket-bandwidth
                                              granularity system create 
          description "Peer to Peer Policer System level Policer"
          rate 300000
          mbs 5625
          tod-override 1 create
              description "Override busy hour #1"
              time-range daily start 17:00 end 22:00
              rate 100000
              mbs 1875
              no shutdown
          exit
          tod-override 2 create
              description "Override busy hour #1"
              time-range daily start 22:00 end 24:00
              rate 200000
              mbs 3750
              no shutdown
          exit
  

The operator can display which policing rate is applied at any moment in time together with all configured override rates using the following command:

show application-assurance group <n> policer <policer-name> detail

The following configuration provides the app-profile and ASO characteristics used for the default subscriber AQP policy for the 25Mbps and 100Mbps access bandwidth range:

BNG>config>app-assure# group 1:1 policy
    app-service-options
        characteristic "access-rate" create
            value "100M"
            value "25M"
            default-value "100M"
        exit
    exit
    app-profile "1-1/25M" create
        description "25Mbps Site/Subscriber"
        divert
        characteristic "access-rate" value "25M"
        capacity-cost 25
    exit    
    app-profile "1-1/100M" create
        description "100Mbps Site/Subscriber"
        divert
        characteristic "access-rate" value "100M"
        capacity-cost 100
    exit

BNG>config>app-assure# group 1
    policer "DefltPol-Sub-BW-DS-25Mbps" type dual-bucket-bandwidth 
                                                     granularity subscriber create
        description "Deflt downstream BW policer for 25Mbps Subs"
        rate 25000
    mbs

The following AQP entry will act as a default AQP policy because it does not include application or IP header match criteria:

BNG>config>app-assure# group 1:1 policy
    app-qos-policy
        entry 500 create
            description "Deflt downstream BW policer for 25Mbps Subs"
            match
                traffic-direction network-to-subscriber
                characteristic "access-rate" eq "25M"
            exit
            action        
                 bandwidth-policer "DefltPol-Sub-BW-DS-25Mbps"
            exit
            no shutdown
        exit

BNG>config>app-assure# group 1
    policer "DefltPol-Sub-FlowCount-US-25Mbps" type flow-count-limit 
                                                     granularity subscriber create
        description "Deflt policer to limit active upstream flows for 25Mbps Subs”
        flow-count 10000
        action permit-deny
    exit
    policer "DefltPol-Sub-FlowCount-DS-25Mbps" type flow-count-limit 
                                                     granularity subscriber create
        description "Deflt policer to limit active downstream flows for 25Mbps Subs”
        flow-count 10000
        action permit-deny
    exit

The following AQP entry acts as a default AQP policy because it does not include application or IP header match criteria:

BNG>config>app-assure# group 1:1 policy app-qos-policy
    entry 510 create
        description " Deflt policer to limit active upstream flows for 25Mbps Subs"
        match
            traffic-direction subscriber-to-network
            characteristic "access-rate" eq "25M"
        exit
        action
            flow-count-limit "DefltPol-Sub-FlowCount-US-25Mbps"
        exit
        no shutdown
    exit
    entry 515 create
        description " Deflt policer to limit active downstream flows for 25Mbps Subs"
        match
            traffic-direction network-to-subscriber
            characteristic "access-rate" eq "25M"
        exit
        action
            flow-count-limit "DefltPol-Sub-FlowCount-DS-25Mbps"
        exit
        no shutdown
    exit

BNG>config>app-assure# group 1
    policer "DefltPol-Sub-FlowRate-US-25Mbps" type flow-rate-limit 
                                                     granularity subscriber create
        description "Deflt policer to limit upstream flow setup rate for 25Mbps Subs”
        rate 200
        action permit-deny
    exit
    policer "DefltPol-Sub-FlowRate-DS-25Mbps" type flow-rate-limit 
                                                    granularity subscriber create
        description "Deflt policer to limit downstr flow setup rate for 25Mbps Subs"
        rate 200
        action permit-deny
    exit

The following AQP entry acts as a default AQP policy because it does not include application or IP header match criteria:

BNG>config>app-assure# group 1:1 policy app-qos-policy
    entry 520 create
        description "Deflt policer to limit upstream flow setup rate for 25Mbps Subs"
        match
            traffic-direction subscriber-to-network
            characteristic "access-rate" eq "25M"
        exit
        action
            flow-rate-limit "DefltPol-Sub-FlowRate-US-25Mbps" 
        exit
        no shutdown
    exit
    entry 525 create
        description "Deflt policer to limit downstr flow setup rate for 25Mbps Subs"
        match
            traffic-direction network-to-subscriber
            characteristic "access-rate" eq "25M"
        exit
        action
            flow-rate-limit "DefltPol-Sub-FlowRate-DS-25Mbps"
        exit
        no shutdown
    exit

The following configuration example provides a per AA subscriber peer-to-peer rate limit of 1Mbps. It does not include the app-profile configuration because the ASO characteristic and values can be either statically configured within the app-profile or dynamically signaled through RADIUS or Gx using ASO overrides.

AA subscribers with service characteristic "P2P-Sub-DL" value of "1M" will have a bandwidth policer of 1Mbps applied to peer to peer traffic in the network to subscriber direction:

BNG>config>app-assure# group 1
    policer "P2P-Sub-DL-1M" type single-bucket-bandwidth granularity subscriber create
        description "Per-subscr BW policer to limit P2P downstream traffic to 1Mbps"  
        rate 1000
        mbs 19
        action permit-deny
    exit

BNG>config>app-assure# group 1:1 policy 
    app-service-options
        characteristic "P2P-Sub-DL" create
            value "10M"
            value "1M"
            value "unlimited"
            default-value "unlimited"
        exit

BNG>config>app-assure# group 1:1 policy app-qos-policy
    entry 30 create
        description "Per-subscr BW policer to limit P2P downstream traffic to 1Mbps"
        match
            app-group eq "Peer to Peer"
            traffic-direction network-to-subscriber
            characteristic "P2P-Sub-DL" eq "1M"
        exit
        action
            bandwidth-policer "P2P-Sub-DL-1M"
        exit
        no shutdown
    exit