Show Commands - Alcatel-Lucent 7450 Quality Of Service Manual

Named Pools
Description This command creates the context to configure a QoS network-queue 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 a QoS policy with multipoint queues is applied to an Epipe or IES SAP, the multipoint queues
are not created. 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 network-queue 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 or 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.
Quality of Service Guide 747