This is the most well-known FRTS method, which has been available for quite a while on Cisco routers. It is now being outdated by MQC configurations.
The key characteristic is that all settings are configured under map-class command mode, and later are applied to a particular set PVCs. The
same configuration concept was used for legacy ATM configuration mode (map-class atm).
Legacy FRTS has the following characteristics:
- Enabled with frame-relay traffic-shaping command at physical interface level
- Incompatible with GTS or MQC commands at subinterfaces or physical interface levels
- With FRTS you can enforce bitrate per-VC (VC-granular, unlike GTS), by applying a map-class to PVC
- When no map-class is explicitly applied to PVC, it’s CIR and Tc are set to 56K/125ms by default
- Shaping parameters are configured under map-class frame-relay configuration submode
- Allows to configure fancy-queueing (WFQ/PQ/CQ) or simple FIFO per-VC
- No option to configure fancy-queueing at interface level: interface queue is forced to FIFO (if no FRF.12 is configured)
- Allows for adaptive shaping (throttling down to minCIR) on BECN reception (just as GTS) and option to reflect incoming FECNs as BECNs
- Option to enable adaptive shaping which responds to interface congestion (non-empty interface queue)
Example: Shape PVC to 384Kbps with minimal Tc (10ms) and WFQ as interface queue
map-class frame-relay SHAPE_384K frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 ! ! Adaptive shaping: respond to BECNs and interface congestion ! frame-relay adaptive-shaping becn frame-relay adaptive-shaping interface-congestion ! ! Per-VC fancy-queueing ! frame-relay fair-queue ! interface Serial 0/0/0:0 frame-relay traffic-shaping ! interface Serial 0/0/0:0.1 ip address 177.0.112.1 255.255.255.0 frame-relay interface-dlci 112 class SHAPE_384K
Verification: Check FRTS settings for the configured PVC
Rack1R1#show frame-relay pvc 112
PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)
DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0
cir 384000 bc 3840 be 0 byte limit 480 interval 10 <------ Shaping parameters
mincir 192000 byte increment 480 Adaptive Shaping BECN and IF_CONG <---- Adaptive Shaping enabled
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair <---- WFQ is the per-VC queue
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0
The other PVC, with no class configured, has CIR set to 56Kbps and uses FIFO as per-VC queue:
Rack1R1#show frame-relay pvc 113 PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE) DLCI = 113, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.2 cir 56000 bc 7000 be 0 byte limit 875 interval 125 <---- CIR=56K mincir 28000 byte increment 875 Adaptive Shaping none pkts 74 bytes 5157 pkts delayed 0 bytes delayed 0 shaping inactive traffic shaping drops 0 Queueing strategy: fifo <------------------ FIFO Output queue 0/40, 0 drop, 0 dequeued
Check the physical interface queue:
Rack1R1#show interfaces serial 0/0/0:0 | inc Queue Queueing strategy: fifo
- Interface queue could be changed to PIPQ (PVCs are assigned to 4 pririty groups, with PQ being physical interface queue)
- PIPQ stands for PVC Interface Priority queueing
Example: Map PVC 112 traffic to high interface queue, and PVC 113 to low interface queue, with WFQ being per-VC queueing
! ! Shape to 384K an assign to high interface level queue ! map-class frame-relay SHAPE_384K_HIGH frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 ! ! Per-VC fancy-queueing ! frame-relay fair-queue frame-relay interface-queue priority high ! ! Shape to 256k an assign to low interface level queue ! map-class frame-relay SHAPE_256K_LOW frame-relay cir 256000 frame-relay bc 2560 frame-relay be 0 ! ! Per-VC fancy-queueing ! frame-relay fair-queue frame-relay interface-queue priority low ! ! Enable PIPQ as interface queueing strategy ! interface Serial 0/0/0:0 frame-relay traffic-shaping frame-relay interface-queue priority ! interface Serial 0/0/0:0.1 ip address 177.0.112.1 255.255.255.0 frame-relay interface-dlci 112 class SHAPE_384K_HIGH ! interface Serial 0/0/0:0.2 ip address 177.0.113.1 255.255.255.0 frame-relay interface-dlci 113 class SHAPE_256K_LOW
Verfication: Check PVC interface-level priorities
Rack1R1#show frame-relay pvc 112
PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)
DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.1
cir 384000 bc 3840 be 0 byte limit 480 interval 10
mincir 192000 byte increment 480 Adaptive Shaping none
pkts 1687 bytes 113543 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0
priority high
^^^^^^^^^^^^^
Rack1R1#show frame-relay pvc 113
PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)
DLCI = 113, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.2
cir 256000 bc 2560 be 0 byte limit 320 interval 10
mincir 128000 byte increment 320 Adaptive Shaping none
pkts 1137 bytes 79691 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0
priority low
^^^^^^^^^^^^
Verify interface-level queue:
Rack1R1#show interfaces serial 0/0/0:0 | inc (Output|high)
Output queue (queue priority: size/max/drops):
high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0
- With FRF.12 fragmentation configured per any PVC, physical interface queue is changed to dual-FIFO
- This is due to the fact that fragmentation is ineffective without interleaving
- Fragment size is calculated based on physical interface speed to allow minimum serialization delay
Example: Enable FRF.12 fragmentation for PVC DLCI 112 and physical interface speed 512Kbps
! ! PVC shaped to 384Kbps, with physical interface speed 512Kbps ! map-class frame-relay SHAPE_384K_FRF12 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 ! ! Per-VC fancy-queueing ! frame-relay fair-queue ! ! Enable FRF.12 per VC. Fragment size = 512Kbps*0,01/8 = 640 bytes ! frame-relay fragment 640 ! ! ! interface Serial 0/0/0:0 frame-relay traffic-shaping ! interface Serial 0/0/0:0.1 ip address 177.0.112.1 255.255.255.0 frame-relay interface-dlci 112 class SHAPE_384K_FRF12
Verfication: Check PVC settings
Rack1R1#show frame-relay pvc 112
PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)
DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.1
fragment type end-to-end fragment size 640
cir 384000 bc 3840 be 0 limit 480 interval 10
mincir 192000 byte increment 480 BECN response no IF_CONG no
frags 1999 bytes 135126 frags delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0
Look at physical interface queue:
Rack1R1#show interfaces serial 0/0/0:0 | inc Queu|Output q Queueing strategy: dual fifo Output queue: high size/max/dropped 0/256/0 Output queue: 0/128 (size/max)
- You can map up to 4 priority queues to 4 different VCs (inverse PIPQ)
- This scenario usually implies multiple PVCs running between two sites (e.g. PVC for voice and PVC for data)
Example: Map voice packets to high interface-level priority queue and send them over PVC 112
! ! Voice bearer ! access-list 101 permit udp any any range 16384 32767 ! ! Simple priority list to classify voice bearer to high queue ! priority-list 1 protocol ip high list 101 interface Serial 0/0/0:0 ip address 177.1.0.1 255.255.255.0 ! ! We apply the priority group twice: first to implement queueing ! priority-group 1 ! ! Next to map priority levels to DLCIs ! frame-relay priority-dlci-group 1 112 112 113 113
Verfication:
Rack1R1#show queueing interface serial 0/0/0:0 Interface Serial0/0/0:0 queueing strategy: priority Output queue utilization (queue/count) high/217 medium/0 normal/1104 low/55 Rack1R1#show frame-relay pvc 112 PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE) DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0 pvc create time 3d01h, last time pvc status changed 3d01h Priority DLCI Group 1, DLCI 112 (HIGH), DLCI 112 (MEDIUM) DLCI 113 (NORMAL), DLCI 113 (LOW)
- You can change per-VC queue to CBWFQ/LLQ, and still shape with FRTS
- Note that available bandwidth will be calculated from minCIR value, which is CIR/2 by default
Example: Implement CBWFQ Per-VC
! ! Classify voice using NBAR ! class-map VOICE match protocol rtp ! ! Simple LLQ ! policy-map CBWFQ class VOICE priority 64 class class-default bandwidth 64 ! ! Use CBWFQ as queueing strategy ! Note that MinCIR = 384/2=192Kbps ! map-class frame-relay SHAPE_384K_CBWFQ frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 service-policy output CBWFQ ! ! ! interface Serial 0/0/0:0 frame-relay traffic-shaping ! interface Serial 0/0/0:0.1 ip address 177.0.112.1 255.255.255.0 frame-relay interface-dlci 112 class SHAPE_384K_CBWFQ
Verfication: Check PVC queueing strategy
Rack1R1#show frame-relay pvc 112
PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)
DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0
cir 384000 bc 3840 be 0 byte limit 480 interval 10
mincir 192000 byte increment 480 Adaptive Shaping none
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
service policy CBWFQ
Serial0/0/0:0: DLCI 112 -
Service-policy output: CBWFQ
Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol rtp
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
32 packets, 2560 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Output Queue: Conversation 41
Bandwidth 128 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Output queue size 0/max total 600/drops 0
To verify that only MinCIR of bandwidth is allocated to CBWFQ under map-class do the following:
Rack1R1(config)#policy-map CBWFQ Rack1R1(config-pmap)# class VOICE Rack1R1(config-pmap-c)# priority 64 Rack1R1(config-pmap-c)# class class-default Rack1R1(config-pmap-c)# bandwidth 192 I/f Serial0/0/0:0 DLCI 112 Class class-default requested bandwidth 192 (kbps) Only 128 (kbps) available
I want to know the definition of “fancy-queing”.I searched CCO ,but I could not faind it.
Does “fancy-queing” mean only WFQ/PQ/CQ as written above.
Thanks.
want to know the definition of “fancy Queing”.
I searched CCO and so on, but I could not find clearly.
Thanks
Fancy Queueing is a common name to the set of legacy queueing techniques, namely WFQ (Weighted Fair Queueing), PQ (Policy Queueing) and CQ (Custom Queueing)
Hi, firstly thanks for the great articles.
With regard to Frame-Relay fragmentation, I am confused as to why the physical interface speed would be used as the basis for fragment size rather than the CIR.
Consider a 128kbps circuit: On a leased line the fragment size required for 10ms delay would be 160 bytes, (128000 x 0.01 /
- no worries.
Now consider an (average) traffic shaped 64kpbs CIR on a 128kpbs access circuit where Tc is set to 10ms: Although the serialisation rate has a potential for serializing a 160 byte packet in 10ms, it will (I think) actually only serialize 80 bytes in 5ms and then remain ‘idle’ before transmitting another 80 bytes at the next Tc in order to obtain the shaped rate (64kpbs). If in this case the fragment size was set based on the access rate, 160 byte/128kpbs, then the potential delay for a waiting packet would (I think) be 20ms, not 10ms - Also the delay potential would worsen with any increase in difference between the CIR and access rate.
I hope my example makes sense.
Thanks
Danny
to: Danny
You are touching a very “delicate” topic here, related to “critical” behavior or shaping algorithm
First thing to note - packets are first shaped at VC level, then dequeued and only then fragemented.
Basically, a shaper is a “statistically behaving” system - that is, it demonstates the desired shaping rate only during some “runtime long enough” to exhibit the desired behavior :).
When we come to setting shaper’s speed to some really low values, we may face a problem: shaper’s token bucket size may become lower than the “quantum” size - that is, the average packet size (the same issues is often obeserved with Custom Queueing, where you need to set queue sizes in bytes).
The problem is as follows: if a packet is waiting to be send, and token bucket size is always lower than the packet size, we can logically end up waiting forever for packet to be send. This is due to the fact, that shaper’s behavior is “quantum” based, and packets are not infinitely divisible.
Handling such sort of issues is outside the “classical” shaping algorithm; some additional state tracking logics could be used to provide statistical fairness (like say keeping track of token bucket deficit) - these are implementation details. In any case, you could not guarantee yourself any determined shaping delay and, therefore, the desired QoS characteristics (though things may still work, thanks to some black voodoo magic and de-jitter buffers
In real life, try to make sure your token bucket size is always big enough to fit any “average” packet. You may set MTU settings small enough to guarantee the maximum “quantum” size, or make Tc a bigger value (which will surely affect voice quality). Or just make sure you do not mix voice and data on such slow circuits
Very interesting