ADC is a StarOS in-line service application that runs on Cisco ASR 5500 platforms. For additional platform information, refer to the appropriate System Administration Guide and/or contact your Cisco account representative.

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.

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.

ADC has the capability to detect network traffic for sub-classification of audio, file transfer, instant messaging, video, voipout or unclassified traffic. The duration of the call 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 presence of different network traffic, and generate records that can be used to calculate the traffic call duration.

P2P flows now support the Transactional Rule Matching (TRM) feature. The TRM/FP feature enables the Enhanced Charging Service (ECS) to bypass per-packet rule matching on a transaction once the transaction is fully classified. This enables ECS to better utilize CPU resources and accommodate additional throughput for the system, thus improving the overall performance.

A transaction for TRM can be defined as the entire UDP flow, the ACK of the 3-way handshake to the FIN/RST of a TCP flow, or the HTTP request to the next HTTP request, or HTTP request to the FIN/RST for the final request of the flow. The TRM feature can also perform rule matching on IP L4 rules (UDP, TCP), HTTP, and HTTPS.

For more information on the TRM/FP feature, refer to the ECS Administration Guide.

The Flow Aware Packet Acceleration (FAPA) feature improves the throughput in terms of PPS, by caching rule matching results of a flow for selected flows so as not to incur the lookup penalty for a large number of packets in that flow. This new accelerated path is capable of performing a full range of basic functions including handling charging, modification of packet headers, and incrementing various counters. The accelerated path dynamically evaluates the current flow state and reverts back to the slow path when the flow cannot be handled on the fast path.

TRM/FP support has been extended beyond rule-matching. The FAPA function identifies packets that need only a small amount of processing, and performs necessary tasks on these packets. Only those packets that do not require DPI are allowed to enter the Accelerated path. VoLTE, encrypted, HTTP, HTTPS, RTP and plain TCP/UDP traffic where L7 analysis is not enabled, and so on are all the flows that will get accelerated.

Important

A Flow Aware Packet Acceleration license is required on ASR5500 and VPC platforms.

P2P flows will be optimized and accelerated using FAPA. ADC when enabled with FAPA improves P2P performance considerably.

Important

FAPA accelerates P2P flows for most protocols except for some protocols/applications explicitly listed below.

For more information on the FAPA feature, refer to the ECS Administration Guide.

The ADC Rule feature will support detection of application level flows as described in Release-11 of 3GPP standard. ADC Rules are certain extensions to dynamic and predefined PCC Rules in order to support specification, detection and reporting of an application flow. These rules are installed (modified/removed) by PCRF via CCA-I/CCA-U/RAR events. ADC rules can be either dynamic PCC or predefined PCC rules, and the existing attributes of dynamic and predefined rules will be applicable.

Important

ADC Rule support is a licensed-controlled feature. Contact your Cisco account representative for detailed information on specific licensing requirements.

When the license is not enabled, P2P continues to function as per its original behavior, that is, it monitors the traffic at the entire rulebase level. When the license is enabled, the P2P behavior changes such as to monitor traffic at per subscriber level.

Dynamic PCC rule contains either traffic flow filters or Application ID. When Application ID is present, the rule is treated as ADC Rule. Application ID is the name of the ruledef which is pre-defined in the ASR 5500. This ruledef contains application filters that define the application supported by P2P protocols and non-P2P protocols.

In releases prior to release 19.3: PCEF will process and install ADC rules that are received from PCRF interface, and will detect the specified application(s) and report detection of application traffic to the PCRF. Reporting of application traffic are controlled by PCRF and generates Application Start/Stop events along with the Application ID. Application mute status can be enabled or disabled on both dynamic and predefined ADC rules. When mute is disabled, Application Start/Stop event trigger will be generated by PCEF for that specific Application ID. Mute status can be enabled or disabled by PCRF for dynamic rules, and configured on ASR 5500 for pre-defined rules.

In 19.3 and later releases: When a subscriber attaches to the network, PCRF will install ADC rule/Group of Ruledefs towards PCEF to detect Application flow. The Install ADC rules will additionally enable default routes to HTTP, HTTPS, FTP, RTSP, RTCP or SIP analyzer based on the rule-definition. The default routes use the standard ports associated with the respective protocol. When a new flow comes, the route matching happens for dynamic routes first, then static routes and finally default routes. When a flow matches that ADC rule, an APP-START notification is sent to PCRF with Application ID, Instance ID and flow information. Instance ID is a unique identifier for a particular ADC flow. PCRF then takes necessary action for the detected application. When ADC flow terminates, an APP-STOP notification is sent to PCRF with Application ID and Instance ID.

The following types of ADC ruledefs can be configured.

• ruledef adc_rule 
     p2p protocol = <name> 
     p2p protocol-group = <name> 
     p2p behavioral = <name> 
     multiline-or all-lines 
     end 

  multiline-or all-lines is optional if rule contains only one line.

• ruledef adc_rule_type2 
     p2p protocol = <name> 
     p2p traffic-type = <sub_type_name> 
     end 

• ruledef adc_rule_type3 
     p2p anymatch = TRUE 
     end 

  When p2p any-match = TRUE is configured, only one rule containing this rule line can be installed. This rule line must not be used with any other P2P rule line.

ADC Mute Customization

Earlier, 3GPP ADC over Gx did not support application MUTE status change. Once the application was muted, it was not possible to unmute it. From release 21.1, this feature introduces custom MUTE/UNMUTE functionality. ASR 5500 PCEF now supports customization to control reporting of the Application Detection Information CCRUs. For this, an AVP has been introduced with two possible values - custom MUTE and custom UNMUTE.

TOS/DSCP Support

In 19.3 and later releases, the ADC functionality is extended to identify applications and distinguish bearer traffic based on TOS/DSCP. DSCP/TOS based ADC dynamic rules over Gx will be supported for default and dedicated bearers. Bearer mapping and rule matching will be done based on DSCP/TOS value. Filters can be created for PCC rules based on TOS-Traffic-Class AVP under flow information.

When a subscriber attaches to the network, PCRF will install PCC rule with TOS/DSCP filter towards PCEF. PCEF will create a dedicated bearer and send the packet filters to UE as well. When a new flow comes with first packet as Uplink, UE does bearer matching based on the TOS/DSCP value, and sends flow on the correct dedicated bearer. For downlink packet, ECS does bearer lookup and assigns correct bearer to the flow based on the TOS/DSCP value.

ADC Event reporting will contain flow template with outer IP 3 tuples (Source IP, Destination IP, Port). L4-L7 rule match will also work for PMIP service.

ADC supports many streaming applications that are ad-supported and the flows corresponding to these third-party advertisements are generic. These advertisement flows could not be differentiated from specific application flows based on the deterministic pattern. As part of this feature, a configurable option is provided to dynamically correlate advertisement flows and associate the respective applications.

Any advertisement service is associated with the corresponding application protocol. The type of ad-flow will be configured per application. Refer to the Configuring P2P Advertisement server section in the Application Detection and Control Configuration chapter for more information on configuring the P2P Advertisement Server correlation group.

Limitations

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.

Important

The bulk statistics format previously supported by the older implementation for individual ADC protocols in ECS schema is deprecated, and the new bulk statistics format is supported in 14.0 and later releases in the new P2P schema.

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-protocol%\n%p2p-protocol-group%\n%p2p-uplnk-bytes-name%:%p2puplnk-bytes-value

%\n%p2p-dwlnk-bytes-name%:%p2p-dwlnk-bytes-value%\n%p2p-uplnk-pktsname%:%p2p-uplnk-pkts-value%

p2p-uplnk-pkts-value%\n%p2p-dwlnk-pkts-name%:%p2p-dwlnk-pkts-value%\n%p2pduration-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/file transfer/instant messaging/video/voipout/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.

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.