Jan
22

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
About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

16 Responses to “Legacy Frame-Relay Traffic Shaping”

 
  1. mamitasu says:

    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.

  2. nike says:

    want to know the definition of “fancy Queing”.
    I searched CCO and so on, but I could not find clearly.

    Thanks

  3. Petr Lapukhov, CCIE #16379 says:

    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)

  4. Danny says:

    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 / 8) – 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

  5. Petr Lapukhov, CCIE #16379 says:

    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 :)

  6. Graham says:

    Very interesting

  7. Matt Hill says:

    So what is the best/easiest way to calculate the Bc and Be values?

    Bc = CIR/Tc?
    Be = ?

  8. Mitch says:

    what do you mean by “It is now being outdated by MQC configurations.”? I have a MPLS network with frame-relay circuits at the branches, would you still recommend me to use legacy FRTS or use MQC on the interface itself? Frame relay traffic shaping have caused issues on the MPLS network. thanks

  9. This simply means that the MQC simplifies the configuration logic of the legacy QoS mechanisms; also, there are certain features that are only supported in MQC vs. the legacy features.

    Additionally it depends on what version you are running. If you are running service provider trains, such as 12.0S or IOS XR, you’ll see limitations in the QoS feature set as compared with the Enterprise trains, such as Advanced Enterprise Services.

  10. Nick says:

    Hi Petr,

    Marvelous article as always!
    I have a question related to Danny’s question.
    Suppose we get a task which asks us to
    ensure that the maximum time it takes to transmit a packet across the Frame Relay network is 10ms.
    Physical speed is 1536 kbps, while CIR is 512 kbps.
    Would it still make sense to fragment based on physical rate?

    TIA,
    Nick

  11. AVINOL says:

    How can i do the following
    Configure frame realy traffic shaping .
    the routing protocols are not candidated to be shaped or droped
    CIR 512K , MinCIR 128K Other are default

  12. Pankaj Verma says:

    What if we don’t specify the map-class and still shaping is configured on the interface. I am facing an issue with this scenario. one user are able to access but as we keep on increasing the number of user it worsen.

    It means Default 56K is being shared by number of sessions ?

  13. Jesse says:

    Petr,

    In the begining of the article, you are stating the following:
    “No option to configure fancy-queueing at interface level: interface queue is forced to FIFO (if no FRF.12 is configured)”

    Then, you configure the following commands:

    “frame-relay interface-queue priority high” and
    “frame-relay interface-queue priority low” in two map-classes, respectively, and when using the “show interface serial 0/0/0:0″ command, you show the following output:
    “Output queue (queue priority: size/max/drops):
    high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0″

    Isn’t this “fancy queuing” at the interface level?

    • @Jesse

      that’s a well-known “hack” that FRTS uses to properly implement packet interleaving. It uses the 4-line priority queue, but only utilizes the High and the Normal queues. This queue is “forced” for the interface once you enable FRTS, and you cannot change it to any other queueing method.

      Petr

  14. Jesse says:

    Petr,

    Thanks for the explanation. One thing is unclear to me. You said that only High and Normal queues are utilized when PIPQ is configured. So, if I use the “frame-relay interface-queue priority low” command in the map-class called from within the DLCI configuration mode (like you did in the example below), will the traffic using that DLCI be queued into the Normal interface-level queue instead of the Low interface-level queue?

    Also, is it true that with the adoption of the HQF code in 12.4(20)T and later, the Dual FIFO queuing is no longer available even if FRF.12 is configured? If that is true, what would your suggestion be for interface-level queuing strategy if FRTS is continued to be used (instead of CBS) for Voice and Data.

 

Leave a Reply

Categories

CCIE Bloggers