Zusammenfassung

  • Die Called-Party-Kennung konnte auf einer gemeinsam genutzten ISDN-Anlage PPP auswählen, erteilte dem Endpunkt aber weder Betriebsfreigabe noch Gewissheit über den Anrufer.
  • Ohne administratives LCP-Open musste der Ruf abgewiesen werden; erst annehmen und dann schließen oder Pakete ignorieren war ausdrücklich verboten.
  • Codierung, Framing, unteres Up, LCP Opened, Authentisierung, NCP und Anwendungsergebnis blieben nach der Annahme eigenständige Nachweise.

Verfügbarer Träger, geschlossener Dienst

Die im Mai 1994 veröffentlichte RFC 1618 beschrieb PPP über geschaltete ISDN-Verbindungen. Sie erwartete ausdrücklich kein monolithisches weltweites ISDN. Vermittlungen, Teilnehmerregeln und Endgeräte unterschieden sich; gemeinsame Voreinstellungen sollten Interoperabilität ermöglichen, nicht diese Unterschiede leugnen.

Ein B-Kanal war ein Punkt-zu-Punkt-Träger, eine PRI konnte viele davon gleichzeitig anbieten. Ein D-Kanal konnte bei passendem Framing ebenfalls PPP tragen, war aber knapp und oft auf die lokale Vermittlung begrenzt. Diese Eigenschaften beschrieben Transport, nicht die lokale Bereitschaft, einen Dienst anzunehmen.

Mehrere Rufnummern konnten auf derselben physischen Anlage enden. Jede wurde administrativ einem Dienst zugeordnet; die lokale Vermittlung lieferte die Kennung der angerufenen Partei. Damit ließ sich die gewählte Tür bestimmen. Wer davor stand und ob sie gerade geöffnet werden durfte, sagte die Kennung nicht.

Das reichere Signal war nicht durchgängig

Das LLC Information Element schien Codierung oder Framing außerhalb des Datenpfads ankündigen zu können. Laut der in RFC 1618 festgehaltenen Erfahrung wurde es aber nicht zuverlässig Ende-zu-Ende übertragen: kompatible Vermittlungen waren zu wenig verbreitet und die Abonnementregeln der Anbieter zu verschieden.

Für PPP war kein LLC-IE-Wert vergeben. Andere Werte waren kein gültiger PPP-Hinweis und durften ignoriert werden. Vor allem durfte das Feld nicht die Wahl von Framing oder Codierung bestimmen.

Gemeinsame Semantik braucht eine vollständige Kette von Stellen, die sie bewahren. Ein Feld, das ein Vermittler aufgrund eigener Regeln auslässt, bleibt eine Behauptung am Ursprung. RFC 1618 ersetzte diese Lücke nicht durch ein mächtigeres Etikett, sondern durch engere lokale Evidenz und eine lokale Entscheidung.

Open, Up und Opened

Wenn die Called-Party-Kennung verwendet wurde — oder künftig ein PPP-spezifischer LLC-Wert einträfe —, musste der Empfänger ohne administratives Open den Ruf ablehnen. Er durfte den Kanal nicht annehmen und anschließend schließen oder schweigend Pakete verwerfen.

RFC 1548 und RFC 1661 definieren Open als Erlaubnis eines Netzwerkadministrators, Mensch oder Programm. Up meldet die Verfügbarkeit der unteren Schicht. Opened ist der spätere Zustand des LCP-Automaten nach dem Konfigurationsaustausch.

Die Vermittlung stellt den Träger bereit, lokale Verwaltung erlaubt den Dienst, beide Endpunkte handeln Parameter aus. Kein früherer Schritt darf für den nächsten sprechen. Eine einzige Anzeige „offen“ würde genau die Zuständigkeit beseitigen, die bei Fehlern benötigt wird.

Frühe Ablehnung schonte auch den geschalteten Kanal. Spätes Schweigen verwandelte eine bewusste lokale Sperre in ein mehrdeutiges Symptom: falsches Framing, fehlender Peer oder Netzverlust? Die Ablehnung an der Eintrittsstelle hielt Ursache und Entscheider zusammen.

Erkennung als begrenzter Versuch

Nach der Freigabe blieb die Bitdarstellung offen. Aus Sicht von PPP war der ISDN-Kanal eine synchrone Vollduplexverbindung; Codierung und Scrambling gehörten jedoch zur DTE/DCE-Ausrüstung. RFC 1618 empfahl NRZ am T-Punkt als Standard, NRZI als konfigurierte Alternative und verwarf das ältere invertierte NRZ.

Automatische Erkennung bedeutete Moduswechsel. Pro Modus sollten zwei LCP Configure-Requests gesendet werden, bevor der nächste erprobt wurde. Insgesamt mussten die Versuche in weniger als 59 Sekunden enden, vorzugsweise innerhalb der üblichen 30. Schweigen bewies keine Ursache; es berechtigte nur zum nächsten Versuch innerhalb des Budgets.

Ohne Vorkonfiguration begann der B-Kanal mit bitsynchronem HDLC. Oktettsynchrones HDLC setzte verfügbare Oktettgrenzen und Konfiguration voraus. Mehrere Framings gleichzeitig waren nicht vorgesehen. RFC 1549 verband NRZI zudem mit schwächeren Eigenschaften des 16-Bit-FCS und empfahl die Aushandlung von 32 Bit. Ein Trägersignal bestätigte keine gemeinsame Fehlererkennung.

V.120 erklärte das Dokument für diesen Einsatz als veraltet, weil sein Framing schwer von Frame Relay zu unterscheiden sein konnte; stattdessen empfahl es, PPP in Frame Relay zu übertragen. Das war eine begrenzte Interoperabilitätswahl, kein Beleg für das Verfahren eines bestimmten Anrufs.

Eine Warteschlange konnte wählen lernen

Die MTU der Netzwerkschicht sollte höchstens 1500 betragen, außer der Peer hatte ausdrücklich eine MRU von mindestens 2048 ausgehandelt. Der Neustarttimer sollte außerdem exponentiell von 250 Millisekunden bis drei Sekunden zurückweichen. Persistentes Wählen brauchte Grenzen. Nach gescheitertem Linkaufbau durfte die Sendewarteschlange geleert werden, wodurch der auslösende Datenverkehr vorübergehend verschwand.

Bleibt ein Paket nach dem Fehlschlag liegen, erzeugt es den nächsten Ruf. Ohne Grenze wird eine Anwendungsanforderung zu wiederholtem Leitungsverbrauch. Wird die Schlange ohne Nachweis gelöscht, verschwindet hingegen die Ursache. Beenden und Dokumentieren sind deshalb zwei getrennte Pflichten.

RFC 1618 bevorzugte PPP Multilink gegenüber BONDING. RFC 1990 definierte später die Bündelung mehrerer ISDN-Kanäle für Bandbreite nach Bedarf. Auch dort bildeten vorhandene Leitungen erst nach LCP-Aushandlung ein logisches Bundle.

Annahme war nur die erste Quittung

Danach mussten Codierung und Framing funktionieren, die untere Schicht Up melden, LCP Opened erreichen, optionale Authentisierung gelingen und das passende NCP öffnen. Erst dann durfte der Netzwerkverkehr fließen; Anwendungserfolg war nochmals ein anderer Befund.

Der RFC-Editor-Eintrag belegt Veröffentlichung, Autor und heutigen Proposed-Standard-Status, nicht Produktverhalten oder gegenwärtige Nutzung. RFC 1618 behandelt Sicherheit nicht; die angerufene Nummer authentisiert den Anrufer nicht.

Heng Lus Running-Code Primacy trennt das Feld vom tatsächlichen Verhalten. Seine Minimum Initial Specification erklärt, warum gemeinsame Defaults klein bleiben und die Annahmeentscheidung lokal bleiben kann.

Die Vermittlung nannte den Dienst. Sie konnte ihn nicht im Namen des Endpunkts öffnen. RFC 1618 machte das Nein vor der Annahme sichtbar, statt es hinter einem stummen Kanal zu verbergen.

Quellen