Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

10.09.1982 - 

Karstadt AG: 128-Byte-Trick reduziert Kosten im X.25-Netz mit IBM ACFNCP und NIA

Datex-P-Pakete fast bis zum letzten Bit gefüllt

Im Rahmen des Ausbaues des Datenfernverarbeitungsnetzes, mit dem Ziel der Anbindung aller Filialen an die von der Karstadt Datenverarbeitung zur Verfügung gestellten Möglichkeiten im Bereich der Unternehmensplanung und Personalverwaltung wird verstärkt der neue Dienst der Deutschen Bundespost, Datex-P eingesetzt. Da die auf den Zentralsystemen eingesetzten Softwarepakete primär SNA-orientiert ausgelegt sind, bot es sich an, die entsprechende Soft- und Hardware der IBM für die X.25-Unterstützung zu verwenden. Die dabei gemachten Erfahrungen waren durchweg positiv. Nach den überraschend problemlosen und erfolgreichen ersten Test entdeckten wir allerdings einige unangenehme Eigenschaften der Umsetzungsroutinen.

Als die Hardwarevoraussetzungen - Datex-P10-Anschlüsse für die 3705 und zwei weitere Anschlüsse für die Gegenstellen, zwei IBM/5973-L02-NIAs (Network Interface Adapter) - geschaffen waren, geschah die Implementation der Software im NCP (Network Control Program) problemlos mit SMP (System Modification Program). Nach geringfügigen anfänglichen Handhabungsschwierigkeiten wurden die ersten Kommunikationstests mit den verschiedenen Verbindungsmöglichkeiten (SVC = Switched Virtual Circuit und PVC = Permanent Virtual Circuit) und verschiedenen IBM- und Nicht-IBM-Terminals erfolgreich durchgeführt.

Als besonders angenehm stellte sich dabei heraus, daß die Verwendung von Datex-P definitiv keinen Einfluß auf die verwendeten Programme hatte. Aus der Sicht des Hosts stellen sich die beiden Verbindungsarten wie normale HFJ-Leitungen oder Wählverbindungen dar. Die Anpassung der verwendeten Verfahren zur Leitungssteuerung werden vollständig transparent vom NCP-X.25-Programm und der am Zielort installierten NIA vorgenommen. Die Art des Verbindungsaufbaues zeigt das Bild 1. Der Nachteil der NIA ist, daß pro Datex-P-Anschluß auf der Seite der NIA nur eine Steuereinheit angeschlossen werden kann, das heißt, daß kein Multipoint-Betrieb möglich ist, obwohl das X.25-Subchannel-Konzept gerade dort viele Möglichkeiten bietet.

Die vom NCP erzeugten SDLC-Frames werden dabei vom X.25-Programm in X.25-Packets gebrochen, mit den notwendigen Angaben versehen und über das Datex-P-Netz zur NIA am Zielort übertragen. Aufgabe der NIA ist danach das Aufbauen von SDLC-Frames aus den Datenpaketen und die Weitergabe an die zugehörige Terminalsteuereinheit. Auf dem Datenwege vom Terminal zum Host werden diese Aufgaben entgegengesetzt ausgeführt.

Nach den überraschend problemlosen und erfolgreichen ersten Tests entdeckten wir allerdings einige unangenehme Eigenschaften der Umsetzungsroutinen.

Auf den beim Test benutzten Leitungsmonitoren und im Line-Trace des NCPs für die getesteten Verbindungen konnte man erkennen, daß die Umsetzung der SDLC-Frames in X.25-Pakete dazu führte, daß zum Teil sehr kleine Datenmengen einer Nachricht in eigenen Paketen durch das Netz transportiert wurden.

Die vom Terminal abgegebenen Daten stellten sich hinter der NIA wie in Bild 2 gezeigt dar. Diese Form ist logisch, denn die Terminalsteuereinheit betrachtet die Verbindung nach den ihr bekannten Spielregeln, das heißt aus der Sicht einer normalen SDLC-Verbindung.

Die verwendete Steuereinheit eine IBM /3276, produziert SDLC-Frames von 256 Bytes Daten und jeweils dem TH (Transmission Header). Im ersten Frame ist darüber hinaus noch der im SNA benötigte RH (Request Header) enthalten. Diese Frames gibt die Steuereinheit jetzt zur nachgeschalteten NIA, die die Aufgabe hat, aus den Frames Pakete nach den Regeln von Datex-P zu bauen. Ein Datex-P-Paket darf aber nur 128 Bytes Daten enthalten; deshalb müssen die SDLC-Frames in einzelne Stücke zu 128 Bytes gebrochen werden. TH und RH werden dabei zur Aufrechterhaltung der End-to-end-Kontrolle als Daten mit durch das X.25-Netz transportiert. Zur Vollständigkeits- und Folgenkontrolle der Segmente versieht die NIA jedes X.25-Paket zusätzlich mit dem sogenannten LLC-Header (Logical Link Control). Bei der Analyse dieses Verfahrens ergibt sich zwangsläufig, daß Jeweils zehn beziehungsweise 13 Bytes beim ersten SDLC-Frame in einem eigenen X.25-Paket enthalten sind.

Unangenehm dabei ist, daß die Verrechnungseinheit im Datex-P-Netz 64 Bytes ist. Das bedeutet, daß für den Transport dieser kleinen Stücke jeweils die Gebühr für ein halbes Datex-P-Packet zu zahlen ist. Dieses ungünstige Verhalten liegt daran, daß das Terminal nicht auf das X.25-Protokoll Rücksicht nimmt. Eine Beseitigung dieser Situation ist praktisch erst mit dem Einsatz von Native-X.25-Terminals zu erwarten, die solche angebrochenen Pakete innerhalb einer Nachricht unterlassen könnten. Auch der mehrfache Anschluß von verschiedenen Steuereinheiten an einen Datex-P-Hauptanschluß sollte dann irgendwann möglich sein.

Anders sieht es auf der Seite des NCP aus. Die Tests zeigten ein vergleichbares Bild beim Paketierungsverhalten, wie im Bild 3 zu erkennen ist.

Hier bietet sich die Möglichkeit, auf die Anforderungen des Datex-P-Netzes einzugehen. Es gibt im NCP zwei Parameter, mit denen die Größe der zu bildenden SDLC-Frames beeinflußt wird.

Zum einen ist dies die Angabe "Maxdata" im PU-Macro des NCP, welche die maximale SDLC-Frame, Größe angibt, die für das damit beschriebene Terminal auszugeben erlaubt ist. Die bei Karstadt im Einsatz befindlichen PUs (Physical Units) vom Typ IBM /3276-74 und IBM /3650 sind beide vom PU-Typ 2 und erlauben somit die gleichen Maxdata-Werte.

Andererseits wird der im PU-Macro spezifierte Maxdata-Wert nicht wirklich vom NCP benutzt, sondern eine Größe, die sich annähernd daran aus den im NCP verwendeten Puffern ergibt.

Die Größe der NCP-Puffer ist damit zu einem wichtigen Faktor bei der Beeinflussung der SDLC-Frames und damit auch der X.25-Pakete geworden.

Zur Berechnung der NCP-Puffer, eine generelle Angabe bei der Generierung der NCP-Software im Build-Macro, liefert die IBM spezielle Formeln, nach denen man anzugebende Puffergröße errechnen kann.

Bei näherem Betrachten dieses Verfahrens ist er jedoch mehr theoretischer Natur, da für Berechnung Zahlen notwendig sind, die den wenigsten NCP-Benutzern zuverlässig zur Verfügung stehen.

Man arbeitet also üblicherweise dort mit geschätzten Werten, wie beispielsweise der durchschnittlichen Nachrichtenlänge im gesamten Netz und ähnlichem. auf diese Weise hat sich sicher jeder NCP-Benutzer einen mehr oder weniger effektiven Wert für die zu verwendende Puffergröße ermittelt und arbeitet damit auf normalen Wähl-, HFD-oder Datex-L-Leitungen erfolgreich, ohne sich jede Woche neue Gedanken darüber zu machen, wenn sich in irgendwelchen Programmen die durchschnittliche Nachrichtenlänge verändert. Diese Situation ist in einem konventionellen Netz auch von untergeordneter Bedeutung.

Anders sieht das bei der Verwendung von Datex-P aus. Da die Bildung der SDLC-Frames und somit letztlich auch der X.25-Packets von dem Maxdata-Wert und dieser wiederum nicht unwesentlich von der Größe der verwendeten Puffer beeinflußt wird, ist die Auswahl der Puffergröße - zumal im NCP verwendeter genereller Wert - sorgfältig vorzunehmen.

Bedauerlich ist, daß in der zum X.25-Programmpaket verfügbaren Literatur keine eindeutigen Hinweise auf diesen Zusammenhang zu finden sind. Darüber hinaus sind die Beschreibungen zu den Maxdata-Angaben im NCP zum Teil nicht vollständig richtig, und auf den Zusammenhang mit der im NCP verwendeten Puffergröße wird auch nicht besonders stark hingewiesen. Diese Aussagen gelten zumindestens für die bei Karstadt im Einsatz befindliche Software, ACF/VTAM Release 2 und ACF/NCP Release 2.1.

Die eingehende Beschäftigung mit der Materie in Verbindung mit den Datex-P-Tests führte jedoch bald zu einer eindeutigen Definition der vom NCP in Zusammenarbeit mit dem X.25-Programm in der 3705 verwendeten Regeln.

Zum einen sind das die allgemeinen Vorschriften für das NCP:

- Die NCP-Puffergröße muß ein Vielfaches von 4 sein;

- die NCP-Puffergröße muß größer/gleich 60 und kleiner/gleich 240 sein;

- Maxdata für eine PU-Type 2 muß kleiner/gleich 265 sein.

Zum anderen die zum Teil nicht eindeutig oder gar nicht erwähnten Regeln in bezug auf die Segmentierung einer Nachricht:

- Die wirklich verwendete Maxdata-Größe ist ein Vielfaches der NCP-Puffergröße plus 6 (PU-Type 2) und ist kleiner/gleich der Maxdata-Angabe im betroffenen PU-Macro;

- der erste SDLC-Frame ist 28 Bytes kürzer als die so ermittelte Größe, was vermutlich am 28 Byte großen VTAM-Prefix liegt, der vom NCP eliminiert wird;

- X.25-Packets werden jeweils an einem SDLC-Frame neu begonnen, unabhängig davon, ob das vorherige Paket gefüllt wurde oder nicht.

Bei Beachtung dieser Regeln ermittelt man bald wenige mögliche Angaben für die zu verwendende Puffergröße und den zugehörigen Maxdata-Wert.

Puffergröße von 60, 80, 120 oder 40 sind die einzig sinnvoll zu verwendenden im Zusammenhang mit Datex-P. Ein Maxdata-Wert von 250 bietet dann die im Bild 4 gezeigte, fast optimale Ausnutzung der Datex-P-Segmente. Die jeweils leeren sechs Bytes in den Folgesegmenten sind aufgrund der Notwendigkeit, daß die NCP-Puffergröße durch 4 teilbar sein muß, nicht mit Daten zu belegen. Die 34 Bytes des ersten SDLC-Frames (2. Datex-P-Segment) ergeben sich aus dem 28 Bytes kürzeren Anfangs-Frame und den eben erwähnten sechs Bytes und sind, wenn die Länge der zu sendenden Nachrichten im Netz ein SDLC-Frame im Normalfalle überschreiten, nicht sinnvoll zu verhindern.

Mit diesem Wissensstand könnte man sich im Prinzip zufriedengeben, da in bezug auf die Kosten im Datex-P-Netz und unter Berücksichtigung der Tatsache, daß alle angefangenen 64 Daten-Bytes zu bezahlen sind, keine kostenmäßige Verbesserung zu erzielen ist. Eine Verbesserung der Segmentierung ist nur dann zu erreichen, wenn die NCP-Software auf X.25 stärkere Rücksichten nehmen würde und von der Seite des Terminals diesem die Berücksichtigung der X.25-Umgebung unterlegt werden könnte.

Sechs freie Bytes sinnvoll nutzen

Erwarten kann man solche Verbesserungen jedoch frühestens dann, wenn auch von der IBM größere Mengen von Datenstationen für den Verkehr mit X.25 ausgelegt sein werden und der Gebrauch der NA nicht mehr notwendig ist.

Allerdings hat uns das Vorhandensein der sechs freien Bytes in jedem zweiten X.25-Segment noch auf einen anderen Gedanken gebracht. Da dieser Freiraum ja sowieso bezahlt werden muß, beabsichtigten wir, ihn wenigstens sinnvoll zu nutzen.

Das war, wie sich ergab, recht einfach zu erreichen. Bei der Verwendung einer Puffergröße von 60 oder 120 Bytes im NCP und einem Maxdata-Wert von 128 ergibt sich nämlich die im Bild 5 gezeigte Segmentierung.

Diese Art bringt zwar keine Kostenvorteile, birgt aber einen angenehmen Sondereffekt.

Der durch die Angabe Maxdata-128 aufgebaute Transmission-Header in jedem der X.25-Segmente nimmt den Platz der vorherigen freien sechs Bytes ein und ist sozusagen "kostenfrei", was an sich natürlich kein Vorteil ist. Das Vorhandensein eines Transmission-Headers in jedem Datex-P-Segment führt jedoch dazu, daß die empfangende NIA nicht mehr genötigt ist, die X.25-Packets zu einer SDLC-Frame zusammenzusetzen. Sie wird de facto auf der Sendeseite ausgeschaltet. Das führt dazu, daß der Bildschirmbenutzer zügig mit den ankommenden Daten versorgt wird und so den Eindruck einer guten Antwortzeit hat.

Darüber hinaus ist diese Antwortzeit wegen des entfallenden NIA-Prozesses in der Tat kürzer.

Wichtiger erscheint uns jedoch der optische Eindruck des Benutzers dabei. Die zügige Ausgabe jedes ankommenden Segmentes auf dem Schirm verkürzt die Wartezeit des Benutzers auf seine Antwort. Auch wenn während der Ausgabe der Nachricht der Benutzer nicht die Möglichkeit hat, bereits Eingaben zu machen, wird seine Aufmerksamkeit durch die ausgegebenen Informationen in Anspruch genommen. Die positive Eigenschaft dieses Vorganges kann jeder, der sich mit Dialoganwendungen beschäftigt, bestätigen.

Auch als ansonsten durchaus kritischer Benutzer von Hard- und Software der IBM muß man insgesamt "Big Blue" attestieren, daß die im Rahmen von X.25 verwendete Hard- und Software für die Zeit des Überganges zu einem eventuell stärker auf X.25 ausgelegten Betrieb, den Umständen entsprechend gut und transparent für den Benutzer ausgelegt wurde. Sie bietet darüber hinaus, was man nicht aus den Augen lassen sollte, die leichte Möglichkeit, zurück zu normalen HFD- und Wählverbindungen zu gehen, falls die Tarifpolitik der Deutschen Bundespost oder die Menge der zu übertragenden Daten dies angeraten erscheinen läßt.

Abteilungsleiter und Systementwickler bei der Karstadt AG, Essen.