QoS in MC-MLPPP

Overview

If the user enables the multi-class option under an MLPPP bundle, the XMA or MDA egress data path provides a queue for each of the four 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, therefore, in 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 described in Default packet forwarding class to MLPPP class mapping .

Table 1. Default packet forwarding class to MLPPP class mapping
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

Packet forwarding class to MLPPP class mapping describes a different mapping enabled when the user applies one of three predefined egress QoS profiles in the 4-class bundle configuration only.

Table 2. Packet forwarding class to MLPPP class mapping
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.

MLPPP class queue threshold parameters and MLPPP class queue thresholds for in-profile and out-of-profile packets describe 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 are discarded when any class queue reaches the OOP threshold. Packets with a low drop precedence marking, such as in-profile, are discarded when any class queue reaches the max threshold.

Table 3. MLPPP class queue threshold parameters

 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
Figure 1. MLPPP class queue thresholds for in-profile and out-of-profile packets

MLPPP class queue scheduling parameters and MLPPP class queue scheduling scheme describe the class queue scheduling parameters.

Table 4. MLPPP 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%
Figure 2. MLPPP class queue scheduling scheme

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 2 and 3 queues 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 needed 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 serviced with strict priority in ascending order of class number.

Ingress MLPPP class reassembly

For an MLPPP bundle with the multi-class option enabled, there is a default profile for setting the reassembly 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 described in MLPPP ingress QoS profile: reassembly timers (ms).

Table 5. MLPPP ingress QoS profile: reassembly timers (ms)

 Class 0 Class 1 Class 2 Class 4

MLPPP ingress QoS default profile (2-Class bundle)

25

25

NA

NA

MLPPP ingress QoS default profile (3-Class bundle)

25

25

25

NA

MLPPP ingress QoS default profile (4-Class bundle)

25

25

100

1000

MLPPP ingress QoS profile 1 (4-class bundle)

10

10

100

1000

Basic configurations

Configure an egress and ingress MLPPP profile.

The following displays the profile configuration examples:


A:ALA-12>config>qos# info
#------------------------------------------
       mlppp-profile-ingress 2 [create]
           description my-4-class-bundle-ingress-profile            
               class class 0
                   reassembly-timeout 10
               class class 1
                   reassembly-timeout 100
               class class 2
                   reassembly-timeout 500
               class class 3
                   reassembly-timeout 1000
       mlppp-profile-egress 4 [create]
           description my-4-class-bundle-egress-profile
           fc be mlppp-class 3
           fc l2 mlppp-class 2
           fc af mlppp-class 2
           fc l1 mlppp-class 2
           fc h2 mlppp-class 2
           fc ef mlppp-class 1
           fc h1 mlppp-class 1
           fc nc mlppp-class 0
                  class 0
              max-queue-size  10
           class 1
              max-queue-size  50
              mir 25
                 class 2
              max-queue-size  100
              weight 25
                 class 3
              max-queue-size  1000
              weight 75

#------------------------------------------
A:ALA-12>config>qos#


A:ALA-12>config>port>ml-bundle# info
#------------------------------------------
               multilink-bundle bundle-ppp-6/1.1
                 multilink-bundle
                    fragment-threshold 384
                 mlppp
               multiclass 4
                           ingress
                              qos-profile 2
                 exit
                           egress
                              qos-profile 4
                           exit
                    exit
                    exit
                    member 1/1/1.1.1.1
                    member 1/1/1.1.2.1
                    member 1/1/1.1.3.1
                    member 1/1/1.1.4.1
                    minimum-links 2

Configuring MC-MLPPP

Use the following CLI syntax to create an MC-MLPPP:

config>qos# mlppp-profile-ingress 2 [create]
description dmy-4-class-bundle-ingress-profile
class class 0
reassembly-timeout 10
class class 1
reassembly-timeout 100
class class 2
reassembly-timeout 500
class class 3
reassembly-timeout 1000
config>qos# mlppp-profile-egress 4 [create]
description dmy-4-class-bundle-egress-profile

Configuring MC-MLPPP QoS parameters

A 4-class MLPPP bundle can be configured. This feature cannot be used with MC-MLPPP bundles with fewer than 4 classes.

The following describes the parameters and the configuration processes and rules:

  • The user creates an ingress QoS profile, mlppp-profile-ingress, to configure the wanted value of the ingress per-class reassembly timer. Ingress QoS profile #1 is reserved to the predefined profile with parameter values in MLPPP ingress QoS profile: reassembly timers (ms). 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, is always the one in MLPPP ingress QoS profile: reassembly timers (ms) for the ingress QoS Profile #1, regardless what parameter value the edited Profile #1 has at that time.

  • The user creates an egress QoS profile, mlppp-profile-egress, to configure the wanted values for the per-class queue and queue scheduling parameters. The user is also able to configure the mapping of the system forwarding classes to the MLPPP classes. Egress QoS profiles #1, 2, and 3, are reserved to the predefined profiles with parameter values shown in Packet forwarding class to MLPPP class mapping , MLPPP class queue threshold parameters, or MLPPP class queue scheduling parameters . The user is allowed to edit these profiles and change parameter values. However, the default value of a parameter when a user creates a profile with a profile-id higher than 3, or when the user performs the no option on the parameter, is the one shown in Packet forwarding class to MLPPP class mapping , MLPPP class queue threshold parameters, or MLPPP class queue scheduling parameters for the egress QoS Profile #1. This is regardless of the parameter value the edited profiles have at that time.

  • A maximum of 128 ingress QoS profiles and 128 egress QoS profiles can be created on the system.

  • The values of the ingress per-class reassembly timer are configured in the ingress QoS profile.

  • The mapping of the system forwarding classes to the MLPPP classes are configured in the egress QoS profile. There is a many-to-one relationship between the system FC and an MLPPP class. See Packet forwarding class to MLPPP class mapping for the mapping when one of the three predefined 4-class egress QoS profiles is selected.

  • The maximum size for each MLPPP class queue in units of ms at the available bundle rate is configured in the egress QoS profile. This is referred to as max in MLPPP class queue thresholds for in-profile and out-of-profile packets and as max-queue-size in CLI. The out-of-profile threshold for an MLPPP class queue, referred to as oop in MLPPP class queue thresholds for in-profile and out-of-profile packets, is not directly configurable and is set to 50% of the maximum queue size rounded up to the nearest higher integer value.

  • The MLPPP class queue scheduling parameters are configured in the egress QoS profile. The minimum information rate, referred to as MIR in MLPPP class queue scheduling scheme and mir in CLI, applies to Class 1 queue 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 MLPPP class queue scheduling scheme and weight in CLI, applies to class 1, class 2, and class 3 queues. W1 in MLPPP class queue scheduling scheme 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 as percentage Class 2 queue shares and Class 3 queue shares of the available bundle rate.

  • The user applies the ingress and egress QoS profiles to a 4-class MLPPP bundle for the configured QoS parameter values to take effect on the bundle.

  • The following operations require the bundles associated with a QoS profile to be shutdown to take effect:

    • a change of the numbered ingress or egress QoS profile associated with a bundle

    • a change of the bundle associated ingress or egress QoS profile from default profile to a numbered profile and the other way around

  • Changes to any parameters in the ingress and egress QoS profiles can be performed without shutting down the associated bundles.

QoS in MLFR and FRF.12 fragmentation

The following sections describe MLFR and FRF.12 feature descriptions and implementation.

QoS in MLFR

The MLFR feature introduces the following new QoS requirements on the XM or MDA:

  • Four XMA or MDA queues are provided per MLFR bundle to store the fragments of the FR SAP packets; one queue per FR scheduling class. Fragments of all FR SAPs of a specific scheduling class are queued in the same queue.

  • The fragments of an FR SAP packet must be queued in the same XMA or MDA queue regardless of which forwarding class queue they use in the IOM.

The FR class queue parameters and its scheduling parameters are configured by applying an Egress QoS profile to an MLFR bundle.

Default FR class queue threshold parameters and FR class queue thresholds for in-profile and out-of-profile packets describe 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 are discarded when any class queue reaches the OOP threshold. Packets with a low drop precedence marking, for example, in-profile, are 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.

Table 6. Default FR class queue threshold parameters

 Class 0 Class 1 Class 2 Class 3
Max Oop Max Oop Max Oop Max Oop

Queue threshold (in ms@available bundle rate)

10

5

50

25

150

75

750

375
Figure 3. FR class queue thresholds for in-profile and out-of-profile packets

Default FR class queue scheduling parameters and FR class queue scheduling for an MLFR bundle describe the class queue scheduling parameters for an MLFR bundle.

Table 7. Default FR class queue scheduling parameters
WRR parameters

MIR

W1

W2

W3

90%

<1%

89%

10%
Figure 4. FR class queue scheduling for an MLFR bundle

The minimum information rate, referred to as MIR in FR class queue scheduling for an MLFR bundle 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 Default FR class queue scheduling parameters 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, the user can configure the value of the FR scheduling class ingress reassembly timeout for an MLFR bundle. The default values of the timers are shown in Default FR ingress QoS profile: reassembly timers (ms).

Table 8. Default FR ingress QoS profile: reassembly timers (ms)
Class 0 Class 1 Class 2 Class 3

10

10

100

100

A change of the numbered ingress or egress QoS profile requires the bundles or links associated with a QoS profile to be shutdown to take effect.

Changes of parameters in the currently assigned ingress and egress QoS profiles can be made without shutting down the associated bundles or links.

QoS in FRF.12 end-to-end fragmentation

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, as shown in DLC egress channel queue scheduling.

Figure 5. DLC egress channel queue scheduling

Some minor modifications are introduced to accommodate end-to-end FRF.12 fragments. The user-configured FR scheduling class for this SAP dictates 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 high-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:

  • Hi priority (HP) SAP queue: SAP_HP_Q_PIR= Sum{all SAP_FC_Q_PIR}

  • Low priority (LP) SAP queue: SAP_LP_Q_WRR_Weight = Sum{all SAP_FC_Q_CIR}