Internet Traffic Engineering Modellierung und Planung

Transkript

1 Internet Traffic Engineering Modellierung und Planung Eine Semesterarbeit in der Lehrveranstaltung AK-Netze - Multimediale Online-Übertragung Fachhochschule Schmalkalden FB Informatik Markus Neviadomski Michael Jahn 1 Einleitung Die Bedeutung von Computernetzwerken im Alltag wächst ständig. Damit einher geht auch der Bedarf nach immer mehr Bandbreite auch für den einzelnen Anwender. Hinzu kommen neue Dienste wie Multimedia-Applikationen, Echtzeitanwendungen und interaktive Anwendungen. Durch diese Entwicklung wächst auch der Bedarf nach mehr Dienstgüte im Internet, da die klassischen Anwendungen ganz andere Anforderungen an Netze haben als die heutigen Killerapplikationen wie zum Beispiel Video-Streaming und IP-Telefonie. Der heute verwendete best-effort -Ansatz mit seinen Schwächen bietet keine ausreichende Dienstgüte mehr und wird in Zukunft immer mehr an Bedeutung verlieren. Gezielte Beeinflussung und Steuerung des Datenverkehrs im Internet, aber auch in lokalen und Providernetzen wird sich zu einem wichtigen Element in der Vernetzungsstruktur der Zukunft entwickeln. Hinzu kommt der Wunsch der Provider, ihre Netzwerke möglichst effizient auszulasten, um bei geringen Kosten einen bestmögliche Auslastung zu erreichen. Dazu existieren derzeit zwei generelle Ansätze, um mehr Dienstgüte und vor allem verschiedene Abstufungen in Dienstgüteklassen zu realisieren. Auf der einen Seite steht das End-to-End Quality of Service, welches bereits in ersten Schritten realisiert wird. Demgegenüber steht der etwas akademische Ansatz des Traffic Engineering, der sich auf die Untersuchung und Steuerung der Internet-Traffic konzentriert und welches Schwerpunkt dieser Arbeit sein wird. Allerdings beschränken wir und nicht nur auf diese Sicht, sondern versuchen, die Verknüpfung beider Verfahren aufzuzeigen. Der erste Abschnitt legt die theoretischen Grundlagen des Traffic Engineering, geht aber soweit wie notwendig auch auf QoS ein. Danach möchten wir die verschiedenen Aspekte der Lastmessung und Modellierung für Internet-Traffic aufzeigen und Probleme in diesem Bereich erörtern. Die Schlussfolgerungen aus dieser Diskussion und die praktischen Auswirkungen werden im Anschluss diskutiert. Abschließend geht der Artikel noch auf Multi Protocol Label Switching (MPLS) als eine Technik ein, die alle Voraussetzungen mitbringt, um Dienstgüte in Netzen zu verwirklichen. Der Fokus liegt dabei auf der Unterstützung von QoS und Traffic Engineering durch MPLS. Dabei wollen wir zeigen, an welcher Stelle diese Technologie steht, wenn es sich um die Gestaltung zukünftiger Internet-Backbones dreht. 2 Traffic Engineering und Quality of Service Die Grundlagen 2.1 Traffic Engineering Die Komplexität des Internets ist aufgrund seines immer noch exponentiellen Wachstums nur schwer zu prognostizieren. Die hoch dynamischen Verkehrsflüsse ergeben sich als Konsequenz der Überlagerung einer enorm großen Anzahl von gleichzeitig bestehenden Kommunikationsbeziehungen zwischen Internetbenutzern und -Anwendungen. Deshalb ist eine angemessene Steuerung des Verkehrs unverzichtbar. Das Internet Traffic Engineering bezeichnet im Allgemeinen Maßnahmen zur technisch-wissenschaftlichen Beschäftigung mit Verkehr in Kommunikations- und Rechnernetzen. Es gibt zwei verschiedene Ansichten über die Inhalte des Traffic Engineering. Die Performance Evaluation Community definiert es wie folgt: Messung und Analyse von Verkehr, u. a. um typische bzw. möglichst repräsentative Lastsituationen oder Hochlastsituationen zu ermitteln. Charakterisierung und Modellierung von Verkehr, u.a. um für Planungs-, Optimierungs- und Seite 1

2 Analysemodelle über geeignete Verkehrscharakterisierungen zu verfügen. Steuerung und die allgemeine Beeinflussung des Verkehrs, um günstiges Netzverhalten zu gewährleisten. [14] Die IETF beschränkt Ihre Sicht auf das Teilgebiet der Steuerung und Beeinflussung des Verkehrs. Dabei umfasst die Beeinflussung Ihrer Meinung nach folgende Aspekte [14]: die Aushandlung von Verkehrs- und Dienstgüteparametern (Service Level Agreements); die Veränderung (z. Bsp. gezielte Zugangssteuerung) des Verkehrs an der Schnittstelle für den Zugang zum Kommunikationsnetz; die Priorisierung von Teilverkehr, um Pakete Kommunikationsnetz-intern mit unterschiedlicher Wichtigkeit behandeln zu können; die Verkehrsformung (z.b. Glättung von Schwankungen im Verkehrsaufkommen) um besseres Netzverhalten zu erzielen; die Wegeermittlung (Routing) für Datenpakete, die evtl. Rücksicht nimmt auf die Wichtigkeit der zu übertragenden Pakete; die Rekonfiguration des Netzes und die Anpassung von Wegelenkungsverfahren. Traffic Engineering und Dienstgütemanagent (Qualitiy of Service (QOS)-Management) stehen in engem Zusammenhang. Durch verschiedene Maßnahmen des Traffic Engineering ist es einerseits möglich die Dienstgüte des Netzes für laufende Übertragungen zu verbessern, und andererseits kann versucht werden für besonders wichtige Dienste von vornherein eine Mindestqualität zu definieren und zu garantieren. 2.2 Quality-of-Service Grundsätzlich kann Quality-of-Service (QoS) als Summe einzelner Maßnahmen angesehen werden, die zur Verbesserung der Dienstgüte für bestimmte, priorisierte Anwendungen oder auch Verkehrsflüsse beitragen. Dabei sollte die von der Anwendung geforderte Güte durch vorhandene Ressourcen bereit gestellt werden. Dies wird vor allem dadurch erreicht, die Priorität einzelner Pakete zu erhöhen und die anderer zu verringern. Die Steuerung dieser Prioritäten geschieht in Management-Tools durch unterschiedliche Behandlung der entsprechenden Warteschlangen. Ebenso können niedriger priorisierte Queues früher verworfen werden, sollte es zu Engpässen im Netz kommen. Hierbei sollten jedoch zwei Dinge beachtet werden: Erstens, Warteschlangen sollten niemals ganz gefüllt werden, ansonsten müssten evtl. nachfolgende Pakete verworfen werden, falls ein Engpass auftritt. Selbst dann, wenn es sich um höher priorisierte Pakete handelt. Und zweitens sollten Mechanismen vorhanden sein, die es erlauben niedriger priorisierte Pakete früher als höher priorisierte Pakete zu verwerfen, selbst wenn diese vor den höheren in der Warteschlange stehen. Aktuell unterschiedet man drei verschiedene so genannte Service-Levels. Service-Level bedeutet in diesem Zusammenhang vor allem die unterschiedlichen Möglichkeiten des Netzwerkes einen gewissen Service in End-to-End- Verbindungen zu gewährleisten. Die Services differieren vor allem in der Strenge in der sie Quality-of-Service-Zusagen treffen können, vor allem in Bezug auf Bandbreite, Verzögerung, Jitter und Verlustrate. Best-effort-Service: die Standardvariante ohne jegliche QoS-Zusagen; am besten zu charakterisieren durch eine FIFO- Warteschlange, die keine unterschiedlichen Prioritäten kennt Differentiated-Service (auch Soft-QoS genannt): einige Pakete werden bevorzugt behandelt (schnellere Abarbeitung, mehr durchschnittliche Bandbreite, weniger durchschnittliche Verlustrate); es stellt allerdings nur eine statistische Bevorzugung dar, es werden keine feste Zusagen getroffen, Pakete sollen mit hoher Wahrscheinlichkeit nicht zu spät kommen; meist durch Tools, wie PQ, CQ, WFQ, and WRED realisiert Guaranteed Service (auch Hard-QoS genannt): es stellt eine absolute Reservierung von Netzwerkressourcen für bestimmten Verkehr (intolerante Echtzeitanwendungen) dar; wird z. Bsp. durch das RSVP (Ressource Reservation Protokoll) realisiert; zu spät kommende Pakete sind wertlos [2] 3 Lastmessung und Modellierung Die Grundlage für das Traffic Engineering legen Messungen des aktuellen Internetverkehrs. Das heißt im laufenden Betrieb wird der Verkehr beobachtet um Veränderungen des Teilnehmerverhaltens (Benutzer sowie Applikationen) festzustellen. Messungen werden seit langem in allen Kommunikationsnetzen durchgeführt. Die Messdaten werden u. a. zur Verkehrslenkung und zum Test der aktuellen Dienstgüte verwendet. In sehr komplexen Netzen wie dem Internet werden jedoch auch noch weitergehende Messungen durchgeführt. Dabei wird die Größe und die Topologie des Netzes und die Verkehrslenkung im Netz erfasst, oder die Dynamik der Protokolle, der Seite 2

3 Abb1: Aktivitätsebenen und ihr Zusammenhang mit der Verkehrsmodellierung [1] Verkehrslenkung, des Anwendungs- und Nutzerverhaltens untersucht [1]. Mit Hilfe der Untersuchungen sollen Netzprobleme analysiert werden, um dadurch die Leistungsfähigkeit von Diensten bewerten und die Effizienz neuer Architekturen abschätzen zu können. 3.1 Messmethoden Meist wird zur Charakterisierung des Internet- Verkehrs eine passive Messmethode eingesetzt. Vor der Messung muss hierbei allerdings Klarheit über das eigentliche Messziel bestehen, d.h. der zu bestimmende Verkehr sollte im Bezug auf Verkehrsebene, Ort und zeitlichem Zusammenhang so genau wie möglich festgelegt werden. Wird dies nicht getan, ist das Ergebnis entweder nicht nutzbar oder die ermittelten Daten nicht konkret genug. Zur Aufzeichnung der Messgrößen kommen verschiedene Methoden in Frage. Zum einen können Monitoroptionen der vorhandenen Netzkomponenten eingesetzt werden. Vorzugsweise sollten jedoch spezielle Messgeräte eingesetzt werden, um nicht durch zusätzliche Belastung der Netzkomponenten das Messergebnis zu verfälschen. Hierzu genügt meist ein einfacher PC mit Monitor-Software wie z.b. tcpdump [17] oder ethereal [18]. Eine entscheidende Rolle spielt auch die Wahl von Messort, Messzeitpunkt sowie Messdauer. Vom Messort hängen die jeweils gemessenen Antwortzeiten der beobachteten Komponenten ab. Messzeitpunkt sowie Messdauer sind entscheidend für die Bewertung der Netzaktivitäten. Sie können z.b. im Tagesverlauf sehr stark schwanken. Ein Kompromiss zwischen kleinen Messdauern für stationäre Werte und großer Messdauer für ausreichend statistische Relevanz ist entscheidend. Allerdings treten bei der Messung von Internet- Verkehr auch mehrere Probleme auf. Zum einen nimmt die Varianz der Messwerte bei zunehmender Beobachtungsdauer erheblich zu. Meist können deswegen weder die Varianz der zu bestimmenden Größen noch ein Konfidenzintervall für den Mittelwert zuverlässig bestimmt werden. Ausserdem ist es schwierig direkte Messungen auf höheren Verkehrsebenen durchzuführen, da es zunehmend schwieriger wird noch einzelne Verbindungen zu erkennen oder Dialogpausen von Sitzungspausen zu unterscheiden. Für WWW- Verkehr ist beispielsweise das Nutzerverhalten aus Verkehrsmessungen innerhalb eines Netzes nicht mehr exakt zu bestimmen [1]. Allerdings kann das Nutzerverhalten durch die Verwendung von Heuristiken aus den Messergebnissen abgeschätzt werden. Z.B. wird versucht die nutzergenerierten HTTP-Requests durch die Zwischenankunftszeit abzuschätzen: übersteigt diese eine Sekunde so wird die Nachricht meist einer Nutzeranforderung zugeordnet. Aus diesem Grund ist es von sehr großer Bedeutung, die TCP-Ebene in die Analyse und Modellierung mit einzubeziehen. Das TCP- Protokoll stellt eine virtuelle, gesicherte End-to-End- Beziehung auf Basis des IP-Protokolls zur Verfügung. Der Paketfluss innerhalb einer solchen Verbindung erfolgt in beide Richtungen, wobei der Datenstrom nicht unbedingt gleichmäßig erfolgt, sondern sehr oft in Form von Bursts auftritt. Das dabei entstehende genauere Modell rechtfertigt in jedem Fall den Mehraufwand zur genauen Analyse der TCP-Schicht. Obwohl diese ganzen Abschätzungen nicht sehr genau sind, führen sie meist zu brauchbaren Ergebnissen, sofern man das Ziel der Messung kennt. 3.2 Modellierung Aufgrund der großen Unterschiede zwischen den einzelnen Meßgrößen und -methoden gibt es auch verschiedene Modellierungsansätze für die Systemund Verkehrsmodelle. Diese gliedern sich grob gesehen in Nutzer-, Anwendungs-, Transportprotokoll- und Netzmodell (siehe Abb. 1). Zwischen jedem dieser Teilmodelle findet ein bidirektionaler Informationsfluss statt und sie können in den Kategorien Rückkopplung, Ebenen und Bündelung unterschieden werden. Modelle mit Rückkopplung reagieren auf Verzögerung und Verlust von Paketen im Netz, was ohne Rückkopplung nicht möglich wäre. Modelle die mehrere Ebenen simulieren sollen, enthalten normalerweise Nachbildungen der Mechanismen auf diesen Ebenen, sodass die Modellparameter physikalisch gedeutet werden können. Bei Untersuchungen von Servern werden Seite 3

4 Abb2: Reaktives WWW-Verkehrsmodell[1] beispielsweise detaillierte Modelle der Nutzer- und Anwendungsebene eingesetzt, die vollständige Transaktionen stochastisch nachbilden [1]. Ziel der Verkehrsmodellierung ist es, geeignete Verkehrsbeschreibungen zu finden, welche die Erzeugung einer realistischen Last auf ein zu simulierendes System ermöglichen [1]. Ein interessanter Ansatz ist die Summenbildung über Teilnehmerverkehre verschiedener Dienste. Dabei wird versucht, realistischen Internet-Verkehr, der eigentlich aus zahlreichen und sehr unterschiedlichen Beziehungen besteht (WWW, E- Mail, FTP, etc.), aus dienstspezifischen Einzelquellen nachzubilden, da die Beziehungen einzelner Teilnehmer relativ exakt modelliert werden können. Es wird für einen einzelnen Teilnehmer getrennt nach den einzelnen Diensten ein Lastmodell erstellt. Wendet man darauf die Ergebnisse einer Lastmessung in einem charakteristischen Internet-Zugangsnetz für einen einzelnen Teilnehmer an, erhält man ein recht gutes diensteabhängiges Lastprofil für einen einzelnen Nutzer. Diese Unterteilung in einzelne Dienste ist zwingend notwendig, wenn man ein ausreichend genaues Modell erstellen will. Dies wird sofort deutlich, wenn man das Volumen zum Beispiel HTTP, FTP und Mailtraffic auf einem durschnittlichen Internetlink vergleicht. Dabei hat momentan HTTP mit Abstand das größte Volumen zu verzeichnen. In einem solchen Modell fasst man idealerweise die einzelnen TCP-Übertragungen zu bestimmten Gruppen zusammen. So kann man einen HTTP-Abruf einer Webseite eine request- Nachricht und ein oder mehrere response- Nachrichten zuordnen. Somit kann man die entsprechenden responses genau einem request zuordnen. Die Schwierigkeit besteht zum einen in der Abgrenzung solcher Objekte und zum anderen in der großen Varianz, vor allem der responses. Während ein request meist die 1500Byte nicht übersteigt, in der Regel ist dieser etwa 380Byte groß[14], kann ein response von wenigen Byte bis hin zu vielen Megabyte umfassen. Die Streuung an dieser Stelle liegt sehr hoch, wodurch eine genaue Prognose wieder erschwert wird. Hilfreich ist auch hier eine Unterscheidung nach dem übertragenem Dateityp (ASCII, Video, Bild). Für ein umfassendes Verkehrsmodell erfolgt die Aufaddierung der einzeln modellierten Dienste und die Hochrechnung auf die zu erwartenden Teilnehmerzahlen. Dabei ergibt sich sehr schnell eine hohe Komplexität, welche eine hohe Disziplin bei der Modellierung erfordert. Der Vorteil zeigt sich aber schnell bei den Möglichkeiten, die damit realisierbar sind. So bietet sich dieser Ansatz zum genauen Untersuchen von dienstbezogenen Merkmalen in einem Netz sehr an, auch ist durch das Variieren von einzelnen Parametern eine recht schnelle Anpassung an veränderte Ausgangssituationen in einem gewissen Rahmen möglich. So kann bei plötzlichen Ansteigen von filetransfer durch übermäßige Tauschbörsennutzung das Modell angepasst werden, indem die Lastdaten für diesen Verkehr nach oben korrigiert werden. Auch können einzelne, konkrete Lastsituationen untersucht werden oder verschiedene Warteschlangenstrategien theoretisch untersucht werden. Da die Modelle über Summenverkehre diverse Nachteile mit sich bringen (z.b. die Momentaufnahme von Messwerten hängt von der in dem Moment erreichbaren Datenrate ab) wird oft eine reaktive Modellierung benutzt. Hierbei werden vor allem Rückkopplungseffekte mit berücksichtigt. Insbesonders ist die Modellierung des TCP- Protokolls mit seinen Flusskontroll- und Paketwiederholungsmechanismen für die reaktive Modellierung von Paketverkehr unerlässlich. Die Rückkopplungen bei einem reaktiven WWW- Verkehrsmodell werden in Abbildung 2 dargestellt. Die Bestimmung der einzelnen Parameter eines solchen Modells ist sehr umfangreich, da für jede einzelne Ebene Parameter definiert und bestimmt werden müssen. Einige davon (z.b. Nutzerungeduld) können nicht genau bestimmt werden und man verwendet deshalb wieder Heuristiken zur Abschätzung dieser Parameter. Das größte Problem, vor dem die Modellierung heute steht und wo auch in Zukunft keine Änderung Seite 4

5 zu erwarten ist, ist die große Varianz der einzelnen Modellparameter. Diese ist ein Problem bei der Simulation für einen längeren Zeitraum. Auch nach langer Simulationszeit sind vor allem bei hoch variantem Verkehr immer noch starke Schwankungen feststellbar, so dass genaue Aussagen auch hier erschwert werden. Desweiteren entstehen bei der Simulation großer Topologien, wie es zum Beispiel für die Entwicklung von Routing- Algorithmen sinnvoll wäre, derart komplexe Modelle, dass man schnell an die Grenze des sinnvoll machbaren stößt. Abb3: Architektuer eines IP-Zugangsnetzes [4] genug darstellt, aber gleichzeitig auch eine möglichst geringe Komplexität aufweist. Desweiteren müssen die unterschiedlichen Dienstgütemerkmale Berücksichtigung finden. Um hier zu einem guten Kompromiss zu kommen, hat sich das universelle Link-Modell (Abb. 4) als sehr brauchbar herausgestellt. Gleichzeitig bietet es eine gewisse Sicherheit bei der Planung, da man auch für das Auftreten von Hochlastbedingungen auf der sicheren Seite ist. Modelle, die auch die Aggregation von reservierten, aber nicht benutzten Kapazitäten anderer Dienstgüteklassen berücksichtigen, haben sich in der praktischen Netzplanung als zu komplex und unhandlich erwiesen. Solche sogenannten integrierten Lastmodelle dienen eher der akademischen Forschung. Da vor allem im Bereich des elastischen Verkehrs derart präzise Vorhersagen und Planungen nicht möglich sind, ist die Nutzung der integrierten Modelle vom Aufwand nicht gerechtfertigt. Die Netzplanung als ganzes untergliedert man idealerweise in die Teilschritte physisches Netzdesign, Verkehrskategorisierung, Bedarfsermittlung und Dimensionierung. 4 Planung Bis vor kurzem bestand die Netzplanung in der Hauptsache aus der Realisierung von neuen Verbindungen mit immer höherer Bandbreite. Man ging im Allgemeinen davon aus, das durch extrem hohe Bandbreiten ein ausreichendes Maß an Dienstgüte zu realisieren war. Der Trend geht aber mittlerweile dahin, das viele Telekommunikationsnetzbetreiber zu einem universellen IP-Netz migrieren möchten, über das jede Art von Dienst abgewickelt werden kann. Gleichfalls eine Rolle spielt der wachsende Kostendruck, der zu einer effizienteren Nutzung vorhandener Strukturen zwingt. Dies erfordert aber die Schaffung von besseren Dienstgütemerkmalen als das bekannte Best Effort. Dieser Prozess beeinflusst auch entscheidend die Planung für solche Strukturen. 4.1 Netz-Design Das physikalische Design gehört nicht unmittelbar zum Traffic Engineering, ist aber grundlegende Voraussetzung für robuste Netzstrukturen, welche letztendlich mit Hilfe von TE realisiert werden sollen. Für die Platzierung der Zugangs- und Backboneknoten gelten ähnliche Regeln wie in der klassischen Telekommunikation. Der Hauptunterschied von TK-Netzen zu Multi-Service IP- Netzen zeigt sich hauptsächlich in der Dimensionierung der Links. Zur Plazierung der Netzknoten legt man im Allgemeinen den zu erwartenden Kommunikationsbedarf fest. Die Netzknoten werden dabei an den am rentabelsten Die Netzplanung erfolgt immer mehr auf der Grundlage der genauen Analyse und Modellierung von Internetverkehr. Die so gewonnenen Ergebnisse fließen unmittelbar in den Prozess der Netzplanung und Dimensionierung ein. Dazu ist es erforderlich, sich eines Modells zu bedienen, welches die zu erwartende Situation genau Abb4: Universelles Linkmodell [4] Seite 5

6 erscheinenden Orten aufgebaut. Dabei geht man erstmal von der Annahme aus, das der Kommunikationsbedarf proportional zur Anzahl der Teilnehmer an einem Ort ist. Desweiteren spielen natürlich auch vorhandene bzw. zugängliche Räumlichkeiten, eventuell verfügbare Leitungen und die Kosten einer Knotenplatzierung eine Rolle. Dann werden einige Knoten als so genannte Weitverkehrsknoten bestimmt. In welcher Art und Weise dies geschieht, hängt ganz von den Anforderungen an das Netz ab. Dazu existieren verschiedene Ansätze und Algorithmen[15],[16], zum Beispiel in Abhängigkeit des noch zu ermittelnden Bandbreitenbedarfes. Weiterhin definiert man Zugangsknoten und eventuell Aggregationsknoten. Einen solchen exemplarischen Aufbau zeigt Abbildung Verkehrskategorien Bei der Verkehrskategorisierung greift man das zugrundeliegende Verkehrsmodell auf und erstellt anhand dessen so genannte Verkehrsarten, in dem man die Applikationen nach ihrem Verkehrsverhalten zusammenfasst. Anhand des Verkehrsverhaltens ist die Einteilung in bestimmte Verkehrsklassen möglich. Diese lassen sich eindeutig durch entsprechende Verkehrs- und Dienstgüteparameter beschreiben und danach auf die entsprechenden Dienstgüteklassen eines Netzes abbilden. Das universelle Linkmodell orientiert sich hauptsächlich an der Unterteilung in elastischen und stromförmigen Verkehr. Eine Übersicht zur Einteilung und Kategorisierung zeigt Abbildung 5. Anhand solcher Einteilungen und der entsprechenden Kategorisierung des zu erwartenden Verkehrs muss der Netzplaner die Entscheidung über die zu verwendende Trägertechnologie treffen. Kann ein Netz aufgrund technologischer Einschränkungen (z. Bsp fehlende QoS-Unterstützung durch Schicht 2 -Protokolle ) eine Dienstklasse nicht erbringen, so ist auch die Unterstützung der darauf aufbauenden Anwendungen nicht oder nur teilweise gegeben. Nur durch den Einsatz geeigneter Trägertechnologie ist die gewünschte Dienstgüte realisierbar. 4.3 Bandbreitenermittlung Ein nicht zu unterschätzendes Problem stellt die Ermittlung des Bandbreitenbedarfes dar, für den das neue Netz konzipiert werden soll. Auf der einen Seite stehen dem Planer die Ergebnisse aus der Modellierung zur Verfügung, andererseits ist das Internet unter Umständen extremen Anforderungsschwankungen unterworfen. Das Abb5: Verkehrskategorisierung [4] reicht vom unerwartet massiv anwachsendem Verkehr einer bestimmten Applikation bis hin zum plötzlichen Wegfall bestimmter Applikationen. Hier werden die zum Teil sehr kurzen Halbwertszeiten einzelner Anwendungen (file sharing) deutlich. Die so entstehende sehr schlecht zu kalkulierende Belastung wird überdies noch durch die variablen Verkehrsbeziehungen beeinflusst. So können unterschiedliche Verkehrsbeziehungen auftreten, auf denen sich die Belastung ebenfalls sehr dynamisch gestaltet kann. So sind prinzipiell mehrere Kategorien denkbar, welche in Abbildung 5 dargestellt sind. Auch hier können sich die Verkehrsverhältnisse unerwartet massiv verändern. Auch sind mögliche Kommunikationen nur sehr unscharf zu beschreiben, da sich z. Bsp. der Standort von Servern sehr unterschiedlich gestalten kann. Auch der Anschluss neuer Teilnetze bzw. eine Bandbreitenänderung kann die Qualität und / oder Quantität des Transitverkehrs erheblich beeinflussen. 4.4 Dimensionierung für Stromförmigen Verkehr Die einfachere Bedarfsermittlung lässt sich für den stromförmigen Verkehr durchführen, da diese Verkehrsart i.d.r. von interaktiven Echtzeitdiensten, wie IP-Telefonie, erzeugt wird. Diese traditionellen Dienste sind bereits bei der Entwicklung von Telefonnetzen ausgiebig und über einen langen Zeitraum erforscht worden. Auch beim Aufbau von ATM-Netzen konnten in dieser Hinsicht Erfahrungen gewonnen werden. Der Unterschied zum klassischen PSTN liegt lediglich in der benötigten Bandbreite während die Charakteristik einer solchen IP-Verbindung identisch zu einer Verbindung in einem leitungsvermittelten Netz ist. Lediglich bei neueren interaktiven Anwendungen wie Spielen besteht Forschungsbedarf, um den dort auftretenden Verkehr besser einordnen zu können. Wichtige Parameter für stromförmigen Verkehr sind zum einen die Anzahl der Verbindungen zur Hauptverkehrsstunde (HV-Stunde) und deren Seite 6

7 jeweilige Bandbreite. Die Belastung zur HV-Stunde lässt sich durch die gleichen Algorithmen berechnen, die auch im klassischen Telefonnetz zum Einsatz kommen[5]. Für die Netzplanung ist es auch sinnvoll, bei Verbindungen die mit mehreren Bitraten beschrieben werden, diese in die effektive Verbindungsbitrate zu transformieren. Sollte eine Zugangskontrolle für stromförmigen Verkehr eingesetzt werden, so ist als Dienstgütekriterium die Blockierungswahrscheinlichkeit heranzuziehen. Unter Blockierungswahrscheinlichkeit versteht man im allgemeinen die Wahrscheinlichkeit, das ankommende Verbindungen aufgrund der schon bestehenden Last nicht mehr geschaltet werden, da ein oder mehrere Dienstgütekriterien durch das Netz nicht mehr erfüllt werden können. Dementsprechend muss die Dimensionierung so erfolgen, das die zu erwartende Anzahl der Verbindungen mit der ermittelten Bitrate in jedem Fall durchgeschaltet werden. Dazu sollte noch eine etwaige Reserve vorgehalten werden, um Schieflasten und unerwartete Änderungen in der Anforderung ohne Verlust an Dienstgüte zu ermöglichen. Die Blockierungswahrscheinlichkeit einer Verbindung muss als Ende-Ende Blockierungswahrscheinlichkeit betrachtet werden. Diese errechnet sich jedoch aus einer Menge von einzelnen Linkwahrscheinlichkeiten, da entlang des Verbindungspfades jeder einzelne Link zur Blockierung beitragen kann. Ziel der Netzplanung ist, alle Verkehrsbeziehungen auf allen Links zu ermöglichen und gleichzeitig die Kosten so gering wie möglich zu halten. Wird bei stromförmigen Verkehr an einem Netzknoten keine Zugangskontrolle durchgeführt, kann bei der Dimensionierung des nachfolgenden Links nicht die Blockierungswahrscheinlichkeit angenommen werden. Kommt es hier zu einer Überlastung, werden alle bestehenden Verbindungen in ihrer Bandbreite beschnitten, was schliesslich dazu führt, das eine solche Verbindung nicht mehr allen Dienstgütemerkmalen genügt. In diesem Fall sollte man bei der Netzplanung die Wahrscheinlichkeit annehmen, ab wann die einzelne Verbindung zu stark in ihrer Bandbreite begrenzt wird. 4.6 Dimensionierung für elastischen Verkehr Im Vergleich zu stromförmigen Verkehr stellt sich die Bedarfsermittlung und Dimensionierung für elastischen Verkehr ungleich schwieriger dar. Das ungefähre Verkehrsvolumen ist zwar durch Langzeitmessungen und Modellierungen vergleichbarer physischer Verbindungen möglich, letztendlich stellt dies aber nur eine sehr unsichere Vorhersage zur Verfügung. Hilfreich ist, das ungefähre Verkehrsvolumen zur Hauptverkehrszeit abzuschätzen und den zu erwartenden Dateigrößen und gemittelten Dateimengen gegenüber zustellen, sowie an dieser Stelle auf Wachstumsraten, welche anhand der Modellierung ermittelt wurden, zurückzugreifen. Trotzdem kann eine gewisse Unschärfe nie ganz ausgeschlossen werden. Als Qualitätskriterium für eine elastische Verbindung nimmt man den mittleren Durchsatz oder die gemittelte Zeitdauer für eine Übertragung bestimmter Datenvolumen an. Vorteilhaft wirkt sich auch der TCP-Regelmechanismus aus, welcher die Senderaten dynamisch an die gerade zur Verfügung stehende Bandbreite anpasst und sich am den Link orientiert, wobei für einen Ende-Ende-Pfad immer der Link mit der geringsten verfügbaren Geschwindigkeit maßgeblich ist. Geht man von der Annahme aus, das der TCP-Regelalgorithmus optimal arbeitet, ist die Aufteilung der Bandbreite vergleichbar mit einem Processor sharing, da alle zu einem Zeitpunkt gesendeten Daten quasigleichzeitig übertragen werden und jedem Fluss die gleiche Datenrate zur Verfügung steht. Die effektive Datenrate r eines Flusses ergibt sich also aus der Anzahl n der Verfügung stehenden Gesamtbandbreite für diesen Link nach r=c/n. Im Normalfall ist eine solche Berechnung aber immer sehr stark von Schätzungen und Prognosen abhängig. Die Vergangenheit des Internet ist aber gekennzeichnet durch eine starke Eigendynamik, die zum Teil sehr schnell zu Tage tritt. Ein gutes Beispiel ist für dieses überdimensionale Wachstum der Provider Arcor. Durch massive Preissenkung und starkes Bewerben der ADSL-Angebote kam es zu einem solchen Ansturm an Neukunden, sodass einzelne Netzsegmente des Arcor-Backbone lange Zeit keine ausreichende Bandbreite boten, um allen angeschlossenen Teilnehmern eine gute Versorgung zu ermöglichen. An diesem Beispiel sieht man das es gerade bei der Dimensionierung für elastischen Verkehr besser ist, etwas mehr Spielraum nach oben hin zu lassen, aber nicht ohne die Kosten aus den Augen zu verlieren. 4.7 Dimensionierung von Zugangs und Kernnetzen Wird ein Netzdesign ähnlich des in Abb. 3 dargestellten Modells gewählt und eine solche oder ähnliche Unterteilung des Netzes gewählt, hat das auch Auswirkungen auf die Netzoptimierung. Da an ein Zugangsnetz andere Anforderungen gestellt werden als an ein Kernnetz, sind jeweils andere Optimierungsansätze im Rahmen der Netzplanung erforderlich. Zugangsnetze stellen in den meisten Fällen einen nicht unbeträchtlichen Teil der Gesamtkosten dar, schon aus diesem Grund sollte hier eine Optimierung angestrebt werden. Auch sind Ausfälle und Lastprobleme in Zugangsnetzen für die angeschlossenen Teilnehmer meist deutlicher spürbar als im Kernnetzbereich. Ein Zugangsnetz ist Seite 7

8 idealerweise sternförmig aufgebaut und mit einem, meist redundanten Link mit dem Zugangsnetz verbunden. Dies entspricht genau dem in Abb 3 gezeigten Bild. Die zu erwartende Hauptlast wird sich auf den Aggregationslink konzentrieren, welcher das Zugangsnetz mit dem Kernnetz verbindet. Schon durch die Topologie bedingt entfallen Optimierungsschritte und Entscheidungen im Bereich des Routings, solange eine reine baumförmige Struktur vorhanden ist. Abb6: Verkehrsbeziehungen in IP-Netzen Die Dimensionierung der Zugangslinks erfolgt anhand der bekannten Bandbreiten, mit der die einzelnen Teilnehmer angeschlossen sind. Hierbei wird die Summe über die maximal angeschlossenen Teilnehmer und ihrer Bandbreite gebildet. Genauso kann mit dem Aggregationslink verfahren werden. Eine gewisse Überbuchung der einzelnen Aggregationslinks kann zwar gelegentlich ökonomisch gefordert werden, macht aber im Hinblick auf die Netzqualität wenig Sinn und sollte lediglich temporär akzeptiert werden. Weiterhin sollte die Annahme gelten, das das Kernnetz ausreichend dimensioniert ist und dadurch keine Rückwirkungen durch eventuelle Überlasten im Zugangsnetz spürbar werden. Somit ist eine unabhängige Dimensionierung möglich. Die Dimensionierung eines Kernnetzes dagegen verlangt nach einer anderen Optimierungsstrategie als dies bei den Zugangsnetzen der Fall ist. Hier trägt die Routingentscheidung maßgeblich zur Qualität des zumeist teil oder vollvermaschten Netzes bei. Das Ziel des Traffic-Engineering ist es, ein möglichst optimales Ergebnis bei der Wegefindung und der entsprechenden Dimensionierung der einzelnen Links auf diesen Wegen zu erreichen. Die Erstellung von Routingregeln und die Optimierung der Vermaschungsstruktur stellt hierbei die Hauptaufgabe dar. Besondere Beachtung findet dabei das Routingprotokoll, welches in diesem Netz zum Einsatz kommen soll. Grundlegende Voraussetzung zum Einsatz eines Routing- Protokolls ist, dass es die Umsetzung der ermittelten Wegemuster und Routingentscheidungen ermöglicht. Ausserdem muss es die Einhaltung aller getroffenen Dienstgüteanforderungen an das Netz gestatten. Hierbei erweist sich zum Beispiel ein Link-State- Protokoll wie OSPF als sehr geeignet, wenngleich dieses in seiner aktuellen Version recht schnell an seine Grenzen stößt. Dieser Routing-Protokolltyp ermöglicht unabhängig von den tatsächlichen Dimensionierungen das Einstellen einer Verbindungsmetrik für einen Link, allerdings ohne verschiedene Verkehrsarten zu berücksichtigen. Bei solchen Verfahren, die sich an Verbindungsmetriken orientieren oder eine explizite Routenwahl benutzen (wie MPLS), ist die Dimensionierung eng mit der Routenoptimierung verknüpft. Da sich beide Entscheidungen jeweils direkt beeinflussen, wäre hier eine Verbindung beider Schritte beim TE wünschenswert. Dies ist praktisch allerdings kaum realisierbar, da nur bei kleinen Netzen der Prozess überschaubar bleibt und die Komplexität bei größeren Netzen nur eine Planung in Einzelschritten erlaubt. Der gesamte Prozess des Traffic Engineering steht unter der Prämisse, das eine Netzstruktur geschaffen wird, die alle momentanen Anforderungen bezüglich der Dienstgüte erfüllt, aber auch für zukünftige Anforderungen genügend Reserven bereithält. Das bis hierhin ermittelte Netzkonzept erfüllt die Dienstgüteanforderungen hinsichtlich Leitungskapazität nur dann, wenn die tatsächliche Verkehrslast mit dem angenommenen Modell übereinstimmt. Da dies in der Praxis äußerst selten vorkommt und statt dessen mehr oder weniger große Abweichungen auftreten, muss das Netz in der Lage sein, darauf zu reagieren um trotzdem möglichst lange eine angemessene Dienstgüte zu bieten. Die am häufigsten auftretenden Probleme sind Überlasten durch zu hohes Verkehrsaufkommen und so genannte Schieflasten durch Abweichung vom vorhergesagten Verkehrsverhalten. Diesen Fehlerquellen kann man entgegenwirken, indem von vornherein höhere Übertragungskapazitäten geplant werden, als nach dem Modell erforderlich wären. Hier besteht aber die latente Gefahr, das massiv Überkapazität geschaffen wird. So wäre es von Vorteil, das jeder Link im Netz das maximale Verkehrsvolumen bewältigen kann. Wirtschaftlich gesehen ist eine solch hohe Überdimensionierung jedoch undenkbar. Die andere Variante wäre an der Seite 8

9 Netzgrenze Zugangskontrollmechanismen zu implementieren. Dadurch würden Überlastsituationen weitgehend vermieden werden können, allerdings ist dieser Ansatz im praktischen Einsatz zu unflexibel. Kurzfristig freiwerdende Kapazitäten können nicht durch Verkehrsbeziehungen mit momentaner Überlast genutzt werden. Einen Ausweg aus dieser Situation bieten dynamische TE- Verfahren wie adaptives Routing, Mehrwege- Routing oder explizites Routing. Letzteres wird von einem MPLS-Netz sehr vorteilhaft unterstützt. Diese Verfahren sind auch sehr gut geeignet, um im laufenden Netzbetrieb in die Routingstruktur einzugreifen, und dadurch Anpassungen an sich verändernde Lastsituationen zu ermöglichen. Darunter fällt zum Beispiel das ändern von Metriken oder Bandbreitenaufteilung für die unterschiedlichen Verkehrsarten. In welchen Intervallen diese Anpassung nötig ist, hängt ganz von den Anforderungen an das Netz ab. Im allgemeinen wird eine Änderung an der Routingstruktur weniger oft nötig sein,als die Bandbreitenbelegung der virtuellen Pfade. Sollte es zu einem Ausfall einer Netzkomponente und eines oder mehrerer Links kommen, kann mit Hilfe der TE-Mechanismen dem entgegengewirkt werden. So ist es möglich, Ersatzrouten zu schalten oder dynamisch auftretende Überlastungen durch Mehrwege-Routing zu reduzieren. Es bietet sich hier an, im Rahmen der Planung mehrere Fehler- und Schieflastszenarien zu erstellen, die auch die entsprechenden Verkehrsmatrizen für diesen Fall enthalten. Tritt dann ein solcher Fall ein, kann schnell darauf reagiert werden. Abb7: IPv6 Headerstruktur Ein letzter entscheidender Faktor des Traffic Engineering ist, dass alle genannten Maßnahmen nur auf einzelne Domänen, also eigenständige Netze mit gleicher Technologie, beschränkt sind. Für jede dieser Domänen ist ein eigener TE-Prozeß notwendig und für die Netzübergänge müssen gemeinsame Regeln und Abkommen zur Dienstgüte getroffen werden. Diese sogenannten Service-Level-Agreements stellen ein Regelwerk dar, auf das sich beide Netztechnologien verständigen können und dessen Dienstgütemerkmale von beiden Netzen gleichermaßen erfüllt werden können. Das Ergebnis dieser Planung muss, bevor es umgesetzt wird, auf jeden Fall einer Kostenbewertung unterzogen werden. Können die finanziellen Vorgaben nicht erfüllt werden, müssen alle oder einzelne Planungsschritte wiederholt werden, um abweichende Planungsvarianten zu erhalten. 5 TE als Grundlage für QoS Die im TE enthaltenen Verfahren, sind prinzipiell sehr gut geeignet, Dienstgüteparameter in das Design eines Netzes mit einfließen zu lassen und es Quality of Service(QoS)-fähig zu machen. In die Dienstgüte eines Netzes fließen immer die Leistungsparameter von mehreren Ebenen ein, von der Bitübertragungsschicht bis zur Anwendungsebene. QoS im Zusammenhang mit Traffic Engineering bezieht sich dabei auf die unteren Schichten des OSI-Modells bis zur IP-Schicht. Eine grundlegende Vorraussetzung für Quality of Service in einem Netz ist auch, das von der Bitübertragungsschicht an alle Layer die Möglichkeit bieten, Verkehrsklassifizierung und Priorisierung abzubilden. Dies sicherzustellen, indem entsprechende Übertragungstechniken wie ATM oder MPLS verwendet werden, ist eine Aufgabe des TE in der ersten Planungsphase. Ausserdem sind sie für eine verzögerungsarme Paket- oder Zellvermittlung notwendig. Auch an dieser Stelle greift wieder das TE, um Queuestrategien zu untersuchen oder einfach nur Netzwerkhardware auszuwählen, welche im benötigten Zusammenhang möglichst optimal die Anforderungen abdeckt. QoS selbst kann als Mechanismus verstanden Seite 9

10 werden, der sich hauptsächlich mit Dienstgüte auf Paketebene, für IP-Netze demzufolge auf IP- Pakete, in End-to-End Verkehrsbeziehungen konzentriert. Für das TE heißt das im Umkehrschluss, das genau an dem Punkt der Linkdimensionierung und des Routing auch über QoS-Parameter nachgedacht werden sollte. Dazu ist die bei der Planung vorgenommene Einteilung in elastischen und stromförmigen Verkehr eine Grundvoraussetzung, da auch die Dienstgüteklassen unter anderem nach diesem Schema strukturiert sind. Traffic Engineering ist also als Werkzeug zu verstehen, welches geeignet ist, ein Teilnetz QoS-fähig zu machen. Die von der IETF benannten zwei Möglichkeiten, um Quality of Service in einem Netz zu implementieren finden sich auch im Traffic Engineering Prozess in ganz ähnlicher Form wieder. 5.1 TE und Integrated Services Die Integrated Services, auch IntServ genannt, kann man in Form des Stromförmigen Verkehrs beim TE finden. Bei IntServ werden zum Beispiel über RSVP feste Bandbreiten für einen Flow belegt und stehen damit den anderen Flüssen über diesen Link nicht mehr zur Verfügung. Der TE-Prozess für stromförmigen Verkehr ist auch auf die fixe Allokation von Bandbreiten ausgerichtet, meist in Kombination mit einer Zugangskontrolle. Hier wird der Zusammenhang sehr direkt deutlich, durch Traffic Engineering werden brauchbare Bedingungen geschaffen, um in dem Netz guaranteed services anbieten zu können. Wenn eine Anwendung dann z. Bsp über RSVP eine Verbindung aufbauen und Ressourcen reservieren möchte, steht eine gewisse Bandbreite des Links für stromförmigen Verkehr zur Verfügung und darauf kann die angeforderte Verbindung gemappt werden. 5.2 TE und Differentiated Services Für Differentiated Services, kurz DiffServ, stellen sich dagegen die Methoden des TE für elastischen Verkehr als sehr geeignet dar. DiffServ geht ja nicht von einer statischen Reservierung gewisser Parameter aus, sondern basiert auf der unterschiedlichen Behandlung von Paketen. Dafür sind in einem Netz Priorisierungsmöglichkeiten vorzusehen, um die entsprechenden Dienstgüteklassen auch für diesen Ansatz des QoS zu bieten. Dadurch können verschiedene Dienstgüteparameter gesetzt werden, die eine gezielte Klassifizierung von Verkehr innerhalb der für den elastischen Verkehr reservierten Bandbreite erlauben. Dabei ist zwar eine Garantie der Dienstgüte nicht möglich, aber vor allem bei Last auf dem Netzsegment eine wesentlich verbesserte Weiterleitung der priorisierten Paket, als die bei best-effort der Fall wäre. Hinzu kommt eine wesentlich einfachere Implementierung gegenüber dem IntServ-Ansatz, da bei DiffServ lediglich das TOS-Feld im Ipv4 Header eine neue Bedeutung erhält und von jeder Netzkomponente ausgewertet wird. Im Ipv6-Protokollheader ist für die Priorisierung von Flows von vornherein an ein solches Feld gedacht worden,dort sind 8 Byte für eine Traffic-Class reserviert (Abb 7). Ausserdem unterstützt Ipv6 Flow-Control auf Paketebene, welches auch zur Dienstgüte-verbesserung genutzt werden kann. Interessant wird es, wenn auf dem Layer 2 ebenfalls ein Protokoll zum Einsatz kommt, das Dienstgüteparameter und Klassifizierung beherrscht. Eine solche Möglichkeit bieten ATM oder MPLS. Dabei können dann IP-basierte Dienstgüteklassen auch im Layer 2 prametrisiert werden und eine wesentlich effizientere Weiterleitung der Daten erfolgen. Welches Protokoll im Endeffekt zum Einsatz kommt, entscheidet sich je nachdem, welche Dienstgüteklassen im einzelnen von dem zu planenden Netz unterstützt werden sollen. Ein weiterer Vorteil von DiffServ ist die Möglichkeit der Aggregierung vieler kleiner Verkehrsströme zu sog. Behavior Aggregates. Dabei wird der gesamte Verkehr mit den selben Einstellungen des DiffServ-Bytes von jeder DiffServ fähigen Netzwerkkomponente unabhängig von Quelle oder Ziel gleich behandelt. Das minimiert den Berechnungsaufwand in den Routern und vereinfacht die Weiterleitung im Netz. 5.3 Routing Sobald eine Topologie eine gewisse Größe erreicht, hat auch die Planung der Routingstruktur einen nicht unerhebliche Einfluss auf die Dienstgüte in einem Netz. Das wohl wichtigste Kriterium ist dabei der Hop-Count, denn jeder neue Hop erhöht die Verzögerung um eine gewisse Zeit. Traffic Engineering kann an dieser Stelle eine steuernde Position einnehmen. So ist für Echtzeit-Verkehr, welcher sehr empfindlich auf Verzögerungen und Verzögerungschwankungen reagiert, direkte Routenführung denkbar, während weniger anfälliger Verkehr über Routen mit mehr Hops oder schlechteren Dienstgütemerkmalen geführt werden kann. Auch ist ein dynamisches Routing prinzipiell möglich, welches bei Überlastung einer Strecke toleranten Verkehr umroutet, um so dem weniger toleranten wieder ausreichend Übertragungsgüte zu sichern. 5.4 Service-Level-Agreements Die heutigen Netze bestehen in den seltensten Fällen vollkommen autonom und sind in sich abgeschlossen. Gehört ein Netz zum Internet, ist Seite 10

11 eine Verbindung zu anderen Netzen sowieso selbstverständlich. Andere Netze bedeuten meist auch andere Provider, Länder oder Organisationen. Da Dienstgüte und deren Merkmale ein sehr flexibler Begriff ist, kommt es natürlich auch bei unterschiedlichen Netzbetreibern zu unterschiedlichen Auffassungen, wenn es um die Definition von Dienstgütemerkmalen geht. Auch der geplante Verwendungszweck eines Netzes hat Einfluss auf das Verständnis von Dienstgüte. An dieser Stelle kommen die Service-Level- Agreements(SLA's) zum Tragen. Dies sind Vereinbarungen, welche an Übergängen zu anderen netzen abgeschlossen werden. Sie stellen Mindestvereinbarungen über Dienstgüte dar, welche von beiden Netzen auf jeden Fall erfüllt werden sollen. Dazu gehören die Verfügbarkeit, bereitgestellte Dienste, garantierte Dienstgütemetriken und auch die Verantwortlichkeit, falls diese Spezifikationen nicht eingehalten werden. Abb8: MPLS-Labelstruktur 6. MPLS Die bis hierhin angesprochenen Techniken und Möglichkeiten, speziell zur Umsetzung von Quality of Service scheitern momentan an der Tatsache, das 20 Jahre alte Protokolle im Einsatz sind, welche sich der Umsetzung der heutigen Wünsche und Anforderungen in den Weg stellen. Aus verständlichen Gründen ist aber eine grundlegende Neugestaltung mit neuentwickelten Protokollen und Techniken nicht denkbar. Allerdings existieren einige Ansätze, um auf vorhandenen Techniken aufzusetzen und neue zu implementieren. Dazu zählt auch das Multi-Protokoll-Label-Switching (MPLS). Einen umfassenden Überblick dazu gibt RFC3031 Herkömmliche Router treffen ihre Transportentscheidung auf Layer 3, indem sie den IP-Header analysieren und mit ihrer Routingtabelle abgleichen. Switches hingegen arbeiten auf Layer2 und leiten Daten zum Beispiel an Hand der MAC- Adresse weiter. Allerdings stellen Router zunehmend den Flaschenhals vor allem in Backbonenetzen großer Carrier dar. Je größer die Routingtabellen werden, umso schlechter wird der effektive Paketdurchsatz dieser Komponenten. Um diesen Engpass zu umgehen, entwickelte Cisco das so genannte Tag-Switching. Daraus wurde schließlich das entwickelt, was heute als MPLS bezeichnet wird. Auch ATM ist aus dieser Entwicklung hervorgegangen und kann als eine Ausprägung von MPLS angesehen werden. Der große Vorteil bei MPLS ist, das nicht wie beim klassischen Routing für jedes Paket eine Routingentscheidung getroffen wird, sondern pro Verbindung wird eine Route ausgehandelt. Dies reduziert die Last auf einem Router ganz extrem. Wie funktioniert dies nun auf Protokollebene? MPLS führt eine Zwischenschicht zwischen Layer 2 und 3 ein und versieht jedes Frame mit einem MPLS- Label, welches sich zwischen den Header von Schicht 2 und 3 befindet. Die Struktur dieses Label zeigt Abb 8. Kommt nun ein Paket an einem MPLS-Router an und das Label ist leer, schaut der Router in seiner Routingtabelle nach dem next Hop und fordert dort ein Label an. Dieses wird in den Header eingetragen und das Paket geht auf die Reise. Jeder Router in der Kette führt eine Label-Tabelle, in der die momentan benutzten Labels mit den zugeordneten Interfaces verwaltet werden. Kommen mehrere Pakete, die auf dem selben Weg zum selben Ziel wollen, kann ein und das selbe Label mehrfach verwendet werden. Dadurch wird praktisch bei einem Verbindungsaufbau eine Route nach einem klassischen Routingverfahren ermittelt, und danach erfolgt lediglich eine Weiterleitung anhand des vergebenen Labels, vergleichbar mit Layer 2 Switching. Eine neuer Routingprozeß ist lediglich notwendig, wenn eine zu lange Verbindungspause bestand, so das das Label bereits wieder verworfen wurde, oder wenn durch Leitungsausfall o. ä. sich eine Topologieänderung ergibt, die eine neue Route erfordert. Ein weiterer Vorteil ist, das die Labels nicht weltweit eindeutig sein müssen wie IP-Adressen. Lediglich innerhalb eines autonomen Systems dürfen keine Duplikate auftauchen. Dies führt dazu, das die Label-Tabellen nicht zu umfangreich werden und das nicht so lange Labels notwendig sind. Im Endeffekt besteht ein MPLS-basierendes Netzwerk aus Systemen, welche eine mittels IP-Routingprotokoll getroffene Routingentscheidung in einem Label-Switch-Path (LSP) temporär festhalten, um anhand dieser Information nachfolgende Datenpakete schnell zustellen zu können, ohne erneut eine Routingentscheidung treffen zu müssen. Dieser Vorgang wird Label-forwarding oder auch Labelswitching genannt. An dieser Stelle zeigt sich die enge Verzahnung der Begriffe des Routing und des Switching. Ein weiterer, entscheidender Vorteil von MPSL ist seine Multi-Protokoll-Fähigkeit. Das Schicht 3 Protokoll ist komplett austauschbar, ohne das an den Kernroutern irgendwelche Veränderungen vorgenommen werden müssen. Diese Router analysieren lediglich noch das MPLS-Label und brauchen im Normalfall nicht mehr in den IP-Header hineinzuschauen. Routingentscheidungen werden von den Randroutern eines Netzes getroffen, lediglich bei Änderung eines LSP sollten auch Seite 11

12 Kernrouter einen neuen LSP ermitteln können. Außerdem verschiebt sich der Skalierungsaufwand komplett an den Rand des Kernnetzes. Sollen weitere Nutzer angeschlossen werden, baut man lediglich neue Randrouter auf und erweitert bei Bedarf die Backboneleitungen in ihrer Bandbreite. 6.1 Traffic Engineering with MPLS Geradezu ideale Bedingungen bietet MPLS für Traffic Engineering Mechanismen, insbesondere für die Gestaltung von Quality of Service. Durch die Bildung von virtuellen Pfaden (LSP), ähnlich den switched virtual circuits (SVC) im ATM oder Frame- Relay bietet ein MPLS-Netz vielfältige Möglichkeiten zur Verkehrssteuerung. Eine LSP im MPLS kann auf zwei Arten angelegt werden. Einmal als automatische Hop-by-Hop LSP und einmal als explizit geroutete Pfade (ER-LSP). Für das Ziel des TE, den Verkehr möglichst effizient durch das Netzwerk zu führen, sind gerade die ER-LSP's interessant. Damit können auf einfache Art und Weise Traffic Engineering Fähigkeiten zur Dienstgütesicherung implementiert werden. Standardmaßig kommt bei hop-by-hop LSP das Label Distribution Protocol zum Einsatz, dieses erzeugt den Switch-Path. Die detaillierte Beschreibung dazu findet sich in RFC3036. Bei ER- LSP allerdings kommt eine neue Technik zum Einsatz, das contraint-based routing mittels Label Distribution Protocol (CR-LDP), welches speziell zur Unterstützung von DiffServ entwickelt wurde. Somit ist eine gezielte Beeinflussung der Paketströme möglich. Möglich wird das durch die individuelle Labelvergabe. Diese muss nicht nur nach Quelle Zielbeziehung erfolgen, sondern es können für zwei Pakete zum gleichen Ziel auch unterschiedliche Labels, z. Bsp. nach Dienstgüteanforderungen des jeweiligen Paketes vergeben werden. Für diese unterschiedlichen Label zu einem Ziel kann man wiederum ein Regelwerk erstellen, wonach bestimmte Label über unterschiedliche ER-LSP's geswitcht werden. Somit können für verschiedene Dienstgüteanforderungen bestimmte Pfade explizit ausgewiesen werden. Der Aufwand der Labelbestimmung und Klassifizierung liegt dabei wieder auf den Randroutern. Auch hier sind Verkehrssteuerungen bei Überlast möglich. Es erfolgt dann eine Umlenkung bestimmter Verbindungen auf andere LSP's. CR-LDP unterstützt weiterhin noch direkt Anforderungen des Traffic Engineering Verfahren zur Pfadoptimierung, Pfad-Bestimmung usw. Außerdem muss das Netz über eine hohe Flexibilität verfügen, um bei Ausfall eines Pfades schnell und mit möglichst wenig Verlust einen neuen Pfad zum Ziel zu finden. Verkehr gleicher Dienstklasse, wobei alle Pakete des Trunks das gleiche Label und die gleiche 3bit lange class of Service bekommen. Jeder Trunk wiederum kann mehrere Paketflüsse in sich vereinigen, während jeder LSP mehrere Trunk zusammenfassen kann. In [19] wird das Verkehrsverhalten bei Verwendung solcher Trunks untersucht. Allgemein kann man feststellen, das der Paketdurchsatz bei vernünftiger Parametrisierung durch Aggregierung gleicher Verkehrsklassen um ein vielfaches höher sein kann, als ohne diese Technik. Damit bieten sich wieder Optimierungsansätze im Rahmen des Traffic Engineering 7 Zusammenfassung und Ausblick Der in diesem Artikel behandelte Zusammenhang zwischen Traffic Engineering und Quality of Service lässt noch sehr viel Spielraum erkennen. Es wurden bei weitem nicht alle Aspekte aufgezeigt, die sich bei diesem vielschichtigen Thema ergeben. Insgesamt sollte der Artikel jedoch einen Überblick über die Zusammenhänge geben und die wichtigsten darstellen. Dazu kommt ein kleiner technologischer Ausblick auf eine recht neue Protokollschicht, die auch in Zukunft noch viel Entwicklungspotential hat. Da sich die Anforderungen an die Kommunikationsnetze beständig ändern, wird immer eine Anpassung und Weiterentwicklung nötig sein. Gerade diese Dynamik machen Netzplanung und Modellierung zu einem interessanten Forschungs- und Anwendungsgebiet. Für QoS interessant ist auch die Möglichkeit, innerhalb der LSP's virtuelle Trunks aufzubauen. Darunter versteht man die Zusammenfassung von Seite 12