WAN protocols

Frame Relay
 Frame Relay became a popular packet switched
WAN service in the 2000s - Cost Effective
 Considered Multi Access – Similar to Ethernet
 Does not support broadcasts
 Frame Relay is Non Broadcast Multi Access
technology (NBMA)
 Requires Virtual Circuits to be established
prior to sending data
 Virtual Circuits are identified by DLCIs
 Frame Relay switches route data on the basis of
DLCI numbers
Introduction to Frame Relay Technology
 Frame Relay
 Frame Relay has at its roots a technology called X.25
 Frame Relay networks allow users to communicate
between two DTE devices through DCE devices –
often represented as a cloud
 Users can’t see a difference
between connecting to and
gathering resources from a local
server or connecting to a remote
server connected with Frame Relay
 Each Router has a single
connection into the Frame Relay
Cloud –using that connection, they
are able to reach every router in the
Frame Relay cloud – is more
economical
 Frame Relay Technology
Everything that must happen in order for two DTE devices to
communicate
 Frame Relay Components
 Access Links Serial connections into a frame relay cloud
having different Access Rates
 Frame relay Switch is the DCE – It is responsible for
providing frame relay services
 Link Management Interface (LMI) protocol: used for
communication between Routers and Frame relay switches
 LMI messages work as keepalives - learn operational status of links
 Frame Relay: Virtual Circuits
 Instead of real circuits used by leased lines, Frame
Relay operates using virtual circuits (logical
circuit)
 These virtual circuits are established between two
DTE devices through the Frame Relay service
Provider’s network
 Virtual circuits act like and deliver the functionality
of a leased line, even though in reality, the routers
are dumping their frames into a large, shared
infrastructure
 You never see the complexity of what is happening
inside the cloud because you have a virtual circuit
 Frame Relay: Virtual Circuits
 There are two types of virtual circuits—permanent
and switched
 Permanent Virtual Circuits (PVCs) more
common type
 Virtual Circuit mappings are preconfigured on the frame
relay network by the telco
 As long as subscribers pay the bill, they will remain in
place
 Switched Virtual Circuits (SVCs) are more like
a phone call – very uncommon for Frame Relay
 The virtual circuit is established when data needs to be
transmitted, then is taken down when data transfer is
complete
 Data Link Connection Identifiers (DLCIs)
 On a single Access Link, there can be multiple VCs running
in parallel, each with their own assigned bandwidth
 Frame Relay PVCs are identified to DTE end devices using
Data Link Connection Identifiers (DLCIs)
 A Frame Relay service provider assigns DLCI values
 used on Frame Relay interfaces to distinguish between different
virtual circuits
 Because many virtual circuits can be terminated on one
multipoint Frame Relay interface, many DLCIs are often
affiliated with it
 Inverse ARP (IARP) is used with DLCIs in a Frame Relay
network- maps a DLCI to an IP address (like ARP does
with MAC addresses to IP addresses)
 Data Link Connection Identifiers (DLCIs)
 When Router A wants to send a frame to Router B, it looks up the IARP
i.e mapping of the DLCI to B’s IP address
 Router A then encapsulates the frame with the DLCI value
corresponding to B’s IP address
 The Frame Relay Switch gets this frame and performs a lookup on the
DLCI/physical-port combination it stores (This is similar to MAC
lookup tables)
 In that table, it finds a new “locally significant” (between it and the
next-hop switch) DLCI to use in the header, and the required outgoing
physical port
 This happens all the way to Router B
 Therefore, it appears that Router A knows the entire virtual circuit to
Router B, even though every DLCI between every pair of devices may have
been completely different
 The point is that Router A is unaware of these differences
 That’s what makes the DLCI locally significant
 DLCI numbers are typically assigned by the provider and start at 16
 Committed Information Rate (CIR)
 With a leased line, you typically specify the bandwidth you
desire (T1, fractional T1, DS3, etc.)
 But with Frame Relay, you specify both an access rate
and a CIR
 Relay Assumption: all customers will never need to transmit
constant data at the same time
 Frame Relay provides a portion of dedicated
bandwidth to each user, but also allows the user to
exceed their guaranteed bandwidth if resources on the
telco network are available
 This allows customers to buy a lower amount of
bandwidth than what they really use
 Committed Information Rate (CIR)
Two separate bandwidth specifications decided at
time of purchase of Frame Relay Services:
 Access rate The maximum speed at which the
Frame Relay interface can transmit
 CIR : Guaranteed bandwidth provided by the
service provider to each virtual connection
on an access link
 If these two values are the same, the Frame Relay

connection is pretty much just like a leased line

 However, they can also be set to different values
 Committed Information Rate (CIR)
Example:
Let’s say that, you buy an access rate of T1
(1.544Mbps) and a CIR of 256Kbps
 By doing this, the first 256Kbps of traffic you
send is guaranteed to be delivered
 Anything beyond that is called a “burst,”
which is a transmission that exceeds your
guaranteed 256Kbps, and can be any
amount up to the T1 access rate (if that
amount is in your contract).
 Local Management Interface (LMI)
 Local Management Interface (LMI) is a signaling standard
used between your router and the first Frame Relay switch
it’s connected to
 It allows for passing information about the operation and
status of the virtual circuit between the provider’s network
and the DTE (your router)
 It communicates information about the following:
 Keepalives These verify that data is flowing
 Multicasting This is an optional extension of the LMI that allows,
for example, the efficient distribution of routing information and
ARP requests over a Frame Relay network
 Multicasting uses the reserved DLCIs from 1019 through 1022
 Local Management Interface (LMI)
 Global addressing This provides global significance
to DLCIs, allowing the Frame Relay cloud to work
exactly like a LAN
 Status of virtual circuits This provides DLCI status
 These status inquiries and status messages are used as
keepalives when there is no regular LMI traffic to send
 LMI is not communication between your routers—it’s
communication between router and the nearest Frame
Relay switch
 It’s entirely possible that the router on one end of a PVC is
actively receiving LMI, while the router on the other end of
the PVC is not
 Local DLCI

DLCI is assigned to
every Virtual
Connection
 Global DLCI

DLCI is assigned to
every Router
Local Management Interface (LMI)
Routers receive LMI information from the service
provider’s Frame Relay switch on a frame
encapsulated interface and update the virtual circuit
status to one of three different states:
 Active state Everything is up, and routers can
exchange information
 Inactive state The router’s interface is up and
working with a connection to the switching office,
but the remote router is not working
 Deleted state No LMI information is being
received on the interface from the switch. It could
be a mapping problem or a line failure
 Frame Relay Congestion Control
 Is there any way for us to find out when our telco’s shared
infrastructure is free and clear and when it’s not?
 And if there is, how do we go about it?

Here are the three congestion bits and their meanings:

1) Discard Eligibility (DE) when you burst (transmit packets
beyond the CIR of a PVC), any packets exceeding the CIR are
eligible to be discarded if the provider’s network is congested
 Because of this, the excessive bits are marked with a
Discard Eligibility (DE) bit in the Frame Relay header
 If the provider’s network is congested, the Frame Relay
switch will discard the packets with the first DE bit set
 So if your bandwidth is configured with a CIR of zero, the
DE will always be on
 Frame Relay Congestion Control
2) Forward Explicit Congestion Notification (FECN)
When the Frame Relay network recognizes congestion in the
cloud, the switch will set the Forward Explicit Congestion
Notification (FECN) bit to 1 in a Frame Relay packet header
 This will indicate to the destination DTE that the path the

frame just traversed is congested

3) Backward Explicit Congestion Notification (BECN)
When the switch detects congestion in the Frame Relay
network, it’ll set the (BECN) bit in a Frame Relay frame that’s
destined for the source router
 This notifies the source router that its packets are facing
congestion in the frame relay cloud ahead
BECN/FECN indicate direction of congestion