The Multilink PPP feature provides load balancing functionality over multiple WAN links while providing multivendor interoperability and support for packet fragmentation, proper sequencing, and load calculation on both inbound and outbound traffic. The Multilink PPP feature supports the fragmentation and packet sequencing specifications described in RFC 1990.

Multilink PPP allows packets to be fragmented and fragments to be sent at the same time over multiple point-to-point links to the same remote address. Multiple links come up in response to a defined dialer load threshold. The load can be calculated on inbound or outbound traffic, as required, for the traffic between specific sites. Multilink PPP provides bandwidth on demand and reduces transmission latency across WAN links.

Multilink PPP can work over synchronous and asynchronous serial type of single or multiple interfaces that have been configured to support both dial-on-demand rotary groups and PPP encapsulation.

Multilink PPP combines multiple physical links into a logical bundle called a Multilink PPP bundle. A Multilink PPP bundle is a single, virtual interface that connects to the peer system. Having a single interface (Multilink PPP bundle interface) provides a single point to apply hierarchical queueing, shaping, and policing to traffic flows. Individual links in a bundle do not perform any hierarchical queueing. None of the links have any knowledge about the traffic on parallel links. Hierarchical queueing and quality of service (QoS) cannot be applied uniformly to the entire aggregate traffic between a system and its peer system. A single, virtual interface also simplifies the task of monitoring traffic to the peer system (for example, all traffic statistics run on one interface).

Figure 1. Multilink PPP Bundle

Multilink PPP works with fully functional PPP interfaces. A Multilink PPP bundle can have multiple links connecting peer devices. These links can be serial links or broadband links (Ethernet or ATM). As long as each link behaves like a standard serial interface, mixed links work properly in a bundle.

To designate a link to a specified bundle, use the ppp multilink group command for configuring the link. This command restricts the link to join only the specified bundle. When a link negotiates to join a Multilink PPP bundle, the link must provide proper identification that is associated with the Multilink PPP bundle. If the negotiation is successful, the link is assigned to the requested Multilink PPP bundle. If the link provides identification that coincides with the identification associated with a different Multilink PPP bundle in the system or if the link fails to match the identity of a Multilink PPP bundle that is already active on the multilink group interface, the connection terminates.

A link joins a Multilink PPP bundle only if it negotiates to use the bundle when a connection is established and the identification information exchanged matches that of an existing bundle.

When you configure the ppp multilink group command on a link, the command applies the following restrictions on the link:

• The link is not allowed to join any bundle other than the indicated group interface.

• The PPP session must be terminated if the peer device attempts to join a different bundle.

A link joins a bundle only when the identification keys for that link match the identification keys for an existing bundle. (See the “Factors that Govern a Link Joining a Bundle” section.) Merely configuring the ppp multilink group command on a link does not allow the link to join the corresponding bundle; the link must have matching identification keys to join the corresponding bundle. Identification keys are always used as the determining factor for matching links with bundles.

Because the ppp multilink group command merely places a restriction on a link, any Multilink-PPP-enabled link that is not assigned to a particular multilink group can join the dedicated bundle interface if the Multilink-PPP-enabled link provides correct identification keys for that dedicated bundle. Removing the ppp multilink group command from an active link that is currently a member of a multilink group does not make that link leave the bundle because the link is still a valid member of the multilink group. However, the link is no longer restricted to this one bundle.

The table below lists the different configurations of Multilink PPP and the number of links supported by each one of them.

The main benefit of Multilink PPP is the support for link fragmentation and interleaving (LFI). LFI minimizes packet latency on delay-sensitive voice, video, and interactive applications when data is sent over low-speed interfaces.

With LFI, the latency of delay-sensitive traffic is minimized because Multilink PPP breaks the nonpriority or nonlatency-sensitive traffic into smaller fragments. The delay-sensitive traffic is then PPP encapsulated and interleaved with nonpriority Multilink PPP fragments or packets. At the receiver, Multilink PPP fragments or packets are reordered and reassembled while the PPP-encapsulated packets are received and immediately forwarded. (Multilink PPP is bypassed; no reordering or reassembly is performed.)

Multilink PPP bundle interfaces can be one of the following types:

• Multilink group interfaces

• Virtual access interfaces (VAIs)

Both these types of interfaces provide the same level of PPP and multilink functionality after a bundle is established. All PPP and multilink-related features run identically on a bundle.

A link joins a bundle when identification keys for that link match identification keys for an existing bundle.

The following two keys define the identity of a remote system: the PPP username and Multilink PPP endpoint discriminator. PPP authentication mechanisms (for example, password authentication protocol [PAP] or Challenge-Handshake Authentication Protocol [CHAP]) learn the PPP username. The endpoint discriminator is an option negotiated by the Link Control Protocol (LCP). Therefore, a bundle consists of links that have the same PPP usernames and endpoint discriminators.

A link that does not provide a PPP username or an endpoint discriminator is an anonymous link. Multilink PPP collects all anonymous links into a single bundle that is referred to as the anonymous bundle or the default bundle. Typically, there can be only one anonymous bundle. Any anonymous links that negotiate Multilink PPP join (or create) the anonymous bundle.

When you use multilink group interfaces, more than one anonymous bundle is allowed. When you preassign a link to a Multilink PPP bundle by using the ppp multilink group command and the link is anonymous, the link joins the bundle interface to which it is assigned if the interface is not already active and is associated with an anonymous user.

Multilink PPP determines the bundle a link joins by following these steps:

1. When a PPP session is initiated, Multilink PPP creates a bundle name identifier for the link.

2. Multilink PPP then searches for a bundle with the same bundle name identifier. The following scenarios are possible:

   • If a bundle with the same identifier exists, the link joins that bundle.
   • If a bundle with the same identifier does not exist, Multilink PPP creates a new bundle with the same identifier as the link, and the link becomes the first link to join the bundle.

The table below describes commands and associated algorithms that are used to generate a bundle name. In the table, “username” typically means an authenticated username; however, an alternate name can be used instead. The alternate name is usually an expanded version of the username (for example, virtual private dialup network [VPDN] tunnels might include the network access server name) or a name derived from other sources.

When devices running Cisco software begin negotiating a large number of broadband sessions, a peer device may be constrained by its processing capabilities. This limitation may cause an excessive number of timeouts (because the peer device may be renegotiating hundreds of sessions due to timeouts) while trying to negotiate PPP parameters. Cisco software provides an internal mechanism to control the rate of session establishment (to prevent excessive timeouts) for broadband sessions by using the Call Admission Control (CAC) functionality. CAC can be configured to control the number of sessions that can be negotiated in a given period of time. Controlling the rate of session establishment is also known as throttling. The mechanism of throttling helps to prevent unnecessary negotiation timeouts with slower devices. The following commands show how to configure the CAC functionality:

Device(config)# call admission new-model
Device(config)# call admission limit 500
Device(config)# call admission cpu-limit 80
Device(config)# call admission pppoe 10 1
Device(config)# call admission pppoa 10 1
Device(config)# call admission vpdn 10 1

• The call admission new-model command enables the new-model-based CAC, which regulates session establishment based on both CPU utilization and incoming session requests.

• The call admission limit command (also referred to as charge limit) sets the maximum total concurrent charge threshold. If this threshold is exceeded, any additional session requests are rejected.

• The call admission cpu-limit command specifies the CPU utilization threshold, as a percentage. If this threshold is exceeded, new sessions are rejected. CAC uses the 5-second CPU utilization of IOS daemon (IOSd) for this calculation.

• Session requests are rejected if either the cpu-limit (80% in the example above) or the charge limit (1000 in the example above) is exceeded.

• The call admission pppoe 10 1 command specifies the charge values for a single PPP over Ethernet (PPPoE) session. In the above example, the session charge is 10, and the lifetime is 1 second. The charge values are set per call type (PPP over ATM [PPPoA], PPPoE, or virtual private dialup network [VPDN]). The extended lifetime is calculated as the sum of two lifetime values. For the above example, the extended lifetime is 1 + 1 = 2.

• You can calculate calls per second (CPS) as follows:

  CPS = Charge Limit / (Session Charge * Extended Lifetime)

  For the above example, CPS = 500 / (10 * 2) = 25

For a more detailed explanation, refer to the “Broadband Scalability and Performance” module in the Cisco ASR 1000 Series Aggregation Services Routers Software Configuration Guide.

Multilink PPP encapsulation adds six extra bytes (four header and two checksum) to each outbound packet. These overhead bytes reduce the effective bandwidth of a connection; therefore, the throughput for a Multilink PPP bundle is slightly less than that for an equivalent bandwidth connection that is not using Multilink PPP. If the average packet size is large, the extra Multilink PPP overhead is not readily apparent. However, if the average packet size is small, the extra overhead becomes more noticeable.

Multilink PPP fragmentation adds additional overhead to a packet. Each fragment contains six bytes of Multilink PPP header plus a link encapsulation header. The size of the link encapsulation header varies based on the topology of a network. The Layer 2 headers for Ethernet, ATM, and serial interfaces add different number of bytes to a packet.

The Multilink PPP over Serial Interfaces feature enables you to bundle T1 interfaces into a single, logical connection called a Multilink PPP bundle. (See the “Multilink PPP Bundles” section.) The Multilink PPP over Serial Interfaces feature also provides the following functionalities:

• Load balancing—Multilink PPP provides bandwidth on demand and uses load balancing across all member links (up to ten) to transmit packets and packet fragments. Multilink PPP mechanisms calculate the load on inbound or outbound traffic between specific sites. Because Multilink PPP splits packets and fragments across all member links during transmission, Multilink PPP reduces transmission latency across WAN links. Ideally, all member links in a bundle would be of the same bandwidth (for example, T1s). Load balancing and fragmentation and interleaving also allow for a mix of unequal cost member links for situations where a small increment in the bundle bandwidth is required.

• Increased redundancy—Multilink PPP allows traffic to flow over remaining member links when a port fails. When you configure a Multilink PPP bundle that consists of T1 lines from more than one line card and if one line card stops operating, part of the bundle on other line cards continues to operate.

• Link fragmentation and interleaving (LFI)—The Multilink PPP fragmenting mechanism fragments large, nonreal-time packets and sends fragments at the same time over multiple point-to-point links to the same remote address. Smaller, real-time packets remain intact. The Multilink PPP interleaving mechanism sends real-time packets between fragments of nonreal-time packets, thus reducing real-time packet delay.

The figure below shows a Multilink PPP bundle that consists of T1 interfaces from three T3 interfaces.

Figure 2. Multilink PPP Bundle for Multilink PPP over Serial Interfaces

The Multilink PPP over Broadband feature allows you to combine Multilink PPP over Ethernet (MLPoE) and Multilink PPP over ATM (MLPoA) links into a multilink bundle. Functionally, Multilink PPP over broadband is the same as Multilink PPP over serial interfaces, with the exception of interface management. In Multilink PPP over serial interfaces, interfaces are statically defined in the configuration database, that is, in the startup configuration. In Multilink PPP over broadband, link interfaces are created dynamically by Cisco software while negotiating a PPP session.

The Multilink PPP feature operates in the following two deployment schemes: “PTA mode” and “LNS mode.” In the PPP termination and aggregation (PTA) mode, a device acts as the PTA device and terminates Multilink PPP sessions coming from the customer premises equipment (CPE). In the Layer 2 Tunneling Protocol (L2TP) Network Server (LNS) mode, a device terminates Multilink PPP sessions (carried in a Layer 2 tunnel that originates on a L2TP Access Concentrator [LAC] device) coming from the CPE device.

Note	Cisco software allows a device to function as a LAC switch. Therefore, in the LNS mode, Cisco software can run on both LAC and LNS devices. A Cisco device cannot act as a CPE device.

Cisco software can terminate Multilink PPP over ATM (MLPoA) ATM adaptation layer 5 (AAL5) multiplexer (MUX) or AAL5 Subnetwork Access Protocol (SNAP), Multilink PPP over Ethernet (MLPoE), Multilink PPP over Ethernet over ATM (MLPoEoA) AAL5 SNAP, Multilink PPP over Ethernet over Queue-in-Queue (MLPoEoQinQ), or Multilink PPP over Ethernet over VLAN (MLPoEoVLAN) sessions acting as the PTA node. In the LNS mode, Cisco software can terminate Multilink PPP over LNS (MLPoLNS) sessions by using Ethernet (Gigabit Ethernet or 10 Gigabit Ethernet) and ATM (AAL5 MUX and AAL5 SNAP) as the LAC-to-LNS connection to the LAC device. Cisco software also provides support to act as a LAC device to switch broadband Multilink PPP sessions between a CPE or Digital Subscriber Line Access Multiplexer (DSLAM) and an LNS device.