The following are the constraints and rules of this provisioning model when used in the ingress PW shaping feature:
Only a queue-group containing policers can be instantiated in the network ingress context of an IOM/IMM FP. If the queue-group template contains policers and queues, the queues are not instantiated.
If the queue-group contains queues only, the instantiation in the data path fails.
One or more instances of the same policer queue-group name and, or a different policer queue-group name can be created on network ingress context of an IOM/IMM FP.
The queue-group-name must be unique within all network ingress and access ingress queue groups in the system.
The instantiated FP policer queue-group can be used by PW packets received on a network IP interface configured on both Ethernet ports and POS ports of that IOM/IMM.
When a PW FC is redirected to use a policer in a named policer queue-group and the queue-group name does not exist, the association fails at the time the user associates the ingress context of a spoke-SDP with the named queue-group. In such a case, the PW packet feeds directly into the ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the FP.
When a PW FC is redirected to use a policer in a named policer queue-group and the queue-group name exists but the policer-id is not defined in the queue-group template, the association fails at the time the user associates the ingress context of a spoke-SDP with the named queue-group. In such a case, the PW packet feeds directly into the ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the FP.
When a PW FC is redirected to use a policer in a named policer queue-group and the queue-group name exists and the policer-id is defined in the queue-group template, it is not required to check that an instance of that queue-group exists in all ingress FPs that have network IP interfaces. The handling of this is dealt with in the data path, as follows:
When a PW packet for that FC is received and an instance of the referenced queue-group name exists on that FP, the packet is processed by the policer and is then fed directly into the per-FP ingress shared queues referred to as policer-output-queues.
When a PW packet for that FC is received and an instance of the referenced queue-group name does not exist on that FP, the PW packets are fed directly into the corresponding ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the FP.
If a network QoS policy is applied to the ingress context of a PW, any PW FC, that is not explicitly redirected in the network QoS policy has the corresponding packets feed directly into the ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the FP. This behavior is the same regardless of whether the ingress network IP interface from which the PW packet is received is redirected or not to a policer queue-group.
If no network QoS policy is applied to the ingress context of the PW, then all packets of the PW feed:
the ingress network shared queue for the packet FC defined in the network-queue policy applied to the ingress of the FP. This is the default behavior.
a queue-group policer followed by the per-FP ingress shared queues referred to as policer-output-queues if the ingress context of the network IP interface from which the packet is received is redirected to a queue-group. The only exceptions to this behavior are for packets received from an IES/VPRN spoke interface and from a R-VPLS spoke-SDP, which is forwarded to the R-VPLS IP interface. In these two cases, the ingress network shared queue for the packet FC defined in the network-queue policy applied to the ingress of the FP is used.
Operationally, the provisioning model in the case of the ingress PW shaping feature consists of the following steps: