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
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
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
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
To The September 2002 Table Of Contents ]