Qos on cisco proprietary rpr – Cisco 15327 User Manual

Page 218

Advertising
background image

14-10

Ethernet Card Software Feature and Configuration Guide, R7.2

Chapter 14 Configuring Quality of Service

QoS on Cisco Proprietary RPR

Note

QoS and policing are not supported on the ML-Series card interface when link aggregation is used.

Note

Egress shaping is not supported on the ML-Series cards.

QoS on Cisco Proprietary RPR

For VLAN bridging over Cisco proprietary RPR , all ML-Series cards on the ring must be configured
with the base Cisco proprietary RPR and Cisco proprietary RPR QoS configuration. SLA and bridging
configurations are only needed at customer Cisco proprietary RPR access points, where IEEE 802.1Q
VLAN CoS is copied to the Cisco proprietary RPR CoS. This IEEE 802.1Q VLAN CoS copying can be
overwritten with a set-cos action command. The CoS commit rule applies at Cisco proprietary RPR ring
ingress.

If the packet does not have a VLAN header, the Cisco proprietary RPR CoS for non-VLAN traffic
is set using the following rules:

The default CoS is 0.

If the packet comes in with an assigned CoS, the assigned CoS replaces the default. If an IP packet
originates locally, the IP precedence setting replaces the CoS setting.

The input policy map has a set-cos action.

The output policy map has a set-cos action (except for broadcast or multicast packets).

The Cisco proprietary RPR header contains a CoS value and DE indicator. The Cisco proprietary RPR
DE is set for noncommitted traffic.

The ML-Series card Cisco proprietary RPR transit traffic, which is defined as traffic going from POS
port to POS port around the Cisco proprietary RPR , can only be classified by Layer 2 CoS. Other match
rules are ignored. This is a ML-Series card specific implementation of QoS on Cisco proprietary RPR
designed for the CoS based QoS model of the Cisco Metro Ethernet Solution.

This Layer 2 CoS dependence prevents DSCP-based output policy maps from working properly with
Cisco proprietary RPR on the ML-Series card. Using a DSCP based policy-map causes all transit traffic
to be incorrectly treated as class-default. This results in a discard of the transit traffic without any regard
for the DSCP priority when transit station congestion occurs.

The DSCP based output policy map limitation has a work around. Each Cisco proprietary RPR frame
has it's own three bit CoS marking, which is normally copied from the VLAN CoS. This is the field on
which "match cos" classification is done for transit Cisco proprietary RPR traffic. The Cisco proprietary
RPR CoS can be marked based on the DSCP match at the input station, and then classified based on the
Cisco proprietary RPR CoS at transit stations. This method can support a maximum of eight classes. If
you are using nine classes (including class-default), two of them would need to be combined to use this
work-around.

Example 14-1

shows a class and policy-map definition configuration that would overcome the DSCP

limitation. The example also changes nine classes into eight by combining the Voice and Call-Sig
classes.

Advertising