7210 SAS Quality of Service7210 SAS-K 2F2T1C7210 SAS-K 2F4T6CRelease
9.0.R8
7210 SERVICE ACCESS SWITCH
7210 SAS Quality of Service
7210 SAS-K 2F2T1C
7210 SAS-K 2F4T6C
Release 9.0.R8
3HE12057AAAJTQZZA
Issue: 01
November 2017
Nokia — Proprietary and confidential.
Use pursuant to applicable agreements.
Page 2
Nokia is a registered trademark of Nokia Corporation. Other products and company
names mentioned herein may be trademarks or tradenames of their respective
owners.
The information presented is subject to change without notice. No responsibility is
assumed for inaccuracies contained herein.
Contains proprietary/trade secret information which is the property of Nokia and must
not be made available to, or copied or used by anyone outside Nokia without its
written authorization. Not to be used or disclosed except in accordance with
applicable agreements.
About This Guide................................................................................................................................................15
List of Technical Publications ........................................................................................................................15
In This Chapter ...................................................................................................................................................17
Nokia 7210 SAS-Series Services Configuration Process...................................................................................17
In This Chapter ...................................................................................................................................................19
Queue – support on various platforms .....................................................................................................50
Meter/Policers and Policer Parameters.........................................................................................................51
Meter - Meter ID .......................................................................................................................................51
Meter - Committed Information Rate ........................................................................................................52
Meter - Peak Information Rate .................................................................................................................52
Meter - Adaptation Rule for Meters ..........................................................................................................53
Meter - Committed Burst Size ..................................................................................................................54
Meter – Maximum Burst Size ...................................................................................................................54
Meter – Ingress Profile Assignment .........................................................................................................54
Meter Counters ........................................................................................................................................56
Meter Modes ............................................................................................................................................56
Meter - QoS Override ...............................................................................................................................56
Meter QoS Override - Configuring Meter Override parameters ...............................................................57
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide3
Page 4
Table of Contents
Meter – support on various platforms.......................................................................................................57
Service Ingress QoS Policies .......................................................................................................................57
Default Service Ingress Policy .................................................................................................................59
Service Ingress Classification .......................................................................................................................60
Service Ingress Classification .................................................................................................................60
Service Ingress Classification– IP and Mac Packet fields........................................................................61
Service Egress QoS Policies ........................................................................................................................63
Default Service Egress Policy .................................................................................................................64
RED Slopes...................................................................................................................................................70
Operation and Configuration of RED Slopes ...........................................................................................70
Simplified overview of RED for 7210 SAS-K platform ..............................................................................71
Scheduler on 7210 SAS-K ............................................................................................................................73
CPU Queues on SAS-K......................................................................................................................................74
Egress Port Rate Limiting...................................................................................................................................74
Forwarding-Class To Queue ID Mapping ......................................................................................................76
FC to Queue ID mapping ..............................................................................................................................76
Preclassification on 7210 SAS-K 2F4T6C..........................................................................................................76
Discard Eligibility Indicator (DEI) based Classification and Marking.............................................. 79
In This Section....................................................................................................................................................79
DEI based Classification and Marking ...............................................................................................................79
DEI based Classification on 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C ..............................................79
DEI based marking .......................................................................................................................................80
Port Level Egress Rate-Limiting ......................................................................................................... 81
In This Section....................................................................................................................................................81
In This Section....................................................................................................................................................89
In This Section....................................................................................................................................................97
In This Section..................................................................................................................................................109
Overview of Network QoS policy on 7210 SAS-K 2F2T1C .............................................................................109
Resource Allocation for Network QoS policy for 7210 SAS-K 2F2T1C ......................................................111
Service Management Tasks .............................................................................................................................129
In This Section..................................................................................................................................................157
Default Network Queue policy for 7210 SAS-K 2F2T1C .................................................................................160
Default Network Queue policy for 7210 SAS-K 2F4T6C ..................................................................................162
Service Management Tasks .............................................................................................................................164
67210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 7
Table of Contents
Show Commands...................................................................................................................................175
Service Ingress QoS Policies ............................................................................................................ 179
In This Section..................................................................................................................................................179
Overview of Service Ingress Policy .................................................................................................................179
Configuration Guidelines for SAP Ingress Policy .......................................................................................180
Resource Allocation for Service Ingress QoS classification policy.........................................................181
Resource allocation for SAP ingress meters..........................................................................................183
Default SAP Ingress Policy ...................................................................................................................183
SAP Ingress Policy Defaults ..................................................................................................................184
Use of Index file by SAP QoS Ingress policy .........................................................................................185
Create Service Ingress QoS Policies .........................................................................................................185
Service Ingress QoS Policy of 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C ........................................186
Service Ingress QoS Queues for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C ....................................186
Service Ingress QoS Meters for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C......................................187
SAP Ingress Forwarding Class Configuration for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C ...........187
Service Ingress Dot1p and IP DSCP Criteria ..............................................................................................189
Service Ingress IP Match Criteria ...............................................................................................................190
Service Ingress MAC Match Criteria ..........................................................................................................190
Applying Service Ingress Policies .........................................................................................................191
Service Management Tasks ............................................................................................................................192
Service Ingress QoS Policy Commands ................................................................................................206
Service Ingress QoS Policy Entry Commands .......................................................................................214
Service Ingress MAC QoS Policy Match Commands.............................................................................218
SAP Ingress Queue and meter QoS Policy Commands ........................................................................222
Show Commands ........................................................................................................................................229
Service Egress Policies .................................................................................................................... 237
In This Section..................................................................................................................................................237
In This Section..................................................................................................................................................257
In This Section..................................................................................................................................................261
Overview of Buffer pools and Slope policies ...................................................................................................261
RED Slope Commands ..........................................................................................................................275
Show Commands...................................................................................................................................277
Remark Policies for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C .............................................. 281
In This Section..................................................................................................................................................281
Remark Policy Forwarding Class Commands........................................................................................296
Show Commands ........................................................................................................................................301
Table 5Default Network QoS policy ID #2 - ingress classification map - Dot1p Mapping to forwarding class
37
Table 6Default Network QoS policy mpls-lsp-exp-classification to FC Mapping .......................................38
Table 7Default Network QoS policy dscp-classification to FC Mapping ....................................................38
Table 8Default Network QoS policy Dot1p to FC Mapping for network egress .........................................40
Table 9Default Network QoS policy Dot1p to FC Mapping for network ingress ........................................41
Table 10Default Network Queue Policy Definition on 7210 SAS-K2F2T1C and 7210 SAS-K2F4T6C. ......42
Table 11Default Service Ingress Policy ID 1 Definition for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C59
Table 12Service Ingress QoS Policy IP Match Criteria for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C61
Table 13Service Ingress QoS Policy IPv6 Criteria for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C.....62
Table 14Service Ingress QoS Policy MAC Match Criteria for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C
62
Table 15MAC Match Ethernet Frame Types ...............................................................................................63
Table 16MAC Match Criteria Frame Type Dependencies .........................................................................63
Table 17Default Service Egress Policy ID 1 Definition ................................................................................65
Table 18Default slope policy definition for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C.......................73
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide13
Page 14
List of Tables
Remark Policies for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C .............................................. 281
Table 29Summary of remark policy and attachment points for 7210 SAS-K 2F2T1C ..............................282
Table 30Summary of remark policy and attachment points for 7210 SAS-K 2F4T6C ..............................285
147210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 15
About This Guide
This guide describes Quality of Service (QoS) provided by the 7210 SAS-D, 7210 SAS-E,
7210 SAS-K 2F2T1C, and 7210 SAS-K 2F4T6C platforms and presents examples to
configure and implement various tests and presents examples to configure and implement
various protocols and services.
On 7210 SAS devices, not all the CLI commands are supported on all the platforms and in all
the modes. In many cases, the CLI commands are mentioned explicitly in this document. In
other cases, it is implied and easy to know the CLIs not supported on a particular platform.
This document is organized into functional chapters and provides concepts and descriptions
of the implementation flow, as well as Command Line Interface (CLI) syntax and command
usage.
Preface
Audience
This manual is intended for network administrators who are responsible for configuring the
7210 SAS-Series routers. It is assumed that the network administrators have an understanding
of networking principles and configurations. Protocols, standards, and services described in
this manual include the following:
•CLI concepts
•Quality of Service (QoS) policies and profiles
List of Technical Publications
The 7210 SAS-D, 7210 SAS-E, 7210 SAS-K 2F2T1C, and 7210 SAS-K 2F4T6C OS
documentation set is composed of the following books:
•7210 SAS-D, 7210 SAS-E, 7210 SAS-K 2F2T1C, and 7210 SAS-K 2F4T6C OS
Basic System Configuration Guide
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide15
Page 16
About This Guide
•This guide describes basic system configurations and operations.
•7210 SAS-D, 7210 SAS-E, 7210 SAS-K 2F2T1C, and 7210 SAS-K 2F4T6C OS
System Management Guide
•This guide describes system security and access configurations as well as event
logging and accounting logs.
•7210 SAS-D, 7210 SAS-E, 7210 SAS-K 2F2T1C, and 7210 SAS-K 2F4T6C OS
Interface Configuration Guide
•This guide describes card, Media Dependent Adapter (MDA), link aggregation group
(LAG), and port provisioning.
•7210 SAS-D, 7210 SAS-E, 7210 SAS-K 2F2T1C, and 7210 SAS-K 2F4T6C OS
Router Configuration Guide
•This guide describes logical IP routing interfaces and associated attributes such as an
IP address, port, as well as IP and MAC-based filtering.
•7210 SAS-D and 7210 SAS-E OS Services Guide
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS Services Guide
•This guide describes how to configure service parameters such as customer
information, and user services.
•7210 SAS-D, 7210 SAS-E, 7210 SAS-K 2F2T1C, and 7210 SAS-K 2F4T6C OS
OAM and Diagnostic Guide
•This guide describes how to configure features such as service mirroring and
Operations, Administration and Management (OAM) tools.
•7210 SAS-D and 7210 SAS-E OS Quality of Service Guide
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS Quality of Service Guide
•This guide describes how to configure Quality of Service (QoS) policy management.
•7210 SAS-K 2F4T6C OS MPLS Guide
This guide describes how to configure Multiprotocol Label Switching (MPLS) and
Label Distribution Protocol (LDP).
•7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C
This guide provides an overview of routing concepts and provides configuration
examples for OSPF, IS-IS and route policies.
OS Routing Protocols Guide
167210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 17
Getting Started
In This Chapter
This chapter provides process flow information to configure Quality of Service (QoS)
policies and provision services.
Nokia 7210 SAS-Series Services Configuration
Process
Table 1 lists the tasks necessary to configure and apply QoS policies. This guide is presented
in an overall logical configuration flow. Each section describes a software area and provides
CLI syntax and command usage to configure parameters for a functional area.
Table 1: Configuration Process
AreaTaskChapter
Policy configurationConfiguring QoS Policies
Egress RatePort Level Egress Rate-Limiting
Accounting ModeFrame-based Accounting
NetworkNetwork QoS Policies
Network queueNetwork Queue QoS Policies
Service Ingress Service Ingress QoS Policies
Service EgressService Egress Policies
SchedulersSchedulers
Remark PoliciesRemark Policies for 7210 SAS-K
2F2T1C and 7210 SAS-K 2F4T6C
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide17
Page 18
Nokia 7210 SAS-Series Services Configuration Process
Table 1: Configuration Process (Continued)
AreaTaskChapter (Continued)
ReferenceList of IEEE, IETF, and other
proprietary entities
Standards and Protocol Support
187210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 19
In This Chapter
This chapter provides information about Quality of Service (QoS) policy management.
Topics in this chapter include:
•QoS Overview
→ Overview of QoS Policies on 7210 SAS-K 2F2T1C
→ Overview of QoS Policies on 7210 SAS-K 2F4T6C
→ QoS Marking Interpretation
→ Summary of Major Functions of QoS Policies
QoS Policies
→ Network QoS Policies
→ Network QoS Policies on Access-uplink Ports
→ Network Queue Policies
→ Queues and Queue Parameters
→ Meter/Policers and Policer Parameters
→ Service Ingress QoS Policies
→ Service Ingress Classification
→ Service Egress QoS Policies
→ Buffer Pools
→ Slope Policies
→ RED Slopes
•Schedulers
→ Scheduler on 7210 SAS-K
•CPU Queues on SAS-K
•Egress Port Rate Limiting
•Forwarding Classes
→ Forwarding-Class To Queue ID Mapping
→ FC to Queue ID mapping
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide19
Page 20
QoS Overview
•Preclassification on 7210 SAS-K 2F4T6C
•QoS Policy Entities
•Configuration Notes
QoS Overview
The 7210 SAS devices are designed with QoS mechanisms on both ingress and egress to
support multiple services per physical port. The 7210 SAS devices are extensive and flexible
capabilities to Classify, Policy, Queue, Shape, and mark traffic.
Note: The QoS capabilities supported on different 7210 SAS platforms are different. In other
words, not all the platforms support all of the capabilities. Please read through the following
chapters to know what is available on different 7210 SAS platforms.
In the Nokia service router’s service model, a service is provisioned on the provider-edge
(PE) equipment. Service data is encapsulated and then sent in a service tunnel (for example:
QinQ tunnel, Dot1q tunnel, IP/MPLS tunnel, etc.) to the far-end Nokia service router where
the service data is delivered.
The operational theory of a service tunnel is that the encapsulation of the data between the
two Nokia service routers appear like a Layer 2 path to the service data although it is really
traversing an QinQ or IP or IP/MPLS core. The tunnel from one edge device to the other edge
device is provisioned with an encapsulation and the services are mapped to the tunnel that
most appropriately supports the service needs.
The 7210 SAS supports eight forwarding classes internally named: Network-Control, High1, Expedited, High-2, Low-1, Assured, Low-2 and Best-Effort. The forwarding classes are
discussed in more detail in .
7210 SAS devices use QoS policies to control how QoS is handled at distinct points in the
service delivery model within the device. There are different types of QoS policies that cater
to the different QoS needs at each point in the service delivery model. QoS policies are
defined in a global context in the 7210 SAS and only take effect when the policy is applied
to a relevant entity.
QoS policies are uniquely identified with a policy ID number or name. Typically, Policy ID
1 or Policy ID “default” (there are a few instances where the default QoS policy uses a
different ID) is reserved for the default policy which is used if no policy is explicitly applied.
The QoS policies within the 7210 SAS can be divided into three main types:
207210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 21
•Policies are used for classification, defining metering and queuing attributes and
defining marking behavior.
•Slope policies define default buffer allocations and WRED slope definitions.
•Port Scheduler policies, SAP ingress/egress policies and network/network-queue
policies determine how queues are scheduled.
Overview of QoS Policies on 7210 SAS-K 2F2T1C
On 7210 SAS-K2F2T1C, QoS policies are applied on service ingress, service egress and
access uplink ports (ingress and egress) and define the following:
•Classification rules for how traffic is mapped to forwarding classes.
•Forwarding class association with queues.
•Queue parameters for shaping, scheduling and buffer allocation.
•Option to associate forwarding class with meters/policers and configure meter
parameters for enforcing rate and control burst.
QoS Policies
•QoS marking in the packet header.
There are several types of QoS policies:
•Service ingress (for access SAP ingress).
•Service egress (for access SAP egress).
•Network (for access-uplink port ingress and egress).
•Network queue (for access-uplink port egress).
•Slope policies (for all queues).
•Remark policies (for both access SAP egress and access-uplink port egress).
•Dot1p and DSCP classification policies (for access SAP ingress and access-uplink
port ingress).
Service ingress QoS policies are applied to the customer-facing Service Access Points (SAPs)
on access ports. Traffic that enters through the access SAP is classified to map it to a
Forwarding Class (FC) and the user has an option to also assign a profile on SAP ingress. A
forwarding class can be associated with either queues or policer/meter on service ingress. In
other words, service ingress forwarding class can be configured to use queue or a meter
allowing for some forwarding classes to use queues and some others to use meters. When the
forwarding class is associated with a queue on access SAP ingress (also known as service
ingress), the profile determines the enqueing priority for the packet, with in-profile packets
having a higher chance of getting a buffer, than out-of-profile packets. The mapping of traffic
to forwarding class/queues can be based on combinations of customer QoS marking in the
packet header (for example: IEEE 802.1p bits, IP DSCP bits, MAC address, etc). The
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide21
Page 22
QoS Overview
characteristics of the forwarding class queues are defined within the policy as to the number
of forwarding class queues to use for unicast traffic and BUM (Broadcast, Unknown-unicast,
and Multicast) traffic along with the queue rate and buffer parameters (like CIR, PIR, CBS,
MBS). Each of the forwarding classes can be associated with different parameters for unicast
traffic and different parameters for multi-point (that is, BUM) traffic. A service ingress QoS
policy defines up to 8 queues per policy, with up to 2 queues (that is, Unicast Queue Mapping
and Multicast Queue Mapping) per forwarding class. Unicast and multi-point traffic can be
mapped to use the same queue or mapped to use different queues per forwarding class with a
maximum of up to 2 queues per forwarding class, one each for unicast and for multicast
traffic. In the case of VPLS service, four types of forwarding are supported (which is not to
be confused with forwarding classes), unicast, multicast, broadcast, and unknown. Multicast,
broadcast, and unknown types are flooded to all destinations within the service while the
unicast forwarding type is handled in a point-to-point fashion within the service. Multicast,
broadcast, and unknown traffic types use the same multicast-queue mapping defined for
forwarding class. In other words, a separate queue for multicast, broadcast, and unknown
unicast traffic types cannot be defined.
Service ingress policies provide an option to use a policer per forwarding class, instead of a
queue. It allows users to classify low-latency less bursty traffic on service ingress to a
forwarding class and use a policer to enforce rate. When a forwarding class is associated with
policer on access SAP ingress, the profile determines the ingress color for the packet. It
allows in-profile (green) packets to use the available tokens from the CIR rate first while outof-profile packets use available tokens from the PIR rate first. Thus user can prioritize inprofile packets over out-profile packets by ensuring that CIR rate is available for in-profile
service ingress packets. The mapping of traffic to forwarding class meter can be based on
combinations of customer QoS marking in the packet header (for example: IEEE 802.1p bits,
IP DSCP bits, MAC address, etc). The characteristics of the forwarding class policer are
defined within the policy as to the number of forwarding class meter to use for unicast traffic
and BUM (Broadcast, Unknown-unicast, and Multicast) traffic along with the policer rate
(like CIR, PIR) and burst parameters (like CBS, MBS). Each of the forwarding classes can
be associated with different parameters for unicast traffic and different parameters for
multipoint (that is, BUM) traffic. A service ingress QoS policy defines up to 16 meters per
policy, with up to 2 meters per forwarding class. Unicast and multi-point traffic can be
mapped to use the same policer or mapped to use different policer per forwarding class with
a maximum of up to 2 policer per forwarding class, one each for unicast and for multicast
traffic. In the case of VPLS service, four types of forwarding are supported (which is not to
be confused with forwarding classes), unicast, multicast, broadcast, and unknown. Multicast,
broadcast, and unknown types are flooded to all destinations within the service while the
unicast forwarding type is handled in a point-to-point fashion within the service. Multicast,
broadcast, and unknown traffic types use the same multicast meter mapping defined for
forwarding class. In other words, a separate meter for multicast, broadcast, and unknown
unicast traffic types cannot be defined.
227210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 23
QoS Policies
Service ingress QoS policy also provides an option to configure a mix of meters and queues
per policy and per forwarding class. In other words, it is possible to use a queue for one of the
forwarding class used to forward bursty traffic while using a meter for another forwarding
class used to forward low-latency traffic. In addition, it is possible to configure a queue for
unicast traffic type while using a meter for BUM traffic types or vice-versa.
On service ingress when a combination of queues and meters are used, option is available to
configure the service ingress aggregate rate for queues and meters individually. In other
words, the service ingress aggregate policer rate enforces the rate across all the forwarding
class meters configured in the SAP while the service ingress aggregate shaper rate enforces
the rate across all the forwarding class queues configured in the SAP.
Service egress QoS policies are applied to SAPs and map forwarding classes to service egress
queues for a service. The system can allocate a maximum of 8 queues per SAP for the 8
forwarding classes. All traffic types (that is, both unicast and BUM traffic types) share the
same queue on service egress. A service egress QoS policy defines the forwarding class
queue characteristics and also defines how to remark the forwarding class to priority bits in
the packet header (for example: IEEE 802.1p bits in the Ethernet VLAN tag) in the customer
traffic.
Network QoS policies are applied to access uplink ports. Access-uplink ports are typically
used to connect to the core network and forward customer traffic towards the core network.
A network QoS policy defines both ingress and egress behavior. On access-uplink port
ingress, traffic that enters through the access-uplink port is classified to map it to a forwarding
Class and the user has an option to assign a profile. Forwarding class is associated with
ingress queues on access uplink port ingress and the profile determines the enqueing priority
for the packet, with in-profile packets have a higher chance of getting the buffer, than out-ofprofile packets. The mapping of traffic to forwarding class queues is based on QoS marking
(for example: IEEE 802.1p bits, IP DSCP bits). The characteristics of the forwarding class
ingress queues are defined within the policy as to the number of forwarding class queues for
unicast traffic type and BUM (Broadcast, Unknown-unicast, and Multicast) traffic type,
along with the queue rate and buffer parameters (like CIR, PIR, CBS, MBS, etc.). Each of the
forwarding classes can be associated with different ingress and ingress queue parameters for
unicast traffic type and for multi-point (that is, BUM) traffic type. A network QoS policy
defines up to 8 ingress queues per policy, with up to 2 ingress queues per forwarding class.
Unicast and multi-point traffic can be defined to use the same queue or different ingress
queues per forwarding class. In the case of VPLS service, four types of forwarding are
supported (which is not to be confused with forwarding classes), unicast, multicast,
broadcast, and unknown. Multicast, broadcast, and unknown types are sent to multiple
destinations within the service while the unicast forwarding type is handled in a point-topoint fashion within the service. All these traffic types use the same queue (in other words, a
separate queue for multicast, broadcast, and unknown unicast traffic types cannot be defined).
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide23
Page 24
QoS Overview
On access-uplink port egress, the policy maps forwarding class and profile state to Dot1p and
/or IP DSCP values for traffic to be transmitted out of the access-uplink port. All the accessuplink SAPs configured on the same access-uplink port use the same policy and the same set
of forwarding class queues. In other words, traffic received and transmitted through all the
access-uplink SAPs configured on a given access-uplink port receive similar QoS treatment.
Network queue policies are applied on egress of access uplink ports and map forwarding
classes to network egress queues on access uplink ports. The system allocates 8 egress queues
per access-uplink port for the 8 forwarding classes. The policy defines the forwarding class
queue characteristics (that is, CIR, PIR, CBS, MBS, etc.). All traffic types (that is, both
unicast and BUM traffic types) share the same queue on access-uplink port egress. All the
access-uplink SAPs configured on the same access-uplink port use the same policy and the
same set of forwarding class queues. In other words, traffic transmitted through all the accessuplink SAPs configured on a given access-uplink port receive similar QoS treatment.
Slope policies are applied to service ingress queues, service egress queues, access uplink port
ingress, queues, and access uplink port egress queues. Each of these queuing points allocates
buffers from the buffer pool and implements WRED for congestion management. During
congestion WRED is used to evaluate how buffers from the pool are allocated to different FCs
and to in-profile and out-of-profile traffic within a given FC. The slope policies define the
WRED parameters to use for in-profile/high-priority packets and for out-of-profile/lowpriority packets. The high-slope and low-slope define the parameters for in-profile/highpriority packets and for out-of-profile/low-priority packets respectively. In addition, 7210
SAS-K introduces the concept of ring and non-ring ports with an option for preferential
allocation of traffic for ring ports. The system by default treats access-uplink ports as ring
ports.
Remark policies are applied to access SAP egress and access-uplink port egress. They are not
directly associated with the SAP and access-uplink port egress. Instead they are associated
with service egress policy and network qos policy. They define the forwarding class and
profile to egress marking values (for example: IEEE 802.1p bits in the Ethernet VLAN tag)
to use.
Dot1p classification and DSCP classification allows user to define the map of Dot1p bits and
IP DSCP values to forwarding class and assign the profile for the packet on access SAP
ingress and access-uplink port ingress.
One service ingress QoS policy and a single service egress QoS policy can be applied to a
specific access SAP. One network QoS can be applied to a specific access-uplink port. One
network queue policy can be applied to the access uplink port. If no QoS policy is explicitly
applied to a SAP or port, a default QoS policy is applied.
247210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 25
Overview of QoS Policies on 7210 SAS-K 2F4T6C
On 7210 SAS-K2F4T6C QoS policies are applied on service ingress, service egress and
access uplink ports (ingress and egress) and define the following:
•Classification rules for how traffic is mapped to forwarding classes.
•Forwarding class association with queues.
•Queue parameters for shaping, scheduling and buffer allocation.
•Option to associate forwarding class with meters/policers and configure meter
parameters for enforcing rate and control burst.
•QoS marking in the packet header.
QoS Marking Interpretation
There are several types of QoS policies:
QoS Policies
•Service ingress (for access SAP ingress)
•Service egress (for access SAP egress)
•Network (for access-uplink port ingress and egress and network port ingress and
egress)
•Network queue (for access-uplink port egress and network port egress)
•Slope policies (for all queues)
•Remark policies (for both access SAP egress, access-uplink port egress and network
port egress)
•Dot1p, IP DSCP and MPLS EXP classification policies (for access SAP ingress,
access-uplink port ingress and network port ingress) Please note, that MPLS EXP
classification policies are only for network ports.
Service ingress QoS policies are applied to the customer-facing Service Access Points (SAPs)
on access ports. Traffic that enters through the SAP is classified to map it to a Forwarding
Class (FC) and the user has an option to also assign a profile on SAP ingress. A forwarding
class can be associated with either queues or policer/meter on service ingress. In other words,
service ingress forwarding class can be configured to use queue or a meter allowing for some
forwarding classes to use queues and some others to use meters. When the forwarding class
is associated with a queue on access SAP ingress (also known as service ingress), the profile
determines the enqueing priority for the packet, with in-profile packets having a higher
chance of getting a buffer, than out-of-profile packets. The mapping of traffic to Forwarding
class/queues can be based on combinations of customer QoS marking in the packet header
(for example: IEEE 802.1p bits, IP DSCP bits, MAC address, etc.). The characteristics of the
forwarding class queues are defined within the policy as to the number of forwarding class
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide25
Page 26
QoS Overview
queues to use for unicast traffic and BUM (Broadcast, Unknown-unicast, and Multicast)
traffic along with the queue rate and buffer parameters (like CIR, PIR, CBS, MBS). Each of
the forwarding classes can be associated with different parameters for unicast traffic and
different parameters for multi-point (that is, BUM) traffic. A service ingress QoS policy
defines up to 8 queues per policy, with up to 2 queues (that is, Unicast Queue Mapping and
Multicast Queue Mapping) per forwarding class. Unicast and multi-point traffic can be
mapped to use the same queue or mapped to use different queues per forwarding class with a
maximum of up to 2 queues per forwarding class, one each for unicast and for multicast
traffic. In the case of VPLS service, four types of forwarding are supported (which is not to
be confused with forwarding classes), unicast, multicast, broadcast, and unknown. Multicast,
broadcast, and unknown types are flooded to all destinations within the service while the
unicast forwarding type is handled in a point-to-point fashion within the service. Multicast,
broadcast, and unknown traffic types use the same multicast-queue mapping defined for
forwarding class. In other words, a separate queue for multicast, broadcast, and unknown
unicast traffic types cannot be defined.
Service ingress policies provide an option to use a policer per forwarding class, instead of a
queue. It allows users to classify low-latency less bursty traffic on service ingress to a
forwarding class and use a policer to enforce rate. When a forwarding class is associated with
policer on access SAP ingress, the profile determines the ingress color for the packet. It
allows in-profile (green) packets to use the available tokens from the CIR rate first while outof-profile packets use available tokens from the PIR rate first. Thus user can prioritize inprofile packets over out-profile packets by ensuring that CIR rate is available for in-profile
service ingress packets. The mapping of traffic to forwarding class meter can be based on
combinations of customer QoS marking in the packet header (for example: IEEE 802.1p bits,
IP DSCP bits, MAC address, etc). The characteristics of the forwarding class policer are
defined within the policy as to the number of forwarding class meter to use for unicast traffic
and BUM (Broadcast, Unknown-unicast, and Multicast) traffic along with the policer rate
(like CIR, PIR) and burst parameters (like CBS, MBS). Each of the forwarding classes can
be associated with different parameters for unicast traffic and different parameters for
multipoint (that is, BUM) traffic. A service ingress QoS policy defines up to 16 meters per
policy, with up to 2 meters per forwarding class. Unicast and multi-point traffic can be
mapped to use the same policer or mapped to use different policer per forwarding class with
a maximum of up to 2 policer per forwarding class, one each for unicast and for multicast
traffic. In the case of VPLS service, four types of forwarding are supported (which is not to
be confused with forwarding classes), unicast, multicast, broadcast, and unknown. Multicast,
broadcast, and unknown types are flooded to all destinations within the service while the
unicast forwarding type is handled in a point-to-point fashion within the service. Multicast,
broadcast, and unknown traffic types use the same multicast meter mapping defined for
forwarding class. In other words, a separate meter for multicast, broadcast, and unknown
unicast traffic types cannot be defined.
267210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 27
QoS Policies
Service ingress QoS policy also provides an option to configure a mix of meters and queues
per policy and per forwarding class. In other words, it is possible to use a queue for one of the
forwarding class used to forward bursty traffic while using a meter for another forwarding
class used to forward low-latency traffic. In addition, it is possible to configure a queue for
unicast traffic type while using a meter for BUM traffic types or vice-versa.
On service ingress when a combination of queues and meters are used, option is available to
configure the service ingress aggregate rate for queues and meters individually. In other
words, the service ingress aggregate policer rate enforces the rate across all the forwarding
class meters configured in the SAP while the service ingress aggregate shaper rate enforces
the rate across all the forwarding class queues configured in the SAP.
Service egress QoS policies are applied to SAPs and map forwarding classes to service egress
queues for a service. The system can allocate a maximum of 8 queues per SAP for the 8
forwarding classes. All traffic types (that is, both unicast and BUM traffic types) share the
same queue on service egress. A service egress QoS policy defines the forwarding class
queue characteristics and also defines how to remark the forwarding class to priority bits in
the packet header (for example: IEEE 802.1p bits in the Ethernet VLAN tag) in the customer
traffic.
Network QoS policies are applied to access uplink ports or network ports. Following provides
an overview of the network QoS policy applied to access-uplink ports followed by an
overview of the network QoS policy applied to network ports.
Access-uplink ports are typically used to connect to the core network using QinQ or Dot1q
links and forward customer traffic towards the core network. A network QoS policy defines
both ingress and egress behavior on a access-uplink port. On access-uplink port ingress,
traffic that enters through the port is classified to map it to a forwarding Class and the user
has an option to assign a profile. Forwarding class is associated with ingress queues on access
uplink port ingress and the profile determines the en-queuing priority for the packet, with inprofile packets have a higher chance of getting the buffer, than out-of-profile packets. The
mapping of traffic to forwarding class ingress queues is based on QoS marking (for example:
IEEE 802.1p bits, IP DSCP bits). The characteristics of the forwarding class ingress queues
are defined within the policy as to the number of forwarding class queues for unicast traffic
type and BUM (Broadcast, Unknown-unicast, and Multicast) traffic type, along with the
queue rate and buffer parameters (like CIR, PIR, CBS, MBS, etc.). Each of the forwarding
classes can be associated with different ingress queue parameters for unicast traffic type and
for multi-point (that is BUM) traffic type. A network QoS policy defines up to 8 ingress
queues per policy, with up to 2 ingress queues per forwarding class. Unicast and multi-point
traffic can be defined to use the same ingress queue or different ingress queues per forwarding
class. In the case of VPLS service, four types of forwarding are supported (which is not to be
confused with forwarding classes), unicast, multicast, broadcast, and unknown. Multicast,
broadcast, and unknown types are sent to multiple destinations within the service while the
unicast forwarding type is handled in a point-to-point fashion within the service. All these
traffic types use the same queue (in other words, a separate queue for multicast, broadcast,
and unknown unicast traffic types cannot be defined). On access-uplink port egress, the
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide27
Page 28
QoS Overview
policy maps forwarding class and profile state to Dot1p and /or IP DSCP values for traffic to
be transmitted out of the access-uplink port. All the access-uplink SAPs configured on the
same access-uplink port use the same policy and the same set of forwarding class queues. In
other words, traffic received and transmitted through all the access-uplink SAPs configured
on a given access-uplink port receive similar QoS treatment.
Network ports are typically used to connect to the core network using IP/MPLS tunnels and
forward customer traffic towards the core network. A network QoS policy defines both
ingress and egress behavior on a network port. On network port ingress, traffic that enters
through the port is classified to map it to a forwarding Class and the user has an option to
assign a profile. Forwarding class is associated with ingress queues on network port ingress
and the profile determines the en-queuing priority for the packet, with in-profile packets have
a higher chance of getting the buffer, than out-of-profile packets. The mapping of traffic to
forwarding class ingress queues is based on QoS marking (for example: MPLS EXP bits,
IEEE 802.1p bits, IP DSCP bits). The characteristics of the forwarding class ingress queues
are defined within the policy as to the number of forwarding class queues for unicast traffic
type and BUM (Broadcast, Unknown-unicast, and Multicast) traffic type, along with the
queue rate and buffer parameters (like CIR, PIR, CBS, MBS, etc.). Each of the forwarding
classes can be associated with different ingress and ingress queue parameters for unicast
traffic type and for multi-point (that is BUM) traffic type. A network QoS policy defines up
to 8 ingress queues per policy, with up to 2 ingress queues per forwarding class. Unicast and
multi-point traffic can be defined to use the same ingress queue or different ingress queues
per forwarding class. In the case of VPLS service, four types of forwarding are supported
(which is not to be confused with forwarding classes), unicast, multicast, broadcast, and
unknown. Multicast, broadcast, and unknown types are sent to multiple destinations within
the service while the unicast forwarding type is handled in a point-to-point fashion within the
service. All these traffic types use the same queue (in other words, a separate queue for
multicast, broadcast, and unknown unicast traffic types cannot be defined). On network port
egress, the policy maps forwarding class and profile state to MPLS EXP and/or Dot1p and /
or IP DSCP values for traffic to be transmitted out of the network port. All the IP interfaces
configured on the same network port use the same policy and the same set of forwarding class
queues. In other words, traffic received and transmitted through all the IP interfaces
configured on a given network port receive similar QoS treatment.
Network queue policies are applied on egress of access uplink ports and network ports. It
maps forwarding classes to network egress queues on access uplink ports and on network
ports. The system allocates 8 egress queues per port (per network port and per access-uplink
port) for the 8 forwarding classes. The policy defines the forwarding class queue
characteristics (that is, CIR, PIR, CBS, MBS, etc.). All traffic types (that is, both unicast and
BUM traffic types) share the same egress queue on access-uplink port and network port. All
the access-uplink SAPs configured on the same access-uplink port use the same policy and
the same set of forwarding class queues. In other words, traffic transmitted through all the
access-uplink SAPs configured on a given access-uplink port receive similar QoS treatment.
All the IP interfaces configured on the same network port use the same policy and the same
set of forwarding class queues. In other words, traffic transmitted through all the IP interfaces
configured on a given network port receive similar QoS treatment.
287210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 29
QoS Policies
Slope policies are applied to service ingress queues, service egress queues, access uplink port
ingress queues, access uplink port egress queues, network port ingress queues, network port
egress queues. Each of these queuing points allocates buffers from the buffer pool and
implements WRED for congestion management. During congestion WRED is used to
evaluate how buffers from the pool are allocated to different FCs and to in-profile and outof-profile traffic within a given FC. The slope policies define the WRED parameters to use
for in-profile/high-priority packets and for out-of-profile/low-priority packets. The highslope and low-slope define the parameters for in-profile/high-priority packets and for out-ofprofile/low-priority packets respectively. In addition, 7210 SAS-K introduces the concept of
ring and non-ring ports with an option for preferential allocation of traffic for ring ports. The
system by default treats network ports and access-uplink ports as ring ports.
Remark policies are applied to access SAP egress, access-uplink port egress and network port
egress. They are associated with service egress policy and network qos policy. They define
the forwarding class and profile to egress marking values (for example: IEEE 802.1p bits in
the Ethernet VLAN tag) to use.
Dot1p classification policy, IP DSCP classification policy and MPLS EXP classification
policy allows user to define the map of Dot1p bits, IP DSCP values and MPLS EXP values
respectively to forwarding class and assign the profile for the packet. Dot1p classification
policy and IP DSCP classification policy is available on access SAP ingress and accessuplink port ingress. Dot1p classification policy, IP DSCP classification policy, and MPLS
EXP classification policy is available on access SAP ingress and access-uplink port ingress,
and network port ingress.
One service ingress QoS policy and a single service egress QoS policy can be applied to a
specific access SAP. One network QoS can be applied to a specific access-uplink port. One
network queue policy can be applied to the network port. If no QoS policy is explicitly
applied to a SAP or port, a default QoS policy is applied.
Summary of Major Functions of QoS Policies
A summary of the major functions performed by the QoS policies is listed in Table 2.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide29
Page 30
QoS Overview
Table 2: QoS Policy Types and Descriptions for 7210 SAS-K 2F2T1C
Policy TypeApplied at…Description
Service Ingress Access SAP
Ingress
Service EgressAccess SAP
Egress
Egress RateAccess port and
Access-uplink
port
Network QoS Access-uplink
port
•Option to define up to 8 forwarding class queues and queue
parameters to define queue characteristics (For example:
scheduler priority and weight, rates, etc.)
•Option to defines up to 16 forwarding class meters and
meter parameters to define meter characteristics (For
example: rates, CBS, MBS, etc.)
•For traffic classification, defines match criteria to map
flows to the queues based on Dot1p or IP DSCP criteria or
MAC criteria or IP criteria.
• Allocates up to 8 forwarding class queues and maps
forwarding classes to the queues.
•Defines FC to remarking values, through the use of remark
policies.
•Defines queue parameters to define queue characteristics
(For example: scheduler priority and weight, rates, etc.).
Configures the maximum bandwidth available for traffic sent out of
a specified port.
•At ingress, defines up to 8 forwarding class queues and
queue parameters to define queue characteristics (For
example: scheduler priority and weight, rates, etc.).
•For traffic classification, defines match criteria to map
flows to the queues based on Dot1p and DSCP values.
•At egress, defines FC to remarking values, through the use
of remark policies.
Network QueueAccess-uplink
port
•Allocates up to 8 forwarding class queues and maps
forwarding classes to the queues.
•Defines queue parameters to define queue characteristics
(For example: scheduler priority and weight, rates, etc.).
Slope policiesSAP queues (both
ingress and
egress) and
Access-uplink
port (both ingress
and egress
•Enables or disables the high-slope and low-slope
parameters for queue.
•On 7210 SAS-K 2F2T1C, in addition to high-slope and
low-slope, user has an option to use high-slope-ring and
low-slope-ring parameters for access-uplink port egress
queues.
queues)
307210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 31
Table 2: QoS Policy Types and Descriptions for 7210 SAS-K 2F2T1C (Continued)
Policy TypeApplied at…Description
QoS Policies
Remark Policies SAP egress,
Access-uplink
port egress
Dot1p classification
policy and DSCP
classification policy
Access SAP
ingress and
access-uplink port
•Defines FC to remarking values; Not directly associated
with a SAP or a port. Instead it is associated with SAP
egress policy and network qos policy.
•Defines the map of Dot1p bits and IP DSCP values to
forwarding class and assign the profile for the packet on
access SAP ingress and access-uplink port ingress.
ingress
Table 3: QoS Policy Types and Descriptions for 7210 SAS-K 2F4T6C
Policy TypeApplied at…Description
Service Ingress Access SAP
Ingress
•Option to define up to 8 forwarding class queues and queue
parameters to define queue characteristics (For example:
scheduler priority and weight, rates, etc.)
•Option to defines up to 16 forwarding class meters and
meter parameters to define meter characteristics (For
example: rates, CBS, MBS, etc.)
•For traffic classification, defines match criteria to map
flows to the queues based on Dot1p or IP DSCP criteria or
MAC criteria or IP criteria.
Service EgressAccess SAP
Egress
• Allocates up to 8 forwarding class queues and maps
forwarding classes to the queues.
•Defines FC to remarking values, through the use of remark
policies.
•Defines queue parameters to define queue characteristics
(For example: scheduler priority and weight, rates, etc.).
Egress RateAccess port,
Access-uplink
Configures the maximum bandwidth available for traffic sent out of
a specified port.
port, and network
port
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide31
Page 32
QoS Overview
Table 3: QoS Policy Types and Descriptions for 7210 SAS-K 2F4T6C (Continued)
Policy TypeApplied at…Description
Network QoS Network port and
Access-uplink
port
Network QueueNetwork port and
Access-uplink
port
Slope policiesAccess SAP
queues (both
ingress and
egress), network
port queues (both
ingress and
egress) and
Access-uplink
port (both ingress
and egress
queues)
•At ingress, defines up to 8 forwarding class queues and
queue parameters to define queue characteristics (For
example: scheduler priority and weight, rates, etc.).
•For traffic classification, defines match criteria using
packet header bits (e.g. MPLS EXP, Dot1p, IP DSCP, etc.)
to map flows to the queues.
•At egress, defines FC to remarking values, through the use
of remark policies.
•Allocates up to 8 forwarding class queues and maps
forwarding classes to the queues.
•Defines queue parameters to define queue characteristics
(For example: scheduler priority and weight, rates, etc.).
•Enables or disables the high-slope and low-slope
parameters for queue.
•On 7210 SAS-K 2F4T6C, in addition to high-slope and
low-slope, user has an option to use high-slope-ring and
low-slope-ring parameters for network port and accessuplink port egress queues.
Remark Policies Access SAP
•Defines FC to remarking values
egress, network
port egress,
Access-uplink
port egress
Network port
ingress, Access
SAP ingress and
access-uplink port
ingress
•Defines the map of Dot1p bits and IP DSCP values to
forwarding class and assign the profile for the packet
received on access SAP ingress and access-uplink port.
•Defines the map of MPLS EXP, Dot1p, and IP DSCP
values to forwarding class and assign the profile for packets
received on network port.
327210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 33
Service and Network QoS Policies
The QoS mechanisms within the 7210 SAS-K are specialized for the type of traffic on the
interface.
On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, for customer interfaces, there is service
ingress and service egress, and for access uplink port, and network ports, there is network
ingress and network egress traffic (Figure 1 below).
QoS Policies
Figure 1: 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C Service and Network Traffic
Types and QoS model
The 7210 SAS uses QoS policies applied to a SAP for a service or to an access uplink port or
to a network port to define the queuing, queue attributes, meter attributes, and QoS marking/
interpretation.
The 7210 SAS supports the following major types of service and network QoS policies:
•Service ingress QoS policies
•Service Egress QoS policies
•Network QoS policies
•Network Queue QoS policies
The support of different policies varies across different platforms. More details are available
in the following chapters and sections of this chapter.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide33
Page 34
QoS Overview
Network QoS Policies
Network QoS Policies on network ports on 7210 SAS-K 2F4T6C
Platforms supported: 7210 SAS-K 2F4T6C
Network QoS policies define egress QoS marking and ingress QoS interpretation for traffic
on received on network ports.
A network QoS policy defines both the ingress and egress handling of QoS on the network
ports. The following functions are defined:
•Ingress
→ Option to use MPLS EXP value to map traffic to available forwarding classes
and profile state.
→ Option to use Dot1p value to map traffic to available forwarding classes and
profile state.
→ Option to use IP DSCP value to map traffic to available forwarding classes and
profile state.
→ Option to use all of three above simultaneously along with DEI for forwarding
class determination and assigning profile.
→ Defines forwarding class to queue mapping.
•Egress
→ Option to define the forwarding class and profile state to MPLS EXP value
markings.
→ Option to define the forwarding class and profile state to Dot1p value markings.
→ Option to define the forwarding class and profile state to IP DSCP value marking
→ Remarking of QoS bits can be enabled or disabled
The required elements to be defined in a network QoS policy are:
•A unique network QoS policy ID.
•Egress forwarding class to priority bits (for example: 802.1p, etc.) used for marking,
for each forwarding class.
•A default ingress forwarding class and an optional in-profile/out-of-profile state.
•At least one default unicast forwarding class meter or queue based on the platform.
The parameters that can be configured for a meter and queue are discussed below.
Optional network QoS policy elements include:
347210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 35
QoS Policies
•Additional queues.
•MPLS EXP value to forwarding class and profile state mappings for all values
received
•Dot1p value to forwarding class and profile state mappings for all values received.
•Option to use DEI bit along with Dot1p classification for profile state mapping
•Option to use IP DSCP value to forwarding class and profile state mappings for all
DSCP values received.
Ingress Classification Support for Network ports on 7210 SAS-K
2F4T6C
On ingress of network ports user has an option to use both MPLS EXP and Dot1p bits to map
received MPLS packets to forwarding class.
•If both MPLS EXP and Dot1p bits are configured, then the match order for MPLS
packets is to match with MPLS EXP entries first and assign a FC if there is match. If
no match, match with Dot1p entries, if configured and assign a FC if there is a match
with Dot1p entries. If there is no match with both MPLS EXP and Dot1p entries,
assign the default FC configured. DEI bit can be used to assign profile state to the
MPLS packets on network ingress.
•On ingress of network ports, the user has an option to use both IP DSCP and Dot1p
bits to map received IP packets (plain routed packets in the context of network IP
interfaces configured on the network port) to forwarding class. If both IP DSCP and
Dot1p bits are configured, then the match order for IP packets is to match with IP
DSCP entries first and Dot1p entries next. The FC and profile value configured in the
entry which matches first is assigned to the packet. If there is no match with either IP
DSCP and Dot1p values, then the default FC is assigned to the packet. DEI bit can
be used to assign profile state to the IP packets of network ingress.
•On 7210 SAS-K 2F4T6C, MPLS EXP classification entries that map MPLS EXP
values to FC, Dot1p classification entries that map Dot1p bits to FC and IP DSCP
classification entries that map IP DSCP values to FC is defined using MPLS EXP
classification policies, Dot1p-classification policies and DSCP classification policies
respectively.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide35
Page 36
QoS Overview
Egress Marking Support for Network ports on 7210 SAS-K 2F4T6C
On network port egress, option is provided to mark MPLS EXP and Dot1p values for MPLS
packets. For IP packets sent out of network port, option is provided to mark IP DSCP and
Dot1p values for IP packets. Along with Dot1p user has an option to mark DEI bit for both
MPLS and IP DSCP packets.
Network policy ID 2 is reserved as the default network QoS policy applied to network ports.
The default policy cannot be deleted or changed. The default network QoS policy is applied
to all network ports which do not have another network QoS policy explicitly assigned.
The network QoS policy applied at network egress (that is, on an network port) determines
how or whether the profile state is marked in packets transmitted into the service core
network. If the profile state is marked in the service packets, out-of-profile packets are
preferentially dropped over in-profile packets at congestion points in the network.
For network egress, traffic remarking in the network QoS policy can be enabled or disabled.
Table 4 lists the default mapping of forwarding class to Dot1p values for egress marking.
For network ingress, Table 6 the default mapping of mpls-lsp-exp-classification values to
forwarding class and profile state for the default network QoS policy.
Table 6: Default Network QoS policy mpls-lsp-exp-classification to FC Mapping
MPLS EXP valueIngress FCProfile
0beOut
1l2In
2afOut
3afIn
4h2In
5efIn
6h1In
7ncIn
For network ingress, Table 7 the default mapping of dscp-classification values to forwarding
class and profile state for the default network QoS policy.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide37
Page 38
QoS Overview
Table 7: Default Network QoS policy dscp-classification to FC Mapping
IP DSCP valueIngress FCProfile
bebeOut
efefIn
cs1l2In
nc1h1In
nc2ncIn
af11afIn
af12afOut
af41h2In
Network QoS Policies on Access-uplink Ports
Platforms supported: 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C
Network QoS policies define egress QoS marking and ingress QoS interpretation for traffic
on received on access-uplink ports.
A network QoS policy defines both the ingress and egress handling of QoS on the access
uplink ports. The following functions are defined:
•Ingress
→ Option to use Dot1p value mapping to forwarding classes and profile.
→ Option to use IP DSCP value to map traffic to different forwarding classes and
profile.
→ Defines forwarding class to ingress queue mapping
•Egress
→ Option to define the forwarding class and profile to Dot1p value markings.
→ Option to define the forwarding class and profile to IP DSCP value marking
→ Remarking of QoS bits can be enabled or disabled.
The required elements to be defined in a network QoS policy are:
•A unique network QoS policy ID.
387210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 39
•Egress - forwarding class and optional profile state to priority bits (for example:
802.1p, etc.) used for marking, for each forwarding class.
•A default ingress forwarding class and an optional in-profile/out-of-profile state.
•At least one default unicast forwarding class queue. The parameters that can be
configured for a ingress queue are discussed below.
Optional network QoS policy elements include:
•Additional queues.
•Dot1p value to forwarding class and profile state mappings for all values received.
•Option to use DEI bit along with Dot1p classification for profile state mapping
•Option to use IP DSCP value to forwarding class and profile state mappings for all
DSCP values received.
Ingress Classification Support for access-uplink ports
QoS Policies
On ingress of access-uplink ports user has an option to use both IP DSCP and Dot1p bits to
map received IP packets to forwarding class. If both IP DSCP and Dot1p bits are configured,
then the match order for IP packets is to match with IP DSCP entries first and Dot1p entries
next. The FC and profile value configured in the entry which matches first is assigned to the
packet. If there is no match with either IP DSCP and Dot1p values, then the default FC is
assigned to the packet. DEI bit can be used to assign profile state to the packets of network
ingress.
On 7210 SAS-K 2F4T6C, Dot1p classification entries that map Dot1p bits to FC and IP
DSCP classification entries that map IP DSCP values to FC is defined by using Dot1pclassification policies and DSCP classification policies respectively.
Network policy ID 1 is reserved as the default network QoS policy applied to access-uplink
ports. The default policy cannot be deleted or changed. The default network QoS policy is
applied to all access uplink ports which do not have another network QoS policy explicitly
assigned.
The network QoS policy applied at network egress (that is, on an access uplink port)
determines how or whether the profile state is marked in packets transmitted into the service
core network. If the profile state is marked in the service packets, out-of-profile packets are
preferentially dropped over in-profile packets at congestion points in the network.
For network egress, traffic remarking in the network QoS policy can be enabled or disabled.
See Table 8 for more information.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide39
Page 40
QoS Overview
Table 8: Default Network QoS policy Dot1p to FC Mapping for network egress
Dot1p ValueIngress FCProfile
0beOut
1l2In
2afOut
2l1In
4h2In
5efIn
6h1In
7ncIn
For network ingress, Table 9 the default mapping of Dot1p values to forwarding class and
profile state for the default network QoS policy.
Table 9: Default Network QoS policy Dot1p to FC Mapping for network ingress
Dot1p ValueIngress FCProfile
0beOut
1l2In
2afOut
3afIn
4h2In
5efIn
6h1In
7ncIn
407210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 41
QoS Policies
Network Queue Policies
Network Queue policies on 7210 SAS-K 2F2T1C and 7210 SAS-K
2F4T6C
Network queue policies are applied on egress of access-uplink ports on SAS-K2F2T1C.
On 7210 SAS-K2F4T6C, network queue policies are applied on egress of access-uplink ports
and network ports.
The Network queue policies can be defined with up to a maximum of 8 egress queues. The
user has an option to define the policies with less than eight egress queues.
The queue characteristics configured on a per-forwarding class basis are:
•Committed Buffer Size (CBS) in Kilobytes
•Maximum Buffer Size (MBS) in Kilobytes
•Peak Information Rate (PIR) as a percentage of egress port bandwidth
•Committed Information Rate (CIR) as a percentage of egress port bandwidth
•Queue priority and Queue weight
Network queue policies are identified with a unique policy name which conforms to the
standard 7210 SAS alphanumeric naming conventions. The system default network queue
policy is named default and cannot be edited or deleted. Tabl e 9 describes the default network
queue policy definition in access-uplink mode.
Table 10: Default Network Queue Policy Definition on 7210 SAS-K2F2T1C and 7210 SAS-K2F4T6C.
Forwarding ClassQueueDefinition
Network-Control (nc)Queue 8PIR = 100%
CIR = 10%
MBS = 200 Kilobytes
CBS = 50 Kilobytes -7210
SAS-K 2F2T1C
CBS = 24 Kilobytes -7210
SAS-K 2F4T6C
priority = 1
weight = 1
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide41
Page 42
QoS Overview
Table 10: Default Network Queue Policy Definition on 7210 SAS-K2F2T1C and 7210 SAS-K2F4T6C.
Forwarding ClassQueueDefinition (Continued)
High-1 (h1)Queue 7PIR = 100%
CIR = 10%
MBS = 200 Kilobytes
CBS = 50 Kilobytes -7210
SAS-K 2F2T1C
CBS = 24 Kilobytes -7210
SAS-K 2F4T6C
priority = 1
weight = 1
Expedited (ef)Queue 6PIR = 100%
CIR = 100%
MBS = 200 Kilobytes
CBS = 50 Kilobytes -7210
SAS-K 2F2T1C
CBS = 24 Kilobytes -7210
SAS-K 2F4T6C
priority = 1
weight = 1
High-2 (h2)Queue 5PIR = 100%
CIR = 100%
MBS = 200 Kilobytes
CBS = 50 Kilobytes -7210
SAS-K 2F2T1C
CBS = 24 Kilobytes -7210
SAS-K 2F4T6C
priority = 1
weight = 1
427210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 43
QoS Policies
Table 10: Default Network Queue Policy Definition on 7210 SAS-K2F2T1C and 7210 SAS-K2F4T6C.
Forwarding ClassQueueDefinition (Continued)
Low-1 (l1)Queue 4PIR = 100%
CIR = 25%
MBS = 200 Kilobytes
CBS = 50 Kilobytes -7210
SAS-K 2F2T1C
CBS = 24 Kilobytes -7210
SAS-K 2F4T6C
priority = 1
weight = 1
Assured (af)Queue 3PIR = 100%
CIR = 25%
MBS = 200 Kilobytes
CBS = 50 Kilobytes -7210
SAS-K 2F2T1C
CBS = 24 Kilobytes -7210
SAS-K 2F4T6C
priority = 1
weight = 1
Low-2 (l2)Queue 2PIR = 100%
CIR = 25%
MBS = 200 Kilobytes
CBS = 50 Kilobytes -7210
SAS-K 2F2T1C
CBS = 24 Kilobytes -7210
SAS-K 2F4T6C
priority = 1
weight = 1
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide43
Page 44
QoS Overview
Table 10: Default Network Queue Policy Definition on 7210 SAS-K2F2T1C and 7210 SAS-K2F4T6C.
Forwarding ClassQueueDefinition (Continued)
Best-Effort (be)Queue 1PIR = 100%
CIR = 0%
CBS = 7%
MBS = 200 Kilobytes
CBS = 50 Kilobytes -7210
SAS-K 2F2T1C
CBS = 24 Kilobytes -7210
SAS-K 2F4T6C
priority = 1
weight = 1
Queues and Queue Parameters
This section describes the queue parameters provisioned for queues used in service ingress
policy, service egress policy, access egress policy, network qos policy and network queue
policy.
Note: Not all 7210 platforms support queues for all the above policies. In addition, the queue
parameters support available varies across different platforms. See platform specific QoS
overview sections above and the chapter following to know the support available on different
platforms.
Queues are available on different platforms as follows:
On 7210 SAS-K 2F2T1C queues are available with the following:
•SAP ingress policies associated with access SAP ingress.
•SAP egress policies associated with access SAP egress.
•Network Queue policies associated with access-uplink port egress.
•Network QoS policies associated with access-uplink port ingress.
On 7210 SAS-K 2F4T6C queues are available with the following:
•SAP ingress policies associated with access SAP ingress.
•SAP egress policies associated with access SAP egress.
•Network Queue policies associated with access-uplink port egress.
447210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 45
•Network QoS policies associated with access-uplink port ingress.
•Network Queue policies associated with network port egress.
•Network QoS policies associated with network port ingress.
The queue parameters are:
•Queue- Queue ID
•Queue- Committed Information Rate
•Queue- Peak Information Rate
•Queue- Adaptation Rule for Queues
•Queue- Committed Burst Size
•Queue – Ingress Profile Assignment
•Queue – Weight and Priority
•Queue Counters
QoS Policies
Queue- Queue ID
The queue ID is used to uniquely identify the queue. The queue ID is only unique within the
context of the QoS policy within which the queue is defined. It allows user to define multiple
queues with different characteristics and identify them while associating it with different
forwarding classes.
On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, user has an option to allocate up to 8
queues and assign them queue ID along with option to configure some of the queue
parameters which determine the queue characteristics.
Queue- Committed Information Rate
The committed information rate (CIR) for a queue performs two distinct functions:
•Minimum bandwidth guarantees — Queue’s CIR setting provides the bandwidth
which will be given to this queue as compared to other queues on the port competing
for a share of the available link bandwidth. The queue CIR does not necessarily
guarantee bandwidth in all scenarios and also depends on factors such as CIR over
subscription and link port bandwidth capacity. For each packet in a queue, the CIR
is checked with the current transmission rate of the queue. If the current rate is at or
below the CIR threshold, the queue is considered in-profile. If the current rate is
above the threshold, the queue is considered out-of-profile. The in-profile and outprofile state of queue is linked to scheduler prioritizing behavior as discussed below.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide45
Page 46
QoS Overview
•Scheduler queue priority metric — The scheduler serving a group of queues
prioritizes individual queues based on their current CIR and PIR states. Queues
operating below their CIR are always served before those queues operating at or
above their CIR. Also see information about schedulers to know the scheduler
behavior on different 7210 platforms.
NOTE: On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, the in-profile and out-profile
state of the ingress queue determines the packets final profile state based on the queue CIR,
PIR values. The in-profile and out-profile state of the ingress queue also interacts with the
scheduler mechanism and provides the minimum and maximum bandwidth guarantees. This
is true only off ingress queues and not of egress queues. In other words, the in-profile and outprofile state of the egress queue does not change the packets final profile state based on the
queue CIR, PIR values. The in-profile and out-profile state of the egress queue only interacts
with the scheduler mechanism and provides the minimum and maximum bandwidth
guarantees. Please see the section on “Queue – Ingress Profile Assignment on 7210 SAS-K”
to know more.
When defining the CIR for a queue, the value specified is the administrative CIR for the
queue. User has some control over how the administrative CIR is converted to an operational
CIR should the hardware not support the exact CIR and PIR combination specified. The
interpretation of the administrative CIR is discussed below in Queue- Adaptation Rule for
Queues. Although the 7210 SAS is flexible in how the CIR can be configured, there are
conventional ranges for the CIR based on the forwarding class of a queue. An egress queue
associated with the high-priority class normally has the CIR threshold equal to the PIR rate
although the 7210 SAS allows the CIR to be provisioned to any rate below the PIR should
this behavior be required.
The CIR of the queue is configurable under the different qos policies that provide the option
to configure the queue parameters – example under service ingress and service egress queue
policies, access port policies, network queue policies, etc.
Queue- Peak Information Rate
The peak information rate (PIR) defines the maximum rate at which packets are allowed to
exit the queue. It does not specify the maximum rate at which packets may enter the queue;
this is governed by the queue's ability to absorb bursts. The actual transmission rate of an
egress queue depends on more than just its PIR. Each queue is competing for transmission
bandwidth with other queues. Each queue's PIR, CIR and the relative priority and/or weight
of the scheduler serving the queue, all combine to affect a queue's ability to transmit packets.
467210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 47
When defining the PIR for a queue, the value specified is the administrative PIR for the
queue. The user has some control over how the administrative PIR is converted to an
operational PIR should the hardware not support the exact CIR and PIR values specified. The
interpretation of the administrative PIR is discussed below in Queue- Adaptation Rule for
Queues
The PIR of the queue is configurable under the different qos policies that provide the option
to configure the queue parameters – example under service ingress and service egress queue
policies, access port policies, network queue policies, etc.
Queue- Adaptation Rule for Queues
The adaptation rule provides the QoS provisioning system with the ability to adapt specific
CIR and PIR defined administrative rates to the underlying capabilities of the hardware the
queue will be created on to derive the operational rates. The administrative CIR and PIR rates
are translated to actual operational rates enforced by the hardware queue. The rule provides
a constraint used when the exact rate is not available.
QoS Policies
For the CIR and PIR parameters individually, the system will attempt to find the best
operational rate depending on the defined constraint. The supported constraints are:
•Minimum — Find the hardware supported rate that is equal to or higher than the
specified rate.
•Maximum — Find the hardware supported rate that is equal to or lesser than the
specified rate.
•Closest — Find the hardware supported rate that is closest to the specified rate.
Depending on the platform on which the queue is provisioned, the actual operational CIR and
PIR settings used by the queue will be dependent on the method the hardware uses to
implement and represent the mechanisms that enforce the CIR and PIR rates. The adaptation
rule controls the method the system uses to choose the rate step based on the administrative
rates defined by the rate command.
NOTE: For 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, the 7210 SAS software
considers the adaptation rules and the hardware values available to determine the admin PIR/
CIR rates.
To illustrate (the example that follows is only for illustration of the use of adaptation rule and
the values provided below does not list the actual values supported in hardware), how the
adaptation rule constraints minimum, maximum and closest are evaluated in determining the
operational CIR or PIR for the 7210 SAS, assume there is a queue where the administrative
CIR and PIR values are 90Kbps and 150 Kbps, respectively. If the adaptation rule is
minimum, the operational CIR and PIR values will be 128Kbps and 192Kbps respectively,
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide47
Page 48
QoS Overview
as it is the native hardware rate greater than or equal to the administrative CIR and PIR values.
If the adaptation rule is maximum, the operational CIR and PIR values will be 64Kbps and
128Kbps. If the adaptation rule is closest, the operational CIR and PIR values will be 64Kbps
and 128Kbps, respectively, as those are the closest matches for the administrative values that
are even multiples of the 64 Kbps rate step.
Queue- Committed Burst Size
The committed burst size (CBS) parameters specify the amount of buffers that can be drawn
from the reserved buffer portion of the queue’s buffer pool. Once the reserved buffers for a
given queue have been used, the queue contends with other queues for additional buffer
resources up to the maximum burst size.
The CBS of the queue is configurable under the different QoS policies, if supported by the
platform, that provide the option to configure the queue parameters – example under service
ingress and service egress queue policies, network queue policies, etc. The CBS for a queue
is specified in Kbytes.
On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, the CBS for the queues is user
configurable. By default, software assigns a default value. It can be modified by the user as
per their needs. The default value are specified in the command description.
Queue- Maximum Burst Size
The maximum burst size (MBS) parameter specifies the maximum queue depth to which a
queue can grow. This parameter ensures that a customer that is massively or continuously
oversubscribing the PIR of a queue will not consume all the available buffer resources. For
high-priority forwarding class service queues, the MBS can be relatively smaller than the
other forwarding class queues because the high-priority service packets are scheduled with
priority over other service forwarding classes.
The MBS of the queue is configurable under the different QoS policies, if supported by the
platform, that provide the option to configure the queue parameters – example under service
ingress and service egress queue policies, network queue policies, etc. The MBS for a queue
is specified in Kbytes.
On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, the MBS for the queues is user
configurable. By default, software assigns a default value. It can be modified by the user as
per their needs. The default values are specified in the command description.
487210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 49
Queue – Ingress Profile Assignment
On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C queues can operate in two modes –
profile mode and non-profile mode. On 7210 SAS-K 2F2T1C, SAP Ingress queues and
Access uplink port ingress queues operate in either profile mode or non-profile mode.
On 7210 SAS-K 2F4T6C, SAP Ingress queues, Network port ingress queues and Access
uplink port ingress queues operate in either profile mode or non-profile mode
In ‘profile mode’, the profile defined in the policy is used to determine the WRED slope to
use for ingress queuing, with ‘profile in’ packets using high-slope and ‘profile out’ packets
using low-slope. The ingress queue shaper does not change the profile value assigned to a
packet that has a user assigned profile value. In other words, if an user assigns a profile value
of green and the packet exceeds the CIR rate of the shaper, it is not changed to yellow.
Similarly, packets assigned yellow color is not changed by the shaper. The color assigned by
the user is also subsequently used at the egress queuing point to determine the slope to use.
In ‘non-profile’ mode, the profile is not specified by the user (and hence the node maps it to
‘undefined’ value. The low WRED slope is used at the ingress queuing point, as all packets
received are considered to be the same as ‘profile out’. The packet is then assigned the profile
by the ingress queue shaper. It is assigned ‘in’ profile value if it’s within the CIR and assigned
‘out’ profile value if it exceeds the CIR. It is dropped if it exceeds the PIR rate of ingress
queue shaper (except for packets which are assigned a profile value of “undefined” on ingress
and where the shaper assigns the profile based on CIR/PIR rate). The profile assigned by the
ingress queue shaper is also subsequently used at the egress queuing point to determine the
slope to use.
QoS Policies
The user is provided with different options to assign the profile to the packet (for example:
DEI based). It is always assigned on ingress of the packet into the node. Once the profile is
assigned at the ingress, it is used at subsequent queuing points in the system. In other words,
subsequent modules and queuing points in the system do not change the profile assigned to
the packet on ingress. The profile assigned at ingress is also used to subsequently assign
different marking/remarking values to in-profile and out-of-profile packets, if the user so
desires.
Queue – Weight and Priority
On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, user is provided an option to assign the
priority and weight to the queue. The priority determines the service order of the queue when
the scheduler schedules multiple queues configured on the same port. The queue weight
determines the proportion of the available bandwidth that the scheduler allocates to a queue.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide49
Page 50
QoS Overview
Queue Counters
The router maintains counters for queues within the system for granular billing and
accounting.
Each queue maintains the following counters:
The counters available vary among the 7210 SAS platform. Not all the counters are supported
on all the platforms. Additionally there are restrictions on the number of counters that can be
used simultaneously with a single queue. Some platforms can only count octets or packets
and other can count both packets and octets. Counter (and corresponding accounting record)
support available on each of the platform is listed in the 7210 SAS System Management user
guide under the “Accounting Records/Logs” section.
•Counters for packets and octets accepted into the queue
•Counters for packets and octets rejected at the queue
•Counters for packets and octets transmitted in-profile
•Counters for packets and octets transmitted out-of-profile
Queue – support on various platforms
The following support is available on different platforms:
•On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C - Service queue is provisioned
on access sap ingress and access sap egress service queues within service ingress
QoS policies and service egress QoS policies, respectively.
•On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C - access-uplink port egress
queues are defined within network queue policies.
•On 7210 SAS-K 2F4T6C - network port ingress queues are defined within network
QoS policies.
•On 7210 SAS-K2F2T1C and 7210 SAS-K2F4T6C - access-uplink port ingress
queues are defined within network qos policies.
•On 7210 SAS-K2F4T6C - network port egress queues are defined within network
queue policies.
507210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 51
Meter/Policers and Policer Parameters
This section describes the meter parameters provisioned for meters used in service ingress
policy. The terms “meters” and “policers” are used interchangeably in this document to refer
to policing or metering.
NOTE: Not all 7210 platforms support meters for all the QoS policies. In addition, the meter
parameters support available varies across different platforms. See platform specific QoS
overview sections above and the chapters following to know the support available on
different platforms.
Meters are available on different platforms as follows:
On 7210 SAS-K 2F2T1C meters are available with the following:
•SAP ingress policies associated with access SAP ingress.
On 7210 SAS-K 2F4T6C meters are available with the following:
QoS Policies
The meter parameters are:
Meter - Meter ID
The meter ID is used to uniquely identify the meter/policer. The meter ID is only unique
within the context of the QoS policy within which the meter is defined. It allows user to define
multiple Meters with different characteristics and identify them while associating it with
different forwarding classes.
•SAP ingress policies associated with access SAP ingress.
•Meter- meter ID
•Meter- Committed Information Rate (CIR)
•Meter- Peak Information Rate (PIR)
•Meter- Adaptation Rule for Meters
•Meter- Committed Burst Size (CBS)
•Meter – Ingress Profile Assignment
•Meter Counters
On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, user has an option to allocate up to 8
meter and assign them meter ID along with option to configure the meter parameters which
determine the meter characteristics.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide51
Page 52
QoS Overview
Meter - Committed Information Rate
The committed information rate (CIR) for a meter is the long term average rate at which
traffic is considered as conforming traffic or in-profile traffic. The higher the rate, the greater
the throughput user can expect. The user will be able to burst above the CIR and up to PIR
for brief periods of time. The time and profile of the packet is decided based on the burst sizes
as explained in the following sections.
When defining the CIR for a meter, the value specified is the administrative CIR for the
meter. The 7210 SAS devices have a number of native rates in hardware that it uses to
determine the operational CIR for the meter. The user has some control over how the
administrative CIR is converted to an operational CIR should the hardware not support the
exact CIR and PIR combination specified. Refer to the interpretation of the administrative
CIR in Adaptation Rule for Meters.
NOTE: On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, the in-profile and out-profile
value assigned determines the meter behavior for the packet. Please see the section on “Meter
– Ingress Profile Assignment on 7210 SAS-K” to know more.
Meter - Peak Information Rate
The peak information rate (PIR) defines the maximum rate at which packets are allowed to
exit the meter. It does not specify the maximum rate at which packets may enter the meter;
this is governed by the meter's ability to absorb bursts and is defined by its maximum burst
size (MBS).
When defining the PIR for a meter, the value specified is the administrative PIR for the meter.
The 7210 SAS devices have a number of native rates in hardware that it uses to determine the
operational PIR for the meter. The user has some control over how the administrative PIR is
converted to an operational PIR should the hardware not support the exact CIR and PIR
combination specified. Refer to the interpretation of the administrative PIR in Adaptation
Rule for Meters.
NOTE: On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, the in-profile and out-profile
value assigned determines the meter behavior for the packet. Please see the section on “Meter
– Ingress Profile Assignment on 7210 SAS-K” to know more.
527210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 53
Meter - Adaptation Rule for Meters
The adaptation rule provides the QoS provisioning system with the ability to adapt specific
CIR and PIR defined administrative rates to the underlying capabilities of the hardware the
queue will be created on to derive the operational rates. The administrative CIR and PIR rates
are translated to actual operational rates enforced by the hardware meter/policer. The rule
provides a constraint used when the exact rate is not available.
For the CIR and PIR parameters individually, the system will attempt to find the best
operational rate depending on the defined constraint. The supported constraints are:
•Minimum — Find the hardware supported rate that is equal to or higher than the
specified rate.
•Maximum — Find the hardware supported rate that is equal to or lesser than the
specified rate.
•Closest — Find the hardware supported rate that is closest to the specified rate.
Depending on the platform on which the queue is provisioned, the actual operational CIR and
PIR settings used by the queue will be dependent on the method the hardware uses to
implement and represent the mechanisms that enforce the CIR and PIR rates. The adaptation
rule controls the method the system uses to choose the rate step based on the administrative
rates defined by the rate command.
QoS Policies
NOTE: For 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, the 7210 SAS software
considers the adaptation rules and the hardware values available to determine the admin PIR/
CIR rates.
To illustrate (the example that follows is only for illustration of the use of adaptation rule and
the values provided below does not list the actual values supported in hardware), how the
adaptation rule constraints minimum, maximum and closest are evaluated in determining the
operational CIR or PIR for the 7210 SAS, assume there is a queue where the administrative
CIR and PIR values are 90Kbps and 150 Kbps, respectively. If the adaptation rule is
minimum, the operational CIR and PIR values will be 128Kbps and 192Kbps respectively,
as it is the native hardware rate greater than or equal to the administrative CIR and PIR values.
If the adaptation rule is maximum, the operational CIR and PIR values will be 64Kbps and
128Kbps. If the adaptation rule is closest, the operational CIR and PIR values will be 64Kbps
and 128Kbps, respectively, as those are the closest matches for the administrative values that
are even multiples of the 64 Kbps rate step.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide53
Page 54
QoS Overview
Meter - Committed Burst Size
The committed burst size parameter specifies the maximum burst size that can be transmitted
by the source at the CIR while still complying with the CIR. If the transmitted burst is lower
than the CBS value then the packets are marked as in-profile by the meter to indicate that the
traffic is complying meter configured parameters.
The operational CBS set by the system is adapted from the user configured value by using the
minimum constraint. The burst size configured by the user affects the rate step-size used by
the system. The system uses the step size in a manner that both the burst-size and rate
parameter constraints are met.
Meter – Maximum Burst Size
For trTCM (policer using two-rate three-color marker) The maximum burst size parameter
specifies the maximum burst size that can be transmitted by the source at the PIR while
complying with the PIR. If the transmitted burst is lower than the MBS value then the packets
are marked as out-profile by the meter to indicate that the traffic is not complying with CIR,
but complying with PIR.
For srTCM (policer using single rate three color marker), the maximum burst size parameter
specifies the maximum burst size that can be transmitted by the source while not complying
with the CIR. If the transmitted burst is lower than the MBS value then the packets are marked
as out-profile by the meter to indicate that the traffic is not complying with CIR. If the packet
burst is higher than MBS then packets are marked as red are dropped.
The operational MBS set by the system is adapted from the user configured value by using
the minimum constraint. The burst size configured by the user affects the rate step-size used
by the system. The system uses the step size in a manner that both the burst-size and rate
parameter constraints are met.
Meter – Ingress Profile Assignment
On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C meter can operate in two modes – profile
mode (also color-aware mode) and non-profile mode (also called color-blind mode). On 7210
SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, SAP Ingress meters operate in either profile mode
or non-profile mode.
547210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 55
QoS Policies
To enable ‘color-aware mode’/’profile mode’, must assign the initial ingress profile explicitly
using the in/out profile commands using the classification entries or use DEI for it. If use-dei
command is enabled, then the in/out profile value assigned by the user is ignored (in other
words DEI takes priority). It is recommended to use the default value of ‘undefined’ for
ingress profile when DEI is enabled. To enable color-blind metering, user must not assign any
initial ingress profile value (and the default undefined is used). With both color-aware and
color-blind metering, the final color is assigned by the meter associated with the FC, based
on the configured rates. The packet within CIR is assigned a final profile value of ‘in-profile’
and a packet that exceeds CIR and is within PIR is assigned a final profile value of ‘outprofile’. Anything above PIR is dropped.
The following functionality is implemented to support color-aware/color-blind metering:
•Ingress profile assignment as part of ingress classification (initial profile value)
•On SAP ingress, if the operator trusts the markings in the packet received from the
customer device, then
→ DEI can be used to assign the initial profile value; Use of DEI is enabled per FC.
→ Packet priority fields (for example: Dot1p, IP DSCP, etc.) can be used for
classification to a FC
→ Packet priority fields (for example: Dot1p, IP DSCP, etc.) can be used for
classification to a FC and also assign the profile
→ Profile assigned using DEI overrides initial profile value assigned using explicit
classification rules, however it is recommended to not assign profile explicitly
when DEI use is enabled
•On SAP ingress, if the packet header priority value is not trusted, user has the
following options:
→ Packet fields (e.g. mac-criteria & ip-criteria) can be used for classification to a
FC and assign the profile
→ If no classification entry matches or if the matched classification entry does not
explicitly assign profile, these packets are assigned a value of undefined
•Ingress Profile assignment as part of ingress policing/metering (lets call this the final
profile value)
→ If the initial profile value is assigned to a packet and if it is in-profile, it attempts
to take tokens from CBS bucket. If available, its final profile value is set to inprofile. If not enough tokens in CBS bucket, check MBS bucket. If sufficient
tokens are available in MBS bucket, the packets final profile value is set to outprofile.; If not enough tokens in MBS bucket its dropped.; This color-aware
mode of operation for in-profile packets
→ If the initial profile value is assigned to a packet and if it is out-profile, it attempts
to take tokens from MBS bucket. If available, its final profile value is set to outprofile. If not enough tokens in MBS bucket, its dropped.; This is color-aware
mode of operation for out-profile packets.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide55
Page 56
QoS Overview
Meter Counters
The router maintains counters for meters within the system for granular billing and
accounting.
Each meter maintains the following counters:
→ If the initial profile value is assigned to a packet and if it is undefined, it attempts
to take tokens from CBS bucket. If available, its final profile value is set to inprofile. If not, check for enough tokens in MBS bucket and if available its final
profile is set to out-profile. If not enough tokens in MBS bucket its dropped. This
is color-blind mode of operation.
•Counter to count packets and octets forwarded in-profile
•Counter to count packets and octets forwarded out-of-profile
•Counter to count packets and octets dropped
Accounting record support available on each of the platforms is listed in the 7210 SAS
System Management Guide under the “Accounting Records/Logs” section.
Meter Modes
The 7210 SAS-K devices supports following meter modes:
•srtcm: Single Rate Three Color Marking
•trtcm: Two Rate Three Color Marking
In srtcm the CBS and MBS Token buckets are replenished at single rate, that is, CIR where
as in case of trtcm CBS and MBS buckets are individually replenished at CIR and PIR rates,
respectively. Trtcm mode implements the policing algorithm defined in RFC4115.
Meter - QoS Override
The QoS Override feature support on access SAP allows the user to override the meter
parameters such as CBS, MBS, Rate (CIR and PIR), Mode, and Adaptation rule (CIR and
PIR) at the SAP context.
The values are taken from the SAP-Ingress policy, when the meter parameter values are not
overridden.
567210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 57
QoS Policies
The configuration guidelines of QoS Override are:
•QoS override commands can be used only for the meters or policers defined in the
SAP ingress policy used with access SAPs.
•QoS override commands are not allowed when the attached policy is of an exclusive
type.
•QoS override commands are not allowed on Mirror destination SAPs.
•QoS override commands are not supported for service egress QoS policies used with
access SAPs.
•QoS override commands are not supported for ingress and egress QoS policies used
with access-uplink ports.
•QoS override commands are not supported ingress and egress QoS policies used with
network ports.
Meter QoS Override - Configuring Meter Override parameters
The following example displays the meter override parameter configuration:
*A:dut-h>config>service>epipe>sap>ingress>meter-override>meter$ info detail
----------------------------------------------
----------------------------------------------
mode trtcm2
adaptation-rule cir min pir max
cbs 1000 kbits
mbs 2000 kbits
rate cir 1000 pir 10000
Meter – support on various platforms
The following support is available on different platforms:
•On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C - Service meter can be
provisioned on access sap ingress within service ingress QoS policies.
Service Ingress QoS Policies
Service ingress QoS policies define ingress service forwarding class queues or meters and
map traffic flows to forwarding class on access SAP ingress.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide57
Page 58
QoS Overview
Note: Not all 7210 platforms support queues and meters on service ingress. The support
varies across different platforms. Please read the subsequent chapters/sections for more
information.
On 7210 SAS-K platforms, when a service ingress QoS policy is created, it always has one
queue defined that cannot be deleted. The queue is used to queue all the traffic, both the
unicast traffic and the multipoint traffic. These queues exist within the definition of the
policy. The queues only get instantiated in hardware when the policy is applied to a SAP.
Multipoint queues are instantiated only if the SAP ingress policy defines a multipoint queue.
By default, software does not allocate any multipoint queues.
In the simplest service ingress QoS policy, all traffic is treated as a single flow and mapped
to a single queue, including all flooded traffic.
The required elements to define a service ingress QoS policy are:
A unique service ingress QoS policy ID.
•A QoS policy scope of template or exclusive.
•At least one default forwarding class queue. The parameters that can be configured
for a queue are discussed in Queues and Queue Parameters.
Optional service ingress QoS policy elements for 7210 SAS-K platforms include:
•Additional unicast queues or multicast queues up to a total of 8 queues.
•Additional unicast meters or multicast meters up to a total of 16 meters.
•QoS policy match criteria to map packets to a forwarding class.
Each queue/meter can have unique queue/meter parameters to allow individual shaping or
rate limiting of the flow mapped to the forwarding class. The Figure 2 below depicts service
traffic being classified into three different forwarding classes.
587210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 59
Figure 2: Traffic Queuing Model for Forwarding Classes
QoS Policies
Default Service Ingress Policy
Service ingress QoS policy ID 1 is reserved for the default service ingress policy. The default
policy cannot be deleted or changed. The default service ingress policy is implicitly applied
to all SAPs which do not explicitly have another service ingress policy assigned. In the
default policy, all traffic is mapped to the default forwarding class which uses a queue by
default. The characteristics of the default policy are listed in Table 11.
Table 11: Default Service Ingress Policy ID 1 Definition for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C
CharacteristicItemDefinition
QueueQueue 11 (one) queue all unicast traffic and multicast traffic:
•Forward Class: best-effort (be)
•CIR = 0
•PIR = max
•MBS = 60 Kilobytes
•CBS = 10 Kilobytes
•Priority= 1
•Weight= 1
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide59
Page 60
QoS Overview
Table 11: Default Service Ingress Policy ID 1 Definition for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C
CharacteristicItemDefinition
FlowsDefault Forwarding
Class (be)
1 (one) flow defined for all traffic:
•All traffic mapped to best-effort (be)
Service Ingress Classification
Mapping flows to forwarding classes is controlled by comparing each packet to the match
criteria in the Service Ingress QoS policy applied to an access SAP. The ingress packet
classification to forwarding class is subject to a classification policy provisioned.
Service Ingress Classification
On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C devices, on access SAP ingress user has
an option to use either Dot1p classification or IPv4 DSCP classification or IPv4 packet header
fields or IPv6 packet header fields or MAC packet header fields. The Dot1p or DSCP
classification rules to be used are defined in the Dot1p and DSCP classification policy and
associated with the SAP ingress policy. The DSCP and Dot1p classification policies can be
configured in the same QoS policy. The IPv4 or IPv6 or MAC criteria can be configured in
the SAP ingress policy.
When packets are received on an access SAP, the following steps are used to determine the
FC to assign to the packet.
Step 1.Match IP criteria entries with the IP packet header fields in the packet. Assign the
FC corresponding to the first entry which matches with IP packet header field
values in the packet. If it is not an IP packet or if there is no match, go to next step.
Step 2.Match MAC criteria entries with the MAC packet header fields in the packet.
Assign the FC corresponding to the first entry which matches with MAC packet
header field values in the packet. If there is no match, go to next step.
Step 3.Match the IP DSCP value in the packet with the value configured in each of the IP
DSCP entry defined in the DSCP classification policy. Assign the FC
corresponding to the first entry which matches with IP DSCP value in the packet.
If it is not an IP packet or if there is no match, go to next step.
Step 4.Match the Dot1p value in the packet (if available) with the value configured in each
of the Dot1p entry defined in the Dot1p classification policy. Assign the FC
corresponding to the first entry which matches with Dot1p value in the packet. If
there is no match, go to next step.
607210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 61
Step 5.Assign the default FC.
Service Ingress Classification– IP and Mac Packet fields
The IP and MAC match criteria can be very basic or quite detailed. IP and MAC match
criteria are constructed from policy entries. An entry is identified by a unique, numerical
entry ID. A single entry cannot contain more than one match value for each match criteria.
Each match entry has an action which specifies: the forwarding class of packets that match
the entry. The entries are evaluated in numerical order based on the entry ID from the lowest
to highest ID value. The first entry that matches all match criteria has its action performed.
Table 12 lists the packets fields used for match-criteria used for access SAP ingress
classification on the different 7210 platforms.
Table 12: Service Ingress QoS Policy IP Match Criteria for 7210 SAS-K 2F2T1C and
7210 SAS-K 2F4T6C
QoS Policies
IP Criteria Services applicable on
7210 SAS-K 2F2T1C
•IP DSCPAccess SAPs in Epipe,
VPLS,IES, RVPLS services
•IP source address
and mask, IP
Access SAPs in Epipe,
VPLS,IES, RVPLS services
destination address
and mask, IP
protocol, TCP/UDP
source port and
fragment field
•TCP/UDP
destination port
Services applicable on
7210 SAS-K 2F4T6C
Access SAPs in Epipe,
VPLS, IES, VPRN,
RVPLS services
Access SAPs in Epipe,
VPLS, IES, VPRN,
RVPLS services
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide61
Page 62
QoS Overview
Table 13: Service Ingress QoS Policy IPv6 Criteria for 7210 SAS-K 2F2T1C and 7210
SAS-K 2F4T6C
IPv6 Criteria Services applicable on
7210 SAS-K 2F2T1C
•DSCP value,
Destination IPv6
Access SAPs in Epipe,
VPLS,RVPLS services
Services applicable on
7210 SAS-K 2F4T6C
Access SAPs in Epipe,
VPLS,RVPLS services.
address and mask
match, Destination
port TCP/UDP port
match, Source IPv6
address and mask
match, Source port
TCP/UDP port
match
Table 14: Service Ingress QoS Policy MAC Match Criteria for 7210 SAS-K 2F2T1C and
7210 SAS-K 2F4T6C
MAC Match Criteria Services applicable on
7210 SAS-K 2F2T1C
•IEEE 802.1p/Dot1p
value/mask (for both
Access SAPs in Epipe,
VPLS,RVPLS services
Services applicable on
7210 SAS-K 2F4T6C
Access SAPs in Epipe,
VPLS,RVPLS services.
inner and outer tag
separately), Source
MAC address/mask,
Destination MAC
address/mask,
EtherType Value/
Mask, outer VLAN,
and inner VLAN tag
value
Note that 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C does not support configuring of
the frame-type match criteria and the default frame type configured is Ethernet - II. Table 15
627210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 63
QoS Policies
Table 15: MAC Match Ethernet Frame Types
Note: The default frame type configured is Ethernet - II
Frame FormatDescription
802.3IEEE 802.3 Ethernet frame. Only the source MAC, destination MAC and
IEEE 802.1p value are compared for match criteria.
802dot2-llcIEEE 802.3 Ethernet frame with an 802.2 LLC header. Only the source
MAC and destination MAC address are compared for match criteria.
802dot2-snapIEEE 802.2 Ethernet frame with 802.2 SNAP header. Only the source MAC
and destination MAC address are compared for match criteria.
Ethernet-IIEthernet type II frame where the 802.3 length field is used as an Ethernet
type (Etype) value. Etype values are two byte values greater than 0x5FF
(1535 decimal).
Table 16 lists the criteria that can be matched for the various MAC frame types.
Table 16: MAC Match Criteria Frame Type Dependencies
Frame FormatSource MACDest MACIEEE 802.1p ValueEtype Value
802.3YesYesYesNo
802dot2-llcYesYesYesNo
802dot2-snapYesYesYesNo
ethernet-IIYesYesYesYes
Service Egress QoS Policies
Service egress queues are implemented at the transition from the service core network to the
service access network on access SAPs. The advantages of per-service queuing before
transmission into the access network are:
•Per-service egress sub-rate capabilities.
•More granular, fairer scheduling per-service into the access network.
•Per-service statistics for forwarded and discarded service packets.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide63
Page 64
QoS Overview
The subrate capabilities and per-service scheduling control are required to make multiple
services per physical port possible. With egress shaping, it is possible to support more than
one service per port. It prevents traffic from single service from bursting to the available port
bandwidth and starving other services.
For accounting purposes, per-service statistics can be logged. When statistics from service
ingress queues are compared with service egress queues, the ability to conform to per-service
QoS requirements within the service core can be measured.
Service egress QoS policies define egress queues and map forwarding class flows to queues.
In the simplest service egress QoS policy, all forwarding classes are treated like a single flow
and mapped to a single queue. To define a basic egress QoS policy, the following are
required:
•A unique service egress QoS policy ID.
•A QoS policy scope of template or exclusive.
•At least one defined default queue.
Optional service egress QoS policy elements include:
•Additional queues up to a total of 8 separate queues. A forwarding class queue is
shared by unicast and multipoint (BUM) traffic type mapped to that forwarding class.
•IEEE 802.1p priority value remarking based on forwarding class.
•Option to use IP DSCP values for marking based on FC.
Each queue in a policy is associated with one of the forwarding classes. Each queue can have
its individual queue parameters allowing individual rate shaping of the forwarding class(es)
mapped to the queue. More complex service queuing models are supported in the router
where each forwarding class is associated with a dedicated queue. The forwarding class
determination per service egress packet is determined at ingress. If the packet ingressed the
service on the same router, the service ingress classification rules determine the forwarding
class of the packet. If the packet is received, the forwarding class is marked in the tunnel
transport encapsulation (for example: QinQ encapsulated packet).
Default Service Egress Policy
Service egress QoS policy ID 1 is reserved as the default service egress policy. The default
policy cannot be deleted or changed. The default access egress policy is applied to all SAPs
service egress policy explicitly assigned. The characteristics of the default policy are listed in
the following Table 17.
647210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 65
QoS Policies
Table 17: Default Service Egress Policy ID 1 Definition
Characteristic Item Definition
Queues Queue 11 (one) queue defined for all traffic classes:
•CIR = 0
•PIR = max (line rate)
•MBS = 60 Kilobytes
•CBS = 10 Kilobytes
•Priority= 1
•Weight= 1
Flows Default
Action
1 (one) flow defined for all traffic classes:
•All traffic mapped to queue 1 with
no marking of IEEE 802.1p values
Buffer Pools
Buffer pools are used to manage the packet buffer memory resources used to store packets
and absorb bursts received on a queue.
Buffer pools on 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C
The total amount of available buffers (~64MB on 7210 SAS-K 2F2T1C and 7210 SAS-K
2F4T6C) is divided among the 5 buffer pools listed below. In addition some of the buffers are
reserved for system internal use (such as, Multicast queues).
•CBS buffer pool
•Ingress non-ring MBS pool
•Egress non-ring MBS pool
•Ingress ring MBS pool
•Egress ring MBS pool
CBS buffer pool is used to allocate buffers towards committed burst size (CBS) configured
for ingress and egress queues on the node and some internal system queues.
The CBS pool allocation on different SAS-K platforms is as given below:
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide65
Page 66
QoS Overview
•On 7210 SAS-K 2F2T1C, the CBS pool is used to allocate buffers towards CBS
configured for ingress and egress queues on access SAP, and ingress and egress
queues on access-uplink port.
•On 7210 SAS-K 2F4T6C, the CBS pool is used to allocate buffers towards CBS
configured for ingress and egress queues on access SAP, ingress and egress queues
on access-uplink ports and ingress and egress queues on network ports.
MBS pool is divided into four pools as shown above. The Ingress and Egress non-ring MBS
buffer pool and the Ingress and Egress ring MBS buffer pool. These MBS buffer pools can
be over-subscribed.
The Ingress and Egress ‘non-ring’ MBS buffer pool is used to allocate buffers towards the
Maximum Burst Size (MBS) configured for ingress queues and egress queues respectively
on ‘non-ring’ ports. On both 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, the access
ports are considered to be ‘non-ring’ ports by default (user does not have an option to change
it). The Ingress non-ring MBS pool is used to allocate buffers towards all ingress queues
configured on access SAPs. Similarly the egress non-ring MBS pool is used to allocate
buffers towards all egress queues configured on access SAPs.
The Ingress and Egress ‘ring’ MBS buffer pool is used to allocate buffers towards Maximum
Burst Size (MBS) configured for ingress queues and egress queues respectively on ‘ring’
ports.
Assignment of ring ports and ring MBS buffer pool on different SAS-K platforms is as given
below:
•On 7210 SAS-K 2F2T1C, all access-uplink ports are considered to be `ring' ports and
the Ingress and Egress ring MBS buffer pool is used to allocate buffers towards
access-uplink port ingress and egress queues respectively.
•On 7210 SAS-K 2F4T6C, all network ports and access-uplink ports are considered
to be `ring' ports by default (user does not have an option to change it) and the Ingress
and Egress ring MBS buffer pool is used to allocate buffers towards network port and
access-uplink port ingress queues and network port and access-uplink port egress
queues respectively.
The amount of memory allocated towards these pools is software defined and not user
configurable. The show pools <port-id> system can be used to display total amount of buffers
per pool and the amount of buffers in use per pool.
A:dut-i# show pools 1/1/1 system
===============================================================================
Pool Information
===============================================================================
Port : 1/1/1
Application : System
MMU Total : 65536 KB
667210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 67
MMU CBS : 14336 KB MMU CBS In Use : 2240 KB
Ingress Ring : 11776 KB Ingress Ring In Use: 0 KB
Ingress NonRing : 11776 KB Ingress NonRing In*: 0 KB
Egress Ring : 11776 KB Egress Ring In Use : 0 KB
Egress NonRing : 11776 KB Egress NonRing In *: 0 KB
When 7210 SAS-K 2F2T1C is deployed in a ring environment, the access-uplink ports are
typically used to connect the node to ring, similarly on 7210 SAS-K 2F4T6C, users will
typically use the network ports to join the node into a ring. Therefore, these ports are
designated as the ring ports. These ring ports carry traffic from the head-end towards the node
(that is, 7210 SAS-K), dropping traffic off to user/customer locations. Simultaneously, these
ring ports carry traffic from the user/customer to the head-end. In other words, traffic received
from the user/customer is added to the ring and sent out towards the service edge, where
services are terminated. The traffic in both these directions is typically admitted into the ring
after being shaped and groomed. That is in the upstream direction (that is, in the direction of
customer to service edge) the SLA is enforced at service ingress points (that is, typically
access SAPs) and the traffic is shaped and groomed, similarly in the downstream direction
(that is, in the direction of service edge to customer) it is done by the service edge device or
the access aggregation device. In other words, the downstream traffic should typically be
allowed to pass through the intermediate nodes of the ring, without contention with and
prioritized over the traffic that is received from the customer and being added into the ring by
the nodes on the ring.
QoS Policies
On 7210 SAS-K 2F2T1C, the access-uplink ports are designated as ‘ring’ ports and access
ports are designated as ‘non-ring’ ports. Traffic going from any access-uplink to another
access-uplink port is identified as ‘ring’ traffic. Traffic going from an access port to any
access-uplink port, or traffic going from any access-uplink port to an access port (in egress),
or traffic going from an access port to another access port is identified as ‘non-ring’ traffic.
On 7210 SAS-K 2F4T6C, the network ports and access-uplink ports are designated as ‘ring’
ports and access ports are designated as ‘non-ring’ ports. Traffic going from any network port
or access-uplink to another network port or access-uplink port is identified as ‘ring’ traffic.
Traffic going from an access port to any network port or access-uplink port, or traffic going
from any network port or access-uplink port to an access port (in egress), or traffic going from
an access port to another access port is identified as ‘non-ring’ traffic.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide67
Page 68
QoS Overview
To ensure that the traffic received on ring ports is prioritized over traffic received on non-ring
access ports, a separate ‘Ring’ MBS buffer pool (one each for ingress and egress) is provided
for traffic received and sent out of ring ports. In addition, on network port egress and accessuplink egress (where shaped customer (access) traffic and ‘ring’ traffic share the ‘ring’ pool)
two additional ring slopes (for a total of 4 configurable WRED slopes) are provided to
prioritize the ‘ring’ traffic. Each egress queue on the network port and access uplink port
supports 4 slopes per queue – ring high-slope, ring low-slope, non-ring high-slope and nonring low-slope (in the CLI command the ring slopes are configured using the high-slope-ring
and low-slope-ring and the non-ring slopes are configured using the high-slope and lowslope). Ring high-slope and Ring low-slope is used for in-profile and out-of-profile QoS
profile ‘ring’ traffic. Non-ring high-slope and low-slope is used for in-profile and out-ofprofile ‘non-ring’ traffic. Slope parameters (start-avg, max-avg, max-Prob) of 4 slopes can be
configured such that the ring traffic is prioritized over the ‘non-ring’ traffic (that is, traffic
being added onto the ring) in congestion scenarios.
A separate ‘non-Ring’ MBS buffer pool for traffic received and sent out of access ports along
with 2 configurable WRED slopes is supported. Each queue on the access ports supports 2
slopes per queue –non-ring high-slope and non-ring low-slope. Non-ring high-slope and lowslope is used for in-profile and out-of-profile ‘non-ring’ traffic. The Non-Ring buffer pool
(one each for ingress and egress) is used to allocate buffers for non-ring traffic.
The usage of buffer pools for different traffic flows is as given below:
On 7210 SAS-K 2F2T1C the ring and non-ring buffer pools are used by the following traffic
flows:
•Traffic received on access-uplink SAP and sent out of access-uplink SAP, uses the
ring MBS buffer pool for MBS buffers on access-uplink port ingress and accessuplink port egress. In this case, ring high-slope is used for in-profile traffic and ring
low-slope is used for out-of-profile traffic for both access-uplink ingress and accessuplink egress.
•Traffic received on access SAP and sent out of access-uplink SAP, uses the non-ring
MBS buffer pool for MBS buffers on access SAP ingress and uses the ring MBS
buffer pool for MBS buffers on access-uplink SAP egress. In this case, non-ring high
slope and non-ring low slope is used on both access SAP ingress and access-uplink
egress.
•Traffic received on access-uplink SAP and sent out of another access SAP uses ring
MBS buffer pool for MBS buffers on access-uplink SAP ingress and the non-ring
MBS buffer pool for MBS buffers on access SAP egress. In this case, ring high-slope
and ring low-slope is used on access-uplink ingress and non-ring high-slope and nonring low-slope is used on access egress.
•Traffic received on access SAP and sent out of another access SAP uses the non-ring
MBS pool for MBS buffers for both access SAP ingress and access SAP egress. In
this case, non-ring high-slope and non-ring low-slope is used on both access ingress
and access egress.
687210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 69
QoS Policies
On 7210 SAS-K 2F4T6C the ring and non-ring buffer pools are used by the following traffic
flows:
•Traffic received on network port and sent out of network port, uses the ring MBS
buffer pool for MBS buffers on network port ingress and network port egress. In this
case, ring high-slope is used for in-profile traffic and ring low-slope is used for outof-profile traffic for both network port ingress and port egress.
•Traffic received on access SAP and sent out of port, uses the non-ring MBS buffer
pool for MBS buffers on access SAP ingress and uses the ring MBS buffer pool for
MBS buffers on network port egress. In this case, non-ring high slope and non-ring
low slope is used on both access SAP ingress and network port egress.
•Traffic received on network port and sent out of another access SAP uses ring MBS
buffer pool for MBS buffers on network port ingress and the non-ring MBS buffer
pool for MBS buffers on access SAP egress. In this case, ring high-slope and ring
low-slope is used on network port ingress and non-ring high-slope and non-ring lowslope is used on access egress.
•Traffic received on access-uplink SAP and sent out of access-uplink SAP, uses the
ring MBS buffer pool for MBS buffers on access-uplink port ingress and accessuplink port egress. In this case, ring high-slope is used for in-profile traffic and ring
low-slope is used for out-of-profile traffic for both access-uplink ingress and accessuplink egress.
•Traffic received on access SAP and sent out of access-uplink SAP, uses the non-ring
MBS buffer pool for MBS buffers on access SAP ingress and uses the ring MBS
buffer pool for MBS buffers on access-uplink SAP egress. In this case, non-ring high
slope and non-ring low slope is used on both access ingress and access-uplink egress.
•Traffic received on access-uplink SAP and sent out of another access SAP uses ring
MBS buffer pool for MBS buffers on access-uplink SAP ingress and the non-ring
MBS buffer pool for MBS buffers on access SAP egress. In this case, ring high-slope
and ring low-slope is used on access-uplink ingress and non-ring high-slope and nonring low-slope is used on access egress.
•Traffic received on access SAP and sent out of another access SAP uses the non-ring
MBS pool for MBS buffers for both access SAP ingress and access SAP egress. In
this case, non-ring high-slope and non-ring low-slope is used on both access ingress
and access egress.
Configuration Guidelines for CBS and MBS
•For configuring the CBS value, the following must be considered:
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide69
Page 70
QoS Overview
Slope Policies
The available buffer space is partitioned into buffer pools as described above. The buffers for
a queue are allocated from the buffer pool. Slope policies define the RED slope
characteristics.
→ If Jumbo frames need to be accommodated, then CBS must be set to at least a
minimum of 10Kbytes. The default value set for the queue allows for jumbo
frames. It is recommended to set the CBS to twice the amount of maximum frame
size the queues is expected to carry.
→ CBS pool cannot be oversubscribed.
•For configuring the MBS value, the following must be considered:
→ MBS value determines the maximum delay a packet can experience when using
that queue. It should be set to a value such that the delay is acceptable.
→ It is recommended to set the minimum value for MBS to be about 4 to 5 times
the maximum size of the frame the queue is expected to carry to ensure better
scheduling performance.
By default, each queue on the port is associated with slope-policy default which disables the
high-slope and low-slope for all the queues.
Note: If WRED is not configured, then taildrop is used.
RED Slopes
Operation and Configuration of RED Slopes
On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C each queue provides user with the
following:
•An option to use 2 slopes per queue on non-ring ports - high-priority RED slope and
a low-priority RED slope
•An option to use 4 slopes per queue on ring ports – non-ring high-priority RED slope,
a non-ring low-priority RED slope, a ring high-priority RED slope, and a ring lowpriority RED slope
707210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 71
The high-priority RED slope manages access to the shared portion of the buffer pool for high
priority or in-profile packets. The low-priority RED slope manages access to the shared
portion of the buffer pool for low-priority or out-of-profile packets. Please read the
description in section Buffer pools on 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C
By default, the high-priority and low-priority slopes are disabled.
When a queue depth exceeds the queue’s CBS, packets received on that queue must contend
with other queues exceeding their CBS for shared buffers. To resolve this contention, RED
slopes are used to determine buffer availability on a packet by packet basis. A packet that was
either classified as high priority or considered in-profile is handled by the high-priority RED
slope. This slope should be configured with RED parameters that prioritize buffer availability
over packets associated with the low-priority RED slope. Packets that had been classified as
low priority or out-of-profile are handled by this low-priority RED slope.
Simplified overview of RED for 7210 SAS-K platform
QoS Policies
The following is a simplified overview of how a RED slope determines shared buffer
availability on a packet basis:
•The RED function keeps track of shared buffer utilization and shared buffer average
utilization.
•At initialization, the utilization is 0 (zero) and the average utilization is 0 (zero).
•When each packet is received, the current average utilization is plotted on the slope
to determine the packet’s discard probability.
•A random number is generated associated with the packet and is compared to the
discard probability.
•The lower the discard probability, the lower the chances are that the random number
is within the discard range.
•If the random number is within the range, the packet is discarded which results in no
change to the utilization or average utilization of the shared buffers.
•A packet is discarded if the utilization variable is equal to the shared buffer size or if
the utilized CBS (actually in use by queues, not just defined by the CBS) is
oversubscribed and has stolen buffers from the shared size, lowering the effective
shared buffer size equal to the shared buffer utilization size.
•The new shared buffer average utilization is used as the shared buffer average
utilization next time a packet’s probability is plotted on the RED slope.
•When a packet is removed from a queue (if the buffers returned to the buffer pool are
from the shared buffers), the shared buffer utilization is reduced by the amount of
buffers returned. If the buffers are from the CBS portion of the queue, the returned
buffers do not result in a change in the shared buffer utilization.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide71
Page 72
QoS Overview
Figure 3: RED Slope Characteristics
A RED slope itself is a graph with an X (horizontal) and Y (vertical) axis. The X-axis plots
the percentage of shared buffer average utilization, going from 0 to 100 percent. The Y-axis
plots the probability of packet discard marked as 0 to 1. The actual slope can be defined as
four sections in (X, Y) points (Figure 3):
•Section A is (0, 0) to (start-avg, 0). This is the part of the slope that the packet discard
value is always zero, preventing the RED function from discarding packets when the
shared buffer average utilization falls between 0 and start-avg.
•Section B is (start-avg, 0) to (max-avg, max-prob). This part of the slope describes a
linear slope where packet discard probability increases from zero to max-prob.
•Section C is (max-avg, max-prob) to (max-avg, 1). This part of the slope describes
the instantaneous increase of packet discard probability from max-prob to one. A
packet discard probability of 1 results in an automatic discard of the packet.
•Section D is (max-avg, 1) to (100%, 1). On this part of the slope, the shared buffer
average utilization value of max-avg to 100% results in a packet discard probability
of 1.
Plotting any value of shared buffer average utilization will result in a value for packet discard
probability from 0 to 1. Changing the values for start-avg, max-avg and max-prob allows the
adaptation of the RED slope to the needs of the different queues (for example: access port
queues) using the shared portion of the buffer pool, including disabling the RED slope.
727210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 73
Slope Policy Parameters
The elements required to define a slope policy are:
•A unique policy ID
•The high-slope (for in-profile packets) and low-slope (for out-of-profile packets) per
queue. And configurable parameters on each slope are start-avg, max-avg, and maxprob.
•The ring and non-ring high and low slopes for access-uplink port egress.
•On 7210 SAS-K 2F4T6C, the ring and non-ring high and low slopes for network port
egress.
Table 18: Default slope policy definition for 7210 SAS-K 2F2T1C and 7210 SAS-K
QoS Policies
2F4T6C
ParameterDescription
high-slopestart-avg 70 Percent
max-avg 90 Percent
max-prob 80 Percent
low-slopestart-avg 50 Percent
high-slope-ringstart-avg 70 Percent
low-slope-ringstart-avg 50 Percent
Schedulers
Scheduler on 7210 SAS-K
7210 SAS-K platforms support Strict Priority and WFQ mode of scheduling or a mix of both.
max-avg 75 Percent
max-prob 80 Percent
max-avg 90 Percent
max-prob 80 Percent
max-avg 75 Percent
max-prob 80 Percent
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide73
Page 74
CPU Queues on SAS-K
On 7210 SAS-K 2F2T1C, Schedulers are used at SAP ingress, SAP egress, Access Uplink
Port ingress and Access-uplink port egress.
On 7210 SAS-K 2F4T6C, Schedulers are used at SAP ingress, SAP egress, Network port
ingress, network port egress, Access Uplink Port ingress and Access-uplink port egress.
The scheduler uses 2 loops - the CIR loop and PIR loop, each with 4 priorities. The configured
priority of the queue determines the service order of the queue in the CIR loop and the PIR
loop. The scheduler first goes through the CIR loop, where it services all the queues which
are operating at less than CIR rate according to their priority (that is, higher priority queues
get services earlier than lower priority queues). It then goes through the PIR loop, where it
services all the queues which are operating above the CIR rate (but less than PIR rate)
according to their priority (that is, higher priority queues get services earlier than lower
priority queues). If there are multiple queues configured with the same priority, in the CIR
loop the queues are scheduled using WFQ, with the configured weight (that is, pir-weight) of
the queue used to determine the proportion of the available bandwidth that is given to the
queue. In the PIR loop, the queues are scheduled using WFQ, with the configured weight (that
is, pir-weight) of the queue used to determine the proportion of the available bandwidth that
is given to the queue (using WFQ).
CPU Queues on SAS-K
The packets that are destined to the CPU are prioritized based on the application. Some of the
applications that are prioritized are Layer 2 data packets (a copy of which is sent to CPU for
MAC learning), EFM, CFM, STP, LACP, ICMP, etc. The packets destined to the CPU are
classified internally and are put into the correct CPU queue. These packets are rate-limited to
prevent DoS attacks. The software programs the classification entries to identify these
packets and assigns appropriate bandwidth and priority to them. It is not configurable by the
user.
Egress Port Rate Limiting
This features allows the user to limit the bandwidth available on the egress of the port to a
value less than the maximum possible link bandwidth. On some platforms, it also allows the
user to control the amount of burst sent out.
747210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 75
Forwarding Classes
7210 SAS devices support multiple forwarding classes and class-based queuing, so the
concept of forwarding classes is common to all of the QoS policies. Each forwarding class
(also called Class of Service (CoS)) is important only in relation to the other forwarding
classes. A forwarding class provides network elements a method to weigh the relative
importance of one packet over another in a different forwarding class.
Queues are created for a specific forwarding class to determine the manner in which the queue
output is scheduled. The forwarding class of the packet, along with the in-profile or out-ofprofile state, determines how the packet is queued and handled (the per hop behavior (PHB))
at each hop along its path to a destination egress point. 7210 SAS devices support eight (8)
forwarding classes (Table 19).
QoS Policies
Table 19: Forwarding Classes
FC-IDFC NameFC
Designatio
n
7Network
NCNC2Intended for network control traffic.
DiffServ
Name
Notes
Control
6High-1H1NC1Intended for a second network control
class or delay/jitter sensitive traffic.
5ExpeditedEFEFIntended for delay/jitter sensitive traffic.
4High-2H2AF4Intended for delay/jitter sensitive traffic.
3Low-1L1AF2Intended for assured traffic. Also is the
default priority for network management
traffic.
2AssuredAFAF1Intended for assured traffic.
1Low-2L2CS1Intended for BE traffic.
0Best EffortBEBE
Note that Table 19 presents the default definitions for the forwarding classes. The forwarding
class behavior, in terms of ingress marking interpretation and egress marking, can be changed
by QoS Policies.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide75
Page 76
Preclassification on 7210 SAS-K 2F4T6C
Forwarding-Class To Queue ID Mapping
There are 8 forwarding classes supported on 7210 SAS devices. Each of these FC is mapped
to a specific queue. By mapping FC to different queues the differential treatment is imparted
to various classes of traffic.
FC to Queue ID mapping
On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, user has an option to define up to 8
queues with an option to define the FC to queue mapping in service ingress policy, service
egress policy, network qos policy and network queue policy.
Preclassification on 7210 SAS-K 2F4T6C
On SAS-K 2F4T6C the front-panel ports oversubscribe the capacity of the forwarding
processor. A system defined pre-classification scheme is implemented (it is not user
configurable) to prioritize ingress packets for processing by the forwarding processor. It
prioritize packets based on Dot1p, DSCP and identifies some of the untagged L2 control
protocols into a high priority and low priority queues maintained on ingress per port. The
forwarding processor processes the high priority queue across all the ports before servicing
packets from the lower priority queues. In addition, the network ports are favored over access
ports by allocating more weight-age to the network ports during scheduling.
Preclassification on 7210 SAS-K 2F4T6C
On 7210 SAS-K 2F4T6C, the front-panel ports oversubscribe the capacity of the forwarding
processor. A system defined pre-classification scheme is implemented (it is not user
configurable) to prioritize ingress packets for processing by the forwarding processor. It
prioritize packets based on Dot1p, DSCP and identifies some of the untagged L2 control
protocols into a high priority and low priority queues maintained on ingress per port. The
forwarding processor processes the high priority queue across all the ports before servicing
packets from the lower priority queues. In addition, the network ports are favored over access
ports by allocating more weight-age to the network ports during scheduling.
767210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 77
QoS Policy Entities
Services are configured with default QoS policies. Additional policies must be explicitly
created and associated. There is one default service ingress QoS policy, one default service
egress policy, one default access egress QoS policy, one default network QoS policy and one
default port scheduler policy. Only one ingress QoS policy and one egress QoS policy can be
applied to a SAP or access/access-uplink port or network port.
When you create a new QoS policy, default values are provided for most parameters with the
exception of the policy ID, descriptions. Each policy has a scope, default action, a
description, and meters for ingress policies and queues for egress policies. By default, all
forwarding classes are mapped to Queue 1.
QoS policies can be applied to the following service types:
•Epipe and VPLS
→ On 7210 SAS-K 2F2T1C, SAP ingress policies and SAP egress policies are
supported on an Epipe access service access point (SAP), VPLS access SAP,
RVPLS SAP, and IES SAP.
QoS Policies
→ On 7210 SAS-K 2F4T6C, SAP ingress policies and SAP egress policies are
supported on an Epipe service access point (SAP), VPLS access SAP, RVPLS
SAP, IES access SAP and VPRN access SAP.
QoS policies can be applied to the following entities:
•Network QoS policy on access uplink port (7210 SAS-K 2F2T1C, 7210 SAS-K
2F4T6C)
•Network queue policy (egress) on access uplink port (7210 SAS-K 2F2T1C and 7210
SAS-K 2F4T6C);
•Network QoS policy on network port (7210 SAS-K 2F4T6C only)
The following information describes QoS implementation caveats:
•Creating additional QoS policies is optional.
•Default policies are created for service ingress, service egress, access service egress,
network, network queue, slope, remark, dot1p and DSCP classification and port
scheduler. (the policy types created varies across the platforms)
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide77
Page 78
Configuration Notes
•Associating a service or access or access uplink with a QoS policy other than the
default policy is optional.
787210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 79
Discard Eligibility Indicator (DEI)
based Classification and Marking
In This Section
This section provides information about the Discard Eligibility Indicator (DEI) feature that
describes the requirements for DEI based classification and marking for 7210 platforms.
Note: DEI classification and marking is applicable to 7210 SAS-K 2F2T1C and 7210 SASK 2F4T6C.
Topics in this section include:
•DEI based Classification and Marking
DEI based Classification and Marking
DEI based Classification on 7210 SAS-K 2F2T1C and 7210
SAS-K 2F4T6C
DEI bit in the received packet can be used to assign the ingress profile for the packet. If in the
received packet, DEI = 0, then the packet is considered to be GREEN or in-profile and if DEI
= 1, then the packet is considered to be YELLOW or out-of-profile. Use of DEI bit for ingress
classification can be enabled per FC. For a given FC, if DEI bit is used for ingress profile
assignment, then the profile defined in the ingress classification entry is ignored. For more
information, see “Queue – Ingress Profile Assignment” to understand the behavior when
profile is assigned to the packet on ingress.
On 7210 SAS-K 2F2T1C, DEI based classification is supported on access SAP ingress and
access-uplink port ingress.
On 7210 SAS-K 2F4T6C, DEI based classification is supported on access SAP ingress,
network port ingress and access-uplink port ingress.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide79
Page 80
DEI based Classification and Marking
DEI based marking
DEI bit can be used to mark the packet to carry the profile, assigned by an operator’s trusted
node at the ingress to the carrier’s network, to the subsequent nodes in the network. It allows
high-priority in-profile packet to be allocated appropriate resources by all the network nodes
on the path to the final destination. Similarly, it allows out-of-profile packets to be treated
with less preference compared to in-profile packets by all the network nodes on the path to
the final destination.
The following support is available for DEI based marking:
•On both, 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, option to mark DEI bits
for access SAP egress on access ports.
•On both, 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, option to mark DEI bits
for port egress on access uplink ports.
•On 7210 SAS-K 2F4T6C, Option to mark DEI bits for port egress on network ports.
•By default, in-profile packets are marked with DEI bit of 0 and out-of-profile packets
are marked with DEI bit of 1. The user has an option to mark all the packets
belonging to a FC to the same DEI value irrespective of its profile using the “forcede-mark” option.
•DEI bits can be marked only if the remark policy of remark-type dot1p or dot1p-dscp
is used.
Note: For information on the CLI commands for DEI, see Network QoS Policy Command
Reference, Service Egress Policy Command Reference and Service SAP QoS Policy
Command Reference.
807210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 81
Port Level Egress Rate-Limiting
In This Section
This section provides information to configure port level egress-rate using the command line
interface.
Topics in this section include:
•Overview
•Basic Configurations
•Configuration Descriptions
Overview
Egress port rate limiting allows the device to limit the traffic that egresses through a port to a
value less than the available link bandwidth.
This feature is useful when connecting the 7210 SAS to an Ethernet-over-SDH (EoSDH) or
microwave network, where the network allocates predetermined bandwidth to the nodes
connecting into it, based on the transport bandwidth requirement. When connecting to such a
network it is important that the traffic sent into the SDH node does not exceed the configured
values, since the SDH network does not have QoS capabilities and buffers required to
prioritize the ingress traffic.
Egress rate attributes include:
•Allows for per port configuration of the maximum egress port rate, using the egressrate CLI command.
•Ethernet ports configured as access and access uplink support this feature.
•The port scheduler distributes the available maximum egress bandwidth based on the
CIR/PIR configuration parameters provisioned for the queues.
•On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C the burst parameter is not user
configurable and set to a default by software.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide81
Page 82
Basic Configurations
•When ports are members of a LAG, all the ports use the same value for the egressrate and the max-burst parameters.
•If frame overhead accounting (also known as Frame-based accounting) is enabled,
then queue scheduler accounts for the Ethernet frame overhead.
•On 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C, when an egress-rate sub-rate
value is given, the access-uplink port egress queue rates that are specified using
percentages will use the egress-rate value instead of the port bandwidth if egress rate
is lesser than port bandwidth to configure the appropriate queue rates. Configuration
of egress port rate to different values will result in a corresponding dynamic
adjustment of rates for the egress queues configured on access-uplink ports.
•On 7210 SAS-K 2F4T6C, when an egress-rate sub-rate value is given, the network
port egress queue rates that are specified using percentages will use the egress-rate
value instead of the port bandwidth if egress rate is lesser than port bandwidth to
configure the appropriate queue rates. Configuration of egress port rate to different
values will result in a corresponding dynamic adjustment of rates for the egress
queues configured on network ports.
•When the egress-rate sub-rate value is set, CBS/MBS of the associated network
queues is not modified automatically. On 7210 SAS-K 2F2T1C and 7210 SAS-K
2F4T6C user has an option to change the CBS/MBS values, if need be.
Basic Configurations
To apply port level rate-limiting, perform the following:
•The egress-rate command is present in the *A:Dut-1>config>port>ethernet
context.
•The egress-rate configures the maximum rate (in kbps).
•By default there is no explicit egress-rate command set on port and the port operates
at the maximum line-rate speed it is operating at.
The following displays the egress-rate configuration for a port:
*A:Dut-1>config>port# info
--------------------------------------------- ethernet
egress-rate 120000
exit
no shutdown
827210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 83
Modifying Port Level Egress-Rate Command
To modify egress-rate parameters you can simply apply a egress-rate command with new
egress-rate.
Removing Port Level Egress-Rate Command
To remove egress-rate command from a port, use the no option with the egress-rate
command. The rate for the egress-rate option and max-burst should not be used in this case.
CLI Syntax:config>port>ethernet# no egress-rate
The following displays the removal of egress-rate configuration from a port:
*A:Dut-1>config>port# no ethernet egress-rate
*A:Dut-1>config>port# info
--------------------------------------------- ethernet
exit
no shutdown
By default no egress-rate is configured for a port. For more information on the CLI and
description, see Port Level Egress-Rate Command Reference.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide83
Page 84
Basic Configurations
847210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 85
Port Level Egress-Rate Command Reference
Command Hierarchies
Configuration Commands for 7210 SAS-K 2F2T1C devices
— config
— port
—ethernet
— egress-ratesub-rate
—no egress-rate
QoS Policies
Show Commands
—show
— port [port-id]
Configuration Descriptions
Configuration Commands
egress-rate
Syntaxegress-rate sub-rate
no egress-rate
Contextconfig>port>ethernet
DescriptionPlatforms supported: 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C
This command configures maximum egress rate for a port. The egress-rate is configured as kbps.
The no form of the command removes egress-rate from the port.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide85
Page 86
Port Level Egress-Rate Command Reference
DefaultNo egress-rate and max-burst is configured for the port.
Parameterssub-rate — Specifies an integer value between 1 and 1000000 kbps.
Show Commands
port
Syntaxport [port-id]
Contextshow
DescriptionThis command displays Egress-Rate and Max-Burst value set for port along with other details of the
port.
Parametersport-id — Displays information about the specific port ID.
Output
Sample Output
*A:dut-1>config>qos>network-queue# show port 1/1/1
===============================================================================
Ethernet Interface
===============================================================================
Description : 10/100/Gig Ethernet SFP
Interface : 1/1/1 Oper Speed : 1 Gbps
Link-level : Ethernet Config Speed : 1 Gbps
Admin State : up Oper Duplex : full
Oper State : up Config Duplex : full
Physical Link : Yes MTU : 1514
IfIndex : 35684352 Hold time up : 0 seconds
Last State Change : 01/17/2011 04:05:37 Hold time down : 0 seconds
Last Cleared Time : N/A
867210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 87
QoS Policies
Transceiver Data
Transceiver Type : SFP
Model Number : 3HE00027AAAA02 ALA IPUIAELDAB=
TX Laser Wavelength: 850 nm Diag Capable : yes
Connector Code : LC Vendor OUI : 00:0a:1d
Manufacture date : 2008/08/10 Media : Ethernet
Serial Number : OPCPCH08052638
Part Number : TRPAG1SXLAES-TM
Optical Compliance : GIGE-SX
Link Length support: 550m for 50u MMF; 280m for 62.5u MMF;
===============================================================================
Traffic Statistics
===============================================================================
Input Output
------------------------------------------------------------------------------Octets 0 0
Packets 0 0
Errors 0 0
===============================================================================
* indicates that the corresponding row element may have been truncated.
===============================================================================
Port Statistics
===============================================================================
Input Output
------------------------------------------------------------------------------Unicast Packets 0 0
Multicast Packets 0 0
Broadcast Packets 0 0
Discards 0 0
Unknown Proto Discards 0
===============================================================================
===============================================================================
Ethernet-like Medium Statistics
===============================================================================
Alignment Errors : 0 Sngl Collisions : 0
FCS Errors : 0 Mult Collisions : 0
SQE Test Errors : 0 Late Collisions : 0
CSE : 0 Excess Collisns : 0
Too long Frames : 0 Int MAC Tx Errs : 0
Symbol Errors : 0 Int MAC Rx Errs : 0
================================================================
*A:dut-1>config>qos>network-queue#
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide87
Page 88
Port Level Egress-Rate Command Reference
887210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 89
In This Section
This section provides information to configure frame-based accounting using the command
line interface.
Topics in this section include:
•Overview
Overview
Frame-based Accounting
This feature, when enabled, lets QoS policies account for the Ethernet frame overhead (for
example, it accounts for the IFG (inter-frame gap) and the preamble). Typically, the IFG and
preamble constitutes about 12 + 8 = 20 bytes. The QoS policer/meter and shaper uses this
overhead for Ethernet ports when allocating bandwidth.
Frame-based Accounting
On 7210 SAS-K platforms, a configurable CLI command enables accounting of the frame
overhead per port. This command affects the behavior of the SAP ingress FC meter, SAP
ingress aggregate meter, ingress queue rate, and egress queue rate of all the SAPs configured
on the port. When disabled, the SAP ingress FC meter, SAP ingress aggregate meter, ingress
queue rate, and egress queue rate, along with the port egress rate, do not account for the
Ethernet frame overhead. When enabled, the SAP ingress FC meter, SAP ingress aggregate
meter, ingress queue rate, and egress queue rate, along with the port egress rate, account for
the Ethernet frame overhead. By default, frame-based accounting is disabled for the port.
Accounting records and statistics account for frame overhead for SAPs configured on the port
when FBA is enabled on the port.
On 7210 SAS-K 2F2T1C, frame-based accounting is supported on both access port and
access-uplink port.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide89
Page 90
Overview
On 7210 SAS-K 2F4T6C, frame-based accounting is supported on network port, access port
and access-uplink port.
Enabling and Disabling Frame-based Accounting
On 7210 SAS-K platforms, frame-based accounting is supported per port with the capability
to enable and disable it per port for both ingress and egress. In other words, it not possible to
enable/disable it only for ingress or for egress; both can be enabled together or disabled
together.
To enable frame-based-accounting for both ingress and egress on a port, execute the
command config>port>ethernet>frame-based-accounting.
To disable frame-based-accounting for both ingress and egress on a port, execute the
command config>port>ethernet>no frame-based-accounting.
The following output displays the enabling of frame-based-accounting:
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide91
Page 92
Frame-based Accounting Command Reference
Command Descriptions
•Configuration Commands
•Show Commands
Configuration Commands
frame-based-accounting
Syntaxframe-based-accounting
no frame-based-accounting
Contextconfig>port>ethernet
DescriptionPlatforms Supported: 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T
This command configures per port frame-based accounting. It can be enabled or disabled on each port.
When enabled, all SAP ingress FC meter rates, SAP ingress aggregate meter rates, shaper rates, meter
statistics, and queue statistics on that port also account for the Ethernet Layer 1 overhead (of 20 bytes)
in both ingress and egress directions. In other words, all SAP ingress FC meter rates, SAP ingress
aggregate meter rates, ingress queue shaper rates, egress queue shaper rates, and aggregate SAP shaper
rates account for the Ethernet overhead.
The no form of the command disables frame-based-accounting.
Defaultno frame-based-accounting
Show Commands
network
Syntaxnetwork [policy-id] [detail]
Contextshow>qos
DescriptionThis command displays the accounting status of a network qos policy along with other details of the
policy. When frame-based-accounting is enabled accounting is shown as frame-based otherwise
packet-based.
Parameterspolicy-id — Displays information about the specific policy ID.
927210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 93
Output
QoS Policies
detail — Displays the detail policy information.
Sample output for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C
------------------------------------------------------------------------------Policy-id : 1
Egr Remark : False Egr Rem Plcy : N/A
Forward Class : be Profile : None
Scope : Template
DOT1P Class Poli*: 1 DSCP Class Polic*: 0
MPLS Lsp Exp Cla*: 0
Description : Default network-port QoS policy.
===============================================================================
* indicates that the corresponding row element may have been truncated.
*A:dut-a>show>qos#
DescriptionThis command displays accounting status of a sap-ingress policy along with other details of the policy.
When frame-based-accounting is enabled accounting is shown as frame-based otherwise packet-based.
Parameterspolicy-id — Displays information about the specific policy ID.
associations — Displays the associations of the sap-ingress policy.
match-criteria — Displays the match criteria of the sap-ingress policy.
947210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 95
Output
QoS Policies
detail — Displays the detailed information of the sap-ingress policy.
Sample Output
*A:Dut-1# show qos sap-ingress 1
===============================================================================
QoS Sap Ingress
===============================================================================
Sample Output for 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C
*A:dut-a>show>qos# sap-ingress 1
===============================================================================
QoS Sap Ingress
===============================================================================
------------------------------------------------------------------------------Policy-id : 1 Scope : Template
Default FC : be
Criteria-type : None
Mac Sub-Criteria : None IP Sub-Criteria : None
IPv6 Enabled : False
DOT1P Class Policy Id : 0 DSCP Class Policy Id : 0
MPLS Lsp Exp Class Policy*: 0
Name : default
Description : Default SAP ingress QoS policy.
===============================================================================
* indicates that the corresponding row element may have been truncated.
*A:dut-a>show>qos#
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide95
Page 96
Frame-based Accounting Command Reference
967210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 97
DSCP, Dot1p, and MPLS EXP
In This Section
This section provides information to configure DSCP classification policy, Dot1p
classification policy and MPLS EXP classification policy using the command line interface.
Topics in this section include:
•Overview
•Configuration Descriptions
classification policy
Overview
These policies allow user to define a policy/template that maps the packet priority bits, like
Dot1p, IP DSCP and MPLS EXP bits, to forwarding class and profile. The template can then
be used in a SAP ingress policy to define the ingress classification of flows to forwarding
class.
The support available on different 7210 platforms is provided in the table below:
Table 20: Classification policy with platforms support.
Policy nameSupport available
Dot1p-classification7210 SAS-K 2F2T1C and
7210 SAS-K 2F4T6C with
sap-ingress policy and
network-qos policy.
DSCP classification7210 SAS-K 2F2T1C and
7210 SAS-K 2F4T6C with
sap-ingress policy and
network-qos policy.
7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide97
Page 98
Overview
Table 20: Classification policy with platforms support.
Policy nameSupport available
MPLS-EXP classificationOnly 7210 SAS-K 2F4T6C
DSCP classification policy
This policy is used define the map of IP DSCP values in the IP header of the packet to
forwarding class and profile (ingress profile).
Dot1p classification policy
with network-qos policies
This policy is used define the map of Dot1p values in the ethernet frame to forwarding class
and profile (ingress profile).
MPLS EXP classification policy
This policy is used define the map of MPLS EXP values in the MPLS header of the packet to
forwarding class and profile (ingress profile).
Configuration of DSCP classification policy, Dot1p
classification policy, and MPLS EXP classification policy
The following output displays the enabling DSCP classification policy, Dot1p classification
policy, and MPLS EXP classification policy:
*A:K-SASK12>config>qos># info detail
----------------------------------------------
---------exit
dot1p-classification 1 create
987210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS QoS Guide
Page 99
description "Default Dot1P Classification policy"
dot1p 0 fc "be" profile out
dot1p 1 fc "l2" profile in
dot1p 2 fc "af" profile out
dot1p 3 fc "af" profile in
dot1p 4 fc "h2" profile in
dot1p 5 fc "ef" profile in
dot1p 6 fc "h1" profile in
dot1p 7 fc "nc" profile in
exit
dot1p-classification 10 create
no description
exit
dscp-classification 1 create
description "Default DSCP Classification policy"
dscp be fc "be" profile out
dscp ef fc "ef" profile in
dscp cs1 fc "l2" profile in
dscp nc1 fc "h1" profile in
dscp nc2 fc "nc" profile in
dscp af11 fc "af" profile in
dscp af12 fc "af" profile out
dscp af41 fc "h2" profile in
exit
dscp-classification 20 create
no description
exit
mpls-lsp-exp-classification 1 create
description "Default MplsLspExp Classification policy"
lsp-exp 0 fc "be" profile out
lsp-exp 1 fc "l2" profile in
lsp-exp 2 fc "af" profile out
lsp-exp 3 fc "af" profile in
lsp-exp 4 fc "h2" profile in
lsp-exp 5 fc "ef" profile in
lsp-exp 6 fc "h1" profile in
lsp-exp 7 fc "nc" profile in
exit
mpls-lsp-exp-classification 20 create
no description
exit
QoS Policies
*A:K-SASK12>config>qos>dot1p-classification#
*A:K-SASK12>config>qos>mpls-lsp-exp-classification# info detail
--------------------------------------------- description "Default MplsLspExp Classification policy"
lsp-exp 0 fc "be" profile out
lsp-exp 1 fc "l2" profile in
lsp-exp 2 fc "af" profile out
lsp-exp 3 fc "af" profile in
lsp-exp 4 fc "h2" profile in
lsp-exp 5 fc "ef" profile in
lsp-exp 6 fc "h1" profile in
lsp-exp 7 fc "nc" profile in