Frame relay is based on a packet-switched data network. The
differential of frame relay to previous packet-switched networks
like X.25 is that frame relay switches a frame versus a packet.
Frame relay has considerable low overhead and its speed through the
network is in part to not insuring delivery of data. Frame relay as
a WAN network solution grew due to the low cost for acceptable
performance as compared to leased-line WAN solutions. An optimal
frame relay network design is based on the following:
- Balancing the cost savings of using a public network with the
business performance requirements.
- A scalable WAN design founded in a manageable environment.
- Utilizes a hierarchical design.
Main concerns for implementing a frame relay design is the
ability of the design to scale to not only topology growth but to
traffic growth. Components for creating a scalable frame relay
network designs are:
- The adherence to the three-layer router model of core,
distribution and access layers.
- Overall hierarchical design
- Implementing various mesh topology design
- Addressing protocol broadcast issues
- Addressing performance concerns
Meeting these guidelines results in providing a scalable,
high-availability and low cost frame relay network design.
- Hierarchical Design of Frame Relay Internetworks
Frame relay design is based on permanent virtual connections
(PVCs). A PVC is identified using a Data Connection Link
Identifier (DLCI) number. Multiple PVCs are possible over a
single physical communication link. Using this ability, a single
link can communicate with multiple locations. This function is
shown in Figure 5.1 where router R1 using two PVCs communicates
with two other routers over the public frame relay network. A
PVC can be assigned a bandwidth. The total bandwidth of all
defined PVCs can equal the actual bandwidth of the physical
communication link. In a sense, frame relay acts as a
time-division multiplexer (TDM) over a public network.
Due to the nature of frame relay services through PVCs,
hierarchical designs are more logical than physical in
definition. Each PVC may be guaranteed a bandwidth parameters
called committed information rate (CIR) and excessive burst
limits (Be). The CIR is an agreement with the frame
relay provider for a minimum throughput for the PVC. The
excessive burst limit is an agreement with the frame relay
provider for the available for use by the PVC over and above the
PVC bandwidth to the maximum available on the physical link.
These two variables greatly influence the cost and therefore the
design of the frame relay network.
Scalability is achieved in frame relay network design
through the implementation of a hierarchy. Using a hierarchy
enables incremental growth. The hierarchical approach however,
must follow the three layer routing model in order for meeting
high-availability, acceptable performance and low-cost
requirements. These requirements can be met through careful
planning of actual performance requirements at remote
locations, degree of high-availability service, and minimizing
the complexity of the hierarchy.
Managing a hierarchical network is minimized through the
partitioning of the network into smaller elements. By
simplifying the network into manageable modules,
troubleshooting is eased. The partitioning also provides
protection against broadcast storms and routing loops. A
hierarchical design inherently provides a flexible network
topology allowing the inclusion of other technologies into the
network design. This leads to a hybrid approach for the
overall network infrastructure. While hybrid network design
may enable greater service, it does make network management a
bit more complex. Finally, router management in hierarchical
frame relay networks is reduced due to fewer network
connections based on the hierarchy.
Hierarchical network design lends itself to protecting
networks form broadcast and multicast traffic issues. Regional
hierarchy with smaller areas enables the frame relay network to
maintain overall network performance requirements. Limiting the
number of routers within an area or layer minimizes the chances
of traffic bottlenecks due to broadcast traffic.
- Frame Relay Network Topology
The network topology design chosen for implementing frame relay
networks is dependent on many variables. Among these are the types
of protocols supported and the actual traffic characteristics and
patterns generated by applications using the network. It is
recommended that an optimal frame relay network design support
anywhere form a maximum of 10 to 50 PVCs per physical interface.
Consider the following factors in determining the number of PVCs to
- Broadcast intensive protocols constrain the number of PVCs.
Segregating the protocols into their own PVC for better management
requires more PVCs in multiprotocol networks.
- Broadcast updates due to routing protocols may consume
bandwidth. The number, type and frequency of the routing protocol
updates will dictate the number of PVCs required to meet service
- The available bandwidth of the physical frame relay connection
as measured against the amount of broadcast traffic may dictate
higher-bandwidth PVCs with higher CIRs and excess burst limits.
However, because each PVC has more bandwidth the number of PVCs is
- Static routes can either eliminate or reduce the amount of
broadcasts thereby enabling more PVCs per physical connection.
- Large networks tend to create large routing protocol updates.
Large updates and frequencies require higher bandwidth thereby
reducing the number of available PVCs per physical link.
The topology of a frame relay network is comprised of different
design formats. Each format has its advantageous and
disadvantageous. The network requirements along with the
considerations outlined above on the number of PVCs required in a
design need to be addressed in using the various topology
A frame relay star topology is depicted in Figure 5.2. The
configuration is referred to as a star due to the single
connection by all remote sites to a central location. Star
topologies minimize the number of PVCs and result in a low
cost design. However, due to its design bandwidth at the
central site becomes an issue since it becomes limited due to
the number of remote locations connecting over the physical
connection. Likewise, high-availability through alternate
paths and rerouting of data from the remote locations is
non-existent since there is only one path from the remote
location to the rest of the network. An advantage to a star
topology is ease of management. However, the disadvantageous
of the core or hub router as a single point of failure,
performance impact to the backbone due to the single core
router connection, and the inability of a star topology to
scale make it a poor choice for basing a foundation for the
- Fully Meshed
A fully meshed frame relay network provides a very high degree of
availability. As shown in Figure 5.4 a fully meshed network uses
PVCs connecting all frame relay points on the network.
Disadvantageous to using a fully meshed network is the number of
PVCs required. A PVC is required for logically connecting to each
router on the network. A fully meshed topology requires [n(n-1)]/2
PVCs where n is the number of routers being connected to the frame
relay network. For example, a fully meshed network of five routers
requires [5(5-1)]/2 which equals 10 PVCs.
Although frame relay networks are non-broadcast multiaccess
(NBMA) networks a router sends a broadcast over each active PVC.
This replication process leads to excessive CPU and bandwidth
requirements for jut routing updates, spanning tree updates and SAP
In small frame relay networks, a fully meshed topology is a
reasonable design. The issues that make a fully meshed network for
large networks a poor design are:
- A large number of PVCs
- CPU and bandwidth overhead due to packet and broadcast
- Management complexity
- Partially Meshed
Merging the ease of design and management using a star topology
with the high availability feature provided by a fully meshed
topology results in a requirements balanced partially meshed
topology. Seen in Figure 5.5 a partially meshed topology is two star
topologies being supported by the remote locations. Partially meshed
topologies are ideal for regional implementation. The advantageous
to partially meshed networks are:
- Relatively low-cost as compared to fully meshed
- Minimum number of PVCs required
- Acceptable performance at a reasonable cost
Data must flow through one of the core routers for communication
between locations of a partially meshed topology without a direct
- Fully Meshed Hierarchical
Applying the fully meshed topology to an overall hierarchy
for the three layers of the routing layer model results in a
design that scales and localizes traffic due to the creation
of manageable segments. The modularity of the design enables
the network as a whole to scale well. As shown in Figure 5.6
the hierarchy is based on the strategic connections made
across the routing layer model.
Though again this topology provides high redundancy and
modularity, it continues to have the packet/broadcast
replication problem. The balance of service to cost is also
lost due to the extra number of routers, physical links and
- Hybrid Meshed Hierarchical
Managing the balance between core backbone performance and
maintaining a low-cost network design results in a hybrid
hierarchical frame relay network. A hybrid hierarchical network, as
depicted in Figure 5.7, uses private leased lines for creating a
fully meshed backbone and partially or fully meshed frame relay
networks for connection to the regional network.
In Figure 5.7, we see the use of an ATM core backbone feeding a
leased line distribution network. The distribution layer then
provides network connectivity using a partially meshed topology.
This topology high-availability, great bandwidth for the backbone,
network segmentation and simplified router configuration
- Broadcast Traffic Issues
Broadcasts are typically used for routing protocols to update
network devices on selecting the best path between two
destination on the network. Many routing protocols update their
neighbors or peers on a periodic basis. Routers replicate a
broadcast on to every active PVC defined on the router for
transmission to he partner node at the other end of the PVC.
Figure 5.8 illustrates this point.
In managing the broadcasts of routing protocols, it is
important to understand the time requirement for topology
changes. In stable networks, the timers that manage the
broadcast updates for individual routing protocols may be
extended which helps router and bandwidth overhead in supporting
the routing protocol updates. Another alternative is to include
in the design efficient routing protocols such as EIGRP, for
reducing the routing protocol broadcast updates over the frame
relay network. Managing the replication of broadcasts and
packets is of paramount concern. Fully meshed networks actually
increase the overall cost of a network and increase the overall
load on the network. Table 5.1 lists the relative traffic levels
as they relate to broadcast traffic generated by routing
Relative Broadcast Traffic Level
Routing Table Maintenance Protocol (RTMP)
Interior Gateway Routing Protocol (EIGRP)
Novell Internetwork Packet Exchange (IPX)
Routing Information Protocol (RIP)
Advertisement Protocol (SAP)
Enhanced Interior Gateway
Routing Protocol (EIGRP)
Internet Protocol (IP)
Routing Information Protocol (RIP)
Open Shortest Path First
Intermediate System-Intermediate System
Enhanced Interior Gateway Protocol
Border Gateway Protocol (BGP)
Gateway Protocol (EGP)
DECnet Phase IV
DECnet Phase V
International Organization for Standardization (ISO)
Connectionless Network Service (CLNS)
Xerox Network Systems (XNS)
Banyan Virtual Integrated Network Service
Routing Table Protocol (RTP)
- Performance Considerations
There are several factors affecting performance of frame relay
networks. We have already discussed the affect of broadcasts on the
network. Broadcasts are the primary concern for designing the
bandwidth and number of PVCs necessary to designing a viable frame
relay network. During the planning stage of developing the frame
relay network design the following must be considered:
- Maximum rate requirements
- Committed Information Rate
- Management of multiprotocol traffic
- Determining Maximum rate
The frame relay provider uses several metrics to determine
the billing of the frame relay connections. Therefore, it is
important to fully understand the bandwidth and number of PVCs
required to meet business service levels. The metrics used for
determining the frame relay network configuration are:
Committed burst (Bc) - the number of bits committed to
accept and transmit at the CIR
Excess burst (Be) - the number of bits to attempt to
transmit after reaching the Bc value
Committed Information Rate (CIR) - the maximum permitted
traffic level for each PVC
Maximum data rate (MaxR) - calculated value measured in
bits per second (Bc + Be)/Bc * CIR
Determination of the CIR, Bc and Be is predicated on the
actual speed of the physical line. The maximum values can not
extend past the maximum speed of the link. In addition, the
application profiles will influence the metrics based on the
type of service, transport mechanisms and usage of each
application using the PVCs.
- Committed Information Rate (CIR)
The CIR is the guaranteed bandwidth the frame relay service
provides for each PVC on the physical link. For example, a CIR
of 19.2 Kbps on a 128 Kbps physical link commits the frame
relay network to provide 19.2 Kbps throughput for the PVC
between source and destination. CIR is the metric most
influencing the ability to meet the service levels for the
applications. Failure to properly calculate the appropriate
CIR level results in poor performance and failure to meet
Under estimating the CIR results in discard eligible (DE)
frames. The DE bit value is set to on by a frame relay switch
when the bandwidth used on the PVC begins to exceed the CIR.
Frame relay switches inspect the DE bit value within the
frame. If the DE bit is on, the frame may be discarded based
on the switches resource constraints, network congestion and
- FECN/BECN Congestion Protocol
Frame relay institutes a congestion protocol to protect
network resources from over utilization. This protocol is
termed FECN/BECN. Forward Explicit Congestion Notification
(FECN) is a frame relay message used to notify a receiving
device that there is a congestion problem. Backward Explicit
Congestion Notification (BECN) is a frame relay message used
to notify a sending device that there is a congestion problem.
These messages enable the network devices to throttle the
traffic onto the network. Cisco routers support the use of
FECN and BECN.
- Virtual subinterface and Multiprotocol
Support for multiple protocols over frame relay connections
requires some thought on traffic management. Cisco IOS enables the
use of subinterfaces on physical interfaces. This ability,
diagrammed in Figure 5.9, to create virtual interfaces enables a
network designer to use all the tuning, reporting and management
functions of the Cisco IOS interface commands for each individual
PVC. Using this feature of virtual interfaces also creates unique
buffers on the output queues for each PVC versus n output buffer
queue for the entire physical connection. The result is better
performance and management using virtual subinterfaces.
- SNA Support
Cisco IOS supports the transport of IBM Systems Network
Architecture (SNA) protocols over frame relay using the RFC
1490/FRF.3 specification. The specification describes the
encapsulation technique for transporting the SNA protocols.
Cisco has applied their own algorithms for supporting enhanced
features such as local acknowledgement, dynamic rerouting, SNA
prioritization and PVC prioritization.
- Boundary Network Node (BNN)
Cisco routers implementing RFC 1490/FRF.3 can connect LAN
attached or SDLC attached SNA resources directly to the an IBM
front end processor without the use of a data center based
router or any other intermediate frame relay device. The IBM
front-end processor must be using Network Control Program
(NCP) V7.1 or higher Boundary Network Node (BNN) functions.
Using a Cisco router at the remote location enables these SNA
devices to maintain their current configuration while
realizing the design benefits of a frame relay network. Figure
5.10 illustrates an SNA BNN connection to a mainframe
front-end processor using Cisco routers at the remote
Locations having multiple SNA physical units (PUs)
requiring connectivity may use a single PVC. This is
accomplished by implementing a Service Access Point (SAP)
multiplexing feature. Each SNA PU is assigned a unique SAP
address, which enables the Cisco router to support multiple
SNA PUs over the single PVC.
- Boundary Access Node (BAN)
RFC1490/FRF.3 enhances frame relay connectivity directly to the
FEP by including the IEEE 802.5 MAC header in every frame. This
specification is called Boundary Access Node (BAN). Using BAN an
unlimited number of SNA, devices are supported over a single frame
relay PVC. BAN eliminates the need to use SAP addresses for
multiplexing the SNA connections over a single frame relay PVC.
Additionally, BAN supports duplicate DLCI-MAC address mappings on
the front-end processors for load balancing and redundancy. Support
for BAN on the IBM front-end processor requires NCP V7.3 or higher
and the Cisco IOS must be using IOS 11.1 or greater. Figure 5.11
illustrates the use of BAN connectivity.
The differences between BNN and BAN are:
- BAN does not greatly benefit reduced router configuration over
BNN for single SNA PU connectivity
- For LAN attached SNA PUs, BNN requires a router configuration
change as opposed to the dynamic use of MAC addresses employed by
- BNN is more efficient for SDLC attached devices than BAN. At
locations that have both SDLC attached and LAN attached SNA PUs a
combination of BNN and BAN is beneficial.
- BAN may require an NCP upgrade to V7.3.
- Only BAN supports load balancing and dynamic
- FRAS Host support
Cisco IOS supports the RFC 1490/FRF.3 node function at the data
center router using the Frame relay access support (FRAS) host
function. As shown in Figure 5.12, instead of the frame relay PVC
terminating at an IBM front end processor a Cisco router is used.
The Cisco IOS SNA connectivity features for connecting to the
mainframe using either SDLC, LAN or channel-attachment with a
Channel interface processor (CIP) or channel port adapter (CPA) are
then employed for completing the SNA connection.