Alcatel-Lucent 7450 Quality Of Service Manual page 737

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. On the 7950 XRS, 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 services. Buffer pool queries return zero values for actual buffers allocated and
current buffer utilization.
The no form of this command removes the queue-id from the SAP ingress QoS policy and from any
existing SAPs using the policy. If any forwarding class forwarding types are mapped to the queue, they
revert to their default queues. When a queue is removed, any pending accounting information for each
SAP queue created due to the definition of the queue in the policy is discarded.
The pool keyword is a create time parameter that allows the queue to receive buffers from an explicit
buffer pool instead of the default buffer pool. The specified pool-name must have been explicitly
created in a named-pool-policy and the policy must have been applied to the XMA, MDA, or port on
which the queue resides.
If the specified pool-name does not exist on the XMA or MDA, the queue will be treated as 'pool
orphaned' and will be mapped to the appropriate default pool. Once the pool comes into existence on
the XMA, MDA, or port, the queue will be mapped to the new pool.
Once the queue is created within the policy, the pool command may be used to either remove the queue
from the pool, or specify a new pool name association for the queue. The pool command does not
appear in save or show command output. Instead, the current pool name for the queue will appear (or
not appear) on the queue command output using the pool keyword.
Parameters queue-id — The queue-id for the queue, expressed as an integer. The queue-id uniquely identifies
Quality of Service Guide
the queue within the policy. This is a required parameter each time the queue command is
executed.
Values 1 to 32
Named Pools
739