Bandwidth Consumption of Multi-Path Resilience Concepts Wolfgang Mühlbauer / Matthias Wimmer muehlbaw@in.tum.de / m@tthias.net Betreuer: Claus Gruber

Inhalt Motivation Grundlagen Implementierung Ergebnisse Konzepte für Ausfallsicherheit Mehrwege-Erweiterungen Freigabe der Verbindungsstümpfe Implementierung Übersicht Modellierung der Graphen Aufbau der Nebenbedingungen Baukastenprinzip Probleme Ergebnisse Auswirkungen der Pfadbegrenzung Vergleich der Ausfallsicherheitskonzepte Einfluss der Mehrwege-Erweiterungen Nebeneinanderstellung der Zielfunktionen Zusammenfassung

Motivation für Ausfallsicherheit Flughafen Hauptbahnhof Zwei Wege vom Hauptbahnhof zum Flughafen: Jeweils 40 Minuten Fahrzeit

Konzepte für Ausfallsicherheit: Ansätze Bei Ausfallsicherheit in Datennetzen unterscheidet man zwischen drei Ansätzen: „Protection“: Die Fehlerszenarien sind vorausberechnet und die Ausweichpfade sind im Netz vorkonfiguriert. „Restoration“: Die Fehlerszenarien sind vorausberechnet, die Ausweichpfade werden aber erst im Bedarfsfall im Netz eingestellt. „Rerouting“: Erst im Fehlerfall wird für die betroffenen Pfade ein neuer Weg gesucht. Es ist nicht garantiert, dass ein solcher gefunden wird.

Konzepte für Ausfallsicherheit: 1+1 Path Protection 01101 11101 01101 11101

Konzepte für Ausfallsicherheit: 1:1 Path Protection 01101 11101 10001 Nimm den anderen Pfad!

Konzepte für Ausfallsicherheit: 1:N Path Protection 11000 01101 11111 00001 Nimm den anderen Pfad!

Konzepte für Ausfallsicherheit: Haskin 01101 11001

Konzepte für Ausfallsicherheit: Link Protection 01101 00000

Konzepte für Ausfallsicherheit: Local-to-Egress 01101 11100

Konzepte für Ausfallsicherheit: Regional Protection Nimm den anderen Pfad! 01101 10001 01111

Konzepte für Ausfallsicherheit: Ring-Protection 11111 01110

Konzepte für Ausfallsicherheit: p-Cycles

Mehrwege-Erweiterungen (Multi-Working-Path) 100 100 100 200? 100 100 100 100 100

Mehrwege-Erweiterungen (Multi-Protection-Path) 50 50 50 100 100 50 50 50

Freigabe der Verbindungsstümpfe 100 100 100 100 100

Implementierung - Übersicht Relationenmodell GRAPH Library Linearer Optimierer CPLEX/Concert Repräsentation von Eingabe und Ausgabe Bedingungen (Constraints) Resilience Verfahren Zentrale Ablaufsteuerung

Implementierung – Repräsentation von Graphen Eingabe: 2 GML Dateien Physical Network Demand Graph Ausgabe: 4 GML Dateien Working Graph Protection Graph Verknüpfung der Graphen durch Setzen von Relationen (siehe Beispiel)

Implementierung – Repräsentation von Graphen Working Graph Demand Graph Physical Network Protection Graph

Implementierung – CPLEX Optimierung der Bandbreite mit CPLEX (version 7.5) Zugriff auf CPLEX mittels Concert Solver (Optimierer) Modell Variablen Zielfunktion Constraints Abbildung: Komponenten für den Solver

Implementierung - CPLEX Variablen Variablen des Optimierers muss eine Bedeutung zugeordnet werden! (z.B. Working Pfad, Protection Pfad) Protection Einheiten Kreise Working Pfade Identifikation von Variablen (Auszug) Träger von Kapazitäten: Pfade PathPair PathPairForErrorEdge RerouteProtectionKey RingProtectionKey

Implementierung – CPLEX Variablen Semantisch zusammengehörige Variablen werden in gemein- samer Klasse verwaltet (z.B. alle möglichen Working Pfade). Klasse CplexVariable Vorteil: Allgemeine Formulierung von Constraints möglich Speichert ausgewählte relevante Variablen erlaubt einfaches Iterieren durch die relevanten Variablen Attribute: allVariables (map) Methoden: operator[] addVariables(...) Iterator

Implementierung – CPLEX Constraints Realisierung der Constraints Constraint {abstract} addYourself() Constraint n Constraint m … Ziel: Constraints sollen universell einsetzbar sein. Constraints "fügen sich selbst dem Modell hinzu".

Implementierung – Aufbau eines CPLEX Modells Constraint 1 Ablauf der Erzeugung eines CPLEX Modells Network Calculator (verwaltet die Resilience Klassen) Constraint n Constraint m … Resilience Klasse (Liste aller Constraints) Aktueller Schritt: Resilience Klasse erzeugen: Alle relevanten CPLEX Variablen und Constraints erzeugen. Berechnung im Network Calculator starten: Hinzufügen der Constraints aller Resilience Klassen und der Zielfunktion Network Calculator erzeugen: Alle CPLEX Para- meter werden initialisiert. Dem Network Calculator die neu angelegte Resilience Klasse hinzufügen.

Implementierung – Resilience Klassen Problem: Unterstützung verschiedener Resilience-Verfahren und Multipath-Erweiterungen erfordert Vielzahl an Resilience Klassen Lösung: Wiederverwendung und Vererbung Multipath Klassen (Dedicated) Vererbungshierarchie der Resilience Klassen (Grundidee) CplexResilienceStrategy Multipath Klassen (Shared) Konkrete Klassen zentrale Klasse: Berechnet z.B. relevante Working Pfade enthalten zusätzlich Variablen für ge- teilte (Protection) Kantenkapazitäten Spezielle Constraints für das gewählte Resilience Verfahren Constraints und Variablen für die gewählte Multipath Variante

Implementierung - Zielfunktionen Zielfunktion ist Bestandteil des Network Calculators Implementierung der abstrakten Methode addTargetFunction() in Unterklassen von CplexNetworkCalculator Zukünftige Erweiterbarkeit Mögliche Minimierungsziele: Minimale Gesamtkapazität Minimale Working Kapazität Minimales maximales Kantenauslastungsverhältnis

Implementierung - Modularität Mehrere Resilience Verfahren Modularität/Vielfältigkeit bezüglich: Resilience Verfahren Zielfunktion Multipath Variante 1+1, 1:N, Haskin, Local-To-Egress, Link, Regional, Rerouting with and without Stub-Release, Ring, pCycle Mehrere Working Pfade je Demand Mehrere Protection Pfade je Working Pfad Beliebige und gleiche Kapazitätsverteilung Verschiedene Optimierungsmöglichkeiten Verwendung unterschiedlicher Resilience Verfahren für jeden einzelnen Demand Graphen (falls mehrere Demand Graphen zu einem Physical Network existieren)

Implementierung – Probleme mit dem Speicherbedarf COST 239 Netzwerk # Knoten 11 # Kanten 52 # Pfade pro Demand 923 bis 1760 # Disjunkte Pfadpaare pro Demand ca. 250000 bis 500000 Folge: ca. 472MiB benötigt, um alle Pfadpaare im Speicher zu halten (geschätzter Wert) Abhilfe durch Reduzierung der verwendeten Pfade: Einführung einer Schranke für die maximale Pfadlänge Nur Verwendung der kürzesten Pfade je Pfadpaar

923 bis 1760 Pfade pro Knotenpaar Das COST-239-Netz 11 Knoten 2 x 26 Kanten 923 bis 1760 Pfade pro Knotenpaar ¼ bis ½ Million disjunkte Pfadpaare pro Knotenpaar 2 x 110 Demands Kopenhagen Berlin Wien Milan Paris Prag Amsterdam Luxemburg Brüssel London Zürich

Auswirkungen der Pfadbegrenzung an COST 239 Pfade/Knotenpaar Benutzte Kapazität Zeitverbrauch 10 1.649,12 Gib/s < 1 Minute 20 1.621,15 Gib/s 13 Minuten 30 1.613,40 Gib/s 47 Minuten 40 1.612,85 Gib/s 1 Stunde 24 Minuten 50 1.612,65 Gib/s 3 Stunden 2 Minuten 60 4 Stunden 1 Minute 70 7 Stunden 1 Minute 80 90 100 105 Berechnungen am COST-Netzwerk, 1:N Protection, Multipath-Routing erlaubt.

Vergleich der Ausfallsicherheitskonzepte an COST 239 Working- Pfade Protection-resources Working Kapazität Gesamt-kapazität 1+1 Protection Es existiert hierfür keine Lösung 1:N Protection 136 613 1.279,39 1.612,65 Haskin Link Protection 133 597 1.272,97 1.743,67 Local-To-Egress 138 651 1.270,27 1.719,64 Regional Protection 764 Rerouting mit Stub-Release 808 Rerouting ohne Stub-Release 139 850

Wandlung Link-Protection nach 1:N Protection

Vergleich der Ausfallsicherheitskonzepte an COST 239 Working- pfade Protection-resources Working Kapazität Gesamt-kapazität 1+1 Protection 110 116 1.535,00 3.142,50 1:N Protection 136 455 1.277,46 1.582,93 Haskin 128 492 1.267,50 1.773,44 Link Protection 129 646 1.272,50 1.692,25 Local-To-Egress 123 565 1.679,78 Regional Protection 134 643 1.277,69 1.582,92 Rerouting mit Stub-Release 137 668 Rerouting ohne Stub-Release 140 687

Selbst erstelltes Netz 9 Knoten 2 x 12 Kanten Das WMW-Netz Selbst erstelltes Netz 9 Knoten 2 x 12 Kanten 7 bis 12 Pfade pro Knotenpaar 72 Demands

Vergleich der Ausfallsicherheitskonzepte an WMW Working- pfade Protection-resources Working Kapazität Gesamt-kapazität 1+1 Protection 72 783,62 1.466,96 1:N Protection 90 129 564,74 867,73 Haskin 79 89 1.009,96 Link Protection Es existiert hierfür keine Lösung Local-To-Egress Regional Protection 95 307 867,76 Rerouting mit Stub-Release 94 272 Rerouting ohne Stub-Release 284

Kapazitätsrelationen zwischen den Konzepten 1+1 = 1:1 ≥ Haskin ≥ Link Protection ≥ 1:1 = Reroute ohne Stub-Release ≥ Regional Prot. ≥ Rerout mit Stub-Release Local-to-Egress Protection Ring Protection ≥ P-Cycle Protection

Ergebnisse – Mehrwege-Erweiterungen COST 239 Netzwerk mit je 200 Gib/s Kantenkapaztiät Erlaubte Zahl von Working Pfaden Working- pfade Protection-resources Working Kapazität Gesamt-kapazität beliebig viele 137 492 1276,85 1586,29 3 134 2 483 1 110 327 1272,50 1602,92

Ergebnisse – gleiche und beliebige Kapazitätsaufteilung COST 239 Netzwerk mit je 200 Gib/s Kantenkapaztiät Erlaubte Zahl von Working Pfaden Gesamtkapazität (Beliebige Aufteilung) Gesamtkapazität (Gleiche Aufteilung) Beliebig 1586,29 1588,44 3 1588,47 2 1588,52 1 1604,92 -

Ergebnisse – Unterschiedliche Zielfunktionen COST 239 Netzwerk (Standard) Zielfunktion Gesamt-kapazität Working-kapazität Maximale Kanten-auslastung Mittlere Kanten-auslastung min. Gesamt K. 1612,65 1279,39 99,52% 69,41% min. Working K. 1623,86 1267,50 94,34% 67,55% min. maximale Auslastung 1682,83 1315,62 70,00% 69,03%

Zusammenfassung Auswahl der kürzesten Pfade zwischen einem Knotenpaar scheinbar sinnvolle Heuristik. Unterschiedlicher Bandbreitenverbrauch der Resilience Verfahren. Bandbreitenverbrauch allerdings nicht einziges relevantes Kriterium Je mehr Freiheit bezüglich der Mehrwege-Erweiterungen desto geringer normalerweise der Bandbreitenverbrauch

Vielen Dank für die Aufmerksamkeit!