Queue Group Applications - Alcatel-Lucent 7950 Quality Of Service Manual

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 will experience little impact since
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 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 in order 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 will suffice.
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 above 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.
7950 XRS Quality of Service Guide
Ingress and Egress Queue Group Creation and Redirection
Page 307