VLANs




	Virtuelle Netze Virtuelle Netzkonzepte sorgen dafür, dass unsere Netzwerke nicht länger statische Gebilde bleiben müssen, sondern flexibel und einfach an sich ändernde Gegebenheiten angepaßt werden können. Mittels intelligenter Switches kann man die Endgeräte in einem Netz dynamisch zu logischen Einheiten gruppieren. Da zur Zeit noch keine gültigen Standards vorliegen, gibt es mehrere Ansatzpunkte, die gestellten Anforderungen zu erfüllen. In diesem Beitrag werden die technischen Grundlagen verschiedener Ansätze skizziert bzgl. der Integration in das ISO/OSI-Schichtenmodell, der Switch- Architektur und der Implementierung der VLAN-Protokolle. Da die ATM- Technik mit der LAN-Emulation bereits ein gültiges Verfahren zum Aufbau virtueller Netze vorweisen kann, wird dieses Verfahren genauer betrachtet. Von Klaus Eppele Inhaltsübersicht 1. Einleitung 2. Definition und Ziele virtueller Netze 2.1 Definition 2.2 Ziele 2.2.1 Flexible Netzwerke 2.2.2 Leistungsfähige Netzwerke 2.2.3 Sichere Netzwerke 2.2.4 Sonstige Ziele 3. Die VLAN-Architektur 3.1 Topologie 3.2 Switches 3.2.1 Cut Through Switches 3.2.2 Store and Forward Switches 3.2.3 Zellorientierte Switches 3.3 VLAN-Zuordnung 3.3.1 Austausch der Adreßtabellen 3.3.2 Frame Tagging 3.3.3 Zeitmultiplex 3.3.4 Vorschlag des IEEE 3.4 Layer 3 Switching 3.5 Backbone 4. Die LAN-Emulation für ATM 5. Zusammenfassung 6. Glossar 7. Literatur 1. Einleitung In unserer kurzlebigen Zeit kann nur derjenige Wettbewerbsvorteile erzielen, der schnell auf Veränderungen reagiert. In Zukunft wird es immer wichtiger, dass die installierte Kommunikationsstruktur den Austausch von Informationen auf einfache und flexible Weise sicherstellt. Mit der zunehmenden Komplexität der Unternehmen sind Netzkonzepte gefragt, die eine einfache Abbildung der internen Organisation auf die Netzwerktopologie erlauben und die Bildung dynamischer Workgroups unterstützen. Virtuelle Netze (VLANs) sind die logische Konsequenz in der Kommunikationstechnik auf diese Anforderungen. 2. Definition und Ziele virtueller Netze 2.1 Definition Mit jeder neuen Technik wiederholt sich dasselbe Phänomen: Man findet nicht genau eine, sondern mehrere, voneinander abweichende, Definitionen. Das liegt daran, dass verschiedene Hersteller und Interessensgruppen jede neue Technik genau so definiert haben wollen, dass sich die eigenen Ideen und Produktentwicklungen optimal mit der gültigen Definition vereinen lassen. An dieser Stelle sei deshalb auf die Definition der Arbeitsgruppe 802.1q des IEEE (Institute for Electrical and Electronic Engineers) verwiesen, die derzeit an einem Standard für VLANs arbeitet: "Das IEEE definiert VLANs als eine logische Gruppierung beliebiger Endgeräte innerhalb einer mit Brücken aufgebauten Infrastruktur. Dabei werden die Endgeräte durch ihren Zugangspunkt (MSAP = MAC Service Access Point) zum Netzwerk definiert." VLANs erlauben somit, dass man beliebige Netzteilnehmer aus verschiedenen Netzsegmenten nach bestimmten Kriterien zu einem logischen Netz vereinen kann, ohne dass hierzu das Netzwerk physikalisch umstrukturiert werden muß. Bei komfortablen VLAN-Installationen muß man hierzu einfach die Stationen, die eine virtuelle Verbindung erhalten sollen, am Bildschirm der Netzwerk-Managementstation mit der Maus anklicken. Die VLAN-Implementierung sorgt dann dafür, dass alle Daten, auch Broad- und Multicasts, in einem virtuellen Netz bleiben und nicht in andere virtuelle Netze gelangen. Damit entspricht ein virtuelles Netz einer Broadcast Domain wie sie von der klassischen Ethernet-Technik her bekannt ist. Innerhalb eines virtuellen Netzes werden die Daten gebridged; Routertechnik wird nur benötigt, wenn man verschiedene virtuelle Netze miteinander verbinden will. Da man in der Regel mehrere Netzsegmente in einem logischen Subnetz integriert, wird die Anzahl der zeitraubenden Routerübergänge damit reduziert. 2.2 Ziele 2.2.1 Flexible Netzwerke Eine Vielzahl von Anwendungsfällen bedürfen der Trennung der logischen Netze von der physikalischen Verkabelung und damit der raschen Einführung virtueller Netzstrukturen: a) Projektteams Mitarbeiter verschiedener Abteilungen müssen häufig zu zeitlich begrenzten, projektbezogenen Arbeitsgruppen zusammengefaßt werden. Wenn die projektbezogene Kommunikation dieser Arbeitsgruppen vom restlichen Netzverkehr separiert werden muß, kann dies heute ohne die VLAN-Technik nur dadurch geschehen, dass die Rechner aller Projektteilnehmer physikalisch an ein Netzsegment gekoppelt werden. b) SOHO-Anwendungen Heimarbeitsplätze und kleine Außenbüros (SOHO = Small Office, Home Office) werden immer häufiger installiert und müssen logisch in ein zentrales Netzwerk integriert werden. In Zukunft will man nicht mehr zulassen, dass Benutzer nur deshalb verschiedenen Subnetzen zugeordnet werden müssen, weil sie eine gewisse Entfernung zueinander aufweisen. c) Umzüge Ein weiteres Problem sind die Umzüge. In deutschen Unternehmen zieht jeder Mitarbeiter etwa alle zwei bis drei Jahre innerhalb des Unternehmens um und muß bei Verwendung der üblichen Routertechnik meist einem anderen physikalischen Subnetz zugeordnet werden. Wie schön wäre es, wenn das Netz jeden Umzug selbst registrieren, und der Umziehende weiterhin in seiner logischen Workgroup bleiben könnte. d) Client-/Server-Strukturen Weiterhin sind die Vorteile virtueller Netze dann gefragt, wenn man Server, die in zentralen Technikräumen untergebracht sind, verschiedenen räumlich getrennten Workgroups zuordnen will. 2.2.2 Leistungsfähige Netzwerke Wenn es in einem LAN zu Kapazitätsengpässen kommt, beginnt man üblicherweise, das vorhandene LAN mittels Routern zu segmentieren. Je weniger Rechner sich ein LAN-Segment teilen müssen, desto größer wird die verfügbare Bandbreite für den Einzelnen. Im Extremfall führt dies zur Mikrosegmentierung, bei der jeder Rechner ein eigenes LAN-Segment erhält und dediziert mit der vollen verfügbaren Bandbreite an den Router angeschlossen wird. Problematisch bei dieser Vorgehensweise ist, dass jedes neue Segment als separates logisches Subnetz betrachtet werden muß. Je mehr Subnetze vorhanden sind, desto öfter müssen die Daten den Router passieren, was aufgrund der Rechenzeit im Router jedesmal eine signifikante Verzögerung des Datentransports bewirkt. Außerdem ist diese Vorgehensweise auch deshalb problematisch, weil zum einen die einzelnen Routerports nicht gerade billig sind und weil auf diese Weise die verfügbaren IP-Adreßräume schnell ausgereizt werden. Mit VLANs läßt sich das Problem viel leichter in den Griff bekommen. Die Aufteilung des physikalischen Netzes in logische Einheiten sorgt für eine Art "load sharing": Broadcasts und Multicasts werden nicht über das ganze Netz geflutet, sondern nur in die Subnetze transportiert, die zum gleichen VLAN gehören. Außerdem werden VLANs mittels Switches realisiert. Switches unterstützen je Anschlußport die volle Bandbreite der jeweils angeschlossenen Netztechnik und bieten üblicherweise viel kürzere Verzögerungszeiten als Brücken oder Router. 2.2.3 Sichere Netzwerke Die VLAN-Technik sorgt dafür, dass alle Daten innerhalb eines virtuellen Netzes verbleiben. Die Teilnehmer eines VLAN haben nur dann die Möglichkeit, Daten anderer virtuellen Netze zu empfangen, wenn sich mehrere virtuelle Netze auf einem physikalischen Netzsegment überlappen. Wenn die VLAN-Technik dafür genutzt werden soll, Datenströme verschiedener logischer Netze vollständig voneinander abzuschotten, muß man entweder dafür sorgen, dass alle Stationen eines physikalischen Netzsegments zum selben VLAN gehören oder man muß einen Wechsel vom "shared-medium" zum "switched-medium" vollziehen. In diesem Fall sollte man eine strukturierte Verkabelung nach IS 11801 installieren und für jedes Endgerät einen separaten Anschluß an einen Switch vorsehen. Auf diese Weise kann ein gewisses Maß an Abhörsicherheit im LAN realisiert werden. Jedoch haben VLANs nicht das Ziel, Security-Mechanismen ins LAN zu integrieren. Mit dieser Thematik beschäftigt sich die Arbeitsgruppe 802.10 des IEEE. Wer sichere Netzwerke benötigt, ist mit den Möglichkeiten der VLANs nur schlecht bedient. Authentisierungs- und Verschlüsselungs- Mechanismen dürfen nämlich in diesem Fall auf keinen Fall fehlen. 2.2.4 Sonstige Ziele Damit der Markt VLANs akzeptiert, sollten von den Standardisierunggremien und den Herstellern außerdem die folgenden Anforderungen bedacht werden: a) Migrierbarkeit / Skalierbarkeit VLANs werden nur dann Einzug in bestehende Netzwerke finden, wenn vorhandene Investitionen geschützt werden. Deshalb werden Migrationskonzepte benötigt, die eine schrittweise Migration in die neue Technik erlauben. Zudem müssen VLANs skalierbar sein und mit den Anforderungen des Kunden wachsen können. b) Netzwerk-Management Die Administration und Überwachung der VLANs muß vom zentralen Management-Arbeitsplatz möglich sein. Ein Netzverantwortlicher wird nur dann eine neue Technik akzeptieren, wenn deren Installation und Betrieb nicht zu einem Mehraufwand und damit zu höheren Kosten führen. c) Kosten-Effizienz Die notwendige Hard- und Software zur Realisierung von VLANs darf nicht teurer sein als herkömmliche Netzkonzepte. Aufgrund der gegenüber Brücken und Routern einfacheren Hardware-Struktur der VLAN-Switches und der damit einhergehenden Reduzierung der Hardware-Kosten sollte dieses Ziel leicht realisierbar sein. Abb. 1 Virtuelle Netze agieren auf der ISO/OSI-Ebene 2. Die Verbindung zwischen den virtuellen Netzen geschieht über Router. Virtuelle Netze vereinen die Vorteile von Brücken und Routern. Stationen lassen sich leicht ändern, hinzufügen oder entfernen. Trotzdem hat man den Vorzug der Systemtrennung und Strukturierung, ohne jedoch die Durchsatzprobleme von Brücken und die aufwendige Konfiguration großer Netze mit Routern hinnehmen zu müssen. 3. Die VLAN-Architektur 3.1 Topologie Gemäß IEEE 802.1q sind VLANs eingebettet in eine "bridged infrastructure". Somit sind VLANs "flache" Netze ohne Hierarchien. Die einzelnen Netzsegmente werden mit Switches verbunden, die Datenpakete transportieren, ausfiltern oder fluten. Während traditionelle Brücken beim Fluten ein Datenpaket an alle Ausgänge senden, geben VLAN-Switches Rundsprüche nur an die Ausgänge weiter, die zum selben virtuellen Netz gehören. Mehrere unterschiedliche virtuelle Netze können über einer physikalischen Struktur definiert werden, wobei Endgeräte an mehreren virtuellen Netzen teilnehmen können. Die einzelnen VLANs werden mittels Routern gekoppelt. Die Mächtigkeit der Switches bzgl. der Fähigkeiten, virtuelle Netze zu bilden, ist nicht festgeschrieben. So gibt es Switches, die nur eine portweise VLAN-Gruppierung durchführen können; andere Switches werten hierzu die MAC-Adressen oder sogar weitere Informationen der Datenpakete aus. Klar ist jedoch, dass bezogen auf ein VLAN immer nur der kleinste gemeinsame Nenner aller Switcheigenschaften als Gruppierungsmerkmal gewählt werden kann. Damit auch in VLANs redundante Netzstrukturen aufgebaut werden können, greift man auf das bekannte Spanning Tree Protokoll zurück. Durch Austausch entsprechender IEEE 802.1d Mitteilungen werden Schleifen im Netz in Baumstrukturen aufgespalten. Da der Spanning Tree Algorithmus nicht für große LANs optimiert ist, haben einige Switchhersteller auch hier proprietäre Erweiterungen vorgenommen, um den Algorithmus schneller und robuster zu machen. Wichtig ist, dass die Switches mehrere Spanning-Trees parallel unterstützen können, da für jedes virtuelle LAN ein eigener Spanning Tree Algorithmus angeboten werden muß. Aus diesem Grund spricht man im Zusammenhang mit VLANs bereits häufig von einem "spanning forest". 3.2 Switches LAN-Switches lassen sich in drei Kategorien aufteilen: Cut Through-, Store and Forward- und Cell Oriented Switches: 3.2.1 Cut Through Switches Die Cut Through Switches sind am schnellsten. Jedes empfangene Datenpaket wird nur bezüglich der MAC-Ziel- und -Quelladresse analysiert, so dass bereits nach dem Empfang der ersten 12 Bytes eine Verbindung durchgeschaltet werden kann. Der Empfänger wird durch die Zieladresse eindeutig definiert. Zusätzlich analysiert man die Quelladresse zum automatischen Aufbau von Adreßtabellen (Selbstlernfunktion) und zur Bestimmung der VLAN-Zugehörigkeit des Senders. Nachteilig an diesem Verfahren ist, dass man nur auf die MAC-Adressen filtern kann. CT-Swiches können deshalb virtuelle Netze nur bezüglich MAC-Adressen oder Switch- Ports gruppieren. Außerdem können feherhafte Pakete und Paketfragemente nicht ausgefiltert werden, da ein CRC-Check erst am Ende des Paketes erfolgen kann, wenn der CT-Switch den Großteil des Paketes schon an den Empfänger weitergegeben hat. 3.2.3 Store and Forward Switches Store and Forward Switches agieren wie gewöhnliche Brücken oder Router. Sie empfangen das gesamte Datenpaket, schreiben es in einen internen Puffer und können dann Fehlererkennung und andere Paketbearbeitungsprozeduren durchführen. Die Durchlaufzeiten eines Paketes durch den Switch werden dadurch sehr groß. Während ein CT-Ethernet-Switch nur 96 Mikrosekunden benötigt, um das Adreßfeld zu analysieren, benötigt ein SF-Switch für das Puffern eines maximal großen Ethernet-Paketes von 1512 Bytes 1210 Mikrosekunden; das ist immerhin eine Erhöhung des Delays um den Faktor 12. Außerdem wird die Durchlaufzeit abhängig von der Länge der Datenpakete, was die Übertragungsqualität von Sprach- und Bewegtbildanwendungen sehr beeinträchtigt, da kein kontinuierlicher Datenfluß garantiert werden kann. Am Markt finden sich bereits Produkte, die die Problematik dadurch einschränken, dass der Benutzer selbst bestimmen kann, welche Ports im CT- oder im SF-Verfahren arbeiten sollen. 3.2.3 Zellorientierte Switches Cell Oriented Switches vereinen die Vorteile beider Switch-Varianten. Je nach Hersteller werden die Datenpakete beim Empfang in Zellen von 48 bis 64 Bytes zerlegt. Die einzelnen Zellen werden sofort weitertransportiert. Da sich die für das Filtering wesentlichen Informationen (Typfeld, Layer 3 Adressen, etc.) in den ersten 48 Bytes eines Datenpaketes befinden, erhält man somit die für den Aufbau von virtuellen Netzen gewünschte Filterfunktionalität. Trotzdem bleibt die Verzögerungszeit im akzeptablen Bereich. Gegenüber CT-Switches vergrößert diese sich zwar auf das vier- bis fünffache; wichtig ist jedoch, dass aufgrund des Transports gleichlanger Zellen die Kontiunität des Datenflusses gewahrt bleibt. Das Cell Oriented Switching ist insbesondere dann zu empfehlen, wenn ATM als Backbone-Technologie gewählt wurde. Dann können nämlich die 48 Byte langen Zellen durch Hinzufügen eines ATM-Headers leicht in ATM-Zellen von 53 Bytes verpackt werden. 3.3 VLAN-Zuordnung Alle Switches enes Netzes müssen zu jeder Zeit wissen, welche virtuellen Netze vorhandenen sind. Dazu müssen die Adreßtabellen in den Switches um die IDs der bestehenden virtuellen LANs ergänzt werden, und man muß dafür sorgen, dass die Tabellen der verschiedenen Switches immer konsistent sind. Die Switches müssen also kontinuierlich ihr Wissen austauschen. Genau an dieser Stelle trifft man auf eines der noch wesentlichen Probleme der virtuellen LANs: So ziemlich jeder Hersteller verwendet für diese Informationsabgleichung proprietäre Verfahren, so dass man davon ausgehen kann, dass die wenigsten Komponenten verschiedener Hersteller sich auf Anhieb verstehen. Mindestens drei Verfahren findet man vor: - den regelmäßigen Austausch der Adreßtabellen, - das Frame Tagging und - das Zeitmultiplexverfahren. 3.3.1 Austausch von Adreßtabellen Einige Switches tauschen spezielle Nachrichten aus, um ihre Adreßtabellen auf einen Nenner zu bringen. Bevor ein neuer Teilnehmer zum ersten Mal Daten versenden darf, müssen alle Switches wissen, zu welchem virtuellen Netz dieser Teilnehmer gehört. Der dem neuen Teilnehmer nächstgelegene lokale Switch erkennt die Adresse des zugehörigen virtuellen Netzes am Port, über den er Verbindung zu der neuen Station erhält, da üblicherweise alle Stationen eines Segments genau einem virtuellen Netz zugeordnet sind. Dieser lokale Switch ergänzt seine Adreßtabelle und sendet die neue Information (MAC-Adresse und Adresse des virtuellen LANs) mittels einer kurzen Nachricht hoher Priorität an alle anderen Switches. Leider ist dieser Nachrichtenaustausch nicht standardisiert, so dass hier jeder Hersteller etwas anderes tut. Erst wenn alle Switches die neue Endstation kennen, können deren Daten übertragen werden. Dieses Verfahren ist recht einfach zu implementieren, führt aber in großen Netzen schnell zu Synchronisations- und Überlastproblemen. Letzteres insbesondere auch deshalb, weil die Switches regelmäßig, etwa jede Minute, die kompletten Tabellen untereinander austauschen. Bei Tabellengrößen von ca. 1.000 Bytes und mehr kann man sich leicht ausrechnen, was hier an zusätzlichem Datenverkehr dazu kommt. 3.3.2 Frame Tagging Eine weitere Möglichkeit des Informationsaustauschs ist das Frame Tagging. Jedem Datenpaket wird ein kurzes Datenfeld, ein sogenanntes Tag, hinzugefügt. Dieses Tag beschreibt, zu welchem virtuellen LAN das Datenpaket gehört. Der umständliche Austausch der Adreßtabellen kann somit entfallen. Allerdings generiert auch dieses Verfahren einen erheblichen Overhead, da jedes Datenpaket um Synchronisationsinformation ergänzt werden muß. Außerdem bekommt man Probleme, wenn ein Datenpaket bereits die maximal zulässige Paketlänge hat. Das Hinzufügen eines Tags würde in diesem Fall die Vorgaben des MAC-Protokolls verletzen und dazu führen, dass die zu langen Pakete als Fehler erkannt und vernichtet werden. Als Ausweg hierfür findet man heute nur herstellerspezifische Techniken, die uns derzeit noch zur Installation von Komponenten nur eines Herstellers zwingen. Einige Hersteller haben sich entschlossen, Teile des Sicherheitsstandards IEEE 802.10 (Secure Data Exchange) zu nutzen, um eine herstellerübergreifende Lösung für Frame Tagging zu erhalten. IEEE 802.10 beschreibt ein Verfahren, wie Verschlüsselungs- und Authentisierungsinformationen an ein Datenpaket angefügt werden können. Dazu werden die MAC Frames um einen 32 bit langen Group Identifier erweitert und in einen größeren MAC Frame eingepackt (Encapsulation). Es wird auch definiert, wie Pakete maximaler Größe zerteilt und später wieder zusammengesetzt werden müssen, um durch Anfügen der zusätzlichen Information die maximal erlaubte Paketlänge nicht zu überschreiten. Dieses Verfahren ist für Ethernet, FDDI, Token Ring und HDLC definiert und läßt sich wunderbar für das Frame Tagging in virtuellen Netzen nutzen. Eine weitere Variante des Frame Tagging ist der Ansatz, vorhandene Felder eines Datenpaketes zur Gruppierung von virtuellen LANs zu verwenden. Es gibt bereits Switches, die virtuelle LANs nicht nur aufgrund von MAC- Adressen zusammenstellen, sondern hierfür auch weitere Informationen im Datenpaket, wie die Subnetzadresse oder den Protokolltyp, heranziehen können. Diese Flexibilität erlaubt beispielsweise die Zusammenfassung nicht routfähiger Protokolle (NetBIOS, LAT,...) zu virtuellen Netzen - ein Vorteil, der durch Router nicht erreicht werden kann. Der Nachteil dieses Verfahrens ist, dass die Switches sehr leistungsfähig sein müssen, um "on-the-fly" alle Paketinformationen auszuwerten und mit entsprechenden Tabellen zu vergleichen, und dass die gegebenen Möglichkeiten nur dann ausgeschöpft und richtig angewendet werden können, wenn der Netzadministrator über umfangreiche Protokollkenntnisse verfügt. 3.3.3 Zeitmultiplex Der dritte Ansatz zur Verständigung der Switches untereinander ist das Zeitmultiplexverfahren. Das die Switches vereinende Backbone wird dazu in Slots fester Bandbreite aufgeteilt. Jedes virtuelle LAN erhält exklusiv einen oder mehrere dieser Slots zur Übertragung der Daten. Jedem Switch muß somit nur noch mitgeteilt werden, welcher Time Slot welchem virtuellen Netz zugeordnet ist. Der Overhead aufgrund von Tags oder zusätzlich zu übertragender Synchronisationsinformation entfällt. Problematisch ist an diesem Verfahren nur, dass ungenutzte Bandbreite in den einzelnen Slots nicht für andere virtuelle Netze zur Verfügung steht und brach liegt. Ein Zeitmultiplexverfahren kann nur dann annähernd sinnvoll genutzt werden, wenn aufgrund stetiger Beobachtung des Netzverhaltens die Time Slots optimal zugeordnet werden können. 3.3.4 Vorschlag des IEEE IEEE 802.1q favorisiert aus den oben genannten Verfahren eindeutig das Frame Tagging. Vorgeschlagen sind zwei Modelle: Das "One-Level-" und das "Two-Level-Model". Beim One-Level-Model werden nach den Adreßfeldern (Ziel- und Quelladresse) zwei neue Felder in das Datenpaket eingefügt: Das Ethertype- Field, das das Datenpaket als ein "tagged packet" identifiziert und eine 2- Byte lange VLAN-ID. Dieses neue Datenpaket wird am Ende durch eine FCS (Frame Check Sequence) gesichert. Das "Two-Level-Model" ändert das Orginalpaket nicht und fügt nur einen komplett neuen Header mit den Feldern VLAN-Destination, VLAN-Source, Ethertype, VLAN-ID und CRC an. Beide Verfahren grenzen sich eindeutig vom oben genannten IEEE 802.10 Data Secure Exchange Verfahren ab, um zu verhindern, dass VLAN-Aspekte die Bestrebungen für Sicherheitsstandards beeinflussen. 3.4 Layer 3 Switching Bisher wurden nur sogenannte Layer 2 Switches betrachtet, die auf Ebene 2 des ISO/OSI-Modells arbeiten. Layer 3 Switches bringen zusätzliche Möglichkeiten, weil sie Basis-Routing-Funktionalitäten wie z.B. ARP in die virtuellen Netze integrieren und den externen Router zur Verbindung der virtuellen LANs überflüssig machen. Layer 3 Switches agieren protokollsensitiv. Sie können Ebene 3 Informationen auswerten und deshalb virtuelle Netze abhängig vom verwendeten Protokolltyp definieren, so dass man beispielsweise alle Netware- oder alle IP-Stationen unabhängig von ihrer Plazierung im Netzwerk einem eigenen virtuellen LAN zuordnen kann. Die Zuordnung einzelner Datenpakete zu verschiedenen virtuellen LANs geschieht analog dem klassischen Routing einfach durch Auswertung der Subnetzadressen. Trotz Analyse der Ebene 3 Informationen werden alle Verbindungen innerhalb eines virtuellen Netzes so behandelt, als ob eine Brückentopologie vorliegen würde. Die komplette Routingfunktionalität greift nur zwischen den virtuellen Netzen. Innerhalb eines virtuellen Netzes spielen Routingprotokolle wie RIP oder OSPF keine Rolle; unbekannte Datenpakete werden entgegen der üblichen Vorgehensweise von Routern einfach über das gesamte virtuelle Netz "geflutet". Abb. 2 Layer 3 Switches verwenden Routerfunktionen zur Definition virtueller Netze. Um effizient arbeiten zu können, wird ebenso wie bei Layer 2 Switches innerhalb eines virtuellen Netzes nur gebridged. Wann soll man sich für Layer 2-, wann für Layer 3 Switches entscheiden ? Die Argumente hierfür sind ähnlich den Argumenten, wie wir sie aus dem Vergleich der Brücken- und Routertechnologie kennen. Virtuelle Netze auf Ebene 2 sind leichter zu konfigurieren als Ebene 3 VLANs. Da Layer 2 Switches weniger Software benötigen, sind sie üblicherweise preisgünstiger als Layer 3 Switches und meist auch schneller. Ihre Protokollunabhängigkeit erlaubt Ihnen, nicht routbare Protokolle zu bedienen. Trotz dieser Vorteile der Layer 2 Switches werden Layer 3 Systeme um so interessanter, je komplexer das Netzwerk wird, da der Overhead zur Synchronisierung wegfällt, Broadcasts gezielter übertragen werden können und bessere Filtermöglichkeiten zur Sicherung der virtuellen Netze zur Verfügung stehen. 3.5 Backbone Nicht nur das oben genannte "flooding" trägt dazu bei, dass die Backbone- Verbindung zwischen den Switches leistungsstark sein muß. Vielmehr sorgen virtuelle Netze schon deshalb für eine enorme Backbone-Belastung, weil sich der Datenverkehr einzelner Workgroups nun nicht mehr auf ein physikalisches Segment beschränken muß, sondern bei örtlich verteilten Workgroups die Daten über das gesamte Backbone bis hin zu allen Teilnehmern eines virtuellen Netzes zu übertragen sind. Das Backbone muß für Ortstransparenz sorgen, was bedeutet, dass die Kommunikation zwischen zwei beliebigen Teilnehmern eines virtuellen Netzes mit der gleichen Effizienz geschehen muß, egal ob diese über mehrere Switches miteinander kommunizieren oder direkt benachbart sind. Außerdem müssen alle virtuellen Netze gleichzeitig und möglichst mit der vollen Bandbreite der angeschlossenen Endgeräte bedient werden können. Verschiedene Technologien wie FDDI, Fibre Channel, Fast Ethernet und ATM bieten sich als Backbone-Technologie an. Mittelfristig wird hier ATM das Rennen machen, da ATM - hohe Bandbreiten unterstützt (heute bis 622 Mb/s), - in LAN und WAN eingesetzt werden kann und somit in seiner Ausdehnung nicht beschränkt ist, - uneingeschränkte Skalierbarkeit bietet und - mehrere voneinander unabhängige, logische Verbindungen auf einer physikalischen Leitung vereinen kann. Allerdings muß man heute noch etwas vorsichtig mit ATM sein, wenn man komplexe Netzwerke aufbauen will, da wesentliche Bestandteile von ATM noch nicht vollständig definiert und normiert sind. Trotzden wird ATM die über kurz oder lang favorisierte Technik sein - u.a. auch deshalb, weil das ATM- Forum bereits seit Januar 1995 mit der "LAN-Emulation Specification Version 1.0" den Aufbau virtueller ATM-LANs definiert hat. Dieser Ansatz wird im folgenden Kapitel genauer erläutert. 4. Die LAN-Emulation over ATM Specification Version 1.0 Die Netze, die wir heute nutzen, arbeiten üblicherweise verbindungslos. Wenn man mit einem Partner kommunizieren will, muß man nicht erst eine Verbindung aufbauen. Man gibt einfach seine Sendedaten zusammen mit der Zieladresse auf das verbindungslos arbeitende Shared-Medium-Netzwerk. In korrekt installierten Netzen kann man sich dann sicher sein, dass die Daten irgendwie beim richtigen Empfänger ankommen. Bei ATM ist das nicht so. Hier wird für jeden Sendewunsch eine dedizierte Verbindung aufgebaut. Wenn man nun herkömmliche Netze mit ATM vereinen will, muß man dafür sorgen, dass gewohnte Mechanismen, wie zum Beispiel die Verwendung von Broad- und Multicasts, auf ATM-Strukturen abgebildet werden. Endgeräte, die via ATM kommunizieren möchten, müssen automatisch eine Verbindung über ATM erhalten. Außerdem muß man dafür sorgen, dass die vorhandenen Protokollstacks und Applikationen auf den Endgeräten auch mit ATM weitergenutzt werden können, ohne auch nur die kleinste Veränderung an der installierten Hard- oder Software vornehmen zu müssen. Nur wenn dies sichergestellt ist, kann man preiswert zu ATM migrieren: Man kann damit beginnen, dass man ATM anfangs nur im Backbone installiert und bestehende Endgeräte über dedizierte Leitungen und leistungsfähigen Cell- /Frame-Switches an dieses ATM-Backbone anschließt. Den Endgeräten stehen sofort die Vorteile von ATM (hohe Bandbreiten, Skalierbarkeit bzgl. der Netzzugänge und der Backbonekapazität sowie Multimediafähigkeit aufgrund von Isochronität und Zeittransparenz) zur Verfügung, ohne dass deren Soft- oder Hardware ausgetauscht werden muß. Um die installierte Software will man sich auch dann nicht sorgen, wenn man sukzessive mit Sinken der ATM-Adapterpreise und Anwachsen des Bandbreitenbedarfs nach und nach einzelne Endgeräte mit ATM-Anschlüssen ausstattet und direkt an das ATM-Backbone anschließt. Verschiedene Ansätze zur Lösung der geschilderten Problematik wurden bereits definiert. So schlägt die ITU (Internationale Telekommunikation Union) beispielsweise in ihrer Spezifikation I.364 für den WAN-Bereich vor, die gewünschten Aufgaben sogenannten Connectionless Servern zu übertragen. Auch hat sich bereits die IETF (Internet Engineering Task Force) Gedanken gemacht, wie man "classical IP over ATM" transportieren kann, indem man eine neue MAC-Ebene (Media Access Control) für ATM definiert (Request for Comment - RFC 1577), bzw. wie man durch "encapsulation methods for carrying network interconnection traffic over AAL 5" verschiedene Protokolle über virtuelle ATM-Verbindungen multiplext (RFC 1483). Während der ITU-Ansatz für den lokalen Bereich nicht brauchbar ist, da die ATM-Vorteile Skalierbarkeit und Zeittransparenz verloren gehen und die IETF-Ansätze nur Teillösungen liefern, erhalten wir mit der LAN-Emulation des ATM-Forums eine weitgehend umfassende Lösung. Alle Protokolle, ob routbar oder nicht, werden von der LAN-Emulation unterstützt. Es wird definiert, wie Ethernet- oder Token-Ring-Stationen mit ATM-Stationen und wie Stationen gleicher Netzzugangstechnik untereinander über ATM kommunizieren können (Ethernet mit Ethernet oder Token-Ring mit Token- Ring). Die LAN-Emulation definiert jedoch nicht, wie Ethernet- mit Token-Ring- Stationen Daten über ATM austauschen können. Zur Lösung dieser Aufgabe ist weiterhin Bridging-/Routingfunktionalität gefragt mit dem bekannten Problem, dass aufgrund des "store-and-forward"-Verfahrens keine zeittransparente Kommunikation möglich ist. Außerdem ist die Behandlung von FDDI-Frames nicht definiert. Diese müssen zuerst in Ethernet- oder Token-Ring-Frames gewandelt werden, bevor sie per LAN-Emulation bedient werden können. Abb 3 Die LAN-Emulation wird im ATM-Adapter für ein Endgerät oder im Cell-/ Frame-Switch für alle Endgeräte der angeschlossenen legacy LANs implementiert. Die LAN-Emulation wird als Client-Server-Modell definiert und besteht aus den zwei Komponeten LAN Emulation Client (LEC) und LAN Emulation Service. Die LEC-Funktionalität wird in Hardware oder als Teil der Treibersoftware implementiert. Sie befindet sich entweder direkt im ATM-Adapter des Endgerätes oder im LAN/ATM-Switch von wo sie alle Stationen der angeschlossenen legacy LANs bedient. Der LEC hat mehrere Aufgaben, wobei ihm als Hauptaufgabe die Zuordnung von Ziel-MAC- zu Ziel-ATM- Adresse, also die Adreßauflösung, zufällt. Der LAN-Emulation-Service zerfällt logisch in drei Server-Bestandteile: - den LAN-Emulation-Konfigurations-Server (LECS), - den LAN-Emulation-Server (LES) und - den Broadcast- and Unknown-Server (BUS). Das ATM-Forum hat sich nicht festgelegt, wo die LAN-Emulation-Service- Funktionen zu implementieren sind. Alle drei Funktionen können als eine zusammengehörige Applikation in einem ATM-Switch integriert sein, sie können aber auch verteilt über das Netzwerk implementiert werden, so dass der LES vielleicht in einem ATM-Backbone-Switch sitzt, während der LECS sich in einem Server befindet und der BUS in einem lokalen Switch residiert. Abb. 4 Komponenten der LAN-Emulation und deren Daten- und Kontroll-Verbindungen. Die LAN-Emulation ist ein Service der OSI-Ebene 2 und damit unabhängig von höheren Protokollen. Somit kann sie nicht nur routbare Protokolle wie TCP/IP, IPX, DECnet, etc. sondern auch nicht routbare Protokolle wie Netbios, LAT (Local Area Transport) von DEC oder SNA bedienen. Die Server haben die Aufgaben, sowohl Unicasts (point-to-point) als auch Broad- und Multicasts (point-to-multipoint) zu vermitteln und den LECs bei der Ermittlung der ATM-Zieladressen behilflich zu sein. Dabei ist der LES die Kommando- und Kontrollzentrale jedes emulierten LANs. Er ist dafür verantwortlich, MAC-Adressen zu registrieren und aufzulösen. Der BUS ist zuständig für die Übertragung aller Broad- und Multicasts und der LECS richtet Konfigurations-Informationen über das ATM Netzwerk ein und liefert auf Wunsch die LES-Adresse an einen Clienten, der an einem emulierten LAN teilhaben will. Die LECs kommunizieren auf zwei Arten mit den Servern. Administrative Aufgaben, wie das Auffinden der Adresse eines anderen Clienten, werden über Kontrollverbindungen durchgeführt; für die Datenübertragung gibt es gesonderte Datenverbindungen. Die wichtigste Kontrollverbindung wird vom Clienten zum LES aufgebaut, wenn er einem emulierten LAN beitreten will. Es handelt sich hierbei um eine bidirektionale Verbindung (point-to-point), die optional um eine unidirektionale Verbindung (point-to-multipoint) vom LES zum Clienten ergänzt werden kann. Datenverbindungen sind bidirektionale virtuelle Kanäle zwischen Clienten (point-to-point), zwischen Clienten und BUS (point-to-point) sowie zwischen BUS und Clienten (üblicherweise point- to-multipoint). Die Verbindungen können alle als PVC (permanent virtual circuit), als SVC (switched virtual circuit) oder als Mischung aus beidem realisiert werden. Der BUS ist zuständig für das Versenden aller Broad- und Multicasts. Er kann aber auch zum Versenden von Unicasts genutzt werden in den Zeiträumen, in denen Client und LES noch mit der Adreßauflösung beschäftigt sind. Der Client hat somit die Möglichkeit, schon während der Phase des Verbindungsaufbaus Daten zu senden. Noch bevor alle Handshakes abgehandelt sind und die Datenverbindung steht, kann der Client seine Daten als Unicasts an den BUS geben, der diese an jede Station des emulierten LANs broadcastet. Abb. 5 Die LAN-Emulation Architektur. Die Funktionsweise der LAN-Emulation läßt sich in fünf Schritten erklären: 1. Initialisierung: Damit ein Client Daten versenden darf, muß er zuerst Mitglied eines emulierten LANs werden. Dazu muß er die Adresse des zuständigen LES finden. Die Spezifikation sieht hierfür mehrere Vorgehensweisen vor. Zuerst versucht der Client, per SNMP (simple network management protocol) über ILMI (das interim local management interface) die Adresse des Configuration Servers (LECS) aus einer Tabelle im Switch zu bekommen. Er baut dann kurzzeitig eine Kontrollverbindung zum LECS auf, um von ihm die Adresse des LES zu erhalten. Wenn der LECS nicht erreichbar ist, wird in der Switchtabelle nach einem anderen LECS oder gleich nach einem eingetragenen LES gesucht. Wenn der Client hiermit keinen Erfolg hat, verbindet er sich mittels einer "well-known-ATM-address" mit dem für jedes ATM-Netz gemäß L-UNI spezifizierten LECS. Eine andere Option sieht eine permanente virtuelle Verbindung zum BUS über einen "well known virtual path identifier / virtual channel identifier (VPI/VCI - 0/17 PVC)" vor. Der Client kann aber auch versuchen, eine früher konfigurierte Verbindung zu einen LES zu finden oder eine vordefinierte permanente Verbindung zwischen Client und LECS zu nutzen. 2. Konfiguration: Der Client teilt dem LECS seine MAC-Adresse, seine ATM- Adresse, den gewünschten LAN-Typ (z.B. Ethernet) sowie die maximum frame size (MFS) mit und erhält im Gegenzug die gewünschte LES-Adresse sowie die Bestätigung des LAN-Typs und der Framegröße. 3. Eintritt: Danach baut der LEC eine bidirektionale Kontrollverbindung zum LES auf und sendet ein "Join Request". Dieses Join Request beinhaltet seine ATM-Adresse, seinen LAN-Typ, die maximale Framegröße und gegebenenfalls eine Proxy-Indication. Die Proxy-Indication wird dann benötigt, wenn es sich bei dem Clienten um einen Konzentrator handelt, an den mehrere Endgeräte angeschlossen sind. Weiterhin teilt der LEC mittels Multicastadressen mit, welchen Gruppen er angehört und ob er Daten mit nichtregistrierten Zieladressen erhalten möchte. Der LES sendet nun entweder über die bestehende bidirektionale Kontrollverbindung des LEC oder über eine eigene unidirektionale Kontrollverbindung zum LEC ein "Join Response" zurück, das den Clienten zum emulierten LAN zuläßt oder ihn abweist. Wenn der Client abgewiesen wird, nimmt er den Join Request zurück, bricht die bidirektionale Verbindung ab und versucht sein Glück von neuem. 4. Registrierung und BUS-Initialisierung: Danach erkundigt sich der Client beim LES nach der ATM-Adresse zum Versenden von MAC-Broadcasts und erhält die BUS-ATM-Adresse. Der Client baut dann eine unidirektionale Verbindung zum BUS auf und der BUS fügt den Clienten seiner Point-to- Multipoint-Verbindung hinzu. 5. Datentransfer: Nun beginnt der eigentliche Datentransfer zu einem anderen Partner im emulierten LAN. Wenn der LEC Daten verschicken will, prüft er zuerst, ob er die zur MAC-Ziel-Adresse korrespondierende ATM-Ziel- Adresse bereits kennt und ob bereits eine virtuelle Verbindung zum Ziel besteht. Dies wird dann der Fall sein, wenn es sich um Verbindungen handelt, die häufig genutzt werden oder auf denen man Zeittransparenz benötigt. Ansonsten wird per Signalisierung nach UNI 3.1 (user network interface) eine Verbindung aufgebaut. Wenn der Client die ATM-Zieladresse nicht kennt, sendet er ein LE-ARP (LAN Emulation address resolution protocol) an den LES. Der LES ist entweder so intelligent, dass er den LE-ARP selbst beantworten kann, oder er gibt diesen auf seinen Kontrollverbindungen an alle bekannten Clienten weiter. Während dieser Zeit kann der Client bereits seine Daten über den BUS aussenden. Sobald der LES die ATM-Zieladresse liefert, baut der Client eine direkte Datenverbindung zur Zielstation auf und sendet die restlichen Daten über diese Datenverbindung. Um sicherzustellen, dass bei solchen Umschaltvorgängen Unicasts nicht doppelt verschickt aber auch nicht verloren werden, definiert die LAN-Emulation das sogenannte "flushing". Vor dem Umschalten auf eine neue Verbindung wird auf der gerade genutzen Verbindung eine Flush-Nachricht verschickt, die durch einen reservierten Inhalt im LE-Frame-Header gekennzeichnet ist. Der Empfänger sendet diesen Flush entweder auf einer Kontroll- oder einer Datenverbindung zurück und gibt somit bekannt, dass er alle Daten vor Aussenden des Flush erhalten hat. Erst jetzt darf der Sender auf der neuen Verbindung weitere Daten aussenden. Wenn alle Daten übertragen sind, wird die Verbindung nach einem vorgegebenen Zeitintervall abgebaut. Falls der LES die gewünschte Zieladresse nicht findet, gibt der Client die komplette Nachricht an den BUS weiter, der diese an die übrigen Clienten schickt. In analoger Weise handelt der Client dann, wenn er am ersten Bit der MAC-Adresse erkennt, dass es sich um ein Broad- oder Multicast handelt. Mittels LAN-Emulation kann man herkömmliche Netze via ATM verbinden, ohne dass man Änderungen an den vorhandenen Applikationen durchführen muß. Die LAN-Emulation-Clients, die im ATM-Adapter oder in den LAN/ATM- Switches installiert sind, stellen diesen Anwendungen die gewohnte MAC- Ebene zur Verfügung und sorgen damit für eine Entkopplung der Applikationen vom konkreten Übertragungsverfahren. Damit man ATM optimal nutzen kann, wird man jedoch im Laufe der Zeit neue ATM-spezifische APIs (application programmers interfaces) definieren, um die Protokolle der Leistungsfähigkeit von ATM anzupassen. ATM-Adapter der zweiten Generation müssen dann in der Lage sein, herkömmliche und ATM-konforme Applikationen gleichzeitig bedienen können. Mit dem hier hier beschriebenen Verfahren kann man schon heute virtuelle Netze in ATM-Umgebungen aufbauen. Zu beachten ist jedoch, dass es sich bei der Definition der LAN-Emulation um "work in progress" handelt. Das ATM-Forum hat noch nicht alle gewünschten Funktionen definiert. So wird für Dezember diesen Jahres die Version 2.0 der LAN-Emulation erwartet. Diese Version erlaubt u.a. die redundante Auslegung der zentralen Komponenten der LAN-Emulation und mehr Effizenz für große emulierte (virtuelle) LANs. 5. Zusammenfassung Den virtuellen Netzen gehört die Zukunft, aber leider noch nicht die Gegenwart. Noch ist hier zuviel Euphorie fehl am Platz, da fast nur proprietäre Lösungen am Markt sind und vieles, was heute über die Möglichkeiten virtueller Netze propagiert wird, noch gar nicht vollständig implementiert ist. Trotzdem sollte man das Thema ernst nehmen, aktuelle und kommende Aktivitäten genau beobachten und sein Netzwerk so gestalten, dass man sich hinsichtlich der Nutzung virtueller Netze nichts verbaut. Da sehr viele Hersteller das Thema erkannt haben, wird die weitere Entwicklung sehr schnell vonstatten gehen. Für kompatible Layer 2 VLANs wird IEEE 802.1q sorgen; für Layer 3 VLANs gibt es derzeit keine erkennbaren Spezifikations-Initiativen; für ATM existiert bereits die LAN- Emulation-Spezifikation Version 1.0, die in Kürze mit der Verion 2.0 um neue Funktionen ergänzt wird. 6. Glossar AAL ATM Adaption Layer API Application Programmering Interface ARP Adress Resolution Protocol ATM Asynchroner Transfer Modus BUS Broadcast and Unknown Server CRC Cyclic Redundancy Check CT Cut Through FCS Frame Check Sequence FDDI Fibre Distributed Data Interface HDLC High-level Data Link Control IEEE Institute for Electrical and Electronic Engineers IETF Internet Engineering Task Force ILMI Interim Local Management Interface IP Internet Protocol IS Internationaler Standard ISO/OSI International Standards Organisation / Open Systems Interconnection ITU International Telecommunication Union LAN Local Area Network LEC LAN Emulation Client LECS LAN Emulation Configuration Server LES LAN Emulation Server LAT Local Area Transport MAC Media Access Control MSAP MAC Service Access Point OSPF Open Shortest Path First P-NNI Private Network to Network/Node Interface PVC Permanent Virtual Circuit RIP Routing Information Protocol RFC Request for Comment SF Store and Forward SNMP Simple Network Management Protocol SOHO Small Office Home Office SVC Switched Virtual Circuit TCP/IP Transport Control Protocol / Internet Protocol UNI User Network Interface VN Virtuelles Netz VCI Virtual Channel Identifer VLAN Virtuelles LAN VPI Virtual Path Identifer WAN Wide Area Network 7. Literatur [1] Draft Standard for Virtual Bridged Local Area Networks P802.1Q/D1, July 4, 1996 [2] Horowitz Steven E.: Dancing Bears IEEE 802.1 Virtual LANs [3] Eppele K.: Freischwebend; iX, Heft 12/1995, Seiten 146-153 [4] Eppele K.: Die LAN-Emulation ist der letzte Meilenstein auf dem Weg zu ATM, Computerwoche, Heft 5/1995 vom 3.2.95, Seiten 40-41 [5] Eppele K.: Spaß ab 100, iX, Heft 4/1995, Seiten 80-90 [6] Staff of Data Communications, Virtual LANs Get Real, Data Communications Heft 3/1995, Seiten 87-100 [7] Finn N., Frantz P., Wakerly J.: Two Models For VLAN Tagging Rev. 1.0 Suchbegriffe VLAN Virtuelles Netz Tagging IEEE 802.1q Cut Through Switch Store and Forward Switch Cell Oriented Switch Layer 2 Switch Layer 3 Switch LAN-Emulation Autor Der Autor Dipl. Inform. Klaus Eppele ist Inhaber der Firma improve marketing-training-consulting, Karlsruhe, www.improve-mtc.de. improve marketing-training-consulting Dipl. Inform. Klaus Eppele Heinrich-Weitz-Str. 31 76228 Karlsruhe Tel: 07 21 / 94 74 6-21 Fax: 07 21 / 94 74 6-22 eMail: eppele@improve-mtc.de URL: http://www.improve-mtc Erschienen in HMD, Theorie und Praxis der Wirtschaftsinformatik, Heft 192 (1996), Seiten 5 - 23