Zusammenfassung

  • BACP löste gleichzeitige Anforderungen auf; BAP verlangte vor jeder Aktion eine Antwort; Call-Status meldete anschließend den ausgeführten Anruf und einen möglichen Wiederholungsversuch.
  • Request-Ack bestätigte einen gültigen, empfangenen Befehl, nicht eine funktionierende Leitung. Vollständige BAP-Datagramme mussten für ISDN-Terminaladapter unkomprimiert und unverschlüsselt bleiben.

Die historische Leistung von RFC 2125 liegt in einer unscheinbaren Verzögerung: Zwischen Zustimmung und Wirkung musste ein weiterer Beleg entstehen.

RFC 1990 hatte bereits die Rekonstruktion eines PPP-Multilink-Bundles beschrieben. RFC 2125 ergänzte BACP und BAP, um Mitglieder hinzuzufügen oder zu entfernen. Der RFC-Editor-Eintrag und das PPP-Register der IANA bewahren Status und Protokollwerte.

Das kleinere Magic-Number gewann nur den Wettlauf

Die obligatorische Option Favored-Peer ließ beide Seiten eine von null verschiedene vier Byte lange Magic-Number aushandeln. Bei gleichzeitigen gleichartigen Anforderungen wurde die kleinere Zahl bevorzugt; identische Werte mussten neu verhandelt werden.

Damit war eine Race Condition geordnet. Die Zahl authentifizierte keinen Betreiber, bewertete keine Auslastungsmessung und begründete keine weitergehende Autorität.

Ein Ack war noch kein Anruf

Vor einem selbst ausgelösten zusätzlichen Link stand Call-Request; sollte der Peer anrufen, galt Callback-Request. Jede Request und Indication brauchte vor der Aktion eine Response. Request-Ack bedeutete gültig und empfangen, Request-Nak derzeit unerwünscht, Request-Rej nicht implementiert, Request-Full-Nak erreichte Bandbreitengrenze.

Nach jedem Versuch folgte Call-Status-Indication. Bei einem Fehlschlag stand dort, ob erneut gewählt würde; jeder Retry verlangte eine weitere Meldung. Derselbe Identifier wie in der ursprünglichen Anfrage verband Erlaubnis und Ergebnis, ohne sie gleichzusetzen.

Die Evidenzleiter lautete daher: BACP geöffnet, Favored-Peer entschieden, Request bestätigt, Anruf beendet, Mitglied über LCP hinzugefügt oder entfernt, Multilink-Fragmente beobachtet, Anwendungsergebnis erreicht. Keine frühe Stufe bewies automatisch die späteren.

Überwachung durfte widersprechen

RFC 2125 schrieb keinen gemeinsamen Auslastungsalgorithmus vor. Bei einem aus Messwerten abgeleiteten Abbau musste Link-Drop-Query den Peer fragen. Dieser sollte anhand eigener Beobachtung antworten und durfte nicht nur Empfangsdaten betrachten. Solange eine überwachende Seite den Link benötigte, blieb er bestehen.

Eine lokale Ressourcenlage war anders. Brauchte das System Port oder B-Kanal für einen anderen Zweck, schickte es unmittelbar LCP Terminate-Request. Auch nach ausgeschöpften unbeantworteten Wiederholungen war erzwungener Abbau möglich. Kooperative Optimierung und lokale Ressourcenhoheit blieben getrennt.

Wiederholungen behielten denselben Identifier, damit ein verlorenes Response kein scheinbar neues Vorhaben erzeugte. BAP-Pakete sollten gegenüber Nutzdaten bevorzugt werden, weil gerade der Kapazitätsengpass ihre Übertragung erschweren konnte.

Sichtbare Steuerung als Kompatibilitätspreis

ISDN-Terminaladapter konnten Multilink für einen unwissenden Client steuern. Deshalb durfte das ganze BAP-Datagramm weder komprimiert noch verschlüsselt werden. Ausgehandelte Kompression einzelner PPP-Felder blieb erlaubt. Die Security Considerations erklärten lediglich, Sicherheitsfragen würden nicht behandelt.

BACP Open, Ack und positiver Call-Status beweisen somit weder Vertraulichkeit noch Identität, Einwilligung, stabile Gesamtbandbreite oder Anwendungszustellung.

Lu Hengs Texte über Running-Code Primacy, Minimum Initial Specification und Reality Layers dienen als offengelegte heutige Linse: Der gemeinsame Vertrag bleibt dünn, lokale Heuristik bleibt lokal, und symbolische Erlaubnis ersetzt keine ausgeführte Wirkung.

Quellen