Frame Relay Traffic Shaping

Network Consultants Handbook – Frame Relay
by Matthew Castelli

Traffic shaping supports the controlling of the traffic going out of an interface. This control matches the flow of traffic to the speed of the remote destination (or target) interface and ensures that the traffic conforms to policies contracted for the interface. Traffic adhering to a particular profile can be shaped to meet downstream requirements, eliminating bottlenecks in topologies with data-rate mismatches.

The primary reasons for using traffic shaping are to control access to available bandwidth, to ensure that traffic conforms to the policies established for the available bandwidth, and to regulate the flow of traffic to avoid congestion. Congestion can occur when the sent traffic exceeds the access speed of its destination (target) interface across a VC.

Following are some examples of when to use traffic shaping:

• To control access to bandwidth when policy dictates that the rate of a given interface should not, on the average, exceed a certain rate, even though the access rate exceeds the speed.

• To configure traffic shaping on an interface if you have a network with differing access rates. Suppose that one end of the link in a Frame Relay network runs at 256 kbps and the other end of the link runs at 128 kbps. Sending packets at 256 kbps could cause failure of the applications that are using the link.

Regarding a similar, more complicated case, a link-layer network giving indications of congestion that has differing access rates on different attached DTE; the network might be able to deliver more transit speed to a given DTE device at one time than another. (This scenario warrants that the token bucket be derived, and then its rate maintained.)

• To partition the T1 or T3 links into smaller channels in a subrate service scenario.

Traffic shaping prevents packet loss. The use of traffic shaping is especially important in Frame Relay networks because the switch cannot determine which frames take precedence and therefore which frames should be dropped when congestion occurs. It is important for real-time traffic, such as VoFR, that latency be bounded, thereby bounding the amount of traffic and traffic loss in the data link network at any given time by keeping the data in the router that is making the guarantees. Retaining the data in the router allows the router to prioritize traffic according to the guarantees that the router is making.

Traffic shaping limits the rate of transmission of data, limiting the data transfer to one of the following:

• A specific configured rate

• A derived rate based on the level of congestion

The transfer rate depends on three components that constitute the token bucket: burst size, mean rate, measurement (time) interval.

The mean rate is equal to the burst size divided by the interval, as demonstrated by the following equation:

 Mean rate = Burst Size (BC + BE) / Time Interval (TC)

When traffic shaping is enabled, a maximum burst size can be sent during every time interval. However, within the interval, the bit rate might be faster than the mean rate at any given time.

B_E size is an additional variable that applies to traffic shaping. The excess burst size corresponds to the number of noncommitted bits — those bits outside the CIR — that are still accepted by the Frame Relay switch but marked as DE.

The B^E size allows more than the burst size to be sent during a time interval. The switch will allow the frames that belong to the excess burst to go through, but it will mark them by setting the DE bit. The switch configuration determines whether the frames are sent.

When B_E size equals 0 (B_E = 0) the interface sends no more than the burst size every interval, realizing an average rate no higher than the mean rate. When B_E size is greater than 0 (B_E > 0) the interface can send as many as B_C + B_E bits in a burst, if the maximum amount was not sent in a previous time period. When less than the burst size is sent during an interval, the remaining number of bits, up to the BE size, can be used to send more than the burst size in a later interval.

Frame Relay DE Bit
Frame Relay frames can be specified regarding which have low priority or low time sensitivity. These frames will be the first to be dropped when a Frame Relay switch is congested.
The DE bit is the mechanism that allows a Frame Relay switch to identify such frames to be dropped or discarded.
DE lists and groups can be managed in the following manner:

• DE lists can be specified that identify the characteristics of frames to be eligible for discarding.
• DE groups can be specified to identify the affected DLCI.
• DE lists can also be specified based 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 list number, or a packet size.

Differences Between Traffic-Shaping Mechanisms
Generic traffic shaping (GTS), class-based shaping, distributed traffic shaping (DTS), and Frame Relay traffic shaping (FRTS) are similar in implementation, share the same code and data structures, differ in regard to their CLIs, and differ in the queue types used.

Following are some examples in which these mechanisms differ:

• For GTS, the shaping queue is a weighted fair queue. For FRTS, the queue can be a weighted fair queue (configured by the frame-relay fair-queue command), a strict priority queue with WFQ (configured by the frame-relay ip rtp priority command in addition to the frame-relay fair-queue command), custom queuing (CQ), priority queuing (PQ), or first-in, first-out (FIFO). See Table 15-16 for detailed differences.
• For class-based shaping, GTS can be configured on a class, rather than only on an access control list (ACL). To do so, you must first define traffic classes based on match criteria including protocols, access control lists (ACLs), and input interfaces. Traffic shaping can be applied to each defined class.
• FRTS supports shaping on a per-DLCI basis; GTS and DTS are configurable per interface or subinterface.
• DTS supports traffic shaping based on a variety of match criteria, including user-defined classes, and DSCP.

Table 15-16: Differences Between Shaping Mechanisms

GTS can be configured to behave the same as FRTS by allocating one DLCI per subinterface and using GTS plus BECN support. The behavior of the two is then the same with the exception of the different shaping queues used.

FRTS, like GTS, can eliminate bottlenecks in Frame Relay networks that have high-speed connections at the central site and low-speed connections at branch sites. Rate enforcement can be configured as a peak rate configured to limit outbound traffic to limit the rate at which data is sent on the VC at the central site.

FRTS can be used to configure rate enforcement to either the CIR or some other defined value, such as the excess information rate, on a per-VC basis. The ability to allow the transmission speed that the router uses to be controlled by criteria other than line speed — the CIR or excess information rate — provides a mechanism for sharing media by multiple VCs. Bandwidth can be allocated to each VC, creating a virtual time-division multiplexing (TDM) network.

PQ, CQ, and WFQ can be defined at the VC or subinterface level. These queuing methods allow for finer granularity in the prioritization and queuing of traffic, providing more control over the traffic flow on an individual VC. If CQ is combined with the per-VC queuing and rate enforcement capabilities, Frame Relay VCs can carry multiple traffic types such as IP, SNA, and IPX with bandwidth guaranteed for each traffic type.

FRTS can dynamically throttle traffic by using information that is contained in the BECN-tagged frames that are received from the network. With BECN-based throttling, frames are held in the router buffers to reduce the data flow from the router into the Frame Relay network. Throttling is done on a per-VC basis, and the transmission rate is adjusted based on the number of BECN-tagged frames received.

Derived Rates
FECNs and BECNs indicate congestion in a Frame Relay WAN and are specified by bits within a Frame Relay frame. FECN and BECN operation is as follows:

• FECNs — These are generated when data is sent out of a congested interface. FECNs indicate to a Frame Relay device that congestion was encountered along the transmission path to the destination. Traffic is marked with BECN if the queue for the opposite direction is full enough to trigger FECNs at the current time.

• BECNs — These notify the sending Frame Relay device to decrease the transmission rate. If the traffic is one-way only (such as multicast traffic), there is no reverse traffic with BECNs to notify the sending device to slow down. When a Frame Relay device receives a FECN, it first determines whether it is sending data. If the Frame Relay device is sending data along the return path of the FECN, this data will be marked with a BECN on its way to the other Frame Relay device. If the Frame Relay device is not sending data, it can send a Q.922 “TEST RESPONSE” message with the BECN bit set.

When an interface that is configured with traffic shaping receives a BECN, it immediately decreases, or throttles down, its maximum rate by a significant amount. If, after several intervals, the [throttled] interface has not received another BECN and traffic is waiting in the queue, the maximum rate slightly increases. This dynamically adjusted maximum rate is called the derived rate, which will always be between the upper bound and the lower bound that is configured on the interface.

Traffic Shaping Restrictions
FRTS applies only to Frame Relay PVCs and SVCs.

Figure 15-28 represents the traffic shaping process flow upon receipt of a frame for transmission.

Figure 15-28: Traffic Shaping Flowchart

(Click image for larger view in a new window)

—
Our next segment from Cisco Press’ Network Consultants Handbook will deal with Traffic Policing and Shaping.