Wider das Recht des Stärkeren
Runder Tisch: Angemessene Zuteilung der Netzwerkressourcen – Spätestens mit Voice-over-IP ist Quality-of-Service populär geworden. Die Vorstellungen sind jedoch nur selten konkret. Dabei nehmen die Bedeutung und Notwendigkeit von QoS für einen reibungslosen Anwendungsbetrieb weiter zu, wie ein Roundtable zeigte. Zu diesem luden »Network Computing« und das Forums Konvergenz & Wireless ein.









Wer mit dem Auto in den Süden in die Balkanländer zum Urlaub fährt, kennt den Tauerntunnel. Entweder steckt man in der Blockabfertigung oder versucht, diese durch eine andere Route zu umgehen. Dabei ist die Blockabfertigung ein gutes Beispiel für Quality-of-Service (QoS) im Alltag. Ohne diese wäre es dem Zufall überlassen, wie lange Autos vor dem Tunnel warten müssen. So können die Betreiber die knappe Bandbreite des Tunnels entsprechend steuern. Reine Bandbreite ohne Blockabfertigung (QoS) mag zu Nachtzeiten noch gut funktionieren. Dieses Beispiel hat viel Ähnlichkeit mit einer WAN-Verbindung zwischen zwei Netzwerken und verdeutlicht die Notwendigkeit von QoS.
Allerdings zeigte sich in einem Roundtable, veranstaltet von Network Computing und Forum Konvergenz & Wireless, dass es heißt, genau zu differenzieren. Die Verhältnisse in LAN, WAN und Wireless-LAN sind derzeit sehr unterschiedlich. Dabei beschäftigte das Thema Bandbreite versus QoS die Runde sehr intensiv. So wie B nach A kommt, führt auch das Thema QoS fast zwangsläufig zur Frage nach Service-Level-Agreements. Bei einem genaueren Blick ins Wireless-LAN tauchte die Frage nach Wireless-Switches als Instrument zur Quality-of-Service-Steuerung auf. Hier war sich die Runde nicht ganz einig. Auch die Technologiewahl kann ein Instrument sein, QoS anzugehen. Dies zeigte die Diskussion um DECT oder Voice-over-WLAN für die drahtlose Sprachversorgung. Die Einrichtung von QoS bedarf auch intensiver Gespräche mit dem Anwender. Besonders deutlich wurde dies in den Diskussionen über den Übergang zwischen LAN und WAN.
Viele Gründe für QoS anstatt mehr Bandbreite
Beim Stichwort Quality-of-Service fällt als Begründung meist das Stichwort Voice-over-IP beziehungsweise konvergente Netze. Hier zeigt sich die Notwendigkeit von QoS sehr deutlich. Thomas Boele, Marketing-Manager Central-Europe bei 3Com, nennt als einen Grund, dass sich sonst Applikationen gegenseitig behinderten. So bekämen zeitkritische Anwendungen wie VoIP oder Terminal-Dialoge Probleme durch Lösungen, die sehr große Pakete erzeugten. Für Boele ist die Theorie, dass sich mit Bandbreite alles lösen ließe, ein Relikt aus der Vergangenheit. Ein besonderer Punkt ist für ihn dabei das WAN: Hier müssten sich Anwendungen auf jeden Fall die Bandbreite teilen. Armin Schmidt, Senior-Manager Enterprise-Project-Support bei Nortel, erklärt, dass sich im LAN manches mit Bandbreite lösen lasse. Im Extremfall müsse die zur Verfügung stehende Bandbreite aber den maximal möglichen Verkehr zu jedem Zeitpunkt aufnehmen können. Im WAN sei dies allerdings nicht bezahlbar. Zu den konvergenten Netzen liefert Schmidt noch ein weiteres Argument für QoS: geschäftskritische Applikationen, die immer mehr kommen. Allerdings hat Mike Lange, Manager Business-Development & Product-Marketing bei D-Link, die Erfahrung gemacht, dass viele Unternehmen derzeit überhaupt kein QoS besitzen. Sie setzten VoIP ein und würden das Thema zunächst nur mit Bandbreite und Priorisierung lösen. Auch Karsten Kahle, Managed-Services, Leiter Design bei QSC, hält mehr Bandbreite, für eine Möglichkeit, die Qualität zu erhöhen, falls es einen Engpass gibt. Als Vertreter eines Carriers sieht er diesen besonders auf der letzten Meile. Im Backbone selbst sei genügend Übertragungsleistung vorhanden. Beim WAN gibt es einmal das Zugangsthema und das Backbone selbst. Hier müsse es jeweils QoS durchgängig geben. Christian Krischke, Leiter Sales-Engineering bei Telefónica Deutschland, streicht dagegen heraus, dass erst mit QoS Carrier Layer-3-Netze gut betreiben und in Konkurrenz zu ATM oder Frame-Relay treten könnten.
Nach der Erfahrung von Uwe Sauerbrey, Vice-President und Leiter Produktmanagement bei Swyx Solutions, gibt es für VoIP in einem 100-MBit/s-LAN mit Switcharchitektur in der Regel keine Probleme. Im Wireless-LAN lasse sich dagegen die Bandbreite nicht einfach erweitern, stellt Reinhard Müller klar, Regional-Presales-Manager Central-Europe bei Trapeze Networks. Zudem sieht er besondere Probleme dadurch, dass sich Bandbreite durch Störungen oder auf Grund wechselnder Entfernungen stark ändern kann. Das mache den Einsatz von Voice im WLAN ohne QoS nicht einfach.
Sowohl Mike Lange als auch Uwe Sauerbrey legen Wert darauf, dass man die drei Bereiche LAN, WAN und WLAN unterschiedlich behandeln müsse. Wie Reinhard Müller ist auch Sauerbrey der Meinung, dass man dem WLAN als Shared-Medium die meiste Aufmerksamkeit widmen muss. Aus Sicht von Swyx bleibt hier derzeit nur der Gang zu DECT. Für Oliver Wolff, Systems-Engineer bei Symbol Technologies, lässt dagegen durch eine vernünftige Priorisierung eine passende Sprachqualität erreichen. Dies gehe aber noch nicht über einen entsprechenden Standard. Auch Wolff sieht den Druck für QoS besonders im WAN und WLAN.
Bei allem Plädoyer für QoS findet Hans-Jürgen Jobst, Senior-Product-Manager IP-Solutions bei Avaya-Tenovis, dass erst einmal genügend Bandbreite vorhanden sein müsse. Dann könne man das Thema angehen. Nach Jobst erwarten Anwender ISDN-Qualität bei der Sprache. Ausfälle wie durch Broadcasts seien nicht akzeptabel. Je weniger Bandbreite vorhanden sei, als desto dringender sehe er den Einsatz von QoS an.
In den Zeiten von Würmern und Viren liefert Wolfram Maag, Internetworking-Consultant bei Cisco Systems, ein weiteres, gewichtiges Argument für QoS: die Betriebssicherheit. Ohne QoS komme es zu einer unbegrenzten Ausbreitung von Viren und Würmern. Dies habe es schon in vielen Netzen gegeben. Michael Marsanu, Chief-Technology-Officer bei Funkwerk Enterprise Communications, sieht nicht nur Schädlinge, sondern auch neue Applikationen wie Video-over-IP als Bandbreitenkiller. Mehr Bandbreite führt für ihn nicht zu einer nachhaltigen Lösung. Für René Princz-Schelter, Senior-Systems-Engineer bei Alcatel, gibt es ohne QoS keine vorhersagbare Netzwerkcharakteristik. Erst dadurch könne es Zusagen über die Dienstgüte im Netzwerk für eine bestimmte Anwendung geben. Dies gelte, so Princz-Schelter, besonders für Echtzeit-Anwendungen. Diese reagierten hinsichtlich Jitter, Paketverlust und Round-Trip-Delay sensibel. Schließlich bringt Helmut Rackl, Leiter Produktmanagment Systemtelefone, HiPath-Enterprise-Systems bei Siemens, noch Automatisierungsprojekte in der Fertigungssteuerung ins Spiel. Die Echtzeitfähigkeit sei hier sehr wichtig und durch Bandbreite allein nicht zu erreichen.
Während alle Betrachtungen von QoS und Bandbreite bisher eher statisch waren, führt Uwe Lepa, Sales-Business- Development-Manager bei Cisco Systems, die Dynamik von Netzen als QoS-Argument ins Feld. Selbst wenn das Netz ohne QoS zu Beginn funktioniere, könne sich das einfach ändern. Als Beispiel bringt er den Ausfall eines Systems: Dann sollten die wichtigen Anwendungen weiterlaufen und nicht alle einander ins Gehege kommen, weil sie gleichberechtigt seien. Oliver Wolff erweitert die Diskussion auf die Endgeräte. Denn QoS beginnt für ihn dort und geht bis zum anderen Endgerät beziehungsweise dem Server.
Die Verwaltung von Bandbreite nahm in der Diskusion zu Beginn die größte Rolle ein. Mike Lange betont aber, dass die Qualität eines Services mehr sei. Für ihn gehören dazu Schnelligkeit (Bandbreite), Verfügbarkeit (Sicherheit und Verfügbarkeit) und Nutzbarkeit (Administration). Eine solch klare Vorstellung haben Kunden nach der Erfahrung von Christian Krischke aber nicht davon. Somit sei es notwendig, den Kunden beratend zur Seite zu stehen, um die QoS-Anforderungen effizient umsetzen.
Auch Wolfram Mag sieht das und betont, dass Cisco den QoS-Einsatz vereinfachen wolle. Er führt als Beispiele einfache Tools für das Monitoring oder Assistenten für eine schnelle Anpassung an. Für Boele gehört auch Flexibilität dazu. Als Beispiel nennt er Intrusion-Protection-Systeme, die etwa Chats erlauben und gleichzeitig File-Transfers unterbinden könnten.
QoS verlangt nach SLAs
Die notwendige und vereinbarte Quality-of-Service kann sehr unterschiedlich sein. Um dies individuell festzulegen, bieten sich SLAs (Service-Level-Agreement) an. Dazu gehört auch das Monitoring der entsprechenden Parameter. Bei Telefónica sehe der Anwender über ein Portal die Auslastung und die Verfügbarkeit der Leitung, so Christian Krischke. SLAs ohne Kontrolle hält Wolfram Maag für nicht sinnvoll. Über den »IP SLA Agent« auf einem Cisco-Router könnten Anwendungen die Einhaltung auch überprüfen. Hans-Jürgen Jobst hat die Erfahrung, dass sich viele erst im Rahmen von VoIP Gedanken über SLAs machen. Sie wüssten gar nicht, welche Verfügbarkeit ihr Netz hat. Banken dagegen hätten ausgefeilte SLAs. Allerdings sind QoS und damit auch SLAs für Reinhard Müller nicht sinnvoll, wenn die Bandbreite von Beginn an geringer sei, als die wichtigen Anwendungen benötigen würden.
Für Helmut Rackl ist es ganz allgemein essenziell, die QoS-Daten als Basis für spätere Analysen aufzuzeichnen. Über sie könne man später die Ursache von Problemen identifizieren. Außerdem würden diese Informationen dazu beitragen, frühzeitig Performance-Engpässe zu erkennen und zu beseitigen, ergänzt Thomas Boele. Armin Schmidt bemerkt dazu: Viele Firmen hätten Netzwerk-Administratoren oder eine eigene IT-Abteilung im Haus. Dann sei eine QoS-Analyse kein Problem. Schließlich böten fast alle großen Hersteller geeignete Monitoring-Tools an. Ansonsten könne sich ein Unternehmen das Ganze in Form einer Dienstleistung einkaufen. Mike Lange gibt aber zu bedenken, dass echte Service-Level-Tools für die Anwendungsebene im sechstelligen Bereich lägen. Mittelständische Unternehmen setzten so etwas nicht ein. Im Normalfall verlaufe die Überwachung so, dass ein Anwender bei einem Ausfall den Helpdesk anrufe.
Die Ende-zu-Ende-Überwachung ist für Hans-Jürgen Jobst bei Sprache wichtig. Es gehe zuerst um die Sprachqualität. Was dabei in den einzelnen Netzwerkabschnitten passiere, sei zunächst zweitrangig. Avaya-Tenovis-Endpunkte besäßen deshalb entsprechende Monitoring-Möglichkeiten. Auch René Princz-Schelter sieht das so. Die Alcatel-IP-Phones enthielten daher einen QoS-Probe. Dieser messe permanent die Dienstgüte und melde sie an das zentrale Management. Helmut Rackl ergänzt, dass eine Ende-zu-Ende-Überwachung auch bei Siemens möglich sei.
Armin Schmidt will die Überwachung nicht auf Voice beschränken. Es hänge von den geschäftskritischen Anwendungen beim Unternehmen ab. Reinhard Müller gibt aber zu bedenken, dass ein Ende-zu-Ende-Monitoring nur aussage, dass ein Problem gebe, aber nicht wo.
SLAs müssen wechselnde Verhältnisse berücksichtigen. Armin Schmidt erklärt, dass sich die Wichtigkeit von Anwendungen ändern könne. So seien für den Rechnungsabschluss am Quartalsende eventuell andere Applikationen geschäftskritisch als in der übrigen Zeit. Uwe Lepa nennt als weiteres Beispiel das Wireless-LAN. In einer Lagerhalle mit Wireless-LAN könne sich die Ausleuchtung durch ein paar Paletten mit Wasser schnell ändern.
Schließlich geht es bei SLAs auch darum, festzulegen, was bei Änderungen passieren soll. Uwe Lepa greift sein WLAN-Beispiel auf: Hier müsse dann beispielsweise eine Anpassung der Sendeleistung erfolgen. Nicht immer geht das so einfach. Wenn die Bandbreite im WLAN für Sprache zu gering sei, so Reinhard Müller, könne man diese durch eine dichtere Aufstellung von Access-Points vergrößern.
Wireless-Switch oder nicht
Das Wireless-LAN arbeitet als Shared-Medium mit Access-Points als verteilten Zugangsinstanzen. Deren Schwierigkeiten daraus haben zur einer eigenen Gerätegattung geführt, WLAN-, Wireless-Switches oder Wireless-Controller genannt. Für Thomas Boele sind die Systeme wichtige zentrale Elemente für QoS: Es ließen sich Verkehrsregeln zentral einfacher durchsetzen. Ein weiteres Argument ist für ihn, dass sich dadurch die Möglichkeiten beim Netzwerkdesign wie durch den Einsatz von VLAN-Technologie erweiterten. Auch Armin Schmidt sieht die WLAN-Switches als immer wichtiger an. Deshalb habe Nortel eine enge Partnerschaft mit Trapeze. Siemens habe Chantry erworben, ergänzt Helmut Rackl. Hierein passe auch der Erwerb von Airespace durch Cisco, so Network Computing. Für Oliver Wolff sind die Wireless-Switches ideal, wenn es um schnelles Roaming unter Einhaltung des Sicherheitsregeln geht. Außerdem habe ein zentrales System den Überblick über die angemeldeten Clients und die verfügbare Bandbreite. Außerdem könnten, so Schmidt, WLAN-Switches Clients zwingen, sich an einem Access-Point mit wenig Last anzumelden, wenn beispielsweise der nächste bereist ausgelastet sei. Für René Princz-Schelter schafft der zentrale Ansatz eines WLAN-Switch-Systems erstmals die Möglichkeit, mehrere, bisher autonome WLAN Systeme miteinander zu synchronisieren.
Allerdings hält Michael Marsanu die Sache mit den Wireless-Switches für nicht so eindeutig. Zwar erfordere die Vielzahl der Applikationen eine zentrale Lösung. Marsanu bestreitet auch nicht die Notwendigkeit für Funktionen wie kurze Roaming-Zeiten oder zentrale Überwachung. Es sei aber unerheblich, ob dies ein Wireless-Switch, -Controller oder ein WLAN-Management realisiere. Sein Credo lautet: Man müsse von Fall zu Fall entscheiden, welche die richtige Architektur sei. In das gleiche Horn stößt Wolfram Maag: Man müsse prüfen, welche Lösung der Anwender brauche. Cisco sei in der Lage beide Architekturen anzubieten. Als Vorteil für eine dezentrale Lösung nennt Maag, dass sich Redundanzen leichter realisieren ließen. Einzelhändler bevorzugten diese Architektur. Auch 3Com setze im Enterprise-Bereich beide Architekturen ein, so Thomas Boele. Langfristig denkt er, würden die Wireless-Switch-Funktionen in normale Switches integriert. Dann werde die Management-Software zum Unterscheidungsmerkmal.
Dagegen zeigt sich Reinhard Müller als Verfechter der Wireless-Switch-Linie. Er nennt praktische Gründe: Um zu kontrollieren, in welche Netze einer Domäne ein Client dürfe, müsse ein entsprechender Filter zentral auf einem WLAN-Switch laufen. In einer dezentralen Architektur bekomme der Client nur Zugang zu lokalen Netzen am Access-Point. Wolfram Maag wirft ein, dass es auch mit einer zentralen Management-Instanz funktioniere. Die Umsetzung erfolge dann dezentral auf den Access-Points. Für Müller löst dieses Argument jedoch nicht das Problem, weil die VLANs dafür weiter lokal am Access-Point hängen müssten. Dies sei eine nicht mehr wünschenswerte Layer-2-Architektur. René Princz-Schelter führt außerdem ins Feld, dass nur ein Wireless-Switch-System beziehungsweise ein zentrale Appliance die hohen Anforderungen von Realtime-Anwendungen im WLAN bewältigen könne.
Noch lebt DECT weiter
Mit Voice-over-WLAN bekommt DECT Konkurrenz bei drahtlosen Sprachanwendungen. Doch DECT hat eine breite Basis. Hans-Jürgen Jobst stellt fest, dass DECT derzeit den Löwenanteil an Geräten besitze. Jährlich kämen rund 2,5 Millionen Geräte im Enterprise-Markt hinzu. Während DECT ausgereift sei, müsse VoIP die Lernkurve im Wireless-LAN erst noch bewältigen. Wireless-LAN verunsichere zusätzlich mit dem Buchstabensalat bei den Standards die Anwender. Sie griffen lieber auf eine bewährte Technologie mit günstigen Endgeräten zurück. Auch für Swyx habe DECT derzeit die Präferenz, so Uwe Sauerbrey. Was Endgeräte mit akzeptabler Batterielaufzeit anbelangt, habe DECT einfach die Nase vorn. Zudem sei gerade kleineren Unternehmen die Technologie egal. Sie hätten entweder überhaupt keine WLAN-InfrastrDies gelte heute. In zwei Jahren sehe es bei WLAN anders aus. Dann werde es Standards und preiswerte Endgeräte mit vernüftigen Akkulaufzeiten geben. In Bezug auf die Kompatibilität zwischen verschiedenen Herstellern habe DECT mit GAP die Nase vorn, so Schmidt.
René Princz-Schelter sieht Vorteile für DECT bei der Reichweite (2x) und der Zellgröße (4x) gegenüber der WLAN-Technologie. Bestehende DECT-Installationen geben nach der Erfahrung von Michael Marsanu wenig Grund dazu, auf Wireless-LAN umzusteigen. Auch er sieht keine Anzeichen, dass DECT kurz vor dem Ende stehe.
Doch die Frage nach DECT oder WLAN-Voice ist bei den Kunden angekommen. Diese Erfahrung mache Nortel, so Armin Schmidt. Auch Helmut Rackl sieht, dass die Kunden DECT mit WLAN-Voice vergleichen. René Princz-Schelter findet, dass hinsichtlich Roaming und Handover beide Technologien nach aktuellem Stand auf gleicher Höhe seien.
Sobald ein Unternehmen bereits Wireless-LAN hat, sieht es für WLAN-Voice schon viel besser aus. Für Michael Marsanu werde dann schon aus Wirtschaftlichkeitsgründen das Daten-WLAN auch für Sprache genutzt. Auch Helmut Rackl meint: Wenn der Anwender nur eine Infrastruktur wolle, setze er heute Wireless-LAN ein. Für Oliver Wolff ist die Ausrichtung des WLANs auf reinen Datentransport kein Problem für einen Voice-Einsatz. Schließlich könne das Unternehmen nach einer Designüberprüfung die Access-Points passend verschieben. Wenn es um die Integration von Applikationen in IP-Anlagen gehe, habe Wireless-LAN einen klaren Vorteil, betont Thomas Boele. Denn hier könnten sie die Integration im drahtlosen Bereich fortsetzen. Uwe Lepa nennt als Beispiel dafür das Krankenhaus. Hier wolle man Insellösungen wie Abrechnung, Schwesternrufsystem oder Alamierungsserver integrieren. Da gehe es dann um passende IP-Endgeräte – auch drahtlos –, um das Ganze zu nutzen. Wolfram Maag bringt es so auf den Punkt: Auch wenn die Einstiegshürde bei DECT für den Anwender derzeit geringer sei, verbaue er sich damit ein Stück den Weg in die Zukunft. Wie wichtig die Möglichkeit aber für Unternehmen sein kann, hat Wolff erfahren: Auch wenn der Anwender es nicht brauche, wolle er sicher sein, es in zwei oder drei Jahren einsetzen können. Wolffs Meinung: An Wireless-Voice führt kein Weg vorbei.
WAN-LAN-Übergang muss flexibel sein
Über MPLS können Carrier auch im Backbone Quality-of-Service steuern. Beide Carrier im Roundtable, QSC und Telefónica, tun dies. Auf der Access-Seite verwende QSC Diffserv, so Karsten Kahle. Für Christian Krischke ist dabei wichtig, dass die MPLS-POPs (Point-of-Presence) möglichst nahe an den Kunden-Standorten lägen. So erreiche man einen geringerern Kostenaufwand bei der letzten Meile.
Die spannende Frage ist damit nicht, ob es QoS bei Carriern gibt, sondern wie sie die Priorisierung angehen. Karsten Kahle betont, dass QSC nicht nur die Dienste innerhalb eines Unternehmens dafür berücksichtige, sondern auch Klassen für verschiedene Kundengruppen bereitstelle. Interessant wird es für ihn bei der Anschlussleitung. Durch deren Begrenzung werde es wichtig, die richtigen Klassen für die Services festzulegen. QSC verwende in seinem Modell sechs neutrale Klassen. Erst das Gespräch mit dem Kunden entscheide, stellt Kahle klar, wie dieser dann die Klassen für seine Dienste nutze. Für Krischke geht es aber nicht nur darum, eine bestimmte Anzahl von Klassen bereitzustellen. Echtzeitanwendungen müssten ganz anders behandelt werden als sonstige geschäftskritische Applikationen, betont er. Die Ersteren benötigten mit Low-Latency-Queueing Verfahren eine andere Behandlung. Für den Übergang zwischen LAN und WAN gebe es bei Telefónica vier Klassen. Wären mehr notwendig, können je Klasse bis zu acht weitere Unterklassen über das DiffServ-Verfahren genutzt werden, ergänzt er.
Die Zuordnung von Klassen und Diensten scheint der Punkt zu sein. Dies hänge, so Hans-Jürgen Jobst, von den Carriern ab: Welche Möglichkeiten wie UDP-Ports oder IP-Adressen diese nutzten. Hier erwarte er von den Carriern die entsprechende Flexibilität, da Lösungen sehr projektspezifisch seien. Karsten Kahle stimmt hier zu: Man könne hier keinen Standard festlegen. Die Verknüpfung müsse im Gespräch mit dem Kunden erfolgen. Intern müsse der Carrier auf seinen Core-Routern noch ein weiteres Mapping zwischen Zugangsleitung und Backbone durchführen, ergänzt Christian Krischke. Dadurch könne dieser QoS anbeiten, das durchgängig von einem bis zum anderen Ende zur Verfügung stehe.
Eine Herausforderung bleibt jedoch beim Anwender. Thomas Boele erklärt: Das Unternehmen müsse die Datenströme richtig klassifizieren, bevor sie zum Carrier gehen. Außerdem gebe es eine Reihe von Instrumenten, um im voraus die Bandbreite zu steuern. Als Beispiele nennt Boele Traffic-Policies oder -Shaping. Dabei sei es wichtig, dass die Zuordnung im Netzwerk selbst erfolge. Boeles Begründung: Ansonsten gebe jede Applikation wahrscheinlich sich selbst die höchste Prioritätsstufe.
Fazit
Quality-of-Service wird immer mehr zu einem zentralen Bestandteil des Netzwerkes. Dies kommt einmal durch die Zunahme der Zahl geschäftskritischer Anwendungen. Daneben erfordert Sprache QoS. Auch die Schäden durch Viren und Würmer kann QoS begrenzen. Im WAN und Wireless-LAN ist die Notwendigkeit von QoS am größten. Deren Einsatz erfordert jedoch auch eine Überwachung, ob diese eingehalten werden. Hier sind SLAs ein gutes Mittel. Für QoS benötigt ein Wireless-LAN eine zentrale Steuerung. Standards machen es nicht allein. Ob jedoch ein Wireless-Switch dafür das Mittel der Wahl ist, oder dies vom jeweiligen Fall abhängt, darüber konnte sich die Runde nicht ganz einigen. Bei der Frage nach DECT oder
Voice-over-WLAN gab es Argumente für beide Seiten. Bei Wireless-LAN laufen Sprache und Daten über eine Infrastruktur. Gleichzeitig erlaubt WLAN die Integration neuer Anwendungen. Für DECT sprechen die ausgereifte Technologie und die breite Installationsbasis. Um den Übergang zwischen LAN und WAN richtig zu steuern, muss der Anwender zuerst einmal seine Applikationen kennen. Aufgabe der Carrier ist es dann, im Gespräch mit dem Nutzer den Anwendungen Klassen zuzuordnen. Die technische Umsetzung kann dabei sehr flexibel sein. Immer mehr Netzwerk-, auch Einstiegsgeräte, kommen mit QoS. Dabei bleibt es die Herausforderung für die Hersteller Lösungen bereitzustellen, mit den Administratoren QoS einfach verwalten. Aber auch dann wird sich die Komplexität im Netzwerk für den Anwender weiter erhöhen. Denn er muss mehr denn je seine Anwendungen kennen, die passenden Service-Stufe zuordnen, überwachen und eventuell Massnahmen ergreifen.
wve@networkcomputing.de