3.2.1.1.1. AA Group Partitions

VPN-specific AA services are enabled using operator defined partitions of an AA Group into AA policy partitions, typically with one partition for each VPN-specific AA service. The partition allows VPN specific custom protocols/application/application group definition, VPN specific policy definition and VPN specific reporting (some VPNs with volume-only reports, while others with volume and performance reports). Each partition’s policy can be again divided into multiple application QoS policies using ASOs.

The use of ISA groups and partitions also improves scaling of policies, as needed with VPN-specific AA policies.

If partitions are not defined, all of the AA group acts as a single partition. When partitions are configured, application identification, policy and statistics configuration applies only to the given partition and not any other partitions configured under the same AA group.

The definition of application profiles (and related ASO characteristics/values) are within the context of a given partition (however, application profiles names must have node-wide uniqueness).

The definition of applications, application groups and AQP are also specific to a given partition. This allows:

Partitions also enable accounting/reporting customization for every AA subscriber associated with a partition, for example:

The system provides independent editing and committing of each partition config (separate begin/commit/abort commands).

Policer templates allow group-wide policing, and can be referenced by partition policies.

3.2.1.1.2. Bypass Modes

If no active AA ISA is available (for example, due to an operational failure, misconfiguration) the default behavior is to forward traffic as if no AA was configured, the system does not send traffic to the AA ISA (equivalent to fail to closed). Alarms are raised to flag this state externally. There is an optional “fail to open” feature where AA ISA service traffic is dropped if no active AA ISA is present (such as no AA ISA is present and operationally up).

3.2.1.2.1. No AA ISA Group Redundancy

AA can be configured with no ISA redundancy within the AA group. All AA ISAs are configured as primary with no backup (up to the limit of active AA ISAs per node). There is no fault state indicating that a spare AA ISA is missing. If a primary is configured but not active, there will be a “no aa-isa” fault.

3.2.1.2.2. Failure to Fabric

In the event that no ISA redundancy is deployed or insufficient ISAs are available for needed sparing, the system implements “failure to fabric”. When the ISA status shows the ISA is not available and there is no redundant ISA available, the ingress IOMs simply do not divert the packets that would have been sent to that ISA, but instead these proceed to the next hop directly across the fabric. When the ISA becomes available, the divert eligible packets resume divert through the ISA. This behavior is completely internal to the system, without affecting the forwarding or routing configuration and behavior of the node or the network.

3.2.1.2.3. N+1 AA ISA Card Warm Redundancy

The system supports N+1 AA ISA equipment warm redundancy (N primary and 1 backup). If a backup is configured and there is no ISA available (a primary and backup failed), there will be a “no aa-isa” fault. The backup AA ISA is pre-configured with isa-aa.tim and the group policies. Data path traffic is only sent to active AA ISAs, so the backup has no flow state. If a backup ISA is unavailable, there will be a “backup missing” fault.

An AA subscriber is created and assigned to a primary AA ISA when an application profile is assigned to a subscriber, SAP, or spoke SDP. By default, AA subscribers are balanced across all configured primary AA ISAs.

Upon failure of a primary AA ISA, all of its AA subscribers and their traffic are operationally moved to the newly active backup AA ISA but the current flow states are lost (warm redundancy). The new AA ISA will identify any session-based active flows at a time of switchover as an existing protocol, while the other flows will be re-identified. The existing protocol-based application filters can be defined to ensure service hot redundancy for a subset of applications. Once the backup AA ISA has taken control, it will wait for operator control to revert activity to the failed primary AA ISA module.

The user can disable a primary AA ISA for maintenance by triggering a controlled AA ISA activity switch to do the AA ISA software field upgrade (a shutdown of an active AA ISA is recommended to trigger an activity switch).

The activity switch experiences the following AA service impact:

3.2.1.4.1. Asymmetry Removal Overview

Figure 11 shows an overview of the multi-chassis asymmetry removal functionality.

Figure 11:  Multi-Chassis Asymmetry Removal Functional Overview  

For a Multi-homed parent AA subscriber, the parent SAP/SDP that is Active/Inactive per chassis is agreed by the inter-chassis AA Redundancy Protocol (AARP). For single node multi-homed endpoints, the AARP state is determined within a single node, as explained later in the AARP operational states section.

3.2.1.4.2. Failure Modes

Failure modes include the following:

3.2.1.4.3. AARP Peered Node/Instance Configuration

The multi-homed diverted AA subscriber in each peer node must be configured with the following parameters set in each node of the peer pair as follows:

AARP operation has the following required dependencies:

3.2.1.4.4. Multi-Chassis Control Link (MC-CTL)

A multi-chassis control link is automatically established between peer AARP instances to exchange configuration and status information. Information exchanged includes configured service, protecting SAP, spoke, redundant-interface name, shunt-sdp, app-profile, priority and operational states.

AARP requires configuration of the peer IPv4 system address in order to establish a session between the two node’s system IPv4 addresses.

3.2.1.4.5. Multi-Chassis Datapath Shunts

When traffic needs to be remotely diverted it flows over shunts that are provisioned as sdp-id:vc-id between the dual-homed AA subscriber local service and a remote vc-switching Ipipe.

Subscriber to Network Direction

The traffic is either handled locally (diverted to a local ISA when the AARP state is Master) or at the peer 7750 SR (redirect over the shunt Ipipe when the local AARP state is Backup or Remote). When traffic arrives on the subscriber side spoke SDP of the shunt-Ipipe, the system uses the AARP ID of the Ipipe to associate with an app-profile, hence triggering Ipipe divert. It is diverted to the same ISA used to service the dual-homed SAP or spoke SDP. The ISA then treats this traffic the same as if it was received locally on the dual-homed SAP or spoke SDP context. After ISA processing, the traffic returns on the network side of the Ipipe to the peer. When the traffic returns to the original 7750 SR, the shunt Ipipe terminates into the routed service and it makes a new routing decision.

Network to Subscriber Direction

The traffic is either handled locally (diverted to a local ISA when the AARP state is Master) or at the peer 7750 SR (remote divert over the shunt Ipipe when the local AARP state is Backup or Remote). When traffic arrives on the shunt Ipipe from the peer with an AARP ID and associated app-profile, it is diverted through AA on the way to the subscriber-side spoke SDP. After AA processing, the traffic returns on the subscriber side of the Ipipe to the peer. When the traffic returns to the original 7750 SR, the shunt Ipipe terminates into the routed service and it makes a new routing decision to go out the dual-homed SAP or spoke SDP.

AARP Operational States

In single node operation, there are two operational states, Master or Standalone. A single node AARP instance is Master when all these conditions are met, otherwise AARP is in the standalone state with is no asymmetry removal occurring:

With multi-chassis operation there are 4 operational states for an AARP instance: master, backup, remote and standalone.

An AARP instance activity switch is when one node moves from Master to remote or backup mode, with the peer node becoming Master. This can occur on a per-instance basis using the re-evaluate tool, or for all instances on an ISA that fails. On an AARP activity switch, AA divert changes from local to remote (or vice versa) such that any given packet will not be seen by both nodes, resulting in no missed packet counts or double counts against the AA subscriber.

AARP activity is non-revertive, in order to maximize the ID accuracy of flows. When an AARP instance toggles activity, packets are diverted to the newly active divert ISA and are processed as new flows, which for mid-session flows will often result in “unknown” traffic ID until those flows terminate. When the condition that triggered the AARP activity switch is resolved and the instance remains in backup state, in order to not cause an additional application ID impacting event. This is consistent with AA N+1 ISA activity switches.

Because AA ISA availability is a criteria for AARP switches, any ISA failure or shutdown will move all AARP instance activity to ISAs in the master peer nodes, such as during software upgrades of ISAs. Depending on the nature of the failure or sequence of an upgrade procedure, all AA traffic may be processed by ISAs in one of the peers with no traffic being processed by ISAs on the other node.

If it is desired to rebalance the ISA load between the peer nodes, there is a tools> perform>application-assurance>aarp aarp-id>force-evaluate command re-runs AARP activity evaluation on a per-ISA basis to determine Master/Backup AARP based on configured priority.

Table 6 shows the interaction and dependencies between AARP states between a local node and its peer.

3.2.2.1.1. Services and AA Subscribers

The 7750 SR and 7450 ESS AA ISA provides, for Layer 3 to Layer 7, packet processing used by the AA feature set. AA is applied to IPv4 and IPv6 traffic on a per-AA subscriber basis, where an AA subscriber is one of the following:

Non-IPv4 and IPv6 traffic is not diverted to AA and is forwarded as if AA was not configured; however, AA divert is supported for IP over PPPoE on Layer 2 (Epipe or VPLS) SAPs. An AA subscriber can be contained in the following services:

AA is supported with:

The AA ISA feature set uses existing 7750 SR or 7450 ESS QoS capabilities and further enhances them to provide application-aware traffic reporting and management on per individual AA subscriber, AA subscriber-type or group. A few examples of per-application capabilities within the above AA subscriber contexts include:

The following restrictions are noted — AA is not supported for tunneled transit traffic (GRE or L2TP tunnels using PPP or DHCP based policy) destined for a remote BRAS.

3.2.2.1.2. Spoke SDPs

AA on spoke SDP services allows AA divert of the spoke SDP, logically representing a remote service point, typically used where the remote node does not support AA. A given SAP or spoke SDP can be assigned an app-profile, and when this app-profile is enabled for divert all packets to and from that SAP or spoke SDP will be diverted to an AA ISA (for forwarding classes that are configured as divert eligible).

Table 7 shows spoke SDP divert capabilities.

Spoke SDP divert is only supported on services to/from IOM3-XP or newer IOMs or IMMs.

3.2.2.1.3. Transit AA Subscribers

A transit AA subscriber is an ISA local AA subscriber contained within a parent AA subscriber. There are two types of transit AA subs:

A transit AA subscriber incorporates the following attributes:

When a SAP or spoke-SDP diverted to AA is configured with transit subs, that SAP or Spoke-SDP is referred to as the parent AA subscriber. Transit AA subscribers are supported on the parent SAPs or spoke SDPs that support AA divert.

Table 8 lists the Transit AA subscriber support.

The transit AA subscribers within a given parent AA subscriber can be displayed using the show application-assurance group transit-ip-policy or transit-prefix-policy command.

For transit IP AA subscribers all packets are accounted for once in the ISA records. Therefore, transit IP AA subscriber counts do not count against the parent SAP in reporting. For transit prefix AA subscriber deployments using the remote-site command, traffic for the remote transit subs are processed and counted for both the local parent and the remote transit subscriber.

3.2.2.1.3.3. Static-remote-aa-sub Command

Figure 14:  Static-remote-aa-sub Usage Topology 

This command enables unique ISA treatment of transit prefix subscribers configured on the opposite (remote) side of the system from the parent SAP or spoke SDP. Provisioning a transit sub as remote-aa-sub within a transit prefix policy enables the ISA to treat any network IP-based transit subs in the following ways:

1. Treat packets for the parent AA subscriber independent of whether transits are also configured (stats and policers for parent work as usual).
2. Subsequently treat the same packet as a transit-sub packet when matching to a configured transit sub (stats, policers).
3. Allows natural direction of the packet for both the parent AA subscriber and the transit-AA subscriber, as shown in Figure 14, where a packet from a remote client to a local server will be seen as to-sub for the parent, and from-sub for the transit sub that is logically at the far end site.
4. Correct directionality of packet ID for all AA subscribers allows proper operation of app-filter flow-setup-direction.

3.2.2.1.3.6. RADIUS Transit AA Subscribers

Transit subs can be dynamically provisioned by RADIUS accounting start messages forwarded by the RADIUS AAA server to a RADIUS sub-manager function at the OSS layer. This RADIUS sub manager manages dynamic transit AA subscribers on the appropriate ISA and transit-ip-policy based on the RADIUS accounting information. The interface for the sub manager to configure transit AA subscribers is RADIUS CoA messages, which are acknowledged with a CoA success message to the sub manager.

If a dynamic transit sub cannot be created as requested by a CoA due to resource constraints or conflicts, the node replies to the sub manager with a CoA fail message so that retries will not continue. This message should contain information as to the cause of the rejection. Multiple IPs per sub are allowed when common sub-ID names are seen, but with differing IP hosts.

When a RADIUS update or CoA message is seen, it could contain a modified IP address or app-profile for an existing transit sub which is accepted without affecting transit AA subscriber statistics. These transit AA subscribers are removed by the sub manager when a RADIUS accounting stop message is received.

Figure 15 shows a RADIUS CoA Example.

Figure 15:  RADIUS COA Example 

The attributes in RADIUS COA that identify the downstream transit AA subscribers are:

1. Downstream BRAS/ CMTS: NAS-port-ID
2. IP address: framed-ip-address
3. Subscriber ID: per RADIUS accounting sub-id-string

3.2.2.1.3.8. Diameter Transit AA Subscriber

For Diameter transit AA subscribers, AA auto-detects new IP addresses and notifies the PCRF of new subscribers via a Gx CCR-I message. The PCRF locates the subscriber’s AA policy and returns the information via CCA-I message to AA.

Figure 16 shows a 3GPP pull model, whereby AA initiates the Gx session. Table 9 describes the figure. The PCRF can, at any time after the session is established, push new policies using a RAR message. New policies can include new usage-monitoring or AA ASO values.

Figure 16:  3GPP Pull Model 

Table 9:  3GPP Pull Model Description 

Legend	Description
1	AA detects a new IP address, and sends a CCR-I containing the subscriber-side IP address
2	CCA(I) contains subscriber AA policy information
3	AA applies an AA appProfile, ASOs, and any AA usage monitoring
4	AA reports usage counters for all specified or enabled usage monitoring keys, and removes the sub

The CCR-I message from the 7750 SR node to PCRF contains the following:

1. Session ID
2. Subscriber-side IP address
3. IP-CAN-Type AVP (if enabled) with the value “tbc”
4. Subscription ID AVP, with the following characteristics (if avp-subscription-id is configured as subscriber-id):
   1. Type: END_USER_E164 (private by default)
   2. ID: auto-generated unique ID
5. Destination-Realm as configured in Diameter-Peer-Policy
6. Destination-Host if configured in Diameter-Peer-Policy

The CCA-I message from PCRF to the 7750 SR node contains the following:

1. Session ID
2. Charging-Rule-Install containing the following information:

        Charging-Rule-Definition ::=<AVP Header: 1003>

                {Charging-Rule-Name}

                [TDF-Application-Identifier]

                [Monitoring-Key]

                [AA-Functions {]

                        AA profile

                        AA-App-Service-Options {

                                AA-App-Service-Options-Name

                                AA-App-Service-Options-Value

                ........

                [AVP]

1. Charging-Rule-Name
   1. Usage monitoring: Starts with “AA-UM:”
   2. AppProfile and ASOs: Starts with “AA-Functions:”
2. AA-Functions: AVPs to set AA profile and ASO values
3. TDF-application-identifier: This field specifies a predefined AA charging group, application group, or application name for which usage monitoring functionality is required.

Termination of the Gx session is only done after AA receives an RAR-T message from PCRF with the session-release-cause AVP meeting the configured threshold. After replying to an RAR message with an RAA message, AA sends a CCR-T message with reports of usage counters, if any are enabled.

Table 10 lists the AVPs used for Diameter transit AA subs.

Table 10:  Used AVPs 

AVP	Category	Details	User Configurable
Session-Id	M	Globally unique Generated for each session as: <peer identity>;<high 32 bits>;<low 32 bits>;[<optional value>;]<subscriber ip>	N
Origin-Host	M	Configurable under aaa>diameter-peer-policy	Y
Origin-Realm	M	Configurable under aaa>diameter-peer-policy	Y
Destination-Realm	M	Configurable under aaa>diameter-peer-policy	Y
Auth-Application-Id	M	Set as Gx (16777238)	N
CC-Request-Type	M	Set to INITIAL_REQUEST (1) when initiating a new session Set to TERMINATION_REQUEST (3) when ending a session Set to UPDATE_REQUEST (2) in all other situations	N
CC-Request-Number	M	Generated internally according to Gx specifications Request numbering starts at 0	N
Subscription-Id	M	Configurable using Subscription-Id-Type and Subscription-Id-Data	—
Subscription-Id-Type	M	Configurable under subscriber-mgmt>diameter-application-policy>gx>avp-subscriber-id origin	Y
Subscription-Id-Data	M	Configurable under subscriber-mgmt>diameter-application-policy>gx>avp-subscriber-id origin [type type]	Y
Framed-IP-Address	M	Set to the subscriber’s IP address as seen by AA-ISA in the from-sub direction of the data traffic	N

When the Subscription-Id-Type is “Subname”, then Subscription-Id-Data is auto-generated by AA to be unique node-wide, using the transit IP policy, SAP, and sub IP address.

Unlike AA ESM Diameter-controlled subscribers, transit Gx AA subscribers are not required to support ADC rules over Gx.

Transit Gx AA subscribers use PCC rules as per ESM Diameter AA subscriber implementation, and therefore uses AA-Function AVP.

For transit Gx AA subs, similarly to ESM Gx-controlled subs, the PCRF can set the subID in a CCR-I by sending a PCC rule with the name of the charging rule prefixed with “sub-id:”. The AVP appears as follows:

charging-rule-install (1001) VM------ [44]

     vendor-id TGPP

     data [32] (Grouped)

          charging-rule-name (1005) VM------ [30]

               vendor-id TGPP

               data [18] (UTF8String) : Sub-Id:subID-name

In addition to using the AA Function AVP, AA supports the configuration of the application profile and ASOs by the PCRF via a CCR-I, CCR-U, or RAR that has PCC rules with the name of the charging rule prefixed with “AA-Functions:App:” or “AA-Functions:ASO”, such as:

charging_rule_install[0].charging_rule_name[0] = AA-Functions:App:<name>

charging_rule_install[0].charging_rule_name[1] = AA-Functions:Aso:<char>:<val>

...

charging_rule_install[0].charging_rule_name[n] = AA-Functions:Aso:<char>:<val>

AA allows for the definition of up to 32 ASOs. If the number of ASOs is larger than what can fit within a single charging-rule-install AVP, multiple charging-rule-install AVPs can be used in the CCR-I message.

As the Gx protocol is already supported by the 7750 SR/VSR system, there are no new configurations required. All existing configurations introduced to support ESM Gx control on a BNG can be re-used in AA transit deployment.

3.2.2.1.4. AA Subscriber Application Service Definition

Application Profile

Application profiles enable AA service for a given ESM or DSM subscriber, Service Access Point or spoke SDP (AA subscriber). Each application profile is unique in the system and defines the AA service that the AA subscriber will receive. An ESM subscriber can be assigned to an application profile which affects every host of the particular subscriber. For SAP or spoke SDP AA subscribers, an application profile can be assigned which affects all traffic originated/destined over that SAP or spoke SDP. By default, ESM and DSM subscribers, SAPs or spoke SDPs are not assigned an application profile.

The following are main properties of application profiles.

ESM and DSM policy includes an application profile string. The string points to an application profile pre-provisioned within the router and is derived by:

Mid-session (PPP/DHCP) changes to the application profile string allows:

Figure 17 shows the process for determining the subscriber profile, SLA profile, and application profile of a host.

Figure 17:  Determining the Subscriber Profile, SLA Profile and Application Profile of a Host 

Application Profile Map

AA adds new map (app-profile-map) application profile command to associate an app-profile-string from dynamic subscriber management to a specific application profile using its app-profile-name that has been pre-provisioned. The application profile map is configured in the config>subscr-mgmt>sub-ident-pol context.

The pre-defined subscriber identification policy has to be assigned to a SAP, which determines the sub-id, sub-, sla-, and app-profiles.

Application Service Options (ASOs)

ASOs are used to define service provider and/or customer visible network control (policy) that is common between sets of AA subscribers (for example, upstream/downstream bandwidth for a tier of AA service). ASO definition decouples every AA subscriber from needing subscriber-specific entries in the AQP for standard network services.

As an example, an operator can define an ASO called ServiceTier to define various HSI services (Super, Lite, and so on) (Figure 18-A). The operator can then reference these defined ASOs when creating the App Profiles that are assigned to AA subscribers (Figure 18-B).

Figure 18:  Configuration Example 

Then, the defined ASOs are used in the AQP definition to determine the desired treatment or policy (Figure 19).

Figure 19:  AQP Definition Example 

Alternatively, if ASOs were not used in the previous example, then the operator would have to define a unique AQP entry for every subscriber. Each of these AQPs will have its “match” criteria setup to point to the subscriber ID, while the action for all of these unique AQPs will be the same for the same service (for Tier 1 service, the policer bandwidth will be the same for all Tier 1 AA subscribers) (Figure 20).

Figure 20:  Single ASO Example 

The example in Figure 20, shows how the use of just a single ASO can save the user from having to provision an AQP entry every time a subscriber is created.

Other example uses of ASO entries include:

Application characteristics are defined as specific to the services offered within the operator network. The operator defines ASO characteristics and assigns to each ASO one or more values to define service offering to the customers.

The following are the main elements of an ASO:

The following lists how ASO characteristics are used:

Syntax checking is performed when defining application profiles and AQPs that include application characteristics. This ensures:

ASO Overrides

This feature enables individual attributes/values to be set against an AA subscriber complementary to using app-profiles. The AA subscriber types supported that can have ASO overrides by CLI/SNMP are provisioned business AA SAPs and spoke SDPs, and statically-provisioned transit AA subs. ESM and transit-aa AA subscribers can have ASO overrides applied by RADIUS override VSAs.

Application profile assignment is still used to obtain the following information:

The information configured in the app-profile is also used, but the following can be overridden:

The overrides are specific to a single AA subscriber. An ASO override does affect any other AA subscriber or the app-profile config itself.

Typically the ASO characteristics in the app-profile would not be specified, thus leaving all characteristics at their default values. This is not mandatory though and the app-profile could specify any ASO characteristic and non-default value.

The AQP has entries that can refer to ASO characteristics (attributes) and values in their match criteria. In the absence of any individual attribute/value override, an AA subscriber will continue to work as before - using the ASO characteristics/values defined inside the app-profile assigned to them. With overrides, the AA subscriber attributes used in AQP lookups are the combination of the following:

Show command output display the combined set of attributes that apply to the AA subscriber.

The override commands can only be used if there is already an app-profile assigned to the AA subscriber, otherwise, the overrides are rejected.

The app-profile attribute override is assigned to a specific AA subscriber (SAP, spoke SDP) within the AA Group:partition with where the subscriber exists. While subscriber names are unique, the Group:partition policy context where apps, app-profiles and ASO characteristics are defined is relevant to the override context. Override for ESM subscribers can be triggered via DIAMETER or RADIUS.

AA Subscriber Scale Mode and ASOs

When an AA policy is administered using a per-AA subscriber policy attribute assignment (ASO override) as opposed to using a service profile-based model, the number of attributes and values of ASOs that are needed in an AA Group can be much larger than the ASO scale needed for app-profile based deployments.

In conjunction with the App-profile ASO override, set the AA-group to a mode optimized for the needed ASO, subscriber, and flow scale requirements.

3.2.2.2.1. Application Assurance Identification Components

Figure 21 shows the relationship between the AA system components used to identify applications and configure AA-related capabilities. Each ID-related component is defined as follows:

Table 11 provides an overview of how those various components are used in AA to recognize types of flows and sessions.

3.2.2.2.2. Protocol Signatures

The set of signatures used to identify protocols is generated by Nokia and included with the AA software load. The signature set includes:

Dynamic upgrades of the signatures in the system are implemented by invoking an admin application-assurance upgrade command and then performing AA ISA activity switches.

The protocol signatures are included in aa-isa.tim software load which is not tightly coupled with software releases allowing for protocol signature updates without upgrading and impacting of routing/forwarding engines as part of an ISSU upgrade that updates only the AA ISA software. Refer to upgrade procedures described in the SR OS 21.x.Rx Software Release Notes for detailed information.

Since protocol signatures are intended to be the most basic block of Application Identification, other AA components like Application Filters are provided to further customize Protocol Signatures allowing operators to customize their applications and to reduce a need for a new Protocol Signature load when a new Application may need to be identified. This architecture gives operators more flexibility in responding to ever changing needs in application identifications.

Signature upgrade without a router upgrade is allowed within a major router release independently of system ISSU limits. An AA ISA signature upgrade is supported before the first ISSU router release (for example, operators can upgrade signatures for pre-ISSU minor releases).

In addition, any router release from ISSU introduction release can run any newer aa-isa.tim image within the same major release by performing an aa-isa.tim single step upgrade. For example, release 8.4 may be upgraded in a single step to run release 8.14 of isa-aa.tim.

Each protocol, except internal protocols used for special-case processing statistic gathering (cut-though, for example), can be referenced in the definition of one or multiple applications (through the App-Filter definition). Assignment of a supported protocol to an app-filter or application is not mandatory. Protocols not assigned to an application are automatically mapped by the system to the default Unknown application.

3.2.2.2.3. Custom Protocols

Custom protocols are supported using configurable strings (up to 16 hex octets) for pattern-matched application identification in the payload of TCP or UDP based applications (mutually exclusive to other string matches in an app-filter).

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

There is a configurable description and custom protocol id for a protocol, with configurable shutdown. When disabled, traffic is identified as if the protocol was not configured.

Custom protocols and ALU-provided protocols are functionally equivalent. Custom protocols are used in application definition without limitations (all app-filter entries except strings are supported). Collection of custom protocol statistics on a partition/ISA group/special study sub level is supported.

3.2.2.2.4. Protocol Shutdown

The protocol shutdown feature provides the ability for signature upgrades without automatically affecting policy behavior, especially if some or even all new signatures are not required for a service. All new signatures are disabled on upgrade by default to ensure no policy/service impact because of the signature update.

All protocols introduced at the R1 stage of a given release are designated as “Parent” signatures for a given release and cannot be disabled.

Within a major release, all protocols introduced post-R1 of a major release as part of any isa-aa.tim ISSU upgrade are by default shutdown. They must be enabled on a per-protocol basis (system-wide) to take effect.

When shutdown, post R1-introduced protocols do not change AA behavior (app-id, policy, statistics are as before the protocol introduction), for example, traffic maps to the parent protocol on which the new signature is based. In cases where there is more than one parent protocol, all traffic is mapped to a single, most-likely, parent protocol. For example if 80% of a new protocol has traffic mapping to unknown_tcp, and 20% mapping to another protocols, unknown_tcp would be used as parent.

Enabling/disabling of a new protocol takes affect for new flows only. The current status (enabled/shutdown) of a signature and the parent protocol is visible to an operator as part of retrieving protocol information through CLI/SNMP.

3.2.2.2.5. Supported Protocol Signatures

Protocol signatures are release independent and can be upgraded independently from the router’s software and without impacting router’s operations as part of an ISSU upgrade. A separate document outlines signatures supported for each signature software load (isa-aa.tim). New signature loads are distributed as part of the SR/ESS maintenance cycle. Traffic identified by new signatures will be mapped to an Unknown application until the AA policy configuration changes to make use of the newly introduced protocol signatures.

3.2.2.2.6. Application Groups

Application groups are defined as a container for multiple applications. The only application group created by default is Unknown. Any applications not assigned to a group are automatically assigned to the default Unknown group. Application groups are expected to be defined when a common policy on a set of applications is expected, yet per each application visibility in accounting is required. The application group name is a key match criteria within application QoS policy rules.

3.2.2.2.7. Charging Groups

Charging Groups allow usage accounting by application and/or app groups in a manner that does not affect app to app-group mapping. For example, AA app groups statistics for “Streaming Video” includes all streaming apps, independent of whether any specific application is 0-rated for charging. AA charging groups are used for charging related statistics.

As with app-groups, charging groups are defined under an AA policy context for an AA group or partition. Once defined, individual apps and app-groups can be associated with the desired charging group. The charging group name is a key match criteria within application QoS policy rules.

A default charging group can be specified for the AA policy to associate a charging group to any applications or app-groups that are not explicitly assigned to a charging group.

Charging groups are also assigned an export-id number for accounting export purposes.

If no export-id is assigned, that charging group cannot be added to the AA subscriber stats RADIUS export-type. Once a charging group index is referenced, it cannot be deleted without removing the reference.

3.2.2.2.8. Applications

The application context defines and assigns a description to the application names supported by the application filter entries, and assigns applications to application groups.

The AA system provides no pre-defined applications other than Unknown. Applications must be explicitly configured. Any protocols not assigned to an application are automatically assigned to the default Unknown application. Nokia provides sets of known-good application/app-group configurations upon request. Contact the technical support staff for further information.

The applications are used by AA to identify the type of IP traffic within the subscriber traffic.

The network operator can:

3.2.2.2.9. Application Filters

Application filters (app-filter) are provided as an indirection between protocols and applications to allow the addition of variable parameters (port number, IP addresses, and so on) into an application definition. An application filter is a numbered rule entry that defines the use of protocol signatures and other criteria to define an application. Multiple rules can be used to define what constitutes an application but each rule will map to only one application definition.

The system concept of application filters is analogous to IP filters. Match of a flow to multiple rules is possible and is resolved by picking the rule with the lowest entry number that matches. A flow will only ever be assigned to one application.

The following criteria can be assigned to an application filter rule entry:

The application must be pre-configured prior to using it in an app-filter. Once defined, the new application names can be referenced.

3.2.2.2.10. HTTP

HTTP Protocol

The Hyper-Text Transfer Protocol (HTTP) has become the most significant protocol used on the Internet and has expanded its role beyond web browsing with a large number of applications using HTTP for a variety of functions on both desktop and mobile devices.

AA provides the tools required by residential, mobile and business VPN service providers to accurately classify any web-based applications regardless of where the content is stored and how it is delivered. This is done by using either the default protocol signatures delivered with the AA ISA software or by defining string based signatures from the HTTP header information fields included in the HTTP request messages to further refine the detection.

HTTP Session Persistency

HTTP can use both non persistent connections and persistent connections. Non-persistent connection uses one TCP connection per HTTP request while persistent connection can reuse the same TCP connection for multiple HTTP request to the same server.

Nowadays most applications are using HTTP/1.1 and persistent connection but HTTP/1.0 and non-persistent connections remains on older software and mobile devices.

HTTP flows are classified in a particular application using the first HTTP request of the flow only by default. Optionally, the MS-ISA offers the flexibility to classify each HTTP request within the same flow independently using http-match-all-request feature.

HTTP Proxy Support

AA also supports traffic classification of HTTP between a subscriber and a web proxy. This feature is enabled by default, the ISA monitors and detects HTTP proxy flows automatically, each request within the same persistent connection to the proxy server is classified independently.

3.2.2.2.11. AA IP Prefix Lists

AA ISA allows the match section of session filters, AQPs entries and application filters to include matching against a configured IP filter list or lists. Each IP filter list (aka IP pools) can have up to 64 IP address entries with a configurable mask for each entry.

3.2.2.2.12. Shallow Flow Inspection

When application awareness is not required, but requires other AA value added functions (for example, TCP-O, DEM), significant performance can be gained by not performing pattern or behavior-based identification. A shallow inspection configuration option can disable AA Layer 7 classification to increase throughput performance for deployments that can operate using only AA Layer 3 and Layer 4 shallow flow inspection. This configuration disables all signature-based flow inspection. This configuration can be used with TCP optimization, Dynamic Experience Management, Layer 3 and Layer 4 application filter classification, and Dynamic Experience Management.

3.2.2.2.13. Flow Attributes

Each flow attribute can be enabled for use in the CLI:

The classification techniques used by the flow-attribute algorithms include:

AQP traffic control policies may include flow attributes as a match condition in order to only affect traffic matching or not matching configurable flow attribute confidence level:

3.2.2.3.1. Per-AA Subscriber Special Study

The system can be configured to generate statistical records for each application and protocol that the system identifies for specific AA subscribers. These capabilities are disabled by default but can be enabled for a subset of AA subscribers to allow detailed monitoring of those AA subscriber’s traffic.

Per-AA subscriber per-application and per-AA subscriber per-protocol records are enabled by assigning individual AA subscribers to special study service lists. The system and ISA group limit the number of AA subscribers in this mode to constrain the volume of stats generated. When an AA subscriber is in a special study mode, one record for every application and/or one record for every protocol that are configured in the system are generated for that subscriber. For example, if 500 applications are configured and 200 protocols are identified, 700 records per AA subscriber will be generated, if the AA subscriber is listed in both the per-aa-sub-application and per-aa-sub protocol lists.

3.2.2.3.2. System Aspects

AA uses the existing redundant accounting and logging capability of the 7750 SR and 7450 ESS for sending application and subscriber usage information, in-band or out-of-band. AA statistics are stored using compressed XML format with other system and subscriber statistics in compact flash modules on the redundant SF/CPMs. A large volume of statistics can be expected under scaled scenarios when per-AA subscriber statistics/accounting is enabled.

AA accounting and statistics can be deployed as part of other system functionality as long as the system’s function is compatible with AA accounting or as long as the system-level statistics can become application-aware due to, for example, AA ISA-based classification. An example of this feature interaction includes volume and time-based accounting where AA-based classification into IOM queues with volume and time accounting enabled can, for instance, provide different quota/credit management for off-net and on-net traffic or white/grey applications.

3.2.2.3.3. Application Assurance XML Volume Statistics and Accounting

AA is configured to collect and report on the following statistics when at least one AA ISA is active. The default AA statistics interval is 15 minutes.

Statistics to be exported from the node are aggregated into accounting records, which must be enabled in order to be sent. By default, no records are sent until enabled. Each record template type is enabled individually to control volume of statistics to the desired level of interest. Only non-zero records are written to the accounting files for all AA subscriber based statistics to reduce the volume of data.

The operator can further select a subset of the fields to be included in per-AA subscriber records and whether to send records if no traffic was present for a given protocol or application, for example, sending only changed records.

Each record generated contains the record fields as described in Table 12. The header row represents the record type.

The records are generated per ISA group and partition, with an ISA group identified by the group ID (XML field name “aaGroup”), partition identified by the partition ID (XML field name “aaPart name” and per AA subscriber (if applicable) with the AA subscriber identified by the ESM, DSM, or transit subscriber name, SAP ID (XML field name “subscriber name”, “sap name” or “spoke SDP ID” respectively).

The date, time, and system ID for the records will be visible as part of the existing accounting log capability, thus does not need to be contained inside the AA records themselves.

The Forwarding Class is included in AA XML records as generally a VPN interconnection SLA is a combination of Bandwidth connection at the site level and Forwarding Class to transport the traffic over the MPLS network, by mapping the end-customer DSCP or 802.1P traffic value into a given FC.

AA accounting stats of the application/application-group volume usage per forwarding class shows the exact volume of each application at the per FC level and better ties the AA reports to the VPN services and SLA.

This can also identify key applications using a non-optimal FC over a given VPN/Site and allow the option for AA to remark these into a higher traffic class, with reporting per FC to show resulting use.

3.2.2.3.4. AA Partition Traffic Type Statistics

AA-ISA provides, at the AA partition level, traffic volume visibility of the Layer 3 protocols used to transport the different Layer 4 protocols. These include a traffic volume break down of TCP, UDP and Non-TCP-UDP carried by IPv4 and IPv6, DS_Lite, 6to4/6RD, GTP, and Teredo protocols.

Traffic-type statistics are broken down by “family” and “protocol”:

Therefore, AA-ISA traffic type record provides a collection of 15 sets of traffic volume (bytes) statistics figures, as follows:

These statistics are always counted. There is no configuration required to enable/disable tracking. However, the operator has the option to enable/disable export of these statistics via XML.

Table 13 lists the statistic record fields per AA partition.

3.2.2.3.5. Configurable AA Subscriber Statistics Collection

Existing average volume statistics collected over an accounting interval are extended to provide the maximum volume (bytes/packets) recorded for a throughput measurement period (5 minutes) within an accounting interval. These additional statistics improve accuracy for the access-pipe right-sizing service.

Maximum throughput statistics can be enabled for the selected applications and/or application groups enabled for custom per AA statistics. In addition, the operator can enable (disabled by default) per AA subscriber “Max-throughput” statistics for total (/aggregate) subscriber traffic, independent of defined applications/application-groups.

Maximum throughput statistics records are allocated from the 2048K records available for use for per subscriber records.

Maximum throughput statistics are not provided for the protocols enabled for custom per AA statistics.

3.2.2.3.6. AA-Performance Record for ISA Load

The AA-performance statistics record provides visibility of ISA loading related statistics to allow operational monitoring and planning of ISA overload:

The NSP Analytics provide further analysis and thresholding triggers based on these ISA statistics, suitable for long-range planning trends such as average number of subs or peak numbers of flows.

The node per-ISA planning record values are cleared on accounting read (per all accounting records). Not reading the records means that the average and peak values are the values for the last reporting interval. The time last read is indicated in the record.

The AA performance planning record fields are listed in Table 14.

The AA performance records are listed in Table 15.

3.2.2.3.7. AA Partition Traffic Type Statistics

AA ISA provides, at the AA partition level, traffic volume visibility of the Layer 3 protocols used to transport the different Layer 4 protocols. These include a traffic volume break down of TCP, UDP and Non-TCP-UDP carried by IPv4, IPv6, DS_Lite, 6to4/6RD and Teredo protocols.

Traffic-type statistics are broken down by family and protocol:

Therefore, AA ISA traffic type record provides a collection of 15 sets of traffic volume (Bytes) statistics figures as follows:

These statistics are always counted. There is no configuration required to enable/disable tracking. However, the operator has the option to enable/disable export of these statistics via XML.

Table 16 lists the record fields.

3.2.2.3.8. AA Partition Admit–Deny Statistics

At the partition level, AA provides counters that capture events associated with various application QoS policy (AQP) actions related to packet and/or flow drops and admit actions. These statistics are exported via XML using configured accounting policies.

When enabled at the partition level, AA reports the statistics listed below.

Table 13 lists the record names used for AA admit-deny statistics.

3.2.2.3.9. RADIUS Accounting AA Records

AA RADIUS accounting provides per- level, AA subscriber charging group statistics as well as application-group (AG) and application statistics as part of the RADIUS accounting infrastructure. The primary use of this is to enhance RADIUS accounting with AA information useful for usage-based billing plans, providing flexibility to charge and rate application content using IP subnets, HTTP URLs, SIP URIs, and other AA-identified applications.

The system can export AA accounting statistics using accounting policy records exported with RADIUS accounting. For non-DSM subscribers, AA RADIUS accounting is AA subscriber ID-based, where the AA subscriber context IPv4 and IPv6 host addresses for the sub are not reflected in RADIUS accounting. For DSM subscribers, the AA counters are included in the BB RADIUS session which is based on the BB sub and reflects the BB host context.

AA RADIUS accounting is implemented using ALU Vendor Specific Attributes (VSAs). This provides all charging group counters for a given subscriber to be exported with a common accounting session ID. The following statistics are included in each record. Accounting values are for forwarded packets:

AA RADIUS accounting is supported for ESM, DSM, transit, and SAP or spoke SDP AA-subtypes. RADIUS accounting is used to export AA charging group, app-group, and application values according to the RADIUS accounting policy interval. Charging group statistics are exported in RADIUS accounting independent of application groups (either or both can be enabled).

For DSM subscribers, RADIUS accounting records can be configured to be exported under the Broadband ISA (BB) configuration. In this case, the AA charging group, application group, application and sub aggregate (total AA traffic) counters are passed to the BB ISA for export to the BB RADIUS accounting sessions.

3.2.2.3.10. AA Gx Based Usage Monitoring

Using 3GPP (third generation Partnership Project) diameter (Gx) functionality, AA ISA upon receiving requests from Policy and Charging Rules Function (PCRF), can monitor application usage at the subscriber’s level and report back to PCRF whenever the usage exceeds the thresholds set by the PCRF.

Usage-monitoring can be used by operators to report to PCRF when:

AA can monitor subscriber’s traffic for any defined:

AA ISA Gx-based usage monitoring is restricted to AA ESM and transit AA subscribers’ type therefore it is only supported on 7750 SR.

The AA ISA Gx usage monitoring feature builds on 3GPP Release 11 defined Application Detection and Control (ADC) Gx attributes. In addition, AA ISA is compliant with 3GPP Release 12, whereby the ADC rule functionality is integrated in the PCC rules.

AA ISA reports accumulated usage when:

An AA defined application, application group and/or charging group is automatically allowed to be referenced by a an ADC rule for the purpose of usage monitoring only if:

Figure 22 illustrates the different messaging /call flows involved in application level usage monitoring. For details about the supported AVPs used in these messages, see section Supported AVPs.

Figure 22:  Usage Monitoring 

AA ISA (the PCEF) supports Usage-Thresholds AVPs that refer to the thresholds (in byte) at which point an event needs to be sent back to the PCRF (Figure 22).

No time based thresholds are supported.

AA supports grant-service-unit AVP using the following possible values (AVP):

As shown in Figure 22 (T=7), AA sends a CCR message with a USAGE_REPORT Event-Trigger AVP to the PCRF when the usage counter reaches the configured usage monitoring threshold for a given subscriber (and given application group). AA counters are reset (to zero) when the monitoring threshold is reached (and an event is sent back to PCRF). The counters, however, do not stop counting newly arriving traffic. AA counters only include “admitted” packets. Any packets that got discarded by AA due to –say- policing actions- are not counted for usage-monitoring purposes.

The TDF-Application-Identifier AVP–within the ADC or PCC rule- refers to AA Charging group, AA application group or to an AA application.

TDF-Application-Identifiers (such as charging-groups) have to be manually entered at the PCRF to match AA charging groups configured on the 7750 SR.

If the TDF-Application-Identifiers refers to a name that is used for both a charging group and an application (or application group), AA monitors the charging group. In other words, AA charging group has higher precedence than AA application group.

3.2.2.3.11. Supported AVPs

ADC Rule AVP

The ADC Rule install appears in the CCA and RAR messages from PCRF towards AA ISA.

The AVPs marked by an asterisk in the above example are not supported by AA ISA.

The TDF-application-Identifier field specifies a predefined AA charging group, application group or application name for which usage monitoring functionality is required (for a given subscriber).

The Monitoring-Key AVP (AVP code 1066), refers to a predefined (by PCRF) USAGE Monitoring AVP.

The value of the monitoring key is random. However, it should be noted that a monitoring key instance can only be used in a single ADC rule (for example, single app/app-grp/chg-grp). While the standards allow for a monitoring instance to be referenced by one or more ADC rules, AA ISA implementation restricts this to one ADC rule. Hence, if a monitoring key is referenced in one ADC rule, it cannot be referenced by another.

PCC Rule AVP

The PCC rule install appears in the CCA and RAR messages from PCRF towards AA-ISA.

Charging-Rule-Name — The name of the charging rule that contains a rule related to usage monitoring of a TDF_application_id has to start with:”AA-UM:” e.g. AA-UM: Peer to peer traffic for APN x”.

TDF-application-Identifier — This field specifies a predefined AA charging group, application group or application name for which usage monitoring functionality is required (for a given subscriber).

The Monitoring-Key AVP (AVP code 1066) refers to a predefined (by PCRF) USAGE Monitoring AVP.

The value of the monitoring key is random. However, it should be noted that a monitoring key instance can only be used in a single PCC rule (for example, single app/app-grp/chg-grp). i.e. while the standards allow for a monitoring instance to be referenced by one or more PCC rules, AA ISA implementation restricts this to one PCC rule. Hence, if a monitoring key is referenced in one PCC rule, it cannot be referenced by another.

Usage-Monitoring-Information AVP

The Usage-Monitoring-Information AVP (AVP code 1067) is of type Grouped, and it contains the usage monitoring control information.

The Monitoring-Key AVP identifies the usage monitoring control instance.

Monitoring-Key-AVP

The Monitoring-Key AVP (AVP code 1066) is of type OctetString and is used for usage monitoring control purposes as an identifier to a usage monitoring control instance.

Granted-Service-Unit AVP

The Granted-Service-Unit AVP shall be used by the PCRF to provide the threshold level to the PCEF.

The CC-Total-Octets AVP shall be used for providing threshold level for the total volume, or the CC-Input-Octets and/or CC-Output-Octets AVPs shall be used for providing threshold level for the uplink volume and/or the downlink volume.

The AVPs marked by an asterisk in the above example are not supported by AA ISA.

Used-Service-Unit AVP

This AVP is used by AA_ISA (the PCEF) to provide the measured usage to the PCRF. Reporting is done, as requested by the PCRF, in CC-Total-Octets, CC-Input-Octets or CC-Output-Octets AVPs of Used-Service-Unit AVP.

The Used-Service-Unit AVP contains the amount of used units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended.

The AVPs marked by an asterisk in the above example are not supported by AA ISA.

CC-Total-Octets AVP — The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and contains the total number of requested, granted, or used octets regardless of the direction (sent or received).

CC-Input-Octets AVP — The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and contains the number of requested, granted, or used octets that can be/have been received from the end user.

CC-Output-Octets AVP — The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and contains the number of requested, granted, or used octets that can be/have been sent to the end user.

Usage-Monitoring-Level AVP

The Usage-Monitoring-Level AVP (AVP code 1068) is of type Enumerated and is used by the PCRF to indicate the level to which the usage monitoring instance applies.

If Usage-Monitoring-Level AVP is not provided, its absence shall indicate the value PCC_RULE_LEVEL (1).

The following values are defined (by the standard):

Usage-Monitoring-Report AVP

The Usage-Monitoring AVP (AVP code 1069) is of type Enumerated and is used by the PCRF to indicate that accumulated usage is to be reported by AA ISA (the PCEF) regardless of whether a usage threshold is reached for certain usage monitoring key (within a Usage-Monitoring-Information AVP).

The following values are defined:

If no monitoring keys are set, AA ISA reports all enabled monitoring instances for the subscriber.

Usage-Monitoring-Support AVP

The Usage-Monitoring-Support AVP (AVP code 1070) is of type Enumerated and is used by the PCRF to indicate whether usage monitoring shall be disabled for certain Monitoring Key.

The following values are defined:

Event-Trigger AVP (All Access Types)

The Event-Trigger AVP (AVP code 1006) is of type Enumerated. When sent from the PCRF to the PCEF (AA ISA) the Event-Trigger AVP indicates an event that can cause a re-request of ADC rules. When sent from the PCEF to the PCRF the Event-Trigger AVP indicates that the corresponding event has occurred at the gateway.

When used in a CCR command, this value indicates that AA ISA (the PCEF) generated the request to report the accumulated usage for one or more monitoring keys. AA_ISA provides the accumulated usage volume using the Usage-Monitoring-Information AVPs including the Monitoring-Key AVP and the Used-Service-Unit AVP.

The usage_report event must be set by the PCRF, otherwise AA ISA will not report usage-monitoring when a threshold is crossed.

Usage-Monitoring Disabled

Once enabled, the PCRF may explicitly disable usage monitoring as a result of receiving a CCR from AA ISA which is not related to reporting usage, but related to other external triggers (such as subscriber profile update), or a PCRF internal trigger.

When the PCRF disables usage monitoring, AA ISA reports the accumulated usage which has occurred while usage monitoring was enabled since the last report.

To disable usage monitoring for a monitoring key, the PCRF sends the Usage-Monitoring-Information AVP including only the applicable monitoring key within the Monitoring-Key AVP and the Usage-Monitoring-Support AVP set to USAGE_MONITORING_DISABLED.

When the PCRF disables usage monitoring in a RAR or CCA command, AA ISA sends a new CCR command with CC-Request Type AVP set to the value UPDATE_REQUEST and the Event-Trigger AVP set to USAGE_REPORT to report accumulated usage for the disabled usage monitoring keys.

Termination Session

At AA ISA subscriber’s session termination, AA ISA sends the accumulated usage information for all monitoring keys for which usage monitoring is enabled in the CCR command with the CC-Request-Type AVP set to the value TERMINATION_REQUEST.

3.2.2.3.12. Cflowd AA Records

AA ISA allows cflowd records to be exported to an external cflowd collector. The cflowd collector parameters (such as IP address and port number) are configured per application assurance group. Operators can choose to export cflowd records directly inband on a configurable VLAN from AA or via the CPM, similar to the way system cflowds are exported. By exporting directly inband, a higher rate of cflowd records can be exported compared to export via CPM, as inband export by-passes CPM and hence avoids the CPM bottleneck that could potential lead to cflowd packets discards. All cflowd records collected are exported to the configured collectors. AA ISA supports cflowd Version 10/ IPFIX.

A cflowd record is only exported to the collector once the flow is closed/terminated.

For each of the supported cflowd templates described in this section, the operator can customize which fields to include in the exported templates. For example, an operator can include the following fields: flow attributes, HTTP/SNI hostname, AA protocol/application/application-group, and DEM-related fields.

Volume Statistics

AA ISA allows an operator to collect per flow volume statistics to be exported for any group partition. The packet sampling rate is configurable per AA- ISA-group level. For example, a packet sample rate of 10 means that one of every 10 packets is selected for volume statistics collection. If a flow has at least a single packet sampled for cflowd volume statistics, its per-flow cflowd volume record is exported to the configured collector upon flow closure.

The volume cflowd record includes flow statistics, flow related L3 to L7 information such as IP 5tuple, and a large set of fields that the operator can selectively choose from to include in the exported volume cflowd records; for example, flow duration, application ID, application group ID, device information, flow attributes, HTTP/SNI hostname, and so on.

Comprehensive Statistics

AA ISA allows an operator to collect per flow comprehensive statistics to be exported through cflowd v10/IPFIX.

Unlike AA volume cflowd, which is packet sampled and enabled at the AA-partition level, (covering all traffic within a partition, which prohibits the use of high sampling rates), AA comprehensive flow uses a flow (instead of packet) sampling cflowd mechanism, and allows operators to target desired applications and application groups for sampling. Therefore, providing finer control at the application/application group level, rather than at the partition level (which is the case for volume cflowd).

The operator can decide to collect comprehensive statistics for sampled flows within an enabled group-partition application/application group. The operator can specify parameters to include in the exported comprehensive cflowd record, such as applications/application groups, host fields (applicable to HTTP traffic only), subscriber device type (when available), flow duration, device information, flow attributes, HTTP/SNI hostname, and so on, as well as other general statistics such as a flow's byte or packet counts.

The flow sampling rate is configurable on a per-ISA group level. For example, a flow sample rate of 10 means that every 10th flow is selected for comprehensive statistics collection. Anytime a flow is sampled (selected for comprehensive statistics collection), its mate flow in the reverse direction is also selected. The two flows are exported in a single cflowd record.

Per-flow comprehensive can be enabled (or disabled), using one of two configurable sampling rates, per application/app-group per partition per AA ISA-group.

Applications and/or Application groups selected for comprehensive statistics gathering can use one of these two sampling rates. For example, important applications are assigned high sampling rates, while other applications are subjected to a lower flow sampling rate.

TCP Application Performance

AA ISA allows an operator to collect per flow TCP performance statistics to be exported through cflowd v10/IPFIX.

The operator can decide to collect TCP performance for sampled flows within a TCP enabled group-partition-application/application-group. The flow sampling rate is configurable on per ISA-group level. For example a flow sample rate of 10 means that every 10th TCP flow is selected for TCP performance statistics collection. Anytime a flow is sampled (selected for TCP performance statistics collection) its mate flow in reverse direction is also selected. This allows collectors to correlate the results from the two flows and provide additional statistics (such as round-trip delay). Per-flow cflowd TCP performance records are exported to the configured collectors upon flow closure.

Two configurable TCP flow sampling rates are available per AA ISA group. Applications and/or Application groups selected for TCP performance monitoring can use of one these two sampling rates. For example, important applications are assigned high sampling rates, while other TCP applications are subjected to TCP performance monitoring using a lower flow sampling rate.

Per-flow TCP performance can be enabled (or disabled), using one of two configurable sampling rates, per application/app-group per partition per AA ISA-group.

Audio/Video (A/V) Application Performance

AA ISA integrates a third party audio/video performance measurement software stack to perform VoIP and video conferencing MOS-related measurements for RTP based A/V applications.

A passive monitoring technology estimates transmission quality of voice and video over packet technologies by considering the effects of packet loss, jitter and delay in addition to the impairments caused by encoding/decoding technology. A rich set of diagnostic data is provided that can be used to help network managers identify a variety of problems that could impact the quality of voice and video streams and/or service level agreements (SLAs).

This feature provides:

After a flow terminates, AA ISA formats the flow MOS parameters into a cflowd record and forwards the record to a configured IPFIX /10 cflowd collector. The collector then summarizes these records using route of interest information (source/destinations). In addition, RAM provides the user with statistics (minimum, maximum, and average values) for the different performance parameters that are summarized.

Two configurable RTP flow sampling rates are available per AA ISA group. Applications and/or Application groups selected for RTP performance monitoring can use one of these two sampling rates. For example, important applications (such as Cisco’s Telepresence video conferencing or operator’s VoIP service) are assigned high sampling rates, while other RTP applications are subjected to RTP performance monitoring using a lower flow sampling rate.

Like TCP performance, per flow audio/video performance can be enabled (or disabled), using one of two configurable sampling rates, per application/app-group per partition per AA ISA-group.

The operator can decide to collect RTP A/V performance for sampled RTP flows within an RTP A/ V enabled group-partition-application/application-group. The two available flow sampling rates is are configurable on per ISA group level. For example a flow sample rate of 10 means that every 10th RTP flow is selected for RTP performance statistics collection. Anytime a flow is sampled (selected for RTP A/V performance statistics collection) its mate flow reverse direction is also selected. When RTP dynamic payload types (RTP “PT”) are used, only flows that use SIP to signal RTP codec can be selected for RTP performance measurement. Flows that use static RTP payload types can be selected for performance measurement regardless of the signaling channel used to setup the call.

3.2.2.3.13. vRGW Nested Router Detection

Bridged residential gateway operators may require the vRGW to detect if and when in-home devices are used to route access to network services, thereby acting as a nested router in the home’s LAN to hide multiple end devices behind the router MAC address. Data traffic coming from nested router devices is typically much higher than what an individual device generates or consumes. Nested routers also may violate terms of service for a BRG managed home on the operator’s network.

For a vRGW, each device in the home that is diverted to AA becomes an esm-mac AA subscriber type. When AA tethering detection is enabled, an esm-mac AA subscriber that has traffic behavior representing multi-device traffic patterns is detected by the AA process and a “tethering state” is placed against the AA subscriber, thereby identifying a potential nested router.

The operator can install policies to handle nested router (tethering state) devices as appropriate, including but not limited to: applying different charging, blocking, rate limiting and/or redirecting the traffic from the device to a web portal. Per-subscriber tethering state is an indication of devices that are operating as a nested router and can be included in the AA subscriber cflowd record export.

3.2.2.4.1. AQP Match Criteria

Match criteria consists of any combination of the following parameters:

AQP entries with match criteria that exclusively use any combination of ASO characteristic and values, direction of traffic, and AA subscriber define default policies. All other AQP entries define application aware policies. Both default and application aware policies. Until a flow's application is identified only default policies can be applied.

3.2.2.4.2. AQP Actions

An AQP action consists of the following action types. Multiple actions are supported for each rule entry (unlike ip-filters):

Any flow diverted to an ISA group is evaluated against all entries of an AQP defined for that group at flow creation (default policy entries), application identification completion (all entries), and an AA policy change (all flows against all entries as a background task). Any given flow can match multiple entries, in which case multiple actions will be selected based on the AQP entry’s order (lowest number entry, highest priority) up to a limit of:

AQP entries the IP flow matched, that would cause the above per-IP-flow limits to be exceeded are ignored (no actions from that rule are selected).

Examples of some policy entries may be:

3.2.2.4.3. Application Assurance Policers

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

There are six types of policers:

Once 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 17 illustrates a policer's hardware rate steps for AA ISA.

Policers are unidirectional and are named with these attributes:

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):

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

In Figure 23, 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 will be 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 23:  From-AA Subscriber Application-Aware Bandwidth Policing 

In the to-AA subscriber direction (Figure 24), 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 24:  To-AA Subscriber Application-Aware Bandwidth Policing 

3.2.2.4.4. Application Assurance Dynamic Experience Management

Dynamic Experience Management (DEM) is a feature of AA software that monitors user plane traffic to build a network-wide view of congestion at the subscriber or ANL levels. This enables real-time dynamic actions, such as rate limiting and application blocking. It provides the optimum user experience within the actual, overall network capabilities.

In situations of high network load and congestion, the subscriber quality of experience (QoE) degrades due to restricted resources across the network (such as in the radio transport layers). In this context, background traffic and real-time traffic cannot be differentiated efficiently and dynamically. The ability to differentiate background traffic from real-time traffic is important for delay-sensitive applications, such as video.

The following implementations of the DEM gateway are available, depending on the network access deployment:

3.2.2.4.4.1. WLAN-DEM

Dynamic Experience Management (DEM) is a Wireless LAN Gateway (WLAN GW) capability that monitors user plane traffic to build a network-wide view of congestion on the subscriber, application, and access point radio levels. DEM enables making real-time decisions and dynamic actions, such as rate limiting or blocking of certain applications. It provides a managed, optimal user experience within the actual, overall network capabilities.

In situations of high network load and congestion, application Quality of Experience (QoE) degrades due to restricted resources across the network (for example, in radio or transport). In this context, operators cannot differentiate background traffic from real-time traffic efficiently and dynamically. This differentiation is especially important for delay-sensitive applications such as video.

In Radio Access Networks (RAN), the network congestion points are typically located in the access point WiFi radio. See Figure 25.

Figure 25:  WiFi Network Congestion at AP Radio 

Increased penetration of WiFi-enabled devices (for example, mobile handsets, tablets, laptops, and TVs) and widespread use of streaming video results in frequent data plane congestion events in WiFi networks. This congestion results in service degradation for WiFi subscribers attached to congested access points and creates challenges in implementing fair usage policies to manage network congestion in the access network.

DEM provides the capability of managing WiFi access congestion points at the WLGW to provide some level of QoS guarantees to different applications, which otherwise poses challenges as the loading of the different access points at any point in time is different, both in quantity (Bandwidth) and application types (for example, video, web, or mail).

3.2.2.4.4.3. Multi-Point Congestion Enforcement

The DEM technology allows the DEM GW to detect congestion within the access network.

If congestion is detected at any point, DEM-GW can employ policies per application, per application group, or per subscriber to limit the impact of low-priority traffic on QoE-sensitive applications. See Figure 26.

Figure 26:  DEM-GW Multi-point Congestion Control 

A DEM-GW is integrated directly into the WLGW using AA. The DEM-GW models the congestion points, called ANLs, that it learns from the WLGW subscriber attributes, and manages them accordingly to achieve the configured QoE/QoS target.

The DEM-GW achieves congestion control by:

1. running DPI to classify flows into applications, including encrypted traffic
2. dynamically learning access network congestion points and estimating their maximum capacity:
   1. through real-time detection, sniffing, measurements and profiling
   2. continuous monitoring of UEs locations and associating them to the right access point radio congestion points
3. QoE enforcement:
   1. efficient access point radio congestion detection, localization and management provided via configurable adaptive policers

The DEM-GW actively runs intelligent congestion control. It relies on location information relayed by WLGW sub management for Access Point MAC and VLAN.

For AP congestion detection, the DEM-GW runs an algorithm-based on measurements of Round Trip Time (RTT) to determine congestion state.

The DEM-GW uses location-awareness of all UEs to apply traffic management at specific impacted access sites, while un-restricting users during times of non-congestion. This ensures different applications within an AP radio get fair share of available resources, while controlling low-value traffic during times of congestion.

The inherited subscriber or application awareness at the DEM-GW (SSG/PGW/GGSN), when integrated with AA application detection and control, results in entitlement-based enforcements of specific applications for specified users or UEs, allowing the operators to provide differentiated services.

The end-to-end DEM solution can involve PCRF for opt-in policy control and off-line reporting platforms to facilitate some additional value-add use-cases.

3.2.2.4.4.7. Location-Based Analytics

Location-based analytics provides the operator with an accurate view of the subscriber's location (ANL) and application usage for a specified location in WiFi networks for the purpose of data-mining. See Figure 27.

Figure 27:  Access Point Radio per Application Reporting 

To provide an accurate reporting of the subscriber location via analytics tools such as the Network Services Platform, AA exports location information and congestion status in both volume and comprehensive cflowd reports. The off-line cflowd collector then allows per ANL (Access Point and AP radio) per application or application groups statistics.

3.2.2.4.5. Application Assurance HTTP Redirect

AA HTTP Policy Redirect

With AA ISA HTTP policy based redirect feature, when HTTP flows are blocked, the user is directed to a web portal that displays relevant messages to indicate why the HTTP traffic is blocked, such as: time of day policy to block youtube.com, top-up request, and so on.

Without HTTP policy redirect, when HTTP flows are blocked, the subscriber application retries and before it times-out.

AA ISA provides full customer control to configure an AQP action that redirects traffic that matches the AQP match criteria. Hence, the HTTP redirect service can be applied at any level (application, application group, specific subscribers, specific source IP addresses) or any other AQP match criteria.

To illustrate, say the operator configures www.poker.com as a “gambling” app-group.

The operator configures AA_ISA to drop and redirect all HTTP traffic classified under “gambling” app-group to www.redirect.isp.com. When a client/subscriber initiates an HTTP GET for www.poker.com. Traffic to poker.com is dropped at the AA ISA. AA ISA issues a redirect to the client. [in the redirect, information about the user are encoded in the PATH message, such as www.poker.com, sub-ID, sub-type, reason for redirect (=AQP drop action) AA application name]. Client, unaware of the drop, responds to the redirect.

Redirect landing page explains to the user why the page at www.poker.com is not accessible. See Figure 28.

Figure 28:  HTTP Redirect Due To URL Block 

AA ISA allows the operator to configure HTTP redirect policies. An HTTP redirect policy contains, most importantly, the HTTP host to be used for the redirect. Within the AQP actions, such polices can be linked (like policers). Redirect takes place only if the AQP configured matching criteria is met and the HTTP flow is dropped (due to other AQP actions, such as “drop”, flow-count/rate policers). The redirect only applies to HTTP traffic. Non-HTTP flows (even if the conditions above are met) are not redirected (no redirect for RTSP traffic).

The HTTP redirect policy includes an option for TCP-client-reset. This is used to improve the end-user experience when TCP traffic that cannot be HTTP redirected is blocked. Resetting the client TCP session avoids the client waiting for tcp session timeout. The ISA will initiate a TCP reset towards the client if the AA policy results in an http-redirect with packet drop but the HTTP redirect cannot be delivered. Scenarios for this include blocked HTTPs (TLS) sessions, blocking of non-HTTP traffic, and blocking of existing flows after a policy re-evaluate of an existing subscriber. A mid-session policy change to redirect & block traffic for a sub will cause a TCP reset of existing non-http tcp sessions when the next packet for those sessions arrives. For example, when the packet is dropped.

AA HTTP 404 Redirect

HTTP status code-based redirect feature provides error resolution and search technology that enhances the Internet experience for end customers while generating new revenue stream for the ISP.

Nokia’s AA ISA HTTP status code-based redirect feature, along with its partners Barefruit or Xercole, replaces unhelpful DNS and HTTP error messages with relevant alternatives, giving the user a search solution rather than a no direction. Customers benefit from an improved surfing experience as they are served relevant results that can help them find what they were looking for. The ISP, on the other hand, receives a share of the search revenue.

Every time an end-user clicks on a broken link (Page Not Found), an error page displays. Frequently, a search provider produces results, through a browser plug-in, for that user. This generates revenue for the search provider if the user clicks on a paid link.

With AA ISA HTTP status code-based redirect feature, the user sees high-quality, relevant search results. In addition, instead of the search provider receiving all of the revenue, the ISP is paid every time a user clicks on a sponsored link.

AA ISA provides full customer control to configure an AQP action that redirects traffic that matches the AQP match criteria (Figure 29). Hence, the HTTP redirect service can be applied at any level (application, application group, specific subscribers, specific source IP addresses) or any other AQP match criteria.

Figure 29:  AQP Actions 

HTTP headers are intercepted by AA ISA on the return path from the requested web site. If the HTTP status code is a non-custom 404, then the response is replaced with JavaScript that redirects the client to the Contextual Analysis Servers (Barefruit server). This redirect contains details of the original URI that gave rise to the 404 error.

The operator can configure AA ISA HTTP 404 redirect to use either Barefruit or Xerocole partner contextual analysis servers. A redirect policy can be defined once at the AA group level (similar to policers), and then referenced as many times as needed in AQP actions. The system allows a maximum of one HTTP 404 redirect policy per AA group.

3.2.2.4.6. Application Assurance HTTPS Policy Redirect

The majority of traffic is HTTPS. Many users are not aware of the differences between HTTP and HTTPS and the operator should be able to inform users why access to a web page is not allowed. If access to an HTTPS page is blocked, the user cannot know that this was the result of a policy decision.

AA supports policy-based redirection of HTTPS traffic to a landing page that displays relevant messages to indicate why the traffic is blocked. Similar to HTTP Redirect, the operator can configure an AQP to redirect traffic matching the AQP criteria to an informative web portal.

When a user attempts to access an HTTPS site, an SSL tunnel (between the user's browser and the web server) is established. AA analyses the traffic, and if the configured HTTPS redirect AQP matches, AA returns a Nokia certificate. After the certificate is accepted, the user is redirected to the informative portal.

For configuration details, see Configuring an HTTPS Policy Redirect.

3.2.2.4.7. ICAP - Large Scale Category-based URL Filtering

ICAP and the use of the AA-interface is only supported on the 7750 SR. Large scale URL filtering is a common content filtering requirement from broadband, mobile, and business VPN operators that allows them to solve various use cases such as:

AA provides both a cost efficient and best of breed content filtering solution to solve these use cases by enabling off-line dedicated web filtering servers though the Internet Content Adaptation Protocol (ICAP). Using application assurance the operator does not need to deploy costly inline filtering appliances or a limited client software solution requiring maintenance and updates for a growing number of computing devices and operating systems (for example, laptop, smartphone, smartTV, tablets).

A high level packet flow diagram of the solution is shown in Figure 30. The AA ISA is the ICAP client and performs inline Layer 7 packet processing functions while the ICAP application server is used for URL filtering off-line, thus the application server does not need to be inserted in the data flow:

Figure 30:  ICAP High Level Flow Diagram 

The 7750 SR uses the AA capabilities to extract the URL from the subscriber's HTTP/HTTPs request and send an ICAP rating request to the ICAP server along with the subscriber-id information. The ICAP server can then return an accept or redirect response based on various criteria such as subscriber profile, URL categories, allowlist, denylist, time of the day.

The ICAP response received by the 7750 SR ICAP client is used to either accept, redirect, or block the flow.

In order to handle the instance where an Internet server’s reply arrives before the ICAP server’s response, AA blocks traffic from the Internet server until the response from the ICAP server is received. This ensures that the appropriate action is always applied to the Internet traffic.

3.2.2.4.8. Web-service URL Classification

AA provides a URL filtering mechanism, as an alternative to ICAP, that is used to provide content filtering. Similar to the ICAP-based solution, web-service URL classification can be used to restrict opt-in users from accessing certain (configurable) URL categories. But in contrast to the ICAP-based solution, the decision is made by the AA. There is no involvement by an external element. Nokia has partnered with a leading URL categorization service provider to help provide the categorization; however, Nokia provides the end-to-end service. The operator does not need to integrate with any third party server; all communication between the AA and the URL categorization database is transparent to the operator.

The URL categorization database contains tens of millions of URLs and is constantly being updated. Along with the categorization of new URLs, the database is also updated with malicious URLs. Operators will therefore be able to offer protection against phishing and spam, and other similar sites.

Apart from enabling the operator to restrict content to opt-in users, web-service URL classification provides access to the Internet Watch Foundation (IWF) List. The IWF List contains websites which host the physical or sexual abuse of children. Using the Web-service URL classification, operators can restrict access to those sites. The IWF list is updated in real-time, so the list is always up-to-date.

Using the web-service URL classification, operators can offer the following:

The URL categorization database is hosted on the Cloud. The DNS service ensures that the AA always connects to the fastest server, ensuring minimum latency. In addition, AA implements a cache containing URLs and their categories. The vast majority of categorization requests are served by the cache and do not affect the user experience.

Figure 31 displays a high level diagram of URL categorization in AA.

Figure 31:  AA URL Categorization 

For every HTTP, HTTPS, HTTP2c, or QUIC request an opt-in user makes, AA first checks if the category of the requested URL is available in the cache. If available, AA checks if that category is allowed for the subscriber and acts accordingly.

If the request is not present in the cache, AA makes a Rest-API call to the URL categorization database and asks for the URL’s category. After the AA receives the response, the AA decides whether the request should be allowed or redirected.

The AA removes user-identifiable data prior to sending the URL to the categorization database. As an example, if the user requests “http://www.service.com/request.php?client=123”, the AA sends the following URL for categorization: “http://www.service.com/request.php”.

When the response from the URL categorization database arrives after the web server’s reply, the AA is always a restrictive filter; that is, AA always blocks the traffic in a way similar to the ICAP-based solution. This ensures that operators are never in breach of contract and a late URL categorization response does not result in a website displayed to the user.

The operator can define up to eight profiles containing categories. Using ASOs, a profile is mapped to a user and defines which URL categories are not allowed for that user.

The operator can manually set the category of a hostname to one of the supported categories. This is used in cases where the Categorization DB has categorized a hostname as "Unknown" and operator either knows the category or a hostname has been misclassified. In either case, the operator must contact Nokia and request reclassification of the hostname.

Table 18 shows three example profiles with different levels of restriction. The high-level profile example is the most restrictive profile. The medium-level profile is less restrictive and contains moderate category blocking. The low-level profile contains only a few URL categories to block.

Profiles can be modified at any time. Profiles can be dynamically mapped to users using PCRF/AAA.

Web-service URL Filtering is supported both for HTTP (using the entire URL) and HTTPS (using the hostname only) traffic.

A detailed configuration example is available in the Configuring Web-service URL Classification section.

Note: An additional license is needed to use the feature.

3.2.2.4.9. Local URL-List Filtering

Service providers may need to apply network-wide URL filtering policies and either allow or prevent some content for all subscribers. AA supports both allow-list and deny-list local URL-list filtering.

Local URL-list filtering is performed on both HTTP and HTTPS traffic.

The system supports both unencrypted and OpenSSL 3DES encrypted file formats to protect the contents of the list.

Operators can specify the size of the URL list to be filtered. The size can be set to either standard or extended. If the specified URL list is configured as extended, support is provided for filtering on a larger number of URLs.

The hostnames of a local list may contain wildcards.

File Format

The following characters are considered invalid and result in a failure to load the URL list:

When specifying a URL, do not include schema such as https:// or ftp://. The schema http:// is allowed but is not necessary.

The following is an example of URL list file content.

3.2.2.4.10. HTTP Header Enrichment

AA ISA supports modifications of the HTTP header for traffic going to specific user configured sites (URLs/IPs); in order to add Network based information, such as subscriber ID to the HTTP header. These sites use this information to authenticate the user and/or present the user with user-specific information and services.

Figure 32:  HTTP Enrichment 

In Figure 32, the operator configures the AA ISA to insert the subscriber ID into the HTTP header for all the HTTP traffic destined to the operator portal (designated by server IP and/or HTTP host name). Traffic going to other destinations, such as yahoo.com, does not get enriched. To support this, AA introduces a new AQP action called HTTP_enrich that allows the operator to enrich traffic that satisfies the AQP-matching conditions.

The operator can configure multiple HTTP enrichment policies that are applied to traffic going to different destinations. For example, HTTP traffic destined to “xyz.com”, gets the user’s IP inserted into the header, while traffic going to “billing.xyz.com” gets enriched with the subscriber ID and user’s IP address.

The AA ISA supports insertion of one or more fields listed in Table 20 into the HTTP header.

Note: If a field that is supported in Fixed Wireless Access (FWA) mode only is used in another deployment mode, AA either enriches with the default value or enrichment is not performed.

Table 21 lists user-location encoding and enrichment examples.

Note: The ULI type can change and when it does, the mobile gateway will report it as a change to the AA-sub. AA will store and use the latest ULI for enrichment. As with previous enrichment fields, if the ULI type changes between the original packet transmission and the TCP retransmission, the latest ULI type will be used on retransmission (that is, the ULI for retransmission is not cached). The mcc-mnc values of the ULI are decimal digits (BCD), while the trailing portion of the ULI are hexadecimal values. There can be more than one ULI identity type specified for an AA-sub, in which case the ECGI format is used. Currently, the only combination ULI supported by the mobile gateway is TAI + ECGI. LAI is not supported, therefore this value will not be used for enrichment The ULI is an optional parameter and may not be reported for an AA-sub. In this case, when enrichment is requested, the header is enriched with "User Location Unavailable".

The text preceding an inserted field is fully configurable. For example, sub-ID = 1243534666 or x-sub-ID = 1243534666.

AA supports enrichment of all HTTP methods, such as GET, POST, and so on. AA enriches HTTP traffic without having to terminate the TCP session (for example, it does not act as a proxy). In this way, AA enrichment function does not intervene with other TCP acceleration functions or appliances that could be deployed by the operator.

For configured enriched fields, operators can optionally configure AA ISA to perform MD5 hashing, RC4 encryption, and anti-spoofing.

Encryption can be performed either by configuring an encryption key, which is used to encrypt the header values using the RC4 algorithm, or by installing a certificate and configuring header enrichment to use that certificate. In the case of certificate-based header enrichment, the system uses the key contained in the HTTP header and performs encryption using the RSA algorithm. A maximum of 20 certificate profiles per group are supported.

Anti-spoofing, if enabled, ensures that only the fields enriched by AA are valid. Anti-spoofing is applicable only to the subscriber ID field.

AA statistics reflect post header enrichment packet sizes.

3.2.2.4.11. ACR HTTP Enrichment

Operators can provide an ID to portals using a unique identifier, without exposing the user's secure information (for example, the MSISDN). For this purpose, AA supports header enrichment with Anonymous Customer Record (ACR) of two types: static ACR and dynamic ACR.

A static ACR is always the same for a user. The content provider is not able to retrieve the user's MSISDN, but can track the number of times the same user has connected. To make the encryption result deterministic for the static ACR, the encryption must have padding with null ASCI characters. This ensures the same sequence of bytes is produced every time.

A dynamic ACR is created during session establishment and remains the same while the session is active. A new dynamic ACR is generated when the user reconnects. With a dynamic ACR, the operator cannot track the user's MSISDN or the number of times the user accessed the portal.

Table 22 describes how an ACR is constructed.

Note: The exceptions mentioned in HTTP Enrichment Exceptions, also apply in ACR HTTP enrichment.

3.2.2.4.12. HTTP In Browser Notification

The AA ISA HTTP notification policy-based feature enables the operator to send in browser notification messages to their subscribers. The notification format can either be an overlay, a web banner, or a splash page, which makes HTTP notification less disruptive than standard HTTP redirection for the subscriber; both the original content and the notification message can be displayed at the same time while browsing.

There is a wide range of notification use cases in Broadband and WiFi networks to use this functionality such as fair use policy threshold warning, marketing and monetization messages, late bill payment notice, copyright infringement notice and operational outages.

The solution is based on two primary components, the AA ISA responsible for specific packet manipulation and a messaging server. The messaging server controls the message format and its content while the AA ISA modifies selected HTTP flows so that the subscriber transparently downloads a script located on the messaging server. This script is then executed by the web browser to display the notification message. The AA ISA only select specific HTTP request flows meeting the criteria of a web browser session compatible with in browser notification messages.

A high level view of the typical network elements involved in HTTP in browser notifications are described in Figure 33.

Figure 33:  HTTP in Browser Notification - High Level 

The AA ISA provides full subscriber control to configure an AQP action enabling HTTP notification policy based on specific app-profiles attributes (ASO characteristics), application, or application group. The operator can dynamically modify the subscriber policy from the policy manager to enable or disable HTTP notification during the lifetime of the subscriber.

Notification Interval

The notification can be configured to be displayed either once during the lifetime of the subscriber or at configured minimum interval (in minutes). When an interval in minutes is selected, the subscriber continues to receive notifications messages while browsing.

Success Verification

The system identifies successful and failed notifications. In the event the notification is not successful, the system automatically retries notifying the subscriber at the next flow that meets the criteria of a web browser session.

HTTP Notification Example

To illustrate how HTTP notification works, the steps below describe a typical usage quota notification example with a subscriber reaching its monthly quota:

HTTP Notification Customization Through Radius VSA

The operator can customize the notification message per subscriber through the use a new radius VSA returned either at the subscriber creation time or within a CoA. This new VSA is a string appended automatically at the end of the script-url request made by the subscriber towards the messaging server, and it is not interpreted by the AA ISA. When received by the messaging server, it can be used to return specific content to the subscriber.

As an example, the HTTP Notification can be customized using the RADIUS VSA to display location based information, and the messaging server can use this data to display content based on the desired location:

3.2.2.5.1. Denial of Service (DoS) Protection

DoS attacks work by consuming network and system resources, making them unavailable for legitimate network applications. Network flooding attacks, malformed packets, and port scans are examples of such DoS attacks.

The aim of AA FW DoS protection is to protect subscribers and prevent any abuse of network resources.

Using AA FW stateful session filters, operators can protect their subscribers from any port scan scheme by configuring the session filters to disallow any traffic that is initiated from the network.

Furthermore, AA ISA provides configurable flow policers. These policers, once configured prevent all sort of flooding attacks (for example, ICMP PING flooding, UDP flooding, SYN Flood Attack). These policers provide protection at multiple levels; per system per application/application groups and per subscriber per applications/applications groups. AA ISA flow policers has two flavors; flow setup rate policers and flow count policers. Flow setup rate policers limit the number of new flows, while flow count policers limit the total number of active flows.

To protect hosts and network resources, AA_FW validates/checks the following parameters, if any fails, it declares the packet to be invalid (/Errored):

The above complements ESM enhanced security features, such as IP (or mac) anti-spoofing protection (for example, protecting against “LAND attack”) and network protocols DoS protections. The combination provides a world class carrier grade FW function.

3.2.2.5.2. TCP Validation

Operators can configure AA AQP actions to monitor TCP packet exchanges and ensure that they follow TCP handshake procedures. AA drops packets that do not conform to these procedures. AA FW checks for corrupted TCP packets and invalid TCP flag settings for the different TCP session states.

For example, if the SACK Permitted or MSS option is detected, but the calculated option length is incorrect, AA flags the packet as malformed and drops it. TCP sessions that start without a SYN and packets received after a FIN are discarded as well.

Furthermore, if strict tcp-validation is configured, AA checks and drops TCP packets with invalid sequence or acknowledgment numbers.

Drops due to TCP validation policies are recorded under permit-deny statistics. Therefore, TCAs can be configured against these statistics. Optionally, the operator can also capture TCP validation drop activity by enabling event logging.

3.2.2.5.3. Policy Partitioned AA FW

AA FW can provide up to 128 virtual/partitioned FWs, each with its own FW policies. This is achieved through the use of AA-Partitions. Different VPNs can have different FW policies/rules.

3.2.2.5.4. Configuring AA FW

AA ISA AQPs are enhanced with few new AQP actions that provide session filtering functionality. As is the case of AQPs, these have partition level scope. This allows different FW polices to be implemented by utilizing AA partitions concepts within the same AA ISA group. Hence, multiple virtual AA FW instances can be realized. There is no need for multiple physical instances of FWs to implement different FW policies.

The AA FW stateful session filter consists of multiple entries (similar to ACLs) with a match and action per entry. Actions are deny or permit. A deny action results in packets discarded without creating a session /flow context. match conditions include IP 5 tuples info. An overall default action is also configurable, in case of a no match to any session filter entry.

AQPs with session filter actions, need to have, as a matching condition, traffic direction, ASOs and/or subscriber name. It cannot have any references to applications and/or application groups.

AA FW offers, in addition to session-filter actions, a variety of AQP actions to that are aimed to allow or deny: errored/malformed packets, fragmented packets and/or first packet out-of-order fragments and overload traffic.

Statistics are incremented when packets are dropped by a session filter. These are accounted against:

A session-filter hit-count counter is maintained by AA ISA and can be viewed via CLI. There is no current support for export of session-filter entry hit counters via XML to SAM.

3.2.2.5.5. AA FW Logging

AA ISA can be configured, per AQP or per session filter, to log events related to how the packets are processed (either allowed or denied). AA supports event logging locally on the node or remotely via syslog. AA ISA FW logs contain the following information:

For AQPs, only drop events are captured in the log. The logs do not capture drops due to flow policers.

The operator can configure up to one event log per partition. For offline logging via syslog, the operator needs to configure the IP address of the syslog server and the VLAN ID to be used to connect to the server.

3.2.2.5.6. SeGW Firewall Protection

The 7750 SR SeGW with AA Firewall (AA FW) deployed in 3G/4G/Femto access networks provides the operator with back-end core network security protection. AA FW provides protection for:

Figure 36 shows an example of an SeGW firewall deployment.

Figure 36:  SeGW Firewall Deployment 

SAPs on the private side of Tunnel ISA are diverted to AA for firewall protection. If per eNB/ Femto Access Point (FAP) control is desired, then AA auto-configures/instantiate subscribers based on the “seen-ip” transit-AA subscriber model (no RADIUS interaction is required). This auto-creates a subscriber per eNB/FAP. Alternatively, AA applies firewall rules to the diverted SAP (for all eNBs/FAPs) at the aggregate level (for all eNBs/FAPs).

One AA ISA is supported per Tunnel-ISA group. Therefore, all private side SAPs that are diverted to AA for Firewalling service go to the same AA ISA module with no need to load balance the traffic into different AA ISAs. If the capacity of one AA ISA is not sufficient, then the IPsec tunnel group is split into two (or more) groups. Each group is served by an AA ISA.

3.2.2.5.7. GTP Backhaul Roaming Firewall Protection

Wireless network operators rely on the GPRS Tunneling Protocol (GTP) for the delivery of mobile data services across the access network. GTP is not designed to be secure and is exposing the mobile access network to risk from both its own subscribers and its partners' networks attacks.

While roaming is essential to mobile operators, it comes with its own additional unique security risks when providing connectivity to roaming partners’ networks and the end customers.

Figure 37 shows the S5/S8/Gn/Gp AA Firewall deployment.

Figure 37:  S5/S8/Gn/Gp AA Firewall Deployment 

AA is deployed as a GTP firewall on S8/Gp (or S5/Gn) interfaces either as part of the 7750 SR router in the form of the AA-ISA hardware module or as a separate Virtual SR (VSR) appliance. The AA firewall provides network security features, such as:

AA FW supports GTPv1 and GTPv2.

3.2.2.5.7.3. GTP-C Out-of-State Message-Type Protection

GTP is a stateful protocol. Consequently, some message types can only be sent in specific states. For example, PDP context update messages are not allowed for PDP contexts that do not exist or have been closed.

AA performs stateful GTP protocol validation and permits only packets that are allowed for any given state or a given deployment.

Table 24 lists the message types that are invalid in GTP FW roaming deployments. When AA FW GTP-C inspection is enabled, the packets with the message types listed in Table 24 are dropped and the associated event logs include a “wrong interface” indication.

Note: The packets are dropped regardless of the configuration in the message-type or message-type-gtpv2 filter.

Table 24:  Invalid Message Types in GTP FW Roaming Deployments 

GTP version	GTP-U Port	GTP-C Port
GTPv1	no invalid message types	GTPU PDU GTPV1_END_MARKER GTPV1_MSG_ERR_IND GTPV1-ALL-MBMS message-types GTPV1-ALL-Location management message-types
GTPv2	not applicable	GTP_PKT_ERROR_INDICATION GTP_PKT_DNLK_DATA_FAIL_INDICATION GTP_PKT_STOP_PAGING_INDICATION GTP_PKT_CRE_INDR_TNL_REQ GTP_PKT_CRE_INDR_TNL_RSP GTP_PKT_DEL_INDR_TNL_REQ GTP_PKT_DEL_INDR_TNL_RSP GTP_PKT_RELEASE_BEARERS_REQ GTP_PKT_RELEASE_BEARERS_RSP GTP_PKT_DNLK_DATA GTP_PKT_DNLK_DATA_ACK GTP_PKT_MOD_ACCESS_BEARERS_REQ GTP_PKT_MOD_ACCESS_BEARERS_RSP GTP_PKT_REMOTE_UE_RPRT_NOTF GTP_PKT_REMOTE_UE_RPRT_ACK

AA does not perform GTP-C inspection by default. To enable GTP-C inspection, use the following command:

*A:Dut-C>config>app-assure>group>

+---gtpc-inspection

3.2.2.5.7.5. GTP Message Type Filtering

In addition to performing stateful GTP validation, in which packets with invalid message types (that is, message types that are not applicable to the roaming interfaces) are denied, AA FW allows the operator to further restrict allowed message types by configuring entries for GTP message type filters to deny (or permit) the message types listed in Table 25.

Table 25:  Allowed Message Types That Can Be Denied 

GTP version	GTP-U Port	GTP-C Port
GTPv1	GTPV1_MSG_ECHO_REQ GTPV1_MSG_ECHO_RESP GTPV1_SUPP_EXT_HDR_NOTIF GTPV1_MSG_ERR_IND GTPV1_END_MARKER GTPU_PDU	GTPV1_MSG_ECHO_REQ GTPV1_MSG_ECHO_RESP GTPV1_SUPP_EXT_HDR_NOTIF GTPV1_MSG_VER_NOT_SUPP_IND GTPV1_MSG_PDP_CREATE_REQ GTPV1_MSG_PDP_CREATE_RESP GTPV1_MSG_PDP_UPD_REQ GTPV1_MSG_PDP_UPD_RESP GTPV1_MSG_PDP_DEL_REQ GTPV1_MSG_PDP_DEL_RESP GTPV1_MSG_NET_INIT_REQ GTPV1_MSG_NET_INIT_RESP GTPV1_MSG_MSINFO_REQ GTPV1_MSG_MSINFO_RESP
GTPv2	N/A	GTP_PKT_ECHO_REQ GTP_PKT_ECHO_RSP GTP_PKT_VERSION_NOT_SUPPORTED GTP_PKT_CRE_SES_REQ GTP_PKT_CRE_SES_RSP GTP_PKT_MOD_BEARER_REQ GTP_PKT_MOD_BEARER_RSP GTP_PKT_DEL_SES_REQ GTP_PKT_DEL_SES_RSP GTP_PKT_CHG_NOT_REQ GTP_PKT_CHG_NOT_RSP GTP_PKT_MOD_BEARER_CMD GTP_PKT_MOD_BEARER_FAIL_INDICATION GTP_PKT_DEL_BEARER_CMD GTP_PKT_DEL_BEARER_FAIL_INDICATION GTP_PKT_BEARER_RESOURCE_CMD GTP_PKT_BEARER_RESOURCE_FAIL_INDICATION GTP_PKT_SUSPEND_NOTIFICATION GTP_PKT_SUSPEND_ACK GTP_PKT_RESUME_NOTIFICATION GTP_PKT_RESUME_ACK GTP_PKT_CRE_BEARER_REQ GTP_PKT_CRE_BEARER_RSP GTP_PKT_UPD_BEARER_REQ GTP_PKT_UPD_BEARER_RSP GTP_PKT_DEL_BEARER_REQ GTP_PKT_DEL_BEARER_RSP GTP_PKT_TRACE_SESSION_ACTIVATION GTP_PKT_TRACE_SESSION_DEACTIVATION GTP_PKT_UPDATE_PDN_CONNECTION_SET_REQ GTP_PKT_UPDATE_PDN_CONNECTION_SET_RSP GTP_PKT_DELETE_PDN_CONNECTION_SET_REQ GTP_PKT_DELETE_PDN_CONNECTION_SET_RSP

By default, GTP message filtering allows all of the GTP messages.

To configure GTPv2 message filtering, use the following command:

*A:Dut-C>config>app-assure>group>

+---gtp-filter <gtp-filter-name> [create]

    +---gtpc-inspection

|   +---message-type-v2

|   |   |

|   |   +---default-action {permit|deny}

|   |   |

|   |   +---entry <entry-id> value <gtpv2-message-value> action {permit|deny}

|   |   |   no entry <entry-id>

To configure GTPv1 message filtering, use the following command:

*A:Dut-C>config>app-assure>group>

|   +---message-type

|   |   |

|   |   +---default-action {permit|deny}

|   |   |

|   |   +---entry <entry-id: 1..255> value <gtpv1-message-value> action {permit|deny}

|   |   |   no entry <entry-id>

Note: If the operator configures a message type invalid for the roaming interface and the user configures the message type to be denied, the message type will be dropped and counted under that filter entry (and not tagged dropped due to “wrong-interface” in the event log). However, configuring the message-type filter to “permit” a message type that is invalid for the roaming interface will not take effect, because the packet with the specified message type will be dropped by the GTP-C protocol inspection process.