9. Service ingress QoS policies
This chapter provides information to configure SAP ingress QoS policies using the CLI.
9.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 the 7210 SAS-D and 7210 SAS-Dxp. Instead the 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 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. Other QoS policies must be explicitly associated. 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 CLI, and to configure and maintain devices.
9.1.1. Default SAP ingress policy
The default policy 1 maps all traffic to default FC “be” and maps FC “be” to meter 1. Meter 1 is configured with cir 0 and pir max.
The following is a sample configuration output.
9.1.1.1. SAP ingress policy defaults
The following table lists the 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 |
9.1.1.2. Use of index file by SAP QoS ingress policy
The 7210 SAS uses an index file to store the map that indicates the QoS resource allocation to the SAPs. This file is used to ensure that all the SAPs that were created successfully before the reboot can be recreated during reboot. 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 index file is stored in the flash. During a 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. There is no guarantee that resources will be allocated to all SAPs. When the index file is not present, it is possible that saved the configuration does not execute successfully after the reboot.
 | Note: The index file used for QoS maps is different from the one used for storing interface indexes. |
9.1.1.2.1. Use of the keyword multipoint for default meter “11”
The system allows the 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 the 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 performs resource checks to ensure that resources needed to use the multipoint meter with all the FCs are available before allowing this change.
| Note:
|
9.1.1.2.1.1. Example uses of the multipoint meter
Example 1
In example 1, all FCs in the SAP ingress policy use the default meter 1 (for all traffic types). If the configure qos sap-ingress id meter 11 multipoint create command 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 example, because only the default FC “be” is in use, the multipoint meter is used to meter BUM traffic associated with default FC “be”.
The following example shows the policy after the configuration is changed.
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 configure qos sap-ingress id no meter 11 command to dissociate meter “11” from the FCs, and the FCs use only meter “1” (if no other meter configured explicitly).
Example 2
Starting with the policy in example 2, if the user executes the configure qos sap-ingress <id> meter 11 multipoint create command, the FC “be” continues to use meter “3” and the FC "af" uses meter "11" for BUM traffic. In this example, if the user executes the configure qos sap-ingress id fc be no multicast-meter command, the default meter “11” is used for FC "be".
Example 3
On execution of the configure qos sap-ingress id meter 11 multipoint create command, the FC "be" unknown-unicast traffic type continues to use meter 3 and broadcast and multicast traffic types use meter “11”.
In example 3, if a broadcast-meter was initially configured in the SAP-ingress policy and then followed by execution of the configure qos sap-ingress id meter 11 multipoint create command, the FC “be” changes to use meter “11” for multicast traffi, and broadcast traffic continues to use meter “3” for unknown-unicast traffic and meter “3” for unicast traffic.
In example 3, if the user executes configure qos sap-ingress id fc be no unknown-meter command, meter "3" is used for all traffic types classified to FC “be”. But, if the default meter "11" is defined in the policy, FC “be” uses meter “11” for BUM traffic.
9.1.1.3. Service ingress meter selection rules
This section describes the 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.
The following is a sample default policy configuration output.
The following describes the use of meters in a VPLS service, when meter “11” is not configured in the policy:
- If an 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 an 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 an 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 an 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 an 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. The unknown unicast traffic types use the explicitly defined multicast meter.
- If an FC is created with an explicit unicast meter, explicit broadcast meter, explicit unknown-unicast meter, and explicit multicast meter, use these meters for unicast, broadcast, unknown-unicast, and multicast traffic types respectively.
The following describes the use of meters in a VPLS service, when meter “11” is defined in the policy:
- If an 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 an 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 an 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 an 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 an FC is created with an explicit unicast meter, explicit broadcast meter, and explicit multicast meter, use these meters for unicast, broadcast, and multicast traffic types respectively. Unknown unicast traffic types use the explicitly defined multicast meter.
- If an FC is created with an explicit unicast meter, explicit broadcast meter, explicit unknown-unicast meter, and 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 and IES services.
| Note: These rules apply to IES services when PIM, multicast is not enabled in the service.
|
9.1.1.4. Service ingress QoS policy configuration considerations
The num-qos-classifiers command 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 that is in use, the system recomputes the resources required to accommodate the change. If the resources required exceed the configured value for num-qos-classifiers, the change is not allowed.
If more resources are needed than are configured in num-qos-classifiers for an existing policy, the following options are available:
- Copy the existing policy to a new policy, modify the num-qos-classifiers command, modify the match criteria entries, 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 using the no qos form of the command), change all the required parameters, and finally modify the SAP configuration to use the policy again.
| Note: Both these options have side-effects; for example, they can reset the statistics associated with the meters and potentially cause existing traffic classification not to take effect; however, the system ensures that the default policy is in use during the intermittent time when the policy changes are being made after the two options are performed. |
- In releases prior to release 3.0R1, the software always 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, when creating a SAP ingress policy, the 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, otherwise the command fails. Based on the service (VLL, VPLS, and so on) in which the SAP is configured, for the same SAP ingress policy the amount of resources required is different. The software validates that the number of QoS resources specified with the num-qos-classifiers command is sufficient for the match criteria, FC, and service specified, and the resources are available in hardware. If the validation fails, 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 type is set to ipv4-criteria and the policy is associated with a SAP, the ipv6-criteria or mac-criteria cannot be enabled in the same policy. If there is a need to change the criteria, the user must remove the association and then change the SAP ingress policy to use the new match criteria.
See Resource allocation for service ingress QoS policy classification rules for more information.
9.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, and so on. 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 resources 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 slices with fixed number of entries.
The number of slices allotted for a 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 specific slice can be used for MAC criteria, 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 criterion to use the available SAP ingress QoS resources on a first-come-first-served model. By default, the 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 slices of 256 entries. The following table describes the use of these entires by different types of match criteria.
| Note: Refer to the 7210 SAS Release Notes for information about services supported on different 7210 SAS platforms. The references to services in the following table appear for completeness and do not imply support is available. |
Table 37: SAP ingress resource allocation and match criteria types
Type of match criteria | Description |
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 entry from the slices 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 slice 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 slices and there are no slices 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 slices 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 entries from the slices 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 slice 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 two entries in hardware). In this example, user can have five SAPs using this policy and consuming 125 entries in total. These resources can be shared with policies that use IPv4 criteria, though it consumes two 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 slice is allocated to IPv6 criteria, software automatically adjusts the number of available entries in that slice 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 slices currently allocated for use by either IP-criteria or MAC-criteria or IPv6 criteria. The following are some special cases noted below for allocation of resources for default, dot1p-only and dscp-only SAP ingress policies.
|
The SAP ingress resource slices described in this section are different from the resources that are configured using the num-qos-classifiers command. The num-qos-classifiers command sets the limit on the resources needed per SAP ingress QoS policy. The resources set the maximum limit on the resources available for use by all the SAP ingress policies that are in use simultaneously on the system. The SR OS manages the resource slices allocated to the SAP ingress QoS policy pool and allocates the entries in the slices when a SAP ingress QoS policy is associated with a SAP. This means that a SAP specifies the amount of QoS resources it needs, using the num-qos-resources command (in the SAP ingress policy) and the system allocates the resources required by a SAP from the slices, depending on whether the SAP ingress policy uses ip-criteria, 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 slice are reserved for system use.
9.1.3. Computation of SAP ingress classification and meter resources used per SAP ingress policy
| Note: Refer to the 7210 SAS Release Notes for information about services supported on different 7210 SAS platforms. The references to services in the following table appear for completeness and do not imply support is available. |
This section provides information about the resource consumption per SAP ingress policy. Resources required by the SAP ingress policy are allocated from the ingress-internal-tcam resource pool, based on the amount of resources allocated for SAP ingress classification.
The user can 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 preceding equation is subject to system limits. The preceding 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 num-qos-classifiers command 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 items determine the number of QoS resources to be allocated for a 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 for information 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. These FCs are referred to as “FCs in use”.
9.1.3.1. Determining the number of classification entries
This section describes the rules and methods of determining the number of classification entries.
9.1.3.1.1. Rules for a SAP in a VPLS
Given the number of traffic types to use per “FC in use”, the following rules apply for a SAP in a VPLS service to determine the number of classification entries per FC in use:
- If an 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 an 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 an 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 entry in hardware. This assumes default multipoint meter “11” is not created by the user.
- If an 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 an 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 an 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 an 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 an 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. The unknown unicast traffic type uses the explicitly defined multicast meter. This requires three classification entries in hardware.
9.1.3.1.2. Rules for a SAP in a VLL, IES, or VPRN service with PIM/IP multicast disabled
For calculating the number of classification entries per FC for a SAP in a VLL, IES or VPRN service with PIM/ IP multicast disabled, the following rules apply:
- Multipoint meters cannot be used. Multipoint meters configured in a policy are 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.
9.1.3.1.3. Rules for a SAP in an IES or VPRN service with PIM/IP multicast enabled
Given the number of traffic types to use per “FC in use”, the following rules apply for a SAP in an IES and VPRN service enabled with PIM/IP multicast enabled to arrive at a number of classification entries per FC in use:
- If an FC is in use and is created without explicit meters, use default meter 1 for unicast traffic and multicast traffic. This requires one classification entry in hardware. This assumes the default multipoint meter 11 is not created by the user.
- If an 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 an 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 entry in hardware. This assumes default multipoint meter “11” is not created by the user.
- If an 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 an 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.
9.1.3.1.4. Calculating the number of classification entries per FC
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; 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. By default, two classification entries in hardware are required by an FC.
9.1.3.1.5. Determining the number of classification entries per policy (TC)
Taking into account the number of match criteria and the number of FCs used, use the following equation to determine the total number of classification entries per policy.
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 SAS 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.
9.1.3.1.6. Determining the number of policers/meters per policy (TP)
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 (TQ) = max ((TC), (2 * TP))
The number obtained is rounded off to next multiple of “2” greater than the TQ obtained using this equation.
The user configures the value of TQ using the num-qos-classifiers command.
For more examples and information about resource allocation, see Service ingress QoS policy configuration considerations.
9.1.3.2. Service ingress QoS policies resource usage examples
This section provides resource usage examples for service ingress QoS policies.
9.1.3.2.1. Example 1
In example 1, assuming the policy is attached to a SAP in a VPLS service, classification entries used per FC use the following computation.
Because this FC uses a 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.
Use the following equation to calculate the total classification entries used by this policy.
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 (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 number of meters used = 3 (because both FCs use meter 1, meter 3, and meter 11).
In this example, num-qos-classifiers 16 is used (that is, maximum of (8, (2 * 3))).
If the same policy were used for a SAP in an Epipe service, and all traffic is classified to a unicast traffic type and only unicast meters are used, the following computation is used.
Using the preceding equation, calculate the total classification entries used = 4 and meters used = 2.
9.1.3.2.2. Example 1a (default multipoint meter 11 is not used)
In example 1a, assuming the policy is attached to a SAP in a VPLS service, classification entries used per FC use the following computation.
Because this FC uses unicast meter for all traffic types, an entry to classify all traffic types to this FC explicitly is required.
Calculate the total classification entries used by this policy, using the following equation.
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 (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 (because FCs use meter 1 and meter 3).
In this example, num-qos-classifiers 4 is used (maximum of (4, (2 * 2))). The use of a unicast meter for all traffic-types allows QoS resources to be used efficiently.
If the same policy were used for a SAP in an Epipe service, and all traffic is classified to a unicast traffic type and only unicast meters are used, the following computations are used.
Using this equation, total classification entries used = 4 and meters used = 2.
Using the same policy for Epipe SAPs can lead to inefficient use of resources. Nokia recommends creating a different policy with the required number of resources (that is, with num-qos-classifiers 4).
9.1.3.2.3. Example 2
In example 2, assuming the policy is attached to a SAP in a VPLS service, classification entries used per FC use the following computation.
FC uses unicast meter and broadcast meter, so 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 this equation, the total classification entries used = 11 (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 (FCs use only meter 2, meter 3, and meter 11).
Therefore, in this example, num-qos-classifiers 16 is used (that is, a maximum of (12, (2*3))). Note that the system internally uses 18, instead of 16.
If the same policy were used for a SAP in an Epipe service, all traffic is classified to a unicast traffic type, and only unicast meters are used, use the following computation.
Using this equation, the total classification entries used = 4 and the total meters used = 1.
9.1.3.2.4. Example 2a (default multipoint meter 11 is not used)
In example 2a, assuming the policy is attached to a SAP in a VPLS service, classification entries used per FC use the following computation.
Because this FC uses a unicast meter for unicast, multicast, unknown-unicast traffic, and broadcast meter for broadcast traffic, so two entries are needed.
Using this equation to get the total classification, entries used = 8 (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 (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 used for a SAP in an Epipe service, all traffic is classified to a unicast traffic type and only unicast meters are used, use the following computation.
Using the preceding 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. Nokia recommends creating a different policy with the required number of resources (that is, with num-qos-classifiers 4).
9.1.3.2.5. Example 3
In example 3, assuming the policy is attached to a SAP in a VPLS service, classification entries used per FC use the following computation.
Because this FC uses unicast, broadcast, multicast, and unknown-unicast meter, four entries are required to identify these traffic types explicitly.
Because 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.
Because 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.
Because 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 preceding equation, the total classification entries used = 15 and the total meters used = 6.
If the same policy were used for a SAP in an Epipe service, all traffic is classified to a unicast traffic type and only unicast meters are used, use the following computation.
Using the preceding equation, the total classification entries used = 5 and the total meters used = 3 (because all FCs used only meter 1, meter 3, and meter 5).
9.1.3.2.6. Example 3a (default multipoint meter 11 is not used)
In example 3a, assuming the policy is attached to a SAP in a VPLS service, classification entries used per FC use the following computation.
Because this FC uses unicast, broadcast, multicast, and unknown-unicast meter, four entries are needed to identify these traffic types explicitly.
Because 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.
Because 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 unicast traffic.
Because 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.
Because no explicit meters are configured for FC “be”, it uses meter 1 for all traffic types and needs one entry to identify these traffic types.
Using the preceding equation, the total classification entries used = 12 and meters used = 5. The num-qos-classifiers CLI command can be set to 12 (the minimum value).
Using the same policy for a SAP in an Epipe service, all traffic is classified to a unicast traffic type and only unicast meters are used, the following computations are used.
Using the preceding equation, the total classification entries used = 5 and meters used = 3 (because all FCs used only meter 1, meter 3, and meter 5). For Epipe service, a policy with num-qos-resources 6 can be used.
9.1.3.2.7. Example 4
In example 4, assuming the policy is attached to a SAP in a VPLS service, classification entries used per FC use the following computation.
Because 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.
Because this FC uses unicast, broadcast, multicast and unknown-unicast meter, four entries are required to identify these traffic types explicitly.
Because 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.
Because 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.
Because 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 preceding equation, the total classification entries used = 21 and the total meters used = 8.
If the same policy were used for a SAP in an Epipe service, all traffic is classified to a unicast traffic type and only unicast meters are used, use the following computation.
Using the preceding equation, the total classification entries used = 7 and the total meters used = 4.
Using the same policy for Epipe SAP can lead to inefficient use of resources. Nokia recommends creating a different policy with the required number of resources (that is, num-qos-classifiers 16)
9.1.3.2.8. Example 4a (default multipoint meter 11 is not used)
In example 4a, assuming the policy is attached to a SAP in a VPLS service, classification entries used per FC use the following computation.
Because 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.
Because this FC uses unicast, broadcast, multicast, and unknown-unicast meter, four entries are needed to identify these traffic types explicitly.
Because 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.
Because 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).
Because 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.
Because this FC uses a single meter for all traffic-types only, a single meter and single entry is needed.
Using the preceding equation, the total classification entries used = 20 and meters used = 7. Therefore, in this example num-qos-classifiers 20 is used (the minimum value).
If the same policy were used for a SAP in an Epipe service, all traffic is classified to a unicast traffic type, and only unicast meters are used, use the following computation.
Using the preceding equation, the total classification entries used = 7 and meters used = 4.
Using the same policy for Epipe SAP can lead to inefficient use of resources. Nokia recommends creating a different policy with the required number of resources (that is, with num-qos-classifiers 8).
9.1.3.2.9. Example 5
In example 5, assuming the policy is attached to a SAP in a VPLS service, classification entries used per FC use the following computation.
Because 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.
Because 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.
Calculate the total classification entries used by this policy using the following equation.
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.
In example 5, num-qos-classifiers 72 is used (that is, a maximum of (48, (2 * 4)) = 48, rounded off to the next available numQosClassifier range.
If the same policy were used for a SAP in an Epipe service, all traffic is classified to a unicast traffic type and only unicast meters are used, use the following computation.
Calculate the total classification entries used by this policy using the following equation.
TC = (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 total meters used in this policy = 2.
For Epipe SAP, Nokia recommends defining another sap-ingress policy using num-qos-classifiers 16 (maximum of (16, (2 * 2)) = 16.
9.2. Basic configurations
A basic service ingress QoS policy must conform to the following:
- have a unique service ingress QoS policy ID
- allocate the number of classifier and meter resources needed for use
- have a QoS policy scope of template or exclusive
- have at least one default unicast FC meter/queue
- (optional) use multipoint FC meter/queue
9.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.
9.2.1.1. Service ingress QoS policy
| Note: A meter is available to limit the bandwidth per FC on service ingress. |
To create a service ingress policy, perform the following:
- Define a policy ID value. The system does not dynamically assign a value.
- Define a description that provides a brief overview of policy features.
- Specify the num-qos-classifiers command. The default value is 2. The number of meters/queue allocated is equal to half the number of classifiers specified.
- Specify a default FC for the policy. All packets received on an ingress SAP using this ingress QoS policy will be classified to the default FC.
- Define FC parameters by performing the following.
- 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 following 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 ingress meter and corresponding FC 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.1.1.1. Service ingress QoS meter
To create service ingress meter parameters, perform the following.
- Define a new meter ID value; the system does not dynamically assign a value.
- Configure 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.
9.2.1.1.2. SAP ingress FC
The following is a sample FC configuration output.
9.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.
9.2.1.1.4. Service ingress MAC match criteria
To configure service ingress policy MAC criteria, perform the following.
- Define a new entry ID value. Entries must be explicitly created; the system does not dynamically assign entries or a value.
- Associate the FC with a specific MAC criteria entry ID.
- Define a description. The description provides a brief overview of policy features.
The following is a sample ingress MAC criteria configuration output.
9.2.1.2. Applying service ingress policies
Apply SAP ingress policies to the following service SAPs:
9.2.1.2.1. Epipe service
The following sample configuration output shows an Epipe service configuration with SAP ingress policy 100 applied to the SAP.
9.2.1.2.2. VPLS
The following sample configuration output shows a VPLS service configuration with SAP ingress policy 100.
9.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.
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 it is applied.
9.3.1.1. Removing a QoS policy from service SAPs
The following Epipe service output examples show that the SAP service ingress reverts to policy-id 1 when the non-default policies are 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. Remove a policy from the QoS configuration
Use the following syntax to remove a configuration policy from the QoS configuration.
9.3.4. Editing QoS policies
You can change existing QoS 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 overwrite the original policy.