Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Configuring Excess Bandwidth Sharing on IQE PICs

 

The IQE PIC gives users more control over excess bandwidth sharing. You can set a shaping rate and a guaranteed rate on a queue or logical interface and control the excess bandwidth (if any) that can be used after all bandwidth guarantees have been satisfied. This section discusses the following topics related to excess bandwidth sharing on the IQE PIC:

On some types of PICs, including the IQ and IQ2, and Enhanced Queuing DPCs, you can configure either a committed information rate (CIR) using the guaranteed-rate statement or a peak information rate (PIR) using the shaping-rate statement. You can configure both a PIR and CIR, and in most cases the CIR is less than the value of PIR. For bursty traffic, the CIR represents the average rate of traffic per unit time and the PIR represents the maximum amount of traffic that can be transmitted in a given interval. In other words, the PIR (shaping-rate) establishes the maximum bandwidth available. The CIR (guaranteed-rate) establishes the minimum bandwidth available if all sources are active at the same time. Theoretically, the PIR or CIR can be established at the queue, logical interface, or physical interface level. In this section, the PIRs or CIRs apply at the queue or logical interface (or both) levels.

Note

You can configure a shaping rate at the physical interface, logical interface, or queue level. You can configure a guaranteed rate or excess rate only at the logical interface and queue level.

Once all of the bandwidth guarantees (the sum of the CIRs at that level) are met, there could still be some excess bandwidth available for use. In existing PICs, you have no control over how this excess bandwidth is used. For example, consider the situation shown in Table 1 regarding a 10-Mbps physical interface. This example assumes that all queues are of the same priority. Also, if you do not specify a priority for the excess bandwidth, the excess priority is the same as the normal priority.

Table 1: Default Handling of Excess Traffic

Queue

Transmit Rate (CIR)

Shaping Rate (PIR)

Traffic Rate

Guaranteed Rate (Total = 6 Mbps)

Maximum Rate

Excess Bandwidth (Part of 4 Mbps Excess)

Expected Transmit Rate (Guarantee + Excess)

Q0

10%

80%

10 Mbps

1 Mbps

8 Mbps

0.73 Mbps

1.73 Mbps

Q1

20%

50%

10 Mbps

2 Mbps

5 Mbps

1.45 Mbps

3.45 Mbps

Q2

5%

5%

10 Mbps

0.5 Mbps

0.5 Mbps

0 Mbps

0.5 Mbps

Q3

25%

NA (“100%”)

10 Mbps

2.5 Mbps

10 Mbps

1.82 Mbps

4.32 Mbps

A 10-Mbps interface (the Traffic Rate column) has four queues, and the guaranteed rates are shown as percentages (Transmit Rate column) and in bits per second (Guaranteed Rate column). The table also shows the shaping rate (PIR) as a percentage (Shaping Rate column) and the actual maximum possible transmitted rate (Traffic Rate column) on the oversubscribed interface. Note the guaranteed rates (CIRs) add up to 60 percent of the physical port speed or 6 Mbps. This means that there are 4 Mbps of “excess” bandwidth that can be used by the queues. This excess bandwidth is used as shown in the last two columns. One column (the Excess Bandwidth column) shows the bandwidth partitioned to each queue as a part of the 4-Mbps excess. The excess 4 Mbps bandwidth is shared in the ratio of the transmit rate (CIR) percentages of 10, 20, 5, and 25, adjusted for granularity. The last column shows the transmit rate the users can expect: the sum of the guaranteed rate plus the proportion of the excess bandwidth assigned to the queue.

Note that on PICs other than the IQE PICs the user has no control over the partitioning of the excess bandwidth. Excess bandwidth partitioning is automatic, simply assuming that the distribution and priorities of the excess bandwidth should be the same as the distribution and priorities of the other traffic. However, this might not always be the case and the user might want more control over excess bandwidth usage.

For more information on how excess bandwidth sharing is handled on the Enhanced Queuing DPC, see Configuring Excess Bandwidth Sharing.

On PICs other than IQE PICs, you can limit a queue’s transmission rate by including the transmit-rate statement with the exact option at the [edit class-of-service schedulers scheduler-name] hierarchy level. However, on the IQE PIC, you can set a shaping rate independent of the transmit rate by including the shaping-rate statement at the [edit class-of-service schedulers scheduler-name] hierarchy level. Also, other PICs share excess bandwidth (bandwidth left over once the guaranteed transmit rate is met) in an automatic, nonconfigurable fashion. You cannot configure the priority of the queues for the excess traffic on other PICs either.

To share excess bandwidth on IQE PICs, include the excess-rate statement along with the guaranteed-rate statement (to define the CIR) and the shaping-rate statement (to define the PIR):

To apply these limits to a logical interface, configure the statements at the [edit class-of-service traffic-control-profile profile-name] hierarchy level. To apply these limits to a specific queue, configure the statements at the [edit class-of-service schedulers scheduler-name] hierarchy level. You must also complete the configuration by applying the scheduler map or traffic control profile correctly.

You configure the excess rate as a percentage from 1 through 100. By default, excess bandwidth is automatically distributed as on other PIC types.

You can also configure a high or low priority for excess bandwidth by including the excess-priority statement with the high or low option at the [edit class-of-service schedulers scheduler-name] hierarchy level. This statement establishes the priority at the queue level, which then applies also at the logical and physical interface levels.

Note

You cannot configure an excess rate for a logical interface if there is no guaranteed rate configured on any logical interface belonging to the physical interface.

The following example configures excess bandwidth sharing on logical interfaces of an IQE PIC by using twotraffic control profile:

  1. Create the first traffic control profile called: for-unit-0-percent and specify the associated parameters for sharing the excess bandwidth.
    1. Specify a name for the traffic control profile to create it.

    2. Configure the maximum usage rate.

    3. Specify the guaranteed-rate (to define the CIR)

    4. Specify the excess-rate

  2. Create the second traffic control profile called: for-unit-1-proportion and specify the associated parameters for sharing the excess bandwidth.
    1. Specify a name for the traffic control profile to create it.

    2. Configure the maximum usage rate.

    3. Specify the percentage or proportion of excess bandwidth traffic to share.

    4. Specify the priority for excess bandwidth.

  3. Verify the configuration.
    user@host> show class-of-service traffic-control-profile

The following example configures the excess rate in a scheduler:

  1. Create the first scheduler called: scheduler-for-excess-low and specify the associated parameters for sharing the excess bandwidth.
    1. Specify a name for the scheduler to create it.

    2. Specify the transmit rate for the scheduler.

    3. Configure the maximum usage rate.

    4. Specify the percentage or proportion of excess bandwidth traffic to share.

    5. Specify the priority of excess bandwidth traffic on the scheduler.

  2. Create the second scheduler called: scheduler-for-excess-high and specify the associated parameters for sharing the excess bandwidth.
    1. Specify a name for the traffic control profile to create it.

    2. Specify the transmit rate for the scheduler.

    3. Configure the maximum usage rate.

    4. Specify the percentage or proportion of excess bandwidth traffic to share.

    5. Specify the priority of excess bandwidth traffic on the scheduler.

  3. Verify the configuration.
    user@host> show class-of-service schedulers
Note

All of these parameters apply to egress traffic only and only for per-unit schedulers. That is, there is no hierarchical or shared scheduler support.