Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco XR 12000 Series Router, Release 4.3.x
Modular QoS Deployment Scenarios
Downloads: This chapterpdf (PDF - 1.39MB) The complete bookPDF (PDF - 3.81MB) | Feedback

Modular QoS Deployment Scenarios

Modular QoS Deployment Scenarios

This module provides deployment scenarios use cases for specific QoS features or for QoS implementations of features that are described in other technology guides such as L2VPN or MPLS.

Feature History for QoS Deployment Scenarios on Cisco IOS XR Software

Release

Modification

Release 3.7.0

The VPLS QoS feature was introduced.

Release 3.8.0

The Qos on Multicast VPN feature was introduced.

Release 3.9.0

The ATM Layer 2 QoS feature was introduced.

The IP Header Compression QoS feature was introduced.

Release 4.0.1

ATM Layer 2 QoS support was added for Circuit Emulation over Packet Shared Port Adapters (CEoPs).

Ingress policing support was added for ATM AAL5SNAP, AAL5MUX, and AAL5NLPID encapsulated packets, for all 10 Gbps IP Services Engine (Engine 5) ATM SPAs.

ATM Layer 2 QoS

The following ATM Layer 2 QoS features are supported:

  • Layer 2 Ingress QoS – policing, marking, and queueing are supported
  • Layer 2 Egress Main Interface QoS – shaping, policing, and queueing are supported. 
Marking is not supported. This feature works on both Layer 2 and Layer 3 PVCs independent of any subinterface QoS policies.
  • The Modular QoS CLI (MQC) actions are supported for ATM traffic in the ingress direction only.
    • match atm clp
    • match atm oam
    • set atm clp
    • set mpls exp imp
    • set precedence tunnel (L2TPv3 only)
    • set dscp tunnel (L2TPv3 only)
  • Traffic is classified based on Cell Loss Priority–CLP1, CLP0, or OAM.
  • OAM traffic can be excluded from policing by using the match-oam classification in a hierarchical policy map
  • The following set actions are supported:
    • set mpls exp imp
    • set precedence tunnel
    • set dscp tunnel
    • set qos-group
    • set discard-class
    • set atm-clp (exceed action only)
  • Policy map counters are supported.

Matching

The following match criteria is supported on Layer 2 ATM interfaces in the ingress direction only:

  • match atm clp0
  • match atm clp1
  • match atm oam

The following match criteria is supported on Layer 2 ATM interfaces in the egress direction only:

  • match mpls exp topmost (egress only)
  • match qos-group (egress only)

    Note


    The match-all command does not support the above match criteria.


Marking

These marking actions are supported on Layer 2 ATM interfaces:

  • set mpls exp imposition (AToM only)
  • set qos-group (AToM and local switching)
  • set discard-class (AToM and local switching)
  • set mpls exp imposition and set atm-clp (AToM only)
  • set dscp tunnel (L2TPv3 only)
  • set precedence tunnel (L2TPv3 only)

    Note


    Packets can be matched and remarked for CLP0, CLP1, and OAM.


Policing

Policing is supported on Layer 2 ATM interfaces in the ingress direction only. Policing is performed during segmentation and reassembly (SAR) for the following ATM traffic classes:

  • CBR.1
  • VBR.1
  • VBR.2
  • VBR.3
  • UBR.1
  • UBR.2

Policing is supported for VC, VP, and Port mode L2 ATM interfaces.

OAM cells are policed along with user cells, unless the QOS policy is explicitly configured to exclude OAM cells from being policed. This can be achieved using different match criteria in the policy map. A specific class can be configured to match OAM cells, and the remaining traffic can be matched to the default class.

Policing is done on AAL0 packets with the same conditions as AAL5 packets as follows:

  • AAL5 packet is conforming if all the cells in the packet conform to PCR and SCR buckets.
  • AAL5 packet is exceeding if at least one cell does not conform to the SCR bucket.
  • AAL5 packet is violating if at least one cell does not conform to the PCR bucket.

    Note


    The Martini Control Word C bit is set for all exceeding AAL5 packets. All violating AAL5 packets are dropped.


The following policing options are supported for ATM TM4.0 GCRA policing:

  • Rate in cellsps and percent
  • Peak rate in cellsps and percent
  • Delay tolerance in us
  • Maximum burst size in cells

The following conform and exceed actions are supported for Layer 2 ATM interfaces in the ingress direction:

  • transmit
  • drop
  • set mpls exp imposition (AToM only)
  • set qos-group (AToM and Local switching)
  • set discard-class (AToM and Local switching)
  • set atm-clp (exceed action only, AToM and Local switching)
  • set precedence tunnel (L2TPv3 only)
  • set dscp tunnel (L2TPv3 only)

    Note


    The only violate action that is supported is the drop action.


The following combination of multiple policing actions is supported:

  • set mpls exp imposition and set atm-clp (exceed action only, AToM only)

Hierarchical Policy Maps

For VBR.2 and VBR.3 traffic classes, 2-level hierarchical policy maps are supported in the ingress direction only. Attempts to attach hierarchical policy maps in the egress direction are denied.

The parent policy contains the policing configuration for the PCR bucket and matches on all traffic. The parent policy may exclude OAM traffic.

The child policy contains the policing configuration for the SCR bucket and typically matches on CLP0 cells.

Marking actions are supported only in child policy maps. All other policing actions are allowed in parent policy maps.

Only two policing buckets per Layer 2 circuit are allowed; one in the parent policy that defines the peak rate, and one in the child policy that defines the SCR.

Typically CLP0 cells are sent to the SCR bucket, but it is possible to send both CLP0 and CLP1 cells to the SCR bucket, using the classification criteria in the child policy.


Note


For ATM Layer 2 QoS, in policy maps, the set atm-clp command is supported only as a police exceed action. It is not supported as a standalone set action.


Attaching a Service-Policy to an Attachment Circuit Configuration: Example

PVC Mode


config
   interface ATM 0/1/0/0.2 l2transport
      pvc 10/2
         service-policy input | output atm_policy_o

PVP Mode


config
   interface ATM 0/1/0/0.3 l2transport
      pvp 30
         service-policy input atm_policy_i

Port Mode


config
   interface ATM 0/1/0/0 
      l2transport 
         service-policy input atm_policy_i

Main Interface (non-port mode)


config
   interface ATM 0/1/0/0
      service-policy input | output atm_policy_o 

Policy Map Configuration for CBR/UBR: Example

For CBR.1 (real-time traffic) and UBR (best effort, non-real time traffic) you must specify the PCR and delay tolerance parameters for policing. The main difference between the configurations for UBR.1 and UBR.2 traffic is that for UBR.2 traffic, the exceed action includes the set-clp-transmit option to tag non-conforming cells. The police rate can also be expressed as a percentage.

The following example shows how to configure a QoS policy map for CBR/UBR:


policy-map CBR1
    class class-default
          police rate pcr cellsps delay-tolerance cdvt us 
               conform-action action 
               exceed-action action

Policy Map Configuration for VBR.1: Example

For VBR.1 real-time and non-real time traffic you must specify the PCR, SCR, and delay tolerance parameters for for policing. The atm-mbs parameter can be specified to define the burst allowed on the SCR bucket. The police rates can also be expressed as percentages. Class atm_clp1 is allowed with police actions.

The following example shows how to configure a QoS policy map for VBR.1:


policy-map VBR1
    class class-default
          police rate scr cellsps atm-mbs mbs cells peak-rate pcr cellsps delay-tolerance cdvt us 
               conform-action action  
               exceed-action action 

Policy Map Configuration for VBR.2 and VBR.3: Example

For VBR.2 and VBR.3 real-time and non-real time traffic you must specify the PCR, SCR, and delay tolerance parameters for policing. The atm-mbs parameter can be specified to define the burst allowed on the SCR bucket. The main difference between VBR.1 and VBR.2/VBR.3 is that the SCR bucket is for CLP0 cells only. The police rates can be expressed as percentages. The child policy can have other set actions and can match on ATM CLP1.

The following example shows how to configure a hierarchical policy for VBR.2:


policy-map child
    class atm_clp0
          police rate scr cellsps atm-mbs mbs cells 
               conform-action action  
               exceed-action action 

policy-map VBR2
    class class-default
          police rate pcr cellsps delay-tolerance cdvt us 
               conform-action action  
               exceed-action action 
      service-policy child

Policy Map Configuration to Exclude OAM Cells: Example

OAM cells can be excluded from being policed by configuring the classification criteria. Since match not is not supported, the different classes must be explicitly configured:.

The following example shows how to configure a policy map to exclude OAM cells:


class-map clp-0-1
 match clp 0
 match clp 1

policy-map child
    class atm-oam
        set
    class class-default
          police rate scr cellsps atm-mbs mbs cells
               conform-action action
               exceed-action action

policy-map VBR2
    class clp-0-1
          police rate pcr cellsps delay-tolerance cdvt us
               conform-action action
               exceed-action action
      service-policy child

Policy Map Configuration for Dual Queue Limit: Example

Dual Queue limit configuration is supported on egress L2 ATM interfaces to differentiate between CLP0 and CLP1 cells.


Note


For dual queue, only output service policies are supported. Input service policies are not supported.


The following example shows how to configure a policy map for Dual Queue Limit:


policy-map q-limit
    class class-default
        queue-limit atm-clp Threshold {[ms|us|cells]} Tail-drop-threshold {[ms|us|cells]}

Verifying ATM Layer 2 QoS Configuration: Examples

The following examples show how to display policing results for an ATM interface policy map:


show policy-map interface ATM 0/3/0/0.12 input 

ATM 0/3/0/0.12 input: pvc1

Class class-default
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :                 0/0               0
    Transmitted         :                 0/0               0
    Total Dropped       :                 0/0               0

show policy-map interface ATM 0/3/0/0.12 output 

ATM 0/3/0/0.12 output: pvc1

Class class-default
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :                 0/0               0
    Transmitted         :                 0/0               0
    Total Dropped       :                 0/0               0

The following examples show how to display the configured QoS properties for an ATM interface policy map:


show qos interface atm 0/3/0/0.12 input

Interface ATM0_3_0_0.12  --   Direction: input
Policy                 :   pvc1
Total number of classes:   1
Cell Packing Criteria = CELL_PACK_TIMER_MTU
---------------------------------------------------
LEVEL1 class: classid    =   0x1
class name               =   class-default
new exp                  =   6

show qos interface atm 0/3/0/0.12 output

Interface ATM0_3_0_0.12  --   Direction: output
Policy                 :   pvc1
Total number of classes:   1
Cell Packing Criteria = CELL_PACK_TIMER_MTU
---------------------------------------------------
LEVEL1 class: classid    =   0x1
class name               =   class-default
new exp                  =   6

IP Header Compression QoS

An IP Header Compression (IPHC) profile can be enabled on an interface so that the IPHC profile applies only to packets that match a QoS service policy. In this case, the QoS service-policy class attributes determine which packets are compressed. This allows users to fine tune IPHC with greater granularity.

Policy maps are attached to an interface using the service-policy command. IPHC action applies only to output service policies. IPHC is not supported on input service policies. (IPHC is supported in the input direction but there is no use case to configure IPHC in an input policy.)

You can configure IPHC using QoS as follows:

  • Create a QoS policy with the compress header ip action.
  • Attach the IPHC profile to the interface using the ipv4 iphc profile profile_name mode service-policy command.
  • Attach the QoS policy with compress header ip action using the service-policy output command.

You can also display IPHC statistics using the show policy-map interface command, as shown in the following example:


show policy-map interface Serial0/0/3/0/3:0 output

show policy-map int  Serial0/0/3/0/3:0  output
Mon May 18 22:06:14.698 UTC
Serial0/0/3/0/3:0 output: p1
Class class-default
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :                   0/0                    0
    Transmitted         :                   0/0                    0
    Total Dropped       :                   0/0                    0
  Queueing statistics
    Queue ID                             : 0
    High watermark  (Unknown)            : 0
    Inst-queue-len  (packets)            : 0
    Avg-queue-len   (packets)            : 0
    Taildropped(packets/bytes)           : 0/0
  Compression Statistics
    Header ip rtp
    Sent Total       (packets)           : 880
    Sent Compressed  (packets)           : 877
    Sent full header (packets)           : 342
    Saved            (bytes)             : 31570
    Sent             (bytes)             : 24750
    Efficiency improvement factor        : 2.27

IP Header Compression QoS: Example

In this example, IPHC is configured through QoS as an action under the class map using the compress header ip command.

The packets are classified according to the criteria in the class maps. The policy map specifies which behavior to apply to which classes. IPHC is enabled using the compress header ip action for the class. An IPHC profile with a QoS service policy is attached to a serial interface.


class-map match-all voice1
	 match precedence 2
class-map match-all voice2
	 match access-group acl_iphc

access-list acl_iphc permit udp any range lower-bound src udp port 5000 upper-bound src udp port15000 any lower-bound udp dst port 5000 upper-bound dst udp port 15000

ipv4 access-list acl_iphc permit udp any range 5000 15000 any range 5000 15000

policy-map iphc_policy
	class iphc_class_1
		compress header ip
	class iphc_class_2
		compress header ip

interface serial 0/1/0/1:1 
	ipv4 iphc profile Profile_3 mode service-policy 
		service-policy output iphc_policy

interface Serial 0/2/0/0/1/1/1:1
  ipv4 address 10.0.0.1 255.255.255.252
  ipv4 iphc profile Profile_3 mode service-policy
  service-policy output iphc_policy
  encapsulation ppp

QoS on Multicast VPN

QoS on Multicast VPN: Example

Supporting QoS in an mVPN-enabled network requires conditional and unconditional marking of the DSCP or precedence bits onto the tunnel header. Unconditional marking marks the DSCP or precedence tunnel as a policy action. Conditional marking marks the DSCP or precedence values on the tunnel header as a policer action (conform, exceed, or violate).

Unconditional Marking


class-map c1
  match vlan 1-10

policy-map p1
 class c1
  set precedence tunnel 3

Conditional Marking


policy-map p2
 class c1

  police rate percent 50
  conform action set dscp tunnel af11
  exceed action set dscp tunnel af12

VPLS and VPWS QoS

To support QoS on a virtual private LAN service (VPLS)-enabled network, packets can be classified based on these VPLS-specific match criteria:

  • Match on vpls known
  • Match on vpls unknown
  • Match on vpls multicast

  • Note


    VPLS-specific classification is performed only in the ingress direction. VPLS-specific and VPWS-specific classification are performed only in the ingress direction.


This example illustrates a typical VPLS topology with this configuration (in PE class c1):


class c1
  match vpls known
!
class c2
  match vpls unknown
!
class c3
  match vpls multicast
!
class c4
  match vpls broadcast
!
policy-map p1
  class c1
   set qos-group2
!
class c2
  set qos-group3
!
class c3
  set discard-class4
!
class c4
  set discard-class 5
!

VPLS and VPWS QoS: Example

In the VPLS-enabled network:

  • If a unicast packet arrives on the ingress interface of the PE router with a known MAC address (which means the destination MAC address of the packet is found in the MAC forwarding table), it matches class c1.
  • If a unicast packet arrives on the ingress interface of the PE router with an unknown MAC address (which means the destination MAC address of the packet is not found in the MAC forwarding table), it matches class c2.
  • If a VPLS multicast packet arrives on the ingress interface of the PE router, it matches class c3.

The packets that meet the VPLS-specific match criteria receive QoS treatment according to the policy actions defined in the policy.


Note


Packets with unknown destination MAC address, multicast packets, and broadcast packets are flooded.


VPLS QoS: Example

In this example, the packets that meet the VPLS-specific match criteria receive QoS treatment according to the policy actions defined in the policy. Apply the policy to the VPLS AC interface.

Related Information

The information in this module focuses on the QoS implementation of features that are described in other technology guides. This table indicates the guides where you can find more information about these features.

Feature

Guide

ATM Layer 2 QoS

Cisco IOS XR Interface and Hardware Component Configuration Guide for the Cisco XR 12000 Series Router

Cisco IOS XR Interface and Hardware Component Command Reference for the Cisco XR 12000 Series Router

IP Header Compression

Cisco IOS XR Interface and Hardware Component Configuration Guide for the Cisco XR 12000 Series Router

Cisco IOS XR Interface and Hardware Component Command Reference for the Cisco XR 12000 Series Router

QoS on Multicast VPN

Cisco IOS XR Multicast Configuration Guide for the Cisco XR 12000 Series Router

Cisco IOS XR Multicast Command Reference for the Cisco XR 12000 Series Router

VPLS QoS

Cisco IOS XR MPLS Configuration Guide for the Cisco XR 12000 Series Router

Cisco IOS XR MPLS Command Reference for the Cisco XR 12000 Series Router