A Roadmap for Deploying Converged Networks

October 2004

Table of Contents
1. Executive Summary ................................................................................. 3 2. Introduction.............................................................................................. 4 3. New Considerations Brought About by Deploying IP Telephony .......... 6 4. TDM vs. IP............................................................................................... 7 5. IP Telephony Readiness Assessment....................................................... 8 6. Network Design for a Converged Network ........................................... 10 7. Implementation and Ongoing Management of a Converged Network . 13 8. Call to Action ......................................................................................... 16

1.

Executive Summary There is an unstoppable movement on the part of network organizations to deploy IP Telephony. However, while the advantages of deploying IP Telephony are compelling, there are some challenging tasks that need to be accomplished in order to have a successful IP Telephony deployment. In addition to ensuring the appropriate level of security, these tasks include: Assessing the readiness of the network to support voice Designing and optimizing the network to support voice Implementing and supporting the network

One of the factors that complicate the completion of these tasks is that voice differs from a typical data application. In particular, voice traffic demands virtually 100% availability as well as exceedingly low levels of delay, jitter, and packet loss. In order to realize the benefits of IP Telephony, a large number of network organizations are turning to a 3rd party for assistance. When a network organization engages a 3rd party to help them with migrating to IP Telephony, they need to know that the 3rd party has the appropriate expertise. In particular, the network organization needs to know that the 3rd party has: Helped numerous other companies migrate to IP Telephony A deep understanding of both voice and data technologies Tools and processes that exceed what the network organization has themselves Services that focus on the issues facing the network organization

Given the interest in deploying a converged network, a key question facing network organizations is what is the best approach to take in order to plan, design, implement and manage a converged network infrastructure? A major part of answering this question is to determine the functions that the network organization will perform itself, as well as the functions that the network organization will entrust to a 3rd party. Below is a checklist of ten questions that network organizations need to ask both themselves and any potential 3rd party relative to the deployment of converged networks. The answers to these questions can help network organization determine both when to use a 3rd party, as well as which 3rd party to use. 1. What is your security architecture and how has that changed to reflect the issues created by deploying converged networks?

2. Do you have the expertise, tools and processes to perform a detailed IP Telephony readiness assessment to determine if the converged network has the appropriate security measures? 3. Do you have the expertise, tools and processes to perform a detailed IP Telephony readiness assessment to determine if the converged network can provide the appropriate availability and performance characteristics? 4. Do you have the expertise, tools and processes to proactively optimize the existing network resources? 5. Do you have the expertise, tools and processes to design a converged network infrastructure that incorporates myriad technologies and multiple vendors? 6. What are your capabilities to both stage and implement a multi-vendor converged network? 7. Do you have the expertise, tools and processes to proactively monitor and report on the status of the network relative to security breaches? 8. Do you have the expertise, tools and processes to proactively monitor and report on the status of the network relative to degradation in performance? 9. What is your ability to clearly demonstrate the business value that results from deploying a converged network infrastructure? 10. Are you capable of incrementally migrating the network from where it is currently to the desired end state while leveraging existing investments? 2. Introduction The phrase converged network refers to a network infrastructure that can efficiently and effectively support any and all applications. For most companies, the movement to implement a converged network infrastructure is initially driven by the desire to support voice traffic on what has historically been an IP-based data network. However, once they have deployed voice on an IP-based data network, many companies then use that data network to support other nontraditional applications such as video. The motivation to deploy IP Telephony has changed significantly over the past five years. Five years ago, IP Telephony appealed to a small number of companies, primarily those who were seeking to lower the cost of long distance voice calls. As such, early IP Telephony deployments focused on carrying intracompany calls over the companys IP network rather than over the traditional voice network.

As recently as two years ago, reducing the cost of long distance voice calls was still the primary driver of IP Telephony1. However, even at that time a growing number of IP Telephony deployments were motivated more by the desire to provide enhanced functionality than to reduce cost. This ongoing shift in the motivation to deploy IP Telephony is driven by several factors. One of the primary factors driving this shift is that over the last few years the competitive nature of the network service provider marketplace has consistently lowered the long-distance charges. As such, it has become increasingly difficult to create a compelling business case for deploying IP Telephony based just on reducing the cost of long distance voice calls. Today, the desire to reduce the cost of long-distance voice calls is not a very significant factor motivating companies to deploy IP Telephony. The key factors that are currently motivating companies to deploy IP Telephony are the need to: Enable business process enhancements Provide advanced voice functionality Enable the deployment of integrated applications

However, while the advantages of deploying IP Telephony are compelling, there are some challenging tasks that need to be accomplished in order to have a successful IP Telephony deployment. These tasks include: Assessing the readiness of the network to support voice Designing and optimizing the network to support voice Implementing and supporting the network

In addition, network organizations are growing increasingly concerned about the security vulnerabilities that are created by deploying IP Telephony. In order to realize the benefits of IP Telephony, a large number of network organizations are turning to a 3rd party for assistance. When network organization engages a 3rd party to help them with migrating to IP Telephony, they need to know that the 3rd party has the appropriate expertise. In particular, the network organization needs to know that the 3rd party has: Helped numerous other companies migrate to IP Telephony A deep understanding of both voice and data technologies Tools and processes that exceed what the network organization has themselves Services that focus on the issues facing the network organization

Survey: VoIP Moves Beyond Cost-Cutting, Jim Metzler, BCR, July 2002

In some cases, a network organization is looking for a service from a 3rd party to help them with IP Telephony migration because they do not have the necessary expertise in-house. It is also true that in many other cases the network organization does have the expertise in-house. However, IT management does not want to seriously disrupt the ongoing work of the organization by assigning all of that expertise to IP Telephony migration. Network organizations that utilize a 3rd party IP Telephony migration service fall into one of two categories. One category is comprised of network organizations that would like a 3rd party to provide a service for one or two discrete components of IP Telephony migration, such as performing a readiness assessment, monitoring for security breaches, or providing ongoing support. The second category is comprised of network organizations that would like a 3rd party to provide them a complete outsourcing service for IP Telephony migration. Research recently conducted by Ashton, Metzler & Associates indicates that fifty percent of network organizations would be receptive to a complete end-to-end outsourcing service to help the organization migrate to IP Telephony. 3. New Considerations Brought About by Deploying IP Telephony Some network organizations view IP Telephony deployment as just adding one more application to an IP network. While there certainly is some validity to that argument, there are also a number of very unique aspects of IP Telephony that distinguish it from more traditional data applications. One such aspect is that IP Telephony deployment places availability and performance requirements on the network that are far more demanding than those placed by the typical data application. For example, a traditional data application, such as email, can accept a small amount of downtime. That is not true with voice. The vast majority of people expect that their voice call will go through every time they pick up the phone and dial a number. As will be discussed later in the paper, the requirement for virtually 100% availability needs to be considered at each stage of the lifecycle of a IP Telephony deployment. Another requirement that distinguishes IP Telephony from a more typical data application is the rigorous demands that voice places on the underlying IP network. These rigorous demands include the requirement to have exceedingly low levels of delay, jitter, and packet loss. For many data applications, end-to-end delay is not a critical issue. That is not the case with voice. The ITU (International Telecommunication Union) recommends that the end-to-end delay associated with a voice call not exceed 150 milliseconds (ms). Experience has shown that it is possible to exceed that goal by a small amount. However, if the delay becomes too large, the quality of the voice call degrades noticeably.

Jitter is a measure of how packet delay changes over time. The vast majority of data applications are not at all impacted by jitter. Again, voice is different. Using the RFC 1889 definition of jitter, jitter should not exceed 30 ms or else the voice quality degrades noticeably. Voice, as well as virtually all data applications, is sensitive to packet loss. However, in the case of data applications it is typical to re-transmit any packets that were lost. In a IP Telephony deployment, lost voice packets should not be re-transmitted. This follows in part because modern voice coding algorithms (called CODECs) are explicitly designed to deal with the occasional loss of a packet. As such, it is better to let the CODEC do what it was designed for, than to re-transmit a voice packet and introduce significant delay and jitter. 4. TDM vs. IP In order to understand why IP Telephony deployment has made the discussion of delay, jitter and packet loss so important, it is necessary to understand how a Time Division Mutliplexing (TDM) network differs from an IP network. The traditional voice call is transported over a TDM network. In a TDM network a fixed amount of bandwidth, typically 64 Kbps, is allocated for each voice call. Note that the bandwidth is allocated for a voice call independent of whether or not anybody is actually speaking, or if any other application needs access to the bandwidth. In a traditional IP network, fixed bandwidth is not assigned to any application. The traditional IP network performs what is referred to as statistical multiplexing. This means that traffic from many sources is interwoven onto a single transmission facility. Statistical multiplexing is inherently more efficient than TDM. This follows because with statistical multiplexing, unlike with TDM, there is never a time that there is an application needing bandwidth and yet bandwidth is sitting there idle. However, statistical multiplexing also means that traffic from one application can impact the performance of another application. This is not possible in a TDM network. For the sake of example, assume that two people were attempting to make a IP Telephony call at the same time that two computers were attempting to exchange large files. If at a particular point in time, the computers are not attempting to transmit, the packets that are associated with the IP Telephony call will experience little delay. However, at a point in time that the computers are also attempting to transmit large files, there will be contention for the transmission

facility. Given this, the delay that the IP Telephony packets experience will increase. Since the delay of the IP Telephony packets increases, so does the jitter. In a TDM-based network, the situation described in the preceding paragraph could not happen. In particular, in a TDM-based network bandwidth would be dedicated to the voice call and additional bandwidth would be dedicated to the file transfers. As such, there would be no contention for the bandwidth, and hence no added delay or jitter. To understand one of the ways that packet loss can occur, it is important to realize that in an IP network the routers process each packet. Because the routers process each packet, each router can become a bottleneck. In particular, if all of the transmission facilities that terminated on a given router were all transmitting significant amounts of packets simultaneously, the router could not process all of the packets. To accommodate this situation, routers have the ability to store for very brief periods of time the packets that they cannot process. However, if the transmissions continued past that brief amount of time, the router would start to drop packets. This situation cannot happen in a TDM network. In a TDM network once the call is established, the network does not process the information that is flowing back and forth. As such, there is no need to drop packets that cannot be processed in a timely fashion. The differences between a TDM and an IP network need to be considered over the entire life cycle of a converged network. In particular, the next section of this document will detail some of the activities that must occur in advance to determine if an IP network is robust enough to support voice. Subsequent sections will discuss issues that are unique to the design, implementation and ongoing management of a converged network. 5. IP Telephony Readiness Assessment The goal of assessing the current environment is to identify any potential problems that may affect a customers ability to deploy IP Telephony. The two key questions that must be answered during a IP Telephony readiness assessment are: 1. Can the network provide appropriate levels of security to protect against attacks? 2. Can the network provide the necessary levels of availability and performance?

Note that network organizations do not have to be able to answer these questions on their own. As mentioned in section 2, many network organizations are utilizing services from 3rd parties to assist them with IP migration. Hence, the key issue for a network organization is to ensure that either directly or through the use of a 3rd party, they have access to the expertise, supplemented by sophisticated tools and processes to answer those questions. It is important to note that these two questions must be answered both prior to deploying IP Telephony, as well as continually once IP Telephony has been deployed. The requirement to continually assess the networks ability to support IP Telephony stems from the fact that IP networks are highly dynamic. As such, a network that is capable of supporting IP Telephony at one point in time, may not be capable of supporting IP Telephony at a later point in time. 5.1 Security Assessment As recently as a couple of years ago, the approach that the vast majority of network organizations took relative to security was to implement a design based on providing security at the perimeter of an enterprise. This design was based on two key assumptions. One assumption was that the company had a relatively well-defined perimeter. The second assumption was that the vast majority of the security attacks came from outside of the perimeter. Today it is widely accepted that the two assumptions that supported the perimeter based security design are generally not valid. That does not mean that perimeterbased security is not necessary. It is. However, perimeter-based security is not sufficient. As part of a security assessment, it is important to review the network and the attached devices and to document the security functionality they provide. The next step is to analyze the configuration of the network elements to determine if any of them pose a security risk. It is also necessary to test the network to see how it responds to potential security threats. 5.2 Availability and Performance Assessment Relative to understanding whether or not the network can provide the necessary levels of availability and performance, it is important to realize that there is a very large number of factors that impact network availability and performance. Some of the factors that can impact network availability and performance and which must be identified as part of the network assessment are the: Amount of bandwidth that is available both in the LAN and in the WAN Technologies used in both the LAN and WAN Design of both the LAN and the WAN Choice of protocols

Choice of CODEC Use of encryption Choice of QoS technologies Operating System levels of the network elements

The next step is to verify that there is sufficient capacity to ensure that voice traffic can be delivered with adequate performance. In order to do this, the first step is to develop a baseline that characterizes the current performance of the IP network. As discussed above, this baseline must quantify the network availability as well as the current levels of delay, jitter, and packet loss. The second step in this process is to simulate adding voice traffic to the IP network. The goal of this simulation is to determine if the network can support voice traffic and still provide acceptable levels of performance to the companys other applications. 6. Network Design for a Converged Network There are many factors that go into designing an IP network that can support voice traffic. This section will discuss two of those factors security and bandwidth optimization. It is important to note that the design for a converged network must be done in a holistic fashion. For example, without careful planning, techniques that are implemented to ensure the security of data traffic can have a negative impact on the quality of voice traffic. 6.1 Security Considerations As recently as a few years ago, network organizations spent considerable time talking about security, but far less time and resources actually attempting to improve security2. However, a combination of events has changed that situation and now virtually every network organization is aggressively working to improve security. The events that increased the focus on security include: Highly publicized and fast moving virus attacks Concerns about business continuity following 9/11 Government regulations such as HIPPA and Sarbanes-Oxley Widespread deployment of wireless technologies

It is widely understood that carrying voice traffic on an IP network exposes that traffic to a variety of security concerns. This includes:
2

Disruption of Service

Enterprise Security: A Status Check, Dave Pisciatello and Jim Metzler, BCR, November 2000

10

This refers to a hacker interrupting voice service. This could occur if a hacker initiated a Denial of Service (DoS) attack or a hacker caused the flooding of the IP network with either IP Telephony call control or IP Telephony data packets. Theft of Information This refers to a hacker listening in on voice calls. This could occur if a hacker was able to gain access to either the IP Telephony call control packets or the IP Telephony data packets. Theft of Service This refers to a hacker using a companys IP network to place unauthorized phone calls. One way this could occur is if a hacker attached a rogue device to the IP network. It is extremely difficult to develop an effective security design to protect against concerns like the one listed above without a written security policy. That follows because the primary goal of the security design is to implement whatever practices the company has relative to security; i.e., who has access to what information? As mentioned previously, the industry has moved away from believing that a design based on the concept of providing security solely at the perimeter of the enterprise is adequate. As such, a key component of a network design for a converged network is to develop a design for security that extends both inward and outward from the perimeter. For example, the security design should extend inward and consider individual devices and applications. The security design should also extend outward and consider road warriors and business partners who access the network. As mentioned, it is possible to think of IP Telephony as just one more application running on an IP network. Viewed this way, one could make the argument that whatever security design that a network organization already has in place on its IP network is sufficient to provide security for the IP Telephony traffic. However, that argument ignores the fact that, at described previously, there are significant differences between voice and data applications. For example, data consists of two distinct traffic flows, corresponding to network management and the actual information being transferred. Voice adds a third traffic flow, corresponding to voice signaling. A major part of the process to design a network to support IP Telephony is to ensure that the network can provide the appropriate level of security. So, staying

11

with the example that was raised in the preceding paragraph, the design needs to determine whether or not to segregate the three traffic flows that are associated with voice, and if the decision is made to segregate the traffic, will the segregation be physical (i.e., separate links) or logical; i.e., using VLANs. The design also needs to determine which, if any of the traffic flows should be encrypted. 6.2 Bandwidth Optimization Considerations The cost of bandwidth is typically a very large percentage of the overall cost of running a wide area network. Hence, bandwidth optimization is an important tool in virtually all networks as a technique to minimize the cost of bandwidth. The importance of bandwidth optimization increases significantly once IP Telephony has been deployed. That follows for two reasons: 1. Carrying voice on an IP network increases the bandwidth requirements and hence the cost of that bandwidth. 2. Voice is sensitive to network characteristics such as delay, jitter and packet loss. Because of that, it is important to ensure that voice traffic receive preferential treatment. With that in mind, this section will discuss bandwidth optimization both in the general context of IP networks, as well as in the specific context of transporting voice over an IP network. In particular, this section will discuss the three primary inter-connected components of bandwidth optimization caching, compression, and QoS. Caching is often present in several forms within a corporate environment. Most browsers contain a local cache for web pages they have already accessed. A proxy cache acts similar to a browser cache, but sits at the WAN edge and caches requests from many users, instead of just one. Finally, data center (or reverse proxy) caches offload servers and help speed content out of the data center. Caching can be used to both optimize the use of scarce WAN resources as well as to accelerate the delivery of content. Viewed this way, it is possible to think of caching as a technique in which storage resources are deployed in such a way to cause the WAN to perform as if it had received a one-time bandwidth upgrade. However, deploying caching will not solve the problem of poor application performance. This follows because WAN bandwidth will always be scarce and there is still a need to protect voice traffic from being interfered with by other less critical applications. The answer is to deploy caching in conjunction with QoS. The purpose of compression is to reduce the amount of data to be transmitted over a WAN. Viewed this way, it is possible to look at compression in a very similar

12

way to caching. In particular, compression can sometimes be used to cause the WAN to perform as if it had received a one-time bandwidth upgrade. However, as was the case with caching, deploying compression does not solve the problem of poor applications performance. As was the case with caching, the answer is to deploy compression in conjunction with QoS. It is worth noting that the header associated with IP Telephony packets adds 40 octets to each IP Telephony packet. Because of this, many deployments of IP Telephony implement header compression based on one of the following RFCs:

RFC 1144: TCP/IP Headers for Low-Speed Serial Links RFC 2507: IP Header Compression RFC 2508: Compressing IP/UDP/RTP Headers for Low-Speed Serial Links

Quality of Service (QoS) refers to the ability of the network to provide preferential treatment to certain classes of traffic such as voice. It is required in those situations in which bandwidth is scarce, and there are one or more delay sensitive, business-critical applications. Note that in this context, preferential treatment could mean limiting the bandwidth that certain applications (i.e., email) receive while simultaneously ensuring fairness for all the users of some business critical, delay sensitive application such as voice. There are a number of QoS techniques that the design must consider. This includes: 1. Congestion Management Weighted Fair Queuing Priority Queuing Custom Queuing 2. Congestion Avoidance Random Early Detection Weighted Random Early Detection 3. Policing and Shaping 4. Signaling RSVP 7. Implementation and Ongoing Management of a Converged Network The implementation and ongoing management of a network is not glitzy. However, there are numerous complex tasks associated with these activities that need to be performed flawlessly in order to have a successful deployment of a converged network infrastructure.

13

7.1

Implementation Given the complexity of the task, the implementation of a converged network requires sophisticated project management skills. In addition to being able to manage a large number of activities, the project manager needs to have detailed knowledge and experience with myriad technologies. Based on the size and complexity of the network, it may be necessary to stage the network prior to implementation. Staging the network allows the network organization, or 3rd party, to simulate outages, such as the loss of a line card, in a laboratory setting instead of a production setting. Staging the network allows the network organization, or 3rd party, to perform live load testing of the proposed network. Typically this testing enables the network organization to clean up some hopefully minor technical issues, as well as to finetune the processes that will be used to support the production network. Staging the network also allows the network organization, or 3rd party, to finetune the network design. For example, fine-tuning the design could enable the network organization to tweak the thresholds that cause alarms to be sent to the management console.

7.2

Ongoing Management Section 5 identified two questions that needed to be answered as part of a IP Telephony readiness assessment. Those questions are: 1. Can the network provide appropriate levels of security to protect against attacks? 2. Can the network provide the necessary levels of availability and performance? As section 5 also noted, those questions need to be answered not just during the network assessment, but also once the network is actually deployed.

7.2.1

Security Management In order to ensure that the network can provide the appropriate level of security, there are a number of tasks that must be continually performed, either by the network organization or by a 3rd party. These tasks include: Evolving the companys security policy based on shifts in the business and in technology Evolving the companys security architecture based on changes in the companys security policy and in enabling technologies

14

Identifying and eradicating viruses and worms Identifying and analyzing suspicious behavior in real time Modifying the configuration of network elements in response to the identification of new security threats Refining the technologies and processes to protect against denial of service attacks, theft of information, and theft of service

7.2.2

Availability and Performance Management One of the primary issues that network organizations face as they deploy converged networks is the high likelihood that those networks will be multivendor. This fact greatly complicates the task of ongoing management. For example, if a phone does not work correctly in a converged environment, the source of the trouble could reside in a wide range of equipment, produced by a variety of vendors. All of these potential trouble sources may need to be checked before fixing the trouble. In order to ensure that the network can provide the appropriate level of availability and performance, there are a number of tasks that must be continually performed, either by the network organization itself or by a 3rd party. These tasks include: Service Level Management Service level management is necessary in order to ensure that the network organization is providing to its customers the services that they need with the appropriate characteristics. Proactive Performance Management One of the key roles for proactive performance management is to continually monitor the network looking for signs of network degradation. Another of the key roles is to resolve any such issue, preferable remotely, prior to the degradation impacting the service as seen by the user. Fault Management The role of fault management is to detect, isolate and resolve network problems. Note that there is clear overlap between proactive performance management and fault management. In particular, fault management typically focuses on hard faults, such as having an inoperative network element. Proactive performance management focuses on soft faults, such as increasing

15

network delay. The goal of proactive network management is to identify and resolve soft faults prior to their becoming hard faults. System Backup The role of system backup is to ensure the rapid recovery of a system following an outage. Disaster Recovery There is clear overlap between system backup and disaster recovery. In particular, system backup focuses on the tools and processes to recover an individual system following an outage. One of the roles of disaster recovery is to determine what information on which systems is critical to business operations. This information feeds into the creation of a plan that includes the backup of those key systems. 8. Call to Action There is no question that there is an unstoppable movement to deploy converged network infrastructures. Hence, the question facing most network organizations is not what is the desired network architecture? Rather, the question facing most network organizations is what is the best approach to take in order to plan, design, implement and manage a converged network infrastructure? A major part of answering this question is to determine the functions that the network organization will perform itself, as well as the functions that the network organization will entrust to a 3rd party. Below is a checklist of ten questions that network organizations need to ask both themselves and any potential 3rd party relative to the deployment of converged networks. The answers to these questions can help a network organization determine both when to use a 3rd party, as well as which 3rd party to use. 1. What is your security architecture and how has that changed to reflect the issues created by deploying converged networks? 2. Do you have the expertise, tools and processes to perform a detailed IP Telephony readiness assessment to determine if the converged network has the appropriate security measures? 3. Do you have the expertise, tools and processes to perform a detailed IP Telephony readiness assessment to determine if the converged network can provide the appropriate availability and performance characteristics? 4. Do you have the expertise, tools and processes to proactively optimize the existing network resources?

16

5. Do you have the expertise, tools and processes to design a converged network infrastructure that incorporates myriad technologies and multiple vendors? 6. What are your capabilities to both stage and implement a multi-vendor converged network? 7. Do you have the expertise, tools and processes to proactively monitor and report on the status of the network relative to security breaches? 8. Do you have the expertise, tools and processes to proactively monitor and report on the status of the network relative to degradation in performance? 9. What is your ability to clearly demonstrate the business value that results from deploying a converged network infrastructure? 10. Are you capable of incrementally migrating the network from where it is currently to the desired end state while leveraging existing investments?

17