Premium Service: Potential fact, or forever fiction?

New protocols that label routing queues and service classes are enabling quality of service (QoS) management at the network's core and edge. Before customers receive service guarantees, though, equipment providers must fine-tune their work to ensure that premium traffic can be validated.

Next time you begin a discussion with a marketing person, set your stopwatch. When "value-added service" pops out of his mouth, check how much time has gone by. Most likely, only seconds have passed.

As buzzwords, "value-added services" rank up there with "Internet," "e-commerce" and "next-generation." While the other terms have moved beyond proof of concept, however, value-added services are still on the whiteboard because of the difficulties of imposing QoS standards. Usage-based billing, premium service at premium rates, and guaranteed service levels solicit endless discussions-but virtually no revenue-because the Internet cannot maintain guaranteed QoS.

For the most part, QoS is viewed as a network engineering problem. Once carriers have overcome the engineering challenges, back-end systems must be able to support the new QoS ratings and statistics. An important key to capturing these data will be the traffic information held in the header used by protocols such as MPLS and DiffServ (see sidebar "Back-end Support for MPLS").

The best route to QoS

Created by Cisco and now before the Internet Engineering Task Force (IETF) for standardization, Multi Protocol Label Switching (MPLS) allows carriers to route connections in a connectionless IP network. The protocol is based on engineering concepts established in Asynchronous Transfer Mode (ATM), and it explicitly routes traffic on an established path set by the routers' labeled switch paths.

Carriers are beginning to use MPLS to engineer the core of their networks. Traffic following an MPLS route can reach its destination faster, because it is following a predetermined route that avoids network bottlenecks. The router compares each IP packet with its routing table and forwards the traffic based on the header's source destination. If there is competition for a resource, MPLS will give that resource to a higher priority packet.

"MPLS combines the best of switching and routing, and marries layer two and layer three functionality," says Peter Joy, senior product manager in IP/MPLS for core switching at Lucent.

Routing traffic is MPLS' greatest strength, but it will play a minor part in relaying QoS information. One possible way to use MPLS for QoS would be to monitor the known customer traffic paths. Once the customer's routing paths are established, the carrier could monitor the traffic traveling through the MPLS router's queues for dropped packets, latency, jitter, and other such characteristics.

According to information from the MPLS Resource Center (www.mplsrc.com), MPLS supports the same QoS mechanisms as IP: IP Precedence, Committed Access Rate (CAR), Random Early Detection (RED), Weighted RED, Weighted Fair Queuing (WFQ), Class-based WFQ, and Priority Queuing. Since MPLS also supports reservation of Layer 2 resources, MPLS delivers QoS much like ATM and frame relay does.

But one drawback is the limited space in the MPLS header, IP has six bits available to prioritize QoS; MPLS has three bits. "We are still trying to figure out how to aggregate IP class of service into MPLS class of service," says John Stewart, marketing engineer at Juniper Networks. "You can't do it on a one-to-one basis from IP to MPLS. You have to use fewer IP services, or route multiple QoS classes into a single MPLS service."

In contrast to MPLS, DiffServ is a separate protocol that will probably play a bigger role in QoS because it prioritizes the IP packet. An outgrowth of RSVP (Resource Reservation Protocol), DiffServ was the IETF's answer to RSVP's scalability problems. It uses an empty spot currently in the IP header, and it populates this field with a 0, 1 or 2, which marks the packet's priority level by TOS (type of service) value. Using DiffServ, traffic can be divided into three major classes. Most often these are categorized as premium (high priority, low latency), mission-critical (guaranteed delivery) and best effort (low priority).

Most market watchers expect that the combination of MPLS and DiffServ will move carriers one step closer to offering QoS guarantees. "When you start to turn on prioritization within MPLS, it must be done on some type of architecture. And DiffServ is the perfect choice," says Stewart.

Using the connections set by MPLS and the TOS included in DiffServ, carriers can measure the frames going through designated points on the network. "MPLS defines the link and the conditions, and DiffServ acts as a marker to tell the label switch what type of behavior the packet should receive," says David Drury, vice president of technology strategy at Marconi and president and chairman of the MPLS forum. "By mapping the DiffServ service classes onto the label switch path, carriers can measure traffic flows."

Even Cisco, MPLS' biggest proponent, sees the two protocols as complementary. "MPLS doesn't conflict with DiffServ," says Kurt Kruger, senior manager for VPN solutions for service providers at Cisco. "MPLS allows service providers to use bandwidth effectively and map traffic based on services they are providing or by their capacity planning. DiffServ provides richer services, but the same general capabilities are preserved in MPLS."

Gathering QoS statistics

With best-effort service being the norm, few carriers collect QoS metrics. To do so, carriers will most likely use familiar network performance tools such as probes, mediation equipment and SNMP. As QoS demands become more prevalent and new MPLS and DiffServ-enabled hardware is added to the network, operators will have to fine-tune these processes. At a minimum, QoS tools will have to capture availability, throughput, utilization, error/discards and latency. These metrics will allow carriers to bill by bandwidth, inbound vs. outbound traffic, time of day, international traffic, or priority routing.

Agilent's vision for capturing QoS metrics is to locate probes throughout the network. The test tool maker expects to transfer its experience polling the SS7 network to the IP domain. By probing data links on ATM and IP networks, the carriers can capture specific information about the call setup and the data.

Probes can gather information about the switch, the destination address and usage events. "By looking at specific application measures and tying [them] to network information, QoS metrics and user session, carriers can get a complete mapping of what happened at the physical layer and application layer," says Paul Gowans, product marketing manager for Agilent Technologies' Telecom System Division.

Gowans claims the probe method has a number of advantages over gathering information directly from the network elements. In addition to not affecting the elements' performance, probes provide independent validation of the devices, real-time statistics, and a complete view of the stack and application information.

Another company involved in measuring QoS is Quallaby, a software provider that gathers and reports network performance statistics. Quallaby and Cisco are working together so that Quallaby's system, Proviso, can gather QoS statistics from Cisco's NetFlow using SNMP. Looking at information in the MPLS header, NetFlow is able to capture IP flow, latency, and CAR through Management Information Bases (MIBs). Cisco is providing Quallaby with MIB information, but since CAR information is relatively new, it's taking some time to finalize the requirements.

"By examining each router, each queue, and the physical interface, you can define how many packets were transmitted and how many were discarded," says Francois Caron, senior product manager for Proviso at Quallaby. "It's a good way to measure if the commitment and QoS have been met by the service provider."

Another software provider, CrossKeys, is also using QoS metrics in its Resolve tools to provide service assurance. By polling network devices such as access points, standalone routers, remote access servers and Web servers, Resolve captures network statistics using SNMP. This information is compiled in a database and correlated with SLA information, which is then passed to the billing system.

"By setting thresholds according to latency parameters, you can see if the quality was violated. The information is then entered into the billing system so that it can be rated accordingly," says Jennifer Koussaya, product marketing manager.

For companies such as Resolve that rely on MIBs for their statistics, it's unclear whether DiffServ and MPLS will be able to provide the necessary QoS information. "The challenge will be collecting the MIB and being sure that the MIB picked up the right information to make the SLA meaningful. We will need granular information for our reports," says Koussaya.

Adding QoS into the network

Carriers' efforts to establish MPLS in their core have not been completely successful. The usual interoperability issues between different manufacturers' equipment have plagued early adopters, and carriers have also had problems with equipment from the same provider.

Outside the network core, carriers are deploying MPLS and DiffServ equipment along the network edge to enable virtual private networks (VPNs). These managed services are the first QoS offerings that carriers will bring to market. As MPLS, DiffServ and other protocols make the IP network more traceable, carriers will be able to use IP packet information to further improve QoS.

Despite years of QoS and SLA preparation, carriers are still providing only standard guarantees for availability, packet loss and round-trip latency with their VPN offerings. "We haven't seen many live examples of QoS in service providers' networks. It's been too difficult to check and verify traffic at the packet level," says Dave Curley, vice president of sales and marketing at Bridgewater. The typical explanation from carriers points to limited customer demand.

"Our engineering staff is looking at adding QoS into the network, but QoS' real benefits are in a congested environment. If there isn't congestion, it has no value," says John Summers, senior product manager for VPN services at Genuity. "We aren't seeing much congestion on our backbone or the local loop, and I haven't heard a significant cry for QoS from customers. The tangible benefits are unclear."

Thus far, customers have shown limited interest in the applications that were predicted to carry QoS forward-video and voice. Expected to be the killer applications that would build momentum for QoS technology, voice and video delivered at the best-effort level appear to appease customers' needs.

With enhanced video and voice applications on the horizon, providers are looking at alternative uses of QoS mechanisms. Information in MPLS and DiffServ could be used to bring content closer to customers and improve content delivery. "We can look at content information in the packet and improve the quality by caching content or rerouting traffic, based on availability," says Johan Pirot, assistant vice president and CTO of new IP solutions at Alcatel.

A separate area where QoS is garnering attention is capacity planning. Moving beyond best-effort service doubles the planning requirements, according to Juniper's Stewart. "When you collect statistics on the network edge, you know the kinds of traffic coming in. This information is then used to build capacity into the network core. Congestion points will occur if the carrier has not planned adequately for capacity. Tracking QoS stats can help carriers know if they have violated the SLA and what type of traffic has been affected."

Bridgewater tracks network usage by measuring port activity. By tracking port usage, carriers can get premium rates for extra ports. During normal traffic, a carrier may lease 100 ports. If traffic bursts and the customer needs 110 ports, the customer will pay premium rates for the additional ports.

Bridgewater and Allot are combining efforts to enable this service structure. Bridgewater is authorizing the ports, maintaining the policies and tracking the simultaneous sessions. Allot gathers the accounting information, correlates it with the customer's policies and sends it to the billing system.

"By tracking simultaneous sessions, carriers can effectively use their network capacity and put premium rates on overflow traffic," says Bridgewater's Curley.

Improving QoS support

The disparity among carrier networks and the missing must-have applications are two reasons that QoS has generated more talk than action. But an even bigger problem is the lack of back-end support. "Carriers haven't gotten their OSS in order. They are trying to gather usage metrics that can be used for SLAs and service level management, but they can't deliver the data to their OSS," says Agilent's Gowans.

New products that measure and compare received QoS to requested QoS are available, but the data is still crude. The required granularity that would give carriers details on the customers-and the services they received-is just not available.

"Most devices can't provide the basic QoS information we need," says Quallaby's Caron. "Often there is no information in the SNMP agent, or not enough. We need hardware providers to give us information in a scalable way. We can collect it and merge it with the billing systems, but we need the basics."

Often overlooked is the fact that these service assurance products require vast storage space for the data they do produce. Few carriers have the capacity to sift through the terabytes. "The necessary granular information is not available today. And if it were there, carriers wouldn't know what to do with it," says Gowans. "For now, there's no point in gathering metrics that will be chucked into a large database and never used."