Startseite > Datacenter & Verkabelung > Third-Network - und nun?

Lifecycle-Service-Orchestration

Third-Network - und nun?

27. Mai 2015, 16:45 Uhr | Uwe Scholz, freier Journalist aus Berlin

Fortsetzung des Artikels von Teil 1

Cloud-Services

Als zweite Zielgruppe für das Third-Network hat das MEF die Cloud-Anwender definiert. Hier geht es um die orchestrierte Bereitstellung von Cloud-Anwendungen durch bedarfsgerechte, Performance-gesicherte und sichere MEF-Services. In einem beispielhaften Szenario nutzt ein Unternehmensanwender NaaS on-demand zur Verbindung der virtuellen Maschinen (VMs) oder virtueller Network-Functions (VNFs) in einem remote Datacenter. Zwei Netzwerkbetreiber sind an der Bereitstellung des Services beteiligt – der WAN-Service-Provider sowie Datacenter-Netzprovider. Jeder dieser Provider nutzt in diesem Szenario Standard-MEF-APIs zur Orches-trierung seiner jeweiligen virtuellen Verbindungen und Service-Endpunkte. Die Inter-Operator-Kommunikation wird ebenso über MEF-APIs abgewickelt, um sicherzustellen, dass ein NaaS Ende-zu-Ende für den Teilnehmer aufgesetzt wird. Die Inter-Operator-Orchestrierung ist notwendig, um die Service-Bestellung, die Bereitstellung und das Management der virtuellen Verbindungen über verschiedene Betreibernetze hinweg zu automatisieren.

Und schließlich können auch Individuen vom Third-Network as a Service profitieren, nämlich bei der On-Demand-Nutzung von garantierter und sicherer Performance mit Pay-as-You-Go-Services zu Hause, im Hotel oder anderswo mit kabelgebundenen oder mobilen Medien. Bei der remoten Verbindung zum Büro aus dem Hotel oder von zu Hause nutzt der Teilnehmer typischerweise ein IP-VPN über das Internet. Die Performance variiert dabei bedingt durch die Zahl der Anwender, die sich die Verbindung teilen, die Bandbreite zwischen dem Hotel und dem ISP und den Netzwerkbelastungen im Internet.

Mit dem Third-Network kann der Anwender über ein Web-Portal eine temporäre Highperformance-Verbindung bestellen. Diese Funktion wird durch die Kommunikation zwischen dem ISP und anderen Netzwerkbetreibern via Standard-MEF-APIs erreicht. Das Third-Network stellt eine Service-Differenzierung für ISPs basierend auf entsprechenden Technologien bereit. Einige Methoden hierfür sind etwa eine Erhöhung der VPN-Traffic-Bandbreite, die Priorisierung des VPN-Traffics gegenüber anderem Datenverkehr, die Weiterleitung des Traffics über Routen mit geringerer Latenz oder die Umgehung des Internets über private IP/MPLS-Netze.

Neue Aufgaben

Die Arbeit des MEF konzentriert sich auf den Service-Layer und damit verbundene Funktionen über Multi-Operator-Netze. Dazu hat das MEF bereits 2013 ein Service Operations Committee gegründet. Vor dem Hintergrund der Realisierung des Third-Network umfasst die MEF-Strategie die komplette Lifecycle-Service-Orchestrierung für existierende SDN- und NFV-Netzwerk-Implementierungen. Dies wird erreicht durch ein erweitertes Informationsmodell für die Service-, Ressourcen- und Technologie-Abstraktion, erweiterte Service-Definitionen für zusätzliche Nutzungskontrolle und Service-Differenzierung sowie APIs für Anwendungen wie OSS, BSS und Self-Service-Web-Portale für die Kontrolle der Netzwerk-Ressourcen.

Das MEF wird das umfassende Ethernet-Service Informationsmodell generalisieren, um Network-as-a-Service zu unterstützen. Dies schließt verschiedene Bereiche ein, etwa ein protokollunabhängiges Datenschema, physikalische und virtuelle Service-Endpunkte und Support für Service-OAM zwischen ihnen, dynamische Service-Attribute für Service-Endpunkte und virtuelle Verbindungen, Abstraktion von der zugrundeliegenden Transport-Technologie sowie Flexibilität bei herstellerspezifischen und betreiberspezifischen Erweiterungen.

Ein weiterer Schritt ist die Definition des Network-as-a-Service mit dem Ziel, Variationen der Service-Definitionen zu eliminieren, die die Komplexität erhöhen. Zum Beispiel sollte ein Multipoint-NaaS ein einheitliches Set generalisierter Service-Attribute unabhängig von der Technologie bieten, wie etwa Backbone-Bridging, MPLS VPLS oder IP.

Kooperation mit Standardisierungsgremien

Ein Schlüssel zur Realisierung des Third-Network ist die Definition der kompletten Lifecycle-Service-Orchestrierung einschließlich Service-Definition, Vertrag, Umfang, Angebot, Bestellung, Bereitstellung, Garantie, Reporting, Modifikationen und Trennung. Diese Arbeit hat bereits im MEF Service Operations Committee begonnen und wird basierend auf echten Betreiberprozessen und einschließlich Cloud-zentrierter Service-Lifecycle-Modelle fortgeführt.

Das Ziel der MEF-APIs ist die Funktionsfähigkeit in heterogenen Umgebungen aus Netzwerk-Technologien, Architekturen und Implementierungen. Dieser Ansatz beinhaltet die Unterstützung gegenwärtiger WAN-Implementierungen basierend auf physikalischen Netzwerkfunktionen (PNF) und der Evolution in Richtung auf virtuelle Netzwerk-Funktionen (VNF), Software-Defined-Networks (SDN) und Datacenter-Networks (physikalisch oder virtuell). Die MEF-APIs ermöglichen Service-Lifecycle-Orchestration innerhalb der internen Netzwerkdomains des Betreibers sowie zwischen den Betreiberdomains zur Automation des Service-Lifecycles eines durchgehenden Network-as-a-Service.

Die vom MEF erarbeiteten Zertifizierungen von Equipment, Services und Professionals waren für den Erfolg von Carrier-Ethernet ausschlaggebend. Das MEF wird auch hier das Programm erweitern, um die Konformität zu MEF-APIs und Service-Definitionen zu garantieren.

Es ist offensichtlich, dass die Realisierung des umfassenden Projektes nicht ohne eine weitreichende Kooperation mit anderen Standardisierungsgremien (SDOs) zu erreichen ist. Das MEF hat bereits eine langjährige Erfahrung bei der Einarbeitung von Standards in die MEF-Spezifikationen und bei der Zusammenarbeit mit anderen SDOs zur Vermeidung von Doppelaktivitäten und zur Beschleunigung der Akzeptanz. Um diesen kollaborativen Ansatz zu unterstützen, wurde das „MEF UNITE-Programm“ aufgesetzt. Damit sollen andere Schlüsselorganisationen sowie die Open-Source-Community einbezogen werden, um die Vision des Third-Network zu realisieren.