Zusammenfassung

  • DisplayableDlcAddress war laut RFC 2155 nur für die Anzeige bestimmt; die tatsächlichen Bytes des DLC-Headers sollten in einer DLC-spezifischen MIB gesucht werden.
  • Betriebszustand, über XID beobachtete Peer-Identität, lokale Ersatzwerte, Ereignishistorie und Sitzungserfolg waren eigenständige Nachweise.
  • Eine belastbare Zuordnung verbindet Anzeige, APPN-Instanz, DLC-Typ und RowPointer mit Leitungsbytes und Geltungsbereich, Zeit und Zustand sowie Herkunft und Ergebnis.

Lesbarkeit war keine Vollmacht

Ein sauber dargestellter Wert wirkt wie ein stabiler Inventarschlüssel. RFC 2155, im Juni 1997 als Proposed Standard für APPN veröffentlicht, zog dagegen eine scharfe Grenze. DisplayableDlcAddress durfte null bis 64 ASCII-Zeichen enthalten; die Managementstation sollte den Wert ausschließlich anzeigen.

Die „echte“ DLC-Adresse — die Bytes im Data-Link-Header — war häufig in der MIB des jeweiligen DLC verfügbar. Häufig bedeutet nicht immer, und die Anzeige musste nicht falsch sein. Ihr fehlte nur die Autorität über die Leitungsform. Eine leere Zeichenfolge bedeutete „dem Agenten unbekannt“; eine gefüllte bewies weder Eindeutigkeit noch Aktualität, Nachbarschaft oder Sitzung.

Der RowPointer wechselte die Beweisebene

Port- und Link-Station-Zeilen enthielten Anzeigeadressen sowie appnPortSpecific beziehungsweise appnLsSpecific. Diese RowPointer konnten ein Objekt in der passenden DLC-MIB adressieren; 0.0 bedeutete, dass der Agent keines bestimmen konnte. Eine korrekte Verknüpfung braucht APPN-Instanz, DLC-Typ, Pointer, Schnittstelle, untere Adresse und Erhebungszeit.

RFC 1747 zeigt dies für SDLC: Die Link-Station-Adresse ist ein Pollwert von 1 bis 255 und nur im definierten Bereich eindeutig, während der Kontaktzustand separat geführt wird. RFC 2024 kennt bei DLSw andere Formen, darunter sechs Byte MAC und vier Byte IP in Netzwerkreihenfolge. Eine Anzeigezeichenfolge bewahrt diese Kodierungen und Geltungsbereiche nicht automatisch.

Der bekannte Name konnte aus der lokalen Konfiguration stammen

appnLsAdjCpName konnte den per XID empfangenen Control-Point-Namen enthalten. War noch kein XID eingetroffen, durfte der Agent einen lokal definierten Wert liefern; andernfalls blieb das Feld leer. Dieselbe Darstellung konnte somit eine Beobachtung des Peers oder eine Erwartung des Betreibers sein.

Die Partner-Node-ID stammte aus vier XID-Bytes und nutzte 00000000, wenn sie nicht verfügbar war. Eine Form mit fünf abschließenden Nullen konnte zusätzlich Nicht-Eindeutigkeit auf dem Knoten markieren. TG-Nummer 256 bedeutete nicht ausgehandelt oder unbekannt. Vertrautheit ist keine Herkunftskette.

Gegenwart, Geschichte und Erfolg getrennt halten

Eine Link Station konnte inaktiv, auf Aktivierung wartend, aktiv oder auf Deaktivierung wartend sein. Gute und schlechte XIDs, Aktivierungszeit und Eintritt in den aktuellen Zustand waren separate Objekte. Eine Adresse sagte darüber nichts aus.

Die Statustabelle bewahrte außergewöhnliche oder möglicherweise außergewöhnliche Aktivierungs-, XID- und Beendigungsereignisse. Normalbetrieb erzeugte keinen Eintrag; Aufbewahrungsumfang und -dauer waren Produktentscheidungen. Eine sichtbare Zeile ist daher Geschichte, kein aktueller Nachbar. RFC 2155 schloss außerdem Überwachung und Steuerung von Endpunktsitzungen aus. Eine aktive Verbindung beweist keine erfolgreiche APPN-Sitzung oder Anwendung.

Der RFC-Editor-Eintrag und die Datatracker-Historie dokumentieren den Status. RFC 2455 ersetzte RFC 2155 im November 1998 nach Architekturergänzungen und Implementierungserfahrung, behielt aber die Anzeigegrenze bei. Heng Lus Texte über Running-Code Primacy, Minimum Initial Specification und Reality Layers sind offengelegte redaktionelle Perspektiven, keine RFC-Vorgaben.

Quellen