Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco XR 12000 Series Router, Release 4.1
Modular QoS Deployment Scenarios
Downloads: This chapterpdf (PDF - 230.0KB) The complete bookPDF (PDF - 1.31MB) | Feedback

Table of Contents

Modular QoS Deployment Scenarios on Cisco IOS XR Software

Contents

ATM Layer 2 QoS

Matching

Marking

Policing

Hierarchical Policy Maps

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

Policy Map Configuration for CBR/UBR: Example

Policy Map Configuration for VBR.1: Example

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

Policy Map Configuration to Exclude OAM Cells: Example

Policy Map Configuration for Dual Queue Limit: Example

Verifying ATM Layer 2 QoS Configuration: Examples

IP Header Compression QoS

IP Header Compression QoS: Example

QoS on Multicast VPN

QoS on Multicast VPN: Example

Unconditional Marking

Conditional Marking

VPLS QoS

VPLS QoS: Example

Related Information

Modular QoS Deployment Scenarios on Cisco IOS XR Software

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)

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


Marking

The following 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)

NotePackets can be matched and remarked for CLP0, CLP1, and OAM. 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.

NoteThe Martini Control Word C bit is set for all exceeding AAL5 packets. All violating AAL5 packets are dropped. 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)

NoteThe only violate action that is supported is the drop action. 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.


NoteFor ATM Layer 2 QoS, in policy maps, the 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.


NoteFor dual queue, only output service policies are supported. Input service policies are not supported. 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
 
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
 
 

QoS on Multicast VPN

The support for QoS services on a multicast VPN (mVPN) enabled network involves the marking of DSCP or precedence bits on the tunnel IP header. This feature enables MPLS carriers to offer QoS on mVPN services. The mVPN network uses generic routing encapsulation (GRE) tunnels between provider edge (PE) devices. Multicast packets are placed in GRE tunnels for transmission across the MPLS core network.

The ingress interfaces use the set precedence tunnel and set dscp tunnel commands (both conditional and unconditional) within an ingress policy applied to the ingress interface. shows a typical mVPN network. When an IP packet arrives at PE1 on the ingress interface E1, the packet is sent out of the tunnel interface E2 into the core network by encapsulating the IP packet inside a GRE tunnel.

Figure 1 mVPN Network

 

If the set dscp tunnel command or the set precedence tunnel command is configured on the ingress interface E1, the DSCP or precedence values are set in the GRE tunnel header of the encapsulated packet being sent out of the interface E2. As a result:

  • The set dscp command or the set precedence command (conditional or unconditional) marks the DSCP or precedence values within the IP header.
  • The set dscp tunnel or the set precedence tunnel command (conditional or unconditional) marks the DSCP or precedence values within the GRE header.

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 QoS

To support QoS on a virtual private LAN service (VPLS)-enabled network, packets are classified based on the following VPLS-specific match criteria:

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

NoteVPLS-specific classification is performed only in the ingress direction. VPLS-specific classification is performed only in the ingress direction.


Figure 2 illustrates a typical VPLS topology with the following configuration (in PE class c1):

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

Figure 2 VPLS Components

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.


NotePackets with unknown destination MAC address, multicast packets, and broadcast packets are flooded. 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.

class-map match-any c1
match vpls known
end-class-map
!
 
class-map match-any c2
match vpls unknown
end-class-map
!
 
class-map match-any c3
match vpls multicast
end-class-map
!
 
policy-map p2
class c1
set qos-group 3
set mpls experimental imposition 4
shape average percent 40
!
 
class c2
bandwidth remaining percent 10
set mpls experimental imposition 5
!
 
class c3
bandwidth remaining percent 10
set mpls experimental imposition 7
!
 
class class-default
!
end-policy-map
!

Related Information

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

Table 1 Related Information

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