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