Bandwidth Consumption of Multi-Path Resilience Concepts

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

2. Inhalt • Motivation • Grundlagen • 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

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

4. 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.

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

6. Konzepte für Ausfallsicherheit: 1:1 Path Protection 01101 11101 10001 Nimm denanderen Pfad!

7. Konzepte für Ausfallsicherheit: 1:N Path Protection 11000 01101 11111 00001 Nimm denanderen Pfad!

8. Konzepte für Ausfallsicherheit: Haskin 01101 11001

9. Konzepte für Ausfallsicherheit: Link Protection 01101 00000

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

11. Konzepte für Ausfallsicherheit: Regional Protection Region 1 Region 2 Nimm denanderen Pfad! 01101 10001 01111

12. Konzepte für Ausfallsicherheit: Ring-Protection 11111 01110

13. Konzepte für Ausfallsicherheit: p-Cycles

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

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

16. Freigabe der Verbindungsstümpfe 100 100 100 100 100

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

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

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

20. 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

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

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

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

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

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

26. 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

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

28. Implementierung – Probleme mit dem Speicherbedarf Abhilfe durch Reduzierung der verwendeten Pfade: • Einführung einer Schranke für die maximale Pfadlänge • Nur Verwendung der kürzesten Pfade je Pfadpaar COST 239 Netzwerk Folge: ca. 472MiB benötigt, um alle Pfadpaare im Speicher zu halten (geschätzter Wert)

29. Auswirkungen der Pfadbegrenzung an COST 239 Berechnungen am COST-Netzwerk, 1:N Protection, Multipath-Routing erlaubt.

30. Vergleich der Ausfallsicherheitskonzepte an COST 239

31. Wandlung Link-Protection nach 1:N Protection

32. Vergleich der Ausfallsicherheitskonzepte an COST 239

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

34. Vergleich der Ausfallsicherheitskonzepte an WMW

35. Kapazitätsrelationen zwischen den Konzepten

36. Ergebnisse – Mehrwege-Erweiterungen COST 239 Netzwerk mit je 200 Gib/s Kantenkapaztiät

37. Ergebnisse – gleiche und beliebige Kapazitätsaufteilung COST 239 Netzwerk mit je 200 Gib/s Kantenkapaztiät

38. Ergebnisse – Unterschiedliche Zielfunktionen COST 239 Netzwerk (Standard)

39. 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

40. Vielen Dank für die Aufmerksamkeit!