PPP Multilink and Channel Aggregation

Shivaź devices provide support for high-performance channel aggregation using the industry-standard PPP Multilink Protocol (MLP) (RFC 1990). The PPP Multilink Protocol is a standardized extension of the PPP (Point-to-Point Protocol) standard.

Channel aggregation allows dial-in and LAN-to-LAN connections to bundle multiple channels together to form a single, wider and faster connection, providing greater throughput and less delay.

For more information, see the following topics:

Features

LAN-to-LAN Connections

Dial-In Connections

Packet Fragmentation

Compression

Multilink Multi-Node MMP

BAP and BACP

Features

PPP Multilink has the following functions:

Combination of channels into a multilink bundle

Packet sequencing and ordering

Packet fragmentation

Guarantee of compatibility with other vendors' equipment as it is an open standard

LAN-to-LAN Connections

LAN-to-LAN connections have no limit to the number of links in a multilink bundle other than the maximum call limit. The lines in a LAN-to-LAN multilink bundle may be the same or different types and speeds, including asynchronous, synchronous, modem, or Integrated Services Digital Network (ISDN). However, if you have an excessively large numbers of links on a multilink bundle, the software overhead will reduce efficiency. Four to eight links on a bundle is a reasonable maximum bundle size.

Dial-In Connections

The Shiva dial-in client (ShivaRemote) only supports MLP for ISDN calls, and is limited to two bearer (B)-channels of one Basic Rate Interface (BRI) line. Dial-in users can initiate direct or fixed or roaming dial-back multilink sessions.

Packet Fragmentation

By default, a Shiva device's management tools are configured to divide packets sent over MLP connections into fragments that travel on separate links of the bundle. The Shiva device receiving the transmission reassembles the fragments into one packet. Because of the system overhead required for fragmentation, very small packets are not fragmented (the size threshold for fragmentation is configurable). Fragmentation decreases data transit time (latency) but increases CPU utilization. It can also increase the impact of packet loss or damage in transit.
There is a fixed overhead for fragmentation. The default fragment packets threshold of 30 bytes is about as small as is practical. Higher values (or disabling fragmentation entirely) can reduce the CPU overhead of fragmentation, since a smaller proportion of packets are fragmented. To work properly, fragmentation requires a reassembly protocol (such as the Multilink part of PPP) to keep the fragments and packets in order.
Fragmented data packets can pass each other in transit, since not all links in the connection are necessarily the same speed. Some devices may not be able to perform fragment reassembly correctly due to problems in their code. By disabling fragmentation of outgoing packets on the Shiva device, you can successfully communicate with devices that are not able to reassemble data fragments correctly.

Compression With Multilink

When PPP compression (as defined in the PPP Compression Control Protocol) is in use, ShivOS only supports this protocol above the Multilink protocol: that is, packets sent on PPP Multilink are compressed first and then passed to Multilink for fragmentation across the links in the bundle.

The PPP Compression Control Protocol also defines the use of compression under PPP Multilink, where the compression is done individually on each link after Multilink fragmentation. Individual link compression is not supported by ShivOS.

Multilink Multi-Node MMP

If your site has several network access switches (NAS), a typical setup is to assign a hunt group (accessible from a single phone number) to service all of the lines that service all the NASs. Hunt groups typically assign calls using a round-robin method, which results in successive calls being routed to different lines at the site, and frequently to different NASs.

This poses a problem for Multilink PPP (MLP) calls, because all links in an MLP bundle must terminate at the same NAS for the MLP to be successful. Shiva uses the Multilink Multi-Node PPP (MMP) protocol to allow the NAS receiving an MLP dial-in call to discover which of the other NASs has control of the original MLP call and to transfer the second call to the first NAS.

Note: All NASs must be attached to the same LAN.

BAP and BACP

Bandwidth Allocation Protocol (BAP) and Bandwidth Allocation Control Protocol (BACP) provide a standard mechanism of dynamically managing the links on a multilink PPP connection. Typically, BAP requests are sent from an ISDN dial-in peer to a Shiva device in order to obtain the phone number that should be called to establish the second link in a Multilink Protocol (MP) bundle. BACP is a PPP control protocol that enables the use of BAP on a multilink bundle.

BAP defines packets, parameters, and negotiation procedures to allow two end points to negotiate gracefully by adding and dropping links from a multilink bundle. This may include sending the peer a phone number to use to bring up additional links. Note: BACP is negotiated by default on a multilink-enabled interface. BACP is negotiated once for each multilink bundle, not on each individual link in a bundle.