Queue sharing and redirection

Queue groups are objects created on the access or network Ethernet port or ingress forwarding plane of an IOM/IMM/XMA that allow SAP or IP interface forwarding classes to be redirected from the normal type of queue mapping to a shared queue. Queue groups may contain queues, policers, or a combination of the two depending on the type of queue group. The following types of queue groups are supported:

Access ingress supports a single queue group instance per ingress port, or multiple queue groups created at the ingress forwarding plane level of the IOM/IMM/XMA. Access ingress port queue groups may only contain queues, whereas access ingress forwarding plane queue groups may only contain policers.
Access egress supports the creation of multiple queue groups per egress port. These queue groups may only contain queues.
Network ingress supports the creation of multiple queue groups at the ingress forwarding plane level of the IOM/IMM/XMA. These queue groups may only contain policers.
Network egress supports the creation of multiple queue groups per egress port. These queue groups may contain queues only, or queues and policers.

Supported platforms

Queue sharing and redirection is supported on the 7950 XRS, 7750 SR, and 7450 ESS platforms as follows:

access SAP port and network port queue groups
ingress access and network forwarding plane queue groups except on the 7750 SR-a4/a8

Queue sharing and redirection are also supported in conjunction with the use of a C-XMA, XMA, Ethernet MDA, Ethernet CMA, and IOM-4-HS.

Queue group applications

Access SAP queue group applications

Normally, each SAP (Service Access Point) has dedicated ingress and egress queues that are only used by that particular SAP. The SAP queues are created based on the queue definitions within the SAP ingress and SAP egress QoS policy applied to the SAP. Each packet that enters or egresses the SAP has an associated forwarding class. The QoS policy is used to map the forwarding class to one of the SAP’s local queue IDs. This per-SAP queuing has advantages over a shared queuing model in that it allows each SAP to have a unique scheduling context per queue. During congestion, SAPs operating within their conforming bandwidth experience little impact because they do not need to compete for queue buffer space with misbehaving or heavily loaded SAPs.

The situation is different for a shared or port-queuing model that is based on policing color packets that conform or exceed a static rate before the single queue and that use WRED or drop tail functions to essentially reserve room for the conforming packets.

In this model, there is no way for the conforming packets to go to the head of the line in the view of the port scheduler. Another advantage of per-SAP queuing is the ability for the SAP queues to perform shaping to control burst sizes and forwarding rates based on the SAPs defined SLA. This is especially beneficial when a provider is enforcing a sub-line rate bandwidth limit and the customer does not have the ability to shape at the CE.

However, there are cases where per-SAP queuing is not preferred. Per-SAP queuing requires a more complex provisioning model to properly configure the SAPs ingress and egress SLAs. This requires service awareness at some points in the network where an aggregation function is being performed. In this case, a shared queuing or per-port queuing model is sufficient. Creating ingress and egress access queue groups and mapping the SAPs forwarding classes to the queues within the queue group provides this capability.

A further use case is where a set of ingress SAPs, which may represent a subset of the total number of ingress SAPs, is to be shaped or policed on an aggregate per-forwarding class basis when those SAPs are spread across a LAG on multiple ingress ports, and where color aware treatment is required so that explicitly in-profile traffic is honored up to CIR, but above which it is marked as out-of-profile.

The preceding scenarios can be supported with access queue groups. A single ingress queue group is supported per access port, while multiple ingress queue group instances are supported per IOM/IMM/XMA forwarding plane. To provide more flexibility on the egress side of the access port, multiple egress access queue group queue-group instances are supported per egress access port.

Because queue redirection is defined per forwarding class, it is possible to redirect some forwarding classes to a queue group while having others on the SAP use the SAP local queues. This is helpful when shared queuing is only wanted for a few applications such as VoIP or VoD while other applications still require queuing at the SAP level.

Ingress per SAP statistics with ingress queue groups

A statistic displaying the number of valid ingress packets received on a SAP, or subscribers on that SAP, is shown in the sap-stats output. This is available for SAPs in all services. This is particularly useful to display SAP level traffic statistics when forwarding classes in a SAP ingress policy have been redirected to an ingress queue group.

In the following example, traffic is received on an ingress FP policer with a packet-byte-offset of subtract 10. It can be seen that the ingress queueing stats and offered forwarding engine stats are all zero as the traffic is using the FP ingress policer. The Received Valid statistic is non-zero and matches that seen on the ingress FP queue group, with the difference being that the packet-byte-offset is applied to the queue group policer octets but not the Received Valid octets.

The value in the Received Valid field may not instantaneously match the sum of the offered stats (even in the case where all traffic is using the SAP queues) when traffic is being forwarded; however, when the traffic has stopped, the Received Valid equals the sum of the offered stats.

*A:PE# show service id 1 sap 1/1/9:1 sap-stats

===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id         : 1
SAP                : 1/1/9:1                  Encap             : q-tag
Description        : (Not Specified)
Admin State        : Up                       Oper State        : Up
Flags              : None
Multi Svc Site     : None
Last Status Change : 08/31/2018 11:09:25
Last Mgmt Change   : 08/31/2018 11:09:25
-------------------------------------------------------------------------------
Sap Aggregate Stats
-------------------------------------------------------------------------------
                        Packets                 Octets
Ingress
Aggregate Offered     : 0                       0
Aggregate Forwarded   : 0                       0
Aggregate Dropped     : 0                       0

Egress
Aggregate Forwarded   : 0                       0
Aggregate Dropped     : 0                       0
-------------------------------------------------------------------------------
Sap Statistics
-------------------------------------------------------------------------------
Last Cleared Time     : 08/31/2018 11:12:17

                        Packets                 Octets
CPM Ingress           : 0                       0

Forwarding Engine Stats
Dropped               : 0                       0
Received Valid        : 5                       530
Off. HiPrio           : 0                       0
Off. LowPrio          : 0                       0
Off. Uncolor          : 0                       0
Off. Managed          : 0                       0

Queueing Stats(Ingress QoS Policy 10)
Dro. HiPrio           : 0                       0
Dro. LowPrio          : 0                       0
For. InProf           : 0                       0
For. OutProf          : 0                       0

Queueing Stats(Egress QoS Policy 1)
Dro. In/InplusProf    : 0                       0
Dro. Out/ExcProf      : 0                       0
For. In/InplusProf    : 0                       0
For. Out/ExcProf      : 0                       0
===============================================================================
*A:PE#
*A:PE# show card 1 fp 1 ingress queue-group "qg1" instance 1 mode access statistics

===============================================================================
Card:1  Acc.QGrp: qg1  Instance: 1
===============================================================================
Group Name    : qg1
Description   : (Not Specified)
Pol Ctl Pol   : None                    Acct Pol      : None
Collect Stats : disabled
-------------------------------------------------------------------------------
Statistics
-------------------------------------------------------------------------------
                        Packets                 Octets

Ing. Policer:  1  Grp: qg1
(Stats mode: minimal)
Off. All              : 5                       530
Dro. All              : 0                       0
For. All              : 5                       530
===============================================================================
*A:PE#

Ingress access port queue group hardware queue allocation

When ingress access port queue groups are configured, hardware queues are allocated to each switch fabric destination for each queue configured in the queue group template.

The allocation of ingress access port queue group hardware queues has been optimized for the 7950 XRS-20 systems to avoid allocating ingress hardware queues to XCMs in slots 11 and above.

When the first XCM in slot 11 or above is provisioned, additional ingress hardware queues are allocated to XCMs in slots 11 to 20 for any configured ingress access port queue group queue. If sufficient hardware queues are unavailable, the XCM provisioning fails. Adding queues to the queue group template or adding additional ingress access port queue groups continues to require more hardware queue to be allocated, with the configurations failing if there are not sufficient available. When the last XCM in slot 11 and above is unprovisioned, the related additional hardware queues to all of the XCMs in slots 11 and above are freed.

Network port queue groups for IP interfaces

Queue groups may be created on egress network ports to provide network IP interface queue redirection. A single set of egress port-based forwarding class queues are available by default and all IP interfaces on the port share the queues. Creating a network queue group allows one or more IP interfaces to selectively redirect forwarding classes to the group to override the default behavior. Using network egress queue groups, it is possible to provide dedicated queues for each IP interface.

Non-IPv4/non-IPv6/non-MPLS packets remain on the regular network port queues. Therefore, when using an egress port-scheduler, it is important to parent the related regular network port queues to appropriate port-scheduler priority levels to ensure the needed operation under port congestion. This is particularly important for protocol traffic such as LACP, EFM-OAM, ETH-CFM, ARP, and IS-IS, which by default use the FC NC regular network port queue.

Pseudowire shaping for Layer 2 and Layer 3 services

This feature allows the user to perform ingress and egress data path shaping of packets forwarded within a spoke-sdp (PW). It applies to a VLL service, a VPLS/B-VPLS service, and an IES/VPRN spoke-interface.

Ingress pseudowire shaping

The ingress PW rate-limiting feature uses a policer in the queue-group provisioning model. This model allows the mapping of one or more PWs to the same instance of policers that are defined in a queue-group template.

Operationally, the provisioning model in the case of the ingress PW shaping feature consists of the following steps:

Create an ingress queue-group template and configure policers for each FC that needs to be redirected and optionally, for each traffic type (unicast, broadcast, unknown, or multicast).
Apply the queue-group template to the network ingress forwarding plane where there exists a network IP interface that the PW packets can be received on. This creates one instance of the template on the ingress of the FP. One or more instances of the same template can be created.
Configure FC-to-policer mappings together with the policer redirect to a queue-group in the ingress context of a network QoS policy. No queue-group name is specified in this step, which means the same network QoS policy can redirect different PWs to different queue-group templates.
Apply this network QoS policy to the ingress context of a spoke-sdp inside a service, or to the ingress context of a PW template and specify the redirect queue-group name.

Egress pseudowire shaping

One or more spoke SDPs can have their FCs redirected to use policers in the same policer queue-group instance.

The egress PW shaping provisioning model allows the mapping of one or more PWs to the same instance of queues, or policers and queues, that are defined in the queue-group template.

Operationally, the provisioning model consists of the following steps:

Create an egress queue-group template and configure queues only, or policers and queues, for each FC that needs to be redirected.
Apply the queue-group template to the network egress context of all ports where there exists a network IP interface that the PW packets can be forwarded on. This creates one instance of the template on the egress of the port. One or more instances of the same template can be created.
Configure FC-to-policer or FC-to-queue mappings together with the redirect to a queue-group in the egress context of a network QoS policy. No queue-group name is specified in this step, which means the same network QoS policy can redirect different PWs to different queue-group templates.
Apply this network QoS policy to the egress context of a spoke-sdp inside a service, or to the egress context of a PW template and specify the redirect queue-group name.
One or more spoke SDPs can have their FCs redirected to use queues only, or queues and policers, in the same queue-group instance.

QoS on ingress bindings

Traffic is tunneled between VPRN service instances on different PEs over service tunnels bound to MPLS LSPs or GRE tunnels. The binding of the service tunnels to the underlying transport is achieved either automatically (using the auto-bind-tunnel command) or statically (using the spoke-sdp command; not on the VPRN IP interface). QoS control can be applied to the service tunnels for traffic ingressing into a VPRN service; see Ingress QoS control on VPRN bindings.

Figure 1. Ingress QoS control on VPRN bindings

An ingress queue group must be configured and applied to the ingress network FP where the traffic is received for the VPRN. All traffic received on that FP for any binding in the VPRN (either automatically or statically configured) that is redirected to a policer in the FP queue group (using fp-redirect-group in the network QoS policy) is controlled by that policer. As a result, the traffic from all such bindings is treated as a single entity (per forwarding class) with regard to ingress QoS control. Any fp-redirect-group, mcast-policer, broadcast-policer, or unknown-policer commands in the network QoS policy are ignored for this traffic (IP multicast traffic would use the ingress network queues or queue group related to the network interface).

Ingress classification is based on the configuration of the ingress section of the specified network QoS policy, noting that the dot1p and exp classification is based on the outer Ethernet header and MPLS label whereas the DSCP applies to the outer IP header if the tunnel encapsulation is GRE, or the DSCP in the first IP header in the payload if ler-use-dscp is enabled in the ingress section of the referenced network QoS policy.

Ingress bandwidth control does not consider the outer Ethernet header, the MPLS labels/control word or GRE headers, or the FCS of the incoming frame.

The following command configures the association of the network QoS policy and the FP queue group and instance within the network ingress of a VPRN:

configure
    vprn
        network
            ingress
                qos <network-policy-id> fp-redirect-group <queue-group-name>
                                        instance <instance-id>

When this command is configured, it overrides the QoS applied to the related network interfaces for unicast traffic arriving on bindings in that VPRN. The IP and IPv6 criteria statements are not supported in the applied network QoS policy.

This is supported for all available transport tunnel types and is independent of the label mode (vrf or next-hop) used within the VPRN. It is also supported for Carrier-Supporting-Carrier VPRNs.

VXLAN VNI queue group redirection

VXLAN Virtual Network Identifier (VNI) queue group redirection allows IPv4 and IPv6 VXLAN and VXLAN GPE routed transit packets to be mapped to an FP ingress or port egress queue group instance based on the VXLAN VNI. This allows QoS control to be applied to transit VXLAN traffic.

QoS for transit VXLAN can also be achieved by using VNI classification in an ip-criteria or ipv6-criteria statement within a SAP ingress QoS policy (see Virtual network identifier classification). The main difference between VNI SAP ingress classification and queue group redirection is that the former is only for ingress and is less scalable because it uses SAP policers or queues instead of queue groups; however, it does support ranges of VNIs.

Queue group redirection provides a more advanced mechanism where individual VNIs can use their own FP access ingress and port egress queue group instances for QoS control. Packets with a specific VNI can be redirected to an access ingress and egress queue group instance, with the policer or queue within the queue group instance being selected using the classification capabilities in the associated SAP ingress or egress QoS policy. Queue group redirection is enabled by applying a queue group redirect list, which contains VNI match statements, under an ingress and egress SAP that is configured with a default queue group instance.

VXLAN VNI queue group redirection is not supported at ingress on the 7750 SR-a4/a8 (which do not support FP ingress queue groups). It is supported under IES and VPRN interface SAPs. Redirecting fragmented packets based on the VNI to a queue group instance is not supported; the VNI matching is ignored, and the default queue group instance is used.

Queue group redirect list

A queue group redirection list allows packets that match a configured type value to be redirected to a specific queue group instance at SAP ingress or egress.

The queue group instance must be an instance of the default queue group, which is the queue group configured under the SAP with the QoS policy.

The only type matching supported is vxlan-vni, which enables an ingress and egress match based on the VNI in IPv4 and IPv6 VXLAN and VXLAN GPE packets. Each entry in the redirect list matches a specific VNI and maps it to a specific queue group instance. A maximum of 16 match statements can be configured in a queue group redirect list.

A redirect list is configured as follows:

configure
    qos
        queue-group-redirect-list redirect-list-name
 [create]
            type redirect-list-type
            match field-value instance instance-id
        exit

where:

redirect-list-name specifies the name of the queue group redirect list
redirect-list-type specifies the type of queue group redirect list; the default and only possible value is vxlan-vni
field-value specifies the value of the field in the ingress or egress packet which, when matched, causes the packet to be redirected to the specified queue group instance. The field-value is dependent on the setting of the type and must be a valid VXLAN VNI. The VNI can be specified in any of the available formats but is always shown in decimal.
instance-id specifies the instance of the queue group template to which the VXLAN and VXLAN GPE packets are redirected. The packets can be redirected to the default instance, that is, the instance specified with the QoS policy.

A queue group redirection list is applied under the SAP ingress or egress as shown in the following example. The prior configuration of a default queue group instance (the queue group instance specified with the QoS policy under the SAP ingress or egress) is mandatory. Only a single list can be applied per-SAP ingress or egress.

configure
    service
        {ies | vprn} service-id
            interface ip-int-name
                sap sap-id
                    ingress
                        qos policy-id fp-redirect-group
queue-group-name instance instance-id
                                        queue-group-redirect-list 
redirect-list-name
                                    egress
                                        qos policy-id port-redirect-
group queue-group-name instance instance-id
                                        queue-group-redirect-list 
redirect-list-name

In order for packets to be redirected to the policer or queue in the queue group instance specified in a queue group redirect list, the following criteria must be met:

The FC in the SAP ingress or egress QoS policy must be redirected to an FP or port redirect queue group.
The VNI to be matched must be configured in a match statement in the queue group redirect list.
The instance corresponding to the related match statement must exist on the FP ingress or port egress through which the traffic ingresses or egresses.

If any of these conditions are not met, the traffic is not redirected to the queue group instance specified in the redirect list and falls back to either using the SAP policers and queues or the default instance (the one configured with the QoS policy under the SAP), depending on which condition is not met; this applies to VXLAN and VXLAN GPE packets with VNIs not listed in the redirect list, and non-VXLAN and non-VXLAN GPE packets.

Modifying a queue group redirect list causes the VNI-to-instance matching to change on all SAPs (ingress and egress) where the queue group redirect list is applied.

There is a limit on the number of SAP/VNI combinations at ingress and the number of SAP-instance/VNI combinations at egress per FP, which can be seen using the tools dump resource-usage card slot-num fp fp-number command. The egress limit is a subset of the Dynamic Service Entries and instance mismatches are considered to be allocated on the related ingress and egress FP. The output shows the total, allocated, and free resources, as shown in the following example:

*A:PE# tools dump resource-usage card 1 fp 1
===============================================================================
Resource Usage Information for Card Slot #1 FP #1
===============================================================================
                                                    Total  Allocated       Free
-------------------------------------------------------------------------------
...
                Sap IngQGrp RedirLst Entries |      31999          2      31997
                     Dynamic Service Entries +     131071          2     131069
            SapInst EgrQGrp RedirLst Entries -      31999          2      31997
...
===============================================================================
*A:PE#

If a queue group instance specified in an applied queue group redirect list does not exist on the SAP's FP ingress or port egress, a flag is displayed in the show output for the SAP, for example:

*A:PE# show service id 1 sap 1/1/1
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id         : 1
SAP                : 1/1/1                    Encap             : null
Description        : (Not Specified)
Admin State        : Up                       Oper State        : Up
Flags              : SapIngQGrpRedirMismatch
                     SapEgrQGrpRedirMismatch
Multi Svc Site     : None
Last Status Change : 01/31/2017 17:50:56
Last Mgmt Change   : 02/02/2017 12:02:56
===============================================================================
*A:PE#

The following show command can be used to identify which instances from the redirection list exist on the SAP's FP ingress and port egress and which do not exist and are causing the mismatch:

*A:PE# show service id 1 sap 1/1/1 queue-group-redirection
===============================================================================
Queue Group Redirect List Mismatch Information (Ingress SAP)
===============================================================================
-------------------------------------------------------------------------------
Queue Group      Instance          FP
-------------------------------------------------------------------------------
qg2                     1          1/1
                        2          1/1 : mismatch
-------------------------------------------------------------------------------
===============================================================================
 
===============================================================================
Queue Group Redirect List Mismatch Information (Egress SAP)
===============================================================================
-------------------------------------------------------------------------------
Queue Group      Instance          Port
-------------------------------------------------------------------------------
qg2                     1          1/1/1
                        2          1/1/1 : mismatch
-------------------------------------------------------------------------------
===============================================================================
*A:PE#

Queue group redirect list example

This section provides a configuration example for the use of queue group redirection lists.

In this example, each ingress queue group instance contains three policers, and each egress queue group instance contains three queues (the details of the queue group templates and instance creation are not shown).

The VXLAN VNI mapping to ingress and egress queue group instances is as follows:

The ingress and egress default mapping is to queue group qg1 instance 1.
VXLAN VNI 1 maps to ingress and egress instance 1 (the default instance).
VXLAN VNI 2 maps to ingress and egress instance 2.
VXLAN VNI 3 maps to ingress and egress instance 3.

Non-VXLAN traffic and VXLAN traffic with VNIs other than 2 and 3 use the default instance (VNI 1 is explicitly using the default instance).

An IP interface within an IES service is used.

QoS policies:

sap-ingress 10 create
           queue 1 create
           exit
           queue 11 multipoint create
           exit
           fc "af" create
               policer 2 fp-redirect-group
           exit
           fc "be" create
               policer 1 fp-redirect-group
           exit
           fc "ef" create
               policer 3 fp-redirect-group
           exit
           dscp af11 fc "af"
           dscp ef fc "ef"
           exit
sap-egress 10 create
           queue 1 create
           exit
           fc af create
               queue 2 port-redirect-group-queue
           exit
           fc be create
               queue 1 port-redirect-group-queue
           exit
           fc ef create
               queue 3 port-redirect-group-queue
           exit
           dscp af11 fc "af"
           dscp ef fc "ef"
  exit

Queue group redirect list:

queue-group-redirect-list list1 create
    type vxlan-vni
    match 1 instance 1
    match 2 instance 2
    match 3 instance 3
exit

Service:

ies 1 customer 1 create
    interface "int" create
        address 10.0.0.2/30
        sap 1/1/1 create
            ingress
             qos 10 fp-redirect-group "qg1" instance 1
             queue-group-redirect-list "list1"
            exit
            egress
             qos 10 port-redirect-group "qg1" instance 1
             queue-group-redirect-list "list1"
            exit
        exit
    exit
exit

Show output:

A:PE# show qos queue-group-redirect-list detail
===============================================================================
Queue Group Redirect List Information
===============================================================================
Policy Name        : list1
Match Type         : vxlan-vni
-------------------------------------------------------------------------------
Match               Instance
-------------------------------------------------------------------------------
1                   1
2                   2
3                   3
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Service Associations
-------------------------------------------------------------------------------
Service ID     Service Type             SAP
-------------------------------------------------------------------------------
1              IES                      1/1/1               (Ingress/Egress)
-------------------------------------------------------------------------------
===============================================================================
A:PE#

Queue group templates

Before a queue group with a specific name may be created on a port or an IOM/IMM/XMA ingress forwarding plane, a queue group template with the same name must first be created. The template is used to define each queue, scheduling attributes, and its default parameters. When a queue or policer is defined in a queue group template, that queue exists in every instance of a port or forwarding plane queue group with that template name. The default queue or policer parameters (such as rate or MBS values) may be overridden with a specific value in each queue group. This works in a similar manner to SAP ingress or SAP egress QoS policies.

Queue sharing is also supported when the HSQ (IOM-4-HS) are used. On egress, it is possible to redirect forwarding classes from multiple SAPs to an HSQ queue group. The HSQ also uses the term queue group to describe a group of eight preconfigured hardware queues on its egress port. When queue sharing and redirection is configured on egress, a set of eight HSQ queues could be configured as a part of the queue group template. These correspond to eight hardware queues on the HSQ. When all eight egress FCs are mapped to the queue-group instantiated in the egress port, the per-sap HSQ queue-group resource is freed.

Port queue groups

When an ingress or egress queue group template is defined, a port-based queue group with the same name may be created. Port queue groups are named objects that act as a container for a group of queues. The queues are created based on the defined queue IDs within the associated queue group template. Port queue groups must be created individually on the ingress and egress sides of the port, but multiple port queue groups of the same template name may be created on egress ports if they have a different instance identifier. These are termed ‛queue group instances’. Each instance of a named queue group created on a port is an independent set of queues structured as per the queue group template. Port queue groups are only supported on Ethernet ports and may be created on ports within a LAG.

Additional parameters can be configured under port queue groups, for example, an accounting policy, queue overrides, a scheduler policy, and scheduler overrides.

Percent-rate support

The percent-rate command is supported in an egress queue group template 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.

When the queue rate is configured with percent-rate, a port-limit is applied, specifically, the percent-rate is relative to the rate of the port to which the queue is attached.


*A:PE>config>qos>qgrps>egr>qgrp>queue# percent-rate
  - no percent-rate
  - percent-rate <pir-percent> [cir <cir-percent>]

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

Forwarding plane queue groups

Ingress forwarding plane queue groups allow groups of SAPs on one or more ports, or on a LAG on the IOM, IMM, or XMA, to be bundled together from a QoS enforcement perspective with an aggregate rate limit to be enforced across all SAPs of a bundle. Multiple queue groups are supported per IOM/IMM/XMA or port on access ingress. These are implemented at the forwarding plane level on the ingress IOM so that SAPs residing on different ingress ports or SAPs on a LAG spread across ports on a specific IOM can be redirected to the same queue group.

When an ingress queue group template is defined, a forwarding plane queue group with the same name may be created on an ingress forwarding plane of an IOM, IMM, or XMA. Forwarding plane queue groups are named objects that act as a container for a group of policers. Queues are not supported in forwarding plane queue groups. Only hierarchical policers are supported in the forwarding plane queue group, instead of queues. These policers may be configured to use profile-aware behavior. The policers are created based on the defined policer IDs within the associated queue group template. Multiple forwarding plane queue groups of the same template name may be created on ingress if they have a different instance identifier. These are termed queue group instances. Each instance of a named queue group created on a forwarding plane is an independent set of policers structured as per the queue group template. Forwarding plane queue groups are only supported with Ethernet ports and may be created on IOMs, IMMs, or XMAs with ports in a LAG.

Redirection models

Two models are supported for forwarding class redirection. In the first, the actual instance of a queue group to use for forwarding class redirection is named in the QoS policy. This is called policy-based redirection.

In the second model, the forwarding class queue or policers to apply redirection to are identified in the ingress or egress QoS policy. However, the specific named queue group instance is not identified until a QoS policy is applied to a SAP. This is called SAP-based redirection.

Policy-based redirection allows different forwarding classes in the same QoS policy to be redirected to different queue groups, but it requires at least one QoS policy to be configured per queue group instance.

SAP-based redirection can require less QoS policies to be configured because the policy does not have to name the queue group. However, if redirected, all forwarding classes of a SAP must use the same named queue group instance.

Policy-based redirection is applicable to port queue groups on access ingress and access and network egress, while SAP-based redirection is applicable to forwarding plane queue groups on access and network ingress, and port queue groups on access and network egress.

Access SAP forwarding class-based redirection

Forwarding class redirection is provisioned within the SAP ingress or SAP egress QoS policy. In each policy, the forwarding class to queue ID mapping may optionally specify a named queue group instance (policy-based redirection) or may simply tag the forwarding class for redirection (SAP-based redirection). When the name is specified, the defined queue ID must exist in the queue group template with the same name.

Policy-based redirection

Redirecting a SAP forwarding class to a queue within a port-based queue group using policy-based redirection requires four steps.

Create an ingress or egress queue group template. If the forwarding class redirection is in the ingress SAP path, an ingress queue group template must be created. Similarly, an egress queue group template must be created for egress forwarding class redirection. Optionally, the queues in a template can be created using default parameters. Individual queues must be created before they are associated with a forwarding class. The default queue parameters may be overridden on each port-based queue group.
(This step and the following step can be done in the opposite order.) Create an ingress or egress queue group instance with the same name as the template on the port associated with the SAP. Examples are as follows:
On ingress ports:

config>port>ethernet>access>ingress>queue-group queue-group-name

On egress ports:

config>port>ethernet>access>egress>queue-group queue-group-name [instance instance-id]

Queue parameter overrides can also be applied at this time.
Redirect the SAP ingress or SAP egress QoS policy forwarding class policer or queue to the queue group name and wanted queue ID. Examples are as follows:
On ingress:

config>qos>sap-ingress policy-id

fc fc-name

queue queue-id group queue-group-name

On egress:

config>qos>sap-egress policy-id

fc fc-name

queue queue-id group queue-group-name instance instance-id

config>qos>sap-egress policy-id

fc fc-name

policer policer-id group queue-group-name instance instance-id
Finally, the SAP ingress or SAP egress QoS policy must be applied to the SAP.

SAP-based redirection

Redirecting a SAP forwarding class to a queue within an egress port-based or ingress forwarding plane queue group using SAP-based redirection requires four steps.

Create an ingress or egress queue group template. If the forwarding class redirection is in the ingress SAP path, an ingress queue group template must be created. Similarly, an egress queue group template must be created for egress forwarding class redirection. Optionally, the queues in a template can be created using default parameters. Individual queues must be created before they are associated with a forwarding class. The default queue parameters may be overridden on each port-based queue group.
(This step and the following step can be done in the opposite order.) Create an ingress queue group instance on the forwarding plane of the IOM/IMM/XMA, or an egress port queue group with the same name as the template on the port associated with the SAP.
On ingress:

config>card>fp>ingress>access>queue-group queue-group-name instance instance-id [create]

On egress:

config>port>ethernet>access>egress>queue-group queue-group-name [instance instance-id]
Redirect the SAP ingress forwarding class policer in the SAP-ingress QoS policy using the keyword fp-redirect-group keyword on the policer, or SAP egress forwarding class queue or policer using the port-redirect-group keyword. (Steps 2 and 3 may be done in opposite order.)
On ingress:

config>qos>sap-ingress policy-id

fc fc-name

queue queue-id fp-redirect-group

On egress:

config>qos>sap-egress policy-id

fc fc-name

queue queue-id port-redirect-group-queue

config>qos>sap-egress policy-id

fc fc-name

policer policer-id port-redirect-group-queue
Finally, the SAP ingress or SAP egress QoS policy must be applied to the SAP. The named queue group instance that was created on the ingress forwarding plane or the egress port must be specified at this time.
On ingress:

config>service>epipe>sap sap-id

ingress

qos sap-ingress-policy-id fp-redirect-group queue-group-name instance instance-id

On egress:

config>service>epipe>sap sap-id

egress

qos sap-egress-policy-id port-redirect-group queue-group-name instance instance-id

Ingress and egress SAP forwarding class redirection association rules

Policy-based provisioning model

The association rules between SAP ingress and egress QoS policies and queue group templates are as follows: both the target queue group name and queue ID within the group are explicitly stated within the access QoS policies.

The following association rules apply when the policy-based provisioning model is applied with port queue groups.

When a SAP ingress QoS policy forwarding class is redirected to a queue group queue ID:

If the queue group name does not exist as an ingress queue group template, the forwarding class redirection fails.
If a redirection queue ID does not exist within the ingress queue group template, the forwarding class redirection fails.
If the SAP ingress QoS policy is currently applied to a non-Ethernet port or an Ethernet port where the specified ingress queue group does not exist, the forwarding class redirection fails.

When a SAP ingress QoS policy forwarding class redirection is removed from a queue group queue ID:

If the forwarding class is being moved to another queue group queue ID that does not exist within an ingress queue group template, the redirection removal from the current queue group queue ID fails.
If the forwarding class is being moved to a local queue ID within the SAP ingress QoS policy and the local queue ID does not exist, the redirection removal from the current queue group queue ID fails.
If the forwarding class is being moved to a local queue ID within the SAP ingress QoS policy and it is the first forwarding class to be mapped to the queue ID, the system attempts to instantiate the queue on each ingress SAP where the SAP ingress QoS policy is applied. If the queue cannot be created on any of the SAPs, the redirection removal from the current queue group ID fails.

When a SAP egress QoS policy forwarding class is redirected to a queue group queue ID:

If the queue group name does not exist as an egress queue group template, the forwarding class redirection fails.
If a redirection queue ID does not exist within the egress queue group template, the forwarding class redirection fails.
If the SAP egress QoS policy is currently applied to a non-Ethernet port or an Ethernet port where the specified egress queue group does not exist, the forwarding class redirection fails.

When a SAP egress QoS policy forwarding class redirection is removed from a queue group queue ID:

If the forwarding class is being moved to another queue group queue ID that does not exist within an egress queue group template, the redirection removal from the current queue group queue ID fails.
If the forwarding class is being moved to a local queue ID within the SAP egress QoS policy and the local queue ID does not exist, the redirection removal from the current queue group queue ID fails.
If the forwarding class is being moved to a local queue ID within the SAP egress QoS policy and it is the first forwarding class to be mapped to the queue ID, the system attempts to instantiate the queue on each egress SAP where the SAP egress QoS policy is applied. If the queue cannot be created on any of the SAPs, the redirection removal from the current queue group ID fails.

If the preceding operation is successful:

The system decrements the association counter for the egress queue group template with the same name as the queue group previously specified in the forwarding class redirection.
The system decrements the queue ID association counter within the queue group template for the queue ID previously specified in the forwarding class redirection.
The system decrements the port queue group association counter for each egress port queue group where the SAP egress QoS policy is applied to a SAP.

When a SAP ingress QoS policy with a forwarding class redirection to a queue group queue ID is applied to a SAP, the SAP ingress QoS policy application fails if the queue group specified in any forwarding class redirection does not exist as an ingress port queue group on the port associated with the SAP.

If the preceding operation is successful, the system increments the port queue group association counter for each ingress port queue group referenced in a forwarding class redirection on the port associated with the SAP. The ingress port queue group association counter is incremented for each forwarding class redirected to the queue group within the added policy.

When a SAP ingress QoS policy with a forwarding class redirection to a queue group queue ID is removed from a SAP, the SAP ingress QoS policy removal action fails.

If the preceding operation is successful, the system decrements the port queue group association counter for each egress port queue group referenced in a forwarding class redirection within the removed SAP egress QoS policy. The egress port queue group association counter is decremented for each forwarding class redirected to the queue group within the removed policy.

SAP-based provisioning model

When a redirection to a named forwarding plane queue group instance is applied to a SAP on ingress:

If the queue group name does not exist as an ingress queue group template, the redirection fails.
If a queue group name does exist as an ingress queue group template, but the specified instance-id has not been instantiated on the same forwarding plane as used by the SAP, the redirection fails.
If a redirected policer ID in the SAP ingress QoS policy does not match a policer ID in the named ingress queue group template, the redirection fails.
If the SAP ingress QoS policy is currently applied to a non-Ethernet port or an Ethernet port where the specified ingress queue group instance does not exist on the forwarding plane, the redirection fails.

If the preceding operation is successful:

The system increments the association counter for the ingress queue group template with the same name as the queue group specified in the SAP redirection for each forwarding class redirected to the template.
The system increments the policer ID association counter within the queue group template for each forwarding class redirected to a policer ID.
The system increments the forwarding plane queue group instance association counter for each ingress queue group instance where a SAP ingress QoS policy specifying redirection is applied to a SAP.

When redirection to a named queue group is removed from an ingress SAP:

If the forwarding class is being moved to another queue group policer ID that does not exist within the ingress FP queue group, the redirection removal from the current queue group policer ID fails.
If the forwarding class is being moved to a local policer ID within the SAP ingress QoS policy and the local policer ID does not exist, the redirection removal from the current queue group policer ID fails.
If the forwarding class is being moved to a local policer ID within the SAP ingress QoS policy and it is the first forwarding class to be mapped to the policer ID, the system attempts to instantiate the policer on each ingress SAP where the SAP ingress QoS policy is applied. If the policer cannot be created on any of the SAPs, the redirection removal from the current queue group policer ID fails.

If the preceding operation is successful:

The system decrements the association counter for the ingress queue group template with the same name as the queue group previously specified in the forwarding class redirection.
The system decrements the policer ID association counter within the queue group template for the policer ID previously specified in the forwarding class redirection.

The system decrements the forwarding plane queue group template association counter for each ingress queue group where redirection is applied to the ingress SAP.

For the SAP-based provisioning model, the rules for redirecting a forwarding class queue to an egress port queue group are similar to those on ingress.

If an egress QoS policy containing one or more redirections is applied to a SAP, but either no queue group instance is specified at association time, or a named queue group instance is specified and either the queue group name or the instance identifier does not correspond to a queue group that has been created on the egress port, the association is rejected.
If all of the redirections in an egress QoS policy are to queue ids that do not exist in the named queue group instance, then the association is rejected.
If a policer local to a SAP feeds into a SAP-based queue group queue instance, and the queue ID to use is not explicitly specified in the egress QoS policy (through the command policer policer-id port-redirect-group-queue) and is instead inferred from the forwarding class of the policer, but that forwarding class does not exist in the queue group template, then no error is generated. Instead, the queue with the lowest queue ID is used in the queue group instance. If at a later time, a user attempts to add a queue with a specific queue-id to a policer redirect for a specific forwarding class in the egress QoS template, then the system checks that the corresponding queue-id exists in any queue group instances associated with any SAPs using the QoS policy.

Access queue group statistics

Port queue groups

Additional parameters can be configured under port queue groups, for example, an accounting policy, queue overrides, a scheduler policy, and scheduler overrides.

Forwarding plane queue groups

When a forwarding class is redirected to a forwarding plane queue group queue or policer, the packets sent to the queue or policer are statistically tracked by a set of counters associated with the queue group queue/policer and not with any of the counters associated with the SAP.

This means that it is not possible to perform accounting within a queue group based on the source SAPs feeding packets to the queue. That is, the statistics associated with the SAP do not include packets redirected to a queue group queue.

If the user enables the packet-byte-offset {add bytes | subtract bytes} option under the ingress queue-group policer, the byte counters of that policer reflect the adjusted packet size.

The set of statistics per queue are eligible for collection in a similar manner to SAP queues. The collect-stats command enables or disables statistics collection into a billing file based on the accounting policy applied to the queue group.

Network IP interface forwarding class-based redirection

Forwarding class redirection for a network IP interface is defined in a four-step process:

Create an ingress or egress queue group template with the appropriate queues or policers.
Apply an instance of an ingress queue-group template created in step 1 (containing only policers) to the FP ingress network configuration context of card X. In addition, or alternatively, apply an instance of an egress queue-group template created in step 1 to the network egress configuration context of port Y.
Configure the network QoS policy used on the IP interface to redirect ingress traffic to a policer ID (defined in the ingress queue-group template created in step 1) on the basis of forwarding-class and forwarding-type (unicast vs. multicast). In addition, or alternatively, configure the network QoS policy to redirect egress traffic to a queue ID or a policer ID, or both, based on forwarding-class.
Apply the network QoS policy to the network IP interface and at the same time specify the ingress or egress queue-group instances, or both, associated with the interface.

Egress network forwarding class redirection association rules

The association rules work differently for network egress IP interfaces than they do for access SAPs. Because the network QoS policy does not directly reference the queue group names, the system is unable to check for queue group template existence or queue ID existence when the forwarding class queue redirection is defined. Configuration verification can only be checked at the time the network QoS policy is applied to a network IP interface.

The system keeps an association counter for each queue group template and an association counter for each queue ID within the template. The system also keeps an association counter for each queue group created on a port.

When a network QoS policy is applied to an IP interface with the queue group parameter specified:

If the queue group name does not exist as an egress queue group template, the QoS policy application fails.
If a redirection queue ID within the policy does not exist within the egress queue group template, the QoS policy application fails.
If the IP interface is bound to a port (or LAG) and the specified queue group name does not exist on the port, the QoS policy application fails.

If the preceding operation is successful:

The system increments the association counter for the queue group template with the same name as the queue group specified when the QoS policy is applied.
The system increments the queue ID association counter within the queue group template for each forwarding class redirected to the queue ID.
If the IP interface is currently bound to a port (or LAG), the association counter for the queue group on the port is incremented.

When the queue group parameter is removed from an IP interface:

The system decrements the association counter for the queue group template with the same queue group name that was removed from the IP interface.
The system decrements the queue ID association counter within the queue group template for each forwarding class that had previously been redirected to the queue ID.
If the IP interface is currently bound to a port (or LAG), the association counter for the removed queue group on the port is decremented.

When a network QoS policy egress forwarding class redirection to a queue ID is removed or added, the redirection fails if a redirection is being added to a forwarding class and the queue ID does not exist on the queue groups for IP interfaces where the QoS policy is applied.

If the preceding operation is successful:

The system finds all IP interfaces where the policy is applied.
The system finds all affected queue group templates based on the queue group associated with the QoS policy on each interface.
If removing, the queue ID association counter is decremented within each queue group template based on the queue ID removed from the policy.
If adding, the queue ID association counter is incremented within each queue group template based on the queue ID added to the policy.

When an IP interface associated with a queue group is bound to a port, the port binding fails if the specified egress queue group does not exist on the port.

If the preceding operation is successful, the system increments the association counter for the queue group on the port.

When an IP interface associated with a queue group is unbound from a port, the system decrements the association counter for the queue group on the unbound port.

Egress network IP interface statistics

The statistics for network interfaces work differently than statistics on SAPs. Counter sets are created for each egress IP interface and not per egress queue. When a forwarding class for an egress IP interface is redirected from the default egress port queue to a queue group queue, the system continues to use the same counter set.

PW shaping

Ingress PW shaping using spoke-SDP forwarding class-based redirection

Feature configuration

The user applies a network QoS policy to the ingress context of a spoke-SDP to redirect the mapping of a Forwarding Class (FC) to a policer defined in a queue-group template that is instantiated on the ingress Forwarding Plane (FP) where the PW packets are received (this feature applies to both spoke-SDP and mesh-SDP. Spoke-SDP is used throughout for ease of reading).

config>service>vprn>if>spoke-sdp>ingress>qos network-policy-id fp-redirect-group queue-group-name instance instance-id

A policer queue-group refers to a queue-group containing policers. The user must instantiate this queue-group by applying the following command:

config>card>fp>ingress>network>queue-group queue-group-name instance instance-id

The policers are instantiated at ingress FP, one instance per destination tap, and are used to service packets of this spoke-SDP that are received on any port on the FP to support a network IP interface on LAG and on any network IP interface to support ECMP on the network IP interface and LSP reroutes to a different network IP interface on the same FP.

In the ingress context of the network QoS policy, the user defines the mapping of an FC to a policer-id and instructs the code to redirect the mapping to the policer of the same ID in some queue-group:

config>qos>network>ingress>fc>fp-redirect-group policer policer-idconfig>qos>network>ingress>fc>fp-redirect-group broadcast-policer policer-idconfig>qos>network>ingress>fc>fp-redirect-group unknown-policer policer-idconfig>qos>network>ingress>fc>fp-redirect-group mcast-policer policer-id

The user can redirect the unicast, broadcast, unknown, and multicast packets of an FC to different policers to allow for different policing rates for these packet types (broadcast and unknown are only applicable to VPLS services). However, the queue-group is explicitly named only at the time the network QoS policy is applied to the spoke-SDP, as shown in the preceding example of the VPRN service.

When the FC of a PW is redirected to use a policer in the named queue-group, the policer feeds the existing per-FP ingress shared queues referred to as policer-output-queues. These queues are shared by both access and network policers configured on the same ingress FP. The shared queue parameters are configurable using the following command:

config>qos>shared-queue policer-output-queues

The CLI configuration in this section uses a spoke-SDP defined in the context of a VPRN interface. However, the PW shaping feature is supported with all PW-based services including the PW template.

Provisioning model

The following are the constraints and rules of this provisioning model when used in the ingress PW shaping feature:

Only a queue-group containing policers can be instantiated in the network ingress context of an IOM/IMM FP. If the queue-group template contains policers and queues, the queues are not instantiated.
If the queue-group contains queues only, the instantiation in the data path fails.
One or more instances of the of the same queue-group name or a different queue-group name, or both, can be created on network ingress context of an IOM/IMM FP.
The queue-group-name must be unique within all network ingress and access ingress queue groups in the system.
The instantiated FP policer queue-group can be used by PW packets received on a network IP interface configured on both Ethernet ports and POS ports of that IOM/IMM.
When a PW FC is redirected to use a policer in a named policer queue-group and the queue-group name does not exist, the association fails at the time the user associates the ingress context of a spoke-SDP with the named queue-group. In such a case, the PW packet feeds directly into the ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the FP.
When a PW FC is redirected to use a policer in a named policer queue-group and the queue-group name exists but the policer-id is not defined in the queue-group template, the association fails at the time the user associates the ingress context of a spoke-SDP with the named queue-group. In such a case, the PW packet feeds directly into the ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the FP.
When a PW FC is redirected to use a policer in a named policer queue-group and the queue-group name exists and the policer-id is defined in the queue-group template, it is not required to check that an instance of that queue-group exists in all ingress FPs that have network IP interfaces. The handling of this is dealt with in the data path, as follows:
- When a PW packet for that FC is received and an instance of the referenced queue-group name exists on that FP, the packet is processed by the policer and is then fed directly into the per-FP ingress shared queues referred to as policer-output-queues.
- When a PW packet for that FC is received and an instance of the referenced queue-group name does not exist on that FP, the PW packets are fed directly into the corresponding ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the FP.
If a network QoS policy is applied to the ingress context of a PW, any PW FC, that is not explicitly redirected in the network QoS policy has the corresponding packets feed directly into the ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the FP. This behavior is the same regardless of whether the ingress network IP interface from which the PW packet is received is redirected or not to a policer queue-group.
If no network QoS policy is applied to the ingress context of the PW, then all packets of the PW feed:
- the ingress network shared queue for the packet FC defined in the network-queue policy applied to the ingress of the FP. This is the default behavior.
- a queue-group policer followed by the per-FP ingress shared queues referred to as policer-output-queues if the ingress context of the network IP interface from which the packet is received is redirected to a queue-group. The only exceptions to this behavior are for packets received from an IES/VPRN spoke interface and from a R-VPLS spoke-SDP, which is forwarded to the R-VPLS IP interface. In these two cases, the ingress network shared queue for the packet FC defined in the network-queue policy applied to the ingress of the FP is used.

Operationally, the provisioning model in the case of the ingress PW shaping feature consists of the following steps:

Create an ingress queue-group template and configure policers for each FC that needs to be redirected and optionally, for each traffic type (unicast, broadcast, unknown, or multicast).
Apply the queue-group template to the network ingress context of all IOM/IMM FPs where there exists a network IP interface that the PW packets can be received on. This creates one instance of the template on the ingress of the FP. One or more instances of the same template can be created.
Configure FC-to-policer mappings together with the policer redirect to a queue-group in the ingress context of a network QoS policy. No queue-group name is specified in this step, which means the same network QoS policy can redirect different PWs to different queue-group templates.
Apply this network QoS policy to the ingress context of a spoke-SDP inside a service or to the ingress context of a PW template and specify the redirect queue-group name.

One or more spoke-SDPs can have their FCs redirected to use policers in the same policer queue-group instance.

Ingress packet classification

When a PW is redirected to use a policer queue-group, the classification of the packet for the purpose of FC and profile determination is performed according to the default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the PW. This is true regardless of whether an instance of the named policer queue-group exists on the ingress FP that the PW packet is received on. The user can apply a QoS filter matching the dot1p in the VLAN tag corresponding to the Ethernet port encapsulation, the EXP in the outer label when the tunnel is an LSP, the DSCP in the IP header if the tunnel encapsulation is GRE, and the DSCP in the payload’s IP header if the user enabled the ler-use-dscp option and the PW terminates in IES or VPRN service (spoke-interface).

When the policer queue-group name to which PW is redirected does not exist, the redirection command fails. In this case, the packet classification is performed according to the default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the network IP interface that the PW packet is received on.

Egress PW shaping using spoke-SDP forwarding class-based redirection

Feature configuration

The user applies a network QoS policy to the egress context of a spoke-sdp to redirect the mapping of a Forwarding Class (FC) to a policer or a queue, or both, parts of a queue-group instance created in the egress of a network port.

config>service>vprn>if>spoke-sdp>egress>qos network-policy-id port-redirect-group queue-group-name instance instance-id

The queue-group queues or policers are instantiated at egress port, one instance per network port and per link of LAG network port, and are used to service packets of this spoke-SDP, which are forwarded over any network IP interface on this port.

config>port>ethernet>network>egress>queue-group queue-group-name instance instance-id

In the egress context of the network QoS policy, the user defines the mapping of an FC to a policer-id or a queue-id and instructs the code to redirect the mapping to the queue or policer of the same ID in some queue-group. However, the queue-group is explicitly named only at the time the network QoS policy is applied to the spoke-SDP, as shown in the preceding example of the VPRN service. The command is as follows:

config>qos>network>egress>fc>port-redirect-group {queue queue-id | policer policer-id [queue queue-id]}

There are three possible outcomes when executing this command:

The user can redirect an FC to use a queue in a queue-group, in which case there are no policers used.

config>qos>network>egress>fc>port-redirect-group queue queue-id
The user can redirect an FC to use a policer-id in a queue-group without specifying a queue-id and in which case the policer is feeding the egress shared queue for that FC defined in the network-queue policy applied to the egress of this port.

config>qos>network>egress>fc>port-redirect-group policer policer-id
The user can redirect an FC to use a policer feeding a queue both of which are defined in the named queue-group.

config>qos>network>egress>fc>port-redirect-group policer policer-id queue queue-id

The CLI configuration in this section uses a spoke-sdp defined in the context of a VPRN interface. However, the PW shaping feature is supported with all PW-based services including the PW template.

Provisioning model

This provisioning model allows the mapping of one or more PWs to the same instance of queues, or policers and queue, that are defined in the queue-group template.

The following are the constraints and rules of this provisioning model:

Queue-groups containing queues only or policers and queues can be instantiated in the network egress context of an Ethernet port on IOM/IMM.
When a port is a LAG, one instance of the queue-group is instantiated on each member link.
One or more instances of the same queue-group name or a different queue-group name, or both, can be created in the network egress context of an Ethernet port.
The queue-group-name must be unique within all network egress and access egress queue groups in the system.
A user attempt to instantiate the queue-group on the network egress context of a POS port or a TDM port fails.
When a PW FC is redirected to use a queue or a policer and a queue in a queue-group and the queue-group name does not exist, the association fails at the time the user associates the egress context of a spoke-SDP with the named queue-group. In such a case, the PW packet is fed directly to the corresponding egress queue for that FC used by the IP network interface that the PW packet is forwarded on. This queue can be a queue-group queue or the egress shared queue for that FC defined in the network-queue policy applied to the egress of this port. This is the existing implementation and default behavior for a PW packet.
When a PW FC is redirected to use a queue or a policer and a queue in a queue-group and the queue-group name exists but the policer-id or the queue-id, or both, are not defined in the queue-group template, the association fails at the time the user associates the egress context of a spoke-SDP with the named queue-group. In such a case, the PW packet is fed directly to the corresponding egress queue for that FC used by the IP network interface that the PW packet is forwarded on.
When a PW FC is redirected to use a queue or a policer and a queue in a queue-group and the queue-group name exists and the policer-id or policer-id plus queue-id exist, it is not required to check that an instance of that queue-group exists in all egress network ports that have network IP interfaces. The handling of this is dealt with in the data path as follows:
- When a PW packet for that FC is forwarded and an instance of the referenced queue-group name exists on that egress port, the packet is processed by the queue-group policer and is fed to the queue-group queue. If only a policer is specified in the redirection command, then the packet is processed by the queue-group policer and is then fed into the corresponding egress shared queue for that FC defined in the network-queue policy applied to the egress of this port. If only a queue is specified in the redirection command, the packet is fed to the queue-group queue.
- When a PW packet for that FC is forwarded and an instance of the referenced queue-group name does not exist on that egress port, the PW packet is fed directly to the corresponding egress shared queue for that FC defined in the network-queue policy applied to the egress of this port.
- If a network QoS policy is applied to the egress context of a PW, any PW FC that is not explicitly redirected in the network QoS policy has the corresponding packets feed directly into the corresponding egress shared queue for that FC defined in the network-queue policy applied to the egress of this port.

Operationally, the provisioning model consists of the following steps:

Create an egress queue-group template and configure queues only or policers and queues for each FC that needs to be redirected.
Apply the queue-group template to the network egress context of all IOM/IMM ports where there exists a network IP interface that the PW packets can be forwarded on. This creates one instance of the template on the egress of the port. One or more instances of the same template can be created.
Configure FC-to-policer or FC-to-queue mappings together with the redirect to a queue-group in the egress context of a network QoS policy. No queue-group name is specified in this step which means the same network QoS policy can redirect different PWs to different queue-group templates.
Apply this network QoS policy to the egress context of a spoke-SDP inside a service or to the egress context of a PW template and specify the redirect queue-group name.

One or more spoke-sdps can have their FCs redirected to use queues only or queues and policers in the same queue-group instance.

Egress marking of PW packet header

When the queue-group name that the PW is redirected to exists and the redirection succeeds, the marking of the packet’s DEI/dot1p/DSCP and the tunnel’s DEI/dot1p/DSCP/EXP is performed according to the relevant mappings of the {FC, profile} in the egress context of the network QoS policy applied to the PW. This is true if an instance of the queue-group exists on the egress port that the PW packet is forwarded to. If the packet’s profile value changed because of egress child policer CIR profiling, the new profile value is used to mark the packet’s DEI/dot1p and the tunnel’s DEI/dot1p/EXP and the DSCP or IP precedence is remarked if enable-dscp-prec-remarking is enabled under the policer.

When the redirection command succeeds but there is no instance of the queue-group on the egress port, or when the redirection command fails because of a non-existent queue-group name, the marking of the packet’s DEI/dot1p/DSCP and the tunnel’s DEI/dot1p/DSCP/EXP fields is performed according to the relevant commands in the egress context of the network QoS policy applied to the network IP interface that the PW packet is forwarded to.

Ingress and egress PW statistics

The PW forwarded packet and octet statistics (SDP binding statistics) are currently supported for both ingress and egress and are available via show command, monitor command, and accounting file. These statistics consist of the ingress-forwarded and ingress-dropped packet and octet counters, as well as the egress-forwarded packet and octet counters. However, they do not include discards in the ingress network queues. The latter are counted in the stats of the queues defined in the network-queue policy applied to the ingress of the FP.

The ingress and egress SDP binding stats do not count the label stack of the PW packet but count the PW Control Word (CW) if included in the packet.

With the introduction of the PW shaping feature—the ingress or egress queue-group policer—a PW FC is redirected to also provide packet and octet forwarded and dropped statistics by means of the show command, monitor command, and accounting file of the ingress or egress queue-group instance.

Similar to the SDP binding stats, the ingress policer stats for a spoke-SDP does not count the label stack. When the spoke-SDP is part of a L2-service, they count the L2-encapsulation, minus CRC and VLAN tag if popped out, and they also count the PW CW, if included in the packet. When the spoke-SDP is part of a L3-service, the policer stats only count the IP payload and do not count the PW CW. Unlike the ingress SDP binding stats, if the user enables the packet-byte-offset {add bytes | subtract bytes} option under the queue-group policer, then the policer stats reflect the adjusted packet size in both L2 and L3-spoke-SDPs.

The egress queue-group policer or queue, or both, count the full label stack of the PW packet including the CW. If the user enables the packet-byte-offset {add bytes | subtract bytes} option under the queue-group policer and queue-group queue, then the policer and queue stats reflect the adjusted packet size.

The SDP binding and queue-group statistics do, however remain separate as one or more PWs can have FCs redirected to the same policer ID in the queue-group instance.

Queue group behavior on LAG

Queue group queue instantiation per link

When a port queue group is created on a Link Aggregation Group (LAG) context, it is individually instantiated on each link in the LAG.

Per-link queue group queue parameters

The queue parameters for a queue within the queue group are used for each port queue and are not divided or split between the port queues representing the queue group queue. For instance, when a queue rate of 100 Mb/s is defined on a queue group queue, each instance of the queue group (on each LAG port) has a rate of 100 Mb/s.

Adding a queue group to an existing LAG

A queue group must be created on the primary (lowest port ID) port of the LAG. If an attempt is made to create a queue group on a port other than the primary, the attempt fails. When the group is defined on the primary port, the system attempts to create the queue group on each port of the LAG. If sufficient resources are not available on each port, the attempt to create the queue group fails.

Any queue group queue overrides defined on the primary port are automatically replicated on all other ports within the LAG.

Adding a port to a LAG

When adding a port to a LAG group, the port must have the same queue groups defined as the existing ports on the LAG before it is allowed as a member. This includes all queue group override parameters.

Removing a queue group from a LAG

A queue group must be removed from the primary port of the LAG. The queue group is deleted by the system from each of the port members of the LAG.

Basic configurations

Configuring an ingress queue group template

The following displays an ingress queue group template configuration example:

*A:Dut-T>cfg>qos>qgrps# info 
----------------------------------------------
            ingress
                queue-group "QG_ingress_1" create
                    queue 1 best-effort create
                        mbs 100
                    exit
                    queue 2 best-effort create
                        mbs 100
                    exit
                    queue 3 best-effort create
                        mbs 100
                    exit
                    queue 4 best-effort create
                        mbs 100
                    exit
                exit
            exit
----------------------------------------------
*A:Dut-T>cfg>qos>qgrps#

Note: To fully use the queue group feature to save queues, explicitly map all forwarding classes to queue group queues. This rule is applicable to SAP ingress, SAP egress, and network QoS policies.

Configuring an egress queue group template

The following displays an egress queue group template configuration example:

*A:Dut-T>cfg>qos>qgrps# info 
----------------------------------------------
...
            egress
                queue-group "QG_egress_1" create
                    description "Egress queue group"
                    queue 1 best-effort create
                        mbs 100
                    exit              
                    queue 2 best-effort create
                        mbs 100
                    exit
                    queue 3 best-effort create
                        mbs 100
                    exit
                    queue 4 best-effort create
                        mbs 100
                    exit
                exit
            exit
----------------------------------------------
*A:Dut-T>cfg>qos>qgrps#

Applying ingress queue group to SAP ingress policy

The following displays a SAP ingress policy configuration with group queue-group-name specified:

*A:Dut-T>config>qos>sap-ingress# info 
----------------------------------------------
            queue 1 create
            exit
            queue 11 multipoint create
            exit
            fc "af" create
                queue 2 group "QG_ingress_1"
            exit
            fc "be" create
                queue 1 group "QG_ingress_1"
            exit
            fc "ef" create
                queue 3 group "QG_ingress_1"
            exit
            fc "nc" create
                queue 4 group "QG_ingress_1"
            exit
            dot1p 0 fc "be"
            dot1p 2 fc "af"
            dot1p 4 fc "ef"
            dot1p 6 fc "nc"
----------------------------------------------
*A:Dut-T>config>qos>sap-ingress#

Applying egress queue group to SAP egress policy

The following displays a SAP egress policy configuration with group queue-group-name specified:

A:Dut-T>config>qos>sap-egress# info 
----------------------------------------------
            queue 1 create
            exit
            fc af create
                queue 2 group "QG_egress_1"
            exit 
            fc be create
                queue 1 group "QG_egress_1"
            exit 
            fc ef create
                queue 3 group "QG_egress_1"
            exit 
            fc nc create
                queue 4 group "QG_egress_1"
            exit 
----------------------------------------------
A:Dut-T>config>qos>sap-egress#

Configuring SAP-based egress queue redirection

The following displays a SAP egress policy configuration with port-redirect-group-queue construct (shown for regular egress queues) and the actual queue-group-name is determined by the SAP egress QoS configuration:


*A:Dut-A# configure qos sap-egress 3 
*A:Dut-A>config>qos>sap-egress# info 
----------------------------------------------
            queue 1 create
            exit
            queue 2 create
            exit
            policer 8 create
                rate 50000
            exit
            fc af create
                queue 3 port-redirect-group-queue
                exit
            exit 
            fc be create
                queue 3 port-redirect-group-queue
                exit
            exit 
            fc ef create
                policer 8 port-redirect-group-queue
                exit
            exit 
            fc h1 create
                queue 3 port-redirect-group-queue
                exit
            exit 
            fc h2 create
                queue 3 port-redirect-group-queue
                exit
            exit 
            fc l1 create
                queue 3 port-redirect-group-queue
                exit
            exit 
            fc l2 create
                queue 3 port-redirect-group-queue
                exit
            exit 
            fc nc create
                queue 3 port-redirect-group-queue
                exit
            exit 
----------------------------------------------

This is to be configured in-conjunction with the following:


*A:Dut-A# configure service vpls 1 
*A:Dut-A>config>service>vpls# info 
----------------------------------------------
            stp
                shutdown
            exit
            sap 9/1/2:1 create
                egress
                    qos 3 port-redirect-group qg1 instance 101
                exit
            exit

Configuring queue group on Ethernet access ingress port

The provisioning steps involved in using a queue-group queue on an ingress port are:

Create the queue group template.
1. Create the queue group template in the ingress context.
2. Create the queue within the queue group template.
Create the queue group.
1. Identify the ingress port (or ports) for which the queue group is needed (for LAG, use the primary port member).
2. Create a queue group with the same name as the template on the port or ports.
Map a forwarding class to the queue-id within the queue group.
1. Map forwarding classes to queue-group queues.
2. Identify or create the SAP ingress QoS policy that is used on the ingress SAP where queue redirection is needed.
3. Map the needed forwarding classes to the queue group name and the specific queue ID within the group.
Apply the SAP ingress QoS policy.
1. Identify or create the ingress SAP requiring forwarding class redirection to the queue group.
2. Assign the QoS policy to the SAP.

The following displays an Ethernet access ingress port queue-group configuration example:

*A:Dut-T>config>port# /configure port 9/2/1
*A:Dut-T>config>port# info
----------------------------------------------
        ethernet
            mode access
            access
                ingress
                    queue-group "QG_ingress_1" create
                    exit
                exit
                egress
                    queue-group "QG_egress_1" create
                    exit
                exit
            exit
        exit
        no shutdown
----------------------------------------------
*A:Dut-T>config>port# 
 
*A:Dut-T>config>port# /configure port 9/2/2
*A:Dut-T>config>port# info 
----------------------------------------------
        ethernet
            mode access
            access
                ingress
                    queue-group "QG_ingress_1" create
                    exit
                exit
                egress
                    queue-group "QG_egress_1" create
                    exit
                exit
            exit
        exit
        no shutdown
----------------------------------------------
*A:Dut-T>config>port#

Configuring overrides

The following output displays a port queue group queue override example.

*A:Dut-T>config>port>ethernet>access# /configure port 9/2/1 
*A:Dut-T>config>port# info 
----------------------------------------------
        ethernet
            mode access
            access
                ingress
                    queue-group "QG_ingress_1" create
                        queue-overrides
                            queue 2 create
                                rate 800000 cir 20000
                            exit
                        exit
                    exit
                exit
                egress
                    queue-group "QG_egress_1" create
                    exit
                exit
            exit
        exit
        no shutdown
----------------------------------------------
*A:Dut-T>config>port# /configure port 9/2/2 
*A:Dut-T>config>port# info 
----------------------------------------------
        ethernet
            mode access
            access
                ingress
                    queue-group "QG_ingress_1" create
                    exit
                exit
                egress
                    queue-group "QG_egress_1" create
                        queue-overrides
                            queue 3 create
                                rate 1500000 cir 2000
                            exit
                        exit
                    exit
                exit
            exit
        exit
        no shutdown
----------------------------------------------
*A:Dut-T>config>port#

Configuring queue group on Ethernet access egress port

The provisioning steps involved in using a queue-group queue on an egress access port are:

Create the queue group template.
1. Create the queue group template in the egress context.
2. Create the queue within the queue group template.
Create the queue group.
1. Identify the egress port (or ports) for which the queue group is needed (for LAG use the primary port member).
2. Create a queue group instance with the same name as the template on the port or ports.

From this point, there are two methods for regular Ethernet-based SAPs to have port access egress redirection, policy-based redirection and SAP-based redirection. For policy-based redirection:

Map a forwarding class to the queue-id within the queue group.
1. Identify or create the SAP egress QoS policy that is used on the egress SAP where policy-based queue redirection is needed.
2. Map the needed forwarding classes to the queue group name and the specific queue ID within the group with the ‟group” keyword.
Apply the SAP egress QoS policy.
1. Identify or create the egress SAP requiring forwarding class redirection to the queue group.
2. Assign the QoS policy to the SAP.

For SAP-based redirection:

Map a forwarding class to the queue-id within the queue group.
1. Identify or create the SAP egress QoS policy that is used on the egress SAP where SAP-based queue redirection is needed.
2. Map the needed forwarding classes to the queue group specific queue-id, and the keyword "port-redirect-group-queue". The actual queue-group template name is determined by the sap instance's configuration that associated the sap-egress qos policy in conjunction with the port-redirect-group's instance.
Apply the SAP egress QoS policy and the queue-group template's instance under the SAP.
1. Identify or create the egress SAP requiring forwarding class redirection to the queue group.
2. Assign the QoS policy and the egress queue-group template's instance to the SAP.

Configuring queue group for network egress traffic on port

The provisioning steps involved in using a queue-group queue on an egress network port are:

Create the queue group template.
1. Create the egress queue group template.
2. Create the queues or policers, or both, within the queue group template.
Create the queue group.
1. Identify the egress port (or ports) on which the queue group is needed (for LAG, use the primary port member).
2. Create a queue group with the same name as the template on the port or ports. The instance ID is optional.
Map a forwarding class to the queue-id within the queue group.
1. Identify or create the network QoS policy that is used on the egress IP interface where queue redirection is needed.
2. Map the needed egress forwarding classes within the network QoS policy to the specific queue IDs or policer IDs, or both, within the group (the group name is supplied when the QoS policy is applied to the IP interface).
Apply the network QoS policy.
1. Identify or create the IP interface requiring forwarding class redirection to the queue group.
2. Assign the QoS policy to the IP interface and specify the queue group name (and optionally, instance ID) for redirection of egress traffic.

When a queue within a template is mapped by a forwarding class on any object, the queue may be edited, but not deleted.

Configuring queue group for network ingress traffic on forwarding plane

The provisioning steps involved in using a queue-group for ingress traffic on a network interface are:

Create the queue group template.
1. Create the ingress queue group template.
2. Create the policers within the queue group template.
Create the queue group.
1. Identify the ingress forwarding plane on which the queue group is needed.
2. Create a queue group with the same name as the template in the FP ingress network configuration context. An instance ID is mandatory.
Map a forwarding class to the policer-id within the queue group.
1. Identify or create the network QoS policy that is used on the ingress IP interface where queue redirection is needed.
2. Map the needed ingress forwarding classes within the network QoS policy to the specific policer IDs within the group (the group name is supplied when the QoS policy is applied to the IP interface).
Apply the network QoS policy.
1. Identify or create the IP interface requiring forwarding class redirection to the queue group.
2. Assign the QoS policy to the IP interface and specify the queue group name and instance ID for redirection of ingress traffic.

Using queue groups to police ingress/egress traffic on network interface

An example of the provisioning steps involved in using a queue-group to police ingress and egress traffic on a network interface is as follows:

config    
    qos
        queue-group-templates
            ingress
                queue-group "Ingress_QG_1" create
                    policer 2 create
                        rate 9000
                    exit
                exit
            exit
            egress
                queue-group "Egress_QG_1" create
                    queue 1 best-effort create
                    exit
                    policer 2 create
                        rate 9000
                    exit
                exit
            exit
        exit

        network 2 create
            ingress
                fc be
                    fp-redirect-group policer 2
                exit
            exit
            egress
                fc be
                    port-redirect-group policer 2
                exit
            exit
        exit

    
    card 1
        card-type xcm-x20
            mda 1                 mda-type cx20-10g-sfp                 no shutdown
            exit
        fp 1
            ingress
                network
                    queue-group "Ingress_QG_1" instance 550 create
                    exit
                exit
            exit
        exit
        no shutdown
    
    port 1/1/3
        ethernet
                mtu 1514
                network
                    egress
                        queue-group "Egress_QG_1" instance 550 create
                        exit
                    exit
                exit
            exit
        no shutdown
    exit

    router
        interface ‟to-D”
        address 10.10.11.3/24
        port 1/1/3
        qos 2 egress-port-redirect-group "Egress_QG_1" egress-instance 
        550 ingress-fp-redirect-group "Ingress_QG_1" ingress-instance     
        550
        no shutdown

Configuring ingress/egress PW shaping using spoke-SDP forwarding class-based redirection

An example of the provisioning steps involved in configuring PW shaping using spoke-SDP forwarding class-based redirection is as follows:

configure
#--------------------------------------------------
echo "QoS Policy Configuration"
#--------------------------------------------------
    qos
        queue-group-templates
            ingress
                queue-group "QGIng1" create
                    policer 1 create
                    exit
                    policer 2 create
                    exit
                    policer 3 create
                    exit
                    policer 4 create
                    exit
                exit
            exit
            egress
                queue-group "QGEgr1" create
                    queue 1 best-effort create
                    exit
                    policer 1 create
                    exit
                    policer 2 create
                    exit
                    policer 3 create
                    exit
                    policer 4 create
                    exit
                exit
            exit
        exit
    exit
        network 10 create
            ingress
                lsp-exp 0 fc be profile out
                lsp-exp 1 fc be profile out
                lsp-exp 2 fc be profile out
                lsp-exp 3 fc be profile out
                lsp-exp 4 fc be profile out
                lsp-exp 5 fc be profile out
                lsp-exp 6 fc be profile out
                lsp-exp 7 fc be profile out
                fc af
                    fp-redirect-group policer 4
                exit
                fc be
                    fp-redirect-group policer 1
                exit
                fc l1
                    fp-redirect-group policer 2
                exit
                fc l2
                    fp-redirect-group policer 3
                exit
            exit
            egress
                fc af
                    port-redirect-group policer 4
                exit
                fc be
                    port-redirect-group policer 1
                exit
                fc l1
                    port-redirect-group policer 2
                exit
                fc l2
                    port-redirect-group policer 3
                exit
            exit
        exit
    exit
#--------------------------------------------------
echo "Card Configuration"
#--------------------------------------------------
    card 3
        fp 1
            ingress
                network
                    queue-group "QGIng1" instance 1 create
                    exit
                    queue-group "QGIng1" instance 2 create
                    exit
                exit
            exit
        exit
    exit
#--------------------------------------------------
echo "Port Configuration"
#--------------------------------------------------
    port 3/2/1
        ethernet
            encap-type dot1q
            network
                egress
                    queue-group "QGEgr1" instance 1 create
                    exit
                    queue-group "QGEgr1" instance 2 create
                    exit
                exit
            exit
        exit
        no shutdown


*A:Dut-T>config>service#
        customer 1 create
            description "Default customer"
        exit
        sdp 1 mpls create
            description "Default sdp description"
            far-end 198.51.100.0
            ldp
            path-mtu 9000
            keep-alive
                shutdown
            exit
            no shutdown
        exit 
        vpls 1 customer 1 vpn 1 create
            description "Default tls description for service id 1"
            service-mtu 9000
            stp
                shutdown
            exit
            service-name "XYZ Vpls 1"
            sap 9/2/1:1.* create
                description "Default sap description for service id 1"
                static-mac 00:00:1e:00:01:02 create
                ingress
                    qos 10
                exit
            exit
            spoke-sdp 1:101 vc-type vlan create
                description "Description for Sdp Bind 1 for Svc ID 1"
                ingress
                    qos 10 fp-redirect-group "QGIng1" instance 1
                exit
                egress
                    qos 10 port-redirect-group "QGEgr1" instance 1
                exit
                static-mac 00:00:28:00:01:02 create
                no shutdown
            exit
            no shutdown
        exit


    router
        interface "ip-192.168.0.0"
            address 192.168.0.0/24
            port 3/2/1:1
        exit
        interface "system"
            address 192.168.0.1/32
        exit
#---------------------------------------------

Specifying QoS policies on service SAPs

The following output displays a VPLS service configuration example.

*A:Dut-T>config>service>vpls# info 
----------------------------------------------
            stp
                shutdown
            exit
            sap 9/2/1 create
                ingress
                    qos 10 
                exit
                egress
                    qos 10
                exit
            exit
            sap 9/2/2 create
                ingress
                    qos 10 
                exit
                egress
                    qos 10
                exit
            exit
            no shutdown
----------------------------------------------
*A:Dut-T>config>service>vpls#