TECHNICAL PRODUCT DESCRIPTION     221 02-CRA 119 1170/1-V1 Uen A    

Application Traffic Management Overview

© Copyright Ericsson AB 2009. All rights reserved.

Disclaimer

No part of this document may be reproduced in any form without the written permission of the copyright owner. The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

SmartEdge is a registered trademark of Telefonaktiebolaget L M Ericsson.
NetOp is a trademark of Telefonaktiebolaget L M Ericsson.

Contents

1Application Traffic Management
1.1Application Bandwidth Management
1.2Protocol Detection

2

Traffic Analysis
2.1Shallow Packet Inspection
2.2Deep Packet Inspection
2.3Heuristic Analysis

3

Traffic Classification

4

Statistics Collection
4.1Subscriber Statistics
4.2Log Format

5

Quality of Service Management

6

Operations and Management

Glossary

Reference List


1   Application Traffic Management

Broadband service providers are increasingly challenged by the growth of bandwidth-intensive applications and the inability to generate revenue from the bandwidth used. Some of the key issues associated with these bandwidth-intensive technologies are:

A significant portion of application traffic consists of file downloads of multimedia content that is often hundreds of megabytes in size. With these large file downloads, the traditional patterns of on and off periods of activity are replaced with constant traffic patterns. These new traffic patterns can create congestion on network links and make it difficult for operators to perform effective capacity planning.

In addition to illegal file-sharing, the amount of content provided directly by legal content providers is increasing; therefore, it is not an option to block all application traffic.

You can configure a SmartEdge® router to perform Deep Packet Inspection (DPI) and heuristics-based traffic classification services to get better visibility into subscriber traffic. Based on the information obtained from the traffic analysis, the router can:

Application traffic management enables operators to manage application bandwidth and collect revenue from application traffic while providing the network performance that subscribers expect.

1.1   Application Bandwidth Management

You can manage bandwidth by optimizing services or optimizing network usage.

To optimize services, the SmartEdge router can track bandwidth-intensive applications—for example, file sharing, video streaming, and online gaming—and increase revenue potential by using the following:

To optimize network usage, the SmartEdge router can restrict the total bandwidth used by bandwidth-intensive applications to allow efficient use of the current network infrastructure:

1.2   Protocol Detection

The SmartEdge router detects application protocol traffic, including application protocols masquerading as other types of traffic on well-known ports. Detection of application traffic is based on a combination of signature matching and heuristics; see Section 2. Detection of some encrypted application traffic is supported; however, encrypted traffic can only be detected indirectly using flow metrics and other heuristics. Therefore, detection of encrypted application traffic is not guaranteed.

The SmartEdge router detects a number of protocols, including the following:

Analyzers are updated according to the newest available version of each protocol.

2   Traffic Analysis

The SmartEdge router uses three different traffic analysis methods to extract relevant information:

Figure 1   Application Traffic Analysis

Traffic classification can be based on any of these analysis methods. The application service class result of the classification is independent of the analysis approach followed, and it can be managed and controlled in exactly the same way, regardless of whether shallow inspection, deep inspection, or heuristic analysis have been used. You can create a powerful traffic-identification engine by defining application service classes that rely on more than one analysis approach at the same time.

2.1   Shallow Packet Inspection

Shallow inspection obtains the 5-tuple of the IP packet header:

Shallow inspection is stateless, because the 5-tuple exists in any IP packet.

Shallow inspection enables content type identification based on, for example:

Because shallow inspection is simple and requires minimum node resources, operators use it when the application service servers and ports are well-known and stable. However, shallow inspection cannot identify events within the user session (for example, a message transaction) or any application-specific information (for example, URI), and is sensitive to changes in the application service IP addresses and ports.

Shallow inspection requires the 5-tuple fields to be available. For example, if IPSec is used, the protocol number could be either 50 (ESP) or 51 (AH). If tunneling is used, the source and destination addresses identify only the tunnel end points.

2.2   Deep Packet Inspection

DPI on the SmartEdge router examines packets beyond the IP header and extracts parameters from higher layers (Layer 4 and 7).

DPI is more processing intensive than shallow inspection. Because it requires transparency of the inspected traffic, DPI does not work with compressed or encrypted traffic.

2.3   Heuristic Analysis

Heuristic analysis is based on a set of empirical pattern characteristics of a particular protocol or application, and it does not rely on the exact knowledge required by DPI.

Heuristic analysis is typically used by the SmartEdge router together with DPI. However, only heuristic analysis may be possible when the protocol used:

Unlike shallow or deep inspection, the heuristics traffic analyzer makes a best-guess classification—identification accuracy is not guaranteed to be 100%. For example, some sophisticated heuristic patterns need to inspect several packets before they can identify the protocol (the application tests three known ports in succession before initiating a transaction). In this case, the traffic that was used in the early stages of the detection is not buffered and cannot be classified later because it has already been transmitted. However, you can use heuristic analysis effectively for the following:

The identification is of an aggregated nature; granularity is at the level of the application service session (for example, to identify all P2P traffic from a subscriber’s terminal).

Figure 2   Heuristic Analysis

Three types of patterns are applied, which, when combined, provide the highest possible identification rates:

These heuristic patterns have been created based on the observation and analysis of real traffic.

3   Traffic Classification

When the SmartEdge router detects application traffic, the node applies an application traffic management policy.

Note:  
NAT and ASE services are mutually exclusive and cannot be applied together for a subscriber; only NAT will be applied if you attempt to apply both services to a subscriber.

An application traffic management policy includes a reference to an Access Control List (ACL) policy and an action policy.

An ACL policy is an ordered list of packet filters (rules), each of which defines a class of packets. Different actions can be applied to different classes of packets.

The ACL policy does not define the action applied to the traffic. The action is determined by the traffic management action policy. A traffic management action policy is a collection of class entries, with each class defining one or more actions for that class; see Figure 3.

Figure 3   Actions Applied to Classes Through the Application Traffic Management Policy

Different actions can be applied for the same class of traffic; for example, the same BitTorrent traffic can be rate-limited for a bronze subscriber, but not rate-limited for a gold subscriber.

Multiple ACL rules can refer to the same class; however, any rate limit specified for the class is shared by all traffic mapping to that class. For example, if multiple ACLs refer to class A, and class A specifies a rate limit of 100 Kbps, then all traffic mapping to class A is subject to a combined rate limit of 100 Kbps; rate limits apply per class, not per ACL rule.

Traffic can be classified based on application protocol or transport protocol, or on application protocol category. A category groups applications or protocols used for a similar purpose; for example, streaming, messaging, file transfer, and so on. If a category is specified, all applications defined in the category are included.

By specifying the ACL policy and action policy as references, the ACL policy and action policy can be used by multiple application traffic management policies. For example, the same ACL policy can be referenced by three different traffic management policies to treat the same traffic differently for various user types. Similarly, the same traffic management action policy can be used with multiple ACL policies; see Figure 4.

Figure 4   Application Traffic Management Policies Reference ACL Policies and Action Policies

For information on configuring application traffic management, see Reference [1].

4   Statistics Collection

The node collects subscriber statistics per application protocol for inbound and outbound directions.

4.1   Subscriber Statistics

Subscriber statistics are collected per subscriber for upstream and downstream traffic. Inbound traffic is traffic originating from the subscriber; outbound traffic is traffic destined toward the subscriber.

Even though rate limiting can be specified for a group of protocols, statistics are collected per subscriber, per protocol. Statistics are collected and reported for all protocols detected, not just for those configured in the ACL rules.

The node maintains cumulative statistics counters; however, the counters that are reported in the periodic statistics reports are incremental counters. Only those protocols with activity during the previous reporting interval are reported. When a user logs out, any counters with activity since the last statistics report are reported.

Table 1 describes the statistics collected per subscriber, per protocol, for upstream and downstream traffic.

Table 1    Statistics Collected Per Subscriber Per Protocol

Statistic (Field in Log)

Description

Packets subject to application traffic detection (PktInsp)

Number of packets that were subject to pattern matching; typically, only the first few packets of a session are subject to pattern matching. Does not include packets with zero application payload length.

Bytes subject to application traffic detection (ByteInsp)

Number of bytes that were subject to pattern matching; typically, only the first few kilobytes of a session are subject to pattern matching. Does not include bytes with zero application payload length.

Packets dropped (PktDrop)

Number of packets dropped due to rate limiting.

Bytes dropped (ByteDrop)

Number of bytes in packets dropped due to rate limiting.

Packets sent (PktTx)

Packets received minus packets dropped.

Bytes sent (ByteTx)

Bytes received minus bytes dropped.

Number of flows (Flows)

Number of unidirectional flows detected as belonging to an application traffic session. The counter is incremented once per unidirectional flow.

Packet direction (Src, Dest)

Subscriber to Internet or Internet to subscriber.

4.2   Log Format

Table 2 describes the fields that appear in the generated logs. Statistics are reported per subscriber, per protocol, for upstream and downstream traffic. The counters are incremental since the last statistics report; only those protocols with activity during the previous reporting interval are reported. When a user logs out, any counters with activity since the last statistics report are reported.

Table 2    Description of Log Fields

Log Field

Description

AppProto

Application or protocol for which data is generated in the format numeric-id/application-string; for example, 1/bittorrent

Area

Internal message data. Log area.

ByteDrop

Number of bytes in packets dropped due to rate limiting.

ByteInsp

Number of bytes that were subject to pattern matching; typically, only the first few bytes of a session are subject to pattern matching. Does not include bytes with zero application payload length.

ByteRx

Number of bytes received.

ByteTx

Bytes received minus bytes sent in a single direction since the last statistics message. Reported per direction, per user, and per protocol.

ConnDrop

Number of flows which have been dropped since the last statistics message in this direction

Ctxt

Context in SmartEdge router from which data is generated.

Dest

Destination of traffic: Internet (data upload) or Subscriber (data download). Together with Src, indicates direction of the traffic.

DestIP

Destination IP address.

DestPort

Destination port.

DevId

System hostname and ASP Device Identifier [node-id]/slot/port

Flows

Number of unidirectional flows detected as belonging to an application traffic session. The counter is incremented once per unidirectional flow (that is, incremented by two per bidirectional application traffic session).

Level

Log level.

Module

Internal message data. Module that generated the log; for example, Infra, DPI, Firewall, IKE, IPsec.

MsgId

Internal message data. Message identifier.

PktDrop

Number of packets dropped due to rate limiting.

PktInsp

Number of packets that were subject to pattern matching; typically, only the first few packets of a session are subject to pattern matching. Does not include packets with zero application payload length.

PktRx

Number of packets received.

PktTx

Packets transmitted in a single direction since the last statistics message. Reported per direction, per user, and per protocol.

Policy

Policy applied to the subscriber.

Src

Source of traffic: Internet (data download) or Subscriber (data upload). Together with Dest, indicates direction of the traffic.

SrcIP

Source IP address.

SrcPort

Source port.

Svcs

A space-separated list of Service: Policy values

TransProto

Transport protocol (TCP or UDP)

TS

Timestamp

TZ

Timezone of the node

User

Subscriber for whom data is generated.

Ver

Version of the protocol used for sending messages

The following examples illustrate log format and output for subscriber login, subscriber logout, protocol statistics, and protocol detection.

Example 1   Subscriber Login Log

TZ="GMT+0:0" TS="Wed Apr 22 18:59:01 2009" Ver=1 MsgId=0x100000c8 
Module="Infra" DevId="akari/1/2" Area="Sub" Level="Notice" Ctxt="m1" 
User="user1@m1" Svcs="dpi-tm:abc" 

Example 2   Subscriber Logout Log

TZ="GMT+0:0" TS="Wed Apr 22 18:59:01 2009" Ver=1 MsgId=0x100000c9 
Module="Infra" DevId="akari/1/2" Area="Sub" Level="Notice" Ctxt="m1" 
User="user1@m1"

Example 3   Protocol Statistics Log

TZ="GMT+0:0" TS="Wed Apr 22 19:01:41 2009" Ver=1 MsgId=0x10000727 
Module="DPI-TM" DevId="akari/1/2" Area="Stats:I" Level="Info" 
Ctxt="m1" User="user1@m1" Policy="NULL" AppProto="1/bit-torrent" 
Src="Internet" Dest="Subscriber" PktTx=84357 ByteTx=108510480 
PktDrop=0 ByteDrop=0 Flows=1 ConnDrop=0 

TZ="GMT+0:0" TS="Wed Apr 22 19:01:41 2009" Ver=1 MsgId=0x10000727 
Module="DPI-TM" DevId="akari/1/2" Area="Stats:I" Level="Info" 
Ctxt="m1" User="user1@m1" Policy="NULL" AppProto="1/bit-torrent" 
Src="Subscriber" Dest="Internet" PktTx=84475 ByteTx=3545988 PktDrop=0 
ByteDrop=0 Flows=1 ConnDrop=0

Example 4   Protocol Detection Log

TZ="GMT+0:0" TS="Wed Apr 22 18:59:29 2009" Ver=1 MsgId=0x10000728 
Module="DPI-TM" DevId="akari/1/2" Area="Detect" Level="Notice" 
Ctxt="m1" User="user1@m1" AppProto ="1/bit-torrent" Policy="NULL" 
PxtInsp=0 ByteInsp=0 SrcIP="12.1.5.8" DestIP="121.2.1.1" 
TransProto="tcp" SrcPort=32768 DestPort=6881 

5   Quality of Service Management

Quality of Service (QoS) policies create and enforce QoS levels and bandwidth rates, and prioritize how incoming and outgoing packets are scheduled. A QoS policy may be used to manage application traffic by:

For application traffic management QoS policies, application protocol level QoS actions apply to an aggregate of inbound and outbound directions; separate values for inbound and outbound packets are not supported. You can apply QoS actions per application protocol, or to a group of application protocols.

For more information on QoS class-based marking and rate-limiting, see Reference [2].

6   Operations and Management

The SmartEdge router is operated and configured using a command-line interface (CLI). For information on basic router configuration, including an introduction to SmartEdge OS concepts and the user interface, privilege levels, and managing the configuration file, see Reference [3], Reference [4], Reference [5], and Reference [6].


Glossary

ACL
Access Control List
 
AF
Assured Forwarding
 
ByteDrop
Bytes dropped
 
ByteInsp
Bytes subject to application traffic detection
 
ByteTx
Bytes sent
 
DPI
Deep Packet Inspection
 
DSCP
Differentiated Services Code Point
 
PktDrop
Packets dropped
 
PktInsp
Packets subject to application traffic detection
 
PktTx
Packets sent
 
QoS
Quality of Service

Reference List

[1] Application Traffic Management Configuration and Operation, 1543-CRA 119 1170/1.
[2] Configuring Rate-Limiting and Class-Limiting, 55/1543-CRA 119 1170/1.
[3] SEOS Overview, 3/221 02-CRA 119 1170/1.
[4] Managing Configuration Files, 5/1543-CRA 119 1170/1.
[5] Performing Basic SmartEdge Configuration Tasks, 6/1543-CRA 119 1170/1.
[6] Using the CLI, 3/190 80-CRA 119 1170/1.