Application Detection and Control Overview

This chapter provides an overview of the Application Detection and Control (ADC) in-line service, formerly known as Peer-to-Peer Detection.

The System Administration Guide provides basic system configuration information, and the product administration guides provide procedures to configure basic functionality of core network service. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product Administration Guide, before using the procedures in this chapter.

This chapter covers the following topics:

ADC Overview

The ADC in-line service is mainly used to detect Peer-to-Peer protocols by analyzing traffic. Other popular applications that generate the bulk of Internet traffic like Social Networking and Gaming applications can be detected.

The ADC in-line service works in conjunction with the following products:

  • GGSN
  • IPSG
  • PDSN
  • P-GW

The in-line service now known as ADC is continued to be referred as “P2P” in the configuration.

Peer to Peer (P2P) is a term used in two slightly different contexts. At a functional level, it means protocols that interact in a peering manner, in contrast to client-server manner. There is no clear differentiation between the function of one node or another. Any node can function as a client, a server, or both — a protocol may not clearly differentiate between the two. For example, peering exchanges may simultaneously include client and server functionality, sending and receiving information. P2P is a type of transient Internet network that allows a group of computer users with the same networking program to connect with each other and directly access files from one another's hard drives. A common use case of a P2P application is file sharing.

Once the P2P Client is downloaded and installed, it will log on to a central indexing server. This central server indexes all users who are currently online connected to the server. This server does not host any files for downloading. The P2P client can search for a specific file. The utility queries the index server to find other connected users with the specific file. When a match is found, the central server directs to find the requested file. The result is chosen from the search query and the utility will then attempt to establish a connection with the computer hosting the requested file. If a successful connection is made, it will begin downloading the file. Once the file download is complete, the connection will be broken.

The stunning growth and intensive bandwidth nature of P2P applications can have a significant impact on the underlying network. As most deployments are designed with a significant bias towards downstream traffic, P2P applications stress uplink capacity resulting in increased latency, decreased responsiveness and packet loss.

To avoid detection, P2P software undergoes frequent changes and this requires service providers to upgrade the software with the latest P2P detection logic. This upgrade is time consuming, also causing disruption in services and revenue loss. The Dynamic Software Upgrade (DSU) addresses these problems by enabling operators to upgrade their detection capabilities with no downtime. The detection logic is separated out from the main code and shipped as a plugin. Whenever there is a need for software upgrade, the new plugin will be shipped and loaded into the system. For more information, refer to the Dynamic Software Upgrade section.

Platform Requirements

The ADC in-line service runs on a Cisco® ASR 5x00 chassis running StarOS. The chassis can be configured with a variety of components to meet specific network deployment requirements. For additional information, refer to the Installation Guide for the chassis and/or contact your Cisco account representative.

License Requirements

The ADC is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

Dynamic Software Upgrade

This section describes the Dynamic Software Upgrade (DSU) process that can be used to dynamically update plugins without having to update StarOS and reload the system.

Overview

Dynamic Software Upgrade is the new approach to upgrade the P2P library version that will enable operators to upgrade their detection capabilities with no downtime. This is done by providing updates in the form of software patches which the operator can apply in a live setup with minimal interference.

In this approach, P2P detection code is now delivered as a plugin within the StarOS binary. The plugin is loaded into the system at run time. Whenever there is a change in P2P detection logic of an existing application or a new P2P protocol/application needs to be added, a new version of the plugin is provided as a plugin module. The new plugin is loaded onto the system dynamically without disrupting other services. Once the plugin has been installed and configured, the new P2P rules come into effect for detection.

IMPORTANT:

The dynamically loaded plugins are not incremental. A plugin loads protocol detection logic for all the protocols/applications. A user can update to a higher priority plugin or rollback to a lower priority plugin.

Patching is the process used to install a plugin as an update to a StarOS release. One patch can be provided to multiple compatible, concurrent product releases. A plugin patch is distributed in the form of a compressed distribution kit through the internet or by other means (USB, CD, etc.).

A plugin is a functional software entity that provides updates to a pre-existing StarOS software component. Plugins can be dynamically loaded at runtime and do not require a system restart.

A plugin module is a specific instance of a plugin version consisting of at least one file that can be added to a running, in-service system. The module contains the information or instructions for a specific component's update. Typically this will be a single plugin file.

The Version Priority List (VPL) is a linked list of module versions associated with a specific plugin. Each plugin has one VPL. The list is sorted in ascending order by the priority number that is assigned by the administrator. When updating, the lowest priority number is loaded first and if that version is not successful, the version in the VPL with the next sequentially greater priority number is loaded. This list is iterated until a successful version is found. The VPL also supports manual rollback to a previous version (higher priority number).

The basic sequence for the dynamic software upgrade process is as follows:
  • Downloading the Patch Kit
  • Unpacking the Patch Kit
  • Configuring the Plugin
  • Loading the Plugin
  • Rolling Back to a Previous Plugin Version

For the detailed procedure on performing dynamic software upgrade, refer to the Configuring Dynamic Software Upgrade section of the Application Detection and Control Configuration chapter.

Limitations for DSU

This section lists the limitations of Dynamic Software Upgrade.

  • Support for session recovery is limited and there is no support for ICSR in this release.
  • The system will allow loading two plugins at the most at any point of time. If there is a need to upgrade the system again, the oldest plugin will be unloaded.
  • Detection state for a few subscribers may be lost if a plugin is unloaded from the memory.
  • The newly upgraded plugin will be used for all new calls. The existing calls will continue to use the previous plugin.

Audio and Video Duration Tracking

The ADC product has the capability to detect network traffic created by audio and video clients such as Skype, Yahoo, MSN, MyPeople, Gtalk, QQ, Oscar, and Viber. The audio/video duration is a direct indication to the revenue impact of the network operator. The ADC in-line service is well poised to process the network traffic online to detect and control the audio/video presence, and generate records that can be used to calculate the audio/video call durations.

Bulk Statistics Support

The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema. ADC uses P2P schema for bulk statistics support.

The P2P schema is designed in such a way that all variables that end with numeral value “name” are used to extract all data with numeral values “value” for all the protocols supported by the currently loaded patch. With the Dynamic Software Upgrade, the operator need not change the P2P schema by adding or removing variables related to a particular protocol manually for each new patch.

The following is a sample configuration of bulk statistics in the P2P schema:

p2p schema p2p format "%p2p-uplnk-bytes-name%:%p2p-uplnk-bytes-value%\n%p2p-dwlnk-bytes-name%:%p2p-dwlnk-bytes-value%\n%p2p-uplnk-pkts-name%:%p2p-uplnk-pkts-value%\n%p2p-dwlnk-pkts-name%:%p2p-dwlnk-pkts-value%\n%p2p-duration-name%:%p2p-duration-value%\n-------------------------------------\n"

IMPORTANT:

If detection of a specific P2P protocol is enabled, bulk statistics for that protocol will be automatically generated based on the plugin installed on the chassis. In the case of protocols that support sub-classification (audio/video/unclassified), the bulk statistics will be dynamically generated for each of the supported sub-classifications per protocol and also the corresponding total count which is the sum of values of the sub-classified data.

For more information, see the P2P Schema chapter of the Statistics and Counters Reference.

How ADC Works

As part of traffic analysis, packets will be first passed through the ADC analyzers when “p2p dynamic-flow-detection” is enabled. If it is not detected as P2P by any of the ADC analyzers, then it will follow the rule matching to find an application analyzer.

ADC analyzers examine uplink and downlink traffic and use rules that define what packet content to take action on and what action to take when the rule is true. The analyzers also generate usage records for the billing system. The rules are configured/defined in the same way as ECS in-line service ruledefs and rulebases.

ADC also interfaces to a PCRF Diameter Gx interface to accept policy ACLs and rulebases from a PDF. ADC supports real-time dynamic policy updates during a subscriber session. This includes modifying the subscriber's policy rules during an active session by means of ACL name and Rulebase name.

In Gx interface, a Charging Rulebase will be treated as a group of ruledefs. A group of ruledefs enables grouping rules into categories, so that charging systems can base the charging policy on the category. When a request contains names of several Charging Rulebases, groups of ruledefs of the corresponding names are activated. For ADC rules to work in the group of ruledefs, P2P detection has to be enabled in the rulebase statically.

Static policy is supported initially. A default subscriber profile is assumed and can be overwritten on the gateway. Per-subscriber static policy is pulled by the gateway from the AAA service at subscriber authentication.

The following figure illustrates how packets travel through the system using ADC. The packets are investigated and then handled appropriately using ruledefs for charging.
Figure 1. Overview of Packet Processing in ECSv2

Limitations

This section lists the limitations for the ADC protocols that support audio and video sub-classification.

If Audio and Video contents are in the same flow (TCP/UDP), video is considered as the predominant component and the flow is marked as “video”. In this scenario, throttling video will block both audio and video. Throttling only audio or video is not possible.