Die Kommunikationssysteme am RRZE Kommunikationssysteme am RRZE

Transkript

1 Die Kommunikationssysteme am RRZE Die Kommunikationssysteme am RRZE

2 Regionales RechenZentrum Erlangen Vorwort Der IT-Dienstleister der FAU Liebe Leser, Das Netz ist der Computer, so lautete der Slogan eines seinerzeit auch am RRZE stark vertretenen renommierten Computerherstellers. Der Hersteller wurde vom Markt aufgesogen, der Spruch ist geblieben und fand seine Editorial Die Kommunikationssystem am RRZE Regionales RechenZentrum Erlangen (RRZE) Kommunikationssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstraße Erlangen Herausgeber: Regionales RechenZentrum Erlangen (RRZE) Friedrich-Alexander-Universität Erlangen-Nürnberg Dr. G. Hergenröder Martensstraße Erlangen Inhalt: Susanne Naegele-Jackson susanne.naegele-jackson@fau.de Gestaltung / Layout: Anke Vogler rrze-redaktion@fau.de Berechtigung. Die geographisch extrem über mehrere Städte verteilte Lage der FAU sorgte am RRZE schon frühzeitig für eine zentrale Rolle des Kommunikationsbereichs. Die verteilte Lage als technische Herausforderung und die Einbettung des RRZE in einen Technischen Campus als Ansporn waren der Grund für eine wissenschaftliche Herangehensweise. Das RRZE engagierte sich zu Beginn der 80er-Jahre in der neu gegründeten Gesellschaft für Informatik Fachgruppe Rechnernetze und später in der Fachgruppe Echtzeitsysteme. Die Ausrichtung auf den Schwerpunkt Dienstqualität in Netzen war damit praktisch vorgeprägt. Die wissenschaftlichen Fördermöglichkeiten durch die Deutsche Forschungsgemeinschaft, das Bundesministerium für Bildung und Forschung / Deutsche Forschungsnetz und EU sowie die Investitionsprogramme des Landes wurden konsequent genutzt. Die Zusammenarbeit im Deutschen Forschungsnetz-Verbund und im Bayerischen Hochschulnetz sorgten für Know-how Transfer und thematische Ausstrahlung. Die Doppelsicht auf betriebliche Notwendigkeiten und wissenschaftliche Begleitung führte nicht nur zu anspruchsvollen Lösungen, sondern auch zu innovativen Entwicklungen, als Motor für neue Anwendungen, z. B. in der TV-Übertragungstechnik. Die gestalterische Gunst der frühen Stunde ist mittlerweile gewichen, immer einschneidendere Mittelkürzungen sind inzwischen das Thema, so dass man fast um die Zukunft bange sein könnte. Desto erfreulicher ist, dass Engagement, Wagemut und Einfallsreichtum in den Teams nicht nachgelassen haben, sondern sich erfrischend behaupten. Die vorliegende Schrift soll einen Eindruck über die technisch-wissenschaftlichen Ergebnisse des RRZE- Netzes bieten. Das RRZE wird in seinem wissenschaftlichen Engagement in der Kommunikationstechnik nicht nachlassen auch, um so seinen wissenschaftlichen Nachwuchs zu fördern. Dr. G. Hergenröder, Technischer Direktor, RRZE

3 Inhaltsverzeichnis Multi-Domain Monitoring and Troubleshooting perfsonar: Performance Monitoring in europäischen Forschungsnetzen Einführung 6 Performance Monitoring 6 Metriken 6 Messmethoden 7 perfsonar-schichtenmodell und Web Services 7 Die drei Schichten der Messarchitektur 8 perfsonar Web Services 8 Visualisierung und Benutzerschnittstellen 9 Zusammenfassung und Ausblick 10 Literaturverzeichnis 10 perfsonar-lite TSS: Schnelldiagnose von Netzverbindungen im EGEE-III-Projekt Einleitung 11 perfsonar und verwandte Arbeiten 12 perfsonar-lite Troubleshooting Tools 13 Einsatz im EGEE-Projekt und darüber hinaus 15 Zusammenfassung und Ausblick 15 Literaturverzeichnis 15

4 Network Virtualization and Future Internet Platforms Enabling Future Internet Research: The FEDERICA Case Application-oriented Network Measurements Influence of Software-based NIDS on FEC-Protected Uncompressed Video Transmissions Introduction 17 NIDS-related packet re-ordering 17 Influence of jitter on video transmissions 17 NIDS impact on the quality of FEC-protected video 20 Conclusion and future work 23 References 23 Exemplarisches Langzeitreporting von Netzverfügbarkeiten Einleitung 24 Netzwerk 25 Netzverfügbarkeit 25 Messverfahren und Reporting 26 Langzeitverlauf 27 Verfügbarkeit von Netzgeräten (Router, Switche) 27 Verfügbarkeit logischer Netzschnittstellen 29 Ausblick 29 Literaturverzeichnis 30 Introduction 31 FEDERICA as a service 31 Federated facilities worldwide 32 Unique features of FEDERICA 33 Users and use cases 33 User segmentation 34 Major experiments 34 Contribution to future internet research 34 Validation of virtual infrastructure features 34 Evaluation of multi-layer network architectures 35 Design of novel data and control plane protocols 37 Conclusion 38 Acknowledgment 38 References 38 Biographies 39 Investigation of One-Way Delay Variation in Substrate and Slice Measurements over a European wide Future Internet Platform Introduction 41 Measurements over virtual environments 41 Experiment and measurement tool 42 Substrate and slice measurements 43 Discussion of results 44 Conclusion 45 Acknowledgment 46 References 46 Veröffentlichungen seit 2000

5 Zur QoS- und SLA-Überwachung sowie zur Vereinfachung der domänenübergreifenden Fehlersuche der Dienste im europäischen Netzverbund GN2 wurde eine föderierte Multi- Domain Monitoring Architektur namens perfsonar entwickelt. perfsonar definiert geeignete Metriken und Messverfahren zum Performance Monitoring. Es realisiert eine Architektur, um verschiedenste unabhängig entwickelte Sensoren und Messverfahren in eine übergreifende und umfassende Architektur zu integrieren, einheitliche Messungen durchzuführen, zu analysieren und zu visualisieren. Von der Qualitätssicherung profitieren dabei sowohl große internationale Projekte sowie individuelle Nutzer der europäischen Wissenschaftsnetze. Einführung Der über GÉANT2 (GN2) realisierte europäische Verbund von 30 nationalen Forschungsnetzen (NRENs) stellt Netzdienste im paneuropäischen Maßstab zur Verfügung. Ein Beispiel für einen solchen Dienst sind Optical Private Networks (OPNs), die z. B. im Umfeld des LHC-Grid verwendet werden, um das CERN mit den Tier1- und Tier2-Zentren zu verbinden. Die Dienste werden in einer multinationalen Kooperation unabhängiger NRENs und DANTE erbracht. Für die Überwachung der Dienstqualität ist ein Grenz-, Domänen- und Provider-übergreifendes Performance Monitoringsystem unabdingbar. Eine solche Multi-Domain Monitoring and Troubleshooting perfsonar: Performance Monitoring in europäischen Forschungsnetzen Andreas Hanemann 3, Stephan Kraft 2, Patricia Marcu 1, Jochen Reinwand 2, Helmut Reiser 4, David Schmitz 1, Verena Venus 2 1 DFN-Verein, c/o Leibniz-Rechenzentrum 2 Friedrich-Alexander Universität Erlangen-Nürnberg 3 DFN-Verein 4 DFN-Verein - Leibniz-Rechenzentrum, Munich Network Management Team föderierte Multi-Domain Monitoring Architektur wurde im Rahmen des GN2-Projekts JRA1 mit perfsonar konzipiert und realisiert. Diese wird mittlerweile im europäischen Maßstab produktiv eingesetzt. Im folgenden Abschnitt werden die wichtigsten von perfsonar unterstützten Metriken und Messverfahren vorgestellt. Das in internationaler Kooperation entwickelte perfsonar Framework wird in Abschnitt 3 beschrieben. Die an verschiedene Nutzergruppen angepassten Visualisierungstools, mit denen eine Analyse und Darstellung der Messergebnisse ermöglicht wird, fasst Abschnitt 4 zusammen. Der Artikel schließt mit einer Zusammenfassung und einem Ausblick, der insbesondere auf den Regelbetrieb von perfsonar abzielt. Performance Monitoring perfsonar bedient sich einer Reihe von Messeinrichtungen, die Netzwerkkenngrößen ermitteln. Einen Teil der möglichen Metriken insbesondere die, die sowohl im X-WiN als auch im GÉANT2-Projekt gemessen werden sind Inhalt des folgenden Abschnitts. Die Internet Engineering Task Force (IETF) hat mehrere dieser Dienstgüte-Parameter als IP Performance Metrics (IPPM) standardisiert. Metriken Bei IPPM handelt es sich um ein umfassendes Rahmenwerk, das Definitionen von hmetriken zur Messung der Internet-Performance beinhaltet [RFC 2330]. Prinzipiell verfolgt IPPM das Ziel, Messverfahren der Dienstgüte und deren Auswertung zu standardisieren und dadurch die Aussagekraft der erzielten Ergebnisse zu erhöhen. Die verschiedenen Metriken werfen dabei ihr Hauptaugenmerk auf die unterschiedlichen Transportprotokolle des Internets. Die wichtigsten der in perf- SONAR verwendeten und von der IPPM-Arbeitsgruppe definierten Metriken werden im folgenden kurz zusammengefasst. Eine ausführliche Beschreibung der IPPM- Metriken sowie deren Ermittlung findet sich in [Holl2007]. Unter dem One-Way Packet Delay (OWD) [RFC 2679] versteht man diejenige Zeitverzögerung, die einem Paket auf dem Weg von einem Quell- zum Zielrechner widerfährt. Dabei gilt als (optimaler) Startzeitpunkt der Messung der Zeitpunkt, zu dem der Quellrechner das erste Bit des Pakets überträgt und als Endzeitpunkt derjenige, zu dem der Zielrechner das letzte Bit des Pakets empfängt. Der OWD im Bezug auf ein einzelnes Paket ergibt sich schließlich als Differenz von Start- und Endzeitpunkt. One-Way Packet Loss (OWPL) [RFC 2680] gibt an, ob ein bestimmtes von einem Quell- an einen Zielrechner gesendetes Paket dort tatsächlich angekommen oder auf dem Weg zu diesem verloren gegangen ist. Wendet man diese Metrik auf eine Menge nacheinander versendeter Pakete an, lässt sich schließlich der Anteil der auf dem Weg von der Quelle zum Ziel verloren gegangenen Pakete bestimmen. IP Packet Delay Variation (IPDV oder OWDV, One Way Delay Variation) [RFC 3393] bezieht sich jeweils auf zwei Pakete aus einer Menge von sequentiell versendeten Paketen. IPDV ist dabei definiert als die Differenz der Verzögerungen (OWD), die den beiden Paketen auf dem Weg vom Quell- zum Zielrechner widerfahren. Utilization (Auslastung) bezeichnet das tatsächlich auf einem Pfad aufgelaufene Datenvolumen. Hierbei wird die übertragene Datenmenge pro Zeit zwischen zwei Endpunkten ermittelt und über einen Zeitraum dargestellt. Neben diesen Metriken werden in perfsonar auch andere ermittelt (passive Performance Daten, Interface Errors, Interface Drops), die in diesem Beitrag nur erwähnt werden sollen, im einem Projekt-Bericht aber genau beschreiben sind [hlms06]. Messmethoden In Abhängigkeit von der Metrik erfolgt deren Erfassung über drei unterschiedliche Systeme: Hades, BWCTL und SNMP-Polling. Die Metriken OWD, OWPL und IPDV werden mit dem im DFN-Labor entwickelten Hades-Messsystem (Hades Active Delay Evaluation System [DFN-2]) ermittelt. Zur Ermittlung der verfügbaren Bandbreite (Available Bandwidth, AB) wird BWCTL [BWCTL] (Bandwidth Controller) benutzt, ein Wrapper für iperf [iperf], entwickelt von Internet2. Das SNMP-Polling wird zurzeit vom CNM [CNM] (Customer Network Management), das am LRZ München entwickelt wurde, um Auslastungsdaten in X-WIN zu erfassen und zu visualisieren, eingesetzt (s. Abschnitt 4). Die Hades-Messungen werden durch Messstationen ausgeführt, die aktiv Testpakete generieren und diese in das Netzwerk einspeisen und empfangen. Die Messstationen bestehen in der Regel aus einem PC mit Linux-Betriebssystem. Zwischen allen Standorten können Messungen durchgeführt werden. Für die notwendige Uhrensynchronisation sind die Messrechner mit einer GPS-Karte ausgerüstet. Dadurch ist eine Genauigkeit von < 10 Mikrosekunden möglich [DFN-2]. Aus der Ermittlung der One-Way Delays werden die abgeleiteten Größen OWPL und IPDV bestimmt. Die gleichen Messboxen, die zur Ermittlung der Delay-Daten herangezogen werden, dienen über ein zweites Netzwerkinterface zur Messung der verfügbaren Bandbreite. Hierbei wird zwischen zwei Endpunkten mittels BWCTL ein Verkehrsstrom generiert, der auf dem zu messenden Pfad ein möglichst großes Datenvolumen pro Zeit versendet. Im Normalfall werden hier TCP- Ströme benutzt, um den eigentlichen Nutzdatenverkehr nicht unnötig zu behindern. Regelmäßige Messungen werden derzeit im GÉANT2-Netz durchgeführt. perfsonar-schichtenmodell und Web Services Für das Monitoring der im vorherigen Abschnitt vorgestellten Metriken ist es neben dem Messen der Daten notwendig, deren Management in geeigneter Weise zu organisieren sowie die Daten mit Hilfe von Visualisierungs- und Analysewerkzeugen zugänglich zu machen. Hieraus wurde im perfsonar-projekt [bbdh05] ein Modell mit drei Schichten entwickelt, das in Abbildung 1 dargestellt ist und in den nächsten Abschnitten erläutert und auf die Details der Service Layer eingegangen wird, d.h. die momentan zur Verfügung gestellten Web Services werden genauer betrachtet. 6 7

6 Die drei Schichten der Messarchitektur Die Measurement Point Layer ist die unterste Schicht der Architektur. Mit dieser werden Messungen der im vorherigen Abschnitt vorgestellten Metriken durchgeführt, die entweder direkt über ein perfsonar-interface zugreifbar sind (sog. Measurement Points, MPs) oder nicht direkt zugreifbare Datensammlungen für Messarchive (Measuremant Archive, MA) realisieren, die über Dienste der Service Layer (s.u.) nutzbar sind. Hierbei werden vom Rahmenwerk keine festen Vorgaben gemacht, welche Abbildung 1: Das Drei-Schichten-Modell von perfsonar Arten von Messpunkten installiert sein müssen, sondern die Auswahl bleibt den einzelnen Domains überlassen. Die Service Layer dient dem Management der Messungen innerhalb und zwischen Netzwerkdomänen. Der Name der Schicht bezieht sich auf deren Implementierung als Web Services, wodurch eine logische Aufteilung von unterschiedlichen Funktionen erreicht wird. Die Aufgabe eines Dienstes kann beispielsweise die Authentifizierung und Autorisierung von Nutzern, die Verwaltung von anderen Diensten in einem Dienstverzeichnis, der Schutz von Ressourcen zur Überlastvermeidung oder die Archivierung von Messdaten sein, wie im nächsten Abschnitt genauer dargestellt. Die Kommunikation der Dienste erfolgt über SOAP und verwendet dabei ein gemeinsames Protokoll der NMWG (Network Measurement Working Group) des OGF (Open Grid Forum), in dessen Standardisierung die Anforderungen von perfsonar berücksichtigt werden. Auf der obersten Schicht befinden sich Visualisierungswerkzeuge [hjkm06], die die gemessenen Kennzahlen in graphischer Form darstellen und deren Analyse ermöglichen. perfsonar Web Services Die wichtigsten Dienste der perfsonar-service Layer werden im folgenden kurz beschrieben. Der Telnet/SSH MP ist ein Werkzeug, um mittels der Protokolle Telnet oder SSH auf Router zuzugreifen. Der Messpunkt ermöglicht derzeit den Zugriff auf Cisco und Juniper Router und übersetzt herstellerunabhängige Befehle in deren proprietäre Kommandos. Der MP ermöglicht damit (zusammen mit dem dazu entwickelten Visualisierungstool) eine vereinfachte Fehlersuche über Domaingrenzen hinweg. Auf den Hades-Messboxen werden aktive Messungen von OWD, IPDV und OWPL durchgeführt. Diese Messungen sind nicht direkt zugreifbar, sondern werden zentral beim DFN-Labor gesammelt und in einer Datenbank verwaltet. Diese Datenbank ist mit einer perfsonar-schnittstelle ausgestattet und wird als HADES MA bezeichnet. Derzeit sind insgesamt etwa 100 Messstationen in sieben Domains im Einsatz, die kontinuierlich Hades Messungen durchführen. Der BWCTL MP (Bandwidth Controller Measurement Point) ist ein Dienst zum Testen der verfügbaren Bandbreite. Dabei wird zwischen zwei MPs soviel Verkehr erzeugt, wie man erfolgreich übertragen kann. BWCTL Messungen sind ebenfalls auf allen Messboxen möglich, es wird jedoch nicht vollvermascht gemessen. Der am weitesten verbreitete Service (Installationen in 15 Domains) ist das Round Robin Database Measurement Archive (RRD MA), das eine perfsonar- Schnittstelle für den Zugriff auf Daten in RRD-Dateien dargestellt. Hierbei geht es vor allem um Auslastungsdaten, aber auch um Paketverwerfungen an Routerinterfaces. Alternativ zum RRD MA gibt es das SQL MA, das einen Zugriff auf SQL-Datenbasen, wie z. B. MySQL oder PostgreSQL ermöglicht. Der Lookup Service ist ein Verzeichnisdienst für perfsonar-services, bei dem sich Services registrieren und darüber gefunden werden. Er wird in den nächsten Monaten dahingehend erweitert, dass die Lookup Services eine Föderation bilden und damit Anfragen an andere Lookup Services weiterleiten können. Der Authentication and Authorization Service dient dazu, dass einzelne Domains festlegen, wie Installationen von Diensten in der Domain verwendet werden können. Der Dienst erlaubt dabei die Festlegung einer Zuordnung zwischen Attributen eines Nutzers und dessen Rechten, z. B. kann man einem Mitarbeiter eines NOCs den Zugriff auf eine Telnet/SSH MP-Installation gewähren und dieses für andere Nutzer untersagen. cnis (common Network Information Service) ist eine Topologiedatenbasis, die statische Topologieinformationen über eine Domain zur Verfügung stellt. Dieses wird insbesondere für die Visualisierungs- und Analysetools gebraucht. Visualisierung und Benutzerschnittstellen Die perfsonar-web Services erlauben den Zugriff auf die Messungen über eine XML-Schnittstelle, auf die in JRA1 entwickelte Visualisierungstools zugreifen. Die Tools sind zielgruppenspezifisch entwickelt worden. Als Zielgruppen werden dabei Mitarbeiter von Network Operation Centers (NOC), Projektgruppen, einzelne Wissenschaftler und administrative Mitarbeiter unterschieden (näheres hierzu in [hjkm06]). Der Schwerpunkt der Aktivitäten liegt im Moment auf den NOC-Mitarbeitern, denen genaue Daten zur Fehleranalyse bereitgestellt werden sollen, sowie bei der Unterstützung von Projekten, insbesondere des LHC-Projekts. Das Tool perfsonarui bietet einen direkten Zugriff auf perfsonar-dienste und stellt diese gruppiert nach Metriken dar. Das Tool setzt Grundkenntnisse über perfsonar voraus und ist für die Fehleruntersuchung konzipiert. Abbildung 2 zeigt die Darstellung von Auslastungsdaten, bei der man entweder die gesamten Daten in einem Archiv anzeigen kann (im Beispiel vom GÉANT2 MA) oder eine Route nachverfolgen kann. Diese wird mit einem Traceroute beschrieben und die Daten aus den entsprechenden MAs werden so zusammengetragen, dass man Stellen mit hoher Auslastung entlang des Pfades, die möglicherweise zu Beeinträchtigungen führen, identifizieren kann. In perfsonarui stehen außerdem weitere Oberflächen zur Darstellung von HADES-Daten und für BWCTL- Messungen zur Verfügung. Das VisualperfSONAR-Tool läuft innerhalb einer Weboberfläche und ist auf die Analyse von Pfaden spezialisiert. Bei diesen werden die Daten von verschiedenen Metriken zusammengetragen und sollen in der Zukunft in einen automatischen Report zusammengestellt werden. Der Pfad wird zur Veranschaulichung in Google Maps mit den Koordinaten der Interfaces dargestellt. Das CNM-Tool stellt die Topologie von Netzen mittels hierarchischer Karten dar. Die Karten beinhalten Abbildung 2: Darstellung von Auslastungsdaten im perfsonarui sowohl Netzknoten (Router) und Verbindungen (Links) zwischen unterschiedlichen Knoten als auch Statusinformationen und Kennzahlen. Eine Baum- und eine graphische Darstellung stehen dabei zur Verfügung. In der Baumdarstellung kann man einzelne Unterbäume ausklappen und Sichten auswählen, die dann in der graphischen Darstellung auf der rechten Seite angezeigt werden. In Abbildung 3 wird die Topologie des bulgarischen Forschungsnetzes dargestellt und die auf den Links angezeigte Kennzahl ist der Durchsatz. Es ist zusätzlich möglich zwischen den unterschiedlichen Kennzahlen (Jitter, Delay, Paketverlust usw.) beliebig zu wechseln (links oben im Fenster). Diese Karten zeigen den aktuellen oder historischen Status eines Netzes an. Für einzelne Knoten oder Links stehen Tages-, Wochen-, Monats- und Jahresstatistiken zur Auswahl, um den Verlauf der Messungen zu betrachten. Das CNM-Tool kann kundenspezifisch angepasst werden, indem man für verschiedene Kunden verschiedene Karten bzw. Kennzahlen freigibt. Das wird durch einen Authentisierungsmechanismus realisiert und ist in Projekten dieser Größenordnung notwendig. Abbildung 3: Netztopologie des bulgarischen Forschungsnetzes 8 9

7 Parallel zu perfsonarui wurden zur Darstellung der gemessenen Metriken OWD, OWPL und IPDV am DFN- Labor geeignete Visualisierungen entwickelt [HADES]. Als primäre Übersicht werden die Messdaten in Form einer Karte dargestellt. Entsprechend der Zugehörigkeit zu einer Messdomain erhält man so ein Bild der Delaymessungen entlang der Netzwerktopologie. Zusätzlich können von allen Standorten aus die vorhandenen Messungen (derzeit ca ) zur zeitlichen Darstellung selektiert werden. Auch BWCTL Messungen können in die Datendarstellung integriert werden. Ein Beispiel für die Darstellung der Messdaten findet sich in Abbildung 4. Zusammenfassung und Ausblick Im europäischen Verbundprojekt GÉANT2 entsteht unter Mitwirkung der angeschlossenen nationalen Forschungsnetze unter der Leitung von DANTE ein Rahmenwerk zur Leistungsüberwachung in nationalen und internationalen Weitverkehrsnetzwerken. Der Ansatz perfsonar stellt einen einzigartigen Weg dar, über Domänengrenzen hinweg Methoden zur Ermittlung von Performance-Metriken integrativ zur Verfügung zu stellen und Messergebnisse Abbildung 4: Delay und Bandbreitenmessungen zusammenfassend über benutzerorientierte Oberflächen zu visualisieren (Multi Domain Monitoring). In einem Drei-Schichten Modell werden, ausgehend von unabhängigen Messwerkzeugen, über eine Service- Oriented-Architecture (SOA) Schnittstellen definiert, die maßgeschneidert für die Erfordernisse der Benutzer die gewünschten Informationen liefern. perfsonar soll es jedem Netzbetreiber ermöglichen, auf einfache und transparente Weise eine Monitoring-Infrastruktur aufbauen zu können, die entsprechend seiner Vorgaben die passenden Werkzeuge zur Verfügung stellt.neben dem eigentlichen Monitoring ist angestrebt, die erzeugten Daten zu analysieren und bedarfsgerechte Alarmsysteme zu kreieren, um die perfsonar-infrastruktur effizient nutzen zu können. Im Laufe des Jahres 2008 ist die Installation der Services in einer Reihe von europäischen Netzen (auch im X-WiN) geplant, um dann im Regelbetrieb die Überwachung der Netzqualität in der beschriebenen Weise zu ermöglichen. Literaturverzeichnis [Holl2007] T. Holleczeck: Redesign und Implementierung eines Softwarepakets zur Messung der IP Performance nach OWAMP-Standard (Studienarbeit), Erlangen [DANTE] [RFC 2330] Paxson, V., G. Almes, J. Mahdavi, M. Mathis: RFC 2330: Framework for IP Performance Metrics. RFC, IETF, Mai 1998, [RFC 2679] Almes, G., S. Kalindindi, M. Zekauskas: RFC 2679: A One-way Delay Metric for IPPM. IETF, September 1999, [RFC 2680] Almes, G., S. Kalindindi, M. Zekauskas: RFC 2679: A One-way Packet Loss Metric for IPPM. IETF, September 1999, [RFC 3393] Demichelis, C., P. Chimento: RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM). IETF, November 2002, [RFC 3148] Mathis, M., M. Allman: RFC 3148: A Framework for Defining Empirical Bulk Transfer Capacity Metrics. IETF, Juli 2001, [iperf] Iperf. [BWCTL] Bandwidth Test Controler (BWCTL). [CNM] Customer Network Management (CNM). [DFN-2] [hjkm06] [bbdh05] [hlms06] IPPM Performancemessungen in Hochgeschwindigkeitsnetzen. messprogramm.html Hanemann, A., Jeliazkov, V., Kvittem, O., Marta, L., Metzger, J., Velimirovic, I., Complementary Visualization of perfsonar Network Performance Measurements, In Proceedings of the International Conference on Internet Surveillance and Protection (ICISP), 2006, IARIA/IEEE, Cap Esterel, France, August, Boote, J. W., Boyd, E. L., Durand, J., Hanemann, A., Kudarimoti, L., Lapacz, R., Swany, D. M., Zurawski, J., Trocha, S., PerfSONAR: A Service Oriented Architecture for Multi Domain Network Monitoring, In Proceedings of the Third International Conference on Service Oriented Computing, , LNCS 3826, Springer Verlag, ACM Sigsoft, Sigweb, Amsterdam, The Netherlands, Dezember, Hanemann, A., Liakopoulos, A., Molina, M., Schmitz, D., Solberg, A., Swany, D. M., Velimirovic, I., van Maele, A., van den Berghe, S., Deliverable DJ1.2.3: Network Metric Report, GÉANT2/JRA1 project report, Februar, perfsonar-lite TSS: Schnelldiagnose von Netzverbindungen im EGEE-III-Projekt Susanne Naegele-Jackson, Martin Gründl 1, Andreas Hanemann 2 1 Friedrich-Alexander Universität Erlangen-Nürnberg Martensstrasse 1, Erlangen (susanne.naegele-jackson, martin.gruendl)@fau.de 2 DFN-Verein Alexanderplatz 1, Berlin hanemann@dfn.de Das EGEE-III-Projekt (Enabling Grids for E-sciencE) vernetzt mehr als 280 Einrichtungen in Europa und ist damit eines der führenden Grid-Projekte. Es ist daher notwendig, eine Lösung zur Fehlersuche auf der Netzebene zu haben, falls die Eigenschaften von Verbindungen über das Netz nicht wie erwartet sind. Im Vorgängerprojekt EGEE-II wurde hierzu eine eigene Monitoring-Lösung entwickelt, die jedoch von den Einrichtungen in großer Mehrheit als zu aufwendig im Betrieb betrachtet wurde. Deshalb wurde diese Lösung verworfen und in EGEE-III ein Troubleshooting-Ansatz gewählt, bei dem nur bei aktuellen Problemen eine leicht zu handhabende Untersuchungssoftware eingesetzt wird. Diese am RRZ-Erlangen entwickelte Software basiert auf Teilen des im GN2/GN3-Projekt entwickelten Monitoringsystems perfsonar. Einleitung Das EGEE-III-Projekt [EGEE] ging aus den Projekten EGEE-I und EGEE-II hervor und baut auf den Erfahrungen dieser Projekte auf. Die Überwachung und Fehlersuche im Gesamtnetz stellte sich im Laufe der ersten beiden Projekte immer mehr als komplexe Aufgabe dar. Zu Beginn von EGEE-III wurde zunächst innerhalb der EGEE-SA1 Activity eine Lösung zur Netzüberwachung angestrebt. Es zeigte sich dann allerdings, dass ein solches komplettes Monitoring über das ganze Netz, welches mehr als 40 Netzbetreiber umfasst, viel zu komplex für einen dauerhaften Einsatz und eher ungeeignet für die Schnelldiagnose von Problemen war. Außerdem standen viele NRENs (National Research 10 11

8 and Education Networks) und Grid Partner einer allum- daher nahe, eine Lösung für Troubleshooting in EGEE als Aufgaben in spezifische Web Services. Beispielsweise und dass das Troubleshooting anwendungsübergreifend fassenden Netzüberwachung mit fremdkontrolliertem Erweiterung einer schon existierenden Software zu ent- gibt es Dienste zur Archivierung von Messungen, zur zum Einsatz kommen kann. Die Test Tools zusammen Verkehr eher abneigend gegenüber, da sie das Netz in wickeln. Das für Multi-Domain Umgebungen entwickelte Suche nach Messungen oder anderen Diensten und für mit der perfsonar-schnittstelle sind für die einfache erster Linie für Projektaufgaben verwenden und nicht perfsonar eignet sich für diesen Zweck, da es durch die Autorisierung bei der Durchführung von Messungen. Installation und Verwendung im Problemfall bei einer durch Verkehr für aktive Messungen belasten wollen. seine modulare Architektur und Flexibilität hinsichtlich Im User Interface Layer werden schließlich mehrere oder mehrerer EGEE-Sites geeignet. Die Webbasierte Um trotzdem effizient und schnell nach Problemen im Netz suchen zu können, war die Alternative zum Netzmonitoring die Entwicklung von Troubleshooting Tools, mit deren Hilfe man Verbindungsprobleme gezielt aufspüren und dadurch schneller lösen kann. Verbindungstests sollten möglich sein, die nicht von einem zentralen Router aus durchgeführt werden, sondern direkt über die betroffenen Routen die Schwachstelle untersuchen können. Dabei sollten die Untersuchungen der Messmethoden leicht angepasst werden kann. Dieses wurde auch bereits mit dem Tool Command-Line MP [SKCM07] vom brasilianischen Forschungsnetz RNP gezeigt. Dieses ist jedoch nur zur Messung von Durchsatz (Tool BWCTL, [BWCTL]), Verzögerung (Tool OWAMP, [OWAMP]), Ping und Traceroute geeignet und kann nicht so einfach an die im EGEE-Projekt zu beachtenden Rahmenbedingungen hinsichtlich der Beschränkungen der Nutzerrechte angepasst werden. Visualisierungswerkzeuge angeboten, die den Zugriff auf die Messdaten erlauben. perfsonar basiert auf der Web Services Technologie, so dass der Austausch zwischen den einzelnen Services über die Extensible Markup Language (XML) klar definiert ist. Ein besonderer Schwerpunkt von perf- SONAR sind IP-Metriken: Verfügbarkeitsdaten, die die Robustheit eines Netzes beschreiben sowie Verlustraten und Fehlerraten, die auf mögliche Staus im Netz oder Software steht auf einem vom zentralen EGEE Network Operation Center (ENOC) betriebenen Webserver für alle registrierten Benutzer bereit. Das typische Szenario (siehe Abbildung 2) sieht so aus, dass bei einem Netzproblem zwischen Netzknotenpunkten A und B ein Netzwerkadministrator mit den erforderlichen Zugangsrechten von einem entfernten Netzknotenpunkt (d.h. dem ENOC) aus die Tools von Punkt A oder B für eine Ferndiagnose starten und einer Netzstörung nicht dadurch behindert werden, dass perfsonar (Performance focused Service Ori- auf Gerätefehler hinweisen und auch Latenzdaten, die so die Strecke zwischen A und B untersuchen kann. die Tests zur Problemdiagnose nicht sofort durchgeführt ented Network Monitoring Architecture) [perfsonar, überlastete Verbindungen oder eventuelle Umleitungen Selbst beim DNS Lookup Service kann dies von Vorteil werden können. Ein Netzadministrator soll keine wert- BBDH05, HKMR08] ist eine dienstorientierte Architektur über andere Routen aufzeigen. sein, insbesondere dann, wenn eine Abfrage zu einem volle Zeit dadurch verlieren, dass er nach Accounts und Hosts auf beiden Seiten der gestörten Strecke suchen muss, sondern soll durch eine einfache Konfiguration von Diagnosetests unterstützt werden. Aus diesem Hintergrund heraus ergaben sich folgende Anforderungen an ein neues Netzdiagnosesystem: Es sollte unbedingt eine light-weight Lösung sein, die nicht unnötig durch permanenten Testverkehr rund um die Uhr Bandbreite in Anspruch nimmt. Mit für multi-domain Netzüberwachungen und Störungsdiagnose, die im GN2 bzw. GN3-Projekt [GN2/GN3] sowie von internationalen Partnern, wie z. B. Internet2, entwickelt wurde bzw. wird. Netzadministratoren können mit Hilfe dieses Tools Engpässe im Netz auch außerhalb ihrer Domains frühzeitig erkennen und Ende-zu-Ende- Probleme leichter und schneller lösen. perfsonar ist aber als Netzüberwachungssystem konzipiert und nicht speziell für Troubleshooting geeignet. perfsonar wird zurzeit im LHC OPN (privates optisches Netz für das Large Hadron Collider Projekt am CERN [LHC OPN]) und im GÉANT Netz eingesetzt, außerdem wird es auch bei vielen NRENs verwendet. Die Entwicklung der Troubleshooting Tools auf dieser weitverbreiteten Software aufzusetzen, ist daher nicht nur sinnvoll, sondern ermöglicht auch eine schnelle Akzeptanz auf der Nutzerseite. internen Host über einen lokalen DNS Server detailliertere Informationen liefern kann, als über eine globale DNS-Abfrage von außen zur Verfügung gestellt wird. Die eigentliche Ausführung der perfsonar-lite anderen Worten, es sollte eine Troubleshooting Lösung entwickelt werden, die gezielt bei einem Problem on- In perfsonar werden drei Schichten unterschieden (s. Abbildung 1): Der Measurement Point Layer, der perfsonar-lite Troubleshooting Tools demand eingesetzt werden kann. Außerdem sollte die Lösung möglichst leicht weiträumig verteilt werden können und plattformunabhängig der großen Anzahl von Nutzern in der EGEE Grid Community zur Verfügung gestellt werden können. Eine weitere Anforderung war, dass es sich bei den Modulen um nachhaltige Entwicklungen handeln sollte, und sofern möglich, auf bereits vorhandener und im Einsatz verbreiteter Software aufsetzen sollte. Dieses Kriterium führte dazu, dass das weitverbreitete perfsonar (siehe unten) und dessen Kommunikationsschnittstelle in die neue Troubleshooting Software integriert wurde und damit perfsonar-lite TSS (Troubleshooting Service) entstand. perfsonar und verwandte Arbeiten Für das Netzmonitoring existieren bereits viele einzelne Tools wie z. B. MRTG [MRTG] oder iperf [IPERF] sowie komplette Lösungen. Für das Monitoring von Clustern oder Grids kann beispielsweise Ganglia [Ganglia] eingesetzt werden, während MonALISA [MonALISA] zum Netzmonitoring mit Agenten geeignet ist. Es liegt Service Layer und der User Interface Layer. Im Measurement Point Layer werden aktive oder passive Messungen mit Hilfe von verschiedenen Netzüberwachungswerkzeugen über sogenannte Measurement Points (MPs) durchgeführt. Ein MP ist dabei jeweils für eine Art von Netzkennzahlen konzipiert, z. B. für Auslastung, Paketlaufzeiten oder Paketverluste. Der Service Layer dient zum Management der Messungen und gliedert diese Abbildung 1: Das Drei-Schichten-Modell von perfsonar Das DFN-Labor in Erlangen entwickelt für perf- SONAR im Rahmen des GN2/GN3-Projekts einen speziellen Mess-PC für die aktive Messung von Paketlaufzeiten, deren Schwankungen, Paketverlusten sowie den Netzpfaden. Diese Messstationen werden an interessanten Stellen im Netz, z. B. den GÉANT PoPs, aufgestellt. Deren Messdaten werden archiviert und über eine perfsonar-schnittstelle bereitgestellt. Des Weiteren wird für das von Internet2 stammende Tool BWCTL (Bandwidth Test Controller, [BWCTL]) eine perfsonar-schnittstelle zur Verfügung gestellt. Die durch dieses Projekt vorhandene perfsonar- Kommunikationsschnittstelle ist der Ausgangspunkt für die Implementierung im EGEE-III-Projekt. Sie ist für die Verwendung von mehreren Test Tools so erweitert worden, dass die Ergebnisse der Tests über die perf- SONAR-Schnittstelle bereit stehen. Für die Tools, die integriert werden sollen, gab es von EGEE die Vorgabe, dass mindestens Ping, Traceroute, BWCTL, Port Scan (Tool NMAP, [NMAP]) sowie DNS Lookup unterstützt werden sollen. Die Metriken wurden so ausgewählt, damit sie für möglichst viele Anwendungen relevant sind Abbildung 2: Einsatz der Troubleshooting Service Tools für Ferndiagnosen TSS (Troubleshooting Service) Tools erfolgt über die plattform-unabhängige perfsonar-basierte Plugin Architektur, die in Abbildung 3 dargestellt ist: Grundelement dieser Architektur ist ein generisches Plugin, über das die Service-Anfragen aktiviert werden. Dabei handelt es sich um ein XML-Template, das mit den Abfrageparametern des Benutzers ergänzt wird. Die vollständige XML-Nachricht wird dann in einen SOAP (Simple Object Access Protocol) Envelope verpackt und kann so als strukturierte Information an das perfsonar Interface übergeben werden. Nach Ausführung der 12 13

9 Anfrage mit eventueller Durchführung einer Messung liefert das perfsonar-kernmodul die Ergebnisse zurück so das sie dem Benutzer über die perfsonar-lite TSS Schnittstelle zur Verfügung gestellt werden können. Alle Messanfragen werden über die Benutzer- über die Management-Plattform auf dem Webserver durchführen; über diese Plattform kann ein Manager auch Messstationen registrieren und verwalten. Die Zugangsgranularität für Benutzer auf Ebene 3 erlaubt eine Zugangsbeschränkung einzelner Benutzer auf individuelle Messstationen. Die Parameter Window Size und Round Trip Time (RTT) wurden im konkreten Fall von BWCTL selbst bestimmt, wobei auch externe Vorgaben möglich sind. Eine graphische Darstellung der Ergebnisse wird derzeit entwickelt. Zusammenfassung und Ausblick Nachdem perfsonar-lite TSS seit Mai 2008 entwickelt wurde, konnte bei der EGEE-Konferenz in Barcelona im September 2009 eine Version der Software sowohl mit einem Vortrag als auch mit einer Demonstration vorgestellt werden. Die Software steht nun auch zum ausführlichen Testen für alle Teilnehmer am EGEE-Projekt bereit. Zusätzliche Erweiterungen der Software sind geplant und werden insbesondere Archivierungsmöglichkeiten und erweiterte Darstellungen der Resultate betreffen. Außerdem wird zur Zeit noch an zusätzlichen Firewall-Regelungen für BWCTL-Tests gearbeitet; es soll dabei auch untersucht werden, wie es sich vermeiden lässt, dass Messungen fälschlicherweise von Intrusion Abbildung 3: perfsonar-lite TSS Messungen in einer EGEE Site Detection Systems (IDS) als DoS-Attacken interpretiert werden können. schnittstelle auf dem ENOC Webserver gestartet. Aber der Webserver liefert nicht nur das Interface, wo ein Nutzer Service-Anfragen stellen kann, sondern ist auch verantwortlich für Authentifizierung und Autorisierung der Anwender. Der Zugang zu den Messungen ist in einem Drei- Schichten-Modell geregelt, welches in Abbildung 4 gezeigt wird: Auf der höchsten Ebene stehen die Super User vom ENOC, die grundsätzlich jede Messung von jedem Start- und Zielpunkt aus aufrufen können. Die zweite Ebene bilden sogenannte Managers, die über die GOC-DB (Grid Operations Center Database) definiert sind; typischerweise sind Manager Benutzer, die in der GOC-DB Rollen wie z. B. Regional Manager, Site Administrator oder Deputy Regional Manager belegen. Die Granularität eines Managerzugangs zum Messbereich beschränkt sich auf Standorte, wobei jeder Standort (site) beliebig viele Messstationen (probes) betreiben kann. Manager, die einem ROC (Regional Operations Center) angehören, haben üblicherweise Zugang zu allen Messstationen dieses ROCs. Die Zugehörigkeit eines Managers zu einem ROC oder zu einem Standort wird über die GOC-DB verifiziert. Die dritte Ebene der Zugangskontrolle betrifft normale Benutzer: Grundsätzlich kann sich jeder als Nutzer registrieren lassen, solange er über ein gültiges Gridzertifikat verfügt, das von einer gültigen Certificate Authority (CA) ausgestellt wurde und nicht wegen eines Missbrauchs entzogen wurde. Allerdings muss er sich zusätzlich von einem Manager als Nutzer registrieren lassen. Ein Manager kann Benutzerregistrierungen bequem Abbildung 4: 3-Schichtenmodell für Autorisierung und Authentifizierung Um eine Abfrage oder Messung von einer Messstation starten zu können, muss dort ein perfsonar-lite TSS Client installiert werden. Für die Kommunikation zwischen Client und Webserver wird eine SSL-Verbindung aufgebaut. Messungen sind grundsätzlich erlaubt, wenn der Benutzer Zugangsrechte auf eine Messstation hat, die entweder Start- oder Zielpunkt der Abfrage ist. Bei jeder Messung wird der Manager, der die betreffende Messstation über die Management Plattform registriert hat, über die Messanfrage mit einer informiert, die Aussagen liefert zu Start- und Zielpunkt der Messung und Art der durchgeführten Anfrage. Beim Service Tool Port-Scan wird der Manager auch über weitere Angaben wie z. B. betroffene Einzelports oder Portbereiche informiert. Abbildung 5 zeigt die Durchführung eines BWCTL- Tests zwischen zwei EGEE Sites durch das ENOC. Hierbei wird ein Test mit TCP 20 Sekunden lang durchgeführt und man erhält das übertragene Gesamtvolumen sowie die durchschnittliche Geschwindigkeit. Abbildung 5: Verwendung von BWCTL in der Serveranwendung von perfsonar-lite TSS Einsatz im EGEE-Projekt und darüber hinaus Wie im vorherigen Abschnitt darstellt, wurde die Software für das EGEE-III-Projekt entwickelt und wird nun in Kürze für das Troubleshooting entsprechend dem EGEE-Betriebskonzept eingesetzt. Die Software ist derzeit teilweise an den Bedingungen des EGEE-III-Projekts ausgerichtet, insbesondere was das Rechtemanagement angeht, wo eine Kopplung mit den entsprechenden Datenbanken erfolgte. In weiten Teilen, d. h. im Bezug auf die Troubleshooting Tools selbst sowie die Kommunikation mit perfsonar-interface, ist die Software jedoch auch für allgemeinere Szenarien geeignet. Beispielsweise könnte bei einem Projekt wie dem Large Hadron Collider am CERN ein permanentes Monitoring für das Kernnetz (hier die Kopplung von Tier0 und Tier1-Zentren) gewünscht werden. Für die Zusammenarbeit mit Tier2-Zentren oder spätestens für die Verbindungen mit Tier3-Zentren wären diese Lösungen aber recht aufwendig, so dass sich eine leicht zu installierende Troubleshooting-Lösung anbietet. Auch innerhalb des X-WiN sollte der Einsatz überlegt werden, so dass das DFN-NOC dieses Tool bei Bedarf zum Messen der Verbindung zu einer Einrichtung oder zwischen zwei Einrichtungen einsetzen könnte. Literaturverzeichnis [BBDH05] [BWCTL] [EGEE] [Ganglia] [GN2/GN3] [HKMR08] [IPERF] [LHC OPN] [MonALISA] [MRTG] [NMAP] [OWAMP] [perfsonar] Boote, J. W., Boyd, E. L., Durand, J., Hanemann,A., Kudarimoti, L., Lapacz, R., Swany, D. M., Zurawski, J., Trocha, S., PerfSONAR: A Service Oriented Architecture for Multi Domain Network Monitoring, In Proceedings of the Third International Conference on Service Oriented Computing, , LNCS 3826, Springer Verlag, ACM Sigsoft, Sigweb, Amsterdam, The Netherlands, Dezember, Hanemann, A., Kraft, S., Marcu, P., Reinwand, J., Reiser, H., Schmitz, D., Venus, V., perfsonar: Performance Monitoring in europäischen Forschungsnetzen, In Proceedings Erstes DFN Forum Kommunikationstechnologien Verteilte Systeme im Wissenschaftsbereich, GI Verlag/DFN, Kaiserslautern, Deutschland, Mai, Large Hadron Collider Optical Private Network, MONitoring Agents using a Large Integrated Services Architecture, Multi Router Traffic Grapher,

10 [SKCM07] Sampaio, L., Koga, I., Costa, R., Monteiro, H., Vetter, F., Fernandes, G., Vetter, M., Monteiro, J., Implementing and Deploying Network Monitoring Service Oriented Architectures: Brazilian National Education and Research Network Measurement Experiments, Proceedings of the 5th Latin American Network Operations and Management Symposium (LANOMS 2007), Brazil, September Applicationoriented Network Measurements Influence of Software-based NIDS on FEC-Protected Uncompressed Video Transmissions Susanne Naegele-Jackson, Jochen Kaiser, Peter Holleczek Regional Computing Center Erlangen (RRZE) Martensstrasse 1, Erlangen, Germany (susanne.naegele-jackson, jochen.kaiser, Abstract This study investigates the tradeoff between security and the usability or performance of multimedia services in the case of a softwarebased network intrusion detection system and uncompressed video transmissions. Uncompressed video transmissions are especially interesting in this context as they are not subjected to jitter and delays caused by compression mechanisms and can therefore be expected to be more robust when it comes to added delay variations and subsequent distortions stemming from security devices. The paper focuses on the special case where video is protected by Forward Error Correction mechanisms, which allow reordering of the original packet sequence after it may have been altered by network impairments. Various Forward Error Correction mechanisms are applied in the presence of a network intrusion detection system and its impact on the resulting video quality is investigated. Keywords-network intrusion detection systems; video Introduction Network Intrusion Detection Systems (NIDS) are network-based intrusion detection systems that are placed at strategically important locations within the network with the purpose of monitoring traffic and detecting malicious intruders. Unlike firewalls that limit traffic access from certain network openings with filter rules in an effort to block intrusions, intrusion detection systems focus on incoming traffic at network ports that must intentionally remain open to allow the use of applications with outside interaction and activities such as videoconferencing, for example. In order to be able to detect unwanted malicious invasions of the network system, an NIDS often uses processes that entail packet reordering. This paper investigates a software-based NIDS system in connection with uncompressed video transmissions and studies to what extend NIDS-related packet re-ordering can actually impact the resulting video quality especially in the case where FEC algorithms are in place to offer video protection. Chapter 2 first provides an introduction to NIDS-related packet reordering; Chapter 3 offers an in-depth look at jitter manifestation during video transmissions and how FEC mechanisms are employed to alleviate jitter impact. Chapter 4 presents the test setup of a laboratory-based video transmission with a network intrusion detection system in place and evaluates its influence on the uncompressed video. Chapter 5 summarizes the results and concludes the investigation. NIDS-related packet re-ordering Packet re-ordering is often used as part of NIDS in order to detect malicious invasions: Matrawy, von Oorschot and Somayaji [1], for instance, proposed a diversity-based traffic management system for the intrusion detection and control of polymorphic flash UDP worms and Denial of Service attacks, which used dynamic traffic characterization. During this process of learning and regulating classes or network traffic, packets were classified into a number of queues. The authors stated that this classification could sometimes have the effect that packets within one TCP or UDP flow could be split across multiple queues and would then likely be reordered and experience different levels of delay. A more prevalent cause for packet reordering in connection otherwise cause problems at the target system after reassembly [2, 3]. The defragmentation process also entails the reordering of the data packets according to their sequence numbers for correct assembly. Ordinarily this would not be a problem as all data packets will have to be lined up in their correct order eventually; however, in connection with Forward Error Correction (FEC) mechanisms this sequential order can be interrupted by duplicate redundant packets. Forward Error Correction is typically used with video transmissions where a request of retransmission of lost or late packets is not possible due to the strict time-constraints of video data. For this reason, redundant data is added to the payload as part of an FEC algorithm with the expectation that hopefully any lost or corrupted data will be able to be reconstructed during adverse network conditions and impairments. As part of the FEC mechanism, duplicate packets may be generated and arranged in a specific order to protect against packet loss and will be required for the process of regaining and repairing the video signal at the receiver not only in that pre-specified order but also within a certain time frame. As duplicate packets also carry identical sequence numbers, a reordering of data packets for premature defragmentation and security purposes not only adds to the overall delay of the multimedia transmission, but also disturbs the expected FEC sequence and ordering for optimal decoding and error correction at the video receiver. As a consequence, additional reordering may be required at the video receiver, which can lead to critical delay variation (jitter) of the data packets and may cause serious distortions and artifacts in video or audio sequences. Influence of jitter on video transmissions There are several different types of jitter that can affect the quality of a transmitted video signal: Network jitter occurs when the data packets are not transmitted with equal amounts of end-to-end delay, but arrive at their destination irregularly with varying time-intervals between arrivals. But video quality can also be affected by jitter wander, which is a very small scale jitter that occurs when jitter influences the clock extraction of the serial bit stream until the timing jitter leads to a time shift that is greater than half the clock period and thus results in bit errors. The following sections will explain both types of jitter errors in more detail. quality. with intrusion detection systems can be defragmentation: NIDS use IP defragmentation in order to be able to detect attacks that are based on malicious code that is fragmented across multiple data packets and that would 16 17

11 A. Network Jitter Errors affecting video streams and thus a viewer s perception of video quality can be due to data loss and buffer overflow during the transmission, but can also be the result of large delay variations that prevent a continuous playout at the receiver and force the decoder to discard late packet arrivals (this type of loss is also referred to as late loss). Jitter compensation can be achieved by temporarily buffering incoming packets until the data can be displayed in a steady stream at the expense of increased delay. Figure 2 describes the trade-off between late loss and delay and depicts the required decoder buffer size. The end-to-end delay of a packet or cell carrying video data is composed of a fixed amount of compression delay at the encoder (Denc); the data units then require a certain fixed amount of time to be transmitted (propagation delay Dprop). Across the network, queueing delays (Dqueue) are added to the overall end-to-end delay, whenever the packet must wait to be scheduled for processing. Queueing delays are variable delays, since they are highly dependent on scheduling times and competing traffic that contribute to queue lengths and waiting times. When an IP packet arrives at the receiver, an additional variable delay (Dord) may become necessary to allow time for reordering the packet, since contrary to ATM transmissions, IP packets belonging to one MPEG transport stream may be sent over different routes and loose their original succession in line. At the receiver, the decoding delay Ddec also adds a fixed amount of delay to the overall end-to-end delay. With a minimum amount of delay variation, a packet i will then finally be available for playout at its destination at time ai,min; with a maximum amount of jitter packet i will be available for playout at time ai,max. Since video sequences must be displayed according to strict timing constraints (for PAL video, a new frame must be available every 40 ms, for instance), there is a given delay limit DL when the data must be played out. If a packet is not available at its playout time, i.e., DL < ai (with ai denoting the time packet i becomes available), then it is considered a late loss and must be discarded, although it did survive the network transmission and no network loss occurred. A packet with availability ai,min <= ai <= DL will be stored in the decoder buffer until it can be displayed at its appropriate time. The buffer must therefore be large enough to hold all packets arriving between the possible arrival time Dmin (minimum jitter occurred) and the playout time DL when the frame associated with these packets must be displayed. One-way applications can afford to extend the deadline DL to allow more packets to arrive in time; the increased end-to-end delay, however, severely inhibits spontaneity and interactive communication. B. Jitter Wander Another source for distortions in video transmissions is jitter wander or video sync timing wander [4, 5]. When video is transmitted over a network and packets arrive irregularly because of large delay variations, the time extraction from the serial video stream can start to exhibit a certain drift or time shift; such jitter wander can even lead to bit errors, whenever the jitter drift is larger than half the clock period (Figure 1). The time extraction at the video decoder is accomplished with a single integrated circuit block called Phase Locked Loop (PLL). The PLL operates by comparing the phase of the incoming reference clock signal from the sender to the phase of the Voltage Controlled Oscillator (VCO), which is a circuit block within the PLL of the video decoder at the destination. If there is a phase difference between incoming signal and the clock pulse from the VCO, the phase of the VCO is locked to the incoming signal and the VCO starts generating a periodic clock output signal that is synchronized to the input reference. When jitter wander introduces a slow creep of the time baseline, however, the incoming data bits are eventually misinterpreted at the decoder due to the drifted clock pulse and bit errors occur. Figure 1: Video sync timing wander and bit errors. Such bit errors can only be repaired by FEC mechanisms with cyclic redundancy checks and checksums, for example; the use of jitter buffers or display buffers at the video receiver does not improve the video quality in this case, because the bits are already being misinterpreted Figure 2: Delay, delay variation and time-constraints of video transmissions across networks. as they arrive at the decoder and any additional buffering map an SDI video stream of 270 Mbps onto IP packets does not improve the situation. of 1466 Bytes length; the resulting traffic flow has CBR (Continuous Bit Rate) characteristics and the steady amount of bandwidth it requires is dependent on the FEC C. Jitter Control Based on FEC Mechanisms settings of the device. The FEC mechanism is capable of Both types of jitter can be alleviated with the use correcting packet loss and incorrect packet sequencing of Forward Error Correction algorithms: Packets that within its correction range. The amount of applied FEC experience excessive jitter across the network and arrive mechanisms can be adjusted for each application in too late at their destination and must be considered lost order to keep the FEC overhead and FEC induced latencies to a minimum. for the video application or packets that have actually been lost during the transmission can in some cases The Cx1000 adapters offer two different types of be replaced with redundant duplicate packets that were FEC methods: A Double-FEC mechanism for network generated as part of an FEC algorithm. At the same time, transmissions where severe impairments are expected, most FEC mechanisms also apply checksums and cyclic and a Partial-FEC method that offers less bandwidth redundancy checks and are therefore able to restore bit overhead. The Double-FEC mechanism provides errors due to jitter wander to a certain extent. However, full redundancy by sending each packet of the video the exact definition of the FEC algorithm and the amount stream twice and doubling the bandwidth requirements. of available buffer time that is allocated to the repair and A setting of Double-FEC requires also the specification of recovery process determine in the end how much of the a burst window size between 2 and 4096, which defines jitter distortions can actually be avoided. the maximum number of consecutive packets that may In our investigation we used SDI video adapters be out of sequence or lost and still be fully recovered by (Path1 Cx1000) [6] for the transmission of uncompressed the inverter at the destination. digital video across IP networks. The Path1 adapters 18 19

12 Partial-FEC is intended for networks or applications where doubling the video bit rate is not an option. With its settings of a burst size and bandwidth overhead it offers the possibility to optimize the trade-off between bandwidth requirements and partial redundancy for packet loss protection. As in the case of Double-FEC, the burst window size specifies the maximum amount of packet losses that can still be reconstructed; possible burst size selections can be varied between 2 and 1024 packets. The overhead parameter can be adjusted from 6% to 50% and indicates the amount of bandwidth that will be required in addition to the regular video bit rate. The partial redundancy set by the overhead parameter also indirectly defines the length of the recovery process in case of a burst loss. Additional losses that occur within this recovery period cannot be fully restored by the Partial-FEC algorithm. Optimal overhead values can be set by observing network loss patterns and determining the minimum time Tburst between burst losses; to estimate Tburst and configure a reasonable overhead percentage, the devices offer a dropped packet counter that can be monitored for changes. In the following Chapter these FEC mechanisms are applied to the back-to-back transmission of an uncompressed video signal via a software-based NIDS and the resulting video quality is described. NIDS impact on the quality of FEC-protected video In the test setup, an uncompressed Serial Digital Interface (SDI) video signal was fed into the Path1 encoder, which mapped the video source to IP packets. Before the packets were received by the Path1 decoder (or network destination) they traveled through a Dell PowerEdge 1750 server [7] where a (Juniper) NetScreen IDP 1000 system [8] was mounted (Figure 3). The NetScreen IDP 1000 is a software-based intrusion detection and protection (IDP) system, which does not only offer capabilities to detect attacks from reaching a target host, but also provides features such as the dropping of malicious packets during attacks. In contrast to hardware-based NIDS with their highly specialized hardware modules, software-based systems run their software on a PC-architecture with time-consuming CPU processing. The NetScreen IDP system is based on a three-tier architecture that includes an IDP sensor and an IDP management server along with the IDP user interface. The primary task of the IDP sensor is network monitoring in order to detect anomalies in network traffic. The detection of suspicious packets is based on a set of specific rules defined in its IDP databases. The management server is responsible for logging and reporting data and applying the security policy management of Figure 3: Test setup for the investigation of uncompressed SDI video transmissions and the jitter impact on the resulting video quality caused by an NIDS and its packet reordering. the IDP system and was used with a Solaris 8 Management Server Platform. The Dell PowerEdge 1750 server offered dual Intel XeonTM 3.06GHz processors, dual Gigabit NICs and 266MHz DDR SDRAM (8GB) memory. Before testing the real-time application traffic, we conducted performance tests with an Agilent Router Tester 900 [9]. The tests showed a maximum throughput of 99.85% of the GE interface capacity resulting in ps of throughput (with a packet size of 1400 Bytes). A test with a small packet size of 64 Bytes resulted in a maximum throughput of packets per second (or Mbps) without any measurable side effects to the system or packet drops. In addition to these throughput tests we also examined the ability of the NIDS to process concurrent flows; the NIDS was capable of processing at least parallel flows. For the tests in this investigation, the following FEC settings of the Path1 video sender/receiver were used: Transmissions of SDI over IP with Double-FEC algorithms with burst sizes of 32 (DBL32) and 1024 (DBL1024) packets, and Partial-FEC methods with burst sizes of 32 or 1024 packets and selections of 10% and 25% bandwidth overhead. For Partial-FEC settings, the following notation will be used: PT32-10 describes a burst window size of 32 packets and a load overhead of 10%; PT32-25 refers to a burst size of 32 packets with a 25% bandwidth overhead. Similarly, PT and PT stand for Partial-FEC methods with burst sizes of 1024 packets and 10% or 25% overhead loads. During the tests the NIDS was not configured to perform any policing functions; the packets were simply sent through the system. Although no policing functions were set at the IDP and the video sender and receiver were connected back-to-back via the IDP system, a variety of video distortions could be observed (Figure 4). Since no other network components were present in the test setup, the video distortions had to be attributed to the NIDS processing; a direct back-to-back loop of the Path1 equipment for control showed indeed a perfect video transmission without any of the artifacts observed with the IDP present. Figure 4: Typical video distortions as observed with FEC mechanisms PT and PT Subjectively the video distortions were rated as shown in Table 1: The best video quality was achieved with PT32-10 and PT32-25 algorithms, as in these cases the video seemed fine for long durations when suddenly severe distortions would occur that lasted several seconds. The worst subjective video quality was delivered by FEC algorithms that had long window burst sizes of 1024 packets; the distortions occurred with a periodic rhythm of every 2 seconds and were worst for the PT-FECs; DBL FECs fared slightly better with less severe distortions, but their periodic nature also turned the subjective quality of the video into a rating of poor only. This applied to both DBL32 and DBL1024 FECs, although the smaller burst window size exhibited less severe video distortions. FEC Mechanism Subjective video quality Video artifacts The observations suggest that the software-based NIDS processing caused enough delay variation in the arrival of the video packets at the video receiver to severely distort the video. The frequent and repetitive nature of the errors led to a subjectively better quality perception in cases where the FEC method had a small burst error window size of only 32 packets and the repetitive nature of the errors allowed enough recovery time for the Partial-FEC algorithm to be able to fully restore the errors. This was not the case for an error burst window size of 1024 packets, where distortions with a loss of signal could be detected every few seconds. In an effort to locate the reason behind this packet jitter, we investigated the log statistics of the Path1 video receiver: The statistics showed that the IDP system had actually reordered the packets on their way through, although no policing features had even been activated at this time. Table 2 provides an overview of the log statistics obtained from the Path1 receiver for various FEC settings and reflects the measurements of a 5-minute (300 sec.) interval: FEC Mechanism reordered packets (300 sec. interval) DBL 32 DBL 1024 PT PT PT PT Table 2: FEC mechanisms of the Path1 video sender / receiver and log statistics of reordered packets during a 5-Minute interval. FEC mechanisms with Double (DBL) algorithms all showed an equal number of 230 packets being reordered. Partial-FECs also had equal amounts of packets reordered, which seemed to be dependent on the amount of redundant bandwidth that was used and turned out to be the same for both window burst sizes of 32 packets and 1024 packets: the least amount of DBL 32 DBL 1024 PT PT PT PT POOR POOR EXC / BAD EXC / BAD BAD BAD mild distortions every 2 seconds distortions every 2 seconds distortions every few seconds distortions every few seconds Table 1: FEC mechanisms and subjective video quality of video transmissions via IDP system. loss of signal every 2s loss of signal every 2s 20 21

13 packets (115 packets) were reordered in the cases provided a perfect video. Similarly, the addition of a 10 by itself exceed the recommended limit of 150 ms as in methods; double-fec algorithms could not be applied with a 25% bandwidth overhead; when the bandwidth ms buffer also improved the video quality for PT the example of the PT method with 440 ms: for a good video quality. Repetitious jitter wander and overhead was reduced to only 10%, a reordering of 185 and PT algorithms. The additional display buffer at time drifts were also introduced by the software-based packets had been required. The exact details on the FEC the decoder obviously allowed more time for reordering NIDS processing that led to bit errors and subsequent algorithms, their functionalities and how the redundant percentage of bandwidth is distributed across the video payload were unfortunately not revealed by the manufacturer. Thus the observation remains that for Partial-FECs in this case less packets had to be reordered when more bandwidth was available - independent of the configured burst error window size at the receiver. A full bandwidth redundancy of 100% as in the cases of Double-FECs, however, did not lower the number of reordered packets further, but instead led to the highest number of packets requiring reordering. FEC Mechanism display buffer DBL 32 No gains DBL 1024 No gains PT ms PT ms PT ms PT ms Table 3: FEC mechanisms of the Path1 video sender / receiver, display buffers and subjective video quality. If the distortions were caused by excessive delay variation of the video packets, the question had to be investigated, if additional display buffers could alleviate the problem and improve the subjective video quality. For this reason, the tests were repeated and this time additional display buffers were configured at the Path1 video receiver until an improvement of the video could be subjectively established. Table 3 provides an overview of the results. In the cases of Double-FEC methods, no improvements could be gained by adding additional display buffers; not even a 10 second buffer was able to obtain any gains as far as video quality and observed distortions were concerned. This was not the case for the Partial FEC algorithms: In these examples, the quality of the video could be improved. When a display buffer of 22 ms was configured at the video receiver that provided 22 ms of additional time for decoding/reordering and error correction before each video frame had to be played out, the video improved significantly. In fact, the distortions seemed to have disappeared and the added display time the packet sequence that had been disturbed by the IDP system and the FEC mechanisms could work much more effectively. Smaller display buffers for the Partial-FEC mechanisms led to a video quality that was improved, but still exhibited distortions. These artifacts occurred very periodically with extremely long intervals of excellent video quality in between; the video would seem excellent in the beginning and after several minutes started to behave erratically for a minute or two, and would then return to its excellent state. The periods without errors could last up to 20 minutes or more, depending on the amount of display buffer that was set and the FEC algorithms that were configured. This periodic return of distortions with such intervals therefore had to be attributed to a certain amount of jitter wander introduced by the software-based NIDS and its packet processing. The periodic nature of some of the distortions was the result of a slow clock drift that caused bit errors. These errors could at first still be compensated with the FEC mechanisms in place, but after a certain period of time reached an error distribution that the FEC algorithm could no longer handle. As the time shift kept drifting further, the errors disappeared again as soon as the clock had drifted into the next half of the clock period again. The use of the software-based IDP system therefore was rather problematic in connection with the FEC mechanisms of the uncompressed video. Double-FECs did not yield an excellent video quality and the application of Partial-FECs only led to improvements of video quality in connection with display buffers that added an additional delay of up to 22 ms to the overall end-to-end delay of the video packets. This end-to-end delay, however, is especially crucial for interactive multimedia applications where the end-to-end delay must stay below 150 ms for a one-way transmission time in order to perceive the interactive process as spontaneous [10]. Even for uncompressed transmissions such an additional delay (as was required for a display buffer in these tests) is substantial, since the application of the FEC algorithm to the video data must also be taken into account as part of the overall one-way delay: Table 4 shows that the application of FEC methods can already add significant amounts to the overall end-to-end delay and may already No FEC FEC Mechanism Adaptation delay 1.8 ms DBL ms DBL ms PT ms PT ms Table 4: Signal adaptation and FEC induced delays. PT ms PT ms The indicated delay values in Table 4 do not include any additional delays the video packets may encounter as part of their transmission such as propagation delay, queueing delays or compression delays when compressed video is used. The requirement of an additional display buffer due to software-based NIDS processing could therefore be the decisive factor if an interactive multimedia application is possible across the network or not. Conclusion and future work The tests presented in this paper described the influence of a software-based NIDS on uncompressed video that was protected by various FEC algorithms using packet redundancy and reordering to improve video quality in the presence of impairments such as jitter. As NIDS typically employ packet reordering for IP defragmentation in order to detect hacker attacks that involve the fragmentation of malicious code across multiple data packets it was challenging to see how much of an impact such NIDS-related reordering could actually have on the resulting video quality. Unfortunately the tests showed that the tradeoff between security and the usability of the multimedia service could not be bridged as the software-based NIDS reordering and defragmentation processes introduced so much jitter to packets carrying video data that the resulting video quality was severely impacted. The tests even showed that this jitter impact could already be observed when no actual policing features were activated and was so severe that testing the NIDS in connection with added policing became irrelevant. Additional display buffers of up to 22 ms were necessary to alleviate the jitter influence on the video packets in connection with Partial-FEC video artifacts. The additional display buffers that were required to receive an improved video quality would be difficult to configure for applications that are interactive and depend on the lowest possible end-to-end delay. In future work, an improvement could be the application of hardware-based NIDS or IDP systems. The hardware components could accomplish the packet reordering with faster speeds and may introduce much less jitter to the video. Future work should repeat these tests with a comparable hardware-based IDP system and similar FEC algorithms. In addition to uncompressed SDI transmissions, future work should also involve the investigation of HD video, where the high data volumes could lead to video distortions caused by NIDS packet drops [11]. References [1] Matrawy A., van Oorschot P. C., and Somayaji A., Mitigating Network Denial-of-Service through Diversity- Based Traffic Management, Applied Cryptography and Network Security: 3rd Int. Conf., ACNS 2005, New York, June 7-10, (2005), Proceedings, Lecture Notes in Computer Science Vol Springer, [2] Caswell B., Beale J., and Baker A., Snort IDS and IPS Toolkit. (2007) Syngress Publishing ISBN [3] El-Atawy A. and Al-Shaer E., Building Covert Channels over the Packet Reordering Phenomenon, 28th Ann. IEEE Conf. Comp. Comm. (INFOCOM 09), Rio de Janeiro, Brazil, (2009), [4] Tekronix, Inc., Jitter Analysis: A Brief Guide to Jitter. (2005) eng/61w_18897_1.pdf (accessed June 14, 2010) [5] Tekronix, Inc., Analyzing Jitter Using a Spectrum Approach. (2002) tidownload.lotr?ct=ti&cs=apn&ci=2291&lc=en (accessed June 14, 2010) [6] Path1 Network Technologies, Cx1000 Forward Error Correction, Path1 Network Technologies, Inc., San Diego, CA. (2002) (accessed June 14, 2010) [7] Dell PowerEdge 1750 Server, Dell Product Group. (2003) [8] Juniper NetScreen IDP (June 2010) [9] Agilent RouterTester 900, (June 2010) [10] ITU-T G.114: Transmission Syst. & Media: Gen. Char. of Int. Tel. Conn. & Int. Tel. Circuits. One-Way Transmission Time. (1996) [11] Mell P., Hu V., Lippmann R., Haines J., and Zissman M., An Overview of Issues in Testing Intrusion Detection Systems, National Institute of Standards and Technology ITL. (2002) pdf (accessed June 14, 2010)

14

15 kann, z. B. von seiner Arbeitsplatzstation zu zentralen Servern. Zu prüfende Objekte, Objektklassen, Operationen Potentielle Testobjekte sind z. B. einzelne, reale Geräte (z. B. Router, Switche), ihre Interfaces, Links (Verbindungen untereinander), aber auch virtuelle Objekte und Schnittstellen (VLANs, Defaultroutes), sowie Funktionen im Zusammenwirken (Routing, Kommunikationspfade). Einzel- und summarische Aussagen (Bewertung, Zusammenfassung) Sowohl für komplexe Objekte (z. B. Router) als auch erst recht für ein gesamtes Netzwerk stellt sich die Frage, welche Bedeutung ermittelte Verfügbarkeiten einzelner Elemente oder Teilbereiche für das jeweils übergeordnete Gebilde haben. Definition und Bestimmung von Verfügbarkeiten bzw. Ausfällen Je komplexer einzelne Objekte oder Funktionen sind, desto erforderlicher ist es festzulegen, wann sie als verfügbar bzw. ausgefallen (nicht verfügbar) gelten und mit welchen Methoden dies zu ermitteln ist. Definition von Betriebszeiten (100%), Berücksichtigung von Ausfallursachen Am nächsten liegt der pauschale Ansatz für die Betriebszeit (Sollzeit der Verfügbarkeit, 100%-Bezug) von 24 Stunden an allen Tagen. Er könnte aber z. B. für einzelne Netzteile oder Komponenten individuell modifiziert werden, wenn sie vorübergehend gezielt aus dem Betrieb genommen werden (geplante Unterbrechungen, Umbau/Wartung). In diesen Fällen wäre es auch vertretbar, entsprechende Ausfälle nicht als solche zu bewerten, also zur Beurteilung von Verfügbarkeit nicht zu berücksichtigen. Dies gilt für einen Netzbetreiber in gewissem Maße auch für Ausfälle, deren Ursachen außerhalb seines Einflussbereichs liegen (externe Ursachen, Stromausfälle, Störungen durch Nutzerfehlverhalten). Zielsetzung, Aufwand, Werkzeuge Ausgerichtet an Zielvorstellungen sind im konkreten Fall Begriffe, Parameter und Methodik zu definieren. Dabei sind erforderlicher Aufwand, verwendbare Werkzeuge sowie personelle und technische Möglichkeiten zu berücksichtigen, d.h. unter Gesichtspunkten von Kosten/Nutzen zu bewerten. Sie lautet: Dabei stehen der mittlere Fehlerabstand (englisch: Mean Time Between Failures) für Zeiten ohne Fehler und die mittlere Reparaturzeit (englisch: Mean Time To Repair) für Ausfallzeiten. Es wird also ausfallfreie Zeit in Bezug zur Summe aus ausfallfreier und Ausfallzeit gesetzt (Prozentwert ergibt sich aus Multiplikation des Quotienten mit 100). Beobachtete Objekte Die behandelten Objekte gliedern sich in zwei Gruppen: reale Netzgeräte (Router und Switche) und virtuelle Netzschnittstellen (IP-Defaultrouten von Subnetzen). Einzelverfügbarkeit Verfügbarkeit wird in Prozent pro Objekt berechnet nach der Formel In Abbildung 2 sind die Statusermittlung durch eine zentrale Managementstation, Auswertung des Loggings zur Bestimmung von Verfügbarkeiten und das Reporting der Resultate über ein für Nutzer zugängliches Webinterface skizziert. Zur Berechnung von Verfügbarkeitszahlen gibt es verschiedene formale Ansätze. So orientiert sich zum Beispiel Formel (1) an einem Modell, in dem Betriebsstörungen als Fehler einzelner Komponenten (Geräte) erkannt, identifiziert, behoben werden und darüber entsprechend Buch geführt wird. Das gilt auch für einen etwas offeneren Ansatz, bei dem Betriebs- und Ausfallzeiten direkt in die Berechnung eingehen, also z. B. ohne vorherige Mittelung: (Ausfallzeit steht für die Summe aller Ausfälle eines betrachteten Zeitraums). Beide Ansätze führen bei entsprechender Interpretation zu gleichen Resultaten, lassen aber für die Anwendung offen, auf welche Objekte oder Objektmengen sich die Formeln genau beziehen und wie die eingehenden Parameter konkret definiert und ermittelbar sind. Dies ist in Bearbeitung oben beschriebener Problematik in der Praxis spezifisch festzulegen. Daraus ergibt sich auch, dass resultierende Angaben, Auswertungen und Darstellungen immer im jeweiligen Kontext zu betrachten und nur sehr bedingt allgemein vergleichbar sind. So erfordern z. B. garantierte Jahresverfügbarkeiten von 99,999 % und höher (max. 5 Min. Ausfall im Jahr) nicht nur gezielte Maßnahmen der Gestaltung von Betrieb und Netzwerk, sondern auch spezifische Methoden für ihren Nachweis, abgesehen davon, dass ein solcher Wert zwar generell anzustreben, aber allenfalls in sehr speziellem Kontext tatsächlich sinnvoll anzufordern ist. Messverfahren und Reporting Das RRZE verwendet zur Gewinnung von Aussagen über Netzverfügbarkeiten einen pragmatischen, ohne großen dedizierten Aufwand umzusetzenden Ansatz mit dem zentralen Netzwerkmanagement (NMS) bzw. seiner Statusüberwachung als Ausgangsbasis. Er lässt sich wie folgt beschreiben: Diese Formel, die dem oben beschriebenen Ansatz (2) entspricht, dient der monatlichen und jährlichen Berechnung prozentualer Verfügbarkeiten. Parameter Betriebszeit Als Betriebszeit gelten pauschal für alle Objekte 24 Stunden an allen Tagen eines Monats bzw. Jahres. Parameter Ausfallzeit Ausfallzeiten werden pro Objekt über die zentrale Statusüberwachung bestimmt, sie sind jeweils als die Summe aller Abschnitte zwischen down und up definiert. Statusermittlung Ein Objekt hat den Status up, wenn es vom zentralen Management (NMS) erfolgreich angesprochen werden kann (über Protokolle SNMP, Ping), den Status down, wenn dies nicht der Fall ist. Die Abfragezyklen liegen in der Regel zwischen 60 und 180 Sekunden. Statusbedeutung Der Status beurteilt neben der Funktionsfähigkeit eines Objektes auch den jeweiligen Kommunikationspfad durch das Netz (vom NMS zum Objekt) und damit auch allgemeine Grundfunktionalitäten des Netzes. Anmerkung Ausfallzeiten gehen unabhängig von ihren Ursachen (extern/intern, geplant/ungeplant) in die Berechnung ein. (Dagegen rechnen manche Netzprovider wie der DFN angekündigte geplante Unterbrechungen aus den Ausfallzeiten heraus). Reporting Die monatlich/jährlich ermittelten Einzelverfügbarkeiten werden für die Nutzer aufbereitet und über ein Webinterface (WEB-NMS) zur Ansicht bereitgestellt (Reporting). Dabei sind zu jeder (der beiden) Gruppen die Objekte aufsteigend nach Verfügbarkeitswerten gelistet und längere Ausfallzeiten in Kommentaren textlich erläutert und bewertet (Ursachen, Auswirkungen, Behebungen, usw.) Summarische Verfügbarkeit In den zusammenfassenden Auswertungen werden Durchschnitts- und Minimalwerte betrachtet. Abbildung 2: Netzwerkmanagement und Verfügbarkeitsbestimmung Langzeitverlauf Das RRZE hat nach der beschriebenen Methode ab dem Jahr 2000 Verfügbarkeiten systematisch bestimmt und dokumentiert. Bei Betrachtung und Vergleich der Resultate ist zu beachten, dass sich der Aufbau des Netzwerks im Laufe der Zeit auf Basis technologischen Fortschritts und finanzieller Möglichkeiten verändert hat und die oben beschriebene Struktur migrativ entstanden ist. Die verschiedenen Ausbau- und Entwicklungsstufen des Klinikumsnetzes sind in einem zusammenfassenden Bericht des RRZE näher beschrieben [HILL]. Verfügbarkeit von Netzgeräten (Router, Switche) Die Verlaufsgrafik in Abbildung 3 stellt die Verfügbarkeiten aller Netzkomponenten, d.h. der Router und (zentral betreuten) LAN-Switche dar, unabhängig von ihrer Relevanz für den gesamten Klinikbetrieb. Angezeigt sind pro Jahr der jeweils minimale (Min) und maximale 26 27

16 (Max) Wert sowie der Durchschnitt (Mittel) über alle (Standby-Betrieb) unterschieden. In zusammenfas- neuerer Technologie (Schnittstellen > 622 mbps statt 155 über alle Subnetze bei 99,99%, d.h. die entsprechende der erfassten Geräte. In einer 2. Minima-Kurve (Min2) sender Auswertung sind bezüglich aller, jeweils betrie- mbps, Routing in Hardware statt über CPU-Verarbeitung) Ausfallzeit betrug pro Jahr eine knappe Stunde (53 Min.). sind extreme Ereignisse mit sehr geringer Bedeutung benen Router die minimalen (R-Min), durchschnittlichen sind an jeweils deutlich verbesserten Werten abzulesen. für den Gesamtbetrieb außer Acht gelassen, wie z. B. eine von der betreffenden Nutzergruppe initiierte lokale (R-Mittel) Jahreswerte dargestellt, ergänzt durch eine nur über die primären Router bestimmte Minimakurve Sie liegen ab 2004 im jeweiligen Jahresmittel oberhalb von 99,98% bzw. 1 Std. 45 Min pro Jahr. Ausblick Stromabschaltung über die Osterfeiertage (in kleinem Einzelgebäude, 2008) oder Abschaltungen im Rahmen genereller, baulicher Renovierungsmassnahmen in der Rechtsmedizin (ohne unmittelbar klinische Versorgung, 2009). Die Abstände der Verlaufskurven lassen darauf schließen, dass relativ schlechte Verfügbarkeiten weitgehend Einzellfällen zuzuordnen sind. Min2 deutet an, wie durch genaue Betrachtung und Bewertung von Fehlersituationen ein differenzierteres Gesamtbild gezeichnet werden kann. Abbildung 3: Jahresverfügbarkeiten der Netzkomponenten (Router+Switche) Das Netz hatte bezüglich seiner Netzkomponenten in der Gesamtheit unabhängig von Störungsursachen, d.h. unter Einschluss extremer Sonderfälle, über die angezeigten elf Jahre eine mittlere Verfügbarkeit von 99,93% und war in den letzten fünf Jahren im Mittel zu 99,97% verfügbar. Das entspricht einer durchschnittlichen Ausfallzeit von sechs bzw. 2,5 Stunden pro Jahr. Dabei sei nochmal angemerkt, dass diese Verfügbarkeiten verschiedene Funktionalitäten und Konnektivitäten der Komponenten beinhalten, also z. B. nicht auf reine (aktive) Standzeiten (SysUpTime) der Geräte beschränkt sind. Unter den Netzkomponenten spielen die Router als LAN-Verteiler und Vermittler zwischen verschiedenen IP-Netzen eine fundamentale Rolle. Ihre Verfügbarkeiten werden deshalb herausgehoben und in Abbildung 4 gesondert dargestellt. Im Redundanzkonzept des Netzes werden primäre (Normalbetrieb) und sekundäre Router (R-Min-P). Des Weiteren enthält die Grafik drei individuelle Kurven, die die Verfügbarkeiten des primären Routers eines Bereichs darstellen. In diesem Sinne gilt dabei eine eindeutige Zuordnung, obwohl die Router je nach Entwicklungsphase des Netzes für unterschiedliche reale Geräte(typen) stehen können. Die schlechtesten Verfügbarkeiten (R-Min: 2001, 2003) gehören zu sekundären Routern und sind daher nur mit sehr bedingtem Einfluss auf den Betrieb. Dazu ist z. B. in der originalen Jahresstatistik 2001 kommentiert (romulus gehört zum Bereich sued): Backup-Router romulus : Ausfälle auf Grund von Instabilitäten und Tests (vornehmlich Mai und Oktober) ohne gravierende Auswirkungen auf den Betrieb. Abbildung 4: Summarische und exemplarische Jahresverfügbarkeiten der Router Der kleinste Wert eines primären Routers (R-Min-P: 2002) fällt in die Aufbauphase eines neuen Bereichs (noz, Neubau Nicht Operatives Zentrum) und steht damit für einen noch nicht voll eingeführten Regelbetrieb. Sonst liegen die Werte in jüngerer Vergangenheit tendenziell oberhalb von 99,95. In den Kurven zu den Anfangsjahren spiegelt sich wieder, wie steigende Nutzung die wenigen Router zunehmend an ihren Leistungsgrenzen belastet und zu gelegentlichen Verklemmungen geführt hat. Ihre Entlastung durch Ausbau und Einsatz von Geräten Verfügbarkeit logischer Netzschnittstellen Für Nutzer bzw. Endgeräte sind auf IP-Ebene sobezeichnete Defaultroutes die nächsten Schnittstellen zur Kommunikation mit Systemen außerhalb des eigenen VLANs bzw. IP-Subnetzes. Diese stellen sich im hier betrachteten Netzwerk als logische, virtuelle IP-Hostadressen dar, die in Redundanz jeweils einem von zwei Routern zugeordnet sind. Dabei erfüllt einer der Router die Schnittstellenfunktion im Standardbetrieb (primärer Router), während der zweite dessen Aufgaben in Ausfallsituationen automatisch übernimmt (Standby-Router). Dementsprechend sind in der Regel die Verfügbarkeiten der IP-Schnittstellen höher, als die einzelner Router. Es kann aber durchaus auch Ausnahmen geben, in denen der Betrieb einzelner Subnetze gestört ist, während die betreffenden Router erreichbar und funktionsfähig sind. Beispiele dafür können etwa partielle Verklemmungen (unter Einschluss des Redundanzbetriebs) oder Ausfälle im Betrieb der zugehörigen virtuellen LANs sein. In Abbildung 5 sind die Verfügbarkeiten verschiedener, als Repräsentanten (regionaler) Bereiche ausgewählter Netze sowie Minimum (Min) und Durchschnitt (Mittel) bezüglich aller erfassten Subnetze dargestellt. Auch hier ist der Effekt steigender Last in Bezug auf die klassischen, CPU-gesteuerten Router zu erkennen. Über die Jahre lag die aggregierte Verfügbarkeit Abbildung 5: Summarische und exemplarische Jahresverfügbarkeiten der Router von Nutzerschnittstellen (IP-Defaultroutes) Die dargestellte Methodik zur Erfassung und Auswertung von Verfügbarkeitsdaten bietet verschiedene Ansätze zur Verbesserung und zur Erhöhung der Aussagekraft. Dazu gehören folgende Punkte: Erhöhung der Genauigkeit von Erfassung und Auswertung Je mehr sich die Verfügbarkeitszahlen oberhalb von 99,95 % bewegen, desto stärker erscheint es angebracht, die Genauigkeit durch kürzere Abfragezeiten (kleiner 60 bzw. 180s) und exaktere Berechnungen (etwa auf drei Dezimalstellen) zu erhöhen. Klassifizierung von Ausfallzeiten und zugeordneter Berechnungen Durch Einteilung von Ausfallzeiten in geplante / ungeplante oder intern / extern verursachte Unterbrechungen können entsprechend zusammengefasste Auswertungen diese Unterscheidungen auch zahlenmäßig ausdrücken (statt nur in textlich kommentierter Form). Berücksichtigung der Bedeutung getesteter Objekte Das Netzwerk ist als Kommunikationsinfrastruktur darauf ausgelegt, möglichst gleichförmige Bedingungen zu schaffen. Dennoch gibt es aber Unterschiede einzelner Komponenten oder Standorte in der Bedeutung für den gesamten Netz- und Klinikbetrieb. Entsprechend können Störungen als mehr oder weniger gravierend beurteilt werden. Dies könnte in zusammenfassenden Berechnungen etwa durch gewichtete Durchschnittsbildung entsprechend berücksichtigt werden. Ausweitung der Tests auf weitere Objekttypen Technisch wäre z. B. die Einbeziehung von Endsystemen in die Verfügbarkeitstest überhaupt kein Problem. Um dabei Aussagen über das Netzverhalten zu gewinnen, müssten die Endsysteme allerdings selbst eine sehr hohe Verfügbarkeit aufweisen bzw. eigene Ausfälle klar diagnostizierbar und damit rausrechenbar sein. Entsprechend geeignete Testsysteme (Probes) könnten dann als Referenzen verschiedener Netzbereiche dienen. Dedizierte Testszenarien Für besonders hohe Verfügbarkeitsanforderungen etwa von zentralen Servern oder kritischen Apparaturen lassen sich spezielle Testszenarien entwickeln, die die Einhaltung von Vorgaben überprüfen. Die Systeme selbst und gezielt platzierte Probes könnten Teil solcher Szenarien sein.darüber hinaus gibt es 28 29

17 natürlich auch Ansätze, die nur mit ergänzender oder alternativer Anwendung weiterer Werkzeuge zu verfolgen sind. Als Beispiel dafür seien der Einsatz mehrerer Abfragestationen und entsprechend übergreifender Auswertungen genannt, was sich etwa mit Cisco-IP-SLA (Netzkomponenten als Testquellen) oder aber mit verteilten Managementsystemen realisieren ließ. Die vom RRZE geübte Praxis hat über einen für IT- Verhältnisse langen Zeitraum nützliche Grundaussagen über die Netzverfügbarkeit geliefert. Die Offenlegung der Resultate und deren grobe Zusammenfassungen kann bei naiver Betrachtung zwar auch zu Fehlinterpretationen führen, sind aber bedeutender Bestandteil eines transparenten Netzbetriebs. Sie geben Betreibern und Nutzern Basis zur Abschätzung eines für Netzgestaltung und Anwendungen wichtigen Dienstgüteparameters. Aus dieser Sicht machen Fortführung und Weiterentwicklung unter Beachtung vertretbaren Aufwands weiter Sinn. Literaturverzeichnis [CIS] Cisco System Inc.: Availability Measurement, Networkers 2004, Session NMS-2201, verfügbar am unter prod/collateral/iosswrel/ps6537/ps6550/ prod_presentation0900aecd pdf. [GRE] Green, H., Hant J., Lanzinger, D.: Calculating Network Availability, Aerosp. Corp., Los Angeles, CA, Aerospace conference, 2009 IEEE, verfügbar am unter jsp?tp=&arnumber= [HILL] Hillmer, U.: Das Datennetz im Universitätsklinikum, Entwicklung von , RRZE-IFB 8, Dezember 2011, file/1136. [MGN] Cisco Medical-Grade Network (MGN) 2.0 Campus Architecture, last updated March 31, 2011, solutions/verticals/healthcare/ MGN_Campus.pdf. [NTR] N-Tron Corporation: Network Availability, verfügbar am [ZAH] Zahemszky, A., Tapolcai, J., Császár, A., Mihály, A.: Novel Availability Metrics for Network Topologies, High Speed Networks Laboratory, Budapest University of Technology and Economics, Sept. 30, 2009, verfügbar am von upload/ file/technical/c1_3_zahemszky_tapolcai_ Csaszar_Mihaly.pdf. [ZOU] Zou, W., Janic M., Kooij, R., Kuipers, F.: On the Availability of Networks, Broadband Europe, Antwerp, Belgien, Dezember 2007, verfügbar am unter bbeurope07.pdf. Network Virtualization and Future Internet Platforms Enabling Future Internet Research: The FEDERICA Case Peter Szegedi 1, Jordi Ferrer Riera 2 and Joan A. García-Espín 2, Markus Hidell 3, Peter Sjödin 3 and Pehr Söderman 3, Marco Ruffini 4 and Donal O Mahony 4, Andrea Bianco 5 and Luca Giraudo 5, Miguel Ponce de Leon 6 and Gemma Power 6, Cristina Cervelló-Pastor 7, Víctor López 8, Susanne Naegele-Jackson 9 1 Trans-European Research and Education Networking Association 2 Fundació i2cat 3 KTH Royal Institute of Technology 4 Trinity College Dublin 5 Politecnico di Torino 6 Waterford Institute of Technology 7 Universitat Politècnica de Catalunya 8 Universidad Autónoma de Madrid 9 Friedrich-Alexander University of Erlangen-Nuremberg Abstract The Internet, undoubtedly, is the most influential technical invention of the 20th century that affects and constantly changes all aspects of our day-to-day lives nowadays. Although it is hard to predict its long-term consequences, the potential future of the Internet definitely relies on future Internet research. Prior to every development and deployment project, an extensive and comprehensive research study must be performed in order to design, model, analyze, and evaluate all impacts of the new initiative on the existing environment. Taking the ever-growing size of the Internet and the increasing complexity of novel Internet-based applications and services into account, the evaluation and validation of new ideas cannot be effectively carried out over local test beds and small experimental networks. The gap which exists between the smallscale pilots in academic and research test beds and the real-size validations and actual deployments in production networks can be bridged by using virtual infrastructures. FEDERICA is one of the facilities, based on virtualization capabilities in both network and computing resources, which creates custom-made virtual environments and makes them available for Future Internet Researchers. This article provides a comprehensive overview of the state-of-the-art research projects that have been using the virtual infrastructure slices of FEDERICA in order to validate their research concepts, even when they are disruptive to the test bed s infrastructure, to obtain results in realistic network environments. Introduction The European Community co-funded project FED- ERICA (Federated E-Infrastructure Dedicated to European Researchers Innovating in Computing Network Architectures) [1] supports the development of the future Internet by definition. The project consortium is an optimal mixture of research institutes, universities, and industrial partners in order to foster cross-sector collaboration. Although, the two-and-a-half-year project officially ended on 30 October 2010, after a four-month extension, the infrastructure and its services are still up and running thanks to the voluntary efforts of the European Research and Education Networking (NREN) organizations, which are actively participating in the operation of the infrastructure. FEDERICA s architecture has been designed in such a way that allows users to request virtual slices of the infrastructure that are completely isolated from each other and behave exactly as if they were physical infrastructure from the point of view of the users experiments. The major objective of the deployment of such an infrastructure is twofold. On one hand, FEDERICA allows extensive research on virtualization based architecture itself. Experiments on various resource virtualization platforms, virtual resource descriptions, monitoring and management procedures, virtual network slice compositions, isolations or federations can be performed. On the other hand, the virtual slices of FEDERICA enable multidisciplinary research on future Internet within the slices. This article is organized as follows. After a brief summary of the FEDERICA virtualization capable infrastructure and its services, we provide an overview of similar initiatives around the world emphasizing the importance of federated facilities. Then, we discuss the special features of FEDERICA that make the infrastructure unique (as of today) by way of supporting a wide variety of future Internet research activities, maybe leading to new paradigms. As FEDERICA is highly user-centric, we introduce the broad spectrum of its user community by looking at the actual users and use cases. The contribution of FEDERICA user experiments to the whole Internet research space is also illustrated in this article that finally concludes with the project s perspective for the future. FEDERICA as a service FEDERICA project participants have designed and deployed a virtualization capable infrastructure substrate, including programmable high-endrouters, multi-protocol switches, and PC-based virtualization capable nodes, on a pan- European footprint (Figure 1). The physical net-work topology is composed of 13 sites, 4 core and 9 non-core nodes, connected by 19 point-topoint links. On top of this substrate, virtual infrastructure slices can be created, which realize whatever topologies are requested by the users. The facility is also connected to the public Internet, thereby enabling easy access from any location and type of connectivity (wireless or fixed line) [1]. Virtualization is the key having a profound influence in technology. In its network-oriented meaning, it corresponds to the creation of multiple virtual networks on top of a physical infrastructure. The network virtualization can be performed at most layers of the ISO/OSI stack, from the data link to the network layer. In its systemoriented sense the process is even faster and more intriguing, leading to multiple operating systems with varying tasks running on the same hardware platform. The service architecture of FEDERICA fol- lows the Infrastructure as a Service (IaaS) paradigm. IaaS, in principle, is the common delivery of hardware (e.g., server, storage, network), and associated software (e.g., operating systems virtualization technology, file systems) as a service. It is an evolution of traditional hosting that does not require any long term commitment and allows users to provision resources on demand. Amazon Web Services Elastic Compute Cloud (EC2) and Secure Storage Service (S3) are examples of commercial IaaS offerings [2]. FEDERICA has two major services: 30 31

18 The provisioning of best effort or QoS IP slices with the option of both preconfigured and unconfigured resources (i.e., routing protocols, operation systems, QoS parameters) The provisioning of raw resources in terms of data pipes (i.e., native Ethernet links) and unconfigured resources (i.e., empty vir- tual machines, clear routing tables, no network protocols) The current FEDERICA services may naturally evolve toward Platform as a Service (where various preconfigured images and network scenarios can be provided from a repository), and Application as a Service (where a set of applications can be preselected by users). This may eventually lead to a complete portfolio of cloud services, where all of theseservices share simplicity in access, typically through a web inter- face, simple scalability, and ease of use. Federated facilities worldwide FEDERICA does not operate in isolation. There are initiatives all over the world, which are of particular relevance and represent the natural set of peers for liaison and collaboration with FEDERICA. United States The Global Environment for Network Innovation (GENI) initiative [3] in the United States is an activity that aims at creating a unique virtual laboratory for at-scale networking experimentation. GENI is in its third phase, called spiral 3, of exploratory rapid prototyping with about 50 experiments and facilities operational. Work in spiral 3 should improve the inte- gration, operations, tools, and documentation of GENI prototypes to lower the barriers of use. User projects have to collectively agree on a federation architecture to create the GENI environment spanning multiple facilities. The FEDERICA project has obtained excellent interactions with the GENI project office and some GENI experiments (e.g., ProtoGENI, GpENI) through regular meetings. Japan The AKARI Architecture Design Project in Japan [4] aims to implement a new generation network by 2015, developing a network architecture and creating a network design based on that architecture. The philosophy is topursue an ideal solution by researching new network architectures from a clean slate without being impeded by existing constraints. Some prototyping projects have been started at the University of Tokyo in collaboration with the National Institute of Information and Communi- cations Technology (NICT). Europe In Europe, the FIRE initiative [5] from the European Commission funds various infrastructure Figure 1: FEDERICA infrastructure, the substrate topology. projects (e.g., Panlab, Wisebed, OneLab) with which FEDERICA already has strong collaboration. The federation of OneLab and FEDERICA facilities is an excellent example in terms of combining guaranteed and nonguaranteed resources. FEDERICA can offer resources to OneLab that have full access to the network layers and OneLab can provide access to a larger set of distributed computing resources. During the last years, OneLab has developed an architecture to federate different domains based on PlanetLab that is called Slice Federation Architecture (SFA) [6]. SFA enables FEDERICA and similar infrastructures to become a worldwide federated facility supporting collective on future Internet research. Figure 2: User segmentation results on the exploited unique features of FEDERICA. Unique features of FEDERICA FEDERICA can be easily compared with PlanetLab [7]. PlanetLab started in Princeton, New Jersey, and is a well-known global research facility based on a large set of end hosts on top of the public Internet. The hosts are running a common software package that includes a Linux-based operating system. The key objective of this software package is to support distributed virtualization (i.e., the ability to allocate a slice of PlanetLab networkwide hardware resources to a user application). In contrary, a FEDERICA node is not only considered as an end host as in PlanetLab, but a combined network and computing element that itself routes traffic and affects network reachability. In addition, the user is not forced to use a specific operating system or application but it is free to install any software component within the slice. While PlanetLab connections are based on the public Internet, FEDERICA allows the user to perform experi- ments on the lower layers as well. FEDERICA architecture is more than an evolution of the concept of a traditional test bed. Test beds are usually devoted to a few technologies and oriented to production service or to pure research, and are not flexible enough to accommodate both types of use. The FEDERICA environment is also different from a commercial cloud environment, where the delay between nodes is typically negligible. In FEDERICA the delay corresponds to physical distance of the substrate nodes. Such naturally distributed architecture provides an ideal environment for testing medium size experiments and migration paths in a realistic environment. The unique features of FEDERICA (as of today) can be summarized as follows: FEDERICA has its own physical substrate fully controlled and managed by the FEDERICA Network Operation Center. This allows the user to take over control of the lower layer resources within their slices. At the moment, only raw Ethernet resources are available for the users but in the near future native optical resources (i.e., lambdas) may also be provided. Thanks to having full control over the substrate links, specific QoS parameters can be assured for the virtual connection of the user slices and real transmission delays can be experienced. Currently the links run up to 1 Gb/s but this may be upgraded radically in the near future. FEDERICA users have full flexibility and freedom to choose any networking protocol or operating system to be installed on their virtual nodes. To the virtualization platform end, JUNOS-based programmable highend Juniper platforms and VMware-based SUN servers are both currently deployed in the FEDERICA substrate. FEDERICA can ensure the reproducibility of the complete testing environment and conditions of the user experiments at a different location or time. Repeatability of the experiments can also be ensured in the sense of obtaining the same results given the same initial conditions at any time. The overall architecture is federation-ready in line with the Slice Federation Architecture concept. Moreover, FEDERICA provides, for example, non-webbased federated SSH access to all of its resources supported by the Single-Sign-On infrastructure of the research and education community. However, it is important to mention some of the limitations of FEDERICA, too. Typically, compared to PlanetLab or commercial clouds, the scalability of the FEDERICA virtual infra- structure is limited. The scalability is the function of the given size of the physical substrate (that may be extended in the future) and the number of active user experiments requiring QoS assurances on links and/or computing nodes. As a consequence of this, user access to the FEDERICA slices must be governed with care. This role is undertaken by the User Policy Board of the project, which collects and approves (or rejects) user slice applications. The exploitation of the aforementioned unique features of FEDERICA is illustrated in this article by a wide range of user projects. Users and use cases During the active lifetime of the FEDERICA project ( ) the consortium partners approached and consulted more than 40 potential user groups all over Europe that resulted 15 slice requests for specific user experiments, as of 30 October, The segmentation and analysis of the user community have been considered to be important to FEDERICA. The aim of this segmentation was to understand the user community better and the type of experiments that can exploit the unique features of FEDERICA. This should help to steer the future infrastructure development and user consultation activities in the right direction so as to support the needs of the community better

19 User segmentation The detailed results of the FEDERICA user segmentation are available in the public project deliverables [8]. In the following section, we highlight the main characteristics of the user community. Analyzing both the slice requests already sub- mitted and the preliminary requirements collected from the possible user groups, Figure 2 shows that 40 percent of the performed experiments in FEDERICA use a slice as a fully configured IP network with best effort connections. There is nothing unique in that sense, so other motivations (e.g., cost, economy of scale, simplicity of use) must exist in the case of that 40 percent. In contrast, 60 percent of the experiments performed use FEDERICA because of its unique features (e.g., IP quality of service assurance or unconfigured resource provisioning). In particular, 26.6 percent of users have requested raw resources and data pipes (i.e., IaaS) in order to fully configure and manage their slices. Analyzing the potential broader user base, we expect a few more user experiments in the future exploiting the above mentioned unique features of FEDERICA. Major experiments FEDERICA s mission is to support the development of the future Internet via Future Internet Research projects. To measure its success, FEDERICA has collected feedback from users in order to understand, say, the contribution of the experiments results to the ICT research community as a whole. Figure 3 shows the results of the users feedback on this particular aspect. Sixty percent of the experiments performed in FEDERICA contribute to international research projects partly funded by the European Commission. More than 10 percent of experiments are aimed at directly or indirectly contributing to standardization activities in the field of networking. Requests from the commercial or private sector has not yet been received during the active lifetime of the project, but some discussions within the community suggest that it could be possible in the future. Contribution to future internet research In the following section, we illustrate the usage of FEDERICA via a wide spectrum of its user experiments. The examples of user experiments are grouped in three categories according to their main objectives; validation Figure 3: Contribution of FEDERICA experiments to ICT research community. of virtual infrastructure features, evaluation of multilayer network architectures, and design of novel data and control plane protocols. Validation of virtual infrastructure features This group of experiments aims at validating the basic principles of virtualization capable infrastructures in general and particularly the unique features of FEDERICA. The Universitat Politècnica de Catalunya (UPC), Spain, requested a FEDERICA slice, called ISOLDA, in order to perform basic network performance and slice isolation tests. Parameters such as bandwidth, latency, jitter, and packet loss were measured in parallel slices with the aim to prove sufficient isolation between them. Figure 4 depicts the test scenario where two virtual connections (red and dashed green slices) share a physical port on the FEDERICA substrate node in the middle. This shared physical link contains two different VLANs, one for each virtual connection. VM1 and VM3 are located on the same virtual machine server, called VMServer 1, while VM2 and VM4 are located on another server, called VMServer 2. The other virtual connection (dotted blue line) does not share any resource. The isolation test at network level was done by using various control and management protocols to identify whether the isolated virtual machines can accidentally connect to each another. Isolation of virtual machines was also proven by ping tests. The results from these tests were affirmative, as the virtual machines on different slices were not visible to one another. In conclusion, information was obtained about how the FEDERICA substrate nodes should be configured to assure the isolation feature between slices that share physical resources. Following these defined procedures in FEDERICA, the isolation between slices is completely ensured. KTH Royal Institute of Technology, Sweden, requested a slice, called METER, in order to study another important feature of FEDERICA: the repeatability of its experiments. This user project dealt with problems related to repeated experiments on a shared network, where other external activities may influence the set of results. KTH investigated a method to identify time periods of comparable network conditions based on metadata-contextual information about the environment where the experiment was executed. performance metrics such as oneway delay, one-way delay variation, and packet loss [9]. The main purpose of the experiment was to collect and archive these IP performance metrics over an extended period of time and make the data available to other FEDERICA project partners and experiments that needed reference data as part of their investigations on the behavior of virtualized networks and slice processing. The data was also used to show that FEDERICA users had a stable network environment and repeatable conditions for their experiments. Evaluation of multi-layer network architectures This group of experiments illustrates the capability of connecting external test beds or virtual slices provided During the timeframe of an experiment, active background measurements were run to collect metadata parameters. Experiment data was timestamped and KTH used statistical analysis on the metadata to determine if experiment data was gathered during comparable network conditions. An important goal was to be able to do this without interrogating the experiment data itself. Within Figure 4: ISOLDA: Network performance and slice isolation tests. the slice, service degradation in terms of resource competition with experimental activities in other slices was rarely by other facilities to the FEDERICA user slice. In this detected. An important part of the experimental work way, multi-layer and multi-domain network architectures was to detect differences in network conditions e.g., and federation principles can be evaluated. in terms of latency. A set of background comparable Trinity College Dublin (TCD), Ireland, requested network conditions. Based on the measurement results, a slice, called OIS, in order to carry out experiments it was possible to reduce the confidence intervals of the on the Optical IP Switching (OIS) concept, a network outcome of the repeated experiment, so the remaining architecture [10] that was developed by the CTVR values were suitable for comparison. Telecommunications Research Centre based at the The Friedrich-Alexander University of Erlangen- University of Dublin. The idea behind OIS is to build a Nuremberg (FAU), Germany, in cooperation with packet router that can analyze traffic flows and use an FEDERICA partner Deutsche Forschungsnetz (DFN), underlying optical cross-connect to bypass the router requested a slice in order to perform Hades Active Delay electronics for suitable 1P flows. The FEDERICA slice Evaluation System (HADES) measurements over the was used to analyze how dynamic creation, modification physical infrastructure of FEDERICA. The nodes of the or cancellation of optical paths can degrade the quality of FEDERICA substrate were measured in a full mesh applications transported over TCP protocols, on a largescale testbed implementation. The results presented topology; with bidirectional measurements, this yielded 42 measured links. substantial differences to those previously obtained HADES was developed and deployed as a tool that through laboratory-based experiments. provides performance measurements and offers IP 34 35

20 The OIS network architecture was setup in TCD s to proceed, using real-size platforms, real operating laboratory as a core network and interconnected with systems, and real applications in a realistic environment, vanilla IP domains, which were realized within the FED- which is similar to the actual target system. ERICA slice. In the experiment the FEDERICA slice The Universidad Autónoma de Madrid (UAM), was organized in such a way that emulated a simple in Spain also requested a FEDERICA slice, called access network, where user data were aggregated by ANFORA, in order to interconnect that with two other an IP router and sent toward the TCD testbed. Here infrastructures. This complex networking experiment packets were routed back to FEDERICA towards the used resources of three facilities: FEDERICA, OneLab, destination network. TCD could then verify how their and PASITO. Beside the FEDERICA slice, UAM already testbed would work when connected to external legacy had OneLab nodes with specific monitoring cards in IP networks. The results showed, for example, that order to perform quality of service measurement and UDP and TCP transmissions are impaired when the was also connected to PASITO, the Spanish national signals are dynamically switched from an electronic to layer 2 networking facility [12], to provide lower-layer an optical connection if both upstream and downstream connections at the FEDERICA points of presence. The links are congested. The experiment also gave TCD the multilayer test facility that was created (Figure 5) was opportunity to evaluate feasibility and efforts required used to evaluate the Path Computation Element (PCE) to use virtualized networks in combination with physical protocol, and to validate multilayer traffic engineering testbeds. (MTE) algorithms. The Telecommunications Software & Systems The FEDERICA slice allowed the creation of a virtual Group (TSSG), based in Waterford, Ireland, was one network topology, which played the role of an IP service of the 10 partners of the European Commission funded provider s backbone network. OneLab measurement project PERIMETER [11] which is finished in May tools, implemented on top of FEDERICA virtual nodes, The project addressed challenges such as quality of ensured precise monitoring of traffic engineering (TE) experience (QoE), security, and end user impact in order parameters, like bandwidth or delay. The end-toend to establish a new paradigm for seamless mobility. TSSG monitoring information was sent to the PCE database so, requested a FEDERICA slice (incorporating five virtual PCE nodes knew the actual performance of each layer. nodes and routers) to extend the existing physical test During the experiment, end-user traffic was routed bed and carry out more robust testing of the PERIMusing the IP layer (i.e., FEDERICA slice) by default, while ETER application particularly in the areas of routing, the network performance was adequate. However, when scalability, and authentication. This was a relatively inexpensive way to dynamically pool and use resources for there was IP congestion, the lower layer connections of PASITO infrastructure were used to provide the desired experimentation of new networking concepts. The federated PERIMETER testbed and FEDERICA slice were used to conduct a number of testing processes including scenario conformance tests, interoperability tests, application tests, Living Labs tests, and performance and scalability tests in the project. These testing processes could not be performed while achieving such a level of realism without the use of FEDERICA. In conclusion, it was validated that the federation of a physical test bed and a virtual slice allows experimental testing Figure 5: ANFORA: investigation of federation and multilayer network scenarios. Figure 6: PHOSPHORUS: Harmony network resource brokering system scalability study. quality of service for the end users. PCE computed the end-to-end routes and decided on which network layer the traffic should be transmitted. As a result of the experiment it was concluded that, PCE is suitable for multilayer algorithms since their computation is more complex than traditional routing algorithms. Moreover, the PCE database was filled with information of both layers providing a global view of the network to the operator. The interconnection of FEDERICA, OneLab, and PASITO provided a unique test environment in order to successfully validate various MTE algorithms. Design of novel data and control plane protocols This group of experiments aims at designing and validating novel data and control plane protocols as well as architectures. The Politecnico di Torino (PoliTo), Italy, requested a slice, called VMSR, in order to experiment with the Virtual Multistage Software Router (VMSR) distributed architecture. Distributed routers are logical devices whose functionalities are distributed on multiple internal elements, running on virtual machines, in order to achieve larger aggregated throughput and improved reliability. The VMSR multistage router architecture [13] was composed by three internal stages: layer-2 load balancers, Ethernet switches to interconnect components, and standard Linux based software routers. In order to coordinate the internal elements and to allow VMSR to behave externally as a single router, custom-made control and management protocols were designed by PoliTo. The VMSR experiment in FEDERICA consisted of three L2 balancers (Linux virtual machines running Click on Ethernet Virtual Switch), one Ethernet switch, three L3 routers (i.e., standard PCs running the Linux protocol stack and XORP), and three external nodes that generate and sink traffic. The main advantage of implementing the VMSR experiment in FEDERICA was related to the ability of controlling and monitoring network resources allocation inside the architecture, which would not be possible in a testbed (e.g., on top of the public Internet). Functional tests on the control and management plane protocols were successfully performed. PoliTo measured throughput and latencies on all the involved links while varying the packet size of traffic generators to determine the suitability of the infrastructure supporting highperformance applications