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.

03.11.1995

SNA Meets TCP/IP/Multiprotokoll-Router befoerdert SNA-Daten mit Hilfe von TCP/IP

Alles spricht vom Netzwerk der Zukunft und inwieweit Switch- Techniken die DV revolutionieren koennen. Doch die Betreiber von grossen Netzen, die in den meisten Faellen auf IBM-Systemen und SNA basieren, plagen ganz andere Sorgen: Wie koennen starre SNA- Installationen und flexible LAN-Strukturen unter einen Hut gebracht werden? Eine Antwort auf diese Frage war noch nie so dringend wie heute. Denn auch im Bannkreis des IBM-Hosts machen sich zusehends Client-Server-Anwendungen mit verteilten Kommunikations- und Verarbeitungslasten breit, die dem Unternehmensnetz mehr Flexibilitaet hinsichtlich Verbindungen und Bandbreite abverlangen.

Von Georg Goebel*

Die Installation von Multiplexern ist ein Weg zur Netzintegration, um LAN und SNA zusammenzufassen. Der Vorteil dieses Verfahrens liegt darin, dass Time Division Multiplexing (TDM) in diesem Fall die Vermittlung unterschiedlicher Datenstroeme ueber eine Verbindung uebernimmt und dadurch hilft, Leitungsverbindungen einzusparen. Ausserdem kann die zeitkritische, keinen Verzug zulassende Uebertragung etwa von Video und Sprache zusaetzlich integriert werden.

Der Einsatz dieser alten Technik hat jedoch den Nachteil, dass man weiterhin zwei getrennte Netze betreiben muss, die separat zu verwalten und pflegen sind. Darueber hinaus birgt diese Integrationstechnik noch ein weiteres Manko: Auf der Multiplexer- Verbindung muessen die Bandbreiten einzelner Kanaele starr festgelegt werden. Damit ist die TDM-Technik nicht in der Lage, sich dem stark schwankenden LAN-Verkehr flexibel anzupassen. Entweder werden die Bandbreiten einzelner Kanaele zu gross dimensioniert und damit in Zeiten niedriger Datenlast vergeudet, oder sie werden zu klein ausgelegt und koennen dann die Uebertragungsspitzen nicht mehr aufnehmen.

Frame-Relay-Dienst laesst noch zu wuenschen uebrig

Dem wechselnden Bandbreitenbedarf des LAN-Verkehrs passt sich hingegen die Frame-Relay-Technik optimal an. Via Frame Relay LAN- und SNA-Verkehr gemeinsam ueber eine Leitung zu uebertragen, heisst Bandbreiten nach dem Prinzip des statistischen Multiplexing nach Bedarf zuteilen. Leider ist Frame Relay in Deutschland noch etwas unterentwickelt. Die Telekom hat es mit dem Regeldienst Frame Link zwar unterdessen im Angebot, doch haelt sich der Durchsatz auf den WAN-Verbindungen in Grenzen. Geboten werden maximal 64 Kbit/s, in Schritten - sogenannten Committed Interface Rates (CIR) von 16 beziehungsweise 32 Kbit/s.

Wer via Frame Relay hoehere Durchsatzleistungen erreichen will, kann dies nur im eigenen Netz realisieren, mit entsprechenden Investitionen in Hardware und Netzbetrieb. Weitere Einschraenkungen bei der Netzintegration ueber Frame Relay: Der Dienst ist nur bedingt fuer die Vermittlung von Sprache und Video geeignet, weil auf Grund unterschiedlicher Paketlaengen und dynamischer Bandbreitenzuteilung keine zeitgerechte Anlieferung der Daten beim Zielsystem garantiert werden kann. Das Frame-Relay-Protokoll selbst raeumt zudem keine Moeglichkeiten ein, Anwendungen und Daten unterschiedliche Prioritaeten zuzuweisen und so bestimmte Datenstroeme bevorzugt zu behandeln.

Aufgrund dieser Einschraenkungen ist auch die von IBM propagierte Frame-Relay-Loesung eher mit Vorsicht zu geniessen, auch wenn sie mit dem Software-Upgrade fuer das IBM-Front-end kostenlos mitgeliefert wird. Zudem birgt die FEP-integrierte Loesung einen Unsicherheitsfaktor: Da sie bisher nur in kleineren Netzen mit wenigen Front End Processors (FEPs) zum Einsatz kommt, liegen keine Erfahrungen vor, ob der integrierte Software-Switch in groesseren Netzen auch Anforderungen wie Rerouting und Verkehrsfluss- Steuerung bei Datenueberlast auf den Verbindungen erfuellen kann.

Hier tritt der Multiprotokoll-Router-Backbone als Loesung auf den Plan. Er ermoeglicht, aufgrund ausgefeilter Router-Technik nicht nur den LAN- und SNA-Verkehr auf einer gemeinsamen Kommunikationsschiene - naemlich dem Multiprotokoll-Backbone - zu buendeln, sondern auch die LAN- und SNA-Welt unter einen Hut zu bringen. Ferner koennen beliebig grosse Netze gebildet sowie Bandbreiten nach Bedarf dynamisch zugeordnet werden.

Da Multiprotokoll-Router zudem - wie ihr Name bereits sagt - eine Vielzahl an unterschiedlichen LAN- und WAN-Techniken beherrschen, steht auch einer SNA-Integration in ein aeusserst heterogenes LAN- und WAN-Umfeld nichts im Wege. TCP/IP, IPX, Decnet, Localtalk und Vines werden unter anderem von leistungsfaehigen Multiprotokoll- Router-Systemen ebenso unterstuetzt wie X.25, DDV, ISDN, Frame Relay, Datex-M oder ATM.

Router ersetzt den teuren Front-end-Prozessor

Eine solche Loesung zahlt sich fuer den Anwender unter dem Strich aus, weil der Multiprotokoll-Router remote sehr oft den teuren FEP ersetzt. Dadurch koennen Leitungskosten sowie die hohen Investitionen in FEP-Lizenzen, FEP-Software-Gebuehren und die kostspielige Wartung dieser Systeme eingespart werden.

Besonders interessant ist der Multiprotokoll-Backbone spaetestens, seit dementsprechende Normen festgelegt wurden. Der Schluessel zu mehr Wirkungsbreite beim SNA-LAN-Zusammenschluss ist Data Link Switching, kurz DLSw. DLSw - eine Weiterentwicklung des Request for Comment RFC 1434 - wurde im APPN Implementors Workshop (AIW) von der Data Link Switching Working Group zum Standard RFC 1795 erkoren. Er definiert, wie SNA- und Netbios-Datenstroeme via TCP/IP zu uebertragen sind, und legt darueber hinaus Parameter fuer eine netzweite Flusskontrolle und Klassifizierung von Datenstroemen sowie ein systemuebergreifendes Netzwerk-Management fest. Genauer betrachtet, umfasst der DLSw-Standard aber nur ein Mindestmass an Definitionen, um Kompatibilitaet zwischen unterschiedlichen Herstellerprodukten zu gewaehrleisten. So fehlen beispielsweise Zusatzfunktionen wie Kanalanschluss und QLLC-Konvertierung.

Weit ueber dieses Mindestmass hinaus geht hingegen die Definition DLSw+ des Marktfuehrers Cisco Systems. Weil der Zuwachs an Funktionalitaet durch Erweiterung des DLSw-Standards um Ciscos Remote Source Route Bridging (RSRB) erreicht wurde, erweist sich DLSw+ als voll kompatibel zum DLSw-Standard. Die Zusatzfunktionen haben gute Chancen, in den DLSw-Standard aufgenommen zu werden. Einen Vergleich der Spezifikationen DLSw und DLSw+ zeigt die Tabelle. Die wesentlichen Unterschiede sind folgende:

- Mit DLSw ist nur das Einpacken des SNA- und Netbios-Protokolls in den TCP/IP-Rahmen geregelt.

- Mit DLSw+ ist zusaetzlich der Transport im HDLC-Rahmen sowie mit verkuerztem FST/IP-Paketkopf moeglich. Die letzte Methode ist dann sinnvoll, wenn die Fehlerwahrscheinlichkeit auf den Uebertragungsleitungen aeusserst gering ist, weil in diesem Fall nur eine kurze Pruefung des Vorspanns erfolgt.

- DLSw erlaubt nur Router-Installationen begrenzten Ausmasses (hoechstens 100 Router), weil saemtliche Beziehungen zwischen allen Router-Systemen im Netz nach TCP/IP-Adressstruktur definiert werden muessen. Eingeschraenkt wurde per Definition die Netzgroesse auch deshalb, weil die meisten Router im Markt aufgrund ihrer Prozessorleistung und Speicherkapazitaet nicht mehr als 100 TCP- Verbindungen gleichzeitig unterstuetzen koennen.

- DLSw+ umgeht das Netzlimit, indem es das Netzwerk in kleinere Einheiten, sogenannte Peer Groups, einteilt. Bei dieser Verfahrensweise muessen nur die Router-Beziehungen innerhalb der einzelnen Peer Groups, aber keine komplexen Aussenbeziehungen definiert werden. Die Aussenbeziehung uebernehmen eigenstaendig Border Peers. Bei Kommunikationsbedarf wird dann statt einer Kettenverbindung ueber viele Router-Systeme nur eine einfache Verbindungen zur naechsten Peer Group dynamisch geschaltet und nach Abschluss der Uebertragungsprozess sofort wieder abgebaut. Da die Verbindungsanforderung nur mit einem einzigen Explorer-Paket initiiert wird, kann zudem die Steuerdatenlast auf den Verbindungen erheblich gesenkt und dadurch die Verarbeitungslast im Internetsystem drastisch reduziert werden. Damit koennen auch weniger leistungsstarke Router als Border Peers die Vermittlung zwischen den Peer Groups uebernehmen.

- Zwar sieht DLSw auch Backup-Schaltungen im Fehlerfall und bei Datenueberlast auf den Primaerverbindungen vor. Die Umschaltung muss der Administrator jedoch selbst konfigurieren. Dadurch vergeht wesentliche Zeit, in der Uebertragungsdaten abhanden kommen. Daten muessen also aufwendig nacherfasst werden.

- DLSw+ macht die Kommunikation im Netz sicherer. Weil der Router den Ausfall einer Verbindung ueber das TCP/IP-Protokoll erkennt, kann er selbsttaetig eine andere Leitung schalten. Dabei laesst DLSw+ mehrere alternative Wege zu. In gleicher Weise koennen Backup- Verbindungen mittels DLSw+ eingerichtet werden, die dann bei Ueberlast auf der Primaerstrecke automatisch einen Teil des Datenaufkommens uebernehmen (Load Balance).

Besonders kostensparend ist die Multiprotokoll-Backbone-Loesung, wenn der Router direkt mit dem SNA-Host verknuepft wird - eine Verbindungsart, die zumindest im lokalen Bereich moeglich ist. In diesem Fall wird der FEP obsolet, weil der Router selbst die Vermittlerrolle des FEPs zum LAN-Segment - in der Regel Token Ring - uebernimmt. Dabei wird die Verbindung im Vergleich zum FEP wesentlich schneller. Ueber den Bus & Tag-Direktanschluss sind 4 MB/s, ueber den ESCON-Kanal sogar 17 MB/s moeglich.

Durch neue Funktionen beim Direkt-Kanalanschluss wie TCP/ IP offload wird die Leistung im Netz zudem drastisch gesteigert und der Host von der Verarbeitung des TCP/IP-Protokolls entbunden. Das funktioniert, weil TCP/IP offload die Verarbeitung des Protokolls im Multiprotokoll-Router abwickelt. Der SNA-Host muss sich nur noch um das TCP/IP-Paket kuemmern, das er via CLAW-Schnittstelle (Common Link Access for Workstation) vom Router erhaelt. Da der Multiprotokoll-Router gleichzeitig das Handling der SNA-Protokolle uebernimmt und sich dem Host gegenueber wie ein 3172-LAN-Gateway verhaelt, ist nur noch ein solches Geraet erforderlich, um den kompletten SNA- und LAN-Verkehr zu bewaeltigen.

Wie effektiv der Multiprotokoll-Router-Backbone als Integrations- Tool tatsaechlich ist, beweist IBM mit dem Front-end-Switch 3746- 950-Nways selbst, der gegen die Router-Loesung positioniert wurde. Es wird jedoch einige Zeit dauern, bis die IBM-spezifische Loesung den Stand der Technik beispielsweise der Cisco-Multiprotokoll- Router-Systeme erreicht hat. Neben der Tatsache, dass dieses neue IBM-System erst im Dezember 1995 verfuegbar sein soll, wird die erste Version weder X.25, Frame Relay, ISDN noch ATM unterstuetzen. Zudem geht die strikte APPN-Orientierung beim Front-end-Switch 3746-950-Nways voll auf Kosten der traditionellen Terminal-Host- Anwendungen, die immerhin heute noch rund 90 Prozent des Datenverkehrs in SNA-Netzwerken ausmachen.

Neben der Funktionsbandbreite von DLSw+ und dem direkten Kanalanschluss an den SNA-Host bieten Multiprotokoll-Router Features, um innerhalb des Unternehmensnetzes den SNA-Verkehr statt ueber IBM-typische Standleitungen ueber oeffentliche Netze mit X.25-, Frame-Relay-, ATM- oder SMDS-Protokoll zu schicken. Der Anwender kann also beim Transport seiner Daten flexibel auf den Uebertragungsdienst setzen, der ihm den groesstmoeglichen Nutzen bietet. Diese Funktionen werden durch den RFC-1490 und die QLLC- Unterstuetzung realisiert.

Den Einsatz proprietaerer Protokolle genau abwaegen

Mit RFC 1490 ist es moeglich, den SDLC-Datenstrom in Frame-Relay- Pakete zu verpacken und kostenguenstig ueber den Telekom-Dienst Frame Link zu versenden. Preiswert ist dieser Dienst schon deshalb, weil eine geringe Bandbreite (Committed Interface Rate) ausreicht und dennoch bei Uebertragungsspitzen automatisch und kostenlos zusaetzliche Bandbreite zur Verfuegung gestellt wird. Zudem muss der Anwender bei diesem Dienst nur fuer die tatsaechliche Uebertragungszeit zahlen. Wird einem Cisco-Router zum Beispiel ein Frame Relay Access Device vorgeschaltet, koennen zudem serielle SDLC-Datenstroeme ins geforderte Frame-Relay-Format umgesetzt und parallel andere Kommunikationsstroeme abgehandelt werden.

Mit der Unterstuetzung des IBM-spezifischen QLLC-Protokolls kann der Router zudem an Stelle des FEP in der reinen SNA-Umgebung die Vermittlung des SDLC-Datenstromes ueber das X.25-Netz uebernehmen. Als ein Multiprotokoll-faehiges System sorgt der Router zudem im Zielsegment fuer die Umsetzung in die geforderte LAN-Technik wie Ethernet, Token Ring oder FDDI.

Die Native Client Interface Architecture von Cisco markiert einen weiteren Schritt auf dem Weg zu einer Synthese von lokaler und IBM-spezifischer Netzwelt. NCIA ist eine Funktionalitaet, die als Software auf dem PC oder der PC-Karte zum Einsatz kommt und dort die Verpackung des SNA-Verkehrs im TCP/IP-Rahmen vornimmt. Diese Vorarbeit spart dem Router die aufwendige Konvertierung. Er muss sich nur um die Zielzuweisung kuemmern. Noch wird die Umsetzung gemaess Remote Source Route Bridging (RSRB) durchgefuehrt. Bald wird jedoch die DLSw+-Verpackung eingesetzt werden.

Advanced Peer-to-Peer Networking (APPN) wird von IBM als das Protokoll der Zukunft im SNA-Umfeld propagiert. Mit APPN hat IBM erstmals im SNA-Netz die Host-zentrierte Arbeitsweise gegen ein Peer-to-Peer-Modell ersetzt. Damit ist nicht laenger der Host der zentrale Vermittler, ueber den alle Datenstroeme laufen, sondern das Netz mit seinen intelligenten Netzknoten. Sie uebernehmen die direkte Verbindung zwischen den Kommunikationspartnern. Im Gegensatz zum Backbone-Protokoll TCP/IP ist APPN eine proprietaere Loesung, die vor allem fuer die SNA-Welt gedacht ist. Der Anwender sollte sich daher sehr genau ueberlegen, ob er dem herstellerspezifischen Weg folgen oder auf offene Protokolle vertrauen will.

Ein Weg, diese Entscheidung offenzuhalten, ist der Einsatz von Multiprotokoll-Routern, die beide Sprachen beherrschen. Die Integration der Funktion APPN ermoeglicht, auch die neuen SNA- Protokolle im Rahmen der Advanced Program-to-Program Communication (APPC) via Multiprotokoll-Backbone zu verarbeiten. Dabei steht die volle APPN-Network-Node-Funktion zur Verfuegung. Selbst traditionelle 3270-Anwendungen koennen ueber die Zusatzfunktion des Routers Dependent LU Requester (DLUR) und Dependent LU Server (DLUS) durchgefuehrt werden. Voraussetzung dafuer ist allerdings, dass auf dem SNA-Host VTAM 4.2 zum Einsatz kommt. Mit der Folgeversion von DLUR und DLUS wird die zweite Generation von APPN mit High Performance Routing (HPR) unterstuetzt werden und damit unter anderem auch das unterbrechungsfreie Rerouting von SNA- Sitzungen.

Der FEP-Ersatz hilft Betriebskosten reduzieren

Die Kostenersparnis, die durch den Einsatz eines Multiprotokoll- Backbones erzielbar ist, kann immens sein. Gleichzeitig kann das Unternehmen trotz starrer SNA-Architektur mit dieser Technik sanft zur Client-Server-Verarbeitung migrieren. Ein Beispiel aus der Praxis eines fraenkischen Herstellers von Waelzlagern: Durch Abloesung aller dezentralen FEPs werden Kosten in Hoehe von 400000 Mark pro Jahr eingespart. Dazu konnte sich das Unternehmen jeweils eine der beiden Datendirektverbindungen zwischen der Zentrale und den fuenf Niederlassungen sparen, wodurch sich die Leitungskosten um jaehrlich 60000 Mark reduzieren. Auch an der Wartung wird kraeftig gespart, denn die Router-Loesung kann, im Gegensatz zu den FEPs, vom eigenen Personal gepflegt und gewartet werden. Insgesamt hatte sich die Investition in den Multiprotokoll-Backbone bereits nach einem Jahr amortisiert.

Das Multiprotokoll-Router-Netz ist zudem heute in vielen Networks von Banken und Sparkassen der Einstieg in eine Client-Server-Welt, weil es den Netzbetreibern Kostenvorteile gegenueber den alten SNA- Methoden der FEPs und Cluster-Controller bietet. Ganz zu schweigen von der Offenheitund Standardisierung dieser Loesung.

*Georg Goebel ist Leiter Produkt Marketing der Telemation Gesellschaft fuer Datenuebertragung mbH in Oberursel.