10. Service Egress QoS Policies

This chapter provides information to configure service egress QoS policies using the CLI.

10.1. Overview

The service-egress policy defines the Service Level Agreement (SLA) for service packets as they egress on a SAP configured on either an access port or a hybrid port. Service-egress QoS policies allow the definition of queue parameters along with a remark policy.

With the default service egress policy, the system allocates one queue. The eight FCs are mapped to use the same queue. The user has the option to define up to eight queues per policy and define the FC-to-queue mapping. In addition, the policy allows the user to define the queue parameters. The hardware does not support a linear range of values for the rate parameters (CIR and PIR). The user can specify the computation method of rates to match the rates supported by the hardware, through the configuration of adaptation rules.

The SAP egress policy for access SAPs supports the following:

  1. per-SAP egress queuing and shaping, hierarchical shaping on SAP egress (with three levels of shaping) with a per-FC/queue shaper, per-SAP aggregate shaper and per-port egress rate shaper
  2. SAP egress queues, shaping, and scheduling
    1. on the 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T, hardware queues are allocated in groups of two, and on the 7210 SAS-K 3SFP+ 8C, hardware queues are allocated in groups of four; these grouped queues are reserved for use by the SAP even if the user specifies an odd value. The 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T support two, four, six, or eight queues per SAP. The 7210 SAS-K 3SFP+ 8C supports four or eight queues per SAP.
    2. provides an option to configure the FC-to-queue map, allowing the user to assign the packets classified into a particular FC to any of the queues configured for the SAP
    3. on SAP egress, only a single queue can be configured per FC and all traffic (unicast and BUM) share the single queue
    4. allows configuration of queue shaper rate (CIR/PIR), CBS and MBS, queue priority and weight. The assigned priority and weight is used to determine the priority and weight of the queue in both the CIR and PIR scheduling loop
    5. allows configuration of WRED slopes (per queue) – high-slope and low-slope. One of the configured WRED slopes is used to allocate buffer to the packet. In-profile packets use the high-slope and out-of-profile packets use the low-slope. The profile of the packet is determined at the ingress (access uplink port ingress or Access SAP ingress) and carried through to be used at SAP egress to determine the WRED slope to apply and also to determine the egress marking value to use (if remarking/marking is enabled)
    6. supports Strict Priority (SP) scheduling and Weighted-Fair Queuing (WFQ) scheduling for SAP egress queues
  3. SAP egress remarking/marking
    1. dot1p and/or IP DSCP marking must be supported on access SAP egress. Configuration of per FC dot1p and/or IP DSCP marking is supported, with the capability to assign different dot1p and/or IP DSCP values for in-profile and out-of-profile packets. In addition, support for marking DEI value is available.

The following is a sample configuration output showing the default access SAP egress QoS.

*A:SAH01-071>config>qos>sap-egress# info detail 
----------------------------------------------
            description "Default SAP egress QoS policy."
            scope template
            no remarking 
            remark 1
            queue 1 create
                adaptation-rule cir closest pir closest
                rate cir 0 pir max
                mbs 60
                cbs 10
                slope-policy "default"
                priority 1
                weight 1
            exit
            fc af create
                queue 1
            exit 
            fc be create
                queue 1
            exit 
            fc ef create
                queue 1
            exit       
            fc h1 create
                queue 1
            exit 
            fc h2 create
                queue 1
            exit 
            fc l1 create
                queue 1
            exit 
            fc l2 create
                queue 1
            exit 
            fc nc create
                queue 1
            exit 

10.1.1. Egress SAP FC and Profile Overrides

The FC of an access egress packet can be changed to redirect the packet to an alternate queue than the ingress FC determination would have used. The profile of an access egress packet can also be changed to modify the congestion behavior within the egress queue. In both cases, egress marking decisions will be based on the new FC and profile, instead of the FC or profile determined at ingress.

The SAP egress QoS policy supports the use of reclassification rules to override the ingress FC and profile of packets that egress a SAP where the QoS policy is applied.

dot1p, IP precedence, and DSCP entries can be defined, each with an explicit FC or profile override parameters. The reclassification logic for each entry follows the same basic hierarchical behavior as the classification rules within the SAP ingress QoS policy. IP DSCP entries have the highest match priority, followed by IP precedence and dot1p.

If the IP precedence values overlap with DSCP values by matching the same IP header TOC field, the DSCP entry parameters override or remove the IP precedence parameters. When none of the matched entries override a parameter, the ingress classification is preserved; that is, the FC and profile assigned by SAP/network ingress classification rules is carried over and used at egress.

Note:

The egress queue shaper does not reassign the profile for the packet. By default, the profile is assigned a value of undefined at access SAP egress when the profile is not defined explicitly by the user in the service egress policy reclassification entry. A value of undefined specifies that the profile assigned at ingress will be carried over. Therefore, the user can use egress reclassification to assign only an FC without specifying a profile. The profile assigned at ingress by either the ingress classification entry or the ingress shaper is carried over. The egress classification entry modifies the profile only if the user explicitly configures the profile as in or out.

This capability is supported on access SAP egress for all services.

10.1.2. Configuration Guidelines for Access SAP Egress Policies

This section provides a list of configuration guidelines for access SAP egress policies.

Note:

This section applies to SAPs configured on access ports and hybrid ports.

The configuration guidelines for access SAP egress policies are the following.

  1. On the 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T, hardware queues are allocated in groups of two, and on the 7210 SAS-K 3SFP+ 8C, hardware queues are allocated in groups of four; these grouped queues are reserved for use by the SAP even if the user specifies an odd value. The 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T support two, four, six, or eight queues per SAP. The 7210 SAS-K 3SFP+ 8C supports four or eight queues per SAP.
  2. FC-to-queue map can be defined; this allows the user to assign the packets classified into a particular FC to any one of the queues configured for the SAP.
  3. Both unicast traffic and BUM traffic share a single queue per FC. In other words, unlike service ingress policy, it is not possible to assign different queues for BUM traffic and unicast traffic.
  4. The queue parameters such as queue shaper rate (CIR/PIR), CBS and MBS, queue priority and weight can be defined. The assigned priority and weight is used to determine the priority and weight of the queue in both the CIR and PIR scheduling loop.
  5. WRED slopes (per queue) can be configured: high-slope and low-slope. Depending on the queue mode and the profile assigned to the packet on SAP ingress classification, one of the configured WRED slopes is used to evaluate if a buffer can be allocated to the packet. In-profile packets use the high-slope and out-of-profile packets use the low-slope.
  6. SP scheduling and WFQ scheduling for SAP ingress queues are supported.

10.1.2.1. Basic Configurations

A basic service egress QoS policy must conform to the following:

  1. have a unique service egress QoS policy ID
  2. have a QoS policy scope of template or exclusive
  3. have at least one FC queue

10.1.2.2. Creating an Access SAP Egress Policy

To create an access SAP egress policy, define the following:

  1. a SAP egress policy name
  2. a brief description of the policy features
  3. the queue parameters for all the queues

Use the following syntax to configure a SAP egress policy.

*A:SAH01-051>config>qos# sap-egress
  - no sap-egress <policy-id>
  - sap-egress <policy-id> [create]
 
 <policy-id>          : [1..65535]|<name:64 char max>
 <create>             : keyword - mandatory while creating an entry.
 
 [no] description     - Description for this sap-egress policy
 [no] fc              + Configure forwarding-class mappings
 [no] queue           + Configure a queue
 [no] remark          - Specify Remarking policy for this policy
 [no] remarking       - Enable/disable remarking
 [no] scope           - Specify scope of the policy
 
*A:SAH01-051>config>qos# info detail
 sap-egress 1 create
            description "Default SAP egress QoS policy."
            scope template
            no remarking
            remark 1
            queue 1 create
                adaptation-rule cir closest pir closest
                rate cir 0 pir max
                mbs 60
                cbs 10
                slope-policy "default"
                priority 1
                weight 1
            exit
            fc af create
                queue 1
            exit
            fc be create
                queue 1
            exit
            fc ef create
                queue 1
            exit
            fc h1 create
                queue 1
            exit
            fc h2 create
                queue 1
            exit
            fc l1 create
                queue 1
            exit
            fc l2 create
                queue 1
            exit
            fc nc create
                queue 1
            exit
        exit
 

10.1.2.3. Editing QoS Policies

Existing policies and entries can be edited through the CLI or NMS. The changes are applied immediately to all services where the policy is applicable.

To prevent configuration errors perform the following.

  1. Copy the policy to a work area.
  2. Edit the policy.
  3. Overwrite the original policy.