What every business should know before deploying Wan
connectivity technology
Most large, multi-site businesses have either moved to
multi-protocol label switching (MPLS) wide area networks or intend
to do so within the next year. At least 14 providers in the UK now
offer MPLS, which is fast becoming the defacto Wan standard for
connecting offices.
Most companies will change over to MPLS because it is the most
economic Wan offered by their service provider and may even be the
only Wan service available.
However, after the deployment decision is made, many will try to
take advantage of the different classes of service on offer to
ensure consistent application performance. MPLS is a popular choice
as it lies at the confluence of needs from users and service
providers.
Service providers encourage migration to MPLS because it lets them
make cost savings, but also to offset the commoditisation of
bandwidth by offering customers more "value".
It also offers providers opportunities to expand services by
allowing differentiated performance for business networks; a
concept often marketed under the apparently interchangeable
acronyms of class of service and quality of service.
For businesses faced with static or reduced IT budgets, the need to
cut the costs of the Wan - typically the next biggest IT
expenditure after salaries - sits uncomfortably with the continued
deployment of new bandwidth-hungry applications. "Webified"
applications, consolidation of servers and plans to deploy
latency-sensitive applications such as VoIP all need more
bandwidth, or better management of bandwidth. By separating
applications into different levels of service, the goal of
application quality of service seems attainable.
However, MPLS is a carrier core technology. Contrary to the common
assumption, it does not extend to user premises and has little
benefit at the interface where large Lan bandwidths meet the
limited access speeds of the Wan leading to the carrier core.
Unfortunately, most application performance problems occur at the
Lan/Wan interface, with large, bulky data flows, such as database
replication, contending for bandwidth with thin, latency-sensitive
application flows, such as Citrix or VoIP. This lack of control at
the edge is why classes of service simply cannot equate to quality
of service.
Deploying an MPLS core network to deliver quality of service will
not yield end-to-end quality of service for applications. The link
from the Lan to the MPLS core is typically the lowest-capacity
portion of the network. It backs up with deep queues in the router
and introduces the most latency. To make matters worse, it can also
present a problem in ensuring compliance with a service level
agreement.
In the real world, the average company numbers its key business
applications in the hundreds, and the largest enterprises support
in excess of a thousand applications. The problem that faces the
company with an MPLS network, which supports only a handful of
classes, is how to map applications to classes of service.
Deciding which application to map to which class of service and
which other applications should share the same class is a critical
decision in developing the Wan architecture. But few organisations
know how much bandwidth is used by each session of an application,
or how many sessions are used at any one time. It is often "best
guess" as to how large a class of service should be requested from
a service provider and what guarantees about jitter and latency are
required.
Even if the enterprise has characterised its own suite of
applications, most service providers only map applications to
classes of service based on the TCP port number or VLan of the
application. Most applications share the same port number. For
example, casual web browsing uses port 80, as does internet radio
streaming, which cannot be distinguished from business-critical
HTTP XML traffic. As a result, in a normal MPLS implementation,
there is no guarantee that the applications within a class of
service are those that should be there.
Because MPLS networks are based primarily on router technology, the
classes of service and reporting gained from them to offer SLAs are
not "flow-aware". When congestion causes router queues to build at
the Lan-Wan edge, data packets within a class may be placed in
different classes of service with different performance agreements,
or dropped completely with no reporting as to the specific
applications or users affected. But if the service provider fails
to report that applications in premium classes do not perform as
expected, the enterprise will take the blame for offering too much
traffic.
This will be a particular problem as enterprises take advantage of
the distributed routed mesh that MPLS enables.
Today, most application traffic flows mirror the physical network
topology of a star and hub architecture. Most servers are located
centrally with clients at the edge. But with the deployment of IP
telephony, which needs a complete mesh to offer quickest routing
between offices, and new applications, flows will become
increasingly meshed in nature.
This presents a real challenge since traffic flows at remote sites
can no longer be measured at the nexus, and monitoring and
management of traffic will have to be undertaken at all remote
sites. If it is not, applications that continue to flow to the core
will contend for bandwidth with applications that flow into the
mesh. The loss of visibility will mean that contention between
applications will go unseen and unreported until disgruntled
end-users start ringing the helpdesk.
Roger Hockaday is EMEA director of marketing at
Packeteer
