Alcatel-Lucent 7950 Quality Of Service Manual page 213

hsmda-counter-override counter-id — The hsmda-counter-override reclassification action is optional and
only has significance on SAPs which are created on an HSMDA. When specified, packets matching the
IP precedence value will be mapped to the defined HSMDA exception counter-id for the packets queue
group. The default behavior is to use the default counter on the queue group for the queue to which the
packet is mapped. The hsmda-counter-override action may be overwritten by an ip-criteria
reclassification rule match. The specified counter-id must be specified as an integer between 1 and 8. To
remove the ESMDA exception counter reclassification action for the specified DSCP value, the dscp
command must be re-executed without the hsmda-counter-override reclassification action defined.
Values
queue
Syntax queue queue-id [multipoint] [queue-type] [queue-mode] pool pool-name
queue queue-id [multipoint] [queue-type] pool pool-name
no queue queue-id
Context config>qos>sap-ingress
config>qos>sap-egress
Description
This command creates the context to configure an ingress service access point (SAP) QoS policy queue.
Explicit definition of an ingress queue's hardware scheduler status is supported. A single ingress queue
allows support for multiple forwarding classes. The default behavior automatically chooses the expedited or
non-expedited nature of the queue based on the forwarding classes mapped to it. As long as all forwarding
classes mapped to the queue are expedited (nc, ef, h1 or h2), the queue is treated as an expedited queue by
the hardware schedulers. When any non-expedited forwarding classes are mapped to the queue (be, af, l1
or l2), the queue is treated as best effort (be) by the hardware schedulers. The expedited hardware
schedulers are used to enforce expedited access to internal switch fabric destinations. The hardware status of
the queue must be defined at the time of queue creation within the policy.
The queue command allows the creation of multipoint queues. Only multipoint queues can receive ingress
packets that need flooding to multiple destinations. By separating the unicast for multipoint traffic at service
ingress and handling the traffic on separate multipoint queues special handling of the multipoint traffic is
possible. Each queue acts as an accounting and (optionally) shaping device offering precise control over
potentially expensive multicast, broadcast and unknown unicast traffic. Only the back-end support of
multipoint traffic (between the forwarding class and the queue based on forwarding type) needs to be
defined. The individual classification rules used to place traffic into forwarding classes are not affected.
Queues must be defined as multipoint at the time of creation within the policy.
The multipoint queues are for multipoint-destined service traffic. Within non-multipoint services, such as
Epipe services, all traffic is considered unicast due to the nature of the service type. Multicast and broadcast-
destined traffic in an Epipe service will not be mapped to a multipoint service queue.
When an ingress SAP QoS policy with multipoint queues is applied to an Epipe SAP, the multipoint queues
are not created. When an ingress SAP QoS policy with multipoint queues is applied to an IES SAP, a
multipoint queue will be created when PIM is enabled on the IES interface.
Any billing or statistical queries about a multipoint queue on a non-multipoint service returns zero values.
Any queue parameter information requested about a multipoint queue on a non-multipoint service returns
the queue parameters in the policy. Buffers will not be allocated for multipoint queues on non-multipoint
7950 XRS Quality of Service Guide
1 —8
Page 213