Introduction.doc

518 views
459 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
518
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Introduction.doc

  1. 1. 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 duplicated without written prior authorization by Cisco Systems David Oroshnik Americas Technical Solutions Group Cisco Confidential 1
  2. 2. Table of Contents 1 Introduction....................................................................................................................................................3 1.1 Overview.................................................................................................................................................3 1.2 Target Audience......................................................................................................................................3 2 Solution Checklist Items................................................................................................................................3 2.1 Transport Options...................................................................................................................................3 2.1.1 ATM................................................................................................................................................5 2.1.2 Frame Relay.....................................................................................................................................6 2.1.3 Voice over IP.................................................................................................................................10 2.2 Signaling...............................................................................................................................................12 2.2.1 Accommodating Different Signaling Types..................................................................................12 2.2.2 Analog Signaling...........................................................................................................................15 2.2.3 Digital Signaling............................................................................................................................15 2.3 Dial Plans..............................................................................................................................................16 2.3.1 Overview........................................................................................................................................16 2.3.2 Implementation on Router/Gateways............................................................................................17 2.3.3 Dial Plan Migration.......................................................................................................................17 2.4 Bandwidth and Compression................................................................................................................17 2.4.1 Overview........................................................................................................................................17 2.4.2 Compression Algorithms:..............................................................................................................19 2.4.3 Multiple Compression Cycles........................................................................................................19 2.4.4 Payload Sizing...............................................................................................................................20 2.4.5 Required Bandwidth .....................................................................................................................21 2.4.6 VoIP Header Compression............................................................................................................21 2.5 Delay.....................................................................................................................................................22 2.5.1 Coder or Processing Delay............................................................................................................22 2.5.2 Packetization Delay.......................................................................................................................22 2.5.3 Algorithmic Delay.........................................................................................................................22 2.5.4 Serialization Delay.........................................................................................................................22 2.5.5 Queuing/Buffering Delay..............................................................................................................22 2.5.6 Network Switching Delay..............................................................................................................23 2.5.7 De-jitter Delay...............................................................................................................................23 2.5.8 Tandem Switching.........................................................................................................................23 2.6 Head-end Aggregation..........................................................................................................................25 2.6.1 Small Frame Relay Network.........................................................................................................25 2.6.2 Large Frame Relay Network.........................................................................................................25 2.6.3 Frame Relay Access Network with Head-End ATM Delivery.....................................................26 3 WAN Solution Scenarios.............................................................................................................................30 3.1 Introduction...........................................................................................................................................30 3.2 Core-to-Core.........................................................................................................................................30 3.3 Branch-to-Core.....................................................................................................................................32 3.4 Branch-to-Branch.................................................................................................................................33 4 Revision History..........................................................................................................................................35 Cisco Confidential 2
  3. 3. 1 Introduction 1.1 Overview This 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 Audience This 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 Items The 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 Options Your common transport options are: • Frame Relay (VoFR) • ATM (VoATM) Cisco Confidential 3
  4. 4. • 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. IP ATM/FR IP V WAN V VoIP Figure 2-1: Protocol Reach Figure 2-2 illustrates the typical architecture for a voice-enabled router/gateway. Phone or PBX Layer 3 Voice Voice + Data Path Services Gateway & Routing Switching Services Services Data Path L2 Voice Path Framing Layer 2 & Frame Services VoIP Voice Path Switching Layer 1 Physical Services Layer LAN UIO Serial Ports 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 Cisco Confidential 4
  5. 5. 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, Cisco Confidential 5
  6. 6. 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. Cisco Confidential 6
  7. 7. 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 Rate CIR 128k 128k Router Min CIR CIR Carrier Interface 64k 64k Interface 0k 0k 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. Router Network Queue Increasing Delay Data Data D D D D D D D D D BECN = 1 BECN = 1 BECN Threshold Discard Eligible Figure 2-4: Network Queue Operation Cisco Confidential 7
  8. 8. 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. Router Network Queue Increasing Delay Data + Voice Data + Voice V V V D D D D D D BECN = 1 BECN = 1 BECN Threshold Discard Eligible 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 Rate Line Rate 128k CIR: 80k Router CIR Carrier Interface 64k Interface Min CIR: 58k 0k 0k 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. Cisco Confidential 8
  9. 9. Router Egress Queue Bc = 200 bits Router Egress Queue Bc = 200 bits D3 D2 D1 Interleaving Interleaving V D V V V V V V 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. Cisco Confidential 9
  10. 10. 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. Network Queue Discard Eligible BECN Threshold Router BECN = 1 Increasing Delay BECN = 1 Data Data D D D D D D D D D Voice Voice V V V V 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. Cisco Confidential 10
  11. 11. 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 Cisco Confidential 11
  12. 12. 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 Signaling Signaling 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 CAS: Channel Associated Signaling • Two-Wire • North American Robbed Bit • Loop Start • European, all bits in channel 16 • Ground Start E&M CCS: Common Channel Signaling • Two-Wire • Out-of-band Signaling • Four-Wire • Five Types (I, II, III, IV, V) 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. Cisco Confidential 12
  13. 13. 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. Router/Gateway T1/E1 Voice Serial Module Interface Translation PBXA A Voice Router Local Network Channels Signaling Interface WAN Signaling Frames 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. PBX1 PBXA PBX2 PBX3 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. Cisco Confidential 13
  14. 14. Now consider the integrated network shown in Figure 2-11. PBX1 V PBXA PBX2 V V PBX3 V 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. Router/Gateway T1/E1 Voice Signaling Path Module Serial Framing Interface D-channel Process PBXA A Network Interface WAN Voice Channels Voice Compression 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. PBX1 V PBXA PBX2 V V PBX3 V Figure 2-13: Signaling Intelligence in Transparent Model Cisco Confidential 14
  15. 15. 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. 24 Voice • CAS Channels – ABCD bits in-band – All 24 channels have signals 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. 23 Voice Channels • CCS – Signaling on the Data channel 1 Signaling Channel – Voice on the Bearer channels 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 Cisco Confidential 15
  16. 16. 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. PBX1 V PBXA PBX2 V V PBX3 V 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. Cisco Confidential 16
  17. 17. 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 Compression Just 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. Flow Codec Compression De- Codec Algorithm compression Analog to PCM WAN PCM to Analog Telephone Conversion PCM to Packet Packet to PCM Conversion Telephone 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 Cisco Confidential 17
  18. 18. 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. Flow Compression Codec Algorithm Analog to PCM WAN Conversion Telephone PCM to frame Router V 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. Flow Compression Codec Algorithm Analog to PCM WAN Conversion Telephone PCM to frame PBX Router V Figure 2-19: CODEC Function in PBX Cisco Confidential 18
  19. 19. 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. flow Input Output One ACELP Compression & Decompression Cycle Original Signal Close Approximation + Small Distortion 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. Cisco Confidential 19
  20. 20. 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 ACELP Compression Service 10 bytes G.729 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 crc 10 ms of voice hdr • High Overhead crc 10 ms of voice hdr 3 Small Frames • High Packet Rate crc 10 ms of voice hdr • High CPU Utilization Large Payload • Moderate Delay 1 Large Frame • Low Overhead crc 10 ms of voice 10 ms of voice 10 ms of voice hdr • Low Packet Rate Cisco Confidential 20
  21. 21. • 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 + Header + Trailer + Flag) Required Bandwidth = X (Coder Bandwidth ) (Payload Size) 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. Cisco Confidential 21
  22. 22. 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 Delay Minimizing 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 Cisco Confidential 22
  23. 23. 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 . Normal Operating Queue Depth Voice Frames Voice Frames Voice Frames Voice Frames From Network to DSP decode From Network V V V VV VV V V VV VV V V V V to DSP decode Variable Fixed Playout Over Flow: Under Flow: Arrival Rate Queue fills if voice Queue empties if Rate = Codec Frame frame arrive too Quiescent Point: voice frame arrive = Codec Frame Rate +/- ∆ fast Specified in mSec too slow Rate 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. Cisco Confidential 23
  24. 24. Consider the typical enterprise network shown in Figure 2-23. Location 1 Location 3 PBX- PBX- Location 2 Location 4 PSTN PBX- PBX- PBX- Location 5 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. • PBX Tandem PBX1 – High Delay, Low Quality V PBXA PBX2 V V PBX3 • Router Tandem: V – 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. Cisco Confidential 24
  25. 25. 2.6 Head-end Aggregation Head-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. PBXA A V PBXA A V PBXA WAN A V PBXA A V PBXA A V PBXA A V PBXA A V 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. Cisco Confidential 25
  26. 26. 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. Frame Relay ATM Encapsulation Encapsulation Conversion V Frame MC3810 Relay FRF ATM Access 5/8 Delivery Network V 3660 V 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. Cisco Confidential 26
  27. 27. 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. ATM: 53 bytes Direct Encapsulation Voice/Fax cc Pad Voice/Fax Payload ATM hdr Fields Header 8 6 30 3 5 Length in Octets ATM with FRF.5 Encapsulation: 53 bytes FRF.5 Encapsulation Frame Relay Portion: 36 bytes AAL5 trailer Pad Voice/Fax Payload V/F Hdr DLCI ATM hdr Fields 8 4 30 3 2 5 Length in Octets 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. Cisco Confidential 27
  28. 28. Frame Relay ATM Frame Relay Encapsulation Encapsulation Encapsulation V V C2600 3660 Frame Local FRF.8 Relay FRF ATM Transparent Access 8 Delivery Translation Network 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. Frame Relay Service ATM Service Frame Relay Encapsulation Conversion Encapsulation Conversion Encapsulation V C2600 IGX Frame FRF.8 Relay FRF ATM V Access 8 Delivery V Network V 7200/3600 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. Cisco Confidential 28
  29. 29. 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. Recovered Frames Re-enter Router C3600 Voice T1/E1 Data Router Voice Services S1 ATM Transparent Frame Handler Delivery FRF.8 ATM Handler Service Frame Handler DS3 S0 Voice Frames Recovered by FRF.8 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. Data Fragments re-built into Frames. C3600 Voice T1/E1 Data Router Voice Services S1 ATM Transparent Frame Handler Delivery FRF.8 ATM Handler Service Frame Handler DS3 S0 Data Fragments & Voice Frames recoverd by FRF.8 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, Cisco Confidential 29
  30. 30. multiple serial connections could be made to a 7200 behind it for voice and data termination. This is shown in Figure 2-32. Frame Relay Service ATM Service Frame Relay Encapsulation Conversion Encapsulation Conversion Encapsulation V V C2600 3600 Frame FRF.8 Relay FRF ATM services V Access 8 Delivery V Network 7200 for voice/data Figure 2-32: 3660 As FRF.8 Switch at Head-End 3 WAN Solution Scenarios 3.1 Introduction The 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-Core If 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 Cisco Confidential 30

×