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 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: | |
Examples/use cases | ||
|
||
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. | ||
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: | ||
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. |