7210 SAS OS Quality of Service Guide7210 SAS-M7210 SAS-T7210 SASMxp7210 SAS-S7210 SAS-SxRelease 9.0.R8
7210 SERVICE ACCESS SWITCH
7210 SAS OS Quality of Service Guide
7210 SAS-M
7210 SAS-T
7210 SAS-Mxp
7210 SAS-S
7210 SAS-Sx
Release 9.0.R8
3HE11482AAAHTQZZA
Issue: 01
September 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 ........................................................................................................................16
Technical Support .........................................................................................................................................17
In This Chapter ...................................................................................................................................................19
Alcatel-Lucent 7210 SAS-Series Services Configuration Process .....................................................................19
In This Chapter ..................................................................................................................................................21
Overview of QoS Policies on 7210 SAS-M and 7210 SAS-T in Access-uplink mode ...................................22
Overview of QoS Policies on 7210 SAS-M and 7210 SAS-T in network mode ............................................25
Overview of QoS Policies on 7210 SAS-Mxp in network mode ....................................................................28
Overview of QoS Policies on 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE ...................................32
Service and Network QoS Policies .....................................................................................................................36
Network QoS Policies in Network Mode.............................................................................................................37
'ip-interface' type Network QoS policy ..........................................................................................................38
“port” Type Network QoS Policy ....................................................................................................................40
Network QoS Policies for Access-uplink Mode ..................................................................................................42
Network Queue policies in Network mode .........................................................................................................44
Network Queue policies in Access-uplink mode ................................................................................................46
Meter ID.........................................................................................................................................................48
Committed Information Rate for Meters ........................................................................................................49
Peak Information Rate for Meters .................................................................................................................49
Adaptation Rule for Meters............................................................................................................................50
Maximum Burst Size (For Meter/Policers).....................................................................................................51
Meter Counters..............................................................................................................................................52
Meter Modes .................................................................................................................................................52
Color Aware Policing ..........................................................................................................................................52
QoS Overrides for Meters/Policers .....................................................................................................................53
Configuration guidelines of QoS Override .....................................................................................................54
Configuring Meter Override parameters .............................................................................................................54
Queue ID ......................................................................................................................................................55
Committed Information Rate for Queues.......................................................................................................56
Peak Information Rate for Queues ................................................................................................................57
Adaptation Rule for Queues ..........................................................................................................................57
Committed Burst Size (CBS) and the Maximum Burst Size (MBS) for Queues ............................................59
Service Ingress QoS Policies .............................................................................................................................61
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide3
Page 4
Table of Contents
Service Egress QoS Policies on 7210 SAS-Mxp................................................................................................67
Access Egress QoS Policies on 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE
71
Access Egress QoS Policies on 7210 SAS-Mxp ................................................................................................75
Access Egress QoS policy for SAP-based queuing mode on 7210 SAS-Mxp ...................................................75
Access Egress QoS policy for Port-based Queuing mode on 7210 SAS-Mxp ...................................................76
Buffer Pools on 7210 SAS-M and 7210 SAS-T ..................................................................................................78
Buffer pool allocation - Per port MBS pool (7210 SAS-M and 7210 SAS-T) ................................................78
Buffer pool allocation - Per Node MBS pool on 7210 SAS-T .......................................................................79
Decommissioning Ports with Per port MBS pool ................................................................................................80
Using decommission command for Buffer Allocation on 7210 SAS-M and 7210 SAS-T devices............80
Configuration guidelines for use of ‘Decommission’ commands on 7210 SAS-M and 7210 SAS-T devices
81
Buffer Pools on 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE devices................................................82
Buffer Pools on 7210 SAS-Mxp..........................................................................................................................83
Slope Policies for 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE devices84
RED Slopes In Network and Access-uplink Mode ........................................................................................85
Tuning the Shared Buffer Utilization Calculation...........................................................................................88
Schedulers on 7210 SAS-Mxp ...........................................................................................................................97
CPU Queues ......................................................................................................................................................97
Remark Policy on 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-Mxp (Network
Egress Port Rate Limiting...................................................................................................................................98
Discard Eligibility Indicator (DEI) based Classification and Marking............................................ 107
In This Section..................................................................................................................................................107
DEI based Classification ..................................................................................................................................107
DEI based marking ..........................................................................................................................................109
Port Level Egress Rate-Limiting ....................................................................................................... 111
In This Section..................................................................................................................................................111
Show Commands...................................................................................................................................116
Frame Based Accounting .................................................................................................................. 119
In This Section..................................................................................................................................................119
Frame Based Accounting ............................................................................................................................119
Effects of Enabling Ingress Frame Based Accounting on Ingress Meter Functionality ..............................120
Effects of Enabling Egress Frame Based Accounting on Network Queue Functionality ............................120
Accounting and Statistics ...........................................................................................................................120
In This Section..................................................................................................................................................125
Service Management Tasks .............................................................................................................................158
In This Section..................................................................................................................................................209
Service Management Tasks .............................................................................................................................216
Show Commands...................................................................................................................................226
Service Ingress QoS Policies ............................................................................................................ 229
In This Section..................................................................................................................................................229
Create Service Ingress QoS Policies ..........................................................................................................244
Service Ingress QoS Policy .........................................................................................................................244
Service Ingress QoS Meter ...................................................................................................................245
Service Ingress IP Match Criteria ..........................................................................................................246
Service Ingress MAC Match Criteria .....................................................................................................247
Examples for Computation of resources required for Service ingress QoS policy.................................248
Applying Service Ingress Policies ..............................................................................................................284
Service Management Tasks .............................................................................................................................286
In This Section..................................................................................................................................................331
Access Egress QoS Policies for 7210 SAS-Mxp ............................................................................. 359
In This Section..................................................................................................................................................359
Service Egress Policies for 7210 SAS-Mxp...................................................................................... 379
In This Section..................................................................................................................................................379
QoS Port Scheduler Policies for 7210 SAS-M and 7210 SAS-T ..................................................... 395
In This Section..................................................................................................................................................395
Creating a QoS Port Scheduler Policy ...................................................................................................396
Service Management Tasks .............................................................................................................................396
Copying and Overwriting Scheduler Policies ..............................................................................................397
Schedulers on 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE.............................................. 399
In this section....................................................................................................................................................399
87210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 9
Table of Contents
QoS Port Scheduler Policy Command Reference ............................................................................................401
Port Scheduler Policy Commands .........................................................................................................403
Show Commands...................................................................................................................................405
Schedulers on 7210 SAS-Mxp ........................................................................................................... 409
In This Section..................................................................................................................................................409
Scheduling with SAP based queues on Access ports .....................................................................................410
Scheduling on Network Ports ...........................................................................................................................412
Scheduling on Hybrid port with SAP based egress queues .............................................................................412
Port Based Scheduling and Queuing on Access Ports ....................................................................................413
Scheduling on hybrid port with port based SAP queues ..................................................................................415
In This Section..................................................................................................................................................417
Service Management Tasks .............................................................................................................................426
In This Section..................................................................................................................................................445
Service Management Tasks .............................................................................................................................446
Creating a Queue Management Policy .......................................................................................................446
In This Section..................................................................................................................................................461
147210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 15
About This Guide
This guide describes Quality of Service (QoS) provided by the 7210 SAS-M, T, Sx/S 1/
10GE,Sx 10/100GE, and Mxp 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 that are not supported on a particular
platform.All the variants of 7210 SAS-M and 7210 SAS-T can be configured in two modes,
that is, in network mode and in access-uplink mode. In network mode configuration 7210
SAS-M and 7210 SAS-T uses IP/MPLS to provide service transport. In access-uplink mode
configuration 7210 SAS-M and 7210 SAS-T uses Ethernet QinQ technology to provide
service transport. The mode can be selected by configuring the BOF appropriately. 7210
SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE devices operates only on
Network mode.
Preface
This guide also presents examples to configure and implement various tests.
Note:
•This user guide is applicable to all 7210 SAS-M, 7210 SAS-T, 7210 SAS-Mxp, 7210
SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE platforms, unless specified otherwise.
•In either mode, it is expected that the user will only configure the required CLI
parameters appropriate for the mode he intends to use. Unless otherwise noted, most
of the configuration is similar in both the network mode and Access uplink mode.
•The 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE can be operated in
standalone mode and satellite mode. The user guide provides features and CLI
commands supported in 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE
standalone mode of operations. Only the Basics System Configuration User Guide
contains information on how to boot the 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/
100GE in satellite mode of operation.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide15
Page 16
About This Guide
Audience
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 that are 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.
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-M, T, X, R6, R12, Mxp, Sx OS documentation set is composed of the
following books:
•7210 SAS-M, T, X, R6, R12, Mxp, Sx OS Basic System Configuration Guide
This guide describes basic system configurations and operations.
•7210 SAS-M, T, X, R6, R12, Mxp, Sx OS System Management Guide
This guide describes system security and access configurations as well as event
logging and accounting logs.
This guide provides an overview of routing concepts and provides configuration
examples for OSPF, IS-IS, and route policies.
Technical Support
Preface
If you purchased a service agreement for your 7210 SAS device and related products from a
distributor or authorized reseller, contact the technical support staff for that distributor or
reseller for assistance. If you purchased an Alcatel-Lucent service agreement, contact your
welcome center.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide17
Page 18
About This Guide
187210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 19
In This Chapter
This chapter provides process flow information to configure Quality of Service (QoS)
policies and provision services.
This guide provides information to configure QoS policies in both network mode and accessuplink mode. Unless otherwise noted, many of the qos policies are applicable to both network
mode and access-uplink mode.
Getting Started
Alcatel-Lucent 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
•SAP ingressService Ingress QoS Policies
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide19
Page 20
Alcatel-Lucent 7210 SAS-Series Services Configuration Process
207210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 21
In This Chapter
This chapter provides information about Quality of Service (QoS) policy management.
Topics in this chapter include:
•QoS Overview
•QoS Policy Entities
•Configuration Notes
QoS Policies
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, Police, 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 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 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.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide21
Page 22
QoS Overview
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 Forwarding Classes.
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:
•QoS 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 or network/network-queue
policies determine how queues are scheduled.
Overview of QoS Policies on 7210 SAS-M and 7210 SAS-T
in Access-uplink mode
When configured to operate in access-uplink mode, 7210 SAS M and 7210 SAS-T QoS
policies are applied on service ingress, access port egress, and access-uplink port ingress and
egress. These policies allow user to configure the following:
•Classification rules for how traffic is mapped to forwarding classes
•Forwarding class association with meters and meter parameters used for policing
(rate limiting).
•Queuing parameters for shaping and buffer allocation
•QoS marking/interpretation
There are several types of QoS policies:
•Service ingress (for access SAP ingress)
•Access egress (for access port egress)
•Network (for access-uplink port, ingress and egress)
•Network queue (for access-uplink port, egress)
227210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 23
QoS Policies
•Port scheduler (for access port and access-uplink port egress)
•Slope Policies
Service ingress QoS policies are applied to the customer-facing Service Access Points
(SAPs). Traffic that enters through the SAP is classified to map it to a Forwarding Class (FC).
Forwarding class is associated with meters/policier on ingress. The mapping of traffic to
meters can be based on combinations of customer QoS marking (IEEE 802.1p bits), IP and
MAC criteria. The characteristics of the forwarding class meters are defined within the policy
as to the number of forwarding class meters for unicast traffic and the meter characteristics
(like CIR, PIR, etc.). Each of the forwarding classes can be associated with different unicast
parameters. A service ingress QoS policy also defines up to three (3) meters per forwarding
class to be used for multipoint traffic for multipoint services. There can be up to 32 meters in
total per Service ingress QOS policies. In the case of the VPLS, 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-topoint fashion within the service.
An access egress policy is analogous to a SAP egress policy as defined in the 7x50 SR series
of products. The difference is the point of attachment. An access egress policy is applied on
the physical port as opposed to the logical port (SAP) for SAP egress policy. It applies to all
the SAPs on the given port. An access egress QoS policy maps the traffic egressing out on
the customer facing ports into various queues and marks the traffic accordingly. The FCs are
mapped onto the queues. There are 8 queues at the port level. FC-to-queue mapping is static
and is not configurable. The number of queues is not user configurable and software always
allocates 8 queues at the port level. An access egress policy also defines how to remark the
forwarding class to packet header bits (for example: IEEE 802.1p bits in the L2 VLAN
header, etc.).
For devices configured to operate in access uplink mode, network QoS policies apply to
access uplink ports. Access-uplink ports in access-uplink mode are analogous to network
ports in network mode. On ingress, the policy applied to an access-uplink port maps incoming
Dot1p values to forwarding class and profile state for the traffic received from the core
network. On egress, the policy maps forwarding class and profile state to packet header
values (for example: IEEE 802.1p value in the L2 header, etc.) for traffic to be transmitted
into the core network.
Network queue policies are applied on egress of access-uplink ports when operating in
access-uplink mode. The policies define the forwarding class queue characteristics for these
entities. The FCs are mapped onto the queues. There are 8 queues at the port level. FC-toqueue mapping is system defined not user configurable. The number of queues is not user
configurable and software always allocates 8 queues at the port level.
Service ingress, access egress, and network QoS policies are defined with a scope of either
template or exclusive. Template policies can be applied to multiple entities (such as SAPs and
ports) whereas exclusive policies can only be applied to a single entity.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide23
Page 24
QoS Overview
One service ingress QoS policy can be applied to a specific SAP. Access egress policy can
be applied to an access port. One access egress QoS policy can be applied to the access port.
One network QoS policy can be applied to a access-uplink port when operating in accessuplink mode. A network QoS policy defines both ingress and egress behavior. One network
queue policy can be applied to an access-uplink port. If no QoS policy is explicitly applied to
a SAP, port or interface, a default QoS policy is applied.
A summary of the major functions performed by the QoS policies is listed in Table 3.
Note: Not all policies are supported on all platforms. For more information, see the sections,
and chapters below.
Table 2: QoS Policy Types and Descriptions for 7210 SAS-M, T devices in Access-uplink mode
Policy TypeDevice
Operating
Mode
Service Ingress Access-Uplink
mode
Access Egress Access-Uplink
mode
NetworkAccess-Uplink
mode
Applied at…DescriptionPage
SAP ingress•Defines up to 16 forwarding class
61
meters and meter parameters for traffic
classification.
•Defines match criteria to map flows to
the meters based on any one of the
criteria.
Access port•Defines up to 8 forwarding class queues
42
and queue parameters for traffic
classification.
•Maps forwarding classes to the queues.
•Defines FC to remarking values (for
example: Dot1p, etc.).
•Defines CIR levels and PIR weights that
determines how the queue gets
prioritized by the scheduler.
Access-Uplink
port
•Used for classification/marking of IP
packets.
37
•At ingress, defines Dot1p to FC
mapping and 8 meters.
•At egress, defines FC to remarking
values (for example: Dot1p, etc.)
247210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 25
QoS Policies
Table 2: QoS Policy Types and Descriptions for 7210 SAS-M, T devices in Access-uplink mode (Continued)
Policy TypeDevice
Operating
Mode
Network QueueAccess-uplink
mode
SlopeAccess-uplink
mode
Port schedulerAccess-uplink
mode
Applied at…DescriptionPage
Access-uplink
port
Access ports
and Access
uplink ports
Access ports
and Access
uplink ports
•Defines forwarding class mappings to
network queues and queue
characteristics for the queues.
• Enables or disables the high-slope, lowslope, and non-TCP parameters within
the egress pool.
•Defines the parameters for the port
scheduler.
44
90
94
Overview of QoS Policies on 7210 SAS-M and 7210 SAS-T
in network mode
QoS policies are applied on service ingress, access port egress, network port ingress and
egress, and network IP interfaces ingress when configured to operate in network mode.
These policies allow user to configure the following:
•Classification rules for how traffic is mapped to forwarding classes
•Forwarding class association with meters and meter parameters used for policing
(rate-limiting).
•Queuing parameters for shaping
•QoS marking/interpretation
There are several types of QoS policies:
•Service ingress (for access SAP ingress)
•Access egress (for access port egress)
•Network (for network and hybrid port, ingress and egress)
•Network queue (for network and hybrid port, egress)
•Port scheduler (for access port, network port and hybrid port egress)
•Slope Policies
•Remark policies (for access port, network port and hybrid port egress marking only
on 7210 SAS-T Network Mode)
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide25
Page 26
QoS Overview
Service ingress QoS policies are applied to the customer-facing Service Access Points
(SAPs). Traffic that enters through the SAP is classified to map it to a Forwarding Class (FC).
Forwarding class is associated with meters/policier on ingress. The mapping of traffic to
meters can be based on combinations of customer QoS marking (IEEE 802.1p bits), IP and
MAC criteria. The characteristics of the forwarding class meters are defined within the policy
as to the number of forwarding class meters for unicast traffic and the meter characteristics
(like CIR, PIR, etc.). Each of the forwarding classes can be associated with different unicast
parameters. A service ingress QoS policy also defines up to three (3) meters per forwarding
class to be used for multipoint traffic for multipoint services. There can be up to 32 meters in
total per Service ingress QOS policies. In the case of the VPLS, 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-topoint fashion within the service.
An access egress policy is analogous to a SAP egress policy as defined in the 7x50 SR series
of products. The difference is the point of attachment. An access egress policy is applied on
the physical port as opposed to the logical port (SAP) for SAP egress policy. It applies to all
the SAPs on the given port. An access egress QoS policy maps the traffic egressing out on
the customer facing ports into various queues and marks the traffic accordingly. The FCs are
mapped onto the queues. There are 8 queues at the port level. FC-to-queue mapping is static
and is not configurable. The number of queues is not user configurable and software allocates
8 queues at the port level. An access egress policy also defines how to remark the forwarding
class to packet header bits (e.g. IEEE 802.1p bits in the L2 VLAN header, and others.).
For devices configured to operate in network mode, there are two types of network QoS
policies, one applied to a network IP interface and the other is applied to a network port.
Network QoS policies are applied to IP interfaces. On ingress, the policy applied to an IP
interface maps incoming MPLS LSP EXP values to forwarding class and profile state for the
traffic received from the core network. On egress, the policy maps forwarding class and
profile state to MPLS LSP EXP values for traffic to be transmitted into the core network. The
network policy applied to a network port maps incoming IP packets, DSCP or Dot1p values,
to the forwarding class and the profile state for the traffic received from the core network. On
egress, the policy maps forwarding class and profile state to DSCP and/or Dot1p values for
IP traffic to be transmitted into the core network.
Network queue policies are applied on egress to network ports when operating in network
mode. The policies define the forwarding class queue characteristics for these entities. The
FCs are mapped onto the queues. There are 8 queues at the port level. FC-to-queue mapping
is static and is not configurable. The number of queues is not user configurable and software
allocates 8 queues at the port level.
Service ingress, access egress, and network QoS policies are defined with a scope of either
template or exclusive. Template policies can be applied to multiple entities (such as SAPs and
ports) whereas exclusive policies can only be applied to a single entity.
267210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 27
QoS Policies
One service ingress QoS policy can be applied to a specific SAP Access egress policy can be
applied to an access port. One access egress QoS policy can be applied to the access port. One
network QoS policy can be applied to a specific IP interface or network port based on the type
of network QoS policy. when operating in network mode. One network QoS policy can be
applied to a access-uplink port when operating in access-uplink modeA network QoS policy
defines both ingress and egress behavior. One network queue policy can be applied to the
network port or a access-uplink port.
If no QoS policy is explicitly applied to a SAP, port or interface, a default QoS policy is
applied.
A summary of the major functions performed by the QoS policies is listed in Tabl e 3.
Note: Not all policies are supported on all platforms. For more information, see the sections,
and chapters below.
Table 3: QoS Policy Types and Descriptions for 7210 SAS-M, T devices in network mode
Policy TypeDevice
Operating
Mode
Applied at…DescriptionPage
Service Ingress Network mode SAP ingress•Defines up to 16 forwarding class
meters and meter parameters for traffic
classification.
•Defines match criteria to map flows to
the meters based on any one of the
criteria.
Access Egress Network mode Access port•Defines up to 8 forwarding class queues
and queue parameters for traffic
classification.
•Maps forwarding classes to the queues.
•Defines FC to remarking values.
•Defines CIR levels and PIR weights that
determines how the queue gets
prioritized by the scheduler.
61
61
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide27
Page 28
QoS Overview
Table 3: QoS Policy Types and Descriptions for 7210 SAS-M, T devices in network mode (Continued)
Policy TypeDevice
Operating
Mode
Network (of
type’ipinterface’)
Network (of
type’port’)
Network QueueNetwork mode Network Ports
SlopeNetwork mode Access ports,
Network modeIP interface•Used for classification/marking of
Network modeNetwork and
Applied at…DescriptionPage
Hybrid Ports
and Hybrid
Ports
Network ports
and Hybrid
ports
MPLS packets.
•At ingress, defines MPLS LSP-EXP to
FC mapping and 12 meters used by FCs.
•At egress, defines FC to MPLS LSPEXP marking.
•Used for classification/marking of IP
packets.
•At ingress, defines DSCP or Dot1p to
FC mapping and 8 meters.
•At egress, defines FC to DSCP or Dot1p
marking or both.
•Defines forwarding class mappings to
network queues and queue
characteristics for the queues.
• Enables or disables the high-slope, lowslope, and non-TCP parameters within
the egress pool.
37
37
44
90
Port schedulerNetwork mode Access ports,
Network ports
and Hybrid
ports
Remark Network Mode
(Only on 7210
SAS-T)
Network Port,
Access ports
and Hybrid
Ports
•Defines the parameters for the port
scheduler.
•Applied at egress, defines the FC to
Priority Bits (DSCP or dot1p or EXP)
marking.
94
461
Overview of QoS Policies on 7210 SAS-Mxp in network
mode
QoS policies are applied on service ingress, access port egress, network port ingress and
egress, and network IP interfaces ingress when configured to operate in network mode.
287210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 29
QoS Policies
These policies allow user to configure the following:
•Classification rules for how traffic is mapped to forwarding classes
•Forwarding class association with meters and meter parameters used for policing
(rate-limiting).
•Queuing parameters for shaping
•QoS marking/interpretation
There are several types of QoS policies:
•Service ingress (for access SAP ingress)
•Access egress (for access SAP egress)
•Access egress (for access port egress)
•Network (for network and hybrid port, ingress and egress)
•Network queue (for network and hybrid port, egress)
•Port scheduler (for access port, network port and hybrid port egress)
•Slope Policies
•Remark policies (for access port, network port and hybrid port egress marking)
Service ingress QoS policies are applied to the customer-facing Service Access Points
(SAPs). Traffic that enters through the SAP is classified to map it to a Forwarding Class (FC).
Forwarding class is associated with meters/policier on ingress. The mapping of traffic to
meters can be based on combinations of customer QoS marking (IEEE 802.1p bits), IP and
MAC criteria. The characteristics of the forwarding class meters are defined within the policy
as to the number of forwarding class meters for unicast traffic and the meter characteristics
(like CIR, PIR, etc.). Each of the forwarding classes can be associated with different unicast
parameters. A service ingress QoS policy also defines up to three (3) meters per forwarding
class to be used for multipoint traffic for multipoint services. There can be up to 32 meters in
total per Service ingress QOS policies. In the case of the VPLS, 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-topoint fashion within the service.
Service egress QoS policies are applied to SAPs and map forwarding classes to service egress
queues for a service. The system allocates a maximum of 8 queues per SAP for the 8
forwarding classes. It is not user configurable. 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.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide29
Page 30
QoS Overview
An access egress policy is applied on the physical port as opposed to the logical port (SAP)
for SAP egress policy. It applies to all the SAPs on the given port. An access egress policy
defines how to remark the forwarding class to packet header bits (For example: IEEE 802.1p
bits in the L2 VLAN header, and others.).
The 7210 SAS-Mxp provides an option to use port-based queuing on access ports. This is a
per-node configuration option and is mutually exclusive to use of SAP-based egress queues
(configured through service egress policies). When enabled, all SAPs on the access port share
a set of 8 queues configured on the port and the access egress policy is used to define the
queue parameters for port-based queues.
For devices configured to operate in network mode, there are two types of network QoS
policies, one applied to a network IP interface and the other is applied to a network port.
Network QoS policies are applied to IP interfaces. On ingress, the policy applied to an IP
interface maps incoming MPLS LSP EXP values to forwarding class and profile state for the
traffic received from the core network. On egress, the policy maps forwarding class and
profile state to MPLS LSP EXP values for traffic to be transmitted into the core network. The
network policy applied to a network port maps incoming IP packets, DSCP or Dot1p values,
to the forwarding class and the profile state for the traffic received from the core network. On
egress, the policy maps forwarding class and profile state to DSCP and/or Dot1p values for
IP traffic to be transmitted into the core network.
Network queue policies are applied on egress to network ports when operating in network
mode. The policies define the forwarding class queue characteristics for these entities. The
FCs are mapped onto the queues. There are 8 queues at the port level. FC-to-queue mapping
is static and is not configurable. The number of queues is not user configurable and software
allocates 8 queues at the port level.
Service ingress, access egress, and network QoS policies are defined with a scope of either
template or exclusive. Template policies can be applied to multiple entities (such as SAPs and
ports) whereas exclusive policies can only be applied to a single entity.
One service ingress QoS policy can be applied to a specific SAP. Access egress policy can
be applied to an access port. One access egress QoS policy can be applied to the access port.
One network QoS policy can be applied to a specific IP interface or network port based on
the type of network QoS policy. A network QoS policy defines both ingress and egress
behavior. One network queue policy can be applied to the network port. If no QoS policy is
explicitly applied to a SAP, port or interface, a default QoS policy is applied.
A summary of the major functions performed by the QoS policies is listed in Table 3.
Note: Not all policies are supported on all platforms. For more information, see the sections,
and chapters below.
307210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 31
Table 4: QoS Policy Types and Descriptions for 7210 SAS-Mxp devices
QoS Policies
Policy TypeDevice
Operating
Mode
Applied at…DescriptionPage
Service Ingress Network mode SAP ingress•Defines up to 16 forwarding class
meters and meter parameters for traffic
classification.
•Defines match criteria to map flows to
the meters based on any one of the
criteria.
Service EgressNetwork mode SAP Egress•Defines up to 8 forwarding class queues.
•Maps forwarding classes to the queues.
•Defines Queue parameters (e.g. rate,
priority, weight, etc.) for the queue that
determine how the queue gets the
available bandwidth and prioritized by
the scheduler.
•Defines FC to remarking values.
Access EgressNetwork modeAccess Port• Defines FC to remarking values.
•When port-based queuing is enabled, it
used to configure the queue parameters
for port-based queues.
61
67
75
Network (of
type’ipinterface’)
Network modeIP interface •Used for classification/marking of
MPLS packets.
•At ingress, defines MPLS LSP-EXP to
37
FC mapping and 12 meters used by FCs.
•At egress, defines FC to MPLS LSPEXP marking.
Network (of
type’port’)
Network mode Network Ports
and Hybrid
Ports
•Used for classification/marking of IP
packets.
•At ingress, defines DSCP or Dot1p to
44
FC mapping and 8 meters.
•At egress, defines FC to DSCP or Dot1p
marking or both.
Network QueueNetwork mode Network Ports
and Hybrid
Ports
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide31
•Defines forwarding class mappings to
network queues and queue
characteristics for the queues.
44
Page 32
QoS Overview
Table 4: QoS Policy Types and Descriptions for 7210 SAS-Mxp devices (Continued)
Policy TypeDevice
Operating
Mode
SlopeNetwork mode Access ports,
Remark Network ModeNetwork Port,
Applied at…DescriptionPage
Network ports
and Hybrid
ports
Access ports
and Hybrid
Ports
• Enables or disables the high-slope, lowslope, and non-TCP parameters within
the egress pool.
•Applied at egress, defines the FC to
Priority Bits (DSCP or dot1p or EXP)
marking.
90
461
Overview of QoS Policies on 7210 SAS-Sx/S 1/10GE and
7210 SAS-Sx 10/100GE
QoS policies are applied on service ingress, access port egress, network port ingress and
egress, and network IP interfaces ingress when configured 7210 SAS-Sx/S 1/10GE and 7210
SAS-Sx 10/100GE operates with MPLS uplinks.
These policies allow user to configure the following:
•Classification rules for how traffic is mapped to forwarding classes.
•Forwarding class association with meters and meter parameters used for policing
(rate-limiting).
•Queuing parameters for shaping
•QoS marking/interpretation
There are several types of QoS policies:
•Service ingress (for access SAP ingress)
•Access egress (for access port egress)
•Network (for network and hybrid port, ingress and egress)
•Network queue (for network and hybrid port, egress)
•Port scheduler (for access port, network port and hybrid port egress)
•Slope Policies
•Remark policies (for access port, network port and hybrid port egress marking)
327210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 33
QoS Policies
Service ingress QoS policies are applied to the customer-facing Service Access Points
(SAPs). Traffic that enters through the SAP is classified to map it to a Forwarding Class (FC).
Forwarding class is associated with meters/policier on ingress. The mapping of traffic to
meters can be based on combinations of customer QoS marking (IEEE 802.1p bits), IP and
MAC criteria. The characteristics of the forwarding class meters are defined within the policy
as to the number of forwarding class meters for unicast traffic and the meter characteristics
(like CIR, PIR, etc.). Each of the forwarding classes can be associated with different unicast
parameters. A service ingress QoS policy also defines up to three (3) meters per forwarding
class to be used for multipoint traffic for multipoint services. There can be up to 32 meters in
total per Service ingress QOS policies. In the case of the VPLS, 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-topoint fashion within the service.
An access egress policy is analogous to a SAP egress policy as defined in the 7x50 SR series
of products. The difference is the point of attachment. An access egress policy is applied on
the physical port as opposed to the logical port (SAP) for SAP egress policy. It applies to all
the SAPs on the given port. An access egress QoS policy maps the traffic egressing out on
the customer facing ports into various queues and marks the traffic accordingly. The FCs are
mapped onto the queues. There are 16 queues at the port level (8 for unicast and 8 for
multicast). FC-to-queue mapping is static and is not configurable. The number of queues is
not user configurable and software allocates 16 queues at the port level. An access egress
policy also defines how to remark the forwarding class to packet header bits (e.g. IEEE
802.1p bits in the L2 VLAN header, and others.).
On 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, there are two types of network QoS
policies, one applied to a network IP interface and the other is applied to a network port or a
hybrid port. Network QoS policies are applied to IP interfaces. On ingress, the policy applied
to an IP interface maps incoming MPLS LSP EXP values to forwarding class and profile state
for the traffic received from the core network. On egress, the policy maps forwarding class
and profile state to MPLS LSP EXP values for traffic to be transmitted into the core network.
The network policy applied to a network port maps incoming IP packets, DSCP or Dot1p
values, to the forwarding class and the profile state for the traffic received from the core
network. On egress, the policy maps forwarding class and profile state to DSCP and/or Dot1p
values for IP traffic to be transmitted into the core network.
Network queue policies are applied on egress to network ports or hybrid ports when operating
in network mode. The policies define the forwarding class queue characteristics for these
entities. The FCs are mapped onto the queues. There are 16 queues at the port level. FC-toqueue mapping is static and is not configurable. The number of queues is not user
configurable and software allocates 16 queues at the port level.
The usage of QoS policies on hybrid ports is described below:
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide33
Page 34
QoS Overview
•Network queue policies are supported for queue configuration of egress queues on
hybrid ports. These egress queues are shared by traffic sent out of SAPs and network
IP interfaces configured on hybrid port.
•Network qos (type == ip-interface) policies are supported for network IP interfaces
on hybrid ports. The behavior is similar to the existing behavior for network IP
interfaces on network ports. It supports per IP interface ingress classification and
policing, and egress marking (only EXP marking for MPLS traffic).
•Network qos (type == port) policies are supported for hybrid ports. The behavior is
similar to existing behavior for network ports. It supports per port ingress
classification and policing, and egress marking (Dot1p and/or DSCP marking) for IP
control packets.
•SAP ingress QoS policies are supported for SAPs configured on Hybrid ports. The
behavior is similar to existing behavior for access SAP ingress. It supports per SAP
ingress classification and policing.
•For marking traffic sent out of SAPs and IP traffic sent out of IP interfaces configured
on hybrid port, user needs to use the network qos policy of type 'port', with an option
to mark Dot1p, DSCP, or both. NOTE that if DSCP remarking or both is specified,
then the DSCP field is not marked for the traffic sent out of the L2 SAPs.
Service ingress, access egress, and network QoS policies are defined with a scope of either
template or exclusive. Template policies can be applied to multiple entities (such as SAPs and
ports) whereas exclusive policies can only be applied to a single entity. One service ingress
QoS policy can be applied to a specific SAP. Access egress policy can be applied to an access
port. One access egress QoS policy can be applied to the access port. One network QoS policy
can be applied to a specific IP interface or network port or hybrid port based on the type of
network QoS policy. A network QoS policy defines both ingress and egress behavior. One
network queue policy can be applied to the network port or hybrid port. If no QoS policy is
explicitly applied to a SAP, port or interface, a default QoS policy is applied.
A summary of the major functions performed by the QoS policies is listed in Tabl e 3.
Note: Not all policies are supported on all platforms. For more information, see the sections,
and chapters below.
347210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 35
QoS Policies
Table 5: QoS Policy Types and Descriptions for 7210 SAS-Sx/S 1/10GE and 7210 SAS0Sx 10/100GE
devices
Policy TypeDevice
Operating
Mode
Applied at…DescriptionPage
Service Ingress Network mode SAP ingress•Defines up to 16 forwarding class
meters and meter parameters for traffic
classification.
•Defines match criteria to map flows to
the meters based on any one of the
criteria.
Access Egress Network mode Access port•Defines up to 8 forwarding class queues
and queue parameters for traffic
classification.
•Maps forwarding classes to the queues.
•Defines FC to remarking values.
•Defines CIR levels and PIR weights that
determines how the queue gets
prioritized by the scheduler.
Network (of
type’ipinterface’)
Network modeIP interface•Used for classification/marking of
MPLS packets.
•At ingress, defines MPLS LSP-EXP to
FC mapping and 12 meters used by FCs.
61
61
37
•At egress, defines FC to MPLS LSPEXP marking.
Network (of
type’port’)
Network modeNetwork and
Hybrid Ports
•Used for classification/marking of IP
packets.
37
•At ingress, defines DSCP or Dot1p to
FC mapping and 8 meters.
•At egress, defines FC to DSCP or Dot1p
marking or both.
Network QueueNetwork mode Network Ports
and Hybrid
Ports
SlopeNetwork mode Access ports,
Network ports
and Hybrid
•Defines forwarding class mappings to
network queues and queue
characteristics for the queues.
• Enables or disables the high-slope, lowslope, and non-TCP parameters within
the egress pool.
44
90
ports
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide35
Page 36
QoS Overview
7210 SAS M
Ethernet Access Switch
Network Egress
Network Ingress
Service Ingress
Access Egress
Switch Processing Unit/
MMU
Access
Network
Table 5: QoS Policy Types and Descriptions for 7210 SAS-Sx/S 1/10GE and 7210 SAS0Sx 10/100GE devices
(Continued)
Policy TypeDevice
Operating
Mode
Port schedulerNetwork mode Access ports,
Applied at…DescriptionPage
•Defines the parameters for the port
Network ports
scheduler.
and Hybrid
ports
Remark Network ModeNetwork Port,
Access ports
and Hybrid
•Applied at egress, defines the FC to
Priority Bits (DSCP or dot1p or EXP)
marking.
Ports
Service and Network QoS Policies
The QoS mechanisms within the 7210 SAS platforms are specialized for the type of traffic
on the interface. For customer interfaces, there is service ingress and access service egress
traffic, and for IP interfaces, there is network ingress and network egress traffic (Figure 1).
Figure 1: 7210 SAS Traffic Types Operating in Network Mode
94
461
When operating in access-uplink mode, the QoS mechanisms available are similar to network
mode, expect that network ingress and network egress traffic is associated with access-uplink
interfaces instead of network IP interface or network port (as shown in Figure 2).
367210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 37
QoS Policies
7210 SAS M
Ethernet Access Switch
Access Uplink Egress
Access Uplink Ingress
Service Ingress
Access Egress
Switch Processing Unit/
MMU
Access
Access Uplink
Figure 2: 7210 SAS-M Traffic Types for Access Uplink Mode
The 7210 SAS uses the following QoS policies applied to a SAP or a network port or an
access port or an access-uplink port to define queuing, queue attributes, policer/meter
attributes and QoS marking interpretation.
The 7210 SAS supports four types of service and network QoS policies:
•Service ingress QoS policies
•Service egress QoS policies.
•Network QoS policies
•Network Queue QoS policies
Network QoS Policies in Network Mode
Network QoS policies configured in Network mode are as follows:
1. Two types of network QoS policies can be defined, ip-interface and port. By
default, when a network QoS policy is created, it is an ip-interface type.
2. A network QoS policy of type ip-interface is created in the configure>qos>network network-policy-id network-policy-type ip-interface create context.
3. A network QoS policy of type port is created in the configure>qos>network
network-policy-id network-policy-typeportcreate context.
4. When a network QoS policy of type ip-interface is applied to an IP interface
configured on network port and hybrid port , it is used for classification of MPLS
packets received based on LSP-EXP bits and marking of MPLS-EXP bits for MPLS
traffic sent out of IP interface.
5. When a network QoS policy of type port is applied to a network and hybrid port, it
is used for classification of IP packets based on the DSCP or Dot1p bits and marking
of DSCP and/or Dot1p bits for packets sent out of network/hybrid ports.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide37
Page 38
QoS Overview
'ip-interface' type Network QoS policy
Network QoS policies (ip-interface type) define ingress forwarding class meters and maps
traffic to those meters for IP interfaces. When a network QoS policy is created, it always has
two meters defined that cannot be deleted, one for all the unicast traffic and one for all the
multipoint traffic. These meters exist within the definition of the policy. The meters only get
noticed in the hardware when the policy is applied to an IP interface. It also defines the
forwarding class to EXP bit marking, on the egress mode.
A network QoS policy defines both the ingress and egress handling of QoS on the network
IP interface and network port. The following functions are defined for network policy type
ip-interface:
•Ingress
→ Defines EXP value mapping to forwarding classes.
→ Defines forwarding class to meter mapping.
•Egress
→ Defines the forwarding class to EXP value markings.
→ Remarking of QoS bits can be enabled or disabled.
Note that FC to DSCP marking is used to mark only IP traffic sent out through
that port if marking is enabled and FC to Dot1p marking is used to mark IP and
MPLS traffic sent out through that port, if marking is enabled.
The required elements to be defined in a network QoS policy are:
•A unique network QoS policy ID.
•Egress forwarding class to EXP value mappings for each forwarding class.
•A default ingress forwarding class and in-profile/out-of-profile state.
•At least one default unicast forwarding class meter. The parameters that can be
configured for a meter are discussed in Meter/Policer Parameters.
•Optional multipoint forwarding class meter.
Optional network QoS policy elements include:
•Additional unicast meters up to a total of 8.
•Additional multipoint meters up to 8.
•EXP value to forwarding class and profile state mappings for all EXP values
received.
Network policy ID 2 is reserved as the default network QoS policy of type IP interface. The
default policy cannot be deleted or changed.
387210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 39
QoS Policies
Default network QoS policy 2 is applied to all IP interfaces which do not have another
network QoS policy explicitly assigned.
The network QoS policy applied at network egress (for example, on an IP interface)
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 core packets, out-of-profile packets
are preferentially dropped over in-profile packets at congestion points in the core network.
For network egress, traffic remarking in the network QoS policy is disabled. Table 6 lists the
default mapping of forwarding class to EXP values.
For network ingress, Table 6 lists the default mapping of EXP values to forwarding class and
profile state for the default network QoS policy. Color aware policing is supported on
network ingress.
Table 7: Default Network QoS Policy (type = ip-interface) EXP to FC Mapping
EXP Value FC IngressProfile
0beOut
1l2In
2afOut
3afIn
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide39
Page 40
QoS Overview
Table 7: Default Network QoS Policy (type = ip-interface) EXP to FC Mapping
EXP Value FC IngressProfile
4h2In
5efIn
6h1In
7ncIn
“port” Type Network QoS Policy
Network QoS policy of type port defines ingress forwarding class meters and maps traffic to
those meters for only IP traffic received on network and hybrid ports. When a network policy
of this type is created it has a single unicast meter which cannot be deleted. These meters exist
within the definition of the policy. The meters get instantiated in hardware, only when the
policy is applied to a network port. It also defines the forwarding class to DSCP and/or Dot1p
marking to be used for packets sent out through that port.
A network QoS policy of type port defines both the ingress and egress handling of QoS on
the network port.
The following functions are defined:
•Ingress
→ Defines DSCP or Dot1p value mapping to forwarding classes. Only one type
supported, such as DSCP or Dot1p, per policy. Option to use DEI bit along with
Dot1p classification.
→ Defines forwarding class to meter mapping.
•Egress
→ Specifies remark policy that defines forwarding class to DSCP or Dot1p (or both)
value markings.
→ Remarking of QoS bits is always disabled
The required elements to be defined in a network QoS policy of port type are:
•A unique network QoS policy ID and network-policy-type set to port.
•Egress forwarding class to DSCP or Dot1p (or both) value mappings for each
forwarding class.
•A default ingress forwarding class and in-profile/out-of-profile state.
407210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 41
QoS Policies
•At least one default unicast forwarding class meter. The parameters that can be
configured for a meter are discussed in Meter Parameters on page 25.
Optional network QoS policy elements include:
•Additional unicast meters up to a total of 8.
•Additional multipoint meter up to a total of 8.
•A DSCP or Dot1p (or both) value to forwarding class and profile state mappings for
all DSCP or Dot1p values received.
•Option to use DEI bit along with Dot1p classification for profile state mapping.
Network policy ID 1 is reserved as the default network QoS policy of type port. 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.
Table 8 lists the default mapping of forwarding class to Dot1p and DSCP values.
Table 8: Default Network QoS Policy of type 'port' Egress Marking
Table 9 lists the default mapping of Dot1p/DSCP values to forwarding class and profile state
for the default network QoS policy of type port, for network ingress. Color aware policing is
supported on network ingress.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide41
Page 42
QoS Overview
Table 9: Default Network QoS Policy of Type Port - Dot1p/DSCP to FC Mapping
Dot1p/DSCP ValueFC Ingress Profile
0be Out
1l2 In
2af Out
3afIn
4h2 In
5efIn
6h1 In
7nc In
Network QoS Policies for Access-uplink Mode
Network QoS policies define ingress forwarding class meters and maps traffic to those meters
for access uplink ports. When a network QoS policy is created, it always has two meters/
policers defined that cannot be deleted, one for the all unicast traffic and one for all multipoint
traffic. These meters exist within the definition of the policy. The meters only get instantiated
in hardware when the policy is applied to an access uplink port. It also defines the forwarding
class to priority bit marking, on the egress.
A network QoS policy defines both the ingress and egress handling of QoS on the access
uplink ports. The following functions are defined:
•Ingress
→ Defines Dot1p value mapping to forwarding classes and profiles. Option to use
DEI bit along with Dot1p classification. (DSCP is not available for use)
→ Defines forwarding class to meter mapping.
•Egress
→ Option to define the forwarding class to Dot1p value and IP DSCP value for
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.
427210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 43
QoS Policies
•Egress forwarding class to Dot1p value mappings for each forwarding class.
•A default ingress forwarding class and in-profile/out-of-profile state.
•At least one default unicast forwarding class meter. The parameters that can be
configured for a meter are discussed in Meter/Policer Parameters.
•At least one multipoint forwarding class meter.
Optional network QoS policy elements include:
•Additional unicast meters up to a total of 8.
•Additional multipoint meters up to 8.
•Dot1p value to forwarding class and profile state mappings for all Dot1p values
received.
•Option to use DEI bit along with Dot1p classification for profile state mapping.
Network policy ID 1 is reserved as the default network QoS policy. 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 (for example, on an access uplink port) determines how or if the
profile state is marked in packets transmitted into the service core network. If the profile state
is marked in the service core packets, out-of-profile packets are preferentially dropped over
in-profile packets at congestion points in the core network. For network egress, traffic
remarking in the network QoS policy is always enabled. Table 10 lists the default mapping
of forwarding class to Dot1p values.
Table 10: Default Network QoS Policy used for Egress Marking on Access-uplink
Ports
FC-IDFC NameFC LabelDiffServ
Name
7Network
ncNC2111-7111-7
Egress Dot1p
Marking
In-ProfileOut-of-
Profile
Control
6High-1h1NC1110-6110-6
5ExpeditedefEF101-5101-5
4High-2h2AF4100-4100-4
3Low-1l1AF2011-3010-2
2AssuredafAF1011-3010-2
1Low-2l2CS100-1001-1
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide43
Page 44
QoS Overview
Table 10: Default Network QoS Policy used for Egress Marking on Access-uplink
Ports (Continued)
FC-IDFC NameFC LabelDiffServ
Name
Egress Dot1p
Marking
In-ProfileOut-of-
Profile
0Best EffortbeBE000-0000-0
For network ingress, Table 11 lists the default mapping of Dot1p values to forwarding class
and profile state for the default network QoS policy. Color aware policing is supported on
ingress for access-uplink ports.
Table 11: Default Network QoS Policy used for Dot1p to FC on Access-uplink Ports
Dot1pValue FC IngressProfile
0beOut
1l2In
2afOut
3afIn
4h2In
5efIn
6h1In
7ncIn
Network Queue policies in Network mode
In network mode of operation, Network queue policies define the network forwarding class
queue characteristics. Network queue policies are applied on egress on network and hybrid
ports for 7210 SAS-M, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE and 7210 SASMxp operating in network mode. The system allocates a fixed number of queues for the
network port and FCs are mapped to these queues. All policies uses a fixed number queues
like the default network queue policy.
The number of queues allocated for a network queues policy is given below:
447210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 45
QoS Policies
•On 7210 SAS-M,T, and Mxp, 8 queues are allocated and 8 FC are mapped to these 8
queues. The FC to queue mapping is as given in the Table 38, Forwarding Class to
Queue-ID Map for 7210 SAS-M, 7210 SAS-T, and 7210 SAS-Mxp, on page 101.
•On 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, 16 queues are allocated,
with 2 queues per FC, one each for unicast traffic and multicast (BUM) traffic. The
FC to queue mapping is as given in the Table 39, Forwarding Class to Queue-ID Map
for 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, on page 102.
On 7210 SAS-M,T, and Mxp, 8 queues are allocated and 8 FC are mapped to these 8 queues.
The FC to queue mapping is as given in the Table 38, Forwarding Class to Queue-ID Map for
7210 SAS-M, 7210 SAS-T, and 7210 SAS-Mxp, on page 101.
On 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210
SAS-Mxp, the network queues on hybrid ports are used for MPLS traffic, IP traffic and SAP
traffic sent out of IP interfaces and SAPs configured on hybrid ports.
The queue characteristics that can be configured on a per-forwarding class basis are:
•Peak Information Rate (PIR) as a percentage of egress port bandwidth
•Committed Information Rate (CIR) as a percentage of egress port bandwidth
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. CBS values cannot be provisioned.
Table 12 describes the default network queue policy definition in network mode.
7210 SAS-Sx 10/100GE, and 7210 SAS-Mxp configured in Network mode) (Continued)
Forwarding ClassQueueDefinition (Continued)
High-2 (h2)Queue 5•PIR = 100%
•CIR = 100%
•CBS = 12.5%
Low-1 (l1)Queue 4•PIR = 100%
•CIR = 25%
•CBS = 12.5%
Assured (af)Queue 3•PIR = 100%
•CIR = 25%
•CBS = 12.5%
Low-2 (l2)Queue 2•PIR = 100%
•CIR = 25%
•CBS = 12.5%
Best-Effort (be)Queue 1•PIR = 100%
•CIR = 0%
•CBS = 12.5%
Network Queue policies in Access-uplink mode
In access-uplink mode of operation Network queue policies are applied on egress of access
uplink ports for 7210 SAS-M and 7210 SAS-T devices operating in access uplink mode. The
system allocates 8 queues for the network port and FCs are mapped to these 8 queues. All
policies uses eight queues like the default network queue policy.
The queue characteristics that can be configured on a per-forwarding class basis are:
•Peak Information Rate (PIR) as a percentage of egress port bandwidth.
•Committed Information Rate (CIR) as a percentage of egress port bandwidth.
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. CBS values cannot be provisioned.
Table 13 describes the default network queue policy definition in access-uplink mode.
467210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 47
QoS Policies
Table 13: Default Network Queue Policy Definition (for 7210 SAS-M and 7210 SAS-T configured in access
uplink mode)
Forwarding ClassQueueDefinition
Network-Control (nc)Queue 8•PIR = 100%
•CIR = 10%
•CBS = 7%
High-1 (h1)Queue 7•PIR = 100%
•CIR = 10%
•CBS = 7%
Expedited (ef)Queue 6•PIR = 100%
•CIR = 100%
•CBS = 21%
High-2 (h2)Queue 5•PIR = 100%
•CIR = 100%
•CBS = 21%
Low-1 (l1)Queue 4•PIR = 100%
•CIR = 25%
•CBS = 7%
Assured (af)Queue 3•PIR = 100%
•CIR = 25%
•CBS = 21%
Low-2 (l2)Queue 2•PIR = 100%
•CIR = 25%
•CBS = 7%
Best-Effort (be)Queue 1•PIR = 100%
•CIR = 0%
•CBS = 7%
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide47
Page 48
QoS Overview
Meter/Policer Parameters
This section describes the meter parameters available for meter. Meters are available for use
in both network mode and access-uplink mode with the following policies.
In network mode of operation meter/policer is available with the following:
•SAP ingress policies.
•Network QoS policy of type port associated with network port ingress or hybrid port
ingress.
•Network QoS policy of type ip-interface associated with network IP interfaces
configured on network port of hybrid port.
In access-uplink mode of operation meter/policer is available with the following:
•SAP ingress policies
•Network QoS policy associated with access-uplink port ingress
Meter ID
The meter parameters are:
•Meter ID
•Committed Information Rate for Meters
•Peak Information Rate for Meters
•Adaptation Rule for Meters
•Committed Burst Size (For Meter/Policers)
•Maximum Burst Size (For Meter/Policers)
•Meter Counters
•Meter Modes
The meter ID is used to uniquely identify the meter. The meter ID is only unique within the
context of the QoS policy within which the meter is defined.
487210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 49
Committed Information Rate for Meters
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.
The CIR for meter is provisioned on service ingress and network ingress within service
ingress QoS policies and network QoS policies, respectively.
QoS Policies
Peak Information Rate for Meters
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.
The PIR for meter is provisioned on service ingress and access uplink port or network port
ingress within service ingress QoS policies and network QoS policies, respectively
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide49
Page 50
QoS Overview
Adaptation Rule for Meters
The adaptation rule provides the QoS provisioning system with the ability to adapt the
administrative rates provisioned for CIR and PIR, to derive the operational rates based on the
underlying capabilities of the hardware. The administrative CIR and PIR rates are translated
to actual operational rates enforced by the hardware meter. The rule provides a constraint,
when the exact rate is not available due to hardware capabilities.
The hardware rate step-size is provided in Table 14:
Table 14: Supported Hardware rates and burst step sizes for CIR and PIR values for all platforms
The system attempts to find the best operational rate depending on the defined constraint.
The supported constraints are listed below:
Minimum: Find the next multiple of step-size that is equal to or greater than the
specified rate.
•Maximum: Find the next multiple of step-size that is equal to or less than the
specified rate.
•Closest: Find the next multiple of step-size that is closest to the specified rate.
Table 15 lists the rate values configured in the hardware when different PIR or CIR
rates are specified in the CLI.
Table 15: Administrative Rate Example
Administrative RateOperation Rate
(Min)
Operation Rate
(Max)
Operation Rate
(Closest)
8 8 8 8
507210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 51
Table 15: Administrative Rate Example (Continued)
QoS Policies
Administrative RateOperation Rate
(Min)
Operation Rate
(Max)
Operation Rate
(Closest)
1016 8 8
11808511808 11800 11808
46375463764636846376
If user has configured any value greater than 0 and less than 648 then operation rate
configured on hardware would be 648 kbps irrespective of the constraint used.
Note: 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. For example, if the rate specified is less than 4Gbps but the burst size
configured is 17Mbits, then the system uses rate step-size of 16Kbits and burst step-size of
8192bits (refer to Table 14, row#2)
Committed Burst Size (For Meter/Policers)
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.
Maximum Burst Size (For Meter/Policers)
For trTCM, 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, 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.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide51
Page 52
QoS Overview
The operational MBS set by the system is adapted from the user configured value by using
the minimum constraint.
Meter Counters
The 7210 SAS devices maintains the following counters for meters within the system for
granular billing and accounting. Each meter maintains the following counters:
•Counters for packets or octets marked as in-profile by meter
•Counters for packets or octets marked as out-of-profile by meter
Meter Modes
The 7210 SAS devices supports following meter modes:
•srtcm: Single Rate Three Color Marking
•trtcm: Two Rate Three Color Marking
•trtcm1:Two Rate Three Color Marking1 (Applicable only for Service Ingress QoS
Policies)
•trtcm2:Two Rate Three Color Marking2 (Applicable only for Service Ingress QoS
Policies)
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. trtcm1 implements the policing algorithm defined in RFC2698 and trtcm2
implements the policing algorithm defined in RFC4115.
Color Aware Policing
The 7210 SAS devices support Color Aware policing at the network ingress, where as at
service ingress policing an option is provided to use either color-aware policing or color-blind
policing. In color aware policing user can define the color of the packet using the
classification and feed those colored packets to the meter. A color aware meter would treat
those packets with respect to the color defined.
527210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 53
QoS Policies
•If the packet is pre-colored as in-profile (or also called as Green colored packets) then
depending on the burst size of the packet meter can either mark it in-profile or outprofile.
•If the packet is pre-colored as out-profile (also called as Yellow colored packets) then
even if the packet burst is lesser than the current available CBS, it would not be
marked as in-profile and remain as out-profile.
•If the packet burst is higher than the MBS then it would be marked as Red and would
be dropped by meter at ingress.
The profile marked by the meter is used to determine the packets eligibility to be enqueued
into a buffer at the egress (when a slope policy is configured at the egress).
In color-blind mode, the profile/color assigned to the packet on ingress is ignored. The CIR
and PIR rate configured for the meter is used to determine the final color/profile for the
packet. If the packet is within the CIR, then the final profile/color assigned to the packet is
in-profile/green and if the packets exceeds the CIR and is within the PIR, then the final
profile/color assigned to the packet is out-of-profile/yellow. Packets that exceed the PIR rate
are dropped.
In color-aware mode, the meter uses the profile assigned to the packet on ingress. Profile can
be assigned on ingress either by enabling DEI classification as done on access ports or by
assigning profile based on either Dot1p or DEI as done on network ports and access-uplink
ports. In color-aware mode, following behavior is available:
•If the packet is pre-colored as in-profile (or also called as Green colored packets) then
depending on the burst size of the packet meter can either mark it in-profile or outprofile.
•If the packet is pre-colored as out-profile (also called as Yellow colored packets) then
even if the packet burst is lesser than the current available CBS, it would not be
marked as in-profile and remain as out-profile.
•If the packet burst is higher than the MBS then it would be marked as Red and would
be dropped by meter at ingress.
QoS Overrides for Meters/Policers
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.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide53
Page 54
QoS Overview
Meter Override commands are supported on all types of access SAP.
Configuration guidelines of QoS Override
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.
•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 allowed when ToD is attached to the SAP.
•In 7210 SAS devices configured in access-uplink mode, QoS override commands are
not supported for ingress and egress QoS policies used with access-uplink SAPs and
ports.
•In QoS override commands are not supported ingress and egress QoS policies used
with network IP interfaces and network ports.
Configuring Meter Override parameters
The following example displays the meter override parameter configuration:
mode trtcm2
adaptation-rule pir max cir max
cbs 300
mbs 200
rate cir 300 pir 400
exit
exit
----------------------------------------------
*A:7210SAS>config>service>epipe>sap>ingress#
547210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 55
Queue Parameters
This section describes the queue parameters available for queue. Queues are available for use
in both network mode and access-uplink mode with the following policies.
In network mode of operation queue is available with the following:
→ Network Queue policies associated with network port or hybrid port egress.
→ Access-egress policies associated with access port egress.
•On 7210 SAS-Mxp network mode:
→ Network Queue policies associated with network port or hybrid port egress.
→ SAP egress policies associated with SAP egress (when SAP-based egress
queuing and scheduling is enabled for use).
→ Access-egress policies associated with access port egress (when port-based
egress queuing and scheduling is enabled for use).
QoS Policies
Queue ID
In access-uplink mode of operation a queue is available with the following:
•On 7210 SAS-M and 7210 SAS-T access-uplink mode:
→ Network Queue policies associated with access-uplink port egress.
→ Access-egress policies associated with access port egress.
The queue parameters are:
•Queue ID
•Committed Information Rate for Queues
•Peak Information Rate for Queues
•Adaptation Rule for Queues
•Committed Burst Size (CBS) and the Maximum Burst Size (MBS) for Queues
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. On 7210 SAS M, the queue ID
is not a user configurable entity but the queue ID is statically assigned to the 8 Queues on the
port according to FC-QID map table shown in Table 37.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide55
Page 56
QoS Overview
Committed Information Rate for Queues
The committed information rate (CIR) for a queue performs two distinct functions:
1. Minimum bandwidth guarantees — Egress 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 oversubscription and link port bandwidth capacity. For each packet in an egress
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. This in and
out profile state of queue is linked to scheduler prioritizing behavior as discussed
below.
2. Scheduler queue priority metric — The scheduler serving a group of egress 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.
Queues at the egress never marks the packets as in-profile or out-profile based on the queue
CIR, PIR values. The in-profile and out-profile state of the queue interacts with the scheduler
mechanism and provides the minimum and maximum bandwidth guarantees.
When defining the CIR for a queue, the value specified is the administrative CIR for the
queue. 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. The interpretation of the administrative CIR is discussed below in 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. A access 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 for a queue is provisioned on egress within access egress QOS policy.
The CIR for the network port queues (for 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/
10GE, 7210 SAS-Mxp in network mode) and access uplink port queues (for 7210 SAS-M and
7210 SAS-T in access uplink mode) are defined within network queue policies based on the
forwarding class. The CIR for the network queues is specified as a percentage of the network
interface bandwidth.
567210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 57
Peak Information Rate for Queues
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 a
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.
The PIR is provisioned on egress queues within access egress QoS policies.
The PIR for network queues are defined within network queue policies based on the
forwarding class. The PIR for the network queues is specified as a percentage of the network
interface bandwidth.
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 Adaptation Rule for Queues
QoS Policies
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 due to hardware implementation tradeoffs.
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 hardware upon which the queue is provisioned, the actual operational CIR
and PIR settings used by the queue will be dependant on the method the hardware uses to
implement and represent the mechanisms that enforce the CIR and PIR rates.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide57
Page 58
QoS Overview
The 7210 SAS uses a single rate step value of to define the granularity for both 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.
For the supported CIR/PIR range values 0 to 1Gb, the same hardware rate is show in Table 16
or the supported CIR/PIR range values 0 to 10Gb for a 10-Gig Port, the same hardware rate
is show in Table 17.
Table 16: Supported Hardware Rates and CIR/PIR Values for 7210 SAS-M, 7210 SAS-
T, and 7210 SAS-Sx/S 1/10GE devices
Hardware Rate StepsRate Range (kbps)
8 Kb/sec0 - 16770 kbps
16kbps16780 - 33540 kbps
32kbps33550 - 67090 kbps
64kbps67100 - 134180 kbps
128kbps 134190 - 268360 kbps
256kbps268370 - 536730 kpbs
512kbps 536740 - 1000000 kbps
Table 17: Supported Hardware Rates and CIR/PIR Values for 10-Gig Port for all
platforms
Hardware Rate Steps Rate Range
8 Kb/sec 0 - 16383 kbps
16kbps 16384 - 32767 kbps
32kbps 32768 - 65535 kbps
64kbps 65536 - 131071 kbps
128kbps 131072 - 262143 kbps
256kbps 262144 - 524287 kpbs
512kbps 524288 - 1048575 kbps
1024kbps 1048576 - 2097151 kbps
2048kbps2097152 – 4194303 kbps
4096kbps4194304 – 8388607 kbps
587210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 59
QoS Policies
Table 17: Supported Hardware Rates and CIR/PIR Values for 10-Gig Port for all
platforms (Continued)
Hardware Rate Steps Rate Range
8192kbps8388608 – 10000000 kbps
Table 18: Supported Hardware Rates and CIR/PIR Values for 7210 SAS-Mxp devices
Hardware Rate StepsRate Range (kbps)
8 Kb/sec0 - 16383 kbps
16kbps16384 - 32767 kbps
32kbps32768 - 65535 kbps
64kbps 65536 - 131071 kbps
128kbps 131072 - 262143 kbps
256kbps262144 - 524287 kpbs
512kbps 524288 - 1000000 kbps
To illustrate 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 96 Kbps and
152 Kbps 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 88 Kbps and
144 Kbps.
If the adaptation rule is closest, the operational CIR and PIR values will be 88 Kbps and 152
Kbps, respectively, as those are the closest matches for the administrative values that are even
multiples of the 8 Kbps rate step.
Committed Burst Size (CBS) and the Maximum Burst Size
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide59
Page 60
QoS Overview
(MBS) for Queues
The committed burst size and maximum burst size (CBS and MBS) parameters specify the
amount of buffers reserved for a queue and up to how much of buffers a queue can contend
for in the shared buffer space respectively 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.
On 7210 SAS-M, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T, CBS
for the queues is not configurable entity for the access, network ports and access uplink ports.
The CBS value for the queues is set to appropriate default values which takes care of specific
FC needs in terms of maintaining the differential treatment. The default values are provided
in the table below.
On 7210 SAS-Mxp, the CBS and MBS for the queues are configurable entities for the service
egress queues and network port queues. The CBS and MBS value for the queues is set to
appropriate default values which takes care of specific FC needs in terms of maintaining the
differential treatment. The default values are provided in the table below.
Table 19: Default CBS and MBS Values
PlatformsCBS in KBytes
(Network Queue/ Access
Uplink Queue)
SAS-T (MBS
1.681.68See Note 1See Note 1
CBS in KBytes
(Access Queue)
MBS in KBytes
(Network Queue/
Access Uplink
Queue)
MBS in KBytes
(Access Queue)
Pool= Node)
SAS-T (MBS
3.3753.375See Note 1See Note 1
Pool= Port)
SAS-M8.48.4See Note 2See Note 2
SAS-Mxp1281025664
607210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 61
QoS Policies
Note:
1. On 7210 SAS-T, both in network mode and access-uplink mode the node can be
operated with either per port MBS pool or per node MBS pool. In per port MBS pool
mode, the maximum MBS per queue, assuming no other queues on the same port have
any traffic is 33 Kbytes. In per node MBS pool mode, the maximum MBS that can be
utilized by a queue, assuming only some queues have traffic is 1458 Kbytes.
7210 SAS-T also supports decommissioning feature with per port MBS pool mode. With
it, per port MBS pool can be increased by taking away packet buffers from other ports.
In this case, the maximum MBS per queue, assuming no other queue has any traffic on
that port, depends on the user configuration. For example, assuming one port is
decommissioned and its buffers are allocated to port 1/1/1, then the maximum MBS per
queue on port 1/1/1, assuming no other queues have any traffic is 93 Kbytes.
The CLI command ‘show pool port id network-egress’ /‘show pool port id accessegress’/‘show pool Port ID access-uplink-egress’ are available to display the values in
use depending upon the mode of port. (Network/access/access-uplink).
2. On 7210 SAS-M, both in network mode and access-uplink mode, per port MBS pool
mode is used. With it the maximum MBS per queue, assuming no other queues on the
same port have any traffic is 83 Kbytes.
7210 SAS-M also supports decommissioning feature with per port MBS pool mode.
With it, per port MBS pool can be increased by taking away packet buffers from other
ports. In this case, the maximum MBS that can be utilized by a queue, assuming no
other queue has any traffic on that port, depends on the user configuration. For
example, assuming one port is decommissioned and its buffers are allocated to port
Port 1/1/1, then the maximum MBS per queue on port Port 1/1/1, assuming no other
queues have any traffic is 234 Kbytes.
The CLI command ‘show pool Port ID network-egress’ /‘show pool port id accessegress’/‘show pool Port ID access-uplink-egress’ are available to display the values in
use depending upon the mode of port. (Network/access/access-uplink).
Service Ingress QoS Policies
Service ingress QoS policies define ingress service forwarding class meters and map flows to
those meters. When a service ingress QoS policy is created, it has a single meter defined that
cannot be deleted, but used for all the traffic (both unicast and multicast traffic). These meters
exist within the definition of the policy. The meters only get instantiated in hardware when
the policy is applied to a SAP. In the case where the service does not have multipoint traffic,
the multipoint meters will not be instantiated.
In the simplest service ingress QoS policy, all traffic is treated as a single flow and mapped
to a single meter, including all flooded traffic is mapped to the same meter. 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.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide61
Page 62
QoS Overview
7210_001-7210
AAA
BABBB
EEEE
Ingress
Match
Criteria
Series - 1
Packet
Stream
Ingress
Policers/Meters
Egress
Queues
Egress Port
Scheduler
Expedited
Assured
Best Effort
•The number of classification and meter resources to allocate for this policy.
•Allocates resources from the ingress internal CAM resource pool for use for service
ingress QoS policies. Additionally, allocate resources to the appropriate
classification match criteria.
•At least one default forwarding class meter. The parameters that can be configured
for a meter are discussed in Meter/Policer Parameters.
Optional service ingress QoS policy elements include:
•Additional unicast meters up to a total of 8.
•Additional multipoint meters up to 31.
•QoS policy match criteria to map packets to a forwarding class.
Each meter or a queue can have unique meter or queue parameters to allow individual
policing or shaping of the flow mapped to the forwarding class. The figure below depicts
service traffic being classified into three different forwarding classes.
Figure 3: Traffic Queuing Model for Forwarding Classes
Mapping flows to forwarding classes is controlled by comparing each packet to the match
criteria in the QoS policy. The ingress packet classification to forwarding class is subject to
a classification policy provisioned.
On 7210 SAS devices, on SAP ingress user has an option to use either MAC criteria or IP
criteria or both IPv4 and MAC. To allow users to use the available classification resources
627210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
effectively the following options are available:
•Supported MAC header fields using the mac-criteria any option
Page 63
QoS Policies
•Only Dot1p bits in the MAC header using the mac-criteria dot1p-only option
•Supported IPv4 header fields using the ip-criteria any option
•Only IPv4 DSCP in the IPv4 header using the ip-criteria dscp-only option
•Supported IPv6 header fields using the ipv6-criteria any option
•Only IPv6 DSCP bits in the IPv6 header using the ipv6-criteria dscp-only option
•Both MAC and IPv4 header fields using the both MAC and IPv4 criteria option
together in a policy.
Among the above supported criteria the following can be configured together in a single
policy:
•mac-criteria any
•mac-criteria dot1p-only
•ip-criteria any and/or ipv6-criteria any or ipv6-criteria dscp-only
•ip-criteria dscp-only and/or ipv6-criteria any or ipv6-criteria dscp-only
•mac-criteria any and ip-criteria any or ip-criteria dscp-only and/or ipv6-criteria dscponly
•mac-criteria dot1p-only and ip-criteria any or ip-criteria dscp-only and/or ipv6criteria dscp-only
Note: When specifying both MAC and IP criteria in a single SAP ingress policy, only IPv6
DSCP match is allowed. Other IPv6 fields such as src-address, dst-address, are not allowed
to be used.
In addition to classification rules listed above, the user has an option to use DEI bit for
identifying the ingress profile and enable color-aware policing. See, Discard Eligibility
Indicator (DEI) based Classification and Marking. The below section lists the packets fields
that can be used for match-criteria used for SAP ingress classification.
Note: The resource allocation required for each of these different criteria is given at Service
Ingress QoS Policies.
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.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide63
Page 64
QoS Overview
Table 20: Service Ingress QoS Policy IP Match Criteria for 7210 SAS-M, 7210 SAS-Sx/S 1/10GE, 7210 SAS-
Sx 10/100GE, and 7210 SAS-Mxp network mode
IP Criteria
•IP DSCP value/mask and IP
Precedence value (available for SAPs
in VPLS, VLL, PBB Epipe I-SAP,
PBB VPLS I-SAP, IES and VPRN,
and R-VPLS services)
Table 21: Service Ingress QoS Policy MAC Match Criteria for 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE,
7210 SAS-Sx 10/100GE, and 7210 SAS-Mxp Network mode
MAC Criteria
IP source and mask, IP destination and mask,
IP protocol, TCP/UDP source port, TCP/UDP
destination port, (available only for SAPs in
VPLS, VLL, PBB Epipe I-SAP, PBB VPLS ISAP, IES and VPRN services)
•IEEE 802.1p/Dot1p value/mask, Source MAC
address/mask, Destination MAC address/mask,
EtherType Value/Mask (available for VLL,
VPLS, PBB (Epipe I-SAP, VPLS I-SAP, BSAP), IES, VPRN, and R-VPLS services.
Table 22: Service Ingress QoS Policy IPv6 Match Criteria for 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE,
7210 SAS-Sx 10/100GE and 7210 SAS-Mxp network mode
IPv6 Criteria
• IP DSCP value/mask and IP Precedence value
(available for SAPs in VPLS, VLL, PBB
services)
IPv6 128-bit source and mask, IPv6 128-bit destination
and mask, IP protocol/next-header, TCP/UDP source
port, TCP/UDP destination port, (available only for
SAPs in VPLS, VLL, PBB Epipe I-SAP,PBB VPLS ISAP)
Table 23: Service Ingress QoS policy MAC criteria for 7210 SAS-M and 7210 SAS-T access-uplink mode
IP Criteria
•IP DSCP value/mask and IP
Precedence value (available for access
SAPs in VPLS, VLL, IES, and RVPLS services)
647210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
IP source and mask, IP destination and mask, IP
protocol, TCP/UDP source port, TCP/UDP destination
port, (available only for access SAPs in VPLS, VLL,
and IES services)
Page 65
QoS Policies
Table 24: Service Ingress QoS Policy IPv6 Match Criteria in 7210 SAS-M and 7210 SAS-T access-uplink
mode
IPv6 Criteria
•IP DSCP value/mask and IP Precedence
value (available for SAPs in VPLS, and
VLL services)
IPv6 128-bit source and mask, IPv6 128-bit
destination and mask, IP protocol/next-header,
TCP/UDP source port, TCP/UDP destination
port, (available only for SAPs in VPLS and VLL
services)
Table 25: Service Ingress QoS Policy MAC Match Criteria in 7210 SAS-M and 7210 SAS-T access-uplink
mode
MAC Criteria
• IEEE 802.1p/Dot1p value/mask, Source
MAC address/mask, Destination MAC
address/mask, EtherType Value/Mask
(available for VLL, VPLS, IES, and RVPLS services.
The MAC match criteria that can be used for an Ethernet frame depends on the frame’s
format. See Table 26.
Table 26: MAC Match Ethernet Frame Types
Frame FormatDescription
802.3IEEE 802.3 Ethernet frame. Only the source MAC, destination MAC and
IEEE 802.1p value 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 27 lists the criteria that can be matched for the various MAC frame types.
Table 27: MAC Match Criteria Frame Type Dependencies
Frame FormatSource MACDest MACIEEE 802.1p ValueEtype Value
802.3YesYesYesNo
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide65
Page 66
QoS Overview
Frame FormatSource MACDest MACIEEE 802.1p ValueEtype Value
ethernet-IIYesYesYesYes
Table 27: MAC Match Criteria Frame Type Dependencies (Continued)
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 no queues are defined. All
traffic is mapped to the default forwarding class which uses a meter by default. The
characteristics of the default policy are listed in Table 28.
Table 28: Default Service Ingress Policy ID 1 Definition
ItemDefinition
Meter 11 (one) meter all unicast traffic:
•Forward Class: best-effort (be)
•CIR = 0
•PIR = max (4000000 kbps in case of a LAG with four
member ports)
•MBS, CBS = default (values derived from applicable
policy)
Default
Forwarding Class
1 (one) flow defined for all traffic:
•All traffic mapped to best-effort (be)
(be)
The available ingress CAM hardware resources can be allocated as per user needs for use with
different QoS classification match criteria. By default system allocates a single meter and 2
classification entries, so that all traffic is mapped to a single FC and the FC uses a single
meter. Users can modify the resource allocation based on their need to scale the number of
entries or number of associations (that is, number of SAPs using a policy that uses a particular
match criterion). If no resources are allocated to a particular match criteria used in the policy,
then the association of that policy to a SAP will fail. Allocation of classification entries also
allocates meter resources, used to implement the per FC per traffic type policing function.
Please refer to the Resource Allocation for Service Ingress QoS policies to know more about
resource usage and allocation to SAP ingress policies.
667210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 67
Hierarchical Ingress Policing
Hierarchical ingress policing allows the users to specify the amount of traffic admitted into
the system per SAP. It also allows the user to share the available bandwidth per SAP among
the different FCs of the SAP. For example, user can allow the packets classified as Internet
data to use the entire SAP bandwidth when other forwarding classes do not have traffic.
It provides an option to configure SAP aggregate policer per SAP on SAP ingress. The user
should configure the PIR rate of the aggregate policer. The user can optionally configure the
burst size of the aggregate policer.
The aggregate policer monitors the traffic on different FCs and determines if the packet has
to be forwarded to an identified profile or dropped. The final disposition of the packet is based
on the operating rate of the following:
•Per FC policer
•Per SAP aggregate policer
QoS Policies
For more information on the final color assigned of the packet, refer to the command
description of "aggregate-meter-rate" command in the 7210 SAS M,T,Mxp, Sx Services
Guide.
A new meter mode “trtcm2” (RFC 4115) is introduced for use only on SAP ingress. When
the SAP aggregate policer is configured, the per FC policer can be only configured in
“trtcm2” mode. The existing meter mode “trtcm” is re-named as “trtcm1” (RFC 2698). The
meter modes “srtCM” and “trtcm1” are used in the absence of aggregate meter.
Note: Before use of per SAP aggregate policer/meter, meter resources must be allocated
using the CLI command config> system> resource-profile> ingress-internal-tcam> sap-aggregate-meter. Change to the amount of resources allocated for SAP aggregate meter
requires a reboot of the node to take effect. The amount of resources allocated for this
feature determines the amount of SAPs that can use aggregate meter/policer. For more
information, see the 7210 Basic System Configuration User Guide.
Service Egress QoS Policies on 7210 SAS-Mxp
Service egress queues are implemented at the transition from the service core network to the
service access network and is available when SAP based egress queues and shaping is
enabled (using the command “configure>system>resource-profile> qos> no port-scheduler-mode”). The advantages of per-service queuing before transmission into the access network
are:
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide67
Page 68
QoS Overview
•Per-service egress subrate capabilities especially for multipoint services.
•More granular, fairer scheduling per-service into the access network.
•Per-service statistics for forwarded and discarded service packets.
The sub-rate capabilities and per-service scheduling control are required to make multiple
services per physical port possible. Without egress shaping, it is not possible to support more
than one service per port with QoS differentiation among services. There is no way to prevent
service traffic 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.
The system allocates 8 queues to service egress by default. 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.
•The parameters that can be configured for a queue are discussed in Queue Parameters
on page 39.
The optional service egress QoS policy elements include:
•Specify remark policy that defines IEEE 802.1p priority value remarking based on
forwarding class.
In 7210 SAS-Mxp, the user has an option to use SAP-based marking. With SAP based
marking the remark policy defined in the SAP egress policy associated with each SAP is used
to mark the packets egressing out of SAP if marking is enabled. See the Service Egress
Policies for 7210 SAS-Mxp and the Remark Policies to know about more marking behavior
and options available. The user also has an option to enable port-based marking, in which case
the remark policy defined in the access-egress policy associated with the access port
determines the marking values to use for all the SAPs defined on that port. For more
information, see Access Egress QoS Policies on 7210 SAS-Mxp.
687210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 69
QoS Policies
Note:
•
On 7210 SAS-Mxp, the users have an option to use either port-based egress queuing and
shaping or SAP-based egress queuing and shaping for SAPs configured on access ports
or hybrid ports. The command, “configure>system>resource-profile> qos>port-scheduler-mode”, lets the user select the mode to be used for SAPs configured on all the
ports of the node (in other words, this is a per node setting).
•On 7210 SAS-Mxp, if remarking is enabled in SAP egress policy and also port based
marking is disabled, then for L2 SAPs, the dot1p values configured in the SAP egress
policy is used. For L3 SAPs no marking is done.
•On 7210 SAS-Mxp, if remarking is enabled in SAP egress policy and also port based
marking is enabled, then for L2 SAPs, the dot1p values configured in the SAP egress
policy is used. For L3 SAPs the Dot1p and DSCP values configured in the access-egress
policy is used. In addition, for L2 SAPs, the DSCP values configured in the accessegress policy is used to mark the IP traffic sent out of L2 SAPs.
•On 7210 SAS-Mxp, if remarking is disabled for the SAP egress policy and port based
marking is enabled, then IP DSCP values are marked even for the traffic egressing out
of the L2 SAPs configured on the port. To avoid this, it is recommended to use only FC
to dot1p values when both L2 and L3 SAPs are configured on the same access port.
Each queue in a policy is associated with one of the forwarding classes. Each queue can have
an individual queue parameters allowing individual rate shaping of the forwarding class(es)
mapped to the queue. The forwarding class determination per service egress packet is
determined at ingress. If the packet ingressed the service on the same node, 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.
The FC to queue map is fixed and the queue's priority is determined by the queue number,
with higher queue number having the higher priority. The user can configure a queue to be a
strict queue to change the scheduling behavior for that queue. For more information, see
Schedulers on 7210 SAS-Mxp.
Note: On 7210 SAS-Mxp, only unicast traffic sent out of RVPLS SAPs uses per SAP egress
queues. BUM traffic sent out of RVPLS SAPs uses per port egress queues.
Service egress QoS policy ID 1 is reserved as the default service which do not have another
service egress policy explicitly assigned. The characteristics of the default policy are listed in
the following table.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide69
Page 70
QoS Overview
Table 29: Default SAP Egress Policy ID 1 Definition for 7210 SAS-Mxp
Item Definition
Queue 1-81 (one) queue defined for each traffic class
Queue 8•CIR=0
•PIR=max (line rate)
•Cir-Level 1
•Pir-Weight 1
•Queue-Management Policy : default
Queue7•CIR=0
•PIR=max (line rate)
•Cir-Level 1
•Pir-Weight 1
•Queue-Management Policy : default
Queue 6 •CIR = 0
•PIR = max (line rate)
•Cir-Level 1
•Pir-Weight 1
•Queue-Management Policy : default
Queue 5•CIR = 0
•PIR = max (line rate)
•Cir-Level 1
•Pir-Weight 1
•Queue-Management Policy : default
Queue 4 •CIR = 0
•PIR = max (line rate)
•Cir-Level 1
•Pir-Weight 1
•Queue-Management Policy : default
707210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 71
QoS Policies
Table 29: Default SAP Egress Policy ID 1 Definition for 7210 SAS-Mxp (Continued)
Item Definition
Queue 3•CIR = 0
•PIR = max (line rate)
•Cir-Level 1
•Pir-Weight 1
•Queue-Management Policy: default
Queue 2•CIR = 0
•PIR = max (line rate)
•Cir-Level 1
•Pir-Weight 1
•Queue-Management Policy : default
Queue 1•CIR = 0
•PIR = max (line rate)
•Cir-Level 1
•Pir-Weight 1
•Queue-Management Policy : default
Default ActionAll FCs are mapped to corresponding Queues and Dot1p values
are marked as follows:
Access Egress QoS Policies on 7210 SAS-M, 7210
SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/
100GE
An access egress policy defines the access port queues, mapping of Forwarding class (FC) to
queue, and marking characteristics for the traffic egressing towards the customer on the
access ports. By configuring appropriate queue shape rates the individual FC traffic can be
managed so that each FC traffic is well within SLA limits and does not impact the
serviceability of other FCs.
The number of queues available per access port on different 7210 platforms is as given below:
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide71
Page 72
QoS Overview
•On 7210 SAS-M and 7210 SAS-T are 8 queues always available per access port and
all forwarding classes traffic is mapped into these separate 8 queue as per Forwarding
Class to Queue-ID Map, For more information, see Forwarding Class to Queue-ID
Map for 7210 SAS-M, 7210 SAS-T, and 7210 SAS-Mxp.
•On 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, 16 queues are available per
access port, with 8 queues allocated for unicast traffic and 8 allocated for multicast
traffic. For each of the 8 FCs, unicast traffic and multicast traffic is mapped to two
different queues, for a total of 16 queues across 8 FCs. For more information, see
Forwarding Class to Queue-ID Map for 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx
10/100GE
To define a basic access egress QoS policy, the following are required:
•A unique service access QoS policy ID.
•A QoS policy scope of template or exclusive.
•The parameters that can be configured for a queue are discussed in Queue
Parameters.
•On 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, the access egress policy
allows users to specify a single rate for both multicast and unicast queues. In other
words, rates cannot be specified individually for unicast queue and multicast queue
of a given FC. Instead the rate specified for a queue (say Queue #8) is distributed
equally to the unicast queue and multicast queue associated with the FC. See the
Schedulers on 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE for more
information.
•Remarking (for example: IEEE 802.1p value, etc.) based on forwarding class.
In the 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE,
remarking of dot1p or DSCP or both bits by default is disabled. It can be enabled by the
remarking command with options to remark dot1p/dscp/both present under access-egress
context.
The following options are available on different platforms:
•In 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE,
network mode, user is provided with an option to remark Dot1p or DSCP or both.
•In 7210 SAS-M and 7210 SAS-T access-uplink mode, user is provided with an
option to remark both Dot1p bits and IP DSCP bits.
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.
The forwarding class is determined as follows for network mode and access-uplink mode:
727210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 73
QoS Policies
•In network mode, if the packet was received over a service transport tunnel on a
network port, the forwarding class is typically determined by in the MPLS LSP EXP
bits.
•For 7210 SAS-M and 7210 SAS-T in access uplink mode, if the packet was received
on a access-uplink port, the forwarding class is determined by the Dot1p bits in the
outer tag of the QinQ encapsulation.
Access egress QoS policy ID 1 is reserved as the default access ports which do not have
another access egress policy explicitly assigned. The characteristics of the default policy are
listed in the following table.
Table 30: Default Access Egress Policy ID 1 Definition for 7210 SAS-M and 7210 SAS-T
CharacteristicItem Definition
QueuesQueue 1-81 (one) queue defined for each traffic class
Network-Control (nc)Queue 8•CIR=0
•PIR=max (line rate)
•CBS=default (values derived for
optimal buffer usage)
High-1 (h1)Queue7•CIR=0
•PIR=max (line rate)
•CBS=default (values derived for
optimal buffer usage)
Expedited (ef)Queue 6 •CIR = 0
•PIR = max (line rate)
•CBS = default (values derived for
optimal buffer usage)
High-2 (h2)Queue 5•CIR = 0
•PIR = max (line rate)
•CBS = default (values derived for
optimal buffer usage)
Low-1 (l1) Queue 4 •CIR = 0
•PIR = max (line rate)
•CBS = default (values derived for
optimal buffer usage)
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide73
Page 74
QoS Overview
Table 30: Default Access Egress Policy ID 1 Definition for 7210 SAS-M and 7210 SAS-T
CharacteristicItem Definition
Assured (af)Queue 3•CIR = 0
•PIR = max (line rate)
•CBS = default (values derived for
optimal buffer usage)
Low-2 (l2)Queue 2•CIR = 0
•PIR = max (line rate)
•CBS = default (values derived for
optimal buffer usage)
Best-Effort (be) Queue 1•CIR = 0
•PIR = max (line rate)
•CBS = default (values derived for
optimal buffer usage)
Flows Default
Action
All FCs are mapped to corresponding
Queues and Dot1p values are marked as
follows:
Table 31: Default Access Egress Policy ID 1 Definition for 7210 SAS-M and 7210 SAS-T
CharacteristicDefinitionDefinition
In-ProfileOut-Profile
Network-Control (nc)7 7
High-1(h1)66
Expedited (ef)55
High-2 (h2)44
Low-1 (l1)33
Assured (af)2 2
Low-2 (l2)1 1
Best-Effort (be) 0 0
747210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 75
QoS Policies
Access Egress QoS Policies on 7210 SAS-Mxp
On 7210 SAS-Mxp, the users have an option to use either port-based egress queuing and
shaping or SAP-based egress queuing and shaping for SAPs configured on access ports or
hybrid ports. The command, “configure>system>resource-profile> qos>port-scheduler-mode”, lets the user select the mode to be used for SAPs configured on all the ports of the
node (in other words, this is a per node setting).
On 7210 SAS-Mxp platforms, an access egress policy provides different functionality based
on the queuing mode in use as described in the following sections.
Access Egress QoS policy for SAP-based queuing
mode on 7210 SAS-Mxp
When SAP-based egress queues are in use, 7210 SAS-Mxp supports SAP-based marking for
access SAPs and port-based egress marking on access ports. SAP-based marking is only
supported for L2 SAPs, that is, SAPs configured in Epipe and VPLS service. If user enables
remarking in the SAP egress policy attached to the SAP, then the remark policy configured
is used to mark the packets sent out of the SAP. If remarking is disabled in the SAP egress
policy attached to the SAP, then remark policy configured under the access-egress policy
associated with the egress access port is used to mark all packets sent out of the L2 SAP
configured on the access port. This is known as port-based marking. Port-based marking is
supported primarily for L3 SAPs (that is, SAPs configured in VPRN services and IES
services). In other words, SAP based marking is not supported for L3 SAPs.
On 7210 SAS-Mxp, no explicit CLI command is provided to choose between port-based
marking and SAP-based marking for L2 SAPs. The user can choose SAP based marking by
enabling remarking in the SAP egress policy attached to the L2 SAP or choose port based
marking by disabling remarking in the SAP egress policy attached to the SAP and enabling
remarking in the access-egress policy associated with the access port on which the L2 SAP is
configured.
A remarking policy can be defined for each access egress policy and remarking is disabled
by default. Only remarking policy of type dot1p, dot1p-lsp-exp-shared, dscp or dot1p-dscp
can be used with access-egress policy. The following is the marking behavior with different
remark policy types (see the note below):
•If remark policy type is dot1p or dot1p-lsp-exp-shared, then all traffic sent out of L2
SAPs and L3 SAPs configured on that port will have its Dot1p bits marked.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide75
Page 76
QoS Overview
•If remark policy type is dscp, then all traffic sent out of L2 SAPs and L3 SAPs
configured on that port will have its IP DSCP bits marked (assuming L2 SAPs are
carrying IP traffic).
•If remark policy type is of type dot1p-dscp, then all traffic sent out of L2 SAPs and
L3 SAPs configured on that port will have its IP DSCP bits (assuming L2 SAPs are
carrying IP traffic) and Dot1p bits marked.
Access egress QoS policy ID 1 is reserved as the default access egress policy. The default
policy cannot be deleted or changed. The default access egress policy is applied to all access
ports which do not have another access egress policy explicitly assigned. By default sapqos-marking is enabled.
Note: :
•On 7210 SAS-Mxp, if remarking is enabled in SAP egress policy and also port based
marking is disabled, then for L2 SAPs, the dot1p values configured in the SAP egress
policy is used. For L3 SAPs no marking is done.
•On 7210 SAS-Mxp, if remarking is enabled in SAP egress policy and also port based
marking is enabled, then for L2 SAPs, the dot1p values configured in the SAP egress
policy is used. For L3 SAPs the Dot1p and DSCP values configured in the accessegress policy is used. In addition, for L2 SAPs, the DSCP values configured in the
access-egress policy is used to mark the IP traffic sent out of L2 SAPs.
•On 7210 SAS-Mxp, if remarking is disabled for the SAP egress policy and port based
marking is enabled, then IP DSCP values are marked even for the traffic egressing out
of the L2 SAPs configured on the port. To avoid this, it is recommended to use only FC
to dot1p values when both L2 and L3 SAPs are configured on the same access port.
Access egress QoS policy ID 1 is reserved as the default access egress policy. The default
policy cannot be deleted or changed. The default access egress policy is applied to all access
ports which do not have another access egress policy explicitly assigned. By default sap-qosmarking is enabled.
Access Egress QoS policy for Port-based Queuing
mode on 7210 SAS-Mxp
On 7210 SAS-Mxp, when port-based queues are enabled, in addition to marking values, the
access egress QoS policy provides an option to define port-based queues and scheduling.
767210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 77
QoS Policies
When port-scheduler-mode is enabled, software uses 8 egress queues per access port or
hybrid port and all the SAPs configured on the port will share the 8 egress queues for traffic
sent out of that port. When port-scheduler-mode is enabled, the queue parameters for the
access port egress queues are defined using the access egress policies.
Additionally, the marking values used to mark traffic from different forwarding classes is
defined by the remark policy in the access egress policy. In other words, per SAP marking
cannot be used when Port-based queuing mode is used. A remarking policy can be defined
for each access egress policy and remarking is disabled by default. Only remarking policy of
type dot1p, dot1p-lsp-exp-shared, dscp or dot1p-dscp can be used with access-egress policy.
The following is the marking behavior with different remark policy types:
•If remark policy type is dot1p or dot1p-lsp-exp-shared, then all traffic sent out of L2
SAPs and L3 SAPs configured on that port will have its Dot1p bits marked.
•If remark policy type is dscp, then all traffic sent out of L2 SAPs and L3 SAPs
configured on that port will have its IP DSCP bits marked (assuming L2 SAPs are
carrying IP traffic).
•If remark policy type is of type dot1p-dscp, then all traffic sent out of L2 SAPs and
L3 SAPs configured on that port will have its IP DSCP bits (assuming L2 SAPs are
carrying IP traffic) and Dot1p bits marked.
Note:
•When port-scheduler-mode is disabled, per SAP egress queues are available for use.
The per SAP egress queues are configured in the service egress policies.
•In 7210 SAS-Mxp, with port-based queuing mode is enabled, RVPLS SAPs use the
port-based egress queues for both unicast and BUM traffic. In other words, all the
SAPs, including RVPLS SAPs share the 8 egress queue created per port.
•When port-based queues are enabled, SAPs configured on hybrid port shares the
egress queues with network port traffic. Packets sent out a SAP on a hybrid port use
the marking values, if remarking is enabled, defined in the network QoS policy
associated with the hybrid port.
On 7210 SAS-Mxp, access egress QoS policies define egress queues and map forwarding
class flows to queues, if port-scheduler-mode is enabled. In port-scheduler-mode, the system
allocates 8 queues to access port egress by default. To define a basic access egress QoS
policy, the following are required:
•A unique access egress QoS policy ID.
•A QoS policy scope of template or exclusive.
•The parameters that can be configured for a queue are discussed in Queue
Parameters.
Optional service egress QoS policy elements include:
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide77
Page 78
QoS Overview
•Specify remark policy that defines IEEE 802.1p priority value remarking based on
forwarding class.
On 7210 SAS-Mxp, when port-based queuing is used, the FC to queue map is fixed and the
queue's priority is determined by the queue number, with higher queue number having the
higher priority. The user can configure a queue to be a strict queue to change the scheduling
behavior for that queue. For more information about scheduling Schedulers on 7210 SAS-
Mxp.
Buffer Pools on 7210 SAS-M and 7210 SAS-T
The 7210 SAS devices, when operating in network mode and access-uplink mode, supports
either one or both of the two modes of buffer pool allocation for port egress queues - per port
MBS pool and per node MBS pool. The buffer pools take care of the buffer requirements at
the port level for various queue shaping/ scheduling mechanisms. In addition, in per port
MBS pool mode, an option is provided to decommission the port and allocate its buffers
towards other ports. The following sections provides more information about these two
modes.
Buffer pool allocation - Per port MBS pool (7210 SAS-M and
7210 SAS-T)
When the decommission entries are not configured, during system initialization, based on the
maximum number of ports supported on the device, the total buffer is distributed into per port
egress buffer pool for access ports, network ports, access-uplink ports and hybrid ports. Each
port on the system gets an equal portion of the available buffers. From the buffers allocated
to a port, each queue gets its CBS amount of buffers. The remaining buffers are allocated
towards the shared MBS pool per port. All the queues of the port can use the buffers from the
shared MBS pool. This model of buffer pool allocation is called per port MBS pool.
With the per port MBS pool, each queue is allocated with a small fixed amount of buffers
towards the CBS (Committed burst size) and each port is allocated with a shared pool of
buffers towards the MBS (Maximum Burst Size). The queue’s CBS portion of buffers
guarantees that the queue does not starve due to lack of buffers. The buffers allocated towards
the MBS pool, allows each port to handle some amount of burst. Per port MBS pool/portion
of buffers is shared by all the queues of the port and allows any queue or a small group of
queues of the port to absorb larger bursts assuming that, not all the queues receive burst
simultaneously. In a typical network, the router/switch in the ingress traffic is usually a mix
of packets of different sizes and different flows burst at different time intervals, which allows
for better burst absorption capability per queue using shared resources.
787210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 79
QoS Policies
Buffer pool allocation - Per Node MBS pool on 7210 SAS-T
In the per node MBS pool mode, each of the queue on a port, is allocated a CBS amount of
committed buffers. The remaining amount of buffers is allocated towards the MBS pool that
is available for sharing among all the queues across all the ports of the node. The queue’s CBS
portion of buffers guarantees that the queue does not starve due to lack of buffers. The buffers
allocated towards the node’s MBS pool, allows each port to handle some amount of burst. Per
port MBS pool of buffers is shared by all the queues of the port and allows any queue or a
group of queues across multiple ports to absorb larger bursts, assuming that not all the queues
on all the ports receive burst simultaneously. In a typical network, the router/switch in the
ingress traffic is usually a mix of packets of different sizes and different flows burst at
different time intervals, which allows for better burst absorption capability per queue using
shared resources.
The hardware implements an algorithm to handle requests for allocation of buffers from the
MBS pool (in both models) assuming that not all the ports and queues burst at the same time.
This allows some queues to utilize a larger portion of the buffers when it is available, allowing
them to handle larger bursts. At the same time, the algorithm ensures that all the queues get
fair share of the buffers, so that the throughput on those ports is not affected. When hardware
receives a packet, before it decides to queue up the packet on the egress queue of the
destination port, it determines the discard threshold for the queue based on the
oversubscription factor and the total amount of free buffers available at that point of time. The
queue’s discard threshold is higher, if the amount of free buffers available is larger (which
indicates other queues on the node have lesser congestion), allowing the queue to absorb
larger bursts. The queue’s discard threshold is lower, if there is lesser amount of free buffers
available (which indicates that other queues are heavily congested on the node), which results
in the packet being dropped. At the same time, algorithm allocates the available free buffers
to queues which are using lesser amount of buffers or not using any buffers. This allows equal
sharing of available buffers and maintains a good throughput for less congested queues.
On 7210 SAS-M (in both access-uplink mode and network mode), 4MB of buffers are
available and by default per port MBS pool is used. Per node MBS pool of buffers is not
supported
On 7210 SAS-T (in both access-uplink and network mode), 2MB of buffers are available and
by default per node MBS pool is used and an option is available to user to change it to per
port MBS pool.
Note: On both 7210 SAS-M and 7210 SAS-T, in both network mode and access-uplink
mode, and with either per port MBS pool or per node MBS pool, the system internal ports,
such as internal loopback port used for mirroring, port loopback with mac-swap, and others
are allocated some buffers. Additionally, some buffers are reserved for internal use.
Buffer pools cannot be created or deleted in the 7210 SAS.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide79
Page 80
QoS Overview
Decommissioning Ports with Per port MBS pool
To allow operators better control over which ports get larger portion of queue buffers, the
operator is provided with an option to use per-port MBS pool (like what is available on 7210
SAS-M) and decommission ports. The decommissioning of ports is only allowed when the
node is booted with the option to use per-port MBS pool.
With the decommissioning feature, the user is provided with an option to make efficient use
of the available port egress queue buffer pool by allocating queue buffers of the unused ports
to in-use ports. It allows the user to specify the unused front-panel ports which cannot be used
to deploy any services. The software does not allocate any queue buffers to these unused ports
and assigns it to a specific port or a group of ports. The user is provided with a CLI command
to decommission a port and make it unavailable to deploy services. This mechanism allows
operators who use limited number of ports to deploy services, to increase the amount of queue
buffers allocated to them by decommissioning ports that will not be used to deploy any
services.
Using decommission command for Buffer Allocation on 7210 SASM and 7210 SAS-T devices
Note: The platforms that support using decommission command for buffer allocation are
7210 SAS-M in both access-uplink and network mode, all variants of 7210 SAS-M – namely
7210 SAS-M 24F, 7210 SAS-M 24F 2XFP (ETR and non-ETR), with or without the CES
MDA and the 2x10G MDA, and 7210 SAS-T. On 7210 SAS-M variants that support the 2
x10G MDA, it is possible to decommission the 10G ports on the MDA or to allocate more
buffers to the 10G ports on the MDA. This feature is not supported on 7210 SAS-Mxp.
This feature enables the user to make efficient use of the available port egress queue buffer
pool by allocating queue buffers of the unused ports to ports. Services cannot be configured
on the unused ports as software takes away all the queue buffer resources from these ports
that need increased amount of buffers to handle larger bursts. This allows the operators who
use limited number of ports to deploy services, to increase the amount of queue buffers
allocated to them by decommissioning ports that are not used to deploy services.
The amount of credit of queue buffers received by a port is used to increase the MBS portion
of the buffer pool of the port. This allows any queue on the port to use the buffers, if needed.
The CBS portion of the queue is not modified with this feature.
Note: The system has to be rebooted after decommissioning of ports for the queue buffers
to be reallocated and the configuration to take effect.
807210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 81
QoS Policies
The users have an option to specify the groups of ports which receives the credit of queue
buffers freed up using the decommission command. With this option, the user can specify a
port or group of ports which receives the credit of queue buffers. For example, it is possible
for the user to configure decommissioning of 4 fixed copper ports and allocate the freed queue
buffers to the remaining copper ports in the system or decommission 5 fiber ports and allocate
the freed up queue buffers to the 10G XFP ports, and so on. This mechanism allows the
operators to provide higher amount of queue buffers to a specific port or a group of ports,
allowing them to pick and choose ports that need the extra buffers for burst absorption. The
user is allowed to increase the per port MBS pool limit so that more buffers are available to
absorb larger bursts, at the cost of decommissioning ports which are not used to configure
services.
Configuration guidelines for use of ‘Decommission’ commands on
7210 SAS-M and 7210 SAS-T devices
•The CLI command “configure>system>resource-profile>decommission>entry”
allows the user to configure the list of ports to be decommissioned and the list of ports
that need more buffers. The system does not allocate any packet buffers to the ports
which are decommissioned. For more information, see the CLI command description
for details on the functionality provided by the command.
•Packet buffers are added to the MBS pool of the port (the MBS pool is shared by the
8 queues on the port) and the CBS portion of the queues are not modified.
•The user can modify the list of ports or update to the list of ports specified with the
decommission command (and also entry command) when the node is up, but the
changes are effected by software only after a reboot of the 7210 SAS-M node.
•The software maintains two lists of entries, one is the current list of ports and another
which has been modified by the user and takes effect only after the next reboot. These
lists can be displayed using the show command. The configuration file always stores
the list of entries as configured by the user, so that when rebooted the modified
entries and new entries (if any) takes effect.
•A port must be in administrative down (shutdown) state before it is in a
decommission entry. An attempt to configure a port which is administratively up (no
shutdown) state results in an error. The administrative state or the operational state
of the port is not affected by configuring the port in a decommission entry.
•The decommissioned port cannot be used in any service configuration or as a
loopback port. An attempt to do so results in an error.
•The decommissioned port must not be configured with BOF parameter, ‘no-serviceports’.
•Buffer allocation to a port should is possible for access ports, network ports or hybrid
ports. In other words, irrespective of port mode, it is possible to assign more buffer
resources to the port.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide81
Page 82
QoS Overview
•The user needs to ensure that enough buffers are available for the internal loopback
ports or front-panel ports assigned for loopback. It is not recommended to take away
buffers allocated to these ports and assign it to other ports. This might cause
unintended behavior of the system. The system software does not check for this, but
expects users to ensure this through proper configuration.
•During system boot up, while executing the commands in the configuration file
software checks if the no-service-ports are configured under the decommission
entries. If there is match, software throws an error and stops execution of further
commands in the configuration file. When this happens, user needs to correct the
configuration file or the BOF file, to either remove the ports from the decommission
entries or not configure them as no-service-ports in the BOF, save the BOF file or the
configuration file based on where the change was made and reboot the node.
•On 7210 SAS-T, the decommission command takes affect only if the per port MBS
pool is in use, that is, the user needs to configure the CLI command
“configure>configure> system> resource-profile> qos> mbs-pool port”, before
using the decommission port feature.
The following configuration sample shows the ports to be decommissioned and the ports that
need more buffers.
A:7210SAS>config>system>res-prof>decom# info detail
---------------------------------------------entry 15 port 1/2/1,1/2/2 to 1/1/2
entry 23 port 1/1/5 to 1/1/3
Note: For more information on the decommission CLI commands, see the “7210 SAS OS
Basics System User Guide”.
Buffer Pools on 7210 SAS-Sx/S 1/10GE and 7210
SAS-Sx 10/100GE devices
The 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE has 4MB of packets buffers and it
supports only a single mode of operation, per node MBS pool, in this release. In this mode,
the MBS pool is shared across all queues on all ports. In the per node MBS pool mode, each
of the 16 egress queues available on a port, is allocated a CBS amount of committed buffers.
The remaining amount of buffers is allocated towards the per node MBS pool that is available
for sharing among all the queues across all the ports of the node.
827210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 83
QoS Policies
NOTE: The system internal ports, such as internal loopback port used for mirroring, port
loopback with mac-swap, and others are allocated with some buffers. Additionally, some
buffers are reserved for system internal use (for example: CPU queues, etc.).
The amount of buffers remaining after allocating buffers for system internal use is available
for allocation towards MBS buffers for all egress queues and per node MBS pool.
The hardware implements an algorithm to handle requests for allocation of buffers from the
MBS pool assuming that not all the ports and queues burst at the same time. This allows some
queues to utilize a larger portion of the buffers when it is available, allowing them to handle
larger bursts. At the same time, the algorithm ensures that all the queues get fair share of the
buffers, so that the throughput on those ports are not affected. When the hardware receives a
packet, before it decides to queue up the packet on the egress queue of the destination port, it
determines the discard threshold for the queue based on the oversubscription factor and the
total amount of free buffers available at that point of time. The queue’s discard threshold is
higher, if the amount of free buffers available is larger (which indicates other queues on the
node have lesser congestion), allowing the queue to absorb larger bursts. The queue’s discard
threshold is lower, if there is lesser amount of free buffers available (which indicates that
other queues are heavily congested on the node), which results in the packet being dropped.
At the same time, algorithm allocates the available free buffers to queues which are using
lesser amount of buffers or not using any buffers. This allows equal sharing of available
buffers and maintains a good throughput for less congested queues.
NOTE: 7210 SAS-Sx/S 1/10GE does not support per port MBS pool mode and port
decommissioning features in this release. Buffer pools cannot be created or deleted in 7210
SAS.
Buffer Pools on 7210 SAS-Mxp
The 7210 SAS-Mxp has a single buffer pool per node, the system pool. All the queues created
by the system are allocated buffers from this system pool. Queues come up with default
buffers, and the buffers change accordingly when they are associated with a network port or
SAP. Queue management policies allow the user to specify the parameters that determine
buffer allocation to the queues. Buffer pools cannot be created or deleted in the 7210 SAS.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide83
Page 84
QoS Overview
Slope Policies for 7210 SAS-M, 7210 SAS-T, 7210
SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE
devices
Note: On 7210 SAS-Mxp, the queue management policies are used to configure the WRED
slopes.
The available buffer space is partitioned into buffer pools. The buffers for a queue are
allocated from the available buffer pool as described in the section on Buffer Pools on 7210
SAS-M and 7210 SAS-T, Buffer Pools on 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/
100GE devices, and Buffer Pools on 7210 SAS-Mxp.
Slope policies define the RED slope characteristics as a percentage of pool size for the pool
on which the policy is applied. When per port MBS pool configuration is used. When per
node MBS pool is in use, the slope parameters are interpreted as a percentage of the logical
size for the queue and is not a percentage of the total MBS pool size.
On 7210 SAS-M and 7210 SAS-T (network mode and access-uplink mode), default buffer
pools exist (logically) at the port levels, when configured to use per port MBS pool.
•Access egress pool
•Network egress pool (in network mode)
•Access uplink egress pool (in access uplink mode)
By default, each queue on the port is associated with slope-policy default which disables the
high-slope, low-slope, and non-TCP slope within the pool.
On 7210 SAS-M (network mode and access-uplink mode) Access, network pools (in network
mode) and access uplink pools (in access uplink mode) are created at the port level, when per
port MBS pool is configured, creation is dependent on the physical port mode (network,
access, or access uplink).
NOTE: If WRED is not configured, then taildrop is used.
847210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 85
RED Slopes In Network and Access-uplink Mode
Operation and Configuration
On 7210 SAS platforms RED slopes support is as follows:
•On 7210 SAS-M (network mode and access-uplink mode) each queue provides user
an option to configure high-priority RED slope a non-TCP RED slope, and a lowpriority RED slope -OR- use 2 slopes - high-priority RED slope and a low-priority
RED slope per queue.
•On 7210 SAS-T (both network mode and access-uplink mode), each queue, supports
a high-priority RED slope and a low-priority RED slope.
On 7210 SAS-Mxp, each queue supports a high-priority RED slope and a lowpriority RED slope.
•On 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, each queue supports a
high-priority RED slope and a low-priority RED slope.
QoS Policies
The high-priority RED slope manages access to the shared portion of the buffer pool for highpriority 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. The non-TCP slope
manages access to the shared portion of the buffer pool for non-TCP packets (such as MPLS
packets received on network ingress).
By default, all slopes are disabled.
The WRED uses average queue lengths, queue thresholds provisioned, and drop probability
to calculate the packet’s eligibility to be enqueued. The committed portion of the buffer pool
is exclusively used by a queue to enqueue traffic within committed rate.
For the queues within a buffer pool, packets are either queued using committed burst size
(CBS) buffers or shared buffers. The CBS buffers are simply buffer memory that has been
allocated to the queue while the queue depth is at or below its CBS threshold.
The percentage of the buffers that are to be reserved for CBS buffers is configured by the
software (cannot be changed by user). This setting indirectly assigns the amount of shared
buffers on the pool. This is an important function that controls the ultimate average and total
shared buffer utilization value calculation used for RED slope operation. The CBS setting can
be used to dynamically maintain the buffer space on which the RED slopes operate.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide85
Page 86
QoS Overview
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, the
buffer pool uses two RED slopes 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.
The following is a simplified overview of how a RED slope determines shared buffer
availability on a packet basis:
1. The RED function keeps track of shared buffer utilization and shared buffer average
utilization.
2. At initialization, the utilization is 0 (zero) and the average utilization is 0 (zero).
3. When each packet is received, the current average utilization is plotted on the slope
to determine the packet’s discard probability.
4. A random number is generated associated with the packet and is compared to the
discard probability.
5. The lower the discard probability, the lower the chances are that the random number
is within the discard range.
6. 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.
7. 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.
8. If the packet is queued, a new shared buffer average utilization is calculated using the
time-average-factor (TAF) for the buffer pool. The TAF describes the weighting
between the previous shared buffer average utilization result and the new shared
buffer utilization in determining the new shared buffer average utilization. (See
Tuning the Shared Buffer Utilization Calculation.)
9. 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.
10. 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.
867210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 87
Figure 4: RED Slope Characteristics
QoS Policies
Probability
1
.75
.50
.25
0
0%25%50%75%100%
Max-Avg
B
Start-Avg
A
Average Utilization
D
C
Max-Prob
OSSG020
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 4):
1. 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.
2. 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.
3. 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.
4. 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 access or network queues using the shared
portion of the buffer pool, including disabling the RED slope.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide87
Page 88
QoS Overview
Tuning the Shared Buffer Utilization Calculation
The 7210 SAS allows tuning the calculation of the Shared Buffer Average Utilization
(SBAU) after assigning buffers for a packet entering a queue as used by the RED slopes to
calculate a packet’s drop probability. It implements a time average factor (TAF) parameter in
the buffer policy which determines the contribution of the historical shared buffer utilization
and the instantaneous Shared Buffer Utilization (SBU) in calculating the SBAU. The TAF
defines a weighting exponent used to determine the portion of the shared buffer instantaneous
utilization and the previous shared buffer average utilization used to calculate the new shared
buffer average utilization. To derive the new shared buffer average utilization, the buffer pool
takes a portion of the previous shared buffer average and adds it to the inverse portion of the
instantaneous shared buffer utilization (SBU). The formula used to calculated the average
shared buffer utilization is:
where:
SBAU
SBAU
= Shared buffer average utilization for event n
n
= Shared buffer average utilization for event (n-1)
n-1
SBU = The instantaneous shared buffer utilization
TAF = The time average factor
Table 29 shows the effect the allowed values of TAF have on the relative weighting of the
instantaneous SBU and the previous SBAU (SBAU
SBAU (SBAU
Table 32: TAF Impact on Shared Buffer Average Utilization Calculation
TAF
0
1
2
2
2
TAF
0
1
).
n
Equates ToShared Buffer
Instantaneous
Utilization Portion
11/1 (1)0 (0)
21/2 (0.5)1/2 (0.5)
has on the calculating the current
n-1)
Shared Buffer Average
Utilization Portion
887210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 89
QoS Policies
Table 32: TAF Impact on Shared Buffer Average Utilization Calculation (Continued)
TAF
2
3
4
5
6
7
8
9
10
11
2
2
2
2
2
2
2
2
2
2
2
TAF
2
3
4
5
6
7
8
9
10
11
Equates ToShared Buffer
Instantaneous
Utilization Portion
Shared Buffer Average
Utilization Portion
41/4 (0.25)3/4 (0.75)
81/8 (0.125)7/8 (0.875)
161/16 (0.0625)15/16 (0.9375)
321/32 (0.03125)31/32 (0.96875)
641/64 (0.015625)63/64 (0.984375)
1281/128 (0.0078125)127/128 (0.9921875)
2561/256 (0.00390625)255/256 (0.99609375)
5121/512 (0.001953125)511/512 (0.998046875)
10241/1024 (0.0009765625)1023/2024
(0.9990234375)
20481/2048
(0.00048828125)
2047/2048
(0.99951171875)
12
13
14
15
12
2
13
2
14
2
15
2
40961/4096
(0.000244140625)
81921/8192
(0.0001220703125)
163841/16384
(0.00006103515625)
327681/32768
(0.000030517578125)
4095/4096
(0.999755859375)
8191/8192
(0.9998779296875)
16383/16384
(0.99993896484375)
32767/32768
(0.999969482421875)
The value specified for the TAF affects the speed at which the shared buffer average
utilization tracks the instantaneous shared buffer utilization. A low value weights the new
shared buffer average utilization calculation more to the shared buffer instantaneous
utilization. When TAF is zero, the shared buffer average utilization is equal to the
instantaneous shared buffer utilization. A high value weights the new shared buffer average
utilization calculation more to the previous shared buffer average utilization value. The TAF
value applies to all high and low priority RED slopes for ingress and egress buffer pools
controlled by the buffer policy.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide89
Page 90
QoS Overview
Slope Policy Parameters
The elements required to define a slope policy are:
•A unique policy ID.
•On 7210 SAS-M, choose whether the three slopes per queue must be used or two
slopes must be used.
•On 7210 SAS-T, 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, only two
slopes per queue is available.
•The high and low RED slope shapes for the buffer pool: settings for the high-priority
and low-priority RED slopes.
•The RED slope shapes for the buffer-pool, that is, settings for the RED slopes:
→ If 3 slopes are used, then user needs to configure high-priority TCP slope, low -
priority TCP slope and non-TCP slope parameters.
→ If two slopes are used, then user needs to configure high-priority slope and low
-priority slope parameters.
All slopes are available per queue and the following parameters are configurable for each
slope:
•start-avg
•max-avg
•max-prob
•Time average factor (TAF)
A slope policy is defined with generic parameters so that it is not inherently an access or a
network policy. A slope policy defines access egress buffer management properties, when it
is associated with an access port buffer pool and network egress buffer management
properties, when it is associated with a network port buffer pool.
Slope policy ID default is reserved for the default slope policy. The default policy cannot be
deleted or changed. The default slope policy is implicitly applied to all access and network
buffer pools which do not have another slope policy explicitly assigned.
Table 34 lists the default values for the default slope policy.
Queue management policies allows the user to define the queue buffer and WRED slope
parameters. The device supports a single buffer pool per node. All the queues created in the
system are allocated buffers from this system pool. The default buffers are allocated to the
queues accordingly when they are associated with a SAP or a network port. Queue
management policies allow the user to define the CBS, MBS and WRED parameters for use
by the queue. The CBS and MBS parameters are used to allocate the appropriate amount of
buffers from the system pool to the queues. The WRED parameters allow the user to define
the WRED slope characteristics. User can define a high-slope and a low-slope for each of the
queues. High-slope is used for in-profile packets being enqueued into the queues and lowpriority slope is used for out-of-profile packets being enqueued into the queues. By default
each queue is associated with a default queue-management policy. The default policy
allocates the appropriate amount of CBS and MBS buffers based on whether the queue is
associated with a SAP or network port.
Note: If WRED is not configured, then taildrop is used.
Queue Management Policy Parameters
The elements required to define a queue management policy are:
•A unique policy ID.
•The RED slope shapes for the buffer-pool, that is, start-average, max-average, maxdrop-probability settings for the high-priority and low priority RED slope
•The TAF factor for the queue
Queue management policy ID default is reserved for the default queue management policy.
The default policy cannot be deleted or changed. The default policy is implicitly applied to
all queues which do not have another queue management policy explicitly assigned.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide93
Page 94
QoS Overview
Table 35: Default values for the default slope policy for 7210 SAS-Mxp
Port Scheduler Policies for 7210 SAS-M, 7210 SAST, 7210 SAS-Sx/S 1/10GE, and 7210 SAS- Sx 10/
100GE
Port scheduler policies control the traffic behavior on a per-port basis. Associated with each
egress port is a set of eight class of service (CoS) queues and a default port-scheduler-policy
named “default”. This default policy makes the port to behave in strict mode. The default
policy cannot be modified. The user can attach another policy to the port to change its
scheduling behavior. The scheduler that provides the arbitration across the eight CoS queues
is a scheduler that is configured in a variety of modes. A major aspect of the arbitration
mechanism is the ability to provide minimum and maximum bandwidth guarantees. This is
accomplished by tightly integrating a network queue and access egress policies into the
scheduler. After the packets are mapped into a COS queue, they are forwarded/conditioned
using one of these schedulers (such as Strict Priority (SP), Round-Robin (RR), Weighted
Round-Robin (WRR), Weighted Deficit Round-Robin (WDRR), (WRR+SP, WDRR+SP).
The traffic shaping aspect is tightly integrated with the scheduler.
947210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 95
Scheduler Modes
Note: For 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, please refer to the Chapter
onSchedulers on 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE.
The scheduling modes interact with the minimum and maximum bandwidth CoS queue and
maximum bandwidth egress port shaping specifications. Each egress port may be configured
to have a specific scheduling mode. The scheduler first services the queues to meet their CIR
and then services the queues to meet the PIR. There are five possibilities as follows:
•Strict priority scheduling across CoS queues — The strict priority scheduler provides
strict priority access to the egress port across the CoS queue from highest CoS queue
index (7) to the lowest (0). The purpose of the strict priority scheduler is to provide
lower latency service to the higher CoS classes of traffic. In this mode, the scheduler
services the queues in order of their prority in both the CIR and PIR loop.
QoS Policies
Table 36: Minimum and Maximum Bandwidth Meters Example
QoS Queue NameMinimum BandwidthMaximum Bandwidth
710 Mbps1 Gbps
610 Mbps1 Gbps
550 Mbps1 Gbps
450 Mbps1 Gbps
350 Mbps1 Gbps
250 Mbps1 Gbps
150 Mbps1 Gbps
050 Mbps1 Gbps
Displayed in Table 36, CoS queues 7 and 6 each have a minimum bandwidth
specification of 10 Mbps, whereas the remaining QoS queues have a minimum
bandwidth specification of 50 Mbps. All CoS queues have a maximum bandwidth
specification of 1 Gbps. The goal of these settings is to guarantee the minimum
bandwidth settings for each of the queues while also allowing each CoS queue to
fully use the egress port capability by having the maximum bandwidth setting at 1
Gbps. The strict priority scheduler mode provides low latency service for CoS queues
6 and 7 while their minimum bandwidth guarantees are being satisfied.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide95
Page 96
QoS Overview
•Round robin scheduling across CoS queues — The round robin scheduler mode
provides round robin arbitration across the CoS queues. The scheduler visits each
backlogged CoS queue, servicing a single packet at each queue before moving on to
the next one. The purpose of the round robin scheduler is to provide fair access to the
egress port bandwidth (at a packet level). This works best when packet sizes are
approximately comparable. In this mode, the scheduler services the queues in roundrobin for both the CIR and the PIR loop.
•Weighted round robin (WRR) — In WRR mode, the scheduler provides access to
each CoS queue in round robin order.When the scheduler is providing access to a
particular queue, it services a configurable number of back-to-back packets before
moving on to the subsequent CoS queue. A value of strict is used to designate that a
particular queue be considered to be a part of a hybrid Strict + WRR configuration.
The values 1 to 15 are used to indicate the number of back-to-back packets to be
serviced when the scheduler is servicing a particular CoS queue. If the weight
specified is N, but if the number of packets in the queue is lesser than N, the scheduler
continues working and moves on to the next backlogged queue. In this mode, with
no strict queues configured, the scheduler services the queues in round robin in the
CIR loop. The configured weights are not considered in the CIR loop. The weights
are used only in the PIR loop.
•Weighted deficit round robin (WDRR) scheduling— An inherent limitation of the
WRR mode is that bandwidth is allocated in terms of packets. WRR works well if the
average packet size for each CoS queue flow is known.WDRR aims at addressing
this issue. WDRR provides a bandwidth allocation scheduler mode that takes into
account the variably-sized packet issue by maintaining sufficient state information
when arbitrating across the CoS queues. In this mode, with no strict queues
configured, the scheduler services the queues in round-robin in the CIR loop. The
configured weights are not considered in the CIR loop. The weights are used only in
the PIR loop. A weight value of 1 to 15 can be configured for each queue. Based on
the weights provided respective amount of bytes is de-queued from the queue. A
value of 0 is used to designate that a particular queue be considered to be a part of a
hybrid Strict + WDRR configuration. If a weight value of 1 is given for queue 1 and
5 is given for queue 2, then we will see traffic out of the port in the ratio of 1:5
between the queues (1 and 2), provided no traffic is flowing in the other queues. A
weight value of 1 will actually pump out 2Kbytes from that queue, a value of 5 will
pump out 10 Kbytes. Twice of the weight value given will be pumped out.
•Strict + WRR/WDRR — If the WRR/WDRR weight associated with a particular
CoS queue is set to strict, the queue is considered to be in a strict priority mode. This
set of strict priority queues is serviced first in the order of their CoS numbering
(higher numbered CoS queue receives service before smaller numbered queues). In
this mode, the scheduler services the strict queues first and then the queues
configured with weights in both the CIR and PIR loop. The scheduler ensures that it
meets the CIR of all the queues (both strict queues and queues with weight), if
967210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 97
bandwidth is available before scheduling the queues in the PIR loop. If multiple
queues are configured as strict, the higher-priority strict queues are serviced first
before the lower priority strict queues in both the CIR and the PIR loop. The weights
configured for the queues are only considered during the PIR loop.
Schedulers on 7210 SAS-Mxp
7210 SAS-Mxp supports scheduling as follows:
•When SAP-based scheduling mode is enabled, the following support is available:
→ per SAP egress scheduler for access port and hybrid port.
→ per port egress scheduler for network and hybrid port.
•When port-based scheduling mode is enabled, the following support is available:
→ per port egress scheduler for access port.
→ per port egress scheduler for network and hybrid port.
QoS Policies
For more information on scheduling behavior and to understand the queue parameters
considered by the scheduler, see Schedulers on 7210 SAS-Mxp.
CPU Queues
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 CPU provides eight queues from
BE (0) to NC (7). The packets destined to the CPU are classified internally and are put into
the correct 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.
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide97
Page 98
QoS Overview
Remark Policy on 7210 SAS-T, 7210 SAS-Sx/S 1/
10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-Mxp
(Network mode)
This policy allows the user to define the forwarding class to egress marking values. Based on
the packet encapsulation used to send out the service packets, the remark policy allows the
user to define and associate appropriate policies to service egress and network egress QoS
policies.
The 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE network Mode
supports the following types of remark policies:
•dot1p - Used for service egress, access port egress, and network qos (type port).
•dscp - Used for access port egress and network qos [port type] policies.
•lsp-exp - Used for network qos [ip-interface type] policies.
•dot1p-dscp - Used for access port egress and network qos [port type] policies.
•dot1p-lsp-exp-shared - Used for Access port egress, and network qos [ip-interface
type] policies.
Each of these remark policy type can be associated with only appropriate Qos policies as
listed above.
The required elements to define a remark QoS policy are:
•A unique remark QoS policy ID.
•Forwarding class to appropriate marking values
For more details refer to the Remarking Policies chapter below Remark Policies on page 461.
Egress Port Rate Limiting
The 7210 SAS supports port egress 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. It also allows the user to control the amount of burst sent out.
987210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Page 99
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 37).
QoS Policies
Table 37: 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
7210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide99
Page 100
QoS Overview
Note that Table 37 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 a Network QoS Policies in Network Mode. All forwarding class queues support the
concept of in-profile and out-of-profile.
1007210 SAS-M, T, Mxp, Sx, S OS Quality of Service Guide
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.