Life on the Edge: New Devices Give Providers Advanced Service Options
Hanna Hurley
07/01/2001
The network’s edge is gaining heft from additional devices that could improve customer performance and monitor SLAs. These new boxes mean more metrics. But can billing systems handle the extra weight?
A new class of devices has besieged the network edge. At the border of the service provider’s network and the customer, these newcomers shape, prioritize and monitor customers’ IP traffic. They promise service providers advanced SLAs, tiered services and bandwidth guarantees.
These hardware devices, which generally communicate with routers and other network elements, allow service providers to offer SLAs above and beyond uptime, availability and latency. Instead, they gather performance statistics such as bandwidth usage, application and response time, then tie these metrics to customers. The importance of this information, especially when used in conjunction with customer data, can be crucial to overcoming network bottlenecks and intelligently using available resources.
If stranded at the edge, these devices provide few benefits and are hardly worth their weight. They must be integrated with multiple back-office OSSs to take full advantage of network management, policy management, provisioning and billing support (see “Integration Progress,” for a look at the work already under way by some OSS providers).
In typical fashion, though, service providers have had difficulty integrating the edge devices with their OSSs, which has slowed the boxes’ adoption rate and limited their functions to a single task rather than multiple duties.
The tools are more likely to be used to limit customers’ bandwidth usage rather than rate usage statistics at variable times and correlate them to an SLA. Those days are coming, claims Azi Ronen, executive vice president of marketing and technology at Allot Communications. “We see service providers in the first phase of development where these tools help them contain customer usage as they build their broadband network. In the second stage, our customers will offer more tiered services, which will lead to self-provisioning and usage-based billing.”
Edge Devices and Initial Deployments
Before a service provider can take advantage of the edge device’s support for tiered services and SLAs, it must integrate the boxes with the billing system as well as the customer care directory, database or other repository that contains the customer SLA information. With integration plans just beginning, the edge devices and their partners are looking to support simpler services, such as bandwidth management, bandwidth usage, video on demand and guaranteed access.
Allot relies on Lightweight Directory Access Protocol (LDAP) and RADIUS interfaces for integration. Its centralized management tool, NetPolicy Manager, connects via RADIUS to transfer network data to the billing system and uses LDAP to gather customer SLA information. NetPolicy Manager queries the customer care database using LDAP interfaces to gather all customer policies. This information is downloaded to the NetEnforcer edge devices using Common Open Policy Service (COPS).
To report customer and network metrics, such as bandwidth consumption at the session level, NetEnforcer records each customer session via the RADIUS Open Database Connectivity (ODBC) interface. NetEnforcer records details such as client and server information, the amount of data passed, the type of application and the time. This information can be used to measure bandwidth usage and alert the customer of over usage.
“A customer may have a minimum and maximum bandwidth guarantee. If the customer’s SLA guaranteed 1 Mbps to 2 Mbps throughput, but the customer is sending 2.5 Mbps, 2 Mbps would be transferred and the remainder sent as a favor,” says Ronen. “We can record this information and let the customer know he is working in a gray area beyond the SLA. If the network is loaded, that customer may face delays, so he should consider going to the 3 Mbps level. We could also gather the amount of packets dropped due to the load going beyond the SLA.”
Currently, Allot does not gather availability information or metrics on jitter or delay, but Ronen says these metrics are important for SLAs and will be supported in future releases.
Billing software vendor TeleKnowledge sees Allot and its competitors as enablers of broadband services such as video on demand or online gaming. To create these types of services, the technical characteristics of the service are set in the billing system and the parameters are translated to the policy management application. After the session, the usage is evaluated against the guaranteed QoS parameters.
The company does a one-to-one comparison of the guaranteed traffic parameters to the network parameters to establish whether the customer received the service that was requested. If there was a breach of contract, it is treated as part of the event and put into a rating engine. The rating engine can decide how the customer will be compensated based on data collected and computed.
These services become especially interesting when the edge devices are integrated with customer care and provisioning systems, says Youv Tzruya, director of product management at TeleKnowledge.
This integration, done through a shared LDAP directory or XML-based messages, would allow customers to increase bandwidth for an incremental time rather than an entire service period. When a customer wants to view streaming video, he could increase his bandwidth for only the 10 minutes it would take to view the video, says Tzruya.
“The billing system will keep track of the session and once the time frame has expired, it re-provisions the service with the original characteristics. This type of activity generates events, which must be sent to the rating engine and rated according to the change in quality, type of service or time. After the session, the user can look at his bill to see if the QoS change was done and how the change affected the balance of his bill.”
To make these changes, the rating engine must receive general and specific parameters. Mean time between failure, availability and adherence to bandwidth parameters are some of the general parameters for video-on-demand, while the specifics would be frame rate, audio delays of more than 10 milliseconds and buffering.
“The rating engine must account for metrics beyond the standard parameters of IP traffic,” says Tzruya. “Service received from the infrastructure devices and the application server may speak in different terms, but they must be compiled together to get the final QoS.”
Packeteer is a company that combines analysis and reporting features with QoS and performance control. Its PacketWise product can recognize about 300 different applications and gather metrics such as usage, availability and performance (see Table 1 for more examples). “Most of our customers are interested in gathering metrics about applications,” says Jeff Barker, director of product marketing at Packeteer. “They want coarse metrics like length utilization and more granular information at the application level, such as how much bandwidth is being used for SAP, casual Web browsing or sharing music over the Internet.”
For QoS, Packeteer’s PacketWise allows service providers to set policies, such as rate, priority or discard for different applications. Rate policies can set a minimum bandwidth for some applications, such as reserving 21 Kbps for VoIP or set maximum bandwidths for other sessions. Each FTP download, for example, could be capped at 28 Kbps. Priority policies allocate bandwidth based on traffic rated 0 to 7. Games would get a priority of 0, while Telnet would have a priority of 6. The discard policy blocks the traffic from entering the network.
PacketWise collects its traffic information through SNMP and uses XML APIs to pass the usage, response time, end-to-end response time, service level compliance, or application availability to the billing system. Barker says the billing system can automatically request usage information and collect the comma-delimited data from PacketShaper using XML, which is then dropped into the billing system’s rating engine.
Barker doesn’t expect Packeteer’s and other edge devices to be used to facilitate usage-based billing, but he does see them as a method to enforce usage-based policies. “Service providers’ enterprise customers want predictable expenses,” he says. “Using our tool, providers can offer a flat rate that enforces bandwidth or usage policies.”
PacketWise’s reporting features, Barker explains, can let an enterprise customer know exactly how its users are sharing the network. The reports could reveal that 40 percent of the bandwidth is being used for sharing music. By setting policies that only allow a percentage of the bandwidth to be used for music sharing, more bandwidth will be available for business-critical applications.
Sitara has many of the same capabilities as Packeteer. Its QoS mechanisms include TCP rate shaping, class-based queuing, fair allocation of bandwidth by connection, packet size optimization, ability to borrow bandwidth from idle classes, and caching.
Sitara’s QoSDirector uses XML, HTTP, SNMP and command-line interpreter (CLI)-based APIs to export data to the billing system. It can exchange SLA information in existing LDAP-based directories.
“More customers are talking about delivering QoS guarantees for multimedia or VoIP than delivering it,” says Bob Steingart, vice president of strategic alliances at Sitara. “Right now our customers are interested in knowing how much bandwidth is being used and setting limits to bandwidth usage. They want to know burst rate, packet loss, latency and jitter information.”
Sitara sees the hosting arena as one short-term opportunity for edge devices. Currently, most service providers have little control over access to the centers, explains Steingart. Sitara can provide access guarantees for customers by setting a policy to 1 Mbps for each pipe, which can burst above that setting if more bandwidth is available.
Deciphering the Metrics
These edge devices are fulfilling their promises of setting QoS and improving performance, but SLA management is falling short. The shortcoming is due to two problems: too much data and an inability to correlate network performance with the SLA.
All their metrics and parameters combined with customer policies are creating more data than most billing systems can handle. The multiple if-then scenarios that depend on the metrics and policies pulled from network devices, databases and directories are too complex.
“The devices produce more data than the billing systems need, but the metrics do not have the granularity we need,” says Susan Culler, vice president of marketing for the Tapestry product line at AMS. “We may need the time of the beginning of the session and the end of the session, or data on the entire session, but these tools may only have stats on every 15 seconds or give us an average of all the usage. We need a finer level of detail to provide more useful SLAs.”
The device manufacturers counter that their customers are more interested in groups of records. “There is nothing interesting about each HTTP session or each line to the server,” says Allot’s Ronen. “There’s no reason to collect the information in separate records. They should be in total records. This allows businesses to see how many bytes are used for FTP and VoIP.”
Combining records also lowers the toll on the devices and ensures they can perform, adds Ronen. “If we can accumulate the details from several sessions,” he says, “we can save NetEnforcer’s resources for calculation and bandwidth management.”
This disparity between the device’s averaged statistics and the need of the billing and customer care system for granular statistics has stalled service providers’ ability to offer quality-based SLAs. Applying these metrics to each customer, says Joan Garrett, vice president of marketing at Dorado Software, will lead to more customer-centric SLAs.
Another problem stalling SLAs, she says, is that the customer care systems that store the SLA information are rarely correlated with the network performance data. Instead of one-to-one integration efforts, companies like Orchestream and Dorado claim service activation software, which flows through all devices and systems associated with a service, is the best solution.
“Many vendors can monitor SLA performance based on bandwidth performance, but the disconnect is in audit mode. They can’t take the usage stats and map them to the traffic reports and engineering report,” explains Garrett. “OSS needs to support the capability to pass real-time network usage data to the billing system or customer care system. More CRM systems must be integrated to know what service is invoked and why.”
Orchestream’s CTO Benedict Enweani agrees that network performance must be integrated with all OSS for useful SLAs. “The services performance must be measured against the performance of the network,” he says. “All systems must understand the relationship of the services deployed and the physical equipment used to deliver those services.”
Instead of just one device that monitors a VPN or any service, Enweani explains, all network components of that service must be monitored: “The customer profile and the service must be combined with the data collected from the physical devices, correlated, and presented in a format prescribed by the SLA.”
Are Edge Devices Overcommitted?
Positioned as policy monitors, traffic shapers and service deliverers, the edge devices have dipped their toes into multiple OSS streams. The multidimensional packages send their carrier customers mixed messages. Are they part of network management, customer care and billing, or provisioning? What, exactly, is their main benefit to service providers?
Like many young companies trying to carve out a niche, they are testing several potential market areas to see which aspects of their expertise pull the most interest. But this anything-to-anyone approach could backfire if the companies make half-hearted integration attempts. For any of their claims to prove true, the edge devices must be integrated, or interact, with multiple support systems. The companies will need to add more partners and alliances, as well as increase their understanding of a service provider’s environment.
Will these companies accept the responsibility to fulfill their claims, or will they shrug it off and place the blame on the limitations of the back-office systems? Hopefully, the hardware providers will be able to work with their OSS partners to extend their capabilities beyond limiting bandwidth and fulfill their promises of quality-based SLAs.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article