Summary

  • RFC 2125 made bandwidth on demand a sequence of bounded decisions: settle simultaneous requests, acknowledge a valid proposal, attempt the call, report its status, change bundle membership and only then observe useful traffic.
  • Its narrow receipts prevented one peer’s permission from masquerading as a working link, but compatibility with intercepting ISDN terminal adapters required whole BAP datagrams to remain uncompressed and unencrypted.

The revealing message in RFC 2125 is not the request to add bandwidth. It is the later message that admits the request was not the bandwidth.

A peer sent a Call-Request before originating another link, or a Callback-Request when it wanted the other peer to call. The receiver had to answer. A Request-Ack meant the command was valid, received and acceptable at that moment. Only after an implementation tried to add the link did it send Call-Status-Indication, reporting whether the attempt succeeded and whether a failure would be retried.

Permission and execution were correlated by an identifier, but they remained different evidence.

First decide who wins the race

RFC 1990 had already defined a Multilink bundle: several PPP links could carry fragments of one logical packet stream. It deliberately left the policy for adding and removing those members outside its reconstruction rules. RFC 2125, published in March 1997, supplied BACP and BAP for that separate control problem. The RFC Editor record preserves its Standards Track status, while the IANA PPP registry records BACP as 0xc02b and BAP as 0xc02d.

Before BAP could act, BACP negotiated Favored-Peer. Each side supplied a non-zero four-octet Magic-Number. If both peers simultaneously sent the same class of add or drop request, the lower value was favored. Equal values were rejected and renegotiated.

This was a collision rule, not a theory of authority. The lower number did not authenticate the endpoint, measure congestion, prove the owner of a telephone line or show that its bandwidth heuristic was fair. It answered one small operational question: when both sides act at once, whose request proceeds.

An acknowledgement stopped short of the call

RFC 2125 required a response to every BAP Request and Indication before action. Its response vocabulary kept several reasons apart. Request-Ack accepted a valid command. Request-Nak meant not now. Request-Rej meant the command type was unsupported. Request-Full-Nak said the bundle had reached an available or configured maximum or minimum, so retry should wait until total bandwidth changed.

Acceptance could also return a Phone-Delta, allowing the peer to derive a callable number from one already known. That was coordination data, not a successful dial.

The later Call-Status-Indication closed the next stage. One indication was required for each call attempt. A failure could announce either no retry or retry; choosing retry created an obligation to send another indication for the next attempt. The indication reused the original call request’s identifier. A corresponding response acknowledged receipt of the status report. It did not alter the result being reported.

That chain made the historical distinction unusually visible:

  1. BACP open showed that bundle control was available.
  2. Favored-Peer selected a winner for a simultaneous operation.
  3. Request-Ack admitted the command.
  4. Call-Status described the completed call attempt.
  5. link establishment or LCP termination changed membership.
  6. observed Multilink fragments and application receipts showed whether capacity carried useful work.

No lower rung honestly proved every higher one.

Removing bandwidth exposed two kinds of need

RFC 2125 did not require both peers to run one common utilization algorithm. Each implementation could watch transmit traffic, both directions or neither. That freedom created a careful rule for utilization-driven removal: the would-be remover sent Link-Drop-Query-Request, and the peer answered from what it monitored. The link stayed up while either monitoring side still judged it necessary.

A resource condition was different. If a system needed a physical port or B-channel for another purpose, it used LCP Terminate-Request directly. It could also force termination after exhausting its supported retries while waiting for a Link-Drop response. The protocol therefore separated cooperative optimization from local resource custody. One asked whether both monitoring views permitted removal; the other exposed a local constraint that could no longer wait.

The teardown sequence aimed to avoid directional loss: after sending Terminate-Request, a peer should stop transmitting data while continuing to receive until Terminate-Ack. That prescription was valuable. It was not proof that every implementation, circuit or buffered packet completed losslessly.

Lost control packets kept their identity

Requests and indications started a timer. A timeout retransmitted the same message with the same identifier, allowing the receiver to recognize that a lost response had not created a new operation. Exceeding the implementation’s retry limit permitted recovery, including forced link removal. BAP packets were also meant to receive priority over ordinary data because the control traffic might be needed precisely when the bundle was constrained.

The mechanism supplied correlation and a recovery boundary, not exactly-once effects. An operator still needed the request, response, call status, membership event and traffic observation to reconstruct what occurred.

Interception won over confidentiality

The sharpest compatibility compromise sat in the datagram format. ISDN terminal adapters sometimes managed Multilink for clients that did not understand it. To let those adapters intercept control, RFC 2125 required whole BAP datagrams to remain uncompressed and unencrypted. Negotiated PPP address/control-field and protocol-field compression could still apply, but the BAP message itself had to stay visible.

The memo’s Security Considerations section said security issues were not discussed. Its receipts must therefore not be enlarged into claims of confidential control, authenticated organizational authority or user consent.

Lu Heng’s Running-Code Primacy offers a disclosed modern lens: the claim should be no larger than the state that running systems make observable. Minimum Initial Specification explains why BAP could standardize a thin exchange while leaving bandwidth heuristics local. Reality Layers sharpens the final boundary: a symbolic permission is not an executable result.

RFC 2125’s enduring lesson is not that bandwidth on demand always worked. It is that permission, attempt, membership and delivered capacity belonged in different records.

Sources