The Cisco Frame Relay implementation currently supports routing on IP, DECnet, AppleTalk, XNS, Novell IPX, CLNS, Banyan VINES,
and transparent bridging.
Although Frame Relay access was originally restricted to leased lines, dialup access is now supported. For more information,
for dialer profiles or for legacy dial-on-demand routing (DDR) see the see the module Dial-on-Demand Routing Configuration.
To install software on a new router or access server by downloading software from a central server over an interface that
supports Frame Relay, see the module Loading and Maintaining System Images.
To configure access between Systems Network Architecture (SNA) devices over a Frame Relay network, see the module Configuring
SNA Frame Relay Access Support.
The Frame Relay software provides the following capabilities:
-
Support for the three generally implemented specifications of Frame Relay Local Management Interfaces (LMIs):
- The Frame Relay Interface joint specification produced by Northern Telecom, Digital Equipment Corporation, StrataCom, and
Cisco Systems
- The ANSI-adopted Frame Relay signal specification, T1.617 Annex D
- The ITU-T-adopted Frame Relay signal specification, Q.933 Annex A
-
Conformity to ITU-T I-series (ISDN) recommendation as I122, "Framework for Additional Packet Mode Bearer Services":
- The ANSI-adopted Frame Relay encapsulation specification, T1.618
- The ITU-T-adopted Frame Relay encapsulation specification, Q.922 Annex A
-
Conformity to Internet Engineering Task Force (IETF) encapsulation in accordance with RFC 2427, except bridging.
-
Support for a keepalive mechanism, a multicast group, and a status message, as follows:
- The keepalive mechanism provides an exchange of information between the network server and the switch to verify that data
is flowing.
- The multicast mechanism provides the network server with a local data-link connection identifier (DLCI) and a multicast DLCI.
This feature is specific to our implementation of the Frame Relay joint specification.
- The status mechanism provides an ongoing status report on the DLCIs known by the switch.
-
Support for both PVCs and SVCs in the same sites and routers.
SVCs allow access through a Frame Relay network by setting up a path to the destination endpoints only when the need arises
and tearing down the path when it is no longer needed.
-
Support for Frame Relay Traffic Shaping beginning with Cisco IOS Release 11.2. Traffic shaping provides the following:
- Rate enforcement for individual circuits--The peak rate for outbound traffic can be set to the committed information rate
(CIR) or some other user-configurable rate.
- Dynamic traffic throttling on a per-virtual-circuit basis--When backward explicit congestion notification (BECN) packets
indicate congestion on the network, the outbound traffic rate is automatically stepped down; when congestion eases, the outbound
traffic rate is stepped up again.
- Enhanced queueing support on a per-virtual circuit basis--Custom queueing, priority queueing, and weighted fair queueing
can be configured for individual virtual circuits.
-
Transmission of congestion information from Frame Relay to DECnet Phase IV and CLNS. This mechanism promotes forward explicit
congestion notification (FECN) bits from the Frame Relay layer to upper-layer protocols after checking for the FECN bit on
the incoming DLCI. Use this Frame Relay congestion information to adjust the sending rates of end hosts. FECN-bit promotion
is enabled by default on any interface using Frame Relay encapsulation. No configuration is required.
-
Support for Frame Relay Inverse ARP as described in RFC 1293 for the AppleTalk, Banyan VINES, DECnet, IP, and IPX protocols,
and for native hello packets for DECnet, CLNP, and Banyan VINES. It allows a router running Frame Relay to discover the protocol
address of a device associated with the virtual circuit.
-
Support for Frame Relay switching, whereby packets are switched based on the DLCI--a Frame Relay equivalent of a Media Access
Control (MAC)-level address. Routers are configured as a hybrid DTE switch or pure Frame Relay DCE access node in the Frame
Relay network.
Frame Relay switching is used when all traffic arriving on one DLCI can be sent out on another DLCI to the same next-hop
address. In such cases, the Cisco IOS software need not examine the frames individually to discover the destination address,
and, as a result, the processing load on the router decreases.
The Cisco implementation of Frame Relay switching provides the following functionality:
-
- Switching over an IP tunnel
- Switching over Network-to-Network Interfaces (NNI) to other Frame Relay switches
- Local serial-to-serial switching
- Switching over ISDN B channels
- Traffic shaping on switched PVCs
- Congestion management on switched PVCs
- Traffic policing on User-Network Interface (UNI) DCE
- FRF.12 fragmentation on switched PVCs
-
Support for
subinterfaces associated with a physical interface. The software groups one or more PVCs under separate subinterfaces, which in turn are
located under a single physical interface. See the Configuring Frame Relay module.
-
Support for fast-path transparent bridging, as described in RFC 1490, for Frame Relay encapsulated serial and High-Speed
Serial Interfaces (HSSIs) on all platforms.
-
Support of the Frame Relay DTE MIB specified in RFC 1315. However, the error table is not implemented. To use the Frame Relay
MIB, refer to your MIB publications.
-
Support for Frame Relay fragmentation. Cisco has developed the following three types of Frame Relay fragmentation:
- End-to-End FRF.12 Fragmentation
FRF.12 fragmentation is defined by the FRF.12 Implementation Agreement. This standard was developed to allow long data frames
to be fragmented into smaller pieces (fragments) and interleaved with real-time frames. End-to-end FRF.12 fragmentation is
recommended for use on PVCs that share links with other PVCs that are transporting voice and on PVCs transporting Voice over
IP (VoIP).
-
- Frame Relay Fragmentation Using FRF.11 Annex C
When VoFR (FRF.11) and fragmentation are both configured on a PVC, the Frame Relay fragments are sent in the FRF.11 Annex
C format. This fragmentation is used when FRF.11 voice traffic is sent on the PVC, and it uses the FRF.11 Annex C format for
data.
See the module Configuring Voice over Frame Relay in the
Cisco IOS Voice, Video, and Fax Configuration Guide for configuration tasks and examples for Frame Relay fragmentation using FRF.11 Annex C.
-
- Cisco Proprietary Fragmentation
Cisco proprietary fragmentation is used on data packets on a PVC that is also used for voice traffic.
See the module Configuring Voice over Frame Relay in the
Cisco IOS Voice, Video, and Fax Configuration Guide for configuration tasks and examples for Cisco proprietary fragmentation.