Ist-Aufnahme LAN - Green-Field oder Update

Natürlich setzen wir mit der IP-Telefonie auf der LAN-/WAN-Infrastruktur auf. Und die Stärken und Schwächen dieser Infrastruktur schlagen sich eindeutig auf die Qualität und Verfügbarkeit der Telefonie nieder. Deshalb ist an einer der ersten Stellen eine Analyse der EDV-Ungebung notwendig. Dazu gehören die Komponenten, aktiv wie passiv, die Konfiguration dieser, die Applikationen, die neben VoIP auf dem Netz weiterhin ihren Nutzen bringen müssen, verfügbare Bandbreiten etc. In einer VoIP einsetzenden Firma im hohen Norden z.B. hat sich ergeben, das jeden Montag morgen um 10:30 Uhr die IP-Telefonie qualitativ zur Qual wurde. Nach einer längeren Analyse des gesamten Systems ohne das ein Fehler in der IP-Telefonanlage erkannt wurde, stellte sich heraus, dass jeden Montag morgen um 10:30 Uhr ein Printjob auf einen Nadeldrucker über das Netz gejagt wurde. Dieses ist als solches nicht sehr problematisch: Allerdings lagen Auslöser und Drucker dermaßen ungeschickt am Netz, dass nahezu jedes Segment einschließlich des Backbones von diesem Printjob belastet wurde. Durch geeignete Zusammenlegung der beteiligten Ports auf einen Ethernet-Switch hat sich das Problem ins Nichts aufgelöst und die IP-Telefonie läuft seit dem auf qualitativ hohem Niveau.

Bei der Betrachtung der EDV-Umgebung sind natürlich auch Protokolle gefragt, die auf dem Netz nebenbei auch noch installiert sind und eventuell eine wichtige Funktion erfüllen. Dazu muss ganz deutlich gesagt werden, dass einige Protokolle wie AppleTalk oder NetBEUI auf einem Netzwerk starke Broadcasteigenschaften besitzen. Dadurch sind sie nicht geeignet, um neben VoIP auf dem Netz zu laufen. Es sei denn es werden Subnetze über Layer3-Switching/Routing eingerichtet, die mit diesen Protokollen arbeiten ohne das dort IP-Telefonie mitlaufen muss. Hier kann man sich z.B. vorstellen, das für die beteiligten Arbeitsplätze ein IP-Telefon als Hardware-Lösung zum Einsatz kommt welches sich in einem getrennten Subnetz befindet.

Generell ist als Topologie für den Einsatz von IP-Telefonie Ethernet die geeignetste. Dies ergibt sich zum einen natürlich durch die starke Marktdurchdringung dieser Technologie, zum anderen aus der einfach gestaltbaren Erweiterung der Bandbreite innerhalb des Ethernets. Aber auch die Messgrößen Quality und Class of Service sind mittlerweile verfügbar. In dem Standard IEEE 802.3 sind mit p und Q Substandards definiert, die für Quality of Service / Class of Service sorgen und im Zusammenspiel mit hinreichender Bandbreite eine saubere Lösung für die IP-Telefonie bieten. Eine Voraussetzung allerdings muss im Ethernet erfüllt sein: es muss ein geswitchtes Ethernet sein. Jeder Teilnehmer muss sein eigenes Ethernet-Segment zur Verfügung haben. Und dies mit full-duplex Verbindungen. Einige Hersteller von IP-Telefonsystemen kokettieren mit der Aussage, dass ihr System auch auf shared Ethernet laufen würde. Beim shared Ethernet haben wir allerdings die Ethernet-Urgrundlage CSMA/CD: Carrier Sense, Multiple Access / Collision Domain. Und das letztere ist es, welches der IP-Telefonie im shared Ethernet den Garaus macht. Alle an einem Hub angeschlossenen Teilnehmer sind innerhalb einer Kollisionsdomäne und das bedeutet, das Kollisionen vorkommen. Kollisionen aber sind das Ende sämtlichen Echtzeitverkehrs, der über UDP transportiert wird. Denn UDP sorgt nicht für eine nochmalige Sendung von nicht erhaltenen oder korrupten IP-Paketen. UDP sorgt für eine nochmalige Verwendung des a la letzten erhaltenen Paketes. Bei geringen Paketverlusten kein Problem, aber wenn mehrere Teilnehmer an einem Hub angeschlossen sind, produzieren sie - auch ohne VoIP - Kollisionen. Also: gar nicht erst in Betracht ziehen! Wenn IP-Telefonie, dann auf geswitchten Netzwerken. Der Anwender und die eigenen Nerven werden es danken.

Aber auch im geswitchten Umfeld ist Ethernet nicht gleich Ethernet. Es existieren im Markt einige auch namhafte Anbieter von Switchhardware, deren Geräte bei den Echtzeitanforderungen von VoIP Grenzen aufzeigen. Hier gibt es aktuelle Tests die z.B. in der Network Computing, Ausgabe 03/2001, veröffentlicht wurden. Die Real-World-Labs haben mehrere VoIP-fähige Switches getestet. Dieser Test zeigt, dass es neben den Geräten des im Internet am weitesten verbreitetsten Herstellers noch andere am Markt existieren, die geeignet und sogar auch bessere Voraussetzungen bieten. Um ein paar Namen zu nennen: Extreme Networks mit den Summit- und Black Diamond- Switches, Enterasys Networks und Cisco Systems schneiden bei derartigen Test in der Regel gut bis sehr gut ab.

Auf jeden Fall kann mit der Auswahl derart geeigneter Switches, die auch IP-Routing durch ASIC-basiertes Layer3-Switching und damit mit "wirespeed" durchführen, eine Grundlage für Entlastung des Systemadministrators gelegt werden. Wenn derartig schnelle Geräte im Einsatz sind, bei denen alle Pakete, die durch einen Port ankommen durch einen anderen Port gesichert weitergeleitet werden - "wirespeed" eben - dann braucht man im weiteren nicht mehr ganz so viel in den Datenfluss zur Beeinflussung von Quality und Class of Service einzugreifen. Ganz aus der Pflicht ist man aber dabei trotzdem nicht, denn es ist bei IP-Telefonie nicht der Durchschnitt der Bandbreitenbe- und Netzwerkauslastung gefragt. Gefragt ist die ständige optimale Verfügbarkeit. Da können bereits einige wenige Peaks in der Auslastung schon für viel Verwirrung sorgen. Gerade dann, wenn zu diesem Zeitpunkt gerade der Chef telefoniert. Siehe beschriebenes Printjob-Problem.

Es soll allerdings hierbei nicht der Eindruck entstehen, dass die komplette Switch-Hardware ausgetauscht werden muss. Zum einen gehen wir hier von Teilbereichen der Firma aus. Das hieße im speziellen Fall, dass wenn dann nur einige wenige Switches mit der Aufgabe betraut werden, Echtzeitverkehr weiter zu vermitteln. Zum anderen kommt es natürlich ganz stark auf die Auslastung der Switches an, ob der einzelne dem anstehenden Verkehr gewachsen ist. Wichtig ist, sich der Problematik bewusst zu sein und zu wissen, dass momentan keine Messmethode existiert, die quantitativ festlegt, ob ein LAN für VoIP geeignet ist. Diese Messverfahren sind momentan im entstehen. Man könnte sich eine Quantifizierung über die Auslastung und das Fehlerverhalten des RTP-Verkehrs im LAN vorstellen. Allerdings scheitern konkrete Versuche dieser Art immer wieder an der Individualität jedes einzelnen Netzwerkes. Im Einzelfall ist über eine Eignung zu entscheiden und eine Netzwerkanalyse, die auch statistische Daten (per Sniffer o.ä.) über einen längeren Zeitraum sammelt, ist dafür ratsam bis notwendig. Als Resultat aus solchen Analysen kann sich ergeben, das es eines Redesigns des Netzwerkes bedarf. Ein solches Redesign z.B. der IP-Adressstruktur oder der Portbelegung tut nicht weh, kann aber Wunder bewirken.

Bis hierhin haben wir das LAN betrachtet. Aber einer der vom Marketing und den Marktforschern am stärksten herausgestellten Nutzen von VoIP ist die Kostensenkung bei Fernverbindungen. Hierbei stehen natürlich die internen Gespräche mit Filialen/Niederlassungen an erster Stelle. Als Nebenprodukt solcher Filialstrukturen fallen bei derartigen "Multizonen"-Installationen kostengünstige Gespräche in die Ortsnetze der jeweiligen Filialen als Nebenprodukt ab. Multizoning bedeutet, dass mehrere Gatekeeper, die zu einer Firma gehören und über IP-Verbindungen miteinander ständigen Kontakt haben, voneinander wissen und dementsprechend Gespräche in die Zone eines benachbarten Gatekeepers über diese IP-Verbindung geführt werden und sogar am Amtskopf der Niederlassung ins Ortsnetz telefonieren. Dieses Konzept setzt allerdings voraus, dass auf den WAN-Verbindungen genügend Bandbreite zur Verfügung steht und/oder bei der Bedienung dieser WAN-Strecken mit geeigneten Maßnahmen für eine Qualitätssicherung gesorgt wird.

Für Bandbreite im WAN zu sorgen, ob es nun direkte Standleitungen sind oder eine Vernetzung der Filialen über ein Virtual Private Network, kostet in der Regel viel Geld. Und das nicht nur einmalig sondern monatlich. Deshalb kann es hier ratsam sein, sein Augenmerk auf die Qualitätssicherung auf der verfügbaren Mindestbandbreite zu sorgen. Auch hier hat der Systemadministrator eine Vielzahl von Möglichkeiten, den einzelnen Anwendungen Bandbreite zu sichern bzw. zu beschneiden. Es ist schließlich nicht unbedingt wichtig, das eine E-Mail eine Minute früher oder später ankommt oder das Internet-Surfen ein paar Sekunden länger dauert. Aber unternehmenskritische Anwendungen sollten hier Vorrang genießen. Das ist aber nicht erst seit der Einführung von IP-Telefonie so. Der Austausch von Daten mit dem zentralen ERP-System über VPN ist ebenfalls eine solche unternehmenskritische Anwendung für die ausreichende und genügend schnelle Verbindungen existieren sollten. Jetzt kommt nur noch VoIP dazu. Und muss dementsprechend in der Priorität der Firma behandelt werden. In der Regel ist Sprachkommunikation besonders wichtig. Allerdings kann man hier ebenfalls Abstufungen festlegen, dass Sprachkommunikation für interne Zwecke nicht die höchste Priorität besitzt, ein Gespräch mit externen Gesprächspartnern wie Kunden oder Lieferanten allerdings die höchste Priorität besitzt. Dort handelt es sich auch um eine Darstellung des Unternehmens nach außen.

Für die Planung heißt dies wir identifizieren den Zweck unserer IP-Telefonie über das WAN: nur intern oder auch extern. Und legen dann fest wie wir reagieren wollen. Denn auch für die Router, die diese WAN-Verbindungen bedienen existieren verschiedene Möglichkeiten, Quality of Service zu bieten. Ein bekannter Standard, an dem weiterhin gearbeitet wird ist Differentiated Services (DiffServ), der für die Differenzierung der Bereitstellung von WAN-Ressourcen das Type of Service-Feld des IP-Paketes verwendet. Das Paket wird also gemäß der Priorität markiert und von den beteiligten Routern auf dem Weg zum Ziel untersucht und gemäß ebendieser Priorität behandelt. In Ergänzung von DiffServ arbeitet der Standard Integrated Services (IntServ), der weitergehende Einflussnahmen in das Identifizieren der Quellen eines IP-Paketes durchführt damit aber auch sehr kompliziert wird. Er sorgt dafür, das Aufsetzend auf dem RSVP-Standard (Ressource Reservation Protocol) zunächst die Strecke zum Ziel gemäß der eingestellten Priorität untersucht wird und bei positiver Rückmeldung eine Reservierung dieser Strecke stattfindet. Voraussetzung für den Einsatz dieser Möglichkeiten ist natürlich eine vorhandene Geräteinfrastruktur, die diese Merkmale unterstützt. Und das ist zugegebenermaßen selten der Fall.

Aber keine Sorge. Auch hier lässt sich mit relativ geringem Aufwand Hilfe beschaffen. Es existiert z.B. eine Lösung, bei der mit Hilfe von "Black Boxes" aus einer ungeregelten WAN-Strecke eine dynamisch verwaltete und mit Quality of Service ausgestattete wird. Dies Black Boxes werden LAN-seitig vor die Router-Schnittstelle installiert und können direkt Einfluss nehmen in welcher Reihenfolge und Größe IP-Pakete den Router zur weiteren Verarbeitung erreicht. Daraus ergeben sich zwei Vorteile: Zum einen werden die Router nicht mit "zusätzlichen" Aufgaben betraut und können sich um Ihre originäre Aufgabe, das Routing auf Layer3-Ebene, kümmern. Zum anderen wird ein Investitionsschutz garantiert, dass die vorhandenen Router auch für die innovativen, neuen Lösungen verwendet werden können.

Mit diesen Black Boxes können sehr detaillierte Filter gesetzt werden, die gewährleisten, dass die IP-Pakete mit den Prioritäten für die vorhandenen Ziele weitergeleitet werden. Hierbei geht es nicht nur um die Kontrolle, ob es sich um UDP oder TCP-Pakete handelt. Es wird höher in die OSI-Schichten geschaut. So kann z.B. für den Einsatz von IP-Telefonie festgelegt werden, dass RTP-Verkehr, der über einen spezifischen Kommunikationsport transportiert wird, mit der höchsten Priorität weitergeleitet wird. Aber auch wenn nicht unbedingt nur IP-Telefonie als echtzeitkritische Anwendung auf dem Netzwerk läuft, sondern auch Videokonferenzen über das IP-Netz abgehalten werden - im Intranet und in Verbindung mit Application Sharing eine sehr sinnvolle Weiterentwicklung des VoIP-Ansatzes - können für die Videokonferenzen höhere Prioritäten festgelegt werden, als für gleichzeitig stattfindende Telefongespräche und sonstige auftretende IP-Pakete. Dieser Effekt ist sehr deutlich spürbar und erlaubt auch eine deutlich Steigerung in der durchgängigen, dauerhaften Qualität der Sprachverbindungen.

Ein Aspekt, der sich aus dem Anschluss eines IP-Telefonie-Systems an eine WAN-Verbindung ergibt, ob über Stand- oder Wählverbindungen oder per VPN, ist natürlich noch die Sicherheit. Überall dort wo eine Schnittstelle von außen erreichbar ist, wird das Netzwerk für einen potentiellen Angriff freigegeben. Das gilt aber zunächst "nur" für die auch ohne VoIP vorhandenen Schnittstellen im Intranet. Der zusätzliche Faktor von VoIP beschränkt sich in der Regel um die Betrachtung der installierten oder zu installierenden Firewall. Um die IP-Telefonie über die Firewall herüber zu bekommen wird eine Firewall benötigt, bei der man den UDP-Port mit zu definierenden Regeln freischalten kann, denn über diesen Port läuft die Kommunikation im VoIP-Umfeld. Dieser Punkt bedarf einer kritischen Auseinandersetzung mit den Sicherheitsrichtlinien der Firma. Ein Diskussionspunkt, der immer wieder auftaucht ist die Amtschnittstelle des Gateways. Hier wird ja schließlich auch eine Schnittstelle, die von außen erreichbar ist, zum Angriff freigegeben. Mitnichten! Zumindest dann nicht, wenn ich die Funktion des Application Sharing über das Gateway abschalte. Was ja auch kein wirklich großartiger Verlust ist. Denn mit Gesprächspartnern, die ich über Amt anrufe Dokumente zu bearbeiten ist tatsächlich ohnehin schon sicherheitsrelevant. Wenn ich also diese Funktion deaktiviere, deaktiviere ich jegliche Möglichkeit auf der Datenebene das Gateway zu passieren. Das Gateway hat dann nur noch die Aufgabe Sprachverkehr zwischen dem Intranet und dem öffentlichen Telefonnetz/ISDN auszutauschen.

Mit den bisherigen Betrachtungen lässt sich nun eine optimale IP-Telefonumgebung designen. Wir haben die drei H.323-Komponenten mit ihren Auswirkungen auf Arbeitsweise am Arbeitsplatz und auf die LAN/WAN-Umgebung diskutiert und bei der Analyse des Netzwerkes Ergebnisse erzielt, die sich zusammen mit den Systemvoraussetzungen des IP-System-Herstellers in Action Items als Vorbereitung der Installation festhalten lassen. Sinnvoll ist es in jedem Fall mit dem Lieferanten ein Lasten-/Pflichtenheft zu erstellen, in dem sämtliche gegebenen Voraussetzungen und zugesicherten Funktionen detailliert beschrieben sind. Jeder, ob Kunde oder Lieferant, hat damit eine Grundlage für die Implementierung. Und eines steht sicherlich fest: Je detaillierter und konkreter die Vorbereitung und Planung je weniger Überraschungen treten bei der Implementation auf.