Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Integration of the SRC Software and the Ellacoya DPI Platform

    This topic describes the integration of the SRC software with the Ellacoya DPI platform.

    Ellacoya Networks DPI Platform

    The SRC software is integrated with the Ellacoya IP Service Control System (IPSCS), which delivers comprehensive monitoring tools and extensive reporting that gives providers network visibility into and control over their subscribers, network, and service offerings (see Figure 1). The IPSCS includes the following components:

    • IPSCS e30 Switch, which provides application session and usage information based on real-time deep inspection of network traffic.

    • Service logic engine (SLE), which is the control component of the IPSCS software. The SLE includes the Usage Quota Management System (UQMS) applications programming interfaces (API) that the SRC software can call to collect usage data and to indicate that subscriber sessions have started, changed, or stopped. Calls for the API are carried between the SLE and the SRC software by the Remote Method Invocation (RMI) protocol.

    The IPSCS allows the creation of Usage Quota Management Systems, which allows third-party systems, such as the SRC software, to be integrated with the IPSCS. The UQMS is a provisioning system that determines business rules and communicates them to the IPSCS and other network components.

    Service providers provision business rules on the UQMS. Based on the configuration instructions from the UQMS, the IPSCS collects usage statistics on specified intervals and applications, and then forwards the data to the UQMS for processing. The UQMS sends authentication and configuration information for subscribers to the IPSCS.

    Juniper Networks Platforms

    As shown in Figure 1, the SRC software is integrated with the Ellacoya DPI platform through an SAE script service that works as a UQMS to the IPSCS. The script service sends event messages to and receives messages from the SLE through the UQMS API. The script service translates subscriber logins and logouts and service activation and deactivation to corresponding RMI function calls in the SLE. The script service collects accounting data from the SLE and maps the data to SRC service session usage data. The SRC software is integrated with the Ellacoya platform in a way that makes services implemented by the e30 Switch just like any other SRC service.

    The SRC software supports the DPI solution on routers running JunosE or Junos OS, and on PacketCable Multimedia Specification (PCMM) policy servers and cable modem termination system (CMTS) devices.

    You can integrate the SLE with the SRC software through a SOAP interface to the NIC and the SAE.

    Figure 1 shows the components involved in the SRC-DPI integration.

    Figure 1: DPI Integration Overview

    DPI Integration Overview

    IPSCS Service Offers and Service Bundles

    The Ellacoya IPSCS has the concept of service offers that contain a collection of service bundles. Service bundles are applied to a subscriber and contain a set of policy rules that define the patterns needed to recognize application sessions between specified source and destination networks. The service bundle includes the actions to take on application sessions, including marking specified streams with a DiffServ code point. Each rule in a service bundle can also have an activation period to control the time it is active.

    A service offer also allows the association of traffic-accounting profiles (TAPs) with service bundles. TAPs are used to interface with external accounting systems. If a TAP is applied to a service bundle for a subscriber, then the counters for that service bundle are accumulated in accounting records indexed by TAP name.

    Mapping Service Offers and Service Bundles to SRC Concepts

    A service offer applied to a subscriber in the IPSCS corresponds to the SRC concept of the set of services active for a subscriber. A service bundle in an applied service offer corresponds to an SRC service activation.

    A TAP applied to a service bundle roughly corresponds to accounting being enabled on an SRC policy.

    The DPI integration maps SRC service activations and deactivations to changing the service offer applied to the subscriber so that it contains the corresponding set of service bundles. For example, a service provider offers three SRC services—Web access, e-mail, and peer-to-peer file sharing—to its subscribers. Each service can be dynamically enabled or disabled. The Ellacoya DPI system provides eight service offers that accommodate all possible combinations of the three SRC services.

    Synchronization Between the SRC Software and the Ellacoya System

    Table 1 outlines the interactions that must be synchronized between the SRC software and the Ellacoya system.

    Table 1: Synchronization Between the SRC Software and the Ellacoya System




    Service offer

    Provisioned on the Ellacoya system

    Contains the definition of the profile set in terms of network policies. For example, rate limits and ToS marking.



    Subscribers are dynamically created in the Ellacoya database as the SRC software provisions them through the UQMS API.

    Subscriber/Service offer binding


    The binding of the subscriber to a service offer is done dynamically when the SRC software provisions the subscriber through the UQMS API.

    Subscriber/IP address binding


    The binding between the subscriber and IP address is a transient binding communicated from the SRC software when the subscriber session starts.

    Collecting Accounting Data

    The IPSCS has a bulk statistics architecture where usage counters are collected for all active subscribers and services in bulk, and is controlled by a global accounting interval. The DPI script service polls for new usage data through the UQMS API based on the SLE global accounting interval. The SLE returns a list of file Uniform Resource Identifiers (URIs) of bulkstats files that have not been processed by the DPI script service.

    After the DPI script service collects accounting data from the SLE, it maps the accounting data to usage data for an SRC service, and provides the usage data to the SAE. Because the SLE reports accounting data in the last accounting interval and the SAE expects service usage data since the service started, the script service adds the usage data in each accounting interval since the script service started. The script service keeps the counters in memory and also stores them so they can be recovered if there is an SAE failover.

    The script service also stores a timestamp for the last time new data was reported to the SAE. This way, if there is a failover, the script service can determine when the doneWithFile method can be called for a file and whether or not a piece of usage data has been processed. The new SAE (after failover) requests the accounting data for sessions where the data in the file was reported to the previous SAE. At this time, the script service can compare timestamps (records in the file are also timestamped) to recognize that the data was previously reported and to recognize when all of the data in a file has been processed.

    The IPSCS provides only one accounting record per accounting interval, per service offer, and per subscriber. This behavior means that if a DPI script service is stopped and restarted during one IPSCS accounting interval (usually 15 minutes), service usage of the two service sessions within that interval are allocated to one of the service sessions—the first service session for which the SAE requests an accounting update.

    Modified: 2018-09-20