Frame-Relay QoS Options

From: Petr Lapukhov (petrsoft@gmail.com)
Date: Wed Mar 29 2006 - 04:41:55 GMT-3


Hello Group,

FR QoS has been a long time pain in the neck for most of us :))
I tried to create a short summary of things I learned about FR QoS options.

Hope you find it useful, and of course, any kind of feedback is welcome! :)

Petr

Frame-Relay QoS Options

#1 Regulating traffic flow - shaping & policing:

    #1.1 GTS (legacy)

        - As usual GTS, works with WFQ shaper's queue.
        - Works per intf/subintf (no PVC granularity)
        - You can use adaptive keyword to adapt to BECNs, reflect as FECNs
            (As i understand, BECN received on any intf/subintf's PVCs
            will cause sending rate to fall down to minCIR)
             - You can use Fancy-queueing on interface with GTS.

    #1.2 FRTS (legacy)

        - Enforces rate per-VC (granular) - 56kbit 125ms default
        - FRTS parameters are configured under "map-class frame-relay"
                and require "frame-relay traffic-shaping" interface command
        - You can enable Fancy-queueing/FIFO per-VC
        - You can't enable Fancy-queueing at interface
        - Interface queue forced to FIFO (if no FRF.12)
        - Interface queue could be turned to PIPQ (PVCs
            are assigned to 4 pririty groups)
        - Interface queue forced to dual-FIFO (with FRF.12)
        - You can map 4 priority groups to 4 different VCs
        - You can turn per-VC queue to CBWFQ/LLQ, yet shape with FRTS
            (available queue bandwidth is calculated from minCIR/CIR)
            applied with "service policy" in "map-class frame-relay"

    #1.3 MQC FRTS (brand new)

        - No "frame-relay traffic-shaping" interface command required
        - Shaping is configure with MQC commands (shape average/adaprive),
            but you still use "map-class frame-relay" to apply it to DLCI
        - You can't use Fancy Queueing as per-VC queue, only CBWFQ/LLQ,
            as shaper's queue (hierarchical policy-maps config; available
            bandwidth is calculated from adaptive/average shape values).
        - You can't apply fragmentation in MQC config (hell i dunno why! :),
            you should apply it at interface level or at map-class.
        - Interface queue could be Fancy (not resticted to FIFO as with FRTS
legacy)
        - You can't enable dual FIFO on interface with MQC FRTS

    #1.4 FR Adaptive traffic shaping (backoff to minCIR)

        - BECN adaptive - works with GTS/FRTS/MQC
        - Voice adaptive (VATS): You can enable VATS only with MQC (no FRTS
support)
        - Intf congestion: You can enable this with MQC as well as with FRTS
        - VATS requires MQC shaping in VC's parent policy, and LLQ
configured in
            child policy

    #1.5 Policing (generic)

        - CAR (per interface/subinterface)
        - MQC policer (per-class, per-VC policing) - same as usual.
          One note - you can set DE as markdown option.

#2 Congestion Management:

Remember, to queue at subintf, you need to create a state of congestion
there,
either with FRTS legacy, or with MQC FRTS.

    - With no configuration applied, all VCs share single interface queue
    - FRTS enables per-VC queueing (+shaping the same time)
    - FRTS permits per-VC Fancy Queueing
    - FRTS permits mapping 4 priority groups to 4 different VCs
    - Legacy FRTS could force interface queue to FIFO/dual FIFO/PIPQ
    - With MQC FRTS you need to enable MQC shaping in parent policy,
      in order to engage CBWFQ/LLQ in child policy.
    - MQC FRTS could exist with fancy-queueing on interface
    - dual FIFO in turned on by FRF.12 configuration in map-class +
      FRTS legacy enable on interface (simple FIFO)
    - FRF.12 in map-class turns per-VC queue to WFQ
    - Simply enabling per-VC IP RTP Priority/LLQ does not turn interface
      queue to dual FIFO
     - You can tune FR broadcast queue separately on interface

#3 Classification & Marking

    - As usual, you can mark/classify with MQC
    - You can match DCLI in MQC class-map
    - MQC could be applied per-VC (with map-class)
    - MQC could be applied per-intf/subintf (with map-class or with
      service-policy, where you match dlci)
    - You can also mark with CAR (generic technique)
    - You can use markdown feature in MQC policer (generic technique)
    - You can set DE bit with legacy inteface commands per-VC
(de-list/group)
    - You can set DE bit with MQC (class-based)
    - You can set DE bit with MQC policer markdown

#4 Link Efficiency:

    Note, compression is performed before fragmentation

    #4.1 Fragmentation (FRF.12)

        - You can enable fragmentation with FRTS (per map-class)
          and apply it per-VC, per intrf/subintf
        - You can enable fragmentation at interface level
          (for all VCs) with FRTS legacy turned OFF
        - With interface-level fragmentation you can shape/queue
          only with MQC
        - When you turn on FRF.12 in map-class with FRTS, interface
          queue is forced to dual-FIFO
        - You can enable voice-adaptive fragmentation with FRTS or with MQC
        - To enable voice-adaptive fragmentation you need LLQ either within
          FRTS map-class, or configured with MQC
        - with FRF.12 and legacy FRTS you can only use WFQ/LLQ per-VC
        - Fragmentation is performed AFTER per-VC dequeueing
        - With dual FIFO unfragmented packets go to high-pririry queue

    #4.2 TCP header compression

        - TCP HC requires CISCO encapsulation on DLCI
        - You can tune specific dlci to use CISCO encapsulation
          with "frame-relay map"
        - TCP HC could be enabled per interfaces/subinterface/DLCI
        - TCP HC at interface prohibits the use of PQ/CQ at interface
        - TCP HC could be class-based with MQC configuration
        - TCP HC should be configured with frame-relay commands (not
generic)

    #2.3 RTP header compression

        - Configured with frame-relay commands (non-generic)
        - No IPHC/ECRTP support
        - Could be configured per-VC (with frame-relay map)
        - RTP hdr compression could be class-based (with MQC)

    #4.4 Payload compression

        - Three types of compression
        - Could be tuned per-VC or per-interface/subinterface
        - Cisco-proprietary types require cisco encapsulation (per-VC)

References:

Configuring FR
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/
ch05/index.htm

MQC FRTS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/
ch05/hfrqosmq.htm

LLQ for FRTS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t
/121t2/dtfrpqfq.htm

FR Fragmentation at interface
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/
ch05/hfrfrint.htm

VATS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/
ch05/h_vats.htm

Class-based header compression
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/
part30/ch10/qshdcmp4.htm

IP RTP header compression
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/
part30/ch10/qshdcmp2.htm



This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:40 GMT-3