CoS for PPP and MLPPP Interfaces on ACX Series Routers

Limitations That are Common for CoS on PPP and MLPPP Interfaces

The following restrictions apply for configuring CoS on PPP and MLPPP interfaces on ACX Series routers:

• For interfaces with PPP encapsulation, you can configure interfaces to support the IPv4, Internet Protocol Control Protocol (IPCP), PPP Challenge Handshake Authentication Protocol (CHAP), and Password Authentication Protocol (PAP) applications.

• Drop timeout, which defines a recovery method for any packets dropped by the member links in a link services or multilink bundle, is not applicable for ACX routers.

• Loss of traffic occurs during a change of CoS configuration; you cannot modify scheduling attributes instantaneously. The link moves to the down state for PPP, and the protocol is denoted as down for MLPPP interfaces.

• Scheduling and shaping capabilities are based on the CIR-EIR model and are not in accordance with the weighed fair queuing mode. The minimum transmit speed is 32 Kbps, and the minimum difference that can be supported between the transmit rate and shaping rate is also 32 Kbps.

• Buffer size is calculated in terms of packets using 256 bytes as the average packet size. For example, if you configure a 10 percent buffer size for TI interfaces, the buffer allocated as 1.536 Mbps * (10/100) * (0.1 sec) = 15360 bits. The following formula computes the configured queue length:

  Queue length configured = Buffer/average packet size = (15360/256)/8 = 7.5 = 8 packets.

  Because there are no shared buffers, the usage of "buffer-size" and "buffer-size exact" attributes result in the same behavior.

• Only two loss priority levels, namely low and high, are supported. Traffic that arrives from the Packet Forwarding Engine with a medium-high priority is treated as high priority traffic. Although you can configure the medium-high loss priority type when you configure the action for a firewall term, it is considered by the system as high priority traffic.

• A fixed, in-built mapping between forwarding class and queue number as follows is performed: Best-effort is queue 0, expedited-forwarding is queue 1, assured-forwarding is queue 2, and network-control is queue 3

• For WRED configurations, the difference between maximum fill-level and minimum-fill level is a number raised to the power of 2 in terms of number of packets (x^2). Otherwise, the lower fill-level is tuned to turn the difference into a value raised to the power of 2. For example, queues contain a size of 64 packets. If the following configuration is performed:

  content_copy zoom_out_map

   fill-level 50 drop-probability 0; 
  fill-level 100 drop-probability 100;
  

• For the lower fill level, the minimum number of packets is 32. However, if you specify the fill-level to be 45 instead of 50, the lower fill level is 28. Because 64 - 28, which equals 36 is not a power of 2, the lower fill-level is internally adjusted to convert it to be a number exponentially raised to 2.

• When fragmentation-map is configured, the forwarding-class carrying the multi-class 0 traffic must be assigned the highest priority and the forwarding-class carrying the multi-class 3 traffic must be assigned the lowest priority. Such a configuration is necessary because of the NPU design.

Limitations for CoS on PPP Interfaces

The following restrictions apply for configuring CoS on PPP interfaces on ACX Series routers:

• The distribution of excess rate between 2 or more queues that contain the same priority occurs on a first-come, first-served basis. For example, consider two Queues configured as follows:

  Q1 : Transmit-rate = 10%, Shaping-rate = 20%

  Q2 : Transmit-rate = 10%, Shaping-rate = 30% on same priority

  The excess rate for Q1 = (20 - 10) = 10%

  The excess rate for Q2 = (30 - 10) = 20%

• The excess rate distribution between Q1 and Q2 does not follow the same ratio but packets in these queues are served in first-come, first-served manner. The shaping rate continues to be honored in such a scenario.

Guidelines for Configuring CoS on PPP and MLPPP Interfaces

Keep the following points in mind when you configure CoS on PPP and MLPPP interfaces:

• You can configure only the any option with the protocol statement at the [edit class-of-service schedulers scheduler-name drop-profile-map] hierarchy level to specify the protocol type for the specified scheduler. You cannot specify the TCP or non-TCP protocol types.

• CoS functionalities for fractional T1 and E1 interfaces are not supported. CoS is supported only for full T1 and E1 interfaces.

• Weighted fair queuing (WFQ) shaping and scheduling model is not supported. Instead of WFQ, CIR-EIR model is supported to handle shaping and scheduling requirements.

• Percentage-based rate configuration is not supported for MLPPP LSQ interfaces; only absolute rate configration in bps is supported.

• Auto-adjustment of shaping and scheduling rates with the addition or deletion of T1/E1 links is not supported. All the limitations applicable for CoS on ACX routers apply for PPP interfaces.

• All the policer limitations on ACX routers for Gigabit Ethernet interfaces are valid for PPP interfaces. This restriction includes ingress and egress policers. Because these limitations are chassis-wide, they are also effective for PPP interfaces.

• All valid configurations specified for MLPPP interfaces with inet address families are also valid for MLPPP interfaces with MPLS address families. For example, EXP classifier as a global classifier is supported for ingress classification and EXP rewrite rule is supported for egress logical interfaces.

• PPP encapsulation is supported on ACX1000, ACX2000, ACX2100, and ACX4000 routers.

• A maximum of 1000 logical interfaces can be supported on an ACX router .

• A maximum of 280 PPP or MLPPP logical interfaces can support drop-profiles on a system. On each MIC, a maximum of 140 PPP or MLPPP interfaces are supported.

Limitations for CoS on MLPPP Interfaces

The following restrictions apply for configuring CoS on MLPPP interfaces on ACX Series routers:

• Percentage-based configuration for scheduling and shaping parameters is not supported; only absolute rate configuration is supported. As a result, dynamic, swift redjustment of shaping and scheduling settings does not happen with the addition or deletion of T1/E1 links.

• Buffer size is calculated in terms of a single T1 or E1 link speed. Therefore, a temporal value, in microseconds, is used to compute the buffer size for a higher value of the buffer size. For the temporal setting, the queuing algorithm starts dropping packets when it queues more than a computed number of bytes. This maximum is computed by multiplying the transmission rate of the queue by the configured temporal value. The default queue size and percentage-based queue size are not based on the current bandwidth.

• If you configure a scheduler map without a fragmentation map, any scheduler-map configuration including the default settings are applied the same behavior as the exact transmission rate functionality. Priorities of traffic are not honored and no excess rates are provisioned. The forwarding class with no rate configuration receives the minimum fixed rate allocated to it, which is 32 Kbps.

• Support for oversubscription and priority is not available, which might cause inefficient bandwidth utilization. For example, consider a default scheduler map, with the best-effort queue configured with a rate that is equal to 16*T1*(.95) transmit-rate exact.

• The network-control queue is configured with a rate that is equal to 16*T1*(0.05) transmit rate exact. In such a scenario, the following behavior is observed for MLPPP bundle with a single T1 link:

  Traffic that arrives as only best-effort type of traffic is provided with complete bandwidth capacity if no traffic is distributed to any other queue. Traffic that arrives on the only network-control queue is limited to a bandwidth of 1.2288 Mbps, even if no traffic is present on any other queue. When traffic arrives on both the best-effort and network-control queues, an equal division of traffic is done on both the queues because both the queues are within their minimum guarantee rate. Queues other than Best-Effort and Network-Control receive 32 Kbps of exact transmit bandwidth.

  Queues other than best-effort and network-control are assigned 32 Kbps of exact transmit bandwidth.

Consider another example of a default scheduler map, and an MLPPP bundle with two T1 links. In such a scenario, the following behavior is observed for MLPPP bundle with two T1 links:

Traffic that arrives on only the best-effort queue obtains the entire bandwidth capacity if there is no traffic on any other queue. Traffic that arrives on only the network-control queue is limited to 1.2288 Mbps, even when no traffic is passing through any other queue. When traffic arrives on both the queues, it is marked at 1.2288 Mbps for the network-control queue and at 1.843200 Mbps for best-effort queue.

For a default scheduler-map with an MLPPP bundle that contains 16 T1 links, the traffic that arrives as only best-effort traffic receives a bandwidth that is equal to (0.95 * 16 * T1) capacity if there is no traffic on any other queue. Traffic that arrives as only network-control traffic is limited to 1.2288 Mbps even if no traffic on any other queue is observed. When traffic arrives on both the queues, it is tagged as 1.2288 Mbps for network-control and (0.95 * 16 * T1) Mbps for best-effort queues. If you configure a scheduler-map with a fragmentation map, two or more classes when configured with same priority receive only the transmit-rate served for them and function as the traffic defined for exact transmit-rate functionality.

Support for oversubscription between two multi-classes on the same priority is not provided. The queue corresponding to which there is no-multiclass entry is moved to the disabled state. Only one-to-one mapping between forwarding-class to multi-class is supported. One forwarding class can send traffic corresponding to only one multi-class.

CoS Functionalities for IPv4 Over PPP Interfaces

The following CoS capabilities are supported on PPP interfaces for IPv4 traffic:

• Ingress Classification can be either specified as fixed classifiers or behavior aggregate (BA) classifiers. Fixed classifiers map all traffic on an interface to the forwarding class. The forwarding class determines the output queue. To configure a fixed classifier, include the forwarding-class class-name statement at the [edit class-of-service interface interface-name unit logical-unit-number] hierarchy level.

• BA classification, or CoS value traffic classification, refers to a method of packet classification that uses a CoS configuration to set the forwarding class of a packet based on the CoS value in the IP packet header. The CoS value examined for BA classification purposes can be the Differentiated Services code point (DSCP) value, or the IP precedence value, or EXP bits. The default classifier is based on the IP precedence value.

• To configure the global EXP classifier, include the following statements at the [edit class-of-service system-defaults] hierarchy level.

  content_copy zoom_out_map

  [edit class-of-service]
  {
      system-defaults
          {
          classifiers exp classifier-name
      }
  }
  

  CoS supports one global system default classifier of the EXP type, as shown in the following example:

  content_copy zoom_out_map

  [edit class-of-service]
  {
      system-defaults {
          classifiers {
              exp exp-classf-core;
          }
      }
  }
  

• All packets that are received on a logical interface in the ingress direction can be classified to a single forwarding class using fixed classification.

• BA Classification based on the following packet fields is supported at the logical interface level:

  • IPv4 - inet-precedence

  • DSCP

  The following is the configuration stanza for defining BA classifiers:

  content_copy zoom_out_map

  [edit class-of-service]
          classifiers {
              (inet-precedence|dscp ) classifier-name
              {
                  forwarding-class class-name loss-priority [low | high] code-points ([ aliases ] | [ dscp-bits ]);
              }
  

• Queuing and scheduling functionalities comprise the following parameters:

  • Transmit rate per queue

  • Shaping rate per queue

  • WRED

  • Forwarding classes. A maximum of 4 forwarding classes can be defined for PPP interfaces.

• The four priorities supported for logical interface-level queuing are strict-high, medium-high, medium-low, or low. The transmit rate per queue (CIR) is the minimum committed rate can be specified for each queue. The shaping rate per queue (PIR) is the maximum transmit rate can be specified for each queue. For WRED, the default behavior is to enable tail drops. The drop profile configuration enables WRED and enables different drop behavior based on the drop precedence to be entered. Loss priority settings help determine which packets are dropped from the network during periods of congestion. The software supports multiple packet loss priority (PLP) designations: low and high

• Buffer-size can be specific in percentage and temporal configuration. This size is turned into the number of packets per queue, with 256 bytes treated as the average packet size. The following settings can be configured at the queue level:

  • Guaranteed transmit rate (CIR)

  • Shaping rate (PIR)

  • Drop profile

  • Buffer size

  content_copy zoom_out_map

  	[edit class-of-service]
          schedulers scheduler_name {
              transmit-rate (percent number | rate);
              shaping-rate (percent number | rate);
              buffer-size (percent | temporal)
              drop-profile-map map_name;
          }
  

  Only 4 forwarding classes and only 4 queues per logical interface are supported. Also, logical interface-based shaping is not supported.

• Packet and byte counters for transmitted and dropped packets are available per queue. These statistical details are displayed using the show interfaces queue command. Aggregation to provide port-level statistics, if needed, is also supported by the system. The logical interface-level statistics are correctly available for egress direction and are displayed in the output, but the statistics pertaining to dropped packets are not considered because of hardware limitations. The following configuration stanza defines the rewrite rules:

  content_copy zoom_out_map

          [edit class-of-service]
          rewrite-rules {
              (inet-precedence | dscp | exp) rewrite-name
              {
                  forwarding-class class-name loss-priority [low | high] code-point value;
              }
          }
  
  

  Each of the rewrite rules can be attached to an interface by using the following configuration syntax:

  content_copy zoom_out_map

  [edit class-of-service interfaces interface-name]

  content_copy zoom_out_map

  rewrite-rules {
      dscp (rewrite-name | default) protocol (inet-both | inet-outer | mpls);
      exp (rewrite-name | default) protocol protocol-types;
      inet-precedence (rewrite-name | default) protocol (inet-both | inet-outer | mpls);
  }
  

  All of the firewall features supported on ACX routers are applicable for PPP interfaces for IPv4 packets.

• For rewrite rules, IPv4 or inet precedence and EXP rules are supported. EXP rewrite rules apply only to logical interfaces. You cannot apply EXP rewrite rules to physical interfaces. There are no default EXP rewrite rules. If you want to rewrite the EXP value in MPLS packets, you must configure EXP rewrite rules and apply them to logical interfaces. If no rewrite rules are applied, all MPLS labels that are pushed have a value of zero (0). The EXP value remains unchanged on MPLS labels that are swapped.

CoS Functionalities for IPv4 Over MLPPP Interfaces

The following CoS capabilities are supported on MLPPP interfaces for IPv4 traffic:

• Ingress Classification can either be specified as fixed or BA classifiers.

• Fixed classification using forwarding classes and BA classification using IPv4 precedence value are supported.

• The following scheduling and queuing properties are supported:

  • Transmit rate per queue

  • Shaping rate per queue

  • WRED

  • Forwarding classes

  • Buffer size per queue

• Forwarding class to multilink class mapping. You use the multilink-class statement to map a forwarding class into a multiclass MLPPP (MCML).

• All of the firewall features supported on ACX routers are applicable for MLPPP interfaces for IPv4 packets

• For rewrite rules, IPv4 precedence rule is supported.

The following CoS capabilities are supported on MLPPP interfaces for MPLS packets:

• Ingress Classification can either be specified as fixed or BA classifiers. Fixed classification using forwarding classes and BA classification using EXP bits are supported.

• The following scheduling and queuing properties are supported:

  • Transmit rate per queue

  • Shaping rate per queue

  • WRED

  • Forwarding classes

  • Buffer size per queue

• Forwarding class to multilink class mapping. You use the multilink-class statement to map a forwarding class into a multiclass MLPPP (MCML).

• All of the firewall features supported on ACX routers are applicable for MLPPP interfaces for IPv4 packets

• For rewrite rules, the EXP rule is supported.

The following example illustrates an MLPPP CoS configuration set:

[edit]
class-of-service {
        classifiers {
            inet-precedence all-traffic-inet {
                forwarding-class assured-forwarding {
                    loss-priority low code-points 101;
                }
                forwarding-class expedited-forwarding {
                    loss-priority low code-points 000;
                }
            }
        }
        drop-profiles {
            plp-low-red {
                fill-level 50 drop-probability 0;
                fill-level 100 drop-probability 100;
            }
            plp-high-red {
                fill-level 25 drop-probability 0;
                fill-level 50 drop-probability 100;
            }
        }
        forwarding-classes {
            queue 0 best-effort;
            queue 1 assured-forwarding;
            queue 2 expedited-forwarding;
            queue 3 network-control;
        }

        schedulers {
            evdo-mlppp-best-effort {
                transmit-rate 1M;
                buffer-size percent 80;
                priority medium-high;
            }
            evdo-mlppp-assured-forwarding {
                transmit-rate 500000;
                buffer-size percent 10;
                drop-profile-map loss-priority low protocol any drop-profile plp-low-red;
                drop-profile-map loss-priority high protocol any drop-profile plp-high-red;
                priority medium-low;
            }
            evdo-mlppp-expedited-forwarding {
                transmit-rate 300000;
                buffer-size percent 5;
                priority low;
            }
            evdo-mlppp-network-control {
                transmit-rate 200000;
                buffer-size percent 5;
                priority strict-high;
            }
        }

        scheduler-maps {
            evdo-mlppp-cos-map {
                forwarding-class best-effort scheduler evdo-mlppp-best-effort;
                forwarding-class assured-forwarding scheduler evdo-mlppp-assured-forwarding;
                forwarding-class network-control scheduler evdo-mlppp-network-control;
                forwarding-class expedited-forwarding scheduler evdo-mlppp-expedited-forwarding;
            }
        }               
        fragmentation-maps {
            frag-mlppp {
                forwarding-class {
                    assured-forwarding {
                        multilink-class 2;
                    }
                    expedited-forwarding {
                        multilink-class 3;
                    }
                    best-effort {
                        multilink-class 1;
                    }
                    network-control {
                        multilink-class 0;
                    }
                }
            }
        }

        interfaces {
            lsq-0/* {
                    unit * {
                        scheduler-map evdo-mlppp-cos-map;
                        fragmentation-map frag-mlppp;
                    }
            }
        }

The following example illustrates an MLPPP firewall configuration set:

[edit]
firewall {
            filter classify-evdo-traffic-mlppp {
                interface-specific;
                term signalling {
                    from {
                        dscp ef;
                    }
                then {
                    count signalling-counter;
		    forwarding-class network-control;
		    accept;
		}
            }
	    term user-speech {
	        from {
                    dscp af31;
                }
	        then {
	            policer user-speech-rate-limit;
                    count user-speech-counter;
                    forwarding-class network-control;
                    accept;
                }
            }
	    term ptt-mcs {
	        from {
	            dscp af11;
	        }
	        then {
	            count ptt-mcs-counter;
	            forwarding-class network-control;
	            accept;
	        }
	    }
	    term user-video {
	        from {
	            dscp af21;
	        }
	        then {
	            count user-video-counter;
	                loss-priority low;
	                forwarding-class assured-forwarding;
	                accept;
	            }       
	        }
                term user-cmcs {
                    from {
                        dscp af12;
                    }
	            then {
	                count user-cmcs-counter;
	                loss-priority low;
	                forwarding-class assured-forwarding;
	                accept;
	            }
	        }
	        term ran-rlp-retransmission {
	            from {
	                dscp af41;
	            }
	            then {
	                count rlp-retransmit-counter;
	                loss-priority high;
	                forwarding-class assured-forwarding;
	                accept;
	            }
	        }
	        term user-best-effort {
	            then {
                    count user-be-counter;
		        forwarding-class best-effort;
	                accept;
	            }
	        }
	    }
	}