Link Services Interfaces Overview

You configure the link services queuing interface (lsq-0/0/0) on a J Series device to support multilink services and Compressed Real-Time Transport Protocol (CRTP).

The link services interface on a J Series device consists of services provided by the following interfaces on the Juniper Networks M Series and T Series routing platforms: multilink services interface (ml-fpc/pic/port), link services interface (ls-fpc/pic/port), and link services intelligent queuing interface (lsq-fpc/pic/port). Although the multilink services, link services, and link services intelligent queuing (IQ) interfaces on M Series and T Series routing platforms are installed on Physical Interface Cards (PICs), the link services interface on a J Series device is an internal interface only and is not associated with a physical medium or Physical Interface Module (PIM).

Note: (ls-fpc/pic/port) is not supported on J series and SRX platforms.

For more information about the link services interfaces, see the Junos Services Interfaces Configuration Guide.

This section contains the following topics.

• Services Available on J Series Link Services Interface
• Link Services Exceptions on J Series Services Routers
• Multilink Bundles Overview
• Link Fragmentation and Interleaving Overview
• Compressed Real-Time Transport Protocol Overview
• Configuring Fragmentation by Forwarding Class
• Configuring Link-Layer Overhead
• Configuring Multiclass MLPPP
• Queuing with LFI on J Series Devices
• Configuring CoS Components with LFI

Services Available on J Series Link Services Interface

On a J Series device, the link services interface is a logical interface available by default. Table 77 summarizes the services available on a J Series link services interface.

Link Services Exceptions on J Series Services Routers

The link and multilink services implementation on a J Series Services Router is similar to the implementation on the M Series and T Series routing platforms, with the following exceptions:

• J Series devices support link and multilink services on the lsq-0/0/0 interface instead of the ml-fpc/pic/port, lsq-fpc/pic/port, and ls-fpc/pic/port interfaces.
• When LFI is enabled, fragmented packets are queued in a round-robin fashion on the constituent links to enable per-packet and per-fragment load balancing. For more information, see Queuing with LFI on J Series Devices.
• J Series devices support per-unit scheduling on all types of constituent links (on all types of interfaces).
• J Series devices support Compressed Real-Time Transport Protocol (CRTP) with MLPPP as well as PPP.

Multilink Bundles Overview

The J Series device supports MLPPP and MLFR multilink encapsulations. MLPPP enables you to bundle multiple PPP links into a single multilink bundle, and MLFR enables you to bundle multiple Frame Relay data-link connection identifiers (DLCIs) into a single multitlink bundle. Multilink bundles provide additional bandwidth, load balancing, and redundancy by aggregating low-speed links, such as T1, E1, and serial links.

You configure multilink bundles as logical units or channels on the link services interface lsq-0/0/0:

• With MLPPP and MLFR FRF.15, multilink bundles are configured as logical units on lsq-0/0/0—for example, lsq-0/0/0.0 and lsq-0/0/0.1.
• With MLFR FRF.16, multilink bundles are configured as channels on lsq-0/0/0—for example, lsq-0/0/0:0 and lsq-0/0/0:1.

After creating multilink bundles, you add constituent links to the bundle. The constituent links are the low-speed physical links that are to be aggregated. You can create 64 multilink bundles, and on each multilink bundle you can add up to 8 constituent links. The following rules apply when you add constituent links to a multilink bundle:

• On each multilink bundle, add only interfaces of the same type. For example, you can add either T1 or E1, but not both.
• Only interfaces with a PPP encapsulation can be added to an MLPPP bundle, and only interfaces with a Frame Relay encapsulation can be added to an MLFR bundle.
• If an interface is a member of an existing bundle and you add it to a new bundle, the interface is automatically deleted from the existing bundle and added to the new bundle.

For information about configuring MLPPP bundles, see Configuring an MLPPP Bundle. For information about configuring MLFR bundles, see Configuring MLFR FRF.15 Bundles and Configuring MLFR FRF.16 Bundles.

Link Fragmentation and Interleaving Overview

As it does on any other interface, priority scheduling on a multilink bundle determines the order in which an output interface transmits traffic from an output queue. The queues are serviced in a weighted round-robin fashion. But when a queue containing large packets starts using the multilink bundle, small and delay-sensitive packets must wait their turn for transmission. Because of this delay, some slow links, such as T1 and E1, can become useless for delay-sensitive traffic.

Link fragmentation and interleaving (LFI) solves this problem. It reduces delay and jitter on links by fragmenting large packets and interleaving delay-sensitive packets with the resulting smaller packets for simultaneous transmission across multiple links of a multilink bundle.

Figure 29 illustrates how LFI works. In this figure, Device R0 and Device R1 have LFI enabled. When Device R0 receives large and small packets, such as data and voice packets, it divides them into two categories. All voice packets and any other packets configured to be treated as voice packets are categorized as LFI packets and transmitted without fragmentation or an MLPPP header. If CRTP is configured on the bundle, LFI packets are transmitted through CRTP processing. The remaining non-LFI (data) packets can be fragmented or unfragmented based on the configured fragmentation threshold. The packets larger than the fragmentation threshold are fragmented. An MLPPP header (containing a multilink sequence number) is added to all non-LFI packets, fragmented and unfragmented.

The fragmentation is performed according to the fragmentation threshold that you configure. For example, if you configure a fragmentation threshold of 128 bytes, all packets larger than 128 bytes are fragmented. When Device R1 receives the packets, it sends the unfragmented voice packets immediately but buffers the packet fragments until it receives the last fragment for a packet. In this example, when Device R1 receives fragment 5, it reassembles the fragments and transmits the whole packet.

The unfragmented data packets are treated as a single fragment. Thus Device R1 does not buffer the unfragmented data packets and transmits them as it receives them.

For information about configuring LFI, see Enabling Link Fragmentation and Interleaving.

Compressed Real-Time Transport Protocol Overview

Real-Time Transport Protocol (RTP) can help achieve interoperability among different implementations of network audio and video applications. However, in some cases, the header, which includes the IP, UDP, and RTP headers, can be too large (around 40 bytes) on networks using low-speed lines such as dial-up modems. Compressed Real-Time Transport Protocol (CRTP) can be configured to reduce network overhead on low-speed links. CRTP replaces the IP, UDP, and RTP headers with a 2-byte context ID (CID), reducing the header overhead considerably.

Figure 30 shows how CRTP compresses the RTP headers in a voice packet and reduces a 40-byte header to a 2-byte header.

On J Series devices, you can configure CRTP with MLPPP or PPP logical interface encapsulation on link services interfaces. For more information about configuring MLPPP, see Configuring an MLPPP Bundle.

Real-time and non-real-time data frames are carried together on lower-speed links without causing excessive delays to the real-time traffic. For more information about LFI, see Link Fragmentation and Interleaving Overview.

Configuring Fragmentation by Forwarding Class

For lsq-0/0/0 on SRX210, SRX240, SRX650, J2320, J2350, J4350, and J6350 devices, you can specify fragmentation properties for specific forwarding classes. Traffic on each forwarding class can be either multilink encapsulated (fragmented and sequenced) or nonencapsulated (hashed with no fragmentation). By default, traffic in all forwarding classes is multilink encapsulated.

When you do not configure fragmentation properties for the queues on MLPPP interfaces, the fragmentation threshold you set at the [edit interfaces interface-name unit logical-unit-number fragment-threshold] hierarchy level is the fragmentation threshold for all forwarding classes within the MLPPP interface. For MLFR FRF.16 interfaces, the fragmentation threshold you set at the [edit interfaces interface-name mlfr-uni-nni-bundle-options fragment-threshold] hierarchy level is the fragmentation threshold for all forwarding classes within the MLFR FRF.16 interface.

If you do not set a maximum fragment size anywhere in the configuration, packets are still fragmented if they exceed the smallest maximum transmission unit (MTU) or maximum received reconstructed unit (MRRU) of all the links in the bundle. A nonencapsulated flow uses only one link. If the flow exceeds a single link, then the forwarding class must be multilink encapsulated, unless the packet size exceeds the MTU/MRRU.

Even if you do not set a maximum fragment size anywhere in the configuration, you can configure the MRRU by including the mrru statement at the [edit interfaces lsq-0/0/0 unit logical-unit-number] or [edit interfaces interface-name mlfr-uni-nni-bundle-options] hierarchy level. The MRRU is similar to the MTU, but is specific to link services interfaces. By default the MRRU size is 1504 bytes, and you can configure it to be from 1500 through 4500 bytes.

To configure fragmentation properties on a queue, include the fragmentation-maps statement at the [edit class-of-service] hierarchy level:

To set a per-forwarding class fragmentation threshold, include the fragment-threshold statement in the fragmentation map. This statement sets the maximum size of each multilink fragment.

To set traffic on a queue to be nonencapsulated rather than multilink encapsulated, include the no-fragmentation statement in the fragmentation map. This statement specifies that an extra fragmentation header is not prepended to the packets received on this queue and that static link load balancing is used to ensure in-order packet delivery.

For a given forwarding class, you can include either the fragment-threshold or no-fragmentation statement; they are mutually exclusive.

You use the multilink-class statement to map a forwarding class into a multiclass MLPPP. For a given forwarding class, you can include either the multilink-class or no-fragmentation statement; they are mutually exclusive.

To associate a fragmentation map with a multilink PPP interface or MLFR FRF.16 DLCI, include the fragmentation-map statement at the [edit class-of-service interfaces interface-name unit logical-unit-number] hierarchy level:

Configuring Link-Layer Overhead

Link-layer overhead can cause packet drops on constituent links because of bit stuffing on serial links. Bit stuffing is used to prevent data from being interpreted as control information.

By default, 4 percent of the total bundle bandwidth is set aside for link-layer overhead. In most network environments, the average link-layer overhead is 1.6 percent. Therefore, we recommend 4 percent as a safeguard.

For lsq-0/0/0 on SRX210, SRX240, SRX650, J2320, J2350, J4350, and J6350 devices, (lsq), you can configure the percentage of bundle bandwidth to be set aside for link-layer overhead. To do this, include the link-layer-overhead statement:

You can include this statement at the following hierarchy levels:

• [edit interfaces interface-name mlfr-uni-nni-bundle-options]
• [edit interfaces interface-name unit logical-unit-number]
• [edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number]

You can configure the value to be from 0 percent through 50 percent.

Configuring Multiclass MLPPP

For lsq-0/0/0 on SRX210, SRX240, SRX650, J2320, J2350, J4350, and J6350 devices, with MLPPP encapsulation, you can configure multiclass MLPPP. If you do not configure multiclass MLPPP, 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 routing platforms.

Multiclass MLPPP makes it possible to have multiple classes of latency-sensitive traffic that are carried over a single multilink bundle with bulk traffic. In effect, multiclass MLPPP allows different classes of traffic to have different latency guarantees. With multiclass MLPPP, you can map each forwarding class into a separate multilink class, thus preserving priority and latency guarantees.

Note: Configuring both LFI and multiclass MLPPP 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 PPP implementation does not support the negotiation of address field compression and protocol field compression PPP NCP options, which means that the software always sends a full 4-byte PPP header. The Junos OS implementation of multiclass MLPPP does not support compression of common header bytes.

Multiclass MLPPP greatly simplifies packet ordering issues that occur when multiple links are used. Without multiclass MLPPP, all voice traffic belonging to a single flow is hashed to a single link to avoid packet ordering issues. With multiclass MLPPP, you can assign voice traffic to a high-priority class, and you can use multiple links. For more information about voice services support on the lsq-0/0/0 interface, see the Junos OS Feature Support Reference for SRX Series and J Series Devices.

To configure multiclass MLPPP 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 multiclass MLPPP 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-routers logical-router-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 multiclass MLPPP class, include the multilink-class statement at the [edit class-of-service fragmentation-maps forwarding-class class-name] hierarchy level:

The multilink class index number can be 0 through 7. The multilink-class statement and the no-fragmentation statement are mutually exclusive.

To view the number of multilink classes negotiated, issue the show interfaces lsq-0/0/0.logical-unit-number detail command.

Queuing with LFI on J Series Devices

LFI or non-LFI packets are placed into queues on constituent links based on the queues in which they arrive. No changes in the queue number occur while the fragmented, non-fragmented, or LFI packets are being queued.

For example, assume that Queue Q0 is configured with fragmentation threshold 128, Q1 is configured with no fragmentation, and Q2 is configured with fragmentation threshold 512. Q0 is receiving stream of traffic with packet size 512. Q1 is receiving voice traffic of 64 bytes, and Q2 is receiving stream of traffic with 128-byte packets. Next the stream on Q0 gets fragmented and queued up into Q0 of a constituent link. The stream on Q1 is considered to be LFI because no fragmentation is configured. Therefore, all packets on Q1 are queued up on Q1 on constituent link. Because the fragmentation threshold of Q2 is more than the packet size it is receiving, the packet is queued on Q2 of a constituent link without fragmenting, but with multilink header because it is a non-LFI packet.

Using lsq-0/0/0, Compressed Real-Time Transport Protocol (CRTP) can be applied on LFI and non-LFI packets. There will be no changes in their queue numbers because of CRTP.

Queuing on Q2s of Constituent Links

When using class of service on a multilink bundle, all Q2 traffic from the multilink bundle is queued to Q2 of constituent links based on a hash computed from the source address, destination address, and the IP protocol of the packet. If the IP payload is TCP or UDP traffic, the hash also includes the source port and destination port. As a result of this hash algorithm, all traffic belonging to one traffic flow is queued to Q2 of one constituent link. This method of traffic delivery to the constituent link is applied at all times, including when the bundle has not been set up with LFI.

Configuring CoS Components with LFI

If you configure CoS components with LFI on a J Series device, we recommend that you follow certain recommendations for shaping rate, scheduling priority, and buffer size. For configuration instructions, see Configuring MLPPP Bundles and LFI on Serial Links. For more information about other CoS components, see Junos OS Class of Service Configuration Guide for Security Devices.

Shaping Rate

When you configure LFI, we recommend that you configure the shaping rate on each constituent link of the multilink bundle. Shaping rate configuration on the constituent links is required to limit the jitter on the LFI queue. If you anticipate no delay-sensitive or jitter-sensitive traffic on the LFI queue, or if there is no LFI traffic at all, shaping rate configuration is optional.

For information about how to configure a shaping rate, see Junos OS Class of Service Configuration Guide for Security Devices.

Scheduling Priority

J Series devices support per-unit scheduling that allows you to configure scheduler maps on each MLPPP or MLFR multilink bundle. You can also configure scheduler maps on constituent links, but you must maintain the same relative priority on the constituent links and on the multilink bundle.

Table 78 shows an example of correct and incorrect relative priorities on a multilink bundle and its constituent link. In this example, you have assigned a high priority to LFI packets and a low priority to data packets on the multilink bundle. To maintain the relative priority on the constituent links, you can assign a high priority to the LFI packets and a medium-high priority to the data packets, but you cannot assign a medium-high priority to LFI packets and a high priority to data packets.