Fundamentals of Voice over Frame Relay
Fundamentals of Voice over Frame Relay
by Brian Morgan - September 20, 2000
This article serves as both a basic and not-so-basic overview of some of the technologies behind Voice over Frame Relay (a primer of sorts). Implementations of this rapidly growing technology are numerous and continue to push it to its limits. The transport of voice traffic over data networks is an increasingly common implementation. It is important to gain an understanding of the technology in general. This article will not cover VoFR in depth; however, it does provide a basic understanding of the technology and assumes that the reader is already familiar with Frame Relay usage and terminology.
Technology, and its evolution, is usually driven by one thingmoney. The cost of telecommunications has always been an issue in every company. Whether that cost relates to site connectivity or long distance calling charges, companies are all looking for a way to cut costs.
What if it were possible to bypass some of the normal tolls involved in passing phone calls from site to site within the company? There are already plans for data connectivity (possibly already implemented). Why not pass voice traffic across our data lines? That way, charges will not be assessed for long distance calls.
This is the driving force behind VoFR technologies.
Contrary to popular belief, you do not receive "free" phone calls with any "voice over" technology. We've all heard the line, "Hey, let's put voice on our data circuits. We're already paying for them, so the voice calls will be free." This topic is discussed in the text of this document. Get that thought out of your head now. Unfortunately, nothing is free.
Voice over Frame Relay is defined by the Frame Relay Forum specification FRF.11. This specification is discussed in its own section, "FRF.11 Voice over Frame Relay," a bit later. This section contains a very brief review of basic Frame Relay operation.
Frame Relay is a switching technology that was developed to facilitate point-to-point as well as point-to-multipoint connectivity. Frame Relay was developed to support high-speed data transfer over a telco network. Its purpose is to provide a way of sending information across a WAN by dividing it into frames. Each frame has an address that the network uses to determine the destination of the frame. The frames travel through a series of switches within the Frame Relay network and arrive at their destination.
Frame Relay networks are typically depicted as clouds, because the network is not made up of physically connected endpoints. Instead, a logical path known as a Virtual Circuit (VC) is defined within the network. Each of these virtual circuits is differentiated from others using an identifier known as a DLCI.
Frame Relay is a data link layer technology, which makes use of unique connection identifiers to differentiate conversations. These connection identifiers are known as Data Link Connection Identifiers (DLCIs). DLCIs are usually statically assigned through the configuration of Permanent Virtual Circuits (PVC). PVCs are manually configured into each switch that the circuit must traverse. They are similar to static routes manually configured into a router. Switched Virtual Circuits (SVC) allow the dynamic assignment of DLCIs (SVCs are not common with Frame Relay implementations and therefore won't be discussed further in this article). A DLCI is locally significanta term that's been thrown around with some frequency. Local significance means that this identifier has meaning only on the present leg of a connection (i.e., a single leg of a connection between a router and switch or between two switches). Consider Figure 1 as an example.
Figure 1 DLCI Local Significance Illustration
In the preceding figure, each leg of the connection has a DLCI that is meaningful only for that leg of the transmission.
DLCIs are used in making switching decisions. When paired with an inbound or outbound interface designation, the DLCI creates a unique piece of information with which the switch can make a path decision. In Figure 1, for example, frames entering switch A through interface 1 having a DLCI of 16 are switched to interface 2, and a new DLCI of 42 is assigned. The decision is based on the switchs PVC definition.
Hopefully, everything we've covered to this point has been review material because that's as deep as we go in this section. For more information on Frame Relay in general, check out http://www.frforum.com.
Frame Relay Topologies
Frame Relay implementations have been deployed in a number of differing manners. Overall, the ideas behind these implementations are similar. Frame Relay supports full mesh, partial mesh, and hub & spoke topologies, as follows:
- Full MeshThe full mesh topology is an "all-to-all" implementation and tends to be the most robust. This topology can be considered to have a form of redundancy built into it because each router has connections to every other router (true redundancy involves multiple paths between each router). Should one connection fail, connectivity to remote networks can still be achieved via another router (as long as it was the link that failed, not the router). This topology also results in the least delay for traffic moving across the network. One disadvantage to the full mesh, however, is that it is the most expensive topology to run.
- Partial MeshThe partial mesh topology is a less expensive cousin of the full mesh. Partial mesh involves redundant (multiple path redundancy, not parallel link redundancy) connections between high volume and/or critical sites co-existing with single connections from lower volume and/or non-critical sites converging into a central site.
- Hub & SpokeThe hub & spoke topology consists of a central site router with connections to all remote sites. This is the most common type of topology implemented in Frame Relay installations. There are usually very few, if any, redundant connections. Redundant connections are typically provided by ISDN dial backup circuits.