Zusammenfassung

  • RFC 2353 nutzte UDP/IPv4 bewusst als native DLC-Schicht für APPN/HPR; HPR-RTP lieferte Ende-zu-Ende-Wiederherstellung und LDLC die Lebensprüfung.
  • Wurde die Prüfung im Leerlauf unterdrückt, konnte ein Knoten den ausgefallenen Link löschen, während der Nachbar ihn weiter als aktiv führte.
  • Eine spätere Reaktivierung konnte als unzulässiger paralleler Link abgewiesen oder eine neue Sitzung an einen bereits verworfenen Zustand geschickt werden. Der Standardentwurf verlangte Nachmessen und Ersetzen.

Ein Keepalive verbraucht Bandbreite, Timer und Aufmerksamkeit. Es erzeugt aber zugleich etwas Wertvolleres: einen regelmäßig erneuerten gemeinsamen Zeitpunkt. RFC 2353 zeigte, was geschieht, wenn man diesen Zeitpunkt im Leerlauf einspart.

Das Informational RFC vom Mai 1998 war kein Internetstandard. Es dokumentierte eine APPN/HPR-over-IP-Architektur, die der APPN Implementers’ Workshop im Dezember 1997 als „Closed Pages“ genehmigt hatte. Das stand für Implementierungsreife in diesem Verfahren, nicht für heutige Verbreitung.

IP sollte als native Datenlinksteuerung für HPR dienen, während APPN-Pfadauswahl und Dienstklassen erhalten blieben. Das optionale Connection-Network-Modell verringerte die Zahl vordefinierter Links. UDP war gewählt, weil HPR die Zuverlässigkeitsfunktionen bereits besaß.

UDP trug Pakete, nicht Linkzustand

RFC 768 definiert einen kleinen Datagrammdienst mit Ports, Länge und Prüfsumme, ohne Verbindungsabbruch. RFC 791 definiert IPv4-Datagramme und Routing.

RFC 2353 wies Verlust, Duplikate, Verzögerung, Umordnung und Konnektivitätsverlust den höheren Schichten zu. Das HPR-eigene RTP — nicht das spätere IETF-Echtzeitprotokoll — übernahm selektive Wiederholung, Reihenfolge und adaptive Rate. LDLC verwaltete logische Links und Liveness. TCP hätte Wiederholungswarteschlangen und Zustände verdoppelt.

Damit entstanden getrennte Belege: Datagrammbeobachtung, RTP-Wiederherstellung und LDLC-Lebensprüfung. Keiner sagte automatisch, welchen Linkzustand der Nachbar gespeichert hatte.

Leerlauf machte Wissen asymmetrisch

Weil UDP keinen Ausfall meldet, brauchten HPR/IP-Links periodische LDLC-Tests. Das Dokument nennt als Voreinstellungen zehn Sekunden Liveness, fünfzehn Sekunden Wiederholung und drei Versuche.

Optional durfte eine Implementierung die Tests stoppen, wenn keine Daten flossen. Unterliegende Einrichtungen konnten ruhen. Nach einem Ausfall konnte aber eine Seite früher reagieren.

Der informierte Knoten deaktivierte seine Instanz. Bei der Reaktivierung traf er auf den Nachbarn, dessen alte Instanz noch aktiv war, und erhielt eine Ablehnung wegen eines nicht unterstützten parallelen Links. Umgekehrt konnte der unwissende Knoten Daten oder Sitzungsaktivierungen senden, die der andere nach dem Löschen verwarf.

Beide Protokolleinträge konnten ihrer Beobachtung entsprechen. Das fehlende Ereignis war die gemeinsame Bestätigung.

Ablehnung war ein Messauftrag

Bei einer Parallel-Link-Ablehnung sollte der Knoten Liveness auf verwandten aktiven Links testen, insbesondere bei gleichem IP-Paar und anderen SAP-Paaren. Veralteter Zustand musste seine Blockadewirkung erneut verdienen.

Kam ein Aktivierungs-XID mit identischem IP- und SAP-Paar, sollte die alte Instanz deaktiviert und neu aufgebaut werden; ein Timer begrenzte streunende XIDs. Außerdem empfahl das RFC, vor endgültiger Reaktion auf LDLC-Fehler eine Reaktivierung zu versuchen.

Die Sense Codes X'10160045' und X'10160046' erklärten die lokale Ablehnung definierter oder dynamischer Parallelverbindungen. Sie bewiesen weder die erste Fehlerseite noch eine entfernte Verarbeitung oder den Sitzungsausgang.

Zuverlässigkeit war nicht Einigkeit

HPR-RTP konnte Daten Ende-zu-Ende wiederherstellen und ordnen, ohne die LDLC-Automaten zu synchronisieren. Erfolgreiche Liveness bewies keine APPN-Sitzung. Ein Fehlercode erzählte nicht die gesamte entfernte Historie.

Auch Sicherheit blieb separat: SNA-Sitzungsauthentisierung und Verschlüsselung, IPsec für UDP sowie Firewallfilter. Schutz ersetzt keine Zustandsabstimmung.

Der RFC-Editor-Eintrag und die Datatracker-Historie belegen den Dokumentstatus. RFC 1122 liefert Hostanforderungen, nicht den entfernten HPR-Zustand.

Lu Hengs Running-Code Primacy begrenzt lokale Wahrheit auf das, was der laufende Peer akzeptiert. Minimum Initial Specification und lokale Zukunftsentscheidung bevorzugen prüfbare Übergänge. Die Wirklichkeitsebenen trennen Datagramm, Lebenszeichen, Link, Sitzung und Ergebnis.

Die bleibende Aussage ist nicht, dass jedes Keepalive unverzichtbar sei. Wer Beobachtung spart, akzeptiert spätere Einigkeit. Wiederanlauf muss deshalb den lokalen Zustand erneut zur Prüfung stellen.