• Search •
• References •
• Support •

Simply Speaking
FRF.11 & FRF.12
Implementation Agreements
Overview

Article Number: A014
Article Type: Application
Modified: August 31, 1999

SUMMARY

The Frame Relay Forum plays an important role in the promotion of Frame Relay as a key WAN technology and its use in a variety of network applications. Its members come from every part of the networking industry and include product vendors, major carriers, network consultants and end users too. Develcon has been a participating member of the Frame Relay Forum for several years.

Its web site includes a complete set of resources relating to the use, education, specification and marketing of Frame Relay. Of particular interest to this topic is the listing of Implementation Agreements that serve as a vehicle to standardize the implementation of application support over a frame relay infrastructure. They do not represent a "standard" per se, but rather should be considered a recommendation set forth by the forum to be adopted by equipment designers alike.

This article will focus on two such Implementation Agreements--FRF.11 & FRF.12. Each of these IAs is strategic in the success of the integration of Voice over a Frame Relay network.

MORE INFORMATION

The following material provides a summary of these two key IAs.

FRF.11 - Voice over Frame Relay Implementation Agreement

This agreement specifies how to transport voice application data over a Frame Relay network. Its focus is to extend the application support of frame relay to include the transport of digital voice payloads, with specific emphasis on the unique needs of voice.

It addresses the following set of requirements:

• Transport of compressed voice within the payload of a frame relay frame
• Support a diverse set of voice compression algorithms
• Effective utilization of low bit-rate frame relay connections
• Multiplexing of up to 255 sub-channels on a single frame relay DLCI
• Support of multiple voice payloads on the same or different sub-channel within a single frame
• Support of data sub-channels on a multiplexed frame relay DLCI

The transport of compressed voice is provided with generalized frame formats, the definition of sub-channels, and the multiplexing of these sub-channels into a single DLCI. These three specific concepts will be the focus of the remainder of this section. Please keep in mind that this is not a definitive list, so for information on other relavent topics within this IA, the IA should be consulted directly.

Sub-channels

Each Frame Relay PVC (DLCI) represents one logical stream or traffic flow, and it will generally interconnect two logical points in a network to exchange information. The concept of a sub-channel extends this ability allowing the formation of multiple streams within a single PVC. With sub-channels, any given PVC may support up to 255 sub-channels or streams creating up to 255 logical traffic lanes within the connection between two network points.

The content, also called the payload, of an individual PVC is transparent to a Frame Relay network so the implementation of sub-channels remains compatible with existing Frame Relay services. As such, it becomes solely the responsibility of the end-devices to handle and manage the use of sub-channels within the PVC content.

Payloads

Fundamental to the transport of data and voice over sub-channels is the definition of the various payloads. There are two basic types of payloads consisting of "Primary" and "Signalled" payloads. Without going into too many unnecessary details, the Primary payloads include Encoded Voice, Encoded FAX or Voice-band Modem data, and Data frames, while the Signalled payloads include Channel Associated Signalling (CAS), dialed digits, inband encoded FAX relay, and fault indications.

Each payload entity is called a sub-frame, which consists of a variable length header and the payload itself. Included in the header is the voice/data channel identification (CID) with extension and length indications.

Sub-channel Multiplexing

This may already be clear, but the ability to share a single PVC for the purpose of carrying multiple data flows through a Frame Relay network has a universal benefit, and is not just limited to carrying voice. By placing multiple sub-frame payloads into a single DLCI frame, the end devices may now save on network charges normally incurred with multiple individual PVCs. This helps to increase processing and transport efficiencies.

Summary

This is truly only a skin-deep level view of FRF.11. The actual Implementation Agreement is more detailed covering the signaling procedures, packet encoding, and compliance information necessary to provide a Voice over Frame Relay service.

Suffice it to say that this IA paved the way for the adoption of Voice over Frame Relay as a viable alternative to traditional wide-area telephony services.

FRF.12 - Frame Relay Fragmentation

FRF.12 is an Implementation Agreement defined to help support voice and other real-time (delay-sensitive) data on lower-speed links. It accommodates the variation of frame sizes in a manner that allows the mixture of real-time and non-real-time data.

Base Requirements

The Frame Relay Forum has defined the following set of requirements to be addressed by FRF.12. They are:

• Allow real-time and non-real-time data to share the same Frame Relay link
• Allow the fragmentation of frames of all formats
• Defines a fragmentation procedure that can be used by other protocols or IAs, such as FRF.11
• Defines three fragmentation models, and all models share the same common fragmentation procedures.

FRF.12 helps to address the impact of delay through a network by way of fragmentation. (Fragmentation, in this context, is the act of splitting a large data frame into smaller pieces.) It provides a transmitting Frame Relay device with the ability to fragment long frames into a sequence of shorter frames that can then be reassembled into the original frame by the receiving device. Each of the smaller pieces may then be transmitted separately through the network allowing better control over delay and delay variation.

Fragmentation also allows the end-station to interleave delay-sensitive traffic from one stream with fragments of a longer frame in another stream onto the same physical link thus improving the delay experienced by each circuit. For a brief discussion of delay, please refer to the next section.

Switched Performance Improvements

Fragmentation can benefit the performance of a switched architecture by reducing the impact of serialization delay. By reducing the size of frames through fragmentation, an intermediate node will be able to propogate individual fragments before receiving the final fragment. Without fragmentation, an intermediate node would have to wait to receive the entire long frame at an interface before it could switch the frame out another port.

Summary

When you mix data types, fragmentation can be employed to help control the delay imposed by one data type to accommodate the delay tolerance of another. It can improve and reduce serialization delays experienced on multi-hop networks, and it will improve predictability of the network. FRF.12 solves a very key practical network problem.

A brief discussion of delay

There is often nothing more frustrating than experiencing long delays through a telephone network and trying to carry on a normal conversation with a remote party. Long delays are common on satellite-based transmission facilities, and are often experienced on over-seas long-distance telephone calls. We've all experienced this and the annoying impact it can have on human conversation.

The leap to relate this type of delay to the delay experienced over a data network is not great. In fact, transmission facilities of any type will impart a delay. However, the delay characteristics of a data network are most often variable and may not be completely predictable.

It is easy to understand delay caused by serialization--the conversion of data to a serial bit-stream--and how the induced delay will be dependent upon the rate of the serial link--the higher the speed, the lower the serialization delay. But there are other causes for delay having equal impact on the performance of a network. They can include network congestion, processing latency, the physical length of transmission facilities, the number of "hops" or switching nodes in the path, among many others. Some of these can't be avoided, while others can be accommodated and reduced.

Delay Sensitivity

It is important to understand that certain types of data are more delay sensitive than others. Some forms of data can accept long delays, and some can't afford to have any delay in transmission.

Voice is an example of a stream which can ill-afford excessive delay between the transmitting end-points. Long delays will cause "satellite-like" performance, and this, as we have experienced, is not ideal.

Data like electronic mail (E-mail) is delay insensitive and can accommodate long delays between end-points without any degradation in the application. Of course we all like our E-mail to arrive without too much delay, but we are not overly concerned if it takes a little longer than normal.

REFERENCES

For further information on the Implementation Agreements, please refer to the Frame Relay Forum's website. If you would like further information on the use of FRF.11 and FRF.12 in the Athena and Athena Access product family, please consult their respective Operations Guide.§

Copyright © 1999 Develcon Electronics Ltd.  All Rights Reserved.