8. Service Ingress QoS Policies
This section provides information to configure SAP ingress QoS policies using the command line interface.
8.1. Overview of Service Ingress Policy
There is one default service ingress policy. The default policy has two classification resources and one meter (the num-qos-classifiers set to value “2”). Service Ingress queuing is not supported on 7210 SAS-D and 7210 SAS-Dxp. Instead user has the option of using policing per FC (and for VPLS services, per FC and per traffic type). 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. See “CLI Usage” in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information about the tasks and commands necessary to access the command line interface, and to configure and maintain your devices.
8.1.1. Default SAP Ingress Policy
The default policy 1, maps all traffic to default forwarding class 'be' and maps FC 'be' to meter 1. Meter 1 is configured with cir 0 and pir max, as shown below:
8.1.1.1. SAP Ingress Policy Defaults
Table 36 describes SAP ingress policy defaults.
Table 36: SAP Ingress Policy Defaults
Field | Default |
description | “Default SAP ingress QoS policy.” |
scope | template |
num-qos-classifiers | 2 |
meter | 1 |
mode | trtcm1 |
adaptation-rule | cir closest pir closest |
rate | pir = max, cir= 0 |
cbs | 32kbits |
mbs | 128kbits |
default-fc | be |
8.1.1.2. 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 attempts to allocate resources for all the SAPs on a first-come-first-served basis (Note: There is no guarantee that resources will be allocated to all SAPs). Hence, when the file is not present it is possible that configuration saved, does not execute successfully after the reboot.
 | Note: The index file used for QoS map is different from the one used for storing Interface indexes. |
8.1.1.2.1. Use of the Keyword Multipoint for Default Meter “11”
The system allows sharing of a single meter for both unicast and multipoint traffic. The user can configure any of the available meters for multipoint traffic. The use of multipoint keyword during meter creation is deprecated, except for use with meter 11 as described in the following paragraphs.
When the multipoint keyword is specified with meter 11 the software interprets it to be the default multipoint meter. The default multipoint meter is used for all FCs that do not have explicit multipoint meters configured.The software does the appropriate resource checks to ensure that resources needed to use multipoint meter with all the FCs are available before allowing this change.
| Note:
|
Examples of usage of multipoint meter:
Example 1:
All FCs in the SAP ingress policy use the default meter 1 (for all traffic types). If the command “configure qos sap-ingress <id> meter 11 multipoint create” is executed, it attaches the default meter “11” with all the FCs defined in the SAP ingress policy.
After this configuration, all the FCs in this policy use two meters, default meter "1" to meter unicast traffic for all the FCs and meter “11” to meter BUM traffic for all the FCs. In this specific example, since only default FC “be” is in use, the multipoint meter will be used to meter BUM traffic associated with default FC “be”.
After the change the policy is as displayed in the example below:
Delete the multipoint meter “11” to remove all the FCs associated with the multicast-meter (assuming all the FCs are using the default multicast meter and do not have any other multicast meter explicitly configured). Execute the command “configure qos sap-ingress <id> no meter 11”, this disassociates meter “11” from the FCs and now the FCs use only meter “1” (if no other meter configured explicitly).
Example 2:
Starting with the above policy, if the user now executes the command "configure qos sap-ingress <id> meter 11 multipoint create", the FC “be” continues to use meter “3” and the FC "af" uses meter "11" for BUM traffic. In the above example, if the user were to execute "configure qos sap-ingress <id> fc be no multicast-meter", then the default meter “11” is used for FC "be" too.
Example 3:
On execution of the command "configure qos sap-ingress <id> meter 11 multipoint create", FC "be" unknown-unicast traffic type will continue to use meter 3 and broadcast and multicast traffic type will use meter “11”.
In the above example, if initially a broadcast-meter was configured in the sap-ingress policy and then followed by execution of the command "configure qos sap-ingress <id> meter 11 multipoint create", then FC be changes to use meter “11” for multicast traffic and broadcast traffic continue to use meter “3” for unknown-unicast traffic and meter “3” for unicast traffic.
In the above example, if the user executes "configure qos sap-ingress <id> fc be no unknown-meter", then meter "3" is used for all traffic types classified to FC “be”. But, if the default meter "11" is defined in the policy, then FC “be” uses meter “11” for BUM traffic.
8.1.1.3. Service Ingress Meter Selection Rules
The following are rules for meter selection by different traffic types under various configurations for VPLS services:
- In the default policy, only meter “1” is defined. All FC and all traffic types use meter “1” by default. Meter “11” is not created by default and is not available for use.
Sample configuration:
The following describes the usage of meters in a VPLS service, when meter “11” is not configured in the policy:
- If a FC is created without explicit meters, the default meter “1” is used for unicast traffic and for multipoint traffic types (such as broadcast, multicast and unknown-unicast traffic).
- If a FC is created with an explicit unicast meter, that meter is used for unicast traffic and for multipoint traffic types (such as broadcast, multicast and unknown-unicast traffic).
- If a FC is created with an explicit unicast meter and explicit broadcast meter, use these meters for unicast and broadcast traffic respectively and use the unicast meter for all other traffic types.
- If a FC is created with an explicit unicast meter and explicit multicast meter, use the unicast meter for unicast traffic and multicast meter for all other traffic types.
- If a FC is created with an explicit unicast meter, an explicit broadcast meter, and an explicit multicast meter, use these meters for unicast, broadcast and multicast traffic types respectively. Unknown unicast traffic type will use the explicitly defined multicast meter.
- If a FC is created with an explicit unicast meter, an explicit broadcast meter, an explicit unknown-unicast meter, and an explicit multicast meter, use these meters for unicast, broadcast, unknown-unicast and multicast traffic types respectively.
The following describes the usage of meters in a VPLS service, when meter “11” is defined in the policy:
- If a FC is created without explicit meters, use the default meter “1” for unicast traffic and default meter “11” for all other traffic types (such as broadcast, multicast and unknown-unicast).
- If a FC is created with an explicit unicast meter, use that meter for unicast traffic and use default meter “11” for all other traffic types.
- If a FC is created with an explicit unicast meter and explicit broadcast meter, use these meters for unicast and broadcast traffic respectively and use meter “11” for all other traffic types.
- If a FC is created with an explicit unicast meter and explicit multicast meter, use the unicast meter for unicast traffic and multicast meter for all other kinds of traffic.
- If a FC is created with an explicit unicast meter, an explicit broadcast meter, and an explicit multicast meter, user these meters for unicast, broadcast and multicast traffic types respectively. Unknown unicast traffic type will use the explicitly defined multicast meter.
- If a FC is created with an explicit unicast meter, an explicit broadcast meter, an explicit unknown-unicast meter, and an explicit multicast meter, use these meters for unicast, broadcast, unknown-unicast and multicast traffic types respectively.
The following are rules for meter selection for Epipe, IES services:
| Note: These rules apply to IES services when PIM, multicast is not enabled in the service.
|
8.1.1.4. Service Ingress QoS Policy Configuration Considerations
The num-qos-classifiers parameter cannot be modified when the policy is in use (for example, when it is associated with a SAP). Other parameters in the SAP ingress policy can be changed.
When changing other parameters (for example, fc meter map or fc classification match criteria entries) for a policy which is in use, the system recomputes the resources required to accommodate the change. If the resources required exceeds the configured value for num-qos-classifiers, then the change is not allowed.
If more resources are needed than what is configured in num-qos-classifiers for a existing policy, then the following options are available.
- Copy the existing policy to a new policy, modify the num-qos-classifiers parameter, modify the match criteria entries suitably, and finally modify the SAP configuration to associate it with the new policy.
- Ensure the existing policy is not in use by any SAP (if required change the SAP configuration to disable the use of the QoS policy with the no qos form of the command), change all the required parameters and finally modify the SAP configuration to use the policy again.
Note that both these options have side-effects, for example, it resets the statistics associated with the meters and can potentially cause existing traffic classification not to take effect. But, the system will ensure that default policy is in use during the intermittent time when a policy changes are being made following the steps given above.
- In releases prior to release 3.0R1, the software always the computes the number of resources (like classifiers and meters) required by a policy assuming it will be used in a VPLS service. This allows the policy to be applied to either an Epipe or VPLS service.
- From release 3.0R1 onwards, on creation of SAP ingress policy, software does not compute the number of resources required by a policy and validate it against resources available in the system. The software validates the resources needed only when the SAP ingress policy is attached to a SAP. If enough resources are available the association succeeds, else the software fails the CLI command. Based on the service (i.e. Either VLL, VPLS, and so on.) the SAP is configured in, for the same SAP ingress policy the amount of resources required is different. The software validates that the amount of qos resources specified with the command num-qos-classifiers is sufficient for the match criteria, forwarding class and service specified and the resources are available in hardware. On failure of the validation, the software disallows the association of the SAP ingress policy with the SAP.
- The match criteria type (that is, mac-criteria, ipv4-criteria and ipv6-criteria) cannot be changed when the SAP ingress QoS policy is in use. For example - if the match-criteria is set to ipv4-criteria and the policy is associated with a SAP then the ipv6-criteria or mac-criteria cannot be enabled in the same policy. If there is a need to change the criteria, then user must remove the association and then change the SAP ingress policy to use the new match criteria.
Please see the section on “Resource Allocation for Service Ingress QoS Policy Classification Rules” for more information.
8.1.2. Resource Allocation for Service Ingress QoS Policy Classification Rules
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, etc. SAP ingress QoS can be allocated classification and meter resources for use from this pool. Further on, resources can be allocated for different SAP ingress QoS policy classification 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 fixed number of entries.
The number of chunks to be allotted for SAP ingress QoS policy is specified using the configure>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource command.
User can specify a limit for the amount of resources required for SAP ingress QoS policies and also an option to limit the amount of resources used per match criteria supported for SAP ingress QoS policies. A given chunk can be used for either MAC criteria or IP criteria or IPv6 criteria. Allocation of classification entries also allocates meter/policer resources, used to implement per FC per traffic type policing.
By default, the system allocates resources for SAP ingress QoS policies to maintain backward compatibility with release 4.0 and allocates resources for MAC criteria and IP criteria (by setting it to 'max'). Setting the value to ‘max’ allows each match criteria to use the available SAP ingress QoS resources on first-come-first-served model. By default, software does not allocate resources for use by ingress IPv6 filters. Before associating an IPv6 SAP ingress policy to a SAP, resources must be allocated. Until resources are allocated for use by IPv6 filters, software fails all attempts to associate an IPv6 filter policy with a SAP.
When the user allocates resources for use by SAP ingress QoS policies using the configure>system>resource-profile>qos-sap-ingress-resource command, the system allocates resources in chunks of 256 entries. The usage of these entries by different type of match criteria is given below:
| Note: Please check the release notes for services supported on different 7210 platforms. The references to services below appear for completeness and does not imply support is available. |
- mac-criteria (any) - User needs to allocate resources for mac-criteria from the SAP ingress QoS resource pool by using the configure>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource>mac-match-enable command before using SAP ingress policies with mac-criteria. Every entry configured in the SAP ingress QoS policy using the mac-criteria uses one (1) entry from the chunks in the hardware.For example: Assume a SAP Ingress QoS policy is configured to use mac-criteria with 25 entries and uses configure>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource>mac-match-enable 1, to configure one chunk for use by mac-criteria (allowing a total of 256 entries for use by policies using mac-criteria). In this case, the user can have 10 SAPs using mac-criteria SAP ingress policy and consumes 250 entries.
- ipv4-criteria (any) - The usage is same as the mac-criteria. Resources need to be allocated using the configure>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource>ipv4-match-enable command. Additionally, IPv4 criteria can share the entries allocated for IPv6 criteria. The software automatically allocates entries from an IPv6 criteria slice to IPv4 criteria policies, if there are no entries available in the allocated IPv4 criteria chunks and there are no chunks available for allocation to IPv4 criteria from the SAP ingress QoS resource pool. The number of hardware entries taken up by an IPv4 criteria entry when using the IPv6 criteria chunks is the same as required by an entry using IPv6 criteria (see below for details).
- ipv6-criteria (any) - User needs to allocate resources from the SAP ingress QoS resource pool for ipv6-criteria by using the configure>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource>ipv6-ipv4-match-enable command before using IPv6 criteria and num-qos-classifiers must specify the ipv6 keyword. Every ipv4 criteria match entry or ipv6 criteria match entry configured in the QoS policy using ipv6-criteria uses two (2) entries from the chunks allocated for use by ipv6-criteria (128-bit) in the hardware. Software allocates entries from the ipv6-criteria pool if the SAP ingress QoS policy uses both ipv6-criteria entries and ipv4-criteria (any or IPv4 DSCP) entries or if the SAP ingress QoS policy uses only IPv6 criteria any or if the SAP ingress QoS policy uses ipv4 criteria any and there are no resources available in the IPv4 criteria (as explained above).For example: Assume a QoS policy is configured to use ipv6-criteria with 25 entries and using configure>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource>ipv4-ipv6-128-match-enable 1, user configures one chunk for use by ipv6-criteria. This allows for a total of 128 entries for use by SAPs using SAP ingress QoS policies with ipv6-critiera (as each IPv6 entry uses 2 entries in hardware). In this example, user can have five (5) SAPs using this policy and consuming 125 entries in total. These resources can be shared with policies that use IPv4 criteria, though it consumes 2 entries in hardware consumed per IPv4 criteria entry. It allows user to make use of spare IPv6 resources for IPv4 criteria policies, though if user plans to have a larger number of IPv4 criteria policies they are better off allocating more resources for use with IPv4 criteria.Note when a chunk is allocated to IPv6 criteria, software automatically adjusts the number of available entries in that chunk to 128, instead of 256, since 2 entries are needed to match IPv6 fields. The number of meters available does not reduce though and 128 meters are available for use.
- dot1p-only, IPv4 dscp-only, IPv6 dscp-only and Default SAP Ingress QoS policies - User can use the option 'dot1p-only' or dscp-only', if they plan to use only dot1p bits or only DSCP bits for SAP ingress classification. This typically allows for efficient use of available hardware resources and better scaling. SAP ingress policies that use only Dot1p bits or only IPv4/IPv6 DSCP and Default SAP ingress QoS policies can use the resources from chunks currently allocated for use by either IP-criteria or MAC-criteria or IPv6 criteria. There are some special cases noted below for allocation of resources for default, dot1p-only and dscp-only SAP ingress policies:
- If there are no chunks available for accommodating a SAP that is associated with default or dot1p-only or a dscp-only SAP ingress policy, the software allocates resources against mac-criteria if the SAP is configured in a VLL or VPLS service. The software uses the required number of entries for this policy. The remaining entries is available for SAPs that use mac-criteria or that use only dot1p or only ipv4/ipv6 DSCP or that use default policy.
- If there are no chunks available for accommodating a SAP that is associated with default, dot1p-only or a dscp-only SAP ingress policy, the software allocates resources against ipv4-criteria if the SAP is configured in an IES or a VPRN service. The software uses the required number of entries for this policy. The remaining entries is available for SAPs that use ipv4-criteria or that use only ipv4/ipv6 DSCP or only dot1p criteria or that use default policy.
The SAP ingress resource chunks referred to in this section is different from the resources specified using the command 'num-qos-classifiers'. num-qos-classifiers set the limit on the resources needed per SAP ingress QoS policy. The above resources set the maximum limit on the resources available for use by all the SAP ingress policies in use simultaneously on the system. The software manages the resource chunks allocated to SAP ingress QoS policy pool and allocates the entries in the chunks when a SAP ingress QoS policy is associated with a SAP. In other words, a SAP specifies the amount of QoS resources it needs, using the 'num-qos-resources' CLI command (in the SAP ingress policy) and the software allocates the resources required by a SAP from the chunks depending on whether the SAP ingress policy uses ip-criteria or mac-criteria or ipv6-criteria.
| Note: On the 7210 SAS-D and 7210 SAS-Dxp, mac-criteria SAP ingress QoS policies can use an additional 128 classification entries with 64 meters. These entries are allocated to the mac-criteria SAP ingress QoS resource pool by default and cannot be reassigned to any another feature or any other match criteria. |
Use the tools>dump>system-resources command to display information about the current usage and availability. One or more entries per chunk are reserved for system use.
8.1.3. Computation of SAP Ingress Classification and Meter Resources Used per SAP Ingress Policy
Please check the release notes for services supported on different 7210 SAS platforms. The references to services below appear for completeness and does not imply support is available.
This section provides information on the resource consumption per SAP ingress policy. Resources required by SAP ingress policy is allocated from the ingress-internal-tcam resource pool based on the amount of resources allocated for SAP ingress classification.
The user is allowed to configure the number of classification entries the SAP requires (for example: TQ).
Number of meters allocated automatically by system = TQ / 2 (up to a maximum of 32 meters).
To calculate the number of SAPs allowed, assume all configured to use ‘TQ’ QoS resources per SAP.
Number of SAPs allowed = maximum classification entries / TQ.
| Note: The number of SAPs arrived at using the equation above is subject to system limits. The above equation is used to derive the limit on the number of SAPs due to QoS resources only. |
The user is allowed to mix and match SAPs with different QoS resources (that is, using different values of TQ). The allowed values in 7210 SAS-D devices for the parameter num-qos-classifiers are 4,8,16,32,64,128 and 256. The allowed num-qos-classifiers values for 7210 SAS-Dxp devices are any multiple of 2 between 2 and 256.
The following determines the number of QoS resources to be allocated for an SAP:
- Number of match-criteria entries used to identify the FC.
- Number of FCs to use and number of traffic-types to be policed per FC.
- The amount of hardware classification resources needed per entry configured by the user (See Resource Allocation for Service Ingress QoS Policy Classification Rules to know about resources needed per match entry. It varies based on different match criteria in use).
Only those FCs that are in use by the match-criteria classification entries are considered for the number of FCs. Therefore, these FCs are referred to as ‘FC in use’.
Given the number of traffic types to use per 'FC in use', the following rules apply for a SAP in a VPLS service to arrive at number of classification entries per FC in use:
- If a FC is in use and is created without explicit meters, use default meter #1 for unicast traffic and for all other traffic types (that is, broadcast, multicast and unknown-unicast). This requires one classification entry in hardware. This assumes default mulitpoint meter #11 is not created by the user.
- If a FC is in use and is created without explicit meters, use default meter #1 for unicast traffic and default meter #11 (assuming meter “11” is created by the user), for all other traffic types (that is, broadcast, multicast and unknown-unicast). This requires two classification entries in hardware.
- If a FC is in use and is created with an explicit unicast meter, use that meter for unicast traffic and for all other traffic types (that is, broadcast, multicast and unknown-unicast). This requires one classification entries in hardware. This assumes default multipoint meter “11” is not created by the user.
- If a FC is in use and is created with an explicit unicast meter, use that meter for unicast traffic and use default meter #11 (assuming meter “11” is created by the user) for all other traffic types. This requires two classification entries in hardware.
- If a FC is in use and is created with an explicit unicast meter and explicit broadcast meter, use these meters for unicast and broadcast traffic respectively and use the unicast meter for all other traffic types (that is, multicast and unknown-unicast). This requires two classification entries in hardware. This assumes that the default multipoint meter #11 is not created by the user.
- If a FC is in use and is created with an explicit unicast meter and explicit broadcast meter, use these meters for unicast and broadcast traffic respectively and use meter #11 (assuming meter 11 is created by the user) for all other traffic types. This requires three classification entries in hardware.
- If a FC is in use and is created with an explicit unicast meter and explicit multicast meter, use the unicast meter for unicast traffic and multicast meter for all other kinds of traffic. This requires two classification entries in hardware.
- If a FC is in use and is created with an explicit unicast meter, an explicit broadcast meter, and an explicit multicast meter, use these meters for unicast, broadcast and multicast traffic types respectively. Unknown unicast traffic type will use the explicitly defined multicast meter. This requires three classification entries in hardware.
For calculating the number of classification entries per FC for a SAP in a VLL service or IES and VPRN service with PIM/ IP multicast disabled, the following rules apply:
- Multipoint meters cannot be used. Multipoint meter configured in a policy is not used when the policy is applied to a SAP in an Epipe service.
- All FCs in use and associated with a meter always use the unicast meter. Therefore, all FCs in use utilize only one classification entry in the hardware.
Given the number of traffic types to use per 'FC in use', the following rules apply for an SAP in a IES and VPRN service enabled with PIM/IP multicast enabled to arrive at number of classification entries per FC in use:
- If a FC is in use and is created without explicit meters, use default meter #1 for unicast traffic and for multicast traffic. This requires one classification entry in hardware. This assumes default multipoint meter #11 is not created by the user.
- If a FC is in use and is created without explicit meters, use default meter #1 for unicast traffic and default meter #11 (assuming meter “11” is created by the user), for multicast traffic. This requires two classification entries in hardware.
- If a FC is in use and is created with an explicit unicast meter, use that meter for unicast traffic and for multicast traffic. This requires one classification entries in hardware. This assumes default multipoint meter “11” is not created by the user.
- If a FC is in use and is created with an explicit unicast meter, use that meter for unicast traffic and use default meter #11 (assuming meter “11” is created by the user) for multicast traffic. This requires two classification entries in hardware.
- If a FC is in use and is created with an explicit unicast meter and explicit multicast meter, use the unicast meter for unicast traffic and multicast meter for multicast traffic. This requires two classification entries in hardware.
Apply the rules to determine the number of classification entries per FC (only for the FCs in use) using the following equation:
C(i)=SFCi(unicast)+FCi(multicast)+FCi(broadcast)+FCi(unknown_unicast)
i=nc,h1,ef,h2,l1,af,l2,be
where FCi (unicast), FCi (multicast), FCi (broadcast), and FCi (unknown-unicast) are set to a value of 1 if this FC uses classifier to identify traffic-type unicast, multicast, broadcast and unknown-unicast respectively. FCi (unicast), FCi (multicast), FCi (broadcast), and FCi (unknown-unicast) are set to a value of 0 if this FC does not use a classifier to identify this traffic-type.
If the user does not configure meters explicitly for the FC and meter “11” is not created, the default unicast meter is used for all traffic types and therefore, only one classification entry in hardware is required by the FC. If the user does not configure meters explicitly for the FC and meter “11” is created, the default unicast meter and multicast meter are used. Therefore by default, two classification entries in hardware are required by a FC.
Taking into account the number of match criteria and the number of FCs used, use the equation given below to arrive at total number of classification entries per policy, for example:
TC=S E(i)* C(i)
i=nc,h1,ef,h2,l1,af,l2,be
where:
- E(i) is the number of match-criteria entries that classify packets to FCi. For 7210 platforms, the maximum number of classification entries per policy can be 64 (including default).
- C(i) is the number of classification entries that are required by FCi to identify different traffic types.
Determine the number of policers or meters to use (for example TP). A maximum of 32 meters per policy are available.
Only those meters associated with FCs are considered for number of meters. Note that only 'FCs in use' is considered.
Total QoS resources required (for example TQ) = max ( (TC), (2 * TP) ).
The number obtained is rounded off to next multiple of “2” greater than TQ obtained above.
The user configures value TQ using CLI command num-qos-classifiers.
For more information, see the “Service Ingress QoS Policy Configuration Considerations” on Service Ingress QoS Policy Configuration Considerations for examples on resource calculation.
8.1.3.1. Service Ingress QoS Policies Resource Usage Examples
This section provides resource usage examples for service ingress QoS policies.
8.1.3.1.1. Example 1
In the example above, assuming the policy is attached to a SAP in a VPLS service, compute the number of classification entries per FC as follows:
Since this FC uses unicast meter, an entry is needed to identify this traffic type explicitly. Another entry is needed to classify broadcast, multicast and unknown-unicast traffic type to the same FC and use the default meter #11.
Using the equation, the total classification entries used by this policy is calculated as:
TC = (0 * 0)nc + (0 * 0)h1 + (0 * 0)ef + (1 * 2)h2 + (1 * 2)l1 + (1 * 2)af + (0 * 0)l2 + (1 * 2)be = 8 (since three explicit match criteria entries are used to map traffic to each of FC H2, FC L1, and FC AF along with a default classification entry for FC BE).
Meters used = 3 (since FCs use meter #1, meter #3 and meter #11).
Therefore, in this example, num-qos-classifiers 16 is used (i.e. maximum of (8, (2 * 3))).
If the same policy were to be used for a SAP in an Epipe service, then since all traffic is classified to a unicast traffic type and since only unicast meters are used, the following:
Using the above equation, the total classification entries used = 4 and total meters used = 2.
8.1.3.1.2. Example 1a (Default multipoint meter “11” is not used):
In the example above, assuming the policy is attached to a SAP in a VPLS service, compute the number of classification entries per FC as follows:
Since this FC uses unicast meter for all traffic types, we need an entry to classify all traffic types to this FC explicitly.
Using the equation, calculate the total classification entries used by this policy, as follows:
TC = (0 * 0)nc + (0 * 0)h1 + (0 * 0)ef + (1 * 1)h2 + (1 * 1)l1 + (1 * 1)af + (0 * 0)l2 + (1 *1)be = 4 (since three explicit match criteria entries are used to map traffic to each of FC H2, FC L1, and FC AF along with a default classification entry for FC BE).
The total number of meters used = 2 (since FCs use meter #1 and meter #3).
Hence, in this example, num-qos-classifiers 4 is used (maximum of (4, (2 * 2))). Hence, use of unicast meter for all traffic-types allows for use QoS resources efficiently.
If the same policy were to be used for a SAP in an Epipe service, then since all traffic is classified to a unicast traffic type and since only unicast meters are used, the following:
Using the above equation, total classification entries used = 4 and meters used = 2.
As can be seen here, using the same policy for Epipe SAP can lead to inefficient use of resources. Hence, it is recommended to create a different policy with the required number of resources (that is, with num-qos-classifiers 4)
8.1.3.1.3. Example 2
In the example above, assuming the policy is attached to a SAP in a VPLS service, classification entries used per FC are as follows:
Since this FC uses unicast meter and broadcast meter, two entries are required to identify these traffic types explicitly. Another entry is required to classify multicast and unknown-unicast traffic type to the same FC and use the default meter #11.
Using the above equation, the total classification entries used = 11 (since three explicit match criteria entries map to each of FC H2, L1, and AF along with a default classification rule for BE).
Meters used = 3 (since FCs use only meter #2, meter #3 and meter #11).
Therefore, in this example, num-qos-classifiers 16 is used (i.e. maximum of (12, (2*3))). Note that the system internally uses 18, instead of 16.
If the same policy were to be used for a SAP in an Epipe service, then since all traffic is classified to a unicast traffic type and since only unicast meters are used, the following is used:
Using the above equation, the total classification entries used = 4 and the total meters used = 1.
8.1.3.1.4. Example 2a (Default multipoint meter “11” is not used):
In the example above, assuming the policy is attached to a SAP in a VPLS service, classification entries used per FC as:
Since this FC uses unicast meter for unicast, multicast, unknown-unicast traffic and broadcast meter for broadcast traffic, hence two entries are needed.
Using the above equation, to get the total classification entries used = 8 (since three explicit match criteria entries map to each of FC H2, L1, and AF along with a default classification rule for BE).
The number of meters used = 2 (since FCs use only meter #2 and meter #3).
Hence, in this example num-qos-classifiers 8 is used (that is,maximum of (8, (2*2))).
If the same policy were to be used for a SAP in an Epipe service, then since all traffic is classified to a unicast traffic type and since only unicast meters are used, the following:
Using the above equation, to get total classification entries used = 4 and Meters used = 1. As can be seen here, using the same policy for Epipe SAP can lead to inefficient use of resources. Hence, it is recommended to create a different policy with the required number of resources (that is, with num-qos-classifiers 4)
8.1.3.1.5. Example 3
In the example above, assuming the policy is attached to a SAP in a VPLS service, the classification entries used per FC are as follows:
Since this FC uses unicast, broadcast, multicast and unknown-unicast meter, four entries are required to identify these traffic types explicitly.
Since this FC uses unicast meter and broadcast meter, two entries are required to identify these traffic types explicitly. Another entry is required to classify multicast and unknown-unicast traffic type to the same FC and use the default meter #11.
Since this FC uses only unicast meter, an entry is required to identify this traffic type explicitly. Another entry is required to classify broadcast, multicast and unknown-unicast traffic type to the same FC and use the default meter #11.
Since this FC uses unicast, broadcast and multicast meter, three entries are required to identify these traffic types explicitly. Unknown-unicast traffic type is classified using the same entry as multicast traffic type and uses the same meter.
Using the above equation, the total classification entries used = 15 and the total meters used = 6.
If the same policy were to be used for a SAP in an Epipe service, then since all traffic is classified to a unicast traffic type and since only unicast meters are used, the following are used:
Using the above equation, the total classification entries used = 5 and the total meters used = 3 (since all FCs used only meter #1, meter #3 and meter #5).
8.1.3.1.6. Example 3a (Default multipoint meter "11" is not used) :
In the example above, assuming the policy is attached to a SAP in a VPLS service, the classification entries used per FC are:
Since this FC uses unicast, broadcast, multicast and unknown-unicast meter, four entries are needed to identify these traffic types explicitly.
Since this FC uses unicast meter and broadcast meter, two entries are needed to identify these traffic types explicitly, multicast and unknown-unicast traffic use the same resource as the unicast traffic.
Since this FC uses unicast meter and broadcast meter, two entries are needed to identify these traffic types explicitly. multicast and unknown-unicast traffic use the same resource as the unicast traffic.
Since this FC uses unicast, broadcast and multicast meter, three entries are needed to identify these traffic types explicitly. Unknown-unicast traffic type is classified using the same entry as multicast traffic type and uses the same meter.
Since no explicit meters are configured for FC be, it uses meter 1 for all traffic types and needs one entry is needed to identify these traffic types.
Using the above equation, the total classification entries used = 12 and meters used = 5. The num-qos-classifiers can be set to 12 (the minimum value).
If the same policy were to be used for a SAP in an Epipe service, then since all traffic is classified to a unicast traffic type and since only unicast meters are used, the following results:
Using the above equation, the total classification entries used = 5 and meters used = 3 (since all FCs used only meter #1, meter #3 and meter #5). For epipe service a policy with num-qos-resources set to 6 can be used.
8.1.3.1.7. Example 4
In the example above, assuming the policy is attached to a SAP in a VPLS service, compute the classification entries per FC as:
Since this FC uses unicast, broadcast and multicast meter, three entries are required to identify these traffic types explicitly. Unknown-unicast traffic type is classified using the same entry as multicast traffic type and uses the same meter.
Since this FC uses unicast, broadcast, multicast and unknown-unicast meter, four entries are required to identify these traffic types explicitly.
Since this FC uses unicast, broadcast and multicast meter, three entries are required to identify these traffic types explicitly. Unknown-unicast traffic type is classified using the same entry as multicast traffic type and uses the same meter.
Since this FC uses unicast meter and broadcast meter, two entries are required to identify these traffic types explicitly. Another entry is required to classify multicast and unknown-unicast traffic type to the same FC and use the default meter #11.
Since this FC uses unicast, broadcast and multicast meter, three entries are required to identify these traffic types explicitly. Unknown-unicast traffic type is classified using the same entry as multicast traffic type and uses the same meter.
Using the above equation, the total classification entries used = 21 and the total meters used = 8
If the same policy were to be used for a SAP in an Epipe service, then since all traffic is classified to a unicast traffic type and since only unicast meters are used, the following are used:
Using the above equation, the total classification entries used = 7 and the total meters used = 4.
As illustrated in this example, using the same policy for Epipe SAP can lead to inefficient use of resources. Hence, it is recommended to create a different policy with the required number of resources (i.e. with num-qos-classifiers = 16)
8.1.3.1.8. Example 4a (Default multipoint meter "11" is not used):
In the example above, assuming the policy is attached to a SAP in a VPLS service, compute the classification entries per FC as:
Since this FC uses unicast, broadcast and multicast meter, three entries are needed to identify these traffic types explicitly. Unknown-unicast traffic type is classified using the same entry as multicast traffic type and uses the same meter.
Since this FC uses unicast, broadcast, multicast and unknown-unicast meter, four entries are needed to identify these traffic types explicitly.
Since this FC uses unicast, broadcast and multicast meter, three entries are needed to identify these traffic types explicitly. Unknown-unicast traffic type is classified using the same entry as multicast traffic type and uses the same meter.
Since this FC uses unicast meter and broadcast meter, two entries are needed to identify these traffic types explicitly. multicast and unknown-unicast traffic of the same FC use the unicast resources (both meter and classification entry).
Since this FC uses unicast, broadcast and multicast meter, three entries are needed to identify these traffic types explicitly. Unknown-unicast traffic type is classified using the same entry as multicast traffic type and uses the same meter.
Since this FC uses a single meter for all traffic-types only a single meter and single entry is needed.
Using the above equation, the total classification entries used = 20 and meters used = 7. num-qos-classifiers to use is 20 (the minimum value).
If the same policy were to be used for a SAP in an Epipe service, then since all traffic is classified to a unicast traffic type and since only unicast meters are used, the following:
Using the above equation, the total classification entries used = 7 and meters used = 4.
As can be seen here, using the same policy for Epipe SAP can lead to inefficient use of resources. Hence, it is recommended to create a different policy with the required number of resources (that is, with num-qos-classifiers 8).
8.1.3.1.9. Example 5
In the example above, assuming the policy is attached to a SAP in a VPLS service, the following number of classification entries per FC:
Since this FC uses unicast meter, an entry is required to identify these traffic types explicitly. Another entry is required to classify broadcast, multicast and unknown-unicast traffic type to the same FC and use the default meter #11.
Since this FC uses unicast, broadcast and multicast meter, three entries are required to identify these traffic types explicitly. Unknown-unicast traffic type is classified using the same entry as multicast traffic type and uses the same meter.
Using the equation, the total classification entries used by this policy is calculated as follows:
TC = (0 * 0)nc + (0 * 0)h1 + (0 * 0)ef + (0 * 0)h2 + (0 * 0)l1 + (15 * 3)af + (0 * 0)l2 + (1 * 3)be = 48
The total meters used in this policy = 4.
Hence, in this example, num-qos-classifiers 72 are used (i.e. maximum of (48, (2 * 4)) = 48, rounded off to the next available numQosClassifier range.
If the same policy were to be used for a SAP in an Epipe service, then since all traffic is classified to a unicast traffic type and since only unicast meters are used, the following are used:
Using the equation, the total classification entries used by this policy is calculated as follows:
(0 * 0)nc + (0 * 0)h1 + (0 * 0)ef + (0 * 0)h2 + (0 * 0)l1 + (15 * 1)af + (0 * 0)l2 + (1 * 1)be = 16
The number of meters used in this policy = 2.
Hence for Epipe SAP it is recommended to define another sap-ingress policy with num-qos-classifiers 16 is used (maximum of (16, (2 * 2)) = 16.
8.2. Basic Configurations
A basic service ingress QoS policy must conform to the following:
- Have a unique service ingress QoS policy ID.
- Allocates number of classifier and meter resources needed for use.
- Have a QoS policy scope of template or exclusive.
- Have at least one default unicast forwarding class meter/queue.
- Use of multipoint forwarding class meter/queue is optional.
8.2.1. Create Service Ingress QoS Policies
Configuring and applying QoS policies is optional. If no QoS policy is explicitly applied to a SAP, a default QoS policy is applied.
8.2.1.1. Service Ingress QoS Policy
| Note: A meter is available to limit the bandwidth per forwarding class on service ingress. |
To create an 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 the num-qos-classifiers parameter. By default, it is set to 2. The number of meters/queue allocated is equal to half the number of classifiers specified.
- 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-meter/queue default value to override the default unicast forwarding type meter mapping for fc fc-name.
- Modify the multicast-meter/queue default value to override the default multicast forwarding type meters/queue mapping for fc fc-name.
- Modify the unknown-meter/queue default value to override the default unknown unicast forwarding type meter mapping for fc fc-name.
- Modify the broadcast-meter default value to override the default broadcast forwarding type meter mapping for fc fc-name.
- On platforms where applicable, 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.
8.2.1.1.1. Service Ingress QoS Meter
To create service ingress meter parameters, define the following:
- A new meter ID value — The system will not dynamically assign a value.
- Meter parameters — Ingress meters support the definition of either srTCM (Single Rate Tri-Color Meter) or trTCM (Two Rate Tri-Color Meter), CIR/PIR, CBS/MBS parameters.
The following is a sample ingress meter configuration output.
8.2.1.1.2. SAP Ingress Forwarding Class (FC)
The following is a sample forwarding class configuration output.
8.2.1.1.3. 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.
8.2.1.1.4. 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.
8.2.1.2. Applying Service Ingress Policies
8.2.1.2.1. Epipe Service
The following is a sample Epipe service configuration output with SAP ingress policy 100 applied to the SAP.
8.2.1.2.2. VPLS
The following is a sample VPLS service configuration output with SAP ingress policy 100.
8.2.1.2.3. IES
| Note: SAP ingress QoS policies for access SAPs and IES on access SAPs are only supported on 7210 SAS-D and 7210 SAS-Dxp. |
The following is a sample IES service configuration output.
8.3. Service Management Tasks
This section describes the service management tasks.
8.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 it is applied.
8.3.1.1. Remove a QoS Policy from Service SAPs
The following Epipe service output examples show that the SAP service ingress reverted to policy-id “1” when the non-default policies were removed from the configuration.
8.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.
8.3.3. Remove a Policy from the QoS Configuration
8.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.