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.

04.06.1993

Komponenten wachsen mehr und mehr zusammen

Vor dem Hintergrund, heterogene Systeme in der unternehmensweiten Netzinfrastruktur mehr und mehr verbinden zu muessen, haben sich die Anforderungskriterien der Netzadminstratoren an Internetworking-Komponenten geaendert. Die Hersteller trugen dieser Tatsache zum Teil Rechnung, wodurch es zu einem Prozess des Zusammenwachsens der Komponentenklassen sowie einer Weiterentwicklung der Kommunikationstechniken kam. In den Mittelpunkt des Interesses sind

dabei die Hubs gerueckt, die ihrereseits mehr und mehr Bruecken- und

Router-Funktionalitaeten und Switching-Merkmale uebernehmen.

Von Petra Borowka*

Aufgrund der Realisierung der

Media-Access-Control-Funktionalitaet (MAC) benoetigen Bruecken fuer die Paketbearbeitung eine Verarbeitungszeit im Bereich von m-Sekunden (ms) bis Millisekunden. Prinzipiell sind zwei Brueckentypen zu unterscheiden: lokale und remote Bruecken. Die lokale Bruecke hat zwei oder mehr Ports, ueber die sie ihre angeschlossenen Subnetze verbindet.

Lokale Bruecken verbinden LAN-Segmente direkt, als Subnetzkopplung innerhalb eines Unternehmens- oder Campus-Netzes. Die Verbindung wird ueber die LAN-Ein- und -Ausgangsports der Bruecke hergestellt, das heisst mit Ein- und Ausgangsgeschwindigkeiten der LAN- Bandbreite. Bei LANs gleichen Typs erfolgt die Verbindung relativ problemlos. Handelt es sich jedoch um verschiedene MAC-Protokolle an den Ein- und Ausgangsports, muss zur Umsetzung vom schnelleren LAN (zum Beispiel 100 Mbit/sauf das langsamere (zum Beispiel 10 Mbit/s) ausreichend Pufferplatz fuer eine Zwischenspeicherung der Pakete vorhanden sein.

Remote Bruecken verbinden ihrem Namen entsprechend Subnetze ueber Weitverkehrsstrecken, also reine Backbone-Strecken ohne eigene angebundene Endstationen. Diese Bruecken sind immer mindestens paarweise installiert. An beiden Endpunkten einer Weitverkehrsstrecke zwischen zwei LAN-Subnetzen wird dann jeweils eine remote Bruecke implementiert, die einen oder mehrere Ethernet- Ports sowie einen oder mehrere remote Ports haben kann. Die meisten Weitverkehrsbruecken besitzen genau einen Ethernet- und je nach Bedarf ausbaubar ein bis acht remote Ports, die zum Beispiel ueber X.21 mit Geschwindigkeiten von 9.6 Kbit/s bis Mbit/s arbeiten. Oft ist die aggregierte Bandbreite, auch Summenkapazitaet genannt, jedoch auf maximal 2 oder 4 Mbit/s begrenzt, das heisst, es koennen nicht alle acht Ports mit 2 Mbit/s installiert werden - dies wuerde die Verarbeitungs- und Pufferkapazitaet der Bruecke bei voller Auslastung aller Weitverkehrsstrecken ueberschreiten.

Da remote Bruecken je nach Kapazitaet der DFV-Leitungen sehr grosse Kapazitaetsunterschiede vom LAN zum Weitverkehrsnetz ausgleichen muessen, spielt der Pufferplatz (Abfangen von Lastspitzen) und die Puffer-organisation eine wesentlich groessere Rolle als bei lokalen Bruecken zur reinen LAN-LAN-Kopplung. Auch die Implementierung eines Spanning-Tree-Algorithmus (Unterdrueckung von Paketzyklen) ist komplexer.

Ein Router verbindet Subnetze wie oben beschrieben gemaess Ebene 3 des OSI-Referenzmodells. Durch die Kopplung auf Ebene 3 koennen unterschiedliche Ebene-2-Protokolle sehr gut ausgetauscht werden: Es gibt zum Beispiel keine Schwierigkeiten mit vorhandenen oder nicht vorhandenen Typfeldern und unterschiedlichen maximalen Frame-Laengen.

Aufgrund der implementierten Ebene-3-Intelligenz stellt eine Router-Kopplung im Vergleich zur Bridge-Kopplung komplexere und effizientere Moeglichkeiten zur Verfuegung, redundante Netzstrukturen hinsichtlich dynamischer Wegwahl und alternativer Routen auszunutzen: Durch den Einsatz von Netzwerkadressen lassen sich hierarchische Netzstrukturen (Unterteilung in verschiedene Klassen von Subnetzen) realisieren. Allerdings liegt durch den hoeheren Protokoll-Overhead die Paket-Bearbeitungszeit eines Routers je nach Konfiguration im Bereich von 100 ms bis weit ueber 1000 ms.

Im Gegensatz zu Bruecken interpretiert ein Router nur die Pakete, die direkt an ihn adressiert sind (kein Promiscuous Mode), in puncto Default erfolgt kein Pakettransport. Nur wenn das Zielnetz bekannt ist, wird ein Paket weitergeleitet. Broadcasts werden nicht weitertransportiert, sondern bei routbaren Protokollen vom Router bearbeitet.

Aufgrund der komplexeren Wegwahl-Funktionalitaet und der Unterbindung von Default-Transport sind Router insbesondere zur LAN-Interconnection ueber Weitverkehrsnetze sowie zum Handling logischer Subnetz-Strukturen auf Ebene 3 des OSI-Referenzmodells geeignet.

Vom Typ her lassen sich Router in Single Protocol Router, Multiprotocol Router und Hybride Router unterscheiden. Single Protocol Router bearbeiten nur ein Protokoll und werden heute nur noch in Ausnahmefaellen eingesetzt. Stand der Technik ist der Multiprotokoll-Router, der in steigendem Masse in den letzten zwei bis drei Jahren Verbreitung fand, wodurch der Router-Einsatz bei der Komplexitaet heutiger Netze als Alternative zum Brueckeneinsatz erneut interessant wurde.

Multiprotokoll-Router sind in der Lage, im Gegensatz zu

Single-Protocol-Routern mehrere Protokolle parallel zu handhaben. Ueber verschiedene Protokoll-Stacks (Implementierung mehrerer Layer-3-Protokolle), die in einem Geraet implementiert sind, werden verschiedene logische Netze jeweils untereinander verbunden (Decnet-Decnet, IP-IP, ...). Dadurch werden Mehrfach-Backbones (je Protokoll ein logischer Backbone mit einem eigenen Typ von Single Protocol Router) eliminiert - ein einziges Geraet im Backbone reicht zur Kopplung aller unterstuetzten Protokollwelten aus.

Beim Empfang eines Paketes stellt der Router fest, zu welchem Protokoll es gehoert und verarbeitet es mit der entsprechenden Protokollroutine weiter. Die Verbindung verschiedener Protokollwelten erfolgt auch bei Multiprotokoll-Routern nur im Sinne einer LAN-WAN-LAN-Kopplung (zum Beispiel Decnet - X.25 - Decnet, IP - X.25 - IP), nicht zwischen verschiedenen LAN- Protokollwelten.

Die Produkterweiterung in Richtung Brueckenfunktionalitaet ist der Hybride Router (andere Namen: Bridge/Router, Bridging Router, Routing Bridge, Brouter oder auch einfach nur Router, da alle etablierten Router inzwischen auch bridgen koennen) als erweiterter Multiprotokoll-Router. Alle Pakete, die nicht geroutet werden koennen, weil das entsprechende Protokoll nicht im Router implementiert oder ueberhaupt nicht routbar ist, werden mit Brueckenfunktionalitaet bearbeitet. Dabei verwendet das Geraet wieder den Promiscuous Mode, in dem alle Pakete zur Weiterverarbeitung empfangen werden. Erst nach Interpretation der Kontrollinformation wird entschieden, ob das Paket geroutet oder gebridged wird.

Mit der Brueckenfunktionalitaet werden in der Regel gleiche LANs verbunden (Ethernet - Ethernet, Token Bus - Token Bus). Vorteil ist die im Entwicklungszyklus neu erreichte Protokoll- Unabhaengigkeit: Es koennen wieder alle Anwendungen quasi transparent ueber einen hybriden Router laufen. Diese Router- Erweiterung war notwendig, um Router im Markt zu etablieren: Halten sich doch einige nicht routbare Protokolle wie LAT, Netbios und SNA in produktiven Umgebungen sehr hartnaeckig - und diese Protokolle koennen nur mit Brueckenfunktionalitaet bearbeitet werden. Ein Router ohne Bruecke ist somit fuer den Anwender nur die halbe Miete.

Bei hohem subnetzuebergreifendem Verkehr stellen sowohl Bruecken als auch Router einen potentiellen Engpass dar. In diesem Fall ist unter Umstaenden ein Redesign der Subnetzstruktur erforderlich.

Bruecken und Router werden als Box mit entsprechender Firmware und Software ausgeliefert oder auch als Software-programm, das auf einem mehr oder weniger beliebigen PC laufen kann. Die Leistung haengt im letzteren Fall entscheidend davon ab, welcher PC eingesetzt wird. In den letzten zwei Jahren integrieren darueber hinaus mehr und mehr Hub-Hersteller Bruecken und Router als Einschubmodule in einen Hub, oft als OEM-Karten in Zusammenarbeit mit entsprechenden Bruecken- und Router-Herstellern.

Die Boxarchitekturen sind kaum noch PC-basiert, sondern mit speziellen Chips wachsender Anzahl und Guete (Motorola 68040, AMD 29000) ausgeruestet. Es sind meistens Rack-montierbare Slot-Modelle (ACC, Cisco, Coral, Digital, 3Com, NSC/Vitalink, Proteon, Retix, RND, Wellfleet e.a.), die entsprechend den gewuenschten LAN- und WAN-Anbindungen modular aufgeruestet werden koennen. Fuer eine Reihe von Produktlinien gibt es zusaetzlich kleine festkonfigurierte Einstiegsmodelle. Zukuenftig scheint bei grossen Netzen mit wachsenden Anforderungen an den Durchsatz und der Forderung nach Multiport-Kopplungen eine Boxarchitektur mit schnellem Backplane-Bus und der Moeglichkeit von Multiprozessor-Einsatz erstrebenswert.

PC-Loesungen lassen sich unterscheiden nach dediziert eingesetzten PCs und WAN-Einschubkarte in einem Server (der noch Kapazitaet zum Routen uebrig hat) plus Software.

Vereinfacht gesagt, ist ein Hub genau das, was der Netzbetreiber als Modul auf die Backplane aufgesteckt hat. Das variiert von Glasfaser- ueber Konzentratorkarten bis zur Endgeraete-Anbindung via Shielded, Unshielded, Koax und sonstige Kabel, Terminal-Server- Einschuebe, Bruecken- und Router-Module bis hin zu Rechnerintegration per PC- oder Workstation-Karte und zukuenftig ATM-Interface. Kurzum, der Hub ist eine aeusserst flexible Internetworking-Komponente, die im Kampf um Marktanteile versucht, ein zentraler Integrationspunkt von Netzwerken zu werden: Hubs koennten das Herzstueck des Internetzes werden, so wie frueher der Mainframe das Herzstueck der Peripherie war. Ein gutes Stueck auf diesem Weg hat der Hub schon zurueckgelegt - jedenfalls gemessen am Umsatzwachstum und den Schlagzeilen, die zur Zeit in der Fachliteratur zu lesen sind.

Entstanden sind die Hubs aus der Ethernet-Technik heraus zur sternfoermigen Verbindung von Glasfaserstrecken und Endgeraete- Ankopplung (AUI, TP, BNC), auch als Sternkoppler bezeichnet. Durch die Hub-Technik wurden erstmals flexibel strukturierte Verkabelungskonzepte moeglich, die bei flaechendeckender Realisierung sowohl staendigen Umzuegen als auch der Anbindung aller Dienste mit entsprechender Zuverlaessigkeit und Redundanz gerecht werden. In der weiteren Entwicklung und mit wachsender Etablierung des Token Ring kamen entsprechende RLV-Module und in den letzten Jahren konsequenterweise auch FDDI-Konzentrator-Module hinzu.

Ein Hub (auch Konzentrator, Media-Center, Modular Hub, Smart Hub, Sternkoppler) besteht aus einem Chassis und einer Reihe Slots fuer die Einschubkarten. Eine minimale Konfiguration besteht aus einer Endgeraeteanbindung an ein LAN-Interface, das sternfoermig mit anderen LAN-Segmenten verbunden wird. Ganz wesentlich ist dabei das voellig gleichartige Kopplungsprinzip fuer alle Endgeraete und LANs: naemlich sternfoermig. Typischerweise sind alle (ein bis 24) Ports einer Einschubkarte mit demselben LAN-Segment verbunden.

Es gibt jedoch auch Hubs, die eine Einzelzuweisung von Ports (einer Karte) zu verschiedenen Segmenten erlauben (zum Beispiel Bytex, Chipcom). Verschiedene Karten koennen an dasselbe Segment (denselben Backplane-Bus) oder an verschiedene Segmente angebunden werden. Dass die Zuordnung nicht ueber

manuelle Konfiguration per Dip Switch, sondern ueber ein entsprechendes Management Tool erfolgen sollte, bedarf keiner weiteren Eroerterung. Auch leere Slots in der Backplane sollten die Connectivity aller anderen Karten nicht beeintraechtigen - was derzeit nicht von allen Herstellern erfuellt wird: Teilweise muessen die Karten ohne Zwischenslots eingebaut werden, um volle Funktionalitaet zu gewaehrleisten.

Zentrales Architekturelement des Hubs ist die Backplane: Sie praegt nicht nur die aktuelle Funktionalitaet des Hubs, sondern auch deren Weiterentwicklung zum Beispiel in Richtung Aufruestbarkeit der Modulkapazitaet oder ATM-Migration. Aktuell sind die erforderliche Kapazitaet beziehungsweise ausreichende Durchsatzmoeglichkeiten in der Regel durch mehrere parallele Backplane-Busse (bei Chipcom zum Beispiel maximal drei Ethernet- Busse, sieben Token-Ring-Busse, vier FDDI-Busse) gegeben.

Die Einbindung von (einzelnen) Bruecken- und Router-Einschueben kommt zwar inzwischen haeufiger vor, hat aber noch nicht zur Trendwende beim Einsatz von Stand-alone-Bruecken und -Routern gefuehrt. Wuenschenswert waere hier eine offengelegte Interface- Spezifikation des Hubs, auf deren Basis etablierte Bruecken-und Router-Hersteller entsprechende Einschubmodule entwickeln koennten, die dann wenigstens zu den Stand-alone-Geraeten voll kompatibel waeren. Derzeit beschraenkt sich das Spektrum auf die Zusammenarbeit der Anbieter (zum Beispiel Cisco, Madge, Olicom, Retix, Wellfleet) zur Entwicklung einiger OEM-Module.

Aehnlich wie Multiport-Bruecken und -Router gibt es auch Hubs verschiedener Ausbaufaehigkeit, klassifizierbar nach

- Gruppen-Hub (ein LAN-IF, mindestens acht Endgeraete-Anschluesse)

- Abteilungs-Hub (mindestens drei Slots, zwei LAN-IF, mindestens 24 Endgeraete-Anschluessesowie

- Backbone-Hub (mindestens acht Slots, LAN-IF fuer Ethernet, Token Ring und mindestens zwei FDDI-LANs, mindestens 150 Endgeraete- Anschluesse, davon 30 FDDI-Anschluesse (SAC).

Die Angaben ueber maximale Anzahl von bestimmten LAN-Interfaces und Endgeraete-Anschluessen sind stets mit Vorsicht zu geniessen: Oftmals koennen die Spitzenwerte nur erreicht werden, wenn kein einziger Slot mit einem Management-Modul belegt ist - gerade bei grossen Hubs ein undenkbarer Zustand. Die Anzahl vernuenftigerweise eingesetzter Management-Module (meistens mindestens eine Karte je unterstuetztem LAN) reduziert daher die Anzahl verfuegbarer Slots zur Endgeraete-Konzentration erheblich (unter Umstaenden eine Karte pro genutztem Backplane-Bus).

Um bei den rund 50 Hub-Herstellern, die den Markt mit Produkten beliefern, die Spreu vom Weizen zu trennen, seien an dieser Stelle einige Kriterien genannt, die ein Hub erfuellen sollte, der als Integrationskomponente in einem mittelgrossen bis grossen Multivendor-Netz eingesetzt werden soll:

- Unterstuetzung von Ethernet, Token Ring und FDDI,

- modulare Aufruestbarkeit in mehreren Modellen (Gruppen-Hub, Abteilungs-Hub, Backbone-Hubs) bei Austauschbarkeit der Einschubkarten,

- ein Backplane mit Mehrfach-Bussen fuer getrennte Segmente, die sich durch Bruecken- und Router-Module koppeln lassen,

- ausreichende Kapazitaet der Backplane, auch fuer zukuenftige Erweiterungen,

- Unterstuetzung aller gaengigen Verkabelungstypen (STP, UTP, BNC, AUI),

- Redundanzoptionen fuer CPU und Stromversorgung,

- flexible Verbindbarkeit von Ports und Karten ueber die Backplane,

- Integration von Bruecken- und Router-Modulen,

- Faehigkeit der automatischen Port-Abschaltung im Fehlerfall nicht nur fuer Ethernet (bei Kollisionen), sondern auch fuer Token Ring (bei Beaconing),

- Faehigkeit der automatischen Abkopplung extern angebundener IBM 8228-Ringleitungsverteiler bei Beaconing-Situationen sowie

- intuitiv bedienbare Management-Oberflaeche.

Bei der Ueberlegung, ob Hubs sich als die zentrale Internetworking-Komponente eignen, faellt nicht zuletzt der Aspekt Netzwerk-Management ins Gewicht: Zur Netzintegration gehoert auch integratives Management eines Multivendor-Netzes, und das erschoepft sich nicht nur in der Moeglichkeit, Ports zu konfigurieren und aktive Netzknoten zu monitoren.

Auch sind vernuenftig strukturierte Menuemasken zur Konfigurierung teilweise geeigneter als blinkende Grafikabbilder des realen Outfits, die den schlimmstenfalls auch noch mausungeuebten Netzbetreuer intuitiv raten lassen, was denn bei einem Mausklick auf eine bestimmte Karte passiert: Abschalten oder Zoom der Karte? Abschalten oder Statusmeldung bei einem Port? Leider ist hier keinerlei Einheitlichkeit oder Systematik zum Management verschiedener Hubs ersichtlich, und die Standardisierung hat noch einen langen Weg vor sich. Zwischenzeitlich warten alle gespannt auf die SNMP-Chassis-MIB und deren erste Implementierungen in Plattformsystemen.

In der Regel muss je unterstuetztem LAN ein eigenes Management- Modul eingesetzt werden. Volle Funktionalitaet, zum Beispiel das Sammeln von Statistikdaten, wird jedoch auch nicht von einer Karte fuer alle gleichen LAN-Busse geleistet; hierfuer ist zum Teil je Bus eine eigene Karte erforderlich. Dabei argumentieren die Hersteller, wer die Management-Funktionalitaet nicht braucht, koenne Kosten sparen. Aber auf wen trifft das schon zu? Wuenschenswert waere zur Erhoehung der trotz Management verfuegbaren Slots die Entwicklung von Management-Agenten je Hub-Karte, die mit einem zentralen, gegebenenfalls redundanten Management-Einschub kommunizieren, idealerweise ueber SNMP und in gaengige Plattformen integrierbar.

Der Blick ueber den Tellerrand in Sachen Management faellt Hub- Herstellern noch schwer: Zugriff auf MAC-Adressen der angeschlossenen Endgeraete, Export von Konfigurationsdaten in gaengige Datenbanken, Informationen ueber betriebene Protokolle, Alarmfilter, Korrelation von Fehlermeldungen oder Hilfestellung zur Fehleranalyse, die ueber ein rot blinkendes Icon hinausgeht, sind selten zu finden. Einen Lichtstreifen am Horizont stellen hier RMON-Implementierungen oder Analysatoreinschuebe als uebergreifende Ansaetze dar.

Fazit: Die neue Generation multifunktionaler Koppelelemente weist eine Reihe integrierender Merkmale auf, die die Heterogenitaet der zu verbindenden Subnetze hinsichtlich der eingesetzten Zugangsverfahren und hoeheren Kommunikationsprotokolle im LAN- und WAN-Bereich widerspiegelt (siehe Kasten).

Merkmale

multifunktionaler

Koppelelemente

- Multiport-Faehigkeit im LAN-Bereich mit

- Integration der etablierten Standard-LANs (Ethernet, Token Ring, FDDI),

- Multiprotokoll-Faehigkeit, bezogen auf routbare Protokolle,

- Brueckenfunktionalitaet fuer die nicht routbaren Protokolle,

- Translation-Brueckenfunktionalitaet zwischen verschiedenen MAC- Ebenen,

- Multiport-Faehigkeit im WAN-Bereich mit

- Unterstuetzung verschiedener WAN-Standards (HDLC, X.25, FR, DQDB, SMDS),

- zukuenftige Integration von WAN-Switches sowie

- CPU-Kapazitaet und Auslegung des System-Busses fuer hochgradige Konzentration von LAN- und WAN-Interfaces in einem Koppelelement.

Diese neue Generation von Koppelelementen wird die Basis unternehmensweiter Backbone-Strukturen fuer Multiprotokoll-Betrieb und langfristig unter Umstaenden Migration nach OSI bilden. Sie sind nach vollzogener Funktionsintegration der Bruecken- und Routerfunktionalitaet weder als Bruecke noch als Router zu bezeichnen, sondern eher als INPs - Inter-Netzwerk-Prozessoren (Internetwork Nodal Processors).

Mit steigenden Moeglichkeiten der Peer-to-peer-Kommunikation werden zukuenftig in wachsendem Masse aus Kosten- und Effizienzgruenden Daten ueber Abteilungs- und Standortgrenzen hinweg ausgetauscht werden, was die Verfuegbarkeit hoeherer LAN-Kapazitaeten im Standort-Backbone sowie in

standortuebergreifenden WAN-Verbindungen erforderlich macht. Anwendungen, die fuer die beschriebene Vernetzungsphase am Beginn ihres Lebenszyklus stehen, sind zum Beispiel Bilduebertragung, Videokonferenz, Multimedia und verteilte Anwendungen, letztere mehr im LAN- Bereich.

Aktuell sind drei Generationen von INPs absehbar:

- Integration von Bruecken- und Routerfunktionalitaet (erste Generation),

- Integration der Switching-Funktionalitaet derzeitiger WAN-Knoten und teilweise SNA-Integration (zweite Generation) sowie

- Integration verschiedener Datenstroeme auf der Basis von Breitband-Kommunikation und SNA-Integration (dritte Generation). Die zukuenftigen Generationen von INPs werden nach Vollzug der beschriebenen Integration Multiplexer-, Bruecken- und Routerfunktionalitaet in sich vereinigen (siehe Grafik).

Bis zu welcher Funktionskomplexitaet ein solcher INP zukuenftig weiterentwickelt werden wird, ist zum aktuellen Zeitpunkt schwer abschaetzbar. Insbesondere welche Faehigkeiten der SNA-Integration ein INP zukuenftig bieten kann und muss, ist noch sehr unklar, ebenso der zukuenftige Grad an maximaler Protokoll- und Interface- Konzentration. Der Break-evenPoint zwischen Effizienz und Betreuungskomplexitaet eines derartigen multifunktionalen Backbone-Konzentrators ist aufgrund fehlender Verbreitung und Einsatzerfahrung noch nicht vorhersehbar. Fuer die zukuenftige Entwicklung ist eine Reihe von Aspekten relevant:

- Entwicklung der Router-Funktionalitaet hin zum Gateway,

- SNA-Integration,

- Abwaegung des Router-Einsatzes gegenueber reinem X.25-Switching auf der Basis von Multiplexern und X.25-Switches,

- Multiprotokoll-Betrieb gegenueber der Migration zu OSI als gemeinsames Backbone-Protokoll sowie

- Berechtigung und Grenzen von Bruecken-Backbones gegenueber Router- Backbones bei parallelem Multiprotokoll-Betrieb.

Diese Aspekte werden beim INP-Einsatz und beim Aufbau integrierter Unternehmensnetze zu beachten sein.

Wie schon der obige Versuch einer Charakterisierung von Basistechniken und Internetworking-Komponenten zeigt, geht derzeit die Entwicklung mehrerer Kommunikationstechniken mit einem Zusammenwachsen der Komponentenklassen Hand in Hand. Traditionelle Bruecken- und Router-Produkte wachsen zusammen und integrieren Switch- und zukuenftig auch Hub-Funktionen. Letztere gehoeren zu einer Komponentenklasse, die in den letzten eineinhalb Jahren ins zentrale Interesse vieler Netzwerkplaner gerueckt sind: die Hubs. Urspruenglich zur Endgeraete-Anbindung und Medienkonvertierung entwickelt, zeigen sich inzwischen bei Hubs deutliche Entwicklungen zur Integration von Bruecken- und Router- Funktionalitaet. Wer letztendlich wem den Markt streitig macht oder welche Produkte sich als komplementaere Ergaenzung zueinander etablieren, bleibt abzuwarten.

*Petra Borowka ist unabhaengige Unternehmensberaterin fuer Netzwerk- Fragen in Stolberg.