Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

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.

The Cisco implementation of the SMDS protocol is based on cell relay technology as defined in the Bellcore Technical advisories, which are based on the IEEE 802.6 standard. We provide an interface to an SMDS network using DS1 or DS3 high-speed transmission facilities. Connection to the network is made through a device called an SDSU--an SMDS digital service unit (DSU). The SDSU attaches to a router or access server through a serial port. On the other side, the SDSU terminates the line.

The implementation of SMDS supports the IP, DECnet, AppleTalk, XNS, Novell IPX, Banyan VINES, and OSI internetworking protocols, and transparent bridging.

The implementation of SMDS also supports SMDS encapsulation over an ATM interface. For more information and for configuration tasks, see Configuring ATM.

Routing of AppleTalk, DECnet, IP, IPX, and ISO CLNS is fully dynamic; that is, the routing tables are determined and updated dynamically. Routing of the other supported protocols requires that you establish a static routing table of SMDS neighbors in a user group. Once this table is set up, all interconnected routers and access servers provide dynamic routing.

Note	When configuring IP routing over SMDS, you may need to make adjustments to accommodate split horizon effects. Refer to the Configuring EIGRP module for information about how Cisco software handles possible split horizon conflicts. By default, split horizon is disabled for SMDS networks.

The SMDS implementation includes multiple logical IP subnetworks support as defined by RFC 1209. This RFC describes routing IP over an SMDS cloud in which each connection is considered a host on one specific private network, and points to cases where traffic must transit from network to network.

The implementation of SMDS also provides the Data Exchange Interface (DXI) Version 3.2 with heartbeat . The heartbeat mechanism periodically generates a heartbeat poll frame.

When a multicast address is not available to a destination, pseudobroadcasting can be enabled to broadcast packets to those destinations using a unicast address.

X.25 is one of a group of specifications published by the ITU-T. These specifications are international standards that are formally called Recommendations . The ITU-T Recommendation X.25 defines how connections between DTE and DCE are maintained for remote terminal access and computer communications. The X.25 specification defines protocols for two layers of the Open Systems Interconnection (OSI) reference model. The data link layer protocol defined is LAPB. The network layer is sometimes called the packet level protocol (PLP), but is commonly (although less correctly) referred to as the X.25 protocol.

The ITU-T updates its Recommendations periodically. The specifications dated 1980 and 1984 are the most common versions currently in use. Additionally, the International Standards Organization (ISO) has published ISO 7776:1986 as an equivalent to the LAPB standard, and ISO 8208:1989 as an equivalent to the ITU-T 1984 Recommendation X.25 packet layer. The Cisco X.25 software follows the ITU-T 1984 Recommendation X.25 , except for its Defense Data Network (DDN) and Blacker Front End (BFE) operation, which follow the ITU-T 1980 Recommendation X.25 .

Note	The ITU-T carries out the functions of the former CCITT. The 1988 X.25 standard was the last published as a CCITT Recommendation . The first ITU-T Recommendation is the 1993 revision.

In addition to providing remote terminal access, The Cisco X.25 software provides transport for LAN protocols--IP, DECnet, XNS, ISO CLNS, AppleTalk, Novell IPX, Banyan VINES, and Apollo Domain--and bridging.

Cisco IOS X.25 software provides the following capabilities:

• LAPB datagram transport--LAPB is a protocol that operates at Level 2 (the data link layer) of the OSI reference model. It offers a reliable connection service for exchanging data (in units called frames ) with one other host. The LAPB connection is configured to carry a single protocol or multiple protocols. Protocol datagrams (IP, DECnet, AppleTalk, and so forth) are carried over a reliable LAPB connection, or datagrams of several of these protocols are encapsulated in a proprietary protocol and carried over a LAPB connection. Cisco also implements transparent bridging over multiprotocol LAPB encapsulations on serial interfaces.

• X.25 datagram transport-- X.25 can establish connections with multiple hosts; these connections are called virtual circuits. Protocol datagrams (IP, DECnet, AppleTalk, and so forth) are encapsulated inside packets on an X.25 virtual circuit. Mappings between the X.25 address of a host and its datagram protocol addresses enable these datagrams to be routed through an X.25 network, thereby permitting an X.25 PDN to transport LAN protocols.

• X.25 switch--X.25 calls can be routed based on their X.25 addresses either between serial interfaces on the same router (local switching) or across an IP network to another route r, using X.25 over TCP (XOT). XOT encapsulates the X.25 packet level inside a TCP connection, allowing X.25 equipment to be connected via a TCP/IP-based network. The Cisco X.25 switching features provide a convenient way to connect X.25 equipment, but do not provide the specialized features and capabilities of an X.25 PDN.

• ISDN D channel--X.25 traffic over the D channel, using up to 9.6 kbps bandwidth, can be used to support many applications. For example, it may be required as a primary interface where low volume sporadic interactive traffic is the normal mode of operation. For information on how to configure X.25 on ISDN, refer to the modules Configuring X.25 on ISDN and Configuring X.25 on ISDN Using AO/DI.

• PAD--User sessions can be carried across an X.25 network using the packet assembler/disassembler (PAD) protocols defined by the ITU-T Recommendations X.3 and X.29.

• QLLC--The Cisco IOS software can use the Qualified Logical Link Control (QLLC) protocol to carry SNA traffic through an X.25 network.

• Connection-Mode Network Service (CMNS)--CMNS is a mechanism that uses OSI-based network service access point (NSAP) addresses to extend local X.25 switching to nonserial media (for example, Ethernet, FDDI, and Token Ring). This implementation provides the X.25 PLP over Logical Link Control, type 2 (LLC2) to allow connections over nonserial interfaces. The Cisco CMNS implementation supports services defined in ISO Standards 8208 (packet level) and 8802-2 (frame level).

• DDN and BFE X.25--The DDN-specified Standard Service is supported. The DDN X.25 Standard Service is the required protocol for use with DDN Packet-Switched Nodes (PSNs). The Defense Communications Agency (DCA) has certified the Cisco DDN X.25 Standard Service implementation for attachment to the DDN. The Cisco DDN implementation also includes Blacker Front End operation.

• X.25 MIB--Subsets of the specifications in SNMP MIB Extension for X.25 LAPB (RFC 1381) and SNMP MIB Extension for the X.25 Packet Layer (RFC 1382) are supported. The LAPB XID Table, X.25 Cleared Circuit Table, and X.25 Call Parameter Table are not implemented. All values are read-only. To use the X.25 MIB, refer to the RFCs.

• Closed User Groups (CUGs)--A CUG is a collection of DTE devices for which the network controls access between two members and between a member and a nonmember. An X.25 network can support up to 10,000 CUGs. CUGs allow various network subscribers (DTE devices) to be segregated into private subnetworks that have limited incoming or outgoing access.

The Cisco X.25 implementation does not support fast switching.

Layer 2 VPN (L2VPN) services are point-to-point. They provide Layer 2 point-to-point connectivity over either an Multiprotocol Label Switching (MPLS) or a pure IP (Layer 2 Tunneling Protocol Version 3) core.

Cisco's WAAS Express software interoperates with WAN optimization headend applications from Cisco. Cisco WAAS Express improves WAN access and use by optimizing applications, such as backup (is backup an application or a mechanism?), that require high bandwidth or are bound to a LAN.

WAAS Express helps enterprises meet the following objectives:

• Complement the Cisco WAN optimization system by adding the capability to branch routers.

• Provide branch office employees with LAN-like access to information and applications across a geographically distributed network.

• Minimize unnecessary WAN bandwidth consumption through the use of advanced compression algorithms.

• Virtualize print and other local services to branch office users.

• Improve application performance over WAN by addressing the following common issues:

  • Low data rates (constrained bandwidth)
  • Slow delivery of frames (high network latency)
  • Higher rates of packet loss (low reliability)

The Network Analysis Module (NAM) Performance Agent (PA) for WAAS Express analyzes and measures network traffic. The PA enables baselining, monitoring, and troubleshooting of application performance. The analysis and measurement of network traffic is done by the Measurement, Aggregation, and Correlation Engine (MACE). MACE performs the required measurements on a subset of traffic and exports the necessary metrics to a target.