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.

01.04.1994

Vielfalt der Protokolle bringt den Netzbetrieb ins Schleudern

Das "Multi" heutiger Netzwerke - multifunktionaler Arbeitsplatz, Multimegabit, Multi-Segment-Hub, Multiprotokoll-Router, Multiuser- Betrieb, Multimedia, Multivendor - hat etwas unbewusst Verfuehrerisches: die Suggestion, es ginge immer noch eine Anwendung, ein Protokoll mehr. Dabei werden jedoch oft die zunehmenden Wechselwirkungen und der steigende Betreuungsaufwand fuer "Multi-Internetzwerke" von Anbietern verschwiegen und von Netzplanern zuwenig beachtet. Petra Borowka* skizziert in diesem Beitrag Integrationsansaetze und notwendige Konsequenzen fuer den Parallelbetrieb von Anwendungen und Protokollen in einer gemeinsamen Netzinfrastruktur.

Der Einsatz mehrerer Protokolle innerhalb eines Unternehmensnetzes im parallelen Netzbetrieb ist Betriebsrealitaet. Verschieden strukturierte Subnetze mit unterschiedlichen Hersteller- und Protokollwelten sind ueber Backbone-Konfigurationen zu verbinden. Dabei ist zu entscheiden, wie viele und welche Protokolle auf dem gemeinsamen Backbone zugelassen werden: Einerseits sind Betreuungskomplexitaet und wechselseitige Beeinflussung von Protokollen zu reduzieren, andererseits dient der Backbone gerade dazu, Kommunikation zwischen den verschiedensten Systemen zu ermoeglichen.

Erfahrungen zeigen, dass Multiprotokoll-Backbones anfaelliger fuer Fehler sind und weniger leistungsstark arbeiten als im Single- Betrieb. Die Schwierigkeiten beginnen bei der Aufteilung des Netzes in logische Netzwerke: Beim Einsatz von Decnet, Transmission Control Protocol/Internet Protocol (TCP/IP) und Internetwork Packet Exchange (IPX) wird das Netz entsprechend der Decnet-, TCP/IP- und IPX-Benutzer dreimal unterteilt. Dabei ueberschneiden sich diese Teile beliebig, statt deckungsgleich zu sein, wie es eine geordnete Struktur erfordern wuerde. Weitere Multikandidaten sind Appletalk, Vines, Open Systems Interconnection (OSI), Xerox Network Services (XNS), Advanced Peer-to-peer Networking (APPN).

Protokollmix erfordert Multiprotokoll-Router

Hinzu kommt fuer jede Protokollwelt ein eigenes Routing-Protokoll mit separaten Metriken und Tuning-Parametern, mit der Konsequenz separater Routing-Tabellen je Protokoll, die der Router ueber einzelne Prozesse parallel handhaben muss (vgl. Abbildung 1).

Der Vorteil des parallelen Betriebs verschiedener Protokolle liegt darin, Netzbetreibern ein optimales Tuning zu ermoeglichen. Diverse Protokolle lassen sich ueber verschiedene Verbindungen leiten und koennen so redundante Netzverbindungen effizient ausnutzen. Wie neutrale Tests gezeigt haben, bringen herstellereigene Protokolle fuer die betriebenen Anwendungen oft den groessten Durchsatz: In der SNA-Welt (Systems Network Architecture) liefert Advanced Programm- to-program Communication (APPC) einen groesseren Durchsatz als TCP fuer Transaktionsanwendungen (Faktor 2 innerhalb eines Subnetzes, Faktor 1,3 ueber zwei Subnetze geroutet). APPN ist beim File- Transfer schneller als FT Protocol (FTP) (Faktor 3,5 innerhalb eines Subnetzes, Faktor 5 ueber zwei Subnetze, Faktor 0,5 ueber WAN geroutet; getestet wurde TCP fuer OS/2 von FTP Software). Allerdings differieren die Ergebnisse je nach getesteter FTP- Version und Systemplattform (TCP/IP fuer OS/2 von IBM arbeitet zum Beispiel schneller als die Software von FTP).

Die beibehaltene Vielfalt bedingt jedoch einige Nachteile: Der Einsatz von teuren Multiprotokoll-Routern ist erforderlich. Die Betreuung vieler Protokolle gestaltet sich aeusserst aufwendig, und die erforderliche CPU-Leistung sowie die Speicherkapazitaet eines entsprechenden Routers sind hoch. Im WAN-Bereich fuehrt Multiprotokoll-Betrieb oft zu hohen Kosten aufgrund notwendiger Ueberkapazitaeten, sollen sich verschiedene Protokolle nicht negativ auf die Performance auswirken.

Die Integration der SNA-Welt verschaerft das Leistungsproblem, da der typischerweise Burst-artige LAN-Verkehr schwankende SNA- Antwortzeiten produziert, was von Terminal-Benutzern keinesfalls akzeptiert wird. Als Folge ist deshalb die Leitungskapazitaet zu erhoehen.

Die Implementierung eines weiteren (neuen) Protokolls fuehrt oft zu einem Redesign des Netzwerks, weil die verschiedenen Protokolle unterschiedliche logische Segmentierungen erfordern (TCP/IP und Decnet bieten wesentlich mehr Strukturmoeglichkeiten als beispielsweise Appletalk und IPX).

Es gibt keine uebergreifende Ueberlastkontrolle, das heisst, falls ein Protokoll Ueberlast produziert, werden alle anderen Protokollwelten in Mitleidenschaft gezogen. Anders ausgedrueckt: Jedes Protokoll versucht soviel Bandbreite wie noetig fuer sich selbst zu ergattern und reduziert die Senderate erst bei hohen Verzoegerungszeiten oder vermehrten Paketverlusten. Ist eine Sendekontrolle nicht moeglich, gibt es irgendwann einfach ein Session-Time-out, zum Beispiel bei LAT oder Netbois.

Parallele Backbones sind teuer und unuebersichtlich

Dabei muss die Ueberlast, die den Time-out verursacht hat, nicht unbedingt zur Gruppe der Geschaedigten gehoeren. Das Verursacherprinzip wird also nicht gewahrt. Prioritaetenvergabe fuer einzelne Protokolle in Multiprotokoll-Routern, die diese Funktion unterstuetzen, stellt eigentlich das kleinste Uebel dar. Wer das Opfer ist, wird nicht dem Zufall ueberlassen, sondern vorher festgelegt. Es fehlen Management-Tools, die parallele Protokolle integrieren. Meistens wird je Protokollwelt eine separate Netzkarte angelegt, die die jeweiligen logischen Strukturen wiedergibt (ein lobenswerter Ansatz ist hier die integrierte Node Discovery fuer IP, Decnet unter anderem in HP Openview).

Die heute vielfach betriebenen parallelen Backbones fuer SNA (FEPs) und LAN (Router mit zusaetzlicher Bridge-Funktion) sind ebenso unuebersichtlich wie teuer. Zwei wesentliche Techniken wurden zur SNA-Integration ueber LAN entwickelt: SDLC-LLC-Konvertierung (SDLC = Synchronous Data Link Control, LLC = Logical Link Control) und TCP-Enkapsulierung. So lassen sich vorhandene FEP-Backbones abloesen und die neu aufgebauten LAN-Backbones mit benutzen.

SDLC-LLC-Konvertierung integriert SNA ins LAN

SDLC-LLC-Konvertierung ist eine Technik, die in den letzten beiden Jahren zur SNA-Integration entwickelt wurde. SDLC-LLC-Konverter oder -Router, die SDLC-LLC-Konvertierung leisten, werden an die SDLC-Ausgangsleitung einer Steuereinheit 3x74 oder eines FEP angeschlossen und transformieren den entsprechenden Datenstrom von SDLC-Format nach Token-Ring- oder Ethernet-LLC-Format und umgekehrt. Dies erspart eine Ausruestung der Steuereinheiten mit Token-Ring-Interface und ermoeglicht bei einem LAN-WAN-Verbund mit Token Ring oder Ethernet die Abloesung von FEPs in remoten Standorten. Am zentralen Host ist es entweder ein FEP (3745, 3746) oder ein LLC-SDLC-Konverter, der den Datenstrom wieder nach SDLC ruecktransformiert. Da die Konvertierung im LAN-WAN-Bereich rein auf Source-Routing-Technik beruht, kann im Fehlerfall kein dynamisches Re-Routing erfolgen. Die Session muss per Source- Routing-Route-Discovery neu aufgebaut werden (vgl. Abbildung 2).

TCP/IP-Enkapsulierung ueber Router ist eine Technik, nicht routbare Protokolle wie SNA und Netbios im WAN-Bereich dynamisch routbar zu machen und die Begrenzung des Token-Ring-Source-Routings auf sieben Hops (sieben Bruecken/Router) aufzuheben. Auch IBM hat den Vorteil der Technik eingesehen und benutzt zusammen mit Herstellern wie Cisco, 3Com, Wellfleet und Proteon DLS (Data Link Switching) nach RFC 1434 als gemeinsame Basis, solange sich die heterogene Welt noch nicht mehrheitlich zu APPN als generelles Protokoll bekennt.

Fuer das Host-Management (Netview) stellt sich die WAN-Leitung bei TCP-Enkapsulierung wie eine fehlerfreie SDLC-Leitung oder Token Ring dar. Bei entsprechender Redundanz wird von den Routern im Fehlerfall dynamisch umgeleitet, da Netview keinen Zugriff auf die Router und TCP-basierte Weiterleitung hat. Die FEPs und Steuereinheiten aufwaerts und abwaerts zur Router-Verbindung sind jedoch nach wie vor mit Netview zu managen.

Der Wunschtraum vieler Netzbetreiber, dem parallelen Backbone fuer SNA und LAN ein Ende zu machen, das heisst Front-end-Equipment in Millionenhoehe auf den Gebrauchtmarkt zu werfen und statt dessen billige Router einzusetzen, liess sich bisher nur sehr eingeschraenkt verwirklichen. Ein Kernproblem bei Multiprotokollbetrieb mit SNA liegt darin, konstante Antwortzeiten fuer SNA-Anwender zu erhalten. Dies ist bei Lastprofilen mit Megafiles von LAN-Anwendungen und kurzen Terminalpaketen in Hochlastzeiten mittels FIFO-Abarbeitung (First in, first out) kaum moeglich. Einige Bruecken- und Router-Hersteller haben daher Funktionen entwickelt, die verschiedene Protokolle mit unterschiedlicher Prioritaet belegen und somit zum Beispiel eine bevorzugte Bewaeltigung des SNA-Verkehrs vor anderen Protokollen ermoeglichen. Zwei Priorisierungsklassen existieren:

Bei absoluter Priorisierung wird je Prioritaetsklasse eine separate Warteschlange fuer die Abarbeitung aufgebaut. Hoeher gewichtete Warteschlangen werden bis zum Ende abgearbeitet. Erst dann sind die uebrigen Warteschlangen an der Reihe. Bei relativer Priorisierung wird je Prioritaetsklasse eine separate Warteschlange aufgebaut. Dieser wird nun ein entsprechender Anteil an der gesamten Bearbeitungskapazitaet zugeordnet (zum Beispiel SNA 60 Prozent, IPX 25 Prozent, TCP 15 Prozent).

Eine Standardisierung von Prioritaetsmechanismen bei Multiprotokollbetrieb ist nicht in Sicht, und die Implementierungen aller Hersteller sind unterschiedlich und nicht kompatibel. Die noch recht neue Technik der Protokollpriorisierung im heterogenen LAN bringt einige Risiken fuer Anwender:

- Die Bevorzugung von SNA-Verkehr erhoeht die Antwortzeiten anderer Protokolle, unter Umstaenden bis zum Time-out. Dieser Fall kann eintreten, wenn keine relative, sondern eine absolute Priorisierung vorliegt.

- Es gibt nur wenig Erfahrungswerte, wie gut die Priorisierung bei laenger dauernden Bursts (mehrere Sekunden) und Ueberlast der WAN- Leitungen tatsaechlich arbeitet.

- Die Nutzung von Priorisierungsfunktionen legt den Anwender praktisch auf einen Hersteller fest.

In jedem Fall ist eine Abloesung des SNA-Backbones nur schrittweise ueber ausfuehrliche Testphasen anzuraten.

Zum Reduzieren der Multieffekte im Netzwerk gibt es folgende Integrationsansaetze auf verschiedenen Ebenen: Nutzung eines gemeinsamen Protokoll-Stacks, eines einheitlichen Transportprotokolls sowie eines einheitlichen Routing-Verfahrens.

Die praktische Loesung, einen Single-Protokoll-Backbone zu erzwingen, solange noch kein integriertes Protokoll zur Verfuegung steht, ist der mehrfache Gateway-Einsatz oder Enkapsulierung in ein weit akzeptiertes Protokoll, wie es heute nur TCP/IP sein kann. Die Nutzung eines gemeinsamen Protokoll-Stacks fuer alle Kommunikationsaktionen ist im Vergleich zu verfuegbaren Anwendungen auf proprietaeren Stacks jedoch nach wie vor eingeschraenkt.

Auch wenn immer mehr Anwendungen direkt auf TCP aufsetzen - bedeutsam ist hier die Option TCP statt IPX ab Netware 4.x -, hat die voellige Restriktion auf ein einzelnes Transportprotokoll als Strategie bis jetzt noch keine breite Akzeptanz gefunden.

Zur Integration von OSI- und TCP/IP-Routing (IS-IS und OSPF) und Decnet wurde von Digital 1990 der RFC 1195 erarbeitet. Integriert werden Systeme, die IP- oder OSI-Adressierung nutzen. Das IS-IS- Frame wird um einige Informationen erweitert, um IP-Kommunikation durchfuehren zu koennen. Die erreichte Integration geht allerdings auf Kosten von Optionsmoeglichkeiten in OSPF. Kuenftig ist auch die Integration von IPX und Appletalk ueber Integrated IS-IS geplant. Der Vorteil dieser Loesung liegt auf der Hand: unterschiedliche Netzadressierung der einzelnen Protokolle mit einheitlicher Netzwege- und Ueberlaststeuerung sowie nur noch einer Routing- Tabelle.

Mit dem Integrationsvorteil werden jedoch einige Nachteile eingekauft: Die jeweils fuer einzelne Protokollwelten optimierten Metriken werden aufgegeben. Die Anpassung aller derzeitigen Applikationen auf ein gemeinsames Traegersystem ist sehr aufwendig. Teilweise wird sie durch eine Art Gateway-Modul zwischen oberen und unteren Protokollschichten geloest werden, der wenig Leistung bringt. Es ist schwierig, die historisch gewachsenen, aeusserst unterschiedlichen Adressstrukturen verschiedener Protokollbereiche in einem gemeinsamen Strukturierungskonzept zusammenzufuehren.

Ein weiterer Integrationsansatz ist das neuerdings von IBM angestrebte Multiprotocol Transport Network (MPTN) in der Produktlinie Anynet. Hierbei wird die feste Bindung einer Anwendung an ein bestimmtes Transportprotokoll geloest (TCP, APPN, IPX in ferner Zukunft). Dazu wird ein Adaptionsmodul, das de facto ein Gateway auf Schicht vier darstellt, zwischen Netzwerk und hoeheren Schichten eingefuegt und somit die Luecke geschlossen. Es leistet die Anbindung an eines von mehreren verfuegbaren Transportprotokollen. So laesst sich eine urspruengliche SNA- Anwendung dann ueber TCP-Sockets transportieren und umgekehrt eine Unix-Anwendung auf SNA. Das Adaptionsmodul entspricht nach oben einer von IBM definierten Schnittstelle Common Transport Semantics (CTS), auf die Anwendungen unabhaengig von unterliegenden Protokollen aufsetzen koennen (vgl. Abbildung 3).

Fuer Umgebungen, die schon stark heterogen gepraegt sind, ist ausser einem erleichterten Zugriff auf traditionelle SNA-Anwendungen kein weiterer Vorteil absehbar, was eine unternehmensweite MPTN- Implementierung zum aktuellen Zeitpunkt in Frage stellt. Die Idee, den Anwender endlich vom benutzten Transportprotokoll zu befreien, wurde auch von Microsoft in Windows NT und NT Advanced Server aufgegriffen: Hier ist eine Transport-Schnittstelle definiert (Transport Driver Interface, TDI), die wahlweise auf Netbeui, TCP oder IPX aufsetzt.

Wie weit sich die MPTN- oder TDI-Ansaetze im Markt etablieren werden, bleibt abzuwarten. Als Gegenargumente lassen sich auffuehren:

- die noetige Anpassung einer riesigen Basis von Anwendungen, die derzeit ueber native Protokollbindung laufen;

- Leistungsverluste durch das Adaptionsmodul;

- zunehmende Portierung vieler Anwendungen auf natives TCP sowie

- bereits realisierte Multiprotokollfaehigkeit der Adapterkarten mit Network Device Interface Specification (NDIS) und ODI.

Probleme, die den Netzbetrieb zum Risiko machen, sind nicht nur auf technische Unzulaenglichkeiten, sondern auch auf organisatorische Unternehmensablaeufe zurueckzufuehren: Die Zustaendigkeiten verteilen sich auf mehrere Abteilungen, was Absprachen erschwert. Etablierte Machtbereiche im Unternehmen stehen einem optimierten Netzbetrieb entgegen. Ein projektbezogener Beschaffungsansatz statt koordinierter Erweiterungsplanung fuehrt zu Entwicklungen in verschiedenen Netzteilen, die sich gegenseitig behindern. Zu kleine Netzbetriebsmannschaften machen eine adaequate Planung und Entwicklung von Netzerweiterungen unmoeglich. Permanente Umzugsaktivitaeten (rund 30 Prozent im Durchschnitt in groesseren Unternehmen) binden zuviel Manpower.

Fazit: Mehr denn je wird deutlich, dass eine beliebig wachsende Protokollvielfalt im Unternehmensnetz auf Dauer nicht praktikabel ist. Welcher Ansatz sich langfristig durchsetzen wird - ein gemeinsames Netzwerk- und Routing-Protokoll oder reduzierte, aber weiterhin parallel betriebene Protokollvielfalt -, ist derzeit nicht absehbar. Die jahrelange Verzoegerung von OSI einerseits und die starke Ausweitung von TCP/IP-Installationen andererseits geben dem parallelen Ansatz, insbesondere mit der Verfuegbarkeit vielfaeltiger Multiprotokoll-Router-Produkte, derzeit bedarfsbedingtes Uebergewicht und praktische Vorteile. Hier gilt es die Anzahl der betriebenen Protokolle auf ein vernuenftiges Mass zu beschraenken. Der vernuenftigere Ansatz ist Integrated IS-IS oder die Einigung auf irgendein anderes Kompromissprotokoll.

Zusammen mit staendig steigenden anwendungsbedingten Kapazitaetsanforderungen wird in den naechsten Jahren verstaerkte Netzstrukturierung mit hoher Backbone-Kapazitaet einsetzen oder weiterentwickelt werden. Dabei gibt es einige Gewinner:

- Ethernet an erster und Token Ring an zweiter Stelle etablieren sich als die Standard-LANs auf Abteilungsebene.

- Hubs zur Endgeraeteanbindung, zur strukturierten Verkabelung, Segmentierung und Bildung von Collapsed Backbones erleben in den naechsten zwei Jahren den Hoehepunkt ihres Booms.

- Router-Einsatz zur LAN-WAN-Kopplung und standortinternen Backbone-Bildung erreicht zunehmende Verbreitung.

- TCP/IP erfaehrt weitere Verbreitung auch im Netzwerk-Management- Bereich ueber SNMP, und

- etablierte Protokolle im PC-Bereich (IPX, Appletalk) werden vorerst nicht durch OSI verdraengt, sondern auch von grossen Herstellern mit traditionell gegenlaeufigen Interessen integriert und unterstuetzt.

Demgegenueber sind als Verlierer einzustufen:

- traditionelle Host-Terminal-Netze (IBM, Siemens);

- TDM-Netze;

- proprietaere Protokolle, die nur mangelhaft offengelegt werden (Decnet, SNA);

- proprietaere Hersteller-Management-Systeme;

- OSI mit Ausnahme von X.400 und EDI-Nebenstellenanlagen sowie

- DQDB als MAN.

Einige Entwicklungen sind hinsichtlich ihrer Marktrelevanz mit hohem Unsicherheitsfaktor behaftet:

- Multimedia,

- Integriertes Routing (Integrated IS-IS),

- einheitliche Transport-Interfaces (MPTN, TDI),

- ATM als einheitliches Uebertragungsverfahren sowie

- FDDI bis zum Endgeraet.

Internetworking

im multifunktionalem Netz stellt den Anwender oft vor Probleme: Unterschiedliche Protokolle muessen integriert und die logische Segmentierung angepasst werden.

Eckwerte zur

Optimierung des Netzbetriebs

- Einschraenkung der Protokollvielfalt im Backbone-Bereich;

- Reduzierung nicht Rout-faehiger Protokolle in komplexen Multivendor-Netzen;

- Wahl offener Routing-Protokolle;

- Verbesserung des Netzbetriebs durch strukturierte Connectivity- Planung;

- verbesserte Organisation und Tool-Einsatz zum Netzwerk- Management;

- unternehmensweit abgestimmte Komponentenbeschaffung sowie

- Einfuehrung neuer Technologien wie SNA-Passthrough, DLS, Protokollpriorisierung nur ueber Piloten.