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.
NOTE: 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 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 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.
BE 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 BE 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 BE size equals 0 (BE = 0) the interface sends no more than the burst size every interval, realizing an average rate no higher than the mean rate. When BE size is greater than 0 (BE > 0) the interface can send as many as BC + BE 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
|Command-Line Interface||Applies parameters per subinterface
Traffic group command supported
|Applies parameters per interface or per class||Applies parameters per interface or subinterface||Classes of parameters|
Applies parameters to all VCs on an interface through inheritance mechanism
No traffic group command
|Queues Supported||Weighted fair queuing (WFQ) per subinterface||Class-based weighted fair queuing (CBWFQ) inside GTS||WFQ, strict priority queue with WFQ, CQ, PQ, first come, first served (FCFS) per VC||WFQ, strict priority queue with WFQ, CQ, PQ, FCFS per VC|
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.
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.
Our next segment from Cisco Press' Network Consultants Handbook will deal with Traffic Policing and Shaping.