This section provides information to configure MC-MLPPP using the command line interface.
Topics in this section include:
If the user enables the multiclass option under an MLPPP bundle, the XMA or MDA egress data path provides a queue for each of the 4 classes of MLPPP. The user configures the required number of MLPPP classes to use on a bundle. The forwarding class of the packet, as determined by the ingress QoS classification, is used to determine the MLPPP class for the packet and hence which of the four egress XMA or MDA queues to store the packet. The mapping of forwarding class to MLPPP class is a function of the user configurable number of MLPPP classes. The default mapping for a 4-class, 3-class, and 2-class MLPPP bundle is shown in Table 66.
FC ID | FC Name | Scheduling Priority (Default) | MLPPP Class 4-class bundle | MLPPP Class 3-class bundle | MLPPP Class 2-class bundle |
7 | NC | Expedited | 0 | 0 | 0 |
6 | H1 | Expedited | 0 | 0 | 0 |
5 | EF | Expedited | 1 | 1 | 1 |
4 | H2 | Expedited | 1 | 1 | 1 |
3 | L1 | Non-Expedited | 2 | 2 | 1 |
2 | AF | Non-Expedited | 2 | 2 | 1 |
1 | L2 | Non-Expedited | 3 | 2 | 1 |
0 | BE | Non-Expedited | 3 | 2 | 1 |
Table 67 shows a different mapping enabled when the user applies one of three predefined egress QoS profiles in the 4-class bundle configuration only.
FC ID | FC Name | Scheduling Priority (Default) | MLPPP Class (MLPPP Egress QoS profile 1, 2, and 3) |
7 | NC | Expedited | 0 |
6 | H1 | Expedited | 0 |
5 | EF | Expedited | 1 |
4 | H2 | Expedited | 2 |
3 | L1 | Non-Expedited | 2 |
2 | AF | Non-Expedited | 2 |
1 | L2 | Non-Expedited | 2 |
0 | BE | Non-Expedited | 3 |
The MLPPP class queue parameters and its scheduling parameters are also configured by applying one of the three predefined egress QoS profiles to an MLPPP bundle.
Table 68 and Figure 51 provide the details of the class queue threshold parameters. Packets marked with a high drop precedence, such as out-of-profile, by the service or network ingress QoS policy will be discarded when any class queue reaches the OOP threshold. Packet with a low drop precedence marking, such as in-profile, will be discarded when any class queue reaches the max threshold.
Class 0 | Class 1 | Class 2 | Class 3 | |||||
Queue Threshold (in ms @ Available bundle rate) | Max | Oop | Max | Oop | Max | Oop | Max | Oop |
2-Class Bundle Default Egress QoS Profile | 250 | 125 | 750 | 375 | N/A | N/A | N/A | N/A |
3-Class Bundle Default Egress QoS Profile | 50 | 25 | 200 | 100 | 750 | 375 | N/A | N/A |
4-Class Bundle Default Egress QoS Profile | 10 | 5 | 50 | 25 | 150 | 75 | 750 | 375 |
4-Class Bundle Egress QoS Profile 1 | 25 | 12 | 5 | 3 | 200 | 100 | 1000 | 500 |
4-Class Bundle Egress QoS Profile 2 | 25 | 12 | 5 | 3 | 200 | 100 | 1000 | 500 |
4-Class Bundle Egress QoS Profile 3 | 25 | 12 | 5 | 3 | 200 | 100 | 1000 | 500 |
Table 69 and Figure 52 provide the details of the class queue scheduling parameters.
WRR Parameters | ||||
4-class MLPPP Egress QoS Profile | MIR | W1 | W2 | W3 |
Profile 1 | 85% | <1% | 66% | 33% |
Profile 2 | 90% | <1% | 89% | 10% |
Profile 3 | 85% | <1% | 87% | 12% |
All queue threshold and queue scheduling parameters are adjusted to the available bundle rate. If a member link goes down or a new member link is added to the bundle, the scheduling parameters MIR, W1, W2, W3, as well as the per class queue thresholds OOP and max are automatically adjusted to maintain the same values.
Class 0 queue is serviced at MLPPP at available bundle rate. Class 1 queue is guaranteed a minimum service rate but is allowed to share additional bandwidth with class 2 and 3 queues based on the configuration of WRR weight W1.
Class queues 2 and 3 can be given bandwidth guarantee by limiting MIR of class 1 queue to less than 100% and by setting the WRR weights W1, W2 and W3 to achieve the desired bandwidth distribution among all three class queues.
There is one queue per bundle member link to carry link control packets, such as LCP: PPP, and which are serviced with strict priority over the 4 class queues (not shown).
In the default 2-class, 3-class, and 4-class egress QoS profile, the class queues are service with strict priority in ascending order of class number.
For a MLPPP bundle with the multi-class option enabled, there is a default profile for setting the re-assembly timer value for each class. When the predefined MLPPP ingress QoS profile 1 is applied to a 4-class bundle, the values of the timers are modified as shown in Table 70.
Class 0 | Class 1 | Class 2 | Class 4 | |
MLPPP ingress QoS default profile (2-Class bundle) | 25ms | 25ms | NA | NA |
MLPPP ingress QoS default profile (3-Class bundle) | 25ms | 25ms | 25ms | NA |
MLPPP ingress QoS default profile (4-Class bundle) | 25ms | 25ms | 100ms | 1000ms |
MLPPP ingress QoS profile 1 (4-class bundle) | 10 | 10 | 100 | 1000 |
A 4-class MLPPP bundle can be configured. This feature cannot be used with MC-MLPPP bundles with fewer than 4 classes.
The following describe the parameters and the configuration processes and rules:
The user creates an ingress QoS profile, mlppp-profile-ingress, to configure the desired value of the ingress per-class re-assembly timer. Ingress QoS profile #1 is reserved to the predefined profile with parameter values in Table 70. The user is allowed to edit this profile and change parameter values. However, the default value of a parameter when a user creates a profile with a profile-id higher than 1, or performs the no option on the parameter, will always be the one in Table 70 for the ingress QoS Profile #1 regardless what parameter value the edited Profile #1 has at that point in time.
Configure an egress and ingress MLPPP profile.
The following displays the profile configuration examples:
Use the following CLI syntax to create an MC-MLPPP:
The following sections describe MLFR and FRF.12 feature descriptions and implementation.
The MLFR feature introduces the following new QoS requirements on the XM or MDA:
The FR class queue parameters and its scheduling parameters are configured by applying an Egress QoS profile to an MLFR bundle.
Table 71 and Figure 53 provide the details of the class queue threshold parameters. Packets that are marked with high drop precedence, for example, out-of-profile, by the service or network ingress QoS policy will be discarded when any class queue reaches the OOP threshold. Packets with a low drop precedence marking, for example, in profile, will be discarded when any class queue reaches the max threshold. Only the max threshold is user configurable and is referred to as max-queue-size in the CLI. The OOP threshold is always set to 50% of the max threshold.
Class 0 | Class 1 | Class 2 | Class 3 | |||||
Queue threshold (in ms@available bundle rate | Max | Oop | Max | Oop | Max | Oop | Max | Oop |
10 | 5 | 50 | 25 | 150 | 75 | 750 | 375 |
Table 72 and Figure 54 provide the details for the class queue scheduling parameters for an MLFR bundle.
WRR Parameters | |||
MIR | W1 | W2 | W3 |
90% | <1% | 89% | 10% |
The minimum information rate, referred to as MIR in Figure 54 and MIR in CLI, applies to Class 1 queues only. The MIR parameter value is entered as a percentage of the available bundle rate. The WRR weight, referred to as W1, W2, and W3 in Table 72 and weight in CLI, applies to class 1, class 2, and class 3 queues. W1 is not configurable and is internally set to a value of 1 such that Class 1 queue shares 1% of the available bundle rate when the sum of W1, W2, and W3 equals 100. W2 and W3 weights are integer values and are user configurable such that Class 2 queue shares W2/(W1+W2+W3) and Class 3 queue shares W3/(W1+W2+W3) of the available bundle rate.
All queue threshold and queue scheduling parameters are adjusted to the available bundle rate. If a member link goes down or a new member link is added to the bundle, the scheduling parameters MIR, W1, W2, W3, as well as the per class queue thresholds OOP and max are automatically adjusted to maintain the same values.
In addition, operator user can configure the value of the FR scheduling class ingress re-assembly timeout for an MLFR bundle. The default values of the timers are shown in Table 73.
Class 0 | Class 1 | Class 2 | Class 3 |
10 | 10 | 100 | 100 |
The following operations require the bundles or links associated with a QoS profile to be shutdown to take effect.
The following operations can be performed without shutting down the associated bundles or links:
When end-to-end fragmentation is enabled on an FR SAP, the queuing and scheduling on the XMA or MDA is reusing the existing FR SAP high and low priority queues are show in Figure 55.
Some minor modifications are introduced to accommodate end-to-end FRF.12 fragments. The user configured FR scheduling class for this SAP will dictate which of the FR SAP XMA or MDA queues should be used to queue the fragments. Classes 0 and 1 map all fragments of the FR SAP to the Hi-Priority SAP queue. Classes 2 and 3 map all fragments of the FR SAP to the Low-Priority SAP queue.
The scheduling parameters of these queues have to be modified from existing ones as follows: