BAP, PPP Bandwidth Allocation Protocol

Protocol suite:	PPP.
Protocol type:	PPP link control protocol.
PPP protocol:	0xC02D.
SNMP MIBs:
Working groups:	pppext, Point-to-Point Protocol Extensions.
Links:

This protocol was designed to manage the dynamic bandwidth allocation of implementations supporting the MP, PPP Multi-link Protocol.

BAP can be used to manage the number of links in a multi-link bundle. BAP defines datagrams for adding and removing individual links in a multi-link bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multi-link connection.

RFC 2125, pages 1 - 3, 7 - 9:

This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP).

As PPP multilink implementations become increasingly common, there is a greater need for some conformity in how to manage bandwidth over such links. BACP and BAP provide a flexible yet robust way of managing bandwidth between 2 peers. BAP does this by defining Call- Control packets and a protocol that allows peers to co-ordinate the actual bandwidth allocation and de-allocation.

The LCP Configuration Option (23 for the Link Discriminator) is used to declare a unique discriminator for the link that the option is sent over. This option MUST be negotiated by LCP on every link. BAP uses the link discriminator to differentiate the various links in a multilink bundle. Each link in a multilink bundle MUST have a unique discriminator. The discriminator is independent for each peer, so each link may have 2 different LCP Link Discriminator values, one for each peer. When the Link Discriminator is sent in a BAP packet, the transmitter sends the Link Discriminator Option value received from its peer in the peer's LCP Configure Request packet.

BAP defines packets, parameters and negotiation procedures to allow two endpoints to negotiate gracefully adding and dropping links from a multilink bundle. An implementation can:

Request permission to add a Link to a bundle (Call Request).

Request that the peer add a link to a bundle via a callback (Callback Request).

Negotiate with the peer to drop a link from a bundle (this implies that the peer can refuse) (Link Drop Query Request).

BAP allows two peer implementations to manage the bandwidth available to the protocols using the multilink bundle by negotiating when to add and drop links (See Link Management).

All of the BAP Request and Indication packets require a Response packet in response before taking any action.

In order to resolve race conditions, an implementation MUST implement the BACP Favored-Peer Configuration Option.

Before any BAP packets may be communicated, PPP MUST reach the Network-Layer Protocol phase, and BACP MUST reach the opened state.

BAP header:

00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Type								Identifier								Length
Data :::

Type. 8 bits, Binary coded hexadecimal.
Specifies the BAP message.

Type	Description
01	Call-Request.
02	Call-Response.
03	Callback-Request.
04	Callback-Response.
05	Link-Drop-Query-Request.
06	Link-Drop-Query-Response.
07	Call-Status-Indication.
08	Call-Status-Response.

Identifier. 8 bits.
This field aids in matching Requests and Indications with Responses. Call-Status-Indication packets MUST use the same Identifier as was used by the original Call-Request or Callback-Request that was used to initiate the call. All other Request or Indication packets MUST use a unique Identifier for each new Request or Indication. All Response packets MUST use the same Identifier as the Identifier in the Request or Indication packet being responded to. When re-transmitting a request or indication, the Identifier MUST be the same as the Identifier used on the previous transmission of the request or indication.

Length. 16 bits.
Indicates the length of the packet including the Type, Identifier, Length and Options fields. Bytes outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception.

Data. Variable length.
This field will usually contain the list of zero or more BAP Options that the sender desires to transmit. The first byte of the Data field in a response datagram will contain the Response Code.

Response Code. 8 bits, binary coded.

Code	Description
00	Request-Ack.
01	Request-Nak.
02	Request-Rej.
03	Request-Full-Nak.

BAP Datagram Options. Variable length.
BAP Datagram Options are used in various BAP packets. The format of these options loosely follows the formatting conventions of LCP Configuration Options. When there are multiple BAP Options in one BAP packet, the options MAY be transmitted in any order.

00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15
Option								Length
Data :::

Option. 8 bits, binary coded hexadecimal.
Specifies the type of requested BAP Datagram Option.

Option	Length	Description
1	1	Link-Type.
2	1	Phone-Delta.
3	2	No-Phone-Number-Needed.
4	1	Reason.
5	4	Link-Discriminator.
6	4	Call-Status.

Length. 8 bits.
Indicates the length of this BAP Option including the Type, Length, and Option Data fields.

Data. Variable length.
Contains information specific to the BAP Option. The format and length of this field is determined by the Type and Length fields.

Glossary:

BOD, Bandwidth on demand.
(RFC 2125) BOD refers to the ability of a system to allocate and remove links in a multilink system to change the bandwidth of a multilink bundle. This may be done in response to changing line conditions and it also may be done in response to changing resource conditions. In either case, changing bandwidth dynamically during a multilink connection is referred to as BOD.

RFCs:

[RFC 2125] The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP).

Category: Standards Track.

Publications:

Obsolete RFCs: