AA group policies

Components

An AA group policy includes the following components, as required:

The following table describes the components.

Component

Description

Application

Identifies the type of IP payload in the subscriber flow

An application provides a definition and description to the application names supported by an application filter.

Defaults

One predefined application (“unknown”) is provided. The unknown application cannot be modified.

All other applications must be configured.

Examples/use cases

Webscale companies, CORBA, DNS Server

Notes

The application name is a key match criterion within the AQP rules that are applied to the IP traffic of a subscriber. The application name is also the unique identifier of the application object for reporting systems such as the NSP Analytics application.

Network operators can change the application group that an application is associated with, or view the application filters that define the application.

Application group

A container for multiple applications

Defaults

A set of default application groups is provided. At least one default application group (“unknown”) must be associated with each NE. The default application groups cannot be modified.

Examples/use cases

File hosting, gaming, mail, peer to peer

Notes

Multiple applications can be assigned to an application group. An application can only belong to one group.

Applications that are not assigned to an application group are automatically placed in the “unknown” application group.

Charging group

A set of applications that you need to bill for in a specific way, such as usage-based billing

Defaults

If an application is not associated with a charging group, a default charging group is assigned.

If tethering detection or flow attribute matching is in use with 7450 ESS, a default tethered charging group can be configured.

Examples/use cases

Applications that are free to the end user can all be associated with a zero-rate charging group.

A use case for charging groups is bill-shock avoidance.

Application profile

Enables AA service for traffic to and from an ESM subscriber, ESM subscriber host, SAP, or spoke SDP. Each application profile is unique and defines the AA service that the AA subscriber receives. The type of traffic is configured in the system-wide configuration of QoS FCs to be diverted to the ISA-AA MDA for subscribers with AA enabled. The FC is used for any subscriber traffic that a service provider needs to inspect using AA.

A subscriber can be assigned an application profile that affects every host of the subscriber. For SAP or spoke SDP AA subscribers, an application profile can be assigned that affects the traffic originating from or destined for the SAP or spoke SDP.

For subscribers with application profiles that enable AA, traffic is diverted to the active ISA-AA MDA using ingress QoS policy filters. The filters identify classes that can be diverted for AA. The system identifies and diverts traffic for any subscriber to the ISA-AA MDA, according to the application profile. Diversion to the ISA-AA MDA depends on the ISA-AA MDA status. If a subscriber is not configured to divert traffic to the ISA-AA MDA, normal ingress forwarding occurs.

Defaults

One predefined application profile (“default”) is provided.

By default, subscribers are not assigned to an application profile and traffic is not diverted for AA analysis.

Notes

  • Application profiles are customer-defined and created using the configured ASO characteristics.

  • Application profiles allow ASO characteristics to be associated with AA subscribers.

  • Local instances of the application profile are configured to bind to specific objects of an NE (for example, L2 access interface, SAP, local subscriber explicit map entry, and so on).

  • Application profiles can be assigned only when ISA-AA cards are assigned to an ISA-AA group.

  • Global application profiles must be manually distributed to the NEs.

  • Application profiles can be assigned a capacity cost for subscriber load balancing among ISAs within the AA group.

Application filter

Application filters are provided as an indirect action between protocols and applications to allow the addition of variable parameters, for example, port numbers and IP addresses, to an application definition. An application filter contains numbered entries that define the use of protocol signatures and other application criteria. Multiple filter entries can be used to define an application, but each application filter entry maps to one application.

Notes

A traffic flow may have multiple filter entries. The entries are applied to the flow sequentially, and the matching entry with the lowest ID value is applied first. A traffic flow can be assigned to only one application.

You can accommodate the insertion of new entries in a list of entries by renumbering one or more of the existing entries using a GUI or OSS client. See To renumber application filter entries for information about renumbering application filter entries using the GUI.

An application must be configured before the associated application filter is defined.

Application service option (ASO)

A series of operator-defined application characteristics that define the service provider and customer network functions that are common to sets of subscribers

ASOs prevent subscribers from requiring each subscriber-specific entry in the application QoS policies for standard network services.

ASOs are assigned one or more characteristic values to define service offerings to customers.

ASO characteristics are used:

  • as input to application profiles

  • by application QoS policies to influence how specific traffic is checked and how policies are applied

Examples/use cases

  • Entry for each managed application group; for example, VoIP, P2P, and HTTP

  • Multiple entries where specific applications in an application group can be individually managed as service parameters; for example, HTTP content from a specific content provider, or streaming video from network television or games

  • HSI tiers, for example, Gold, Silver, and Bronze, that specify bandwidth levels

  • Bandwidth parameters for each service option

Notes

You can configure ASO characteristics for a subscriber using an AA subscriber policy override. An AA subscriber policy override can be configured for a SAP or spoke SDP binding. The AA subscriber must have an application profile assigned, or the subscriber policy override is rejected.

You can retrieve on demand the ASO values that are assigned to a SAP or spoke SDP binding subscriber from the properties form of the subscriber.

In a typical application, ASOs define the HSI service parameters.

  • ASOs are optional; AA can check the subscriber IP traffic without the use of application service options.

  • ASOs can be configured for each AA group policy.

  • ASO characteristics are used to define application profiles and operator-defined AQP rules.

  • The set of ASOs represent network-wide menus of service capabilities that are available to subscribers.

Application QoS policy (AQP)

List of rules that define the match criteria and action to be performed on all traffic flows. The AQP rules use the application groups, applications, and so on, as the match criteria. The output of the AQP rules defines the policy actions to perform.

Notes

AQP rules consist of match and action criteria:

  • Match—Refers to the criteria used to identify a flow in order to apply actions such as dropping, forwarding, mirroring, and policing of bandwidth and flow. Matches cannot be made against protocols.

    Match criteria can be a combination of the following:
    • applications or application groups

    • ASO characteristics

    • flow direction

    • AA subscribers

    • flow source or destination IP address and/or port

    • flow attributes

  • Action—Defines AA actions to be applied to traffic. For example, you can apply a set of actions such as bandwidth policing, packet discards, QoS remarking, and rate limiting to a flow.

Custom protocols

Configurable strings of up to 16 hexadecimal octets for pattern-matched application identification in the payload of TCP- and UDP-based applications

The match applies to the client-to-server, server-to-client, or any direction for TCP-based applications, and to any direction for UDP-based applications.

Notes

You can configure a custom protocol description, custom protocol ID, and shutdown. When a custom protocol is administratively disabled, traffic is identified as though the protocol is not configured.

Custom protocols and Nokia protocols are distinct; the span of a custom protocol is limited to the group or partition associated with an AA policy. Nokia protocols span all groups and partitions. All application filter entries, except strings, are supported. Custom protocol statistics collection on an ISA-AA partition group or special study subscriber is supported.