PDF of this tutorialThree technologies are emerging for the process of consolidating voice and data: frame relay, ATM, and IP. Each is optimized for different applications and has different design objectives and a different heritage, which will determine the extent of the role that each will play in networks of the future.
Voice over Frame Relay
Frame relay was explicitly designed as a solution for the burgeoning bandwidth and LAN interconnection requirements of corporations in the early 1990s. Specifically, it was designed for data applications. While frame relay was initially offered at rates ranging from 64 kbps to 1.544 Mbps, several carriers began offering high-speed frame relay at speeds of up to DS–3 in 1996 to address bandwidth constraints at central sites of corporate networks. In an effort to make frame relay more flexible in terms of bandwidth requirements by bridging the gap between DS–1 and DS–3 access rates, the Frame Relay Forum is currently working on an implementation agreement for multilink frame relay. According to this agreement, users will be allowed to inverse-multiplex multiple, low-speed access links into one higher-speed, logical connection. Frame relay requires that a logical connection be established between all users wishing to communicate, which limits the connectivity capabilities of frame relay compared to connectionless protocols such as IP.
Natural market forces are slowing frame relay’s growth rate as its target market saturates and users are uncertain of the role of frame relay in an IP world. Although it was originally positioned as a data service, frame relay for voice applications was soon promoted by frame-relay access device (FRAD) vendors. The length of the frame can vary, although the maximum size allowed by service providers is typically 4,096 bytes in alignment with LAN frame sizes. The use of relatively long, variable-length frames is attractive to the data community because it decreases the amount of overhead for frames carrying data traffic, which tend to be large in size. Unfortunately, this can create problems for voice traffic, as the variable-length frames can cause variable-length delays that may degrade the quality of voice. The widespread deployment of ATM backbones by service providers addressed the nodal delay and latency issues associated with voice over frame relay. Currently, more than 70 percent of all traffic that originates as frame relay at the customers’ premises runs over an ATM backbone. Voice over frame relay will prove to be an interim solution as other alternatives become more prominent in the year 2000.
Voice over ATM
ATM has been embraced by incumbent local and long-distance carriers as well as next-generation telcos. ATM offers service categories that comprise the highly touted QoS capabilities. Although ATM was specifically designed for the consolidation of voice, video, and data traffic, most users to date are using it for high-speed data applications. Only recently has there been a surge in activity with voice over ATM in the equipment-vendor and service-provider areas. However, there is clearly a new model beginning to emerge that uses ATM as a multiservice access consolidation technique to provide connectivity to traditional circuit-switched voice networks and packetized data networks such as public frame relay and the Internet. This will allow both on-net and off-net voice capabilities for end users, while the access line is shared with data applications.
In this configuration, tier-1 (T1) ATM is used as an access mechanism to reach the service provider’s point of presence (PoP). Gateways are located at that point to direct traffic to the appropriate networks and send off-net voice to the PSTN, frame-relay traffic to a frame-relay network, and IP traffic to the Internet. On-net voice and data traffic can be transported natively across the network. This model represents a graceful migration path to convergence; service providers preserve their investment in existing networks, while the disruption to users is minimized.
ATM was specifically designed to address the latency and delay issues that arise when transporting multiple traffic types, including voice or other delay-sensitive traffic, across a network. Such delay issues resulted in the selection of a fixed-length, 53-byte cell, a compromise between the longer length favored by the data community for its lower overhead and the shorter cell size favored by the voice community to handle QoS issues for delay-sensitive traffic such as voice. The cell size is not optimal for any single traffic type but is optimized for a mixture of traffic types with varying requirements from the network. ATM has been criticized rather viciously for being a technology that can support all types of traffic adequately but that does not support any single type of traffic well. Other alternatives, however, wrestle with these same issues. Challenges also lie ahead in terms of defining standards for ATM/PSTN gateways that will be the linchpin of the multiservice access model.
Voice over IP
In VoIP, voice equipment connects to the WAN access device, which packetizes and performs the required processing before passing it to the WAN. This could be either a public or private IP–based network or a public frame-relay or ATM network.
The stringent delay requirements of voice traffic have traditionally presented a formidable challenge for connectionless IP networks. Vendors have focused their attention on confronting this challenge with enhancements to equipment that will provide QoS in IP networks.
A number of techniques are being employed to accomplish this objective, many of which are similar to those used in ATM networks. QoS in an IP network is a network-wide challenge; it cannot be restricted to individual parts, as the QoS chain is only as strong as its weakest link. The most prominent initiative falls under the differentiated services banner. This work is relevant for service providers who wish to escape the flat-rate, low-margin, best-effort model of IP services that currently prevails because it will enable them to offer tiered service offerings.
The VoIP market diverges from both frame relay and ATM when it comes to breadth of vendor support because VoIP will ultimately be the end-to-end packetized voice solution. Explaining the tremendous amount of activity in the area of VoIP is simple. VoIP leverages the huge worldwide installed base of transmission control protocol (TCP)/IP networks in public and private networks, the LAN and the WAN, and business and residential markets. IP is thus distinguished from any other technology or protocol in existence.
Turning the traditional best-effort service offered by IP into one that provides QoS for different types of traffic has proven to be a formidable task. Currently, the technology remains unproven and immature, and the standards controversies are simmering as competitive positioning among vendors intensifies.
The most important specification is the family of H.323 standards, the most widely deployed specification for voice over IP. However, there are a number of concerns about H.323’s long-term viability. Controversy rages over the choice and number of compression algorithms used, the use of Q.931 as a call setup mechanism, security issues, and the feeling among some that H.323 sacrifices the critical advanced telephony features and functionality required to offer enhanced services and achieve interoperability. These issues have led to the concern, in the VoIP community, that what is rapidly becoming the de facto standard is not the optimal solution and that its shortcomings will adversely affect the evolution of the market in the future. Despite these legitimate concerns, H.323’s momentum continues to grow in the marketplace.
The Internet Engineering Task Force (IETF) has also been working diligently to develop specifications to enable real-time applications such as voice to work over IP. The most prominent IETF initiative falls under the banner of differentiated services (DiffServ). The work of the DiffServ group is relevant for service providers wishing to escape the flat-rate, low-margin, best-effort model of IP services that currently prevails because it will enable them to offer tiered service offerings. While DiffServ can be implemented in pure hop-by-hop traditional router networks, the IETF is also working on another mechanism that can be used in conjunction with it to allow service providers to offer multiple classes of service. That mechanism is multiprotocol label switching (MPLS). Essentially, MPLS combines the benefits of connection-oriented technologies with the flexibility and ubiquity of connectionless IP to enable multiple classes of service to be provisioned over a service provider’s backbone. Several technologies could be used in the backbone, including ATM, frame relay, and high-speed routers.
The current trend indicates that the model of future IP–based networks will use IP to access the network where DiffServ mechanisms will be in place to prioritize traffic according to application requirements. These will then be translated into MPLS language at the network ingress with the use of a label to be attached to the packet for transport across the backbone network. This configuration will allow service providers to offer several classes of service, based on relative QoS.
Multimedia gateway control protocol (MGCP) is a combination of IP device control (IPDC) and simple gateway control protocol (SGCP), both of which were designed to interconnect IP and SS7 networks. MGCP has gained considerable momentum over the past six months as a technique to address the scalability issues of H.323.
The IETF’s Multiparty Multimedia Session Control Working Group (MMUSIC) has developed yet another signaling protocol that can be used for IP telephony. It is called session initiation protocol (SIP) and is more IP–centric than H.323. SIP is considered to be better for implementations of IP telephony over wide-area networks.
VoIP in the WAN access segment can be configured in a number of ways in enterprise networks. The one most relevant for WAN access involves direct connection between a private branch exchange (PBX) and a VoIP–capable router or access device. The question then becomes what to use for the wide-area connection. The choices in a public environment are the Internet or public data services such as frame relay or ATM. Voice over the Internet is not viable in the short term for several reasons. The ability to offer multiple service levels is based on the network’s ability to support QoS. This is a nontrivial task for the Internet. The evolution of the Internet to support QoS is an enormous task, replete with technical, regulatory, logistical, and political challenges. Finally, until IP gateways that are capable of providing the features and functionality of the PSTN are widely deployed, corporations will shy away from pure VoIP in public environments (see Table 1).
