Service Egress QoS Queue

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

The following displays an egress QoS policy configuration:

Percent-Rate Support

The percent-rate command is supported for pir and cir parameters for both queues and policers. Also supported is the capability of specifying the rate as a percentage value of the line rate for sap-ingress and sap-egress qos policies. It is supported for both queues and policers. The user has the option of specifying percent-rate for pir and cir parameters. For pir, the range is 0.01 to 100.00, and for cir, the range is 0.00 to 100.00.

The rate can be also configured using the existing keyword rate in Kbps.

For queues, when the queue rate is in 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, when the port-limit is used the percent-rate is relative to the rate of the port (including the ingress-rate/egress-rate setting) to which the queue is attached. 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.

SAP-Egress QoS Policy:

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 which is not using HQoS is relative to its administrative PIR and can be approximated as (MBS[kB] × 8) / PIR[kbps]) in seconds. A queue’s PIR is set to max, 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 high-prio-only, hi-low-prio-only, 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 Mbps, the show output changes to:

The output shows that the operational MBS is now 50% of the administrative MBS and that the queue’s high-prio-only and hi-low-prio-only values have changed accordingly.

Egress SAP Forwarding Class and Forwarding Profile 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 (in or out) 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.

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 above 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 which use 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 FP2- and higher-based hardware, excluding when a HS-MDA is used. 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:

Dot1p Egress Remarking

Dot1p marking 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:

The precedence of the above commands is summarized as, 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, i.e. 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.

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 marked / determined using existing QoS fields: for example, the three MPLS EXP and Ethernet dot1p bits. Using certain combination(s) 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. Now 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

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

The precedence of the above commands is summarized as, from highest to lowest precedence:

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, i.e. 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.

DEI in IEEE 802.1ad

IEEE 802.1ad-2005 standard allows drop eligibility to be conveyed separately from priority in service VLAN TAGs (STAGs). The service VLAN TAG has a new format where the priority and discard eligibility parameters are conveyed in the three bit priority code point (PCP) field and respectively in the DE bit (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.

DEI in IEEE 802.1ah

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

The backbone VLAN ID (BVID) is a regular 802.1ad STAG. 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.

IEEE 802.1ad Use Case

Figure 15 illustrates 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 this 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 STAG.

Figure 15:  DE Aware 802.1ad Access Network 

The following shows an example of the QoS processing in more detail.

Figure 16 displays a simple example 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 STAG 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 STAG to classify the frames as in/out of profile. Color aware policing/metering can generate addition 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, ingress into the related SDP, the DE indication is used to classify the packets into an internal PHB.
5. 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.

IEEE 802.1ah Use Case

Figure 17 illustrates 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 STAG. 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/STAG: for example, the DE bit from the BVID header represents the QoS associated with the “Ethernet Tunnel” while the DE bit from the ITAG represent the service QoS.

Figure 17:  DE Aware PBB Topology  

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

DSCP/Prec Egress Remarking

DSCP/prec marking can be performed on egress for all services and with respect to the profile of the packet.

The following commands can be used to remark the DSCP/prec values at a SAP egress:

Remarking the DSCP/prec based on the profile result of egress policing must be enabled as the follows under the related policer configuration:

Queue Depth Monitoring

Queue depth monitoring gives more visibility to the operator 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 in nature. This is supported on FP2- and higher-based line cards.

An override (monitor-depth) 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 configuration below gives an example of enabling the monitoring of the depth of queue 1 on an Epipe SAP.

The queue depth can then be shown as follows:

The 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, in the above output, the queue depth was in the range of 51% to 60% for 3.22 percent of the polls, the polling was performed over an elapsed time of 11 minutes and 48 seconds, and the average polling interval was 99ms.

The monitoring is performed on the hardware queues corresponding to the configured queue. It is possible that the set of related hardware queues for a given configured queue changes 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 will only report occupancy information of all currently instantiated hardware queues, specifically, no attempt is made to 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 specific limit on the number of queues that can be monitored but the amount of each line card CPU’s resources allocated to the monitoring is bounded, consequently average polling interval will increase 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 reset to zero. Issuing a clear card will also clear this information. Packet drops caused at the pool level, rather than at the queue level, would result in lower queue depths being reported.

Service Ingress QoS Queue

To create service ingress queues parameters, define the following:

The following displays an ingress queue configuration:

Percent-Rate Support

The percent-rate command is supported for pir and cir parameters for both queues and policers. Also supported is the capability of specifying the rate as a percentage value of the line rate for sap-ingress and sap-egress qos policies. It is supported for both queues and policers. The user has the option of specifying percent-rate for pir and cir parameters. For pir, the range is 0.01 to 100.00, and for cir, the range is 0.00 to 100.00.

The rate can be also configured using the existing keyword rate in Kbps.

For queues, when the queue rate is in 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, when the port-limit is used the percent-rate is relative to the rate of the port (including the ingress-rate/egress-rate setting) to which the queue is attached. 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.

SAP Ingress QoS Policy:

Service Ingress Forwarding Class (FC)

The following displays a forwarding class and precedence configurations:

Service 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:

Service 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:

Service 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:

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 when using one of the following statements: 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.

This is supported on all FP2 and higher based line cards. 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 configured below) and directed to policer 1 while the remainder of the customer’s traffic is processed using ingress queue 1. This is shown in Figure 18.

Figure 18:  Ingress Criteria Classification Directly to Policer 

The configuration would be as follows:

Virtual Network Identifier (VNI) 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.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 feature is supported on FP2- and higher-based hardware.

The following restrictions also apply:

FC Mapping Based on EXP Bits

You can use the lsp-exp command to set your 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:

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 Services Guide for information about configuring service parameters on the 7750 SR and 7450 ESS.

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.

Copying and Overwriting QoS Policies

You can copy an existing service egress or 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.

The following output displays the copied policies:

Deleting QoS Policies

Every service SAP is associated, by default, with the appropriate egress or 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 egress or ingress policy, the association reverts to the default policy-id 1.

A QoS policy cannot be deleted until it is removed from all SAPs where they are applied.

Remove a Policy from the QoS Configuration