2.2.1.1. Network QoS Policy “ip-interface” Type

Network QoS policies (ip-interface type) define ingress FC meters and maps traffic to those meters for IP interfaces. When a network QoS policy is created, it always has two meters defined that cannot be deleted, one for all the unicast traffic and one for all the multipoint traffic. These meters exist within the definition of the policy. The meters only get noticed in the hardware when the policy is applied to an IP interface. It also defines the 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 network policy type ip-interface:

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 type IP interface. The default policy cannot be deleted or changed.

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

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

For network ingress, Table 10 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 type port defines ingress FC meters and maps traffic to those meters for only IP traffic received on network and hybrid ports. When a network policy of this type is created it has a single unicast meter which cannot be deleted. These meters exist within the definition of the policy. The meters get instantiated in hardware, only when the policy is applied to a network port. It also defines the FC to DSCP and/or dot1p marking to be used for packets sent out through that port.

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

The following functions are defined:

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

Optional network QoS policy elements include:

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

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

Table 11 lists the default mapping of FC to dot1p and DSCP values.

Table 12 lists the default mapping of dot1p/DSCP values to FC and profile state for the default network QoS policy of type port, for network ingress. Color-aware policing is supported on network ingress.

2.2.3.1. Network Queue Policies in Network Mode

In 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-M, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE and 7210 SAS-Mxp operating in network mode. The system allocates a fixed number of queues for the network port and FCs are mapped to these queues. All policies uses a fixed number queues like the default network queue policy.

The number of queues allocated for a network queues policy is given below:

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

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

Network queue policies are identified with a unique policy name which conforms to the standard 7210 SAS alphanumeric naming conventions. The system default network queue policy is named default and cannot be edited or deleted. CBS values cannot be provisioned. Table 15 describes the default network queue policy definition 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 on egress of access uplink ports for 7210 SAS-M and 7210 SAS-T devices operating in access uplink mode. The system allocates 8 (eight) queues for the network port and FCs are mapped to these 8 (eight) queues. All policies uses 8 (eight) queues like the default network queue policy.

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

Network queue policies are identified with a unique policy name which conforms to the standard 7210 SAS alphanumeric naming conventions. The system default network queue policy is named default and cannot be edited or deleted. CBS values cannot be provisioned. Table 16 describes 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 above supported criteria the following can be configured together 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 classification rules listed above, the user has an option to use the DEI bit for identifying the ingress profile and enabling color-aware policing. See Discard Eligibility Indicator-based (DEI-based) Classification and Marking. The packet fields that can be used as match criteria for SAP ingress classification are described in Table 17 and Table 18.

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 from policy entries. An entry is identified by a unique, numerical entry ID. A single entry cannot contain more than one match value for each match criteria. Each match entry has an action which specifies the 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 MAC match criteria that can be used for an Ethernet frame depends on the frame format. See Table 19.

Table 20 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 explicitly 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 characteristics of the default policy are listed in Table 21.

When using CAM-based classification and policing, available ingress CAM hardware resources can be allocated as per user needs 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 criteria used in the policy, the association of that policy to a SAP will fail. Allocation of classification entries also allocates meter resources, which are used to implement the per FC per traffic type policing function. Refer to Resource Allocation for Service Ingress QoS Policies Using CAM-based Classification for details on resource usage and allocation to SAP ingress policies.

2.2.4.2. Table-based Classification

The 7210 SAS-Mxp also provides 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 Service Ingress QoS Policies 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 SAP aggregate policer per SAP on SAP ingress. Users should configure the PIR of the aggregate policer. Users can optionally configure 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-M, T, Mxp, Sx, S Services Guide for more information on 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 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 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 in the 7210 SAS-M, T, R6, R12, Mxp, Sx, S 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, that is, SAPs configured in Epipe and VPLS service.

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 (that is, SAPs configured in VPRN services and IES services). In other words, 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. The user can 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.

A remarking policy can be defined for each access egress policy and remarking is disabled by default. Only remarking policy of type dot1p, dot1p-lsp-exp-shared, dscp or dot1p-dscp can be used with access-egress policy. The following is the marking behavior with different remark policy types (see the note below):

Note: On 7210 SAS-Mxp, for Layer 2 SAPs, if remarking is enabled in the SAP egress policy and port-based marking is disabled, the dot1p values configured in the SAP egress policy are used. For Layer 3 SAPs no marking is done. On 7210 SAS-Mxp, for Layer 2 SAPs, if remarking and port-based marking are enabled in the SAP egress policy, the dot1p values configured in the SAP egress policy are used. For Layer 3 SAPs the dot1p and DSCP values configured in the access-egress policy are used. In addition, for Layer 2 SAPs, the DSCP values configured in the access-egress policy are used to mark the IP traffic sent out of Layer 2 SAPs. On 7210 SAS-Mxp, if remarking is disabled for the SAP egress policy and port-based marking is enabled, IP DSCP values are marked, including for the traffic egressing from the Layer 2 SAPs configured on the port. To avoid this, it is recommended to use only FC-to-dot1p values when both Layer 2 and Layer 3 SAPs are configured on the same access port.

Access egress QoS policy ID 1 is reserved as the default access egress policy. The default policy cannot be deleted or changed. The default access egress policy is applied to all access ports which do not have another access egress policy explicitly assigned. By default sap-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, software uses 8 (eight) egress queues per access port or hybrid port and all the SAPs configured on the port will 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 for more information.

Additionally, the marking values used to mark traffic from different FCs is defined by the remark policy in the access egress policy. In other words, per SAP marking cannot be used when port-based queuing mode is used. A remarking policy can be defined for each access egress policy and remarking is disabled by default. Only remarking policy of type dot1p, dot1p-lsp-exp-shared, dscp or dot1p-dscp can be used with access-egress policy. The following list provides the marking behavior with different remark policy types.

Note: When port-scheduler-mode is disabled, per-SAP egress queues are available. Per-SAP egress queues are configured using service egress policies. On the 7210 SAS-Mxp, when port-based queuing mode is enabled, RVPLS SAPs use the port-based egress queues for both unicast and BUM traffic; all the SAPs, including RVPLS SAPs share the eight egress queues created per port. When port-based queues are enabled, SAPs configured on a hybrid port share the egress queues with network port traffic. Packets sent from a SAP on a hybrid port use the marking values, if remarking is enabled, that are defined in the network QoS policy associated with the hybrid port.

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

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

2.4.3.1. Configuring Access Egress QoS Policy Queue Override Parameters

Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S 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 within which 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 throughput user can expect. The user will be able to burst above the CIR and up to PIR for brief periods of time. The time and profile of the packet is decided based on the burst sizes as explained in the following sections.

When defining the CIR for a meter, the value specified is the administrative CIR for the meter. The 7210 SAS devices have a number of native rates in hardware that it uses to determine the operational CIR for the meter. The user has some control over how the administrative CIR is converted to an operational CIR should the hardware not support the exact CIR and PIR combination specified. Refer to the interpretation of the administrative CIR in Adaptation Rule for Meters.

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

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 governed by the meter's ability to absorb bursts and is defined by its maximum burst size (MBS).

When defining the PIR for a meter, the value specified is the administrative PIR for the meter. The 7210 SAS devices have a number of native rates in hardware that it uses to determine the operational PIR for the meter. The user has some control over how the administrative PIR is converted to an operational PIR should the hardware not support the exact CIR and PIR combination specified. Refer to the interpretation of the administrative PIR in Adaptation Rule for Meters.

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

2.8.1.4. Adaptation Rule for Meters

The adaptation rule provides the QoS provisioning system with the ability to adapt the administrative rates provisioned for CIR and PIR, to derive the operational rates based on the underlying capabilities of the hardware. The administrative CIR and PIR rates are translated to actual operational rates enforced by the hardware meter. The rule provides a constraint when the exact rate is not available due to hardware capabilities.

The hardware rate step-size is listed in Table 28.

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

Table 29 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 then the operation rate configured on hardware would be 648 kbps, regardless of the constraint used.

Note: The burst size configured by the user affects the rate step-size used by the system. The system uses the step size so that both the burst-size and rate parameter constraints are met. For example, if the rate specified is less than 4 Gbps but the configured burst size is 17 Mbits, then the system uses a rate step size of 16 Kbits and a burst step size of 8192 bits (see Table 28, row 2). If the meter is a srTCM meter, then both rate and burst constraints specified for both CBS and MBS are considered together to determine the step-size to use for CIR, CBS, and MBS parameters. If the meter is a trTCM1 meter, then the CIR rate and CBS burst parameters are considered together to determine the step-size to use for CIR and CBS parameters, and the PIR rate and MBS burst parameters are considered together to determine the step-size to use for PIR and MBS parameters. If the meter is a trTCM2 meter, then the CIR rate and CBS burst parameters are considered together to determine the step-size to use for CIR and CBS parameters, and the PIR (EIR) rate and MBS (EBS) burst parameters are considered together to determine the step-size to use for PIR (EIR) and MBS (EBS) parameters.

2.8.1.5. Committed Burst Size (for Meter/Policers)

The committed burst size parameter specifies the maximum burst size that can be transmitted by the source at the CIR while still complying with the CIR. If the transmitted burst is lower than the CBS value then the packets are marked as in-profile by the meter to indicate that the traffic is complying meter configured parameters.

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

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

2.8.1.6. Maximum Burst Size (for Meter/Policers)

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

For srTCM, the maximum burst size parameter specifies the maximum burst size that can be transmitted by the source while not complying with the CIR. If the transmitted burst is lower than the MBS value then the packets are marked as out-profile by the meter to indicate that the traffic is not complying with CIR. If the packet burst is higher than MBS then packets are marked as red are dropped.

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

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

2.8.1.7. Meter Counters

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

2.8.1.8. Meter Modes

The 7210 SAS devices supports following meter modes:

In srtcm the CBS and MBS Token buckets are replenished at single rate, that is, CIR where as in case of trtcm CBS and MBS buckets are individually replenished at CIR and PIR rates, respectively. trtcm1 implements the policing algorithm defined in RFC2698 and trtcm2 implements the policing algorithm defined in RFC4115.

2.8.3.1. Configuration Guidelines for QoS Override

The configuration guidelines of QoS override are as follows.

2.8.3.2. Configuring Meter Override Parameters

The following is a sample meter override parameter configuration output.

2.9.1.1. Queue ID

The queue ID is used to uniquely identify the queue. The queue ID is only unique within the context of the QoS policy within which the queue is defined. On 7210 SAS M, the queue ID is not a user configurable entity but the queue ID is statically assigned to the 8 (eight) queues on the port according to FC-QID map table listed in Table 25.

2.9.1.2. Committed Information Rate for Queues

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

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

When defining the CIR for a queue, the value specified is the administrative CIR for the queue. The user has some control over how the administrative CIR is converted to an operational CIR should the hardware not support the exact CIR and PIR combination specified. The interpretation of the administrative CIR is discussed below in Adaptation Rule for Queues.

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

The CIR for a queue is provisioned on egress within access egress QoS policy.

The CIR for the network port queues (for 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Mxp in network mode) and access-uplink port queues (for 7210 SAS-M and 7210 SAS-T in access-uplink mode) are defined within network queue policies based on the FC. The CIR for the network queues is specified as a percentage of the network interface bandwidth.

2.9.1.3. Peak Information Rate for Queues

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

The PIR is provisioned on egress queues within access egress QoS policies.

The PIR for network queues are defined within network queue policies based on the FC. The PIR for the network queues is specified as a percentage of the network interface bandwidth.

When defining the PIR for a queue, the value specified is the administrative PIR for the queue.The user has some control over how the administrative PIR is converted to an operational PIR should the hardware not support the exact CIR and PIR values specified. The interpretation of the administrative PIR is discussed below in Adaptation Rule for Queues.

2.9.1.4. Adaptation Rule for Queues

The adaptation rule provides the QoS provisioning system with the ability to adapt specific CIR and PIR defined administrative rates to the underlying capabilities of the hardware the queue will be created on to derive the operational rates. The administrative CIR and PIR rates are translated to actual operational rates enforced by the hardware queue. The rule provides a constraint used when the exact rate is not available due to hardware implementation trade-offs.

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

Depending on the hardware upon 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 30 lists the supported hardware rate steps that correspond to the CIR and PIR ranges between 0 and 1 Gbps on 7210 SAS-M, 7210 SAS-T, and 7210 SAS-Sx/S 1/10GE Devices. Table 31 lists the supported hardware rate steps that correspond to the CIR and PIR range values between 0 to 1 Gbps for the 7210 SAS-Mxp. Table 32 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.

To illustrate how the adaptation rule constraints minimum, maximum and closest are evaluated in determining the operational CIR or PIR for the 7210 SAS, assume there is a queue where the administrative CIR and PIR values are 90 Kbps and 150 Kbps, respectively.

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

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

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

2.9.1.5. Committed Burst Size (CBS) and the Maximum Burst Size (MBS) for Queues

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

On 7210 SAS-M, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T, CBS for the queues is not configurable entity for the access, network ports and access uplink ports. The CBS value for the queues is set to appropriate default values which takes care of specific FC needs in terms of maintaining the differential treatment.

On 7210 SAS-Mxp, the CBS and MBS for the queues are configurable entities for the service egress queues and network port queues. The CBS and MBS value for the queues is set to appropriate default values which takes care of specific FC needs in terms of maintaining the differential treatment. Table 33 lists the default values.

2.9.2.1. Buffer Pools on 7210 SAS-M and 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-M (in both access-uplink mode and network mode), 4MB of buffers are available and by default per port MBS pool is used. Per node MBS pool of buffers is not supported

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

Note: On the 7210 SAS-M and 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 (like what is available on 7210 SAS-M) and decommission ports. The decommissioning of ports is only allowed when the node is booted with the option to use per-port MBS pool.

With the decommissioning feature, the user is provided with an option to make efficient use of the available port egress queue buffer pool by allocating queue buffers of the unused ports to in-use ports. It allows the user to specify the unused front-panel ports which cannot be used to deploy any services. The software does not allocate any queue buffers to these unused ports and assigns it to a specific port or a group of ports. The user is provided with a CLI command to decommission a port and make it unavailable to deploy services. This mechanism allows operators who use limited number of ports to deploy services, to increase the amount of queue buffers allocated to them by decommissioning ports that will not be used to deploy any services.

2.9.2.2.1. Using Decommission Command for Buffer Allocation on 7210 SAS-M and 7210 SAS-T Devices

Note: Using the decommission command for buffer allocation is only supported on the 7210 SAS-M (all variants: 7210 SAS-M 24F 2XFP (ETR and non-ETR), with or without the CES MDA and the 2x10G MDA) and 7210 SAS-T. On 7210 SAS-M variants that support the 2 x10G MDA, it is possible to decommission the 10G ports on the MDA or to allocate more buffers to the 10G ports on the MDA. This feature is not supported on 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-M and 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, but the changes are effected by software only after a reboot of the 7210 SAS-M node.

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

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

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

The decommissioned port must not be configured with BOF parameter, ‘no-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-M, T, R6, R12, Mxp, Sx, S 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

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

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 which do not have another queue management policy explicitly assigned. Table 34 lists the default values for the default slope policy for the 7210 SAS-Mxp.

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

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

Table 35 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 Policy Parameters

The elements required to define a slope policy are:

All slopes are available per queue and the following parameters are configurable for each slope:

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

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

Table 36 lists the default values for the default slope policy for 7210 SAS-M in network mode. Similarly, Table 37 lists the default values for 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE in network mode.

2.9.4.3. Slope Policies for 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE Devices

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

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

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

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

On 7210 SAS-M (network mode and access-uplink mode) access, network pools (in network mode) and access-uplink pools (in access uplink mode) are created at the port level when per port MBS pool is configured, adn creation is dependent on the physical port mode (network, access, or access uplink).

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