Configuring Multiclass MLPPP on LSQ Interfaces
For link services IQ (lsq-) interfaces with MLPPP encapsulation, you can configure multiclass MLPPP (MCML). If you do not configure MCML, fragments from different classes cannot be interleaved. All fragments for a single packet must be sent before the fragments from another packet are sent. Nonfragmented packets can be interleaved between fragments of another packet to reduce latency seen by nonfragmented packets. In effect, latency-sensitive traffic is encapsulated as regular PPP traffic, and bulk traffic is encapsulated as multilink traffic. This model works as long as there is a single class of latency-sensitive traffic, and there is no high-priority traffic that takes precedence over latency-sensitive traffic. This approach to LFI, used on the Link Services PIC, supports only two levels of traffic priority, which is not sufficient to carry the four-to-eight forwarding classes that are supported by M Series and T Series routers. For more information about the Link Services PIC support of LFI, see Configuring Delay-Sensitive Packet Interleaving on Link Services Logical Interfaces.
For link services IQ interfaces only, you can configure MCML, as defined in RFC 2686, The Multi-Class Extension to Multi-Link PPP. MCML makes it possible to have multiple classes of latency-sensitive traffic that are carried over a single multilink bundle with bulk traffic. In effect, MCML allows different classes of traffic to have different latency guarantees. With MCML, you can map each forwarding class into a separate multilink class, thus preserving priority and latency guarantees.
 | Note: Configuring both LFI and MCML on the same bundle is not necessary, nor is it supported, because multiclass MLPPP represents a superset of functionality. When you configure multiclass MLPPP, LFI is automatically enabled. The Junos OS implementation of MCML does not support compression of common header bytes, which is referred to in RFC 2686 as “prefix elision.” |
MCML greatly simplifies packet ordering issues that occur when multiple links are used. Without MCML, all voice traffic belonging to a single flow is hashed to a single link to avoid packet ordering issues. With MCML, you can assign voice traffic to a high-priority class, and you can use multiple links. For more information about voice services support on link services IQ interfaces (lsq), see Configuring Services Interfaces for Voice Services.
To configure MCML on a link services IQ interface, you must specify how many multilink classes should be negotiated when a link joins the bundle, and you must specify the mapping of a forwarding class into an MCML class.
To specify how many multilink classes should be negotiated when a link joins the bundle, include the multilink-max-classes statement:
You can include this statement at the following hierarchy levels:
- [edit interfaces interface-name unit logical-unit-number]
- [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]
The number of multilink classes can be 1 through 8. The number of multilink classes for each forwarding class must not exceed the number of multilink classes to be negotiated.
To specify the mapping of a forwarding class into a MCML class, include the multilink-class statement at the [edit class-of-service fragmentation-maps map-name forwarding-class class-name] hierarchy level:
The multilink class index number can be 0 through 7. The multilink-class statement and no-fragmentation statements are mutually exclusive.
To view the number of multilink classes negotiated, issue the show interfaces lsq-fpc/pic/port.logical-unit-number detail command.
