APPI-Spezifikationen eher verfügbar

APPN: Cisco geht mit eigener Strategie auf Distanz zu Big Blue

02.10.1992

MÜNCHEN (gh) - Die Fronten in der Auseinandersetzung um die Lizenzierung von IBMs Peer-to-peer-Protokoll APPN scheinen nun geklärt. Die kalifornische Cisco Systems Inc. wird sowohl die Lizenz für Big Blues APPN Quellcode erwerben als auch eine eigene lizenzfreie SNA Lösung unter dem Namen APPI entwickeln. Damit sieht sich der Marktführer aus Armonk unweigerlich mit einer "offenen" APPN-Alternative konfrontiert, die zudem von großen Teilen der Industrie unterstützt wird.

"Nach Abwägung aller Faktoren kann man nur zu einem Ergebnis kommen: APPI ist die deutlich bessere Alternative." Mit dieser, von vielen Insidern als Kriegserklärung gewerteten Äußerung warf der Cisco-Verantwortliche Gerard Rousset, seit einem dreiviertel Jahr European IBM Market Manager bei den Kaliforniern, den Armonkern den Fehdehandschuh hin Der Marktführer im Router-Business wird nun tatsächlich das in die Tat umsetzen, was sich in den letzten Wochen bereits immer deutlicher abgezeichnet hatte: Die Anwender und Entwickler sollen zwischen der teuren APPN-Lizenz und einem "offenen Standard" APPI wählen können.

Mit dem Bekanntwerden von Ciscos APPI-Plänen vor einigen Wochen hatte der Unmut über die Lizenzierungspolitik der IBM neue Nahrung erhalten. Während man bei Cisco sehr schnell eine Reihe prominenter Mitstreiter für die APPI-lnitiative gewinnen konnte (vgl. CW Nr. 38 vom 18. September 1992, Seite 4: "Networking-Companies wollen APPN-Monopol der IBM brechen"), hielt man sich mit offiziellen Äußerungen über die Zielrichtung von APPI bisher bedeckt.

Um so deutlicher nun fiel aber das Statement vor der Presse in München aus. Brisanz erhielt dies vor allem aber auch durch die Tatsache, daß ausgerechnet Europa-Manager Rousset, der erst vor neun Monaten zusammen mit drei anderen Kollegen aus dem APPN-Entwicklerstab der IBM zu Cisco wechselte, diese Aufgabe zuteil

wurde. Bei dem Bemühen, dem blauen Riesen in seiner ureigenen SNA-Domäne Konkurrenz zu machen, scheuten die Cisco Verantwortlichen offensichtlich weder Kosten noch Mühen. "Kompetenz auf diesem Niveau können Sie in kurzer Zeit nicht selbst erwerben, sie muß eingekauft werden", meinte hierzu ein Cisco-Vertreter gegenüber der COMPUTERWOCHE.

Ab sofort verfolgt Cisco im Rahmen des "IBM-Internetworking-Planes" einen zweigleisigen Ansatz. Schwerpunkt bildet das eigene APPI, das nach Angaben der Kalifornier alle bekannten Internetworking Merkmale von TCP/IP-Netzen adaptives Routing, Unterstützung verschiedener Übertragungsmedien und -Protokolle, hohe Leistung etc. mit den SNA Peer-to-peer-Features verbinden soll.

Anders als IBMs APPN wird APPI allen Anbietern, Entwicklern und Anwendern kostenlos zugänglich sein und eine offene SNMP-MIB (Management Information Base) für die Netzverwaltung enthalten. Ein von Cisco initiiertes Konsortium, dem sich bereits Firmen wie Alcatel, British Telecom und Cabletron angeschlossen haben, will die offene Spezifikation und weitere Entwicklung von APPI überwachen.

Ciscos Entscheidung, eine Alternative zum APPN-Ansatz der IBM zu entwickeln, gründet sich, wie es weiter hieß, sowohl auf technische als auch auf Marktfaktoren. Zum einen gebe es derzeit weltweit mehr als 50 000 installierte SNA-Netze. Zum anderen sei jedoch aufgrund des Erfolges LAN- gestützter Client-Server-Architekturen das Bedürfnis der Anwender nach Übergangsmöglichkeiten auf verteilte Peer-to-peer-Netze gerade auch in traditionellen SNA-Umgebungen deutlich gestiegen. Die IBM mußte, so Insider Rousset, zur Kenntnis nehmen, "daß das herkömmliche SNA- Routing nicht mehr zeitgemäß ist", und habe "APPN zur neuen Lösung deklariert".

Herbe Kritik am technischen Profil von APPN

Alle Beteuerungen der IBM in puncto Offenheit von APPN sind jedoch nach Ansicht der Cisco-Experten nur Lippenbekenntnisse zumindest solange Big Blue nicht die Lizenzpolitik für den APPN-Quellcode ändere. Zu befürchten sei, daß IBM die Kontrolle über diesen Code behalten wolle und dadurch jegliche Veränderungen an der Spezifikation den Segen aus Armonk benötigten. Die Aufsicht über eine für die Industrie insgesamt so wichtige Softwarelösung sollte daher, so der offizielle Cisco-Standpunkt, nicht bei einem einzigen Hersteller liegen".

Hart ins Gericht gehen die kalifornischen Connectivity-Spezialisten aber auch mit dem technischen Profil von APPN. Es nutze nur einen Teil der Möglichkeiten eines "adaptiven Routings" - Features, die klassischen TCP/IP-Anwendern schon seit längerem zur Verfügung stehen. So richte APPN zwar einen anfänglichen Routing-Weg ein, verfüge jedoch über kein Verfahren zum "Rerouten", falls der anfängliche Weg verschlossen ist. Konsequenz: Bei einem Zusammenbruch dieses Weges sei die Sitzung schlichtweg verloren.

Darüber hinaus sei, wie es bei Cisco heißt, der Einsatz von APPN auf Token Ring-, SDLC und X.25 Komponenten begrenzt, während bis dato Ethernet-Topologien nur teilweise, Frame Relay und FDDI überhaupt nicht unterstützt werden Hinzu komme, daß die Fähigkeit von APPN, in einer Multiprotokoll-Umgebung neben an deren Protokollen zu bestehen noch nicht getestet worden sei. Außerdem bedeute die Implementierung von APPN die Hinzufügung eines weiteren Protokolls, das über den WAN-Backbone geroutet werden müsse und so das Management eben dieses Backbones erschwere.

Der Trend in der Industrie geht jedoch nach Auffassung der Cisco Verantwortlichen eher dahin, die Anzahl der verwendeten Protokolle zu senken. Deshalb würden die Anwender jeden Migrationsweg begrüßen, Peer-to-peer-Kommunikation über bestehende Verbundnetze und Dienste zu realisieren. Zudem könnten TCP/IP-Netze mittlerweile Zehntausende von Paketen pro Sekunde routen - deutlich mehr als das, was gegenwärtige APPN-Produkte vermögen. Eine IP-gestützte Alternative wie APPI würde folglich Leistungsmerkmale von der IP-Ebene auf den SNA-Bereich ausdehnen.

Um das Verhältnis zur IBM nicht vollständig zu trüben - immerhin wurde im "IBM Integrationsgeschäft" bisher nicht schlecht verdient - werden die Kalifornier mittelfristig also zwei Peer-to-peer-Varianten für die SNA-Umgebung implementieren: ein von der IBM lizenziertes APPN für Benutzer, die die IBM-Network-Node-Kompatibilität benötigen, und APPI für diejenigen Anwender, die laut Cisco "einen offenen Standard und gesteigerte Funktionalität bevorzugen".

Entsprechende Verhandlungen mit der IBM über die Lizenzierung des APPN-Quellcodes würden voraussichtlich erst, wie Cisco-Manager Rousset erklärte, Anfang 1993 aufgenommen, schließlich sei derzeit noch nicht absehbar, wie man in Armonk auf die APPI-Herausforderung reagiere. Bis zum dritten Quartal 1994 wolle man jedoch die Implementierung des IBM-APPN-Network-Node realisieren. Cisco-Router sollen ab diesem Zeitpunkt wahlweise APPI-oder APFN-Fähigkeiten unterstützen.

Gehen die Verhandlungen mit der IBM problemlos über die Bühne, wird Cisco die Verbindung von IBM-Network-Nodes mit solchen von OEMs ermöglichen. Die Anwender werden dann, so die Pläne der Entwickler aus Menlo Park, zwischen drei möglichen Peer-to-peer-Zugängen wählen können: IBMs APPN, das offene Standard-APPl-Set oder eine integrierte Kombination beider Protokoll-varianten.

Bis es jedoch soweit ist, will Cisco zunächst die eigenen APPI-Lösungen auf den Markt bringen. In einer ersten Stufe soll im dritten Quartal 1993 mit dem "Open Network Node" (ONN) ein Peer-to-peer-Router auf der Grundlage von IP-Vernetzungs-prinzipien zur Verfügung stehen. Jeder ONN wird dabei direkt mit entsprechenden End Nodes (EN) sowie Low Entry Networking Nodes (LEN) verbunden, die vollständige Verzeichnis- und Routing-Dienste für SNA-Sitzungen bereitstellen und dadurch Benutzern Peer-to-peer-Kommunikation über einen Multiprotokoll-Backbone ermöglichen (siehe Abbildung 1).

In einer zweiten Stufe, deren Realisierung für das erste Quartal 1994 vorgesehen ist, will Cisco die ONN-Spezifikationen um "SNA Intermediate-Rout-Funktionen" erweitern. Dies soll vor allem zu mehr Flexibilität bei der Netzgestaltung beitragen, weil die ONNs dann nicht nur als Zugangs- Router eingesetzt werden können, sondern auch als Intermediate-Router, um den SNA-Peer-to-peer-Verkehr zu transportieren (siehe Abbildung 2). Die Unterstützung von Intermediate ONN verbessere vor allem, so die Darstellung von Cisco, die Verschluß-und Durchflußkontrolle im Backbone und trage zu einem verbesserten Netz-Management auf

SNA-Ebene bei.