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.
|Core (Data Transfer Protocol)
||Q.922 Annex A (Enhanced form of LAPD)
Frame Relay consists of:
- Customer Premises Equipment (CPE) which can be a bridge, router and/or a Frame Relay Assembler/Disassembler
- 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.
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:
||Reserved for ANSI Annex D and CCITT Annex A link management
|1 - 15
|16 - 1007
|1008 - 1018
|1019 - 1022
||Reserved for LMI multicast
||Reserved for LMI link management
Additional address bytes allow for DLCI addresses greater than 1024, however these are not common.
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:
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
- 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:
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
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 (Tc) and given by the formula
CIR = Bc/Tc.
The Committed Burst (Bc) is maximum number of bits that a switch is set to transfer over any Tc.
The formula Bc = Tc x CIR demonstrates that the higher the Bc to CIR ratio is
the longer the switch can handle a burst.
The Excess Burst (Be) 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 = Be/Tc. If you do not know Tc, then because Tc =
Bc/CIR, you can substitute Tc into the EIR formula to give EIR = CIR * Be/Bc.
The Peak Rate is CIR + EIR.
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 Bc 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
((Tc). 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
(Bc) 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
Bc / 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 + Be 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
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.
describes INARP in detail.
describes Multiprotocols over Frame Relay.
describes IP over Frame Relay.