Service ingress and egress QoS policies

Overview

There is one default service ingress policy and one default service egress policy. Each policy can have up to 32 ingress queues and 8 egress queues per service.

The default policies can be copied and modified but they cannot be deleted. The default policies are identified as policy ID 1.

The default policies are applied to the appropriate interface, by default. For example, the default SAP ingress policy is applied to access ingress SAPs. The default SAP egress policy is applied to access egress SAPs. Other QoS policies must be explicitly associated.

For information about the tasks and commands necessary to access the CLI and to configure and maintain routers, see the Entering CLI Commands chapter in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide.

Basic configurations

A basic service egress QoS policy must have the following:

  • a unique service egress QoS policy ID

  • a QoS policy scope of template or exclusive

  • at least one defined default queue

A basic service ingress QoS policy must have the following:

  • a unique service ingress QoS policy ID

  • a QoS policy scope of template or exclusive

  • at least one default unicast forwarding class queue

  • at least one multipoint forwarding class queue

Configuring and applying QoS policies is optional. If no QoS policy is explicitly applied to a SAP or IP interface, a default QoS policy is applied.

Service ingress QoS policy

To create a service ingress policy, define the following:

  • a policy ID value. The system does not dynamically assign a value.

  • a description. The description provides a brief overview of policy features.

  • a default forwarding class for the policy. All packets received on an ingress SAP using this ingress QoS policy are classified to the default forwarding class.

  • a default priority for all packets received on an ingress SAP using this policy

  • mappings from incoming packet contents to a forwarding class, then separately, from the forwarding class to queue

  • forwarding class parameters:

    • Modify the multicast-queue default value to override the default multicast forwarding type queues mapping for fc fc-name.

    • Modify the unknown-queue default value to override the default unknown unicast forwarding type queues mapping for fc fc-name.

    • Modify the broadcast-queue default value to override the default broadcast forwarding type queues mapping for fc fc-name.

  • a precedence value for the forwarding class or enqueuing priority when a packet is marked with an IP precedence value

  • IP, IPv6, and MAC-based SAP ingress policies to select the appropriate ingress queue and corresponding forwarding class for matched traffic

  • a SAP ingress policy 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 displays an service ingress policy configuration:

A:ALA-7>config>qos>sap-ingress# info
----------------------------------------------
...
        sap-ingress 100 create
            description "Used on VPN sap"
...
----------------------------------------------
A:ALA-7>config>qos>sap-ingress#

Service ingress QoS queue

To create a service ingress queue, define the following:

  • a new queue ID value. The system does not dynamically assign a value

  • queue parameters. Ingress queues support multipoint queues, explicit and auto-expedite hardware queue scheduling, and parent virtual scheduler definition.

The following displays an ingress queue configuration:

A:ALA-7>config>qos# info
#------------------------------------------
echo "QoS Policy Configuration"
#------------------------------------------ 
...
        sap-ingress 100 create
            description "Used on VPN sap"
            queue 1 create
            exit
            queue 2 multipoint create
            exit
            queue 10 create
                parent VPN_be
                rate 11000
            exit
            queue 12 create
                parent VPN_priority
                rate 11000
            exit
            queue 13 create
                parent VPN_reserved
                rate 1
            exit
            queue 15 create
                parent VPN_video
                rate 1500 cir 1500
            exit
            queue 16 create
                parent VPN_voice
                rate 2500 cir 2500
            exit
            queue 17 create
                parent VPN_nc
                rate 100 cir 36
            exit
            queue 20 multipoint create
                parent VPN_be
                rate 11000
            exit
            queue 22 multipoint create
                parent VPN_priority
                rate 11000
            exit
            queue 23 multipoint create
                parent VPN_reserved
                rate 1
            exit
            queue 25 multipoint create
                parent VPN_video
                rate 1500 cir 1500
            exit
            queue 26 multipoint create
                parent VPN_voice
                rate 2500 cir 2500
            exit
            queue 27 multipoint create
                parent VPN_nc
                rate 100 cir 36
            exit
...
#------------------------------------------
A:ALA-7>config>qos# 

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 or later hardware that is ignored when the related policy is applied to 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:

*A:PE>config>qos>sap-ingress# queue 1 percent-rate
  - no percent-rate
  - percent-rate <pir-percent> [cir <cir-percent>] [fir <fir-percent>] [port-limit | local-limit] [fir <fir-percent>]
  - percent-rate <pir-percent> police [port-limit | local-limit]

 <pir-percent>        : [0.01..100.00]
 <cir-percent>        : [0.00..100.00]
 <fir-percent>        : [0.00..100.00]
 <police>             : keyword
 <port-limit | local-*> : keyword


*A:PE>config>qos>sap-ingress# policer 1 percent-rate
  - no percent-rate
  - percent-rate <pir-percent> [cir <cir-percent>]

 <pir-percent>        : [0.01..100.00]
 <cir-percent>        : [0.00..100.00]


*A:PE>config>qos>sap-ingress#

Ingress forwarding class (FC)

The following displays a forwarding class and precedence configurations:

A:ALA-7>config>qos# info
#------------------------------------------
...
            fc af create
                queue 12
                broadcast-queue 22
                multicast-queue 22
                unknown-queue 22
            exit
            fc be create
                queue 10
                broadcast-queue 20
                multicast-queue 20
                unknown-queue 20
            exit
            fc ef create
                queue 13
                broadcast-queue 23
                multicast-queue 23
                unknown-queue 23
            exit
            fc h1 create
                queue 15
                broadcast-queue 25
                multicast-queue 25
                unknown-queue 25
            exit
            fc h2 create
                queue 16
                broadcast-queue 26
                multicast-queue 26
                unknown-queue 26
            exit
            fc nc create
                queue 17
                broadcast-queue 27
                multicast-queue 27
                unknown-queue 27
            exit
            prec 0 fc be
            prec 2 fc af
            prec 3 fc ef
            prec 5 fc h1
            prec 6 fc h2
            prec 7 fc nc
...
#------------------------------------------
A:ALA-7>config>qos# 

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:

A:ALA-7>config>qos# info
...
#------------------------------------------
echo "QoS Policy Configuration"
#------------------------------------------
...
        sap-ingress 100 create
...
            ip-criteria
                entry 10 create
                    description "Entry 10-FC-AF"
                    match protocol 6
                        src-ip 10.10.10.103/24
                    exit
                    action fc af priority high
                exit
                entry 20 create
                    description "Entry 20-FC-BE"
                    match protocol 17
                        dst-port eq 255
                    exit
                    no action
                exit
            exit
        exit
..
#------------------------------------------
A:ALA-7>config>qos# 

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:

A:ALA-48>config>qos>sap-ingress# info
----------------------------------------------
            queue 1 create
            exit
            queue 11 multipoint create
            exit
            ip-criteria
            exit
            ipv6-criteria
                entry 10 create
                    description "IPv6 SAP-ingress policy"
                    match 
                        src-ip 2001:db8:1000::/64
                        dst-ip 2001:db8:2000::/64
                    exit
                    action fc be priority low
                exit
                entry 20 create
                    description "Entry 20-FC-AF"
                    match next-header tcp
                        src-port eq 500
                    exit
                    action fc af priority high
                exit
            exit
----------------------------------------------
A:ALA-48>config>qos>sap-ingress#

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 and matching on destination-port are mutually exclusive.

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:

  • VPRN 1/int: 10, 20, 30

  • VPRN 2/int: 10, 20, 30, 1000

  • VPRN 3/int: 10, 20, 30, 2000

Example:

configure
    qos
        match-list
            ip-prefix-list "ipv4-base-config" create
                prefix 10.0.0.0/16
                prefix 10.1.0.0/16
            exit
            ip-prefix-list "list1" create
                prefix 172.16.1.0/24
                prefix 172.16.2.0/24
            exit
            ip-prefix-list "list2" create
                prefix 192.168.1.0/24
                prefix 192.168.2.0/24
            exit
            ipv6-prefix-list "ipv6-base-config" create
                prefix 2001:db8:1000::/64
                prefix 2001:db8:2000::/64
            exit
            ipv6-prefix-list "list1" create
                prefix 2001:db8:3000::/64
                prefix 2001:db8:4000::/64
            exit
            ipv6-prefix-list "list2" create
                prefix 2001:db8:5000::/64
                prefix 2001:db8:6000::/64
            exit
        exit
        sap-ingress 10 name "10" create
            queue 1 create
            exit
            queue 11 multipoint create
            exit
            policer 1 create
            exit
            policer 2 create
            exit
            ip-criteria
                type tagged-entries
                entry 10 create 
                    match
                        src-ip ip-prefix-list "ipv4-base-config"
                    exit
                    action fc "l2" policer 1
                exit
                entry 20 create
                    match
                        src-ip 10.2.0.0/16
                    exit
                    action fc "af" policer 2
                exit
                entry 30 create
                    match
                        src-ip 10.3.0.0/16
                    exit
                    action fc "af"
                exit
                entry 1000 create 
tag 1
                    match
                        src-ip ip-prefix-list "list1"
                    exit
                    action fc "l1"
                exit
                entry 2000 create 
tag 2
                    match
                        src-ip ip-prefix-list "list2"
                    exit
                    action fc "ef"
                exit
            exit
        exit
            ipv6-criteria
                type tagged-entries
                entry 10 create 
                    match
                        src-ip ipv6-prefix-list "ipv6-base-config"
                    exit
                    action fc "l2" policer 1
                exit
                entry 20 create
                    match
                        src-ip 10.2.0.0/16
                    exit
                    action fc "af" policer 2
                exit
                entry 30 create
                    match
                        src-ip 10.3.0.0/16
                    exit
                    action fc "af"
                exit
                entry 1000 create 
tag 1
                    match
                        src-ip ip-prefix-list "list1"
                    exit
                    action fc "l1"
                exit
                entry 2000 create 
tag 2
                    match
                        src-ip ip-prefix-list "list2"
                    exit
                    action fc "ef"
                exit
            exit
        exit
    exit
    service
        vprn 1 name "1" customer 1 create
            interface "int" create
                address 10.10.10.1/24
                sap 1/1/1:1 create
ingress
    sap-ingress "10"
                exit
            exit
        exit
        vprn 2 name "2" customer 1 create
            interface "int" create
                address 10.20.20.1/24
                sap 1/1/1:2 create
                    ingress
    sap-ingress "10"
                        criteria-overrides
                            ip-criteria
                                activate-entry-tag 1
                            ipv6-criteria
                                activate-entry-tag 1
                        exit
                    exit 
                exit
            exit
        exit
        vprn 3 name "3" customer 1 create
            interface "int" create
                address 10/30/30.1/24
                sap 1/1/1:3 create
                    ingress
    sap-ingress "10"
                        criteria-overrides
                            ip-criteria activate-entry-tag 2
                            ipv6-criteria activate-entry-tag 2
                        exit
                    exit 
                exit
            exit
        exit
    exit

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:

  • a new entry ID value. Entries must be explicitly created. The system does not dynamically assign entries or a value.

  • the action to associate the forwarding class or enqueuing priority with a specific MAC criteria entry ID

  • a description. The description provides a brief overview of policy features.

  • match criteria for ingress SAP QoS policy. Optionally, specify an IP protocol to be used as an ingress SAP QoS policy match criterion.

The following displays an ingress MAC criteria configuration:

A:ALA-7>config>qos# info
...
#------------------------------------------
echo "QoS Policy Configuration"
#------------------------------------------
...
        sap-ingress 101 create
...
            mac-criteria
                entry 10 create
                    description "Entry10-low prio"
                    match
                        dst-mac 04-67-ff-00-00-01 ff-ff-ff-ff-ff-ff
                        dot1p 7 7
                    exit
                    action fc be priority low
                exit
            exit
        exit
#------------------------------------------
A:ALA-7>config>qos# 

VLAN ID matching

On ingress, VLAN ID matching may be used to set QoS on SAP ingress. The matching rules are the same as for VID filter (See ‟VID filters” in the Filter Policies section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide) but the action allows setting of the forwarding class.

For example, to set the forwarding class of all VIDs with 6 in the lower 3 bits of the VID, a filter (as follows) could be constructed, then ingress qos 5 could be applied to any SAP that requires the policy.

qos
        sap-ingress 5 create
            queue 1 create
            exit
            queue 11 multipoint create
            exit
            mac-criteria
                type vid
                entry 1 create
                    match frame-type ethernet-II
                        outer-tag 6 7
                    exit
                    action fc "af"
                exit
            exit
        exit
    exit

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 specific 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 Ingress criteria classification directly to policer) and directed to policer 1 while the remainder of the customer’s traffic is processed using ingress queue 1.

Figure 1. Ingress criteria classification directly to policer

The configuration would be as follows:


        sap-ingress 10 create
            queue 1 create
            exit
            queue 11 multipoint create
            exit
            policer 1 create
            exit
            mac-criteria
                entry 10 create
                    match
                        src-mac 00-xx-yy-00-00-00 ff-ff-ff-00-00-00
                    exit
                    action policer 1
                exit
            exit
        exit

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:

        sap-ingress 10 create
            queue 1 create
            exit
            queue 11 multipoint create
            exit
            policer 1 create
            exit
            policer 2 create
            exit
            ip-criteria
                type vxlan-vni
                entry 10 create
                    match protocol udp
                        vxlan-vni eq 1
                    exit
                    action policer 1
                exit
                entry 20 create
                    match protocol udp
                        vxlan-vni range 2 10
                    exit
                    action policer 2
                exit
            exit
        exit

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:

  • Source and destination port matching on a SAP, on which a SAP ingress QoS policy is applied that has ip-criteria or ipv6-criteria statements with type vxlan-vni, is not available for:

    • IPv4 QoS classification for VXLAN or VXLAN GPE traffic

    • IPv6 QoS and filter classification for VXLAN or VXLAN GPE traffic

    If the criteria type is set to vxlan-vni and if source or destination port matching entries are configured in an IPv4 or IPv6 SAP ingress QoS policy or in an IPv6 filter policy, any VXLAN or VXLAN GPE ingress traffic do not match these entries on the SAP on which the SAP ingress QoS policy is applied.

  • The simultaneous configuration on a SAP of a QoS policy containing an ip-criteria entry with type vxlan-vni and of a MAC filter with type vid is not supported, and the other way around.

    This is only applicable to Epipe and VPLS services.

  • If a SAP ingress QoS policy that has ip-criteria or ipv6-criteria statements with type vxlan-vni is applied to a SAP, any ip-criteria or ipv6-criteria entry match vxlan-vni statements do not match:

    • IPv4 packets containing options

    • IPv6 packets containing extension headers

    • ingress 802.1ah PBB frames

    • IPv6 over PPPoE traffic received with more than one VLAN tag

    • non-first fragments of an IPv4 or IPv6 fragmented packet

  • The configuration of a SAP ingress QoS policy containing ip-criteria or ipv6-criteria entry match vxlan-vni statements is not supported within an SLA profile.

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:

*A:Dut-T>config>qos>sap-ingress# info 
----------------------------------------------
            queue 1 create
            exit
            queue 2 create
            exit
            queue 3 create
            exit
            queue 11 multipoint create
            exit
            fc "af" create
                queue 2
            exit
            fc "be" create
                queue 1
            exit
            fc "ef" create
                queue 3
            exit
            lsp-exp 0 fc "be" priority low
            lsp-exp 1 fc "af" priority high

Storing match criteria entries

Cards store QoS policy match-criteria entries in dedicated memory banks in hardware also referred to as CAM tables:

  • IP/MAC ingress

  • IP/MAC egress

  • IPv6 ingress

  • IPv6 egress

FP4-based or later cards

To optimize both scale and performance, policy match-criteria entries configured by the user are compressed by each FP4 line card before being installed in hardware.

This compression can result, in an unexpected scenario typically only achieved in a lab environment, in an overload condition where entries for a line card QoS policy on a line card FP are not programmed. This overload condition can occur when applying a QoS policy for the first time on a line card FP or when adding entries to a QoS policy.

  • applying a QoS policy

    A policy is installed for the first time on a line card FP if no router interface, service interface, SAP, spoke SDP, mesh SDP or ESM subscriber host was using the policy on this FP.

    A policy installed for the first time on a line card FP can lead to a compression failure resulting in an overload condition for this policy on this FP. In this case, none of the entries for the affected QoS match-criteria policy are programmed, and the QoS policy queuing, FC mapping, and FC marking are unaffected.

  • adding QoS match-criteria entries

    Adding an additional entry to a QoS policy can lead to a compression failure resulting in an overload condition.

    In this case, the newly added entry is not programmed on the affected FP. Additional entries added to the same policy after the first overload condition are also not programmed on the affected FP as the system attempts to install all outstanding additions in order.

    The CPM QoS management task controls the maximum number of match criteria entries per FP. If the user attempts to go over the scaling limit, the system returns an interactive error message.

    Note: A trap is raised if a policy is in overload, there is no interactive error message.
  • removing QoS match-criteria entries

    Removing match-criteria entries from a QoS policy is always successful.

  • resolving overload

    The overload condition should be resolved by the network operator before adding new entries in the affected policy.

    To identify the affected policy, the system logs the overload event providing slot number, FP number, and impacted memory bank. Based on this information, the tools>dump>qos>match-criteria-overload command allows the user to identify the affected policy and policy entries in the system.

    To resolve the overload condition, the network operator can remove the newly added entries from the affected policy or assign a different policy.

Service egress QoS policy

To create a service egress policy, define the following:

  • a new policy ID value. The system does not dynamically assign a value.

  • the scope. A QoS policy must be defined as having either an exclusive scope for one-time use, or a template scope, which enables its use with multiple SAPs.

  • a description. The description provides a brief overview of policy features.

Service egress QoS queue

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

  • the forwarding class name or names associated with the egress queue. The egress queue for the service traffic is selected based on the forwarding classes that are associated with the queue.

  • a new queue ID value. The system does not dynamically assign a value.

  • queue parameters. Egress queues support explicit and auto-expedite hardware queue scheduling, and parent virtual scheduler definition.

The following displays an egress QoS policy configuration:

A:ALA-7>config>qos# info
--------------------------------------------------
...
        sap-egress 105 create
            description "SAP egress policy"
            queue 1 create
                parent "scheduler-tier1"
            exit
            queue 2 create
            exit
            queue 3 expedite create
                parent "test1"
            exit
            fc af create
                queue 1
            exit
            fc ef create
            exit
        exit
...
------------------------------------------------
A:ALA-7>config>qos# 

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 at egress. If there is no parent scheduler rate or agg-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:

*B:PE>config>qos>sap-egress# queue 1 percent-rate
- no percent-rate
- percent-rate <pir-percent> [cir <cir-percent>] [port-limit | local-limit]

<pir-percent> : [0.01..100.00]
<cir-percent> : [0.00..100.00]
<port-limit | local-*> : keyword

*B:PE>config>qos>sap-egress# policer 1 percent-rate
- no percent-rate
- percent-rate <pir-percent> [cir <cir-percent>]

<pir-percent> : [0.01..100.00]
<cir-percent> : [0.00..100.00]


*B:PE>config>qos>sap-egress#

Egress queue CBS and MBS as a function of delay

SR OS supports egress queue length configuration (CBS and MBS) as a function of the expected delay. The system automatically translates this configuration into kilobytes based on the administrative rate of the queue parent (for example, the scheduler or aggregate shaper) for queues that have a parent. The actual operational values of CBS and MBS are shown in kilobytes, and not as a function of the delay, in the corresponding show pools commands.

The delay value for the specified queue can be configured in the following ways:

Nokia recommends using the same method of defining CBS, MBS, and burst limit for all queues within the same SAP egress policy. CBS and MBS as a function of delay is not supported on HSQ. Policies that contain a function of delay applied to an HSQ will have default egress queue CBS and MBS value.

CBS, MBS, and burst limit as a function of queue delay

SR OS supports CBS, MBS, and burst limit configuration, in microseconds, as a function of the delay in SAP egress policy using the following commands.

  • MD-CLI
    configure qos sap-egress queue
                    burst-limit-delay-time
                    cbs-delay-time
                    mbs-delay-time
    
  • classic CLI
    configure qos sap-egress queue
                    burst-limit delay-time
                    cbs delay-time
                    mbs delay-time

The actual CBS, MBS, and burst limit values are calculated based on the queue parent administrative rate and may differ depending on the scheduling hierarchy. This calculation can be done only if the queue parent has an explicit rate defined (for example, a scheduler rate or aggregate rate). The system uses the default values if the queue parent is a port without an explicit rate defined.

Note: This feature is supported on LAGs in link or port-fair adapt-qos modes only. It is not supported on ESM.

CBS and MBS as a function of SAP delay budget

SR OS supports egress queue CBS and MBS configuration as a function of the total latency budget for the specific SAP using the following procedures.

The actual CBS and MBS values are calculated based on the queue parent administrative rate and may differ depending on the scheduling hierarchy. This calculation can be done only if the queue parent has an explicit rate defined (for example, a scheduler rate or aggregate rate). The system uses the default values if the queue parent is a port without an explicit rate defined.

Note: This feature is supported on LAGs in link or port-fair adapt-qos modes only. It is not supported on ESM.
  • MD-CLI
    1. Configure the SAP latency budget, in microseconds, using one of the following commands:

      configure service epipe sap egress qos latency-budget
      configure service ies interface sap egress qos latency-budget
      configure service vpls sap egress qos latency-budget
      configure service vprn interface sap egress qos latency-budget
    2. In the SAP egress policy, configure the percentage of the SAP latency budget for an individual queue:

      configure qos sap-egress queue cbs-delay-percent
      configure qos sap-egress queue mbs-delay-percent
  • classic CLI
    1. Configure the SAP latency budget, in microseconds, using one of the following commands:

      configure service epipe sap egress latency-budget
      configure service ies interface sap egress latency-budget
      configure service vpls sap egress latency-budget
      configure service vprn interface sap egress latency-budget
    2. In the SAP egress policy, configure the percentage of the SAP latency budget for an individual queue:

      configure qos sap-egress queue cbs delay-percent
      configure qos sap-egress queue mbs delay-percent

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 because of 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 are not affected and are forwarded. Reducing these parameters constrains the latency for newly arriving packets, but those packets already in the queue before the new parameter values were set are 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 specific 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:

configure
    qos
       queue-group-templates
          egress
              queue-group queue-group-name create
                  queue queue-id

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:

queue-group "qg1" create
  queue 1 best-effort create
       parent "s1" 
       rate 50000
       mbs 1000 kilobytes
       dynamic-mbs
   exit

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

*B:PE# show pools access-egress 5/1/1 queue-group "qg1" instance 1
...
===============================================================================
Queue : accQGrp->qg1:1(5/1/1)->1
===============================================================================
FC Map               : not-applicable
Dest Tap             : not-applicable   Dest FP          : not-applicable
Admin PIR            : 50000            Oper PIR         : 50000
Admin CIR            : 0                Oper CIR         : 0
Admin MBS            : 1008 KB          Oper MBS         : 1008 KB
High-Plus Drop Tail  : 1008 KB          High Drop Tail   : 1008 KB
Low Drop Tail        : 888 KB           Exceed Drop Tail : 792 KB
CBS                  : 0 KB             Depth            : 0
Slope                : not-applicable

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:

*B:PE# show pools 5/1/1 access-egress queue-group "qg1" instance 1
...
===============================================================================
Queue : accQGrp->qg1:1(5/1/1)->1
===============================================================================
FC Map               : not-applicable
Dest Tap             : not-applicable   Dest FP          : not-applicable
Admin PIR            : 50000            Oper PIR         : 25000
Admin CIR            : 0                Oper CIR         : 0
Admin MBS            : 1008 KB          Oper MBS         : 504 KB
High-Plus Drop Tail  : 1008 KB          High Drop Tail   : 1008 KB
Low Drop Tail        : 948 KB           Exceed Drop Tail : 900 KB
CBS                  : 0 KB             Depth            : 0
Slope                : not-applicable

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

Queue length as a delay value

The length of a queue within an egress queue group template can be configured as a target queue delay, in ms, instead of an absolute byte/kbytes value. The queue MBS is calculated from the queue delay and the administrative PIR, with the MBS [kB] being approximately the value of ((queue delay[ms]/1000) ✕ (PIR[kb/s] / 8)).The queue delay is configured as follows:

configure
    qos
       queue-group-templates
          egress
              queue-group queue-group-name create
                  queue queue-id
                      queue-delay ms

The queue-delay command and the mbs command are mutually exclusive. To change between the mbs and queue-delay parameters, the current parameter must be removed before adding the new parameter; that is, changing from mbs to queue-delay requires a no mbs before the queue-delay is configured and changing from queue-delay to mbs requires a no queue-delay before the mbs is configured. If queue-delay is configured for an egress queue group queue, it is not possible to override the MBS for that queue.

The following is an example of configuring queue delay and the resulting MBS:

*A:PE# configure qos queue-group-templates egress queue-group "qg2"
*A:PE>cfg>qos>qgrps>egr>qgrp# info
----------------------------------------------
                    queue 1 best-effort create
                        rate 50000
                        queue-delay 100
                    exit
----------------------------------------------
*A:PE>cfg>qos>qgrps>egr>qgrp# exit all
*A:PE# show pools access-egress 5/1/1 queue-group "qg2" instance 1
...
===============================================================================
Queue : accQGrp->qg2:1(5/1/1)->1
===============================================================================
FC Map               : not-applicable
Dest Tap             : not-applicable   Dest FP          : not-applicable
Admin PIR            : 50000            Oper PIR         : 50000
Admin CIR            : 0                Oper CIR         : 0
Admin MBS            : 612 KB           Oper MBS         : 612 KB
High-Plus Drop Tail  : 612 KB           High Drop Tail   : 612 KB
Low Drop Tail        : 540 KB           Exceed Drop Tail : 480 KB
CBS                  : 0 KB             Depth            : 0
Slope                : not-applicable

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 are 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 is not 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 match the same IP header TOS field, the DSCP entry parameters override or remove the IP precedence parameters. When none of the matched entries override a parameter, the ingress classification is preserved.

Egress IP match criteria

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

*A:PE>config>qos# info
----------------------------------------------
#--------------------------------------------------
echo "QoS Policy Configuration"
#--------------------------------------------------
        sap-egress 10 name "10" create
            queue 1 create
            exit
            ip-criteria
                entry 10 create
                    match
                        src-ip 192.168.0.0/16
                    exit
                    action fc "af"
                exit
                entry 20 create
                    match
                        dst-ip 10.0.0.0/8
                    exit
                    action fc "be"
                exit
            exit
        exit
----------------------------------------------
*A:PE>config>qos#

Egress IPv6 match criteria

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

*A:PE>config>qos# info
----------------------------------------------
#--------------------------------------------------
echo "QoS Policy Configuration"
#--------------------------------------------------
        sap-egress 10 name "10" create
            queue 1 create
            exit
            ipv6-criteria
                entry 10 create
                    match
                        dst-ip 2001:db8:1000::/64
                    exit
                    action profile in fc "ef"
                exit
            exit
        exit
----------------------------------------------
*A:PE>config>qos#

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:

  • a queue in the policer-output-queues queue group that is automatically created on an access or hybrid port with the queue used that was chosen by the forwarding class definition in that queue group. If the forwarding class is modified in the action statement, the new forwarding class selects the queue to be used.

  • a specific queue in a user-configured queue group. For SAP egress, this requires the use of the port-redirect-queue-group queue parameter in the criteria action statement with the queue group name being specified when the egress QoS policy is applied to the SAP. For subscribers, the queue group to be used is selected using the inter-dest-id associated with the subscriber and configured as the host-match dest under the port access queue group configuration.

  • a SAP queue configured within the SAP egress QoS policy

  • the queue to which the forwarding class for the traffic is mapped. This could be a queue group, SAP, or subscriber queue. This requires the use of the use-fc-mapped-queue parameter in the criteria action statement. If the forwarding class is modified in the action statement, new forwarding class selects the queue to be used.

The number of configuration combinations of a policer and one of the preceding methods is capped at 63 within a specific 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.

*A:PE>tools>dump>resource-usage# card 1 fp 1
===============================================================================
Resource Usage Information for Card Slot #1 FP #1
===============================================================================
                                                  Total   Allocated        Free
-------------------------------------------------------------------------------
...
                          Egress Qos Bypass  |   262143           0      262143
...

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 specific 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 Egress SAP.

Figure 2. Egress SAP

The configuration would be as follows:

sap-egress 10 create
    queue 1 create
    exit
    policer 1 create
    exit
    ip-criteria
       entry 10 create
           match
               dscp ef
           exit
           action policer 1
       exit
    exit
 exit

Storing match criteria entries

Cards store QoS policy match-criteria entries in dedicated memory banks in hardware, also referred to as CAM tables:

  • IP/MAC ingress

  • IP/MAC egress

  • IPv6 ingress

  • IPv6 egress

FP4-based or later cards

To optimize both scale and performance, policy match-criteria entries configured by the user are compressed by each FP4 or later line card before being installed in hardware.

This compression can result, in an unexpected scenario typically only achieved in a lab environment, in an overload condition where entries for a line card QoS policy on a line card FP are not programmed. This overload condition can occur when applying a QoS policy for the first time on a line card FP or when adding entries to a QoS policy.

  • applying a QoS policy

    A policy is installed for the first time on a line card FP if no router interface, service interface, SAP, spoke SDP, mesh SDP or ESM subscriber host was using the policy on this FP.

    A policy installed for the first time on a line card FP can lead to a compression failure resulting in an overload condition for this policy on this FP. In this case, none of the entries for the affected QoS match-criteria policy are programmed, and the QoS policy queuing, FC mapping, and FC marking are unaffected.

  • adding QoS match-criteria entries

    Adding an additional entry to a QoS policy can lead to a compression failure resulting in an overload condition.

    In this case, the newly added entry is not programmed on the affected FP. Additional entries added to the same policy after the first overload condition are also not programmed on the affected FP as the system attempts to install all outstanding additions in order.

    The CPM QoS management task controls the maximum number of match criteria entries per FP. If the user attempts to go over the scaling limit, the system returns an interactive error message.

    Note: A trap is raised if a policy is in overload, there is no interactive error message.
  • removing QoS match-criteria entries

    Removing match-criteria entries from a QoS policy is always successful.

  • resolving overload

    The overload condition should be resolved by the network operator before adding new entries in the affected policy.

    To identify the affected policy, the system logs the overload event providing slot number, FP number, and impacted memory bank. Based on this information, the tools>dump>qos>match-criteria-overload command allows the user to identify the affected policy and policy entries in the system.

    To resolve the overload condition, the network operator can remove the newly added entries from the affected policy or assign a different policy.

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:

configure qos sap-egress policy-id create
    use-policer-result-marking-dot1p-inner 
    fc fc-name create
    dot1p {dot1p-value | in-profile dot1p-value out-
     profile dot1p-value [exceed-profile dot1p-value]}
    dot1p-inner {dot1p-value | in-profile dot1p-value
     out-profile dot1p-value | exceed-profile dot1p-value} 
    dot1p-outer {dot1p-value | in-profile dot1p-value
     out-profile dot1p-value [exceed-profile dot1p-
     value]}
    exit

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:

  • dot1p-outer used for outer tag markings

  • dot1p-inner used for inner tag markings

  • existing dot1p used for marking both tags

  • markings taken from packet received at ingress

  • dot1p-inner marking is dependent on policer result if use-policer-result-marking-dot1p-inner is enabled

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.

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, because 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 specific 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 are 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:

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:

  • de-mark-outer used for outer tag markings

  • de-mark-inner used for inner tag markings

  • existing de-mark used for marking both tags

  • 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.

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 DE Bit in the 802.1ad S-tag).

Figure 3. 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 are the first ones to be dropped.

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.

IEEE 802.1ad use case

DE aware 802.1ad access network 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 toward the 802.1ad access provide correct DE indication by marking the new DE bit in the S-tag.

Figure 4. DE aware 802.1ad access network

DEI processing ingress into the PE1 SAP 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 5. 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 or EXP bits, or both) 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.

IEEE 802.1ah use case

DE aware PBB topology 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 6. 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.

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:

configure qos sap-egress policy-id create
  fc fc-name create
    dscp {dscp dscp-name | in-profile dscp-name out-
      profile dscp-name [exceed-profile dscp-name]}
    prec {ip-prec-value | in-profile ip-prec-value out-
      profile ip-prec-value} [exceed-profile ip-prec-
      value]}
  exit
exit

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:

sap-egress policy-id create
  policer policer-id create
    enable-dscp-prec-remarking
  exit
exit

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-queue-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.

A:PE-1# show service id 1 sap 1/2/1 queue-depth
===============================================================================
Queue Depth Information (Ingress SAP)
===============================================================================
No Matching Entries
===============================================================================
===============================================================================
Queue Depth Information (Egress SAP)
===============================================================================
-------------------------------------------------------------------------------
Name : 1->1/2/1->1
MBS : Def
-------------------------------------------------------------------------------
Queue Depths (percentage)
-------------------------------------------------------------------------------
0%-10% 11%-20% 21%-30% 31%-40% 41%-50% 51%-60% 61%-70% 71%-80% 81%-90% 91%-100%
-------------------------------------------------------------------------------
68.21  3.64    3.43    3.47    3.86    3.22    3.86    2.87    3.78    3.66
-------------------------------------------------------------------------------
Average Elapsed Time : 0d 00:11:48
Wghtd Avg Polling Interval: 99 ms
-------------------------------------------------------------------------------
===============================================================================

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, instead of 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 specific 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 therefore it can be monitored through telemetry.

Service management tasks

This section discusses service ingress and egress service management tasks.

Applying service ingress and egress policies

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

See 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.

Epipe

The following output displays an Epipe service configuration with SAP ingress policy 100 and SAP egress 105 applied to the SAP.

A:ALA-7>config>service# info
----------------------------------------------
        epipe 6 customer 6 vpn 6 create
            description "Distributed Epipe service to west coast"
            sap 1/1/10:010 create
                ingress
                    qos 100
                exit
                egress
                    qos 105
                exit
            exit
            spoke-sdp 2:6 create
                ingress
                    vc-label 6298
                exit
                egress
                    vc-label 6300
                exit
            exit
            no shutdown
        exit
----------------------------------------------
A:ALA-7>config>service#

IES

The following output displays an IES service configuration with SAP ingress policy 100 and SAP egress 105 applied to the SAP.

A:ALA-7>config>service# info
----------------------------------------------
        ies 88 customer 8 vpn 88 create
            interface "Sector A" create
                sap 1/1/1.2.2 create
                    ingress
                        qos 100
                    exit
                    egress
                        qos 105
                    exit
                exit
            exit
            no shutdown
        exit
----------------------------------------------

VPLS

The following output displays a VPLS service configuration with SAP ingress policy 100. The SAP egress policy 1 is applied to the SAP by default.

A:ALA-7>config>service# info
----------------------------------------------
        vpls 700 customer 7 vpn 700 create
            description "test"
            stp
                shutdown
            exit
            sap 1/1/9:010 create
                ingress
                    qos 100
                exit
            exit
            spoke-sdp 2:222 create
            exit
            mesh-sdp 2:700 create
            exit
            no shutdown
        exit
----------------------------------------------
A:ALA-7>config>service#

VPRN

The following output displays a VPRN service configuration for the 7750 SR and 7950 XRS.

A:ALA-7>config>service# info
----------------------------------------------
...
        vprn 1 customer 1 create
            ecmp 8
            autonomous-system 10000
            route-distinguisher 10001:1
            auto-bind-tunnel
                resolution-filter
                resolution-filter ldp
            vrf-target target:10001:1
            interface "to-ce1" create
                address 10.1.0.1/24
                sap 1/1/10:1 create
                    ingress
                        qos 100
                    exit
                    egress
                        qos 105
                    exit
                exit
            exit
            no shutdown
        exit
...
----------------------------------------------
A:ALA-7>config>service#

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.

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.

CLI syntax:

config>qos# copy {sap-ingress | sap-egress} source-policy-id dest-policy-id [overwrite]

The following output displays the copied policies:

A:ALA-7>config>qos# info
---------------------------------------------
...
exit
        sap-ingress 100 create
            description "Used on VPN sap"
            queue 1 create
            exit
            queue 2 multipoint create
            exit
            queue 10 create
                parent "VPN_be"
                rate 11000
            exit
...
        sap-ingress 101 create
            description "Used on VPN sap"
            queue 1 create
            exit
            queue 2 multipoint create
            exit
            queue 10 create
                parent "VPN_be"
                rate 11000
            exit
        sap-ingress 200 create
            description "Used on VPN sap"
            queue 1 create
            exit
            queue 2 multipoint create
            exit
            queue 10 create
                parent "VPN_be"
                rate 11000
            exit
...
---------------------------------------------
A:ALA-7>config>qos# 

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.

A:ALA-7>config>qos# no sap-ingress 100
MINOR: CLI SAP ingress policy "100" cannot be removed because it is in use.
A:ALA-7>config>qos#

Removing a policy from the QoS configuration

Use the following syntax to remove a policy from the QoS configuration:

config>qos# no sap-ingress policy-id

Example:

config>qos# no sap-ingress 100
config>qos# no sap-egress 1010