2.2.1.1. Network QoS policy “ip-interface” type

Network QoS policies of the ip-interface type define ingress FC meters and map traffic to those meters for IP interfaces. When a network QoS policy is created, it always has two meters defined that cannot be deleted: one for the unicast traffic and one for the multipoint traffic. These meters exist within the definition of the policy. The meters are used by the hardware only when the policy is applied to an IP interface. This policy also defines the FC to EXP bit marking, on the egress mode.

A network QoS policy defines both the ingress and egress handling of QoS on the network IP interface and network port. The following functions are defined for a network policy of the ip-interface type:

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

Optional network QoS policy elements include:

Network policy ID 2 is reserved as the default network QoS policy of the ip-interface type. The default policy cannot be deleted or changed.

Default network QoS policy 2 is applied to all IP interfaces that do not have another network QoS policy assigned.

The network QoS policy applied at network egress (for example, on an IP interface) determines how or whether the profile state is marked in packets transmitted to the service core network. If the profile state is marked in the service core packets, out-of-profile packets are preferentially dropped over in-profile packets at congestion points in the core network. For network egress, traffic remarking in the network QoS policy is disabled. The following table lists the default mapping of FC-to-EXP values.

For network ingress, the following table lists the default mapping of EXP values to FC and profile state for the default network QoS policy. Color-aware policing is supported on network ingress.

2.2.1.2. Network QoS policy “port” type

Network QoS policy of the port type defines ingress FC meters and maps traffic to the meters for only IP traffic received on network and hybrid ports. When a network policy of this type is created, it has a single unicast meter that cannot be deleted. These meters exist within the definition of the policy. The meters are instantiated in hardware only when the policy is applied to a network port. This policy also defines the FC-to-DSCP or dot1p marking used for packets sent out through that port.

A network QoS policy of the port type defines both the ingress and egress handling of QoS on the network port.

The following functions are defined:

The following are the required elements defined in a network QoS policy of the port type:

Optional network QoS policy elements include the following:

Network policy ID 1 is reserved as the default network QoS policy of the port type. The default policy cannot be deleted or changed.

The default network QoS policy is applied to all network ports that do not have another network QoS policy assigned.

The following table lists the default mapping of FC-to-dot1p and DSCP values.

The following table lists the default mapping of dot1p or DSCP values to FC and profile state for the default network QoS policy of the port type for network ingress. Color-aware policing is supported on network ingress.

2.2.3.1. Network queue policies in network mode

In the network mode of operation, network queue policies define the network FC queue characteristics. Network queue policies are applied on egress on network and hybrid ports for 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T operating in network mode. The system allocates a fixed number of queues for the network port, and FCs are mapped to the queues. All policies use a fixed number of queues, like the default network queue policy.

The following is the number of queues allocated for a network queue policy:

On 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T, the network queues on hybrid ports are used for MPLS, IP, and SAP traffic sent out of IP interfaces and SAPs configured on hybrid ports.

The following queue characteristics can be configured on a per-FC basis:

Network queue policies are identified with a unique policy name, which conforms to the standard 7210 SAS alphanumeric naming conventions. The system default network queue policy is named “default” and cannot be edited or deleted.

Note: CBS and MBS values are system-defined and cannot be provisioned by the user on the 7210 SAS-R6 IMM-c, 7210 SAS-R12 IMM-c, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T.

The following table lists the default network queue policy definition for the 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T configured in network mode.

The following table lists the default network queue policy definition for the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 configured in network mode.

2.2.3.2. Network queue policies in access-uplink mode

In access-uplink mode of operation, network queue policies are applied at egress of access-uplink ports for 7210 SAS-T devices operating in access-uplink mode. The system allocates 8 (eight) queues for the network port and FCs are mapped to the 8 (eight) queues. All policies uses 8 (eight) queues, like the default network queue policy.

The following queue characteristics can be configured on a per-FC basis:

Network queue policies are identified with a unique policy name, which conforms to the standard 7210 SAS alphanumeric naming conventions. The system default network queue policy is named “default” and cannot be edited or deleted. CBS values cannot be provisioned. The following table lists the default network queue policy definition in access-uplink mode.

2.2.4.1. CAM-based classification

When using CAM-based classification on 7210 SAS devices, at SAP ingress users have an option to use either MAC criteria or IP criteria, or both IPv4 and MAC criteria to allow users to use the available CAM classification resources effectively.

The following options are available:

Among the preceding supported criteria, the following can be configured in a single policy:

Note: When specifying both MAC and IP criteria in a SAP ingress policy, only an IPv6 DSCP match is allowed. Other IPv6 fields, such as src-address and dst-address, are not allowed.

In addition to the preceding list of classification rules, the user can set the DEI bit for identifying the ingress profile and enabling color-aware policing. See Discard eligibility indicator-based (DEI-based) classification and marking and Service ingress QoS policies for more information. The packet fields that can be used as match criteria for SAP ingress classification are described in Table 19 and Table 20.

Note: To determine the resource allocation required for each of these different criteria, see Service ingress QoS policies.

The IP and MAC match criteria can be very basic or quite detailed. IP and MAC match criteria are constructed using policy entries. An entry is identified by a unique, numerical entry ID. A single entry cannot contain more than one match value for each match criteria. Each match entry has an action that specifies the FC of packets that match the entry.

The entries are evaluated in numerical order based on the entry ID, from the lowest to highest ID value. The first entry that matches all match criteria has its action performed.

The following table lists the MAC match criteria that can be used for an Ethernet frame, which depends on the frame format.

The following table lists the criteria that can be matched for the various MAC frame types.

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, no queues are defined. All traffic is mapped to the default FC, which uses one meter by default. The following table lists the characteristics of the default policy.

When using CAM-based classification and policing, available ingress CAM hardware resources can be allocated as needed, for use with different QoS classification match criteria. By default, the system allocates a single meter and 2 classification entries, so that all traffic is mapped to a single FC and the FC uses a single meter. Users can modify the resource allocation based on the need to scale the number of entries or the 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 criterion used in the policy, the association of that policy to a SAP fails. Allocation of classification entries also allocates meter resources, which are used to implement the per-FC per-traffic type policing function. See Resource allocation for service ingress QoS policies using CAM-based classification for information about resource usage and allocation to SAP ingress policies.

2.2.4.2. Table-based classification

The 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 provide an option to use table-based classification using either IP DSCP or dot1p classification to assign both an FC and profile on SAP ingress for use with color-aware meters. See Table-based classification using dot1p and IP DSCP for assigning FC and profile on SAP ingress for the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 for more information.

2.2.4.3. Hierarchical ingress policing

Hierarchical ingress policing allows users to specify the amount of traffic admitted into the system per SAP. It also allows users to share the available bandwidth per SAP among the different FCs of the SAP. For example, users can allow 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 per SAP on SAP ingress. Users should configure the PIR and, optionally, the burst size of the aggregate policer.

The aggregate policer monitors the traffic on different FCs and determines whether the packet is forwarded to an identified profile or dropped. The final behavior of the packet is based on the operating rate of the following items:

Refer to the command description of aggregate-meter-rate command in the 7210 SAS-Mxp, S, Sx, T Services Guide for information about the final color assigned of the packet.

The meter mode “trtcm2” (RFC 4115) 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” (formerly “trtcm”, as per RFC 2698) are used in the absence of an aggregate meter.

Note: Before using a per-SAP aggregate meter/policer, meter resources must be allocated using the config system resource-profile ingress-internal-tcam sap-aggregate-meter command.When the amount of resources allocated for a SAP aggregate meter is changed, the node must be rebooted. The amount of resources allocated for this feature determines the number of SAPs that can use the aggregate meter/policer. Refer to the “System Resource Allocation” section of the 7210 SAS-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information.

2.4.2.1. Access egress QoS policy for SAP-based queuing mode on 7210 SAS-Mxp

When SAP-based egress queues are in use, 7210 SAS-Mxp supports SAP-based marking for access SAPs and port-based egress marking on access ports. SAP-based marking is only supported for Layer 2 SAPs (configured in Epipe and VPLS services).

If the user enables remarking in the SAP egress policy attached to the SAP, the remark policy configured is used to mark the packets sent out of the SAP. If remarking is disabled in the SAP egress policy attached to the SAP, the remark policy configured under the access egress policy associated with the egress access port is used to mark all packets sent out of the Layer 2 SAP configured on the access port. This is known as port-based marking. Port-based marking is supported primarily for Layer 3 SAPs (configured in VPRN and IES services). SAP-based marking is not supported for Layer 3 SAPs.

On 7210 SAS-Mxp, no explicit CLI command is provided to choose between port-based marking and SAP-based marking for Layer 2 SAPs. Choose SAP-based marking by enabling remarking in the SAP egress policy attached to the Layer 2 SAP or choose port-based marking by disabling remarking in the SAP egress policy attached to the SAP and enabling remarking in the access egress policy associated with the access port on which the Layer 2 SAP is configured.

See Access egress QoS policies for 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 for more information about marking behavior with different remark policy types.

Access egress QoS policy ID 1 is reserved as the default access egress policy. The default policy cannot be deleted or changed. The default access egress policy is applied to all access ports which do not have another access egress policy explicitly assigned. By default sap-qos-marking is enabled.

2.4.2.2. Access egress QoS policy for port-based queuing mode on 7210 SAS-Mxp

On 7210 SAS-Mxp, when port-based queues are enabled, in addition to marking values, the access egress QoS policy provides an option to define port-based queues and scheduling.

When port-scheduler-mode is enabled, the software uses 8 (eight) egress queues per access port or hybrid port and all the SAPs configured on the port share the 8 (eight) egress queues for traffic sent out of that port. When port-scheduler-mode is enabled, the queue parameters for the access port egress queues are defined using the access egress policies.

Individual queue parameters for a specific queue can be modified using the queue override feature. See Queue overrides for access egress QoS policies on the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 for more information.

Additionally, the marking values used to mark traffic from different FCs are defined by the remark policy in the access egress policy. Per-SAP marking cannot be used when port-based queuing mode is used. See Access egress QoS policies for 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 for more information about marking behavior with different remark policy types.

On 7210 SAS-Mxp, access egress QoS policies define egress queues and map FC flows to queues, if port-scheduler-mode is enabled. In port-scheduler-mode, the system allocates 8 (eight) queues to access port egress by default. To define a basic access egress QoS policy, the following are required:

Optional service egress QoS policy elements include specifying a remark policy that defines IEEE 802.1p priority value remarking based on the FC.

On 7210 SAS-Mxp, when port-based queuing is used, the FC-to-queue map is fixed and the queue priority is determined by the queue number, with the higher queue number having the higher priority. The user can configure a queue to be a strict queue to change the scheduling behavior for that queue. See Schedulers on 7210 SAS-Mxp for more information about scheduling.

2.4.3.1. Access egress QoS policies for SAP-based queuing mode

Note: The SAP-based queuing mode is supported only on the 7210 SAS-R6 IMM-b and 7210 SAS-R12 IMM-b. It is not supported on the 7210 SAS-R6 IMM-c and 7210 SAS-R12 IMM-c.

The 7210 SAS-R6 and 7210 SAS-R12 support SAP-based marking for access SAPs and port-based egress marking on access ports. SAP-based marking is only supported for L2 SAPs, which are SAPs configured in Epipe and VPLS services. If users enable remarking in the SAP-egress policy attached to the SAP, the configured remark policy is used to mark the packets sent out of the SAP. If remarking is disabled in the SAP-egress policy attached to the SAP, the remark policy configured under the access egress policy associated with the egress-access port is used to mark all packets sent out of the L2 SAP configured on the access port. This is known as port-based marking.

Port-based marking is supported primarily for L3 SAPs (that is, SAPs configured in VPRN services and IES services). SAP-based marking is not supported for L3 SAPs.

No explicit CLI command is provided to choose between port-based marking and SAP-based marking for L2 SAPs. The user can choose SAP-based marking by enabling remarking in the SAP-egress policy attached to the L2 SAP, or port-based marking by disabling remarking in the SAP egress policy attached to the SAP and enabling remarking in the access egress policy associated with the access port where the L2 SAP is configured.

See Access egress QoS policies for 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 for more information about marking behavior with different remark policy types.

2.4.3.2. Access egress QoS policy for port-based queuing mode

Note: The port-based queuing mode is supported on IMM-b and IMM-c cards. On IMM-c cards, it is the default and the only supported queuing mode.

When port-based queues are enabled in addition to marking values, the access egress QoS policy provides an option to define port-based queues and scheduling.

Users have an option to use either port-based egress queuing and shaping or SAP-based egress queuing and shaping for SAPs configured on access ports or hybrid ports. The config system global-resource-profile qos port-scheduler-mode command allows users to select the mode used for SAPs configured on all the ports of the node (this is a per-node setting). When port-scheduler-mode is enabled, the software uses eight egress queues per access port, and all the SAPs configured on the port share the eight egress queues for traffic sent out of that port.

When port-scheduler-mode is enabled, the queue parameters for the access port egress queues are defined using the access egress policies.

Modify queue parameters for a specific queue using the queue override feature. See QoS overrides for meters/policers for more information.

Additionally, the marking values used to mark traffic from different FCs are defined by the remark policy in the access egress policy. Per-SAP marking cannot be used when port-based queuing mode is used. See Access egress QoS policies for 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 for more information about marking behavior with different remark policy types.

Access egress QoS policies define egress queues and map FC flows to queues, if port-scheduler-mode is enabled. Using port-scheduler-mode, the system allocates eight queues to access port egress by default. To define a basic access egress QoS policy, the following are required:

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

Optional service egress QoS policy elements include the following:

When port-based queuing is used, the FC-to-queue map is fixed and the queue priority is determined by the queue number, with higher queue numbers having the higher priority. The user can configure a queue to be a strict queue to change the scheduling behavior for the queue.

Access egress QoS policy ID 1 is reserved as the default access egress policy. The default policy cannot be deleted or changed. The default access egress policy is applied to all access ports that do not have another access egress policy explicitly assigned. By default, sap-qos-marking is enabled. Table 27 and Table 28 list the characteristics of the default policy.

The marking values used to mark traffic from different FCs are defined by the remark policy in the access egress policy. The following table lists the remarking policy for type dot1p for 7210 SAS-R6 and 7210 SAS-R12.

2.4.4.1. Configuring access egress QoS policy queue override parameters

Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide for CLI command descriptions of the queue override parameters.

The following is a sample queue override parameter configuration output.

2.8.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 where the meter is defined.

2.8.1.2. Committed information rate for meters

The committed information rate (CIR) for a meter is the long term average rate at which traffic is considered as conforming traffic or in-profile traffic. The higher the rate, the greater the expected throughput. The user is able to burst above the CIR and up to PIR for brief periods of time. The time and profile of the packet is decided based on the burst sizes, as explained in the following sections.

When defining the CIR for a meter, the value specified is the administrative CIR for the meter. The 7210 SAS devices have a number of native rates in hardware that are used to 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 the interpretation of the administrative CIR in Adaptation rule for meters.

The CIR for meters is provisioned on service ingress and network ingress within service ingress QoS policies and network QoS policies, respectively.

2.8.1.3. Peak information rate for meters

The peak information rate (PIR) defines the maximum rate at which packets are allowed to exit the meter. It does not specify the maximum rate at which packets may enter the meter; this is determined 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 native rates in hardware that are used to 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. Refer to the interpretation of the administrative PIR in Adaptation rule for meters.

The PIR for meters is provisioned on service ingress and access uplink ports or network port ingress within service ingress QoS policies and network QoS policies, respectively.

2.8.1.4. Color-aware and color-blind policers

The 7210 SAS devices support color-aware policing at network ingress, whereas at service ingress a policing option is provided to use either color-aware policing or color-blind policing. In color-aware policing, users can define the color of the packet using the classification and send the colored packets to the meter. A color-aware meter treats the packets according to the color defined:

The profile marked by the meter is used to determine the eligibility of the packet to be enqueued into a buffer at egress (that is, when a slope policy is configured at the egress).

In color-blind mode, the profile (color) assigned to the packet on ingress is ignored. The CIR and PIR rates configured for the meter determine the final profile (color) for the packet. If the packet is within the CIR, the final profile (color) assigned to the packet is in-profile (green). If the packet exceeds the CIR and is within the PIR, the final profile (color) assigned to the packet is out-of-profile (yellow). Packets that exceed the PIR rate (red) are dropped.

In color-aware mode, the meter uses the profile assigned to the packet on ingress. The profile can be assigned on ingress either by enabling DEI classification as done on access ports or by assigning profile based on either dot1p or DEI as done on network ports and access-uplink ports. On the 7210 SAS-Mxp, 7210 SAS-R6 and 7210 SAS-R12, the profile can also be assigned on service (or SAP) ingress by using a DSCP classification policy to set FC and profile. See Table-based classification using dot1p and IP DSCP for assigning FC and profile on SAP ingress for the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 for more information about table-based classification.

2.8.1.5. 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 as a result of hardware capabilities.

The following table lists the hardware rate step-size for the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-T.

The following table lists the hardware rate step-size for the 7210 SAS-Sx 10/100GE.

The system attempts to find the best operational rate depending on the defined constraint. The supported constraints are the following:

The following table lists the rate values configured in the hardware when different PIR or CIR rates are specified in the CLI.

If the user has configured any value greater than 0 and less than 648, the operation rate configured on hardware is 648 kbps, regardless of the constraint used.

Note: The configured burst size 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, the system uses a rate step size of 16 Kbits and a burst step size of 8192 bits (see Table 32, 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.

2.8.1.6. Committed burst size (for meter/policers)

The committed burst size (CBS) 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.

The operational CBS set by the system is adapted from the user configured value by using the minimum constraint.

Note: See Table 32 for information about the burst parameter step-size.

2.8.1.7. Maximum burst size (for meter/policers)

For trTCM, the maximum burst size parameter specifies the maximum burst size that can be transmitted by the source at the PIR while complying with the PIR. If the transmitted burst is lower than the MBS value, the packets are marked as out-profile by the meter to indicate that the traffic is not complying with CIR, but complying with PIR.

For srTCM, the maximum burst size parameter specifies the maximum burst size that can be transmitted by the source while not complying with the CIR. If the transmitted burst is lower than the MBS value, 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 that are marked as red are dropped.

The operational MBS set by the system is adapted from the user-configured value by using the minimum constraint.

Note: See Table 32 for information about the burst parameter step-size.

2.8.1.8. Meter counters

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

2.8.1.9. Meter modes

The 7210 SAS devices support the following meter modes:

In srtcm, the CBS and MBS token buckets are replenished at single rate, that is, CIR. Whereas in the case of trtcm, CBS and MBS buckets are individually replenished at CIR and PIR rates, respectively. trtcm1 implements the policing algorithm defined in RFC 2698, and trtcm2 implements the policing algorithm defined in RFC 4115.

2.8.1.10. QoS overrides for meters/policers

Support for the QoS override feature on an access SAP allows the user to override the meter parameters, such as CBS, MBS, rate (CIR and PIR), mode, and adaptation rule (CIR and PIR) at the SAP context.

When meter parameter values are not overridden, the values are taken from the SAP ingress policy. That is, QoS override is not used.

Meter override commands are supported on all types of access SAP.

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 where the queue is defined. On the 7210 SAS, the queue ID is not a user configurable entity, but the queue ID is statically assigned to the 8 queues on the port according to the FC-QID map listed in Table 29.

2.9.1.2. CIR for queues

The CIR for a queue performs the following distinct functions:

Queues at the egress never mark the packets as in-profile or out-profile based on the queue CIR and PIR values. The in-profile and out-profile state of the queue interacts with the scheduler mechanism and provides the minimum and maximum bandwidth guarantees.

When defining the CIR for a queue, the value specified is the administrative CIR for the queue. The user has some control over how the administrative CIR is converted to an operational CIR 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. A access egress queue associated with the high-priority class normally has the CIR threshold equal to the PIR rate, although the 7210 SAS allows the CIR to be provisioned to any rate below the PIR if this behavior is required.

The CIR for a queue is provisioned in the appropriate queue policy associated with the service object (that is, a network or hybrid port, or an access SAP, as applicable).

2.9.1.3. PIR for queues

The 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 determined 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 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 if the hardware does not support the exact CIR and PIR values specified. See Adaptation rule for queues for information about the interpretation of the administrative PIR.

The PIR for a queue is provisioned in the appropriate queue policy associated with the service object (that is, a network, hybrid, or access port, or and access SAP, as applicable).

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 where the queue is created 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 as a result of hardware implementation trade-offs.

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:

Depending on the hardware on which 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 7210 SAS uses a single rate step value to define the granularity for both the CIR and PIR rates. The adaptation rule controls the method the system uses to choose the rate step based on the administrative rates defined by the rate command.

Table 35 lists the supported hardware rate steps that correspond to the CIR and PIR ranges between 0 and 1 Gb/s on 7210 SAS-T and 7210 SAS-Sx/S 1/10GE devices. Table 36 lists the supported hardware rate steps that correspond to the CIR and PIR range values between 0 to 1 Gb/s for the 7210 SAS-Mxp. Table 37 lists the supported hardware rate steps that correspond to the CIR and PIR range values between 0 to 1 Gb/s for the 7210 SAS-R6 and 7210 SAS-R12. Table 38 lists the supported hardware rate steps that correspond to the CIR and PIR ranges between 0 to 10 Gbps on 10-Gig ports on all platforms. Table 39 lists the supported hardware rate steps that correspond to the CIR and PIR range values between 0 to 1 Gb/s for the 7210 SAS-Sx 10/100GE.

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 Kbps and 150 Kbps, respectively.

If the adaptation rule is minimum, the operational CIR and PIR values are 96 Kbps and 152 Kbps respectively, as the native hardware rate is greater than or equal to the administrative CIR and PIR values.

If the adaptation rule is maximum, the operational CIR and PIR values are 88 Kbps and 144 Kbps.

If the adaptation rule is closest, the operational CIR and PIR values are 88 Kbps and 152 Kbps, respectively, as those are the closest matches for the administrative values that are even multiples of the 8 Kbps rate step.

2.9.1.5. CBS and MBS for queues

The CBS and MBS parameters configure the amount of buffers that a queue can use. The CBS parameter specifies the amount of buffer reserved for a queue in the queue buffer pool. The MBS parameter specifies the portion that a queue can contend for in the shared buffer space. When all reserved buffers for a specific queue are used, the queue contends with other queues for additional buffer resources up to the configured MBS.

On the 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T, the CBS parameter for queues is not configurable for access, network, and access-uplink ports. The CBS is set to system-defined values.

On 7210 SAS-Mxp, and 7210 SAS-R6 and 7210 SAS-R12 equipped with IMM-b cards, the CBS and MBS values for the queues are configurable for the service egress and network port queues. The CBS and MBS is set to default values that address the specific FC needs to maintain differential treatment.

On the 7210 SAS-T (network and access-uplink mode), the node can be operated with either a per-port or per-node MBS pool. The decommissioning feature is supported in the per-port MBS pool mode, which increases the per-port MBS pool by taking away packet buffers from other ports. In this case, the maximum MBS per queue, assuming no other queue has 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 93 Kbytes. The show pools port-id network-egress, show pools port-id access-egress, and show pools port-id access-uplink-egress CLI commands display the values in use depending on the port mode (network, access, and access-uplink).

The following table lists the default CBS and MBS values for the 7210 SAS platforms.

2.9.2.1. Buffer pools on 7210 SAS-T

The 7210 SAS devices, when operating in network mode and access-uplink mode, support either one or both of the two modes of buffer pool allocation for port egress queues - per port MBS pool and per node MBS pool. The buffer pools take care of the buffer requirements at the port level for various queue shaping/ scheduling mechanisms. In addition, in per port MBS pool mode, an option is provided to decommission the port and allocate its buffers towards other ports. The following sections provides more information about these two modes.

2.9.2.1.2. Buffer pool allocation - per node MBS pool (7210 SAS-T)

In the per node MBS pool mode, each of the queue on a port, is allocated a CBS amount of committed buffers. The remaining amount of buffers is allocated towards the MBS pool that is available for sharing among all the queues across all the ports of the node. The queue’s CBS portion of buffers guarantees that the queue does not starve due to lack of buffers.

The buffers allocated towards the node’s MBS pool, allows each port to handle some amount of burst. Per port MBS pool of buffers is shared by all the queues of the port and allows any queue or a group of queues across multiple ports to absorb larger bursts, assuming that not all the queues on all the ports receive burst simultaneously. In a typical network, the router/switch in the ingress traffic is usually a mix of packets of different sizes and different flows burst at different time intervals, which allows for better burst absorption capability per queue using shared resources.

The hardware implements an algorithm to handle requests for allocation of buffers from the MBS pool (in both models) assuming that not all the ports and queues burst at the same time. This allows some queues to utilize a larger portion of the buffers when it is available, allowing them to handle larger bursts. At the same time, the algorithm ensures that all the queues get fair share of the buffers, so that the throughput on those ports is not affected.

When hardware receives a packet, before it decides to queue up the packet on the egress queue of the destination port, it determines the discard threshold for the queue based on the oversubscription factor and the total amount of free buffers available at that point of time.

The queue’s discard threshold is higher if the amount of free buffers available is larger (which indicates other queues on the node have lesser congestion), allowing the queue to absorb larger bursts. The queue’s discard threshold is lower if there are fewer free buffers available (which indicates that other queues are heavily congested on the node), which results in the packet being dropped. At the same time, algorithm allocates the available free buffers to queues which are using lesser amount of buffers or not using any buffers. This allows equal sharing of available buffers and maintains a good throughput for less congested queues.

On 7210 SAS-T (in both access-uplink and network mode), 2MB of buffers are available and by default per node MBS pool is used and an option is available to user to change it to per port MBS pool.

Note: On the 7210 SAS-T (network mode and access-uplink mode) with either a per-port MBS pool or a per-node MBS pool, system internal ports — such as an internal loopback port used for mirroring, port loopback with mac-swap, and others — are allocated buffers. Some buffers are reserved for internal use. Buffer pools cannot be created or deleted on the 7210 SAS.

2.9.2.2. Decommissioning ports with per port MBS pool

To allow operators better control over which ports get larger portion of queue buffers, the operator is provided with an option to use per-port MBS pool 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-T devices

Note: Using the decommission command for buffer allocation is only supported on the 7210 SAS-T. This feature is not supported on the 7210 SAS-Mxp.

This feature enables the user to make efficient use of the available port egress queue buffer pool by allocating queue buffers of the unused ports to ports. Services cannot be configured on the unused ports as software takes away all the queue buffer resources from these ports that need increased amount of buffers to handle larger bursts. This allows the operators who use limited number of ports to deploy services, to increase the amount of queue buffers allocated to them by decommissioning ports that are not used to deploy services.

The amount of credit of queue buffers received by a port is used to increase the MBS portion of the buffer pool of the port. This allows any queue on the port to use the buffers, if needed. The CBS portion of the queue is not modified with this feature.

Note: The system has to be rebooted after decommissioning of ports for the queue buffers to be reallocated and the configuration to take effect.

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 5 fiber ports and allocate the freed up queue buffers to the 10G XFP ports, and so on. This mechanism allows the operators to provide higher amount of queue buffers to a specific port or a group of ports, allowing them to pick and choose ports that need the extra buffers for burst absorption.

The user is allowed to increase the per port MBS pool limit so that more buffers are available to absorb larger bursts, at the cost of decommissioning ports which are not used to configure services.

2.9.2.2.2. Configuration guidelines for use of decommission commands on 7210 SAS-T devices

The configure system resource-profile decommission entry CLI 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 8 (eight) queues on the port) and the CBS portion of the queues are not modified.

The user can modify the list of ports or update to the list of ports specified with the decommission command (and also entry command) when the node is up.

The software maintains two lists of entries, one is the current list of ports and another which has been modified by the user and takes effect only after the next reboot. These lists can be displayed using the show command. The configuration file always stores the list of entries as configured by the user, so that when rebooted the modified entries and new entries (if any) takes effect.

A port must be in administrative down (shutdown) state before it is in a decommission entry. An attempt to configure a port which is administratively up (no shutdown) state results in an error. The administrative state or the operational state of the port is not affected by configuring the port in a decommission entry.

The decommissioned port cannot be used in any service configuration or as a loopback port. An attempt to do so results in an error.

The decommissioned port must not be configured with BOF parameter, ‘no-service-ports’.

Buffer allocation to a port should is possible for access ports, network ports or hybrid ports. In other words, irrespective of port mode, it is possible to assign more buffer resources to the port.

The user needs to ensure that enough buffers are available for the internal loopback ports or front-panel ports assigned for loopback. It is not recommended to take away buffers allocated to these ports and assign it to other ports. This might cause unintended behavior of the system. The system software does not check for this, but expects users to ensure this through proper configuration.

During system boot up, while executing the commands in the configuration file software checks if the no-service-ports are configured under the decommission entries. If there is match, software throws an error and stops execution of further commands in the configuration file. When this happens, user needs to correct the configuration file or the BOF file, to either remove the ports from the decommission entries or not configure them as no-service-ports in the BOF, save the BOF file or the configuration file based on where the change was made and reboot the node.

On 7210 SAS-T, the decommission command takes affect only if the per port MBS pool is in use, that is, the user needs to configure the configure system resource-profile qos mbs-pool port CLI command, before using the decommission port feature.

The following configuration sample shows the ports to be decommissioned and the ports that need more buffers.

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

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

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

entry 23 port 1/1/5 to 1/1/3

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

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

Note: Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information about the decommission commands.

2.9.2.3. Buffer pools on 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE

The 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE has 4MB of packets buffers and it supports only a single mode of operation, per node MBS pool, in this release. In this mode, the MBS pool is shared across all queues on all ports. In the per node MBS pool mode, each of the 16 egress queues available on a port, is allocated a CBS amount of committed buffers. The remaining amount of buffers is allocated towards the per node MBS pool that is available for sharing among all the queues across all the ports of the node.

Note: The system internal ports, such as internal loopback ports used for mirroring, port loopback with mac-swap, and others, are allocated with some buffers. Some buffers are reserved for system internal use (for example, CPU queues).

The amount of buffers remaining after allocating buffers for system internal use is available for allocation towards MBS buffers for all egress queues and per node MBS pool.

The hardware implements an algorithm to handle requests for allocation of buffers from the MBS pool assuming that not all the ports and queues burst at the same time. This allows some queues to utilize a larger portion of the buffers when it is available, allowing them to handle larger bursts. At the same time, the algorithm ensures that all the queues get fair share of the buffers, so that the throughput on those ports are not affected. When the hardware receives a packet, before it decides to queue up the packet on the egress queue of the destination port, it determines the discard threshold for the queue based on the oversubscription factor and the total amount of free buffers available at that point of time.

The queue’s discard threshold is higher, if the amount of free buffers available is larger (which indicates other queues on the node have lesser congestion), allowing the queue to absorb larger bursts. The queue’s discard threshold is lower, if there is lesser amount of free buffers available (which indicates that other queues are heavily congested on the node), which results in the packet being dropped. At the same time, algorithm allocates the available free buffers to queues which are using lesser amount of buffers or not using any buffers. This allows equal sharing of available buffers and maintains a good throughput for less congested queues.

Note: The 7210 SAS-Sx/S 1/10GE does not support per-port MBS pool mode and port decommissioning features in this release. Buffer pools cannot be created or deleted on the 7210 SAS.

2.9.2.4. Buffer pools on 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12

The 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 have a single buffer pool per node, the system pool. All the queues created by the system are allocated buffers from this system pool. Queues come up with default buffers, and the buffers change accordingly when they are associated with a network port or SAP. Queue management policies allow the user to specify the parameters that determine buffer allocation to the queues. Buffer pools cannot be created or deleted in the 7210 SAS.

2.9.3.1. Queue management policy parameters

The elements required to define a queue management policy are:

Queue management policy ID default is reserved for the default queue management policy. The default policy cannot be deleted or changed. The default policy is implicitly applied to all queues that do not have another queue management policy explicitly assigned. The following table lists the default values for the default slope policy.

See Table 40 for the default CBS and MBS queues on the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12.

2.9.4.1. Tuning the shared buffer utilization calculation

The 7210 SAS allows tuning the calculation of the Shared Buffer Average Utilization (SBAU) after assigning buffers for a packet entering a queue as used by the RED slopes to calculate a packet’s drop probability. It implements a time average factor (TAF) parameter in the buffer policy which determines the contribution of the historical shared buffer utilization and the instantaneous Shared Buffer Utilization (SBU) in calculating the SBAU. The TAF defines a weighting exponent used to determine the portion of the shared buffer instantaneous utilization and the previous shared buffer average utilization used to calculate the new shared buffer average utilization. To derive the new shared buffer average utilization, the buffer pool takes a portion of the previous shared buffer average and adds it to the inverse portion of the instantaneous shared buffer utilization (SBU). The formula used to calculated the average shared buffer utilization is shown in the following figure.

Figure 5:  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

The following table 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).

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.2. Slope policies for 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE devices

Note: On 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12, queue management policies are used to configure the WRED slopes. See Queue management policies for 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 for more information.

Slope policies define the RED slope characteristics as a percentage of the size of the queue on which the policy is applied when the per-port MBS pool configuration is used. When per node MBS pool is in use, the slope parameters are interpreted as a percentage of the logical size for the queue and is not a percentage of the total MBS pool size.

On 7210 SAS-T (network mode and access-uplink mode), default buffer pools exist (logically) at the port levels, when configured to use per port MBS pool and is dependent on the physical port mode:

By default, each queue on the port is associated with slope-policy default which disables the high-slope, low-slope, and non-TCP slope within the pool.

On the 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 1/10GE and 7210 SAS-Sx 10/100GE configured in standalone and standalone-VC mode, default buffer pools exist (logically) at the port levels and is dependent on the port mode:

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

Note: If WRED is not configured, taildrop is used.