This diagram illustrates the network topology for the sample scenarios used in this document:


Sample Scenario: Frame Relay Traffic Shaping for Data Only
Assume this scenario: A 128Kbps frame relay circuit with a CIR PVC of 64Kbps. The user wants to burst to port speed (128Kbps) and throttle down to CIR rate (64 kbps) if BECNs are received to avoid data loss.
FRTS for Data PVCs
This is a typical FRTS configuration for data PVCs:
!--- Output suppressed.
interface Serial1
no ip address
no ip directed-broadcast
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
!
interface Serial1.100 point-to-point
ip address 1.1.1.1 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 100   
   class my_net
!
!--- Output suppressed.
!
map-class frame-relay my_net
frame-relay adaptive-shaping becn
frame-relay cir 128000
对于数据×××，这里一般设置成比实际线路CIR大或者等于接口速度
frame-relay bc 8000
frame-relay be 8000
frame-relay mincir 64000
对于数据×××，这里一般设置成实际VC的CIR（提供商提供的）
Relevant FRTS Commands
      frame-relay traffic-shaping—This command enables FRTS for the interface. Every DLCI under this interface is traffic shaped with either user-defined or default traffic shaping parameters. User-defined parameters can be specified in two ways:
o         Using the command class class_name under the frame-relay interface-dlci configuration or
o         Using the command frame-relay class under the serial interface.
In the example above, class my_net is used under the DLCI configuration.
      class class_name —Use this command to configure FRTS parameters for a specific DLCI. In the above example, the class is defined as "my_net". The class parameters are configured under the command map-class frame-relay class_name .
      map-class frame-relay class_name —Use this command to configure the FRTS parameters for a specified class. There can be multiple class-maps in a configuration. Each DLCI can have a separate class or DLCIs can share a single map class.
      frame-relay adaptive-shaping becn —This command configures the router to respond to frame relay frames that have the BECN bit set. When a frame is received on that PVC with the BECN bit set, then the router throttles traffic down on that PVC to the MINCIR value. The CIR is usually set to the port speed or a value higher than the true CIR of the PVC. The MINCIR value is then set to the true CIR of the PVC.
      frame-relay cir bps —Use this command to specify the incoming or outgoing committed information rate (CIR) for a Frame Relay virtual circuit.
      frame-relay bc bits —Use this command to specify the incoming or outgoing committed burst size (Bc) for a Frame Relay virtual circuit.
      frame-relay be bits —Use this command to specify the incoming or outgoing excess burst size (Be) for a Frame Relay virtual circuit.
      frame-relay mincir bps —Use this command to specify the minimum acceptable incoming or outgoing committed information rate (CIR) for a Frame Relay virtual circuit. This is the rate at which traffic will be throttled down to when using adaptive shaping.
Frame Relay Traffic Shaping For Voice
When configuring FRTS for voice, data performance may suffer at the expense of good voice quality. Here are some guidelines to enhance voice quality when configuring FRTS for voice:
      Do not exceed the CIR of the PVC
对于语音，最好不要超额使用实际线路的CIR，避免使用BECN等流量×××方法。
Most users have difficulty following this recommendation because the result is the router will no longer be able to burst to port speed. Because voice quality cannot tolerate much delay, any queueing of voice packets within the Frame Relay cloud must be minimized. When CIR is exceeded (PVC CIR, not the router configured CIR), depending on the provider and how congested the rest of the Frame Relay network is, packets may begin queue in the Frame Relay network. By the time the Frame Relay switch queues have backed up enough to trigger BECNs, the voice quality is already diminished. Because customers have many different Frame Relay providers and differing amounts of congestion across their sites, it is difficult to forecast what configuration works. Maintaining values at (or below) CIR on the PVCs that transport voice has proven to work consistently.
Some providers sell a Frame Relay service of 0 CIR. Obviously, not exceeding CIR in this case would prevent any voice from being sent across the frame link. A service of 0 CIR may be used for voice but there needs to be a Service Level Agreement (SLA) with the provider to guarantee minimal delay and jitter for a certain bandwidth across the 0 CIR PVC.
      Do not use frame relay adaptive shaping
If the configured CIR within the frame relay map class is the same as the true CIR of the PVC, there is no need to throttle down traffic due to BECNs. If CIR is not exceeded, BECNs are not generated.
      Make Bc small so that Tc (shaping interval) is small (Tc = Bc/CIR)
设置BC足够小，这样可以使得TC间隔变小。
The minimum Tc value is 10 ms, which is ideal for voice. With a small Tc value, there is no risk of large packets using all the shaping credits. Large Tc values can lead to large gaps between packets sent because the traffic shaper waits an entire Tc period to build up additional credits to send the next frame. Making Bc = 1000 bits is usually a low enough value to force the router to use the minimum Tc of 10ms. This setting should not affect data throughput.
      Set Be = zero
To ensure the CIR value is not exceeded, Be is set to zero so there is no excess burst within the first shaping interval.
Note:   A good solution employed by some customers is to use separate PVCs for data and voice. This solution enables the customer to transmit up to port speeds in the data only PVC while maintaining a load at or below CIR on the voice PVC. Some frame providers may not find the solution appropriate depending on the frame switch and its queuing structure. If possible, have the Frame Relay provider prioritize the voice PVC over the data one so that there is not any queuing delay because of the data packets.
Sample Scenario: Frame Relay Traffic Shaping for Voice
Assume the following scenario: A 128Kbps frame relay circuit with a CIR PVC of 64Kpbs. The Frame Relay PVC is used to transport voice and data traffic.
Traffic Shaping Configuration for Voice over IP (VoIP) over Frame Relay
This is a typical configuration for traffic shaping for Voice over IP (VoIP) over Frame Relay:

!--- Output suppressed.
!
interface Serial1
no ip address
no ip directed-broadcast
encapsulation frame-relay
frame-relay traffic-shaping
!
ip address 1.1.1.1 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 100   
   class voice
!
!--- Output suppressed.

!
map-class frame-relay voice
frame-relay fragment 160
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 1000
frame-relay be 0
frame-relay fair-queue
!
下面是在FR上配置VOICE单独带宽.
Traffic Shaping Configuration for Voice over Frame Relay (VoFR)
This is a typical configuration for traffic shaping for VoFR:
!--- Output suppressed.


!
interface Serial1
no ip address
no ip directed-broadcast
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial1.100 point-to-point
ip address 1.1.1.1 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 100   
   class voice
   vofr cisco
!
!--- Output suppressed.
!
map-class frame-relay voice
frame-relay voice bandwidth 32000
frame-relay fragment 160
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 1000
frame-relay be 0
frame-relay fair-queue
!
Relevant FRTS Commands
Relevant FRTS commands (not discussed in the Frame Relay Traffic Shaping For Data section) are explained in this section.
      vofr cisco—(Applicable only for VoFR) This command enables VoFR for the PVC.
      frame-relay voice bandwidth bps —Applicable only for VoFR) Use this command to specify how much bandwidth is reserved for voice traffic on a specific data link connection identifier (DLCI). This command gives voice traffic a bandwidth ceiling.
      frame-relay fragment bytes —Use this command to enable fragmentation of Frame Relay frames for a Frame Relay map class. For more information refer to: Frame Relay Fragmentation for Voice. Be aware that every PVC that shares an interface with a voice PVC will need fragmentation depending on the lowest link speed between the two routers, even if the PVC is data only. Since the voice PVC may share the same physical interface as other PVCs, large datagrams going out on these other PVCs may cause delay for voice packets trying to go out the same physical interface on a voice PVC.
      no frame-relay adaptive-shaping—This command disables adaptive shaping.
      frame-relay cir 64000 —Use this command to force the router to transmit at the same rate of the PVC CIR (In the above example, 64kbps even though the port speed is 128Kbps).
      frame-relay bc 1000—Use this command to configure the router to use a small Tc or shaping interval.
      frame-relay be 0—Since the PVC CIR is not exceeded, be is set to 0 so that there is no excess burst in the first shaping interval

Background Theory
A big challenge with voice-data integration is to control the maximum one-way end-to-end delay for time-sensitive traffic such as voice. For good voice quality, this delay is less than 150 milliseconds (ms). An important part of this delay is the serialization delay on the interface, which should not exceed 20 ms. Serialization delay is the time it takes to actually place the bits onto an interface.
Serialization Delay = frame size (bits) / link bandwidth (bits per second [bps])
For example, a 1500-byte (B) packet takes 187 ms to leave the router over a 64 kbps link. If you send a nonreal-time data packet of 1500 B, real-time (voice) data packets queue until the transmit of the large data packet. This delay is unacceptable for voice traffic. If nonreal-time data packets are fragmented into smaller frames, the frames are interleaved with real-time (voice) frames. In this way, both voice and data frames can be carried together on low-speed links without excessive delay to the real-time voice traffic.
FRF.12 Fragmentation
FRF.12 is an implementation agreement that supports voice and other real-time delay-sensitive data on low-speed links. The standard accommodates variations in frame sizes in a manner that allows a mixture of real-time and nonreal-time data.
FRF.12 stipulates that, when fragmentation is on for a data-link connection identifier (DLCI), there is fragmentation of only data frames that exceed the specified fragmentation size. This arrangement allows small VoIP packets, which are not fragmented due to the size, to be interleaved as frames between large data packets that have been fragmented into smaller frames. This improves the serialization delay for packets that leave the router. As a result, voice packets do not wait for the process of large data packets.
In a VoIP implementation, Frame Relay (Layer 2 protocol) cannot distinguish between VoIP and data frames. FRF.12 fragments all packets that are larger than the fragment size setting. Configure the fragmentation size on the DLCI such that voice frames are not fragmented. You can configure the fragment size under the Cisco IOS? Software map-class frame-relay command with the issue of the frame-relay fragment fragment_size command. The fragment size is in bytes, and the default is 53 B. Many variables determine the size of the voice packets. For more information on voice packet size, refer to the document Voice over IP - Per Call Bandwidth Consumption.
FRF.11 Standard
A Voice over Frame Relay (VoFR) implementation uses the FRF.11 to define how voice and data are encapsulated on the Frame Relay DLCI. Thus, data, fax signaling, and voice use FRF.11 encapsulation for transmission on a DLCI that carries voice. To mix these traffic types on a DLCI, FRF.11 defines subchannels (identifiable by channel IDs) within the DLCI. Each subchannel has a header field that describes the frame payload type. FRF.11 can specify up to 255 subchannels per DLCI.
Note: If you have not configured DLCIs for VoFR, the DLCIs use standard Frame Relay data encapsulation, as FRF.3.1 specifies.
FRF.11 Annex-C Fragmentation
FRF.11 Annex-C fragmentation describes the way an FRF.11 DLCI (configured for VoFR) carries data. FRF.11 Annex-C includes a fragmentation specification for the data subchannels.
Only frames with data payload type are fragmented. Frame Relay distinguishes voice frames from nonreal-time data frames because the FRF.11 payload specifies the traffic type. Therefore, regardless of the voice frame size, the voice frame bypasses the fragmentation engine.
Frame Relay FRF.12 Versus FRF.11 Fragmentation
There are several recognized forms of Frame Relay fragmentation:
FRF.11 Annex-C fragmentation—Used on DLCIs configured for VoFR.
FRF.12 fragmentation—Used on DLCIs that carry data (FRF.3.1) traffic, which includes VoIP. The Layer 2 Frame Relay protocol considers the VoIP packets to be data.
There is a common misconception that FRF.12 fragmentation supports VoFR and a general unawareness that FRF.11 also specifies a fragmentation scheme. This confusion results in misunderstanding about fragmentation for VoFR and VoIP over Frame Relay. This list clarifies some key differences:
A Frame Relay DLCI runs either FRF.12 or FRF.11, but never both. FRF.12 and FRF.11 are mutually exclusive.
If you have configured the DLCI for VoFR, the DLCI uses FRF.11. If fragmentation is on for this DLCI, the DLCI uses FRF.11 Annex-C (or the Cisco derivative) for the fragmentation headers.
If you have not configured the DLCI for VoFR, the DLCI uses FRF.3.1 data encapsulation. If fragmentation is on for this DLCI, the DLCI uses FRF.12 for the fragmentation headers. DLCIs which carry VoIP use FRF.12 fragmentation because VoIP is a Layer 3 technology that is transparent to Layer 2 Frame Relay.
You can support VoIP and VoFR on different DLCIs on the same interface, but not on the same DLCI.
FRF.12 fragments voice packets if you have set the fragmentation size parameter to a value smaller than the voice packet size. FRF.11 Annex-C (VoFR) does not fragment voice packets regardless of the fragmentation size that you have configured.
FRF.11 Annex-C only needs support in platforms that support VoFR. Because the use of FRF.12 is predominantly for VoIP, it is important to support FRF.12 as a general feature on Cisco IOS Software platforms that transport VoIP over slow-speed WAN links (slower than 1.5 Mbps). For this reason, there is support for FRF.12, in Cisco IOS Software Release 12.1.2T and later, on nonvoice-gateway platforms such as the 805, 1600, 1700, 2500, 4500, and 4700.
NetPro Discussion Forums - Featured Conversations
Networking Professionals Connection is a forum for networking professionals to share questions, suggestions, and information about networking solutions, products, and technologies. The featured links are some of the most recent conversations available in this technology.