Section 8.3. Network Environment
8.3. Network EnvironmentAs a part of arguing the business case for a switch to VoIP, you've got to assess your network's readiness for it. Before you can deliver telephony, you need a fairly modern network. This can be done incrementallya site at a timeor you can assess your entire global WAN all at once, if you have one. 8.3.1. LANGenerally, LANs should be assessed as though they aren't even connected from the enterprise WAN, so that they are able, ultimately, to enable high-quality telephony in the event the WAN is disconnected. In IP telephony, the LAN replaces the private voice cabling system used by the TDM bus on a traditional PBX system. The TCP/IP protocol running on an Ethernet LAN provides the endpoint leg of the voice transport. But not just any Ethernet LAN will work. Only modern, 100BaseT switched Ethernet (or better) is reliable enough for a production VoIP workgroup. If you're using any LAN technology other than 10/100 mbps Ethernet, don't bother trying to run VoIP in your local area network. There are enough other reasons to dump Token Ring and 10Base2. If you haven't updated to 10/100 mbps Ethernet by now, you probably have bigger issues to deal with right now than VoIP. In a nutshell , it's time to forklift the Token Ring network and put in an Ethernet switch or two. 8.3.1.1 VoIPX? VoNetBEUI? Not a chance.IPX/SPX just doesn't work with voice applications. Neither does NetBEUI. If possible, eliminate them completely from the network, as they don't play nice with all the available quality-of-service mechanisms. As you'll read in Chapter 9, using VLANs is one way to partition unwanted protocols away from the VoIP network. 8.3.1.2 CablingLAN cabling needs to be Cat5, Cat5e, or Cat6 twisted-pair. As with legacy protocols, legacy cabling needs to get the old heave-ho. In high-interference or long-distance segments where fiber must be used for desktop runs, you'll have to use an interface converter to support VoIP equipment. This is because IP phones and VoIP gateway modules are usually equipped with RJ45 connectors and because (presently) there's no way to deliver power using fiber- optic cables. Fiber is perfect for backbone connections, campus area links, and other high-speed LAN connections that don't have to carry inline power (see "Power over Ethernet," later in this chapter). 8.3.1.3 Switches versus repeatersLAN segments where you plan on using VoIP must be switched. While hubs and other repeaters may work in low-traffic, less-than -critical situations, they aren't a best practice because they can't allocate or monitor bandwidth, and because they don't safeguard against Ethernet packet collisions, which cause latency and jitter. While you're investigating Ethernet switches for your LAN, consider only managed switches and layer 3 switches, which give you more control over the traffic on your LAN than their predecessors. Your LAN switches (and LAN-connected routers) will also need to support class-of-service measures such as ToS, or IP precedence. You'll almost certainly need to use VLANs. Most managed switches provide all of the these. When reading the spec sheets of Ethernet switches, consider all of these standards. Chapter 9 offers more extensive coverage of them.
8.3.1.4 Wireless Ethernet802.11b/802.11g are great technologies for WLAN and LAN-to-LAN bridging, but they aren't very partial to VoIP. First off, they don't support QoS the way modern Ethernet switches do, and the packetization delay incurred by their framing and radio transmission introduces lag. Moreover, WLAN can't support nearly the number of endpoint devices as a wired Ethernet segment that's comparable in link speed. If you need wireless phones in the office, using analog cordless phones is still a very practical solution. 8.3.2. Power over EthernetIn traditional telephony, the power to run each phone comes from the communications line that's attached to the telephone set. On the PSTN, 20 to 50 volts DC are required to power and signal analog endpoints. Voltage and frequency variances are what comprise analog signals for legacy protocols such as Ear and Mouth and FXS/FXO. Digital phone sets often have a similar voltage requirement, though their signals are carried over a digital bus. Legacy endpoints almost always get their power from the same line that handles their signaling, though one obvious exception is cordless phones, which need to be able to draw enough current to charge their handsets' batteries. Such draw isn't practical over DC communications wires. With IP phones, the power situation is a bit more flexible. Most IP phones can be powered either through an AC/DC power transformer (like a legacy cordless phone), or through one of two common methods of receiving power through the Ethernet cable plant. These two methods are PoE, or power over Ethernet standards, and both do roughly the same task: provide a loop of DC electric power over an unused pair in the twisted-pair Ethernet cable that is connected from the switch to the IP phone. 8.3.2.1 Cisco power versus 802.3afCisco began manufacturing a PoE solution long before the IEEE's 802.3af recommendation was ratified in 2003. Consequently, most of Cisco's IP phones don't work with 802.3af. Instead, they use the Cisco PoE solution, which I call Cisco Power. The line voltage and pin arrangements of the two are what make them incompatible. Meanwhile, 802.3af-compliant IP phones, which represent a majority, don't work correctly using Cisco Power. The two opposing standards just aren't compatible, though there are some wiring hacks that can allow a Cisco Power phone to be powered from an 802.3af power source and vice versa. Rather than make its own IP endpoints compatible with 802.3af, Cisco has provided another solution: make their switches offer 802.3af power. Late-model Cisco switches can even autodetect the power requirements of each attached device and provide the right type of power on that particular port, so that you could mix and match 802.3af phones and Cisco Power phones on the same switch.
Consider the power requirements of your IP phone fleet . Will they work with 802.3af, or do they require a proprietary power standard? Do the switches in place today provide the right kind of power, or any at all? Is connecting an AC/DC adapter at each phone location a reasonable idea? It may be in a 5-person office, but all those adapters could really add up in a 500-person office. How does the addition of switch-delivered power affect your VoIP rollout cost estimate? Provisioning a central power source with PoE simplifies the task of supplying backup power. Three or four PoE switches in a single rack are much easier to connect to a UPS or backup generator than a building full of IP phones in separate offices. 8.3.2.2 Power injectionA number of vendors offer patch panels that inject inline power. Avaya and others offer 802.3af injectors that allow you to add PoE to your network without forklifting all of your non-PoE switches. Sometimes, PoE injectors are a less expensive proposition than PoE switches, especially when the switches themselves are young, can't be easily replaced , or are leased for a long term . That said, green field rollouts will likely want to avoid power injectors, because they take twice as much rack space as a PoE switch. Properly implemented, PoE can save lots of overhead, and it lets you centralize your power backup strategy. (Imagine the alternativesbacking up the whole building or putting a UPS under everybody's desk.) Be sure each of your LAN segments can support PoE now or in the future, and plan appropriately for your chosen method of power provisioning. 8.3.3. LAN Readiness ChecklistEach location that has a LAN with which you'll support VoIP must adhere to the same minimum guidelines, according to a plan that you'll create:
It's important that you have a well-documented LAN or campus topology, including associated IP addressing plans, as well as addresses and physical locations of key servers such as firewalls, DNS servers, and DHCP servers. A description of your switches' VLAN setup is essential, if you're presently using VLAN. (VLAN is covered in greater detail in Chapter 9.) If layer 3 switches are used, well-documented routing and load-balancing plans should be produced, if these features are currently in use. Where are your switches located? Are they distributed in phone closets like distribution frames , or are they all in a single room? Do people have hubs and switches under their desks next to their feet? All of these issues can be compiled into a readiness assessment, like the LAN readiness checklist in Table 8-3. Table 8-3. Sample LAN readiness checklist
Once you've answered Yes to every item on the LAN plan checklist, you've got to identify which, if any, of the following required server devices will be located on the LAN:
None of these need to be located on the same Ethernet segment as the IP phones (except the DHCP server), though disaster planning and bandwidth preservation often dictate that they be. (More on disaster planning is found in Chapter 13.) For example, if you're using a softPBX call path for all calls originating from a segment with 1,000 IP phones, it's probably a good idea to locate that softPBX on the same segment as the phones. This is because an IP-over-T1 link, for example, wouldn't have enough bandwidth to carry the media channels of even 50 G.729A/RTP calls. Such a link would be required if the softPBX were located on a remote LAN segment. The TFTP, DNS, and DHCP servers are used to provide network configuration information and firmware updates to IP phones. Like a desktop PC, an IP phone needs an IP address, a subnet mask, a DNS address, and a default router address (if it will be used with a WAN or the Internet). These configurations can be centrally managed using a DHCP server and then automatically assigned to each phone during the DHCP host registration process. Some VoIP-specific configurations, such as SIP proxy addresses or H.323 gatekeeper addresses, can also be set on IP phones via DHCP or TFTP.
So a TFTP server, DNS server, and DHCP are all essential for an enterprise VoIP LAN setup; account for them as you design your network. TFTP servers and DNS servers needn't be on the same Ethernet segment as the IP phones, but the DHCP server does. Count on one DHCP server per segment, just as you would in a plain TCP/IP LAN setting. Alsoin many instances, TFTP, DNS, and DHCP services can all be run on the same physical server. DHCP is offered as a built-in feature on many routers. 8.3.4. WANYour WAN links, just like your LAN links, may have varying degrees of VoIP-friendliness. Some WAN technologies are particularly good for VoIP, like point-to-point T1, ATM switching, and optical links. Point-to-point T1 is good because its effective link speed doesn't fluctuate 1.5 mbps, because it's always dedicated to you and no other network users, and because it doesn't introduce much packetization delay. T1s can be sliced and diced as the administrator sees fit: half PCM DS0s, half data for TCP/IP, and so on. ATM switching works well for long-distance VoIP networks, especially through the use of VoATM, a way of removing some IP packet overhead before transport over the ATM network. Other types of WAN links are very poor for VoIP, such as frame-relay, fractional T1 (56 k or 64 k), ISDN, and microwave radio. Frame-relay brings so much latency to the table that it can really frustrate callers , and bursts of packet loss and jitter are common on frame-relay networks. Fractional T1 (56 kbps) and ISDN just aren't fast enough to carry more than a single G.729A-encoded call at a time. Microwave radio bridges have some of the same problems that 802.11b/g WLAN networks haveespecially packetization delay and jitterand one that WLAN doesn't, namely sensitive antenna calibration. Wide area network technologies don't always support the same QoS measures as Ethernet. Keep this in mind as you document your WAN. Does each point-to-point T1 have routers on either end of the circuit that can provide quality-of-service measures? Do those radio bridges support VLAN tagging? Do your ATM-WAN or frame-relay provider's other customers use the network for voice? Talk to the providers and some of their other customers to find out how well it works. Table 8-4 shows a sample readiness checklist that you can use to evaluate your wide area network. Table 8-4. Sample WAN readiness checklist
8.3.5. VPNVirtual private networks have proven to be both a substantial cost saver and, sometimes, a substantial headache . They're great because they allow the Internet to be leveraged in a wide area connectivity application and allow remote offices and road warriors to connect to the data center to check their email, update their database apps, and synchronize their Palm Pilots. Most of the time, VPN is great for these apps, because they are not sensitive to lag, jitter, and packet loss. But VPN poses a much greater challenge to VoIPfor two reasons. First, VPN is especially laggy and ridden with the overhead of tunneling and encryption. Second, most VPN techniques don't provide for any quality-of-service monitoring or enforcement. So, like broadcast Ethernet or VoIP over dial-up, you may be able to use VPN to carry voice calls, but the quality and consistency of those calls will be unpredictable. Chapter 13 includes a configuration for a Cisco router that enables a VoIP trunk using a VPN tunnel. 8.3.5.1 Managed VPNIn response to the quality shortcomings of VPN, some carriers have begun to introduce a service called managed VPN. This service connects multiple sites within your organization to one another completely within a single carrier's network rather than the public Internet, using VPN technology to keep the traffic secure within that network. Having all of the VPN subscribers connected to the same network allows the service provider to maintain service-level agreements, something not possible with ordinary VPN. Managed VPN is therefore a much better carrier for VoIP traffic. 8.3.5.2 VoIP over dial-upSave yourself the hassle and disappointment. No analog dial-up connection has enough bandwidth to support a full-duplex , enterprise-quality VoIP call. You may use Yahoo! Chat's VoIP over dial-up and think that, since it works, telephony-oriented VoIP can work over dial-up. But that's only because Yahoo! is using the Truespeech codec, which is not an enterprise-grade (or even toll-quality) codec. Modem speeds (56 kbps) just aren't fast enough to carry the voice stream, and besides, if your modem is plugged into a POTS line, just use it for voice calls.  |
EAN: 2147483647
Pages: 172