The Four Flavors of Frame-Relay Traffic Shaping
In this short blog post, we are going to give condensed overview of the four main flavors of Frame-Relay Traffic Shaping (FRTS). Historically, as IOS evolved with time, different methods have been introduced, having various level of feature support. Two main features, specific to Frame-Relay Traffic-Shaping are per-VC shaping and queueing and adaptive shaping in response to Frame-Rleay congestion notifications (e.g. BECNs). You'll see that not every flavor supports these two features. We begin with the «fossil» known as Generic Traffic Shaping.
Generic Traffic Shaping
This feature was initially designed to shape packet traffic sent over any media, be it Ethernet, Frame-Relay, PPP etc. The command syntax is traffic-shape {rate|group} and allows specifying traffic scope using an access-list (notice that different ACL types are supported). You may tune the Bc/Be values as well as the shaping queue depth (amount of buffers). If the shaper delays traffic, the queue service strategy would be fixed to WFQ with the queue size equal to the buffer space allocated. Additional WFQ parameters such as number of flows and congestive discard threshold could not be tuned and set based on the shaper rate automatically.
An unique feature of GTS is the ability to apply multiple shapers to a single interface. However, shapers are not cascaded, but rather a packet is assigned to the first matching shaper rule. In the example below, there are three rules, with the last one being "fallback", matching all packets that didn't match access-lists 100 and 101. Unlike using the legacy CAR feature (rate-limit command) you cannot «cascade» multiple traffic-shape statements on the same interface, i.e. there is no "continue" action.
traffic-shape group 100 128000
traffic-shape group 101 64000
traffic-shape group 199 256000
!
access-list 199 permit ip any any
You cannot apply GTS per-VC unless you have created a subinterface for this particular PVC. You may, however, enable shaping that adapts to FR BECNs, using the syntax traffic-shape adaptive {rate} along with traffic-shape rate. Notice that if multiple PVCs map to interface, reception of a BECN on any of the VCs will trigger speed throttling.
Legacy Frame-Relay Traffic-Shaping
This feature uses the map-class frame-relay syntax and was initially designed to implement specifically Frame-Relay Traffic Shaping and Policing (FRTS and FRTP) in Cisco IOS routers. This is still probably the most widely used form of FRTS. You specify all parameters under a map-class and then apply this map-class to a specific PVC or interface using the syntax similar to the following:
map-class frame-relay DLCI_101
frame-relay cir 256000
frame-relay bc 2560
frame-relay be 0
frame-relay mincir 192000
frame-relay adaptive-shaping becn
!
interface Serial 0/0
frame-relay traffic-shaping
!
interface Serial 0/0.1
frame-relay interface-dlci 101
class DLCI_101
A mandatory command that goes with Legacy FRTS is frame-relay traffic-shaping applied to an interface (there is also frame-relay policing command to implement traffic policing). With this command applied, all PVC CIRs are set to default 56Kbps unless you change that value in a map-class that you apply. Additionally, interface software queue is turned into FIFO, and every PVC gets its own, second-level, logical queue realized as shaper's queue. Therefore, FRTS enables "true" FRTS by allowing for two-level queueing hierarchy.
Legacy FRTS allows for various queueing methods on per-VC level. You may use any of legacy techniques such as Custom Queueing, Priority Queueing, FIFO and WFQ/IP RTP Priority. More importantly, you may enable CBWFQ on per-VC level, by using the map-class command service-policy output along with the policy-map implementing CBWFQ logic. Note that if you apply CBWFQ per-VC, the maximum avaiable bandwidth is based on minCIR settings for a VC, not the CIR.
All the above QoS mechanisms could be combined with Per-VC fragmentation enabled solely by using the map-class command frame-relay fragment. Normally, you need to enable fragmentation on every PVC terminated on the interface, so make sure you configure all map-classes properly. As soon as fragmentation is enabled, the interface-level FIFO queue is turned into special «truncated» Priority Queue used for interleaving fragments and voice packets. Only High and Normal queues out of the PQ are used to implement interleaving and you can inspect queue utilization using the command show queueing.
Obviously enough, you cannot use GTS on the same interface where FRTS has been enabled and vice-versa - IOS will reject the command. Compared to GTS, legacy FRTS provide a lot of syntactical consistency - you apply all features using the map-class commands plus you have a rich selection of QoS mechanisms along with that.
(BTW, if you're wondering the purpose of frame-relay tc command under a map-class, it is used in zero-CIR scenarios for traffic policing. With zero-CIR policing all traffic is considered exceeding, but you may want to specify the peak rate by setting Be and Tc together).
MQC Frame-Relay Traffic-Shaping
This was Сisco's attempt to leverage MQC syntax for the purpose of traffic-shaping. The problem was that the syntax is still combined with the "legacy" style map-class syntax. Here's how it works:
- You create a «first-level» policy-map implementing shaping for a VC. You can only use «class-default» at this level, and apply shaping parameters using the commands shape average, shape peak, and shape adaptive. For example:
policy-map SHAPE
class class-default
shape average 512000 5120 0
shape adaptive 256000 - You create «nested» or «second-level» policy that implements CBWFQ. Note that CBWFQ/LLQ is the only queueing method supported with MQC-based FRTS (no CQ or PQ allowed, though you can emulate WFQ using MQC syntax).
policy-map CBWFQ
class VOICE
priority 128
class class-default
fair-queue - Combine both policy-maps and attach the parent policy to a map class. You should not enable the interface-level command frame-relay traffic-shaping with MQC FRTS.
policy-map SHAPE
class class-default
service-policy CBWFQ
!
map-class frame-relay DLCI_101
service-policy output SHAPE
!
interface Serial 0/0.1
frame-relay interface-dlci 101
class DLCI_101
From the above configuration example it is apparent that PVC shaping settings are now defined using the MQC shape average and shape adaptive commands. Similar to the use of CBWFQ with legacy FRTS, available CBWFQ bandwidth is based on the shape adaptive setting. Also, as mentioned before, you should not use the command frame-relay traffic-shaping with MQC FRTS. In fact, legacy FRTS and MQC FRTS are incompatible.
Frame-Relay Fragmentation (FRF.12) is supported with MQC FRTS, however you have to enable it at the interface level using the command frame-relay fragment X end-to-end. Interleaving queue is created automatically and cannot be seen using IOS show commands. Fragmentation is enabled on all PVCs terminated at the interface.
Compared to legacy FRTS, the MQC equivalent has some unique features, known as «Voice Adaptive Shaping» and «Voice Adaptive Fragmentation». The first feature activates adaptive shaping when packets are detected in the LLQ queue (if there is one configured) and the second feature activates fragmentation under the same condition of traffic present in the LLQ. The first feature is useful in oversubscription scenario, where you want to slow down from peak rate to committed rate when sending VoIP traffic to ensure better voice quality. The second feature is more useful, and allows you enabling traffic fragmentation only when it's really needed, i.e. when a voice calls is active.
Class Based Generic Traffic Shaping (CB-GTS)
The last method is based purely on MQC syntax using the generic commad shape average. In many senses, it's similar to the legacy GTS but uses newer syntax and supports more granular application. Have a look at the following example:
policy-map SHAPE_DLCI_101
class class-default
shape average 256000
!
! You can match DLCI's in class-maps
!
class-map DLCI_202
match fr-dlci 202
!
policy-map SHAPE_DLCI_202
!
policy-map INTERFACE_POLICY
class DLCI_202
service-policy SHAPE_DLCI_202
!
interface Serial 0/0
service-policy output INTERFACE_POLICY
!
interface Serial 0/0.1
frame-relay interface-dlci 101
service-policy output SHAPE_DLCI_101
The above example shows you two approaches to implementing VC-specific shaping. The first one uses a specific subinterface and the second one uses a class-map matching specific DLCI. The first method more reminds the legacy GTS, while the second allows pushing all VC policy under a single policy-map. Of course, you can always nest another MQC policy under a shaped class and implement CBWFQ and/or traffic marking/policing, just like you would do with any normal MQC configuration. FRF.12 fragmentation is also supported by means of the interface-level command frame-relay fragment, the same used with MQC FRTS.
Now for the CB-GTS limitation. There is a bunch, unfortunately. first of all, adaptive shaping does not work with CB-GTS i.e. the command shape average does not have any effect. Secondly, you may enable fragmentation at the interface level, but you cannot use any of MQC-based FRTS features, such as voice-adaptive fragmentation and shaping. Therefore, CB-GTS is not exactly a Frame-Relay Traffic Shaping solution, though it allows for generic shaping on per-VC basis.
Summary
As IOS software was evolving, multiple approaches to FRTS have been developed. Possibly the most commonly used one nowaday is Legacy FRTS, which supports practically all features with except to adaptive shaping/fragmentation availabled with MQC FRTS only. Even though from today's perspective MQC CB-GTS seems to be the most reasonable method, it does yet lack support of such important feature as adaptive shaping. It's up to you to select the best method, but be aware of their limitations.