Frame Relay

Introduction

Frame Relay is a packet-multiplexed interface in a packet switching environment, the DTE (router) and the DCE (switch) can multiplex various connections over a common medium by way of virtual circuits. Frame Relay is designed for reliable digital and fibre environments so it has little need of the accounting and error checking overheads that come with X.25.

The ITU-T produced the recommendation I.122 which was the framework for packet mode bearer services and described how LAPD could be used for applications other than ISDN Q.921 signalling. The ANSI T1S1 committee also produced a set of standards which matched those produced by the ITU-T.

Description	ANSI	ITU-T
Service	T1.606	I.233.1
Core (Data Transfer Protocol)	T1.618	Q.922 Annex A (Enhanced form of LAPD)
Congestion Management	TI.606	I.370
Access Signalling	T1.617	Q.933

Frame Relay consists of:

Customer Premises Equipment (CPE) which can be a bridge, router and/or a Frame Relay Assembler/Disassembler (FRAD).
An access line such as High Speed Serial Interface (HSSI), V.35, RS-449 or MCT1.
A Frame Relay Switch (DCE).
A Permanent Vitual Circuit (PVC) which is a predefined path between DTEs to which a Data Link Connection Identifier (DLCI) is assigned by the supplier. This number only is significant between the local switch and the CPE and so can be used elsewhere in the network.
More recently Switched Virtual Circuits (SVC) can be set up by the service provider using the standards ANSI T1.617 Annex D, ITU-T Q.933 Annex A and ITU-T Q.922.

Frame Format

This diagram illustrates the 'Two-Byte' frame format:

Frame Relay normally modifies the HDLC header from a 1 byte address field to a 2 byte address field, as seen above. You can have a 3 or 4 byte format as well. In addition, there is no Control field!

Starting Delimiter Flag - 0x7E
High order 6 bits of DLCI address
Command/Response used by higher order applications for end-to-end control
Extended Address bit which indicates whether this octet is the last one in the header. 0 means more to follow and 1 means that this is the end.
Low order 4 bits of DLCI address
Forward Explicit Congestion Notification (FECN) bit
Backward Explicit Congestion Notification (FECN) bit
Discard Eligibility (DE) bit
Extended Address bit. In this case, this is a 1, but there can be more address bits to follow to give 17 bits (3-byte address field) or 24 bits (4-byte address field).
Data - can be up to 16,000 octets, but the 16-bit FCS generally limits the whole frame size to 4096 octets.
Frame Check Sequence (FCS)
Ending Delimiter Flag - 0x7E

Valid 10 bit DLCI addresses are:

0	Reserved for ANSI Annex D and CCITT Annex A link management
1 - 15	Reserved
16 - 1007	Any PVC
1008 - 1018	Reserved
1019 - 1022	Reserved for LMI multicast
1023	Reserved for LMI link management

Additional address bytes allow for DLCI addresses greater than 1024, however these are not common.

Protocol Encapsulation

When encapsulating other protocols the data field of the Frame Relay packet contains a Network Level Protocol Identification (NLPID) which can be 0xCC (IP), 0x80 (Sub-Network Access Protocol - SNAP) or 0x81 (OSI).

When a SNAP header is identified, the 3-byte Organisational Unique Identifier (OUI) and the 2-byte Protocol Identifier (PID) further identifies the protocol. See the following tables:

OUI

0x00-00-00	XNS
0x00-00-00	IPX
0x00-80-C2	Bridging
0x00-80-9B	AppleTalk

PID

0x81-37	IPX
0x00-07	802.3 bridging
0x80-9B	AppleTalk

In addition, Banyan Vines and DECnet are supported.

Frame Relay Forum

The Frame Relay Forum came together in 1991 to promote the use of Frame Relay and to develop common ways of implementing it. The forum is made up of many manufacturers and developers. The Frame Relay Forum implementation agreements are listed below:

FRF.1.1 - User-to-Network (UNI)
FRF.2.1 - Network-to-Network (NNI)
FRF.3.1 - Data Encapsulation
FRF.3.2 - Multiprotocol Encapsulation Implementation (MEI)
FRF.4.1 - UNI Switched Virtual Circuit (SVC)
FRF.5 - Frame Relay/ATM PVC Network Interworking.
FRF.6 - Frame Relay Service Customer Network Management (MIB)
FRF.7 - Frame Relay PVC Multicast Service and Protocol Description
FRF.8 - Frame Relay/ATM Service Interworking
FRF.8.1 - Frame Relay/ATM PVC Service Interworking
FRF.9 - Data Compression over Frame Relay
FRF.10 - Frame Relay Network-to-Network interface SVC
FRF.11 - Voice over Frame Relay. Defines multiplexed data, voice, fax, DTMF digit-relay and CAS/Robbed-bit signaling frame formats. Annex C is Cisco's derivative for fragmentation.
FRF.12 - Frame Relay Fragmentation allows long data frames to be fragmented into smaller frames and interleaved with real-time frames. Real-time voice and non real-time data frames can be carried together on lower speed links without causing delay to the real-time traffic.
FRF.13 - Service Level Definitions
FRF.14 - Physical Layer Interface
FRF.15 - End-to-End Multilink Frame Relay
FRF.16 - Mulltilink Frame Relay UNI/NNI
FRF.17 - Frame Relay Privacy
FRF.18 - Network-to-Network FR/ATM SVC Service Interworking

FRF.5 Frame Relay/ATM PVC Network Interworking

A single PVC can support voice and data from a Frame Relay DTE through to an ATM UNI, however you cannot use FRF.12 if FRF.5 is operating on a PVC. If you require FRF.12 then you need a separate PVC. Implementation of FRF.5 introduces large delays within the internetworking switch which make it less suitable for delay sensitive traffic such as voice.

FRF.8 Frame Relay/ATM Service Interworking

There are two modes for FRF.8:

Translation Mode - this uses RFC 1490 (IP over Frame Relay) on the Frame Relay side and RFC 1483 (multiprotocol encapsulation over ATM) on the ATM side. This works well for data but not voice.
Transparent Mode - the ATM side receives the payload untranslated and works fine for voice but not for data.

FRF.12 Frame Relay Fragmentation

FRF.12 allows the mixing of real-time and non-real-time data (e.g. FRF.3.1) on the same DLCI via the use of fragmentation techniques that can be used by other FRF implementations and protocols. Before FRF.12 came along, the only way of performing fragmentation and interleaving was to reduce the MTU size. The problem with this is that protocols such as IP are reliant upon the fragmentation bit being set. If it is not then the packet is dropped. Relying on endpoints to reassemble datagrams adds to the delay. IP MTU size reduction must be used if the service provider is converting from Frame Relay to ATM. This because there is no FRF.12 partner in the ATM cloud and ATM does not support interleaving cells from different packets.

With FRF.12, when a packet is fragmented, a fragmentation header is inserted that keeps a note of the sequence numbers so that re-assembly can occur at the other end. If packets arrive out of sequence, they are dropped (unlike MLP). Fragmenting large frames allows the end stations to interleave smaller, delay sensitive frames such as encoded voice. This mitigates against delay and jitter (delay variation). When frames are small, the chances of Serialisation Delay is reduced i.e. intermediate devices do not have to wait to receive a large data frame before forwarding it on. The key here is to set a fragment size that is not too small so as to fragment the delay sensitive packets. By doing this, delay sensitive packets will not have a fragmentation header. FRF.12 is ideal for VoIP environments. Below is a table of link speeds and the delay that the link will add depending on the fragment size in bytes:

	10ms	20ms	30ms	40ms	50ms	100ms	200ms
56kbps	70	140	210	280	350	700	1400
64kbps	80	160	240	320	400	800	n/a
128kbps	160	320	480	640	800	n/a	n/a
256kbps	320	640	960	1280	n/a	n/a	n/a
512kbps	640	1280	n/a	n/a	n/a	n/a	n/a
768kbps	1000	n/a	n/a	n/a	n/a	n/a	n/a

There are two versions of FRF.12:

FRF.12 UNI - the Frame Relay network takes part in fragmenting and reassembling the data frames because the fragmentation only occurs across the UNI. Once reaching the Frame Relay network the frames are reassembled and transported to the other end where they are re-fragmented again for transport across the UNI at the other end. The fragmentation header sits in front of the Frame Relay header and is stripped off by the Frame Relay network. A problem with this is that the chance of serialisation delay has been re-introduced within the Frame Relay network.
FRF.12 End-to-End - Fragmentation and re-assembly is handled by the end VFRADs so that the fragmented frames traverse the Frame Relay network as fragments. The fragmentation header sits inside the Frame Relay header and remains unseen by the Frame Relay network.

If you have a number of sites using Frame Relay for transport between them and the topology is a hub and spoke topology, then even if you only have delay sensitive traffic such as VoIP at a couple of the sites you will need to enable FRF.12 on ALL links. This is because you can suffer Egress Blocking (from the perspective of the Service Provider) where large data frames from non-VoIP sites going to the VoIP site can block the smaller VoIP packets that are also going to that site (egressing from the SP to that site).

Even if FRF.12 is applied everywhere, you may still have problems at the hub site because a large number of small data frames could hinder the progress of VoIP frames. This can be resolved with queuing mechanisms being implemented by the SP, perhaps within an MPLS backbone.

Another option is to have separate PVCs for data and delay sensitive traffic such as VoIP. This costs more but it does allow your data to burst ab ove CIR whilst you shape the voice traffic to its own CIR. Be aware that data fragmentation will still be required as you will still be using the same serial interfaces.

FRF.11 Voice Over Frame Relay

FRF.11 introduces the idea of sub-channels (or sub-frames) of which up to 255 can exist within one PVC. When FRF.11 is configured, then the default data encapsulation FRF.3.1 is no longer used. In addition, FRF.11 allows for compressed voice using different algorithms. The Frame Relay network does not see these sub-channels, instead, they are managed by the end devices. These sub-channels allow a user to have separate data streams within one PVC without the need to pay more for extra PVCs.

The sub-frames sit in the data part of the Frame Relay frame and are identified by a separate header.

The 6 least significant bits of the Sub-Channel ID. Sub-channel IDs 0 to 3 are reserved. You can have up to 255 sub-channels on a DLCI.
Length Indicator (LI) shows that the payload length field is present.
Extension Indicator (EI) shows that the payload type and CID MSB fields are present.
Payload Type - shows the contents of the payload which could be voice, fax or digits that have been dialled.
The 2 most significant bits of the sub-channel ID.
Payload Length needed if there is more than one sub-frame in the data.

FRF.11 has a number of annexes which have been alluded to already. These are sometimes known as class 2 services:

Annex A - Dialled digits transfer syntax. DTMF digits do not fare well when encoded by voice-centric codecs so they are dealt with in separate Annex A frames.
Annex B - Signalling bit transfer syntax. There are 30 sets of ABCD signalling bits that take up 60ms of time. If signalling is just using A and B bits then these are duplicated in the 'C' and 'D' positions. If just A is being used, then this is copied in the 'B', 'C' and 'D' positions. Analogue signalling e.g. E&M is converted to ABCD bit signalling for transfer over Frame Relay. If there has not been a signalling change in 0.5s, the packet becomes a keepalive packet that is sent every 5 seconds.
Annex C - Data transfer syntax. If a data packet is fragmented then in the payload the first fragment has the Beginning (B) bit set and the last fragment has the End (E) bit set. Packets that are smaller than the fragmentation threshold have both B and E bits set. With Annex C, only frames with data payloads are fragmented, VoFR frames bypass the fragmentation routines no matter what size the voice frames are.
Annex D - Fax relay transfer syntax.
Annex E - CS-ACELP transfer syntax (e.g. G.729)
Annex F - PCM/ADPCM transfer syntax
Annex G - G.727 D/E EADPCM transfer syntax, X.25 over Frame Relay
Annex H - LDCELP transfer syntax (G.728)
Annex I - G.723.1 MP-MLQ dual-rate speech coder

Primary Payloads are encoded voice, fax, modem and data, whilst Signalling Payloads carried on a sub-channel include CAS, dialled digits, silence information and encoded FAX Relay.

There are two classes of FRF.11 equipment:

Class 1 - high bandwidth transmission equipment that needs to comply with the codec G.727 EADPCM as its Primary payload type. The transmit rate has to be 32kbps and the receive rates supported have to be 32kbps, 24kbps and 16kbps. Class 1 devices do not have to support the dialled digit Signalled payload type, but do have to support CAS and AIS Signalled payload types.
Class 2 - Low bandwidth transmission equipment which needs to comply with the codecs G.729 and G.729a as its Primary payload type. Class 2 devices also have to support CAS and AIS Signalled payload types.

Frame Relay Traffic Flow

The Local Access Rate is the clock speed of the port and is the rate that data traffic travels in and out of the port.

The financial costs for Frame Relay are based on Access Line speeds, Linking up the line and the Committed Information Rate (CIR).

The CIR is based on the expected volume of the traffic and can never exceed the line speed. An example is a customer buying a 9.6K CIR on a 64K access line. The customer will be guaranteed 9.6K speed but could burst up to 64K if the need arises, for which he may be charged or frames may be dropped. A customer could go for a zero CIR which would mean that all traffic would be marked as Discard Eligible (DE), so that in a period of congestion, these frames would more likely be dropped. The CIR is calculated as an average rate over a period of time called the Committed Rate Measurement Interval (T_c) and given by the formula CIR = B_c/T_c.

The Committed Burst (B_c) is maximum number of bits that a switch is set to transfer over any T_c. The formula B_c = T_c x CIR demonstrates that the higher the B_c to CIR ratio is the longer the switch can handle a burst.

The Excess Burst (B_e) is the maximum number of uncommitted bits over and above the CIR, that the switch will try to forward.

The Excessive Information Rate (EIR) is the average rate over which bits will be marked with DE and is given by the formula EIR = B_e/T_c. If you do not know T_c, then because T_c = B_c/CIR, you can substitute T_c into the EIR formula to give EIR = CIR * B_e/B_c.

The Peak Rate is CIR + EIR.

Congestion

The Forward Explicit Congestion Notification (FECN) notifies downstream (destination) nodes of congestion when set to '1'; whereas Backward Explicit Congestion Notification (BECN) notifies upstream (source) nodes of congestion when set to '1'. Statistical Time Division Multiplexing is used to provide a measure of this congestion. Discard Eligibility (DE), when set to '1', indicates non-priority traffic and is therefore eligible for discard in congested periods. Any traffic that goes above B_c is marked as DE.

As an aside, when measuring bandwidth you need to realise that you are measuring packets going into a buffer rather than packets going through a physical link so as a percentage you may sometimes see values over 100%.

In a IP environment TCP is used to provide reliable transport of data. The TCP window size slowly increases in size until a packet is dropped, then the window size rapidly shrinks before slowly growing again dynamically. This is often called Slow Start. In the diagram above, switch A gets congested due to traffic from all users that are supplied by the carrier, not just the client illustrated. It is a good idea to configure the edge router to listen to the FECNs and BECNs before the Frame Relay switches decide to drop packets, some of which may be yours. If your packets are dropped then the IP traffic will go through low Start and this adds to the congestion problem if Slow Start occurs continually.

Random Early Detect (RED) is a facility that picks on individual users at different times and drops their packets so forcing them to go through slow start at different times. This helps to spread out congestion and give control of when packets are dropped back to the client.

Frame Relay Traffic Shaping (FRTS)

Using FECNs, BECNs, the CIR and the DE bit enables the Frame Relay network to make intelligent decisions as to what to do when congestion occurs in the network. Edge devices can set the DE bit when there is congestion so that high precedence traffic does not get dropped, otherwise all traffic within a PVC is treated the same by the FR switch.

You can shape outgoing traffic on a per VC basis and set up queues such that different traffic types can be treated appropriately on the same VC.

As we saw earlier the CIR is the average data sent per Time measurement interval ((T_c). Within that time interval the data rate could exceed the average bit rate provided that the average is maintained over the time interval. The committed burst size (B_c) is the maximum number of bits that is allowed within the time interval. Consider the following scenario where a 128 kbps line has a CIR of 64 kbps. If the committed burst size is 8000 bits then the time measurement interval is given by B_c / CIR i.e. 8000 / 64000 = 0.125s.

This diagram identifies the 125ms time intervals over a period of 1 second. In any one time interval up to 8000 bits can be sent before the CIR is exceeded (indicated as black) and the token bucket is empty. At the beginning of the next time period, the token bucket is full again allowing up to 8000 more bits to be sent. So at the line rate of 128kbps, 8000bits are sent after 62.5ms. The above illustrates that the CIR is being fully utilised over the 1 second period. Sometimes, less than 8000 bits will be sent in one time interval. In this case, the remaining number of bits + B_e can be sent in another time interval. If you fully utilise the time interval i.e. send 8000 in 62.5ms, then you have to wait until the next time interval before you can send any more data. This can amount to a delay of 62.5ms in the worst case, which could be a problem for delay sensitive traffic.

BECNs can be examined by FRTS and on a per VC basis, traffic can be throttled back by temporarily buffering outbound packets.

Link Management Interface (LMI)

Data Link Control Management Interface (DLCMI) software on the router checks for Access Line Integrity, new or deleted DLCIs (PVCs) and status of current DLCIs. There are three types of DLCMIs; ANSI T1 617D, Link Management Interface (LMI) and CCITT Annex A (Q.933a). The DTE and DCE need to be configured with the same one and therefore only needs to be the same locally between the router and the switch.

You can configure a router as a partial Frame Relay switch for testing purposes (hence the options, LMI switch, Annex D switch and Annex A switch), using modem eliminators or X.21/V.35 crossover cables will enable you to simulate a Frame Relay switch on one router connecting to a normally configures router. Also, 'DLCMI none' could be chosen if you wished to statically configure all the PVCs. With Rev 1 LMI the switch (DCE) dynamically sends DLCI information and addressing to the DTE (router) and we do not have to set up the DLCI numbers.

By default the router sends a Full Status Message every 6th poll and the switch responds with a Full Status Response. These polling intervals must be the same on the router as on the switch otherwise a no response to poll could result in the line being brought down. DLCI 1023 is the LMI control DLCI at the switch.

The A bit in the PVC status field of an LMI response is cleared when a particular PVC becomes inactive, the local switch can then inform other switches that this PVC is down.

If you have a Cisco-based Frame Relay network, then you have the capability of utilising Enhanced LMI which is used by routers to request QoS information from Frame Relay switches. This QoS information can then be used for FRTS and ensures that you do not have mismatches in configuration between the router and the switch.

Frame Relay Topologies

In a Fully meshed environment, every router has a PVC defined to every other router and in a Non-fully meshed environment (or Hub and Spoke) PVCs are only defined between routers that need to communicate.

There are three access modes:

Group Access: All PVCs on a particular interface are treated as one network, and each DLCI number can be thought of as a MAC address of a host on a LAN. IP addresses are assigned to the interface and configuration applies to the interface and therefore all PVCs associated with that interface.
Direct Access: Each PVC is an individual network and the DLCI number can be thought of as a MAC address of the host at the other end of the WAN.
Hybrid Access: For PDUs that need to be routed all PVCs are set in Group Access mode whilst for bridged PDUs, each PVC is treated as a separate network.

Address resolution occurs by mapping an IP address to a DLCI number, and there are three options:

ARP: Where the network address is known but the DLCI is not. The ARP packet is sent to all active DLCIs and the network address is mapped to the local DLCI through which the reply was received.
INARP: Inverse ARP is where the IP address of the host at the other end of the PVC is unknown, so an INARP packet is sent to all new DLCIs.
ARPINARP: This is a combination of both ARP and INARP.

In a fully meshed network Poison Reverse, Split Horizon and Actual can be used to configure how route propagation can occur throughout the WAN. In a non-fully meshed environment (Hub and Spoke) there is a requirement for the hub to have its interfaces configured with Actual route propagation since the spokes, although they may be on the same sub-network, will not be able to directly talk to one another. The hub router will maintain a routing table with the spoke IP addresses, however, any LANs sitting behind the spokes will be advertised as unreachable (with Poison Reverse) or not advertised at all (with Split Horizon) since the routes will come in on the same interface that the destination packets, for these LANs, would need to be sent out on. So, the hub router should have its route propagation set to Actual or static routes (with the next hop address set as the hub router's interface) set for each spoke on the particular subnet concerned, or perhaps the best alternative, is to turn RIP supply off on the hub router and enable the RIP interface parameter Generate Default.

There is another problem in a hub to spoke environment. A ping from Spoke 1 to Spoke 2 on the same subnet will fail because Spoke 1 would look into its routing table and see that Spoke 2 is on the same subnet. An ARP is sent from Spoke 1 to Spoke 2 in order to resolve the IP address to a MAC address, however the ARP goes to the Hub which drops it since it is not meant for it, the IP address of Spoke 2 is never resolved and the ping cannot be sent. To sort this out, adjacent hosts must be configured for each spoke within each particular subnet. This creates static ARP table entries since you are assigning a MAC address to the Frame Relay IP address of each spoke, this MAC address will be the local DLCI number.

With Direct Access Mode there are no routing problems since each PVC is treated as a separate network and therefore are simple point to point links, often used to be dedicated to specific protocols. If using RIP, then there is the potential for wasting address space since only two IP addresses will be used and the subnet mask is always fixed within the same network. Obviously this problem does not exist with variable subnet masking such as OSPF or RIP-2.

In Hybrid Access Mode, routing protocols view the interface as if it were configured for Group Access Mode whilst bridging protocols view the interface as if it were configured for Direct Access Mode.

RFC 1293 describes INARP in detail.
RFC 1294 describes Multiprotocols over Frame Relay.
RFC 1490 describes IP over Frame Relay.

Home

Disclaimer