7.3.1. Service Ingress QoS Queue

To create a service ingress queue, define the following:

The following displays an ingress queue configuration:

7.3.2. Ingress Percent-Rate Support

The percent-rate command is supported in a SAP ingress QoS policy for pir and cir parameters for both queues and policers, with the fir parameter supported only for queues on FP4 hardware that is ignored when the related policy is applied to FP2- or FP3-based hardware. For pir, the range is 0.01 to 100.00, and for cir and fir, the range is 0.00 to 100.00.

For queues, when the queue rate is percent-rate, either a local-limit or a port-limit can be applied.

When the local-limit is used, the percent-rate is relative to the queue’s parent scheduler rate. If there is no parent scheduler rate, or its rate is max, the port-limit is used. When the port-limit is used, the percent-rate is relative to the rate of the port (including the ingress-rate setting) to which the queue is attached. The port-limit is the default.

For policers, the percent-rate rate is always relative to the immediate parent root policer/arbiter rate or the FP capacity.

The following shows a SAP ingress QoS policy configuration:

7.3.3. Ingress Forwarding Class (FC)

The following displays a forwarding class and precedence configurations:

7.3.4. Ingress IP Match Criteria

When specifying SAP ingress match criteria, only one match criteria type (IP/IPv6 or MAC) can be configured in the SAP ingress QoS policy.

The following displays an ingress IP criteria configuration:

7.3.5. Ingress IPv6 Match Criteria

When specifying SAP ingress match criteria, only one match criteria type (IP/IPv6 or MAC) can be configured in the SAP ingress QoS policy. This feature applies only to the 7750 SR and 7950 XRS.

The following displays an ingress IPv6 criteria configuration:

7.3.6. Tagging of Ingress Ip-criteria and Ipv6-criteria

The SAP ingress QoS policy allows the assignment of a tag to each IPv4/IPv6 criteria statement entry. This is useful when a single SAP ingress QoS policy needs to be used for a different service context and it is still needed to apply service specific entries at individual SAP level.

In this concept, the SAP ingress policy can contain entries with different tag values as well as untagged entries. The user configures a tag entry override per-SAP to select which tagged entries are included for the related SAP (untagged entries are always included). Using this tagging concept is mutually exclusive with matching on destination-port.

In the following example, a base configuration IPv4 prefix list is created together with two other lists (list1 and list2) that are used for different VPRN IP interfaces. Also, a base configuration IPv6 prefix list is created together with two other lists (list1 and list2) that are to be used for different VPRN IP interfaces.

The following entries are used for both the IPv4 and IPv6 criteria statement:

Example:

7.3.7. Ingress MAC Match Criteria

Both IP/IPv6 criteria and MAC criteria cannot be configured in the same SAP ingress QoS policy.

To configure service ingress policy MAC criteria, define the following:

The following displays an ingress MAC criteria configuration:

7.3.8. Ingress Criteria Classification Directly to Policer

It is possible to classify traffic directly to a policer, independent of the policer/queue assigned to the traffic’s forwarding class. This is supported at SAP ingress by configuring a policer in the action statement: ip-criteria, ipv6-criteria, or mac-criteria.

The standard mechanisms are still used to assign a forwarding class to the related traffic, and this forwarding class continues to be used for QoS processing at egress.

The use of explicitly configured broadcast, unknown, or multicast policers is not supported. QPPB processing takes precedence over this feature.

This could be used, for example, when it is required that ingress OAM traffic is not subject to the same QoS control as other customer traffic on a given SAP. The OAM traffic could be classified based on its source MAC address (for example, with an OUI of 00-xx-yy as shown in Figure 12) and directed to policer 1 while the remainder of the customer’s traffic is processed using ingress queue 1.

Figure 12:  Ingress Criteria Classification Directly to Policer 

The configuration would be as follows:

7.3.9. Virtual Network Identifier Classification

Virtual Network Identifier (VNI) classification is supported for VXLAN and VXLAN GPE traffic within a SAP ingress QoS policy. This classification is configured in the ip-criteria and ipv6-criteria contexts with type vxlan-vni (changed from the default type normal). The matching entry must be created with match protocol udp for IPv4 or match next-header udp for IPv6 and uses the vxlan-vni parameter within the match statement to match on a single VNI or a range of VNIs.

An alternative to SAP ingress VNI classification is queue group redirection, which provides a more advanced mechanism where individual VNIs can use their own access ingress and egress queue group instances for QoS control (see VXLAN VNI Queue Group Redirection).

The type cannot be changed when ip-criteria or ipv6-criteria entries are configured. If there are no ip-criteria or ipv6-criteria entries configured, the type can be changed from vxlan-vni to normal. The type can only be changed from normal to vxlan-vni if there are no ip-criteria or ipv6-criteria entries configured and if the SAP ingress QoS policy has not been applied to any object.

The following is an example where traffic received with a VNI of 1 is sent to policer 1 and VNIs 2 to 10 are sent to policer 2:

Ingress VNI classification is applicable to all Ethernet SAPs, except for PW-SAPs, B-VPLS SAPs, and CCAG SAPs, in any applicable service.

The following restrictions also apply:

7.3.10. FC Mapping Based on EXP Bits

Use the lsp-exp command to set the sap-ingress qos policy on Ethernet L2 SAPs to perform FC mapping based on EXP bits.

The lsp-exp option causes the forwarding class and drop priority of incoming traffic to be determined by the mapping result of the EXP bits in the top label.

The following example displays FC mapping based on EXP bits:

7.3.11. Storing Match Criteria Entries

FP2-, FP3-, and FP4-based cards store QoS policy match-criteria entries in dedicated memory banks in hardware also referred to as CAM tables:

7.4.1. Service Egress QoS Queue

To create a service egress QoS queue, define the following:

The following displays an egress QoS policy configuration:

7.4.2. Egress Percent-Rate Support

The percent-rate command is supported in a SAP egress QoS policy for pir and cir parameters for both queues and policers. For pir, the range is 0.01 to 100.00, and for cir, the range is 0.00 to 100.00.

For queues, when the queue rate is percent-rate, either a local-limit or a port-limit can be applied.

When the local-limit is used, the percent-rate is relative to the queue’s parent scheduler rate or the agg-rate rate at egress. If there is no parent scheduler rate or agg-rate rate, or those rates are max, the port-limit is used. When the port-limit is used, the percent-rate is relative to the rate of the port (including the egress-rate setting) to which the queue is attached. The port-limit is the default.

For policers, the percent-rate rate is always relative to the immediate parent root policer/arbiter rate or the FP capacity.

The following shows a SAP egress QoS policy configuration:

7.4.3. Dynamic MBS for Egress Queue Group Queues

Dynamic MBS is used to constrain the maximum delay experienced by the traffic forwarded through an egress queue group queue when the operational PIR of the queue is modified as part of the HQoS algorithm.

The approximate maximum delay of traffic through a queue due to the length of the queue, when the queue is not using HQoS, is relative to its administrative PIR and can be approximated as (MBS[kB] × 8) / PIR[kb/s]) in seconds. A queue’s PIR is set to max, and its administrative PIR is set to the rate of the port to which the queue is attached.

When using HQoS, the PIR is modified by the HQoS algorithm to give an operational PIR that is equal to or lower than the administrative PIR. As the operational PIR changes, the delay through the queue can also change if the length of the queue is fixed. Reducing the operational PIR could increase the delay, while increasing the operational PIR could reduce the delay. Enabling dynamic MBS on a queue allows the system to change the administrative MBS of the queue in a ratio of operational PIR to administrative PIR, giving an operational MBS, which aims to maintain the maximum queue delay. A queue’s drop tails and WRED slope parameters are defined as percentages of the MBS and are, therefore, adjusted accordingly.

When any of the queue parameters are reduced, packets that are already in the queue will not be affected and will be forwarded. Reducing these parameters will constrain the latency for newly arriving packets, but those packets already in the queue before the new parameter values were set will be forwarded with the delay associated with the actual queue depth when the packet was enqueued (based on the previous parameter values).

The configured CBS is used as a minimum operational MBS. The maximum MBS is capped by the maximum administrative MBS (1 GB).

If the operational MBS changes such that its value is similar or equal to the configured CBS, the system increases the CBS to ensure that buffers can be requested from the correct portion of the buffer pool (shared or reserved). This operation is automatic, and the CBS reverts to its configured value if the MBS is increased sufficiently. The automatic increase in the CBS could, however, cause the resv-cbs red or amber alarms to be raised if the increase in the related queues’ CBS results in the total CBS assigned (but not necessarily used) matching or exceeding the resv-cbs red and amber thresholds.

If a LAG is used together with pool-per-queue, the related hardware queues exist in their own pool in the egress WRED megapool on a given FP and the operational MBS is used to size the shared part of the pool with the sum of the CBS defining the reserved part of the pool.

Dynamic MBS is supported for both native FP and pool-per-queue queues within an egress queue group template, which can be applied to access or network Ethernet ports and used for egress network interface traffic, egress SAP traffic, and subscriber egress policed traffic.

The configuration of dynamic MBS and queue depth monitoring are mutually exclusive.

Dynamic MBS is configured as follows:

The operational MBS can be shown using the show pools and show qos scheduler-hierarchy commands.

The following example shows the use of dynamic MBS. A queue group template is applied to port 5/1/1 configured with multiple queues using HQoS, one of which has the following parameters:

Without any traffic in the other queues constraining the operational PIR on this queue, the MBS used is the administrative MBS.

If traffic is sent to the other queues in the queue group such that the operational PIR of queue 1 is reduced to 25 Mb/s, the show output changes to:

The output shows that the operational MBS is now 50% of the administrative MBS and that the queue’s drop tails have changed accordingly.

7.4.4. Egress SAP FC and FP Overrides

An access egress packet’s forwarding class can be changed to redirect the packet to an alternate queue than the ingress forwarding class determination would have used. An access egress packet’s profile can also be changed to modifying the congestion behavior within the egress queue. In both cases, egress marking decisions will be based on the new forwarding class and profile as opposed to the egress forwarding class or profile. The exception is when ingress remarking is configured. An ingress remark decision will not be affected by egress forwarding class or egress profile overrides.

The SAP egress QoS policy allows reclassification rules that are used to override the ingress forwarding class and profile of packets that egress a SAP where the QoS policy is applied.

Dot1p, IP precedence, DSCP, and IP quintuple entries can be defined, each with an explicit forwarding class or profile override parameters. The reclassification logic for each entry follows the same basic hierarchical behavior as the classification rules within the SAP ingress QoS policy. Dot1p, IP precedence, and DSCP have the lowest match priority while the IP criteria (quintuple) entries have the highest.

When an optional parameter (such as profile) for Dot1p, IP precedence, or DSCP entries is not specified, the value from the lower priority IP quintuple match for that parameter is preserved. If the IP precedence values overlap with DSCP values in that they will match the same IP header TOS field, the DSCP entry parameters will override or remove the IP precedence parameters. When none of the matched entries override a parameter, the ingress classification is preserved.

7.4.5. Egress IP Match Criteria

The following displays a SAP egress QoS policy IP criteria configuration:

7.4.6. Egress IPv6 Match Criteria

The following displays a SAP egress QoS policy IPv6 criteria configuration:

7.4.7. Egress Criteria Classification Directly to Policer

It is possible to classify traffic directly to a policer, independent of the policer/queue assigned to the traffic’s forwarding class. This is supported at SAP egress by configuring a policer in the action statement within an ip-criteria or ipv6-criteria statement.

The policed traffic by default exits through one of the following methods:

The number of configuration combinations of a policer and one of the preceding methods is capped at 63 within a given SAP egress QoS policy. For two or more definitions to be counted as a single combination, their action statement must have the same policer ID, the same queue ID (if specified in either statement), the same port-redirect-queue-group (if specified in either statement), and the parameter use-fc-mapped-queues (if specified in either statement).

The forwarding class and profile used are irrelevant when considering the number of combinations. For example, it is possible to configure 32 policers with traffic exiting queue 1, but then, only 31 of the same policers are exiting queue 2; this would use all 63 combinations. A resource is also allocated per FP where each combination configured corresponds to an egress bypass entry used in the FP per sap-instance or per subscriber-sap-sla instance that uses the egress qos policy. The number of egress bypass entries available on an FP, together with the number allocated and the number free, can be seen using the following tools command.

This is supported on all hardware systems. QPPB processing takes precedence over this feature.

This could be used, for example, when it is required that egress traffic with a DSCP value EF is to be policed instead of shaped in a queue on a given SAP. The traffic could be classified based on its DSCP value and directed to policer 1 while the remainder of the customer’s traffic is processed using egress queue 1. This is shown in Figure 13.

Figure 13:  Egress SAP 

The configuration would be as follows:

7.4.8. Storing Match Criteria Entries

FP2-, FP3-, and FP4-based cards store QoS policy match-criteria entries in dedicated memory banks in hardware, also referred to as CAM tables:

7.4.9. Dot1p Egress Remarking

Dot1p remarking can be performed on egress for all services and with respect to the profile of the packet and the VLAN tag.

The following commands can be used to remark the dot1p values at a SAP egress:

All inplus-profile traffic is marked with the same value as in-profile traffic.

The precedence of these commands is summarized as follows, from highest to lowest precedence:

The configuration of qinq-mark-top-only under the SAP egress takes precedence over the use of the dot1p-inner in the policy, that is, the inner VLAN tag is not remarked when qinq-mark-top-only is configured. The marking used for the inner VLAN tag is based on the current default, which is governed by the marking of the packet received at the ingress to the system. If qinq-mark-top-only is omitted, both the inner and outer VLAN tags are remarked.

Remarking the inner dot1p is not supported based on the profile result of egress policing.

The egress remarking occurs after any egress classification.

7.4.9.1. DEI Egress Remarking

It is often desirable to meter traffic from different users to ensure fairness or to meet bandwidth guarantees. Dropping all traffic in excess of a committed rate is likely to result in severe under-utilization of the networks, since most traffic sources are bursty in nature. It is burdensome to meter traffic at all points in the network where bandwidth contention occurs. One solution is to mark those frames in excess of the committed rate as drop eligible on admission to the network.

Previously, the discard eligibility was determined using existing QoS fields; for example, the three MPLS EXP and Ethernet dot1p bits. Using certain combinations of these bits to indicate both forwarding class (priority) and discard eligibility meant decreasing the number of forwarding classes that can be differentiated in the network.

IEEE 802.1ad-2005 and IEEE 802.1ah standards allow drop eligibility to be conveyed separately from priority, preserving all the eight forwarding classes (priorities) that could be indicated using the three 802.1p bits. All the previously introduced traffic types will be marked as drop eligible. Customers can continue to use the dot1p markings with the enhancement of changing the dot1p value used, in access, based on the profile information.

The following commands can be used to remark the DE values at a SAP egress:

CLI Syntax:

sap-egress <policy-id> create

fc <fc-name> create

de-mark [force <de-value>]

de-mark-inner [force <de-value>]

de-mark-outer [force <de-value>]

exit

exit

By default, the DE bit is set to 0 for inplus-profile and in-profile traffic and 1 for out-of-profile and exceed-profile traffic, unless explicitly forced.

The precedence of these commands is summarized from highest to lowest precedence, as follows:

1. de-mark-outer used for outer tag markings
2. de-mark-inner used for inner tag markings
3. existing de-mark used for marking both tags
4. markings taken from packet received at ingress

The configuration of qinq-mark-top-only under the SAP egress takes precedence over the use of the de-mark-inner in the policy, that is, the inner VLAN tag is not remarked when qinq-mark-top-only is configured. The marking used for the inner VLAN tag is based on the current default, which is governed by the marking of the packet received at the ingress to the system. If qinq-mark-top-only is omitted, both the inner and outer VLAN tags are remarked.

Remarking the inner DE bit is not supported based on the profile result of egress policing.

The egress remarking occurs after any egress classification.

7.4.9.1.1. DEI in IEEE 802.1ad

The IEEE 802.1ad-2005 standard allows drop eligibility to be conveyed separately from priority in-service VLAN TAGs (S-TAGs). The S-TAG has a new format where the priority and discard eligibility parameters are conveyed in the 3-bit priority code point (PCP) field and in the DE bit, respectively (see Figure 14).

Figure 14:  DE Bit in the 802.1ad S-TAG 

The introduction of the DE bit allows the S-TAG to convey eight forwarding classes/distinct priorities, each with a drop eligible indication.

When DE bit is set to 0 (DE = FALSE), the related packet is not discard eligible. This is the case for the packets that are within the CIR limits and must be given priority in case of congestion. If the DEI is not used or backwards compliance is required, the DE bit should be set to zero on transmission and ignored on reception.

When the DE bit is set to 1 (DE = TRUE), the related packet is discard eligible. This is the case for the packets that are sent above the CIR limit. In case of congestion, these packets will be the first ones to be dropped.

7.4.9.1.2. DEI in IEEE 802.1ah

IEEE 802.1ah (PBB) standard provides a dedicated bit for DE indication in both the backbone VLAN ID (BVID) and the ITAG.

The BVID is a regular 802.1ad S-TAG. Its DE bit may be used to convey the related tunnel QoS throughout an Ethernet backbone.

The ITAG header offers also an I-DEI bit that may be used to indicate the service drop eligibility associated with this frame.

These bits must follow the same rules as described in DEI in IEEE 802.1ad.

7.4.9.1.3. IEEE 802.1ad Use Case

Figure 15 shows an example of a topology where the new DE feature may be used: a DE aware, 802.1ad access network connected via a regular SAP to a router PE.

In the following example, PE1 can ensure coherent processing of the DE indication between the 802.1ad and the MPLS networks. For example, for packets ingressing the SAP connected to 802.1ad access, read the DE indication and perform classification, color aware metering/policing, marking of the related backbone QoS fields, and selective discarding of the frames throughout the queueing system, based on their discard eligibility. In addition, packets egressing the SAP towards the 802.1ad access provide proper DE indication by marking the new DE bit in the S-TAG.

Figure 15:  DE Aware 802.1ad Access Network 

Figure 16 shows an example of the QoS processing of the DEI processing steps for the IEEE 802.1ad use case for both ingress and egress directions (from a PE1 SAP perspective).

Figure 16:  DEI Processing Ingress into the PE1 SAP 

The following steps related to DEI are involved in the QoS processing as the packet moves from left to right:

1. The QinQ access device sets the DE bit from the S-TAG based on the QoS classification or on the results of the metering/policing for the corresponding customer UNI.
2. The SAP on PE1 may use the DE bit from the customer S-TAG to classify the frames as in/out-of-profile. Color aware policing/metering can generate additional out-of-profile packets as the result of packet flow surpassing the CIR.
3. When the packet leaves PE1 via SDP, the DE indication must be copied onto the appropriate tunnel QoS fields (outer VLAN ID and/or EXP bits) using the internal PHB (per hop behavior) of the packet (for example, the FC and Profile).
4. As the packet arrives at PE2, on ingress into the related SDP, the DE indication is used to classify the packets into an internal PHB.
5. On egress from the PE2 SAP, the internal PHB may be used to perform marking of the DE bit.

A combination of two access networks can be possible. If PBB encapsulation is used, the configuration used for DE in SAP and SDP policies applies to both BVID and ITAG DE bits. When both fields are used, the BVID takes precedence.

7.4.9.1.4. IEEE 802.1ah Use Case

Figure 17 shows an example of a PBB topology where the DE feature can be used. The processing requirements highlighted in the 802.1ad use case apply to the 802.1ah BVID, format and etype, these being identical with the 802.1ad S-TAG. In addition, the DE bit from the 802.1ah ITAG header may need to be processed following the same rules as for the related field in the BVID/S-TAG; for example, the DE bit from the BVID header represents the QoS associated with the “Ethernet Tunnel” while the DE bit from the ITAG represents the service QoS.

Figure 17:  DE Aware PBB Topology  

In this example, the BVID is not used for a part of the network, leaving the I-DEI bit from the ITAG as the only option for a dedicated DE field. If both are included, the QoS information from the BVID is to be used.

7.4.10. DSCP and IP Precedence Egress Remarking

DSCP and IP precedence remarking can be performed on egress for layer 3 services only with respect to the profile of the packet.

Use the following CLI syntax to remark the DSCP and IP precedence values at a SAP egress:

All inplus-profile traffic is marked with the same value as in-profile traffic.

Remarking the DSCP and IP precedence based on the profile result of egress policing must be enabled under the related policer configuration, as follows:

7.4.11. Queue Depth Monitoring

Queue-depth monitoring gives more visibility to the user of the queue depths being experienced on a set of queues when the traffic is bursty. The instantaneous depth of a queue can be seen using the show pools command, whereas queue-depth monitoring shows the variation in queue depth over a period of time. It is applicable to SAP ingress unicast and multipoint queues and SAP egress queues, and for ingress and egress access and network queue group queues used by any service or network interfaces. The monitoring uses a polling mechanism by the line card CPU. Consequently, the results provided are statistical.

An override (monitor-depth command) is used to enable queue-depth monitoring, which is configured under the SAP or queue group queue-overrides. There are show and clear commands, using the queue-depth parameter, for both service SAPs and port queue groups with associated MIB variables.

The queue depth information is shown in the following example.

The preceding output shows the percentage of polls for each 10% range of queue depth. The output includes the name of the queue, its MBS configuration, the average elapsed time over which the depth was monitored (this is the elapsed time since the start of monitoring or the last clear), and the weighted average polling interval.

For example, the output shows a queue depth in the range of 51% to 60% for 3.22% of the polls, for polling that was performed over an elapsed time of 11 minutes and 48 seconds, and with an average polling interval of 99 milliseconds.

The monitoring is performed on the hardware queues corresponding to the configured queue. The set of related hardware queues for a specific configured queue could change over time; for example, when LAG ports are added or removed resulting in monitored hardware queues being added or removed. If the set of hardware queues for the configured queue changes, the system only reports occupancy information of all currently instantiated hardware queues; it does not keep historical occupancy information.

The average polling interval is weighted based on the elapsed monitoring time of the individual hardware queues corresponding to the configured queue, and the elapsed monitoring time is averaged over the same set of hardware queues.

There is no limit on the number of queues that can be monitored, but the amount of each line card’s CPU resources allocated to the monitoring is bounded. Consequently, the average polling interval increases as more queues are monitored on the line card.

If the MBS of a queue is modified, the occupancy information is cleared, and the elapsed timers are reset to zero. Issuing a clear card command also clears this information. Packet drops caused at the pool level, rather than at the queue level, results in lower queue depths being reported

At egress, sap-egress queues as well as queue-groups used at network egress or sap-egress, the monitor-queue-depth command provides two additional parameters.

The fast-polling parameter enables polling of the hardware queue-depth by the on-chip CPU. This supports reduced polling to the order of 10 ms, depending on number of queues with fast-polling enabled. The values are integrated and reported in the same fashion as previously described. The main advantage of the fast-polling option is that short-term burst can be detected by the monitor-queue-depth command.

The violation-threshold parameter, is used to set the queue-depth threshold and record the number of violations that occurred. This supports frequency monitoring of certain bursts that can occur in the traffic; allowing for better capacity planning.

All information gathered by the queue-depth monitoring feature is available in YANG state model and hence it can be monitored through telemetry.

7.5.1. Applying Service Ingress and Egress Policies

Apply SAP ingress and egress policies to the following service SAPs:

Refer to the Subscriber Services Overview section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Overview Guide for information about configuring service parameters on the 7750 SR and 7450 ESS.

7.5.2. Editing QoS Policies

QoS existing policies and entries can be edited. 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, then write over the original policy.

7.5.3. Copying and Overwriting QoS Policies

Existing service egress or ingress policy can be copied, renamed 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.

The following output displays the copied policies:

7.5.4. Deleting QoS Policies

Every service SAP is associated, by default, with the appropriate egress or ingress policy (policy-id 1). The default policy can be replaced with a customer-configured policy but cannot entirely remove the policy from the SAP configuration. When a non-default service egress or ingress policy is removed, 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.

7.5.5. Removing a Policy from the QoS Configuration