Академический Документы
Профессиональный Документы
Культура Документы
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
T1.618
Congestion Management
TI.606
I.370
Access Signalling
T1.617
Q.933
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 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!
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.
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.
1 - 15
Reserved
16 - 1007
Any PVC
1008 - 1018
Reserved
1019 - 1022
1023
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
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.
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.
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
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.
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.
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.
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 G - G.727 D/E EADPCM transfer syntax, X.25 over Frame Relay
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.
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
(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.
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.
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.
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.
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.