Application Assurance

AA overview

Network operators are transforming broadband network infrastructures to accommodate unified architecture for IPTV, fixed and mobile voice services, business services, and High Speed Internet (HSI), all with a consistent, integrated awareness and policy capability for the applications using these services.

As bandwidth demand grows and application usage shifts, the network must provide consistent application performance that satisfies the end customer requirements for deterministic, managed quality of experience (QoE), according to the business objectives for each service and application. AA is the enabling network technology for this evolution in the service router operating system.

AA, coupled with subscriber or VPN access policy control points enables any broadband network to provide application-based services. For service providers, this unlocks:

  • the opportunity for new revenue sources

  • content control varieties of service

  • control over network costs incurred by various uses of HSI

  • complementary security aspects to the existing network security

  • improved quality of service (QoS) sophistication and granularity of the network

  • the ability to understand and apply policy control on the transactions traversing the network

AA: inline policy enforcement

The following shows AA ISA inline identification, classification, and control.

Figure 1. AA ISA inline identification, classification and control

The integrated solution approach for AA recognizes that a per-AA subscriber and per-service capable QoS infrastructure is a pre-condition for delivering application-aware QoS capabilities. Enabling per-application QoS in the context of individual subscriber’s VPN access points maximizes the ability to monetize the application service, because a direct correlation can be made between customers paying for the service and the performance improvements obtained from it. By using an integrated solution there is no additional cost related to router port consumption, interconnect overhead or resilience to implement in-line application-aware policy enforcement.

AA integration in subscriber edge gateways

Multiple deployment models are supported for integrating AA in the various subscriber edge and VPN PE network topologies (AA deployment topologies). In all cases, AA can be added by in-service upgrade to the installed base of equipment instead of needing to deploy and integrate a whole new set of equipment and vendors into the network for Layer 4-7 awareness.

Integrating Layer 4-7 application policy with the 7750 SR or 7450 ESS subscriber edge policy context is the primary solution to address both residential broadband edge and Layer 2/Layer 3 application aware business VPN. Placement of Layer 4-7 analysis at the distributed subscriber edge policy point simplifies AA deployments in the following ways:

  • For residential markets, CO-based deployment allows deployment-driven scaling of resources to the amount of bandwidth needed and the amount of subscribers requiring application-aware functionality.

  • For AA business VPNs, a network deployment allows large scale application functionality at a VPN provider edge access point, vastly reducing complexity, cost, and time-to-market required to offer application-aware VPN services.

  • Traffic asymmetry is avoided. Any subscriber traffic usually passes through one CO subscriber edge element so there is no need for flow paths to be recombined for stateful analysis.

  • PE integration provides a single point of policy enforcement.

  • SeGW integration provides firewall protection for NMS, MME and SGW.

    The following shows AA deployment topologies.

    Figure 2. AA deployment topologies

There are residential topologies where it is not possible or practical to distribute ISAs into the same network elements that run ESM, including for legacy edge BRASs that still need AA policy (reporting and control) for the same Internet services, and which needs to be aligned and consistent with the ESM AA policy. This is supported using transit AA subscribers, typically in the first routed element behind the legacy edge.

AA enables per AA subscriber (a residential subscriber, or a Layer 2 or Layer 3 SAP or spoke SDP), per application policy for all or a subset of AA subscriber's applications. This provides the ability to:

  • implement Layer 4-7 identification of applications using a multitude of techniques from a simple port-based/IP address based identification to behavioral techniques used to identify, for example, encrypted or evasive applications

  • when identified, apply a QoS policy on either an aggregate or a per-AA subscriber, per-application basis

  • provide reports on the identification made, the traffic volume and performance of the applications, and policies implemented

An integrated AA module allows the SR and ESS product families to provide application-aware functions that previously required standalone devices (either in residential or business environment) at a fraction of the cost and operational complexity that additional devices in a network required.

A key benefit of integrating AA in the existing IP/MPLS network infrastructure (as opposed to an in-line appliance) is the ability to select traffic for treatment on a granular, reliable basis. Only traffic that requires AA treatment is simply and transparently diverted to the ISA. Other traffic from within the same service or interface follows the normal forwarding path across the fabric. In the case of ISA failure, ISA redundancy is supported and in the case where no backup ISAs are available, the AA traffic reverts to the normal fabric matrix forwarding, also known as ‟fail to fabric”.

Traffic diversion to the ISA lists ISA traffic diversion information.

Table 1. Traffic diversion to the ISA
Deployment case System divert ID AA subscriber type App-profile on:

Residential Edge (BNG)

ESM Sub-ID

ESM

ESM sub (All IPs, not per-host)

vRGW Bridged Residential Gateway (BRG) subscriber

ESM Sub-ID

ESM

ESM sub (All IPs, not per-host)

vRGW BRG session

ESM-MAC

ESM-MAC

ESM-MAC (by device, for any hosts assigned to a device

Wireless LAN GW

ESM or DSM

ESM or DSM

ESM or DSM

Business Edge

L2/L3 SAP

SAP

SAP (Aggregate)

Residential Transit

Parent L3 SAP or spoke SDP

Transit AA

Transit Sub

Spoke Attached Edge

Spoke SDP

Spoke SDP

Spoke SDP (Aggregate)

SeGW

Parent SAP or spoke SDP or L2/L3 SAP

Transit AA

SAP

Transit AA

SAP

Fixed residential broadband services

Fixed residential HSI services as a single edge Broadband Network Gateway (BNG), virtualized Residential Gateway (vRGW), or as part of the Triple Play Service Delivery Architecture (TPSDA) are a primary focus of AA performance, subscriber and traffic scale.

To the service provider, application-based service management offers:

  • application aware usage metering packages (quotas, 0-rating and so on)

  • new revenue opportunities to increase ARPU (average revenue per user) (for gaming, peer-to-peer, Internet VoIP and streaming video, and so on)

  • fairness (aligns usage of HSI network resources with revenue on a per-subscriber basis)

  • operational visibility into the application usage, trends, and pressure points in the network

To the C/ASP, service offerings can be differentiated by improving the customer’s on-line access experience. The subscriber can benefit from this by gaining a better application experience, while paying only for the value (applications) that they need and want.

DS-Lite

Dual-Stack Lite (DS-Lite) is an IPv6 transition technique that allows tunneling of IPv4 traffic across an IPv6-only network. Dual-stack IPv6 transition strategies allow service providers to offer IPv4 and IPv6 services and save on OPEX by allowing the use of a single IPv6 access network instead of running concurrent IPv6 and IPv4 access networks. DS-Lite has two components: the client in the customer network (the Basic Bridging BroadBand element (B4)) and an Address Family Transition Router (AFTR) deployed in the service provider network.

DS-Lite leverages a network address and port translation (NAPT) function in the service provider AFTR element to translate traffic tunneled from the private addresses in the home network into public addresses maintained by the service provider. On the 7750 SR, this is facilitated through the Carrier Grade NAT function.

When a customer’s device sends an IPv4 packet to an external destination, DS-Lite encapsulates the IPv4 packet in an IPv6 packet for transport into the provider network. These IPv4-in-IPv6 tunnels are called softwires. Tunneling IPv4 over IPv6 is simpler than translation and eliminates performance and redundancy concerns.

The following figure shows the DS-lite deployment

Figure 3. DS-Lite deployment

The IPv6 source address of the tunnel represents a unique subscriber. Only one tunnel per customer (although more is possible), but the IPv6 addresses cannot overlap between different customers. When encapsulated traffic reaches the softwire concentrator, the device treats the source-IP of the tunnel to represent a unique subscriber. The softwire concentrator performs IPv4 network address and port translation on the embedded packet by re-using Large Scale NAT and L2-Aware NAT concepts.

Advanced services are offered through AA multi service ISA to the DS-Lite connected customers. Subscribers’ traffic (ESMs or transit-ip) are diverted to AA ISA for Layer 3 to Layer 7 identification and classifications, reporting and control based on the IPv4 packets (transported within the IPv6 DS-Lite tunnel). This AA classification, reporting and control of subscribers’ traffic take effect before any NAT44 functions. In specific, AA sites on the subscriber side of NAT44.

The absence of a control protocol for the IP-in-IP tunnels simplifies the operational/management model, because any received IPv6 packet to the AA ISA can be identified as a DS-Lite tunneled packet if:

  • Protocol 4 is indicated in the IPv6 header.

  • The embedded IP packet is IPv4 (inside).

Fragmented IPv4 packets are supported only if tunneled through non-fragmented IPv6 packets.

Fragmentation at the IPv6 layer is not supported by AA ISA (when used to tunnel fragmented or non-fragmented IPv4 packets). These packets are cut-through with sub-default policy applied with a possibility of re-ordering.

If DSCP AQP action is applied to DS-Lite packet, both IPv4 and IPv6 headers are modified. AQP mirroring action is applied at the IPv6 layer. All collected statistics include the tunnel over-head bytes (also known as IPv6 header size).

6to4 /6RD

6RD/6to4 tunneling mechanism allows IPv6 sites to communicate over an IPv4 network without the need to configure explicit tunnels, as well as and for them to communicate with native IPv6 domains via relay routers. Effectively, 6RD/6to4 treats the wide area IPv4 network as a unicast point-to-point link layer. Both ends of the 6RD/6to4 tunnel are dual-stack routers. Because 6RD/6to4 does not build explicit tunnels, it scales better and is easier to manage after setup.

6to4 encapsulates an IPv6 packet in the payload portion of an IPv4 packet with protocol type 41. The IPv4 destination address for the encapsulating IPv4 packet header is derived from the IPv6 destination address of the inner packet (which is in the format of 6to4 address) by extracting the 32 bits immediately following the IPv6 destination address's 2002:: prefix. The IPv4 source address in the encapsulating packet header is the IPv4 address of the outgoing interface (not system IP address).

6RD is very similar to 6to4; the only difference is that the fixed 2002 used in 6to4 prefix is replaced by a configurable prefix.

The following figure shows an important deployment of 6RD/6to4 deployment is in access network.

Figure 4. 6to4 in access network deployment

To provide IPv6 services to subscribers, 6RD is deployed in these access networks to overcome the limitations of IPv4 only access network gear (for example, DSLAMs) with no dual stack support.

From an AA ISA point of view, deployment of 6RD in the access network is similar to that of the general deployment case between IPv6 islands with the added simplification that each 6RD tunnel carries traffic of a single subscriber.

When AA ISA sees an IPv4 packet with protocol type 41 and a payload that includes an IPv6 header, it detects that this is a 6rd/6to4 tunneled packet.

AA ISA detects, classifies, reports, and applies policies to 6rd/6to4 packet for ESM, SAP, spoke-SDP, and transit-IP (ip-policy) AA subscriber types.

Fragmented IPv6 are supported only if tunneled through non-fragmented IPv4 packets.

Fragmentation at the IPv4 layer is not supported by AA ISA (when used to tunnel fragmented or non-fragmented IPv6 packets). These packets are cut-through with sub-default policy applied with a possibility of re-ordering.

If the packet has IPv4 options then AA ISA does not look into the IPv6 header. The packet is classified as IPv4 ‟unknown TCP/UDP”. Furthermore, TCP/UDP checksum error detection is only applied for Ipipe and routed services.

If the DSCP AQP action is applied to 6RD6to4 packets, both IPv4 and IPv6 headers are modified. AQP mirroring action is applied at the IPv4 layer. All collected statistics include the tunnel over-head bytes, aka. IPv4 header size.

Wireless LAN gateway broadband services

AA enables a variety of use cases important for Wireless LAN Gateway deployments in residential, public WiFi or VPN wireless LAN services. These include:

  • HTTP redirect for subscriber authentication with HTTP allowlist

    This redirects all non-authenticated subscriber HTTP traffic to an authentication portal and blocks the rest of Internet access, but allows user access to specific allowed websites, download Apps and software needed to authenticate.

  • HTTP/HTTPS redirect by policy

    This is URL or application blocking or usage threshold notification. Redirects some or all subscriber HTTP/HTTPS traffic to an portal landing site based on static or dynamic policy. This can be done while not interrupting selected HTTP/HTTPS based services such as streaming video.

  • inline HTTP browser notification

    This provides messaging in the form of web banners, overlays, or http-redirection. This can always be enabled, One-time per sub at authentication (greeting message ‟Welcome to our WiFi Service”), one time per COA, or periodically.

  • ICAP for large scale URL filtering

    An ICAP client in AA interacts with offline ICAP URL filtering services for parental control or large denylists. This reduces cost as only URLs for specific flows are sent to server, instead of full inline traffic.

  • analytics

    This provides the operator insight into the following: Application and App-group volume usage by time of day/day of week, top subs, devices, and so on.

  • traffic control for fair use policy

    This prevents some users of the hotspot from consuming a disproportionate amount of resources by limiting to volume of such use across all subscribers as a traffic management tool, or on a per-subscriber basis.

  • stateful firewall

    This prevents unsolicited sessions from attacking devices.

  • web-service URL classification

    AA communicates with a web-service which offers URL categorization and provides parental control services. For the web-service model, AA receives the category of the URL and makes local policy decisions.

Application-aware business VPN services

AA for business services can be deployed at the Layer 2 or Layer 3 network provider edge (PE) policy enforcement point for the service or at Layer 2 aggregation policy enforcement point complimentary to the existing Layer 3 IP VPN PE. In a business environment, an AA subscriber represents a VPN access point. A typical business service can have a much larger average bandwidth rate then the residential service and is likely to have a smaller AA subscriber count than a residential deployment.

Multiple ISA2s can be deployed per PE, each incrementally processing up to 40 Gb/s. The in-network scalability is a key capability that allows a carrier to be able to grow the service bandwidth without AA throughput affecting the network architecture (more edge nodes, application-aware devices).

Application-aware Layer 2 and Layer 3 VPNs implemented using AA ISA equipped 7750 SR and 7450 ESS together with rich network management (NSP NFM-P, 5750 RAM, end customer application service portals) give operators a highly scalable, flexible, and cost effective integrated solution for application-based services to end customers. These services may include the following:

  • rich application reporting with VPN, access site visibility

  • right-sizing access pipes into a VPN service to improve/ensure application performance

  • application-level QoS (policing, session admission, remarking, and so on) to ensure application-level performance, end-customer QoE objectives are met.

  • value-added services such as application verification, new application detection, application mirroring

  • performance reporting for real time (RTP) and non-real time (TCP) based applications

  • Dual Stack IPv4 – IPv6 support

  • GTP, 6RD tunneling support

  • control unauthorized or recreational applications by site, by time of day.

The following figure shows AA BVS services integrated into the provider edge.

Figure 5. AA BVS services integrated into the provider edge

Mobile Backhaul

This section discusses Mobile Backhaul (MBH). The following figure shows a GTP-MBH AA deployment.

Figure 6. GTP–MBH AA deployment

In addition to SeGW FireWall deployments that require AA to support handling of GTP encapsulated traffic (S1-U interface), there are a number of deployments that require AA to support detection such as, classification and control of traffic encapsulated within GTP tunnels. These deployments are very similar in nature to AA support for other tunneling mechanisms such as 6RD, 6to4, DS-Lite. and so on For GTP tunnels, two main deployment use cases are identified: WiFi offload and mobile backhaul.

In Mobile Backhaul (MBH) deployment, operators provide business network services called Mobile Data Roaming traffic service (that is, GPRS roaming exchange/service) to Mobile Network operators (MNOs) using MPLS network. MNOs, in turn, use MBH networks to create GTP tunnels across the MBH network between their mobile access network (for example, eNBs/SGSN/SGW) and PGSN/PGW network devices.

MNOs look into their MBH network providers to provide more analytical reporting of the applications running over the GTP-U tunnels.

AA-ISA is used to report on diverted business SAPs, regardless of how the traffic is encapsulated (GTP-U and 6RD, for example). From AA-ISA point of view, the diverted business SAP represents the subscriber. The subscriber is the MNO itself. No transit AA subscriber support is required in this deployment.

In this situation, multiple GTP-U tunnels are carried per SAP. AA reports on the actual content of these tunnels and not on the GTP-U tunnel themselves. For example, AA reports on the applications per SAP and not applications per GTP-u tunnel.

While this use case does not require any form of AA control functions, all AA actions/control functions can be used except for actions that require packet modifications (such as HTTP enrichments, HTTP redirect, remarking, DSCP Remark, HTTP notification).

Stateful firewall service

AA supports stateful firewall, which may be used for Gi firewall, GRX (GTP Roaming) firewall, or SeGW firewall deployed within a 7750 SR Security gateway in ultra-broadband access networks (3G/4G/Femto) and provides the operator with back-end core network security protection. For more information, see AA firewall.

AA system architecture

AA ISA resource configuration

AA ISAs are flexible embedded, packet processing resource cards that require configuration such that services may be associated with the resources. This includes assigning ISAs to groups, optionally defining group partitions, and setting the redundancy model. Load balancing is affected by how ISAs are grouped.

AA ISA groups

An AA ISA group allows operators to group multiple AA ISAs into one of several logical groups for consistent management of AA resources and policies across multiple AA ISA cards configured for that group. The following operations can be performed at the group level:

  • Define one or multiple AA ISA groups to allow AA resource partitioning/reservation for different types of AA service.

  • Define the AA subscriber scale mode for the group. Various scales for residential, VPN, and lightweight-Internet (used for WLAN-GW distributed subscriber management) modes are supported.

  • Assign physical AA ISAs to a group.

  • Select forwarding classes to be diverted for inspection by the AA subscribers belonging to the group and select the AA policy to be applied to the group.

  • Configure redundancy and bypass mode features to protect against equipment failure.

  • Configure QoS on IOMs which host AA ISAs for traffic toward AA ISAs and from AA ISAs.

  • Configure ISA capacity planning using low and high thresholds.

  • Enable partitions of a group.

  • Configure the ISA traffic overload behavior for the group to either back pressure to the host IOM (resulting in possible network QoS-based discards) or to cut-through packets through the ISA without full AA processing. Cut-through is typically enabled for AA VPN groups but not for residential groups.

Residential services is an example where all AA services may be configured as part of a single group encompassing all AA ISAs, for operator-defined AA service. This provides management of common applications and reporting for all subscribers and services, with common or per customer AQP (using ASOs characteristics to divide AA group’s AQP into per app-profile QoS policies).

Multiple groups can be further used to create separate services based on different sets of common applications, different traffic divert needs (such as for capacity planning) or different redundancy models. Multiple groups may be used:

  • when there is a mix of residential and business customers

  • among different business VPN verticals

  • for business services with a common template base but different levels of redundancy, different FC divert, or scaling over what is supported per single group

  • when system level status statistics have AA ISA group/partition scope of visibility

AA group partitions

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

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

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

The definition of application profiles (and related ASO characteristics/values) are within the context of a 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:

  • the definition of unique applications and app-groups per partition

  • the definition of AQP policy per partition

  • the definition of common applications and app-groups per partition with per partition processing and accounting

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

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

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

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

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

Bypass modes

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

Redundancy

AA ISA group redundancy is supported, to protect against card failure and to minimize service interruption during maintenance or protocol signature upgrades.

No AA ISA group redundancy

AA can be configured with no ISA redundancy within the AA group. All AA ISAs are configured as primary with no backup (up to the limit of active AA ISAs per node). There is a 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.

Failure to fabric

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 divert eligible packets resume divert through the ISA. This behavior is completely internal to the system, without affecting the forwarding or routing configuration and behavior of the node or the network.

N+1 AA ISA card warm redundancy

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

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

Upon failure of a primary AA ISA, all of its AA subscribers and their traffic are operationally moved to the newly active backup AA ISA but the current flow states are lost (warm redundancy). The new AA ISA identifies any session-based active flows at a time of switchover as an existing protocol, while the other flows are re-identified. 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 waits for operator control to revert activity to the failed primary AA ISA module.

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

The activity switch experiences the following AA service impact:

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

ISA load balancing

Capacity-cost based load balancing allows a cost to be assigned to diverted AA subscribers (by the app-profile). Load Balancing uses the total allocated costs on a per-ISA basis to assign the subscriber to the lowest sum cost ISA resource. Each ISA supports a threshold as the summed cost value that notifies the operator if or when capacity planning has been exceeded.

The load balancing decision is made based on the AA capacity cost of an AA subscriber. The capacity cost is configured against the app-profile. When assigning a new diverted AA subscriber to an ISA, the ISA with the lowest summed cost (that also has sufficient resources) is chosen. Examples of different load-balancing approaches that may be implemented using this flexible model include:

  • AA subscriber count balancing

    Configure the capacity cost for each app-profile to the same number (for example, 1).

  • AA subscriber stats resource balancing

    Configure the capacity cost to the number of stats collected for AA subscribers using the app-profile. This may be used if different partitions have significantly different stats requirements.

  • bandwidth balancing

    Configure the capacity cost to the total bandwidth in both directions (in kb/s) expected for those AA subscribers. This may be used if different AA subscribers have highly varying bandwidth needs.

Load balancing operates across ISAs with in an AA group, and does not balance across groups. The system ensures that app-profiles assigned to AA subscribers (ESM subscribers, SAPs and spoke SDPs) that are within a single VPLS, Epipe, IES, and VPRN services are all part of the same AA group (partitions within an AA group are not checked or relevant).

Users can replace the app-profile assigned to an AA subscriber with another app-profile (from the same group/partition) that has a different capacity cost.

Regardless of the preferred choice of ISA, the system takes into account the following:

  • Resource counts have per-ISA limits. If exceeded on the ISA of choice, that ISA cannot be used and the next best is chosen.

  • Divert IOM service queuing resources may limit load-balancing. If queuing resources are exhausted, the system attempts to assign the AA subscriber to the ISA where the first AA subscriber within that service (VPLS or Epipe) or service type (IES or VPRN) was allocated.

For prefix transit AA subscriber deployments using the remote-site command, traffic for the remote transit subs are processed a second time. The ISA used by the parent AA subscriber is used by all transits within the parent. In remote-site cases there may be a need to increase capacity cost of parent because the transits stay on same ISA as the parent.

Prefix transit AA subscribers are all diverted to the same Group and partition as the parent SAP.

Asymmetry removal

Asymmetry removal is only supported on 7750 SR routed services. Asymmetry removal is a means of eliminating traffic asymmetry between a set of multi-homed SAP or spoke SDP endpoints. This can be across endpoints within a single node or across a pair of inter-chassis link connected routers. Asymmetry means that the two directions of traffic for a flow (to-sub and from-sub) take different paths through the network. Asymmetry removal ensures that all packets for each flow, and all flows for each AA subscriber are diverted to an AA ISA.

Traffic asymmetry is created when there are multi-homed links for a service, and the links are simultaneously carrying traffic. In this scenario packets for flows use any reachable paths, therefore creating dynamic and changing asymmetry. Single node or multi-chassis asymmetry removal is used for any case where traffic for an AA subscriber may be forwarded over diverse paths on active AA divert links in a multi-homed topology. This includes support for SAP or spoke AA subscribers as well as business and residential transit AA subscribers within the diverted service.

Asymmetry removal must be implemented in the first routed hop on the network side of the subscriber management point, such that there is a deterministic and fixed SAP andspoke SDP association between the downstream subscriber management the parent divert service.

Asymmetry removal allows support for the SAP or spoke SDPs to the downstream element to be multi-homed on active links to redundant PE AA nodes as shown in Transit sub SAP and spoke SDP multi-homing with asymmetry.

Figure 7. Transit sub SAP and spoke SDP multi-homing with asymmetry

AA for transit-ip subscribers is commonly deployed behind the point of the subscriber policy edge after aggregation. This includes cases where AA needed is behind:

  • any node running ESM but where there is no need or space to deploy distributed AA ISAs

  • legacy BRAS that do not support integrated application policy

Asymmetry removal also allows a VPN site (VPN site multi-homing with asymmetry ) to be connected with multi-homed, dual-active links while offering AA services with the ISA.

Figure 8. VPN site multi-homing with asymmetry

Asymmetry removal is supported for Layer 3 AA divert services:

  • IES SAP and spoke SDP

  • VPRN SAP and spoke SDP

When asymmetry exists between multi-chassis redundant systems, Ipipe spoke SDPs are used to interconnect these services between peer nodes over an Inter-Chassis Link (ICL).

Asymmetry removal supports multiple endpoints of a service with a common AARP instance, with a primary endpoint assigned the app-profile (and transit policy for transit subs). The remaining endpoints are defined as secondary endpoints of the AARP instance. All SAP or spoke endpoints within a specific AARP instance are load balanced to the same ISA in that node. Multi-endpoint AARP instances allow single-node asymmetry removal and multi-chassis asymmetry removal with multiple active links per node.

Asymmetry removal overview

Multi-chassis asymmetry removal functional overview shows an overview of the multi-chassis asymmetry removal functionality.

Figure 9. Multi-chassis asymmetry removal functional overview

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

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

  • Divert AA subscriber multi-homed pairing is supported by AA Redundancy Protocol (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.

    • From sub packets on a node with backup AARP ID remote diverted 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. To-sub packets on 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.

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

Failure modes

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

AARP peered node/instance configuration

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

Table 2. Parameter values for peer nodes
Parameter Value

Service ID

Node specific

Interface

Node specific

SAP or spoke/SDP ID

Node specific

AA-group ID

Node specific

App-profile name

Content must be the same in both peers as to not affect behavior. Nokia recommends using same name and content.

Transit policy ID

Same in both (only applies if transits are used)

AARP ID

Same in both

shunt-sdp sdp-id:vc-id

Node specific but must properly cross-connect the local AA subscriber service with the peer Ipipe/service shunt interface to operate properly for asymmetry removal for remote divert traffic. Peer AARPs stay in standalone mode until cross-connect is configured properly.

Master-selection mode

Same in both

Other ISA-AA group configuration

Same in both, including fail-to, divert FC, and so on

IOM traffic classification into a FC

Same in both (can affect AA divert because this is conditioned by the FC). This includes sub side, network side and shunt IOMs.

AARP operation has the following required dependencies:

  • For multi-chassis, shunt links are configured and operationally Up.

  • For multi-chassis, peer communications established.

  • Dual-homed SAP or spoke configured.

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

MC-CTL

A multi-chassis 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, app-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.

Multi-chassis datapath shunts

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

  • subscriber to network direction

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

  • AARP operational states

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

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

    • Divert capability is up.

    • App profile is diverting.

    • AA subscriber is configured.

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

  • master

    In multi-chassis 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 shut down 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/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 multi-chassis 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 re-evaluate tool, or for all instances on an ISA that fails. On an AARP activity switch, AA divert changes from local to remote or 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.

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.

Table 3. Interaction and dependencies between AARP states
Local AARP operation state Peer AARP operational state Description

Master

Backup

Inter-Chassis Link (ICL) Communication established between AARP peers.

AARP dependent resources are up (to-sub/from-sub shunt, aarp control link, dual-homed SAP or spoke SDP).

AARP instances have negotiated initial state assignment using configured priority/system IP address.

AA service is available for the dual-homed SAP or spoke subscriber.

All to-sub/from-sub traffic specific to the dual-homed SAP or spoke SDP is serviced on the local node.

Peer node is available to takeover in the event of a AA service failure on the local node.

Asymmetry is removed for the dual-homed SAP or spoke subscribers, serviced by AA on the local (master) node.

Master

Remote

Same as Master/Backup except:

AA service is available on the local node. AA service is unavailable on the peer node.

Standalone

Standalone

Initial state of the AARP instances upon creation or a result of a failure in any of the AARP dependent resources.

All to-sub/from-sub traffic for the dual-homed SAP or spoke is serviced on each node independently.

aarp instance operational state is outOfService on both sides.

Asymmetry is not removed for the dual-homed SAP or spoke subscribers (traffic ID is not optimal).

ISA overload detection

Capacity cost resource counting does not have a hard per-ISA limit, because the cost values are decoupled from actual ISA resources. However, the value of the total summed cost per-ISA can be reported, and a threshold value can be set which raises an event when exceeded.

ISA capacity overload detection and events are supported within the system resource monitoring / logging capabilities if the traffic and resource load crosses the following high and low load thresholds on a per-ISA basis:

  • ISA capacity cost

  • flow table consumption (number of allocated flows)

  • flow setup rate

  • traffic volume

  • host IOM egress weighted average shared buffer pool use (within the egress QoS configuration for each group). These thresholds are also used for overload cut-through processing.

While an app-profile is assigned to AA subscribers, the capacity-cost for that app-profile can be modified. The system makes updates in terms of the load balancing summary, but this does not trigger a re-balance.

In the absence of user configuration, the app-profile default capacity cost is 1. The range for capacity cost is 1 to 65535 (for example, for bandwidth based balancing the value 100 could represent 100 kb/s). 0 is an invalid value.

If the re-balancing of AA subscribers is required (for instance after the addition of new ISAs), there is a tools command to re-balance AA subscribers between ISAs within a group. Re-balance affects which AA subscribers divert to which ISAs based on capacity cost. Transit subs cannot be rebalanced independent of the parent (they move with the parent divert), and DSM subs cannot be load balanced as all subs on an ISA-AA are from the associated ISA-BB pair. The system attempts to move AA subscribers from the fullest ISA to the least full ISA based on the load balancing mode. If the load becomes balanced or an AA subscriber move fails because of ISA resources or divert IOM service queuing resources, the load balancing terminates.

Alternatively, load balancing can be manually accomplished by the AA subscriber being removed and re-added. This triggers a load balancing decision based on capacity-cost. For ESM, SAP, and spoke SDP subscriber types, this can be accomplished by removing and re-applying the AA subscriber's app-profile. In the case of ESM AA subscribers, shutting down and re-enabling either sub-sla-mgmt or the hosts has the same effect. Dynamic ESM AA subscribers re-balance naturally over time as subscribers come and go from the network.

For transit AA subscriber deployments, the parent divert SAPs are load-balanced based on AA capacity cost from the app-profile configured against the SAP or SDP. The parent capacity cost should be configured to represent the maximum expected cost when all transit subs are present.

All traffic not matching a configured transit subscribers is dealt with as a member of the parent SAP and according to its app-profile.

AA packet processing

There are four key elements of AA packet processing (Application Assurance high level functional components):

  • divert (selection of traffic to be diverted to the AA ISA)

  • identification of the traffic on a per flow (session) basis

  • reporting of the traffic volume and performance

  • policy treatment of the identified traffic

    Figure 10. Application Assurance high level functional components

Divert of traffic and subscribers

Any traffic can be diverted for application-aware processing. AA is enabled through the assignment of an application profile as part of either an enhanced subscriber management or static configuration. This process enables the AA functionality for all traffic of interest to and from a subscriber, SAP or spoke SDP. Which traffic is deemed of interest, is configured through an AA ISA group-specific configuration of forwarding classes (FCs) to be diverted to AA and enabled on a per subscriber, SAP, spoke SDP using application profiles.

Application Assurance ingress datapath shows the general mechanism for filtering traffic of interest and diverting this traffic to the appropriate AA ISA module residing on an IOM (referred as the host IOM). This traffic management divert method applies to both bridged and routed configurations.

Figure 11. Application Assurance ingress datapath

For a SAP, subscribers with application profiles enabling AA, the traffic is diverted to the active AA ISA using ingress QoS policy filters, identifying forwarding and sub-forwarding classes that could be diverted to the AA. Only single point (SAP, ESM, or DSM subscriber, spoke SDP) configuration is required to achieve divert for both traffic originated by and destined for an AA subscriber. Diversion (divert) to the AA ISA is conditional based on the AA ISA status (enabled, failed, bypassed, and so on).

Unless the AA subscriber’s application profile is configured as ‟divert” using Application Profiles and the FC is selected to be diverted as well, the normal ingress forwarding occurs. Traffic that is filtered for divert to AA ISAs is placed in the appropriate location for that system’s AA ISA destination.

Users can leverage the extensive QoS capabilities of the router when deciding what IP traffic is diverted to the AA system for inspection. Through AA ISA group-wide configuration, at least one or more QoS forwarding classes with the ‟divert” option can be identified. The forwarding classes can be used for any AA subscriber traffic the service provider wants to inspect with AA.

Services and AA subscribers

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

  • ESM subscriber

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

  • distributed sub 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:

  • bridged CO

  • routed CO

  • multi-homed COs

  • Layer 2/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:

  • per AA subscriber, application traffic monitoring and reporting

  • per application bandwidth shaping/policing/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

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

Spoke SDPs

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

Spoke SDP divert shows spoke SDP divert capabilities.

Table 4. Spoke SDP divert
Access node service (spoke SDP type) Connected to service

Epipe

VPLS

IES

VPRN

Ipipe

Epipe (Ethernet spoke)

Y

Y

Y

Y

Y

Ipipe (IP spoke)

N/A

N/A

Y

Y

Y

VPLS (Ethernet spoke)

N/A

Y

Y

Y

N

Transit AA subscribers

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

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)

  • app-profile (the divert/no divert and capacity cost setting of the app-profile does 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 subs, that SAP or Spoke-SDP is referred to as the parent AA subscriber. Transit AA subscribers are supported on the parent SAPs or spoke SDPs that support AA divert.

Transit AA subscribers support lists the Transit AA subscriber support.

Table 5. Transit AA subscribers support
Transit subscriber type Epipe VPLS IES VPRN Ipipe

Transit IP

Y

N/A

Y

Y

N/A

Transit prefix

Y

Y

Y

Y

Y

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

For transit IP AA subscribers, all packets are accounted for 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 subscriber deployments using the remote-site command, traffic for the remote transit subs are processed and counted for both the local parent and the remote transit subscriber.

Transit AA subscriber app-profile

The app-profile assigned to the aa-sub-id affects both stats and control of the policy. App-profiles are assigned to the transit AA subscribers either explicitly when the transit-aa-sub is created, or by default (when not specified) according to a default app-profile configured in a transit-ip-policy or transit-prefix-policy. This allows transit AA subscribers to be treated with a different default app-profile than the app-profile (default or specified) set against the parent aa sub. The number of AA subscriber stats used per ISA is proportional to the number of AA subscribers including transit subscribers subs are added.

ASO policy override is supported for static transit subs.

Transit IP policy and transit prefix policy

A transit policy is associated with the parent (divert) SAP/SDP to define how transit AA subscribers are created within that parent. The transit policy must be defined in the configure application-assurance group partition transit-prefix-policy or configure application-assurance group partition transit-ip-policy context before it can be assigned to a parent. Transit IP subs can be created using the methods described in Transit IP subscriber types and creation methods

Table 6. Transit IP subscriber types and creation methods
Transit IP subscriber type Creation method

Static

CLI/SNMP configuration of a transit AA subscriber is done within the transit-ip-policy

Dynamic

DHCP authentication

Dynamic

RADIUS accounting to Policy and Charging Rules Function (PCRF) or AAA

Dynamic

seen-IP transit auto-create

Transit prefix subs are created by static CLI/SNMP configuration of a transit AA subscriber within the transit-prefix-policy. The transit prefix policy follows IP filter conventions for first match and ordering of entries. While for residential /32 transits if there is an IP address conflict between any static prefix transit subs, the latter configuration is blocked, for business transit subs multiple overlapping address entries are allowed to enable longest match within subnets. IP addresses for a VPN site as an AA subscriber are configured with the transit prefix policy. There are two options:

  • aa-sub-ip is used when the site is on the same side of the system as the parent SAP.

  • network-ip is used when the site is on the same opposite of the system as the parent SAP.

A transit prefix subscriber may only have either aa-sub-ip entries or network-ip entries but not both.

The IP addresses defined in the transit-ip-policy for a transit sub are full /32 IP addresses. The IP addresses defined in the transit-prefix-policy for a transit sub are any length from /0 to /32.

Multiple IP addresses (from any prefix/pool) can be assigned to a single transit AA sub. IP addresses must be unique within a transit policy, but can be re-used in separate policies (because they have parent specific context).

The transit policy contains the default app-profile for the transit sub if a transit policy is created but app-profile is not specified. An app-profile can be later explicitly assigned to the transit sub after the sub is created (using RADIUS COA, DHCP or static).

For dynamic transit IP subs, a sub-ident-policy (also used by ESM to associate sub ID policies to a SAP) can now also be associated with the AA subscriber parent by defining the sub-ident policy in the transit IP policy. This determines how sub identifying strings are derived from DHCP option 82 fields. The policy also contains app-profile-map which maps the strings to the defined app-profiles. Transit subs do not use the sla-profile or sub-profile aspects of the sub-ident-map.

In the case of multi-homed transit subs, the transit-ip-policy must be the same on both nodes of the multi-homed parent link to ensure consistency of sub context and policy.

There is no configurable limit to the number of hosts per sub (this is similar to lease-populate which limits the number of dynamic hosts per SAP) and no limit to the number of transit subs per transit IP policy (parent). This is a function of the PE doing subscriber management.

If transit sub resource limits are exceeded (hosts per sub, or subs per ISA) the transit sub creation is blocked (for both static and dynamic models).

There is a per-ISA group/partition show list of AA subscribers in a transit-ip-policy which includes a parent field for transit subs (static versus dynamic identified).

Persistent AA statistics is supported dynamic transit AA subs, ensuring that accounting usage information is not lost when the sub disconnects before reporting interval end.

Static-remote-aa-sub command
Figure 12. Static-remote-aa-sub usage topology

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

  • treats packets for the parent AA subscriber independent of whether transits are also configured (stats and policers for parent work as usual)

  • subsequently, treats the same packet as a transit-sub packet when matching to a configured transit sub (stats, policers)

  • allows natural direction of the packet for both the parent AA subscriber and the transit-AA subscriber, as shown in Static-remote-aa-sub usage topology, where a packet from a remote client to a local server is seen as to-sub for the parent, and from-sub for the transit sub that is logically at the far end site

  • corrects directionality of packet ID for all AA subscribers and allows for correct operation of app-filter flow-setup-direction

Static transit AA subscriber provisionings

Static (through CLI/SNMP) provisioning of transit AA subscribers is supported. A profile policy override to set policy characteristics by ASO (as opposed to within an app-profile) is supported only for statically configured transit AA subs.

If there is an IP address conflict between a static and dynamic transit sub, the static takes precedence (per ESM). If the static is configured first, the dynamic transit sub is rejected. If the dynamic is created first, a warning is provided before removing the dynamic transit sub and notifying the sub-manager by COA failure.

DHCP transit IP AA subscribers at DHCP relay node

DHCP-based transit sub creation provides a sub ID and lease time for IP addresses correlated to the ESM/subscriber context in the PE.

The 7750 DHCP relay agent creates dynamic DHCP AA subscribers when the DHCP ACK is received from the DHCP server, including the sub name, IP address and app-profile from DHCP Option 67 (if present) when the DHCP ACK messages passes through AA node to the downstream subscriber-edge node. If there is no app-profile assigned when the transit AA subscriber is created, a default transit AA subscriber app-profile is used (configured in the transit-ip-policy assigned against the divert parent AA subscriber).

This is compatible with the ESM router edge as well as third-party BRAS and CMTS.

Dynamic AA subscriber stats records are persistent across modem reset/session releases. The end of accounting records are created when transit subs are released.

Multiple IPs per transit AA subscriber are determined by seeing a common the DHCP Option 82 cct ID.

RADIUS transit AA subscribers

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

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

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

RADIUS COA example shows a RADIUS CoA Example.

Figure 13. RADIUS COA example

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

  • downstream BRAS/ CMTS: NAS-port-ID

  • IP address (framed-ip-address)

  • subscriber ID (per RADIUS accounting sub-id-string)

Seen-IP RADIUS notification

Seen-IP transit subscriber notification provides RADIUS Accounting Start notification of the IP addresses and location of active subscribers within a parent AA service. This allows a PCRF to dynamically manage RADIUS AA subscriber policy (create, modify, delete) without requiring static network topology mapping of a subscriber edge gateway to the parent transit service.

When detect-seen-IP is enabled within a transit policy, the ISA detects IP flows on an AA parent subscriber that do not map to an existing transit AA subscriber. It then uses a simple RADIUS Accounting Start notification from the transit AA node to the PCRF to initiate subscriber creation, providing information about the location of the transit subscriber traffic. This provides notice for subscriber authentication changes, such as new subscriber sessions or new host IP addresses added to an existing AA subscriber, while being independent of the network topology for how the BNG is homed into the transit AA nodes.

The RADIUS Accounting Start message is sent to the RADIUS Server referenced by the specified seen-ip-radius-acct-policy. This RADIUS message contains the following information about the flow:

  • subscriber-side IP address

  • parent SAP or spoke-SDP ID (NAS port ID)

  • IP address of node making the request

  • peer SAP or spoke-SDP ID (NAS port ID), if configured

  • peer IP address of SR making the request, if configured

  • AARP ID, if configured

Diameter transit AA subscriber

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

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

Figure 14. 3GPP pull model
Table 7. 3GPP pull model description
Legend Description

1

AA detects a new IP address, and sends a CCR-I containing the subscriber-side IP address

2

CCA(I) contains subscriber AA policy information

3

AA applies an AA appProfile, ASOs, and any AA usage monitoring

4

AA reports usage counters for all specified or enabled usage monitoring keys, and removes the sub

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

  • session ID

  • subscriber-side IP address

  • IP-CAN-Type AVP (if enabled) with the value ‟tbc”

  • subscription ID AVP, with the following characteristics (if avp-subscription-id is configured as subscriber-id):

    • Type is END_USER_E164 (private by default)

    • ID is an auto-generated unique ID

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

  • session ID

  • Charging-Rule-Install containing the following information:

            Charging-Rule-Definition ::=<AVP Header: 1003>
                    {Charging-Rule-Name}
                    [TDF-Application-Identifier]
                    [Monitoring-Key]
                    [AA-Functions {]
                            AA profile
                            AA-App-Service-Options {
                                    AA-App-Service-Options-Name
                                    AA-App-Service-Options-Value
                    ........
                    [AVP]
    
  • Charging-Rule-Name

    • Usage monitoring starts with ‟AA-UM:”

    • AppProfile and ASOs start with ‟AA-Functions:”

  • AA-Functions (AVPs to set AA profile and ASO values)

  • TDF-application-identifier; this field specifies a predefined AA charging group, application group, or application name for which usage monitoring functionality is required

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

Used AVPs lists the AVPs used for Diameter transit AA subs.

Table 8. Used AVPs
AVP Category Details User configurable

Session-Id

M

Globally unique

Generated for each session as:

<peer identity>;<high 32 bits>;<low 32 bits>;[<optional value>;]<subscriber ip>

N

Auth-Application-Id

M

Set as Gx (16777238)

N

CC-Request-Type

M

Set to INITIAL_REQUEST (1) when initiating a new session

Set to TERMINATION_REQUEST (3) when ending a session

Set to UPDATE_REQUEST (2) in all other situations

N

CC-Request-Number

M

Generated internally according to Gx specifications

Request numbering starts at 0

N

Subscription-Id

M

Configurable using Subscription-Id-Type and Subscription-Id-Data

Subscription-Id-Type

M

Configurable under subscriber-mgmt>diameter-application-policy>gx>avp-subscriber-id origin

Y

Subscription-Id-Data

M

Configurable under subscriber-mgmt>diameter-application-policy>gx>avp-subscriber-id origin [type type]

Y

Framed-IP-Address

M

Set to the subscriber’s IP address as seen by AA-ISA in the from-sub direction of the data traffic

N

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

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

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

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

charging-rule-install (1001) VM------ [44]
     vendor-id TGPP
     data [32] (Grouped)
          charging-rule-name (1005) VM------ [30]
               vendor-id TGPP
               data [18] (UTF8String) : Sub-Id:subID-name

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

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

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

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

Transit AA subscriber auto-create

For dynamic transit AA subscribers, AA can automatically detect new IP addresses and create a local subscriber context with no interaction with RADIUS or Diameter policy control. When transit-auto-create is enabled within a transit policy, the ISA detects IP flows on an AA parent subscriber that do not map to an existing transit AA subscriber. When auto-create is enabled, AA subscriber contexts are auto-created under the parent diverted SAPs and spokes using the transit-IP-policy name and subscriber IP address as the AA-sub name. The default app-profile configured against the transit-ip-policy is applied to these subscribers.

By default, auto-created subscribers are persistent and never removed (without removal of the AA group). ISAs may periodically be shut down and then no shutdown to clear the aa-subs to avoid running out of sub context, or, inactive subscribers may be automatically removed after a timeout period by using the transit-auto-create context command for inactivity-monitoring. With this, periodically AA removes any inactive auto-created subscriber where an inactive sub is defined as having no active flows in the last period.

Transit AA subscriber persistence

Transit AA subscribers can be persistent within a single node, because in some cases, there is not a dual-node BNG subscriber redundancy configuration. This allows a single node that has dynamically created transit subs to retain the subscriber state, context, and statistics across a node or ISA reboot.

If dynamic transit AA subscribers are released, renewed, or otherwise changed during an outage or reboot of a transit AA node, the sub manager notifies the transit node of these changes.

Prefix transit subs are not affected by persistence because they can only be statically configured.

Transit diameter AA subscriber geo-redundancy

If there is no Multi Chassis Synchronization (MCS) between the two peer nodes, the two geo-redundant nodes are configured as two distinct realm nodes from the PCRF point of view. Each node acts independently of the other node. After a switch-over, AA on the newly active node detects new traffic flows with new IP addresses. AA notifies PCRF with a CCR-I message to retrieve subscriber policies. After PCRF confirms the same IP address used on a different Gx session ID, it deletes the old session for that IP address.

Similar behavior takes place if an MCS is configured with session IDs and OSI states journaled across, as per ESM implementation. The two geo-redundant nodes are configured with the same host realm, and appear to PCRF as one node. After a switch-over, AA-ISA on the newly active node detects new traffic flows with new IP addresses. AA-ISA notifies PCRF with a CCR-I message to retrieve subscriber policies. The Gx session ID used is unique and different from the session ID used on the previously active node. After PCRF confirms the same IP address used on a different Gx session ID, it deletes the old session for that IP address.

Policers for transit AA subscribers

AA subscriber per-subscriber policers can provide per-SAP policing for the parent SAP, with transit AA subscribers each supporting distinct per-subscriber policers within the parent (packets are only processed once against one AA subscriber, the parent or the transit subscriber). Packets matching transit AA subscribers and policers are not included in a parent policer.

There is no policer hierarchy unless system wide policers are referred to by both the parent AA subscriber and transit AA subscriber. When the remote-site configuration is not used, system policers can be used to police all traffic for a site containing transits, subject to constraints on system policer scale.

When the remote-AA subscriber config is used, the parent owns all packets for stats and policing, so any transit subscriber configuration within the parent does not affect the stats or policers. AA policers are supported on a transit subscriber basis, across all (multiple) IP prefixes per sub.

ISA host IOM for transit subs

The AA divert IOM is not impacted by transit AA subscribers in the divert parent. The ISA host IOM egress datapath functions to convert the parent SAP into transit AA subscribers that are then handled by the ISA consistent with all other AA subscriber features. The ISA itself treats all AA subscribers equally regardless of whether the AA subscriber is from ESM, from DSM, from an SAP, or from a transit subscriber in a parent SAP or spoke.

Prefix transit subs can only be created on IOM4 cards supporting ISAs (and IOM-e).

AA subscriber application services

This section describes AA subscriber application services.

Application profile

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

The following are main properties of application profiles:

  • One or more application profiles can be configured in the system.

  • Application profiles specify whether AA subscriber's traffic is to be diverted to AA.

  • Application profiles are defined by an operator that can reference the configured application service options (ASO) characteristics. See Application Service Options (ASOs).

  • Application profiles must only be assigned after AA resources (AA ISA cards) are configured.

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

  • Application profiles can be assigned to a scope from a subscriber or session, which controls whether the application profile is applied to the entire subscriber or to a device.

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

  • parsing the DHCP Option 82 sub-option 1 circuit ID payload, vendor specific sub-option 9, or customer-defined option different from option 82, during authentication and the DHCPDISCOVER, as well as re-authentication and the subscriber’s DHCPREQUEST

  • RADIUS using a new VSA: [26-6527-45] Alc-App-Prof-Str

  • DIAMETER using ‟AA-profile-name” AVP under ADC rule

  • inheritance from defaults in the sap>sub-sla-mgmt context, to allow default application profile assignment if no application profile was provided

  • static configuration

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

  • modification of the application profile a subscriber is mapped to and pushes the change into the network as opposed to waiting for the subscriber to re-authenticate to the network

  • change to the subscribers application profile inline, without a need for the subscriber to re-authenticate to RADIUS or perform any DHCP message exchange (renew or discover) to modify their IP information

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

Figure 15. Determining the subscriber profile, SLA profile and application profile of a host
Application profile map

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

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

Application Service Options (ASOs)

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

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

Figure 16. Configuration example

Then, the defined ASOs are used in the AQP definition to determine the needed treatment or policy (AQP definition example).

Figure 17. AQP definition example

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

Figure 18. Single ASO example

The single ASO example shows how the use of a single ASO can prevent the user from provisioning an AQP entry every time a subscriber is created.

Other example uses of ASO entries include:

  • entry per application group that is to be managed, such as VoIP, P2P, HTTP

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

  • HSI tiers (for example, Gold, Silver, and Bronze for specifying bandwidth levels)

  • VPN customer ID

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

The following are the main elements of an ASO:

  • A unique name is applied to each characteristic.

  • The name is unique to the group partitionpolicy, but the expectation is that characteristics are consistent network wide.

  • Operator-defined values (variables) are defined for each characteristic and are unique to each characteristic. A default value must be specified from the set of the values configured.

The following lists how ASO characteristics are used:

  • Application service options are used as input to application profiles.

  • AQP rule sets also use the ASO characteristics to influence how specific traffic is inspected and policies applied.

  • Multiple ASO characteristic values are allowed in a single rule.

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

  • The characteristic is correctly identified.

  • When when specifying a characteristic in an app-profile and app-qos-policy, the value must be specified. The default value applies if a characteristic is not specified within an app-profile.

ASO overrides

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

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

  • the application-assurance group (and partition) to which the AA subscriber is being assigned to

  • whether the traffic should be diverted

  • capacity-cost (for load balancing to a multi-isa group)

The information configured in the app-profile is also used, but ASO characteristics and values (these are from the policy defined in the group and partition) can be overridden.

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

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

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

  • the characteristics/values from the app-profile

  • any specific characteristics and values overridden for that AA subscriber

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

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

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

AA subscriber scale mode and ASOs

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

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

Traffic identification

AA traffic identification classifies per-flow traffic into applications and application groups, and assigns flow attributes to the traffic.

Application identification means there is sufficient flow information to provide the network operator with a view of the underlying nature and value of the content based on the end-user application related to each flow. The application ID does not include:

  • anti-virus signatures per IPS/UTM

  • content inspection (e-mail, text, picture, or video images). The payload data content of flows is not examined as part of the application identification.

AA can identify and measure non-encrypted IP traffic flows using any available information from Layer 2 to Layer 7, and encrypted IP traffic flows using heuristic and pattern-match techniques. Nokia maintains a global application database (App-DB) to keep application definitions (app filters and applications) up-to-date in customer deployments.

AA attempts to positively identify the protocols and applications for flows based on a pattern signature observation of the setup and initial packets in a flow. The system correlates control and data flows belonging to the same application. In parallel, statistical and behavioral techniques are also used to identify the application. Until identified, the flow does not have a known application and is treated according to the default policies (AQP policies defined using all or any ASO characteristics, subscriber ID and traffic direction as match criteria) for traffic for that AA subscriber, app-profile and direction (packets are forwarded unless an action is configured otherwise). If the identification beyond OSI Layer 2 is not successful, the flow is flagged as an unknown protocol type, (for example unknown_tcp or unknown_udp). The unknown traffic is handled as part of all application statistics and policy, including generation of stats on the volume of unknown traffic.

AA allows operators to optionally define port-based applications for trusted TCP or UDP ports. Operators must explicitly identify a TCP/UDP port or ports in an application filter used for trusted port application definition and specify if protocol signature-based application identification is to be performed on a flow. Two options are available:

  • If no protocol signature processing is required (expected to be used only when (A) AQP policy must be performed from the first packet seen, (B) the protocol signature processing requires more than one packet to positively identify a protocol or application, and (C) no other application traffic runs over a TCP/UDP port), the first packet seen by AA ISA for a flow on that TCP/UDP port allows application identification. The traffic for a flow is identified as ‟trusted tcp/trusted_udp” protocols.

  • If protocol signature verification of an application is required, that is, it is expected to be used only when:

    • AQP policy must be performed from the first packet seen.

    • The protocol signature processing requires more than one packet to positively identify a protocol or application.

    • Other application traffic may run over a TCP/UDP port, for example TCP port 80

    The first packet seen identifies the application but protocol signature-based analysis continues. After the identification completes, the application is re-evaluated against the remaining application filters allowing detection and policy control of unexpected applications on a trusted port.

Flow attributes provide optional flow classification metadata extracted from traffic by AA stateful flow processing, which complements and is orthogonal to the AA application and app-group classification.

When a flow attribute is enabled, every flow is assigned a confidence level for each enabled attribute. Confidence levels are used to condition control actions and for analytics. AA cflowd record exports include the 0-100% confidence level for each attribute, and are null for attributes that are not enabled. This allows analytics of traffic by flow attribute, including confidence. As with AA protocol signatures, flow attribute signatures are provided as a set in the AA.tim file.

At AA system startup or after an AA ISA activity switch, traffic diverted to the ISA may contain flows that are already in progress. Typically, application identification relies on patterns in the initial set of packets exchanged. If these initial packets were not seen by the ISA, in progress TCP flows are marked with the existing protocol signature and have a policy applied according to an application based on the existing protocol until they end or the identification of an in-progress flow is possible. Statistics are generated.

From the first packet of a flow, a default per-AA subscriber AQP policy is applied to every packet. After an application is identified, subsequent packets for a flow apply AA subscriber and application-specific AQP. The AA-generated statistics for the flow with AA subscriber and application context are collected based on the final determination of the flow's application. A subset of the applications may be monitored on an ongoing basis to further refine the identification of applications carried with the traffic flow and to identify applications using an external application wrapper to evade detection.

AA identification components

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

    Figure 19. Policy structure

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

Table 9. AA classification elements
Term Definition Examples

Protocol signature

The Nokia proprietary component of AA flow identification provided as part of AA S/W load to identify protocols used by clients. Where a protocol is defined as an agreed on format for transmitting data between two devices.

Tftp, iMap, msn-msgr, RTP, emule, http_video, bittorrent, SIP.

The Nokia protocol signatures do not rely on IP port numbers to identify a TCP/UDP port based protocols and applications to avoid false-positives but allow users to define application filters if a port-based identification is deemed adequate (see the example below).

Application filter

User configurable, optional component of AA flow identification that uses any combination of protocol signatures, server IP address and port, flow set-up direction, configurable expressions (for example, an HTTP string match) to identify user’s traffic.

The http_video + IP address of a partner’s video server or the http_video + an HTTP string to identify a partner’s video content as TCP or UDP + TCP/UDP port number to identify a TCP- or UDP-based protocol or application.

Application

User configurable, optional component of AA flow identification that allows defining any specific forms of traffic to and from end user clients by combining application filter entries.

Google Talk, POP3, YouTube, iTunes, Shoutcast.

Application charging group

User configurable, optional component of AA flow identification that allows grouping of similar end use applications using user-defined names and groups.

IM, mail, multimedia, P2P, tunneling, Web, other.

Clients

End user programs that generate user traffic for applications and protocols, and that are used in a process of AA flow identification verification.

The list of clients is constantly evolving as new clients or versions are introduced in the marketplace. The following example illustrates clients that may be used to generate Application traffic matching BitTorrent application defined using BitTorrent and DHT protocol signatures: Limewire, BitTorrent, Azureus, Ktorrent, Transmission, Utorrent.

Flow attributes

Nokia-provided algorithms based on machine learning, which assign flow attribute confidence levels to all traffic flows, whether encrypted or not. The attribute results may be used for analytics or control purposes.

Video, audio, download, upload, abr_service, encrypted, ESNI, real_time_communication

Charging filter

User configurable, optional component of AA flow identification that uses any combination of flow attribute, application, or app-group specified charging group, and flow tethering detection to determine the charging group.

Charging video traffic for a specified application differently from other traffic of the same application that has different flow attributes.

Protocol signatures

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

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

  • Pattern signatures are the set of pattern-match signatures used in analysis.

  • Behavior signatures are the set of diagnostic techniques used in analysis.

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

The protocol signatures are included in aa-isa.tim software load which is not tightly coupled with software releases allowing for protocol signature updates without upgrading and impacting of routing/forwarding engines as part of an ISSU upgrade that updates only the AA ISA software. See upgrade procedures described in the SR OS R23.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 operators to customize their applications and to reduce a need for a new Protocol Signature load when a new Application may need to be identified. This architecture gives operators more flexibility in responding to ever changing needs in application identifications.

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

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

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

Custom protocols

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

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

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

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

Protocol shutdown

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

All protocols introduced at the R1 stage of a 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 shutdown. They must be enabled on a per-protocol basis (system-wide) to take effect.

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

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

Supported protocol signatures

Protocol signatures are release independent and can be upgraded independently from the router’s software and without impacting router’s operations as part of an ISSU upgrade. A separate document 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

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

Charging groups allow usage accounting by application or application groups in a manner that does not affect app 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 stats 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
Applications

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

  • Application name is a key match criteria within application QoS policy rules, which are applied to a subscribers IP traffic.

  • Each application can be associated with one of the application groups provided by AA.

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

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

The network operator can:

  • Define unique applications.

  • Associate applications with an application group. The application group must already be configured.

Application filters

Application filters (app-filter) are provided as an indirection between protocols and applications to allow the addition of variable parameters (port number, IP addresses, and so on) into an application definition. An application filter is a numbered rule entry that defines the use of protocol signatures and other criteria to define an application. Multiple rules can be used to define what constitutes an application but each rule 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 be pre-configured before using it in an app-filter. After defined, the new application names can be referenced.

HTTP
  • HTTP protocol

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

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

  • HTTP session persistency

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

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

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

  • HTTP proxy support

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

AA IP prefix lists

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

Shallow flow inspection

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

Flow attributes

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

config>isa>application-assurance-group <x>
    [no] flow-attribute <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 app-filter entries. For example, video bearer flows for an application that match video component app-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:

config>app-assure>group>policy>aqp>entry>match> flow-attribute <flow-attribute-name> confidence {lt | gte | eq } <confidence>

Statistics and accounting

AA statistics provide the operator with information to understand application usage within a network node.

AA XML record accounting aggregates the flow information into per application group, per application, per protocol reports on volume usage during the last accounting interval. This information is then sent to a statistics collector element for network wide correlation and aggregation into customized graphical usage reports. AA uses and benefits from the rich 7750 SR or 7450 ESS accounting infrastructure and the functionality it provides to control accounting policy details.

The following types of accounting volume records are generated and can be collected:

  • per ISA group and partition record for each configured application group

  • per ISA group and partition record for each configured application

  • per ISA group and partition record for each configured protocol

  • per each AA subscriber record with operator-configurable field content using custom AA records for operator-selected subset of protocols, applications and application groups

  • per AA subscriber per each configured application record (special study mode)

  • per AA subscriber per each supported protocol record (special study mode)

  • per ISA AA-performance record, containing information about the traffic and resources of each ISA

  • per AA partition stats record for counts of traffic by Layer 3 protocol used to transport L4 protocols. This includes TCP, UDP and NonTcpUdp carried by IPv4, IPv6, DS_Lite, 6to4/6RD, GTP, and Teredo protocols

AA supports RADIUS accounting export of per AA subscriber charging group statistics.

Each AA group:partition can be configured for AA subscribers stats export by referencing both an accounting policy (for XML statistics) or a RADIUS accounting policy. To determine how to export various counters for subscriber AA statistics, an export-using keyword is used when enabling AA subscriber level stats export to specify the export method to be used for each, whether accounting policy or RADIUS accounting policy or diameter-based usage monitoring.

Per AA flow statistics are provided as described in Cflowd AA records.

See the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for information about general accounting functionality.

Per-AA subscriber special study

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

Per-AA subscriber per-application and per-AA subscriber per-protocol records are enabled by assigning individual AA subscribers to special study service lists. The system and ISA group limit the number of AA subscribers in this mode to constrain the volume of stats generated. When an AA subscriber is in a special study mode, one record for every application 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.

System aspects

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

AA accounting and statistics can be deployed as part of other system functionality as long as the system’s function is compatible with AA accounting or as long as the system-level statistics can become application-aware 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 XML volume statistics and accounting

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

Statistics to be exported from the node are aggregated into accounting records, which must be enabled 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.

Table 10. AA statistics fields generated per record (accounting file)
Record fields Description Group/partition app group Group/partition application Group/partition protocol AA subscriber custom AA subscriber special study per app AA subscriber special study protocol XML name

Application Group

Name

X

data name

Application

Name

X

X

data name

Protocol

Name

X

X

data name

Aggregation Type ID

ID (can be protocol, application, charging group or application group record)

X

agg-type-name

# Active Subscribers

# of subscribers who had a flow of this category during this interval

X

X

X

nsub

# allowed flows from-sub

# of new flows that were identified and allowed

X

X

X

X

X

X

sfa

# allowed flows to-sub

As above in opposite direction

X

X

X

X

X

X

nfa

# denied flows from-sub

the # of new flows that were identified and denied

X

X

X

X

X

X

sfd

# denied flows to-sub

As above in opposite direction

X

X

X

X

X

X

nfd

# Active flows from-sub

# of flows that were either: closed, opened and closed, opened, or continued during this interval

X

X

X

X

X

X

saf

# active flows to-sub

As above, in opposite direction

X

X

X

X

X

X

naf

Total packets from-sub

X

X

X

X

X

X

spa

Total packets to-sub

X

X

X

X

X

X

npa

Total bytes from-sub

X

X

X

X

X

X

sba

Total bytes to-sub

X

X

X

X

X

X

nba

Total discard packets from-sub

X

X

X

X

X

X

spd

Total short flows

Number of flows with duration <= 30 seconds that completed up to the end of this interval

X

X

X

X

X

X

sdf

Total medium flows

Number of flows with duration <= 180 seconds that completed up to the end of this interval

X

X

X

X

X

X

mdf

Total long flows

Number of flows with duration > 180 seconds that completed up to the end of this interval

X

X

X

X

X

X

ldf

Total discard packets to-sub

X

X

X

X

X

X

npd

Total discard bytes from-sub

X

X

X

X

X

X

sbd

Total discard bytes to-sub

X

X

X

X

X

X

nbd

Total flows completed

# of to- and from-subscriber flows that have been completed up to the reported interval.

X

X

X

X

X

X

tfc

Total flow duration

Duration, in seconds, of all flows that have been completed up to the reported interval.

X

X

X

X

X

X

tfd

From AA Sub:

Maximum throughput byte count

Maximum of all total byte counts recorded for throughput intervals within this accounting interval for traffic originated by AA subscriber for an application/app-group. AA ISA discarded traffic is not included.

X

sbm

From AA Sub:

Packet count corresponding to the max. throughput byte count interval.

Packet count for the throughput interval with the maximum byte count value for traffic originated by AA subscriber for the application/app-group. AA ISA discarded traffic is not included.

X

spm

To AA Sub:

Max throughput time slot index

UTC time that corresponds to the end of the 5-minute throughput interval where the max throughput byte count was detected.

X

smt

From AA Sub:

Forwarding-class

Observed forwarding-class bits.

X

X

X

X

X

X

sfc

To AA Sub:

Forwarding-class

Observed forwarding-class bits.

X

X

X

X

X

X

nfc

To AA Sub:

Maximum throughput byte count

Maximum of all total byte counts recorded for throughput intervals within this accounting interval for traffic originated from Network toward AA subscriber for an application/app-group. AA ISA discarded traffic is not included.

X

nbm

To AA Sub:

Packet count corresponding to the max. Throughput byte count interval.

Packet count for the throughput interval with the maximum byte count value for traffic originated from network toward AA subscriber for an application / app-group. AA ISA discarded traffic is not included.

X

npm

From AA Sub:

Max throughput time slot index

UTC time that corresponds to the end of the 5-minute throughput interval where the max throughput byte count was detected.

X

nmt

From AA Sub: Forwarding-class

Observed forwarding-class bits.

X

X

X

X

X

X

X

From AA Sub:

Maximum throughput byte count

Maximum of all total byte counts recorded for throughput intervals within this accounting interval for all traffic originated by AA subscriber. AA ISA discarded traffic is not included.

X

sbm

From AA Sub:

Packet count corresponding to the max. Throughput byte count interval.

Packet count for the throughput interval with the maximum byte count value for traffic originated by AA subscriber. AA ISA discarded traffic is not included.

X

spm

From AA Sub:

Max throughput time slot index

UTC time that corresponds to the end of the 5-minute throughput interval where the max throughput byte count was detected.

X

smt

To AA Sub:

Maximum throughput byte count

Maximum of all total byte counts recorded for throughput intervals within this accounting interval for traffic originated from network toward AA subscriber. AA ISA discarded traffic is not included.

X

nbm

To AA Sub:

Packet count corresponding to the max. Throughput Byte Count interval.

Packet count for the throughput interval with the maximum byte count value for traffic originated from network toward AA subscriber. AA ISA discarded traffic is not included.

X

npm

To AA Sub:

Max throughput time slot index

UTC time that corresponds to the end of the 5-minute throughput interval where the max throughput byte count was detected.

X

nmt

Forwarding Class

X

fc

App-Profile

AA subscriber application profile name

X

app-profile

App-Service-Options

List of the app-service-options characteristics and values per AA subscriber

X

app-service-option

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/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 ite and allow the option for AA to remark these into a higher traffic class, with reporting per FC to show resulting use.

AA partition traffic type statistics

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

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

  • 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 Families and protocols

Table 11. Families and protocols
Family Protocols

IPv4

TCP, UDP, Other

IPv6

TCP, UDP, Other

DS-Lite

TCP, UDP, Other (IPv4 tunneled inside IPv6)

6to4/6RD

TCP, UDP, Other (IPv6 tunneled inside IPv4)

Teredo

TCP, UDP, Other (IPv6 tunneled inside IPv4 and UDP)

v4inv4GTP

TCP, UDP, Other (IPv4 tunneled inside IPv4 GTP)

v4inv6GTP

TCP, UDP, Other (IPv4 tunneled inside IPv6 GTP)

v6inv4GTP

TCP, UDP, Other (IPv6 tunneled inside IPv4 GTP)

v6inv6GTP

TCP, UDP, Other (IPv6 tunneled inside IPv6 GTP)

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.

AA-partition traffic type statistics lists the statistic record fields per AA partition.

Table 12. AA-partition traffic type statistics
Record name Type Description

nsa

cumulative

sessions admitted (to-sub)

ssa

cumulative

sessions admitted (from-sub)

nca

cumulative

chunks admitted (to-sub)

sca

cumulative

chunks admitted (from-sub)

sba

cumulative

octets admitted (from-sub)

spa

cumulative

packets admitted (from-sub)

sbd

cumulative

octets denied (from-sub)

spd

cumulative

packets denied (from-sub)

nba

cumulative

octets admitted (to-sub)

npa

cumulative

packets admitted (to-sub)

nbd

cumulative

octets denied (to-sub)

npd

cumulative

packets denied (to-sub)

sfa

cumulative

flows admitted (from-sub)

sfd

cumulative

flows denied (from-sub)

saf

intervalized

active flows (from-sub)

nfa

cumulative

flows admitted (to-sub)

nfd

cumulative

flows denied (to-sub)

naf

intervalized

active flows (to-sub)

tfc

cumulative

total terminated flows

tfd

cumulative

total terminated flow duration

sdf

cumulative

short duration flows

mdf

cumulative

medium duration flows

ldf

cumulative

long duration flows

sfc

cumulative

forwarding-class bitmap (from-sub)

nfc

cumulative

forwarding-class bitmap (to-sub)

tet

cumulative

number of subscribers tethered

nte

cumulative

number of subscribers not tethered

Configurable AA subscriber statistics collection

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.

AA-performance record for ISA load

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

  • provides end of reporting interval snapshot of current values of the parameters listed in below 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.

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

  • provides peak values of the above 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 node per-ISA planning record values are cleared on accounting read (per all accounting records). Not reading the records means that the average and peak values are the values for the last reporting interval. The time last read is indicated in the record.

The following table lists AA performance planning record fields.

Table 13. AA performance planning record fields
Parameter Current Average Peak

ISA ID

active subs (with flows)

# subs

# subs

# subs

downloaded subs

# subs

# subs

# subs

ISA AA sub stats resource allocation

# stats records

ISA capacity cost

sum of cost of active AA subs

ISA Transit Subs

# subs

diverted traffic

(packets, octets)

entered ISA

(packets, octets)

policy discards in ISA

(packets, octets)

congestion discards in ISA

(packets, octets)

error discards in ISA

(packets, octets)

policy bypass errors

(packets, octets)

returned traffic

(packets, octets)

Volume cflowd

Records reported

# records

Reports dropped

# records

Packets sent

# packets

Comprehensive cflowd

Records reported

# records

Reports dropped

# records

Packets sent

# packets

TCP performance cflowd

Flows not allocated

#flows

Records reported

# records

Reports dropped

# records

Packets sent

# packets

RTP performance cflowd

Flows not allocated

#flows

Records reported

# records

Reports dropped

# records

Packets sent

# packets

Number of synchronization sources that had to be aborted

#SSRC aborted

URL-filter

url-filter http-requests sent

# http-requests

url-filter - http-request errors

# http-requests

url-filter - http-requests dropped

# http-requests

url-filter - http-requests permitted

# http-requests

url-filter - http-requests redirected

# http-requests

url-filter - http-requests blocked

# http-requests

url-filter - http default actions

# http-requests

url-filter - subscriber count

# subs

url-list permits

url local list #http requests allowed

url-list redirects

url local list #http requests redirected

url-list drops

url local list #http requests dropped

ICAP

icap requests

# messages

icap request errors

# messages

icap permits

# messages

icap redirects

# messages

icap drops

# messages

icap late responses

# messages

icap average rtt

seconds

icap tcp connections

# icap sessions

Web Service

webServRequests (wsreq)

# successful requests

httpRequestErrors (wsersp)

# unsuccessful requests

webServResponses (wsrsp)

# responses

webServLateResponses (wslrsp)

# late responses

webServAvgRtt (wsrtt)

Average SRTT

webServCacheHits (wsch)

# requests served by cache

The following table lists AA performance records.

Table 14. AA performance records
Record name Type Description MIB object (if applicable)

tmo

Cumulative

Octets to MDA

tmnxBsxGrpStatusOctsToMda

tmp

Cumulative

Packets to MDA

tmnxBsxGrpStatusPktsToMda

fmo

Cumulative

Octets from MDA

tmnxBsxGrpStatusOctsFromMda

fmp

Cumulative

Packets from MDA

tmnxBsxGrpStatusPktsFromMda

dco

Cumulative

Octets discarded because of congestion in MDA

tmnxBsxGrpStatusOctsDisCongMda

dcp

Cumulative

Packets discarded because of congestion in MDA

tmnxBsxGrpStatusPktsDisCongMda

dpo

Cumulative

Octets discarded because of policy in MDA

tmnxBsxGrpStatusOctsDiscPolicy

dpp

Cumulative

Packets discarded because of policy in MDA

tmnxBsxGrpStatusPktsDiscPolicy

deo

Cumulative

Octets discarded because of error

tmnxBsxGrpStatusOctsDiscErrors

dep

Cumulative

Packets discarded because of error

tmnxBsxGrpStatusPktsDiscEnors

pbo

Cumulative

Octets policy bypass

tmnxBsxGrpStatusOctsPolicyByps

pbp

Cumulative

Packets policy bypass

tmnxBsxGrpStatusPktsPolicyByps

nfl

Cumulative

Number of flows

tmnxBsxGrpStatusFlows

caf

Intervalized

Current active flows

tmnxBsxGrpStatusFlowsCurrent

aaf

Intervalized

Average active flows

tmnxBsxGrpStatusFlowsAverage

paf

Intervalized

Peak active flows

tmnxBsxGrpStatusFlowsPeak

cfr

Intervalized

Current flow setup rate

tmnxBsxGrpStatusFlowSetupRate

afr

Intervalized

Average flow setup rate

tmnxBsxGrpStatusFlowSetupRateAvg

pfr

Intervalized

Peak flow setup rate

tmnxBsxGrpStatusFlowSetupRatePk

ctr

Intervalized

Current traffic rate

tmnxBsxGrpStatusTrafficRate

atr

Intervalized

Average traffic rate

tmnxBsxGrpStatusTrafficRateAvg

ptr

Intervalized

Peak traffic rate

tmnxBsxGrpStatusTrafficRatePeak

cpr

Intervalized

Current packet rate

tmnxBsxCflowdStatusPktRateCurr

apr

Intervalized

Average packet rate

tmnxBsxGrpStatusPacketRateAvg

ppr

Intervalized

Peak packet rate

tmnxBsxGrpStatusPacketRatePeak

cas

Intervalized

Current active subscribers (with flows)

tmnxBsxGrpStatusSubsCurrent

aas

Intervalized

Average active subscribers (with flows)

tmnxBsxGrpStatusSubsAverage

pas

Intervalized

Peak active subscribers (with flows)

tmnxBsxGrpStatusSubsPeak

cds

Intervalized

Current diverted subscribers

tmnxBsxGrpStatusSubsDiverted

ads

Intervalized

Average diverted subscribers

tmnxBsxGrpStatusSubsDivertedAvg

pds

Intervalized

Peak diverted subscribers

tmnxBsxGrpStatusSubsDivertedPk

rfi

Intervalized

Flows in use

tmnxBsxGrpStatusFlowReslnUse

rcc

Cumulative

ISA capacity cost

tmnxBsxGrpMdaCapacityCost

rss

Cumulative

Subscriber statistics count

tmnxBsxGrpMdaStatsResourceCount

rti

Cumulative

Transit IP address count

tmnxBsxGrpMdaTransitipAddrs

rtp4

Cumulative

Transit prefix v4 address count

tmnxBsxGrpMdaTransPrefV4Entr

rtp6

Cumulative

Transit prefix v6 address count

tmnxBsxGrpMdaTransPrefV6Entr

rtp6r

Cumulative

Transit prefix v6 remote address count

tmnxBsxGrpMdaTransPrefV6RemEntr

srs

Cumulative

Seen IP, requests sent

tmnxBsxGrpStatusHCSeenlpReqSenp

srd

Cumulative

Seen IP, requests dropped

tmnxBsxGrpStatusHCSeenlpReqDrop

tsc

Cumulative

Total subscribers created

tmnxBsxGrpStatusHCSubsCreated

tsd

Cumulative

Total subscribers deleted

tmnxBsxGrpStatusHCSubsDeleted

tsm

Cumulative

Total subscribers modified

tmnxBsxGrpStatusHCSubsModified

vrr

Cumulative

Volume cflowd, records reported

tmnxBsxCflowdStatusRecReported

vrd

Cumulative

Volume cflowd, records dropped

tmnxBsxCflowdStatusRecDropped

vps

Cumulative

Volume cflowd, packets sent

tmnxBsxCflowdStatusPktsSent

crr

Cumulative

Comprehensive cflowd, records reported

tmnxBsxCflowdStatusRecReported

crd

Cumulative

Comprehensive cflowd, records dropped

tmnxBsxCflowdStatusRecDropped

cps

Cumulative

Comprehensive cflowd, packets sent

tmnxBsxCflowdStatusPktsSent

trr

Cumulative

TCP performance cflowd, records reported

tmnxBsxCflowdStatusRecReported

trd

Cumulative

TCP performance cflowd, records dropped

tmnxBsxCflowdStatusRecDropped

tps

Cumulative

TCP performance cflowd, packets sent

tmnxBsxCflowdStatusPktsSent

tfn

Cumulative

TCP performance cflowd, flows but no cflowd resources available

tmnxBsxCflowdStatusFlowsNoRes

rrr

Cumulative

RTP performance cflowd, records reported

tmnxBsxCflowdStatusRecReported

rrd

Cumulative

RTP performance cflowd, records dropped

tmnxBsxCflowdStatusRecDropped

rps

Cumulative

RTP performance cflowd, packets sent

tmnxBsxCflowdStatusPktsSent

rfn

Cumulative

RTP performance cflowd, flows but no cflowd resources available

tmnxBsxCflowdStatusFlowsNoRes

rsr

Cumulative

RTP performance cflowd, number of synchronization sources that had to be aborted

tmnxBsxCflowdStatusHCUSupSSRCSt

res

Cumulative

srflow collector, records sent

The new data name is the collector address and port inserted into the XML record.

tmnxBsxCflowdCollStatRecSent

hrs

Cumulative

URL filter, HTTP requests sent

tmnxBsxUrlFltrStatsHttpRequests

hre

Cumulative

URL filter, HTTP request errors

tmnxBsxUrlFltrStatsHttpReqErrors

hri

Cumulative

URL filter, HTTP requests dropped

n/a

hrp

Cumulative

URL filter, HTTP requests permitted

tmnxBsxUrlFltrStatsHttpRespAIIow

hrr

Cumulative

URL filter, HTTP requests redirected

tmnxBsxUrlFltrStatsHttpRespRedir

hrb

Cumulative

URL filter, HTTP requests blocked

tmnxBsxUrlFltrStatsHttpRespBlock

hda

Cumulative

URL filter, HTTP default actions

tmnxBsxUrlFltrStatsHttpRespDef

irs

Cumulative

ICAP, icap requests

tmnxBsxlcapServerStatsRequests

ire

Cumulative

ICAP, icap request errors

tmnxBsxIcapServerStatsReqErrors

irp

Cumulative

ICAP, icap permits

tmnxBsxIcapServerStatsReapAIIow

irr

Cumulative

ICAP, icap redirects

tmnxBsxIcapServerStatsRespRedir

ird

Cumulative

ICAP, icap drops

tmnxBsxIcapServerStatsRespBlock

ilr

Cumulative

ICAP, icap late responses

tmnxBsxUrlFltrStatsIcapLateResp

irt

Cumulative

ICAP, icap average rtt

tmnxBsxIcapServerStatsRoundTrip

itc

Cumulative

ICAP, icap TCP connections

tmnxBsxlcapServerStatsConnEst

ifs

Cumulative

URL filter, subscriber count

n/a

rtp4r

Cumulative

Transit prefix, v4 remote address count

tmnxBsxGrpMdaTransPrefV4RemEntr

lrp

Cumulative

URL list permits

tmnxBsxUrlFltrStatsHttpRespAIIow

lrr

Cumulative

URL list redirects

tmnxBsxUrlFltrStatsHttpRespRedir

lrd

Cumulative

ULR list drops

tmnxBsxUrlFltrStatsHttpRespBlock

fra

Intervalized

Flow resources average

tmnxBsxGrpStatusFlowResAvg

frp

Intervalized

Flow resources peak

tmnxBsxGrpStatusFlowResPeak

frs

Intervalized

Flow resources alarm state

tmnxBsxGrpStatusFlowResState

fre

Intervalized

Flow resources alarm count

tmnxBsxGrpStatusFlowResRsdCount

frtm

Intervalized

Flow resources alarm time

tmnxBsxGrpStatusFlowResRaisdTime

feo

Cumulative

Flow exhaust octets

tmnxBsxGrpStatusFlwResCtThruOcts

fep

Cumulative

Flow exhaust packets

tmnxBsxGrpStatusFlwResCtThruPkts

fss

Intervalized

Flow setup rate alarm state

tmnxBsxGrpStatusFlowSetupState

fse

Intervalized

Flow setup rate alarm count

tmnxBsxGrpStatusFlowSetupRsdCnt

fstm

Intervalized

Flow setup rate alarm time

tmnxBsxGrpStatusFlowSetupRsdTime

brs

Intervalized

Bitrate alarm state

tmnxBsxGrpStatusBitRateState

bre

Intervalized

Bitrate alarm count

tmnxBsxGrpStatusBitRateRsdCount

brtm

Intervalized

Bitrate alarm time

tmnxBsxGrpStatusBitRateRsdTime

prs

Intervalized

Packet rate alarm state

tmnxBsxGrpStatusPktRateState

pre

Intervalized

Packet rate alarm count

tmnxBsxGrpStatusPktRateRsdCount

prtm

Intervalized

Packet rate alarm time

tmnxBsxGrpStatusPktRateRaisedTime

ocs

Intervalized

Overload alarm state

tmnxBsxGrpStatusWaSBfFmSubState

tmnxBsxGrpStatusWaSBfToSubState

oce

Intervalized

Overload alarm count

tmnxBsxGrpStatusWaSBfFmSubRsdCnt

tmnxBsxGrpStatusWaSBfToSubRsdCnt

octm

Intervalized

Overload alarm time

tmnxBsxGrpStatusWaSBfFmSubRsdTm

tmnxBsxGrpStatusWaSBfToSubRsdTm

oco

Cumulative

Overload cut-through octets

tmnxBsxGrpStatusOvrldCtThruOcts

ocp

Cumulative

Overload cut-through packets

tmnxBsxGrpStatusOvrldCtThruPkls

mcpua

Intervalized

Management CPU average

tmnxBsxGrpStatusMgmlCpuAvg

mcpup

Intervalized

Management CPU peak

tmnxBsxGrpStatusMgmtCpuPeak

dcpua

Intervalized

DP CPU average

tmnxBsxGrpStatusDatapathCpuAvg

dcpup

Intervalized

DP CPU peak

tmnxBsxGrpStatusDatapathCpuPeak

dcpus

Intervalized

DP CPU alarm state

tmnxBsxGrpStatusDatapathCpuState

dcpue

Intervalized

DP CPU alarm count

tmnxBsxGrpStatusDatapathCpuRsdCt

dcpum

Intervalized

DP CPU alarm time

tmnxBsxGrpStatusDatapathCpuRSDTm

AA partition traffic type statistics

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

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

  • Family includes IPv4, IPv6, DS-Lite, 6RD/6to4, and Teredo.

  • 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 Families and protocols

Table 15. Families and protocols
Family Protocols

IPv4

TCP, UDP, Other

IPv6

TCP, UDP, Other

DS-Lite

TCP, UDP, Other (IPv4 tunneled inside IPv6)

6to4/6RD

TCP, UDP, Other (IPv6 tunneled inside IPv4)

Teredo

TCP, UDP, Other (IPv6 tunneled inside IPv4 and UDP)

v4inv4GTP

TCP, UDP, Other (IPv4 tunneled inside IPv4 GTP)

v4inv6GTP

TCP, UDP, Other (IPv4 tunneled inside IPv6 GTP)

v6inv4GTP

TCP, UDP, Other (IPv6 tunneled inside IPv4 GTP)

v6inv6GTP

TCP, UDP, Other (IPv6 tunneled inside IPv6 GTP)

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

Per AA partition stats record fields lists the record fields.

Table 16. Per AA partition stats record fields
Record name Type Description MIB object (if applicable)

sba

cumulative

octets admitted (from-sub)

tmnxBsxTrafStatOctsAdmFmSb

spa

cumulative

packets admitted (from-sub)

tmnxBsxTrafStatPktsAdmFmSb

sbd

cumulative

octets denied (from-sub)

tmnxBsxTrafStatOctsDnyFmSb

spd

cumulative

packets denied (from-sub)

tmnxBsxTrafStatPktsDnyFmSb

nba

cumulative

octets admitted (to-sub)

tmnxBsxTrafStatOctsAdmToSb

npa

cumulative

packets admitted (to-sub)

tmnxBsxTrafStatPktsAdmToSb

nbd

cumulative

octets denied (to-sub)

tmnxBsxTrafStatOctsDnyToSb

npd

cumulative

packets denied (to-sub)

tmnxBsxTrafStatPktsDnyToSb

sfa

cumulative

flows admitted (from-sub)

tmnxBsxTrafStatFlwsAdmFmSb

sfd

cumulative

flows denied (from-sub)

tmnxBsxTrafStatFlwsDnyFmSb

saf

intervalized

active flows (from-sub)

tmnxBsxTrafStatActFlwsFmSb

nfa

intervalized

active flows (to-sub)

tmnxBsxTrafStatActFlwsToSb

nfd

cumulative

flows denied (to-sub)

tmnxBsxTrafStatFlwsDnyToSb

naf

intervalized

active flows (from-sub)

tmnxBsxTrafStatActFlwsFmSb

tfc

cumulative

total terminated flows

tmnxBsxTrafStatTermFlws

tfd

cumulative

total terminated flow duration

tmnxBsxTrafStatTermFlwDur

sdf

cumulative

short duration flows

tmnxBsxTrafStatShrtDurFlws

mdf

cumulative

medium duration flows

tmnxBsxTrafStatMedDurFlws

ldf

cumulative

long duration flows

tmnxBsxTrafStatLngDurFlws

sfc

cumulative

forwarding-class bitmap (from-sub)

N/A

nfc

cumulative

forwarding-class bitmap (to-sub)

N/A

AA partition admit–deny statistics

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

    • error-drop

    • overload-drop

    • tcp-validate

    • fragment-drop all

    • fragment-drop out-of-order

    • gtp-sanity-drop

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

Admit–deny threshold crossing alerts

AA supports Threshold Crossing Alerts (TCAs) that can be configured against any of the statistics counters listed in AA partition admit–deny statistics. A high watermark and a low watermark can be configured for each counter. After the counter value reaches the configured high watermark within any 60 second interval, an event (Trap is set) is raised. The event is cleared if the counter goes below the low watermark threshold in any subsequent 60 seconds interval.

RADIUS accounting AA records

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

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

AA RADIUS accounting is implemented using ALU Vendor Specific Attributes (VSAs). This provides all charging group counters for a 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.

AA Gx based usage monitoring

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

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

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

Figure 20. Usage monitoring

AA ISA (the PCEF) supports Usage-Thresholds AVPs that refer to the thresholds (in byte) at which point an event needs to be sent back to the PCRF (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.

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

Cflowd AA records

AA ISA allows cflowd records to be exported to an external cflowd collector. The cflowd collector parameters (such as IP address and port number) are configured per application assurance group. Operators can choose to export cflowd records directly inband on a configurable VLAN from AA or via the CPM, similar to the way system cflowds are exported. By exporting directly inband, a higher rate of cflowd records can be exported compared to export via CPM, as inband export by-passes CPM and 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.

  • audio/video (A/V) application performance

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

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

    This feature provides:

    • call quality analysis using optimized ITU-T G.107, such as listening and conversational quality MOS and R-factor scores (MOS-LQ, MOS-CQ R-LQ and R-CQ)

    • measurements of perceptual effects of burst packet loss and recency using ETSI TS 101 29-5 Annex E Extensions

    • reporting of RTCP XR (RFC 3611, RTP Control Protocol Extended Reports (RTCP XR)) VoIP metrics payloads

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

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

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

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

vRGW nested router detection

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

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

The operator can install policies to handle nested router (tethering state) devices as appropriate, including but not limited to: applying different charging, blocking, rate limiting 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.

AQP

An AQP is an ordered set of entries defining application-aware policy (actions) for IP flows diverted to a specific AA ISA group. The IP flow match criteria are based on application identification (application or application group name) but are expected to use additional match criteria such as ASO characteristic value, IP header information or AA subscriber ID, for example.

When ASO characteristic values are used in application profiles, the characteristics values can be further used to subdivide an AQP into policy subsets applicable only to a subset of AA subscribers with a specific value of an ASO characteristic in their profile. This allows to, for example, subdivide AQP into policies applicable to a specific service option (MOS iVideo Service), specific subscriber class (Broadband service tier, VPN, Customer X), or a combination of both.

A system without AQP defined has statistics generated but does not impact the traffic that is flowing through the system. However, it is recommended that an AQP policy is configured with at least default bandwidth and flow policing entries to ensure a fair access to AA ISA bandwidth/flow resources for all AA subscribers serviced by a specific AA ISA.

AQP rules consist of match and action criteria:

  • Match refers to application identification determined by application and application group configuration using protocol signatures and user-configurable application filters that allow customers to create a wide range of identifiable applications. To further enhance system-wide per subscriber/service management user configurable application groups are provided.

  • An AQP consists of a numbered and ordered set of entries each defining match criteria including AND, NOT and wild card conditions followed by a set of actions.

AQP Entry <#> = <Match Criteria> AND <Match Criteria> <action> <action>

  • OR match conditions are supported in AQP through defining multiple entries. Multiple match criteria of a single AQP entry form an implicit AND function. An AQP can be defined for both recognized and unrecognized traffic. IP traffic flows that are in the process of being identified have a default policy applied (AQP entries that do not include application identification or IP header information). Flows that do not match any signatures are identified as unknown-tcp or unknown-udp and can have specific policies applied (as with any other protocol).

  • Actions define AA actions to be applied to traffic, a set of actions to apply to the flows like bandwidth policing, packet discards, QoS remarking and flow count or/and rate limiting.

AQP match criteria

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

AQP actions

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.

AA policers

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.

Table 17. Policer's hardware rate steps for AA ISA
Hardware rate steps Rate range (rate step x 0 to rate step x 127 and max)

0.5 Gbytes/s

0 to 64 Gbytes/s

100 Mb/s

0 to 12.7Gbytes/s

50 Mb/s

0 to 6.4 Gbytes/s

10 Mb/s

0 to 1.3 Gbytes/s

5 Mb/s

0 to 635 Mb/s

1 Mb/s

0 to 127 Mb/s

500 kb/s

0 to 64 Mb/s

100 kb/s

0 to 12.7 Mb/s

50 kb/s

0 to 6.4 Mb/s

10 kb/s

0 to 1.2Mb/s

8 kb/s

0 to 1 Mb/s

1 kb/s

0 to 127 kb/s

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 two levels of hierarchy (granularity):

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

Figure 21. From-AA subscriber application-aware bandwidth policing

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.

Figure 22. To-AA subscriber application-aware bandwidth policing
Time of day policing adjustments

Time-of-day changes to AA policing rates are configured using time-of-day overrides in the policers. Up to eight overrides can be configured per policer, each using either a daily or weekly time-range. The adjusted policing limits are applied immediately to all flows.

Congestion override policing

As part of Dynamic Experience Management (DEM), congested Access Network Locations (ANLs) or Non-location Based DEM (NLB-DEM) can, if configured, trigger a policing override of the per-subscriber bandwidth policers.

When a subscriber is declared to be in a congestion state, the per-subscriber congestion policer rates are triggered and override any existing per-subscriber policer rates, including time-of-day policer rates. These per-sub congestion policer rates are applied for the duration of time that the subscriber is in a congestion state.

After the subscriber's state is changed to uncongested, the per-subscriber congestion policer rates are no longer applied to the subscriber's traffic. The adjusted policing limits are applied immediately to all subscriber flows.

The per-sub congestion override policers are only applicable to bandwidth policers, both single and dual leaky buckets. They are not applicable to per-subscriber flow count or flow rate policers.

To configure the per-subscriber bandwidth policer override rates, use the following commands:

  • config>app-assure>group>policer>congestion-override

  • config>app-assure>group>policer>congestion-override>cbs

  • config>app-assure>group>policer>congestion-override>mbs

  • config>app-assure>group>policer>congestion-override>pir

  • config>app-assure>group>policer>congestion-override>cib

Charging filters

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.

Note:

The system does not support adc-start-stop notifications for charging groups assigned to charging filters.

AA TCP Optimization

AA TCP Optimization (TCPO) allows operators to leverage their existing access network deployments to provide higher throughput and improve users’ experience. AA TCPO overcomes the inherited inefficiencies of TCP when faced with larger round-trip delays, high bandwidth, and non-congestion related packet loss, which are common in wireless access networks.

In particular, TCP connections have several factors that affect the effective throughput and users’ experience:

  • Round Trip Time (RTT) delay and available bandwidth

  • TCP window size

  • TCP reaction to error in both the slow start and congestion avoidance that result in random TCP packet loss not because of congestion (for example, because of interference on the access side)

  • buffer bloating in the mobile access network

Note: AA TCPO is offered on the ESA platform running in lightweight subscale mode.
AA TCPO receiver window size

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.

AA TCPO Round Trip Time

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.

Effect of packet loss in mobile networks

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.

AA TCPO congestion window size

The initial congestion window size (cwnd) is a key component of 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. The majority of web transactions are on the small side, under 16 kbytes. The transactions are very short and complete before a slow start gets a chance to ramp up. To make full use of the significant bandwidth offered in mobile networks, AA TCPO sets the initial size of the cwnd, by default, high enough to allow small web transactions to take place within one RTT period. AA TCPO also offers the operator the ability to configure the initial cwnd size as part of the AA TCPO configuration policy.

AA TCPO buffer bloating in mobile networks

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.

Figure 23. 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 configuration

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 operation

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 restrictions

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.

AA Dynamic Experience Management

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

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

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

  • Wireless LAN DEM (WLAN-DEM) for WIFI wireless LAN gateway deployment

  • Non-Location Based DEM (NLB-DEM) for any access network

WLAN-DEM

Dynamic Experience Management (DEM) is a Wireless LAN Gateway (WLAN GW) capability that monitors user plane traffic to build a network-wide view of congestion on the subscriber, application, and access point radio levels. DEM enables making real-time decisions and dynamic actions, such as rate limiting or blocking of 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 WiFi radio. See WiFi network congestion at AP radio.

Figure 24. WiFi network congestion at AP radio

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

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

Intelligent network congestion control

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.

Multi-point congestion enforcement

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

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

Figure 25. DEM-GW multi-point congestion control

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

The DEM-GW achieves congestion control by:

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

NLB-DEM

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, WiFi, 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.

Access-Network-Location policers

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)

DEM-GW per-subscriber congestion override policers

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 congestion-override command is enabled and the subscriber is in a congestion state. 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

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

Figure 26. 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.

AA HTTP redirect

  • AA HTTP policy redirect

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

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

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

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

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

    Redirect landing page describes to the user why the page at www.poker.com is not accessible. See HTTP redirect because of URL block.

    Figure 27. HTTP redirect because of URL block

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

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

  • AA HTTP 404 redirect

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

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

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

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

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

    Figure 28. AQP actions

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

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

AA HTTPS policy redirect

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

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

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

For configuration details, see Configuring an HTTPS Policy Redirect.

ICAP - large scale category-based URL filtering

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

  • category based URL filtering; this is typically offered as an opt-in service by broadband or mobile operators to protect the subscribers from accessing selected category of URLs, such as, gambling, drugs, pornography, racism and so on

  • managed URL filtering service for Business VPN to prevent employee from accessing specific content

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

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

Figure 29. ICAP high level flow diagram

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

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

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

  • Each HTTP request within a TCP flows are sent to the ICAP server for rating.

  • HTTPs (SSL/TLS) ICAP URL-Filtering is limited to the domain name information.

  • HTTPS Redirection can only be performed if the Client Hello message contains an SNI, to match the filter and proceed with the redirect action.

Web-service URL classification

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

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

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

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

parental control
typically offered as an opt-in service; restricts users from accessing URLs categorized as, for example, drugs, gambling, violence, and weapons
security and threat protection
blocks URLs categorized as compromised or phishing/fraud
IWF
blocks sites belonging to the IWF list (mandated by law in several countries)

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

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

Figure 30. AA URL categorization

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

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

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

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

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

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

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

Table 18. Example URL category profile
High Medium Low

IWF List

IWF List

IWF List

Phishing/Fraud

Phishing/Fraud

Phishing/Fraud

Spyware and Malicious Sites

Spyware and Malicious Sites

Spyware and Malicious Sites

Illegal Drugs

Illegal Drugs

Violence

Violence

Weapons

Weapons

Nudity

Alcohol

Criminal Skills/Hacking

Hate Speech

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

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

A detailed configuration example is available in the Configuring web-service URL classification section.

Note: An additional license is needed to use the feature.
URL filtering categories for web-service URL classification

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.

Table 19. URL filtering categories
ID Name Description

1

Compromised

Web pages that have been compromised by someone other than the site owner, which appear to be legitimate, but house malicious code

2

Criminal Skills/Hacking

Web pages depicting activities that violate human rights including murder, sabotage, bomb building and so on

Information about illegal manipulation of electronic devices, encryption, misuse,

and fraud. For example, Warez and other illegal software distribution

3

Hate Speech

Web pages that promote extreme right/left wing groups, sexism, racism, religious hate and other discrimination

4

Illegal Drugs

Web pages that promote the use or information of common illegal drugs and the misuse of prescription drugs and compounds

5

Phishing/Fraud

Manipulated web pages and emails used for fraudulent purposes, also known as phishing

6

Spyware and Malicious Sites

Web sites or software that installs on a user's computer that have the intent to collect information or make system changes without the user's consent

7

Nudity

Web pages that display full or partial nudity with no sexual references or intent

8

Mature

Web sites that are not appropriate for children, includes sites with content about alternative lifestyles, profanity and so on

9

Pornography/Sex

Web pages containing explicit sexual content unsuitable for persons under the age of 18

10

Violence

Web pages that promote questionable activities such as violence and militancy

11

Weapons

Web pages that include guns and weapons when not used in a violent manner

12

Anonymizer

Web pages that promote proxies and anonymizers for surfing websites with the intent of circumventing filters

13

Computers and Technology

Web sites with information about computers, software, hardware, peripheral, and computers services

14

Download Sites

Web sites containing Shareware, Freeware, and other software. Also, P2P sites and software

15

Translator

Web pages that translate languages

16

Alcohol

Web pages that promote, advocate, or sell alcohol including beer, wine, and hard liquor

17

Health

Web pages supporting personal health and medical services including pages with information about equipment, procedures, and so on; not including drugs

18

Pharmacy

Web pages which include prescribed medications and information about approved drugs and their medical use

19

Tobacco

Web pages promoting the use of tobacco related products (for example, cigarettes, cigars, and pipes)

20

Gambling

Web pages which promote gambling, lotteries, casinos, and betting agencies involving chance

21

Games

Web pages consisting of computer games, game producers, and online gaming

22

Cars/Transportation

Web pages about vehicles including the selling, promoting, or discussion of vehicles

23

Dating and Relationships

Web pages that promote relationships such as dating and marriage

24

Home/Leisure

Web sites with information about home improvement and decorating, family, gardening, hobbies and so on

25

Personal Webpages

Web sites about or hosted by personal individuals. Also includes communication through blogs and guestbook servers, and information about personal hobbies and activities

26

Restaurants

Web sites about food, dining, and catering services including sites that provide reviews, advertisement, or other promotion

27

Sports and Recreation

Web sites about sports teams, fan clubs and news. Sites supporting recreation activities including zoos, public recreation centers, pools, and amusement parks

28

Travel

Web pages which provide travel and tourism information, online booking, and travel services such as airlines, car rentals, and hotels

29

Government

Web sites for government organizations, departments, or agencies, including police, fire, and hospitals

30

Military

Web pages sponsored by the armed forces and government-controlled agencies

31

Non-profits

Web pages supporting clubs, communities, unions, and non-profit organizations

32

Politics and Law

Web sites that promote political parties and interest groups. Sites containing information about elections and legislation, and sites that offer legal information and advice

33

Religion

Web sites containing religious information, including information about sects, cults, occultism and religious fundamentalism

34

Education

Web sites for educational institutions and schools and for educational and reference materials, including dictionaries and encyclopedias

35

Art

Web sites about theater, museums, exhibits, photography, and digital graphic resources

36

Entertainment and Videos

Web sites about videos, TV, and motion picture, including celebrity sites and entertainment news

37

Humor

Web pages which include comics, jokes, and other humorous content

38

Music

Web pages that include Internet radio and streaming media, musicians, bands, MP3, and media downloads

39

News

Web pages with general news information such as newspapers and magazines

40

Finance

Web sites for bank and insurance companies and other financial institutions, and for active trading of certificates and stocks

41

Internet Watch Foundation List

Web pages that show the physical or sexual abuse of children, including URLs reported by the Internet Watch Foundation (IWF); examples are child pornography, pedophilia, and child abuse

42

Shopping

Online shopping websites, catalogs, and online ordering. Also includes, auction sites, advertising, and classified ads.

Excludes shopping for products and services exclusively covered by another category such as health

43

Chat/IM

Communication through chat or IM services as well as sites with information about IM communication or chat rooms

44

Community Sites

Newsgroup sites and postings including forums and bulletin boards

45

Social Networking

Social networking web pages and online communities built around communities of people where users connect to other users

46

Web-based E-mail

Web pages that enable users to send and receive e-mails through a web-accessible e-mail account

47

Portal Sites

General web pages with customized personal portals, including white and yellow pages

48

Search Engines

Web pages that enable searching of web, newsgroups, pictures, directories, and other online content

49

Online Ads

Web pages supporting advertising graphics, banners, and pop-up ad content

50

Business/Services

General business web pages

51

Job Search

Web pages supporting job searches, agency searches, career planning, and human resources

52

Real Estate

Web pages with information about renting, purchasing, selling, or financing real estate including homes, apartments, office space, and so on.

53

Spam

Products and web pages promoted through spam techniques

54

Miscellaneous

Web pages that do not clearly fall into any other category

55

Uncategorized

Web pages for which there was no categorization provided

56

Marijuana

Web pages about marijuana or smoking marijuana.

Includes web pages on legalization, medicinal use, facts and info, and pictures endorsing the drug.

Does not include government sponsored web pages such as the Drug Enforcement Agency.

57

Provocative Attire

Refers to photos and videos where the person who is the subject of the photo or video is wearing sexually provocative clothing such as lingerie. Examples are bikini, bustier, negligee, and so on.

Local URL-list filtering

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

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

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

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

The hostnames of a local list may contain wildcards.

File format

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

  • non-printable ASCII characters other than \n and \r

  • space characters in the URL

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

The following is an example of URL list file content:

# Comment line for domain1 URL not using http:// schema
www.domain1.com/URI1
# Comment line for domain2 URL using http:// schema
http://domain2.com/URI2
Deny-lists

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.

Allow-lists

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

URL-list update

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.

HTTP/HTTPS

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.

HTTP header enrichment

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

Figure 31. HTTP enrichment

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

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

The AA ISA supports the insertion of one or more fields listed in HTTP header enrichment fields and formats into the HTTP header.

Note: If a field that is supported in Fixed Wireless Access (FWA) mode only is used in another deployment mode, AA either enriches the header with the default value or the enrichment is not performed.
Table 20. HTTP header enrichment fields and formats
Field Format Supported in all deployments Supported in FWA mode only

apn

Complete APN string

apn-ni

APN Network Identifier (APN-NI) or the complete APN if AA cannot decode the APN properly

billing-type

4-byte value IE: 0001

dynamic-acr

Dynamic Anonymous Customer Reference (ACR)1

imei-hyphenated2

Subscriber's IMEI with format AABBBBBB-CCCCCC-EE

imei-sv

Subscriber's IMEI with format AABBBBBBCCCCCCEE

imsi2

Subscriber’s IMSI

msisdn

Subscriber’s MSISDN

msisdn-ts

Subscriber's MSISDN appended with the UNIX timestamp

msisdn-without-cc

Subscriber's MSISDN without the country code

pgw_ggsn_address

PGW IP Address in IPv4 or IPv6 format, if the user is not in 5G

UPF IP Address, if the user is in 5G

plmin-id

MCC/MNC values as defined in 3GPP 24.301

rat-type

4-byte value as defined in 3GPP 29.212

static-acr

Static ACR1

static-string2

As configured by the operator

subscriber-id

Subscriber’s ID

subscriber-ip

Subscriber’s IP address in IPv4 or IPv6 format

timestamp

8-byte UNIX timestamp when enrichment took place

user-location

See User-location encoding and enrichment examples

user-location-3gpp

ULI encoded as defined in 3GPP TS2.061

user-location-raw2

ULI in raw format: <uli-type1>[+<uli-type2>]= <ULI data in hex>

Example:

x-locinfo: TAI+ECGI= 1300622c46130062014adf16

1 See ACR HTTP enrichment for more information.
2 AA can insert two copies of this parameter in the same HTTP header (with a different header name).

User-location encoding and enrichment examples lists user-location encoding and enrichment examples.

Table 21. User-location encoding and enrichment examples
Identity-type format Enrichment example3

CGI

mcc-mnc-lac-ci

x-user-loc: CellId=310-053-01a1-100a

SAI

mcc-mnc-lac-sac

x-user-loc: ServiceId=310-054-01a2-200b

RAI

mcc-mnc-lac-rac

x-user-loc: RoutingId=310-066-01a3-300c

TAI

mcc-mnc-tac

x-user-loc: TrackingId=310-220-01a4

ECGI

mcc-mnc-eci

x-user-loc: EutranCellId=623-01-1234567

LAI

mcc-mnc-lac

Not supported

Not-available

x-user-loc: User Location unavailable

1 In the enrichment examples, the header field name is configured as x-user-loc.
Note:
  • The ULI type can change and when it does, the mobile gateway reports it as a change to the AA-sub. AA stores and uses the latest ULI for enrichment. If the ULI type changes between the original packet transmission and the TCP retransmission, the latest ULI type is used on retransmission (that is, the ULI for retransmission is not cached).

  • The mcc-mnc values of the ULI are decimal digits (BCD), while the trailing portion of the ULI are hexadecimal values.

  • There can be more than one ULI identity type specified for an AA-sub, in which case the ECGI format is used. The only combination ULI supported by the mobile gateway is TAI + ECGI.

  • LAI is not supported, therefore this value is not used for enrichment.

  • The ULI is an optional parameter and may not be reported for an AA-sub. In this case, when enrichment is requested, the header is enriched with "User Location Unavailable".

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

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

For configured enriched fields, operators can optionally configure AA ISA to perform MD5 hashing, RC4 encryption, AES encryption, and anti-spoofing. When hashing is configured, the operator can optionally configure a string which is appended to the parameter before being hashed.

To perform encryption, the operator can configure an encryption key, which is used to encrypt the header values using the RC4 or AES algorithm, or install a certificate and configure the header enrichment to use that certificate. In the case of certificate-based header enrichment, the system uses the key contained in the HTTP header and performs encryption using the RSA algorithm. The system supports a maximum of 20 certificate profiles per group. The resulting string can be optionally encoded in base64 before it is inserted into the header.

Anti-spoofing, if enabled, ensures that only the fields enriched by AA are valid. Anti-spoofing is applicable only to the subscriber ID field. When configured, anti-spoofing analyzes existing headers. You must also apply the following configuration.

MD-CLI
[ex:/configure application-assurance group 1 http-enrich "example"]
A:admin@node-2# info
    admin-state enable
    field "msisdn" {
        anti-spoof true
        name "x-msisdn"
    }
classic CLI
A:node-2>config>app-assure>group>http-enrich$ info
----------------------------------------------
                field "msisdn"
                    name "x-msisdn"
                    anti-spoof
                exit
                no shutdown
----------------------------------------------

If the packet contains a header named "x-msisdn", AA appends an "X" character to it, and the name of the header becomes "x-msisdnX". AA subsequently enriches the MSISDN header, which ensures that the portals recognize only the header inserted by AA.

Note: AA anti-spoofs up to six headers in the same request, but you can configure anti-spoofing for more than six headers. If the HTTP header contains more than six headers that are anti-spoofed, the connection resets. The maximum of six applies to both different headers and headers of the same type (for example, an MSISDN header inserted seven times).

AA statistics reflect post header enrichment packet sizes.

HTTP enrichment exceptions

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.

ACR HTTP enrichment

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

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

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

ACR formats describes how an ACR is constructed.

Note: The exceptions mentioned in HTTP enrichment exceptions, also apply in ACR HTTP enrichment.
Table 22. ACR formats
Code Description Format Length Notes

CC

Country Code

NUM

3 digits

Example: 234 (UK)

NC

Network Code

NUM

3 digits

Example: 015

T

ACR Type

CHAR

4 characters

"STAT" or "DYNM"

RC

Date and time of transactions

"RSV" ||

CCYYMMD

DT

hh:mm:ssZ

23 characters

The string "RSV" followed by the date time (ISO8601 date), followed by the character "Z" with no spaces

Example: RSV2009-07-09T15:51:15Z

Encrypted

Encryption of the MSISDN and timestamp

344 characters

STAT = encrypted MSISDN

DYNM = encrypted [ISO8601 date + MSISDN]

The timestamp defines the creation time of the ACR

The format of MSISDN is without '+' and leading '0

HTTP in browser notification

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

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

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

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

Figure 32. HTTP in browser notification - high level

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

  • notification interval

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

  • success verification

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

  • HTTP notification example

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

    • AAA identifies that a particular subscriber is now over its quota.

    • A RADIUS CoA message is sent from the AAA to the 7750 SR to modify the subscriber app-profile to enable HTTP notification.

    • The AA ISA modifies the subscriber profile and enable HTTP notification for this subscriber.

    • The notification message is displayed in the subscriber web browser while browsing (in the form of an overlay or web banner). The content of the notification includes a link to the operator web portal to acknowledge the reception of the overage notification.

    • Until the subscriber clicks on the acknowledgment link, the AA ISA continues to execute the same policy so that notification messages are displayed in the subscriber web browser at the configured interval.

    • After the subscriber has clicked on the link provided in the notification message, the provider OSS system updates the AAA which then sends a new CoA message to the 7750 SR to modify the subscriber app-profile.

    • The AA ISA modifies the subscriber app-profile and disables HTTP notifications for this subscriber.

  • HTTP notification customization through RADIUS VSA

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

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

    • Alc-AA-Sub-Http-Url-Param RADIUS VSA: location=SohoStation

    • Configured Script-URL: http://10.1.1.1/notification.js

    • Subscriber HTTP request to the messaging server:

      http://10.1.1.1/notification.js?subId=<aa-subscriber-id>&VSA=&location=SohoStation

AA firewall

The AA firewall (FW) feature extends AA ISA application level analysis to provide an in-line integrated stateful service that protects subscribers from malicious security attacks. Using the AA stateful packet filtering feature combined with AA Layer 7 classifications and control empowers operators with advanced, next generation firewall functionalities that integrated are within. AA stateful firewall and application firewall run on the AA ISA. In a stateful inspection, the AA FW does not only inspect packets at Layers 3 — 7, but also monitors and keeps track of the connection's state. If the operator configures a ‟deny” action within a session filter then the matching packets (matching both the AQP and associated session filter match conditions) are dropped and no flow session state/context is created.

AA FW can be used in all deployments of AA ISA (on the related diverted AA subscriber context):

  • BNG (ESM)
  • WLAN Gateway (ESM or DSM)
  • Transit-subscriber (SAP or spoke-sdp)
  • Business AA (SAP or spoke-sdp)
  • Gi firewall (SAP or spoke-sdp)
  • SeGW firewall (SAP)
  • GRX FW firewall (SAP)

AA FW enabled solution provides:

Stateful flow processing and inspection uses IP Layers 3/4 header information to build a state of the flow within AA ISA. Layer 7 inspection is used to provide ALG support. Stateful flow/session processing takes note of the originator of the session and can therefore allow traffic to be initiated from the subscriber while denying, if configured, traffic originating from the network. Packets received from the network are inspected against the session filter and only those that are part of a subscriber-initiated-session are allowed.

Stateful firewall shows stateful firewall processing.

Figure 33. Stateful firewall

Stateless packet filtering does not take note of session initiator and therefore, it discards or allows packets independent of the any previous packets. Stateless packet filtering can be performed in the system using IOM ACLs.

AA FW inspection of packets at Layer 7 offers Application Layer Gateway functionality for the following applications:

  • rtsp

  • sip

  • h323 (IPv4 only)

  • googletalkvoice

  • ftp

  • tftp

  • pptp

  • citrix

  • sybase

  • msexchange

  • skinny

  • ares

  • bittorrent

  • dns

  • irc

  • mailru

  • qvod

  • R commands

  • sc2

  • socks

  • vudu

  • winmx

  • xunlei

Application layer gateway support shows application layer gateway support.

Figure 34. Application layer gateway support

These applications make use of control channels and flows that spun other flows. AA FW inspects the payload of these control flows so that it can open a pinhole for the associated required flows.

DoS protection

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.

TCP validation

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

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

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

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

Policy partitioned AA FW

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

Configuring AA FW

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

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

AQPs with session filter actions, need to have, as a matching condition, traffic direction, ASOs 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 FW logging

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

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

SeGW firewall protection

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

  • S1-MME (SCTP) traffic

  • S1- U (GTP-U) traffic

  • OAM traffic

SeGW firewall deployment shows an example of an SeGW firewall deployment.

Figure 35. 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.

OAM traffic protection

The aim of AA Firewall protection is to protect and prevent any abuse of OAM network resources (such as NMS).

Network flooding attacks, malformed packets and port scans are examples of such attacks that can be carried out using a compromised eNB/Femto Access Points (FAP).

  • ports scan attacks

    Using AA FW stateful session filters, operators can allow traffic only on certain IP addresses and port numbers.

    For example, operator can configure AA to only allow traffic that is initiated by NMS toward the FAPs. Therefore, a compromised FAP cannot initiate an attack on NMS infrastructure.

    Operator can limit the type of traffic allowed based on Layer 3 — Layer 7 classification. Operator can allow only HTTP with a specific URL/domain, DNS, PTP, FTP (independent of the port number used) and block all other traffic.

  • flood attacks

    The operator can limit the type of traffic allowed based on Layer 3 — Layer 7 classification. The operator can allow only HTTP with a specific URL/domain, DNS, PTP, FTP. The AA ISA provides configurable flow policers that can act on FW permitted sessions. These policers, when configured prevent all sort of flooding attacks, such as ICMP PING flooding, UDP flooding, SYN Flood Attack, and so on, of the port number used) and block all other traffic.

    • These policers provide protection at multiple levels; per system per application/application groups and per FAP (or per NMS) per applications or applications groups.

    • There are three types of AA ISA policers:

      • flow setup rate policers to limit the number of new flows

      • flow count policers to limit the total number of active flows

      • bandwidth policers to limit the total OAM bandwidth allowed by a FAP toward NMS

  • malformed packets attacks

    To protect Hosts and network resources, AA FW performs validation on IP packets, at the IP layer and TCP/UDP layer, to ensure that the packets are valid. Invalid packets are discarded (a configurable option). This provides protection against well-known attacks such as LAND attack. See Stateful firewall service for a complete description. AA allows the operator to optionally drop fragmented or out-of-order fragmented IP packets.

In addition, for OAM traffic, all AA functionalities including Layer 7 analytics and control as well as Application Layer Gateway (ALG) are supported.

For more details on OAM Traffic protection, see the AA firewall and the DoS protection sections.

S1-MME (SCTP) firewall

Network flooding attacks, malformed packets and port scans are examples of DoS attacks that can be carried out using a compromised eNB/FAP. AA FW provides inspection of SCTP (the protocol used to communicate to MME). Such inspection includes checking for SCTP protocol ID, source or destination ports, PPID, SCTP chunk checking and malformed SCTP packet (such as checksum validation).

SCTP chunk checking includes checking for:

  • invalid length values (frames with invalid length value are dropped regardless of the chunk type)

  • data chunks with length value that is too small to accommodate PPID (such frames are dropped as invalid/badly formed)

  • data chunks with length value that is too large for chunk (such frames are dropped as invalid/badly-formed)

For S1-MME traffic, the operator can configure various AA actions:

  • Drop packets with invalid checksum, src/dest IP or port numbers (malformed Packet protection) by appropriately configuring session filters with the following command.

    configure application-assurance group policy app-qos-policy entry action error-drop 
  • Use the sctp-filter command for PPID filtering.

  • Rate limit the amount of S1-MME traffic (flooding protection) in terms of bandwidth (b/s), using AA bandwidth policers.

  • Limit the number of concurrent SCTP flows (flooding protection) using AA flow count policers.

  • Limit the SCTP flow setup rate (flows per second) to protect against DoS flooding using AA flow rate policers.

  • Drop fragmented packets or drop out of order fragmented packets using the following command.

    configure application-assurance group policy app-qos-policy entry action fragment-drop {all | out-of-order}

The actions above can be applied per eNB/FAP IP address or per MME (to control aggregate traffic per MME).

SCTP PPID filtering
AA allows the operator to configure PPID filters that contain a list of PPIDs to allow or deny using the following commands.
configure application-assurance group sctp-filter ppid default-action
configure application-assurance group sctp-filter ppid default-action entry action

The filter can then be used within an AQP action.

AA identifies data chunks within SCTP payloads (for example, as first, nth or last chunk) and filters according to the configure PPID filter. If any chunk PPID matches a PPID on the configured blocked PPID list, the whole SCTP packet is dropped.

SCTP packets without data chunks are not impacted or accounted for by an SCTP Filter.

For IP fragmentation, and in the case where the operator did not configure AA ISA to drop ‟all fragmented traffic”, only the first IP fragment is inspected and subject to the PPID filtering. Any action applied to the first fragment is also applied to the remaining fragments. Out-of-order fragments appearing before the first fragment receive the default action (for example, drop action of ‟out-of-order-Frag”).

S1-U GTP traffic protection

The 7750 SR SeGW with AA FW provides protection of SGW/SGSN infrastructure against an attack from a compromised eNB/FAP. AA FW offers the following:

  • protection against malformed GTP packets attack. For GTP-v1 traffic carried over UDP port number port 2152, AA performs various packet sanity checks, such as:

    • UDP destination port is 2152

    • version (GTP-U should always be version 1)

    • protocol type bit should be 1

    • invalid/missing mandatory header fields

    • invalid optional/spare header fields

    • invalid/missing header extensions

    • invalid length

    For S1-U interface, only GTP-v1 is supported. No support for GTP-v2 (as there is no signaling on S1-U interface).

    Details of the various GTP sanity checks that are performed for different GTP-U message types are shown in GTP-U message types.

    Table 23. GTP-U message types
    Payload size Encapsulated data checks IE checks Header extension checks Optional HEADER check GTP mandatory header checks
    If E, S or PN =1 Length TEID Spare PT Version

    >0

    PayloadSize is assumed to be the size of the remainder of the packet, unless the packet is fragmented No checking of the encapsulated data

    No checks

    Valid types = Service Class Indicator and PDCP PDU Number Extension size= 4*# of extensions

    OptionalSize = 8

    IF E= 0, ExtSize = 0

    Optional Size + Extension Size + Payload Size

    <>0

    0

    1

    1

    G-PDU (Encapsulated Data Delivery) – Message Type 255

    No payload after the IEs

    Only private extensions are allowed.

    No external header allowed.

    No option headers allowed.

    IE Size

    0

    0

    1

    Echo Request – Message Type 1

    No payload after the IEs

    Recovery ID is present Private extensions allowed.

    No external header allowed.

    No option headers allowed.

    IE Size

    0

    0

    1

    1

    Echo Response – Message Type 2

    No payload after the IEs

    Extension Header Type List IE is present Private extensions allowed No checking on the extension header value

    No external header allowed.

    No option headers allowed.

    IE Size

    0

    0

    0

    1

    Supported Extension Headers Notification - Message Type 31

    No payload after the IEs

    TEID IE and GTP-U Peer Address IE are present IE type and length are verified Private extensions allowed

    Only the UDP Port Extension Header is valid

    OptionalSize = 8

    Optional Size + Extension Size +IE Size

    <>0

    0

    1

    1

    Error Indication – Message Type 26

    No payload after the IEs

    Only Private extensions are allowed

    no valid external header allowed.

    OptionalSize = 8

    IF E = 0, ExtSize = 0

    IE Size

    <>0

    0

    1

    1

    End Marker – Message Type 254

    To enable GTP packet sanity checks, the operator must configure:
    configure application-assurance group gtp

    When the gtp command is issued for a partition, AA treats traffic with UDP destination port number 2152 as GTP. It applies the different GTP level firewall functions as configured by the operator. However, it does not look beyond the GTP header for further inner L3-L7 packet classifications and actions. For example, Ipfix record for GTP traffic contains the 5 tuples of the GTP-u tunnel (eNB, SGW IPs and port numbers, and so on, no TEID).

  • protection against unsupported GTP messages

  • AA allows the operator to configure a GTP filter to indicate which GTP message types are to be allowed or denied as well as the maximum allowed GTP message length:

    configure application-assurance group gtp gtp-filter 
            config>app-assure>group <aa-group-id>[:<partition>]>gtp
                     gtp-filter <gtp-filter-name> [create]
                        max-payload-length <bytes>           //[0..65535]
                        message-type
                         default-action {permit|deny}
                         entry <entry-id> value <gtp-message-value> action {permit|deny}
    
  • There are approximately 67 valid message names to enter in the above GTP filter. Both names and numbers are accepted as input (for user convenience), but the CLI info always shows the name:

    echo-request, echo-response, error-indication, g-pdu, end-marker and supported-extension-headers-notification.

  • After a GTP filter is configured, it can then be included as an AQP action:

            config>app-assure>group <aa-group-id>[:<partition>]> policy
                   app-qos-policy
                       entry <entry-id> [create]
                          action
                            gtp-filter <gtp-filter-name>
    
  • extensive GTP header sanity checks (included in GTP-U message types) that are based on different GTP message types are only performed when these GTP messages are permitted by the GTP filter. If no GTP filter is configured, then no extensive GTP-U header checks are performed. In other words, if the operator wants to allow all GTP-U packets and perform all GTP header sanity checks, then the operator needs to configure a GTP filter with default action of permit and no values, such as:

            config>app-assure>group 1:100> gtp
                   gtp-filter ‟allow-all” create
                       message-type
                          default-action permit
    
  • protection against flooding attacks; AA can be configured to drop all fragments and/or out of order fragments, using AQP action: fragment-drop {all | out-of-order}.

  • In the case that the IP fragment-drop command is not set, then the following conditions apply to the way AA inspects GTP traffic:

    • Permit/deny decisions are entirely based on the first fragment. The first fragment contains the entire GTP header in almost all of the cases.

    • Max packet length check is not done across fragments. Only the first fragment length is checked. In other words, AA ISA may allow a packet that is larger than the max packet allowed if it is fragmented, with the first fragment smaller than the configured maximum packet size allowed.

    • First fragmented packet is discarded (and logged), as well as subsequent fragments:

      • If the first packet is too small to contain the mandatory header (12 bytes, ending with the TEID).

      • If the mandatory header indicates there should be an optional header, and the fragment is too small to contain the optional header (mandatory + optional = 16 bytes).

  • GTP-in-GTP protection; GTP-in-GTP is a spoofing method that uses GTP-in-GTP encapsulation. After receiving the GTP packet in the upstream, the Serving GPRS Support Node (SGSN) encodes the packet again and forwards the packet to the Gateway GPRS Support Node (GGSN), through the relative PDP context. The embedded GTP packet may get decoded by the GGSN and allow an attacker to spoof GTP packets.

    AA provides a mechanism to detect and drop GTP-in-GTP GTP-U packets:

            *A:Dut-C>config>app-assure>group>gtp# 
            +---gtp-filter <gtp-filter-name> [create]
            |   +---gtp-in-gtp {permit|deny}
    

    By default, GTP-in-GTP checking is disabled.

GTP backhaul roaming firewall protection

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

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

S5/S8/Gn/Gp AA firewall deployment shows the S5/S8/Gn/Gp AA Firewall deployment.

Figure 36. 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.

UE IP address anti-spoofing

Source address spoofing (also known as Overbilling Attacks) is initiated by a malicious UE that hijacks (spoofs) an IP address of another UE and invokes a download from a malicious server on the Internet. After the download begins, the malicious UE exits the session. The UE under attack, which is receiving the download traffic, gets charged for traffic it did not solicit.

AA FW associates the GTP-C message’s End user address IE with the GTP-U packets to make sure the packets carried in the upstream have the correct source IP address (inner IP within the GTP-U tunnel). When the UE address is negotiated within the PDP Context creation handshake, all the packets originating from the UE that contain a different source address are detected by AA FW and dropped.

To enable UE IP anti-spoofing protection, the operator must enable validate-source-ip-addr:

*A:Dut-C>config>app-assure>group>
+---gtp-filter <gtp-filter-name> [create]
|   +---validate-source-ip-addr

By default, validate-source-ip-addr is disabled.

GTP TEID validation

Compromised GSNs can send storms of GTP traffic with invalid GTP Tunnel Identifications (TEIDs) to cause a DoS attack. By inspecting GTP-C messages, AA FW supports stateful correlation of upstream and downstream GTP flows (DstIP + TEID) of the same PDN session.

AA drops packets with TEIDs that have not been negotiated correctly.

By default, TEID validation is disabled. The operator can enable AA to drop GTP traffic with invalid TEID using the following command sequence.

*A:Dut-C>config>app-assure>group>
+---gtp-filter <gtp-filter-name> [create]
|   +---validate-gtp-tunnels
GTP-C out-of-state message-type protection

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

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

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

Note: The packets are dropped regardless of the configuration in the message-type or message-type-gtpv2 filter.
Table 24. Invalid message types in GTP FW roaming deployments
GTP version GTP-U port GTP-C port

GTPv1

no invalid message types

GTPU PDU

GTPV1_END_MARKER

GTPV1_MSG_ERR_IND

GTPV1-ALL-MBMS message-types

GTPV1-ALL-Location management message-types

GTPv2

not applicable

GTP_PKT_ERROR_INDICATION

GTP_PKT_DNLK_DATA_FAIL_INDICATION

GTP_PKT_STOP_PAGING_INDICATION

GTP_PKT_CRE_INDR_TNL_REQ

GTP_PKT_CRE_INDR_TNL_RSP

GTP_PKT_DEL_INDR_TNL_REQ

GTP_PKT_DEL_INDR_TNL_RSP

GTP_PKT_RELEASE_BEARERS_REQ

GTP_PKT_RELEASE_BEARERS_RSP

GTP_PKT_DNLK_DATA

GTP_PKT_DNLK_DATA_ACK

GTP_PKT_MOD_ACCESS_BEARERS_REQ

GTP_PKT_MOD_ACCESS_BEARERS_RSP

GTP_PKT_REMOTE_UE_RPRT_NOTF

GTP_PKT_REMOTE_UE_RPRT_ACK

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

*A:Dut-C>config>app-assure>group>
+---gtpc-inspection
GTP anomaly prevention (sequence number checks)

Protocol anomaly attacks involve malformed or corrupt packets that typically fall outside of the protocol specifications. Packets are denied by AA FW if they fail the sanity check. Examples of GTP sanity checks are: invalid GTP header length, invalid Information Element (IE) length, invalid reserved fields, invalid sequence number, missing mandatory IEs, out-of-state message type.

In addition to the GTP-C inspection and GTP-U protocol validation described in UE IP address anti-spoofing, GTP TEID validation, and GTP-C out-of-state message-type protection, AA FW performs sequence number validation, whereby AA FW ensures that there are no out-of-sequence GTP packets. By default, sequence number validation is disabled. To enable sequence number validation, use the following CLI command:

*A:Dut-C>config>app-assure>group>
+---gtpc-inspection
+---gtp-filter <gtp-filter-name> [create]
|   |   +---validate-sequence-number

GTP Packets with wrong sequence numbers are dropped when validate-sequence-number is enabled.

GTP message type filtering

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

Table 25. Allowed message types that can be denied
GTP version GTP-U port GTP-C port

GTPv1

GTPV1_MSG_ECHO_REQ

GTPV1_MSG_ECHO_RESP

GTPV1_SUPP_EXT_HDR_NOTIF

GTPV1_MSG_ERR_IND

GTPV1_END_MARKER

GTPU_PDU

GTPV1_MSG_ECHO_REQ

GTPV1_MSG_ECHO_RESP

GTPV1_SUPP_EXT_HDR_NOTIF

GTPV1_MSG_VER_NOT_SUPP_IND

GTPV1_MSG_PDP_CREATE_REQ

GTPV1_MSG_PDP_CREATE_RESP

GTPV1_MSG_PDP_UPD_REQ

GTPV1_MSG_PDP_UPD_RESP

GTPV1_MSG_PDP_DEL_REQ

GTPV1_MSG_PDP_DEL_RESP

GTPV1_MSG_NET_INIT_REQ

GTPV1_MSG_NET_INIT_RESP

GTPV1_MSG_MSINFO_REQ

GTPV1_MSG_MSINFO_RESP

GTPv2

N/A

GTP_PKT_ECHO_REQ

GTP_PKT_ECHO_RSP

GTP_PKT_VERSION_NOT_SUPPORTED

GTP_PKT_CRE_SES_REQ

GTP_PKT_CRE_SES_RSP

GTP_PKT_MOD_BEARER_REQ

GTP_PKT_MOD_BEARER_RSP

GTP_PKT_DEL_SES_REQ

GTP_PKT_DEL_SES_RSP

GTP_PKT_CHG_NOT_REQ

GTP_PKT_CHG_NOT_RSP

GTP_PKT_MOD_BEARER_CMD

GTP_PKT_MOD_BEARER_FAIL_INDICATION

GTP_PKT_DEL_BEARER_CMD

GTP_PKT_DEL_BEARER_FAIL_INDICATION

GTP_PKT_BEARER_RESOURCE_CMD

GTP_PKT_BEARER_RESOURCE_FAIL_INDICATION

GTP_PKT_SUSPEND_NOTIFICATION

GTP_PKT_SUSPEND_ACK

GTP_PKT_RESUME_NOTIFICATION

GTP_PKT_RESUME_ACK

GTP_PKT_CRE_BEARER_REQ

GTP_PKT_CRE_BEARER_RSP

GTP_PKT_UPD_BEARER_REQ

GTP_PKT_UPD_BEARER_RSP

GTP_PKT_DEL_BEARER_REQ

GTP_PKT_DEL_BEARER_RSP

GTP_PKT_TRACE_SESSION_ACTIVATION

GTP_PKT_TRACE_SESSION_DEACTIVATION

GTP_PKT_UPDATE_PDN_CONNECTION_SET_REQ

GTP_PKT_UPDATE_PDN_CONNECTION_SET_RSP

GTP_PKT_DELETE_PDN_CONNECTION_SET_REQ

GTP_PKT_DELETE_PDN_CONNECTION_SET_RSP

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

To configure GTPv2 message filtering, use the following command:

*A:Dut-C>config>app-assure>group>
+---gtp-filter <gtp-filter-name> [create]
    +---gtpc-inspection
|   +---message-type-v2
|   |   |
|   |   +---default-action {permit|deny}
|   |   |
|   |   +---entry <entry-id> value <gtpv2-message-value> action {permit|deny}
|   |   |   no entry <entry-id>

To configure GTPv1 message filtering, use the following command:

*A:Dut-C>config>app-assure>group>
|   +---message-type
|   |   |
|   |   +--default-action {permit|deny}
|   |   |
|   |   +--entry <entry-id: 1..255> value <gtpv1-message-value> action {permit|deny}
|   |   |  no entry <entry-id>
Note: If the operator configures a message type invalid for the roaming interface and the user configures the message type to be denied, the message type is dropped and counted under that filter entry (and not tagged dropped because of ‟wrong-interface” in the event log). However, configuring the message-type filter to ‟permit” a message type that is invalid for the roaming interface does not take effect, because the packet with the specified message type is dropped by the GTP-C protocol inspection process.
Unauthorized APN attacks and APN filtering

Access Point Name (APN) filtering checks GTP-C messages to determine if a roaming subscriber is allowed to access a specified external network (also known as APN).

create-session-request and ‟create pdp request” GTP message types contain an APN IE in the header of a GTP packet. The APN IE consists of an external network-ID (for example, Nokia.com). Optionally, the APN IE can include a unique ID that identifies the operators' PLMN.

APN filtering prevents malicious UEs from initiating a ‟Create PDP/session Request” flood attack toward the PGW/GGSN for invalid or disallowed APNs.

The AA GTP filter can be configured to perform APN filtering to restrict roaming subscribers' access to specific external networks.

An APN filter, an IMSI prefix, and an SGSN Address pool can be used together to filter GTP packets as shown in the following example.

An APN filter entry can also be optionally combined with an SGSN or SGW IP address (or IP address prefix list) to further restrict allowed APN access by configured SGSN or SGW nodes.

*A:Dut-C>config>app-assure>group>
+---gtp-filter <gtp-filter-name> [create]
|   +---imsi-apn-filter //NEW and all its children attributes
|   |   +---default-action {permit|deny} //default permit
|   |   +---entry <entry-id: 1031..2030> create
|   |   |       + apn <string 0|1..32 characters>
|   |   |       |---no apn
|   |   |       + src-gsn ip-prefix-list <ip-prefix-list>
|   |   |       + src-gsn <ip address prefix>
|   |   |       |---no src-gsn
|   |   |       + action {permit|deny} //default permit
|   |   +---no entry <entry-id>

An APN filter and an IMSI prefix filter (see Unauthorized PLMN access—IMSI prefix filtering) can be used together to filter GTP packets.

By default, AA FW allows all of the APNs.

Unauthorized PLMN access—IMSI prefix filtering

The PLMN of a subscriber's home network is identified by combining the Mobile Country Code (MCC) and the Mobile Network Code (MNC). MCC-MNC is also known as the IMSI prefix. IMSI prefix acts as a PLMN identifier.

GTP IMSI prefixes filters can be configured to deny GTP incoming traffic from invalid roaming partners. Conversely, the filters can be configured to allow only incoming traffic from those network operators that have signed roaming agreements. The GTP packets with IMSI prefixes that do not match the configured prefixes are dropped.

An IMSI filter entry can also be optionally combined with an SGSN or SGW IP address (or IP address prefix list) to further restrict allowed IMSI prefix traffic to specific SGSN or SGW nodes.

*A:Dut-C>config>app-assure>group>
+---gtp-filter <gtp-filter-name> [create]
|   +---imsi-apn-filter //NEW and all its children attributes
|   |   +---default-action {permit|deny} //default permit
|   |   +---entry <entry-id: 1031..2030> create
|   |   |       + mcc-mnc-prefix <string of 1 to 6 decimal digits>
|   |   |       |---no mcc-mnc-prefix
|   |   |       + src-gsn ip-prefix-list <ip-prefix-list>
|   |   |       + src-gsn <ip address prefix
|   |   |       |---no src-gsn
|   |   |       + action {permit|deny} //default permit
|   |   +---no entry <entry-id>

An IMSI filter, an APN, and an SGSN Address can be used together to filter GTP packets.

By default, AA FW does not perform IMSI prefix filtering.

Unauthorized network access

An attacker using an unauthorized GSN can cause a denial of service attack using spoofed PDP Context Delete messages (DoS attack) or using a spoofed Update PDP Context Request to hijack existing sessions. Such attacks can also spoof a Create PDP Context Request to gain unlawful Internet access. Session hijacking can come from the SGW/SGSN or the PGW/GGSN. An unauthorized GSN can hijack GTP tunnels or cause a denial of service by intercepting another GSN and redirecting traffic to it.

Operators can use AA-FW to configure pools of trusted GSN IP addresses (using an AA IP-Prefix-list) to stop spoofed requests from untrusted GSNs.

AA IP-Prefix-lists can be configured to model GSN groups as follows:

*A:Dut-C>config>app-assure>group# 
   ip-prefix-list ip-prefix-list-name [create]
            prefix ip-prefix/ip-prefix-length [name prefix-name]

The configured AA IP-Prefix-lists are then referenced in session-filters, such that only sessions that match the lists are ‟permitted”.

*A:Dut-C>config>app-assure>group# session-filter
      default-action  deny
      entry           + Configure an entry in the session filter
        match
     src-ip    // Configure IP addresses that correspond to authorized SGW/SSGN 
 action
     permit
Typical S8/Gp AA FW network deployment model

AA GTP FW is typically deployed as an L3 and VPRN service. SAPs and spokes are diverted to AA for GTP FW. L2 and VPLS connectivity is supported by AA. AA transit subscribers (identified by SGW and SSGN IPs) are auto-created under the parent diverted SAPs and spokes. Operators need to enable inactivity monitoring to remove inactive subscribers. This can be done using the following command:

config>app-assure>group>transit-ip-policy>transit-auto-create 
[no] inactivity-mon

Service monitoring and debugging

Operators can use AA-specific tools in addition to system tools that allow them to monitor, adjust, debug AA services. The following are examples of some of the available functions:

  • Display and monitor AA ISA group status and statistics (AA ISA status and capacity planning/monitoring).

  • Clear AA ISA group statistics (clears all system and per-AA subscriber statistics).

  • Enable special study mode for real-time monitoring of AA subscriber traffic (ESM or transit subscriber, SAP or spoke SDP).

  • Display per AQP entry statistics for number of hits (flow matching the entry) and conflicts (actions ignored because of per-flow-action-limit exceeded).

  • Mirror (all or any subset of traffic seen by an AA ISA group).

  • Display all the per-ISA statistics from the aa-performance record, for examining resource loading of each ISA.

  • Display the top active AA subscribers per ISA by bytes, packets or flows, for traffic in each direction.

CPU utilization

The ISA show status command displays per ISA CPU utilization by main tasks, to provide insight into what aspects of load may be loading the ISA. These are split into 2 main areas:

  • management CPU

    This includes all tasks related to communication between the CPM and the ISA, with the following usage percentage reported:

    • system (various infrastructure and overhead work)

    • management (managing AA policy, AA subscriber and trap configurations, and handling tools requests)

    • statistics (collecting and reporting statistics and Cflowd reporting)

    • idle

  • datapath CPUs

    This includes all tasks related to datapath packet and flow processing on the ISA, with the following usage percentage reported:

    • system (various infrastructure and overhead work)

    • packet processing (receiving, associating with flows, applying application QoS policy, and transmitting)

    • application ID (using protocol signatures and other techniques to identify application/app-group and determine the application QoS policy)

CLI batch: begin, commit and abort commands

The AA uses CLI batch capability in policy definition. To start editing a policy, a begin command must be executed. To finish editing either abort (discard all changes) or commit (accept all changes) needs to be executed. CLI batch state is preserved on an HA activity switch.

To enter the mode to create or edit policies, the begin keyword must be entered at the prompt. Other editing commands include:

  • The commit command saves changes made to policies during a session. The newly committed policy takes effect immediately for all new flows. Existing flows transition onto the new policy shortly after the commit.

  • The abort command discards changes that have been made to policies during a session.

To allow flexible order for policy editing, the policy>commit function cross references policy components to verify, among others:

  • whether all ASO characteristics have a default value and are defined in the app-profile

  • checks whether limits are adhered

Configuring AA with CLI

This section provides information to configure Application Assurance entities using the command line interface. It is assumed that the user is familiar with basic configuration of policies.

Provisioning AA ISA MDA

The following illustrates syntax to provision AA ISA2 and configure ingress IOM QoS parameters (the egress IOM QoS is configured in the config>isa>application-assurance-grp>qos context).

  • classic CLI

    configure card slot-number mda mda-slot mda-type isa2-aa

  • MD-CLI

    configure card slot-number mda mda-slot mda-type isa2-aa

The following output displays an AA ISA configuration example.

Classic CLI:

*A:cpm-a>config>app-assure# show mda 1/1 
===============================================================================
MDA 1/1
===============================================================================
Slot  Mda   Provisioned           Equipped              Admin     Operational  
            Mda-type              Mda-type              State     State        
-------------------------------------------------------------------------------
1     1     isa2-aa                isa2-ms                 up        up         
===============================================================================
*A:cpm-a>config>app-assure#


*A:cpm-a>config>card# info 
----------------------------------------------
        card-type iom4-e-b
        mda 1
            mda-type isa2-aa
        exit
----------------------------------------------
*A:cpm-a>config>card# 

MD-CLI:

(gl)[/]
A:admin@Dut-E# show mda 9/1
===============================================================================
MDA 9/1
===============================================================================
Slot  Mda   Provisioned Type                            Admin     Operational
                Equipped Type (if different)            State     State
-------------------------------------------------------------------------------
9     1     isa2-aa                                     up        up
                me-isa2-ms                                            
===============================================================================


(gl)[/]
A:admin@Dut-E# configure card 9 
(gl)[/configure card 9]
A:admin@Dut-E# info
    card-type iom4-e-b
    mda 1 {
        mda-type isa2-aa
    }
    fp 1 {
    }

Configuring an AA ISA group

This section describes how to enable AA on the router.

  1. Create an AA ISA group.
  2. Assign active and optional backup AA ISAs to an AA ISA group.
  3. Select the forwarding classes to divert.
  4. Enable the group.
  5. Perform the following optional steps:
    1. Enable group policy partitioning.
    2. Configure capacity cost threshold values.
    3. Configure the number of transit prefix IP policies.
    4. Configure IOM egress queues to the MS-ISA.
    5. Enable overload cut through and configure the high and low watermarks values.
    6. Configure performance statistics accounting.

AA ISA group configuration

The following example illustrates AA ISA group configuration with:

  • primary AA ISA and warm redundancy provided by the backup AA ISA

  • ‟fail-to-wire” behavior configured on group failure

  • BE forwarding class selected for divert

  • default IOM QoS for logical ISA egress ports. The ISA ingress QoS is configured as part of ISA provisioning (config>card>mda>network>ingress>qos).

The following commands illustrate the AA ISA group configuration context:

config>isa>application-assurance-group isa-aa-group-id [create] [aa-sub-scale sub-scale] 
backup mda-id
description description
divert-fc fc-name
no fail-to-open
http-enrich-max-pkt size-in-octets
isa-capacity-cost-high-threshold threshold
isa-capacity-cost-low-threshold threshold
isa-overload-cut-through
partitions
minimum-isa-generation min-isa-generation
overload-sub-quarantine
  [no] shutdown
partitions
primary mda-id
qos
  egress
    from-subscriber
      pool [name]
        resv-cbs percent-or-default
        slope-policy slope-policy-name
      port-scheduler-policy port-scheduler-policy-name
      queue-policy network-queue-policy-name
      wa-shared-high-wmark percent
      wa-shared-low-wmark percent
   to-subscriber
     pool [name]
       resv-cbs percent-or-default
       slope-policy slope-policy-name
     port-scheduler-policy port-scheduler-policy-name
     queue-policy network-queue-policy-name
     wa-shared-high-wmark percent
     wa-shared-low-wmark percent
shared-resources
  tcp-adv-func size
[no] shutdown
statistics
  performance
    accounting-policy acct-policy-id
    collect-stats
transit-prefix-ipv4-entries entries
transit-prefix-ipv4-remote-entries entries
transit-prefix-ipv6-entries entries
transit-prefix-ipv6-remote-entries entries

The following output displays an AA ISA group configuration example:

A:ALU-A>config>isa>aa-grp# info detail
 ----------------------------------------------
    no description
    primary 1/2
    backup  2/2
    no fail-to-open
    isa-capacity-cost-high-threshold 4294967295
    isa-capacity-cost-low-threshold 0
    no partitions
    divert-fc be
    qos 
       egress
        from-subscriber
            pool 
                slope-policy "default"
                resv-cbs default
            exit
            queue-policy "default"
            no port-scheduler-policy
        exit
        to-subscriber
            pool
                slope-policy "default"
                resv-cbs default
            exit
            queue-policy "default"
            no port-scheduler-policy
        exit
       exit
    exit
     no shutdown
----------------------------------------------
A:ALU-A>config>isa>aa-grp#

Configuring watermark parameters

Use the following CLI syntax to configure thresholds for logs and traps when under high consumption of the flow table. The flow table has a limited size and these thresholds can be established to alert the user that the table is approaching capacity. These flow table watermarks represent the number of flow contexts allocated on the ISA, which is slightly higher than the actual number of existing flows at the point when the watermark is reached.

The low threshold is used while the high threshold is used as an alarm.

config>application-assurance
  flow-table-high-wmark high-watermark
  flow-table-low-wmark low-watermark

Configuring a group policy

Beginning and committing a policy configuration

To enter the mode to create or edit Application Assurance policies, you must enter the begin keyword at the config>app-assure>group>policy prompt. The commit command saves changes made to policies during a session. Changes do not take effect in the system until they have performed the commit function. The abort command discards changes that have been made to policies during a session.

The following error message displays when creating or modifying a policy without entering begin first:

A:ALA-B>config>app-assure>group>policy#
MINOR: AA #1005 Invalid Set - Cannot proceed with changes when in non-edit mode

There are no default policy options. All parameters must be explicitly configured.

Use the following CLI syntax to begin a policy configuration:

config>app-assure# group group-id
policy
  begin

Use the following CLI syntax to commit a policy configuration:

config>app-assure# group group-id
policy
  commit

Aborting a policy configuration

Use the following CLI syntax to abort a policy configuration:

config>app-assure# group group-id
    policy
        abort

Configuring an IP prefix list

An operator can use IP lists to define a list of IP addresses (along with any masks). This list can be later referenced in AQPs, application filters or session-filters.

Use the following CLI syntax to configure an application filter entry:

config>aa>group>policy>app-assurance>group <aa-group-id>[:<partition>] 
        ip-prefix-list <prefix-list-name> [create]
        no ip-prefix-list <prefix-list-name>
        description <description>
        no description
        prefix <address/mask> [name <prefix-name>]
        no prefix <address/mask>

The following example displays an IP prefix list configuration:


*A:Dut-A>config>app-assure>group# ip-prefix-list AllowedLAN1Hosts create
*A:Dut-A>config>app-assure>group>pfx>$ description "allowed hosts"
*A:Dut-A>config>app-assure>group>pfx>$ prefix 10.10.8.2/32
*A:Dut-A>config>app-assure>group>pfx>$ prefix 10.10.8.180/32
*A:Dut-A>config>app-assure>group>pfx>$ prefix 10.10.8.231/32
*A:Dut-A>config>app-assure>group>pfx>$ exit
*A:Dut-A>config>app-assure>group#


*A:Dut-A>config>app-assure>group# ip-prefix-list "AllowedLan1Hosts"
*A:Dut-A>config>app-assure>group>pfx># info
----------------------------------------------
                description "allowed hosts"
                prefix 10.10.8.2/32
                prefix 10.10.8.180/32
                prefix 10.10.8.231/32
----------------------------------------------
*A:Dut-A>config>app-assure>group>pfx>#

Configuring AA session filters

Session filters can be configured to allow stateful firewall use-cases.

Use the following CLI syntax to configure an AA session filter:

*A:Dut-A>config>app-assure>group# session-filter <session-filter-name> [create]
    default-action {permit | deny} [event-log <event-log-name>]
    description <description-string>
    entry <entry-id> [create]
            action {permit | deny} [event-log <event-log-name>]
            match
                dst-ip <ip-address>
                dst-ip ip-prefix-list <ip-prefix-list-name>
                no dst-ip
                dst-port {eq | gt | lt} <port-num>
                dst-port range <start-port-num> <end-port-num>
                dst-port port-list <port-list-name> 
                no dst-port
                ip-protocol-num <ip-protocol-number>
                no ip-protocol-num
                src-ip <ip-address>
                no src-ip
                src-ip ip-prefix-list <ip-prefix-list>
                src-port {eq | gt | lt} <port-num>
                src-port range <start-port-num> <end-port-num>
                src-port port-list <port-list-name> 
                no src-port
*A:Dut-A>config>app-assure>group# session-filter " denyUnsolictedwMgntCntrl" create
       description ‟S-FW opted-in sub – allow ISP access"
       default-action deny event-log ‟FW_log”
    entry 10 create
         description "allow ICMP access from ISP LAN#1"
         match
             ip-protocol-num icmp
             src-ip 10.10.8.0/24
         exit
         action permit
        exit
       entry 30 create
         description "allow all TCP (e.g. FTP/telnet)access from ISP LAN#2"
         match
             ip-protocol-num tcp
             src-ip 192.168.0.0/24
         exit
         action permit
       entry 40 create
         description "allow TCP on port 80 /HTTP access from a IP List on ISP LAN#1"
         match
             ip-protocol-num tcp
             src-ip ip-prefix-list AllowedLAN1Hosts
             dst-port eq 80
         exit
         action permit

       exit


*A:Dut-A>config>app-assure>group>sess-fltr$ info
----------------------------------------------
                description "S-FW opted-in sub . allow ISP access"
                default-action deny event-log ‟FW_Log”
                entry 10 create
                    description "allow ICMP access from ISP LAN#1"
                    match
                        ip-protocol-num icmp
                        src-ip 10.10.8.0/24
                    exit
                    action permit
                exit
                entry 20 create
                    description "allow ICMP access from ISP LAN#2"
                    action deny
                exit
                entry 30 create
                    description "allow all TCP (e.g. FTP/telnet)access from ISP LAN#2"
                    match
                        ip-protocol-num tcp
                        src-ip 192.168.0.0/24
                    exit
                    action permit
                exit
                entry 40 create
                    description "allow TCP on port 80 /HTTP access from a IP List on 
ISP LAN#1"
                    match
                        ip-protocol-num tcp
                        src-ip ip-prefix-list "AllowedLan1Hosts"
                        dst-port eq 80
                    exit
                    action permit
                exit


----------------------------------------------
*A:Dut-A>config>app-assure>group>sess-fltr$


*A:Dut-A>config>app-assure>group>policy>aqp>
   entry 110 create
    description ‟FW for managed opted-in subs”
       match
         traffic-direction network-to-subscriber
       exit
       action
           session-filter ‟ denyUnsolictedwMgntCntrl "
          fragment-drop all event-log "FW_log"
        error-drop event-log ‟FW_log”
       overload-drop

       exit
   exit


*A:Dut-A>config>app-assure>group>policy>aqp>entry# info
----------------------------------------------
                        description "FW for managed opted-in subs."
                        match
                            traffic-direction network-to-subscriber
                        exit
                        action
                            session-filter "denyUnsolictedwMgntCntrl"
                            fragment-drop all event-log "FW_log"
                            error-drop event-log ‟FW_log”
                            overload-drop
                         
                        exit
                        no shutdown
----------------------------------------------
*A:Dut-A>config>app-assure>group>policy>aqp>entry#

Configuring an application group

An operator can configure an application group to group multiple application into a single application assurance entity by referencing those applications in the group created.

Use the following CLI syntax to configure an application group:

config>app-assure>group>policy# app-group application-group-name [create]
    description description

The following example displays an application group configuration:

*A:ALA-48>config>app-assure>group>policy# app-group "Peer to Peer" create
*A:ALA-48>config>app-assure>group>policy>app-grp# info 
----------------------------------------------
                    description "Peer to Peer file sharing applications"
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>app-grp# 

Configuring an application

An operator can configure an application to group multiple protocols, clients or network applications into a single Application Assurance application by referencing it later in the created application filters as display in other sections of this guide.

Use the following CLI syntax to configure an application:

config>app-assure>group>policy# application application-name [create]
    app-group app-group-name
    description description

The following example displays an application configuration:

*A:ALA-48>config>app-assure>group>policy# application "SQL" create 
*A:ALA-48>config>app-assure>group>policy>app# info
----------------------------------------------
                    description "SQL protocols"
                    app-group "Business Critical Applications"
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>app#

Configuring an application filter

An operator can use an application filter to define applications based on ALU protocol signatures and a set of configurable parameters like IP flow setup direction, IP protocol number, server IP address and server TCP/UDP port. An application filter references an application configured as previously shown.

Use the following CLI syntax to configure an application filter entry:

config>app-assure>group>policy# app-filter
    entry entry-id [create]
        application application-name
        description description-string
        expression expr-index expr-type {eq | neq} expr-string
        flow-setup-direction {subscriber-to-network | network-to-subscriber | both}
        http-match-all-requests
        ip-protocol-num {eq | neq} protocol-id
        network-address {eq | neq} ip-address
        network-address {eq | neq} ip-prefix-list ip-prefix-list-name
        protocol {eq | neq} protocol-signature-name
        server-address {eq | neq} ip-address 
        server-address {eq | neq} dns-ip-cache dns-ip-cache-name 
        server-address {eq | neq} ip-prefix-list ip-prefix-list-name 
        server-port {eq | neq | gt | lt} server-port-number
        server-port {eq | neq} range start-port-num end-port-num
        server-port {eq} {port-num | range start-port-num end-port-num} first-packet-trusted | first-packet-validate}
        no shutdown

The following example displays an application filter configuration:

*A:ALA-48>config>app-assure>group>policy>app-filter# entry 30 create
*A:ALA-48>config>app-assure>group>policy>app-filter>entry# info 
----------------------------------------------
                        description "DNS traffic to local server on expected port #53"
                        protocol eq "dns"
                        flow-setup-direction subscriber-to-network
                        ip-protocol-num eq *
                        server-address eq 192.0.2.0/32
                        server-port eq 53
                        application "DNS_Local"
                        no shutdown
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>app-filter>entry# 

Configuring an application profile

Use the following CLI syntax to configure an application profile:

config>app-assure>group>policy# app-profile app-profile-name [create]
    characteristic characteristic-name value value-name
    description description-string
    [no] aa-sub-suppressible
    divert

The following example displays an application profile configuration:

*A:ALA-48>config>app-assure>group>policy# app-profile "Super" create 
*A:ALA-48>config>app-assure>group>policy>app-prof# info 
----------------------------------------------
                    description "Super User Application Profile"
                    divert
                    characteristic "Server" value "Prioritize"
                    characteristic "ServiceBw" value "SuperUser"
                    characteristic "Teleworker" value "Yes"
                    characteristic "VideoBoost" value "Priority"
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>app-prof# 

Configuring suppressible app-profile with SRRP

For information about SRRP, see the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide.

In the context of an ESM SRRP deployment, the operator can define at the app-profile level if the subscriber is diverted to the ISA-AA card per SRRP group interface. This can be useful to reduce the total number of ISA cards required in the event of a switch-over from a primary to backup SRRP node when AA is used as a value-add service for selected subscribers.

To configure the network for suppressible app-profiles in the context of SRRP the operator needs to:

  • Enable the capability to suppress AA subscribers on a specific SRRP group interface, typically by selecting backup SRRP group interfaces.

  • ESM subscribers with a valid app-profile are diverted to AA by default, to suppress selected group of subscribers using AA for optional value-add services. The operator then specifies which app-profile is suppressed and therefore not diverted to AA.

Use the following CLI syntax to enable the capability to suppress ESM subscribers from a backup SRRP group interface:

config>service>vprn>sub-if>grp-if# suppress-aa-sub [create]
    characteristic characteristic-name value value-name
    description description-string
    [no] aa-sub-suppressible
    divert

The following example displays an application profile configuration used for premium subscribers, this type of subscriber is always be diverted to Application Assurance, it is also the default configuration:

7750>config>app-assure>group>policy# info
----------------------------------------------
                app-profile "Premium" create
                    characteristic "Parental-Control" eq "Yes"
                    divert
                exit
----------------------------------------------

The following example displays an application profile configuration for best effort / value-add subscribers not diverted to Application Assurance on the SRRP group interface configured with ‟suppress-aa-sub”:

7750>config>app-assure>group>policy# info
----------------------------------------------
                app-profile "1-default" create
                    divert
                    aa-sub-suppressible
                exit
----------------------------------------------

Configuring application service options

Use the following CLI syntax to configure application service options:

config>app-assure>group>policy# app-service-options
    characteristic characteristic-name [create]
        default-value value-name
        value value-name

The following example displays an application service options configuration:

*A:ALA-48>config>app-assure>group>policy>aso# info 
----------------------------------------------
                    characteristic "Server" create
                        value "Block"
                        value "Permit"
                        value "Prioritize"
                        default-value "Block"
                    exit
                    characteristic "ServiceBw" create
                        value "Lite_128k"
                        value "Power_5M"
                        value "Reg_1M"
                        value "SuperUser"
                        default-value "Reg_1M"
                    exit
                    characteristic "Teleworker" create
                        value "No"
                        value "Yes"
                        default-value "No"
                    exit
                    characteristic "VideoBoost" create
                        value "No"
                        value "Priority"
                        default-value "No"
                    exit
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>aso# 

Configuring a policer

Use the following CLI syntax to configure a policer:

config>app-assure>group>policy# policer policer-name type type granularity granularity create
    action {priority-mark | permit-deny}
    adaptation-rule pir adaptation-rule
    description description-string
    mbs maximum burst size
    rate pir-rate 
    tod-override tod-override-id [create]

The following example displays an Application Assurance policer configuration.

*A:ALA-48>config>app-assure>group# policer "RegDown_Policer" type dual-bucket-
bandwidth granularity subscriber create

*A:ALA-48>config>app-assure>group>policer# info 
----------------------------------------------
                description "Control the downstream aggregate bandwidth for Regular 
1Mbps subscribers"
                rate 1000 cir 500
                mbs 100
                cbs 50
----------------------------------------------
*A:ALA-48>config>app-assure>group>policer# 

Configuring an application QoS policy

Use the following CLI syntax to configure an application QoS policy:

config>app-assure>group>policy# app-qos-policy
    entry entry-id [create]
        action
            bandwidth-policer policer-name
            drop
            error-drop [event-log event-log-name]
            flow-count-limit policer-name
            flow-rate-limit policer-name
            fragment-drop {all | out-of-order} [event-log event-log-name]
            http-error-redirect redirect-name
            mirror-source [all-inclusive] mirror-service-id
            overload-drop [event-log event-log-name]
            remark
                dscp in-profile dscp-name out-profile dscp-name
                fc fc-name
                priority priority-level
            url-filter url-filter-name characteristic characteristic-name
        description description-string
        match
            aa-sub sap {eq | neq} sap-id
            aa-sub esm {eq | neq} sub-ident-string
            aa-sub spoke-sdp {eq | neq} sdp-id:vc-id
            app-group {eq | neq} application-group-name
            application {eq | neq} application-name
            characteristic characteristic-name {eq} value-name
            dscp {eq | neq} dscp-name
            dst-ip {eq | neq} ip-address[/mask]
            dst-ip {eq | neq} ip-prefix-list ip-prefix-list-name
            dst-port {eq | neq} port-num
            dst-port {eq | neq} range start-port-num end-port-num
            src-ip {eq | neq} ip-address[/mask]
            src-ip {eq | neq} ip-prefix-list ip-prefix-list-name
            src-port {eq | neq} port-num
            src-port {eq | neq} range start-port-num end-port-num
            traffic-direction {subscriber-to-network | network-to-subscriber | both}
        no shutdown

The following example displays an application QoS policy configuration:

*A:ALA-48>config>app-assure>group>policy>aqp# entry 20 create
----------------------------------------------
                        description "Limit downstream bandwidth to Reg_1M subscribers"
                        match
                            traffic-direction network-to-subscriber
                            characteristic "ServiceBw" eq "Reg_1M"
                        exit
                        action
                            bandwidth-policer "RegDown_Policer"
                        exit
                        no shutdown
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>aqp# 

The following example displays an AQP entry configuration to mirror all positively identified only P2P traffic (AppGroup P2P) for a subset of subscribers with ASO characteristic aa-sub-mirror enabled:

A:ALA-48>config>app-assure>group>policy>aqp# 
-------------------------------------------------------------------------------
   entry 100 create
    match
      app-group eq P2P
      characteristic aa-sub-mirror eq enabled
    exit
    action                   # mirror to an existing mirror service id
      mirror-source 100
    exit
   no shutdown
   exit
-------------------------------------------------------------------------------
A:ALA-48>config>app-assure>group>policy>aqp#

The following example displays an AQP entry to mirror all P2P traffic (all positively identified P2P traffic and any unidentified traffic that may or may not be P2P - AppGroup P2P) for a subset of subscribers with ASO characteristic aa-sub-mirror enabled (the order is significant).

A:ALA-48>config>app-assure>group>policy>aqp>entry#
-------------------------------------------------------------------------------
  entry 100 create
    match
      app-group eq P2P
      characteristic aa-sub-mirror value enabled
    exit
    action
      mirror-source all-inclusive 100
    exit
   no shutdown 
   exit
-------------------------------------------------------------------------------
A:ALA-48>config>app-assure>group>policy>aqp#

Configuring a charging filter

Use the following CLI syntax to configure a charging filter:

config>app-assure>group>policy# 
     charging-filter entry <num>
     match
       application eq|neq <app-name>
       app-group eq|neq <app-group-name>
       tethered-flow
       flow-attribute <name> confidence {eq|lt|gte} <value>

     charging-group <charging-group-name>
     [no] shutdown
     [no] description

For example, the following charging filters match the Whatsapp video and audio traffic, and assign them to different charging groups.

Charging filter configuration (classic CLI)
*A:node-2>config>app-assure>group>policy>chrg-fltr# info
entry 1 create
   description "Charging-filter entry for WhatsApp Video"
   match
     application eq "Whats App"
     flow-attribute "video" confidence gte 100
   exit
   charging-group "cgVideo"
   no shutdown
exit
entry 4 create
   description "Charging-filter entry for WhatsApp Audio Only"
   match
     application eq "Whats App"
     flow-attribute "audio" confidence gte 80
     flow-attribute "video" confidence eq 0
   exit
   charging-group "cgAudio"
   no shutdown
exit

Configuring an application and DNS IP cache for URL content charging strengthening

In the context of URL content charging, also known as zero rating, the DNS IP cache (dns-ip-cache command) feature ensures that only legitimate traffic is classified in an application and charging-group. Subscribers’ DNS responses matching a list of domain names used for content charging populate the DNS IP cache. The system can then be configured to create app-filters matching HTTP or HTTPS expressions as well as the IP cache ensuring that traffic is properly classified. If the operator uses proxies in their network, they may also configure a maximum of 8 IP addresses which match the IP addresses of the proxies used. Traffic whose destination IP address matches one of the configured proxies is assumed to be legitimate traffic.

To configure the system for URL content charging strengthening with a dns-ip-cache the operator needs to:

  • Create an application of interest and its related app-filter’s URL expressions. This application is typically mapped into a charging-group.

  • Create a dns-ip-cache. Configure parameters so the IP cache is populated by the domain names from the application mapped to the zero rating charging group and specify which DNS server IP addresses the IP cache listens from.

  • Configure a AQP to enable the dns-ip-cache.

  • Optionally, configure static IP addresses matching the IP addresses of the trusted proxies.

Use the following CLI syntax to create a dns-ip-cache:

config>app-assure>group# 
    dns-ip-cache dns-ip-cache-name [create]
        dns-match
            description <description-string>
            no description
            domain <domain-name> expression <expression>
            no domain <domain-name>
            server-address <server-address> [name <server-name>] 
            no server-address <server-address>
        ip-cache
            size <cache-size>
            high-watermark <percent>
            low-watermark <percent>
            [no] static-address <static-ip-address>
        [no] shutdown 

The following example displays a configuration for a dns-ip-cache configured to snoop DNS responses for two different domains ‟*.domain1.com” and ‟*domain2.com” which are zero rated or charged specifically by the operator. The configuration only uses DNS responses from the DNS server addresses configured within the dns-match to populate the ip-cache:

7750>config>app-assure>group# info
----------------------------------------------
dns-ip-cache "dns-ip-cache1" create
                description "DNS IP Cache #1"
                dns-match
                    domain "Sponsor#1-Domain#1" expression "*.domain1.com$"
                    domain "Sponsor#1-Domain#2" expression "*.domain2.com$"
                    server-address 10.8.4.4 name "CompanyName"
                    server-address 10.8.8.8 name "CompanyName"
                    server-address 192.168.100.11 name "OperatorX-DNS1"
                    server-address 192.168.100.12 name "OperatorX-DNS2"
                exit
                ip-cache
                    size 1000
                    high-wmark 90
                    low-wmark 80
                exit
                no shutdown
            exit
----------------------------------------------

The domains configured in the dns-ip-cache must match the app-filter expressions for the applications zero rated or charged specifically by the operator. The following example displays the charging-group Zero Rated and application Sponsor Content #1 configuration:

7750>config>app-assure>group>policy# info 
----------------------------------------------
                charging-group "Zero Rated" create
                    description "Zero Rated Content"
                    export-id 10
                exit
                app-group "Web" create
                exit
                application "Sponsor Content #1" create
                    description "Application#1 - Content Zero Rated"
                    app-group "Web"
                    charging-group "Zero Rated"
                exit
                app-filter
                    entry 100 create
                        expression 1 http-host eq "*.sponsor1-domain1.com$"
                        server-address eq dns-ip-cache "dns-ip-cache1"
                        application "Sponsor Content #1"
                        no shutdown
                    exit
                    entry 110 create
                        expression 1 http-host eq "*.domain2.com$"
                        server-address eq dns-ip-cache "dns-ip-cache1"
                        application "Sponsor Content #1"
                        no shutdown
                    exit
                exit
---------------------------------------------------------------------------

The following example displays the AQP entry to enable the dns-ip-cache to snoop DNS responses; this can be optionally based on ASO characteristics:

A:7750>config>app-assure>group>policy>aqp# entry 100 create 
        match
            characteristic "dns-ip-cache" eq "yes"
        exit
        action
            action dns-ip-cache "dns-ip-cache1"
        exit
        no shutdown

Configuring an HTTP error redirect

Use the following CLI syntax to configure an HTTP error redirect policy:

config>app-assure>group>
    http-error-redirect redirect-name create
    	no http-error-redirect redirect_name
    description description-string
    no description
    error-code error-code [custom-msg-size custom-msg-size]
    no error-code error-code
    http-host http-host // eg. www.demo.barefruit.com
    no http-host
    participant-id participant-id // 32-char string used by template 1 
    no participant-id
    no] shutdown
    template template-id // {1, 2} one for Barefruit, 2= Xerocole
    no template

The following example displays an Application Assurance HTTP redirect configuration:

*A:ALA-48>config>app-assure>group# http-error-redirect "redirect-404" create
        description ‟redirect policy of 404 to Barefruit servers”
        error-code 404
        http-host 
          att.barefruit.com
        participant-id att-ISP
        template 1


*A:ALA-48>config>app-assure>group> http-error-redirect# redirect-404 info   
----------------------------------------------
                description "redirect policy of 404 to Barefruit servers"
                template 1
                http-host "att.barefruit.com"
                participant-id "att-ISP"

                error-code 404 

*A:ALA-48>config>app-assure>group>http-error-redirect#

Configuring HTTP header enrichment

Use the following CLI syntax to configure an AA HTTP header enrichment policy:

config>app-assure>group> http-enrich <http_enrich_name> [create]
    [no] description <description-string>
    [no] shutdown
    [no] field <field_name> name <header_name>
        // Where ‟Field name” can be:
        // subscriber-ip: Header name for subscriber IP
        // subscriber-id: Header name for the subscriber ID
        // static-string: Header name for inserted string
        // static-string-2: Header name for inserted string
        //imsi: Header name for subscriber IMSI
        //imsi-2: Header name for subscriber IMSI
        //msisdn: Header name for subscriber MSISDN
        //imei-sv: Header name for subscriber IMEI-SV
        //rat-type: Radio Access technology
        //pgw_ggsn-address: Header name for Packet Gateway (GGSN or UPF) IP address serving the UE
        //apn: Header name for APN used by the UE
        //user-location: Header name for UE location(ULI)
        //billing-type: Header name for charging type
        //plmn-id: Public land mobile network ID of the SGSN/MME
        //timestamp: Header name for the timestamp (inserted in unix time format. For example: 1531204313)
        //apn-ni: Header name for APN-NI (Network Identifier) used by the UE
        //msisdn-without-cc: Header name for subscriber MSISDN without country code
        //imei-hyphenated: Subscriber's IMEI with format AABBBBBB-CCCCCC-EE
        //imei-hyphenated-2: Subscriber's IMEI with format AABBBBBB-CCCCCC-EE
        //user-location-raw: Header for ULI in raw format <uli-type1>[+<uli-type2>]=<ULI data in hex> 
        //user-location-raw-2: Header for ULI in raw format <uli-type1>[+<uli-type2>]=<ULI data in hex> 
        //user-location-3gpp: ULI encoded as defined in 3GPP TS2.061
        //static-acr: static ACR
        //dynamic-acr: dynamic ACR
        [no] http-enrich <http_enrich_name>

The following example displays an AA HTTP header enrichment configuration:

*A:BNG>config>app-assure>group# http-enrich enrich_example create
*A:BNG>config>app-assure>group>http-enrich$ description "enrich HTTP headers with 
subscriber IP and subscriber ID"
*A:BNG>config>app-assure>group>http-enrich$ field "static-string" name "x-string"
*A:BNG>config>app-assure>group>http-enrich$ field "static-string" static-string 
"orange"
*A:BNG>config>app-assure>group>http-enrich$ field "subscriber-id" name "x-subID"
*A:BNG>config>app-assure>group>http-enrich$ field "subscriber-id" anti-spoof
*A:BNG>config>app-assure>group>http-enrich$ field "subscriber-ip" name x-subIP
*A:BNG>config>app-assure>group>http-enrich$ field "subscriber-ip" encode type md5 key 
"secret10"
----------------------------------------------
*A:BNG>config>app-assure>group>http-enrich$ info
----------------------------------------------
                field "static-string"
                    name "x-string"
                    static-string "orange"
                exit
                field "subscriber-id"
                    name "x-subID"
                    anti-spoof
                exit
                field "subscriber-ip"
                    name "x-subIP"
                    encode type md5 key 
"bF0sZZDNT8DbZoVJHD1vrYr5mJaEggEqWbSvPhgIcPW6hym0sc08O." hash2
                exit
----------------------------------------------
*A:BNG>config>app-assure>group>http-enrich$

In addition, the following show routine displays various HTTP enrichment-related statistics:

show application-assurance group 1 http-enrich "MyTemplate"        
===============================================================================
Application Assurance Group 1 HTTP Enrichment "MyTemplate"
===============================================================================
Description   : (Not Specified)
Admin Status  : Up
AQP Referenced: No
 
-------------------------------------------------------------------------------
Name                             Field                            Enabled
                                                                  Features
-------------------------------------------------------------------------------
subscriber-ip                    MyField                          M
subscriber-id                    Sub-ID                           AC
-------------------------------------------------------------------------------
                                        A=anti-spoof,C=encode-cert,M=encode-md5,R=encode-rc4
 
----------------------------------------------------------------------
Group               Enriched                 Not Enriched
----------------------------------------------------------------------
1                   0                        0
----------------------------------------------------------------------
Total               0                        0
----------------------------------------------------------------------
===============================================================================

Configuring an HTTP redirect policy

Use the following CLI syntax to configure an HTTP redirect policy:

config>app-assure>group# http-redirect redirect-name [create]
        description <description-string>
        no description
        [no] redirect-https
        [no] template <template-id>
        redirect-url URL // redirect URL e.g. www.isp.com/redirect.html
        no redirect-url
        [no] shutdown
        [no] tcp-client-reset
    no http-redirect <redirect-name>

The following example displays an AA HTTP redirect configuration:

*A:ALA-48>config>app-assure>group# http-redirect "redirect1" create
   description ‟redirect policy for blocked http content traffic without url 
parameters”
   template 3
   redirect-url http://www.isp.com/redirect.html
   no shutdown

The following example displays an Application Assurance http-redirect configuration using macro substitution to append url parameters within the redirect url:

*A:ALA-48>config>app-assure>group# http-redirect "redirect2" create
   description "redirect policy for blocked http content traffic with url parameters"
   template 5
   redirect-url "http://www.isp.com/
redirect.html?requestedurl=$URL&subscriberid=$SUB&subscriberip=$IP&routerid=$RTRI
D&vsa=$URLPRM"
   no shutdown

The following example displays AQP entry to block all http gaming traffic (AppGroup BlockedContent) and perform redirect:

A:ALA-48>config>app-assure>group>policy>aqp>entry#
------------------------------------------------------------------------------- 
    entry 100 create
        match
            app-group eq BlockedContent
        exit 
        action
            drop
            http-redirect redirectgaming flow-type dropped-flows
        exit
    no shutdown 
    exit
------------------------------------------------------------------------------- 
A:ALA-48>config>app-assure>group>policy>aqp#

Configuring an HTTPS policy redirect

Use the following CLI syntax to configure an HTTPS redirect policy:

config>app-assure>group# http-redirect redirect-name [create]
        description <description-string>
        no description
        [no] redirect-https 
        redirect-url <redirect-url>
        no redirect-url
        [no] shutdown
        [no] tcp-client-reset
        template <template-id>
        no template
    no http-redirect <redirect-name>

The following example displays the configuration of an HTTPS redirect object to redirect traffic to the operator's portal:

A:ALA-1>config>app-assure>group# http-redirect "https-redirect-portal" create
    description "simple https redirect policy"
    redirect-url https://www.portal.com/info.html
    redirect-https
    no shutdown

After creating the HTTP Redirect object, an AQP is used to configure the traffic to be redirected:

A:ALA-1>config>app-assure>group>policy>aqp>entry#
--------------------------------------------------------------
   entry 100 create
      match
         application eq BlockedHTTPS_page
      exit
      action
         drop
         http-redirect https-redirect-portal flow-type dropped-flows
      exit
   no shutdown
   exit
--------------------------------------------------------------

Configuring a captive redirect HTTP redirect policy

The traditional HTTP redirect policy is used to redirect flows on the HTTP response packet, meaning the TCP three-way handshake and the original HTTP request are allowed by the 7750 SR to the Internet before the subscriber is redirected. The captive redirect HTTP redirect policy is used to redirect flows without sending any traffic to the Internet unless it matches a configurable allowlist by terminating TCP sessions in the ISA-AA cards, in which case HTTP flows are redirected to a predefined redirect URL while non-HTTP TCP flows are TCP reset.

Captive redirect and HTTPS flows redirection

The captive redirect HTTP redirect policy can be optionally configured to redirect HTTPS sessions in addition to HTTP to a pre-defined redirect landing page, typically the captive-portal URL in the context of a WiFi network. This capability is particularly useful when the router is used to provide a captive-portal type of access, as it allows the operator to improve the user experience by redirecting the subscriber’s web browser sessions to the needed captive-portal landing page when the user first connects to the network using HTTPS instead of HTTP.

Before the introduction of this feature, users opening their web browsers to an HTTPS URL when first connecting to a new Wi-Fi network and expecting to be redirected to a captive portal were instead presented with an error page automatically generated by the web browser because the session was dropped or reset by the network, therefore ultimately preventing the user from connecting. Most non-technical users connecting to a captive-portal network may not know the difference between HTTP and HTTPS when it comes to login/redirection, and a number of subscribers may not connect or may get frustrated trying multiple different links before a successful Wi-Fi authentication.

When the system is configured for captive-redirect redirect-https, it terminates transport layer security (TLS) TCP sessions in the ISA-AA cards and return a self-signed certificate back to the user. Upon the user acceptance of the security warning generated by the web browser, the web session then automatically redirects to the configured captive-portal landing page.

Captive redirect policy supports redirection for HTTP, HTTPS, HTTP2, SPDY, and TCP Fast Open connections.

A session-filter is used to define the criteria for permitting or redirecting flows using the captive redirect HTTP redirect policy. Typically the operator needs to allow UDP on port 53 for DNS and they can optionally allow other content based on IP address, port number, IP prefix list, or DNS IP cache therefore allowing specific on-net of off-net applications through the captive redirect policy.

To configure the system for captive redirect HTTP redirect the operator needs to:

  • Create an http-redirect policy. If the ISA group aa-sub-scale mode is configured for residential or VPN, then configure the http-redirect policy for captive-redirect and associate the appropriate VLAN ID AA Interface (an aa-interface routable within the subscriber’s service must be created for each ISA-AA card in the system). If the ISA group aa-sub-scale mode is configured for DSM, then there is no need to associate the http-redirect policy to a VLAN ID and no need to create an AA Interface.

  • Create a session filter policy to allow at the minimum UDP on port 53. Additional traffic can be allowlisted based on a statically defined IP prefix list or a dynamic DNS IP cache policy. The redirect landing page should be configured using IP prefixes.

  • The last action of the session filter should be set to http-redirect the remaining flows using a predefined captive redirect HTTP redirect policy.

Use the following CLI syntax to create a captive redirect HTTP redirect policy:

config>app-assure>group# http-redirect <redirect-name> [create]
        captive-redirect
            vlan-id <service-port-vlan-id>
            no vlan-id
        description <description-string>
        no description
        [no] redirect-https
        redirect-url <redirect-url>
        no redirect-url
        [no] shutdown
        [no] tcp-client-reset
        template <template-id> 
        no template
    no http-redirect <redirect-name>

The following example displays a typical configuration for a session filter user in the context of captive redirect:

A:7750# configure application-assurance group 1:1 create 
A:7750>config>app-assure>group# info 
----------------------------------------------
            session-filter "wifi-unauthenticated" create
                default-action deny
                entry 5 create
                    match
                        ip-protocol-num udp
                        dst-port eq 53
                    exit
                    action permit
                exit
                entry 10 create
                    match
                        dst-ip dns-ip-cache "whitelist"
                    exit
                    action permit
                exit
                entry 15 create
                    description "Allow traffic to the redirect landing page server"
                    match
                        ip-protocol-num tcp
                        dst-port eq 80
                        dst-ip 172.16.70.100/32
                    exit
                    action permit
                exit
                entry 20 create
                    match
                        ip-protocol-num tcp
                    exit
                    action http-redirect "redirect-portal"
                exit
            exit
----------------------------------------------

The following example displays a typical configuration for the AA interface used by the captive redirect HTTPS redirect policy for ESM Subscribers (DSM does not require the configuration of the AA Interface):

A:7750# configure service ies 1 customer 1 create 
A:7750>config>service>ies# info 
----------------------------------------------
            aa-interface "aa-if-captive-redirect-isa_1-2" create
                description "AA Interface for ISA-AA card 1/2"
                address 172.16.3.1/31
                sap 1/2/aa-svc:20 create
                    no shutdown
                exit
                no shutdown
            exit
----------------------------------------------

The following example displays a typical configuration for the HTTPS redirect policy for ESM Subscribers (DSM does not require the configuration of the VLAN ID):

A:7750# configure application-assurance group 1 
A:7750>config>app-assure>group>http-redir# info 
----------------------------------------------
                template 5
                tcp-client-reset
                redirect-https
                redirect-url "http://172.16.70.100/Redirect/redirect-
portal.html?RequestedURL=$URL"
                captive-redirect
                    vlan-id 20
          exit
                no shutdown
----------------------------------------------

Configuring ICAP URL filtering

To configure the system for ICAP URL filtering, the operator needs to:

  • Create an AA interface and assign an IP address to each AA ISA within an IES or VPRN service. This routed interface is then used by the system to establish TCP communication with the ICAP server.

  • Create an HTTP redirect policy (used by the URL filter to redirect HTTP or HTTPS traffic).

  • Create a URL filter, configure the ICAP server IP address, redirect policy, and default action.

  • Verify that the AA interface and URL filter are operationally up.

Use the following CLI syntax to configure the AA interface for each AA ISA:

config>service>vprn# aa-interface <aa-if-name> [create]
    config>service>vprn>aa-if# aa-interface interface <ip-int-name> [create]
    description <description-string>
    no description
    address <ipv4_subnet/31>
    no address
        sap <card/mda/aa-svc:vlan> [create]
            description <description-string>
            no description
            egress
                [no] filter
                [no] qos
            exit
            ingress
                [no] qos
            exit
            [no] shutdown
        exit

The following example displays an AA interface created for the ISA card 1/2 using IP address 172.16.2.1/31:

A:7750>config>service>ies# info 
----------------------------------------------
            aa-interface "aa-if1" create
                address 172.16.2.1/31
                sap 1/2/aa-svc:10 create
                    egress
                        filter ip 10
                    exit
                    no shutdown
                exit
                no shutdown
            exit

In the example above, 172.16.2.1 is used by the IOM side of the interface while the ISA itself is automatically assigned 172.16.2.0 based on the /31 subnet.

Consider the following recommendations:

  • More than one AA interface can be configured for each AA ISA card, however, the operator must use the same service VLAN across all these interfaces for a URL filter object.

  • Configure an egress IP filter under the SAP toward the ISA AA interface to only allow selected IP addresses or subnets (for example, ICAP servers or network management).

Use the following CLI syntax to configure the URL filter:

config>app-assure>group#
    url-filter <url-filter-name> [create]
        default-action {allow | block-all | block-http-redirect <redirect-name>}
        no default-action
        http-redirect <http-redirect-name>
        no http-redirect
        http-request-filtering {all | first}
        no apply-function-specific-behavior
        icap
            custom-x-header <x-header-name>
            [no] custom-x-header
            vlan-id <service-port-vlan-id>
            no vlan-id
            default-action {allow | block-all | block-http-redirect <redirect-name>}
            no default-action
            http-redirect <http-redirect-name>no http-redirect
            server <ip-address[:port]> [create]
                description <description-string>
                no description
                [no] shutdown
            no server <ip-address[:port]>
    no url-filter <url-filter-name>

If the apply-function-specific-behavior command is enabled, the operator may configure an ICAP-specific default-action and redirect. This is done by configuring default-action and http-redirect in config>app-assure>group>url-filter>icap context.

The following example displays a URL filter configuration:

*A:7750>config>app-assure>group# url-filter "filter1" create
   apply-function-specific-behavior
   icap
      vlan-id 10
      default-action block-http-redirect "http-redirect-portal"
      server 172.16.1.101 create
        no shutdown
      exit
   exit
   no shutdown

Enabling the apply-function-specific-behavior command allows the operator to configure a default-action and HTTP redirect which are specific to ICAP URL filtering only. Alternatively, the operator configures the same default-action and http-redirect for all url-filter functions by disabling the apply-function-specific-behavior and configuring a default-action and http-redirect in the config>app-assure>group>url-filter context.

The following example displays an AQP entry to enable ICAP URL filtering for opted-in subscribers based on ASO characteristics:

A:7750>config>app-assure>group>policy>aqp# entry 100 create 
        match
            characteristic "url-filter" eq "yes"
        exit
        action
            url-filter "filter1"
        exit
        no shutdown

Optionally, the operator can add a custom x-header to the ICAP request in order for the ICAP server to filter traffic based on this new x-header value instead of filtering based on subscriber names. This is done by defining a new ASO characteristic for the different ICAP filtering service packages used in the network and referring the characteristic name in the URL filter AQP action.

The following example displays a URL filter configuration with the custom-x-header field added to the ICAP request:

A:7750>config>app-assure>group# url-filter "filter1" create
  apply-function-specific-behavior
  icap
    default-action block-http-redirect "http-redirect-portal"
    http-redirect "http-redirect-portal"
    custom-x-header "Filtering-Policy"
    vlan-id 10
    server 172.16.1.101 create
      no shutdown
    exit
  exit
  no shutdown

The following example displays the ASO characteristic used to define the type of filtering policy available:

A:7750>config>app-assure>group>policy>aso# info 
----------------------------------------------
                    characteristic "url-filter-policy" create
                        value "filtering-policy-1"  #less than 10 years old
                        value "filtering-policy-2"  # less than 16 years old
                        value "example1"
                        value "none"
                        value "example2"
                        default-value "none"
                    exit
----------------------------------------------

The following example displays the AQP action required to add the appropriate ASO value to the ICAP custom-x-header field:

A:7750>config>app-assure>group>policy>aqp# entry 100 create
        match
            characteristic "url-filter" eq "yes"
        exit
        action
            url-filter "filter1" characteristic "url-filter-policy"
        exit
        no shutdown

Configuring web-service URL classification

The following example describes how to configure web-service URL classification.
  1. Configure the shared resources to be used for the cache.

    In the following example configuration, 100% of shared resources are allocated to web-service URL classification:

    config>isa>aa-grp>shr-res-pool# info detail
        ----------------------------------------------
                    web-service-url-filter 100
        ----------------------------------------------
    
  2. Configure the HTTP redirect policy.

    Traffic that belongs to one of the blocked categories (as defined in the profile activated for the user), is redirected.

    The operator can append the category name and category ID to the redirect URL (that is, the category that resulted in the redirect action).

    The following example displays an HTTP redirect policy configuration:

    config>app-assure>group 1
        ----------------------------------------------
        http-redirect "redirect-ws-filter" create
            description "Redirect for Web Service URL Filtering"
            template 5
            tcp-client-reset
            redirect-https
            redirect-url "http://10.154.90.1/
        redirect.html?catname=$CATNAME&catid=$CATID"
            no shutdown
        exit
        ---------------------------------------------
    
  3. Configure the URL filter and category profiles.

    The operator defines a new URL filter with the following attributes:

    • classifier = "web-service-1"

      defines the URL categorization database to use

    • category-set-id = 1

      defines the URL categories to use

    • fqdn = nokia-api.webtitancloud.com

      defines the URL categorization database endpoint that the AA connects to

    • dns-server

      defines the DNS server to resolve the FQDN

    • profile

      defines up to eight profile names

    • category

      defines the category to be blocked in the configured profile

    In the following URL filter configuration example, the three profiles defined in Example URL category profile of the Web-service URL classification section are configured. Two classification-overrides entries are also configured:

    configure application-assurance group 1 url-filter "ws-filter" 
        config>app-assure>group>url-filter# info
        ----------------------------------------------
            apply-function-specific-behavior
            web-service
                classifier web-service-1 category-set-id 1
                vlan-id 100
                default-action block-http-redirect "redirect-ws-filter"
                http-redirect "redirect-ws-filter"
                fqdn nokia-api.webtitancloud.com
                dns-server 8.8.8.8
                classification-overrides
                entry 1 expression www.site1.abc category "Phishing/Fraud"
                entry 2 expression www.site2.def category "Illegal Drugs"
                profile low create
                    category "Internet Watch Foundation List" block
                    category "Spyware And Malicious Sites" block
                    category "Phishing/Fraud" block
                profile medium create
                    category "Internet Watch Foundation List" block
                    category "Spyware And Malicious Sites" block
                    category "Phishing/Fraud" block
                    category "Illegal Drugs" block
                    category "Violence" block
                    category "Weapons" block
                profile high create
                    category "Internet Watch Foundation List" block
                    category "Spyware And Malicious Sites" block
                    category "Phishing/Fraud" block
                    category "Illegal Drugs" block
                    category "Violence" block
                    category "Weapons" block
                    category "Nudity" block
                    category "Alcohol" block
                    category "Criminal Skills/Hacking" block
                    category "Hate Speech" block
                default-category-profile "low"
            no shutdown
            ----------------------------------------------
    

    Enabling apply-function-specific-behavior allows the operator to configure a default-action and http-redirect which are specific to web-service URL Classification only. Alternatively, the operator may configure the same default-action and http-redirect for all url-filter functions by disabling the apply-function-specific behavior (which is the default) and configuring a default-action and http-redirect in the config>app-assure>group>url-filter.

  4. Configure the ASO.

    The ASO is used to dynamically allocate a profile to a user.

    The following output displays the configuration of an example ASO:

    config>app-assure>group>policy>aso# info
        ----------------------------------------------
            characteristic "url-filter-policy" create
                value "high" 
                value "medium" 
                value "low" 
                default-value "low"
            exit
        ----------------------------------------------
    
  5. Configure the AQP.

    The AQP is used to execute the URL filter policy. The URL filter uses the ASO value that is active for the user to select the category profile.

    In the AQP defined in the following example, there is no match condition. Therefore, the web-service URL classification is applied to all subscribers:

    config>app-assure>group>policy>aqp# entry 100 create
        action
            url-filter "ws-filter" characteristic "url-filter-policy"
        exit
        no shutdown
    

Configuring local URL-list filtering

To configure the system for local URL-list filtering, the operator needs to:

  • Create a URL-list policy referencing a valid file located on the compact flash.

  • Create a url-filter policy for local-filtering by referencing this URL-list.

  • Create an AQP to apply this url-filter policy.

Use the following CLI syntax to create a URL-list:

config>app-assure>group# url-list <url-list-name> [create]
    description <description-string>
    no description
    decrypt-key <key | hash-key | hash2-key> [hash | hash2 |custom]
    no decrypt-key
    file <file-url> 
    no file
    [no] shutdown
    size <url-list-size>
    [no] expression-match
    [standard | extended] - Default : standard

Wildcards are supported on hostname entries. To enable wildcard support, the url-list must have expression-match (in config>app-assure-group>url-list) enabled (the default is disabled). An entry may contain the following:

  • head anchors character set [^ *]

  • tail anchors character set [$ *]

  • mid expression character set [\d \I \. \**]

  • hex escape characters [\x00-\xFF]

The same capabilities with those described in Application Filters section are provided.

When expression-match is set to enabled, the list should contain hostnames only, with wildcards.

The decryption key is optional. If the decryption key is not specified, the system assumes that the file is not encrypted. To encrypt a file in Linux using the supported encryption format, use the following command:

Linux# openssl des3 -nosalt -in <input-file.txt> -out <output.enc>

The following example displays a URL list configuration:

A:7750>config>app-assure>group# url-list url-list1 create
----------------------------------------------
                description "Local List for URL Filtering"
                decrypt-key ".i84/P1uS0lMGoQkae7mAV2Oj10n726Z" hash2
                file "cf3:\url-list1.enc"
                no shutdown
----------------------------------------------

Use the following CLI syntax to create a url-filter policy for local-filtering:

config>app-assure>group# url-filter <url-filter-name> [create]
    url-filter <url-filter-name> [create]
    description <description-string>
    no description
    default-action {allow | block-all | block-http-redirect <redirect-name>}
    no default-action
    [no] http-redirect <redirect-name>
    http-request-filtering {all | first}
    [no] apply-function-specific-behavior
    local-filtering 
        deny-list <url-list-name>
            default-action {allow | block-all | block-http-redirect <redirect-name>}
            no default-action
            [no] http-redirect <redirect-name>
        [no] allow-list <url-list-name>
    [no] shutdown

The following example displays a deny-list URL filter configured for local-filtering:

A:7750>config>app-assure>group# url-filter "url-denylist1" create
A:7750>config>app-assure>group>url-filter# info
----------------------------------------------
apply-function-specific-behavior
local-filtering
  default-action allow
  http-redirect "http-redirect-portal"
  deny-list "url-list1"
exit
no shutdown
----------------------------------------------

The default action should always be configured to ‟allow” when the url-filter is configured for local-filtering. The default-action in this context represents the action the system takes in case the local-list file is not accessible; this scenario may happen if the source file was corrupted or if the compact flash card was not accessible.

The following example displays the AQP entry to enable ICAP url-filtering for opted-in subscribers based on ASO characteristics:

A:7750>config>app-assure>group>policy>aqp# entry 100 create 
        match
            characteristic "child-protection" eq "yes"
        exit
        action
            url-filter "url-blacklist1"
        exit
        no shutdown

Configuring HTTP notification

Use the following CLI syntax to configure an HTTP Notification policy:

config>app-assure>group#
    http-notification <http-notification-name> [create]
        description <description-string>
        no description
        script-url <script-url-name>	
        no script-url
        interval {one-time | <minimum-interval>}
        template <template-id>
        no template
        [no] shutdown
    no http-notification <http-notification-name>

The following example displays an HTTP notification policy configured with a minimum interval of 5 minutes:

A:7750>config>app-assure>group# http-notification "in-browser-notification" create 
A:7750>config>app-assure>group>http-notif# info 
----------------------------------------------
                description "In Browser Notification Example"
                template 1
                script-url "http://10.1.1.1/In-Browser-Notification/script.js"
                interval 5
                no shutdown
----------------------------------------------

The operator then needs to enable the http-match-all-req feature for any HTTP request sent the messaging server domain which is used to monitor HTTP notification success/failures. This is done by creating a new application and enabling http-match-all-req within the app-filter.

A:7750>config>app-assure>group>policy# application "IBN Messaging Server" create
A:7750>config>app-assure>group>policy>app$ app-group "Web"

A:7750>config>app-assure>group>policy# app-filter entry 100 create
A:7750>config>app-assure>group>policy>app-filter>entry$ info
----------------------------------------------
                        expression 1 http-host eq "^10.1.1.1$"
                        http-match-all-req
                        application "IBN Messaging Server"
                        no shutdown
----------------------------------------------

The following example displays the AQP entry required to match this policy based on an ASO characteristic:

A:7750>config>app-assure>group>policy>aqp# info 
----------------------------------------------
                    entry 200 create
                        match
                            characteristic "in-browser-notification" eq "yes"
                        exit
                        action
                            http-notification "in-browser-notification"
                        exit
                        no shutdown
                    exit
----------------------------------------------

Configuring tethering detection

To configure tethering detection, enable the tethering detection option and specify the tethering state of the subscriber for which the specified application QoS policy match entry is applied.

Use the following CLI syntax to configure tethering detection:

configure application-assurance group group-number tethering-detection no shutdown

Use the following CLI syntax to specify the tethering state of the subscriber:

configure application-assurance group group-number policy
        begin
            app-qos-policy entry match aa-sub-tethering-state {detected | not-detected}
        commit
    exit

Configuring AA volume accounting and statistics

A network operator can configure AA volume statistic collection and accounting on both AA ISA system and subscriber levels.

The following commands illustrate the configuration of statistics collection and accounting policy on an AA group/partition aggregate level (without subscriber context).

CLI syntax:

config>app-assure>group>statistics>app-group
    accounting-policy act-policy-id
    collect-stats

CLI syntax:

config>app-assure>group>statistics>application
    accounting-policy act-policy-id
    collect-stats

CLI syntax:

config>app-assure>group>statistics>protocol
    accounting-policy act-policy-id
    collect-stats

The following commands illustrate the configuration of statistics collection and accounting policy for each AA subscriber in the system:

config>app-assure>group>statistics>aa-sub
    accounting-policy acct-policy-id
    aggregate-stats
    app-group app-group-name export-using export-method [export-method]
    application application-name export-using export-method [export-method]
    charging-group charging-group-name export-using export-method [export-method]
    collect-stats
    exclude-tcp-retrans
    max-throughput-stats
    protocol protocol-name export-using export-method
    radius-accounting-policy rad-acct-plcy-name

The following commands illustrate configuration of special study mode for a subset of AA subscribers (configured) to collect all protocol or application statistics with an AA subscriber context:

config>app-assure>group>statistics# aa-sub-study {application | protocol}
    accounting-policy acct-policy-id
    collect-stats

For details on accounting policy configuration (including among others AA record type selection and customized AA subscriber record configuration), see the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.

The following output illustrates per AA-subscriber statistics configuration that elects statistic collection for a small subset of all application groups, applications, protocols:

*A:ALU-40>config>app-assure>group>statistics>aa-sub# info 
----------------------------------------------
                    accounting-policy 4
                    collect-stats
                    app-group "File Transfer"
                    app-group "Infrastructure"
                    app-group "Instant Messaging"
                    app-group "Local Content"
                    app-group "Mail"
                    app-group "MultiMedia"
                    app-group "Business_Critical
                    app-group "Peer to Peer"
                    app-group "Premium Partner"
                    app-group "Remote Connectivity"
                    app-group "Tunneling"
                    app-group "Unknown"
                    app-group "VoIP" 
                    app-group "Web"
                    app-group "Intranet"
                    application "BitTorrent"
                    application "eLearning"
                    application "GRE"
                    application "H323"
                    application "TLS"
                    application "HTTP"
                    application "HTTPS"
                    application "HTTPS_Server"
                    application "HTTP_Audio"
                    application "HTTP_Video"
                    application "eMail_Business"
                    application "eMail_Other"
                    application "Oracle"
                    application "Skype"
                    application "SAP"
                    application "SIP"
                    application "SMTP"
                    application "SQL_Alltypes"
                    application "TFTP"
                    protocol "bittorrent"
                    protocol "dns"
                    protocol "sap"
                    protocol "skype"
----------------------------------------------
*A:ALU-40>config>app-assure>group>statistics>aa-sub#

Configuring cflowd collector

The following output displays an AA cflowd collector configuration example:

*A:ALA-48# configure application-assurance group 1 cflowd collector 192.168.131.149:55000 create
    *A:ALA-48>config>app-assure>group>cflowd>collector$description
    "cflowd_collector_NewYork"
    *A:ALA-48>config>app-assure>group>cflowd>collector# no shutdown
    *A:ALA-48>config>app-assure>group>cflowd>collector# exit

The following output displays the configuration of the newly created example AA cflowd collector:

*A:ALA-48>config>app-assure>group>cflowd# info
----------------------------------------------
    collector 192.168.131.149:55000 create
         description "cflowd_collector_NewYork"
    no shutdown
---------------------------------------------- 
*A:ALA-48>config>app-assure>group>cflowd# 

Use the following CLI syntax to configure an AA cflowd collector:

config>application-assurance>group isa-aa-group-id cflowd
        collector <ip-address[:port]> [create]
        no collector <ip-address[:port]>
            [no] description - Configure description for this cflowd collector
            [no] shutdown - Administratively enable/disable this cflowd collector
        direct-export 
            collector <collector-id> [create]
            no collector <collector-id>
                [no] address + Configure cflowd direct export collector remote address
                [no] description - Configure description for this cflowd direct export

The following output displays an AA direct export cflowd collector configuration example:

*A:Dut-C>config>app-assure>group>cflowd# direct-export vlan-id 300 
*A:Dut-C>config>app-assure>group>cflowd# direct-export collector 1 create
*A:Dut-C>config>app-assure>group>cflowd>dir-exp-coll$ description "direct export to collector in Toronto/CA"
*A:Dut-C>config>app-assure>group>cflowd>dir-exp-coll$ address 10.10.1.1:55000
*A:Dut-C>config>app-assure>group>cflowd>dir-exp-coll>addr$ no shutdown
*A:Dut-C>config>app-assure>group>cflowd>dir-exp-coll>addr$ exit
*A:Dut-C>config>app-assure>group>cflowd>dir-exp-coll$ exit
*A:Dut-C>config>app-assure>group>cflowd# no shutdown
*A:Dut-C>config>app-assure>group>cflowd# info
----------------------------------------------
                no shutdown
                direct-export
                    vlan-id 300
                    collector 1 create
                        address 10.10.1.1:55000
                            no shutdown
                        exit
                        description "direct export to collector in Toronto/CA"
                    exit
                exit
----------------------------------------------
*A:Dut-C>config>app-assure>group>cflowd#
Note: The VLAN-ID must match the one configured under the AA ISA interface. For an example of how to configure an AA interface, see Configuring ICAP URL filtering.

Configuring AA comprehensive, RTP performance, TCP performance, and volume reporting

The following commands show the configuration of AA comprehensive reporting:

config>application-assurance>group isa-aa-group-id cflowd comprehensive
        [no] flow-rate - Configure cflowd comprehensive flow sample rate
        [no] flow-rate2 - Configure secondary cflowd comprehensive flow sample rate
        [no] shutdown - Administratively enable/disable comprehensive sampling
              template + Configure comprehensive template|   
                [no] dynamic-fields + Configure the list of dynamic fields
                    [no] field <field-name> - Configure a dynamic field
                    [no] shutdown - Administratively enable/disable comprehensive template
                  [no] field-selection <field-selection>        Configure the field selection : legacy|dynamic

The following commands show the configuration of AA RTP performance reporting:

config>application-assurance>group isa-aa-group-id cflowd rtp-performance
        [no] flow-rate - Configure cflowd RTP performance flow sample rate
        [no] flow-rate2 - Configure secondary cflowd RTP performance flow sample  rate
        [no] shutdown - Administratively enable/disable RTP performance sampling
    
           audio-template + Configure rtp performance audio fields template
                [no] dynamic-fields + Configure the list of dynamic fields
                    [no] field <field-name> - Configure a dynamic field
                    [no] shutdown - Administratively enable/disable audio template
                [no] field-selection <field-selection>    Configure the field selection : legacy|dynamic
    
           video-template + Configure rtp performance video fields template
                [no] dynamic-fields + Configure the list of dynamic fields
                    [no] field <field-name> - Configure a dynamic field
                    [no] shutdown - Administratively enable/disable video template
                [no] field-selection <field-selection>    Configure the field selection : legacy|dynamic
    
           voice-template + Configure rtp performance voice template
                [no] dynamic-fields + Configure the list of dynamic fields
                    [no] field <field-name> - Configure a dynamic field
                    [no] shutdown - Administratively enable/disable voice template
                [no] field-selection <field-selection>    Configure the field selection : legacy|dynamic

The following commands show the configuration of AA TCP performance reporting:

config>application-assurance>group isa-aa-group-id cflowd tcp-performance
        [no] flow-rate - Configure cflowd TCP performance flow sample rate
        [no] flow-rate2 - Configure secondary cflowd TCP performance flow sample rate 
        [no] shutdown - Administratively enable/disable TCP Performance sampling
           template + Configure tcp performance fields template 
            [no] dynamic-fields + Configure the list of dynamic fields
                [no] field <field-name> - Configure a dynamic field
                [no] shutdown - Administratively enable/disable tcp-performance template
            [no] field-selection <field-selection>    Configure the field selection : legacy|dynamic

The following commands show the configuration of AA volume reporting:

config>application-assurance>group isa-aa-group-id cflowd volume
        [no] rate - Configure cflowd volume sampling rate
        [no] shutdown - Administratively enable/disable volume sampling
          template + Configure volume template
            [no] dynamic-fields + Configure the list of dynamic fields
                [no] field <field-name> - Configure a dynamic field
                [no] shutdown - Administratively enable/disable volume template
            [no] field-selection <field-selection>    Configure the field selection : legacy|dynamic

The following commands show the configuration of AA comprehensive, RTP performance, TCP performance, and volume reporting:

config>application-assurance group isa-aa-group-id[:partition [create]]
    *A:Dut-C>config>app-assure>group>cflowd#
       comprehensive + Configure cflowd comprehensive export
        [no] app-group app-group-name [flow-rate | flow-rate2]
        [no] application application-name [flow-rate | flowrate2]
        [no] shutdown - Administratively enable/disable comprehensive sampling
          
       rtp-performance + Configure cflowd RTP performance export
        [no] app-group app-group-name [flow-rate | flow-rate2]
        [no] application application-name [flow-rate | flowrate2]
        [no] shutdown - Administratively enable/disable RTP performance sampling                      
    
       tcp-performance + Configure cflowd TCP performance export
        [no] app-group app-group-name [flow-rate | flow-rate2]
        [no] application application-name [flow-rate | flowrate2]
        [no] shutdown - Administratively enable/disable TCP performance sampling
    
       volume + Configure cflowd volume export
        [no] shutdown - Administratively enable/disable volume sampling

The following example shows a configuration that includes the following:

  • Enables per-flow volume statistics for group 1, partition 1 and configures sampling rate to 1/1000.

  • Enables per-flow TCP performance statistics for web_traffic application within group 1, partition 1 and configures TCP sampling rate to 1/500.

  • Enables per-flow TCP performance statistics for citrix_traffic application within group 1, partition 1 using TCP sampling rate2 to 1/100.

  • Enables per-flow RTP A/V performance statistics for voip_traffic application within group 1, partition 1 and configures RTP sampling rate to 1/10.

  • Enables per-flow comprehensive statistics for web_traffic.

Example:

*A:ALA-4# configure application-assurance group 1 cflowd
*A:ALA-4>config>app-assure>group>cflowd# volume rate 1000
*A:ALA-4>config>app-assure>group>cflowd# tcp-performance flow-rate 500
*A:ALA-4>config>app-assure>group>cflowd# tcp-performance flow-rate2 100
*A:ALA-4>config>app-assure>group>cflowd# comprehensive flow-rate 5
*A:ALA-4>config>app-assure>group>cflowd# rtp-performance flow-rate 10
*A:ALA-4>config>app-assure>group>cflowd# comprehensive flow-rate 5
*A:ALA-4>config>app-assure>group>cflowd# no shutdown
*A:Dut-C>config>app-assure>group>cflowd# info
----------------------------------------------
                shutdown
                direct-export
                    vlan-id 300
                    collector 1 create
                        address 10.10.1.1:55000
                            shutdown
                        exit
                        description "direct export to collector in Toronto/CA"
                    exit
                exit
                volume
                    rate 1000
                exit
                rtp-performance
                    flow-rate 10
                    flow-rate2 5
                exit
                tcp-performance
                    flow-rate 500
                    flow-rate2 100
                exit
----------------------------------------------
*A:Dut-C>config>app-assure>group>cflowd#

----------------------------------------------
*A:ALA-48>config>app-assure>group>cflowd#
*A:ALA-4# configure application-assurance group 1:1 cflowd
*A:ALA-4>config>app-assure>group>cflowd#
*A:ALA-4>config>app-assure>group>cflowd# volume no shutdown
*A:ALA-4>config>app-assure>group>cflowd# tcp-performance application "web_traffic"
*A:ALA-4>config>app-assure>group>cflowd# tcp-performance application "citrix" flow-rate2
*A:ALA-4>config>app-assure>group>cflowd# tcp-performance no shutdown
*A:ALA-4>config>app-assure>group>cflowd# rtp-performance application "voip_traffic"
*A:ALA-4>config>app-assure>group>cflowd# rtp-performance no shutdown
*A:ALA-4>config>app-assure>group>cflowd# info
----------------------------------------------

----------------------------------------------
volume
    no shutdown 
exit
rtp-performance 
    no shutdown
       application "voip_traffic"
exit
tcp-performance
    no shutdown
       application "web_traffic"
       application "citrix" flow-rate2
exit
----------------------------------------------
*A:ALA-4>config>app-assure>group>cflowd#

Because no template selection is made in the above example for any of the configured cflowd templates (volume, RTP/TCP performance), the legacy template is used.

Alternatively, if the operator wants to have specific fields within, for example, volume templates, then the dynamic option must be selected under:

config>application-assurance>group isa-aa-group-id cflowd volume
        template + Configure volume template
            [no] dynamic-fields + Configure the list of dynamic fields
            [no] field-selection <field-selection> Configure the field selection : legacy|dynamic

The following example displays a volume template configured to use dynamic field selection:

*A:Dut-C>config>app-assure>group>cflowd>volume# template
*A:Dut-C>config>app-assure>group>cflowd>volume>template# field-selection dynamic
*A:Dut-C>config>app-assure>group>cflowd>volume>template# dynamic-fields
*A:Dut-C>config>app-assure>group>cflowd>volume>template>dynamic-fields# field "hostName"
*A:Dut-C>config>app-assure>group>cflowd>volume>template>dynamic-fields# field "aaApp"
*A:Dut-C>config>app-assure>group>cflowd>volume>template>dynamic-fields# field"aaAppGrp"
*A:Dut-C>config>app-assure>group>cflowd>volume>template>dynamic-fields# exit    
*A:Dut-C>config>app-assure>group>cflowd>volume>template# info
----------------------------------------------
                        field-selection dynamic
                        dynamic-fields
                            shutdown
                            field "aaApp"
                            field "aaAppGrp"
                            field "hostName"
                        exit
----------------------------------------------
*A:Dut-C>config>app-assure>group>cflowd>volume>template#