Application Assurance

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 protocol, application, and application group definitions, as well as 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 apply only to the specific partition and not any other partitions configured under the same AA group.

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

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

• definition of unique applications and application groups per partition

• definition of AQP policy per partition

• definition of common applications and application groups per partition with per partition processing and accounting

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

• the ability to define different types of reporting and accounting policies for different partitions in a single AA group, such as uniquely defining which application, protocols, application groups are being reported on for every AA subscriber that uses a specific partition.

• AA group level protocol statistics with partition visibility (for example, protocol counts reported for each partition of the group separately)

In classic CLI, the system provides independent editing and committing of each partition configuration (separate begin, commit, and abort commands).

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

If no active AA ISA is available (for example, because of 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).

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 is a ‟no aa-isa” fault.

If 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 IOMs resume diverting the eligible packets to 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.

The system supports N+M AA ISA equipment warm redundancy (N primary and M backups, where M may be single or multiple). If there are fewer than “N” ISAs available including backups ( for example, 1+1 where both a primary and backup failed), there is a ‟no aa-isa” fault. A backup AA ISA is preconfigured with isa-aa.tim and the group policies. Datapath traffic is only sent to active AA ISAs, so a backup has no flow state. If a backup ISA is unavailable, there is a ‟backup missing” fault, which creates a log event.

If one backup is configured and there is no ISA available (for example, both a primary and backup failed), there is a ‟no aa-isa” fault, which creates a log event. A backup AA ISA is preconfigured with isa-aa.tim and the group policies. Datapath traffic is only sent to active AA ISAs, so the backup has no flow state. If a backup ISA is unavailable, there is a ‟backup missing” fault, which creates a log event.

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.

After the failure of a primary AA ISA, all of its AA subscribers and their traffic are operationally moved to a newly active backup AA ISA but the current flow states are lost (warm redundancy). The new AA ISA identifies any session-based active flows at the time of switchover as an existing protocol, while the other flows are reidentified. The existing protocol-based application filters can be defined to ensure service hot redundancy for a subset of applications. After the backup AA ISA has taken control, it is optional under user control to revert activity from a backup 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. Administratively disabling an active AA ISA is recommended to trigger an activity switch.

When AA group redundancy is configured (one or more backup ISAs or ESA-VMs) it is possible to rotate each ISA in the group into an inactive state as part of the AA minor ISSU software update as described in the SR OS R24.x.Rx Software Release Notes section "AA Signatures Upgrade Procedure". A shutdown of an active AA ISA is recommended to trigger an activity switch.

After an ISA activity switch, the following AA service impacts occur:

• All flow states for the primary ISA are lost, but existing flows can be handled with special AQP rules for the existing flows by the newly active backup AA ISA until sessions end.

• All statistics gathered on the active AA ISA since the last interval information that was sent to the CPM is lost.

The following figure shows an overview of the multichassis asymmetry removal functionality.

For a multihomed parent AA subscriber, the parent SAP or SDP that is active or inactive per chassis is agreed by the inter-chassis AA Redundancy Protocol (AARP). For single node multihomed endpoints, the AARP state is determined within a single node, as described in Multichassis datapath shunts.

• Divert AA subscribers are cost-based load balanced across ISAs in each chassis or AA group (node-local decision).

• Divert AA subscriber multihomed pairing is supported by AARP over inter-chassis link.

  • The same AARP ID is assigned to the divert SAP in both nodes.

  • AARP state in one node is master when all AARP conditions are met.

  • Packets arriving on node with the master AARP ID divert locally to ISA.

  • Packets from subscribers on a node with backup AARP ID remote divert over the subscriber side shunt, appearing to the ISA as if it was a local packet from the AA subscriber and returned to the network side interface spoke SDP shunt after ISA processing. Packets to subscribers on a node with backup AARP ID remote divert over the network side shunt, appearing to the ISA as if it was a local network side divert packet for the AA subscriber, then returned to the subscriber side interface spoke-SDP shunt after ISA processing.

  • All packets are returned to the original node for system egress (sent back over the inter-chassis shunts).

• If ISA N+1 sparing is available in a node, ISA sparing activates before AARP activity switch.

• Supports asymmetry for business SAPs and spoke SDPs, with or without transit AA subs.

• Use the following command to configure the ARRP mode of operation.

  configure application-assurance aarp master-selection-mode

  The AARP master-selection-mode is configured to minimize-switches by default, which is non-revertive and does not factor endpoint status. The ARRP mode of operation is configured per AARP instance. The priority-based-balance command option rebalances based on priority after the master failure condition is repaired. The inter-chassis-efficiency command option rebalances based on priority and includes the EP status in cases where an AARP activity switch is preferred to sustained ICL traffic load (when peer nodes are geographically remote).

Failure modes include the following:

• AARP infrastructure failure including shunts

  For AARP to remove asymmetry, the AARP link must be synchronized between peers and all components of the shunts (Ipipe shunts and interface shunts) must be up and operational. If any of those components has failed, each AARP ID operates as standalone and diverts locally. Asymmetry is not removed.

• failure of one of the interfaces to the dual homed site

  Routing moves all traffic to the remaining link or node. If this is the master AARP peer node, no action is required. For any traffic the backup node, inter-chassis shunting is used. There is no change to the AARP master/backup state. Traffic is still processed by the same ISA as before the failure.

• network reachability fails to master AARP node

  AARP node loses reachability on the network side. This does not trigger an AARP activity switch, the shunt is used to move traffic from the backup node to the master node for the duration of the reachability issue. Routing should take care of traffic reconvergence. However, if the peer AARP is also not reachable, both nodes go on standalone mode and there is no asymmetry removal.

• master AA ISA failure

  AARP activity flips for all the master AARP instances linked to this local ISA if there is no local spare available. Any traffic arriving on the node with the failed ISA uses the shunt to reach the master ISA.

The multihomed diverted AA subscriber in each peer node must be configured with the following command options set in each node of the peer pair as displayed in the following table.

AARP operation has the following required dependencies:

• For multichassis, shunt links are configured and operationally up.

• For multichassis, peer communications are established.

• Dual-homed SAP or spoke is configured.

• Application profile is configured against SAP or spoke with divert (making the subscriber an AA subscriber). This endpoint is called the primary endpoint if more than one endpoint is configured for an AARP instance.

• All endpoints within an AARP instance must be of the same type (SAP or spoke).

• All endpoints with an AARP instance must be within the same service.

A multichassis control link (MC-CTL) 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, application profile, priority and operational states.

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

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. The traffic handling is as follows:

• 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 application profile, therefore 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 application 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:

  • Dual-homed (primary) and dual-homed-secondary endpoints are configured.

  • Divert capability is up.

  • Application profile is diverting.

  • AA subscriber is configured.

With multichassis operation, there are the following operational states for an AARP instance:

• master

  In multichassis operation, an AARP instance can only become operationally master when the inter-chassis link datapath is operational and the control path is or was up, the received peer node status indicating the peer’s AARP instance and similar dependencies is or was up, and the AARP priority is higher than the peer. When the priority is equal then higher system interface IP address is used as a tiebreak.

  The master state is immediately switched to remote for AARP related failures that result in the instance being not ready. ICL datapath shunt SDP failures cause the peer AARP go standalone. A shunt/Ipipe SDP failure is determined by the failure detection protocol used (BFD on routes, keep-alive on SDPs, LDP/RSVP, and so on).

  When a SAP or spoke SDP with an AARP instance is administratively disabled, nothing changes for AARP, as packets can still use the AARP interface. When the SAP or spoke SDP is deleted, AARP is disassociated from the spoke SDP or SAP before deleting. The AARP instance still exists after deleting the SAP or spoke, but without an association to an AA subscriber, the AARP state goes standalone.

• backup

  Backup is the AARP state when all required conditions of the AARP instance are met except the master or backup priority evaluation.

• remote

  When an AARP instance is operating with remote divert set for the protecting SAP or spoke AA subscriber. The peer AARP instance is the master, there is no backup as the local system is not ready. This state is entered as a result of a failure in a local resource on the AARP instance, which triggers the divert traffic to the remote peer, such as a ISA failure without ISA backup). AA subscriber traffic is diverted over shunts to the peer.

• standalone

  AARP is not operational between the multichassis pair, with AA operating with local AA divert to the ISAs within that node. There is no master or backup. This is the starting initial state for the AARP instance, or as a result of a failure in a dependent ICL resource (MC-CTL communication link or shut down).

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 reevaluate tool, or for all instances on an ISA that fails. On an AARP activity switch, AA divert changes from local to remote or remote to local, such that any packet is not seen by both nodes, resulting in no missed packet counts or double counts against the AA subscriber.

AARP activity is non-revertive 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, often results 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 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 moves 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.

In the classic CLI, if rebalancing the ISA load between the peer nodes is necessary, use the following command option to rerun AARP activity evaluation on a per-ISA basis to determine the master and backup AARP instances based on configured priority.

tools perform application-assurance aarp force-evaluate

The following table shows the interaction and dependencies between AARP states between a local node and its peer.

For Layer 3 to Layer 7, the 7750 SR and 7450 ESS AA ISA provides 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:

• ESM subscriber

• ESM-MAC subscriber (bridged residential or vRGW device)

• distributed subscriber management (DSM) subscriber

• SAP or spoke

• transit

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:

• IES

• VPLS

• VLL (Epipe and Ipipe)

• VPRN

AA is supported with the following:

• bridged CO

• routed CO

• multihomed COs

• Layer 2 or Layer 3 VPN service access points and spoke SDPs

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:

• application traffic monitoring and reporting (per AA subscriber)

• per application bandwidth shaping, policing, and prioritization

• throttling of flow establishment rate

• limiting the number of active flows per application (such as BitTorrent, video or teleconference sessions, and so on)

• application-level classification to provide higher or lower (including drop) level traffic management in the system (for example, IOM QoS) and network

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

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 SAP or spoke SDP can be assigned an application profile, and when this application profile is enabled for diversion, all packets to and from that SAP or spoke SDP are diverted to an AA ISA (for forwarding classes that are configured as divert eligible).

The following figure shows spoke SDP divert capabilities.

A transit AA subscriber is an ISA local AA subscriber contained within a parent AA subscriber. The following are the types of transit AA subscribers:

• transit IP AA subscribers – defined by transit IP policy as one or more /32 IP addresses per sub

• transit prefix AA subscribers – defined by transit prefix policy as one or more prefix IP addresses, used in business VPNs

A transit AA subscriber incorporates the following attributes:

• name

• IP address (one or more hosts)

• application profile (the divert and capacity cost configurations of the application profile do not affect transit AA subscribers, because divert occurs only against the parent SAP)

When a SAP or spoke SDP diverted to AA is configured with transit subscribers, 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.

The following table describes transit AA subscriber support.

Use the following commands to display the transit AA subscribers within a parent AA subscriber.

show application-assurance group transit-ip-policy
show application-assurance group transit-prefix-policy

For transit IP AA subscribers, all packets are accounted for when they are in the ISA records. Therefore, transit IP AA subscriber counts do not count against the parent SAP in reporting. For transit prefix AA subscribers that are remote, traffic is processed and counted for both the local parent and the remote transit subscriber.

In the MD-CLI, use the following command to set a transit AA subscriber as remote.

configure application-assurance group partition transit-prefix-policy static-aa-sub is-remote true

In the classic CLI, use the following command to configure a static remote AA subscriber.

configure application-assurance group transit-prefix-policy static-remote-aa-sub

This section describes AA subscriber application services.

Policy structure 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:

• protocol signatures

• application filters

• applications

• application groups

• charging filters

• charging groups

• flow attributes

  

The following table describes how the ID-related components are used in AA to recognize types of flows and sessions.

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

• protocols that can be identified with this load, using a combination of pattern and behavioral techniques (used in generating statistics by protocol and are used as input in combination with other information to identify applications)

• pattern signatures (set of pattern-match signatures used in analysis)

• behavior signatures (set of diagnostic techniques used in analysis)

Dynamic upgrades of the signatures in the system are implemented using the following command and by performing AA ISA activity switches.

admin application-assurance upgrade

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 routing and forwarding engines as part of an ISSU upgrade that updates only the AA ISA software. See the upgrade procedures described in the SR OS R24.x.Rx Software Release Notes for more information.

Because 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 users 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 users more flexibility in responding to continuously 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, users 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 application filter definition). Assignment of a supported protocol to an application filter or application is not mandatory. Protocols not assigned to an application are automatically mapped by the system to the default Unknown application.

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 application 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.

The user can configure a description and custom protocol ID for a protocol, which can be administratively enabled or disabled. 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 application filter entries except strings are supported). Collection of custom protocol statistics on a partition, ISA group, or special study subscriber level is supported.

Use the following command to administratively disable a protocol:

• MD-CLI

  configure application-assurance protocol admin-state disable

• classic CLI

  configure application-assurance protocol shutdown

Administratively disabling a protocol allows for signature upgrades without automatically affecting policy behavior, especially if some or all new signatures are not required for a service. All new signatures are disabled on upgrade by default to ensure no policy or service impact caused by the signature update.

All protocols introduced at the R1 stage of a specific release are designated as ‟Parent” signatures for a specific 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 administratively disabled. They must be enabled on a per-protocol basis (system-wide) to take effect.

When administratively disabled, post R1-introduced protocols do not change AA behavior (application ID, policy, and 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 or disabling a new protocol takes affect for new flows only. The current status (enabled or disabled) of a signature and the parent protocol is visible to the user as part of retrieving protocol information through CLI or SNMP.

Protocol signatures are release independent and can be upgraded independently from the software of the router and without impacting the operations of the router as part of an ISSU upgrade. A separate document describes 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 are mapped to an Unknown application until the AA policy configuration changes to make use of the newly introduced protocol signatures.

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.

Charging groups allow usage accounting by application or application groups in a manner that does not affect application to application group mapping.

Charging groups are user-configurable groupings of applications or application groups that are charged in a similar manner.

For example, AA application group statistics for ‟Streaming Video” includes all streaming applications, independent of whether any specific application is 0-rated for charging. AA charging groups are used for charging-related statistics.

As with application groups, charging groups are defined under an AA policy context for an AA group or partition. After being defined, individual applications and application groups can be directly associated with the chosen 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 application 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 statistics RADIUS export type. After a charging group index is referenced, it cannot be deleted without removing the reference.

The priority to determine the charging group for a flow is as follows:

1. charging group assigned by a charging filter (if configured)
2. default tethered charging group (if configured)
3. charging group configured at the application level
4. charging group configured at the application group level
5. default charging group

Use the commands in the following context to define and assign a description to the application names supported by the application filter entries and assign applications to application groups.

configure application-assurance group policy application

The AA system provides no predefined 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 or application group configurations upon request. Contact the Nokia technical support staff for more information.

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

The network user can perform the following:

• Define unique applications.

• Associate applications with an application group.

  Note: The application group must already be configured.

Application filters 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 maps to only one application definition.

The system concept of application filters is similar 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 is only ever assigned to one application.

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

• unique entry ID number

• application name

• flow setup direction

• server IP address (or server IP filter list)

• HTTP port (or HTTP port list) used by HTTP proxies

• server port (or server port list)

• protocol signature

• IP protocol number

• string matches against Layer 5+ protocol header fields (for example, a string expression against HTTP header fields)

The application must already be configured before it can be used in an application filter. After being defined, the new application names can be referenced.

• 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 requests 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.

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 (IP pools) can have up to 64 IP address entries with a configurable mask for each entry.

When application awareness is not required, but requires other AA value added functions (for example, TCP-O or 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, and Layer 3 and Layer 4 application filter classification.

Use the following command to enable a specific flow attribute.

configure isa application-assurance-group flow-attribute

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

• behavioral machine learning

  This is statistical analysis of flow features to train classifiers, independent of the transport protocol. For example, flows for the Skype protocol have an encrypted attribute, but do not use TLS or QUIC. The confidence level depends on both the algorithm and traffic.

• protocol based

  Stateful packet payload inspection is used against any number of protocols to satisfy the attribute conditions. For example, the TLS protocol has the encrypted attribute. The confidence level is 0 or 100.

• app-filter based

  The AA app-DB classification of traffic into applications may be used to explicitly set flow attributes that always apply to specific application filter entries. For example, video bearer flows for an application that match video component application filters can be assigned that attribute. The confidence level is 0 or 100.

AQP traffic control policies may include flow attributes as a match condition to only affect traffic matching or not matching configurable flow attribute confidence level. Use the command options in the following context to configure the confidence level of the flow attribute to use as match criteria:

• MD-CLI

  configure application-assurance group partition policy app-qos-policy entry match flow-attribute confidence

• classic CLI

  configure application-assurance group policy app-qos-policy entry match flow-attribute confidence

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 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 are generated, if the AA subscriber is listed in both the per-aa-sub-application and per-aa-sub protocol lists.

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 because of, 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.

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 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 wanted 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 specific protocol or application, for example, sending only changed records.

Each record generated contains the record fields as described in AA statistics fields generated per record (accounting file). 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 are visible as part of the existing accounting log capability, therefore it 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 FC.

AA accounting stats of the application or 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 VPN or site and allow the option for AA to remark these into a higher traffic class, with reporting per FC to show resulting use.

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

• Family includes IPv4, IPv6, DS-Lite, 6RD/6to4, Teredo, and GTP (IP v4/v6 in v4/v6).

• Protocol includes TCP, UDP, and Other.

Therefore, AA-ISA traffic type record provides a collection of 15 sets of traffic volume (bytes) statistics figures, as shown in the following table.

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

The following table lists the statistic record fields per AA partition.

Existing average volume statistics collected over an accounting interval are extended to provide the maximum volume (bytes or 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 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.

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

• end of reporting interval snapshot of current values of the parameters listed in AA performance planning record fields into a per AA ISA Planning record. ‟Current” is the value of a counter at the end of the reporting interval, for rate based values this is the ~10sec short term current rate used in CLI statistics.

• time-based averages during record interval of the above values: Average(I)

• peak values of the preceding values in the reporting interval: Peak(I)

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 following table lists AA performance planning record fields.

The following table lists AA performance records.

At the partition level, AA provides counters that capture events associated with various application QoS policy (AQP) actions related to packet 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:

• AQP drop actions

  Drop and admit counters for ‟to” and ‟from” subscriber directions are provided for the AQP commands in the following context:

  • MD-CLI

    configure application-assurance group partition statistics aa-admit-deny accounting-policy
    configure application-assurance group partition statistics aa-admit-deny collect-stats
    configure application-assurance group partition statistics aa-admit-deny policer-stats
    configure application-assurance group partition statistics aa-admit-deny policer-stats-resources
    configure application-assurance group partition statistics aa-admit-deny session-filter-stats
    configure application-assurance group partition statistics aa-admit-deny tcp-validate-stats

  • classic CLI

    configure application-assurance group statistics aa-admit-deny accounting-policy
    configure application-assurance group statistics aa-admit-deny collect-stats
    configure application-assurance group statistics aa-admit-deny policer-stats
    configure application-assurance group statistics aa-admit-deny policer-stats-resources
    configure application-assurance group statistics aa-admit-deny session-filter-stats
    configure application-assurance group statistics aa-admit-deny tcp-validate-stats

• flow policers

  Drop and admit event counters for both ‟to” and ‟from” subscriber directions for flow count and flow rate policers, operating at the system or subscriber level.

• hit counters

  Counters for ‟to” and ‟from” subscriber directions are provided for:

  • GTP filters for each hit on entry of a GTP filter as well as drops related to the GTP maximum size and default action. The GTP maximum size and SCTP PPID range action hit counts only report drop statistics and not permit statistics.

  • SCTP filters for each hit on entry of an SCTP filter as well as hits on PPID range and default actions

  • session filters for each hit on entry within a session filter and default action

AA-partition traffic type statistics lists the record names used for AA admit-deny statistics.

AA collects TCP statistics records, which contain the following information about the TCP protocol:

• TCP total packets and bytes in each direction. The total count includes admitted and denied packets and bytes counters.

• TCP retransmitted packets and bytes in each direction

The counters are updated upon flow closures and are only available if the TCP retransmission dynamic cflowd field is selected to be included in the comprehensive cflowd template with an associated cflowd sampling rate configured.

These counters are accessible in the following ways:

• a new SNMP Table (tmnxBsxGrpTrafficTable)

  The table is indexed by AA group and card/MDA, or AA group and all ISAs in group (card/MDA 0/0).

• the following MD-CLI state commands:

  state application-assurance group status traffic statistics net-to-sub tcp-total
  state application-assurance group status traffic statistics net-to-sub tcp-retransmissions
  state application-assurance group status traffic statistics sub-to-net tcp-total
  state application-assurance group status traffic statistics sub-to-net tcp-retransmissions
  

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 subscriber to be exported with a common accounting session ID. The following statistics are included in each record. Accounting values are for forwarded packets:

• input octets (from-sub)

• input packets (from-sub)

• output octets (to-sub)

• output packets (to-sub)

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.

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 ISA detects the start of a subscriber application (by setting usage threshold to be very low).

• A pre-set usage volume per subscriber application is exceeded.

AA can monitor subscriber’s traffic for any defined:

• application

• application group

• charging group

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:

• A usage threshold is reached.

• The PCRF explicitly disables usage monitoring.

• The PCRF requests for a report.

• When the ADC or PCC rule associated with the monitoring instance is removed or deactivated.

• When a session is terminated.

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

• It is already selected for either XML or RADIUS per subscriber accounting.

• It is explicitly enabled by the operator for per sub statistics collection.

• Usage monitoring is enabled for the specific AA group:partition.

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

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 (Usage monitoring).

No time based thresholds are supported.

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

• CC-Input-Octets AVP (code 412): From Subscriber total byte count threshold

• CC-Output-Octet AVP (code 414): To subscriber total byte count threshold

• CC-Total-octets AVP (code 421): Threshold of aggregate traffic (Input and Output byte counters)

As shown in Usage monitoring (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 subscriber (and an 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 because of –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.

• ADC Rule AVP

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

  • For installing a new ADC rule or modifying an ADC rule already installed, ADC-Rule-Definition AVP shall be used.

  • For activating a specific predefined ADC rule, ADC-Rule-Name AVP shall be used as a reference for that ADC rule.

  
  ADC-Rule-Definition ::= < AVP Header: 1094 >
                          { ADC-Rule-Name }
                          [ TDF-Application-Identifier ]
                          ;  AA charging group /application group / application name
                          [ Flow-Status ]*
                          [ QoS-Information ]*
                          [ Monitoring-Key ] 
                          [ Redirect-Information ] ::= < AVP Header: 1085 >*
                              [ Redirect-Support ] ; *
                              [ Redirect-Address-Type ];*
                              [ Redirect-Server-Address ];*
                          [ Mute-Notification ]*
  
                          *[ AVP ]
  
  

  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 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 toward AA-ISA.

  • For installing a new PCC rule or modifying an PCC rule already installed, the ADC-Rule-Definition AVP shall be used.

  • For activating a specific predefined ADC rule, ADC-Rule-Name AVP shall be used as a reference for that ADC rule.

  
  Charging-Rule-Definition ::= < AVP Header: 1003 > 
  { Charging-Rule-Name } 
            [ TDF-Application-Identifier ] 
            [ Monitoring-Key] 
             ………..   
            *[ AVP ] 
  
  

  Charging-Rule-Name is 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:”. For example, AA-UM: Peer to peer traffic for APN x”.

  TDF-application-Identifier specifies a predefined AA charging group, application group or application name for which usage monitoring functionality is required (for a 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). 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.

  Usage-Monitoring-Information ::= < AVP Header: 1067 >
                            [ Monitoring-Key ]
                            [ Granted-Service-Unit ]
                            [ Used-Service-Unit ]
                            [ Usage-Monitoring-Level ]
                            [ Usage-Monitoring-Report ]
                            [ Usage-Monitoring-Support ]
                           *[ AVP ]
  

• 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 or CC-Output-Octets AVPs shall be used for providing threshold level for the uplink volume or the downlink volume.

  Granted-Service-Unit ::= < AVP Header: 431 >
                            [ Tariff-Time-Change ]*
                            [ CC-Time ]*
                            [ CC-Money ]*
                            [ CC-Total-Octets ] 
                            [ CC-Input-Octets ]
                            [ CC-Output-Octets ]
                            [ CC-Service-Specific-Units ]*
                           *[ AVP ]*
  

  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.

  Used-Service-Unit ::= < AVP Header: 446 >
                            [ Tariff-Change-Usage ]*
                            [ CC-Time ]*
                            [ CC-Money ]*
                            [ CC-Total-Octets ]
                            [ CC-Input-Octets ]
                            [ CC-Output-Octets ]
                            [ CC-Service-Specific-Units ]*
                           *[ AVP ]*
  

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

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

  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.

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

  • SESSION_LEVEL (0) is not applicable for AA-ISA.

  • If PCC_RULE_LEVEL (1) is provided within an RAR or CCA command by the PCRF, it indicates that the usage monitoring instance applies to one or more PCC rules. This is used in 3GPP Release 12 by the AA Usage Monitoring feature.

  • If ADC_RULE_LEVEL (2) is provided within an RAR or CCA command by the PCRF, it indicates that the usage monitoring instance applies to one or more ADC rules. This is used in 3GPP Release 11 by the AA Usage Monitoring feature.

• 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 a specific usage monitoring key (within a Usage-Monitoring-Information AVP).

  If USAGE_MONITORING_REPORT_REQUIRED (0) is provided within an RAR or CCA command by the PCRF, it indicates that accumulated usage shall be reported by the PCEF.

  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 a specific Monitoring Key.

  USAGE_MONITORING_DISABLED (0) indicates that usage monitoring is disabled for a monitoring key.

• 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.

  USAGE_REPORT (26) is used in CCA and RAR commands by the PCRF when requesting usage monitoring at the PCEF (AA ISA). The PCRF also provides in the CCA or RAR command the Usage-Monitoring-Information AVPs including the Monitoring-Key AVP and the Granted-Service-Unit AVP.

  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 does not report usage-monitoring when a threshold is crossed.

• Usage-Monitoring disabled

  When 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.

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 in band on a configurable VLAN from AA or via the CPM, similar to the way system cflowds are exported. By exporting directly in band, a higher rate of cflowd records can be exported compared to export via CPM, as inband export by-passes CPM and therefore avoids the CPM bottleneck that could potentially 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 after 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 applications and application groups for sampling. Therefore, providing finer control at the application/application group level, instead of 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 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 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.

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 multidevice 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 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.

Match criteria consists of any combination of the following parameters:

• the source/destination IP address and port/port-list, or IP-prefix list

• application name

• application group name

• charging group name

• one or more ASO characteristic and value pairs

• direction of traffic (subscriber-to-network, network-to-subscriber, or both, or spoke SDP)

• DSCP name

• AA subscriber (ESM, DSM, or transit subscriber, SAP or spoke SDP)

• IP protocol field, which when used in AQP matches allows more precise control of match criteria; for example, to specify port or IP address matches specifically for either TCP or for UDP.

• subscriber tethering state

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.

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

• dual or single-bucket bandwidth rate limit policer

• drop (discard)

• error drop

• flow count limit policer

• flow setup rate limit policer

• fragment drop

• HTTP enrichment

• HTTP error redirect

• HTTP notification

• HTTP redirect

• HTTPS redirect

• source mirror for an existing mirror service

• remark QoS (one or a combination of discard priority, forwarding class name, DSCP). When applied, ingress marked FC and discard priority is overwritten by AA ISA and the new values are used during egress processing (for example, egress queueing or egress policy DSCP remarking). For MPLS class-based forwarding, ingress-marked FC is still used to select an egress tunnel.

• none (monitor and report only)

• session filter

• URL-Filter (ICAP or web-service based URL filtering)

• GTP filter

• SCTP filter

• TCP MSS adjust

  The value entered should be the MSS value needed for IPv4 packets. IPv6 packets are automatically adjusted to 20 bytes less reflecting the larger IP header.

• TCP validate

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 one flow can match multiple entries, in which case multiple actions are selected based on the AQP entry’s order (lowest number entry, highest priority) up to a limit of:

• 1 drop action

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

  • up to 1 mirror action

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

  • up to 4 BW policers

  • up to 12 flow policers

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:

• Limit the subscriber to 20 concurrent Peer To Peer (P2P) flows max.

• Rate limit upstream total P2P application group to 400 kb/s.

• Remark the voice application group to EF.

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

There are six types of policers:

• Flow rate policer monitors a flow setup rate.

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

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

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

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

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

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

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

Policers are unidirectional and are named with these attributes:

• policer name

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

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

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

• parameters for flow count (maximum number of flows)

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

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

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

• burst size (CBS and MBS)

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

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

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

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

Policers are applied with the following levels of hierarchy (granularity):

• per flow

  • per individual flow

  • single rate bandwidth policers monitor bandwidth using single rate and burst size parameters

  • the policers are applied at the scope of individual flows

• per individual AA subscriber

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

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

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

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

  • total protocol/application rate

  • total app group rate

• Per ANL

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

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

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

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

Charging filters are an optional mechanism to allow the charging group to be assigned based on additional criteria, including flow attributes and tethering detection. Charging filters enable the system to differentiate charging between different traffic component types even within a common application.

For example, video traffic from an application may be charged differently from other traffic types of the same application.

The match criteria are followed by an action that specifies the charging group for these match criteria. If a user configures more than one match condition, the conditions will be ANDed. Charging filters use a first-match list of entries (like app-filter entries), evaluated in numerical order, that allows flexible priority in setting the charging criteria.

For TCP session throughputs to reach the full rate of the available bandwidth, the Receiver Window size (RWIN) must be equal to or larger than the Bandwidth Delay Product (BDP).

Calculate BDP as follows: BDP (bytes) = total available bandwidth ✕ round trip time

AA TCPO dynamically sets RWIN toward the network side large enough to fit or exceed the maximum available bandwidth times maximum anticipated delay, therefore achieving max throughput for a specific bandwidth speed. AA TCPO performs automatic adjustment of RWIN based on the various dynamic factors such as available buffers and delays.

The basic problem limiting TCP performance arises from how the TCP congestion avoidance algorithm interacts with networks having large BDP. Congestion avoidance increases the sender's TCP window by only a single packet for each successful round-trip acknowledgment.

When the TCP window is small, increasing it by a single packet is reasonable, but if a window is very large (for hundreds of packets), then each additional round-trip acknowledgment adds a small increase to the sender's TCP window. In this case, it takes an extraordinarily large number of round trips to rebuild the TCP window in response to a single packet loss, and this leads to slow TCP behavior.

Data shows that when the bandwidth is above a specific level (4M), it has no effect on the webpage loading. On the other hand, reduced RTT directly benefits page loading.

During the TCP congestion avoidance phase, lower RTT decreases the BDP threshold, which means higher throughput for the same bandwidth and RWIN values. The throughput is then limited by the segment with the highest RTT.

AA TCPO reduces RTT, as retransmissions because of loss in the access network are handled by the AA instead of the content server. AA allocates enough buffers in the downlink direction according to the BDP.

The main benefit of reducing RTT is a faster recovery from a packet loss event.

Traditional TCP stacks consider a packet loss event as a sign of congestion. However, in mobile and wireless networks, AA TCPO implements TCP Illinois, TCP BBR, or TCP Westwood (TCPW) toward the subscriber to address packet loss because of non-congestion events. These TCP stacks use bandwidth and delay estimates to enhance the window control (cwin) and back-off process which ensures both faster recovery and more effective congestion avoidance in RAN deployments.

The size of the initial congestion window is a key component of the TCP slow start, also known as the exponential growth phase. Using standard TCP, a period of three RTT is required for an average HTTP web load during slow start, which can happen after a packet loss. However, the majority of web transactions are short and small, under 16 kbytes, and they complete before the slow start has a chance to ramp up. To make full use of the significant bandwidth offered in mobile networks, the AA TCPO sets the default size of the initial congestion window high enough to allow small web transactions to take place within one RTT period. The AA TCPO also offers the user the ability to configure the size of the initial congestion window as part of the AA TCPO configuration policy.

Use the following command option to configure the size of the initial congestion window:

• MD-CLI

  configure application-assurance group tcp-optimizer initial-cwnd

• classic CLI

  configure application-assurance group tcp-optimizer init-cwnd-size

Mobile data networks suffer from buffer bloating. Buffer-bloating phenomena works against the TCP congestion control mechanism and results in poor performance. See Over-buffering in mobile networks.

The two issues that contribute to the bad effect buffer bloating has on TCP performance are:

• Standard TCP congestion control mechanism is loss based.

• Wireless networks employ over-buffering to compensate for burst traffic and channel changes (soft handover). These large buffers tend to conceal packet loss from the sender.

The preceding two factors result in a TCP sender continuing to increase its sending rate even if it has already exceeded the bottleneck link bandwidth capacity. The extra packets are all absorbed by the buffers and the rest are dropped, adding several seconds to the RTT. Networks that suffer from buffer bloating report fluctuation in RTT over time and large bursts of discards or drops.

There are two possible solutions to solve the problem with buffer bloating, while still maintaining high throughput close to BDP:

• Use a dynamic RWIN mechanism at the handsets.

• Deploy delay-based or bandwidth-based TCP sender stacks. This deployment overcomes buffer-bloating issues because these TCP congestion mechanisms use RTT or available bandwidth, which is based on RTT measurements, as in TCPW, to adjust the cwnd size.

AA TCPO is an AA session filter configurable action that refers to a configurable TCPO policy.

Using this session-filter action, operators can optionally target some IP servers for optimization, or conversely exclude specific sites (servers IP addresses) from optimization.

Using the TCPO policy, the operator can select the TCP stack to be used toward the access network, as well as TCP congestion algorithm parameters, such as cwnd and the initial slow start threshold.

Operators can enable or disable Delayed ACK (DACK) as part of the TCPO configuration policy. However, DACK timeout is not configurable. It is set at 200 ms.

Operators have the option to enable TCPO for only those TCP flows that have a network side delay above a configurable threshold. This provides an option, for example, to disable TCPO for content that is colocated with the TCP optimizer.

In addition, operators can use the ADP action to abandon TCP optimization, which disables the TC optimizer for the flows that match the configured AQP match conditions, such as detected application and application groups. This provides a mechanism for the operator to target, or exclude, specific applications or application groups from undergoing TCPO.

TCP Selective ACK (SACK) is supported by AA TCPO if both the server and client negotiate SACK successfully.

AA TCPO implements the TCP new-reno stack toward the core network and TCPW, TCP BBR, or TCP Illinois configurable toward the access network.

AA TCPO does not modify or change the advertised MSS setting.

For interactions between AA TCPO and the rest of the AA feature set (such as policers), AA TCPO is logically implemented upstream from AA toward the core network. For example, if policing is enabled for a subscriber in the "from subscriber” direction, the subscriber packets are subjected to policing before any AA TCPO related action is applied to these packets. Similarly, "from subscriber" statistics maintain counts of flows before hitting the TCPO. On the other hand, in the downstream direction, the "to subscriber" statistics reflect post AA TCPO behavior, while "to subscriber" policing is applied to packets generated by AA TCPO toward the subscriber. The same concept applies to other AA features such as TCP performance measurements and HTTP enrichments.

AA TCPO does not perform any optimization for flows that have fragmented packets, IPv6 extension headers or unsupported or unknown TCP options, such as TCP encrypt. If such packets are received in the middle of the session, AA TCPO ceases optimization for the rest of the session duration.

Nokia recommends enabling the error-drop AQP action to avoid having error packets bypassing AA TCPO and reaching the end systems. Similarly, Nokia recommends that the operator configures the drop out-of-order fragments AQP action.

Operators are recommended to configure session-filter entries to drop unsupported IPv6 extension headers to keep the state machine of AA TCPO synchronized with the TCP stacks at the endpoints.

The unsupported extension headers are:

• 139, Experimental use, Host Identity Protocol [RFC 5201]

• 140, Level 3 Multihoming Shim Protocol for IPv6, [RFC 5533]

• 253, Assigning Experimental and Testing Numbers Considered Useful [RFC 3692], Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers [RFC 4727]

• 254, Assigning Experimental and Testing Numbers Considered Useful [RFC 3692], Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers [RFC 4727]

If these packets arriving in the middle of a flow are not dropped, they arrive at the far end TCP stack without going through AA TCPO. Problems arise when packets of the same session are sent without having EH, arrive at TCPO, but AA TCPO has missed the earlier packet exchanges for that session.

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 specific 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 because of 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 Wi-Fi radio. See Wi-Fi network congestion at AP radio.

Increased penetration of Wi-Fi-enabled devices (for example, mobile handsets, tablets, laptops, and TVs) and widespread use of streaming video results in frequent data plane congestion events in Wi-Fi networks. This congestion results in service degradation for Wi-Fi 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 Wi-Fi 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).

DEM technology is an implementation of intelligent congestion control. If congestion is predicted or detected, the DEM gateway automatically scales back the less delay-sensitive traffic and gives priority to more delay-sensitive applications. Applications are managed to their respective resource needs to provide the best QoE. Over The Top (OTT) applications and users are managed to their respective resource needs and configured preferences.

A DEM-GW builds on AA Layer 3 to Layer 7 DPI capabilities to detect applications per AA subscriber as well as per congestion point. It allows the DEM-GW AA to take intelligent actions when congestion occurs in the access network.

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 DEM-GW multipoint 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:

• running DPI to classify flows into applications, including encrypted traffic

• dynamically learning access network congestion points and estimating their maximum capacity:

  • through real-time detection, sniffing, measurements and profiling

  • continuous monitoring of UEs locations and associating them to the right access point radio congestion points

• QoE enforcement (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 unrestricting 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.

Non-Location Based DEM (NLB-DEM) operates in any access network, within the scope of a subscriber. As such, no location information is required.

NLB DEM-GW runs a congestion detection algorithm at the subscriber level using its RTT mechanism, independent of the user location information or the location of congestion within the access network (for example, Wi-Fi, fixed wireless, DSL, Cable, and so on). Per-subscriber bandwidth policers, if configured, can be triggered if subscriber traffic congestion is detected.

Unlike WLAN-DEM, NLB-DEM does not offer reporting or actions at the ANL level. However, NLB-DEM still offers per-subscriber policing congestion override and does not require any policy interface to pass location information. This makes NLB-DEM flexible and light weight, allowing NLB-DEM to be deployed in any type of access network.

DEM-GW employs adaptive bandwidth policer variants of AA single leaky bucket bandwidth policers, called Access-Network-Location policers. These policers are used exclusively with DEM-GW congestion points (WLGW AP radio). They are similar to existing single bucket policers, but differ in the following aspects:

• The policer rate is configured using a ratio (/%) instead of absolute rates.

• The ratios are applied against the total estimated measured capacity of the congestion point to derive the actual policer's rate. For example, for measured capacity at congestion time of 1.5Mbps, or a configured policer rate of 30%, the actual policer rate applied:1.5*30% =0.5 Mbps.

• Adaptive policers are applied only in the downstream traffic direction.

• Adaptive policers run only while the associated ANL is in congestion state. No action is taken when there is no congestion.

These policers are invoked using existing AQP mechanisms that match configured parameters such as apps or app-groups and execute the configured actions.

Adaptive-policers are used to throttle traffic going through access point radios during congestion state. Multiple adapt-policers can be configured per congestion point-type (type =MAC+VLAN). For example:

• adapt-policer 1,rate=20(%), backhaul links — called from AQP entry with ‟email” app-group match condition

• adapt-policer 2,rate=10(%), backhaul links — called from AQP entry with OTT video app-group match condition

• adapt-policer 3,rate=0(%), backhaul links — called from AQP entry with p2p app-group match condition (this effectively drops p2p traffic during congestion)

Although ANL adaptive policers apply to all traffic going through the ANL to maintain a positive customer experience and ensure priority traffic is not starved during congestion, they do not differentiate between identical traffic classes belonging to different subscribers.

The per-subscriber policers are enabled automatically when the following command is enabled and the subscriber is in a congestion state.

• MD-CLI

  configure application-assurance group policer flow-bandwidth-policer congestion-override
  configure application-assurance group policer single-bucket-bandwidth-policer congestion-override
  

• classic CLI

  configure application-assurance group policer congestion-override

Typically, the policing rate is set so that it mostly affects heavy users. The congestion override policers can be used for all DEM use cases, such as NLB-DEM and ANL-based DEM. The operator can configure a second-stage congestion override policer. Second stage policers are applied when congestion persists even after applying the override congestion policers. Typically, the operators set a stricter bandwidth control in second stage policers to relieve congestion conditions.

Very similar to Time-of-Day (ToD) policers, per-subscriber congestion policers can be applied to all the traffic of a subscriber, specific applications, or application groups as configured in the matching section of AQPs.

Location-based analytics provides the operator with an accurate view of the subscriber's location (ANL) and application usage for a specified location in Wi-Fi networks for the purpose of data-mining. See 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.

URL filtering categories lists all the URL filtering categories supported by the AA for web-service URL classification. For information about web-service URL classification, see Web-service URL classification. For information about configuring web-service URL classification, see Configuring web-service URL classification.

Operators want to prevent subscribers from accessing illegal content in the following situations:

• court-ordered URL takedown

• child pornography related content

• government-mandated URL takedown list

Operators can use AA to comply with these regulatory requirements, typically driven by government or court order to control the access to specific URLs hosting illegal content. In the context of child protection the operator may be required or incited to provide this filtering.

Local URL-list filtering is applied network-wide to all subscribers. This solution provides a cost-efficient method by storing the list of URLs to be filtered on the system compact flash. Therefore, using the AA-ISA ICAP functionality along with an external server is not necessary.

The ISA-AA local url-list filtering policy provides URL control capability using a list of URLs contained in a file stored on one of the system’s compact flash cards. The router uses the AA capabilities to extract the URL from the subscriber's HTTP request and compares it to the list of URLs contained in this local file. If a match is found, the subscriber flow is redirected to a preconfigured web server landing page typically describing why the access to this resource was denied.

Operators may have a list of hostnames for which they do not want to perform any web-service URL classification (or ICAP-based URL filtering). Sites may include the operator's portals or portals which the operator trusts as safe.

Similar to the deny-lists, the globally allowed sites are included in a file and in a local filtering url-filter. If a subscriber's HTTP request is included in the allow-list, then access to the site is allowed. The system does not check any additional URL filters (if configured).

The system supports a flexible mechanism to upgrade a local URL list automatically using either CRON or the NSP NFM-P to comply with the regulatory requirements for list upgrade frequency.

Each HTTP request within a TCP flow is filtered by the AA ISA. For HTTPS traffic, the system extracts the domain name information contained in the SSL/TLS server name.

AA HTTP enrichment functionality has the following exceptions:

• To handle the case of TCP retransmission, AA ISA implements an enrichment window of size = 5. If a retransmission of a packet occurs outside the last five enriched packets, no enrichment takes place.

• Corrupted packets; AA ISA-cut-through and out-of-order fragments are not enriched.

• Out-of-sequence packets are not enriched. For example, if AA –ISA receives out-of-sequence HTTP requests: REQ2,REQ1,REQ3; only REQ2 and REQ3 can be enriched.

• No enrichment takes place if, by enriching, the resulting packet size exceeds the configured MTU size. AA ISA does not perform fragmentation. Verify the maximum HTTP enriched packet size configured using the following command, and ensure that the MTU configured on all interfaces is greater:

  • MD-CLI

    configure isa application-assurance-group http-enrich-max-packet-size

  • classic CLI

    configure isa application-assurance-group http-enrich-max-pkt

  If the MTU is exceeded, the packet is forwarded but not enriched.

• The length of an encrypted header is directly analogous to the length of the encryption key. If a 2048-bit key is used, the encrypted header becomes 512 bytes long. Operators must be cautious when defining the key length and selecting which fields are encrypted and enriched to ensure that the configured MTU size is not exceeded.

• AA ISA does not support header enrichment for WAP1.x, RTSP or SIP headers.

• AA ISA does not support header enrichment for L2 services.

• AA TCP performance measurements cannot coexist with HTTP enrichment. Enriched flows are ineligible for TCP performance sampling. If a flow is selected for TCP performance measurements and is later enriched, then TCP performance measurements cease to continue.

• Enrichment can be applied as an action to any AQP entry, subject to the following conditions:

  • The matching conditions for the AQPs cannot include a specific HTTP protocol (such as, protocol eq HTTP_video). In other words, applications that require a specific HTTP protocol type (such as video or Flash) are not considered for enrichment.

  • Within the same AQP entry, the enrichment action cannot coexist with any other AQP action (such as mark or police).

  • The AQP hit counter is not updated based on executing an HTTP enrichment action of an AQP.

• If it cannot extract the APN Network Identifier (APN-NI), AA performs enrichment using the entire APN string.

Denial of Service (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, when configured, prevent all sorts 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):

• IP layer validation:

  • IP version is not 4 nor 6

  • checksum error (IPv4)

  • header length check

  • packet length check

  • TTL/Hop limit (not equal to zero) check

  • fragment offset check (teardrop and ping of death protection)

• class D/E (>=224.0.0.0)

• broadcast 255.255.255.255 (multicast source address)

• 127.x.x.x (invalid source address)

• invalid subnet (subnet, 0) [unless /31 point-to-point interface]

• invalid subnet multicast (subnet, -1) unless /31 point-to-point interface

• IPv4 destination address checks:

  • broadcast 255.255.255.255, 0.x.x.x,127.x.x.x

• IPv6_source address checks:

  • multicast source address (FFxx:xxxx:……:xxxx)

• IPv6_destination address checks:

  • invalid destination address (=::)

• TCP/UDP validation:

  • header checksum

  • source or destination ports (not equal to zero) check

    (only dest port is checked for UDP)

  • invalid TCP flags

    • TCP FIN Only (only the FIN flag set)

    • TCP No Flags (no flags are set)

    • TCP FIN RST (both FIN and RST are set)

    • TCP SYN URG (both SYN and URG are set)

    • TCP SYN RST (both SYN and RST are set)

    • TCP SYN FIN (both SYN and FIN are set)

  • validates that the first packet of a TCP flow does not contain RST or FIN flags

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.

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 because of 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.

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.

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 or subscriber name. It cannot have any references to applications 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 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:

• protocol = denied by default policy

• application= unknown

• application group = unknown

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.

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:

• group partition

• timestamp

• 5-tuple

• direction

• subscriber info (if available)

• log source/type (session-filter or AQP)

• action (allow/drop)

• session-filter specific

  • session-filter name

  • session-filter entry

• AQP specific

  • drop reason

  • fragment offset (if applicable)

  • fragment ID (if applicable)

  • TCP validation policy (if applicable)

• If an out of order fragment triggers the log, then whatever 5-tuple information is available is included.

For AQPs, only drop events are captured in the log. The logs do not capture drops because of 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.

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:

• S1-MME (SCTP) traffic

• S1- U (GTP-U) traffic

• OAM traffic

SeGW firewall deployment shows an example of an 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 needed, then AA auto-configures or instantiates 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.

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.

S5/S8/Gn/Gp AA firewall deployment shows the 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:

• GTP protocol validation (checks for anomaly attacks that involve malformed, corrupt, or spoofed traffic):

  • header length checks

  • IE length validation

  • invalid reserved field validation

  • reserved information elements validation

  • missing mandatory information elements validation

  • out of state message/information elements validation (GTPv1-c only)

  • sequence number validation

  • TEID validation (blocks GTP tunnel creations that have not been signaled correctly)

• GGSN/PGW and SGSN/SGW redirection protection

• GTP-in-GTP check

• handover control to prevent session hijacking

• source address—UE – anti-spoofing protection

• protection against unauthorized Public Land Mobile Network (PLMN) access and unauthorized APN access by filtering based on APN, International Mobile Station Identity (IMSI) prefix, GTP src IP address prefix list

• protection against unsupported GTP message types by filtering messages based on message type and message length

• protection against flooding attacks:

  • GTP traffic bandwidth policing (limits the GTP bandwidth from a roaming partner’s SGSN or SGW)

  • GTP tunnel limiting (limits the number of concurrent GTP tunnels and the setup rate of these tunnels from a roaming partner’s SGSN or SGW)

• protection against IP fragmentation-based attacks by using drop rules for IP fragmentation of GTP messages

AA FW supports GTPv1 and GTPv2.