Вы находитесь на странице: 1из 14

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 (http://www.frforum.com/) 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 digitrelay 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 (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.

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 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 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.

Вам также может понравиться