×

TMCnet
ITEXPO begins in:   New Coverage :  Asterisk  |  Fax Software  |  SIP Phones  |  Small Cells
 

Feature Article
September 2002


Taming The Complexity

BY MIKE MARKS

Service providers have known for a long time that they�re not going to get rich carrying commodity-level, flat-priced traffic. Their ultimate success lies in their ability to attract customers with high-margin services such as virtual private networks and enhanced broadband services. Before they can do that, however, they need networks that recognize and prioritize different traffic streams according to how quickly and how smoothly they have to get from point A to point B. That accounts for the growing number of QoS (quality of service) projects afoot at service providers all over the world.

QoS gives service providers the platform for creating high-margin services. Distinguishing high-priority traffic from lower priority traffic enables a QoS network to support a demanding service like Voice over IP (VoIP), which has very low tolerance for delay or packet loss. The QoS network recognizes the VoIP traffic stream and routes it through ahead of less sensitive traffic � e-mail, for example. Customers get � and usually demand � service level agreements (SLAs) guaranteeing their most important traffic gets top priority.

At least that�s how QoS networks are designed to work, and probably will, eventually. But just designing a network with QoS features is only half the battle. The other half is making sure it runs right after the network architects leave and the operational staff takes over.

QoS� success at helping service providers meet SLA requirements hinges on operations� ability to fine-tune the complicated routing tables and queuing priorities the network architects designed. Left unaided, operations staff will have a hard time doing that because QoS-enabled networks are orders of magnitude more complicated than anything they�ve had to run before. Operations staff needs built-in management intelligence to track down problem areas, interpret the causes of service degradation, and plan solutions. They also need it for routine tasks, such as capacity planning, that keep the network running smoothly day-in and day-out.

Manageability can not be an afterthought in the move toward QoS. Companies should think about integrating management intelligence, in the form of fault and performance management software, during the QoS implementation phase. Focusing on management at that early juncture helps ensure that QoS investments pay off in IT infrastructures that deliver predictable, reliable performance.

Unraveling The Complexity Of QoS
QoS relies on complex labeling and queuing schemes such as MPLS (multiprotocol label switching) and DiffServ (differentiated services) to establish different classes of service � the often-cited gold, silver, and bronze levels � among voice and data traffic flows. These new capabilities build on the established transport protocols, such as ATM (asynchronous transfer mode) and frame relay, and are distributed in end-user sites, on the edge, and in the core transport network.

Merging these technologies certainly addresses the challenges of managing multiple traffic streams across a single network, but the sophisticated automation built into QoS-architected networks do not immunize them against routine operational issues and long-term performance degradation. Even if keeping highly educated network architects to run daily operations was economically feasible, it�s a waste of talent and a concession that we have failed to build inherently manageable networks.

Operational staffs need management applications that span the range of protocols, technologies, and devices comprising QoS-architected networks. Those management applications must retrieve relevant information from every network component and compile it in information operational staff can understand. The right tools interpret the queuing and prioritization schemes and deliver enough intelligence for operational staff to perform key daily tasks such as capacity planning, service assurance, and SLA monitoring. Truly effective management tools are flexible enough to enable operations staffs to perform these functions on new technologies without raising headcount.

Managing QoS
QoS architectures are now moving out of the theory stage. Supporting technologies, such as MPLS and DiffServ, are beginning to be deployed in large-scale, real-world networks. Network architects have rarely faced high-volume use in a QoS environment, making it difficult to match performance projections to reality. When companies begin deploying new gold, silver, and bronze-level services to customers, they will need to modify the networks to accommodate real-life requirements.

If formerly �one-size-fits-all� bandwidth is divided between high priority, medium priority, and best effort traffic, what has to happen to the medium-priority and best effort traffic so that the high-priority traffic gets through unimpeded? Just how much can performance degrade, before one can classify the traffic treatment as neither �best� nor even much of an �effort?�

Network architects design QoS networks to queue silver and bronze priority traffic so gold traffic gets top priority, with some acceptable limits of packet delay and packet drop. The question quickly arises, however: How much packet traffic can you delay or drop in the real world before silver and bronze service starts to get tarnished to the point the provider is violating its SLA with the customer? Although the customer may be paying less for the lower priority traffic classes, they are still customers, they are still paying, and they still expect the service provider to meet its SLA commitments, even if the requirements are less restrictive than they are for the highest priority traffic.

Network architects with theoretical knowledge and extensive mathematics backgrounds can look at the raw performance numbers generated by a router or application and intuitively understand what the problem is, and how to correct it. By the time QoS networks go live, however, the network architects who built the new systems will have moved onto the next project. Operational staff is on the firing line now.

Operational staff will have to adjust the packet loss rates and provision bandwidth to accommodate all traffic streams at the prescribed levels. To do that, they need to identify problems quickly and, if necessary, report to the customer that they�re not buying enough bandwidth to accommodate their combined gold, silver, and bronze traffic.

Management And Reporting For QoS
Let�s consider a prototypical customer-provider scenario. After carefully weighing a customer�s bandwidth requirements for different classes of service, the service provider sells the customer 10MB of bandwidth for gold traffic with specific SLA commitments for performance on traffic inbound to the service provider�s network, and outbound to the customer�s sites. Based on the customer�s expected usage, and the service provider�s QoS policy, the service provider may attempt to carry any traffic in excess of 10MB, so long as there is room on the network to support it. If the customer exceeds its bandwidth allowance for inbound traffic, but sufficient room on the network to carry the overload does not exist, the provider will drop packets, according to the service policy. When that happens, the service provider must be able to show the client immediately, and in an easily understood format, what happened and why they might need to buy more bandwidth.

The service provider must help the customer understand whether the traffic exceeded 10MB because of a random occurrence, or because a general upward trend in usage and capacity. The service provider must also have a way of tracking which packets were dropped because the customer violated the service policy, and which packets were dropped due to the performance of the network. Conveying this information to the customer is particularly difficult. If the traffic was dropped because the customer exceeded the service contract for gold traffic, the �blame� for the dropped traffic falls onto the customer. Not many customers will accept that responsibility, and not many customer service staff will relish the possibility of that conversation.

In both of these real-world scenarios, much hangs on the service provider�s ability to provide carefully distilled information to its own staff and its customer. The provider�s management application must produce easily comprehensible, graphical reports with backup drill-down data on very short notice. Until recently, network monitoring and management software was not considered a customer-facing application. It only had to support technical operators and engineers working internally. However, with systems and applications being extended outward as services, business-level people and customer service agents also need reports they can understand.

If a management component is designed into the QoS architecture, it�s more likely to provide meaningful information to operations staff and customers. Thinking about management up front helps network architects anticipate issues and consider what information operations staff will need to respond to them. Companies that deploy management software that provides network-architect-level information in usable formats to the operations staff and customers will be able to make adjustments to the QoS architectures without firefighting or increasing head count.

What To Ask For And Expect
Either proprietary or packaged software can perform the variety of monitoring and reporting functions QoS management requires. Different products have different strengths, but there are basic capabilities any management product should have and basic metrics they should collect.

Management technology must deliver information about packet loss, delays, bandwidth utilization, and the like, to operations staff in comprehensible reports supported by drill-down data. This data reinforces SLA compliance with customers, for each of the classes of service deployed over the QoS enabled networks. It helps operations staff proactively identify service degradations before they affect customer service. It also helps them respond to potential trouble on higher classes of service first, thereby protecting the most important traffic.

Management technology must also provide the information operations staff needs to determine when and where additional bandwidth is needed, whether and how to adjust traffic prioritization policies.

QoS architectures are rising to address the challenge of differentiated services. With QoS, however, come fault and performance management needs that traditional management software cannot meet. QoS-enabled networks promise economical voice and data transport. Building in management intelligence ensures the customer revenues they bring in on the front end don�t disappear as higher operating costs on the back end, saving service providers from hiring more operational staff to deal with growing complexity.

Mike Marks is director of service provider product marketing at infrastructure management software provider Concord Communications, Inc. For more information, visit the company�s Web site at www.concord.com.

[ Return To The September 2002 Table Of Contents ]



Today @ TMC
Upcoming Events
ITEXPO West 2012
October 2- 5, 2012
The Austin Convention Center
Austin, Texas
MSPWorld
The World's Premier Managed Services and Cloud Computing Event
Click for Dates and Locations
Mobility Tech Conference & Expo
October 3- 5, 2012
The Austin Convention Center
Austin, Texas
Cloud Communications Summit
October 3- 5, 2012
The Austin Convention Center
Austin, Texas