Applications
The SDX application library provides a set of applications to extend how you can use the SDX software.
ACP
ACP authorizes and tracks subscribers' use of the network resources that are associated with services that the SDX software manages. ACP operates in two separate regions of the SDX network: the edge network and the backbone network. The edge network is the layer 2 access network through which subscribers connect to a router configured as a Broadband Remote Access Server (B-RAS). The backbone network is the region between the router and the service provider's network.
Congestion often occurs in the network at points where connections are aggregated. ACP monitors congestion points at interfaces between devices in the edge network. In the backbone network, ACP monitors one congestion point, a point-to-point label-switched path (LSP), between the router and the service provider's network.
Typically, network administrators use their own network management applications and external applications to provide data for ACP. ACP first obtains updates from external applications through its remote CORBA interface and then obtains updates from the directory through LDAP. ACP does not interact directly with the network to assess the capacity of a congestion point or actual use of network resources.
Figure 12 shows a typical network topology.
![]()
IDP Integration Applications
The IDP integration applications allow you to use IDP to monitor subscriber traffic for detecting malicious network traffic sent to or received by subscribers. In addition to the actions that IDP can take in response to detected incidents, you can configure the SDX software to respond to these incidents by taking one or more of the following actions for subscribers associated with malicious traffic:
- Applying policies, such as policies that limit subscriber bandwidth, to subscriber interfaces
- Sending e-mail messages that describe the nature of an incident
- Redirecting Web requests to an IDP captive portal where a page provides the source or destination of the problem traffic and a description of the incident
The SDX application library provides robust sample data for IDP integration, a sample e-mail gateway application, and a sample IDP captive portal. You can customize the implementation provided, or create a new one based on the samples.
IVE Host Checker Integration Application
The IVE Host Checker integration application allows you to verify that the subscriber systems used to connect to a service provider comply with the service provider's policies. You can deploy IVE Host Checker in a network so that it is activated according to the service provider's requirements. Based on the host-checking results, the subscriber may be allowed full, limited, or no access to the Internet.
The SDX application library provides sample data for IVE Host Checker integration, a sample Host Check Result portal, and a sample VTA application for scheduling host checking. You can customize the implementation provided, or create a new one based on the samples.
Monitoring Agent Application
The Monitoring Agent application integrates IP address managers into an SDX-managed PCMM environment and provides event notification for the SAE from subscribers who log into CMTS devices.
You can use the Monitoring Agent application to allow IP address managers, such as a DHCP server or a RADIUS server, to notify the SAE about subscriber events. You can use the SDX software to notify the SAE when:
Prepaid Service Application
The prepaid service application is a demonstration application that illustrates how to integrate prepaid service applications with the SDX software.
The demonstration application consists of two components:
- Prepaid account server—Provides the central data repository for the prepaid services demonstration application. It maintains the different accounts and provides access for the other SDX components.
- Prepaid Account Web Admin—Allows you to manage prepaid accounts.
The demonstration supports two types of prepaid service applications, time based and volume based.
Sample IPTV Application
The IPTV application is a sample application that demonstrates how to use extended features of ACP and the SAE to manage network resources. You can use ACP to perform call admission control, allocate bandwidth, and initialize and execute applications. You can use the SAE to set up and manage LSP tunnels with router drivers and script service.
Advanced Services Gateway
The Advanced Services Gateway (ASG) allows a gateway client—an application that is not part of the SDX network—to interact with SDX components through a SOAP interface. This feature is useful for business-to-business situations, such as a wholesaler-retailer environment. Typically, the wholesaler owns and administers the SDX components, and the retailer maintains a database of subscribers. Retailers purchase services from one or more wholesalers and sell the services to their subscribers. Using information provided by the wholesaler, the retailer creates a gateway client to communicate with the components in the SDX software.
The ASG offers the following Web applications:
- Dynamic Service Activator allows a gateway client to dynamically activate and deactivate SDX services for subscribers and to run scripts that manage the SAE.
- Subscriber Manager allows a gateway client to create and modify subscriber data and to manipulate the Workflow application.
Traffic-Mirroring Application
The traffic-mirroring application allows service providers to mirror subscriber traffic on any subscriber access platform supported by the SDX software. By activating traffic-mirroring services in an SDX-managed environment, service providers can set up SDX policies to:
- Monitor subscriber traffic and intercept traffic from a particular source or to a particular destination.
- Take actions for subscribers with intercepted traffic by applying policies to the subscriber traffic.
The sample data provided with the application illustrates configurations for a network that contains JUNOSe routers and JUNOS routing platforms and includes policies, services, and router definitions.
Volume-Tracking Application (VTA)
The VTA allows service providers to track and control the network usage of subscribers and services. You can control volume and time usage on a per subscriber or per service basis. This level of control means that service providers can offer tiered services that use volume as a metric, while also controlling abusive subscribers and applications.
When a subscriber or service exceeds bandwidth limits (or quotas), the VTA can take actions including directing the subscriber to a portal to activate additional services or purchase additional bandwidth, imposing rate limits on traffic, sending an e-mail notification, or charging extra for additional bandwidth consumed.
If you use VTAs with the SDX deep packet inspection (DPI) feature, you can control the volume of traffic for specific applications, such as peer-to-peer file sharing.
Types of VTA Applications
There are two main types of volume-control applications that you can set up with the VTA:
- Quota-based application. The VTA limits a subscriber's access rate based on the balances of the subscriber's accounts. Subscribers periodically receive a quota of transfer volume that they can use to upload and download data. They can also purchase additional volume that they can use at any time. For example, a subscriber may receive a 25-MB periodic quota each month. In addition, that subscriber may purchase 25 MB of bought quota in January, and use the bought quota between January and March.
The periodic quota and bought quota are tracked in separate accounts. As a subscriber consumes volume, the VTA debits the accounts, using first the periodic quota and, if no periodic quota is available, the bought quota.
- Threshold-based application. The VTA limits a subscriber's access rate by comparing the volume of data that the subscriber transfers with a specified limit. If a subscriber exceeds a specified usage limit over a specified period of time, the VTA applies a slow rate limit to a subscriber's connection for another specified period of time. This action lowers the subscriber's average bandwidth consumption to an acceptable level.
Managing Subscriber Accounts with Web Portals
We provide two sample portals that manage subscriber accounts. One is an administrator portal that administrators can use to manage VTA subscriber accounts. The second is a subscriber portal that subscribers can use to manage their own accounts. Before you can use these portal, you need to configure the Web applications for the VTA.
The suggested billing model for services managed by VTAs is one in which subscribers pay for services when they select them through a Web portal.
Deep Packet Inspection Integration Application
The SDX software has been integrated with the Ellacoya Networks Deep Packet Inspection (DPI) platform to provide a traffic management solution that combines the advanced traffic identification and reporting features of the Ellacoya DPI with the SDX software's intelligent service policy enforcement. With this solution, providers can identify, monitor, and control traffic on a per-application or per-subscriber basis.
Application traffic such as peer-to-peer file sharing or instant messaging, which in many cases originates or terminates outside of a provider's network, can cause abusive or indiscriminate consumption of bandwidth and impact a provider's ability to deliver its own services. In particular, services that require higher, guaranteed levels of performance, such as Voice-over-IP (VoIP) or video-on-demand (VoD), can be impacted. Having visibility into applications that are transported over the network and their associated bandwidth consumption at various times is important as is the ability to control those applications.
The DPI solution allows providers to implement service control policies on specific traffic flows quickly and effectively. Such policies include throttling back, capping volume, or even enhancing bandwidth or service quality for sanctioned peer-to-peer applications.
Benefits of the DPI Integration
By identifying and effectively controlling traffic at the application level, service providers can:
- Put usage controls on applications on a subscriber basis. For example, you can put a quota limit on the amount of peer-to-peer traffic that a subscriber can consume in a month.
Once subscribers have used their quota, you can apply a policy that throttles back on or blocks a subscriber's peer-to-peer traffic, bill the subscriber for additional usage, or allow the subscriber to purchase additional quota.
- Limit the total percentage of network resources that a specific type of traffic is allowed to consume.
- Provide higher or guaranteed levels of performance for premium services by applying QoS control to application sessions. For example, two subscribers start an Xbox Live session. The Ellacoya DPI platform detects activity for this application, and sends application usage counters to the SDX software. The SDX software pushes policies that deliver a specific level of QoS for this application session to a router or other network device.
- Charge subscribers based on their usage of premium content-based services.
- Offer and charge for tiered Internet services based on both speed and application.
- Better support network planning functions by gaining an in depth understanding of traffic flows and patterns on a per subscriber and per application basis.
Workflow Application
The Workflow application allows a service provider to automate the provisioning process for primary access services. Typically, primary access services consist of broadband access, such as DSL or cable, Internet connectivity with a default profile, and possibly some application services, such as e-mail. Once the primary access service is set up, the subscriber can use the dynamic service selection mechanism for value-added services.
As shown in Figure 13, the Workflow application uses APIs, protocols, scripts, and external programs to communicate with the various components of the SDX software.
![]()
Java
The Java API consists of beans developed by the service provider to describe a desired workflow (for example, sending an e-mail to a technician or mail robot provisioning systems). The beans drive the Workflow application. We provide sample beans as well as template beans that help the service provider design workflow beans.
LDAP
The Workflow application can perform LDAP operations (for example, add, delete, search, and modify entries) to an external LDAP server.
Scripts and External Programs
The Workflow application can be designed to run a script or external program that can perform provisioning functions; for example:
- Execute a sequence of configuration commands or SNMP requests on a network element.
- Request an update in a subscriber database.
- Create an e-mail account.
- Allocate file space on a Web server and configure FTP access for the subscriber.
E-Mail Send/Receive Protocols
The following e-mail send and receive protocols are used in the Workflow application:
- Simple Mail Transfer Protocol (SMTP)—Used by an e-mail bean to send an e-mail to an external entity (for example, a provisioning system)
- Post Office Protocol version 3 (POP3)—Used by the Workflow application to receive e-mail responses to e-mail requests sent previously
- Internet Message Access Protocol (IMAP)—An alternative to the SMTP and POP3 protocols
HTTP
The Workflow application also uses HTTP to send and receive messages to and from external provisioning systems. These messages are usually encoded in XML.
XML
The SDX object state manager (OSM) receives messages from the service provider's provisioning system that are encoded in XML. These messages are requests for the OSM to change the state of subscribers and subscriptions according to service provider-defined object life cycle state machines. For instance, a subscription may have several states, such as created, provisioned, and inactive. The state machine defines the valid transitions from state to state and, optionally, a workflow to carry out the provisioning steps to effect the transition between the states.
The workflows themselves can send XML requests and receive XML responses to and from the service provider's provisioning systems to carry out some of the steps in the workflow.