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

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. ADC utilizes the Enhanced Charging Service (ECS) functionality. For information about ECS, refer to the Enhanced Charging Services Administration Guide.

The ADC in-line service works in conjuction with the following products:
  • GGSN
  • IPSG
  • PDSN
  • P-GW

Detecting P2P protocols requires recognizing, in real time, some uniquely identifying characteristic of the protocols. Typical packet classification only requires information uniquely typed in the packet header of packets of the stream(s) running the particular protocol to be identified. In fact, many P2P protocols can be detected by simple packet header inspection. However, some P2P protocols are different, preventing detection in the traditional manner. This is designed into some P2P protocols to purposely avoid detection. The creators of these protocols purposely do not publish specifications. A small class of P2P protocols is stealthier and more challenging to detect. For some protocols, no set of fixed markers can be identified with confidence as unique to the protocol.

Operators care about P2P traffic because of the behavior of some P2P applications (for example, Bittorrent, Skype, and eDonkey). Most P2P applications can hog the network bandwidth such that 20% ADC users can generate as much traffic as generated by the rest 80% non-ADC users. This can result into a situation where non-ADC users may not get enough network bandwidth for their legitimate use because of excess usage of bandwidth by the ADC users. Network operators need to have dynamic network bandwidth / traffic management functions in place to ensure fair distributions of the network bandwidth among all the users. And this would include identifying P2P traffic in the network and applying appropriate controlling functions to the same (for example, content-based premium billing, QoS modifications, and other similar treatments).

The Application Detection and Control technology makes use of innovative and highly accurate protocol behavioral detection techniques. In order to ensure its effectiveness, the ADC continually supports detection of newer protocols and versions. For more information on the supported protocols and applications, refer to the Peer-to-Peer Protocol and Application Detection Support appendix in this guide.

ADC supports statistics reporting and postpaid charging policies. Per-protocol statistics via bulkstats and via report records including:
  • UDR types: Summarizing data usage for a given content type
  • EDR types: Specific to a particular event
  • e-GCDRs: Specific to 3GPP
Upon detection of a P2P protocol for a particular flow, one of the following actions can be applied:
  • Blocking P2P traffic—blocking protocol(s) and discarding traffic
  • Bandwidth policing—limiting the bandwidth, applied per PDP context per P2P application type
  • Flow policing—limiting the number of simultaneous P2P flows
  • QoS support—including policing
  • TOS marking—applied per P2P protocol type
  • Prepaid and postpaid ADC content-based billing
  • Statistics reporting—analyzing per-protocol statistics using bulkstats

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 Application Detection and Control 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.

P2P Voice Call Duration

The ADC product has the capability to detect network traffic created by P2P VoIP clients such as Skype, Yahoo, MSN, Gtalk, Oscar. The VoIP call duration is a direct indication to the revenue impact of the network operator. The ADC product is well poised to process the network traffic online to detect and control the VoIP presence, and generate records that can be used to calculate the VoIP call durations.

Random Drop Charging Action

The random drop charging action is added as an option to degrade P2P voice calls. This is achieved by randomly dropping packets of the voice calls over the voice call period.

Voice data is encoded in multiple packets by the codec. Since there is a possibility of packets being dropped in a network, the codec replicates the same information across multiple packets. This provides resilience to random packet drops in the network. For a considerable degradable voice quality, a chunk of packets need to be dropped. By this way, the codec will be unable to decode the required voice information. The chunk size for achieving degradation of voice call varies from one protocol to another.

The Random Drop decision has to be made once for a chunk of packets. By choosing the random drop time from a configured range, the drop is achieved at random seconds within a configured range. The packets will drop within a known period of time. For example, if a voice call happens for 2 minutes and if we configure a drop interval of 12–15 seconds, then a packet will be dropped within the first 15 seconds of the voice call.

IMPORTANT:

This feature is applicable only for VOIP calls.

Dynamic Software Upgrade

This section describes the Dynamic Software Upgrade (DSU) process that can be used to incrementally 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 incremental 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 incremental 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 incremental 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 section of the chapter.

How ADC Works

ADC 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 Rel. 7 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 P2P 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. The packets are investigated and then handled appropriately using ruledefs for charging.
Figure 1. Overview of Packet Processing in ECSv2

Advantages of P2P Processing Before DPI

The advantages of P2P processing before DPI:
  • Some protocols like BitTorrent and Orb use HTTP traffic for initial setup. If P2P analysis is done after HTTP, it is possible that these protocols may go undetected.
  • Protocols like Skype use well known ports (like 80 & 443). In these scenarios, the HTTP engine reports these as invalid packets. For protocol detection, it is desirable to have P2P detection before Deep Packet Inspection (DPI).
  • Stateless detection of protocols based on signature will be easier when the P2P analysis is done before DPI.

ADC Session Recovery

Intra-chassis session recovery is coupled with SessMgr recovery procedures.

Intra-chassis session recovery support is achieved by mirroring the SessMgr and AAAMgr processes. The SessMgrs are paired one-to-one with the AAAMgrs. The SessMgr sends checkpointed session information to the AAAMgr. ACS recovery is accomplished using this checkpointed information.

IMPORTANT:

In order for session recovery to work there should be at least four packet processing cards (PSCs/PSC2s), one standby and three active. Per active CPU with active SessMgrs, there is one standby SessMgr, and on the standby CPU, the same number of standby SessMgrs as the active SessMgrs in the active CPU.

There are two modes of session recovery, one from task failure and another on failure of CPU or PSC/PSC2.

Recovery from Task Failure

When a SessMgr failure occurs, recovery is performed using the mirrored “standby-mode” SessMgr task running on the active packet processing card. The “standby-mode” task is renamed, made active, and is then populated using checkpointed session information from the AAAMgr task. A new “standby-mode” SessMgr is created.

Recovery from CPU or PSC/PSC2 Failure

When a packet processing card hardware failure occurs, or when a planned packet processing card migration fails, the standby packet processing card is made active and the “standby-mode” SessMgr and AAAMgr tasks on the newly activated packet processing card perform session recovery.

Limitations

This section lists the limitations of ADC in this release.

BitTorrent

  • Some clients (like Azureus 3.0) provide an advanced user interface which can include an embedded web browser. These are not detected as BitTorrent. Also other features like chat or instant messaging are not detected as BitTorrent. These features are client specific and not related to the BitTorrent protocol.
  • Certain clients also display advertisements. These images are downloaded through plain HTTP and are not detected as BitTorrent.

eDonkey

  • The eDonkey client eMule supports a protocol named Kademlia. This protocol is an implementation of a DHT (Distributed Hash Table). Kademlia is only used for searching new peers which have the file the user wants to download. The download itself uses the eDonkey protocol. However, the Kademlia protocol is not detected as eDonkey.
  • The eDonkey client eMule supports a text chat that is not detected as eDonkey.

FastTrack

SSL packets and HTTP packets from the Kazaa client is not detected. Only data transfer is detected.

Gadu-Gadu

Radio traffic passes through HTTP and is not detected.

Gnutella / Morpheus

  • Some of the clients that use Gnutella protocol for file sharing can also use other file sharing protocols. The part of traffic that follows Gnutella Protocol will only be detected as Gnutella.
  • Client specific patterns which are not part of the Gnutella Protocol will not be detected as Gnutella. UDP contributes to about 20-30 % of most Gnutella clients. Detection is based on some strange patterns in the first packet of these UDP flows. Untested Gnutella clients may have more strange patterns, causing drop in the detection %.
  • The Morpheus Client creates a lot of TCP flows, without any string pattern in the application header. These flows are not currently detected.

Jabber

  • Most clients that use Jabber for IM offer other services like Voice Call or File Transfer. These services are not detected as Jabber.
  • Jabber with SSL encryption cannot be detected, because it uses SSL.

MSN

MSN HTTP downloads such as MSN Games and MSN Applications are not detected. Traffic from these MSN applications use a different protocol for their traffic.

Skype

  • The Skype detection cannot detect traffic of most of the third-party plug-ins. The plug-ins use Skype only for marketing and presentation purposes such as opening a window within a Skype window or modifying the main Skype window with buttons or sounds. These plug-ins do NOT use the Skype protocol to transfer data over the network.
  • Other than Skype Voice, all detected Skype traffic is marked as Skype. Distinctions between different data types within Skype (i.e. text chat, file transfer, and so on) cannot be made.
  • Skype voice detection may not be accurate if it happens with other traffic (file transfer, video, etc.) on the same flow.

Winny

The Winny client also supports bbs. This is currently not detected.

Yahoo

Yahoo! HTTP downloads for yahoo games, images and ads that come during yahoo messenger startup are not detected as Yahoo!. If configured, these can be passed on to the HTTP analyzer for HTTP Deep Packet Inspection.

Other Limitations

  • Most of the heuristic analysis for a subscriber is stateful and depends on building an internal state based on certain patterns seen by the analyzer. Patterns occur over multiple packets in a single flow and over multiple flows for a subscriber. If the system loses the state (due to a task failure for example), then the detection can fail for the affected subscribers/flows after recovery.
    Most P2P protocols emit these patterns regularly (sometimes as early as the next flow created by the application). When the system sees the pattern again, it re-learns the subscriber state and starts detecting the protocol.
  • In this release, P2P rules cannot be combined with UDP and TCP rules in one ruledef.