[ LiB ]User-Network Interface Frame Relay Traffic Shaping

Congestion-Control Mechanisms

Congestion is a problem that plagues the WAN environment more than the LAN environment in networking today. With the speed of today's LAN networks (up to 10 Gb on some interfaces), congestion is not as big a problem in the LAN environment as it has been in the past. Congestion usually occurs when you try to shove 10 Gb of information through a 1.5 Mbps T1 Frame Relay.

One reason that congestion still is a problem in today's environment is that the developers of WAN protocols must deal with the overhead associated with any type of congestion control, causing an increase in congestion. When you are paying a premium for limited speed, you don't want a significant amount of management traffic taking resources away from the critical data that the link was originally purchased for. Frame Relay can reduce this network overhead by implementing a simple congestion-notification mechanism rather than explicit, per-VC flow control.

Shortcomings of CIR

Frame Relay networks provide guaranteed throughput to your critical traffic as long as your data rate falls below the established CIR. If your data rate exceeds the established CIR, the network devices can set a DE bit on the exceeded frames. The DE bit is covered in more detail later in this chapter.

Unfortunately, CIR is not an adaptable setting that can provide flexibility when your traffic rates vary. Service providers often offer their customers the option of bursting above CIR for a defined period of time to handle the bursty nature of LAN traffic crossing a serial interface. Committed burst (Bc) size and excess burst (Be) size define the amount of traffic you can burst above your CIR.

Bc defines the maximum amount of bursty traffic under normal conditions. Be defines the maximum amount of bursty traffic in excess of Bc that Frame Relay attempts to transfer over a set period of time. If the number of frames entering the Frame Relay network is greater than Bc + Be, and the DE bit is set to 1, these frames are discarded.

NOTE

Be is used to determine the maximum data rate (MaxR) for the Frame Relay circuit. MaxR is measured in bits per second and uses the following formula:

MaxR = [(Bc + Be) / Bc] * CIR


If congestion is encountered in a Frame Relay network, two different congestion-notification mechanisms can be used to inform the devices on the circuit:

Figure 9-4 illustrates the directions of FECN and BECN. Notice that FECN travels in the direction of congestion, and BECN travels in the opposite direction of congestion.

Figure 9-4. FECN and BECN Directions

[View full size image]
graphics/09fig04.gif


FECN and BECN each use a single bit in the Frame Relay frame header for congestion notification. Frame Relay also reserves another bit in the header, the DE bit, to mark traffic that may be discarded in the event of congestion.

The FECN Bit

The FECN bit is located in the Address field of the Frame Relay header. The FECN mechanism, used when a DTE device sends frames into the Frame Relay network, is set to 1 when congestion is present. After the frames reach the destination DTE device, the Address field (with the FECN bit set) can be examined. If the bit is set to 1, the frame experienced congestion along the path from the source DTE to the destination DTE. This information can then be sent to a higher-layer protocol for processing. Depending on the implementation of the higher-layer protocol, this information may be used to initiate some type of flow control, or it may be ignored.

The BECN Bit

The BECN bit is located in the Address field of the Frame Relay header. The value of the BECN is set to 1 by the DCE device for frames traveling in the opposite direction of frames that have their FECN bit set. This information tells the receiving DTE device that this particular path through the network is currently experiencing congestion. This information can then be sent to a higher-layer protocol for processing. Depending on the implementation of the higher-layer protocol, this information may be used to initiate some type of flow control, or it may be ignored.

NOTE

A quick review of the FECN/BECN bit tells you that a set FECN bit indicates that a frame encountered congestion, and a set BECN bit notifies the sender of congestion conditions on the circuit. The BECN frame might or might not have encountered any congestion of its own.


Frame Relay Discard Eligibility

Just like traffic that traverses your LAN, certain traffic crossing your WAN needs to have a higher priority than other traffic. There has to be a mechanism for you to ensure that traffic used for business purposes has a higher priority than traffic used to update someone's stock ticker (unless, of course, the stock market is your business). The Frame Relay DE bit indicates frames of priority lower than frames you identify as business-essential. The DE bit is located in the Address field in the Frame Relay header.

When your DTE sets the DE bit to 1, it indicates to the network that this is a frame of lower priority that is eligible for discard (assuming that you have negotiated this in your SLA). On notification of congestion, the DCE begins discarding frames that have the DE bit set before discarding those that do not. This simple management mechanism reduces the likelihood that business-critical traffic will be dropped during periods of congestion.

You can create DE lists that identify the characteristics of packets you want to be eligible for discarding. You can also specify DE groups to identify the DLCI that is affected.

You can use the following command to define a DE list to specify the packets that can be dropped when the Frame Relay switch is congested:



R2(config)#frame-relay de-list list-number {protocol protocol | interface
  typenumber} characteristic

You can base your DE lists on the protocol or the interface, and on characteristics such as fragmentation of the packet, a specific TCP or User Datagram Protocol (UDP) port, an access control list (ACL) number, or a packet size.

You can use the following command to define a DE group specifying the DE list and DLCI affected:



R2(config-if)#frame-relay de-group group-number dlci

Frame Relay Error Checking

Frame Relay uses the CRC, used in many applications such as the file systems in today's popular operating systems, to provide an error-checking mechanism. The CRC works by comparing two calculated values to determine if any errors in the frames were encountered along the transmission path from source to destination. Frame Relay uses the CRC to reduce network overhead caused by error-checking mechanisms. By leaving the extensive error checking up to the higher-layer protocols you run, Frame Relay is not required to retransmit a packet. Instead, the upper-layer protocols retransmit any required packets.

[ LiB ]User-Network Interface Frame Relay Traffic Shaping