SLAs are for everyone

The audit should be aimed at providing the customer with a roadmap to improving their network up to agreed levels of quality, stability, and resilience. As already stated, voice networks have an availability and quality expectation that is far in excess of the typical SME computer network. It is not unusual for availability expectations to be five nines (99.999%), and for the supplier (yes, that's you) to provide a Service Level Agreement (SLA) with penalties if that figure is not achieved.

Some suppliers fight tooth and nail to reduce that SLA figure, but there is no reason to do so as long as you realize they can be a means to gain agreement on who is responsible for which part of the overall system up front, and might possibly differentiate you from the competition if you are in a commercial situation. As long as both you and your customer, whether they are internal or external, are being realistic, there is no reason why you cannot specify that certain preconditions are met before such an SLA can be offered, such as a certain level of bandwidth and latency across the network. You would also need to agree on the line of demarcation between "your" part of the system (such as the server, phones) and the customer's part (such as the underlying network) once any initial implementation work has finished and the enhanced network has been handed over to the customer's operations and maintenance team. But all such discussions should be approached with a view to the ultimate objective. After all, the goal for both sides should be to end up with a great phone system.

Achieving the goal

By now, you've probably agreed with the customer that their network needs work to achieve the agreed service levels. Let's have a look in a little more detail at how that network should look, bearing in mind all the time that the final product will be unique for each customer, given their different needs. Almost always, though, the emphasis will be on making improvements to achieve higher levels of quality, stability and resilience. Here we will look at what is required to achieve the required quality standards. Chapter 7 will explore the topics of stability and resilience in more detail.

In IP networks, quality is usually synonymous with dropped packets, or more accurately with the lack of dropped packets. Traffic across an IP network is not sent in a continuous stream, as in an analog voice network, but rather packaged up into discrete units and sent out into the network with a destination address as part of the package. As suggested by the terminology used, it is not dissimilar to sending packages by post, although in the network each package is pretty much the same size, so larger items are broken up before being sent and reassembled at the destination. It's a bit like getting your flat-pack furniture piece by piece.

Many things can cause these packets to go astray, but the IP protocol has a built-in mechanism (TCP or Transmission Control Protocol) for recognizing this has happened and requesting a resend of the package. This is achieved by including a checksum with each package to ensure that its data is received intact, and by acknowledgement of each package being sent back to the transmitting node. TCP is used for quality-sensitive data, that is, data that requires all the packages to be reassembled if it is to make sense. This is because there is no significant "storage area" for packets on a network, they travel at a certain speed and if they can't be dealt with inside a predefined time, then they are dropped.

For most types of traffic re-sending is usually very effective. After all if your 20 MB file download is delayed by a fraction of a second while a package is re-sent then you probably won't even notice. However, there is an appreciable amount of extra data and traffic generated, which can cause problems in networks that have a time-critical quality requirement, such as voice networks. Therefore, an alternative protocol (UDP or User Datagram Protocol) is used for voice and other "streamed" traffic, as there is no significant loss of perceived quality if small numbers of packets go astray between source and destination. The problems, such as latency and jitter, arise when larger amounts go missing in action.

Within company IP networks, dropped packets typically start occurring when traffic levels get too high. An analog voice network works by setting up a channel with more-than-adequate "bandwidth" between the two parties that is not used by anyone else. Think back to the old switchboard operator moving plugs around on a board, this is exactly what she was doing. An IP network, on the other hand, works on a similar basis to a sorting office, where everything posted converges on a central place (the router on a network) where the address is read and it is sent along the correct path towards its ultimate destination. However, if there are lots of letters and packages in the system, then post boxes can overflow, pickups can be missed, sorting equipment and people overloaded and the whole system would struggle to cope. So it is with a computer network.

Dropped packets in a computer network can frequently be traced to mismatched components, such as the aforementioned hub being used to allow a number of desks to utilize a single network floor port. It's all very well specifying that your comms cabinet be stuffed with Gigabit switches, and that all your PCs have 100 Mbps capability, but stick a 4-port 10 Mbps hub in the middle and the PCs plugged into it will be throttled to 2.5 Mbps or less. Then start adding IP phones on to each desk, or using softphone software on each PC, and you can see how it all gets messy very quickly.

At this point it is worth saying that, for a network carrying voice traffic, using network switches instead of hubs is a no-brainer. Switches go much of the way towards setting up dedicated channels between one port on the network and another, and are much more effective than hubs. The price difference between hubs and switches has reduced significantly in the recent past, removing the greatest barrier to their adoption. If your customer insists on an SLA, you should only agree if their network is fully switched. In fact, being realistic, you should only ever implement a VoIP solution over a fully-switched network as using hubs will cause you problems sooner or later by undermining any other steps you may take to ensure high quality voice traffic.

Furthermore, at the time of writing, Gigabit switches have reduced in price to the extent that serious consideration can be given to using them instead of 100 Mbps switches throughout the network. After all, many new PCs these days come with Gigabit network cards as standard, so putting 100 Mbps switches in your network will, again, artificially throttle speeds. Be aware, though, that there can be a significant difference between a cheaper Gigabit edge switch and a top-end Gigabit core switch, particularly in processing speed. In most cases it's better to have a good quality 100 Mbps core switch than a cheap Gigabit core.

It can be a big task to bring Gigabit ethernet to the desk, though, if the current wiring is not up to scratch. Hence, should the introduction of Gigabit throughout the network be out of scope then there is no serious need for concern. A well designed and implemented 100 Mbps network has plenty of bandwidth for voice traffic, even if it is not as future-proof as it might be.

Backups

One area that can cause problems is if data backups are run across the network during working hours. You'd be surprised how many companies run their backup routines at times when high call volumes can be expected, even during the lunch hour. Such activities have the potential of sucking up 99% of the available bandwidth. For this reason, it is not unusual for larger companies to route server backup traffic over a physically separate network to guarantee that it will not adversely affect front-office activities. For smaller companies this may be too costly an option, so a backup "window" needs to be identified that will occur during low call volume times.

To share or not to share

When designing your voice-capable network, one important consideration is whether or not to carry voice and data traffic on the same network infrastructure. In other words, should you implement a completely separate IP network for your phones, PBX, and Internet circuit? While there are significant benefits to doing so, particularly in terms of assuring bandwidth for voice traffic, in general it's probably not sensible for a couple of reasons.

The first reason covers practicality, particularly around the availability of floor or wall network ports. As many offices were designed around the desire to have one port per desk, it is usually a pretty disruptive exercise to increase that to two ports per desk, as you will need to do if you are to physically separate the voice and data traffic. The customer may also find the increased cost of switches and so on to be quite impractical. The "two ports per desk" impracticality can be assuaged somewhat through the use of VLANs (Virtual LANs), whereby logically separate LANs run side-by-side on the same physical equipment. Often VLANs are implemented by assigning switch ports into groups that allow them to communicate with each other but not with ports in other groups.

In the preceding diagram, we can see that PCs connected to ports 1, 3, 6, and 8 on the switch are on the same VLAN, thus they can communicate with each other but not with any of the PCs connected to other switch ports. Be careful, though, as port-based VLANs will ensure that each port switch will only carry one type of traffic (VoIP or data), which will not remove the need to have two ports per desk if complete traffic segmentation is a "must have" requirement.

There are alternative mechanisms for implementing VLANs, such as tagging traffic based on subnet, protocol, or MAC address. All serve the purpose of separating LAN traffic into logically separate networks on a single physical network, but as the segmentation is not based on a physical connector (that is, the switch port) they will allow for a desk's VoIP and data traffic to be routed over a single network port. Most business-grade IP phones now come with a two-port switch as standard, which allows you to plug the phone into the existing network port, and then plug the PC into the phone. A MAC, subnet, or protocol-based VLAN will then allow you to logically segment the VoIP traffic. The downside of this setup is that if the phone needs to be restarted, there will be a temporary interruption of the network connection to the PC. Make sure the customer is aware of this.

VLANs have the advantage of reserving bandwidth solely for voice traffic, while not necessarily needing to incur the extra cost of multiple switches. This does assume that you have an adequate number of ports free on your current switches if you decide to use port-based VLANs. However, the cost savings are greater when volumes are higher, as you can replace many smaller switches with fewer larger ones. As we will see later, using VLANs can also bring some advantage in increasing resilience to switch failure.

One interesting way around the issue of floor port availability is to use wireless technology for desk phones. Both Wi-Fi (802.11 in its various flavors) and DECT are gaining ground in the VoIP handset market, partly because they neatly sidestep this concern. They also allow for mobility within the workplace in situations where that is desirable, warehouses for instance. In a world where mobile telephony is firmly ensconced, they do not look out of place, although moving from desk phones to mobile handsets in some companies can still be too much of a culture change. It is fair to point out, too, that wireless technology has its downsides, such as:

The Wi-Fi or DECT network of repeaters needs careful design to ensure there are no poor signal areas in and around the buildings and to ensure that seamless handover from one base-station to another can occur. Be aware also that the choice of VoIP codec and Wi-Fi protocol can limit the number of simultaneous calls per base station.

For now, DECT technology is mature enough to warrant serious consideration, but Wi-Fi solutions seem to retain too many issues still, although it is a rapidly maturing marketplace.

Another area that is often overlooked is power. Perhaps it's a hangover from analog phone days, but it's not unusual for customers to be unaware that an IP phone is a powered device. As it is frequently the case that there are too few power sockets for each desk in an office, use of Power over Ethernet (PoE) capable phones and switches is worthy of very serious consideration in all roll-outs. The added cost is only significant in systems with a small number of extensions, and even in these cases it may well be that only certain key phones need to be powered in the event of an outage, reducing the number of PoE switches required. By providing battery backup for the PoE switch and other critical devices, service can be maintained for short periods.

The other downside of completely separating voice and data network traffic is that Computer Telephony Integration (CTI) becomes more difficult to implement. Many IP phones these days have bundled with them software that allows for computer integration, such as selecting a contact from your address book and clicking a button on screen to initiate a call, or having a contact's details pop up on screen automatically when they call you. If, for instance, a company relies heavily on its CRM software, then such integration can save employees a lot of time and thus provide better service to customers. Where CTI is implemented server-side, there is less of an issue as it is relatively easy to add a network interface to the server that bridges the two VLANs/LANs. However, you may have network security engineers up in arms if you implement such a bridge!

Ensuring quality

Should you decide, for whatever reason, to carry voice and data traffic on the same network, then there is one network service you should implement if you are to avoid voice performance issues. We are assuming that you have already ensured that the network is at least 100 Mbps end-to-end, and preferably Gigabit. However, this alone is not enough, particularly if you are working to an SLA. Fortunately, this issue has been recognized and addressed through the Quality of Service (QoS) protocols.

Quality of Service is simply, as its name suggests, a means of ensuring quality on an IP network. A typical IP network will carry traffic for many different services, whether they be very much in the background (NTP or Network Time Protocol might be a good example of this) or quite obvious to the end user (HTTP for instance).

While most of these services can tolerate some delay as packets are re-sent, occasionally a network may run a service that is time-critical, such as voice traffic or streaming video. Using QoS on managed switches or routers, time critical traffic can be given a relatively high priority so that, if bandwidth is limited, such traffic is delivered before lower priority packets. There may also be mechanisms for allocating a portion of the available bandwidth solely to certain services.

If you are required to offer your customer an SLA on a network that shares voice and data traffic, then you should insist on QoS being implemented. Otherwise, the first time a user downloads a large file from the Internet, voice quality will plummet. It is also worth remembering that, to be truly effective, QoS needs to be implemented throughout the extent of the route that is bearing shared traffic. In other words, there is little point in having QoS on your LAN if, once the traffic is passed on to your ISP, there is no QoS for the rest of the route. The easiest means of addressing this problem is to have a dedicated voice circuit outside the LAN. For a small business this may mean one ADSL line for voice traffic and another for other Internet traffic, for instance.

There are two approaches to QoS—IntServ and DiffServ. IntServ allows a very fine level of control of QoS parameters, where you can determine the quality levels for each individual flow of traffic. IntServ requires that all routers that could potentially carry traffic between the nodes on a network are compliant and store all the configuration information for each traffic flow on the network. There is a significant overhead involved with this approach as the number of nodes grows, which obviously does not scale well to a network the size of the Internet, and so is not a common approach for VoIP installations.

The more common QoS implementation—DiffServ—does not offer quite the same level of control, but will scale much better. It requires all traffic to be categorized into a number of classes, which then have the quality rules applied to them. Usually, the classes are rated from 0 (lowest quality) to 7 (highest quality). In a router, packets are examined to determine which class they are in, and held in one of a number of queues until their 'turn' has come to be transmitted. This can actually result in an increase in network traffic if too many low-priority packets are being held in queues until they expire, resulting in the need for re-transmission.

A successful end-to-end QoS implementation requires that all routers in the path are configured to treat each class of service in the same way. Therein lies the problem with most commercial VoIP implementations, as it is usual for the customer to have little or no say in what happens to traffic, regardless of which class of service it is tagged with, once it leaves the LAN and starts traversing the ISP's network and the Internet. It is also possible that an ISP's customers would try to gain an advantage by categorizing all their traffic as highest quality. Therefore, most ISPs will apply their own rules to traffic traversing their network, a technique known as traffic shaping.

Bearing all this in mind, is it still worth implementing QoS within a LAN? I would have to say that if you are carrying voice and data traffic on the same LAN then it is, mainly because it will prioritize voice traffic between the PBX and the phones, and also ensure that outbound voice traffic is presented to the ISP before less time-sensitive traffic. In particular, it will ensure that a user downloading a large file will not suddenly grab all the available bandwidth. But you, and your customer, should be aware that it does not guarantee high quality external calls, it merely mitigates some of the risks. As previously stated, a dedicated voice circuit is the easiest means of addressing this problem (outside the LAN). For a small business, this may mean one ADSL line for voice traffic and another for other Internet traffic, for instance.

When things go wrong

However well a network is designed, and regardless of the quality of the components, one certainty is that somewhere along the line something will go wrong. Good design and components may push that point back in time somewhat, but it will happen. It might be a device on the network that breaks, it might be a cable that works loose or gets bent, or it might be a switch port (or even a whole switch) that fails. At this point, the time and effort you spend on developing plans to deal with such issues will determine how badly the business is affected by the network issue. If you have no plan then you will be launched into a frenzy of high priority activity every time an issue occurs, however small. If you have foolishly agreed to an SLA with no provision for dealing with such issues, then you are bound to end up breaching it.

All is not lost, however, as putting a provision plan together is basically about applying common sense. Firstly, you should consider where you might experience problems; the answer is everywhere, but break it down into logical areas such as phones, cables, switches, routers, Internet circuits, PBX, and so on. Then look at the impact to the business of a failure of a device in one of these areas, categorizing devices into logical groups if necessary (such as reception phones, helpdesk phones, admin phones). At this point you should have a manageable number of scenarios that you can consider for likelihood and impact to the business.

For each scenario you should then be able to discuss contingency plans with the customer. Simple Red/Amber/Green (RAG) charts can be useful at this point to visually demonstrate the risks that can be accepted and those that need addressing, either to reduce the likelihood or to improve the speed of response thus limiting the impact to the business. In general, the response to different scenarios fits well with RAG categorization.

Increasing resilience

Should your risk assessment highlight any "Red" risk areas, the most likely action required to deal with that risk is to increase the resilience of your system. Usually that means introducing redundant equipment or components to the network with the purpose of "stepping in" in case of failure. Approaches that can be used to increase resilience of the network and the telephone system are discussed in Chapter 7.