Frame Relay Traffic Shaping

Frame Relay Traffic Shaping

Traffic shaping uses a rate control mechanism called a token bucket filter. This token bucket filter is set as follows:

excess burst plus committed burst (Bc + Be) = maximum speed for the virtual circuit (VC)

Traffic above the maximum speed is buffered in a traffic shaping queue which is equal to the size of the weighted fair queue (WFQ). The Token Bucket filter does not filter traffic, but controls the rate at which traffic is sent on the outbound interface. For more information on token bucket filters, please see the Policing and Shaping Overview.

This document provides an overview of generic traffic shaping and Frame Relay traffic shaping.

Traffic Shaping Parameters

We can use the following traffic shaping parameters:

• CIR = committed information rate (= mean time)

• EIR = excess information rate

• TB = token bucket (= Bc + Be)

• Bc = committed burst size (= sustained burst size)

• Be = excess burst size

• DE = discard eligibility

• Tc = measurement interval

• AR = access rate corresponding to the rate of the physical interface (so if you use a T1, the AR is approximately 1.5 Mbps).

Let's look at some of these parameters in more detail:

Access Rate (AR)

The maximum number of bits per second that an end station can transmit into the network is bounded by the access rate of the user-network interface. The line speed of the user network connection limits the access rate. You can establish this in your subscription to the service provider.

Committed Burst Size (Bc)

The maximum committed amount of data you can offer to the network is defined as Bc. Bc is a measure for the volume of data for which the network guarantees message delivery under normal conditions. It is measured during the committed rate Tc.

Excess Burst Size (Be)

The number of non-committed bits (outside of CIR) that are still accepted by the Frame Relay switch but are marked as eligible to be discarded (DE).

The token bucket is a 'virtual' buffer. It contains a number of tokens, enabling you to send a limited amount of data per time interval. The token bucket is filled with Bc bits per Tc. The maximum size of the bucket is Bc + Be. If the Be is very big and, if at T0 the bucket is filled with Bc + Be tokens, you can send Bc + Be bits at the access rate. This is not limited by Tc but by the time it takes to send the Be. This is a function of the access rate.

Committed Information Rate (CIR)

The CIR is the allowed amount of data which the network is committed to transfer under normal conditions. The rate is averaged over a increment of time Tc. The CIR is also referred to as the minimum acceptable throughput. Bc and Be are expressed in bits, Tc in seconds, and the access rate and CIR in bits per second.

Bc, Be, Tc and CIR are defined per data-link connection identifier (DLCI). Due to this, the token bucket filter controls the rate per DLCI. The access rate is valid per user-network interface. For Bc, Be and CIR incoming and outgoing values can be distinguished. If the connection is symmetrical, the values in both directions are the same. For permanent virtual circuits, we define incoming and outgoing Bc, Be and CIR at subscription time.

• Peak = DLCI's maximum speed. The bandwidth for that particular DLCI.

• Tc = Bc / CIR

• Peak = CIR + Be/Tc = CIR (1 + Be/Bc)

If the Tc is one second then:

• Peak = CIR + Be = Bc + Be

• EIR = Be

In the example we are using here, the router sends traffic between 48 Kbps and 32 Kbps depending on congestion in the network. Networks may mark frames above Bc with DE but have plenty of spare capacity to transport the frame. The reverse is also possible: they can have limited capacity, yet discard excessive frames immediately. Networks may mark frames above Bc + Be with DE, and possibly transport it, or just drop the frames as suggested by the International Telecommunication Union Telecommunication Standardization Sector specification ITU-T I.370. Traffic shaping throttles the traffic based on backward-explicit congestion notification (BECN) tagged packets from the switch network. If you receive 50 percent BECN, the router decreases the traffic by one eighth of the current transmitted bandwidth for that particular DLCI.

Example

The transmitted speed is 42 Kb. The router decreases the speed to 42 minus 42 divided by 8 (42 - 42/8), making 36.75 Kb. If the congestion decreases after the change, the router reduces the traffic further, dropping to one eighth of current transmitted bandwidth. The traffic is reduced until it reaches the configured CIR value. However, the speed can drop under the CIR when we can still see BECNs. You can specify a bottom limit, such as CIR/2. The network is no longer congested when all frames received from the network no longer have a BECN bit for a given time interval. 200 ms is the default value for this interval.

Generic Traffic Shaping

The Generic traffic shaping feature is a media and encapsulation-independent traffic shaping tool that helps reduce the flow of outbound traffic when there is congestion within the cloud, on the link, or at the receiving endpoint router. We can set it on interfaces or subinterfaces within a router.

Generic traffic shaping is useful in the following situations:

• When you have a network topology that consists of a high-speed (T1 line speed) connection at the central site and low speed (less than 56 kbps) connections at the branch or telecommuter sites. Because of the speed mismatch, a bottleneck often exists for traffic on the branch or telecommuter sites when the central site sends data at a faster rate that the remote sites can receive. This results in a bottleneck in the last switch before the remote-point router.

• If you are a service provider that offers sub-rate services, this feature enables you to use the router to partition your T1 or T3 links, for example, into smaller channels. You can configure each subinterface with a token filter bucket that matches the service ordered by a customer.

On your Frame Relay connection, you may want the router to throttle traffic instead of sending it into the network. Throttling the traffic would limit packet loss in the service provider's cloud. The BECN-based throttling capability provided with this feature allows you to have the router dynamically throttle traffic based on receiving BECN tagged packets from the network. This throttling holds packets in the router's buffers to reduce the data flow from the router into the Frame Relay network. The router throttles traffic on a subinterface basis, and the rate is also increased when fewer BECN-tagged packets are received.

Commands for Generic Traffic Shaping

To define rate control, use this command:

traffic-shape rate bit-rate [burst-size [excess-burst-size]] [group access-list]

To throttle BECNs on a Frame Relay interface use this command:

traffic-shape adaptive [bit-rate]

To configure a Frame Relay subinterface to estimate the available bandwidth when it receives BECNs, use the traffic-shape adaptive command.

Note: You must enable traffic shaping on the interface with the traffic-shape rate command before you can use the traffic-shape adaptive command.

The bit rate specified for the traffic-shape rate command is the upper limit, and the bit rate specified for the traffic-shape adaptive command is the lower limit (usually the CIR value) at which traffic is shaped when the interface receives BECNs. The rate actually used is normally between these two rates. You should configure the traffic-shape adaptive command at both ends of the link, as it also configures the device at the flow end to reflect forward explicit congestion notification (FECN) signals as BECNs. This enables the router at the high-speed end to detect and adapt to congestion even when traffic is flowing primarily in one direction.

Example

The following example configures traffic shaping on interface 0.1 with an upper limit (usually Bc + Be) of 128 kbps and a lower limit of 64 kbps. This allows the link to run from 64 to 128 kbps, depending on the congestion level. If the central side has a upper limit of 256 kbps, you should use the lowest upper limit value.

Here's what we have configured on these routers:

Central# 
 interface serial 0 
  encapsulation-frame-relay 
 interface serial 0.1    
  traffic-shape rate 128000 
  traffic-shape adaptive 64000 


Client# 
 interface serial 0 
  encapsulation-frame-relay 
 interface serial 0.1 
  traffic-shape rate 128000 
  traffic-shape adaptive 64000 

Frame Relay Traffic Shaping

With generic traffic shaping you can only specify one peak rate (upper limit) per physical interface and one CIR (lower limit) value per subinterface. With Frame Relay traffic shaping, you start a token bucket filter per Virtual Circuit.

The traffic shaping over Frame Relay feature provides the following capabilities:

• Rate enforcement on a per-VC basis: You can configure a peak rate to limit outbound traffic to either the CIR or some other defined value such as the excess information rate (EIR).

• Generalized BECN support on a per-VC basis: The router can monitor BECNs and throttle traffic based on BECN-marked packet feedback from the Frame Relay network.

• Priority queuing (PQ), custom queuing (CQ) or WFQ support at the VC level. This allows for finer granularity in the prioritisation and queuing of traffic, giving you more control over the traffic flow on an individual VC. The traffic shaping over Frame Relay feature applies to Frame Relay permanent virtual circuits (PVCs) and switched virtual circuits (SVCs).

Example

Interface Serial 0 
 no ip address 
 encapsulation frame-relay 
 frame-relay traffic-shaping    
! 
interface Serial0.100 
 ip address 1.1.1.1 255.255.255.252 
 frame-relay interface-dlci 100 
 frame-relay class fast 
! 
interface Serial0.200 
 ip address 1.1.1.5 255.255.255.252    
 frame-relay interface-dlci 200 
 frame-relay class slow 
! 
map-class frame-relay slow 
 frame-relay traffic-rate 64000 128000 
! 
map-class 
 frame-relay fast 
 frame-relay traffic-rate 16000 64000 
!

In this example the router adds two token-buckets.

• One runs between 64000 (CIR) and 128000(Bc + Be).

• The other runs between 16000 (CIR) and 64000 (Bc + Be).

If incoming traffic from Ethernet is larger than the token bucket filter, the traffic is buffered up in the frame-relay traffic queue.

To view a flow chart showing packet flow when you implement Frame Relay traffic shaping, please see Frame Relay Traffic Shaping Flowchart. To view a flow chart specifically using a token bucket filter, please see Frame Relay Traffic Shaping - Token Bucket Flowchart.

Commonly Used Frame Relay Commands

This section describes two Cisco IOS® commands that are especially useful when configuring Frame Relay.

show frame-relay pvc

This command shows the status of the permanent virtual circuit (PVC), packets in and out, dropped packets if there is congestion on the line via forward explicit congestion notification (FECN) and backward explicit congestion notification (BECN), and so on. For a detailed description of the fields used with the show frame-relay pvc command, click here.

If you have the output of a show frame-relay pvc command from your Cisco device, you can use Output Interpreter (registered customers only) to display potential issues and fixes.

Sample output is shown below:

RouterA#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
DLCI = 666, DLCI USAGE = UNUSED, PVC STATUS = DELETED, INTERFACE = Serial0
  input pkts 0             output pkts 0            in bytes 0         
  out bytes 0              dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  pvc create time 0:03:18  last time pvc status changed 0:02:27
  Num Pkts Switched 0         
DLCI = 980, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
  input pkts 19            output pkts 87           in bytes 2787      
  out bytes 21005          dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  pvc create time 1:17:47  last time pvc status changed 0:58:27

The DLCI USAGE field contains one of the following entries:

• SWITCHED - the router or access server is used as a switch.

• LOCAL - the router or access server is used as data terminal equipment (DTE).

• UNUSED - the data-link connection identifier (DLCI) is not referenced by user-entered configuration commands on the router.

The PVC can have four possible states. These are shown by the PVC STATUS field as follows:

• ACTIVE - PVC is up and functioning normally.

• INACTIVE - PVC is not up end-to-end. This may be because either there is no mapping (or incorrect mapping) for the local DLCI in the frame-relay cloud or the remote end of the PVC is Deleted.

• DELETED - Either the Local Management Interface (LMI) is not exchanged between the router and the local switch, or the switch does not have DLCI configured on the local switch.

• STATIC - no keepalive configured on the frame-relay interface of the router.

show frame-relay map

Use this command to determine if frame-relay inverse-arp resolved a remote IP address to a local DLCI. This command is not enabled for point-to-point subinterfaces. It is useful for multipoint interfaces and subinterfaces only. Sample output is shown below:

RouterA#show frame-relay map
Serial0 (up): ip 157.147.3.65 dlci 980(0x3D4,0xF440), dynamic,
         broadcast,, status defined, active

For a detailed description of the fields used with the show frame-relay map command, please see Documentation on frame relay Commands.

If you have the output of a show frame-relay map command from your Cisco device, you can use Output Interpreter (registered customers only) to display potential issues and fixes.

Frame Relay and Bridging

Configuration messages called bridge protocol data units (BPDUs) are used in the spanning-tree protocols supported in Cisco bridges and routers. These flow at regular intervals between bridges and constitute a significant amount of traffic because of their frequent occurrence. There are two types of spanning-tree protocols in transparent bridging. First introduced by the Digital Equipment Corporation (DEC), the algorithm was subsequently revised by the IEEE 802 committee and published in the IEEE 802.1d specification. The DEC Spanning-Tree Protocol issues BPDUs at one-second intervals, while the IEEE issues BPDUs at two-second intervals. Each packet is 41 bytes, which includes a 35-byte configuration BPDU message, a 2-byte Frame Relay header, 2-byte Ethertype, and a 2-byte FCS.

Frame Relay and Memory

Memory consumption for Frame Relay resources occurs in four areas:

1. Each data-link connection identifier (DLCI): 216 bytes

2. Each map statement: 96 bytes (or dynamically built map)

3. Each IDB (hardware interface + encap Frame Relay): 5040 + 8346 = 13,386 bytes

4. Each IDB (software subinterface): 2260 bytes

For example, a Cisco 2501 using two Frame Relay interfaces, each with four subinterfaces, with a total of eight DLCIs, and associated maps needs the following:

• 2-interface hardware IDB x 13,386 = 26,772

• 8-subinterface IDB x 2260 = 18,080 subinterfaces

• 8 DLCIs x 216 = 1728 DLCIs

• 8 map statements x 96 = 768 map statements or dynamics

The total is equal to 47,348 bytes of RAM used.

Note: The values used here are valid for Cisco IOS Release 11.1, 12.0 and 12.1 software.

http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a008014f8a7.shtml