Zwar sind erst wenige Produktrealisierungen für die oberste Ebene des OSI-Referenzmodells, die sogenannte Anwendungsschicht, verfügbar, doch steigt nun auch bei den Anwendern das Interesse am Thema Open Systems Interconnection. Ulf Beyschlag und Eduardo Mendoza* zeigen in ihrem Beitrag auf, was bei einer vernünftigen Migration in Richtung OSI zu berücksichtigen ist.

Das Schlagwort OSI gehört heute zum festen Vokabular fast aller Datenverarbeiter. Dabei vergessen wir zumeist, daß das OSI-Referenzmodell mit der Festlegung der sieben Schichten erst vor vier Jahren ein internationaler Standard wurde. Das Referenzmodell selbst ermöglicht aber noch keine Kommunikation. Sie wird erst durch Protokollstandards aller Schichten ermöglicht. Der Anwender interessiert sich hierbei in erster Linie für die Protokolle der Anwendungsschicht (File Transfer, Terminal-Zugriff, Elektronische Post, Transaktionen, . . . ). Dies bedingt allerdings die Verwendung von Protokollen auf allen darunterliegenden Schichten.

Mit Ausnahme der Elektronischen Post (1984) haben sich die wichtigsten Protokollstandards der Anwendungsschicht erst in den letzten zwölf Monaten stabilisiert. Wenige Realisierungen sind als Produkte verfügbar. Es ist daher zu früh für eine abschließende Bewertung des OSI-Ansatzes und der OSI-Protokolle.

Produktankündigungen der wichtigsten Hersteller

Trotzdem scheint der Erfolg von OSI gesichert. Alle marktrelevanten Hersteller bieten bereits OSI-Produkte an oder haben sie angekündigt. Hersteller demonstrieren auf Messen gemeinsam das Zusammenspiel ihren OSI-Implementierungen. Das amerikanische Department of Defense will sich von den eigenen "Arpa"-Protokollen (TCP/IP, FTP, Telnet,...) lösen und in Zukunft nur noch OSI-Protokolle verwenden. Ein Ratsbeschluß der Europäischen Gemeinschaft wird ab Dezember dieses Jahres die Verwendung von verfügbaren OSI-Protokollen für Behörden in den Mitgliedsstaaten zwingend

vorschreiben.

Für alle diejenigen Anwender, die heute bereits Netzwerke betreiben, die entweder auf Herstellerprotokollen, den Arpa-Protokollen oder Eigenentwicklungen beruhen, stellt sich somit die Frage nach der Migration zu OSI. Eine Ausnahme sind diejenigen Anwender, deren DV-Systeme fast ausschließlich von einem Hersteller geliefert werden. In diesen bei mittleren und großen Unternehmen sehr selten anzutreffenden Situationen kann eine vollständige Anlehnung an die Migrationsstrategie des betreffenden Herstellers ausreichend sein.

Am leichtesten hat es der Anwender, der auf der "grünen Wiese" mit der schrittweisen Einführung von OSI-Protokollen beginnen und somit auf eine Migration ganz verzichten kann. Je stärker ein Anwender Datenkommunikation bereits nutzt, desto problematischer ist eine Migration. Sie kann im schlimmsten Fall sehr hohe Kosten verursachen und trotzdem von den Benutzern nicht angenommen werden. Zusätzliches technisches Know-how in einem sich schnell entwickelnden Gebiet muß intern aufgebaut oder extern beschafft werden.

Viele Anwender scheuen daher heute noch den Gedanken an eine Migration. Sie erkennen aber nicht, daß sie durch den weiteren Ausbau ihrer bestehenden Kommunikationsinfrastruktur ohne Migrationsperspektive eine später aus ökonomischen und technischen Gründen erforderliche Migration erheblich erschweren. Eine frühzeitig festgelegte und konsequent durchgeführte mittel- bis langfristige OSI-Migrationsstrategie ist der beste Schutz vor bösen Überraschungen.

TOP als Referenz und als möglicher Einstieg

Eine der wichtigsten Fragen für die Festlegung einer Migrationsstrategie ist das Wohin. Welche Protokolle soll man einsetzen und wie stehen diese zueinander in Beziehung? Die Kommunikations-Architektur ist zu bestimmen. Zwei bedeutende OSI-Architekturen, die in ihrer Version 3 jetzt eine stabile Form gefunden haben, sind als Referenz für eine eigene Architektur zu empfehlen: MAP und TOP. Wahrend MAP (Manufacturing Automation Protocols) von General Motors für die Produktionsumgebung konzipiert wurde, entwickelte Boeing ergänzend TOP (Technical and Office Protocols) für die Büroumgebung. Beide Architekturen überlappen sich in weiten Bereichen.

Ein erster Release von TOP Version 3.0 wurde Ende April veröffentlicht. Mit dem Anhang A dieses Dokuments möchten wir uns hier etwas ausführlicher beschäftigen. Er trägt die Überschrift: Issues in Migrating Towards OSI/TOP. Auf recht allgemeinem Niveau gehalten, bietet er doch sehr nützliche Hinweise für die Konzeption einer individuellen Migrationsstrategie. Insbesondere werden zu berücksichtigende Prinzipien und die Beschreibungen einzelner Schritte aufgeführt. Wir halten die zusammengestellten Prinzipien für so wichtig, daß wir sie hier wiedergeben möchten.

Zehn Prinzipien

(Nicht alle Prinzipien haben in jeder Umgebung Gültigkeit.)

1. Angebotene Netzwerk-Funktionalität. Nach der Migration sollte dem Benutzer zumindest die vorherige Funktionalität zur Verfügung stehen.

2. Minimale Auswirkungen auf die Benutzeranwendungen. Anwendungen, sollten über eine standardisierte Schnittstellenbibliothek und nicht direkt mit den Diensten der Anwendungsschicht kommunizieren. Eine Migration wäre dann für die Anwendungen transparent.

3. Feststellung des Umfangs des Zusammenschlusses. Auf organisatorischer Ebene sollten die Kommunikationsanforderungen festgestellt werden, um sinnvolle Prioritäten für die Migration festlegen zu können.

4. Übergang in Phasen. Die Migration sollte in Phasen erfolgen, wobei bei jedem Übergang Vorsorge zu treffen ist, daß bei unerwarteten Problemen der Übergang rückgängig gemacht werden kann.

5. Bewahrung eines gemeinsamen Übertragungssystems. Ein einheitliches Internetzwerk-Protokoll (ISO IP) sollte in der ganzen Organisation verwendet werden.

6. Konsistenz bei Unternetzwerken und Reduktion der Vielfalt. Auf den unteren beiden Schichten des Referenzmodells sollte keine zu große Vielfalt an unterschiedlichen Technologien eingesetzt werden, um das erforderliche Know-how zu begrenzen.

7. Konfigurationskontrolle. Die Rolle eines Netzwerkmanagers sollte geschaffen werden. Er hat die Einführung neuer und zusätzlicher Hard- und Software konsequent zu kontrollieren.

8. Modularisierung und Isolierung von Komponenten. Über Gateways kann zum Beispiel eine Gesamtinfrastruktur segmentiert werden. Jedes einzelne Segment kann dann einer etwas anderen Migrationsstrategie folgen.

9. Anschaffung von aufwärtskompatiblen Komponenten. Sollte es erforderlich sein, Kommunikationsprodukte anzuschaffen, die mit der Zielarchitektur nicht konform sind, so sollte man sich vom Hersteller zumindest vertraglich zusichern lassen, daß er seine Produkte entsprechend migrieren wird.

10. Ermunterung zur Befolgung der Strategie. Innerhalb der eigenen Organisation sollten die ökonomischen Vorteile der Migration deutlich gemacht werden.

Vermeidung von "Glaubenskämpfen"

Häufig sind in großen Organisationen intensive Auseinandersetzungen zwischen den Anhängern von SNA und OSI, von TCP/IP und DEC-NET zu beobachten. Oft schwelen die Konflikte, brechen aber bei jeder neuen Beschaffung wieder hervor. Solche Konflikte haben direkte (Zeitaufwand) und indirekte (langsamerer Infrastrukturaufbau) Auswirkungen auf die Produktivität einer Organisation. Die Kosten für eine abgestimmte Migrationsstrategie könnten dann schon durch die Vermeidung zukünftiger Konflikte ausgeglichen werden.

* Ulf Beyschlag ist bei der Münchener Softlab GmbH als Projektmanager für das Geschäftsgebiet "Kommunikations-Architekturen" tätig, Dr. Eduardo Mendoza ist im gleichen Bereich Chefberater.