Frame relay is first and foremost a fast packet service. This means it is a Layer 2 technology that provides a packet network service without any error correction provided. Frames submitted to the network are checked for errors, discarded if they are found to have errors, and processed if they are error-free. The processing itself is straightforward: the switching nodes provide a simple relaying function, passing frames across the network fabric to their intended destination.
Frame relay products and implementations are based on standards. The ITU-T provided the framework for frame relay in Recommendations I.122 and I.233. ANSI and other national standards groups assimilated this work for further development within their respective countries. An industry group, the Frame Relay Forum (FRF), developed a series of implementation agreements to help ensure equipment interoperability and service interoperability, and to address user issues not addressed by the telecommunications standards organizations. The FRF no longer exists as a separate organization; it has merged with the Multiprotocol Label Switching (MPLS) Forum.
The absence of any error correction by the service means that frame relay is making two assumptions: that the underlying facilities are largely error-free, and that the end-user is providing his/her own error correction capability. These two assumptions are crucial. First of all, few data environments can tolerate the corruption or loss of data. Frame relay protects against corruption of data. It provides an error check that ensures bit errors are trapped. However, because it lacks a correction capability, it cannot ensure that data is actually delivered. This means that the end-user of the service must have the ability to detect and recover from loss of data within the frame relay service. Fortunately, the protocols in use on the customer premises provide this exact capability.
However, user recovery from data loss is notoriously inefficient. Anyone who has downloaded a Web page and experienced the freezing of that notorious green progress bar at the bottom of Internet Explorer knows what it means to have to wait for recovery from loss. It takes time to do. If the network has a high bit error rate (BER), this will occur frequently and the user will not be satisfied with the service. So frame relay only makes sense when the underlying network is largely error-free. This, in turn, implies a digital and preferably optical infrastructure.
It may seem odd to offer a wide area network (WAN) service that has this casual indifference to bit errors. It is actually not all that different from how customer premises networks have operated for years. If a customer is using Ethernet on premises (and the vast majority are), Ethernet also does not care about correcting bit errors. So data traveling from client to server and crossing both Ethernet and frame relay networks is just as likely to be discarded in the LAN as in the WAN. As long as both do it sparingly, the result is an efficient packet network infrastructure.
Frame Relay and Virtual Circuits
Frame relay provides a connection-oriented, virtual circuit service, in that it is similar to its predecessor: X.25. A service that is connection-oriented is one that involves three distinct communication phases. In the first phase, known as “call setup,” the connection relationship is established. In the second phase, known as “data transfer,” an actual communication occurs. In the final phase, known as “call termination,” the communication relationship is discontinued. There are many examples of connection-oriented communication environments, including the public switched telephone network (PSTN), the X.25 packet service, and even Transport Layer protocols like the Transmission Control Protocol (TCP). The opposite of connection-oriented is connectionless. In a connectionless communication, there is no call setup or call termination phase. One simply transmits when one has something to say. The post office is a good example of a connectionless environment. In networks, connectionless protocols include Ethernet, the Internet Protocol (IP), and the User Datagram Protocol (UDP), none of which require advance warning before a transmission occurs.
Frame relay’s connection-oriented nature manifests itself as a construct called a virtual circuit (VC). In packet networks, a VC is a pre-established path through the network on which communication between two endpoints occurs. It behaves much like a real circuit, with one critical exception. Although the path is defined through the network, the bandwidth on the path is not “nailed up.” That is to say, the VC only consumes bandwidth on the network facilities when there is actually a frame being sent. If there is no frame sent, no network resource is consumed. The switches know the VC exists, but the links are not reserved for the circuit. In a true circuit network, the circuit would demand dedicated bandwidth from every trunk it crosses.
In frame relay, then, no traffic is permitted to cross between two interfaces to the service until a VC is defined between those two interfaces. To the user of the frame relay service, VCs come in two basic flavors: permanent and switched. A permanent VC (PVC) is provisioned when the customer buys the service, and stays in place as long as it remains a customer. A switched VC (SVC) is requested by the customer premises equipment CPE as it is needed, and the CPE requests its removal when it is no longer needed.
Frame Relay and the OSI Model
This visual shows the relationship of the frame relay protocol layers to the OSI model. It shows the levels of protocol invoked during data transfer for either permanent virtual circuit (PVC) or switched virtual circuit (SVC) frame relay.
The first thing to notice is that there are only two levels of protocol used to transfer data across a frame relay network. This is the reason frame relay is often described as a Layer 2 protocol.
Physical connectivity to a frame relay network is typically through a V.35, X.21 or High-Speed Serial Interface (HSSI) ports on a router (or other device) connected to a digital access line, such as 56/64 kbps, T-1/E-1, or T-3/E-3.
The Data Link Layer for frame relay is the Link Access Procedure to Frame Mode Bearer Service (LAPF), which is similar to the High-level Data Link Control (HDLC). It has roots in the Link Access Procedure–D Channel (LAPD) used on an Integrated Services Digital Network (ISDN) D-channel. There are actually two variations of it in use on the frame relay interface. A highly simplified version, called LAPF-Core, is used for actual data transfer on a VC. LAPF itself is used for management and signaling.
For data transfer, there is no need for any upper layer activity. Frame relay is simplicity incarnate. However, there are additional functions that require more capability. First, for SVC frame relay, there must be a way to establish and terminate virtual circuits (VC) on demand. Q.933 provides this by defining signaling messages, such as CALL ESTABLISHMENT, CALL PROCEEDING, DISCONNECT, etc. That being said, SVCs are largely a matter of fiction in the industry. Few (if any) service providers are offering them.
Second, we need a way to verify the integrity of the frame relay interface itself, and to report the status of all VCs on that link, generically referred to as link management. Q.933 defines link management messages (i.e., STATUS ENQUIRY and STATUS) for these purposes.
Frame Relay Interfaces
It is important to realize exactly what a frame relay service is and is not. The visual shows the two interfaces defined by frame relay standards.
The customer must have premises equipment that is frame relay-capable; it can communicate using the frame relay protocols. This equipment communicates with the carrier's frame relay switch over a standard interface known as the User-to-Network Interface (UNI). The UNI specification describes supported Physical Layer options, as well as all of the Data Link Layer characteristics of the interface. Today, all of the Physical Layer options supported in the market are dedicated facilities (e.g., DS-0, DS-1, DS-3). On the UNI, however, there is a clear definition for which end of the link is the user, and which end is providing the service, and the role of the user is different from the role of the network. For example, the network can inform the user that a virtual circuit (VC) has gone out of service. The user is the endpoint of the VC, so it would make no sense for the user to have this capability.
If two frame relay networks need to interconnect so that users on one can communicate with users on the other, the standard interface between the two service providers’ networks is called the Network-to-Network Interface (NNI). Here both ends of the link are frame relay switches and they must be able to operate as peers; thus the interface operates in a manner slightly different from the UNI.
It is especially important to realize which interfaces are omitted from the frame relay specifications. These are the interfaces between the switches within the same service provider’s network. This does not mean that there are no interfaces, of course; it just means that whatever is used here is up to the switch vendor and carrier, and it might be proprietary.
There are two reasons for this apparent oversight. First, historically, such public networks have used products from a single vendor, so interoperability has not been an issue. Second, vendors are free to improvise and devise more efficient protocols for use on these switch interfaces, and thus position their products against their competitors. Carriers are free to choose the technology they feel is best and leverage that against their competitors.
The results have been twofold. First, it has made service interoperability all but impossible without a full NNI definition (hence the need for the NNI specification). Second, switch vendors have looked for other standards to “fill the gap” with regard to this aspect of frame relay. Many vendors have latched on to asynchronous transfer mode (ATM) for this purpose. The effect is to have built a frame relay service with an ATM core.
Specifications for the frame relay UNI are described in ANSI standards T1.617 and T1.618 (which roughly correspond to ITU-T Rec. Q.933 and Q.922, respectively) as well as specific network providers’ service specifications. The Frame Relay Forum (FRF) has also produced a specification for the UNI known as FRF1.2.
Specifications for the frame relay NNI are described in ANSI T1.606b and ITU-T Recommendation I.372. The FRF also defined procedural changes that were needed at the NNI in their FRF.2.2 document.
Frame Relay Network Components
The diagram shows the major components that can theoretically be found in a frame relay environment. There are three basic types of components: user equipment, private frame relay switches, and public frame relay service networks.
The generic term for a device at the user end of a frame relay UNI is a frame relay access device (FRAD). A FRAD can be any device that can take any end-user protocol or traffic and place it into frame relay frames for transmission into the frame relay service. The primary use of frame relay services has been for the interconnection of LANs, so a common type of FRAD is the router. Virtually all routers capable of implementing a WAN port can run frame relay on that port. There are also a host of other devices that can adapt other technologies to frame relay. There are voice FRADs that put voice samples into frame relay. There are video FRADs that place video sessions into frame relay. There are also a host of lower end FRADs that can connect older IBM technologies to frame relay. In fact, over time, the term FRAD has itself become associated with these low-end devices, and a router with frame relay capabilities is simply called a router.
At the network end of the UNI is a frame relay switch. Frame relay switches can be owned by a customer to form a private backbone network. If the customer were to build such a network, the link between the private network and the carrier’s network would have to be a NNI. Private frame relay networks are not common, however.
The public network is also a collection of switches, but they are owned and operated by the service provider. The interface between two carrier services is also an NNI.
|<mp3>http://podcast.hill-vt.com/podsnacks/2007q1/frame_relay.mp3%7Cdownload</mp3> | Frame Relay|
|<mp3>http://podcast.hill-vt.com/podsnacks/2007q1/frame_relay_addressing.mp3%7Cdownload</mp3> | Frame relay addressing|