2. QoS Policies

This chapter provides information about Quality of Service (QoS) policy management.

2.1. QoS Policies 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:

Not all QoS capabilities are supported on all 7210 SAS platforms. Please read through the following chapters to know what is available on different 7210 SAS platforms.

In the Nokia service router service model, a service is provisioned on the provider-edge (PE) equipment. Service data is encapsulated and then sent in a service tunnel (for example: QinQ tunnel, dot1q tunnel, IP/MPLS tunnel, and so on) to the far-end Nokia service router where the service data is delivered.

The operational theory of a service tunnel is that the encapsulation of the data between the two Nokia service routers appear like a Layer 2 path to the service data although it is really traversing an QinQ or IP or IP/MPLS core. The tunnel from one edge device to the other edge device is provisioned with an encapsulation and the services are mapped to the tunnel that most appropriately supports the service needs. 7210 SAS-D and 7210 SAS-Dxp support QinQ uplinks or Dot1q uplinks or NULL port for transport of services.

The 7210 SAS supports eight forwarding classes internally named: Network-Control, High-1, 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:

Policies are used for classification, defining metering and queuing attributes and defining marking behavior.
Slope policies define default buffer allocations and WRED slope definitions.
Port Scheduler policies, SAP ingress/egress policies and network/network-queue policies determine how queues are scheduled.

QoS policies are applied on service ingress, access ports egress and access uplink ports (ingress and egress) and define the following:

Classification rules for how traffic is mapped to forwarding classes
Forwarding class association with 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)
Port scheduler (for access port and access-uplink port egress)
Slope Policies (for congestion management using RED)

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 on SAP 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 used for unicast traffic and the meter attributes (like CIR, PIR, etc.). Each of the forwarding classes can be associated with different meter 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 is typically sent to multiple destinations within the service while the unicast forwarding type is handled in a point-to-point fashion within the service.

An access egress policy is analogous to a SAP egress policy as defined in the 7750 SR, 7450 ESS, 7710 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 and applies to the traffic sent out of all the SAPs configured on the 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 with an option to configure the queue parameters (For example: rate values). There are 8 egress queues at the port level. FC-to-queue mapping is static and is not configurable. The number of queues are static and there are always 8 egress queues at the port level. An access egress policy also defines how to remark the forwarding class to priority bits (For example: IEEE 802.1p bits) in the customer traffic.

Network QoS policies are applied to access uplink ports.On ingress, the policy can be used to 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 priority bits (for example: IEEE 802.1p bits) values for traffic to be transmitted into the core network.

Network queue policies are applied on egress of access uplink ports. The policies define the forwarding class queue characteristics.

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, with a single access egress QoS policy allowed to be associated with access port. One network QoS policy can be applied to a specific access-uplink port. A network QoS policy defines both ingress and egress behavior. One network queue policy can be applied to the access uplink port.

If no QoS policy is explicitly applied to a SAP or port by the user, a default QoS policy is always applied.

2.1.1. Summary of Major Functions of QoS Policies

A summary of the major functions performed by the QoS policies is listed in Table 5.

Table 5: QoS Policy Types and Descriptions for 7210 SAS-D and 7210 SAS-Dxp

Policy Type	Applied at…	Description
Service Ingress	Access SAP ingress	Defines up to 32 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 IP or MAC or both IP and MAC
Access Egress	Access port	Defines up to 8 forwarding class queues and queue parameters for traffic classification Maps forwarding classes to the queues Defines Queue parameters for the queues Defines FC to remarking values Defines CIR levels and PIR weights that determines how the queue gets prioritized by the scheduler
Egress Rate	Access port and Access-uplink port	Configures the maximum bandwidth available for traffic sent out of a specified port
Accounting Mode	Device Level	Sets the accounting mode to packet-based or frame-based for ingress and egress QoS policies
Network	Access uplink ports	At ingress, defines Dot1p to FC mapping and meters At egress, defines FC to remarking values (For example: IEEE 802.1p)
Network Queue	Access uplink ports	Defines forwarding class mappings to network queues and queue characteristics for the queues.
Slope	Port Queues	On 7210 SAS-D, enables or disables the high-slope, low-slope, and non-TCP parameters within the egress pool On 7210 SAS-Dxp, enables or disables high-slope and low-slope parameters for TCP traffic
Port scheduler	Access Port and Access-uplink Port	Defines the parameters for the port scheduler

2.1.2. Service and Network QoS Policy Mechanisms

The QoS mechanisms within the 7210 SAS-D and 7210 SAS-Dxp are specialized for the type of traffic on the interface.

Figure 1 shows that on 7210 SAS-D and 7210 SAS-Dxp, for customer interfaces, there is service ingress and access port egress traffic, and for access uplink port interfaces, there is network ingress and network egress traffic.

Figure 1: 7210 SAS-D and 7210 SAS-Dxp Service and Network Traffic Types and QoS model

The 7210 SAS uses QoS policies applied to a SAP for a service or to an access uplink port or to an access port to define the queuing, queue attributes, meter attributes, and QoS marking/interpretation.

2.2. Network and Service QoS Policies

The 7210 SAS supports the following major types of service and network QoS policies:

Service ingress QoS policies
Access egress QoS policies
Network QoS policies
Network Queue QoS policies

The support of different policies varies across different platforms.

2.2.1. Network QoS Policies on Access-uplink Ports

Network QoS policies define egress QoS marking and ingress QoS interpretation for traffic on received on access-uplink ports. The router automatically creates egress queues for each of the forwarding classes on access-uplink port.

A network QoS policy defines both the ingress and egress handling of QoS on the access-uplink ports. The following functions are defined:

Ingress
1. Defines Dot1p value mapping to forwarding classes and profile
2. Defines forwarding class to meter mapping
Egress
1. Defines the forwarding class and profile state to Dot1p value markings
2. Option to define the forwarding class and profile state to IP DSCP value marking
3. Remarking of QoS bits can be enabled or disabled

The required elements to be defined in a network QoS policy are:

A unique network QoS policy ID.
Egress - forwarding class and profile state to priority bits (for example: 802.1p, etc.) used for marking, for each forwarding class.
A default ingress forwarding class and an optional in-profile/out-of-profile state.
At least one default unicast forwarding class meter. The parameters that can be configured for a meter are discussed below.
Optional multipoint forwarding class meter.

Optional network QoS policy elements include:

Additional unicast meters or queues
Additional multipoint meters or queues
Dot1p value to forwarding class and profile state mappings for all values received
Option to use DEI bit along with Dot1p classification for profile state mapping
Option to define the forwarding class and profile state to IP DSCP value marking

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 (that is, on an access uplink port egress) determines how or whether the profile state is marked in packets transmitted into the service core network. If the profile state is marked in the service packets, out-of-profile packets are preferentially dropped over in-profile packets at congestion points in the network. For network egress, traffic remarking in the network QoS policy can be enabled or disabled for 7210 SAS-D and 7210 SAS-Dxp.

2.2.2. Default Network QoS Policy (Egress) for the 7210 SAS-D

Table 6 lists the default mapping of forwarding class to Dot1p values for egress marking on the 7210 SAS-D.

Table 6: Default Network QoS Policy Egress Marking on 7210 SAS-D

FC-ID	FC Name	FC Label	DiffServ Name	Egress Dot1p Marking		Egress DSCP Marking
FC-ID	FC Name	FC Label	DiffServ Name	In-Profile	Out-of-Profile	In-Profile	Out-of-Profile
7	Network Control	nc	NC2	111 - 7	111 - 7	nc2	nc2
6	High-1	h1	NC1	110 - 6	110 - 6	nc1	nc1
5	Expedited	ef	EF	101 - 5	101 - 5	ef	ef
4	High-2	h2	AF4	100 - 4	100 - 4	af41	af41
3	Low-1	l1	AF2	011 - 3	011 - 3	af21	af22
2	Assured	af	AF1	011-3	011-3	af11	af12
1	Low-2	l2	CS1	001 - 1	001 - 1	cs1	cs1
0	Best Effort	be	BE	000 - 0	000 - 0	be	be

2.2.3. Default Network QoS Policy (Egress) for the 7210 SAS-Dxp

Table 6 lists the default mapping of forwarding class to Dot1p values for egress marking on the 7210 SAS-Dxp.

Table 7: Default Network QoS Policy Egress Marking on 7210 SAS-Dxp

FC-ID	FC Name	FC Label	DiffServ Name	Egress Dot1p Marking		Egress DSCP Marking
FC-ID	FC Name	FC Label	DiffServ Name	In-Profile	Out-of-Profile	In-Profile	Out-of-Profile
7	Network Control	nc	NC2	111 - 7	111 - 7	nc2	nc2
6	High-1	h1	NC1	110 - 6	110 - 6	nc1	nc1
5	Expedited	ef	EF	101 - 5	101 - 5	ef	ef
4	High-2	h2	AF4	100 - 4	100 - 4	af41	af41
3	Low-1	l1	AF2	011 - 3	011 - 3	af21	af22
2	Assured	af	AF1	011-3	011-3	af11	af12
1	Low-2	l2	CS1	001 - 1	001 - 1	cs1	cs1
0	Best Effort	be	BE	000 - 0	000 - 0	be	be

2.2.4. Default Network QoS Policy (Ingress)

For network ingress, Table 8 lists the default mapping of Dot1p values to forwarding class and profile state for the default network QoS policy.

Table 8: Default Network QoS policy Ingress Classification

Dot1p Value	7210 FC Ingress	Profile
0	be	Out
1	l2	In
2	af	Out
3	af	In
4	h2	In
5	ef	In
6	h1	In
7	nc	In

2.2.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.

On 7210 SAS-D and 7210 SAS-Dxp, the system allocates 8 egress queues (not user-configurable) for the network port, and FCs are mapped to these 8 egress queues. All policies use 8 egress queues like the default network queue policy. Table 9 describes the 8 egress queues for 7210 SAS-D.

Table 9: Default Network Queue Policy Definition (7210 SAS-D)

Forwarding Class	Queue	Definition
Network-Control (nc)	Queue 8	PIR = 100% CIR = 10%
High-1 (h1)	Queue 7	PIR = 100% CIR = 10%
Expedited (ef)	Queue 6	PIR = 100% CIR = 100%
High-2	Queue 5	PIR = 100% CIR = 100%
Low-1	Queue 4	PIR = 100% CIR = 25%
Assured	Queue 3	PIR = 100% CIR = 25%
Low-2	Queue 2	PIR = 100% CIR = 25%
Best Effort	Queue 1	PIR = 100% CIR = 0%

Table 10 describes the 8 egress queues for 7210 SAS-Dxp.

Table 10: Default Network Queue Policy Definition (7210 SAS-Dxp)

Forwarding Class	Queue	Definition
Network-Control (nc)	Queue 8	PIR = 100% CIR = 10%
High-1 (h1)	Queue 7	PIR = 100% CIR = 5%
Expedited (ef)	Queue 6	PIR = 100% CIR = 15%
High-2	Queue 5	PIR = 100% CIR = 15%
Low-1	Queue 4	PIR = 100% CIR = 10%
Assured	Queue 3	PIR = 100% CIR = 10%
Low-2	Queue 2	PIR = 100% CIR = 10%
Best Effort	Queue 1	PIR = 100% CIR = 0%

2.2.6. Service Ingress QoS Policies

Service ingress QoS policies define ingress service forwarding class queues or meters and map traffic flows to forwarding class on access SAP ingress.

Note:

Not all 7210 platforms support queues and meters on service ingress. The support varies across different platforms. Please read the subsequent chapters/sections for more information.

2.2.6.1. Service Ingress QoS Policies

Service ingress QoS policies define ingress service forwarding class meters and map traffic flows to forwarding class.

When a service ingress QoS policy is created, it typically has some meters defined that cannot be deleted. These meters is used by default for all traffic both unicast and multicast. 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 a case where the service does not have multipoint traffic, for example Epipe service, 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.

Prerequisite for configuring service ingress QoS policy:

Allocates resources from the ingress internal CAM resource pool for use for service ingress QoS classification using the commands available under the CLI context configure>system>resource-profile. Additionally, resources need to be allocated for the appropriate classification match criteria.

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.
The number of classification and meter resources to allocate for this policy.
At least one default forwarding class meter. The parameters that can be configured for a meter are discussed in Metering/Policing and Meter Parameters.

Optional service ingress QoS policy elements include:

Additional unicast meters up to a total of 31.
Additional multipoint meters up to 31.
QoS policy match criteria to map packets to a forwarding class.

Each meter can have unique meter parameters to allow individual policing of the flow mapped to the forwarding class. Figure 2 shows service traffic being classified into three different forwarding classes.

Figure 2: Traffic Policing and Queuing Model for Forwarding Classes

2.2.6.2. Default Service Ingress Policy

Service ingress QoS policy ID 1 is reserved for the default service ingress policy. The default policy cannot be deleted or changed. The default service ingress policy is implicitly applied to all SAPs which do not explicitly have another service ingress policy assigned. In the default policy, all traffic is mapped to the default forwarding class which uses a meter by default. The characteristics of the default policy are listed in Table 11.

Table 11: Default Service Ingress Policy ID 1 Definition

Item	Definition
Meter 1	1 (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) CBS = 32kbits MBS = 128kbits
Default Forwarding Class (be)	1 (one) flow defined for all traffic: All traffic mapped to best-effort (be)

2.2.7. Service Ingress Classification

Mapping flows to forwarding classes is controlled by comparing each packet to the match criteria in the Service Ingress QoS policy applied to an access SAP. The ingress packet classification to forwarding class is subject to a classification policy provisioned.

2.2.7.1. Service Ingress Classification

On SAP ingress, the 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 effectively, the following options are available:

Supported MAC header fields using the mac-criteria any option.
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 (this option is supported only on 7210 SAS-D and 7210 SAS-Dxp).

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 dscp-only (this option is supported only on 7210 SAS-D and 7210 SAS-Dxp).
mac-criteria dot1p-only and ip-criteria any or ip-criteria dscp-only and/or ipv6-criteria dscp-only (this option is supported only on 7210 SAS-D and 7210 SAS-Dxp).
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.

The available ingress CAM hardware resources from the ingress internal CAM pool can be allocated as per user needs for use with different QoS classification match criteria using the commands available under the CLI context configure> system> resource-profile>. By default, the system allocates resources to SAP ingress classification on bootup. 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 Policy Classification Rules to know more about resource usage and allocation to SAP ingress policies.

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.

2.2.7.2. Hierarchical Ingress Policing on 7210 SAS-D and 7210 SAS-Dxp

Hierarchical ingress policing (also knows as, SAP ingress aggregate meter/policer) 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/meter 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

Refer to the description of the aggregate-meter-rate command in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Services Guide for more information about the final color assigned of the packet.

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 previously existing meter mode “trtcm” is re-named as “trtcm1” (RFC 2698). The meter modes “srtCM” and “trtcm1” can be 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. These resources are shared with Ingress ACLs. 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. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information.

2.3. Access Egress QoS Policies

An access egress policy defines the queue and marking characteristics for the traffic egressing towards the customer on the access ports. There are 8 queues always available at the access port and FCs is mapped to these 8 Queues. By configuring appropriate queue shaper rates the individual FC traffic can be managed so that each FC’s traffic is well within SLA limits and does not impact traffic of other FCs. The access egress policy also provides an option for marking of packets sent out of access ports, allowing the forwarding class to be mapped to packet header priority bits (e.g. IEEE Dot1p bits).

The forwarding classes is mapped to 8 queues by software as per Table 15. It is not user configurable. The Queue ID determines the priority of the queue, with higher queue-id denoting higher priority.

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 Queues and Queue Parameters.
IEEE 802.1p priority value remarking based on forwarding class.
On 7210 SAS-D and 7210 SAS-Dxp, an option to use IP DSCP values for marking based on forwarding class is available.

The forwarding class determination per service egress packet is determined at ingress. If the packet ingressed the service on the same router, the service ingress classification rules determine the forwarding class of the packet. If the packet was received over a service transport tunnel on a access-uplink port, the forwarding class is marked in the outer tag of the QinQ encapsulation.

2.3.1. Default Access Egress Policy

Access egress QoS policy ID 1 is reserved as the default policy associated with access ports which do not have another access egress policy explicitly assigned. The characteristics of the default policy are listed in Table 12.

Table 12: Default Access Egress Policy ID 1 Definition

Forwarding Class	Queue-ID	Queue Parameters
Queues	Queue 1-8	1 (one) queue defined for each traffic class
Network-Control (nc)	Queue 8	CIR=0 PIR= max (line rate)
High-1 (h1)	Queue7	CIR=0 PIR= max (line rate)
Expedited (ef)	Queue 6	CIR = 0 PIR = max (line rate)
High-2 (h2)	Queue 5	CIR = 0 PIR = max (line rate)
Low-1 (l1)	Queue 4	CIR = 0 PIR = max (line rate)
Assured (af)	Queue 3	CIR = 0 PIR = max (line rate)
Low-2 (l2)	Queue 2	CIR = 0 PIR = max (line rate)
Best-Effort (be)	Queue 1	CIR = 0 PIR = max (line rate)

2.4. Meters/Policers

This section provides information about meters/policers.

2.4.1. Metering/Policing and Meter Parameters

This section describes the meter behavior and meter parameters that can be defined for meters provisioned on the service entities (For example: access SAP ingress on 7210 SAS-D).

Note:

Not all 7210 platforms support meters for all the policies. In addition, the meter parameters supported varies across platforms. See platform specific QoS overview sections above. In the sections below, the differences are called out explicitly to know the support available on different platforms.

2.4.1.1. Meter ID

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. It allows user to define multiple meters in a policy and associate them with one of the 8 forwarding classes.

2.4.1.2. Committed Information Rate (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 amount of burst is determined by the CBS and MBS values configured for the meter.

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.

2.4.1.3. Peak Information Rate (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.

2.4.1.4. 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 supported constraints are:

Minimum
Find the next multiple of the hardware step size that is equal to or higher than the specified rate.
Maximum
Find the next multiple of the hardware step size that is equal to or less than the specified rate.
Closest
Find the next multiple of hardware step size that is closest to the specified rate.

2.4.1.4.1. Adaptation Rule for Meters on 7210 SAS-D Devices

Hardware supports meter rates in the multiples of 8 kb/s for the entire range of CIR or PIR rates supported on the device. The system identifies the best operational rate depending on the defined constraint. The supported constraints are listed below:

Minimum
The system identifies the next multiple of 8 kb/s that is equal to or higher than the specified rate.
Maximum
The system identifies the next multiple of 8 kb/s that is equal to or less than the specified rate.
Closest
The system identifies the next multiple of 8 kb/s that is closest to the specified rate.

2.4.1.4.2. Adaptation Rule for Meters on 7210 SAS-Dxp Devices

Hardware supports meter rates in the multiples of 8 kb/s for CIR or PIR rates on 1G ports supported on the device. The system identifies the best operational rate depending on the defined constraint. The supported constraints for 1G ports are listed below:

Minimum
The system identifies the next multiple of 8 kb/s that is equal to or higher than the specified rate.
Maximum
The system identifies the next multiple of 8 kb/s that is equal to or less than the specified rate.
Closest
The system identifies the next multiple of 8 kb/s that is closest to the specified rate.

Table 13 lists information for calculating hardware-supported meter step-size for all supported ranges of rate values and burst step-sizes for all supported ranges of burst values for 10G ports.

Table 13: Supported Hardware Rates and Burst Step Sizes for CIR and PIR Values for 7210 SAS-Dxp

Rate (kbits_sec)	Burst (kbits_burst)	Rate Step Size (bits)	Burst Step Size (bits)
0 to 4194296	0 to 16773	8000	4096
4194297 to 8388592	16774 to 33546	16000	8192
8388593 to 16777184	33547 to 67092	32000	16384
16777185 to 33554368	67093 to 134184	64000	32768
33554369 to 67108736	134185 to 268369	128000	65536
67108737 to 134217472	268370 to 536739	256000	131072
134217473 to 268434944	536739 to 1073479	512000	262144
268434945 to 536869888	1073480 to 16384	1024000	524288

Note:

The burst size configured by the user affects the rate step-size used by the system. The system uses the step size so that both the burst-size and rate parameter constraints are met. For example, if the rate specified is less than 4 Gbps but the configured burst size is 17 Mbits, then the system uses a rate step size of 16 Kbits and a burst step size of 8192 bits (see Table 13, row 2).

If the meter is a srTCM meter, then both rate and burst constraints specified for both CBS and MBS are considered together to determine the step-size to use for CIR, CBS, and MBS parameters.

If the meter is a trTCM1 meter, then the CIR rate and CBS burst parameters are considered together to determine the step-size to use for CIR and CBS parameters, and the PIR rate and MBS burst parameters are considered together to determine the step-size to use for PIR and MBS parameters.

If the meter is a trTCM2 meter, then the CIR rate and CBS burst parameters are considered together to determine the step-size to use for CIR and CBS parameters, and the PIR (EIR) rate and MBS (EBS) burst parameters are considered together to determine the step-size to use for PIR (EIR) and MBS (EBS) parameters.

2.4.1.5. Committed Burst Size (For Meters/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.

Note:

See Table 13 for information about the burst parameter step-size for 7210 SAS-Dxp.

2.4.1.6. Maximum Burst Size (For Meters/Policers)

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 is 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.

Note:

See Table 13 for information about the burst parameter step-size for 7210 SAS-Dxp.

2.4.1.6.1. Excess Burst Size (For Meters/Policers)

The excess burst size (EBS) parameter specifies the excess burst size transmitted by the source while not complying with the CIR. If the transmitted burst is lower than the EBS value, then the packets is marked as out-profile by the meter to indicate that the traffic is not complying with CIR. If the packet burst is higher than EBS then packets are marked as red are dropped.

Note:

EBS parameter is used only when the meter mode is set to trtcm2 as specified below.
See Table 13 for information about the burst parameter step-size for 7210 SAS-Dxp.

2.4.2. Meter Counters

The 7210 SAS devices maintains the following counters for meters within the system for granular billing and accounting.

Counters for packets and or octets marked as in-profile by meter
Counters for packets and or octets marked as out-of-profile by meter
Counters for packets and or octets marked as dropped by meter

The counters available vary among the 7210 SAS platform. Not all the counters are supported on all the platforms. Additionally, there are restrictions on the number of counters that can be used simultaneously with a single meter. Some platforms can only count octets or packets and other can count both packets and octets. Typically, each meter can maintain a subset of the counters. The user is provided the option to select the subset of counter they want to use. See “Accounting Records” in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C System Management Guide for information about counter (and corresponding accounting record) support available on each of the platforms.

2.4.3. Meter Modes

The meter mode command allows the user to select from among three possible

meter types:

srTCM – Single rate Three Color meter, with this meter a single rate can be specified by the user to limit the amount of traffic. The single rate along with the CBS/MBS determines the amount of both in-profile / committed traffic and out-of-profile / excess burst. With this meter, the meter’s CBS and MBS token buckets are replenished at single rate, that is, CIR.
trTCM – Two rate Three Color meter, with this meter user can specify two rates, CIR and PIR can be specified by the user to limit the amount of traffic. It allows the user to limit the amount of in-profile/ committed traffic to CIR rate and allow user to send excess out-of-profile traffic up to a peak rate of PIR. With this meter, the meters CBS token buckets are replenished at CIR rate and MBS/EBS token buckets are replenished at PIR/EIR rate There are two modes supported under this:
1. trtcm1 – Implements policing as per RFC 2698.
2. trtcm2 – Implements policing as per RFC 4115.
3. srtcm – Implements policing as per RFC 2697.

The 7210 SAS-D and 7210 SAS-Dxp devices support the following meter modes:

srtcm: Single Rate Three Color Marking (as per RFC 2697)
trtcm1:Two Rate Three Color Marking (as per RFC 2698)
trtcm2: Two rate three color marking (as per RFC 4115).

The meter mode supported for different QoS policies are different. In other words, not all the meter modes are supported for all the QoS policies.

2.4.3.1. Color-aware and Color-blind Policing/Metering

In color-aware policing user can define the color/profile state (color and profile state is used interchangeably in this section to mean the same) of the packet using the ingress classification rules. The color (also called the profile state) assigned to the packet at ingress is used by the meter along with the rate configured to determine the final profile state of the packet.

The color-aware meter determines the final color/profile state of the packet as follows:

If the packet is precolored as in-profile (or also called as Green colored packets) then depending on the burst size of the packet, the meter can either mark it in-profile or out-profile. If the packet is within the CBS limit, it is assigned a profile value of ‘in-profile’ (or color value of green). If the packet exceeds the CBS limit, then it is reassigned a profile value of ‘out-profile’ (or color value of yellow).
If the packet is precolored 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. Instead it is checked against the MBS/EBS limit directly and is assigned a profile value of out-profile (or color value of yellow) if it is within the MBS/EBS limit.
If the packet burst is higher than the MBS/EBS then it would be marked as Red and would be dropped by meter at ingress.

In color-blind policing, the profile/color assigned to the packet on ingress is ignored and all packets are treated as out-of-profile packets. 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.

The final profile state/color marked by the meter on ingress 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).

The 7210 SAS device supports color-aware policing at the network ingress by default. At service ingress, user is provided an option to use either color-aware policing or color-blind policing.

The following support is available on 7210 SAS-D and 7210 SAS-Dxp:

With access-uplink ports, ingress classification, the profile state/color can be assigned based on either Dot1p bits and or DEI.
Color-aware policing at access-uplink ports ingress is supported by default. In other words, the option to use color-blind meter is not available on access-uplink port ingress.
With access SAP ingress, user is provided an option to use either color-aware policing or color-blind policing.

2.4.4. QoS Overrides for Meter/Policers

The QoS Override feature support 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. It is only supported for access SAPs. The values are taken from the SAP-Ingress policy, when the meter parameter values are not overridden.

Meter Override commands are supported on the 7210 SAS-D and 7210 SAS-Dxp platforms.

2.4.4.1. 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 policy is attached to the SAP.
QoS override commands are not supported for ingress and egress QoS policies used with access-uplink SAPs and ports.

2.4.4.2. Configuring Meter Override Parameters

The following is a sample meter override parameter configuration output.

*7210SAS>config>service>epipe>sap>ingress# info

----------------------------------------------

qos 13

meter-override

meter 1 create

mode trtcm2

adaptation-rule pir max cir max

cbs 300

mbs 200

rate cir 300 pir 400

exit

----------------------------------------------

*A:7210SAS>config>service>epipe>sap>ingress#

2.5. 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-of-profile 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. Table 14 describes the 7210 SAS devices that support the eight (8) forwarding classes.

Table 14: Forwarding Classes

FC-ID	FC Name	FC Designation	DiffServ Name	Notes
7	Network Control	NC	NC2	Intended for network control traffic.
6	High-1	H1	NC1	Intended for a second network control class or delay/jitter sensitive traffic.
5	Expedited	EF	EF	Intended for delay/jitter sensitive traffic.
4	High-2	H2	AF4	Intended for delay/jitter sensitive traffic.
3	Low-1	L1	AF2	Intended for assured traffic. Also is the default priority for network management traffic.
2	Assured	AF	AF1	Intended for assured traffic.
1	Low-2	L2	CS1	Intended for BE traffic.
0	Best Effort	BE	BE	Intended for BE traffic.

Note:

Table 14 presents the default definitions for the forwarding classes. The forwarding class behavior, in terms of ingress marking interpretation and egress marking, can be changed by QoS Policies.

2.5.1. Forwarding-Class To Queue ID Mapping

There are 8 forwarding classes supported on 7210 SAS devices. Each of these FC is mapped to a specific queue. By mapping FC to different queues the differential treatment is imparted to various classes of traffic.

2.5.2. FC to Queue ID Mapping

On these platforms there are only 8 queues available at the port level. These 8 queues are created by default per port. Users cannot create or delete the queues or the queue ID. Only the queue parameters can be changed. The queue-id is not a configurable entity and queue ID 1 to 8 are, by default, used to identify these 8 queues available on the port. The 8 queues are available both on the access and access uplink ports. Queue parameters for these 8 queues can be configured as part of the access egress QoS policy which is applied on the access ports and network queue policy which is applied on the access uplink ports.

The queue ID 1 to 8 are assigned to each of the 8 queues. Queue-ID 8 is the highest priority and queue-id 1is the lowest priority. FCs are correspondingly mapped to these queue IDs according to their priority. The system defined map is described in Table 15.

Table 15: Forwarding Class to Queue-ID Map

FC-ID	FC Name	FC Designation	Queue-ID
7	Network control	NC	8
6	High-1	H1	7
5	Expedited	EF	6
4	High-2	H2	5
3	Low-1	L1	4
2	Assured	AF	3
1	Low-2	L2	2
0	Best-Effort	BE	1

2.6. Schedulers

This section provides information about schedulers.

2.6.1. Port Scheduler Policies

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 provides the arbitration across the eight CoS queues is a scheduler and is configured in a variety of modes. A major aspect of the arbitration mechanism is the ability to provide minimum and maximum bandwidth guarantees. 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.

2.6.2. Scheduler Modes

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 priority in both the CIR and PIR loop.
Displayed in Table 16, 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.
Table 16: Minimum and Maximum Bandwidth Shapers Example
Queue ID
Minimum Bandwidth
Maximum Bandwidth

7
10 Mbps
1 Gbps

6
10 Mbps
1 Gbps

5
50 Mbps
1 Gbps

4
50 Mbps
1 Gbps

3
50 Mbps
1 Gbps

2
50 Mbps
1 Gbps

1
50 Mbps
1 Gbps

0
50 Mbps
1 Gbps
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 round-robin 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 specified, the respective amount of bytes is removed 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 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.

2.7. CPU Queues

This section describes CPU queues and the related features.

2.7.1. Overview

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 used for MAC learning (a copy of which is sent to CPU for MAC learning), EFM, CFM/Y.1731, STP, LACP, ICMP, TWAMP, etc. A set of queues are used to queue packets to the CPU. The number of queues varies per 7210 SAS platform.

7210 SAS-D has 21 queues.
7210 SAS-Dxp has 8 queues.

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.

2.8. Egress Port Rate Limiting

This features allows the user to limit the bandwidth available on the egress of the port to a value less than the maximum possible link bandwidth. On some platforms, it also allows the user to control the amount of burst sent out.

2.9. Queue Management

This section provides information about QoS queue management.

2.9.1. Queues and Queue Parameters

This section describes the queue parameters provisioned for queues used in access egress policy and network queue policy.

Note:

Not all 7210 platforms support queues for all the above policies. In addition, the queue parameters support available varies across different platforms. See platform specific QoS overview sections above and the chapter following to know the support available on different platforms.

2.9.1.1. Queue ID

The queue ID is used to uniquely identify the queue. The queue ID is only unique within the context of the QoS policy within which the queue is defined. It allows user to define multiple queues with different characteristics and identify them while associating it with different forwarding classes.

The software creates 8 queues by default with queue ID 1 to 8. The Queue-ID is automatically assigned to the eight egress queues by software; it is not configurable. Only some of the queue parameters which determine the queue characteristics are configurable.

2.9.1.2. Committed Information Rate

The committed information rate (CIR) for a queue performs the following distinct functions:

Minimum bandwidth guarantees
The queue CIR setting provides the bandwidth that is given to this queue as compared to other queues on the port competing for a share of the available link bandwidth. The queue CIR does not necessarily guarantee bandwidth in all scenarios and also depends on factors, such as CIR over-subscription and link port bandwidth capacity. For each packet in a queue, the CIR is checked with the current transmission rate of the queue. If the current rate is at or below the CIR threshold, the queue is considered in-profile. If the current rate is above the threshold, the queue is considered out-of-profile. The in-profile and out-profile state of queue is linked to scheduler prioritizing behavior as discussed below.
Scheduler queue priority metric
The scheduler serving a group of queues prioritizes individual queues based on their current CIR and PIR states. Queues operating below their CIR are always served before those queues operating at or above their CIR. See Port Scheduler Policies for information about the scheduler behavior on different 7210 SAS platforms.

The in-profile and out-profile state of the queue does not change the packets profile state based on the queue CIR, PIR values. The in-profile and out-profile state of the queue interacts only 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. 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. An egress queue associated with the high-priority class normally has the CIR threshold equal to the PIR rate although the 7210 SAS allows the CIR to be provisioned to any rate below the PIR should this behavior be required.

The CIR of the queue is configurable under the different QoS policies that provide the option to configure the queue parameters — example under access port policies, network queue policies, and so on.

Note:

See Schedulers for information about queue scheduling support on different 7210 SAS platforms.

2.9.1.3. Peak Information Rate

The peak information rate (PIR) defines the maximum rate at which packets are allowed to exit the queue. It does not specify the maximum rate at which packets may enter the queue; this is governed by the queue's ability to absorb bursts. The actual transmission rate of an egress queue depends on more than just its PIR. Each queue is competing for transmission bandwidth with other queues. For each queue, PIR, CIR, and the relative priority and weight of the scheduler serving the queue, all combine to affect a queue's ability to transmit packets.

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 in Adaptation Rule for Queues.

The PIR of the queue is configurable under the different QoS policies that provide the option to configure the queue parameters — example under access port policies, network queue policies, and so on.

Note:

See Schedulers for information about queue scheduling support on different 7210 SAS platforms.

2.9.1.4. 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.

For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint. The supported constraints are:

Minimum
Find the hardware supported rate that is greater than or equal to the specified rate.
Maximum
Find the hardware supported rate that is less than or equal to the specified rate.
Closest
Find the hardware supported rate that is closest to the specified rate.

Depending on the platform on which the queue is provisioned, the actual operational CIR and PIR settings used by the queue are dependent on the method the hardware uses to implement and represent the mechanisms that enforce the CIR and PIR rates. The adaptation rule controls the method the system uses to choose the rate step based on the administrative rates defined by the rate command.

On 7210 SAS-D devices, for the supported CIR and PIR range values 0 to 1 Gb, the hardware rates are listed in Table 17.

Table 17: Supported Hardware Rates and CIR and PIR Values for Egress Queues on the 7210 SAS-D

Hardware Rate Steps (kb/s)	Rate Range (kb/s)
	0 to 16770 kb/s
16 kb/s	16780 to 33540 kb/s
32 kb/s	33550 to 67090 kb/s
64 kb/s	67100 to 134180 kb/s
128 kb/s	134190 to 268360 kb/s
256 kb/s	268370 to 536730 kb/s
512 kb/s	536740 to 1000000 kb/s

On 7210 SAS-Dxp devices, for supported CIR and PIR range values 0 to 10 Gb, the hardware rates are listed in Table 18.

Table 18: Supported Hardware Rates and CIR and PIR Values for Egress Queues on the 7210 SAS-Dxp

Hardware Rate Steps (kb/s)	Rate Range (kb/s)
64 kb/s	0 to 134144 kb/s
256 kb/s	134145 kb/s and above

To illustrate how the adaptation rule constraints of 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 90 kb/s and 150 kb/s respectively. If the adaptation rule is minimum, the operational CIR and PIR values are 128 kb/s and 192 kb/s 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 are 64 kb/s and 128 kbps. If the adaptation rule is closest, the operational CIR and PIR values are 64 kb/s and 128 kb/s, respectively, as those are the closest matches for the administrative values that are even multiples of the 64 kb/s rate step.

2.9.1.5. Committed Burst Size (Queue)

The committed burst size (CBS) parameters specify the amount of buffers that can be drawn from the reserved buffer portion of the queue’s buffer pool. Once the reserved buffers for a given queue have been used, the queue contends with other queues for additional buffer resources up to the maximum burst size.

The CBS of the queue is configurable under the different QoS policies, if supported by the platform, that provide the option to configure the queue parameters – example under service ingress and service egress queue policies, access port policies, network queue policies, etc. The CBS for a queue is specified in K bytes.

For 7210 SAS-D and 7210 SAS-Dxp, the CBS for the queues is not configurable. 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 used on different ports are listed in Table 19.

2.9.1.6. Maximum Burst Size (Queue)

The maximum burst size (MBS) parameter specifies the maximum queue depth to which a queue can grow. This parameter ensures that a customer that is massively or continuously oversubscribing the PIR of a queue will not consume all the available buffer resources. For high-priority forwarding class service queues, the MBS can be relatively smaller than the other forwarding class queues because the high-priority service packets are scheduled with priority over other service forwarding classes.

The MBS of the queue is configurable under the different QoS policies, if supported by the platform, that provide the option to configure the queue parameters – example under service ingress and service egress queue policies, access port policies, network queue policies, etc. The MBS for a queue is specified in Kbytes.

On 7210 SAS-D and 7210 SAS-Dxp, the MBS for the queues is not configurable. The 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 used on different ports are listed in Table 19.

2.9.1.6.1. Default CBS and MBS for Queues

Table 19: Default CBS and MBS Values

Platforms

CBS in KBytes

(Network Queue/ Access Uplink Queue)

CBS in KBytes

(Access Queue)

MBS in KBytes (Network Queue/ Access Uplink Queue)

MBS in KBytes

(Access Queue)

7210 SAS-D

8.4

See 1

7210 SAS-Dxp

See 2

Notes:

On 7210 SAS-D, 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 78 Kbytes. The show>pool port ID>access-egress and show>pool port ID>access-uplink-egress commands are available to display the values in use depending on the port mode (either access or access-uplink).
On 7210 SAS-Dxp, 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 65 Kbytes. The show>pool port ID>access-egress and show>pool port ID>access-uplink-egress commands are available to display the values in use depending on the port mode (either access or access-uplink).
7210 SAS-Dxp also supports a 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 equivalent to 202 Kbytes.

2.9.1.7. Queue Counters

The router maintains counters for queues within the system for granular billing and accounting.

Each queue maintains the following counters:

Counters for packets and octets accepted/forwarded into the queue
Counters for packets and octets rejected at the queue

The counters available vary among the 7210 SAS platform. Not all the counters are supported on all the platforms. Additionally there are restrictions on the number of counters that can be used simultaneously with a single queue. Some platforms can only count octets or packets and other can count both packets and octets. See “Accounting Records” in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C System Management Guide for information about counter (and corresponding accounting record) support available on each of the platforms.

2.9.2. Buffer Pools

Buffer pools are used to manage the packet buffer memory resources used to store packets and absorb bursts received on a queue.

2.9.2.1. Buffer Pools

Buffer pools cannot be created or deleted. The egress buffer pools are distributed as network egress buffer pool for access-uplink ports and access egress buffer pool for access ports. Based on the maximum number of ports to be supported for access and network, the total buffer is distributed into the access egress buffer pool and the network egress buffer pool. The distribution of the buffers into access and network egress pools take care of the buffer requirements at the port level for various queue shaping/ scheduling mechanisms and for various packet sizes varying from 64 bytes to jumbo frames. 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 and it allows the queue to absorb larger bursts if other queues are not bursting simultaneously.

In addition, for 7210 SAS-Dxp in per-port MBS pool mode, an option is provided to decommission the port and allocate its buffers towards other ports.

2.9.2.2. Decommissioning Ports with Per-Port MBS Pool on 7210 SAS-Dxp

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 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.

2.9.2.2.1. Using Decommission Command for Buffer Allocation on 7210 SAS-Dxp

Note:

Using the decommission command for buffer allocation is only supported on the 7210 SAS-Dxp (all variants). For each port receiving reallocated resources from port decommissioning, a maximum of two ports can be decommissioned.

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 other ports. Services cannot be configured on the unused ports as software takes away all the queue buffer resources from these ports and allocates it to 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.

The users have an option to specify the groups of ports which receive 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 4 fiber ports and allocate the freed up queue buffers to the 10G 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.

2.9.2.2.2. Configuration Guidelines for Use of Decommission Commands on 7210 SAS-Dxp

The configure system resource-profile decommission entry command 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 eight queues on the port) and the CBS portions 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 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 administratively down (shutdown) state before it is added to a decommission entry. An attempt to configure a port which is in an 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. Any attempt to do so results in an error.

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.

The following configuration sample shows the ports to be decommissioned.

A:7210SAS>config>system>res-prof>decom# info detail

----------------------------------------------

entry 15 port 1/1/1,1/1/2

----------------------------------------------

A:7210SAS>config>system>res-prof>decom#

Note:

The number of ports that a port can borrow buffers from is limited and varies depending on the platform. Refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information about the decommission commands.

2.9.3. Slope Policies

The available buffer space is partitioned into buffer pools as described in Buffer Pools. The buffers for a queue are allocated from the buffer pool. Slope policies define the RED slope characteristics.

By default, each queue on the port is associated with slope-policy default which disables the high-slope and low-slope for all the queues.

Note:

If WRED is not configured, then taildrop is used.

2.9.4. RED Slopes

2.9.4.1. Operation and Configuration of RED Slopes for 7210 SAS-D

On 7210 SAS-D, each queue provides the user with two options:

Option to configure 3 slopes per queue - high-priority RED slope, and a low-priority RED slope and a non-TCP RED slope.
Option to use 2 slopes per queue - high-priority RED slope and a low-priority RED slope.

The high-priority RED slope manages access to the shared portion of the buffer pool for high priority or in-profile packets. The low-priority RED slope manages access to the shared portion of the buffer pool for low-priority or out-of-profile packets. The non-TCP slope manages access to the shared portion of the buffer pool for non-TCP packets.

By default, the high-priority, low-priority, and non-TCP RED slopes are disabled.

When a queue depth exceeds the queue’s CBS, packets received on that queue must contend with other queues exceeding their CBS for shared buffers. To resolve this contention, two RED slopes are used to determine buffer availability on a packet by packet basis. A packet that was either classified as high priority or considered in-profile is handled by the high-priority RED slope. This slope should be configured with RED parameters that prioritize buffer availability over packets associated with the low-priority RED slope. Packets that had been classified as low priority or out-of-profile are handled by the low-priority RED slope. When the queue is configured with option to use non-TCP Slope, non-TCP packets are handled by this slope.

2.9.4.2. Operation and Configuration of RED Slopes for 7210 SAS-Dxp

On the 7210 SAS-Dxp, two slopes can be used per queue: a high-priority RED slope, and a low-priority RED slope. The slope policy is only used for TCP traffic. Non-TCP traffic is always tail-dropped if the queues are full.

The high-priority RED slope manages access to the shared portion of the buffer pool for high-priority or in-profile TCP packets. The low-priority RED slope manages access to the shared portion of the buffer pool for low-priority or out-of-profile TCP packets. By default, the high-priority and low-priority RED slopes are disabled.

When a queue depth exceeds the queue’s CBS, packets received on that queue must contend with other queues exceeding their CBS for shared buffers. To resolve this contention, two RED slopes are used to determine buffer availability on a packet-by-packet basis. A TCP packet that is 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 are classified as low-priority or out-of-profile are handled by the low-priority RED slope. Non-TCP packets are tail-dropped if the queue is full.

2.9.4.3. Simplified Overview of RED for 7210 SAS-D and 7210 SAS-Dxp

The following is a simplified overview of how a RED slope determines shared buffer availability on a packet basis:

The RED function keeps track of shared buffer utilization and shared buffer average utilization.
At initialization, the utilization is 0 (zero) and the average utilization is 0 (zero).
When each packet is received, the current average utilization is plotted on the slope to determine the packet’s discard probability.
A random number is generated associated with the packet and is compared to the discard probability.
The lower the discard probability, the lower the chances are that the random number is within the discard range.
If the random number is within the range, the packet is discarded which results in no change to the utilization or average utilization of the shared buffers.
A packet is discarded if the utilization variable is equal to the shared buffer size or if the utilized CBS (actually in use by queues, not just defined by the CBS) is oversubscribed and has stolen buffers from the shared size, lowering the effective shared buffer size equal to the shared buffer utilization size.
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 on 7210 SAS-D and 7210 SAS-Dxp.)
The new shared buffer average utilization is used as the shared buffer average utilization next time a packet’s probability is plotted on the RED slope.
When a packet is removed from a queue (if the buffers returned to the buffer pool are from the shared buffers), the shared buffer utilization is reduced by the amount of buffers returned. If the buffers are from the CBS portion of the queue, the returned buffers do not result in a change in the shared buffer utilization.

Figure 3 shows how a RED slope itself is a graph with an X (horizontal) and Y (vertical) axis. The X-axis plots the percentage of shared buffer average utilization, going from 0 to 100 percent. The Y-axis plots the probability of packet discard marked as 0 to 1. The actual slope can be defined as four sections in (X, Y) points:

Figure 3: RED Slope Characteristics

Section A is (0, 0) to (start-avg, 0). This is the part of the slope that the packet discard value is always zero, preventing the RED function from discarding packets when the shared buffer average utilization falls between 0 and start-avg.
Section B is (start-avg, 0) to (max-avg, max-prob). This part of the slope describes a linear slope where packet discard probability increases from zero to max-prob.
Section C is (max-avg, max-prob) to (max-avg, 1). This part of the slope describes the instantaneous increase of packet discard probability from max-prob to one. A packet discard probability of 1 results in an automatic discard of the packet.
Section D is (max-avg, 1) to (100%, 1). On this part of the slope, the shared buffer average utilization value of max-avg to 100% results in a packet discard probability of 1.

Plotting any value of shared buffer average utilization will result in a value for packet discard probability from 0 to 1. Changing the values for start-avg, max-avg and max-prob allows the adaptation of the RED slope to the needs of the different queues (for example: access port queues) using the shared portion of the buffer pool, including disabling the RED slope.

2.9.4.4. Tuning the Shared Buffer Utilization Calculation on 7210 SAS-D and 7210 SAS-Dxp

The 7210 SAS-D 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 calculate the average shared buffer utilization is shown in Figure 4.

Figure 4: Calculation for Average Shared Buffer Utilization

where:

SBAUn = Shared buffer average utilization for event n

SBAUn-1 = Shared buffer average utilization for event (n-1)

SBU = The instantaneous shared buffer utilization

TAF = The time average factor

Table 20 describes the effect the allowed values of TAF have on the relative weighting of the instantaneous SBU and the previous SBAU (SBAUn-1) has on the calculating the current SBAU (SBAUn).

Table 20: TAF Impact on Shared Buffer Average Utilization Calculation

TAF	2TAF	Equates To	Shared Buffer Instantaneous Utilization Portion	Shared Buffer Average Utilization Portion
0	20	1	1/1 (1)	0 (0)
1	21	2	1/2 (0.5)	1/2 (0.5)
2	22	4	1/4 (0.25)	3/4 (0.75)
3	23	8	1/8 (0.125)	7/8 (0.875)
4	24	16	1/16 (0.0625)	15/16 (0.9375)
5	25	32	1/32 (0.03125)	31/32 (0.96875)
6	26	64	1/64 (0.015625)	63/64 (0.984375)
7	27	128	1/128 (0.0078125)	127/128 (0.9921875)
8	28	256	1/256 (0.00390625)	255/256 (0.99609375)
9	29	512	1/512 (0.001953125)	511/512 (0.998046875)
10	210	1024	1/1024 (0.0009765625)	1023/2024 (0.9990234375)
11	211	2048	1/2048 (0.00048828125)	2047/2048 (0.99951171875)
12	212	4096	1/4096 (0.000244140625)	4095/4096 (0.999755859375)
13	213	8192	1/8192 (0.0001220703125)	8191/8192 (0.9998779296875)
14	214	16384	1/16384 (0.00006103515625)	16383/16384 (0.99993896484375)
15	215	32768	1/32768 (0.000030517578125)	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.

2.9.4.5. Slope Policy Parameters for 7210 SAS-D

The elements required to define a slope policy are:

A unique policy ID
The high and low RED slope shapes for the queues: settings for the high-priority and low-priority RED slopes or The high-slope (for TCP in-profile packets), low-slope (for TCP out-of-profile packets) and non-TCP slope (for non-TCP packets). All three slopes are on a per port per queue basis.
Configurable parameters on each slope are start-avg, max-avg, max-prob and time averaging-factor (TAF).

A slope policy is defined with generic parameters so that it is not inherently an access or network policy. A slope policy defines access port egress queue buffer management properties when it is associated with an access port buffer pool and access-uplink port egress queue buffer management properties when it is associated with a access-uplink port buffer pool.

Each access port egress buffer pool and access-uplink port egress buffer pool can be associated with one only slope policy ID. 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 21 lists the default values for the default slope policy.

Table 21: Default slope policy definition for 7210 SAS-D

Parameter	Description	Setting
Policy ID	policy ID	default (for default policy)
High (RED) slope	Administrative state	Shutdown
	start-avg	70% utilization
	max-avg	90% utilization
	max-prob	75% probability
Low (RED) slope	Administrative state	Shutdown
	start-avg	50% utilization
	max-avg	75% utilization
	max-prob	75% probability
Non-TCP (RED) slope	Administrative State	Shutdown
	start-avg	50% utilization
	max-avg	75% utilization
	max-prob	75% probability

2.9.4.6. Slope Policy Parameters for 7210 SAS-Dxp

The elements required to define a slope policy are:

A unique policy ID
The high and low RED slope shapes for the queues: settings for the high-priority and low-priority RED slopes. Slope policies are only used for TCP traffic. Non-TCP traffic is always tail-dropped if the queues are full.
Configurable parameters on each slope are start-avg, max-avg, max-prob and time averaging-factor (TAF).

Table 22 lists the default values for the default slope policy.

Table 22: Default Slope Policy Definition for 7210 SAS-Dxp

Parameter	Description	Setting
Policy ID	policy ID	default (for default policy)
High (RED) slope	Administrative state	Shutdown
	start-avg	70% utilization
	max-avg	90% utilization
	max-prob	75% probability
Low (RED) slope	Administrative state	Shutdown
	start-avg	50% utilization
	max-avg	75% utilization
	max-prob	75% probability

2.10. QoS Policy Entities

Services are configured with default QoS policies. Additional policies must be explicitly created and associated. There is one default service ingress QoS policy, one default service egress policy, one default access egress QoS policy, one default network QoS policy and one default port scheduler policy. Only one ingress QoS policy and one egress QoS policy can be applied to a SAP or access/access-uplink port or network port.

When you create a new QoS policy, default values are provided for most parameters with the exception of the policy ID, descriptions. Each policy has a scope, default action, a description, and meters for ingress policies and queues for egress policies. By default, all forwarding classes are mapped to Queue 1.

QoS policies can be applied to the following service types:

Epipe and VPLS
1. On 7210 SAS-D and 7210 SAS-Dxp, SAP ingress policies are supported on an Epipe service access point (SAP) and VPLS SAP.

QoS policies can be applied to the following entities on 7210 SAS-D and 7210 SAS-Dxp:

Access egress policies on access ports
Network QoS policy on access uplink port
Network queue policy (egress) on access uplink port

2.11. Configuration Notes

The following information describes QoS implementation caveats:

Creating additional QoS policies is optional.
Default policies are created for service ingress, service egress, access service egress, network, network queue, slope, remark, dot1p and DSCP classification and port scheduler. (the policy types created varies across the platforms)
Associating a service or access or access uplink with a QoS policy other than the default policy is optional.

Queue ID	Minimum Bandwidth	Maximum Bandwidth
7	10 Mbps	1 Gbps
6	10 Mbps	1 Gbps
5	50 Mbps	1 Gbps
4	50 Mbps	1 Gbps
3	50 Mbps	1 Gbps
2	50 Mbps	1 Gbps
1	50 Mbps	1 Gbps
0	50 Mbps	1 Gbps

2. QoS Policies

2.1. QoS Policies Overview

2.1.1. Summary of Major Functions of QoS Policies

Table 5: QoS Policy Types and Descriptions for 7210 SAS-D and 7210 SAS-Dxp

2.1.2. Service and Network QoS Policy Mechanisms

Figure 1: 7210 SAS-D and 7210 SAS-Dxp Service and Network Traffic Types and QoS model

2.2. Network and Service QoS Policies

2.2.1. Network QoS Policies on Access-uplink Ports

2.2.2. Default Network QoS Policy (Egress) for the 7210 SAS-D

Table 6: Default Network QoS Policy Egress Marking on 7210 SAS-D

2.2.3. Default Network QoS Policy (Egress) for the 7210 SAS-Dxp

Table 7: Default Network QoS Policy Egress Marking on 7210 SAS-Dxp

2.2.4. Default Network QoS Policy (Ingress)

Table 8: Default Network QoS policy Ingress Classification

2.2.5. Network Queue Policies in Access-uplink Mode

Table 9: Default Network Queue Policy Definition (7210 SAS-D)

Table 10: Default Network Queue Policy Definition (7210 SAS-Dxp)

2.2.6. Service Ingress QoS Policies

2.2.6.1. Service Ingress QoS Policies

Figure 2: Traffic Policing and Queuing Model for Forwarding Classes

2.2.6.2. Default Service Ingress Policy

Table 11: Default Service Ingress Policy ID 1 Definition

2.2.7. Service Ingress Classification

2.2.7.1. Service Ingress Classification

2.2.7.2. Hierarchical Ingress Policing on 7210 SAS-D and 7210 SAS-Dxp

2.3. Access Egress QoS Policies

2.3.1. Default Access Egress Policy

Table 12: Default Access Egress Policy ID 1 Definition

2.4. Meters/Policers

2.4.1. Metering/Policing and Meter Parameters

2.4.1.1. Meter ID

2.4.1.2. Committed Information Rate (Meters)

2.4.1.3. Peak Information Rate (Meters)

2.4.1.4. Adaptation Rule for Meters

2.4.1.4.1. Adaptation Rule for Meters on 7210 SAS-D Devices

2.4.1.4.2. Adaptation Rule for Meters on 7210 SAS-Dxp Devices

Table 13: Supported Hardware Rates and Burst Step Sizes for CIR and PIR Values for 7210 SAS-Dxp

2.4.1.5. Committed Burst Size (For Meters/Policers)

2.4.1.6. Maximum Burst Size (For Meters/Policers)

2.4.1.6.1. Excess Burst Size (For Meters/Policers)

2.4.2. Meter Counters

2.4.3. Meter Modes

2.4.3.1. Color-aware and Color-blind Policing/Metering

2.4.4. QoS Overrides for Meter/Policers

2.4.4.1. Configuration Guidelines of QoS Override

2.4.4.2. Configuring Meter Override Parameters

2.5. Forwarding Classes

Table 14: Forwarding Classes

2.5.1. Forwarding-Class To Queue ID Mapping

2.5.2. FC to Queue ID Mapping

Table 15: Forwarding Class to Queue-ID Map

2.6. Schedulers

2.6.1. Port Scheduler Policies

2.6.2. Scheduler Modes

Table 16: Minimum and Maximum Bandwidth Shapers Example

2.7. CPU Queues

2.7.1. Overview

2.8. Egress Port Rate Limiting

2.9. Queue Management

2.9.1. Queues and Queue Parameters

2.9.1.1. Queue ID

2.9.1.2. Committed Information Rate

2.9.1.3. Peak Information Rate

2.9.1.4. Adaptation Rule for Queues

Table 17: Supported Hardware Rates and CIR and PIR Values for Egress Queues on the 7210 SAS-D

Table 18: Supported Hardware Rates and CIR and PIR Values for Egress Queues on the 7210 SAS-Dxp

2.9.1.5. Committed Burst Size (Queue)

2.9.1.6. Maximum Burst Size (Queue)

2.9.1.6.1. Default CBS and MBS for Queues

Table 19: Default CBS and MBS Values

2.9.1.7. Queue Counters

2.9.2. Buffer Pools

2.9.2.1. Buffer Pools

2.9.2.2. Decommissioning Ports with Per-Port MBS Pool on 7210 SAS-Dxp

2.9.2.2.1. Using Decommission Command for Buffer Allocation on 7210 SAS-Dxp

2.9.2.2.2. Configuration Guidelines for Use of Decommission Commands on 7210 SAS-Dxp

2.9.3. Slope Policies

2.9.4. RED Slopes

2.9.4.1. Operation and Configuration of RED Slopes for 7210 SAS-D

2.9.4.2. Operation and Configuration of RED Slopes for 7210 SAS-Dxp