Frame-relay networks introduce many design and implementation challenges for transporting VoIP traffic. These challenges and their resolutions are listed below.
1. Prioritizing voice traffic
Page 140
2. Preventing nonvoice traffic from delaying voice traffic
3. Minimizing delay and delay variance without effecting other network-layer protocols
4. Enabling QoS functions without degrading performance on the frame-relay connected routers
5. Enabling QoS functions without affecting the traffic over other PVCs
6. Identifying all routers in all paths between source and destination
7. Ensuring that voice traffic does not exceed the network's capacity to deliver frames to the remote end
8. Ensuring that nonvoice traffic is discarded before voice traffic in the event of network congestion
9. Frame-relay traffic shaping and RSVP are not compatible and cannot be run simultaneously
10. Maintaining frame relay's cost-effectiveness and high voice quality
11. Minimizing and/or preventing interference from other network-layer protocols
Tackling these challenges, in order:
1. Challenge number 1 is not a new one, but its implementation on frame-relay interfaces is slightly different. In order to enable priority queuing on a per-PVC basis, frame-relay
subinterfaces must be used. This is not a major problem, but may require router configuration and network addressing modifications in certain scenarios. Also, in order to enable priority queuing, frame-relay traffic shaping must also be enabled, which, in turn, requires that RSVP be disabled on the interface. Other methods of prioritization including the use of IP precedence bits are discussed in the chapter on quality of service for IP.
2. Challenge number 2 is a difficult one to tackle when low-speed links are in use. The
serialization delay associated with low-speed links results in long transmission times for large frames. For example, it takes over 200 ms to transmit a 1500-byte frame over a 56-kbps circuit. Voice traffic will exceed its delay budget if it has to wait for such a large frame to be transmitted. Several protocols and applications call for the use of such large frames, and sharing low-speed links with them is an extreme challenge. One method of overcoming this is to lower the mtu for the serial interface. This limits the size of the frames which can be
Page 141 transmitted over the link, resulting in a lower transmission time for the smaller frames. A
priority-queuing mechanism then enables voice traffic to be interleaved within the other traffic. As we will soon see, this technique is not a panacea for frame-relay related issues.
3. Challenge number 3 is the result of our quick fix from challenge 2. Shrinking the mtu on an interface can have an adverse effect on other protocols. When the mtu for an interface is less than the datagrams which must be transmitted over the interface, the datagrams must be fragmented into smaller datagrams which can later be reassembled. While IP has a facility for this, IPX does not. Therefore, reducing the mtu size on an interface can, in effect, prevent large IPX frames from being transmitted through the interface. Additionally, fragmenting traffic does increase overhead on both the router and the receiving host and will limit the actual amount of data transmitted over the link (due to the additional headers required for the fragmented datagrams). This will cause a slight reduction in performance.
4. Challenge number 4 is a result of the additional processing required to implement router-based QoS mechanisms. While a few of these techniques are supported by the fast-switching software, most are not. Performing the necessary queuing, traffic shaping, and header compression will increase the processor utilization which can adversely affect all communications through the router. This may cause problems on some of the older access routers such as the 2500 and 4000, as well as RP-based 7000 routers. The newer, more powerful routers such as the 2600, 3600, 4500, 4700, 7200, and 7500 series can generally handle these functions without significantly impacting performance. Regardless of the router platform, its relative performance should be measured and monitored before applying these processor intensive tasks.
mtu must be done on the main interface with all of the subinterfaces inheriting the mtu change. It is not possible to change the mtu on a single subinterface. Often, routers positioned at the central site will support multiple remote sites and often multiple protocols to each site. Since adjusting the mtu can have an adverse effect on other protocols, you must be careful when modifying it on an interface with multiple PVCs, because while mtu change may work for intended PVC, it may also disrupt traffic on other PVCs.
6. Challenge number 6 is usually not a major issue, but can become an issue in rerouting conditions. It's usually easy to identify the path between
Page 142 source and destination and apply the necessary QoS techniques along that path under normal conditions. However, the path which may be used during a link or router failure condition is often ignored. Care should be taken to ensure either that the backup data paths are configured properly to support voice traffic or that phone systems and/or voice routers are configured to use an alternate path, like the PSTN, under failure conditions.
7. Challenge number 7 is a simple sanity check. In the data world, we got spoiled with frame relay's ability to handle bursty data traffic. When voice traffic is being considered, care must be taken to ensure that the peak amount of voice traffic does not exceed the network's ability to deliver it to the remote destination. Proper calculations should be made for voice traffic, including framing and protocol overhead.
8. Challenge number 8 helps ensure the end-to-end delivery of voice traffic. As discussed earlier, frame-relay switches will drop frames under congestion conditions. The switch's selection
process can be influenced through the setting of the discard eligible (DE) bit. In order to protect voice traffic from discard, you may wish to mark some or all other traffic as discard eligible using the de-lists command.
9. Challenge number 9 is a caveat which limits the administrator's options when selecting QoS mechanisms for frame-relay-based VoIP networks. If RSVP is strongly desired, then the administrator must forgo the use of priority queuing, custom queuing, and ForeSight-based adaptive shaping. Generic traffic shaping can be used to provide rate control, but priority and custom queuing will not be possible with RSVP enabled. Ostensibly, RSVP should provide the necessary bandwidth and delay variance required, but RSVP queues at the datagram level, so it is unable to overcome problems caused by large frames and high serialization delays.
10. Challenge number 10 refers to the provisioning requirements for transporting voice over frame-relay networks. Cisco's documentation suggests the separate PVCs be configured: one for voice traffic and one for data traffic. Alternatively, Cisco recommends provisioning the CIR at, or close to, the link's access rate. While both of these suggestions go a long way toward
providing improved QoS, they also incur more expense. Frame-relay pricing is usually broken into two components, a local loop charge and a per-PVC charge. Given this, it's easy to see how adding a PVC would increase cost. The second suggestion causes the frame-relay circuit to behave more like a private line. This is good for voice, since performance is more predictable
and there is less probability of the router's output overwhelming the network. However, it diminishes some
Page 143 of the advantages network designers have come to expect from frame relay. More specifically, if the CIR is close to the link-access rate, then there is little room to burst above CIR. Frame relay's burstiness allows network managers to provision circuits to handle the normal traffic flow, knowing that traffic bursts will be handled by the network. Removing bursting means that circuits must be provisioned to better support peak periods, and that means higher CIRs and, in turn, higher costs.
11. Challenge number 11 has been touched on before, only we focused more on voice traffic's effect on other protocols. We must also be careful of what effects these protocols may have on voice traffic. The periodic RIP and SAP updates required by IPX are an example of the
interference which can be caused. Another example is the IP-routing protocol Integrated IS-IS, which sends periodic hello packets that are the length of the interface's mtu. These and other protocol behaviors must be considered when designing a voice-enabled frame-relay network.
12. Challenge number 12 has been around for a long time. The ability to measure the
performance or service levels delivered by your provider is important when considering whether a network will meet voice's low-latency requirements. Management packages have been
developed to measure performance using a number of techniques. Some applications poll SNMP MIBs in the routers and do a fair job of reporting throughput. Others use specialized hardware to accurately measure both throughput and latency. Yet others use specialized processes on
RMON/RMON2 devices to monitor the response time to particular traffic patterns and attempt to characterize the latency of the network as well as the devices supporting the applications running over the network. Cisco has recently introduced the response time reporter function, which is used to measure the response time for traffic sent from the router to an IP host and back to the router. This is an automated equivalent to pinging hosts from the router console and recording the round trip times. Whatever method of measurement is chosen, one must be implemented to not only verify the network's ability to support voice traffic, but to ensure that these service levels are being met during normal operating conditions.