Introduction.doc

Design Guide for Router-Based WAN Voice Solutions

Version 1.0.0

Cisco Systems Confidential and Proprietary

This document contains confidential information and may not be duplicatedwithout written prior authorization by Cisco Systems

David Oroshnik Americas Technical Solutions Group

Cisco Confidential 1

Table of Contents

1 Introduction......................................................................................................31.1 Overview...................................................................................................31.2 Target Audience........................................................................................3

2 Solution Checklist Items..................................................................................32.1 Transport Options......................................................................................3

2.1.1 ATM.....................................................................................................52.1.2 Frame Relay........................................................................................62.1.3 Voice over IP.....................................................................................10

2.2 Signaling..................................................................................................122.2.1 Accommodating Different Signaling Types........................................122.2.2 Analog Signaling................................................................................152.2.3 Digital Signaling.................................................................................15

2.3 Dial Plans................................................................................................162.3.1 Overview...........................................................................................162.3.2 Implementation on Router/Gateways................................................172.3.3 Dial Plan Migration............................................................................17

2.4 Bandwidth and Compression...................................................................172.4.1 Overview...........................................................................................172.4.2 Compression Algorithms:..................................................................192.4.3 Multiple Compression Cycles............................................................192.4.4 Payload Sizing...................................................................................202.4.5 Required Bandwidth..........................................................................212.4.6 VoIP Header Compression................................................................21

2.5 Delay.......................................................................................................222.5.1 Coder or Processing Delay................................................................222.5.2 Packetization Delay...........................................................................222.5.3 Algorithmic Delay...............................................................................222.5.4 Serialization Delay.............................................................................222.5.5 Queuing/Buffering Delay...................................................................222.5.6 Network Switching Delay...................................................................232.5.7 De-jitter Delay....................................................................................232.5.8 Tandem Switching.............................................................................23

2.6 Head-end Aggregation............................................................................252.6.1 Small Frame Relay Network..............................................................252.6.2 Large Frame Relay Network..............................................................252.6.3 Frame Relay Access Network with Head-End ATM Delivery............26

3 WAN Solution Scenarios...............................................................................303.1 Introduction..............................................................................................303.2 Core-to-Core...........................................................................................313.3 Branch-to-Core........................................................................................323.4 Branch-to-Branch....................................................................................33

4 Revision History............................................................................................35


1 Introduction

1.1 OverviewThis document provides a framework for deploying voice-capable wide area networks. An introduction to the key elements of voice network design is presented first, and then those concepts are applied to common networking scenarios.

More often than not, creating a successful voice-data network is a tricky balancing act because the key design elements influence each other. A decision along one dimension usually influences or constrains the flexibility along another dimension. Of course, customer requirements add several more dimensions, some of them conflicting and others not. Customer restrictions can be physical, technological, financial, or political. Again, these must be balanced against the network constraints, product capabilities, and the laws of physics.

Many of the topic areas are not covered in-depth. For example, discussions on CODECs, compression, and delay are covered in detail in other documents and texts. However, this paper ties together these concepts in a manner that focuses on understanding how to balance the components that provide a sound WAN solution.

1.2 Target AudienceThis document is geared primarily to sales engineers. Sales engineers familiar with voice-data integration may have experienced many of the topics discussed here, but still may benefit from some applications they have yet to see.

Value added resellers who wish to be come expert in voice-data integration should find this document especially helpful.

Anyone just beginning to work with voice-data integration will find this paper helpful, though they may have to find other references to find detailed discussions on some of the topics.

2 Solution Checklist ItemsThe checklist items discussed here are the key issues that present themselves in every voice-data network design. When we go through various solution options in Section 3, WAN Solution Scenarios, we’ll discuss to each of these issues. We’ll learn how they interact with one another and how to balance them. The checklist items are:

Transport

Signaling

Dial Plans

Bandwidth and Compression

Delay

Head-End Aggregation

2.1 Transport OptionsYour common transport options are:

Frame Relay (VoFR)

ATM (VoATM)

VoIP (VoIP)


Of course, Frame Relay and ATM are data link protocols and IP is a network protocol. One of the nice things about IP is that as a network protocol, it is (at least in theory) independent of the data link layer. VoIP can operate over Frame Relay, ATM, PPP, HDLC and Ethernet. Additionally, VoIP is the only transit option that allows you to run packetized voice all the way to then end station (telephone). Both Frame Relay and ATM are limited to transport over the wide area network (WAN), though ATM could be used on a fiber based metropolitan area network (MAN). This is shown in Figure 2-1.

VoIP

WAN VV

IP IPATM/FR

VoIPVoIP

WANWAN VVVV

IPIP IPIPATM/FR

VoIP

Figure 2-1: Protocol Reach

Figure 2-2 illustrates the typical architecture for a voice-enabled router/gateway.

Voice Gateway & SwitchingServices

RoutingServices

Framing & FrameSwitching

PhysicalLayer

UIO Serial Ports

LAN

Phone orPBX

Layer 3 Services

Layer 2Services

Layer 1 Services

Voice + Data Path

Data Path

L2 Voice Path

VoIP Voice Path

Voice Gateway & SwitchingServices

RoutingServices

Framing & FrameSwitching

PhysicalLayer

UIO Serial Ports

LAN

Phone orPBX

Layer 3 Services

Layer 2Services

Layer 1 Services

Voice + Data Path

Data Path

L2 Voice Path

VoIP Voice Path

Figure 2-2: Voice-Enabled Router Architecture

Notice the different ways flows that voice is processed. If the voice transport is a layer 2 protocol, Frame Relay or ATM, the voice payload moves directly from the voice gateway services to the layer 2 framing processes. If the voice transport is VoIP, the voice payload moves from the gateway services to the routing services and then down though the layer 2 services.

If a voice frame arrives at the router and that router isn’t the final destination, some kind of re-direction must take place. In the case of VoIP, the mechanism is simple and familiar - the voice


frame is routed via its IP address. The data-link protocol treats the VoIP packet the same way it treats any other IP packet.

However, in the case of Frame Relay or ATM, the process is slightly different. When the layer 2 services receive the voice frame (or cell), the network header identifies the payload as voice or data. If the frame is data, it’s sent up to the routing services. If the payload is voice, the voice header and payload are passed up to the voice switching and gateway services. Here, the switching service looks at the header and determines the disposition of the packet. If destination is elsewhere, the switching service re-directs the frame out the proper DLCI. If the voice frame has reached its destination, the gateway services terminate the voice frame locally.

The following subsections offer a brief introduction to the three transport options, their strengths, and their weaknesses.

2.1.1 ATM

ATM is generally the most expensive transport to deploy because you’re paying for the bandwidth management that’s already built into the data link layer. Additionally, ATM only goes down to T1/E1 speeds. Below T1/E1 speeds, the extra overhead the ATM adds to each cell, often called the cell tax, doesn’t add enough value to warrant deployment. ATM switches and services tend to be more expensive than their Frame Relay and IP counterparts because they are more complex to own and operate. Remember, ATM was originally designed to be THE data link layer to transport voice and data over one network.

Keep in mind, however, you get what you pay for in an ATM network. Because ATM was designed with quality of service in mind, once you specify the service parameters, your QoS issues are behind you. Your data is queued separately from voice and travels over separate virtual channels within the virtual path.

Efficiency is an issue when using ATM. Because ATM adds at least 5 bytes of overhead for each cell (and sometimes more), Voice over ATM tends to be less efficient than voice over Frame Relay. We’ll define efficiency and overhead in more detail in Section 2.4.

2.1.1.1 AAL1

For example, the AAL1 adaptation layer was designed for real-time voice applications. AAL1 was designed to emulate a T1 or E1 circuit, with 24 or 30 channels for PCM encoded voice. AAL1 comes complete with all the hooks and QoS features to move voice easily over ATM backbones. Moving packetized voice over AAL1 using PCM is an accepted ATM standard.

AAL5, however, was designed to handle other types of traffic that have varying delivery requirements. Using AAL5, you can transport traffic that has real-time delivery requirements as well as traffic that has best-effort delivery requirements. The traffic types that fall under AAL5 are real-time variable bit rate (VBR-rt), non-real time variable bit-rate, available bit rate (ABR), and unspecified bit rate (UBR).

AAL1 has the least overhead of all the ATM solutions, with approximately 90% efficiency on a per-call basis.

2.1.1.2 AAL5

There is no ATM standard for moving voice over AAL5. However, Cisco has implemented a non-standard solution using VBR-rt that is available on the 3810 and some of the 3600 platforms. Though not a standard, voice over AAL5 has been successfully demonstrated in many customer sites. The QoS mechanisms in AAL5 are sufficient for effectively delivering voice.

The big advantage for AAL5 is that the cost of an AAL5 virtual channel from a carrier is significantly less than an AAL1 VC. Additionally, Cisco’s implementation for voice over AAL5 can accommodate compressed voice, whereas the AAL1 specification does not. Consequently, bandwidth can be used even more efficiently, resulting in further cost savings.

AAL5 however, is least bandwidth efficient of the three options on a per call basis. For example, for a G.729 call, 30 ms of voice, the most you really want to put in a packet for delay purposes,


requires 30 bytes, but you have to send all 53 bytes in the cell. This results in a per-call efficiency of 57%.

2.1.1.3 AAL2

AAL2 is a relatively new adaptation layer. Specifically designed to accommodate compressed voice, AAL2 allows portions of different voice channels to occupy different positions in the same ATM cell. For example, 10 ms of voice from call A, can be transported in the same cell with 10 ms of voice from calls B, C, and D.

This minimizes accumulation delay (Section 2.5.2), but significantly increases the complexity of the software and hardware, which adds to expense. Also, if the network in engineered for delay, your per call efficiency is dismal if only 10 ms of G.729 voice are sent in every cell. Of course, your efficiency is improved if you can maximize cell utilization. Currently, only service providers who are very focused on end-to-end delay are interested in AAL2.

Cisco is developing platforms that support AAL2. It is likely that they will be deployed only in service provider environments.

2.1.1.4 Product Listing

Several Cisco products support VoATM. AAL1 voice is supported on:

The LS1010 products

The 7200 Routers

The 7500 Routers

The voice gateway platforms for Cisco’s proprietary AAL5 solution are:

MC3810

C3600

C2600, IOS 12.1(2)XD

Any switch capable of supporting the particular adaptation layer used for voice transport, AAL1, AAL2, or AAL5, may be used to transport VoATM.

2.1.2 Frame Relay

Frame Relay is perhaps the most pervasive form of low cost wide-are networking. The widespread deployment and low cost of public Frame Relay services enabled the first boom in getting businesses on the Internet.

Frame Relay has several advantages over ATM in the wide area. First, Frame Relay supports line speeds as low as 9,600 bps whereas the slowest ATM line is a T1. Frame Relay equipment is also simpler than ATM to build and deploy. Consequently, Frame Relay services are less expensive to use and manage than ATM services. Also, Frame Relay uses a two byte header and CRC for each frame. Because frames may be up to 4096 bytes long, Frame Relay can be much more efficient for transporting long data frames.

Unlike ATM, Frame Relay has only minimal quality of service features. For a Frame Relay network to function correctly, the network must either be over-provisioned for the expected capacity or the end points must be well behaved. That is, the end points must obey their service agreements.

In reality, end users rarely obey their service contracts and public networks are moderately over-provisioned. This works well for data-only networks where the re-transmission of a frame doesn’t affect the end user. In a voice network, however, re-transmissions are not possible. The data is real-time and if it’s lost it’s gone forever. Low quality voice will be the result.

The following sections discuss some of the key issues to consider when deploying a voice over Frame Relay network.


2.1.2.1 Typical CIR Configuration

In a conventional data-only network, most users disregard the contracted CIR and configure the router to burst continuously. For example, if the line speed is 256 kbps and the CIR from the carrier is 128 kbps, most users will set the CIR on the router to 256 kbps. Because the higher layer application will re-transmit any lost packets, the router sends all that it can through the network. If packets are lost, they’re re-transmitted, and the user probably doesn’t notice any slowdown. In this way, users are hoping to get ‘more than they paid for’ in terms of bandwidth from their network provider. This is shown in Figure 2-1.

Line Rate128k

CIR64k

0 k

CIR 128k

Min CIR64k

0 k

RouterInterface

CarrierInterface

Line Rate128k

CIR64k

0 k

CIR 128k

Min CIR64k

0 k

RouterInterface

CarrierInterface

Figure 2-3: Conventional CIR Settings

2.1.2.2 Congestion

In a Frame Relay network, the user knows when the forward path is congested by monitoring the Backward Explicit Congestion Notification (BECN) bit. This information, along with the Forward Explicit Congestion Notification (FECN) bit is all the information the end-nodes have for knowing the state of the network. When a router receives a BECN bit, it should throttle back the rate at which it’s sending information into the network. If not, the network has the option to discard each frame that exceeds the service agreement.

Note that if there is no traffic flowing in the reverse direction, the router will never see the BECN information. Because of this, it is required the users properly configure and obey the CIR in combined voice-data networks. Figure 2-4 shows what happens to the network queues when the router bursts above the configured CIR.

DDDDDDDData

Data

BECN = 1BECN = 1

DD

Network Queue

BECNThreshold

Discard Eligible

IncreasingDelay

Router

DDDDDDDData

Data

BECN = 1BECN = 1

DD

Network Queue

BECNThreshold

Discard Eligible

IncreasingDelay

Router

Figure 2-4: Network Queue Operation


In a voice network, the discard of voice frames leads to garbled voice or gaps in the speech - clearly unacceptable in a commercial environment. Suppose now a series of voice frames follows a data burst. The network queues are full, and the voice frames are now labeled as discard eligible. This is shown in Figure 2-5.

DV DDDDDData + Voice

Data + Voice

BECN = 1BECN = 1

Network Queue

BECNThreshold

Discard Eligible

IncreasingDelay

VV

Router

DV DDDDDData + Voice

Data + Voice

BECN = 1BECN = 1

Network Queue

BECNThreshold

Discard Eligible

IncreasingDelay

VV

Router

Figure 2-5: Network Queue Operation with Voice

By the time a BECN is received by the router, it is too late for the voice. Voice frames are either sitting in a long queue, which adds too much delay, or the network has already started to discard frames that exceed the service agreement. In any case, the voice quality will be very poor. The problem can be solved in one of two ways, using multiple PVCs or properly configuring a single PVC.

2.1.2.3 Single PVC Solution

A single PVC is often used because customers don’t want to pay for or manage a second PVC. To deploy a single PVC solution, the customer must understand that they can no longer burst continuously - they must obey their traffic contract. They no longer can get something for nothing, but they will be saving on their long distance charges.

There are several elements to successfully deploying the a single PVC solution. First, you must shape conservatively and obey your traffic contract. The router can obey the shaping rules AND prioritize voice. If the customer is unhappy with the not being able to burst, explain that they can increase their line speed if they feel it’s necessary. A diagram of the suggested settings is shown in Figure 2-6.

Line Rate128k

CIR64k

0 k

CIR: 80k

Min CIR: 58k

0 k

RouterInterface

CarrierInterface

Line RateLine Rate

128k

CIR64k

0 k

CIR: 80k

Min CIR: 58k

0 k

RouterInterface

CarrierInterface

Line Rate

Figure 2-6: Recommended CIR Settings

2.1.2.3.1 Setting The Traffic Shaping Parameters

It is important to understand that the Bc setting in the traffic shaping parameters of Cisco’s voice-enabled routers represents something different than is normally expected. Essentially, the Bc parameter tells the voice-data queue how many bits of data to send before going back and re-checking the voice queue. Consider the example in Figure 2-1.


D1

V

D2D3

InterleavingInterleaving

Bc = 200 bitsBc = 200 bits Router Egress Queue

Router Egress Queue

VVVVV

V D V

D1

V

D2D3

InterleavingInterleaving

Bc = 200 bitsBc = 200 bits Router Egress Queue

Router Egress Queue

VVVVV

V D V

Figure 2-7: Operation of Bc Setting

Suppose Bc is set to 200 bits. If frame D1 is 60 bits, then the traffic shaper will place D1 on the line for transmission and decrement its Bc counter by 60. Now, since the counter hasn’t reached zero, it doesn’t bother to look in the voice queue for the next voice frame. Instead, it puts frame D2, a long frame, on the line for transmission. The Bc counter will be decremented to zero, but there’s more of D2 to transmit, so it’s possible that the voice frames will be excessively delayed. Consequently, Bc must be set based on the line speed.

Table 2.1: Suggested Bc Settings

If line rate is: Then set Bc to:

Less than 128 kbps 300 bits

Between 128 kbps and 512 kbps 500 bits

Greater than 768 Kbps 1000 bits

Also, the CIR on the router should be set to the carrier’s CIR plus the carrier’s Bc setting, that is, the amount that the carrier will accept before setting the DE bit or actually discarding the data. The customer should check with the carrier to see how often the carrier is servicing the input queue. If the queue service is greater than the access rate, it’s possible the customer can raise the CIR on the router above the service agreement. If the carrier is congested, then the router should set the CIR to the service agreement.

You should ask the carrier the following to ensure you’re properly configuring the network:

What is the CIR they are saying is provided for this DLCI?

At what bit rate above CIR can we run, and how long, before they set the DE bit to 1?

How long before can we run at that rate before they discard frames?

With this information it is suggested that you traffic shape in this fashion:

Set the CIR to the service provider's stated Bc rate (except with a 0 CIR service then, set the CIR to their stated discard rate).

Set the Bc to a minimum between (300 - 1000 bits)

Set the minimum CIR (mincir) to the service provider's stated CIR (except with a 0 CIR service, then set the mincir to just below their stated discard rate).

Set voice-cir or voice bandwidth to the actual required rate for voice or some percentage below the mincir.


Lastly, ask the carrier to set the BECN threshold to a smaller setting. Carriers with Cisco equipment will be able to do this. The MGX and IGX products have deep buffers, which greatly increase data throughput but cause delay in voice networks. A smaller BECN threshold effectively increases the sensitivity of the feedback loop, but only when traffic flows in both directions.

2.1.2.4 Dual PVC Solution

A dual PVC is often preferred since the customer can optimize voice performance while not sacrificing their ability to continuously burst the data. While it is easier to tune a dual PVC solution for voice and data, customers don’t like to manage the extra PVC, nor do they like to pay for the extra PVC. Often, if the customer negotiates hard enough with the carrier, the carrier will provide the second PVC for little or no cost. Also, remember that the savings from putting your long distance voice calls on the data network often more than pays for the additional PVC. An illustration is shown in Figure 2-8.

DDDDDDData

Data

BECN = 1BECN = 1

Network Queue

BECN ThresholdIncreasing Delay

D

V

DD

Discard Eligible

VVVVoice

Voice

Router

DDDDDDData

Data

BECN = 1BECN = 1

Network Queue

BECN ThresholdIncreasing Delay

D

V

DD

Discard Eligible

VVVVoice

Voice

Router

Figure 2-8: Network Queues with Two PVCs

In this case, one PVC is used for voice and one for data. The CIR on the voice PVC should match the carriers CIR and should be equal to the bandwidth required with maximum number of concurrent calls. You don’t want to oversubscribe the voice PVC.

The data PVC can be set to burst above the carrier’s CIR. Because the carrier queues the data and voice PVCs separately the voice should be unaffected by any large data bursts.

On lower speed lines, the data PVC must still be fragmented to accommodate voice-data contention on the physical interface. You don’t want voice frames stuck behind large data frames.

2.1.3 Voice over IP

Of all three transport options, VoIP holds the most promise for widely distributed and ubiquitous voice applications. Unlike ATM and Frame Relay, VoIP is a layer 3 protocol, which allows for more intelligent processing within the network.

Remember that VoIP still utilizes a data link protocol to get data across a network. Consequently, you’ll see VoIP used over PPP, ATM, HDLC, Ethernet, and Frame Relay networks.

While ATM and Frame Relay were designed for efficient, point-to-point connections, IP was designed for ubiquitous communications among many nodes. Additionally, IP was not designed with real time delivery in mind, extensions to IP to ensure timely delivery of voice packets are relatively new.


2.1.3.1 Key VoIP Characteristics

2.1.3.1.1 Header Size

VoIP frames have more overhead relative to Frame Relay and ATM. A typical voice frame has 20 or 30 bytes of G.729 voice payload in it. The typical IP header is 40 bytes (IP+UDP+RTP headers) so you can see that there is more header than actual voice payload. This make VoIP less efficient that either ATM or Frame Relay. Additionally, with VoIP, you’ll still have to add the data link header on top of the IP header, this makes it even less efficient.

2.1.3.1.2 Header Compression Overview

The use of IP header compression reduces the IP header to two or four bytes. Using header compression significantly decreases the overhead, and makes VoIP viable on lower speed links. However, using header compression utilizes a very large amount of CPU cycles on the router. This means that a head-end router can be horsepower constrained when terminating a significant number of low speed links. This has been somewhat mitigated by moving CRTP into the fast switched path in the 12.0 IOS code, but network designers should consider CPU resources when reducing overhead with header compression.

The details of VoIP header compression are outlined in Section 2.4.6 on page 21.

2.1.3.1.3 In the Local Area Network

Use of IP in the LAN is real today and will steadily gain market share. Previously, LAN data networks were unable to provide the levels of reliability needed to support voice traffic. Recent improvements in hardware and system design have eliminated many of those issues.

As noted before, IP has some issues with header size. This is not limited to the WAN, a VoIP packet with payload, IP header, and Ethernet header consumes significantly more bandwidth than the standard 64 kbps PCM encoded voice stream. Fortunately, the cost of LAN bandwidth, in the form of switched infrastructures has plummeted, making switched infrastructures nearly ubiquitous. This is good news because a switched infrastructure is essential to deploy VoIP to the desktop - VoIP cannot scale in a shared infrastructure.

Being able to deploy VoIP on the LAN opens up many new opportunities and markets. LAN based PBXs are a reality, as are LAN based call centers. Because VoIP also operates on the WAN, PBX and call center services can be extend beyond the LAN.

2.1.3.1.4 In the Wide Area Network

Use of VoIP in the WAN is limited by the ability to grow the network using header compression. In the absence of bandwidth constraints, VoIP is the clear choice in the WAN because, if the customer desires, it can easily be deployed all the way to the desktop. However, if there are low speed lines in the network, the WAN network must be carefully engineered to account for CPU requirements of header compression.

QoS in the WAN is also a thorny issue. If the customer is using a private leased line network, then they’ll have control of the frames throughout the network. If the customer is using an IP service provider, than the service provider’s QoS capabilities in the network must be known and accounted for. If the service provider is using a Frame Relay network, the care must be taken to ensure that proper QoS techniques are utilized. On ATM networks, the speeds are such that QoS shouldn’t be an issue, but one should keep in mind the type of adaptation layer used. Specifically, VB-nrt should be used for transport of VoIP packets.

2.1.3.1.5 VoIP Quality of Service

Quality of Service over IP for voice is accomplished using several methods. First, the output queues for voice have been constructed that voice always has priority (priority queuing) while the


data streams contend for the remaining bandwidth using weighted fair queuing, WFQ. The aggregate structure is referred to as PQ-WFQ.

Additionally, QoS across the network can be accomplished through the Resource Reservation Protocol, RSVP, Differentiated Services, and IP Precedence Bits.

One of the tricks of balancing QoS for VoIP end-to-end is ensuring that the service contracts are met through each of the intermediate routers. If you’re running over the public internet, RSVP will not be supported end-to-end, and many routers typically ignore the precedence bits. Consequently, VoIP is successful on private networks, or advanced service provider networks, which support the QoS services end-to-end.

2.2 SignalingSignaling can be the most difficult part of integrating a voice and data network. Though there are plenty of standards in voice signaling, some people will tell you that no two implementations are exactly alike. Additionally, a lot of voice network support is outsourced, so when you go on-site, it’s not always easy to know what’s been configured and how it’s supposed to work. Fair or not, the burden falls on the data network engineer to make his or her equipment work with the existing voice system.

Signaling is how the telephone or PBX tells the phone network when and where to place the call. There are several different ways to break down telephony signaling. We’ll cover the basics as detailed in Table 2.2, but first, we’ll go over how the router/gateways accommodate different signaling types.

Table 2.2: Signaling Summary

Analog Digital

FXS/FXO

Two-Wire

Loop Start

Ground Start

CAS: Channel Associated Signaling

North American Robbed Bit

European, all bits in channel 16

E & M

Two-Wire

Four-Wire

Five Types (I, II, III, IV, V)

CCS: Common Channel Signaling

Out-of-band Signaling

2.2.1 Accommodating Different Signaling Types

Before getting into the details of the different signaling types, it’s key to understand how the Cisco router/gateways accommodate each signaling type. Essentially there are two modes the router/gateways use, Translational Signaling and Transparent Signaling.


2.2.1.1 Translational Signaling

In Translational Signaling, the router/gateway actively participates in the call setup, connection, and tear down. It does this by locally emulating what would have normally been the remote equipment. This is shown in Figure 2-9.

T1/E1 VoiceModule

WANNetworkInterfaceNetworkInterface

SerialInterface

Router/Gateway

PBXAPBXAPBXAPBXA Voice

ChannelsLocal

Signaling

Translation

RouterSignalingFrames

Figure 2-9: Translational Signaling Model

Notice that the local signaling is translated into a form the router/gateway network understands.

Another way to look at translational signaling is to look at where the ‘signaling intelligence’ is located in the network. To better illustrate this, let’s look at a typical tie line PBX network as shown in Figure 2-10.

PBX2PBX2

PBX1PBX1

PBX3PBX3

PBXAPBXA

Figure 2-10: Location of Signaling Intelligence

The illustration describes a network of leased T1 lines between PBXs A, 1, 2, and 3. The red dots illustrate the locations of signaling intelligence, this is where the PBX indicates when and where the call will go. Note that there’s signaling intelligence associate with each physical line.


Now consider the integrated network shown in Figure 2-11.

VV

PBXAPBXA PBX2PBX2

PBX1PBX1

PBX3PBX3

VV

VV

VV

Figure 2-11: Distributed Intelligence in Translational Model

In this network, the signaling intelligence is distributed in the PBXs and in the router/gateways. This makes some elements of the network more complex, but it can save costs and improve performance.

2.2.1.2 Transparent Signaling

In a Transparent Signaling model, the signaling information is passed transparently through the router/gateway network and on through to the terminating PBX. In this model, all the voice channels are set up to be compressed at all times, and the PBXs never know the router/gateway network is operating. An diagram of how this accomplished is shown in Figure 2-12.

T1/E1 VoiceModule

WANVoice ChannelsVoice Channels

NetworkInterfaceNetworkInterface

VoiceCompression

SerialInterface

Signaling Path

Router/Gateway

PBXAPBXAPBXAPBXA

FramingProcess

D-channelD-channel

Figure 2-12: Transparent Model

As described in the figure, the signaling channel (d-channel) is framed independently of the voice channels, and frames are passed to the remote destination. Another way of looking at transparent signaling is shown in Figure 2-13.

VV

PBXA PBX2PBX2

PBX1PBX1

PBX3PBX3

VV

VV

VV

Figure 2-13: Signaling Intelligence in Transparent Model


Note that the signaling intelligence, represented by the red dots, stays in the PBX. The routers are dumb agents with respect to the signaling. The way the signaling is handled is very similar to the STUN function on IOS routers.

2.2.2 Analog Signaling

Analog signaling is handled directly by the router/gateway. This means the router actively participates in the signaling for the call and therefore must be involved in the dial plan. In general, FXS interfaces are used to connect user telephones directly to the router/gateway, and FXO lines are used to connect the router/gateway to the PSTN network. E&M interfaces are used to connect the router/gateway to E&M trunk connections on the PBX.

All analog signaling is accommodated by translational signaling.

2.2.3 Digital Signaling

2.2.3.1 Channel Associated Signaling

Digital signaling has more options. If the signaling is CAS, then the ABC&D bits are used to indicate signaling states. The router/gateway may be configured to either actively participate in the call signaling, or pass the signaling through transparently to a remote PBX.

• CAS– ABCD bits in-band

– All 24 channels have signals

24 Voice Channels

Figure 2-14: Channel Associated Signaling

There are provisions in the Cisco software to pass CAS signaling in a transparent fashion. This is especially helpful if the signaling states on the PBX aren’t supported in IOS. For example, when faced with and R2 signaling, you’ll likely want to use CAS transparent signaling as the router/gateway may or may not support the particular variant of R2 you’re seeing.

2.2.3.2 Common Channel Signaling

Another popular digital signaling method is Common Channel Signaling. In this signaling model one channel of the T1 or E1 circuit is set aside as a signaling channel. HDLC style messages are passed between endpoints to indicate on-hook and off-hook conditions, originating phone number, destination phone number, channel being used, etc., etc. ISDN signaling is a CCS protocol most often used to connect PBXs to the PSTN.

• CCS– Signaling on the Data channel

– Voice on the Bearer channels

23 Voice Channels

1 SignalingChannel

• CCS– Signaling on the Data channel

– Voice on the Bearer channels

23 Voice Channels

1 SignalingChannel

Figure 2-15: Channel Associated Signaling

Usually, CCS protocols for inter-PBX communication on a private network are proprietary, like Siemens’ Corenet or Lucent’s DCS+, and the vendors won’t license the protocol to Cisco. Consequently transparent signaling is the only option in this scenario. The IOS feature for transparently passing the CCS d-Channel is called Transparent-CCS.

Qsig is an international standard protocol defining a CCS protocol that can be used to interconnect PBXs from different vendors while still maintaining many of the advanced features


used on private PBX networks. Cisco equipment supports Qsig and can support translational signaling in voice networks that use it.

A network using Transparent CCS is shown in Figure 2-16.

VV

PBXA PBX2PBX2

PBX1PBX1

PBX3PBX3

VV

VV

VV

Figure 2-16: Transparent CCS

Note that with Transparent-CCS there is a one-to-one correspondence between PBX line card interfaces. Translational modes may reduce the need for line cards at the central cite and provide a more cost-efficient many-to-one relationship.

While Transparent-CCS is not as elegant a solution as the translation model using Qsig or CAS, this solution still has many advantages for the customer.

Minimizes T1 usage: Instead of paying for three point-to-point T1s every month, the customer only pays for Access to the network cloud.

Uses bandwidth efficiently: Most of the bandwidth on the dedicated T1s was wasted since each one only used eight channels. Now the network voice bandwidth only when voice is active

No dial plan changes: Since all the switching intelligence stays on the PBX, there is no need transition even small parts of the dial plan to the data network.

This scenario has some drawbacks, however. When voice calls are tandem switched through a Head-End PBX, say PBX-A in Figure XXX, and the compressed voice undergoes two compression cycles. Ideally, a network design should avoid multiple compression cycles, the reasons for this are addressed in detail in Section 2.4.3.

2.3 Dial Plans

2.3.1 Overview

Dial plans, quite simply, are the routing tables of voice traffic. They tell the PBX or router/gateway where to route the call based on dialed digits. The dial plan is essentially a parser with flow chart-like directions that interpret and route the call.

In a typical United States enterprise network one dials 9 for an outside line. In dial plan, a leading 9 tells the PBX to prepare to select an outside line. The PBX then spoofs dial tone to the user. The PBX then waits for the next few digits. If the next digit is a 1, indicating a long distance call, the PBX collects the area code and phone number. It will then, if programmed to do so, figure out the optimal long distance provider to route the call through. When all these decisions have been made, the PBX routes the call.


The dial plan can also key off other leading digits. For example, if the first digit an internal Cisco employee dials is a 5, 6, or 7, the voice network knows the call is internal, and only looks for at the first five digits dialed before placing the call over an internal network.

2.3.2 Implementation on Router/Gateways

Cisco’s router/gateways have many of the same advanced dial plan capabilities as PBXs. This being the case, dial plans on the router/gateways have the potential to become unwieldy and complex.

Dial plans in large corporations are usually complex and hard to deal with. Additionally, many companies outsource their voice operations and it may be extremely difficult to find out what exactly is going on. Usually the customer doesn’t want to pay for an on site visit from their voice network manager and just asks the data network installer to ‘deal with it as is’.

2.3.3 Dial Plan Migration

One of the most difficult parts of integrating a voice data network is ‘re-locating’ the dial plan. If the network signaling model is translational, then significant portions of the dial plan will need to migrate from the PBX to the converged network. This can be a large and arduous task for the network engineer, and Cisco is continually building new tools into its dial plans to make this easier.

One main concern with migrating the dial plan is to make the transition to the voice network completely transparent to the end user. The less a user has to think about using the new voice-data network, the more likely the customer will realize the expected cost savings.

Occasionally it’s not possible to replicate the dial plans on the router/gateways exactly the way the customer desires. If there are dial plan features that need to be added, submit a product enhancement request through proper channels at Cisco.

If transparent signaling is used, the dial plan stays mostly on the PBX. This allows for an easier migration to a converged network, but may result in other less desirable effects, like multiple compression cycles. We’ll discuss this in more detail in upcoming sections.

2.4 Bandwidth and CompressionJust a few short years ago, the key driver for converged voice-data networks was saving on bandwidth. Today, with the reality of VoIP in the LAN, the new driver is laying the groundwork for hybrid applications like call centers and unified messaging.

This doesn’t mean that bandwidth is no longer and issue, in fact, until bandwidth is free, voice compression, its characteristics, and its limitations will continue to be issues for network engineers.

2.4.1 Overview

Voice compression is usually done in the manner shown in Figure 2-17.

Telephone Telephone

Codec

Analog to PCMConversion

Codec

PCM to AnalogConversion

CompressionAlgorithm

PCM to Packet

De-compression

Packet to PCM

WAN

Flow

Figure 2-17: Voice Compression Flow Diagram

The analog signal from the telephone is digitized into PCM signals by the voice CODEC. The PCM samples are then passed to the compression algorithm which compresses the voice and


loads it into a packet format for transmission across the WAN. On the far side of the cloud the exact same functions are performed in reverse order.

Depending on how the network is configured, a Cisco router/gateway can perform both the CODEC and compression functions or only one of them. For example, if an analog interfaces is used on the router/gateway, then the router/gateway performs the CODEC function and the compression function as shown in Figure 2-18.

Figure 2-18: CODEC Function in router/gateway

If instead, a digital PBX is used, the PBX performs the codec function, and the router/gateway just processes the PCM samples from the PBX. An example is shown in Figure 2-19.

Figure 2-19: CODEC Function in PBX


2.4.2 Compression Algorithms:

Table XXX lists common compression algorithms and their nominal bandwidths. Many of these compression algorithms can be found in Cisco router/gateway products.

Table 2.3: Cisco Supported Voice Compression

Coder Nominal Bandwidth

PCM G.711 64 Kbps

G.726 ADPCM 32 Kbps

G.726 ADPCM 24 Kbps

G.726 ADPCM 16 Kbps

G.728 LD-CELP 16 Kbps

CS-ACELP G.729 8 Kbps

CS-ACELP G.729A 8 Kbps

CS-ACELP G.729B 8 Kbps

CS-ACELP G.729AB 8 Kbps

G.723.1 MP-MLQ 6.3 Kbps

G.723.1 ACELP 5.3 Kbps

G.723.1A4 MP-MLQ 6.3 Kbps

G.723.1A4 ACELP 5.3 Kbps

The ‘Nominal bandwidth’ is how much bandwidth the voice stream requires if it were on the wire by itself, without packet headers or flags. Technically, PCM is an encoding method and not a compression algorithm. As noted in the previous section, the compression algorithms require PCM streams as the input format.

2.4.3 Multiple Compression Cycles

The CS-ACELP compression algorithms are not deterministic, this means the input data stream isn’t exactly the same as the output data stream. A small amount of distortion is introduced with each compression cycle, as shown in Figure 2-20.

One ACELPCompression &Decompression

Cycle

Original Signal

flowInput

Close Approximation+ Small Distortion

Output

Figure 2-20: Distortion in Compression Cycle

Consequently, multiple CS-ACELP compression cycles quickly introduce significant levels of distortion. This additive distortion effect is not as pronounced with ADPCM algorithms.

The impact of this characteristic is that in addition to the effects of delay, the network designer must consider how many CS-ACELP compression cycles there are in the path.


Voice quality is subjective, but most users find that two ACELP compression cycles still provide adequate voice quality. A third compression cycle usually results in noticeable degradation, which may be unacceptable to some users. As a rule, the network designer should limit the number of CS-ACELP compression cycles in a path to two. If more cycles must be used, let the customer hear it first.

ADPCM may undergo up to 5 compression cycles.

If a branch-to-branch connection is made through a central PBX, and from the second branch the call is extended over the public voice network and then terminates on a cellular telephone network, there will the three compression cycles in the path, as well as significantly higher delay. In this scenario, quality will be noticeably affected. Again, the network designer must consider the worst-case call path and decide whether it will be acceptable given the users’ network, expectations, and business requirements

2.4.4 Payload Sizing

In many Cisco router/gateway products it’s possible to set the payload size in a voice frame. Let’s take for example a G.729 compression service. The input to the compression service is 10 ms of voice encoded in 80 bytes of PCM information. With ACELP compression, the bandwidth required is reduced by a factor of 8:1 and consequently the same amount of information can be sent using only 10 bytes of G.729 encoded information. This is illustrated in Figure 2-21.

80 bytes of PCM

10 bytes G.729

ACELP CompressionService

Figure 2-21:Payload Sizing With Compression

The output of a G.729 compression service is a continuous series of 10 byte samples, each representing 10 ms of voice. Now you’re faced with a decision. If you choose to minimize delay, you send each sample as you get it, but that forces the router/gateway to generate a lot of frames, which raises CPU utilization. It also adds to overhead as we’ll see in the next section.

Small Payload

Low Delay

High Overhead

High Packet Rate

High CPU Utilization

Large Payload

Moderate Delay

Low Overhead

Low Packet Rate


10 ms of voice hdrcrc 10 ms of voice hdrcrc

hdrcrc 10 ms of voice 10 ms of voice 10 ms of voice hdrcrc 10 ms of voice 10 ms of voice 10 ms of voice

1 Large Frame

3 Small Frames 10 ms of voice hdrcrc 10 ms of voice hdrcrc

10 ms of voice hdrcrc 10 ms of voice hdrcrc

Low CPU Utilization]

On the other hand, if you accept a little accumulation delay as you wait 30 ms for three samples, you can minimize packet overhead and reduce the CPU utilization. It’s up to the network engineer to do what’s correct in your customer’s situation.

Because you can specify the payload size, you have another tool to work with when evaluating customer requirements vs. what the equipment can do. Generally speaking, the default payload size for VoIP is 20 ms of voice and for Frame Relay it’s 30 ms. The former leads to a frame rate of 50 fps and the latter leads to a frame rate of 33.3 fps.

2.4.5 Required Bandwidth

The simplest way to calculate the per-call required bandwidth is to determine the overhead factor and multiply it by the bandwidth. The overhead factor is simply the total number of bytes used to transport the voice payload (including the inter-frame flag) divided by the number of voice payload bytes.

Equation 1: Per-Call Bandwidth Calculation

(Payload Size)(Payload + Header + Trailer + Flag)

X (Coder Bandwidth )Required Bandwidth =

Notice how the ‘byte’ units in the overhead factor cancel out, leaving you with bandwidth on both sides of the equation. For example, suppose you have a Frame Relay frame with 30 bytes of G.729 payload. The calculation would look like this:

1 ea Flag Byte

2 ea Frame Relay Header Bytes

3 ea Voice Header Bytes

30 ea Voice Payload Bytes

2 ea CRC bytes

38 Bytes Total

Therefore, to transport 30 bytes of voice payload, you have to send 38 bytes of information. This gives you an overhead factor of 38/30 = 1.267.

If you now multiply the voice bandwidth by the overhead factor you’ll get the total per-call voice bandwidth required. In our example the required bandwidth is 10.13 Kbps = (8 k) x (38/30).

This formula works for all compression algorithms if you know your payload size and overhead figures. Any byte that’s not in the voice payload that’s used to send the frame should be considered overhead.

2.4.6 VoIP Header Compression

Header Compression is used in VoIP to reduce the overhead on low-speed lines. An ordinary VoIP header contains 20 bytes of IP header, 8 bytes of UDP header, and 12 bytes of RTP header. Add this to a 2 byte data link header, a 2 byte data link CRC, and a flag, and you’ve got 45 bytes of overhead relative to a 20 byte CS-ACELP voice payload. The gives you an overhead factor of 3.25 and a per-call required bandwidth of 26 Kbps.

Using header compression, the total header can be reduced to 2 or 4 bytes. This gives an overhead factor of 1.45 and reduces the required bandwidth used to just 11.6 Kbps per connection.


However, as discussed previously, IP Header compression drains CPU resources so care must be taken if a lot of calls are to be terminated.

2.5 DelayMinimizing delay in voice networks has always been a priority. If there is too much delay in the system, you run the risk of not only aggravating echo and echo cancellation problems, but you can impact the efficiency and comfort of the conversation.

Imagine you’re on an international or cellular call, you’ve probably noticed that sometimes the two speakers interrupt one another. This is because the long delay in the system has altered the natural rhythm of the conversation. We no longer have accurate audio cues as to when the other party is done speaking. Unless a customer is using a satellite system where the laws of physics dictate long delays, minimizing delay in voice networks is of utmost importance.

There are two classes of delays, fixed delays and variable delays. Fixed delay components add directly to the overall delay on the connection.

Variable delays arise from queuing delays in the egress trunk buffers on the serial port connected to the WAN. These buffers create variable delays, usually called jitter, across the network. Variable delays are handled via the de-jitter buffer at the receiving router/gateway.

The following sections briefly describe each of the delay components. There is a very detailed white paper on the Cisco Solutions Center that describes delay in-depth.

2.5.1 Coder or Processing Delay

Coder delay is the time it takes the DSP compression engine to perform its calculations. Because different coders work in different ways, and DSP throughput is related to the number of active voice channels, this delay varies with the voice coder used and the real-time environment.

2.5.2 Packetization Delay

Packetization delay is the time taken to fill a packet payload with encoded/compressed speech. This delay is a function of the sample block size required by the compression algorithm and the number of blocks placed in a single frame. Packetization delay may be called Accumulation Delay, as the voice samples accumulate in a buffer before being released.

2.5.3 Algorithmic Delay

The compression algorithm, which relies on known voice characteristics to correctly process sample block N, must have some knowledge of what’s in block N+1 to accurately reproduce sample block N. This look ahead, which is really an additional delay, is called algorithmic delay and effectively increases the length of the compression block.

2.5.4 Serialization Delay

Serialization delay is the fixed delay required to clock a voice or data frame onto the router/gateway trunk, and It is directly related to the clock rate on the trunk. Remember that at low clock speeds and small frame sizes the extra flag needed to separate frames is significant.

2.5.5 Queuing/Buffering Delay

After the compressed voice payload is built, a header is added and the frame is queued for transmission on the network connection. Because voice should have absolute priority in the router/gateway, a voice frame only waits for either a data frame already playing out, or for other voice frames ahead of it. Essentially the voice frame is waiting for the serialization delay of any preceding frames in the output queue. Queuing delay is a variable delay and is dependent on the


trunk speed and the state of the queue. Clearly there are random elements associated with the queuing delay.

2.5.6 Network Switching Delay

The public network interconnecting the router/gateway locations is the source of many variable delays for voice connections. These delays are also the most difficult to quantify.

If wide-area connectivity is provided by Cisco equipment, or some other private network, it is possible to identify the individual components of delay. In general, the fixed components are from propagation delays on the trunks within the network, and variable delays are from queuing delays clocking frames into and out of intermediate switches and routers.

To estimate line delay a popular estimate of 10 micro-seconds/mile or 6 micro-seconds/km (G.114) is widely used, although intermediate multiplexing equipment, backhauling, microwave links, and other factors found in carrier networks create many exceptions.

2.5.7 De-jitter Delay

Because speech is a constant bit-rate service, the jitter from all the variable delays must be removed before the signal leaves the network. In Cisco router/gateways this is accomplished with a de-jitter buffer at the far-end (receiving) router/gateway. The de-jitter buffer transforms the variable delay into a fixed delay, by holding the first sample received for a period of time before playing it out. This holding period is known as the initial play out delay. This is the queue’s quiescent point a it’s shown in Figure 2-22 .

Voice FramesFrom Network

Voice FramesFrom Network

Over Flow:Queue fills if voice

frame arrive too fast

VariableArrival Rate

= Codec Frame

Rate +/-

V VV VV V V VV V VVV V VV V VV

Fixed PlayoutRate

= Codec FrameRate

Under Flow:Queue empties if voice frame arrive

too slow

Voice Framesto DSP decode

Voice Framesto DSP decode

Quiescent Point: Specified in mSec

Normal OperatingQueue Depth

V V V V V

Figure 2-22: De-Jitter Buffer Operation

Proper handling of the de-jitter buffer is critical. If frames arrive too fast, the queue will grow and overrun. If frames arrive too slowly, the queue will under run. In either case, frames will be lost and voice quality suffers.

The trick to the de-jitter buffer is achieving the proper balance between minimizing the initial holding time while accounting for the +/- deviations in the arrival rate based on variable network delays. While the optimal size can be estimated, in practice it’s often over-estimated and then optimized by trial and error during real-time network conditions.

The optimum initial play out delay for the de-jitter buffer should be set equal to the total variable delay along the connection.

2.5.8 Tandem Switching

Switching a call in and out of a PBX is called ‘tandem switching’ or ‘tandeming’ the call. Tandem switching generally adds delay to the call, but that must be weighed against the cost of having tie trunks connecting each location. The number of tie trunks to connect K locations increases dramatically when location K+1 is added, especially if K is large. Consequently, companies often have just one tie line to each remote location, and then ‘backhaul’ all the voice traffic to a central site. At the central site each call is tandem switched to the destination location.


Consider the typical enterprise network shown in Figure 2-23.

Location 1

Location 2

Location5

Location 3

Location 4PSTN

PBX-

PBX-

PBX-

PBX-

PBX-

Location 1

Location 2

Location5

Location 3

Location 4PSTNPSTN

PBX-PBX-PBX-

PBX-PBX-PBX-

PBX-PBX-PBX-

PBX-PBX-PBX-

PBX-PBX-

Figure 2-23: Typical Enterprise Network

Notice that if a user at location 1 tries to call a user at location 4 there is no direct path. Instead, the call must travel from 1 to 4 via either location 3 or location 5 (or even 2 and then 5). This is known as tandem switching the call.

In a dedicated voice network with PCM encoding, this kind of switching can usually be achieved with minimal delay and quality degradation. This is because the PCM encoding delays are so short that even over long distances the transmission delays are manageable.

In packet voice networks the additional delay added by compression engines and de-jitter buffers makes tandem switching through a PBX a fine balancing act, especially if there are long distance transmission delays. Additionally when the PBX does the tandem switching, the multiple compression cycles degrade voice quality.

Multiple compression cycles may be avoided by having the router/gateway perform the tandem switch before the call terminates on the PBX. This is shown in Figure 2-24.

VV

PBXAPBXAPBX2PBX2

PBX1PBX1

PBX3PBX3

VV

VV

VV

• PBX Tandem – High Delay, Low Quality

• Router Tandem: – Low Delay, High Quality

Figure 2-24: PBX Tandem vs. Router Tandem

Consider the router/gateway at location A an extension of PBX-A. The dashed, red lines indicate the path of a call that is switched by the PBX. The dotted, blue line shows the path traveled by a call tandem switched by the router/gateway. A call traveling along the red path under goes two compression cycles, one from 1-to-A and another from A-to-1, and PBX-A tandem switches the call. Conversely, a call that travels the violet path under goes only one compression cycle and the router/gateway switches the call.


2.6 Head-end AggregationHead-end aggregation can be an issue based on how large the network is and how the service provider drops off the Head-End connection. In a star network topology, if a lot of remote sites are being aggregated at the Head-End, there may be scaling issues involved that require creative solutions.

PBXAPBXA

WAN

PBXAPBXA

PBXAPBXA

PBXAPBXA

PBXAPBXA

PBXAPBXA

PBXAPBXA

V

V

V

V

V

V

V

PBXAPBXAPBXAPBXAPBXAPBXA

WAN






PBXAPBXAPBXAPBXA

VV

VV

VV

VV

VV

VV

VV

Figure 2-25: Large Star Topology

The best way to explain this topic is to go through some examples.

2.6.1 Small Frame Relay Network

Suppose there are 12 remote locations each with 64 kbps connections and one central data center. At the data center you might use a single T1 or maybe even something smaller. In this case, since a there’s not a huge processing requirement you could use a C2600 or MC3810 to connect to WAN at the head-end. The C2600 can support up to 60 voice channels at the central site if that many are required.

2.6.2 Large Frame Relay Network

Suppose there are 60 remote locations, each with a 128 kbps connection to the network. If all were to burst at the same time, the required central site access speed would be 7.68 Mbps. Since this is an unlikely scenario, probably only 3 T1s worth of access would be needed. This could be achieved by using a 3600 series router or 7200 series router at the central site.


2.6.3 Frame Relay Access Network with Head-End ATM Delivery

Usually, if more that 3 T1s are required at the central site, a single ATM DS3 drop will be less expensive and easier to manage. However, because of the complexities of Frame Relay to ATM Interworking, this situation can be problematic. The situation is shown in Figure 2-26.

FrameRelay

AccessNetwork

3660

Frame RelayEncapsulation

ATMDelivery

FRF5/8

ATMEncapsulation

Conversion

V

V

V

MC3810

C2600

Figure 2-26: Frame Access with ATM Head-End

First, there are two standard ways to translate Frame Relay to ATM, FRF.5 and FRF.8. These are standards outlined by the Frame Relay Forum. FRF.5 is essentially a way to tunnel Frame Relay through an ATM network. FRF.8 is a more complex approach that involves manipulating the payloads. FRF.5 services are available, but carriers almost exclusively use FRF.8.

There are two modes of FRF.8 Interworking, transparent and translational. They differ in how the payloads are manipulated between the frames and cells.

Transparent Mode: When encapsulation methods do not conform to the standards cited in Translation mode, but are compatible between the terminal equipment endpoints (an example being packetized voice), the Interworking function (IWF) forwards the payloads unaltered. No mapping for fragmentation/reassembly is performed.

Translation Mode: Encapsulation methods for carrying multiple upper layer user protocols (e.g., LAN to LAN) over a Frame Relay PVC and an ATM PVC conform to the standard FRF.3 and RFC 1483 respectively. Translation Mode supports the Interworking of internetworking (routed and/or bridged) protocols.

Essentially, this means that translations between RFC1490 encapsulated Frame Relay frames and RFC1483 encapsulated ATM cells are handled by translation mode services. In translation mode, the FRF.8 handler examines the ATM AAL5 Common Part Convergence Sub-layer Protocol Data Unit (CPCS-PDU) payload header and determines the type. It then builds a Frame Relay frame with the appropriate Frame Relay Q.922 PDU payload header.

2.6.3.1 How Translations Affect Design

If Frame Relay to ATM translations are required, and the voice is transported directly in the layer 2 protocol, there will have to be separate PVCs for voice and data. If the network were entirely in Frame Relay, then combined voice and data PVCs could be used. However, the ATM implementation for AAL5 voice requires separate virtual channels for voice and data connections.


Because the voice and data are translated differently, separate Frame Relay PVCs are required to achieve a 1-to-1 mapping.

There is not an issue if the voice is running as VoIP over Frame Relay. In this case, you could use a single Frame Relay PVC at the remote site, and run it through an FRF.8 translational function. At the Head-End, the IP frame would be properly translated and the router would correctly interpret the voice and data frames.

2.6.3.1.1 Interworking For Voice

Voice is best handled using FRF.8 Transparent because the non-standard nature of AAL5 voice means the network doesn’t know how to correctly translate the payload.

You may elect to use FRF.5 for voice if you are using an MC3810 at the central site to terminate voice. This is because the MC3810 has an optional internal interface for FRF.5. That is, when AAL5 voice cell originates, you can elect to have a Frame Relay header added directly into the ATM cell, so when the network strips of the ATM header, the Frame Relay frame is already there. Conversely, the MC3810 will be set to expect Frame Relay headers when it receives the cells that originated as Frame Relay at remote locations. The two types of encapsulation are shown in Figure 2-27.

Figure 2-27: FRF.5 Encapsulation

2.6.3.1.2 Interworking For Data (Not Fragmented)

If data frames are not fragmented, it is recommended that they go through an FRF.8 translational process. This takes a standards based payload and cleanly translates the payload from one Frame Relay frame into one or more ATM cells. Cisco routers with ATM interfaces can be configured to operate with RFC1483 standards so they can natively digest the translated frames.

2.6.3.1.3 Interworking for Data (Fragmented)

Fragmentation of Frame Relay frames using FRF.12 makes the frame incompatible with the FRF.8 Translational services and hence requires FRF.8 Transparent. However, re-assembling the original Frame Relay frame requires a two step process because it is not done internally by any Cisco router/gateway products.

The first step at the ATM receiving side is to run the translated the fragmented frames back through a reverse process. This re-creates the original stream of Frame Relay fragments that can then be fed back into a Frame Relay router. For traffic originating at the Head-End, fragmented Frame Relay frames are generated by the central site router and are then fed back through a local FRF.8 translation where they are delivered to the network. The network then re-translates


the cells back into Frame Relay frames where they are delivered to the access locations. This process is shown in Figure 2-28.

Figure 2-28: Reverse FRF.8 Process at Head-End

2.6.3.2 Head-end Solutions Using Frame Relay to ATM Interworking

There are many different ways to accommodate frame to ATM Interworking at the central site. The following examples are possible solutions, but with evolving product features and creativity, many other solutions are viable as well.

2.6.3.2.1 Head-end Solution with IGX

By using an IGX switch at the head-end, we can use the Interworking functions to convert any Interworking style, FRF.5, FRF.8/Translational, or FRF.8/Transparent, back to its original Frame Relay form. This has the advantage of providing a single DS3 interface to the ATM network, yet allows for flexibility at the Head-End. The solution is shown in Figure 2-29.

Figure 2-29: IGX as FRF.8 Reverse Solution

A key advantage to this solution, is that the IGX can be used to break out the data virtual channels from the voice virtual channels. By routing the Frame Relay connections to different physical routers, you can optimize network operations. A single router or group of routers can handle the voice traffic, while another group can handle the data. This could simplify support.

At another level, this solution could be used to minimize DLCI usage throughout the network. If only FRF.8 transparent is used, you can effectively tunnel a single voice-data DLCI from each location through the two FRF.8 transparent conversions. This can minimize DLCI usage and support costs.


2.6.3.2.2 Head-end solution with C3660

The C3660 supports FRF.8 services and can be used, though less elegantly, as a head-end solution. In this instance, again, there are several types of solutions to be had.

If the data is not fragmented and conforms to FRF.8 and RFC 1483 specifications, then a solution as outlined in Figure 2-30 will work. In this example, the data virtual channel is configured for FRF.8 translational, and the voice virtual channel is configured for FRF.8 transparent.

Figure 2-30: 3660 as FRF.8 Solution - No Fragmentation At Access Locations

In this case, data connections (green) are in RFC 1483 format when they enter the router. The cells can be reassembled by the ATM handler and passed up to the routing core. Notice that for the voice (red), the output of the FRF.8 handler must pass through the frame handler to serial port S0 because the FRF.8 service is linked to the layer 2 frame handler. This forces all output from the FRF.8 handler to exit the router. Therefore, an external loop back must be used to bring the recovered voice frames back into the router (S1). These frames now pass up to the voice services where they are either terminated or tandem switched.

Now suppose the data from the access sites is either fragmented due to low speed lines or does not conform to RFC 1483. In this instance, the voice and data have to follow the path shown by the blue lines in Figure 2-31. In this example, both the data and voice virtual channel are configured for FRF.8 transparent.

Figure 2-31: 3660 as FRF.8 Solution - Fragmentation Performed At Access Locations


Only after the frames arrive at S1 can they be broken down into either voice or data. Of course, this solution lends itself to support a single DLCI solution. Moreover, if the traffic level demanded it, the 3600 could be used as shown only as an FRF.8 device, but instead of the loop back, multiple serial connections could be made to a 7200 behind it for voice and data termination. This is shown in Figure 2-32.

Figure 2-32: 3660 As FRF.8 Switch at Head-End

3 WAN Solution Scenarios

3.1 IntroductionThe three are three basic ways that customers deploy wide area voice networks. These designs are generally organized around call flow. Different organizations use voice communications different ways and this greatly influences how they deploy voice networks and dial plans. Often these can be organized by market segments.

For example, a public school system, a brokerage, or an insurance office will generally run all their calls back to a central site, a branch-to-core model. However, a retail environment would likely have local branches calling each other to check inventory, a branch-to-branch model.

Generally, the router/gateways used in WAN voice solutions have similar feature sets. As of the writing of this document not all router/gateways support all IOS features. Due to constantly evolving feature sets, 100% parity across the product lines may never be reached, but in the future the differences will be minimized.

Common Enterprise Router/gateways products:

C1700

C2600

C3600

MC3810

C7200

C7500

When doing a network design it is prudent to make sure all the router/gateways involved support the required feature sets. It is prudent to check with your Cisco SE to confirm the current feature set.


3.2 Core-to-CoreIf the customer is running CCS-type PBX protocols and is primarily interested in consolidating tie lines between large corporate sites, than a Core-to-Core model is in order. Of course, this application requires the Transparent-CCS feature which isn’t available on all platforms in all transport models. The basic model of a Core-to-Core network is repeated in Figure 3-33 with the call flows.

VV

PBXA PBX2PBX2

PBX1PBX1

PBX3PBX3

VV

VV

VV

Call Flow

Figure 3-33: Typical Core-to-Core Call Flow

The red dots indicate where the signaling intelligence is located. Let’s review the checklist items with respect to Core-to-Core network model.

Transport:

The transport used will be dictated by the availability of the Transparent-CCS feature. As of the writing of this document the Transparent-CCS feature doesn’t work on all platforms and over all transport protocols. The following table shows availability and expected release information.

Table 3.4: Transparent-CCS Availability by Platform and Transport

1700 2600 3600 3810 7200

VoATM n/a 12.1(2)XD 12.1(2)XD Available ---

VoFR n/a 12.1(2)XD 12.1(2)XD Available 12.1(3)T

VoIP n/a 12.1(2)XD 12.1(2)XD Available 12.1(3)T

Signaling:

Transparent signaling is used in this model. The proprietary PBX signaling protocol will be transparently forwarded across the network from line card interface to line card interface.

Dial Plan:

The dial plan will remain on the PBX. The only dial plan information the needs to be entered into the router/gateways is the point-to-point routing information for the voice and signaling connections.

Bandwidth and Compression:

Because the PBX is doing the tandem switching and multiple compression cycles are required, you’ll want to use a coder that has low distortion. ADPCM is ideal for this environment. Additionally, many networks that use proprietary features are larger networks and the moderate compression offered by ADPCM will be acceptable. If you must use a CELP algorithm, be sure to limit the number of compression cycles to two.


Delay:

Because multiple compression/de-compression cycles are required when using the PBX as a tandem switch, you’ll want to use a low-delay compression option like ADPCM or LD-CELP. Again, if you must use an ACELP type coder, be sure to limit the number of compression cycles to two.

Head-End Aggregation:

At the central site you’ll need to match each remote site to its own head-end T1 or E1. Consequently, a chassis that supports multiple T1/E1 interfaces is recommended. A 3660 or 7200 type router is your best choice.

If you have Frame Relay and ATM Interworking issues, as discussed in section 2.6.3.2, using an IGX or MGX in front of the routers can make things much easier to manage.

3.3 Branch-to-CoreIn a Branch-to-Core network the call flow almost exclusively originates at the remote site and terminates at the core site. Depending on size of the remote offices, Branch-to-Core networks sometimes use proprietary CCS protocols and sometimes use CAS signaling. Figure 3-34 shows how call flow works in a Branch-to-Core network using the Transparent-CCS feature.

VV

PBXA PBX2PBX2

PBX1PBX1

PBX3PBX3

VV

VV

VV

Call Flow

Figure 3-34: Typical Branch-to-Core Call Flow

The red dots indicate where the signaling intelligence is located. Let’s review the checklist items with respect to Branch-to-Core network model.

Transport:

The transport may be dictated by the availability of the Transparent-CCS feature as discussed in Section 2.2.1.2.

If CAS signaling is used, then the transport may be either Frame Relay, ATM, or IP. In this case you will have more freedom to choose the transport that best suits the customers needs and desires as described in Section 2.1, Transport Options.

Signaling:

If the Transparent-CCS feature is required, than transparent signaling is used as described in the previous section. If the signaling used is CAS, then some portion of the dial plan must be replicated on the router/gateways. Of course, you may also use transparent signaling on CAS circuits if that’s required.


Dial Plan:

If the transparent model is used the dial plan will remain on the PBX. The only dial plan information the needs to be entered into the router/gateways is the point-to-point routing information for the voice and signaling connections.

If the translational model is used, only a minor portion of the dial plan must be replicated on the router/gateways. Because the call flow is simple, the dial plan can be simple as well. There is a connection type available that allows groups of phones to automatically dial a single head-end extension where the next available phone will ring.


Generally, there is no tandem switching trough the PBX. Consequently, most any coder can be used in a Branch-to-Core model. If some tandem switching is expected, it may be best to stay with ADPCM, otherwise, it’s probably best to use a ACELP algorithm to minimize bandwidth.

Delay:

Because there is minimal tandem switching, delay is probably not an issue unless the calls are over very long distances (trans-oceanic). If the there is a long delay, you’re probably better off to still use the ACELP coders on the assumption that the extra delay will be negligible relative to the overall delay, but the bandwidth savings will be significant. On international or satellite links, the bandwidth is the high cost item and it should be minimized in favor of delay.


If using Transparent-CCS you’ll need to match each remote site to its own head-end T1 or E1.

If using CAS signaling, you’ll likely to be able to optimize T1/E1 line card usage at the central cite. This could allow your customer to re-deploy those line cards elsewhere in the network.

If you have Frame Relay and ATM Interworking issues, as discussed in section 2.6.3.2, using an IGX or MGX in front of the routers can make things much easier to manage.

3.4 Branch-to-BranchIn Branch-to-Branch networks the majority of calls are placed between endpoints. This is found in many environments but most often in retail enterprises. Even if stock at remote stores can be checked via the network, a call must still be made to set aside merchandise for the customer or to request an inventory transfer.

Branch-to-Branch networks range is size from local to international, and with those size differences come different issues. We’ll touch on those as we go through the checklist items. A typical Branch-to-Branch network is shown in Figure 3-35. The red dots indicate where the signaling intelligence is located.

VV

PBXAPBXA PBX2PBX2

PBX1PBX1

PBX3PBX3

VV

VV

VV

Call Flow

Figure 3-35: Typical Branch-to-Branch Call Flow


Medium size networks can greatly benefit from a voice data integration because those businesses may have large geographic territories that incur long-distance charges, yet their call volume may not qualify them for the discounts available to large corporations.

Transport:

The transport in Branch-to-Branch networks varies by network size and location. At the branches, connectivity is almost exclusively by Frame Relay, although low-cost DSL services will surely increase the use of VoIP at the branches. Remember, in large networks, using VoIP in the branches may result in CRTP issues at the central site.

Signaling:

Because there are usually less that six phones in any branch location, signaling in Branch-to-Branch networks is exclusively CAS.

Dial Plan:

Because of the need to dial multiple remote locations the dial plans in Branch-to-Branch networks can become complex. Generally, the entire dial plan must be put in the router/gateways. The dial plan may be simplified by breaking the network down by geography and using a tiered approach to the dial plan as shown in Figure 3-36.

200

110 120 130

111 112 121 131 132 133

Figure 3-36: Tiered Dial Plan

Here, each digit helps break down the number by a region. If the router doesn’t recognize the next significant digit as ‘for me’, it forwards up to the next default router/gateway. The default route greatly simplifys routing at the branch, and, like the internet, only main routes are needed at the core.

Of course, in some instances, the customer will be inflexible and you will have to build a dial plan to accommodate an already poorly planned dialing system.


Because of all the re-routing in a Branch-to-Branch network, all the tandem switching is done by the routers. This eliminates the need for multiple compression cycles and makes the delay budget easier to deal with. In reality, most calls will be contained within a small geographical region and transmission delays will be minimal. All this means that you can probably use any coder you want, the only restriction will be the speed of the access line at the branch.

You’ll basically have to balance three issues: access speed, transport, and the number of concurrent calls required. Generally, the customer will have a strong preference towards of the three, and this will drive your decision.


Remember, at low access speeds, you’ll have to use CRTP for VoIP. This may present scaling problems if enough traffic terminates at one location. If most calling is branch-to-branch, this may not be an issue.

Delay:

Delay may become an issue over long distances and tandems hops. However, it is likely that the ACELP coder will be used based on the low speed access at the remote site. Delay will become an issue if the network is so large that the voice frame needs to go through more than 5 tandem connections. The more intermediate nodes the packet traverses, the more likely it is to experience variable delays. If the delay variation becomes too large, the de-jitter buffer may under-run.


If the network is small, say for a regional auto parts chain, it’s likely that you’ll need no more than a single T1 at the central site. In this case, a 3600 router will probably be able to handle all the voice and dial-in requirements of the entire network.

If the network is large, it’s likely you’ll have ATM delivery at the Head-End. In that case , you’ll be dealing with the Frame Relay and ATM Interworking issues discussed in section 2.6.3.2. In such a network, using an IGX or MGX in front of the routers can make things much easier to manage.

4 Revision History

Version Date Changes Made

1.0.0 24 Apr 2000 Original release


Documents

Introduction.doc