QoS policies

QoS policies overview

The 7210 SAS devices are designed with ingress and egress QoS mechanisms 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 as a Layer 2 path to the service data; however, the data 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 the following FCs, internally named: Network-Control, High-1, Expedited, High-2, Low-1, Assured, Low-2, and Best-Effort. See Forwarding classes for more information.

The 7210 SAS supports the use of different types of QoS policies to handle the specific QoS needs at each point in the service delivery model within the device. QoS policies are defined in a global context on the 7210 SAS and only take effect when the policy is applied to an entity.

QoS policies are uniquely identified with a policy ID number or name. Typically, Policy ID 1 or Policy ID ‟default” are reserved for the default policy, however, there are a few instances where the default QoS policy uses a different ID. The default QoS policy is used if no policy is explicitly applied.

The QoS policies supported on the 7210 SAS can be divided into the following types:

QoS policies that are used for classification, defining metering and queuing attributes, and defining marking behavior.
Slope policies that define default buffer allocations and weighted random early detection (WRED) slope definitions.
Port scheduler policies, SAP ingress and egress policies, or network and network-queue policies that determine how queues are scheduled.

Overview of QoS policies on 7210 SAS-D and 7210 SAS-Dxp

7210 SAS-D and 7210 SAS-Dxp QoS policies are applied on service ingress, access port egress, and access uplink ports (ingress and egress). These policies allow users to configure the following:

classification rules for how traffic is mapped to FCs
FC association with meters and meter parameters used for policing (rate-limiting)
queuing parameters for shaping and buffer allocation
QoS marking and interpretation

There are the following types of QoS policies:

service ingress policies for access SAP ingress
access egress policies for access port egress
network policies for access-uplink port ingress and egress
network queue policies 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 SAPs. Traffic that enters through the SAP is classified to map it to an FC. FCs are 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 criteria, and MAC criteria. The characteristics of the FC meters are defined within the policy with regard to the number of FC meters used for unicast traffic and the meter characteristics (like CIR, PIR, and so on). Each FC can be associated with different meter parameters.

A service ingress QoS policy also defines up to three meters per FC, which can be used for multipoint traffic for multipoint services. There can be up to 32 meters in total per service ingress QoS policy.

For VPLS, the following types of forwarding are supported:

unicast
multicast
broadcast
unknown

Multicast, broadcast, and unknown forwarding types are typically sent to multiple destinations within the service, while the unicast forwarding type is handled in a point-to-point manner within the service.

An access egress policy is analogous to a SAP egress policy. 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 eight 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 eight egress queues at the port level. An access-egress policy also defines how to remark the FC-to-priority bits (for example, IEEE 802.1p bits) in the customer traffic.

Network QoS policies can be applied to access uplink ports. On ingress, the policy can be used to map incoming dot1p values to the FC and profile state for the traffic received from the core network. On egress, the policy maps the FC and profile state to priority bit (for example, IEEE 802.1p bits) values for traffic to be transmitted into the core network.

On egress, network queue policies are applied to access uplink ports. The policies define the FC 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); 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, which can then be applied to an access port, with a single access egress QoS policy allowed to be associated with an 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, a default QoS policy is applied.

Summary of major functions of QoS policies

The following table describes the major functions performed by the QoS policies for 7210 SAS-D and 7210 SAS-Dxp.

Table 1. 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 FC 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 eight FC queues and queue parameters for traffic classification maps FCs to the queues defines queue parameters for the queues defines FC-to-remarking values defines CIR levels and PIR weights that determine how the queue is 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	on ingress, defines dot1p to FC mapping and meters on egress, defines FC-to-remarking values (for example, IEEE 802.1p)
Network queue	Access uplink ports	defines FC 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

Network and service QoS policies

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

The following figure shows that on 7210 SAS-D and 7210 SAS-Dxp, for customer interfaces, there are service ingress and access port egress traffic types, and for access uplink port interfaces, there are network ingress and network egress traffic types.

Figure 1. 7210 SAS-D and 7210 SAS-Dxp service and network traffic types and QoS model

The 7210 SAS uses the following QoS policies applied to a SAP, access-uplink port, access port to define queuing, queue attributes, meter attributes, and QoS marking interpretation.

The 7210 SAS supports the following major types of service and network QoS policies: Network QoS policies on access-uplink ports, Default network QoS policy (egress) for the 7210 SAS-Dxp, Default network QoS policy (ingress), Network queue policies in access-uplink mode, Service ingress QoS policies, and Service ingress classification.

Network QoS policies on access-uplink ports

Network QoS policies define egress QoS marking and ingress QoS interpretation for traffic received on access-uplink ports. The router automatically creates egress queues for each of the FCs on the 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
- defines dot1p value mapping to FCs and profile
- defines FC to meter mapping
egress
- defines the FC and profile state to dot1p value markings
- option to define the FC and profile state to IP DSCP value marking
- remarking of QoS bits can be enabled or disabled

The required network QoS policy definitions are the following:

a unique network QoS policy ID
egress - FC and profile state to priority bits (for example, 802.1p, and so on) used for marking, for each FC
a default ingress FC and an optional in-profile or out-of-profile state
at least one default unicast FC meter. See Committed information rate (meters) for information about meter configuration parameters.
optional multipoint FC meter

The optional network QoS policy elements definitions are the following:

additional unicast meters or queues
additional multipoint meters or queues
dot1p value to FC 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 FC and profile state to IP DSCP value marking

Network policy ID 1 is reserved for 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 that 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. The following table lists the default mapping of FC to dot1p values for egress marking on the 7210 SAS-D.

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

Default network QoS policy (egress) for the 7210 SAS-Dxp

The following table lists the default mapping of FC to dot1p values for egress marking on the 7210 SAS-Dxp.

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

Default network QoS policy (ingress)

For network ingress, the following table lists the default mapping of dot1p values to FC and profile state for the default network QoS policy.

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

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 eight egress queues (not user-configurable) for the network port, and FCs are mapped to these right egress queues. All policies use eight egress queues like the default network queue policy. The following table describes the eight egress queues for 7210 SAS-D.

Table 5. Default network queue policy definition (7210 SAS-D)
FC	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%

The following table describes the eight egress queues for 7210 SAS-Dxp.

Table 6. Default network queue policy definition (7210 SAS-Dxp)
FC	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%

Service ingress QoS policies

Service ingress QoS policies define ingress service FC queues or meters and map traffic flows to FC 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 and sections for more information.

When a service ingress QoS policy is created, it typically has some meters defined that cannot be deleted and is used for all traffic (both unicast and multicast traffic). These meters exist within the definition of the policy but 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 are not instantiated.

In the simplest service ingress QoS policy, all traffic is handled as a single flow and mapped to a single meter.

The required elements to define a service ingress QoS policy are the following:

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
the allocation of resources from the ingress internal CAM resource pool for use with service ingress QoS classification using the commands available under the CLI context configure>system>resource-profile. Additionally, the allocation of resources to the appropriate classification match criteria
at least one default FC meter. See Metering/policing and meter parameters for information about the parameters that can be configured for a meter.

Optional service ingress QoS policy elements include the following:

additional unicast meters, up to 31
additional multipoint meters up to 31
QoS policy match criteria to map packets to an FC

Each meter can have unique meter parameters to allow individual policing of the flow mapped to the FC. The following figure shows service traffic being classified into three different FCs.

Figure 2. Traffic policing and queuing model for FCs

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 that do not have another service ingress policy assigned. In the default policy, all traffic is mapped to the default FC, which uses a meter by default. The following table lists the characteristics of the default policy.

Table 7. Default service ingress policy ID 1 definition
Item	Definition
Meter 1	1 (one) meter all unicast traffic: FC: best-effort (be) CIR = 0 PIR = max (4000000 kb/s in case of a LAG with four member ports) CBS = 32 kb MBS = 128 kb
Default FC (be)	1 (one) flow defined for all traffic: all traffic mapped to best-effort (be)

Service ingress classification

Mapping flows to FCs are 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 FC is subject to a provisioned classification policy.

Service ingress classification

On SAP ingress, users have an option to use either MAC criteria or IP criteria, or both IPv4 and MAC criteria. 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 ipv6-criteria any or ipv6-criteria dscp-only
ipv6-criteria dscp-only and ipv6-criteria any or ipv6-criteria dscp-only
mac-criteri any and ip-criteria any or ip-criteria dscp-only 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 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 and dst-address are not allowed.

The available ingress CAM hardware resources from the ingress internal CAM pool can be allocated according to user needs for use with different QoS classification match criteria using the commands available under the CLI configure>system> resource-profile context. By default, the system allocates resources to SAP ingress classification on bootup. Users can change the resource allocation based on their need to scale the number of entries or number of associations (that is, the 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, the association of that policy to a SAP fails. Allocation of classification entries also allocates meter resources, used to implement the per FC per traffic type policing function. See Resource allocation for service ingress QoS policy classification rules for more information about resource usage and allocation to SAP ingress policies.

In addition to the preceding classification rules, the user has an option to use the DEI bit to identify the ingress profile and enable color-aware policing. See DEI-based classification and marking for more information.

Hierarchical ingress policing on 7210 SAS-D and 7210 SAS-Dxp

Hierarchical ingress policing (also known as SAP ingress aggregate meter/policer) allows 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, the user can allow the packets classified as Internet data to use the entire SAP bandwidth when other FCs do not have traffic.

Hierarchical ingress policing provides an option to configure a SAP aggregate policer/meter per SAP on SAP ingress. The user should configure the PIR rate of the aggregate policer and optionally configure the burst size.

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

For more information about the final color/profile assigned to the packet, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Services Guide, configure service sap ingress aggregate-meter-rate command description.

The trtcm2 (RFC 4115) meter mode is used only on SAP ingress. When the SAP aggregate policer is configured, the per-FC policer can be only configured in ‟trtcm2” mode. The meter modes ‟srtcm” and ‟trtcm1” can be used in the absence of an aggregate meter.

Note:

Before using per-SAP aggregate meter/policer, meter resources must be allocated using the config system resource-profile ingress-internal-tcam sap-aggregate-meter command. These resources are shared with ingress ACLs. A change to the number of resources allocated for the SAP aggregate meter requires a reboot of the node to take effect. The amount of resources allocated for this feature determines the number of SAPs that can use the aggregate meter/policer. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information.

Access egress QoS policies

On the 7210 SAS-D and 7210 SAS-Dxp, an access-egress policy defines the queue and marking characteristics for the traffic egressing toward the customer on the access ports. There are eight queues always available at the access port, and FCs are mapped to these eight queues. By configuring queue shaper rates, the individual FC traffic can be managed so that the traffic for each FC is well within SLA limits and does not impact the traffic of other FCs. The access-egress policy also provides an option for marking packets sent out of access ports, allowing the FC to be mapped to packet header priority bits (for example, IEEE dot1p bits).

The FCs are mapped to eight queues by the software, as per FC-to-queue ID map, and this mapping is not user configurable. The queue ID determines the priority of the queue, with a higher queue-ID denoting a 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
IEEE 802.1p priority value remarking based on FC
on 7210 SAS-D and 7210 SAS-Dxp, an option is available to use IP DSCP values for marking based on FC

See Queues and queue parameters for information about the parameters that can be configured for a queue.

The FC 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 FC of the packet. If the packet was received over a service transport tunnel on an access-uplink port, the FC is marked in the outer tag of the QinQ encapsulation.

Default access egress policy

Access-egress QoS policy ID 1 is reserved as the default access-egress policy associated with access ports that do not have another access-egress policy explicitly assigned. The characteristics of the default policy are listed in Default access egress policy ID 1 definition for 7210 SAS-D and 7210 SAS-Dxp.

Table 8. Default access egress policy ID 1 definition for 7210 SAS-D and 7210 SAS-Dxp
FC	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)

Meters/policers

This section provides information about meters/policers.

Metering/policing and meter parameters

This section describes the meter behavior and available 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 SAS platforms support meters for all the policies. In addition, the meter parameters supported vary across platforms. See the platform-specific QoS overview sections in this guide. In the following sections, the platform differences about support are noted.

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 in which the meter is defined. It allows users to define multiple meters in a policy and associate them with one of the eight FCs.

Committed information rate (meters)

The committed information rate (CIR) for a meter is the long-term average rate at which traffic is considered conforming traffic or in-profile traffic. The higher the rate, the greater the expected throughput. The user can configure the burst above the CIR and up to the 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 the hardware that determine the operational CIR for the meter. The user has some control over how the administrative CIR is converted to an operational CIR if the hardware does not support the exact CIR and PIR combination specified. See Adaptation rule for meters for more information about the interpretation of the administrative CIR.

Peak information rate (meters)

The peak information rate (PIR) defines the maximum rate at which packets are allowed to exit the meter. The PIR does not specify the maximum rate at which packets can enter the meter; this is controlled by the ability of the meter 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 rates in hardware that determine the operational PIR for the meter. The user has some control over how the administrative PIR is converted to an operational PIR if the hardware does not support the exact CIR and PIR combination specified. See Adaptation rule for meters for more information about the interpretation of the administrative PIR.

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, which are enforced by the hardware meter. The rule provides a constraint when the exact rate is not available as a result of hardware capabilities. The following constraints are supported:

minimum

The system finds the next multiple of the hardware step size that is equal to or greater than the specified rate.
maximum

The system finds the next multiple of the hardware step size that is less than or equal to the specified rate.
closest

The system finds the next multiple of the hardware step size that is closest to the specified rate.

Adaptation rule for meters on 7210 SAS-D devices

The 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 following constraints are supported:

minimum

The system finds the next multiple of 8 kb/s that is equal to or greater than the specified rate.
maximum

The system finds the next multiple of 8 kb/s that is less than or equal to the specified rate.
closest

The system finds the next multiple of 8 kb/s that is closest to the specified rate.

Adaptation rule for meters on 7210 SAS-Dxp devices

The 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 following constraints are supported for 1G ports:

minimum

The system finds the next multiple of 8 kb/s that is equal to or greater than the specified rate.
maximum

The system finds the next multiple of 8 kb/s that is less than or equal to the specified rate.
closest

The system finds the next multiple of 8 kb/s that is closest to the specified rate.

The following table lists information for calculating the 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 9. Supported hardware rates and burst step sizes for CIR and PIR values for 7210 SAS-Dxp
Rate (kb/s)	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 configured burst size affects the rate step-size used by the system. The system uses the step size to ensure that both the burst size and rate parameter constraints are met. For example, if the rate specified is less than 4 Gb/s but the configured burst size is 17 Mb, then the system uses rate step size of 16 Kb and burst step size of 8192 bits (see Supported hardware rates and burst step sizes for CIR and PIR values for 7210 SAS-Dxp, row 2).

If the meter is a srTCM meter, 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, 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, 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.

Committed burst size (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, the packets are marked as in-profile by the meter to indicate that the traffic is complying with meter-configured parameters.

Note:

See Supported hardware rates and burst step sizes for CIR and PIR values for 7210 SAS-Dxp for information about the burst parameter step size for 7210 SAS-Dxp.

Maximum burst size (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, 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, packets marked as red are dropped.

Note:

See Supported hardware rates and burst step sizes for CIR and PIR values for 7210 SAS-Dxp for information about the burst parameter step size for 7210 SAS-Dxp.

Excess burst size (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, the packets are marked as out-profile by the meter to indicate that the traffic is not complying with the CIR. If the packet burst is higher than EBS, packets marked as red are dropped.

Note:

The EBS parameter is used only when the meter mode is set to ‟trtcm2.”
See Supported hardware rates and burst step sizes for CIR and PIR values for 7210 SAS-Dxp for information about the burst parameter step size for 7210 SAS-Dxp.

Meter counters

The 7210 SAS devices maintain counters for meters within the system for the purpose of granular billing and accounting. Each meter maintains the following counters:

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

The counters available vary among the 7210 SAS platforms. Not all counters are supported on all 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 others can count both packets and octets. Typically, each meter can maintain a subset of the counters. Users have the option to select the subset of the 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.

Meter modes

The meter mode command allows users to select from the following 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 and MBS determine the amount of both in-profile/committed traffic and out-of-profile/excess burst. With this meter, the CBS and MBS token buckets are replenished at single rate, that is, CIR.
trTCM

Two Rate Three Color meter, with this meter users 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 allows 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 the CIR rate and the MBS/EBS token buckets are replenished at the PIR/EIR rate There are two modes supported under this:
- trTCM1 - implements policing as per RFC 2698
- trTCM2 - implements policing as per RFC 4115
- 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)

Different QoS policies support different meter modes; not all the meter modes are supported for all the QoS policies.

Color-aware and color-blind policing/metering

In color-aware policing, the user can define the color/profile state (color and profile state are used interchangeably in this section) 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 following applies to color-aware policing:

If the packet is pre-colored as in-profile (also called green packets), 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, it is reassigned a profile value of out-profile (or color value of yellow).
If the packet is pre-colored as out-profile (also called yellow packets), even if the packet burst is less 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, it is marked red and dropped by the meter at ingress.

In color-blind policing, the profile and color assigned to the packet on ingress are ignored and all packets are treated as out-of-profile packets. The CIR and PIR rates configured for the meter determine the final profile and color for the packet. If the packet is within the CIR, the final profile and color assigned to the packet is in-profile/green, and if the packet exceeds the CIR and is within the PIR, the final profile and 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 eligibility of the packet to be enqueued into a buffer at egress (when a slope policy is configured at egress).

The 7210 SAS device supports color-aware policing at network ingress; however, at service ingress a policing option is provided to use either color-aware policing or color-blind policing.

The following support is available on the 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; the option to use color-blind meter is not available on access-uplink port ingress.
With access SAP ingress, a policing option is provided to use either color-aware or color-blind policing.

QoS overrides for meters/policers

The QoS override feature allows the user to override the meter parameters, such as CBS, MBS, rate (CIR and PIR), mode, and adaptation rule (CIR and PIR) in 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.

Configuration guidelines for QoS override

The configuration guidelines of QoS override are the following:

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.

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
                    exit
----------------------------------------------
*A:7210SAS>config>service>epipe>sap>ingress#

Forwarding classes

The 7210 SAS supports multiple FCs and class-based queuing, which means that the concept of FCs is common to all the QoS policies.

Each FC (also called Class of Service (CoS)) is important only in relation to the other FCs. An FC provides network elements with a method to weigh the relative importance of one packet over another in a different FC.

Queues are created for a specific FC to determine the manner in which the queue output is scheduled. The FC 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. The following table describes the FCs supported by the 7210 SAS.

Table 10. 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:

Forwarding classes lists the default definitions for the FCs. The FC behavior, in terms of ingress marking interpretation and egress marking, can be changed.

FC-to-queue ID map

Eight FCs are supported on 7210 SAS devices. Each of these FCs is mapped to a specific queue. By mapping FCs to different queues, the differential treatment is imparted to various classes of traffic.

On these platforms there are only eight queues available at the port level. These eight 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 eight queues available on the port. The eight queues are available both on the access and access-uplink ports. Queue parameters for these eight 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 IDs 1 to 8 are assigned to each of the eight queues. Queue ID 8 is the highest priority and queue ID 1 is the lowest priority. FCs are correspondingly mapped to these queue IDs according to their priority. The following table describes the system defined map.

Table 11. FC-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

Schedulers

This section provides information about schedulers.

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

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.

The following table shows that 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 12. 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 specific for queue 1 and 5 is specific 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 2 Kbytes from that queue, a value of 5 will pump out 10 Kbytes. Twice of the weight value specific is 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.

CPU queues

This section describes CPU queues and related features.

Overview

The packets that are destined for 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, and so on. A set of queues are used to queue packets to the CPU. The number of queues varies per 7210 SAS platform:

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

The packets destined for 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.

Egress port rate limiting

The 7210 SAS supports port egress rate limiting. This feature 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.

Queue management

This section provides information about QoS queue management.

Queues and queue parameters

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

Note:

Not all 7210 SAS platforms support queues for all policies. In addition, the queue parameter support available varies across different platforms. See platform-specific QoS overview sections above and the following chapters for information about the support available on different platforms.

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 where the queue is defined. It allows the user to define multiple queues with different characteristics and identify them while associating it with different FCs.

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

Committed information rate

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

minimum bandwidth guarantees

The queue CIR setting provides the bandwidth for the 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 the queue is linked to scheduler prioritizing behavior, as described in the following bullet point.
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 or 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. User has some control over how the administrative CIR is converted to an operational CIR if the hardware does not support the exact CIR and PIR combination specified. See Adaptation rule for queues for information about the interpretation of the administrative CIR.

Although the 7210 SAS is flexible in how the CIR can be configured, there are conventional ranges for the CIR based on the FC 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.

Peak information rate

The peak information rate (PIR) defines the maximum rate at which packets are allowed to exit the queue. The PIR does not specify the maximum rate at which packets can enter the queue; this is governed by the ability of the queue to absorb bursts. The actual transmission rate of an egress queue depends on more than just its PIR. Each queue is competing for transmission bandwidth with other queues. Each queue, PIR, CIR, and the relative priority and weight of the scheduler serving the queue, all combine to affect the ability of a queue 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 when the hardware does not support the exact CIR and PIR values specified. See Adaptation rule for queues for more information about the interpretation of the administrative PIR.

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.

Adaptation rule for queues

The adaptation rule provides the QoS provisioning system with the ability to adapt defined CIR and PIR administrative rates to the underlying capabilities of the hardware where 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 following constraints are supported:

minimum

The system finds the hardware supported rate that is greater than or equal to the specified rate.
maximum

The system finds the hardware supported rate that is less than or equal to the specified rate.
closest

The system finds the hardware supported rate that is closest to the specified rate.

Depending on the platform where the queue is provisioned, the actual operational CIR and PIR settings used by the queue depend 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 the following table.

Table 13. 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 the following table.

Table 14. 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 kb/s.

If the adaptation rule is closest, the operational CIR and PIR values are 64 kb/s and 128 kb/s, respectively, because those are the closest matches for the administrative values that are even multiples of the 64 kb/s rate step.

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. After the reserved buffers for a specific 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 options to configure the queue parameters; for example, under service ingress and service egress queue policies, access port policies, network queue policies, and so on. The CBS for a queue is specified in kbytes.

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 that take care of specific FC needs in terms of maintaining the differential treatment. The default values used on different ports are listed in Default CBS and MBS values.

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 FC service queues, the MBS can be relatively smaller than the other FC queues because the high-priority service packets are scheduled with priority over other service FCs.

The MBS of the queue is configurable under the different QoS policies, if supported by the platform, that provide the options to configure the queue parameters; for example, under service ingress and service egress queue policies, access port policies, network queue policies, and so on. 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 that take care of specific FC needs in terms of maintaining the differential treatment. The default values used on different ports are listed in Default CBS and MBS values.

Default CBS and MBS for queues

Table 15. Default CBS and MBS values
Platforms	CBS (Kbytes)		MBS (Kbytes)
Platforms	Network queue and access-uplink queue	Access queue	Network queue and access uplink queue	Access queue
7210 SAS-D	8.4	8.4	See^¹	See^¹
7210 SAS-Dxp 12p	9	9	See^²	See^²
7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p	4.5 (for 1 GE ports) 9 (for 10 GE ports)	4.5 (for 1 GE ports) 9 (for 10 GE ports)	See^³	See^³

¹ On 7210 SAS-D, the 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 12p, the 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).

The 7210 SAS-Dxp 12p also supports a decommissioning feature with per-port MBS pool mode. With it, the 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, the maximum MBS per queue on port 1/1/1, assuming no other queues have any traffic, is equivalent to 202 Kbytes.

³ On 7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p, the per-port MBS limit mode is used. With it, the maximum MBS per queue, assuming no other queues on the same port have any traffic, is 150 Kbytes. The maximum MBS limit per port is 200 Kbytes (the CBS buffers available on that port are in addition to the per-port MBS limit).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).

The 7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p also support a decommissioning feature with per-port MBS limit mode. With it, the 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, the maximum MBS limit per queue on port 1/1/1, assuming no other queues have any traffic, is equivalent to 186 Kbytes. The maximum MBS limit per port is equivalent to 236 Kbytes (the CBS buffers available on that port are in addition to the per-port MBS limit).

Queue counters

The 7210 SAS devices maintain counters for queues within the system for the purpose of 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 platforms. 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 others 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.

Buffer pools

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

Buffer pools

Buffer pools cannot be created or deleted. The egress buffer pools are distributed as network egress buffer pools for access-uplink ports and access egress buffer pools 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 and 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 toward 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 toward other ports.

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 are not used to deploy any services.

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 four fixed copper ports and allocate the freed queue buffers to the remaining copper ports in the system or decommission four 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.

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) take 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 may cause unintended behavior of the system. The system software does not check for this but expects users to ensure this through correct 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. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information about the decommission commands.

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.

RED slopes

This section describes the operation and configuration of random early detection (RED) slopes.

Operation and configuration of RED slopes for 7210 SAS-D

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

option to configure three slopes per queue - high-priority RED slope, low-priority RED slope, and a non-TCP RED slope
option to use two 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 queue depth exceeds the queue 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 is 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 are 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.

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 queue depth exceeds the queue 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.

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 zero and the average utilization is zero.
When each packet is received, the current average utilization is plotted on the slope to determine the packet 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 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 used 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 for more information.)
The new shared buffer average utilization is used as the shared buffer average utilization next time a packet 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.

The following figure shows how a RED slope is a graph with an X (horizontal) and Y (vertical) axis. The X-axis plots the percentage of shared buffer average utilization, ranging from 0 to 100%. 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:

The following describe the sections shown in the preceding figure:

Section A is (0, 0) to (start-avg, 0). This is the part of the slope where 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 results 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.

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 the following figure.

Figure 4. Calculation for average shared buffer utilization

where:

SBAU_n = Shared buffer average utilization for event n

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

SBU = The instantaneous shared buffer utilization

TAF = The time average factor

The following table describes the effect the allowed values of TAF have on the relative weighting of the instantaneous SBU and the previous SBAU (SBAU_n-1) on calculating the current SBAU (SBAU_n).

Table 16. TAF impact on shared buffer average utilization calculation
TAF	2^TAF	Equates To	Shared buffer instantaneous utilization portion	Shared buffer average utilization portion
0	2⁰	1	1/1 (1)	0 (0)
1	2¹	2	1/2 (0.5)	1/2 (0.5)
2	2²	4	1/4 (0.25)	3/4 (0.75)
3	2³	8	1/8 (0.125)	7/8 (0.875)
4	2⁴	16	1/16 (0.0625)	15/16 (0.9375)
5	2⁵	32	1/32 (0.03125)	31/32 (0.96875)
6	2⁶	64	1/64 (0.015625)	63/64 (0.984375)
7	2⁷	128	1/128 (0.0078125)	127/128 (0.9921875)
8	2⁸	256	1/256 (0.00390625)	255/256 (0.99609375)
9	2⁹	512	1/512 (0.001953125)	511/512 (0.998046875)
10	2¹⁰	1024	1/1024 (0.0009765625)	1023/2024 (0.9990234375)
11	2¹¹	2048	1/2048 (0.00048828125)	2047/2048 (0.99951171875)
12	2¹²	4096	1/4096 (0.000244140625)	4095/4096 (0.999755859375)
13	2¹³	8192	1/8192 (0.0001220703125)	8191/8192 (0.9998779296875)
14	2¹⁴	16384	1/16384 (0.00006103515625)	16383/16384 (0.99993896484375)
15	2¹⁵	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.

Slope policy parameters for 7210 SAS-D

The elements required to define a slope policy are the following:

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 only one slope policy ID.

The slope policy ID default is reserved for the default slope policy. The default policy cannot be deleted or changed. The default slope policy is applied to all access and network buffer pools that do not have another slope policy explicitly assigned.

The following table lists the default values for the default slope policy.

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

Slope policy parameters for 7210 SAS-Dxp

The elements required to define a slope policy are the following:

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)

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. The slope policy ID default is reserved for the default slope policy. The default policy cannot be deleted or changed. The default slope policy is applied to all access and network buffer pools that do not have another slope policy explicitly assigned.

The following table lists the default values for the default slope policy.

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

QoS policy entities

Services are configured with default QoS policies. Additional policies must be explicitly created and associated. The following policies are configured by default:

one default service ingress QoS policy
one default service egress QoS policy
one default access egress QoS policy
one default network QoS policy
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 and descriptions. Each policy has a scope, default action, description, and meters for ingress policies and queues for egress policies. By default, all FCs are mapped to Queue 1.

QoS policies can be applied to the following service types:

Epipe

On 7210 SAS-D and 7210 SAS-Dxp, SAP-ingress policies are supported on an Epipe.
VPLS

On 7210 SAS-D and 7210 SAS-Dxp, SAP-ingress policies are supported on a 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

Configuration notes

The following information describes QoS implementation restrictions:

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, access, or access-uplink with a QoS policy other than the default policy is optional.