Centrex Ip Voip Readiness Document

Preparing your Network for SaskTel Centrex IP Service TM

Confidentiality and Proprietary Statement

The information contained in this document is the property of SaskTel, and it is strictly confidential. The recipient of this document, by its retention and use, agrees to treat the information contained herein as confidential to SaskTel.

Without SaskTel’s prior written permission, this information must not be copied, disclosed, or distributed in whole or in part. By receiving this information, the receiving party is bound by these conditions.

VoIP Readiness August 2005 Restricted and Confidential

Table of Contents

Overview ................................................................................................. 1 Centrex IP Architecture ....................................................................................2

Introduction ............................................................................................. 3 Network Behaviors .................................................................................. 4

Jitter.................................................................................................................4 Delay ...............................................................................................................4 Packet Loss ......................................................................................................6

Potential VoIPKilling Impairments......................................................... 7 Ethernet Switches and Prioritization......................................................... 9

M6350 Soft Phone..........................................................................................10 Network Connectivity and SaskTel Centrex IP Service ...................................11

Cabling .................................................................................................. 14 Power .................................................................................................... 15 Security ................................................................................................. 16

Firewall Configuration ...................................................................................17 Bandwidth ............................................................................................. 20 Network Assessment.............................................................................. 21 PostVoIP Implementation..................................................................... 23 SaskTel Recommendations .................................................................... 24 Appendix A: Common LAN Deployment Scenarios .............................. 25 Appendix B: Source Documents ............................................................ 31

VoIP Readiness 1 August 2005 Restricted and Confidential

Overview Target Audience

This document is intended for business professionals and/or IT managers who have the general responsibility for the planning, design, management, and performance of networks within the enterprise domain.

While this document is not expressly technical in nature, it assumes the reader has a thorough understanding of concepts relating to, but not limited to, the following areas:

• Quality of Service (QoS, or Priority Class of Service) • The OSI model • Routers, switches, and firewalls • Wide area networks (WANs) • Signaling

SaskTel Centrex IP

SaskTel Centrex IP is a networkbased VoIP application based on Nortel Networks’ Succession switch architecture. It consists of a central officebased server complex which provides application and signaling functionality to customer premisesbased IP telephone sets and PCbased client software. Media and signaling packets are transported via an IP network.

The promise or value of SaskTel Centrex IP Service lies in two major areas: cost savings, and enhanced functionality. Compared with other types of telephony services, including legacy Centrex service offered over the traditional telephone network, Centrex IP rates may be 15 to 39% cheaper than existing Centrex rates. Because SaskTel Centrex IP is inherently based on IP, it has the capability to do more (service mobility, new multimedia applications, greater integration with other desktop services). For these reasons, and more, SaskTel Centrex IP has appeal and the potential to deliver tremendous value to Customers.

SaskTel Centrex IP, as a real time VoIP application, places more exacting demands on the data networks which transport the service. SaskTel has invested to significantly upgrade its Central Office, transport, and access networks. Since Centrex IP traverses networks which are controlled by Customers, Customers must be prepared to examine, test, design and upgrade their networks in order for users of the service to have a positive experience.

VoIP Readiness 2 March 2006 Restricted and Confidential

Centrex IP Architecture

6

PBX

Carrier Managed Network

Enterprise B Enterprise A Firewall NAT/NAPT

Firewall NAT/NAPT

i2004/i2002 m6350 m6350 i2004/i2002

Enterprise Client LAN Enterprise Client LAN

Carrier CO/CS LAN

DHCP server

DHCP server

PVG

Firewall

CICM

SS7

PSTN OA&M/P

RTP Media Portal

USP UAS

= Carrier Private LAN = Carrier Publicly Routable LAN

CS2000/ CS2000c

Source: Succession CS2000 Service Overview, March 2004, Nortel Networks.


Introduction While much of the following document’s content is applicable to any VoIP deployment, this document has been prepared with particular focus to the considerations necessary for those implementing SaskTel’s Centrex IP service, over an MPLS based wide area network which is capable of certain quality of service (QoS) functions. .

If you are considering running Voice over IP (VoIP) on your local area network (LAN), chances are you'll need to make some changes to your network regardless of whether you’re planning to use a hosted solution or a customerowned solution,. Keep in mind that VoIP is an application like any other. Your network design and capacity can make or break the functionality of VoIP.

Dial tone always

Few impairments Calls are

private

150msec oneway delay max

High voice quality

Even though traditional business telephone services and customerowned TDMbased PBX systems are being replaced with VoIP, end users will still have the same expectation for voice quality and reliability that they have always had with the public switched telephone network (PSTN).

The above diagram depicts users’ expectations for a telephone system. Users expect the same voice quality as with the PSTN with no delays or jitter, privacy, and an instantaneous dial tone. They want phone service that will work even when the power is out.

Traditionally for data networks, timing is less important than accuracy, but voice is a realtime application with very stringent requirements. The typical data network is not designed to meet these requirements.


Network Behaviors To meet end users’ expectations of voice quality and reliability, you should be familiar with the three leading factors which lead to impairment of quality of VoIP. Network behaviors such as delay, jitter, and packet loss have relatively little impact on a data network, but can affect the voice application running over your data network to the point creating an unpleasant experience for your employees and customers, or at worst, making the VoIP service unusable.

Jitter Packet voice systems accept analog voice signals from telephone handsets, which digitize and compress the signal, placing the resulting series of bits into a short packet. The packet is then sent over an IP network. When it reaches the other end, the packet is decoded and the signal is reconstructed. Packets can take different routes across your network, others may get delayed, and the interval time between the packets can vary. This is what jitter is: the variation of delay in received packets.

Steady stream of packets

Packet stream after traveling through the network

At the sending side, voice packets are sent in a continuous stream and they are spaced evenly apart. However, the packetbypacket delay inflicted by the network may be different for each packet, causing irregular spacing or delay between each packet when they arrive at the receiving end. The receiving end requires fixed spacing between the packets before the packets can be converted back to voice. To fix this spacing issue, the receiving IP device will have a jitter buffer inside it that will deliberately delay incoming packets to allow for a continuous fixed stream.

Delay Delay effects how much time a voice packet spends in the network. Delay can be thought of as the interval of time between the moment a sound is made by the speaking person to the moment that sound is heard by the nonspeaking person. Delay is usually expressed in milliseconds (ms: one millisecond is 1/1000 th of a second).

There are typical sources of delay: • The network itself


o When a voice packet transverses the network, it must be received by each networking device and a decision must be made by that device on where to send it.

• Codec o Codecs are algorithms that digitize and compress the voice signal. o Codecs are built into the IP sets, soft clients, and end points. o The time required to process and compress a signal is by definition delay.

Each codec has a certain amount of builtin delay. Codecs which compress a given signal to a smaller overall packet size (high compression) may take more time or cause more delay than another codec which does not compress the signal as highly.

• Jitter buffer depth o This buffer holds incoming packets for a specific amount of time before

forwarding them onto the decoder to be converted back to voice (this is helpful in reducing jitter by eliminating uneven spaces between packets).

o This buffering effect introduces additional delay. A good baseline for oneway delay for acceptable twoway communication is 150 ms. Delays above 400 ms result in poor quality. The following graph shows the likelihood of users being satisfied based on a given amount of delay. As you can see, as jitter increases, users satisfaction decreases.


Source: TIA/EIA Telecommunications Services Bulletin 116 “Voice Quality Recommendations for IP Telephony”

Packet Loss Packet loss is a common occurrence on packet networks. Packet loss can be the result of many causes:

• Overloaded links • Excessive collisions on the LAN • Duplex mismatches

Audio codecs take into account the possibility of packet loss. Codecs may choose to use the packet received just before the lost packet to eliminate any clicks or interruptions in the audio stream. They may also use a more sophisticated method to fill in the gaps.

Network Utilization Network load is another important network factor that could affect voice quality. When the network load is high, especially in Ethernet networks, frame loss and jitter typically increase (a frame is a bundle of packets). Higher loads lead to more collisions. Collided frames are eventually resent over the network, resulting in excessive frame loss and jitter.

If network utilization is high, consider packet prioritization methods (often referred to as Quality of Service or QoS). Packet prioritization allows timesensitive packets such as voice to be prioritized over data packets. A prioritization scheme significantly improves voice quality.


Potential VoIPKilling Impairments Voice is a realtime application with very stringent requirements. Recent studies suggest that over 80% of networks have VoIPkilling impairments even when network utilization is at a low level (ie. impairments in networks can exist even when there is lots of bandwidth available)

Potential VoIPKilling Impairments 1. Duplex Mismatches

• Description: One end of an Ethernet link has a different speed and/or mode from the other end of the Ethernet link. For example, one end of the link could be configured as half duplex while the other end of the same link was configured as full duplex.

• IP phones use the autonegotiation mode, while the ports of supporting LAN switches may use forced configurations (either full or half duplex).

• Duplex mismatches will cause direct packet loss. • Recommended Solution: Configure the devices on both ends to the auto

negotiation mode.

2. Half Duplex Links • Description: A connection where information flows in both directions, but

only in one direction at a time. This type of connection is comparable to a conversation over a walkietalkie or intercom system.

• Half duplex links will cause jitter problems under heavy loads, and this is not appropriate for full duplex streaming applications like VoIP.

• SaskTel continues to offer a 10 Mbps half duplex option with its LANspan and LANspan IP fiberbased services. The DSL technology used to provide both LANspan and LANspan IP services over copper cable are equipped with a 10Mbps half duplex Ethernet interface.

• While 802.3 LAN switches support full duplex operation, many wireless 802.3 LANs do not allow more than one device to talk at a time and therefore do not support full duplex operation.

• If VoIP media paths are subjected to very low utilization, endtoend full duplex linkage and QoS may not be necessary. A single VoIP call on a dedicated high speed internet access with a small quantity of data traffic should not experience significant voice call quality problems. Trouble arises when application traffic from multiple users is transported on half duplex links in conjunction with many active phone calls.

• Recommended Solution: Migrate to a full duplex link environment.


3. Hubs • Description: Hubs are half duplex devices, and VoIP demands full duplex

link operation. • Hubbased LAN segments cannot support full duplex operation. • Half duplex links have much lower trafficcarrying capacity than full duplex

links (30% vs. 70%). Under heavy traffic, they can result in packet loss and packet delay variation due to increased collisions

• Recommended Solution: Hubs must be replaced by switches.

4. Category 3 Cable • Description: Category 3 cable doesn’t support 100 Mbps/full duplex or VoIP. • Recommended Solution: Have Category 5 cable (or higher).


Ethernet Switches and Prioritization As previously mentioned, packet prioritization allows timesensitive packets such as voice to be prioritized over data packets. This will help to minimize endtoend delay through the network, minimize the variability in endtoend delay, and prevent packet loss. This will significantly help improve voice quality.

Through extensive experience, SaskTel has determined that networks which are capable of priorization are necessary. It is a truism that network traffic grows over time. Non congested networks eventually become congested. Therefore, in planning and designing appropriate LAN and WAN networks, priorization must be taken into account.

Ethernet switches, not hubs, should be used, and they should meet the following requirements:

• Should have adequate Ethernet port density, throughput, and reliability. • Must support the necessary packet prioritization IEEE 802.1Q/802.1p, and/or

Diffserv Code Point (DSCP) to 802.1p (layer 2) mapping.

• Should support standards based Power over Ethernet, and be supported by Uninterrupted Power Supply (UPS – see the Power section of this document)

The 802.1p priority can only be used when the terminal (IP phone) is a member of a virtual LAN (VLAN) and 802.1Q headers are being added to all packets leaving the terminal. The Nortel i200x terminal uses an audio profile to configure layer 3, and layer 2 marking for the real time protocol (RTP) media path to the RTP media portal in the central office.

The Nortel i200x terminal does not mark for the UNIStim call signaling packets destined to the call manager in the central office. Signaling can be marked by the LAN switch (if switch can), but will always be marked by the CE router.

Figure 11 below shows an example of the prioritization method required for a typical voice media call.


Source: Nortel NTP 2975551100.2 “Centrex IP Client Manager (CICM) Series 7.0 Engineering Guide, Part 2: Network Design”

Ethernet switches must support multiple output queues to enable voice traffic to be prioritized over data traffic. Queues are just storage areas for the packets as they are received by the switch. Each queue has a priority. Incoming packets are assigned to a particular queue based on the priority set by the IP phone. The switch has mechanisms which enable service of a high priority queues while minimizing the chance of starving service to lower priority queues.

Customers should pay especially close attention if they intend to use switch features in their network generally referred to as “auto QoS”. These kinds of features, while intended to make the application of some priorization easier to implement, often do not meet the needs of a real time application such as voice.

Please refer to Appendix A for various LAN prioritization deployment scenarios.

M6350 Soft Phone The m6350 software for PCs doesn’t support 802.1p or DSCP marking. The ability for 802.1p and DSCP marking is reliant on the capabilities of the specific PC network interface card (NIC). In general, it should be considered that the m6350 soft phone is to be used in a besteffort environment.

Minimum PC requirements for the m6350 soft phone: • Pentium II 233MHz processor


• 32Mb RAM • 10Mb disk space • Good quality fullduplex SoundBlastercompatible soundcard • Good quality headset or handset • LAN or modem connection • Microsoft Windows 95/98/NT/2000/XP

(note that these minimum requirements can change from time to time. Please refer to www.sasktel.com/centrexip for the most up to date requirements).

Network Connectivity and SaskTel Centrex IP Service Currently Centrex IP can only be accessed via SaskTel’s LANspan IP data network service. The LANspan IP data service has QoS capabilities, robustness, and 24/7 support. SaskTel is also investigating other data services that will be allow to access the Centrex IP environment. The overall performance of the Centrex IP service is determined in large part by the quality of the network carrying the service.

This document focuses on describing the use of SaskTel’s LANspan IP service (CommunityNet) in conjunction with Centrex IP.

All traffic on a LANspan IP network connection is transported through the network at IP precedence level 3 and the SaskTelprovided customer edge router marks the traffic entering the WAN to IP precedence level 3. This is the standard level that LANspan IP service provides.

LANspan IP service has an optional Priority Class of Service feature. This option allows traffic to be delivered at a higher priority through the LANspan IP core network than the standard IP precedence level 3. Priority Class of Service option may be purchased at either IP precedence level 4 or IP precedence level 5. If IP precedence level 5 is purchased, level 4 is included.

Centrex IP traffic is routed over the LANspan IP WAN between SaskTel's central office Centrex IP service and the customer's enterprise LAN where the Centrex IP phones are located. Centrex IP traffic consists of signaling, phone firmware, and configuration data, in addition to twoway digitized voice media streams.

Centrex IP (i200x) phones contain an audio profile where the IP TOS precedence level and 802.1p priority are defined for signaling and media traffic (note that some of the attributes of the profile are embedded in the service provided by SaskTel, and are not adjustable by end users). The phone marks the outgoing traffic as directed by the profile. As the voice traffic enters the SaskTel customer edge (CE) router, the priority settings are maintained. Any other data traffic not marked with IP Precedence level 4 or 5 will have its precedence level marked with 3.

http://www.sasktel.com/centrex-ip


When the LANspan IP customer edge (CE) router receives prioritized traffic from the WAN, the precedence will be maintained towards the customer's enterprise LAN through the use of 802.1Q VLAN and 802.1p QoS or passthrough of layer3 TOS settings. The implementation type will be based on the capabilities of the customer owned device which links to the Ethernet interface of the LANspan IP CE router. The linkage between the CE interface and the customer's enterprise LAN is often created by a customerowned firewall/NAT device or trunking (802.1Q VLANs), priority scheduler and hardware transmit queues terminating on a port of a customerowned layer 2 switch. Each scenario can address the need to ensure that proper prioritization is maintained to the customer's LAN.

All data devices on the enterprise LAN typically reside on data VLANs in the traditional switched scenario. It is desirable to provision a separate voice VLAN when you combine the voice network into the data network. In Cisco software commandline interface (CLI) configuration terms, the new voice VLAN is referred to as the auxiliary VLAN. The native VLAN (default VLAN) of the switch would typically support the network’s data devices.

The IP Phone 2002 and 2004 threeport switch enables the capability to share the phone and PC connection to the switch. This configuration requires only one Ethernet cable between the wiring closet and the IP Phone/PC location.

When sharing a single physical switch port, it is recommended that the port be configured as a multiVLAN access port. When the IP phone boots up, its configuration will cause it to associate itself with the voice VLAN (or auxiliary/Cisco VLAN) while the PC will reside in the native VLAN. The data VLAN traffic will be untagged, and the voice VLAN will be untagged.

The internal phone switch does not interpret the 802.1Q header, but rather, allows the packets to pass through unmodified. Priority is achieved on a perport basis. The phone “port” traffic has high priority over the Ethernet port to which the PC is connected.

Voice traffic has the priority bits of all frames set to 6 (octal) by default. Data messages have the priority bits of all frames set to 0. Note that the IP phone will add the data VLAN ID to untagged PC traffic. However, if the traffic arriving on the PC port is already tagged, the frame will pass through unchanged.

An IP phone can receive broadcast frames from a PC’s data VLAN. Any data network broadcast storm packets from the network are seen by the IP Phone. This type of traffic does not adversely affect the IP Phone.

Best practice states the voice VLAN should be associated with a unique IP subnet in order to achieve a successful implementation. In other words, always keep voice and data on unique subnets (VLANs). This will help provide added security and help prevent broadcasts from the data network impacting the realtime voice application.


Note: As Centrex IP deployment is established, collaboration with SaskTel is required in order to ensure accurate configurations between SaskTel’s (LANspan IP) customer edge device and the customer’s local area network (e.g. VLAN ID’s).

This solution allows the scalability of the network from an addressing perspective. IP subnets often have a high percentage of their IP addresses allocated. A separate VLAN (IP subnet) carrying the voice traffic allows the introduction of a large number of new phones in the network without extensive modifications to the existing IP addressing scheme.


Cabling At the present time, some customer networks still have Category 3 cabling. Category 3 cabling doesn’t support VoIP. It is recommended to only use Category 5 cabling (or better).

SaskTel is a Belden CDT Certified System Vendor (CSV). SaskTel can certify wiring installations and provide a 25year performance warranty. Contact your SaskTel Sales Representative for details.


Power Power considerations are very important in the VoIP world. An important characteristic of IP telephony in general compared to the regular telephone network is that if power is lost to some portion of an IP network, such as the IP set or endpoint, or at any other LAN switch, or point in the network, ALL service is lost. Most traditional telephone network sets can still function in a power outage since line voltage for basic operation of the set is delivered from the Central Office.

This requires thorough consideration. Consider an emergency situation where employees may need to call 911. If the power is out, and no UPS support is in place, no calls can be made with the IP phone.

If you plug your IP phone into the AC wall socket, you will need to ensure that your AC wall sockets are serviced from an uninterrupted power supply (UPS) or your business could experience phone outages due to power failures.

Optionally, power can be supplied to the IP phone by a properly equipped Ethernet switch. These types of Ethernet switches will require power from a UPS to prevent downtime in the event of a power outage.

Power must be explicitly considered in network planning and design.


Security The information provided here is high level in terms of detail. SaskTel can provide comprehensive security consulting services. Contact your SaskTel sales representative for more information.

Centrex IP traffic will be carried on the same infrastructure as your regular data. A voice application on the data network is susceptible to all the same viruses and attacks targeting the other applications, such as denial of service (DoS) attacks and viruses. Measures should be taken to ensure that realtime applications are secure and that business assets are protected against malicious intent.

SaskTel’s overall Centrex IP service, including the Central Office, IP core network, transport network, and access network have all been engineered to maximize security while offering needed performance and access.

On the customer’s network, one should consider: • Basic network segmentation (VLANs) • Subnets • The use of a perimeter firewall to provide port filtering of traffic flow.

The enterprise firewall device should: • Be, at the minimum, a layer3 device • Have high reliability and adequate capacity (packet forwarding rate, throughput,

and concurrent sessions). • Be a stateful firewall, capable of L3/L4 packet filtering and inspection based on

defined firewall rules. • Support adequate WAN interfaces, depending upon the interface requirement to

connect to the LANspan IP CE device

This device must: • support DiffServ (DSCP) marking • support DSCP to 802.1p mapping.


Firewall Configuration To support Centrex IP deployment, enterprise firewalls must be properly configured, following the recommendations below:

• “Minimally restricted UDP policy” should be activated on firewalls to perform dynamic stateful packet filtering, allowing a UDP packet via predefined UDP port into enterprise network.

• A small set of firewall “pinholes” (i.e. UDP ports) and firewall rules (see Table 5 & 6) must be defined and configured on the enterprise firewall to allow flow of packets between Centrex IP clients (IP phone i200x and soft client m6350) and public interfaces of the Call Manger (CICM) through the firewalls.

• UNIStim over UDP for control and signaling between Centrex IP clients (i200x and m6350) and the call manager (CICM).

• RTP over UDP for Centrex IP voice media streams between Centrex IP clients (i200x and m6350) and another media endpoint (e.g. RTP Media Portal).

• RTCP (RTP Control Protocol) for periodic network performance monitoring. • UNIStim FTP for client (i200x and m6350) firmware download. • The configurable firewall “pinhole” timer value is recommended to be three

minutes.

Although the use of a firewall provides security for the protected enterprise, very few firewalls are applicationaware. Most firewalls have to open up specific ports called “pinholes” for packets of allowed application to flow through.

Because NAT devices hide the details of the IP addressing structure of the private network, as a side effect, they also provide security. They only allow packets to traverse the NAT towards the enterprise when a bind has already been established. Because NAT is not aware of the application’s nature, it uses a timer to determine when to close a bind or a pinhole.

Each i200x IP telephone set, or m6350 soft client is configured with the IP address of its hosting Centrex IP gateway. When the IP phone powers on, it sends “Resume Connection” to the Centrex IP gateway. A path through the NAT device is set up for phone signaling. Once the initial connection has been made, the IP phone starts the “watchdog” timer, with a default value of two minutes. To keep the signaling path open, every minute, the Centrex IP gateway sends a signaling message to reset the watchdog timer on the IP phone and the client responds with an acknowledgement. As mentioned, the configurable NAT binding timer value is recommended to be three minutes. In this way, a bind or connection is established from within the customer network, with a supporting method of maintaining that trusted connection.

Performance can vary between different NAT and Firewall devices. Monitoring of the CPU and memory usage is required to avert excessive delays.



Important Firewall Recommendations:

If your Enterprise firewall is performing a NAT function for all traffic, it is recommended that the Enterprise network be readdressed as to eliminate the NAT function performed by the Enterprise firewall. If for what ever reason the NAT function must be maintained by the Enterprise firewall then a “no NAT group” must be configured in the firewall to ensure the voice connectivity of the Centrex IP service. Please note, by maintaining a “no NAT group” in your Enterprise firewall all outside networks that are also using the Centrex IP service and require voice connectivity to your Enterprise firewall must be included in your “no NAT group”.

The soft client will not work in the NAT environment because…..




Bandwidth The bandwidth required per call depends on the codec used and the packetization rate. The codec determines the number of voice samples per second, while the packetization rate determines how many milliseconds of voice data is sent in each packet.

Other considerations which determine the amount of bandwidth required per call include the voice sample (voice payload size), IP/UDP/RTP headers, and the data link protocol header, e.g., Ethernet. As of the date of this document, SaskTel Centrex IP utilizes a G711 / 20 ms codec, which effectively consumes 100 kb of bandwidth per active session (64kb bit rate plus overhead).

Care must be taken when examining bandwidth requirements, especially in instances where WAN links are asymmetrical (ie. there are differing bandwidths allocated for upload versus download of traffic from the network).

If you have a 640 Kbps/4 Mbps LANspan IP circuit, you may assume that you can get approximately a halfdozen calls over this link with no problem. This may not be the case. While you do have a 4 Mbps pipe from the wide area network service into your office enterprise network, you only have 640 Kbps going back out (minus ADSL overhead). This asymmetry is fine for a few data traffic users as they probably pull most of their data from head office and the Internet, but voice traffic is very much a twoway application. As such, for bandwidth calculations in this example, you’ll need to work with the 640 Kbps figure. With this rate, you could have approximately six simultaneous calls using the G.711 codec at 20ms packetization intervals, assuming no other IP traffic is running on the same link. This calculation may also be impacted by prioritization schemes in place. For SaskTel network access services such as LANSpan IP or CommunityNet, which are capable of priorizing traffic as it egresses onto the WAN, a maximum of 70% of traffic can be tagged with the highest priority. In the previous example, the 640 kbps available would be reduced to 448 kbps or 70% of 640 kbps.

Another issue to keep in mind is the impact of congestion on other data or nonreal time applications. Since voice traffic receives highest priority, at times of high voice traffic, there will be less remaining bandwidth for other applications using the link. End users would perceive this as a slow down of other data applications. Care must be taken to design adequate bandwidth for voice specifically, and for all application data to traverse the network.


Network Assessment Statistics indicate that 85% of data networks are not ready for VoIP. A 50/50 chance of failure awaits those who proceed without a network assessment. Therefore, SaskTel has a Network Assessment a condition of service to receive Centrex IP service. Testing the infrastructure with simulated VoIP calls can help ensure proper performance.

A network assessment can: • Help minimize the risk of VoIP failure during deployment • Evaluate the data network’s ability to support VoIP • Identify bottlenecks in the network • Measure network statistics that impact VoIP (e.g., jitter, delay, lost packets) • Identify any VoIPkilling impairments in the network • Evaluate call quality • Provide a benchmark of the network’s current state

When a network assessment is performed on a LAN, the most commonly used metric to evaluate call quality is the Mean Opinion Score (MOS):

MOS

Very Satisfied Satisfied

Some users dissatisfied Many users dissatisfied

Nearly all users dissatisfied Not recommended

User satisfaction 5

4.3 4.0 3.6

3.1 2.6 1

Figure 1: Level of user satisfaction as function of MOS

Source: TIA/EIA Telecommunications Services Bulletin 116 “Voice Quality Recommendations for IP Telephony”

The following call quality rating chart displays minimum requirements:

Measurement Good Acceptable Poor MOS At least 4.03 At least 3.60 Any lower value Delay (ms) Less than 150 Less than 400 Any higher value Jitter (%) Less than 0.50 Less than 1.00 Any higher value


Lost Data (%) Less than 0.50 Less than 1.00 Any higher value

To arrange a Network Assessment, contact your SaskTel Sales Representative. A Network Assessment tailored to your individual needs is the first step to successful implementation of SaskTel Centrex IP Service.


PostVoIP Implementation Once you have implemented VoIP in your network, the management of network changes becomes very important. Before you make a change to your network, like adding a new feature or changing a configuration, you need to understand its impact on your VoIP network. Industry best practices should always be followed. ITIL is a set of best practices and standard methodologies for core IT operational processes such as change, release, and configuration management.

Change management is an important consideration. If SaskTel provides post installation and trouble shooting services for troubles which are determined to have root cause in the customer network environment, charges may be applicable.

If possible, inform SaskTel of any major change within your environment.


SaskTel Recommendations • You must have a LANspan IP access. • Ensure there is sufficient bandwidth to carry Centrex IP, data, and other planned

application traffic. • Be aware that when network load is high, jitter and packet loss typically increase. • Implement prioritization methods to ensure voice packets have priority over data

packets. • Make sure the prioritization methods are endtoend. • Ensure your network is free of impairments that may impact voice quality.


Appendix A: Common LAN Deployment Scenarios The following are common Enterprise LAN deployment scenarios in production networks today. These are provided as samples of what should be done to provide guarantees to the quality of VoIP traffic.

Design and deployment decisions made when working with an existing infrastructure may well be different than the ones made if working in a “greenfield” environment.

There may be some difficult challenges when trying to meet expected QoS targets. In each of the cases illustrated below, the voice traffic on the enterprise LAN is prioritized over data traffic using either 802.1p or DSCP (or both).

The simple LAN topology is the most commonly deployed LAN model seen in the enterprise today. The LAN infrastructure was designed and installed with no effort made to separate user traffic based on application.

Many different subnets and VLANs could exist within the LAN today, but the traffic is mixed. Typically, QoS has not previously been deployed; QoS is necessary when implementing Centrex IP.

Simple LAN Configurations In Figure 1 below, the user population is connected through switches to the CommunityNet VPN via the LANspan IP CE router. The IP addressing used on the LAN connecting to the LANspan IP CE router is provided to the enterprise by SaskTel.

Adding Centrex IP service capabilities requires that a connection be provisioned from the enterprise LAN to the SaskTel service hosted in the central office. As a trusted business partner, SaskTel ensures the connection to the hosted service is secure.

Figure 1 Simple LAN with 802.1Q/p support

In the preceding Figure 1, the separation of voice and data traffic is done by logical separation using VLANs. The example illustrates the use of i200x phones that share a LAN access with a PC. The switches in the infrastructure are configured, on a perport basis, as tagged links. Using the 802.1Q VLAN tag field in the Ethernet frame, logical


traffic separation is accomplished. This method eliminates the need for additional Ethernet ports for the connection of IP phones to the LAN infrastructure.

In LAN topologies modeled on the use of closet switches aggregating to central distribution switching and/or core routing, it is critical that an understanding of traffic levels on the trunks linking each level be maintained. Technologies such as multilink trunking can be deployed which permit loadbalancing of the traffic between the devices, thereby ensuring optimal available bandwidth.

The IP addressing for the i200x IP phones are under the control of the enterprise, and the size of the IP subnet is a consideration not to be forgotten. Each IP phone is another IP addressable host on a subnet, and they must be planned appropriately to accommodate the additional devices.

Note that if the addressing is provided to the IP phones through DHCP and the DHCP server is located on a different subnet, a router must be configured to support DHCP relay. It is advisable to assign the VoIP subnet to a contiguous block with the existing IP addressing used within the enterprise.

This example utilizes 802.1Q tagged connections between the enterprise switch and the i200x LAN interfaces. This configuration results in separate logical IP subnets (voice and data) which allows for control of traffic distribution. The layer2 priority assigned to the VoIP frames at the IP phone is carried forward through the LAN, ensuring the frames are treated with the proper priority.

This connectivity model uses an 802.1Q tagged connection between the enterprise switch and the LANspan IP CE router interface. This configuration results in separate logical IP subnets (voice and data) appearing on subinterfaces of the CE router, allowing for control of traffic distribution. This implementation requires the support for 802.1Q on the CE router (an optional QoS feature) and the enterprise switch. The layer2 priority assigned to the VoIP frames is carried forward through the LAN, ensuring the frames are treated with the proper priority.

LAN QoS Rules General rules that apply to the simple LAN solution:

• LANspan IP CE router must be provisioned with the optional QoS feature with 802.1Q configured on the LAN interface.

o This is necessary when the associated enterprise device doesn’t support Layer 3 DiffServ

• LANspan IP CE router must be provisioned with 802.1p to/from DSCP mapping o This is necessary if voice traffic is prioritized on the LAN using 802.1p o The CE router maps the appropriate DSCP values to 802.1p for VoIP

traffic from the WAN entering the Voice VLAN • LANspan IP CE router must support DSCP

o The WAN uses DSCP to prioritize the VoIP traffic


• Enterprise infrastructure must be switch based o This is a local LAN performance requirement.

• Enterprise Layer 2 switching must do 802.1p marking o The ability to mark and then provide priority to voice traffic within the

infrastructure • Enterprise Layer 2 switching should have multiple hardware queues

o Devices limited by two queues typically have limited CPU and processing power and are not adequate for policybased networks.

o Being limited to two queues results in multiple DiffServ values being mapped to the same queue and the behavior applied to the queue is the same for all packets.

In Figure 2 below, the user population is connected through switches to the enterprise firewall/NAT device which then connects to the LANSpan IP or CommunityNet VPN via the LANspan IP CE router. The Ethernet segment between the firewall and the demarcation router interface is typically a small subnet. The IP addressing on the Firewall public interface connecting to the LANspan IP CE router is provided to the Enterprise by SaskTel.

Adding Centrex IP service capabilities requires that a connection be provisioned from the enterprise LAN to the SaskTel service hosted in the Central Office. As a trusted business partner, SaskTel ensures the connection to the hosted service is secure.

For the purpose of illustration, Figure 2 assumes that the Enterprise Firewall/NAT device will impose limitations on the ability to deliver endtoend QoS. Because the device does not support 802.1Q/p, nor is it able to act upon layer3 DiffServ, the enterprise firewall/NAT must maintain the layer3 DSCP settings and forward them intact between the protected enterprise and the LANspan IP CE router.

Because of the limitations of the firewall/NAT device in this example, the enterprise will require the use of two internal firewall interfaces; one dedicated to VoIP traffic and the second interface to transport the data traffic. Switch ports linking the firewall to the protected network are each configured to be a member of a portbased VLAN type.

This connectivity model uses an 802.1Q tagged connection between the enterprise switch and the i200x LAN interface. This configuration results in separate logical IP subnets (voice and data) which allows for control of traffic distribution. The layer2 priority assigned to the VoIP frames at the IP phone is carried forward through the LAN, ensuring the frames are treated with the proper priority.


Figure 2: Subnetbased LAN with 802.1Q/p support and firewall/NAT

LAN QoS Rules General rules that apply to the subnetbased LAN solution (Figure 2):

• LANspan IP CE router must be provisioned with optional QoS feature. o This is necessary to allow the enterprise firewall/NAT device to

transparently pass VoIP precedence onto enterprise devices supporting DSCP to 802.1p mapping. DSCP must be applied before the firewall, since few firewalls support 802.1p

• LANspan IP CE router must support DSCP o The WAN uses DSCP to prioritize the VoIP traffic

• Enterprise firewall/NAT device may support 802.1Q o Firewall and NAT/NAPT device are often the same physical platform and

may support 802.1Q o This is necessary to provide endtoend quality of service in a VLAN

model • Enterprise firewall/NAT device must allow pinholes

o The required pinholes for VoIP traffic must be defined as part of the firewall rules

o Pinholes can be opened on a logical interface if VLAN model is used • Enterprise firewall/NAT device must support QoS transparency

o DSCP transparency is required to preserve QoS marking • Enterprise device must be provisioned with DSCP to 802.1p mapping

o This is necessary if voice traffic is prioritized on the LAN using 802.1p o The device maps the appropriate DSCP values to 802.1p for VoIP traffic

from CommunityNet before entering the Voice VLAN • Enterprise device performing DSCP to 802.1p mapping should have multiple

hardware queues • Enterprise Layer 2 switching must do 802.1p marking


o The ability to mark and then provide priority to voice traffic within the infrastructure

• Enterprise Layer 2 switching should have multiple hardware queues o Devices limited by two queues typically have limited CPU and processing

power and are not adequate for policybased networks o Being limited to two queues results in multiple DiffServ values being

mapped to the same queue and the behavior applied to the queue is the same for all packets

• Enterprise infrastructure must be switch based o This is a local LAN performance recommendation

In Figure 3 below, the user population is connected through the enterprise layer3 switch to the CommunityNet VPN via the LANspan IP CE router. The Ethernet segment between the layer 3 switch and the demarcation router interface is typically a small subnet. The IP addressing on the firewall public interface connecting to the LANspan IP CE router is provided to the enterprise by SaskTel.

Adding Centrex IP service capabilities requires that a connection be provisioned from the Enterprise LAN to the SaskTel service hosted in the central office. As a trusted business partner, SaskTel ensures the connection to the hosted service is secure.

This connectivity model uses an 802.1Q tagged connection between the enterprise switch and the i200x LAN interface. This configuration results in separate logical IP subnets (voice and data), allowing for control of traffic distribution. The layer2 priority assigned to the VoIP frames at the IP phone is carried forward through the LAN ensuring the frames are treated with the proper priority, forwarding the high priority VoIP frames before low priority frames.

Figure 3: Subnetbased LAN with 802.1Q/p and DiffServ support


LAN QoS Rules General rules that apply to the subnetbased LAN solution (Figure 3):

• LANspan IP CE router must be provisioned with optional QoS feature. o This is necessary to allow the enterprise firewall/NAT device to

transparently pass VoIP precedence onto enterprise devices supporting DSCP to 802.1p mapping. DSCP must be applied before the firewall since few firewalls support 802.1p

• LANspan IP CE router must support DSCP o The WAN uses DSCP to prioritize the VoIP traffic

• Enterprise layer3 switch must support DSCP o The network between the LANspan IP CE router and the switch may use

DSCP to prioritize voice traffic • Enterprise layer3 switch must have multiple hardware transmit queues • Enterprise layer3 switch must support 802.1Q

o This is necessary to provide a VLANbased model • Enterprise layer3 switch must support 802.1p to DSCP mapping

o This is necessary if voice traffic is prioritized on the LAN using 802.1p o The device maps the appropriate DSCP values to 802.1p for VoIP traffic

from CommunityNet before entering the Voice VLAN • Enterprise switches must do 802.1p marking

o The ability to mark and then provide priority to voice traffic within the infrastructure

• Enterprise switches should have multiple hardware queues o Devices limited by two queues typically have limited CPU and processing

power and are not adequate for policybased networks o Being limited to two queues results in multiple DiffServ values being

mapped to the same queue, and the behavior applied to the queue is the same for all packets

• Enterprise infrastructure must be switchbased o This is a local LAN performance recommendation


Appendix B: Source Documents 1. Nortel Network’s Centrex IP Client Manager (CICM) Series 7.0 Engineering

Guide

2. Nortel Network’s LAN/WAN design guidelines for deploying Succession services

3. Designing VoIP Networks: Lessons From The Edge by Matthew F. Michels

4. Emerging Network and Communication Technologies The Hype Cycle by Gartner Inc.

5. VoIP: The Future of Voice Traffic – White Paper by SaskTel, November 2004

6. TIA/EIA Telecommunications Services Bulletin 116, “Voice Quality Recommendations for IP Telephony”

7. Succession CS2000 Service Overview, March 2004, Nortel Networks