PPP and other data-link–layer protocols, such as Frame Relay, establish a single point-to-point connection, which may not provide sufficient bandwidth to meet a business’ requirements. Link-aggregation protocols address this limitation.
Theoretically, link aggregation is a simple idea: effectively double your available bandwidth by using two physical cables to connect your endpoints instead of only one, triple your bandwidth by using three cables, quadruple your bandwidth by using four cables, and so on. For example, you could aggregate two 1.544-Mbps T1 connections into a virtual single network connection with an underlying bandwidth of 3.088 Mbps.
However, to take advantage of multiple physical cables, data-link–layer protocols must be modified to fragment frames into smaller frames that can be passed simultaneously over separate cables and then reassembled by the receiving peer.
Link-aggregation protocols, including Multilink PPP (MP) and Multilink Frame Relay (MFR), do exactly that.
The following sections describe MP, as well as two protocols that can be used with MP: Bandwidth Allocation Protocol (BAP) and Bandwidth Allocation Control Protocol (BACP).
Multilink PPP
As its name suggests, MP is an extension to PPP. There are only two differences between regular PPP and MP:
MP introduces three additional configuration options for LCP.
An MP header is added to the information field in the PPP frame format.
This section discusses the additional LCP configuration options.
Maximum Receive Reconstructed Unit
The Maximum Receive Reconstructed Unit (MRRU) configuration option provides two important functions:
The inclusion of the MRRU in an LCP configure-request frame indicates that the sending peer wants to use MP. If the receiving peer acknowledges the option, it must assume that all of the frames received on different cables from the same peer should be processed as part of the same point-to-point link.
The MRRU is required if a peer wants to use MP.
The MRRU replaces the MRU. The MRU specifies the size of the frame that can be sent over a link; the MRRU specifies the frame size once all fragments
2 – 24 HP Restricted Rev. 5.21
Short Sequence Number Header Format
The sequence number assigns an order to frame fragments so they can be properly reassembled. The MP header can have a long sequence number or a short one.
A short sequence number is 12-bits and enables a frame to be split into a little less than 5,000 fragments. The 24-bit long sequence number provides enough bits to create more than 16 million fragments. Unless you are bundling a large number of cables together, the short sequence number is probably sufficient. The long
sequence number is the default, so if a peer wants to use the short number, it must request this option.
Endpoint Discriminator Options
When using MP, the receiving peer gets frame fragments from different cables.
Because this is the case, the receiving peer must be able to distinguish between multiple sending peers. The receiving peer can distinguish between sending peers in one of three methods:
Authentication
Endpoint discriminator
Manual configuration Authentication
Using the normal PPP authentication option enables one peer to recognize fragments from the same authenticated peer.
Endpoint Discriminator
On links where authentication is not required, the endpoint discriminator option can be used instead. The endpoint discriminator enables a peer to distinguish frames from sending peers based on one of the following:
A locally assigned network address
An IP address
A MAC address
A PPP magic number
A telephone number
Authentication and an endpoint discriminator can also be used together to provide a more secure method of distinguishing between peers.
Manual Configuration
In a situation where a dedicated bundle is set up between endpoints, the links can be manually configured to accept all frames from the bundle as if they are coming from the same peer. (A bundle is a group of aggregated links.)
Bandwidth Allocation Protocol
Bandwidth Allocation Protocol (BAP) is a link management protocol that can be used with MP to improve the management of multiple links. BAP configures, maintains, or terminates individual links in a bundle.
MP can be used without BAP, but when using MP alone, peers do not coordinate the adding and dropping of individual links. Like PPP, MP uses LCP to set up the initial link and to terminate the final one. Without BAP, however, peers can add or drop individual links indiscriminately. If a peer tries to send frames over a link that another peer has dropped, those frames are dropped.
Using BAP requires adding another configuration option to LCP—the
link-discriminator option. Negotiation of this option is required. It allows each link in a bundle to be numbered so that BAP can keep track of the individual links.
Keep in mind that BAP doesn’t replace LCP. LCP frames must still be used to configure the first link during the link configuration phase. (This includes
configuring MRRU and other options added by MP, the link discriminator option required by BAP, and the authentication and other LCP options available to basic PPP.)
2 – 26 HP Restricted Rev. 5.21
When BAP is being used, peers must exchange the following frames:
LCP frames that contain both the MRRU configuration option and a link discriminator option
BACP frames, to configure options for BAP
BAP frames, to configure the multiple links being used
NCP frames, for the appropriate layer-3 protocol
MP frames
BACP is explained in a later section.
Bandwidth Allocation Protocol Frames
BAP configurations are required in some types of frames but are optional in others. To understand when configuration options are required, you must understand BAP frame types.
Request frames are described here. Each BAP request frame has a corresponding response frame, as shown above.
Link Configuration Frames
A peer sends a call-request frame to request that a new link be added. A peer can also send a callback-request, which requests that the other peer add the link by
“calling back” on that link.
Link Maintenance Frames
Every time a link is added using either a request or a callback-request, a call-status-indication frame must be sent to verify whether or not the new link was successfully added.
2 – 28 HP Restricted Rev. 5.21
Link Termination Frames
If a peer determines that a link in a bundle is no longer needed, it can send a link-drop-query-request. Unlike LCP terminate-requests, which must always be acknowledged, requests can be refused. If a link-drop-query-request is acceptable, the peer sends an LCP frame to terminate that particular link.
BAP Configuration Options
The table above summarizes which BAP configuration options are required and which are optional in different types of BAP frames.
Link-Type Option
The link-type option specifies the speed and the type of link. Peers are required to include the link-type option in call-request and callback-request frames. In call- or callback-response frames, peers are allowed (but not required) to include the link-type information.
Phone-Delta Option
The phone-delta option provides either an actual phone number or some other unique identifier for the port to which a link is connected. Peers must include this number in callback-request and call-response frames and are allowed to use this number in a call-status-indication frame.
2 – 30 HP Restricted Rev. 5.21
No-Phone-Number Option
The no-phone-number option informs the receiving peer that the sending peer already has its phone number. A call-request frame can include the no-phone-number option. If this option is included in the call-request frame, peers must not include the phone-delta option in the call-response frame.
Link-Discriminator Option
The link-discriminator option designates which link the peer wants to drop and refers to the link discriminator number that was set up by the LCP. This option is required in link-drop-query-request frames.
Call-Status Option
The call-status option is used only in call-status-indication frames. A value of 0 indicates that a call was successful. Other values can be assigned to indicate why a call failed. The call-status option also indicates whether or not a peer should retry adding a link.
Reason Option
The reason option contains an ASCII text string that describes the reason for a request or response. Peers can include the reason option in any BAP configuration frame.
Bandwidth Allocation Control Protocol
BACP is an NCP that manages configuration options for BAP. Before peers can exchange BAP frames, they must exchange BACP frames to negotiate which peer will be favored in the event of a race. That is, when peers attempt to transmit BAP requests simultaneously, one of the peer’s requests must be favored. The favored peer’s BAP request frame will be used.
BACP accomplishes this purpose through the use of configure-request frames that contain the favored-peer configuration option. Each peer is assigned a magic number. The peer with the lower number becomes the favored peer. (To review magic numbers, refer back to the “Link Control Protocol Configuration Options:
section in this module.)
2 – 32 HP Restricted Rev. 5.21