rfc-2125

The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP)

C. Richards, K. Smith
date1997-03 streamIETF areaint wgpppext statusPROPOSED STANDARD pages24 canonicalhttps://www.rfc-editor.org/rfc/rfc2125 doi10.17487/RFC2125
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). [STANDARDS-TRACK]

Extracted elements (26)

design-rationale §5.2

BAP's negotiation approach makes it unnecessary to define a common bandwidth-on-demand algorithm. Either peer may use any BOD heuristic it chooses, and the Link-Drop-Query mechanism ensures a link stays up as long as either peer deems it necessary.

design-rationale §6.2

Phone numbers are conveyed as a delta (unique rightmost digits) from a previously known base number rather than as a full number to avoid the complexity of determining which dialing prefixes are required for a given number/country-code combination.

design-rationale §5.4

Race conditions arise when both peers send a Call-Request, Callback-Request, or Link-Drop-Query-Request simultaneously. The Favored-Peer Magic-Number mechanism resolves these deterministically without requiring additional round trips: the peer with the lower Magic-Number is favored.

interoperability-note §6.3

The No-Phone-Number-Needed option (type 0x03, Length=2) in a Call-Request signals that the caller already has the peer's phone number; the responder MUST NOT include a Phone-Delta option in the Call-Response. This may be used for security or configuration reasons.

normative-requirement §5.5.6 MUST NOT

A Link-Drop-Query-Response with Response Code Request-Rej MUST NOT be transmitted; the Link-Drop-Query-Request datagram and the ability to respond to it MUST be supported by every implementation.

normative-requirement §5.5.7 MUST

After attempting to add a link as the result of a Call-Request or Callback-Request, an implementation MUST send a Call-Status-Indication to report success or failure. If the Action octet is Retry, a subsequent Call-Status-Indication MUST follow each retry attempt.

normative-requirement §5.1 MUST

After receipt of a Link-Drop-Query-Response with Response Code Request-Ack, the transmitter of the Link-Drop-Query-Request MUST initiate link teardown by sending an LCP Terminate-Request on the designated link.

normative-requirement §5.3 MUST

An implementation MUST set a retransmit timer when sending any BAP Request or Indication packet and MUST retransmit with the same Identifier on expiry. BAP packets SHOULD be given priority over other data packets to ensure prompt link addition and removal.

normative-requirement §5.1 MUST

An implementation receiving a Call-Request or Callback-Request MUST respond with the corresponding Response packet containing a valid Response Code.

normative-requirement §3 MUST NOT

BACP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase; packets received before this phase is reached should be silently discarded.

normative-requirement §5.5 MUST NOT

BAP datagrams MUST NOT be compressed or encrypted because ISDN Terminal Adapters may need to intercept BAP datagrams to control the multilink connection. Address-and-Control-Field-Compression and Protocol-Field-Compression are still permitted if negotiated.

normative-requirement §5.5 MUST

Call-Status-Indication packets MUST reuse the Identifier from the original Call-Request or Callback-Request. All other Requests/Indications MUST use a unique Identifier per new request. Response packets MUST echo the Identifier from the corresponding Request/Indication.

normative-requirement §2 MUST

LCP MUST be implemented as defined in RFC 1661, and LCP MUST be in the Network-Layer Protocol phase before BACP can be negotiated.

normative-requirement §4.1 MUST

The Favored-Peer Configuration Option MUST be implemented. A Magic-Number of zero is illegal and MUST always be Nak'd. If it is unclear which peer initiated the connection (e.g., on a leased line), a random number MUST be used.

normative-requirement §2.1 MUST

The Link Discriminator LCP Configuration Option MUST be negotiated by LCP on every link. Each link in a multilink bundle MUST have a unique discriminator assigned by the local endpoint.

normative-requirement §5.2 MUST NOT

When responding to a Link-Drop-Query-Request, an implementation MUST NOT base its response solely on its receive data heuristics; it should consider bidirectional traffic monitoring.

protocol-element §3

BACP (PPP protocol type 0xC02B) operates identically to LCP except it uses only Codes 1–7 (Configure-Request through Code-Reject) and has its own Configuration Options. BACP is negotiated once per multilink bundle and applies to all links in the bundle.

protocol-element §5.5

BAP defines 8 datagram types carried in PPP frames with Protocol type 0xC02D: Call-Request (0x01), Call-Response (0x02), Callback-Request (0x03), Callback-Response (0x04), Link-Drop-Query-Request (0x05), Link-Drop-Query-Response (0x06), Call-Status-Indication (0x07), Call-Status-Response (0x08). All MUST be supported by any implementation.

protocol-element §6.6

The Call-Status BAP option (type 0x06, Length=4) contains a 1-octet Status field (0=success; non-zero failure, using Q.931 cause codes where applicable; 255=non-specific failure) and a 1-octet Action field (0=no retry, 1=retry). MUST be included in Call-Status-Indication packets.

protocol-element §4.1

The Favored-Peer BACP Configuration Option (type 1) negotiates a 4-octet magic number used to determine which peer is favored when a race condition occurs; the peer transmitting the lower Magic-Number value wins.

protocol-element §6.1

The Link-Type BAP option (type 0x01, 5 octets) contains a 2-octet Link Speed field in kbps and a 1-octet bitmask for link type: bit 0=ISDN, bit 1=X.25, bit 2=analog, bit 3=switched digital (non-ISDN), bit 4=ISDN data over voice. It MUST appear in Call-Request and Callback-Request packets.

protocol-element §6.2

The Phone-Delta BAP option (type 0x02) carries calling information as a delta from a previously known number via sub-options: Unique-Digits (1 octet count of differing rightmost digits), Subscriber-Number (ASCII string), and optional Phone-Number-Sub-Address. It MUST appear in Callback-Request and in Call-Response packets with Request-Ack unless No-Phone-Number was sent.

security-consideration §Security Considerations

RFC 2125 explicitly states that security issues are not discussed in this memo. BAP/BACP define no authentication, integrity protection, or confidentiality for bandwidth control messages, leaving them vulnerable to spoofing on shared media.

security

wire-format §5.5

BAP Request/Indication packets contain: Type (1 octet), Identifier (1 octet), Length (2 octets), Data. BAP Response packets insert a Response Code octet (0x00=Request-Ack, 0x01=Request-Nak, 0x02=Request-Rej, 0x03=Request-Full-Nak) between Length and Data.

wire-format §4.1

The Favored-Peer BACP option has Type=1, Length=6, and a 4-octet Magic-Number field. If equal Magic-Numbers are received, a Configure-Nak MUST be sent with a different value.

wire-format §2.1

The Link Discriminator LCP option (Type=23) has Length=4 and a 2-octet Link Discriminator field that uniquely identifies a link within a multilink bundle for a given endpoint.