Offene Netze entstehen nicht auf der grünen Wiese. Wenn sich Architekturen nach den Open-Systems-Interconnection-Standards (OSI) durchsetzen sollen, dann nur wenn sie mit den herkömmlichen SNA-Netzen zusammenarbeiten können. Hier, so hat Gerhard Strecker festgestellt, befindet sich IBM in Zugzwang: Auf Router-Ebene mahnt er eine Öffnung von SNA an, während er beim System-Management Mängel im Netview-Produkt aufdeckt.
Neben den traditionellen Terminalnetzen entstanden in den vergangenen Jahren in vielen Unternehmen neue, zunächst eigenständige Netzinfrastrukturen, die auf Technologien wie OSI, TCP/IP und PC-Architekturen basieren. Damit läßt sich eine DV-Kommunikation mit integrierten PCs aufbauen, in die auch externe Partner wie Zulieferer oder Dienstleister eingebunden sind.
Heute werden diese Möglichkeiten mit verschiedenen unabhängigen Netzen realisiert. Kein Unternehmen kann es sich auf Dauer leisten, mehrfach ausgelegte Infrastrukturen zu betreiben. Die Aufgabe heißt, die Einzellösungen zu einer zumindest teilnetzübergreifenden Kommunikation unter Einschluß der Terminalnetze zusammenzuführen. Aus Sicht des Planers unternehmensweiter Kommunikation stellt sich dabei vor allem die Frage der Koexistenz der IBM-basierten SNA-Netze mit den Regeln offener Kommunikation nach Open Systems Interconnection (OSI).
Unabhängigkeit der Anwender vom Hersteller
Ziel der offenen Kommunikation ist das Zusammenwirken von Systemen und Endgeräten unterschiedlicher Hersteller mittels standardisierter Verfahren. Der Aufbau solcher Multivendor-Umgebungen hat für den Anwender letztlich die Konsequenz der Unabhängigkeit vom Hersteller.
Kein Fachmann glaubt heute mehr an OSI als einziger Netzarchitektur für die Zukunft. Es stellt sich vielmehr die Frage nach dem Platz, den OSI, neben der marktdominierenden SNA-Architektur, einnehmen kann. Die IBM hat 1974 ihre Netzwerkarchitektur Systems Network Architecture (SNA) angekündigt. Sie stellt den konzeptionellen Rahmen für die Realisierung von Produkten dar, die den Aufbau von System- und Netzwerkumgebungen, den Zugriff zu entfernten Verarbeitungsinstanzen und eine verteilte Verarbeitung ermöglichen.
IBM stützt seine SNA-Architektur durch eine Vielzahl von Produkten in allen relevanten Systemumgebungen. Weltweit werden große und größte Netze mit SNA-Technologie aufgebaut und betrieben; derzeit existieren etwa 40 000 dieser Netze. Aufgrund der Marktposition von IBM und der lange Zeit fehlenden vergleichbaren Ansätze haben sich SNA und die Produkte dafür zu einem Industriestandard entwickelt. Fast alle Hersteller haben Produkte, mit denen die eigenen Systeme an SNA- Netze angeschlossen werden können.
Im Gegensatz zu OSI nehmen bei SNA die Host-Systeme eine dominierende Rolle ein. Dies wird zwar durch neuere Konzepte relativiert, doch bleibt SNA ein hierarchisches Architekturmodell, in dem zentrale Kontrollinstanzen die Kommunikation innerhalb eines Netzes steuern. Einerseits erleichtern diese zentralen Instanzen das Management und die Überwachung großer Netze, andererseits führen sie vor allem beim Verbindungsaufbau zwischen zwei Partnern zu extrem komplexen Verfahren. Außerdem hat sich das System bei der Einbindung kommunikationstechnischer Neuerung nicht als besonders flexibel erwiesen.
Anschluß an neue Technologien leichter
OSI hingegen definiert auf allen Ebenen Kommunikationsbeziehungen zwischen gleichrangigen Partnern, die ohne zentrale Steuerung miteinander in Verbindung treten können. Dies erleichtert den Anschluß an neuere Technologien wie X.25, LAN, ISDN oder Router-Netzwerke.
IBM sieht in OSI die Architektur für die externe Kommunikation, während innerhalb der Unternehmen SNA der Vorzug gegeben wird. Für die Gebiete Internetzebene, OSI-Dienste, Interprogramm-Kommunikation und Netzwerk-Management wird untersucht, inwieweit SNA und OSI im Sinne einer Multiprotokoll- Architektur zusammenwirken können.
Grundvoraussetzung für heterogene Unternehmenskommunikation ist die Zusammenführung von Subnetzen unterschiedlichster Technologie. Hierfür wurde bei OSI die Internetzebene eingeführt, die für die Lenkung von Nachrichten zwischen Subnetzen, dem Routing, verantwortlich ist.
In den vergangenen Jahren hat das ISO-Gremium die OSI- Standards für den Zusammenschluß von Subnetzen definiert. Sie bestehen aus Routing-Protokollen und einem allgemeinen Adressierungsschema, das die Vergabe weltweit eindeutiger Adressen erlaubt. Bei der Definition ging OSI von der Erkenntnis aus, daß große vermaschte Netzwerke spezielle Intelligenz in Form von Router-Software benötigen, die flexibel auf vielfältige Veränderungen in einem Netz reagieren kann.
Einem ähnlichen Ansatz folgt SNA: Das "Subarea"- Routing erlaubt den Aufbau beliebig komplexer Netztopologien. Außerdem existieren Funktionen wie Lastverteilung und Alternativ-Routing, falls es zu Ausfällen von Komponenten kommt. Die derzeit von IBM für die SNA-LAN-Anbindung angebotene Lösung kann diese Techniken nicht einsetzen, da lokale Netze an der Peripherie von SNA-Netzen angeschlossen werden und dort das Subarea-Routing nicht zum Tragen kommt.
Anwender verlangen jedoch bei der LAN- Integration in SNA-Netze die Möglichkeit, von einem PC als Client zu einem Server im selben oder in einem entfernten LAN zugreifen und vom selben PC auf traditionelle Weise mit SNA-Host-Applikationen arbeiten zu können. In vielen Unternehmen entstanden und entstehen hierfür doppelt ausgelegte Infrastrukturen, die aus SNA- und Router-Backbones bestehen. Auf die Dauer ist dies sehr kostspielig, da sich nicht nur die Beschaffung, sondern auch die Personal- und Leitungskosten erheblich verteuern.
Um von dieser Doppelstrategie wegzukommen, benötigt das Routing mehr Intelligenz; ein Router muß sowohl die internetzfähigen Protokolle OSI, TCP/IP, XNS, Decnet als auch die SNA-Protokolle kennen, um die Daten auf die gewünschten Wege lenken zu können. Sind diese Voraussetzungen gegeben, spricht man von Multiprotokoll-Routern.
SNA-Daten werden verkapselt
Ein Weg, SNA-Datenströme über Router zu senden, ist das Protokoll Synchronous Passthrough, das heute schon einige Hersteller anbieten. Hierbei werden SNA-Daten (SDLC-Frames) mit einem Internetz-Protokoll wie TCP/IP verkapselt und können somit durch das gesamte Router Netz versendet werden.
Ein Vorteil dieser Lösung ist sicherlich, daß das Router-Netz für die SNA-Übertragung mitgenutzt werden kann. Wesentliche Nachteile sind der zusätzliche Kontrolldatenverkehr im Router-Netz, der durch das SDLC-Verfahren notwendig wird (Polling), und die Lücke im Management des SNA-Netzes, die darin besteht, daß die hierbei verwendeten Router keine Instanzen im Rahmen der SNA-Architekur sind.
Produkte, die Router multiprotokollfähig im Sinne des Subarea-Routings machen, gibt es derzeit nicht. Sie sind aber notwendig, um technisch sinnvolle und wirtschaftliche Lösungen für die unternehmensweite Integration von SNA-Netzen und LANs realisieren zu können (vergleiche Abbildung 1). Eine Möglichkeit, dies zu erreichen, ist die Implementierung der gesamten SNA-Intelligenz in den Routern. Dies wäre jedoch sehr aufwendig, denn bei SNA läßt sich die Routing-Funktionalität nicht von der komplexen Session-Ebene lösen, so daß hierdurch ein sehr großer Overhead entstehen würde.
SNA-Erweiterungen sind unumgänglich
Es scheint, daß nur mit einer SNA-Architekturerweiterung eine umfassende Integration von LAN-basierten Netzwerkinseln möglich ist. IBMs Ankündigung eines Advanced Peer-to-Peer Networking (APPN) bedeutet hier sicherlich einen Schritt in die richtige Richtung: APPN-Netzknoten haben die Möglichkeit, Routing-Entscheidungen zu treffen, ohne dabei die Zentrale, den Host, befragen zu müssen.
APPN erfordert allerdings den Einsatz des SNA-Protokolls LU 6.2, welches zur Kommunikation zwischen Anwenderprogrammen eingesetzt wird. Das hat zur Folge, daß die Router keinen SNA-Terminalverkehr lenken können. Daher lautet die Forderung an IBM, den APPN-Ansatz für alle SNA-Profile zu erweitern, die Protokolle festzuschreiben und zu veröffentlichen. Dies würde die Entwicklung von Multiprotokoll-Routern erlauben, die diesen Namen verdienen und die den Kern für die Koexistenz von SNA- und OSI-orientierten Netzarchitekturen in unternehmensweiten Netzen bilden können.
Weltweit haben sich vor allem zwei OSI-Dienste durchgesetzt, an denen kein Hersteller von Netzprodukten mehr vorbeikommt: X.400 und FTAM. Diese standardisierten Dienste werden vor allem bei der Anbindung von externen Partnern an
Unternehmensnetze eingesetzt. IBM und andere Hersteller bieten eine breite Palette von Produkten an, die es erlauben, OSI-Dienste in SNA-Netzen wirtschaftlich sinnvoll zu nutzen.
X.400 definiert die Protokolle zur Realisierung eines weltweiten elektronischen Message-Handling-Systems. Er ermöglicht, Nachrichten zwischen beliebigen Partnern auszutauschen, unabhängig von den jeweilig eingesetzten Plattformen.
IBM bietet heute über das Basisprodukt ONDS (Open Network Distribution Services) eine Verbindungsmöglichkeit zwischen X.400 und den Bürokommunikationssystemen Officevision/Profs auf VM, Officevision/Disoss auf MVS und Officevision/400 auf OS/400. Diese Übergänge zu X.400 eröffnen den Benutzern eines unternehmensweiten SNA-Netzes bisher nicht vorhandene Kommunikationsmöglichkeiten. Zwar sind in den heutigen Produktversionen die Möglichkeiten der Umsetzung von Officevision- auf X.400-Adressen eingeschränkt, doch ist zu erwarten, daß die Produkte in absehbarer Zeit einen hohen Entwicklungsgrad aufweisen werden.
Dieser Ansatz kann auch für den Austausch von Geschäftsdaten (EDI - Electronic Data Interchange) genutzt werden, bei dem beispielsweise Rechnungen, Bestellungen oder Lieferscheine zwischen Geschäftspartnern in standardisierter Form ausgetauscht werden können. Der Standard X.435 regelt die Übermittlung von EDI-Nachrichten über X.400.
FTAM definiert den OSI-Standard für den Zugriff und die Übertragung von Dateien zwischen Rechnersystemen unterschiedlicher Architektur. Mit der Produktfamilie OSI/FS stellt IBM diesen Dienst für MVS, VM, OS400 und OS/2 zur Verfügung.
OSI/FS wurde konform zu der IBM System Application Architecture (SAA) entwickelt. Dies stellt sicher, daß Anwenderprogramme und Benutzer in allen oben erwähnten Systemen einheitliche Schnittstellen zu dem FTAM-Dienst haben. Außerdem gibt es für das SNA-Filetransfer-Programm Netview FTP einen Übergang zu OSI/FS, der es beispielsweise erlaubt, von einem externen Handelspartner über FTAM empfangene Daten innerhalb des Unternehmensnetzes weiterzuleiten.
Die Kommunikation zwischen Programmen
Mit dem Konzept für Advanced Program-to-Program Communication (APPC) nähert sich SNA der Peer-to-Peer-Kommunikation, wie sie von OSI propagiert wird, bereits an. Mit APPC können PCs und Workstations auf standardisierte Weise in verteilte Anwendungen einbezogen werden. APPC-Produkte gibt es auf allen IBM-Hosts, Workstations und PCs; die APPC-Schnittstellen sind im Rahmen von SAA genau standardisiert.
Wesentliche Konzepte von APPC, wie zum Beispiel das Commit-Protokoll zum Synchronisieren zweier Programme, wurden bei der Standardisierung von dem OSI Distributed Transaction Processing (OSI-DTP) berücksichtigt. OSI-DTP ist eine Obermenge von APPC. Daher sind Gateway-Lösungen und damit die Koexistenz von SNA und OSI bei der Interprogramm-Kommunikation kein wesentliches Problem.
Es reicht jedoch nicht, wenn Unternehmensnetze funktionell den Anforderungen der verschiedenen Benutzer entsprechen, sie müssen auch administrierbar sein und bleiben. Mit seiner Open Management Architecture verfolgt IBM das Ziel, unternehmensweite Netzwerke einheitlich zu überwachen und zu steuern.
Aus diesem Grund bemüht sich die IBM um eine Erweiterung der Netview Produktfamilien für das Management von LANs, TCP/IP- und OSI-Netzen. So wird zum Beispiel das Common Management Information Protocol (CMIP) von OSI unterstützt.
Zwei Ansätze für das Netzwerk-Management
Netzwerk-Management ist in der SNA-Architektur, im Gegensatz zu den OSI-Verfahren, stark an die spezifischen Protokollabläufe auf den SNA- Ebenen gekoppelt. Deshalb läßt sich ein SNA-Netz nicht von einer externen Instanz aus steuern. Für das integrierte Management eines heterogenen Unternehmensnetzes existieren daher aus heutiger Sicht nur zwei Lösungsansätze:
- Das Management des gesamten Netzes von einer Zentrale aus (Netview Focal Point) und
- die getrennte Verwaltung von SNA und der anderen Netze. Bei SNA-fremden Umgebungen geschieht das von einer Instanz aus, die ein Plattformkonzept bietet, das die Integration gängiger Management-Protokolle außerhalb der SNA-Welt ermöglicht. Diese Instanz ist als Netview Service Point mit der Zentrale verbunden ist (vergleiche Abbildung 2).
Ungelöste Probleme bei integrierten Netzen
Für beide Varianten bietet Netview heute Produktlösungen an. Es gibt aber auch Aspekte, für die derzeit noch keine Lösung in Sicht ist:
- Der Netview-Inormationsfluß ist hierarchisch; das heißt, die Netview-Zentrale empfängt Informationen und sendet Kommandos, wodurch das in Abbildung 2 dargestellte Zusammenspiel zwischen Focal Point und Service Point eingeschränkt wird. Das macht die Realisierung der dezentralen Management-Intelligenz schwieriger.
- Netview bietet heute keine einheitliche Methode an, Managed Objects im Sinne von OSI zu integrieren. Dies erschwert die Umsetzung eines einheitlichen, unternehmensweiten Informationsmodells in eine Management Information Base (MIB), die Grundlage für integriertes Netz-Management ist.
- Existierende Netview-Management-Applikationen wurden speziell für Konzepte, Strukturen und Formate, die auf SNA basieren, entwickelt. Es fehlt an Applikationsschnittstellen für die Entwicklung von SNA-übergreifenden Produkten.
Fazit: SNA und OSI koexistieren bereits in vielen Unternehmen. IBM-Produkte sind weit verbreitet und ermöglichen durch die zentralen Verwaltungs- und Steuerungsmöglichkeiten die organisatorische und technische Beherrschung großer Netzverbundsysteme. Die Stärke von OSI liegt demgegenüber in der Akzeptanz und der Flexibilität des OSI-Modells. Viele neue Technologien werden heute danach entwickelt. Auch sind die Konzepte und Standards technologisch ausgereift. Die Integration der beiden Architekturen von unten (Router-Netze) ist noch nicht befriedigend gelöst. Damit dies gelingt, muß sich SNA öffnen, denn der Markt erfordert hier intelligente Lösungen. Mail- und Filetransfer-Dienste von OSI erweitern die Reichweite eines Unternehmensnetzes und somit ergänzen sich SNA und OSI hier sehr gut Auf anderen Gebieten hat die Existenz von OSI bereits bewirkt, daß sich die IBM-Strategie für SNA in die richtige Richtung bewegt. Die OSI-Architektur beherrscht zwar nicht die Welt, aber es geht von ihr eine normierende Wirkung aus.
* Dr. Gerhard Strecker ist Diplom- Mathematiker und arbeitet als Abteilungsleiter Kommunikation im Projektbereich der Softlab GmbH, München.