Frame Relay Virtual Circuit Parameters

Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Network Consultants Handbook – Frame Relay
by Matthew Castelli

Network Consultants Handbook -- Click here to go to publisher's site

Frame Relay Virtual Circuit (VC) Parameters
Frame Relay VCs, both permanent (PVC) and switched (SVC), have three configurable parameters that must be agreed upon between each end node (origination and termination) and the Frame Relay network service provider.

These parameters are as follows:

  • CIR
  • DE
  • VC identifiers
    • DLCIs for PVCs
    • X.121/E.164 addresses for SVCs

Frame Relay CIR
The CIR is the amount of bandwidth that will be delivered as “best-effort” across the Frame Relay backbone network. Network providers typically have provisions in their tariffs guaranteeing delivery of CIR traffic at some percentage. For example, a tariff might state a guarantee such as guaranteeing delivery of 99.9% CIR marked traffic.

CIR is measured in bytes over a periodic interval of time, expressed as TC. BC is the committed burst rate across the VC for that period of time. Bc can be represented by the formula Bc = CIR 4 Tc.

Bc is the negotiated maximum amount of bits that a Frame Relay internetwork is committed to accept and transmit at the CIR. Excess of CIR is measured as Be.
BE is the number of bits that a Frame Relay internetwork will attempt to transfer after Bc is accommodated and is marked as DE.

TC is the periodic interval of time over which BC and BE are measured. The TC interval counter starts when data begins to enter into the Frame Relay network, and ends when data is no longer entering the network. When a new data stream enters the network, the TC counter starts over.

Frame Relay PVCs are simplex connections. Each VC is configured with its own CIR, meaning an A -> B PVC could be configured for 64 kbps CIR, and a B -> A PVC could be configured with a 32 kbps CIR. It is up to the network designer/engineer to determine the proper amount of CIR required, generally based on user and application traffic.

Frame Relay Discard Eligibility (DE)
Frame Relay uses a bit in the frame header to indicate whether that frame can be discarded if congestion is encountered during transmission. The DE bit is part of the Frame Relay frame header’s address field.

The DE bit can be set by the transmitting Frame Relay networking device to prioritize the frame because it has a lower priority than other outgoing frames. If the network becomes congested, frames with the DE bit marked will be discarded prior to frames that do not have the DE bit marked to relieve this congestion.

Figure 15-12 illustrates the process that each Frame Relay switch runs upon receipt of a frame for transmission.

Figure 15-12: Frame Relay Data Frame Transmission Flowchart
Click image for larger view in a new window
(Click image for larger view in a new window)

DE requires that the Frame Relay network interpret, and in some cases act on, the DE bit. Some networks take no action when the DE bit is set, and other networks will use the DE bit to determine which frames to discard. Often the DE bit is used to determine which frames should be dropped first or which frames have lower time sensitivity.

DE lists can be created within the Cisco routing device to identify the characteristics of frames eligible for discarding. DE groups can be specified to identify the DLCI that is affected.

When a DE frame is discarded, it is up to the upper-layer protocols, such as TCP, to determine the loss and effect corrective actions as determined by the protocol’s data correction and retransmission algorithms.

NOTE:   Within the Cisco IOS, the command used to define a DE list specifying the frames that can be dropped when the Frame Relay switch is congested is as follows (this command is entered in global configuration mode):

  frame-relay de-list list-number {protocol protocol |
  interface type number} characteristic

For example, the following command specifies that IP packets larger than 512 bytes (including the 4 byte Frame Relay encapsulation) will have the DE bit set:

  frame-relay de-list 1 protocol ip gt 512

DE lists can be created based on the protocol or the interface, and on characteristics such as fragmentation of the frame, a specific TCP or User Datagram Protocol (UDP) port, an access list number, or a packet size (Layer 3 maximum transmission unit (MTU).
To define a DE group that is specifying the DE list and is DLCI-affected, the following command is used in interface configuration mode:

  frame-relay de-group group-number dlci

For example, the following command specifies that group number 3 will be used for DLCI 170:

  frame-relay de-group 3 170

Although DLCI values can be 10, 16, or 23 bits in length, 10-bit DLCIs have become the de facto standard for Frame Relay WAN implementations.

The 10-bit DLCI values, as recommended by the Frame Relay Forum, are allocated as Table 15-5 indicates.

Table 15-5: Frame Relay Forum 10 Bit DLCI Recommendations

DLCI Value Function
0 FRF — In-channel signaling
1 to 15 Reserved
16 to 1007 Available for VC endpoint assignment
1008 to 1022 Reserved
1023 LMI

The 10-bit DLCI values, as recommended by both the ANSI (T1.618) and the ITU-T (Q.922), are allocated as Table 15-6 indicates.

Table 15-6: ANSI (T1.618) and ITU-T (Q.922) 10-Bit DLCI Recommendations

DLCI Value Function
0 In-channel signaling and management (LMI)
1 to 15 Reserved
16 to 991 Available for VC endpoint assignment
992 to 1007 Frame Relay bearer service Layer 2 management
1008 to 1022 Reserved
1023 Reserved for in-channel layer management

NOTE:   The number of DLCIs configurable per port varies depending on the traffic level. All 1,000 DLCIs can be used. However, 200 to 300 is a common maximum. If the DLCIs are used for broadcast traffic, 30 to 50 is a more realistic number due to CPU overhead in generating broadcasts.

Within the Cisco IOS, the number of PVCs that is configurable per interface is limited to 255; this means that a Frame Relay serial interface is limited to 255 subinterfaces. The 255 subinterface limit is dependent on how they are configured; however, no more than 255 point-to-point subinterfaces with one DLCI each can exist.

You must consider and deal with some practical performance issues on an individual case basis. The higher the CIR on the DLCIs, the more impact that the individual interface’s ability will have on supporting the traffic flow.

A T1 could certainly be expected to handle 24 56 K DLCIs with little problem. However, substantial broadcast traffic could affect the performance. If, for example, 50 56 K DLCIs are configured into a T1 interface, traffic issues, such as congestion and dropped traffic, will arise. This configuration is referred to as oversubscription. For example, consider the following two scenarios:

A network configuration that consists of 24 (DLCIs/PVCs) 4 56 kbps (CIR per PVC) = 1.344 Mbps is well within the T1 bandwidth limitation of 1.344/1.536 Mbps (depending on physical line coding; AMI = 1.344 Mbps, B8ZS = 1.536 Mbps).

This configuration is not oversubscribing the interface because available bandwidth is sufficient to support the traffic requirement: 1.344 Mbps equal to or less than 1.344/1.536 Mbps.

A network configuration of 50 (DLCIs/PVCs) 4 56 kbps (CIR per PVC) = 2.800 Mbps far exceeds the maximum bandwidth supported by a T1 limitation of 1.344/1.536 Mbps (depending on physical line coding; AMI = 1.344 Mbps, B8ZS = 1.536 Mbps).

This configuration is oversubscribing the interface because the bandwidth available is not sufficient to support the traffic requirement: 2.800 Mbps equal to or greater than 1.344/1.536 Mbps.

Our next segment from Cisco Press’ Network Consultants Handbook will cover polling, error handling, and specification enhancements.

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends, and analysis.

Latest Articles

Follow Us On Social Media

Explore More