2.2.1. High-Priority Classes

The high-priority forwarding classes are Network-Control (nc), Expedited (ef), High-1 (h1), and High-2 (h2). High-priority forwarding classes are always serviced at congestion points over other forwarding classes; this behavior is determined by the router queue scheduling algorithm. See Virtual Hierarchical Scheduling for more information.

With a strict PHB at each network hop, service latency is mainly affected by the amount of high-priority traffic at each hop. These classes are intended to be used for network control traffic or for delay- or jitter-sensitive services.

If the service core network is oversubscribed, a mechanism to engineer a path through the core network and to reserve bandwidth must be used to apply strict control over the delay and bandwidth requirements of high-priority traffic. In the router, RSVP-TE can be used to create a path defined by an MPLS LSP through the core. Premium services are then mapped to the LSP, with care to not oversubscribe the reserved bandwidth.

If the core network has sufficient bandwidth, it is possible to effectively support the delay and jitter characteristics of high-priority traffic without using traffic engineered paths, as long as the core treats high-priority traffic with the correct PHB.

2.2.2. Assured Classes

The assured forwarding classes are Assured (af) and Low 1 (l1). Assured forwarding classes provide services with a committed rate and a peak rate, much like Frame Relay. Packets transmitted through the queue at or below the committed transmission rate are marked in-profile. If the core service network has sufficient bandwidth along the path for the assured traffic, all aggregate in-profile service packets will reach the service destination.

Packets transmitted from the service queue that are above the committed rate will be marked out-of-profile. When an assured out-of-profile service packet is received at a congestion point in the network, it will be discarded before in-profile assured service packets.

Multiple assured classes are supported with relative weighting between them. In DiffServ, the code points for the various Assured classes are AF4, AF3, AF2, and AF1. Typically, AF4 has the highest weight of the four and AF1 the lowest. The Assured and Low-1 classes are differentiated based on the default DSCP mappings. All DSCP and EXP mappings can be modified by the user.

2.2.3. Best-Effort Classes

The best-effort classes are Low 2 (l2) and Best-Effort (be). The best-effort forwarding classes have no delivery guarantees. All packets within this class are treated by default as out-of-profile assured service packets.

2.3.1. Queue ID

The queue ID is used to uniquely identify the queue. The queue ID is only unique within the context of the QoS policy within which the queue is defined.

2.3.2. Unicast or Multipoint Queue

Unicast queues are used for all services and routing when the traffic is forwarded to a single destination.

Multipoint ingress queues are used by VPLS services for multicast, broadcast, and unknown traffic and by IES and VPRN services for multicast traffic when IGMP, MLD, or PIM is enabled on the service interface.

2.3.3. Queue Type

The type of a queue dictates how it will be scheduled relative to other queues at the hardware level. Being able to define the scheduling properties of a queue is important because a single queue allows support for multiple forwarding classes.

The queue type defines the relative priority of the queue and can be configured to expedited (higher priority) or best-effort (lower) priority. However, the instantaneous scheduling priority of a queue changes dynamically depending on its current scheduling rate compared to its operational Committed Information Rate (CIR) and Fair Information Rate (FIR) (see Queue Scheduling). Parental virtual schedulers can be defined for the queue using scheduler policies which enforce how the queue interacts for bandwidth with other queues associated with the same scheduler hierarchy (see Scheduler Policies).

The queue type of SAP ingress and egress queues, network queue policy queues, and ingress queue group template queues are defined at queue creation time. The queue type of egress queue group template queues and shared-queue policy queues can be modified after the queue has been created.

The default behavior for SAP ingress and egress queues, network queue policy queues, and shared queue policy queues is to automatically choose the expedited or best effort nature of the queue based on the forwarding classes mapped to it. This is achieved by configuring the queue type to auto-expedited. As long as all forwarding classes mapped to the queue are expedited (nc, ef, h1, or h2), the queue will be treated as an expedited queue by the hardware schedulers. When any best effort forwarding classes are mapped to the queue (be, af, l1, or l2), the queue will be treated as best effort by the hardware schedulers.

The default queue type for ingress queue group template and egress queue group template queues is best-effort.

2.3.4. Queue Scheduling

Packets are scheduled from queues by hardware schedulers based on the type of the queue (see Queue Type) and the current scheduling rate of the queue compared to its operational CIR and FIR. This applies to unicast queues at both ingress and egress, and multipoint queues at ingress, but not to HSQ IOM queues.

The queue type should be chosen based on the kind of traffic in the forwarding classes mapped to the queue.

The hardware scheduler services queues to forward packets from them in a strict priority order, as follows:

2.3.5. Peak Information Rate

The Peak Information Rate (PIR) defines the maximum rate at which packets are allowed to exit the queue. The PIR does not specify the maximum rate at which packets may enter the queue; this is governed by the queue's ability to absorb bursts and is defined by its maximum burst size (MBS).

The actual transmission rate of a service queue depends on more than just its PIR. Each queue is competing for transmission bandwidth with other queues. Each queue's PIR, CIR, FIR, and the queue type (see Queue Type) all combine to affect a queue's ability to transmit packets, as described in Queue Scheduling.

The PIR is provisioned on ingress and egress queues within service ingress and egress QoS policies, network queue policies, ingress and egress queue group templates, and shared queue policies.

When defining the PIR for a queue, the value specified is the administrative PIR for the queue. The router has a number of native rates in hardware that it uses to determine the operational PIR for the queue. The user has some control over how the administrative PIR is converted to an operational PIR should the hardware not support the exact PIR value specified. The interpretation of the administrative PIR is discussed in Adaptation Rule.

2.3.6. Committed Information Rate

The Committed Information Rate (CIR) for a queue performs two distinct functions:

All router queues support the concept of in-profile, out-of-profile, together with inplus-profile and exceed-profile at egress only. The network QoS policy applied at network egress determines how or if the profile state is marked in packets transmitted into the service core network. If the profile state is marked in the service core packets, the packets are dropped preferentially at congestion points in the core as follows:

When defining the CIR for a queue, the value specified is the administrative CIR for the queue. The router has a number of native rates in hardware that it uses to determine the operational CIR for the queue. The user has some control over how the administrative CIR is converted to an operational CIR if the hardware does not support the exact CIR specified. See Adaptation Rule for more information about the interpretation of the administrative CIR.

Although the router is flexible in how the CIR can be configured, there are conventional ranges for the CIR based on the forwarding class of a queue. A service queue associated with the high-priority class normally has the CIR threshold equal to the PIR rate, although the router allows the CIR to be provisioned to any rate below the PIR if this behavior is required. If the service queue is associated with a best-effort class, the CIR threshold is normally set to zero; however, this is flexible.

The CIR for a service queue is provisioned in ingress and egress service queues within service ingress QoS policies and service egress QoS policies respectively. CIRs for network queues are defined within network queue policies. CIRs for queue group instance queues are defined within ingress and egress queue group templates.

2.3.7. Fair Information Rate

A Fair Information Rate (FIR) can be configured on a queue to utilize two additional scheduling priorities (expedited queue within FIR and best-effort queue within FIR). The queues which operate below their FIR are always served before the queues operating at or above their FIR. See Queue Scheduling for more information about queue scheduling.

The FIR does not affect the queue packet profiling operation which is dependent only on the queue's CIR rate at the time that the packet is scheduled; the FIR is purely a scheduling mechanism.

When defining the FIR for a queue, the value specified is the administrative FIR for the queue. The router has a number of native rates in hardware that it uses to determine the operational FIR for the queue. The user has some control over how the administrative FIR is converted to an operational FIR if the hardware does not support the exact FIR specified. See Adaptation Rule for more information about the interpretation of the administrative FIR.

The FIR rate is supported in SAP ingress QoS policies (for ingress SAP and subscriber queues), ingress queue group templates (for access ingress queue group queues), and network queue policies (for ingress and egress network queues). The FIR can also be configured on system-created ingress shared queues. The FIR is configured in kb/s in a SAP ingress QoS policy and an ingress queue group template, and as a percent in a SAP ingress QoS policy, network queue policy, and ingress shared queue. The default FIR rate is zero (0) with an adaptation rule closest.

FIR is only supported on FP4-based hardware and is ignored when the related policy is applied to FP2- or FP3-based hardware.

The FIR rate is not used within virtual hierarchical scheduling (see Virtual Hierarchical Scheduling), but it is capped by the resulting operational PIR.

A FIR should not be configured in a SAP ingress QoS policy, ingress queue group template, or network queue policy associated with a LAG which spans FP4-based and FP2- or FP3-based hardware as the resulting operation could be different depending on which hardware type the traffic uses.

2.3.8. Adaptation Rule

The adaptation rule provides the QoS provisioning system with the ability to adapt specific FIR-, CIR-, and PIR-defined administrative rates to the underlying capabilities of the hardware that the queue will be created on to derive the operational rates. The administrative FIR, CIR, and PIR rates are translated to operational rates enforced by the hardware queue. The adaptation rule provides a constraint used when the exact rate is not available due to hardware implementation trade-offs.

For the FIR, CIR, and PIR parameters individually, the system will attempt to find the best operational rate depending on the defined constraint. The supported constraints are:

Depending on the hardware on which the queue is provisioned, the operational FIR, CIR, and PIR settings used by the queue will depend on the method that the hardware uses to implement and represent the mechanisms that enforce the FIR, CIR, and PIR rates.

As the hardware has a very granular set of rates, Nokia’s recommended method to determine which hardware rate is used for a queue is to configure the queue rates with the associated adaptation rule and use the show pools output command to display the rate achieved.

To illustrate how the adaptation rule constraints (minimum, maximum, and closest) are evaluated in determining the operational CIR or PIR rates, assume there is a queue on an IOM3-XP where the administrative CIR and PIR rates are 401 Mb/s and 403 Mb/s, respectively.

The following output shows the operating CIR and PIR rates achieved for the different adaptation rule settings:

2.3.9. Committed Burst Size

The Committed Burst Size (CBS) parameter specifies the size of buffer that can be drawn from the reserved buffer portion of the queue buffer pool. When the reserved buffers for a given queue have been used, the queue competes with other queues for additional buffer resources up to the MBS.

The CBS is provisioned on ingress and egress service queues within service ingress QoS policies and service egress QoS policies, respectively. The CBS for a queue is specified in kbytes.

The CBS for a network queue is defined within network queue policies based on the forwarding class. The CBS for the queue for the forwarding class is defined as a percentage of buffer space for the pool.

2.3.10. Maximum Burst Size

The Maximum Burst Size (MBS) parameter specifies the maximum queue depth to which a queue can grow. This parameter ensures that a customer that is massively or continuously over-subscribing the PIR of a queue will not consume all the available buffer resources. For high-priority forwarding class service queues, the MBS can be relatively smaller than the other forwarding class queues because the high-priority service packets are scheduled with priority over other service forwarding classes.

The MBS is provisioned on ingress and egress service queues within service ingress QoS policies and service egress QoS policies, respectively. The MBS for a service queue is specified in bytes or kbytes.

The MBSs for network queues are defined within network queue policies based on the forwarding class. The MBSs for the queues for the forwarding class are defined as a percentage of buffer space for the pool.

2.3.11. Queue Drop Tails

The MBS determines the maximum queue depth after which no additional packets are accepted into the queue. Additional queue drop tails are available for the different packet profiles to allow preferential access to the queue's buffers which allows higher priority packets to be accepted into a queue when there is congestion for lower priority packets.

At ingress there is a low drop tail in addition to the MBS. High enqueuing priority packets (for ingress SAP priority mode queues) and in-profile packets (for ingress SAP profile mode queues, network, and shared queues) are allowed to fill up the queue up to the MBS, however, low enqueuing priority packets (for ingress SAP priority mode queues) and out-of-profile packets (for ingress SAP profile mode queues, network, and shared queues) can only fill the queue up to the queue's low drop tail setting.

At egress there are four drop tails in addition to the MBS, one for each profile state:

Each profile type can only fill the queue up to its corresponding drop tail. Figure 1 shows the ingress and egress queue drop tails.

Figure 1:  Ingress and Egress Queue Drop Tails 

At both ingress and egress, the drop tails are configured as a percentage reduction from the MBS (specifying 10% places the drop tail at 90% of the MBS) and consequently all are limited by the queue's MBS.

The default percentage for the low drop tail for ingress SAP, queue group, and shared queues is a reduction from the MBS of:

The default percentages for the drop tails for egress SAP, queue group, and network queues is a percentage reduction from the MBS of:

The exceed, high, and highplus drop tails are not configurable for network queues, however the exceed drop tail is set to a value of 10% in addition to low drop tail and capped by the MBS.

The four drop tails can be configured in any order within egress SAP and queue group queues, however it is logical to order them (from shortest to longest) as exceed, then low, then high, then highplus.

The low drop tail configuration can be overridden for ingress and egress SAP and queue group queues, and for network egress queues. It is also possible to override the low drop tail for subscriber queues within an SLA profile using the keyword high-prio-only.

When there is congestion the drop tail ordering gives preferential access to the queue's buffers. For example, if the drop tails on an egress SAP queue are configured as exceed = 20%, low = 10%, high = 5% and highplus = 0%, when the queue depth is below 80% all profile packet types are accepted into the queue. If the depth increases above 80%, then exceed profile packets will not be accepted and are therefore dropped, while the out-of-profile, in-profile, and inplus profile packets are still accepted into the queue (giving them preference over the exceed profile packets). If the queue depth goes beyond 90% the out-of-profile packets will also be dropped. Similarly, if the queue depth goes beyond 95% the in-profile packets will be dropped. It is only when the MBS has been reached that the inplus profile packets are dropped. This example assumes that the pool in which the queue exists is not congested.

2.3.12. WRED Per Queue

Egress SAP, subscriber, and network queues by default use drop tails within the queues and WRED slopes applied to the pools in which the queues reside in order to apply congestion control to the traffic in those queues. An alternative to this is to apply the WRED slopes directly to the egress queue using WRED per queue. See Table 4.

WRED per queue is supported for SAP egress QoS policy queues (and therefore to egress SAP and subscriber queues) and for queues within an egress queue group template. There are two modes available:

2.3.12.1. Native Queue Mode

When an egress queue is configured for native mode, it will use the native WRED capabilities of the forwarding plane queue. This is supported on FP3- and higher-based hardware.

Congestion control within the queue will use the low and exceed slopes from the applied slope policy together with the MBS drop tail. The queue continues to take buffers from its associated egress access or network buffer pool, on which WRED can also be enabled. This is shown in Figure 2.

Figure 2:  WRED Queue: Native Mode 

To configure a native WRED queue, the wred-queue command is used under queue in a SAP egress QoS policy or egress queue group template with the mode set to native as follows:

Example:

qos

 queue-group-templates

  egress

   queue-group <queue-group-name> create

    queue <queue-id> create

     wred-queue [policy <slope-policy-name>] mode native

      slope-usage exceed-low

    exit

   exit

  exit

 exit

 sap-egress <policy-id> create

  queue <queue-id> [<queue-type>] [create]

   wred-queue [policy <slope-policy-name>] mode native

    slope-usage exceed-low

  exit

 exit

Congestion control is provided by both the slope policy applied to the queue and the MBS drop tail.

The slope-usage defines the mapping of the traffic profile to the WRED slope and only exceed-low is allowed with a native mode queue. The slope mapping is shown in the following example and requires the low and exceed slopes to be no shutdown in the applied slope policy (otherwise traffic will use the MBS drop tail or a pool slope):

1. Out-of-profile maps to the low slope.
2. Exceed-profile maps to the exceed slope.

The instantaneous queue depth is used against the slopes when native mode is configured; consequently, the time-average-factor within the slope policy is ignored.

The inplus and in-profile traffic uses the MBS drop tail for congestion control (the highplus or high slopes are not used with a native mode queue).

If a queue is configured to use native mode WRED per queue on hardware earlier than FP3, the queue operates as a regular queue.

For example, the following SAP egress QoS policy is applied to SAP on an FP3- or higher-based hardware:

Example:

sap-egress 10 create

    queue 1 create

        wred-queue policy "slope1" mode native

                   slope-usage exceed-low

    exit

exit

The details of both the pool and queue can then be shown using the following command:

*A:PE# show pools 1/1/1 access-egress service 1

===============================================================================

Pool Information

===============================================================================

Port                 : 1/1/1

Application          : Acc-Egr          Pool Name             : default

CLI Config. Resv CBS : 30%(default)

Resv CBS Step        : 0%               Resv CBS Max          : 0%

Amber Alarm Threshold: 0%               Red Alarm Threshold   : 0%

-------------------------------------------------------------------------------

Queue-Groups

-------------------------------------------------------------------------------

Queue-Group:Instance : policer-output-queues:1

-------------------------------------------------------------------------------

Utilization                   State       Start-Avg    Max-Avg    Max-Prob

-------------------------------------------------------------------------------

HiPlus-Slope                  Down              85%       100%         80%

High-Slope                    Down              70%        90%         80%

Low-Slope                     Down              50%        75%         80%

Exceed-Slope                  Down              30%        55%         80%

Time Avg Factor      : 7

Pool Total           : 192000 KB

Pool Shared          : 134400 KB        Pool Resv             : 57600 KB

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

Current Resv CBS    Provisioned    Rising         Falling        Alarm

%age                all Queues     Alarm Thd      Alarm Thd      Color

-------------------------------------------------------------------------------

30%                 0 KB           NA             NA             Green

Pool Total In Use    : 0 KB

Pool Shared In Use   : 0 KB             Pool Resv In Use      : 0 KB

WA Shared In Use     : 0 KB

HiPlus-Slope Drop Pr*: 0                Hi-Slope Drop Prob    : 0

Lo-Slope Drop Prob   : 0                Excd-Slope Drop Prob  : 0

===============================================================================

Queue Information

===============================================================================

===============================================================================

Queue : 1->1/1/1->1

===============================================================================

FC Map               : be l2 af l1 h2 ef h1 nc

Dest Tap             : not-applicable   Dest FP          : not-applicable

Admin PIR            : 10000000         Oper PIR         : Max

Admin CIR            : 0                Oper CIR         : 0

Admin MBS            : 12000 KB         Oper MBS         : 12000 KB

High-Plus Drop Tail  : not-applicable   High Drop Tail   : not-applicable

Low Drop Tail        : not-applicable   Exceed Drop Tail : not-applicable

CBS                  : 0 KB             Depth            : 0

Slope                : slope1

WRED Mode            : native           Slope Usage      : exceed-low

-------------------------------------------------------------------------------

HighPlus Slope Information

-------------------------------------------------------------------------------

State            : disabled

Start Average    : 0 KB                 Max Average      : 0 KB

Max Probability  : 0 %                  Curr Probability : 0 %

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

High Slope Information

-------------------------------------------------------------------------------

State            : disabled

Start Average    : 0 KB                 Max Average      : 0 KB

Max Probability  : 0 %                  Curr Probability : 0 %

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

Low Slope Information

-------------------------------------------------------------------------------

State            : enabled

Start Average    : 6960 KB              Max Average      : 8880 KB

Max Probability  : 80 %                 Curr Probability : 0 %

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

Exceed Slope Information

-------------------------------------------------------------------------------

State            : enabled

Start Average    : 4680 KB              Max Average      : 6600 KB

Max Probability  : 80 %                 Curr Probability : 0 %

-------------------------------------------------------------------------------

===============================================================================

===============================================================================

===============================================================================

* indicates that the corresponding row element may have been truncated.

*A:PE#

2.3.12.2. Pool Per Queue Mode

When pool per queue mode is used, the queue resides in its own pool that is located in the forwarding plane egress megapool. The size of the pool is the same as the size of the queue (based on the MBS); consequently, the WRED slopes operating on the pool's buffer utilization are reacting to the congestion depth of the queue. The size of the reserved CBS portion of the buffer pool is dictated by the queue's CBS parameter. This is shown in Figure 3.

Figure 3:  WRED Queue: Pool-per-Queue Mode 

The queue pools take buffers from the WRED egress megapool that must be enabled per FP; if this megapool is not enabled, the queue operates as a regular queue. By default, only the ingress normal and egress normal megapools exist on an FP. The egress WRED megapool is configured using the following commands:

Example:

configure

 card <slot-number>

  fp <fp-number>

   egress

    wred-queue-control

     [no] buffer-allocation min <percentage> max <percentage>

     [no] resv-cbs min <percentage> max <percentage>

     [no] shutdown

     [no] slope-policy <slope-policy-name>

The buffer allocation determines how much of the egress normal megapool is allocated for the egress WRED megapool, with the resv-cbs defining the amount of reserved buffer space in the egress WRED megapool. In both cases, the min and max values must be equal. The slope-policy defines the WRED slope parameters and the time average factor used on the megapool to handle congestion as the megapool buffers are used. The no shutdown command enables the megapool. The megapools on card 1 fp 1 can be shown as follows:

*A:PE# show megapools 5 fp 1

===============================================================================

MegaPool Summary

===============================================================================

Type    Slot-FP   App.    Pool Name                   Actual ResvCBS  PoolSize

                                                      Admin ResvCBS

-------------------------------------------------------------------------------

fp      5-1       Egress  normal                      n/a             282624

                                                      n/a

fp      5-1       Ingress normal                      n/a             374784

                                                      n/a

fp      5-1       Egress  wred                        24576           93696

                                                      25%

===============================================================================

*A:PE#

To configure a pool per queue, the wred-queue command is used under queue in a SAP egress QoS policy or egress queue group template with the mode set to pool-per-queue as follows:

Example:

qos

 queue-group-templates

  egress

   queue-group <queue-group-name> create

    queue <queue-id> create

     wred-queue [policy <slope-policy-name>] mode pool-per-queue

       slope-usage default

    exit

   exit

  exit

 exit

 sap-egress <policy-id> create

  queue <queue-id> [<queue-type>] [create]

   wred-queue [policy <policy-name>] mode pool-per-queue

    slope-usage default

  exit

 exit

Congestion control is provided by the slope policy applied to the queue, with the slopes to be used having been no shutdown (otherwise traffic will use the MBS drop tail or a megapool slope). The slope-usage defines the mapping of the traffic profile to the WRED slope and only default is allowed with pool-per-queue that gives the following mapping:

1. Inplus-profile maps to the highplus slope.
2. In-profile maps to the high slope.
3. Out-of-profile maps to the low slope.
4. Exceed-profile maps to the exceed slope.

For example, the following SAP egress QoS policy is applied to SAP on an FP with the egress WRED megapool enabled:

Example:

sap-egress 10 create

    queue 1 create

       wred-queue policy "slope1" mode pool-per-queue

           slope-usage default

    exit

exit

The details of both the megapool and queue pool usages can then be shown using the show megapools command (detailed version):

*A:PE# show megapools 5 fp 1 wred service-id 1

===============================================================================

MegaPool Information

===============================================================================

Slot                 : 5                FP                    : 1

Application          : Egress           Pool Name             : wred

Resv CBS             : 25%

-------------------------------------------------------------------------------

Utilization                   State       Start-Avg    Max-Avg    Max-Prob

-------------------------------------------------------------------------------

HiPlus-Slope                  Down              85%       100%         80%

High-Slope                    Down              70%        90%         80%

Low-Slope                     Down              50%        75%         80%

Exceed-Slope                  Down              30%        55%         80%

Time Avg Factor      : 7

Pool Total           : 93696 KB

Pool Shared          : 69120 KB         Pool Resv             : 24576 KB

Pool Total In Use    : 0 KB

Pool Shared In Use   : 0 KB             Pool Resv In Use      : 0 KB

WA Shared In Use     : 0 KB

HiPlus-Slope Drop Pr*: 0                Hi-Slope Drop Prob    : 0

Lo-Slope Drop Prob   : 0                Excd-Slope Drop Prob  : 0

===============================================================================

Queue : 1->5/1/1:1->1

===============================================================================

FC Map               : be l2 af l1 h2 ef h1 nc

Dest Tap             : not-applicable   Dest FP          : not-applicable

Admin PIR            : 10000000         Oper PIR         : Max

Admin CIR            : 0                Oper CIR         : 0

Admin MBS            : 12288 KB         Oper MBS         : 12288 KB

High-Plus Drop Tail  : not-applicable   High Drop Tail   : not-applicable

Low Drop Tail        : not-applicable   Exceed Drop Tail : not-applicable

CBS                  : 0 KB             Depth            : 0

Slope                : slope1

WRED Mode            : pool-per-queue   Slope Usage      : default

Time Avg Factor      : 7

-------------------------------------------------------------------------------

HighPlus Slope Information

-------------------------------------------------------------------------------

State            : enabled

Start Average    : 10752 KB             Max Average      : 12288 KB

Max Probability  : 80 %                 Curr Probability : 0 %

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

High Slope Information

-------------------------------------------------------------------------------

State            : enabled

Start Average    : 9408 KB              Max Average      : 10944 KB

Max Probability  : 80 %                 Curr Probability : 0 %

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

Low Slope Information

-------------------------------------------------------------------------------

State            : enabled

Start Average    : 6144 KB              Max Average      : 9216 KB

Max Probability  : 80 %                 Curr Probability : 0 %

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

Exceed Slope Information

-------------------------------------------------------------------------------

State            : enabled

Start Average    : 3648 KB              Max Average      : 6720 KB

Max Probability  : 80 %                 Curr Probability : 0 %

-------------------------------------------------------------------------------

===============================================================================

===============================================================================

* indicates that the corresponding row element may have been truncated.

*A:PE#

Each WRED pool-per-queue uses a WRED pool resource on the FP. The resource usage is displayed in the tools dump resource-usage card [slot-num] fp [fp-number] command output under the Dynamic Q2 WRED Pools header.

2.3.13. Packet Markings

Typically, customer markings placed on packets are not treated as trusted from an in-profile or out-of-profile perspective. This allows the use of the ingress buffering to absorb bursts over PIR from a customer and only perform marking as packets are scheduled out of the queue (as opposed to using a hard-policing function that operates on the received rate from the customer). The resulting profile (in or out) based on ingress scheduling into the switch fabric is used by network egress for tunnel marking and egress congestion management.

The high/low priority feature allows a provider to offer a customer the ability to have some packets treated with a higher priority when buffered to the ingress queue. If the queue is configured with a non-zero low drop tail setting, a portion of the ingress queue’s allowed buffers are reserved for high-priority traffic. An access ingress packet must hit an ingress QoS action in order for the ingress forwarding plane to treat the packet as high priority (the default is low priority).

If the ingress queue for the packet is above the low drop tail setting, the packet will be discarded unless it has been classified as high priority. The priority of the packet is not retained after the packet is placed into the ingress queue. After the packet is scheduled out of the ingress queue, the packet will be considered in-profile or out-of-profile based on the dynamic rate of the queue relative to the queue’s CIR parameter.

At access ingress, the priority of a packet has no effect on which packets are scheduled first. Only the first buffering decision is affected.

At ingress and egress, the current dynamic rate of the queue relative to the queue’s CIR and FIR (where supported) does affect the scheduling priority between queues going to the same destination (either the switch fabric tap or egress port). See Queue Scheduling for information about the strict operating priority for queues.

For access ingress, the CIR controls both dynamic scheduling priority and marking threshold (unless cir-non-profiling is configured). At network ingress, the queue’s CIR affects the scheduling priority but does not provide a profile marking function as the network ingress policy trusts the received marking of the packet, based on the network QoS policy.

At egress, the profile of a packet is only important for egress queue buffering decisions and egress marking decisions, not for scheduling priority. The egress queue’s CIR determines the dynamic scheduling priority but does not affect the packet’s ingress determined profile.

2.3.14. Queue Counters

The router maintains counters for queues within the system for granular billing and accounting. Each queue maintains the following counters:

2.3.15. Color Aware Profiling

The normal handling of SAP ingress access packets applies an in-profile or out-of-profile state (associated with the colors green and yellow, respectively) to each packet relative to the dynamic rate of the queue while the packet is forwarded toward the egress side of the system. When the queue rate is within or equal to the configured CIR, the packet is considered in-profile. When the queue rate is above the CIR, the packet is considered out-of-profile (this applies when the packet is scheduled out of the queue, not when the packet is buffered into the queue).

Egress queues use the profile marking of packets to preferentially buffer in-profile packets during congestion events. When a packet has been marked in-profile or out-of-profile by the ingress access SLA enforcement, the packet is tagged with an in-profile or out-of-profile marking allowing congestion management in subsequent hops toward the packet’s ultimate destination. Each hop to the destination must have an ingress table that determines the in-profile or out-of-profile nature of a packet, based on its QoS markings.

Color aware profiling adds the ability to selectively treat packets received on a SAP as in-profile or out-of-profile regardless of the queue forwarding rate. This allows a customer or access device to color a packet out-of-profile with the intention of preserving in-profile bandwidth for higher priority packets. The customer or access device may also color the packet in-profile, but this is rarely done as the original packets are usually already marked with the in-profile marking.

Each ingress access forwarding class may have one or multiple subclass associations for SAP ingress classification purposes. Each subclass retains the chassis-wide behavior defined to the parent class while providing expanded ingress QoS classification actions. Subclasses are created to provide a match association that enforces actions different than the parent forwarding class. These actions include explicit ingress remarking decisions and color aware functions.

All non-profiled and profiled packets are forwarded through the same ingress access queue to prevent out-of-sequence forwarding. Profiled packets in-profile are counted against the total packets flowing through the queue that are marked in-profile. This reduces the amount of CIR available to non-profiled packets causing fewer to be marked in-profile. Profiled packets out-of-profile are not counted against the total packets flowing through the queue that are marked in-profile. This ensures that the amount of non-profiled packets marked in-profile is not affected by the profiled out-of-profile packet rate.

2.4.1. Service versus Network QoS

The QoS mechanisms within the routers are specialized for the type of traffic on the interface. For customer interfaces, there is service ingress and egress traffic, and for network core interfaces, there is network ingress and network egress traffic, as shown in Figure 4.

Figure 4:  Service vs Network Traffic Types 

The router uses QoS policies applied to a SAP for a service or to a network FP/port to define the queuing, queue attributes, and QoS marking/interpretation.

The router supports four types of service and network QoS policies:

2.4.2. QoS Policy Entities

Services are configured with default QoS policies. Additional policies must be explicitly created and associated. There is one default service ingress QoS policy, one default service egress QoS policy, and one default network QoS policy. Only one ingress QoS policy and one egress QoS policy can be applied to a SAP or network entity.

When a new QoS policy is created, default values are provided for most parameters with the exception of the policy ID and queue ID values, descriptions, and the default action queue assignment. Each policy has a scope, default action, description, and at least one queue. The queue is associated with a forwarding class.

Service QoS policies can be applied to the following service types:

Network QoS policies can be applied to the following entities:

Network queue policies can be applied to:

Default QoS policies map all traffic with equal priority and allow an equal chance of transmission (Best Effort (be) forwarding class) and an equal chance of being dropped during periods of congestion. QoS prioritizes traffic according to the forwarding class and uses congestion management to control access ingress, access egress, and network traffic with queuing according to priority.

2.4.3. Network QoS Policies

Network QoS policies define egress QoS marking and ingress QoS interpretation for traffic on core network IP interfaces. The router automatically creates egress queues for each of the forwarding classes on network IP interfaces.

A network QoS policy defines both the ingress and egress handling of QoS on the IP interface. The following functions are defined:

The required elements to be defined in a network QoS policy are:

Optional network QoS policy elements include:

Network policy ID 1 is reserved as the default network QoS policy. The default policy cannot be deleted or changed.

The default network QoS policy is applied to all network interfaces that do not have another network QoS policy explicitly assigned. Table 6 describes the default network QoS policy egress marking.

For network ingress, Table 7 and Table 8 list the default mapping of DSCP name and LSP EXP values to forwarding class and profile state for the default network QoS policy.

2.4.4. Network Queue QoS Policies

Network queue policies define the network forwarding class queue characteristics. Network queue policies are applied on egress on core network ports or channels and on ingress FPs. Network queue policies can be configured to use as many queues as needed. This means that the number of queues can vary. Not all policies will use the same number of queues as the default network queue policy. The multicast queues are only used at ingress.

The queue characteristics that can be configured on a per-forwarding class basis are:

Network queue policies are identified with a unique policy name that conforms to the standard router alphanumeric naming conventions.

The system default network queue policy is named default and cannot be edited or deleted. For information about the default network queue policy, see Network Queue QoS Policies.

2.4.5. Service Ingress QoS Policies

Service ingress QoS policies define ingress service forwarding class queues and map flows to those queues. When a service ingress QoS policy is created by default, it always has two queues defined that cannot be deleted: one for the default unicast traffic and one for the default multipoint traffic. These queues exist within the definition of the policy. The queues only get instantiated in hardware when the policy is applied to a SAP. In the case where the service does not have multipoint traffic, the multipoint queues will not be instantiated.

In the simplest service ingress QoS policy, all traffic is treated as a single flow and mapped to a single queue, and all flooded traffic is treated with a single multipoint queue. The required elements to define a service ingress QoS policy are:

Optional service ingress QoS policy elements include:

To facilitate more forwarding classes, subclasses are supported. Each forwarding class can have one or multiple subclass associations for SAP ingress classification purposes. Each subclass retains the chassis-wide behavior defined to the parent class while providing expanded ingress QoS classification actions.

There can be up to 64 classes and subclasses combined in a sap-ingress policy. With the extra 56 values, the size of the forwarding class space is more than sufficient to handle the various combinations of actions.

Forwarding class expansion is accomplished through the explicit definition of sub-forwarding classes within the SAP ingress QoS policy. The CLI mechanism that creates forwarding class associations within the SAP ingress policy is also used to create subclasses. A portion of the subclass definition directly ties the subclass to a parent, chassis-wide forwarding class. The subclass is only used as a SAP ingress QoS classification tool; the subclass association is lost when ingress QoS processing is finished.

When configured with this option, the forwarding class and drop priority of incoming traffic will be determined by the mapping result of the EXP bits in the top label. Table 8 lists the classification hierarchy based on rule type.

2.4.5.1. FC Mapping Based on EXP Bits at VLL/VPLS SAP

To accommodate backbone ISPs who want to provide VPLS/VLL to small ISPs as a site-to-site inter-connection service, small ISP routers can connect to Ethernet Layer 2 SAPs. The traffic will be encapsulated in a VLL/VPLS SDP. These small ISP routers are typically PE routers. To provide appropriate QoS, the routers support a new classification option that based on received MPLS EXP bits. Figure 5 shows a sample configuration.

Figure 5:  Example Configuration — Carrier Application 

The lsp-exp command is supported in sap-ingress qos policy. This option can only be applied on Ethernet Layer 2 SAPs.

Table 9 lists forwarding class behavior by rule type.

Table 9:  Forwarding Class Classification Based on Rule Type  

#	Rule	Forwarding Class	Comments
1	default-fc	Set the policy’s default forwarding class.	All packets match the default rule.
2	IP criteria: Multiple entries per policy Multiple criteria per entry	Set when an fc-name exists in the entry’s action. Otherwise, preserve from the previous match.	When IP criteria is specified, entries are matched based on ascending order until first match, then processing stops. A packet can only match a single IP criteria entry.
3	MAC criteria: Multiple entries per policy Multiple criteria per entry	Set when an fc-name exists in the entry’s action. Otherwise, preserve from the previous match.	When MAC criteria is specified, entries are matched based on ascending order until first match, then processing stops. A packet can only match a single MAC criteria entry.

The enqueuing priority is specified as part of the classification rule and is set to “high” or “low”. The enqueuing priority relates to the forwarding class queue’s low drop tail where only packets with a high enqueuing priority are accepted into the queue when the queue’s depth reaches the defined threshold. See Queue Drop Tails.

The mapping of IEEE 802.1p bits, IP Precedence, and DSCP values to forwarding classes is optional as is specifying IP and MAC criteria.

The IP and MAC match criteria can be very basic or quite detailed. IP and MAC match criteria are constructed from policy entries. An entry is identified by a unique, numerical entry ID. A single entry cannot contain more than one match value for each match criteria. Each match entry has a queuing action that specifies:

1. The forwarding class of packets that match the entry
2. The enqueuing priority (high or low) for matching packets

The entries are evaluated in numerical order based on the entry ID from the lowest to highest ID value. The first entry that matches all match criteria has its action performed.

The supported service ingress QoS policy IP match criteria are:

1. Destination IP address/prefix
2. Destination port/range
3. IP fragment
4. Protocol type (TCP, UDP, and so on)
5. Source port/range
6. Source IP address/prefix
7. DSCP value

The supported service ingress QoS policy MAC match criteria are:

1. IEEE 802.2 LLC SSAP value/mask
2. IEEE 802.2 LLC DSAP value/mask
3. IEEE 802.3 LLC SNAP OUI zero or non-zero value
4. IEEE 802.3 LLC SNAP PID value
5. IEEE 802.1p value/mask
6. Source MAC address/mask
7. Destination MAC address/mask
8. EtherType value

Table 10 describes the frame format on which the MAC match criteria that can be used for an Ethernet frame depends on.

Table 10:  MAC Match Ethernet Frame Types  

Frame Format	Description
802dot3	IEEE 802.3 Ethernet frame. Only the source MAC, destination MAC, and IEEE 802.1p value are compared for match criteria.
802dot2-llc	IEEE 802.3 Ethernet frame with an 802.2 LLC header.
802dot2-snap	IEEE 802.2 Ethernet frame with 802.2 SNAP header.
ethernet-II	Ethernet type II frame where the 802.3 length field is used as an Ethernet type (Etype) value. Etype values are 2-byte values greater than 0x5FF (1535 decimal).

The 802dot3 frame format matches across all Ethernet frame formats where only the source MAC, destination MAC, and IEEE 802.1p value are compared. The other Ethernet frame types match those field values in addition to fields specific to the frame format. Table 11 lists the criteria that can be matched for the various MAC frame types.

Table 11:  MAC Match Criteria Frame Type Dependencies  

Frame Format	Source MAC	Dest MAC	IEEE 802.1p Value	Etype Value	LLC Header SSAP/DSAP Value/Mask	SNAP-OUI Zero/Non-zero Value	SNAP- PID Value
802dot3	Yes	Yes	Yes	No	No	No	No
802dot2-llc	Yes	Yes	Yes	No	Yes	No	No
802dot2-snap	Yes	Yes	Yes	No	No 1	Yes	Yes
ethernet-II	Yes	Yes	Yes	Yes	No	No	No

Note:

1. When a SNAP header is present, the LLC header is always set to AA-AA.

Service ingress QoS policy ID 1 is reserved for the default service ingress policy. The default policy cannot be deleted or changed.

The default service ingress policy is implicitly applied to all SAPs that do not explicitly have another service ingress policy assigned. Table 12 lists the characteristics of the default policy.

Table 12:  Default Service Ingress Policy ID 1 Definition  

Characteristic	Item	Definition
Queues	Queue 1	One queue for all unicast traffic: Forward Class: best-effort (be) CIR = 0 PIR = max (line rate) FIR = 0 MBS, CBS, and HP-only = default (values derived from applicable policy)
	Queue 11	One queue for all multipoint traffic: CIR = 0 PIR = max (line rate) FIR = 0 MBS, CBS, and HP-only = default (values derived from applicable policy)
Flows	Default Forwarding Class	One flow defined for all traffic: All traffic mapped to best-effort (be) with a low priority

2.4.5.2. Egress Forwarding Class Override

Egress forwarding class override provides additional QoS flexibility by allowing the use of a different forwarding class at egress than was used at ingress.

The ingress QoS processing classifies traffic into a forwarding class (or subclass) and by default the same forwarding class is used for this traffic at the access or network egress. The ingress forwarding class or subclass can be overridden so that the traffic uses a different forwarding class at the egress. This can be configured for the main forwarding classes and for subclasses, allowing each to use a different forwarding class at the egress.

The buffering, queuing, policing, and remarking operation at the ingress and egress remain unchanged. Egress reclassification is possible. The profile processing is completely unaffected by overriding the forwarding class.

When used in conjunction with QoS Policy Propagation Using BGP (QPPB), a QPPB assigned forwarding class takes precedence over both the normal ingress forwarding class classification rules and any egress forwarding class overrides.

Figure 6:  Egress Forwarding Class Override 

Figure 6 shows the ingress service 1 using forwarding classes AF and L1 that are overridden to L1 for the network egress, while it also shows ingress service 2 using forwarding classes L1, AF, and L2 that are overridden to AF for the network egress.

2.4.6. Service Egress QoS Policies

Service egress queues are implemented at the transition from the service core network to the service access network. The advantages of per-service queuing before transmission into the access network are:

The subrate capabilities and per-service scheduling control are required to make multiple services per physical port possible. Without egress shaping, it is impossible to support more than one service per port. There is no way to prevent service traffic from bursting to the available port bandwidth and starving other services.

For accounting purposes, per-service statistics can be logged. When statistics from service ingress queues are compared with service egress queues, the ability to conform to per-service QoS requirements within the service core can be measured. The service core statistics are a major asset to core provisioning tools.

Service egress QoS policies define egress queues and map forwarding class flows to queues. In the simplest service egress QoS policy, all forwarding classes are treated like a single flow and mapped to a single queue. To define a basic egress QoS policy, the following are required:

Optional service egress QoS policy elements include:

Each queue in a policy is associated with one of the forwarding classes. Each queue can have its individual queue parameters allowing individual rate shaping of the forwarding classes mapped to the queue.

More complex service queuing models are supported in the router where each forwarding class is associated with a dedicated queue.

The forwarding class determination per service egress packet is determined either at ingress or egress. If the packet ingressed the service on the same router, the service ingress classification rules determine the forwarding class of the packet. If the packet is received on a network interface, the forwarding class is marked in the tunnel transport encapsulation. In each case, the packet can be reclassified into a different forwarding class at service egress.

Service egress QoS policy ID 1 is reserved as the default service egress policy. The default policy cannot be deleted or changed. The default access egress policy is applied to all SAPs that do not have another service egress policy explicitly assigned. Table 13 lists the characteristics of the default policy.

2.4.7. Slope Policies

Slope policies are used to define the RED slope characteristics as a percentage of the shared pool size for the pool on which the policy is applied.

For network ingress, a buffer pool is created for the FP and is used for all network ingress queues for ports on that FP.

For access ingress, access egress and network egress a pool is created per port. Default buffer pools exist at the port and FP levels.

By default, each pool is associated with slope-policy default.

Slope policies can also be applied when using WRED per queue; see WRED Per Queue.

2.4.7.2. Tuning the SBAU Calculation

The router allows for tuning the calculation of the SBAU (as used by the RED slopes to calculate a packet’s drop probability) after assigning buffers for a packet entering a queue. The router implements a time average factor (TAF) parameter in the buffer policy that determines the contribution of the historical SBU and the instantaneous SBU in calculating the SBAU.

The TAF defines a weighting exponent used to determine the portion of the shared buffer instantaneous utilization and the previous SBAU used to calculate the new SBAU. To derive the new SBAU, the buffer pool takes a portion of the previous SBAU and adds it to the inverse portion of the instantaneous SBU. The formula used to calculate the SBAU is:

 

where:

SBAUn = SBAU for event n

SBAUn - 1 = SBAU for event (n - 1)

SBU = Instantaneous SBU

TAF = Time average factor

Table 14 describes the effect that the allowed values of TAF have on the relative weighting of the instantaneous SBU and the previous SBAU (SBAUn-1), when calculating the current SBAU (SBAUn).

Table 14:  TAF Impact on Shared Buffer Average Utilization Calculation  

TAF	2TAF	Equates To	Instantaneous SBU Portion	SBAU Portion
0	20	1	1/1 (1)	0 (0)
1	21	2	1/2 (0.5)	1/2 (0.5)
2	22	4	1/4 (0.25)	3/4 (0.75)
3	23	8	1/8 (0.125)	7/8 (0.875)
4	24	16	1/16 (0.0625)	15/16 (0.9375)
5	25	32	1/32 (0.03125)	31/32 (0.96875)
6	26	64	1/64 (0.015625)	63/64 (0.984375)
7	27	128	1/128 (0.0078125)	127/128 (0.9921875)
8	28	256	1/256 (0.00390625)	255/256 (0.99609375)
9	29	512	1/512 (0.001953125)	511/512 (0.998046875)
10	210	1024	1/1024 (0.0009765625)	1023/2024 (0.9990234375)
11	211	2048	1/2048 (0.00048828125)	2047/2048 (0.99951171875)
12	212	4096	1/4096 (0.000244140625)	4095/4096 (0.999755859375)
13	213	8192	1/8192 (0.0001220703125)	8191/8192 (0.9998779296875)
14	214	16384	1/16384 (0.00006103515625)	16383/16384 (0.99993896484375)
15	215	32768	1/32768 (0.000030517578125)	32767/32768 (0.999969482421875)

The value specified for the TAF affects the speed at which the shared buffer average utilization tracks the instantaneous shared buffer utilization. A low value weights the new shared buffer average utilization calculation more to the shared buffer instantaneous utilization. When TAF is zero, the shared buffer average utilization is equal to the instantaneous shared buffer utilization. A high value weights the new shared buffer average utilization calculation more to the previous shared buffer average utilization value. The TAF value applies to all high- and low-priority RED slopes for ingress and egress buffer pools controlled by the buffer policy.

2.4.8. Scheduler Policies

A scheduler policy defines the hierarchy and all operating parameters for the member schedulers. A scheduler policy must be defined in the QoS context before a group of virtual schedulers can be used. Although configured in a scheduler policy, the individual schedulers are created when the policy is applied to an object, such as a SAP or interface.

Scheduler objects define bandwidth controls that limit each child (other schedulers and policers or queues) associated with the scheduler. The scheduler object can also define a child association with a parent scheduler of its own.

A scheduler is used to define a bandwidth aggregation point within the hierarchy of virtual schedulers. The scheduler’s rate defines the maximum bandwidth that the scheduler can consume. It is assumed that each scheduler created will have policers, queues, or other schedulers defined as child associations. The scheduler can also be a child which takes bandwidth from a scheduler in a higher tier.

A parent parameter can be defined to specify a scheduler further up in the scheduler policy hierarchy. Only schedulers in Tiers 2 and 3 can have parental association. When multiple schedulers, policers, and queues share a child status with the scheduler on the parent, the weight or strict parameters define how this scheduler contends with the other children for the parent’s bandwidth. The parent scheduler can be removed or changed at any time and is immediately reflected on the schedulers created by association of this scheduler policy.

When a parent scheduler is defined without specifying level, weight, or CIR parameters, the default bandwidth access method is weight with a value of 1.

If any orphaned policers or queues (where the specified scheduler name does not exist) exist on the ingress SAP and the policy application creates the required scheduler, the status on the queue becomes non-orphaned at this time.

Figure 8 shows how child queues, policers, and schedulers interact with their parent scheduler to receive bandwidth. The scheduler distributes bandwidth to the children by first using each child’s CIR according to the CIR-level parameter (CIR L8 through CIR L1 weighted loops). The weighting at each CIR-level loop is defined by the CIR weight parameter for each child. The scheduler then distributes any remaining bandwidth to the children up to each child’s rate parameter according to the Level parameter (L8 through L1 weighted loops). The weighting at each level loop is defined by the weight parameter for each child.

Figure 8:  Virtual Scheduler Internal Bandwidth Allocation 

2.4.8.2. Hierarchical Scheduler Policies

Hierarchical scheduler policies are an alternate way of scheduling that can be used on service ingress queues and service egress queues and policers. Hierarchical scheduler policies allow the creation of a hierarchy of schedulers where policers, queues, and/or other schedulers are scheduled by superior schedulers.

The use of the hierarchical scheduler policies is often referred to as hierarchical QoS or HQoS on the SR OS.

2.4.8.2.1. Hierarchical Virtual Schedulers

Virtual schedulers are created within the context of a hierarchical scheduler policy. A hierarchical scheduler policy defines the hierarchy and parameters for each scheduler. A scheduler is defined in the context of a tier (Tier 1, Tier 2, Tier 3). The tier level determines the scheduler’s position within the hierarchy. Three tiers of virtual schedulers are supported (see Figure 9).

Tier 1 schedulers (also called root schedulers) can also have a parent scheduler. A scheduler can enforce a maximum rate of operation for all child policers, queues, and associated schedulers.

Figure 9:  Hierarchical Scheduler and Queue Association 

2.4.8.4. Scheduler Policies Applied to Applications

A scheduler policy can be applied either on a SAP (see Figure 10) or on a multiservice customer site (a group of SAPs with common origination/termination point) (see Figure 11). Whenever a scheduler policy is applied, the individual schedulers comprising the policy are created on the object. When the object is an individual SAP, only policers and queues created on that SAP can use the schedulers created by the policy association. When the object is a multiservice customer site, the schedulers are available to any SAPs associated with the site (also see Scheduler Policies Applied to SAPs).

Figure 10:  Scheduler Policy on SAP and Scheduler Hierarchy Creation 

Figure 11:  Scheduler Policy on Customer Site and Scheduler Hierarchy Creation 

Queues and policers become associated with schedulers when the parent scheduler name is defined within the policer or queue definition in the SAP QoS policy. The scheduler is used to provide bandwidth to the queue relative to the operating constraints imposed by the scheduler hierarchy.

2.4.9. ATM Traffic Descriptor Profiles

Traffic descriptor profiles capture the cell arrival pattern for resource allocation. Source traffic descriptors for an ATM connection include at least one of the following:

QoS traffic descriptor profiles are applied on IES, VPRN, VPLS, and VLL SAPs.

ATM traffic descriptor profiles are not supported on the 7950 XRS.

2.4.10. Configuration Notes

The following information describes QoS implementation restrictions: