Frame Relay Overview

back | next | index

Frame Relay is probably the simplest data communications protocol ever conceived. Designed to run over virtually error- free circuits, it's a protocol stripped down for speed.
Frame Relay abolishes the Network Layer of the OSI model, claims the routing and multiplexing functions for itself, and leaves everything else to the higher layers. A Frame Relay service ignores traditional functions such as window rotation, sequence numbering, frame acknowledgment, and automatic retransmission in order to concentrate on the basics: delivering correct data quickly in the right order to the right place. It simply discards incorrect data.

The need for a streamlined protocol like Frame Relay grows from several facts of modern data communications:

Users have more data to communicate, and they'd like that data to travel faster and in larger chunks than current technology has allowed.

Physical transmission gets faster every year and introduces fewer and fewer errors into the data.
Computers and workstations with the intelligence to handle high-level protocols have replaced dumb terminals as the instruments of choice.

Thanks especially to cleaner transmission and smarter workstations, the procedures that traditional Data Link and Network protocols use to recognize and correct errors have become redundant for jobs that require large volume at high speeds.
Frame Relay handles volume and speed efficiently by combining the necessary functions of the Data Link and Network layers into one simple protocol. As a Data Link protocol, Frame Relay provides access to a network, delimits and delivers frames in proper order, and recognizes transmission errors through a standard Cyclic Redundancy Check. As a Network protocol, Frame Relay provides multiple logical connections over a single physical circuit and allows the network to route data over those connections to its intended destinations.
In order to operate efficiently, Frame Relay eliminates all the error handling and flow control procedures common to conventional protocols such as SDLC and X.25. In their place, it requires both an error-free transmission path, such as a digital carrier circuit or a fiber span, and intelligent higher- layer protocols in the user devices.
By definition, Frame Relay is an access protocol that operates between an end-user device such as a LAN bridge or router or a front-end processor and a network. The network itself can use any transmission method that's compatible with the speed and efficiency that Frame Relay applications require. Some networks use Frame Relay itself; others use either digital circuit switching or one of the new cell relay systems.

Frame Relay Networks

The logical path along an originating Frame Relay link, through the network, and along a terminating Frame Relay link to its ultimate destination is called a virtual route or virtual circuit. In a network with Frame Relay access, a virtual circuit uniquely defines the path between two endpoints.
In the diagram above, a mainframe communicates with each of the workstations (devices) on the LAN over a separate virtual circuit. The Frame Relay protocol identifies a virtual circuit by a 10-bit address called a Data Link Connection Identifier (DLCI). Each DLCI is unique on its local Frame Relay link. However, DLCIs are NOT unique throughout the network.
Since the DLCI is a 10-bit number, the Frame Relay protocol defines 1024 possible DLCIs. Of these, 2 (0 and 1023) have been reserved for signalling and 30 (1 to 15 and 1008 to 1022) have been reserved for future use.
For instance, networks that have implemented the optional multicasting feature reserve DLCIs 1019 to 1022 for that purpose. The remaining 992 DLCIs, (16 to 1007), are available to subscribers.
The current Frame Relay standards specify only permanent virtual circuits (PVCs, sometimes called Permanent Logical Links, or PLLs), which are defined when a user first subscribes to the service. Future versions may also include Switched Virtual Circuits (SVCs).
At subscription time, each PVC is assigned several important parameters. First is its Committed Information Rate (CIR), which is the largest number of bits per second that the network agrees to transmit for a PVC within a specified period without discarding data. A PVC's CIR may be less than or equal to the physical capacity of the whole Frame Relay circuit.
Next is its Committed Burst Size (Bc), which is the largest number of consecutive bits that the network agrees to carry without discarding data. Some networks also assign an Excess Burst Size (Be) over the Committed Burst Size, which the network agrees to carry with a greater likelihood that some data will be discarded.

A Frame Relay network can discard data for any of three reasons:

A subscriber has exceeded the amount of data that the network has agreed to carry
A failed Cyclic Redundancy Check, which indicates physical transmission errors
Network congestion, which occurs when the network's community of subscribers transmits enough data to approach or exceed the network's capacity to carry it

A Frame Relay network relies on the higher-layer protocols in its attached devices to recover from errors or congestion. In practice, this means that the higher layers must recognize that the network has discarded one or more frames of data.
Most higher-layer protocols use rotating sequence numbers to recognize frames that have been discarded. When a device receives a sequence number out of order, it requests that its partner retransmit all frames in order since the last frame it received with a correct sequence number.
In a well-tuned network, this typically includes the missing frame and all frames that its originator had transmitted in the time the destination device took to recognize the discard and send a message across the network requesting retransmission. In most cases, the originating device retransmits more data than would have been necessary.
This is a very reliable way to recover data lost through occasional transmission errors. However, when data's been discarded because of traffic congestion, bulk retransmission can only make the problem worse.
Fortunately, most higher-layer protocols use some form of throttling or flow control mechanism to recognize and prevent congestion.
The Frame Relay protocol also provides a way for the network to alert its subscribers when it becomes congested. The header of each Frame Relay frame contains two Explicit Congestion Notification bits that the network can set if it transmits that frame over a congested path. Each of these bits signifies congestion in a specific direction on the virtual route.
A value of 1 in the Forward Explicit Congestion Notification (FECN, pronounced "feacon") bit indicates that the frame has encountered a congested path on its way across the network.
A value of 1 in the Backward Explicit Congestion Notification (BECN, pronounced "beacon") bit indicates that the path through the network in the direction opposite the frame's path (i.e., toward the frame's source) is congested.
The FECN and BECN bits explicitly notify a subscriber's device of congestion on the network and implicitly ask that device to withhold traffic or reduce its transmission rate until the congestion has cleared.

Frame Relay Frame Header


       8     7     6     5     4     3     2     1
    |     |     |     |     |     |     |     |     |
 0  |  0  |  1  |  1  |  1  |  1  |  1  |  1  |  0  |  FLAG
    `-----`-----`-----`-----`-----`-----`-----`-----' ...
    |                                   |     |     |   :
 1  |     DLCI (high-order bits)        | C/R |  EA |   : FRAME
    `-----------------------------------`-----`-----'   > RELAY
    |                       |     |     |     |     |   : HEADER
 2  | DLCI (low-order bits) | FECN| BECN|  DE |  EA |   :
    `-----------------------`-----`-----`-----`-----' ..:
    |                                   |     |     |
 3  |         ADDRESS EXTENSION         | D/C |  EA |  EXTENDED
    `-----------------------------------`-----`-----'  ADDRESS

The Frame Relay frame header is illustrated above. The first octet is a flag field that delimits the frame from another frame or from idle time on the circuit. The second octet contains the first 6 bits of the 10-bit DLCI followed by a Command/Response bit (C/R) and the frame's first Extended Address (EA) bit.
Use of the C/R bit is not defined by Frame Relay, so implementers are free to define a function for it. A value of 0 in an EA bit indicates that the frame's address (DLCI) continues in the next octet. Since the DLCI must occupy parts of two octets at minimum, the EA bit in this octet should always have a value of 0.
The next octet contains the remaining four bits of the DLCI followed by the FECN and BECN bits described above, a Discard Eligibility (DE) bit, and the frame's second EA bit.
The subscriber or the network may set the value of the DE bit to 1 to indicate that the network may discard this frame in preference to frames in which the value of the DE bit is 0. (This occurs only after it has discarded all frames transmitted in excess of their subscribers' CIR and Bc).
In a normal Frame Relay frame, the value of the EA bit in this octet should be 1, to indicate that the address information ends here. An EA value of 0 indicates an that an Extended Address Octet follows. Extended addressing is seldom implemented.
The subscriber's data follows the Frame Relay header in most Frame Relay frames, and the data is followed in turn by the 2- octet Frame Check Sequence (FCS) and a final flag octet. A frame must contain at least one octet of user data for a total of 5 octets between flags.
A frame may not exceed 8192 octets between flags, counting header and FCS. The latest Frame Relay standards recommend a maximum frame size of 1600 octets overall.
Implementers are free to define a smaller maximum frame size if they wish.

Local Management Interface

A major area where the Frame Relay protocol leaves room for improvement is the management of the interface. The network and the subscriber's device should be able to communicate information on which DLCIs have been configured for the link and on which DLCIs are currently active. Since Frame Relay applications can go for relatively long periods without bursts of data, the devices also need a mechanism for ensuring that the physical link is running normally in the absence of traffic.
In September 1990, a group of Frame Relay vendors introduced a signalling mechanism for Frame Relay links that handles both of these functions. The Local Management Interface (LMI) is a simple protocol that runs in one dedicated PVC of a Frame Relay link and allows the subscriber and the network to exchange information about the link itself and about the status of the other PVCs. Since LMI occupies its own PVC, its link signalling cannot congest or interfere with traffic on the PVCs that carry subscriber data.
The use of LMI is entirely optional.
The protocol is designed so that the subscriber must originate all exchanges of information. This feature prevents the network from transmitting unwanted information to subscribers whose devices haven't implemented the LMI protocol.

The subscriber begins an LMI exchange by sending a Status Enquiry message. The Network completes the exchange by answering with a Status message. An exchange of LMI messages can perform either of two functions:

A simple "heartbeat" exchange that verifies that the link is running normally
A report on the individual status of each DLCI defined for the link

LMI Frame Header

      8     7     6     5     4     3     2     1
   |     |     |     |     |     |     |     |     |
0  |  0  |  1  |  1  |  1  |  1  |  1  |  1  |  0  |  FLAG
   `-----`-----`-----`-----`-----`-----`-----`-----` ...
1  |  1     1     1     1     1     1  |  0  |  0  |   :  LMI
   `-----------------------------------`-----`-----`   >  DLCI
2  |  1     1     1     1  |  0  |  0  |  0  |  1  |   :  1023
   `-----------------------`-----`-----`-----`-----' ..:
3  |  0  |  0  |  0  |  0  |  0  |  0  |  1  |  1  |  LAPD UI
   `-----`-----`-----`-----`-----`-----`-----`-----'
4  |  0  |  0  |  0  |  0  |  1  |  0  |  0  |  1  |  PROT DISC
   `-----`-----`-----`-----`-----`-----`-----`-----'
5  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  DUMMY CREF
   `-----`-----`-----`-----`-----`-----`-----`-----'
6  |    MESSAGE TYPE (STATUS OR STATUS ENQUIRY)    |
   `-----------------------------------------------'
   |    INFORMATION ELEMENTS ACCORDING TO TYPE     |
   `-----------------------------------------------'

An LMI frame is divided into a header of 6 octets (beyond the flag) and a list of Information Elements (IEs) that carry the heartbeat or status information. The Data Link protocol used for LMI is a subset of LAPD, the ITU's Link protocol for ISDN signalling. Where the Frame Relay link protocol defines a 2- octet frame header, the LAPD protocol defines a 6-octet header.
Octets 1 and 2 contain the DLCI used by LMI. In the original LMI specification, this was defined to be DLCI 1023. The DLCI appears in Frame Relay format, 6 bits in octet 1 and 4 bits in octet 2. Notice that the Frame Relay control bits (C/R, EA, FECN, BECN, and DE) are all present, but in practice, only the final EA bit (1 for "end of address") is actually used.
Octet 3 identifies all LMI frames as Unnumbered Information frames according to the LAPD standard.
Octet 4 contains a protocol discriminator which identifies the frame as one containing LMI information. (The protocol discriminator will become more important in future implementations that may use other signalling protocols such as ISDN's Q.931 instead of, or along with, LMI.)
Octet 5 contains a LAPD parameter called a Call Reference. In LMI frames, this is a dummy field that's always set to 0.
Octet 6 identifies the LMI Message Type as either Status Enquiry (from the subscriber) or Status (from the network).

LMI Frame Information Elements

Behind the header, the basic LMI protocol recognizes just three types of information elements (IEs):

Report Type
Keep-Alive
PVC Status

All LMI messages contain one Report Type element and one Keep- Alive element. A full Status message from the network to the subscriber also contains one PVC Status element for each PVC on the link.
The Keep-Alive information element contains a pair of 8-bit sequence numbers, Current and Last Received, through which the heartbeat process maintains a running check on the health of the link.
The heartbeat process is similar to the error detection mechanism used by higher-layer protocols. At a regular interval, the subscriber sends a Status Enquiry message that contains a Report Type value of Sequence Number Exchange and a Keep-Alive Element.
When the Network receives the message, it records the Current Sequence Number as its Last Received Sequence Number, increments it by one to produce its new Current Sequence Number, and transmits a Status message with a Keep-Alive element that contains the new numbers.
The sequence numbers rotate in Modulo 256 with one exception. In normal sequence counting, both the subscriber and the network must skip the value 0. Either side may reset its sequence count to 0 at any time: the LMI specification leaves this option open to implementers as a way to reset the heartbeat process in response to conditions on the link.
If either side receives a heartbeat message in which the Sequence Numbers don't follow correctly, it may declare an LMI sequence error. The LMI protocol does not define how users are to handle errors, but suggests maintaining a count of "error events," including bad frames (failed frame checks) and LMI sequence errors, and initiating error-handling procedures when the count reaches a specified threshold within a specified period.
Error handling mechanisms such as alarms and link resets are left to the implementers.
After a specified number of sequence number exchanges, the subscriber issues a Status Enquiry with a value of "Full Status" in the Report Type element. The network answers with a Status Message containing a PVC Status information element for each DLCI currently defined for the link.
Like all LMI information elements, it begins with 2 octets that indicate its element type and length. The next 2 octets contain the DLCI of the PVC on which the element reports.

Note that the format of the DLCI octets is different from that in the Frame Relay header. In the first octet after the DLCI, the first 4 bits are not used and are set to 0. Two of the next 4 bits have meaning in all LMI implementations:

N (New) bit
A (Active) bit

The N bit is set to 1 only when the PVC Status element is reporting on a newly defined DLCI. The N bit will be reset to 0 in all subsequent PVC Status elements for that DLCI.
The A bit is set to 1 whenever the PVC to which the element refers is Active, i.e., known to be transmitting and receiving data. Implementers are free to define when and how a PVC becomes active.
Functions of the bits labeled "D" and "R" and of the three reserved octets at the end of the element are defined by a set of optional extensions to the LMI specification.

Optional LMI Extensions

The LMI specification also defines several optional extensions:

Global addressing convention
Multicast capability
A simple flow control mechanism
Ability for the network to communicate a PVC's CIR to the subscriber in a Status message
A new message type that allows the network to announce PVC status changes without prompting from the subscriber

Implementers may build any, all, or none of these features into their networks.

Global Addressing

The global addressing convention defines a simple commitment from the operator of a network that DLCIs will remain unique throughout the network. In a globally addressed network, each DLCI identifies a subscriber device uniquely.
For a few years Frame Relay networks will remain small enough that they won't need to implement extended addressing to use the global addressing feature. As networks grow and interconnect, any trend toward global addressing will probably require use of extended addresses.

Multicasting

The LMI multicast capability adapts a popular feature from the LAN world. It reserves a block of DLCIs (1019 to 1022) as multicast groups so that a subscriber wishing to transmit a message to all members of the group must transmit the message only once on the multicast DLCI.
The multicasting feature requires a new information element, Multicast Status, in the full LMI Status message. The Multicast Status element is similar in most respects to the PVC Status IE, but it includes a field for the source DLCI transmitting over the multicast group. It also omits the function of the R bit (see below), since a multicast group may use several paths with different congestion conditions.

Flow Control

The optional LMI flow control capability provides a way for the network to report congestion to the subscriber. The flow control feature uses the optional R bit in the PVC Status information element as a "Receive-Not-Ready" signal for the PVC whose status is being reported. A 1 in the R bit indicates congestion; a 0 indicates no congestion.
On networks where LMI is fully implemented, this feature improves on the ECN bits of the basic Frame Relay protocol because the LMI heartbeat process guarantees that PVC Status elements will reach the subscriber periodically. Of course, according to the laissez faire practice of Frame Relay, the subscriber may or may not have implemented the feature, and may or may not choose to act on the information.

Communicating the Minimum Bandwidth Available

The next optional feature uses the three reserved octets at the end of the PVC Status information element to communicate the minimum bandwidth available on the network to the PVC.
In most implementations, this number will be the PVC's CIR. However, clever implementers and operators may begin to use this feature to respond to changing traffic conditions by dynamically increasing or decreasing the bandwidth available to individual PVCs.
The specification neither encourages nor forbids such practices.

Status Update Message

The final optional feature of LMI allows the network to communicate changes in a PVC's status by means of a message type called Status Update without first receiving a Status Enquiry from the subscriber.
The Status Update contains only PVC Status and Multicast Status information elements, so it cannot function in the heartbeat process. Further, it contains Status elements for only those PVCs and multicast groups whose status has changed.

Changes reported include:

Deletion of a PVC or multicast group (reported by setting the optional D bit of the Status element)
Changes in the minimum bandwidth allocated to a PVC
Activation or deactivation of a PVC (indicated by setting or clearing the A bit)
Flow control information (changes in congestion status, signaled by setting or resetting the R bit). Besides improving flow control, this feature allows LMI signalling over network-to-network Frame Relay connections where neither partner functions as a subscriber device

Consolidated Link Layer Management

Another signalling protocol for Frame Relay networks predates LMI. In its original Frame Relay specification, the American National Standards Institute (ANSI) defines an optional Consolidated Link Layer Management (CLLM) message.
CLLM's major function is to augment the BECN mechanism for reporting congestion by allowing the network to report in the "backward" direction in the absence of PVC traffic to carry explicit congestion notification. Both LMI and CLLM operate on DLCI 1023, so the two cannot be implemented on the same network.
CLLM reports congestion in more detail than LMI, noting both the congestion's cause and its expected duration along with a list of DLCIs that should reduce traffic. To date, few Frame Relay vendors have implemented CLLM. The optional Status Update feature of LMI performs a similar function, and its implementation in the richer set of LMI functions makes LMI seem more attractive.

Frame Relay Standards

Alongside a very active community of implementers, several standards bodies have defined specifications for aspects of Frame Relay communications.

In North America, Committee T1S1 of the Exchange Carrier Standards Association has been assigned to draft Frame Relay standard for the American National Standards Institute (ANSI):

The current ANSI standards, T1.606- 1990, T1.617-1991, and T1.618-1991 respectively define Frame Relay service, access signalling for Frame Relay, and the core aspects of the Frame Relay protocol.
The LMI specification, which originated in the "private sector" appears as Annex D of T1.617-1991, which defines a status signalling process that's essentially the same as LMI without the optional extensions. ANSI's LMI-like protocol operates on DLCI 0.
The specification for CLLM appears in the main body of T1.618-1991.

Internationally, the International Telecommunications Union (ITU) has defined a corresponding set of standards:

Recommendation I.233 for the service description, Annex A of recommendation Q.922 for the Frame Relay data transfer protocol.
Recommendation Q.933 for access signalling.

The Frame Relay standards differ from the current practice of Frame Relay communications in one important respect. All the standards assume that the Frame Relay link will carry switched virtual circuits over one channel of an ISDN access interface, while virtually all real-world implementations of Frame Relay are carrying permanent virtual circuits over dedicated access circuits into special packet networks. Thus, the standards are much more complex than their current implementations.

The standards define a set of necessarily elaborate signalling procedures for:

Gaining access to an ISDN channel
Establishing a Frame Relay link on that channel
Establishing and terminating virtual circuits

In practice so far, the one-time process of subscribing to a Frame Relay service replaces all of this signalling. As carriers implement ISDN more widely, the ISDN signalling aspects of the Frame Relay standards will become more important.

back | next | index