9. Service Ingress QoS Policies
This chapter provides information to configure SAP ingress QoS policies using the command line interface.
9.1. Overview of Service Ingress Policy
There is one default service ingress policy. The default policy allocates a single queue and maps all traffic to the “be” (best-effort) forwarding class. The default policies can be copied and modified but they cannot be deleted. The default policies are identified as policy ID 1. The default policies are applied to the appropriate interface, by default. For example, the default SAP ingress policy is applied to access ingress SAPs. You must explicitly associate other QoS policies. For information about the tasks and commands necessary to access the command line interface and to configure and maintain your 7210 SAS devices, refer to the CLI Usage chapter in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide.
In a service ingress QoS policy, a user can define up to 8 queues or 16 policers/meters per policy, with up to 2 queues or 2 meters per forwarding class. In the case of VPLS service, four types of forwarding are supported (which is not to be confused with forwarding classes): unicast, multicast, broadcast, and unknown. Multicast, broadcast, and unknown types are flooded to all destinations within the service while the unicast forwarding type is handled in a point-to-point fashion within the service. All these traffic types use the same queue or meter (in other words, a separate queue or meter for multicast, broadcast, and unknown unicast traffic types cannot be defined).
Unicast and multipoint traffic can be defined to use the same queue or meter or different queues or meter per forwarding class. In other words, 8 queues and 16 policers are shared by unicast and multicast traffic types and if user allocates a dedicated multicast queue for BUM traffic, the number of queues available for unicast traffic reduces. Similarly, up to 16 meters can be shared by unicast and multicast traffic types.
9.1.1. Configuration Guidelines for SAP Ingress Policy
This section provides a list of configuration guidelines for SAP ingress policies.
- The user has the option to configure a smaller number of ingress queues or ingress policers per SAP.
- 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.
- 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.
- Option is available to use up to 2 queues per FC, with one queue for Unicast traffic and one queue for BUM traffic, with a maximum of 8 queues per access SAP. This option can be used with multipoint service, example – VPLS service. BUM traffic shares a single queue per FC. In other words, it is not possible to use individual queue for each of broadcast, unknown-unicast and multicast traffic. It is possible to define the same queue for unicast and BUM traffic, if the user so desires. For example, user can assign 2 queues per FC, such that unicast traffic uses one of the queues and the BUM traffic uses the other queue. This allows users to have 4 FCs per SAP with 2 queues per FC; OR user can have 7 FCs per SAP with 1 queue per FC and the 8th queue being shared by BUM traffic of all the FCs, OR a mix and match is allowed. If a multicast queue is not assigned to a FC explicitly it uses queue 1 (the default queue of the policy).
- 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.
- Allow configuration of WRED slopes (per queue) – 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.
- Supports Strict priority (SP) scheduling and Weighted-Fair Queuing (WFQ) scheduling for SAP ingress queues. For more information about service ingress scheduling, see the Schedulers.
- Option is available to use up to 2 policers per FC, with one policer for Unicast traffic and one for BUM traffic, with a maximum of up to 16 policers per access SAP. This option can be used with multipoint service, example – VPLS service. BUM traffic shares a single meter per FC. In other words, it is not possible to use individual meter for each of broadcast, unknown-unicast and multicast traffic. It is possible to define the same meter for unicast and BUM traffic, if the user so desires. For example, user can assign 2 meters per FC, such that unicast traffic uses one meter and the BUM traffic uses the other meter. This allows users to have 8 FCs per SAP with 2 meters per FC, OR users can have 8 FCs per SAP with 1 meter per FC and the 8th meter being shared by BUM traffic of all the FCs, OR a mix and match is allowed. If a multicast meter is not assigned to a FC explicitly it uses queue 1 (the default queue of the policy).
- Option is available to use a queue or a meter per FC, with up to 2 queues per FC or 2 meters per FC or a queue and a meter per FC for a maximum of up to 8 queues per access SAP and 16 meters/policers per access SAP. It is allowed to configure queue for Unicast traffic and meter for BUM traffic or vice-versa. This option can be used with multipoint service, example – VPLS service. BUM traffic shares a single meter or queue per FC. In other words, it is not possible to use individual meter or an individual queue for each of broadcast, unknown-unicast and multicast traffic. If a multicast meter is not assigned to a FC explicitly it uses queue 1 (the default queue of the policy).
- The meter parameters such as meter rate (CIR/PIR), CBS and MBS, meter mode (srTCM, trTCM) can be defined.
- If both IP criteria and MAC criteria are configured in SAP ingress QoS classification then they need resources from two different slices. In other words, the MAC and IP criteria entries cannot be located in the same slice/chunk. If resources are not found in two different slices, then the association of the policy fails.
9.1.1.1. Resource Allocation for Service Ingress QoS Classification Policy
The available global pool of ingress internal CAM hardware resources can be allocated as per user needs for use with different features such as SAP ingress QoS policy, ingress ACLs, and so on. SAP ingress QoS can be allocated classification for use from this pool. Resources can be allocated for SAP ingress QoS policy classification IPv4, IPv6, and MAC match criteria, based on the operator needs. Users can modify the resource allocated to scale the number of entries available per match criteria or scale the number of SAPs. The resources from the global ingress internal CAM pool are allocated in chunks with a fixed number of entries.
The number of chunks to be allotted for a SAP ingress QoS policy is specified using the CLI command config>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource.
The user can specify a limit for the amount of resources required for SAP ingress QoS policies and also has the option to limit the amount of resources used per match criteria supported for SAP ingress QoS policies. A given chunk can be used for MAC criteria, IP criteria, and IPv6 criteria.
Before associating SAP ingress policy match criteria with a SAP, resources must be allocated. Until resources are allocated for use, attempts to associate a policy with a SAP fail. When the user allocates resources for use by SAP ingress QoS policies using the CLI command config>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource, the system allocates resources in chunks of 510 entries (192 entries for the 7210 SAS-K 3SFP+ 8C).
The above resources set the maximum limit on the resources available for use by all SAP ingress policies in use simultaneously on the system. The software manages the resource chunks allocated to the SAP ingress QoS policy pool and allocates the entries in the chunks when a SAP ingress QoS policy is associated with a SAP. The software allocates the resources required by a SAP from the chunks depending on whether the SAP ingress policy uses IP criteria, IPv6 criteria, or MAC criteria, and the number of entries configured in the SAP ingress policy.
When the user allocates chunks of resources using the CLI command config>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource, the resources are used only for classification entries configured under IPv4 criteria or MAC criteria.
If the user needs to use IPv6 criteria, resources must be allocated using the CLI command config>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource>mac-ipv4-ipv6-128-match-enable. The resources allocated using this command are used for classification entries configured under IPv6 criteria, IPv4 criteria, or MAC criteria. Each IPv6, IPv4, or MAC classification entry consumes two resources from this pool, reducing the number of classification entries that can be accommodated in a single chunk to 256 (96 entries for the 7210 SAS-K 3SFP+ 8C.) The user can choose to allocate all the chunks allocated for SAP ingress QoS classification for IPv6 criteria or allocate only a portion of it.
The tools>dump>system-resources command displays the current usage and availability of the resources. One or more entries per chunk are reserved for system use.
9.1.1.2. Resource Allocation for SAP Ingress Meters
The FC ingress meter and SAP ingress aggregate meter allocate resources for the common meter resource pool. A single FC ingress meter requires one entry from the pool when the policy is associated with the SAP and a single SAP ingress aggregate meter uses a single entry from the pool when the command to enable SAP aggregate meter functionality is executed under the context of the SAP. An increase in FC ingress meter reduces the number of meters available for SAP ingress aggregate meter. The reverse is also true.
The command tools>dump>system-resources can be used to display the current utilization of the ingress meter resource pool.
9.1.1.3. Default SAP Ingress Policy
The default policy 1 maps all traffic to default forwarding class “be” and maps FC “be” to queue 1. Queue 1 is configured with CIR 0 and PIR max. The following is a sample output of a default SAP ingress policy, and Table 41 lists the default values.
Table 41: SAP Ingress Policy Defaults
Field | Default |
description | “Default SAP ingress QoS policy.” |
scope | template |
queue | 1 |
adaptation-rule | cir closest pir closest |
rate | pir = max, cir= 0 |
cbs | 10KBytes - default |
mbs | 60KBytes - default |
priority | 1 |
weight | 1 |
default-fc | be |
9.1.1.4. Use of Index File by SAP QoS Ingress Policy
The 7210 SAS uses an index file to store the map which indicates the QoS resource allocation to SAPs. This file is used on reboot to ensure that all the SAPs that were created successfully before reboot can be created again on a reboot. Without an index file the system cannot ensure this (that is, without an index file it is possible that all the SAPs that were configured successfully, may fail on a reboot after saving the configuration file). The file is stored in the flash. On reboot if the file is found, the system allocates resources as per the stored map. If the file is not found the system implements a best-fit algorithm and tries to allocate resources for all the SAPs on a first-come-first-served basis. Hence, when the file is not present it is possible that configuration saved, does not execute successfully after the reboot.
 | Note: The following caveats apply:
|
9.2. Basic Configurations
A basic service ingress QoS policy must conform to the following:
- Have a unique service ingress QoS policy ID.
- Have a QoS policy scope of template or exclusive.
- Have at least one default unicast forwarding class queue.
- Use of multipoint forwarding class queue is optional.
- Use of meter for unicast and BUM traffic is optional.
Configuring and applying QoS policies is optional. If no QoS policy is explicitly applied to a SAP, a default QoS policy is applied.
9.2.1. Service Ingress QoS Policies
To create a service ingress policy, define the following:
- A policy ID value. The system will not dynamically assign a value.
- Include a description. The description provides a brief overview of policy features.
- Specify a default forwarding class for the policy. All packets received on an ingress SAP using this ingress QoS policy will be classified to the default forwarding class.
- Define forwarding class parameters.
- Modify the unicast/queue default value to override the default unicast forwarding type queue mapping for fc fc-name.
- Modify the multicast/queue default value to override the default multicast forwarding type queue mapping for fc fc-name.
- Associate a meter for fc fc-name, if desired, for both unicast and BUM traffic types.
- Specify the appropriate classification criteria - IPv4/IPv6 or MAC criteria or both IP and MAC criteria. You can define IPv4/IPv6, MAC-based and MAC and IP based SAP ingress policies to select the appropriate ingress meter and corresponding forwarding class for matched traffic.
- A SAP ingress policy is created with a template scope. The scope can be modified to exclusive for a special one-time use policy. Otherwise, the template scope enables the policy to be applied to multiple SAPs.
The following is a sample service ingress policy configuration output.
9.2.2. Service Ingress QoS Queues
To create service ingress queue parameters, define the following:
- A new Queue ID value — The system will not dynamically assign a value.
- Queue parameters — Rate, Slope-policy, CBS, MBS, Priority, and Weight.A:ALA-7>config>qos# infoecho "QoS Policy Configuration"#--------------------------------------------------sap-ingress 1 createpolicy-name "default"description "Default SAP ingress QoS policy."no ip-mac-matchscope templatequeue 1 createadaptation-rule cir closest pir closestrate cir 0 pir maxslope-policy "default"mbs 60cbs 10priority 1weight 1exit.........#------------------------------------------A:ALA-7>config>qos#
9.2.3. Service Ingress QoS Meters
The following are sample service ingress QoS meters.
9.2.4. SAP Ingress Forwarding Class Configuration
The following is a sample SAP ingress forwarding class configuration output with unicast queues and multicast queues.
The following is a sample SAP ingress forwarding class configuration output with a mix of unicast queues and meters and a mix of multicast queues and meters.
9.2.5. Service Ingress Dot1p and IP DSCP Criteria
The following is a sample configuration output of Dot1p classification policy and IP DSCP classification policy used for ingress classification and its association with SAP ingress policy.
9.2.6. Service Ingress IP Match Criteria
When specifying SAP ingress match criteria, only one match criteria type can be configured in the SAP ingress QoS policy.
The following is a sample ingress IP criteria configuration output.
9.2.7. Service Ingress MAC Match Criteria
To configure service ingress policy MAC criteria, define the following:
- A new entry ID value. Entries must be explicitly created. The system will not dynamically assign entries or a value.
- The action to associate the forwarding class with a specific MAC criteria entry ID.
- A description. The description provides a brief overview of policy features.
The following is a sample ingress MAC criteria configuration output.
9.2.8. Applying Service Ingress Policies
SAP ingress QoS policies are supported only on access SAPs.
9.2.8.1. Epipe Service
The following is a sample Epipe service configuration output with SAP ingress policy 100 applied to the SAP.
9.2.8.2. VPLS
The following is a sample VPLS service configuration output with SAP ingress policy 100.
9.2.8.3. IES
The following is a sample IES service configuration output.
9.3. Service Management Tasks
This section describes the service management tasks.
9.3.1. Deleting QoS Policies
Every service SAP is associated, by default, with the appropriate ingress policy (policy-id 1). You can replace the default policy with a customer-configured policy, but you cannot entirely remove the policy from the SAP configuration. When you remove a non-default service ingress policy, the association reverts to the default policy-id 1.
A QoS policy cannot be deleted until it is removed from all SAPs where they are applied.
9.3.1.1. Removing a QoS Policy from Service SAPs
The following Epipe service output samples show that the SAP service ingress reverted to policy-id “1” when the non-default policies were removed from the configuration.
9.3.2. Copying and Overwriting QoS Policies
You can copy an existing service ingress policy, rename it with a new policy ID value, or overwrite an existing policy ID. The overwrite option must be specified or an error occurs if the destination policy ID exists.
9.3.3. Removing a Policy from the QoS Configuration
9.3.4. Editing QoS Policies
You can change QoS existing policies and entries. The changes are applied immediately to all services where this policy is applied. To prevent configuration errors copy the policy to a work area, make the edits, and then write over the original policy.