The classification and scheduling function implemented on the oversubscribed MDA ensures that traffic is correctly prioritized when the bus from the MDA to the IOM is overcommitted. This could occur if the policing parameters configured are such that the sum of the traffic being admitted into the MDA is greater than the capacity between the MDA and the IOM.
The classification function uses the bits set in the DSCP or Dot1p fields of the customer packets to perform classification. It can also identify locally addressed traffic arriving on network ports as Network Control packets. This classification on the oversubscribed MDA uses the following rules:
If the service QoS policy for the SAP (port or VLAN) uses the default classification policy, all traffic is classified as Best Effort (be).
If the service QoS policy for the SAP contains a Dot1p classification, the Dot1p field in the customer packets is used for classification on the MDA.
If the service QoS policy for the SAP contains a DSCP classification, the DSCP field in the customer packets is used for classification on the MDA.
If a mix of Dot1p and DSCP classification definitions are present in the service QoS policy, then the field used to perform classification is the type used for the highest priority definition. For example, if High Priority 1 is the highest priority definition and it specifies that the DSCP field should be used, then the DSCP field is used for classification on the MDA and the Dot1p field is ignored.
If the service QoS policy for the SAP specifies IP or MAC filters for forwarding class identification, then traffic is treated as Best Effort. Full MAC or IP classification is not possible on the MDA (but is possible on the IOM).
The packet is classified into 16 classes. Typically, these are the eight forwarding classes and each packet is assigned one priority per forwarding class. After classification, the packet is offered to the queuing model. This queuing model is limited to three queues each having four thresholds. These thresholds define whether an incoming packet, after classification, is accepted in the queue or not. Table 1 shows typical mapping of classes onto queues and thresholds.
| Counter | {Queue | Threshold | Traffic class} |
|---|---|---|---|
0 |
{2 |
3 |
‟fc-nc / in-profile”} |
1 |
{2 |
2 |
‟fc-nc / out-profile”} |
2 |
{2 |
1 |
‟fc-h1 / in-profile”} |
3 |
{2 |
0 |
‟fc-h1 / out-profile”} |
4 |
{1 |
3 |
‟fc-ef / in-profile”} |
5 |
{1 |
2 |
‟fc-ef / out-profile”} |
6 |
{1 |
1 |
‟fc-h2 / in-profile”} |
7 |
{1 |
0 |
‟fc-h2 / out-profile”} |
8 |
{0 |
3 |
‟fc-l1 / in-profile”} |
9 |
{0 |
3 |
‟fc-l1 / out-profile”} |
10 |
{0 |
2 |
‟fc-af / in-profile”} |
11 |
{0 |
2 |
‟fc-af / out-profile”} |
12 |
{0 |
1 |
‟fc-l2 / in-profile”} |
13 |
{0 |
1 |
‟fc-l2 / out-profile”} |
14 |
{0 |
0 |
‟fc-be / in-profile”} |
15 |
{0 |
0 |
‟fc-be / out-profile”} |
A counter is associated with each mapping. The above is an example and is dependent on the type of classification (such as dscp-exp, dot1p, and so on). When the threshold of a particular class is reached, packets belonging to that class are not accepted in the queue. The packets are dropped and the associated counter is incremented.
The scheduling of the three queues is done in a strict priority, highest priority basis is associated with queue 2. This means that scheduling is done at queue level, not on the class that resulted from the classification. As soon as a packet has been accepted by the queue there is no way to differentiate it from other packets in the same queue (for example, another classification result not exceeding its threshold). All packets queued in the same queue, have the same priority from a scheduling point of view.