Home > Articles > VoIP – making it work on your network

VoIP – making it work on your network

October 3rd, 2005

The benefits of implementing voice over IP (VoIP) – cost reduction through reduced infrastructure, resource reuse and toll bypass – are driving network convergence. Increasingly, all forms of corporate communications are being carried over a single IP network.

While this is desirable for a number of reasons, each service has a different set of requirements which must be satisfied in order that the service operates effectively. Ensuring that no single service monopolises network resources is essential. This can be particularly difficult with VoIP, which requires low latency, low jitter and high bandwidth, while being very ‘bursty’. At the same time VoIP has very high user expectations: if an email arrives a few minutes late this usually goes unnoticed, but users will be very dissatisfied if they pick up their phone and fail to hear a dial tone – especially as they can’t call IT to report the fault!

Traditional network management solutions have been primarily concerned with availability – monitoring device and port availability, and overall connectivity. Less emphasis has been placed on resource management and network performance; with converged networks this is no longer sufficient.

The growth of converged networks, and of VoIP in particular, has to be matched by an expansion in the features offered by network management systems (NMS) at every stage in the life of the network.

Pre-Deployment Analysis

Before converging voice and data, organisations need their NMS to provide a baseline view of the network, including:

What the current network infrastructure and its connectivity is (discovered); Where the clients and servers are located; The bandwidth associated with each server, client, and interface; Which links or devices are currently over or under-provisioned; How network traffic will grow based on current trends.

From here, some of the more difficult questions on data convergence can be answered, the most common being: “How much bandwidth will my VoIP solution consume?” and “Which type of traffic should be prioritised where bandwidth is insufficient?”

The NMS should be able to manage equipment from multiple vendors; most networks’ devices are of differing ages and from numerous suppliers, and they all require monitoring if the entire converged network is to be effectively managed.

Although there are mathematical models to predict the amount of additional bandwidth required for VoIP, most organisations move from experimental test-lab to small-scale departmental use, and finally to full-scale corporate deployment. Even such a cautious approach can still require a leap of faith: the number of users is far greater and spans multiple sites connected by relatively low bandwidth WAN links over which voice traffic must compete with other applications for bandwidth.

A key aspect of VoIP technology is the provision of differentiated services that segregate, prioritise and limit the bandwidth allocated to each type of traffic. Most organisations will use more than one form of traffic differentiation to allow them to protect services and maximise usage of low bandwidth links.

Typically, traffic flows have very differing characteristics, and the protocols used by each traffic class must be considered. For example, loss of Real Time Protocol (RTP) voice traffic, if not excessive, should not result in significant call quality degradation. Dropping traffic using reliable transport protocols can increase network usage still further by increasing the amount of retransmitted data. Balancing these types of protocol/application requirements needs careful analysis and should be an ongoing task as the traffic profile across the network changes.

During the pre-deployment phase, equipment may be relocated from under-utilised to over-utilised areas in order to ‘balance’ the network and ease accommodation of additional VoIP traffic. Accurate discovery of the entire network is a pre-requisite for this, since decisions on equipment relocation carry greater risk where the view is incomplete. This is where NMS network inventory and change reporting add significant advantages.

The NMS should be able to predict call quality across the WAN for each site-to-site combination. It is possible to estimate users’ opinions of the quality of VoIP calls on a point-to-point, and from there, site-to-site basis, using probes to monitor ICPIF (Impairment/Calculated Planning Impairment Factor) and its relationship to MOS (Mean Opinion Score). Hardware probes are expensive to procure and maintain; fortunately, however, there are technologies that can provide these estimates without the need for additional hardware (e.g. Cisco’s Service Assurance Agent).

Some NMSs can help with the creation and management of such probes and can provide monitoring and trending. Furthermore, these probes can highlight the underlying causes of poor call quality and can be used to monitor “in-band” performance in a differentiated services environment (by allowing specification of MPLS labels and DSCP values, for example). Several NMSs offer additional features for monitoring the behaviour and health of the VoIP call placement software.

Once all the preliminaries are in place – hardware located, live traffic analyses complete, bandwidths budgeted and differentiated services planned, the corporate-wide deployment can begin.

Corporate-Wide Converged Network Deployment

Important features required from a NMS during the roll-out phase include:

Good general network management capabilities – especially fault resolution via accurate root cause analysis; Change reporting to maintain historical information on network configuration and performance; Availability monitoring and event generation; Traffic monitoring – especially congestion and traffic loss; Monitoring call quality, latency, jitter and packet loss both in the LAN and across the WAN; Monitoring call control software, and its host; Monitoring key voice components, such as gateways, gatekeepers and IP handsets; View generation on regions of the network that are undergoing significant change.

Careful monitoring throughout the deployment eases the migration progress, mitigates risk and provides an early indication of problems – together with the necessary information to assess the cause, its implications, and to suggest remedial action.

Post Deployment Monitoring

The post-deployment requirements of an NMS also include:

Flexible reporting and trend analysis to allow network managers to predict the amount and impact of growth in network traffic; Efficient and accurate fault identification with symptomatic event suppression; Identification of poor network performance and likely causes; Highlighting utilisation of backup resources; Highlighting the effect of traffic loss through under-provisioned or over-utilised links; Trending on service performance; The ability to generate different views of the network, whether logical, physical or geographical; The capacity to tune performance thresholds from the pan-network level down to individual port level for event generation.

Conclusion

The amalgamation of many different services onto a single network, each with very different requirements and sensitivities, requires the introduction of an extra layer of complexity through the use of differentiated services. A modern NMS operating on a converged data network carrying a range of traffic from email through to eCommerce, database replication and voice has very different and significantly more complex demands placed upon it than traditional NMSs.

These demands are often not satisfied in existing corporate NMS solutions or are provided by an ad-hoc collection of disparate products. Organisations that are migrating to a converged network should consider an NMS which not only addresses all of these needs, but provides interfaces into its underlying architecture and data structures to enable integration with other products as unforeseen needs arise in the future.

Articles

Comments are closed.