[Contents] [Prev] [Next] [Index] [Report an Error]

Components

The SDX software is a dynamic system made up of many components. Conceptually, the components can be thought of as tools because they provide several application programming interfaces (APIs) that allow them to be customized, extended, and integrated with other systems.

The vast majority of the SDX software's power and capability is made available through the components described in this section. The SDX software also works with several network components that extend the capabilities of the SDX software.

Table 5 gives a brief description of the components that make up the SDX software. Table 6 gives a brief description of standard infrastructure components that the SDX software uses. The remainder of this section describes these components in more detail. 





 Table 5:  Descriptions of SDX components  


 Component


 Description




 Admission Control Plug-In (ACP)



 Authorizes and tracks subscribers' use of network resources associated with services that the SDX application manages. 





 SDX Configuration Editor



 Provides a way to configure several other SDX components through an XML-based GUI. You can configure SAE parameters that are stored in the directory, NIC parameters used by portals, Web applications including EASP and plug-ins, as well as other features. 





 Configuration tool



 Generates start scripts and initial local configuration for newly installed SAEs and SNMP agents.





 Network information collector (NIC)



 Collects information about the state of the network, and can provide a mapping from a given type of network data to another type of network data. 





 Policy Editor



 Gives service providers the ability to define and modify policies and to store these policies in the directory.





 SDX Admin



 Allows service providers to add, modify, and delete services, network definitions, and advanced configurations within the SDX software. 





 SDX gateway



 Allows a gateway client—an application that is not part of the SDX network—to interact with SDX components through a SOAP interface. 





 SDX Web Admin



 SDX Web Admin is a series of Web applications that let you use a Web browser to configure, manage, and monitor various SDX components and related infrastructure components. SDX Web Admin includes the following applications: 


    
  
  •  Admission Control Web Admin - monitors the ACP and reorganizes the backup directory
    • 
  
  •  Inventory Importer Web Admin - configures, starts, stops, and monitors the process of importing NMC-RX Element Management System data 
    • 
  
  •  NIC Web Admin - displays NIC configurations in the directory, manages hosts, and simulates resolutions
    • 
  
  •  Prepaid Account Web Admin - manages prepaid accounts
    • 
  
  •  Policy Web Admin - searches for QoS policy information
    • 
  
  •  SAE Web Admin - manages and monitors the operation of SDX software; tests portals and classifier scripts
    • 






 Service activation engine (SAE) 



    
  
  •  Authorizes, activates and deactivates subscriber and service sessions by interacting with RADIUS servers and acting as a COPS server to apply subscriber specific policies on JUNOSe routers.
    • 
  
  •  Collects accounting information about subscribers and services from routers, and stores the information in RADIUS accounting servers, flat files, and other accounting databases.
    • 
  
  •  Provides APIs for starting and stopping subscriber and service sessions and for integrating with systems that authorize subscriber actions and track resource usage. 
    • 






 Service Selection Portal (SSP) 



 Provides a framework for building Web applications that allow residential and enterprise subscribers to manage their own network services. It comes with several full featured sample Web applications that are easy to customize and suitable for deployment. 





 Simple Network Management Protocol (SNMP) agent



 Monitors system performance and availability. It runs on all the SDX hosts and makes management information available through SNMP tables and sends notifications via SNMP traps. 





 Volume-tracking applications (VTAs)



 Monitors subscriber resource usage to allow service providers to offer flexible usage quotas, limit bandwidth to subscribers that overuse network resources, and to notify subscribers that may have been compromised by viruses or worms that overuse network resources. 





 Workflow application



 Automates the process of provisioning and decommissioning primary access services for subscribers. 






 






 Table 6:  Standard infrastructure components  


 Component


 Description




 AAA RADIUS server 



 Authenticates users and authorizes their access to the requested system or service. Accepts accounting data—time active and volume of data sent—about user and service sessions.





 Directory



 Repository of subscriber information, services, policies, and service portal configurations. The SDX software uses the Lightweight Directory Access Protocol (LDAP) for interactions with the directory. 





 J2EE application server



 Enables J2EE applications, including Web applications, to be used with the SDX software.





 Relational database (RDB)



 Provides a repository of frequently updated subscriber usage and resources information.

AAA RADIUS Server

RADIUS enables remote access servers to communicate with a central server to authenticate users and authorize their access to the requested system or service. RADIUS allows a company to maintain subscriber profiles in a central database that all remote servers can share. Having a central service makes it is easier to track usage for billing and to keep network statistics. The router provides RADIUS accounting and authentication, while the SAE provides SAE accounting and authentication.

We provide the Merit RADIUS application as a convenience to get started. We recommend that service providers move to a more sophisticated RADIUS server, such as Interlink RAD-Series AAA RADIUS or the Funk Steel-Belted RADIUS application, or integrate the SDX software with some other currently used RADIUS server. The SDX software works with other authentication, authorization, and accounting (AAA RADIUS) systems; however, we test and support system integration only with Merit, RAD-Series AAA RADIUS Server, and Funk Steel-Belted RADIUS software.

You can use any RADIUS server for authentication and accounting that is compliant with these standards:

When a provider uses the SDX schema to integrate the RADIUS server with the directory, the SDX software provides the highest level of subscriber control. For example, when subscriber information is stored in the directory, the SDX software can provide a list of services for each individual subscriber.

The less integration the RADIUS server has with the directory, the less control the SDX software provides for individual users. For example, users may have to be grouped based on criteria such as domain name, router, or interface.

The SDX software can work without a RADIUS server. The SDX software can use either LDAP authentication and flat-file accounting, or it can rely on plug-ins to perform authentication and accounting.

Admission Control Plug-In (ACP)

The ACP authorizes and tracks subscribers' use of network resources 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 via its remote CORBA interface, and then obtains updates from the directory via LDAP. ACP does not interact directly with the network to assess the capacity of a congestion point or actual use of network resources.

Figure 2 shows a typical network topology.


Figure 2: Position of ACP in the network

Local Configuration Tool

Administrators use the local configuration tool to configures local files on the hosts that support SDX components such as the SAE and NIC. For some SDX components, the local configuration tool also reads data from and writes information to the directory.

Figure 3 shows an example of the configuration tool.


Figure 3: Sample configuration tool window

Directory

The directory is the central nervous system of the SDX software. In essence, the directory is the integration point of multiple systems that interact with the SDX software. The directory serves as a central repository of customer information, license information, service definitions, policies, and SAE configurations. We provide the OpenLDAP directory with the SDX software as a convenience to demonstrate the capabilities of the product. We recommend a more sophisticated directory server, such as Sun ONE Directory Server or DirX directory server.

Provisioning the Directory

For the SDX software to work, all the information must be provisioned in the directory. We provide some basic tools, such as SDX Admin and Policy Editor, to help provision the information into the directory.

An external OSS can also provision all or part of the information directly through the LDAP interface or indirectly using DirXmetahub. Metahub provides the ability to integrate connected data sources, such as a relational database holding the subscriber information, other LDAP directories, or flat files (for example, XML) into the SDX directory infrastructure. Metahub is a set of components that includes:

Metahub provides the SDX software with a unified view by synchronizing the OSS data, stored in one or more databases, into the SDX directory. This synchronization process can be performed in a scheduled manner as a full or delta import from the connected data sources into the SDX directory store and vice versa. Both mechanisms —the direct LDAP interface and the metahub solution—must follow the SDX LDAP schema.

Additionally, we provide sample data in LDAP Data Interchange Format (LDIF) to demonstrate how to provision the directory for different application scenarios.

LDAP Version 3

The SDX software employs LDAP version 3 to interact with directories. The SDX software is compatible with any LDAP version 3-compliant directory, but some integration work might be necessary, such as for the following requirements:

Prepackaged Integration

We provide prepackaged integration for:

Distinguished Names

The directory is organized in a tree format that is optimized for read operations. The directory consists of entries that store information about various objects of interest, such as network devices, organizations, and subscribers. The tree structure of the directory is presented in the navigation pane of SDX Admin.

Each entry at a given level in the tree hierarchy must have a unique name. One or more attributes from the entry provide the unique name, known as the relative distinguished name (RDN). The RDN identifies a unique entry at that level in the directory tree. Each RDN consists of an expression that associates an attribute type with the identifying value, as in the following sample RDNs from Figure 4:

o=umc

o=Users

retailername=vISP-one

ou=first-region

unique-id=joe 





 NOTE: The "#" can cause various problems if used in DNs. Do not use the "#" character in DNs.

Figure 4: Directory tree as displayed by SDX Admin

Each entry in the directory is identified and can be located by its distinguished name (DN). The DN is a comma-separated sequence of hierarchical entries in the tree, concatenated from the particular entry backward to the base, or root, of the tree structure. In contrast to the RDN, the DN for an entry is unique within the entire directory. The DN for subscriber Joe would be the following:

unique-id=joe, ou=first-region, retailername=vISP-one, o=users, o=umc







 NOTE: Throughout the SDX documentation, in text we show the elements of a DN separated by comma/space pairs. We do this for readability. The SDX software and the LDAP specifications require acceptance of the space, but the space is not necessary.

A base DN is the DN of an object that serves as the starting point for a directory search. For the directory as a whole, the base DN is o=umc for a default installation of the SDX software; it is the root object of the tree. For a search of policies, the base DN is the following:

o=policies, o=umc

A bind DN is the DN of a login to the directory. It must be entered (like a username) with a password to log in to the directory. In the SDX software, you will use the bind DN and password when you start up the SDX Admin tool to view or modify the contents of the directory.

Table 7 lists some commonly used DN attribute types. 





 Table 7:  Common attribute types  


 Attribute type abbreviation


 Attribute type definition




 cn



 Common name





 st



 State or province name





 o



 Organization name





 ou



 Organizational unit name





 c



 Country name





 uid



 User ID

The directory schema used by the SDX software includes entries for management configuration, network device configuration, policies, services, retailers or providers, and subscriber profiles.

Directory Eventing and Failover

Many SDX components, such as the SAE, policy engine, and SDX Admin, are designed to run nonstop. These components get most of their configuration and provisioning data from the directory. If the data in the directory changes, it is not necessary to manually reload the data into the potentially large number of affected components. The SDX directory client running in each of these components detects changes that affect the component, and the appropriate updates are made. For instance, if a subscriber has not paid his bill, an administrator can mark the subscriber's entry in the directory as disabled. Then, if the subscriber is currently logged in, all his subscriptions are deactivated, no matter which SAE currently manages his access service. Another example is changing the definition of a service. When the new service definition is stored in the directory, all SAEs are notified, and all active subscriptions to the service are adjusted to the new definition.

The SDX directory client is configured with a list of directory servers to use: one primary and any number of backups. If connectivity to the primary directory is lost, the directory client switches to an available backup directory server. If connectivity to the primary directory is restored, the SDX directory client detects the connection and switches back to the primary directory. This capability makes it possible to fine tune SDX deployments for added levels of availability and performance.

Third-Party Directory Servers

For information on the directory servers that you can integrate with the SDX software, see the release notes. The SDX software is designed to work with directory servers that are robust, scalable, and suitable for the carrier market.

J2EE Application Server

The SDX software is shipped with the JBoss application server. For a list of the J2EE application servers we have tested with the SDX software, see the release notes. This application server is J2EE compliant and supports the J2EE applications that the SDX software offers. J2EE application servers include a Web application server.

The Web application server supports JSP technology. JSP pages are Web pages that contain Java code and JSP tags (similar to HTML tags) embedded in normal HTML. The Java code and JSP tags produce dynamic HTML content and invoke the SAE functionality.

For example, the sample residential and enterprise portals are Web applications that operate inside a Web application server.

Residential Portal

Three residential portal examples are shipped with the SDX software. These examples can be used to demonstrate how service providers can implement self-managed value-added services for residential subscribers by using Web technology. The examples reflect different business models and are a very helpful starting point. The sample portals provided are:

Figure 5 shows a residential Web portal that could be created using the SDX software.


Figure 5: Sample residential Web portal

Enterprise Portal

The enterprise portal shows a Web application that lets service providers implement self-managed value-added services for IT administrators. These examples can ast as a framework or starting point.Figure 6 is an example of an enterprise Web portal.


Figure 6: Sample enterprise Web portal

Portals for PDAs

The Web-based SSPs you develop for the SDX software are compatible with personal digital assistants (PDAs). You can view an SSP on a PDA by starting the Web browser and entering the URL of the SSP host, in the following format:

http://<host>:8080/ssportal

<host> is the name or IP address of the host.

You can log in with your username and password.

When you have logged in, you can view the available services.

You can then navigate through the menus to activate and deactivate services.

NIC

The network information collector (NIC) is used by other SDX components such as the EASP and the demonstration residential portal. The NIC collects information about the state of the network, and can provide a mapping from a given type of network data, known as a key, to another type of network data, known as a value. The NIC component includes a Web administration interface that allows users to monitor and inspect the state of NIC servers.

Table 8 shows the resolutions that the standard SDX software can perform. For customized software that allows other resolutions, contact Juniper Networks Professional Services.





 Table 8:  Available NIC resolutions  


 Key


 Value




 Subscriber's IP address



 Subscriber's login name





 Subscriber's IP address (for situations in which the SAE manages the subscriber)



 SAE reference





 Subscriber's IP address (for situations in which the SAE manages the interface that the subscriber uses, but not the subscriber)



 SAE reference





 Subscriber's login name



 SAE reference





 Enterprise's distinguished name (DN)



 SAE reference

A NIC comprises a set of software components that work together to collect, process, and provide data. To allow you to design a NIC that performs efficiently for your network configuration, the NIC architecture is highly distributed. This feature means that you can install NIC components in the region of the network that is relevant to the particular functions that those components perform.

For example, in a simple network configuration where a single office deals with all network traffic, you can install all the NIC components on one workstation. However, in a complex network that supports multiple regions, you might install NIC components in each point of presence (POP) to collect information for that region. The back office, which directs traffic to the different POPs, might also support NIC components that provide information to all POPs.

The basic NIC infrastructure comprises NIC proxies, NIC resolvers, and NIC hosts. NIC proxies perform communication tasks and store results from mapping processes. NIC resolvers perform the actual mapping processes. NIC hosts support NIC resolvers and NIC agents.

NIC agents collect and publish data. They are highly specific to the type of data they collect and to the source with which they communicate to obtain the data. Consequently, NIC agents are not part of the basic NIC architecture; they are discrete software components that plug into the NIC infrastructure. Several NIC agents are supplied with the SDX software.

NIC configurations support redundancy. In a redundant configuration, a pair of NIC hosts or agents form a redundancy community with or without a monitor. The community defines the components that form the redundant relationship, and the monitor tracks the connections between the redundant components.

Figure 7 shows an example of a distributed NIC configuration for a network that supports one POP. This NIC maps several types of data keys to several types of data values, and supports redundancy for all NIC components.

To obtain customized software that allows data mappings other than those available with the standard software, contact Juniper Networks Professional Services. For detailed information about planning a NIC, see SDX Components Guide, Vol. 2, Chapter 9, Overview of the NIC.


Figure 7: Sample distributed NIC configuration

Policy Editor

Policy Editor is a GUI that allows easy specification and validation of policies. Policy Editor stores policies in a central repository, or directory. Policy Editor works closely with a policy engine, which performs dynamic policy decisions while activating services, leveraging on the directory content to decide which policies to use in a given context. Figure 8 provides an example of Policy Editor.


Figure 8: Sample Policy Editor

SDX Admin

SDX Admin is a GUI that a service provider uses to add, modify, and delete services, network definitions, and advanced configurations within the SDX software. For small installations and demonstrations, SDX Admin can be used to create and modify retailers, users, and subscriptions to services.

As shown in Figure 9, two panes make up the SDX Admin interface:


Figure 9: SDX Admin panes

From SDX Admin, for example, you can create and define a new service, define a grouping of virtual routers, or define a new retailer in a wholesaler environment.

Also, using SDX Admin, administrators can set the language for SDX interfaces so that information can be displayed in the language of choice. The language environment is set globally on the host that is running the SDX Admin software.

SDX Configuration Editor

The SDX Configuration Editor is an XML-based GUI that administrators can use to configure SDX components that store data in the directory. The SDX components that you can configure are the SAE, NIC parameters used by portals, and the Script Invoker and Content Provider Web applications. Some of the parameters that you can configure include LDAP connection parameters, logging, router access, plug-ins, RADIUS accounting and authentication, HTTP access, the Enterprise Access Service Port (EASP), and the license manager.

The SDX Configuration Editor is a plug-in to the Eclipse platform (http://www.eclipse.org) and presents .xml property files as forms in which you edit configuration elements.

SDX Gateway

The SDX gateway 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 SDX gateway offers the following Web applications:

SDX Web Admin

SDX Web Admin is a series of Web applications that let you use a Web browser to configure, manage, and monitor various SDX components and related infrastructure components. This section describes each of the SDX Web Admin applications.

Admission Control Web Admin

You can use Admission Control Web Admin to monitor the ACP and reorganize the backup directory. Admission Control Web Admin displays information about:

NIC Web Admin

NIC Web Admin allows you to:

Policy Web Admin

Policy Web Admin allows SDX operators to connect to a directory and search for:


Figure 10: Sample Policy Web Admin

Prepaid Account Web Admin

Prepaid Account Web Admin allows you to manage prepaid accounts. You can create, list, update, or clear prepaid accounts.

SAE Web Admin

SAE Web Admin allows SDX operators and developers to manage and monitor the SAE. They can:

Figure 11 is a sample screen from SAE Web Admin.


Figure 11: Sample SAE Web Admin

Service Activation Engine (SAE)

Along with the Common Open Policy Service (COPS) policy engine, the SAE performs data-processing tasks and interacts with other systems (such as a JUNOSe router and the RADIUS server) to retrieve and disseminate data in the SDX environment.

The SAE implements the SAE core API, acts as a policy server, and implements the COPS server that communicates with the JUNOSe router. The SAE depends on information stored in a directory.

The SAE manages subscribers and services by sharing subscriber sessions and service sessions with its associated routers.

SDX Accounting

The router and the SAE generate RADIUS accounting records when subscribers access the Internet and use SSP services. The records are sent to RADIUS accounting servers and logged in accounting log files. External systems collect the accounting log files and feed them to a rating and billing system.

Accounting Policy

The SAE defines the policies that control the network traffic for the subscriber based on the subscriber's subscriptions. It also determines the accounting statistics collected for the subscribed service.

While defining the policies for a service, the SAE can choose the policy rules to be used for accounting per interface direction (ingress and egress). Statistics are collected for the chosen policy rules for the service and sent to the RADIUS accounting server. The SAE can also decide not to collect any policy rule-specific statistics for the service. In this case, only session times are sent to the accounting system when the service is deactivated. When choosing multiple policy rules on traffic direction for statistics collection, the statistics are summarized by adding the individual values.

Subscription Process

Once an outsourced service is set up, subscribers can order primary access or value-added services from retailers, who in turn notify the wholesaler of the new end subscription. Conversely, accounting data is collected by the wholesaler and communicated to the retailer to provide enough data for the retailer to bill the subscriber.

The overall subscription process is simplified:

Tracking Subscriber Sessions

The intelligent service accounting function of the SDX software tracks the subscription activity for each subscriber and each service session. It collects usage information and passes the information to the appropriate rating and billing system.

Multiple service sessions can be activated simultaneously for a user and can be tracked separately from an accounting standpoint.

Events are generated when service sessions are activated and deactivated, and during interim accounting updates.

Accounting Plug-Ins

Plug-ins allow service providers to easily extend the capabilities of their systems through the use of plug-in software. See Plug-Ins and Public Interfaces for information about these plug-ins.

Interim Accounting

The router and SAE generate interim accounting records for broadband primary services (through PPP) and SSP services, respectively. RADIUS servers log the interim records in their accounting log files when interim accounting is enabled.

The external rating system calculates the charges by using interim records instead of stop records for timeout sessions. This occurs when the last record is interim and for open sessions whose last record at the end of a billing cycle is interim.

An accounting interim interval is defined for each service and applied to all subscriptions to that service. The router and SAE generate accounting requests with a status of interim for every period of time specified with the interim value.

The router receives an accounting interim value for a session through a RADIUS server when the router makes an authentication request. If the RADIUS server does not provide a value, then the router does not generate interim accounting records.

The SAE obtains an accounting interim value from the directory. When the accounting interim value is not stored, the SAE uses global values. When a value equals zero, the SAE does not generate interim accounting records.

Service Selection Portal (SSP)

The SSP provides subscribers with access to services, and can locate a specific SAE by using information that is dynamically obtained when subscribers connect.

Because the data-processing function of the SDX software is separate from the access function, you can easily integrate the SDX software with existing portals, regardless of the technology used to deliver the portal. If your portal environment provides schemes for checking availability of Web servers and balancing loads between Web servers, you can also take advantage of these schemes for the SSP.

Toolkit of APIs and Sample Portals

The SDX software includes a toolkit of APIs for developing Web-based portals, as well as a set of documented sample Web applications that demonstrate the use of these APIs. The sample portals are compatible with industry-standard J2EE application platforms that support the Java Servlet and Java Server Page (JSP) technologies. The sample portals are designed to be highly customizable and can be used for many applications with minimal development and integration effort. Portals developed with the APIs can run in any Web environment that supports CORBA or SOAP.

Web-based portals can be tailored to a service provider's presentation needs and customized to each individual subscriber. Dynamically generated from information stored for subscribers, the portal pages give subscribers instant access to personalized services, without the need to interact with customer representatives. Proprietary client software is not required; subscribers can use a standard Web browser on a workstation or a PDA.

Using the SDX software gives subscribers more control over their service choices and helps service providers build closer bonds with subscribers and with retail partners, while letting providers retain control of their network.

Plug-Ins and Public Interfaces

Service providers can use SAE plug-ins and APIs to extend the capabilities of their systems.

Examples of plug-ins are accounting and authentication, admission control, customized accounting and authentication, and prepaid access.

The SAE provides two public APIs and an SPI:

Through these interfaces, an external application can track and control subscriber and service sessions.

SAE Core API

This API is used to control the behavior of the SDX software. There are many uses of the SAE core API. For example, it can be used to provide subscriber credentials information (username/password) or to request service subscription activation/deactivation for a user.

CORBA Remote API

This API provides remote access to the core portal API. All functions that are available through the SAE core API are available through the CORBA remote API. The remote API provides several extension interfaces that allow customization of the API for special needs.

CORBA Plug-In SPI

The SDX software includes a CORBA-based session-tracking plug-in SPI. This SPI enables linking the rest of the service provider's operations support system (OSS) with the SDX software so that the OSS can be notified of events in the life cycle of SAE sessions. For example, plug-ins can be notified when a user attempts to log in and begins the authentication and authorization process. This notification makes it possible to consult general data and resource allocation information available to the OSS in the making of authorization decisions.

The QoS-tracking plug-in (QTP) provides a way to dynamically manage QoS profiles on JUNOSe routers. The QTP ensures that as a subscriber activates and deactivates services, the required QoS profile is attached to the subscriber interface. With the QTP, the QoS profile selected is based on the activation state of an aggregation of services, not just one service.

SNMP Agent

The SNMP agent monitors system performance and availability. It can be installed and runs on all SDX hosts. It monitors host resources and SDX software running on the host. The agent obtains information from traps through SNMP and SAE Web Admin. It can monitor any SDX process running on the host and comes preconfigured to monitor SDX processes such as those associated with DirX, Interlink RADIUS, and OpenLDAP. Additionally, it provides detailed monitoring and configuration of SDX server components such as the residential and enterprise portals, the policy engine, and the Workflow application.

The SNMP agent provides SNMP version 1 (SNMPv1) and SNMPv2 interfaces to support integration with HP OpenView and other network management systems. The agent also provides network management systems (such as HP OpenView) with SNMP trap notifications in case a component fails or when critical resources are out of limits. The limits are configurable.

SNMP Agent MIBs

The SNMP agent MIB consists of the following modules:

See RFC 1213 - Management Information Base for Network Management of TCP/IP-based internets: MIB-II (March 1991).

Volume-Tracking Applications

VTAs enable providers to track the volume of data that subscribers upload and download. By tracking this information, service providers can respond to situations in which subscribers exceed their bandwidth limits. Typical responses include:

The SDX application library includes two VTAs:

VTAs use accounts and sessions to manage VTA subscribers. A VTA account represents the resources available for a subscriber. A VTA session is a period of activity between a subscriber and a VTA. VTAs require use of a relational database to store information about accounts and sessions.

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. We provide sample portals for Quota and Threshold VTAs.Figure 12 shows the VTA architecture and the position of a VTA in the SDX network.


Figure 12: VTA architecture and position in the SDX network

The VTA comprises a server and a client. The VTA server runs in a J2EE server and comprises several components. These components acquire data from the SAE and from the VTA client, process the data to determine the action the VTA should take, store and retrieve information in the attached database, and take action to control how subscribers transfer data. The VTA client is a Web portal for administrators and subscribers. Administrators can manage VTA subscribers and view the status of VTA transactions via the portal. Subscribers can view the status of their transactions, and purchase enhanced data transfer services via the portal.

Quota VTA

Quota VTA limits a subscriber's access rate based on the balances of accounts that record the subscriber's use of network resources. Subscribers periodically receive a quota of transfer volume (periodic quota) that they can use to upload and download data. They can also purchase additional volume (bought quota) 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.

Subscribers managed by Quota VTA require a subscription, either through an individual or shared profile, to a quota service, which provides a better quality of service than the default. When a subscriber logs in to the SAE, the SAE tries to activate the quota service. However, if neither account has a positive balance, the VTA deactivates the quota service, and the SAE reverts to the default policy or a policy that supports a service with a lower bandwidth to the subscriber.

Threshold VTA

Threshold 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.

Each subscriber must have a subscription, either through an individual or shared profile, to a Behaving service and a Misbehaving service. The Behaving service forwards traffic, assigns a high QoS profile to traffic, or assigns a fast rate limit to traffic. The Misbehaving service assigns a slow rate limit to traffic.

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 benefit from the SSP and 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.


Figure 13: SDX Workflow APIs, protocols, and scripts

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.

HTTP

The Workflow application also uses HTTP to send and receive messages to and from external provisioning systems. These messages are usually encoded in Extensible Markup Language (XML).

E-Mail Send/Receive Protocols

The following e-mail send and receive protocols are used in the Workflow application:

Extensible Markup Language

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.

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:

[Contents] [Prev] [Next] [Index] [Report an Error]