Das hier auch neue Netzwerktrends eine Rolle spielen, erklärt Mark Cohn, Senior Director, Market Development bei Ciena und verweist auf die SDN-Arbeiten der Open Networking Foundation, die definiert, welche Netzwerkaktivitäten auf der Control-Plane und welche auf der Management-Plane stattfinden. „Wir benötigen ein gemeinsames Verständnis und haben demzufolge auch während der vergangenen eineinhalb Jahre mit der ONF und dem MEF diskutiert um herauszufinden, was der übergreifende Ansatz für das architektonische Rahmenwerk ist, in dem wir zukünftig arbeiten.“
Cohn führt weiter aus: „Bis zu einem gewissen Grad ist eine Überlappung der Arbeiten unvermeidlich und auch akzeptabel. Aber wir müssen diese Überlappung minimieren und die verschiedenen Organisationen müssen entscheiden, wie die Teile an denen sie arbeiten, zusammengeführt werden können. Je höher wir uns auf dem Orchestrierungslayer befinden, desto geringer werden die Überschneidungen sein, weil sich die ONF nicht damit
beschäftigt.“
Gint Atkinson, VP Network Architecture bei KVH, folgt diesem Punkt und erweitert die Fragestellung: “Versteht die Orches-trierung die Unterschiede zwischen den verschiedenen Service-Implementierungen? Sollte die Orchestrierungslösung sehen, ob die Services durch die Management-Plane konfiguriert wurden oder durch einen SDN-Controller oder die Control-Plane? Ich denke, Orchestrierung sollte sich von dieser Detailebene lösen. Wir benötigen definitiv eine Abstraktionsebene. Schwieriger noch ist die Frage, was Orchestrierung im Detail über zwei Services oder Komponenten wissen muss, um sie in einer Service-Chain oder einem neuen Service-Paket zusammenzuführen.
Sicher wollen wir nicht, dass die Orches-trierung mehr benötigt als die notwendigen Interfaces um einen Request durchzuführen. Sie sollte nicht in Management-Interfaces oder Control-Plane-Interfaces eingreifen.“
Vinay Saxena, Chief Architect von HP nimmt diesen Punkt auf: „Was ist allerdings ein Service? Wenn wir einen Service von einer hohen Ebene aus betrachten, dann ist er aus Sicht des Konsumenten abstrakt, trotzdem gibt es Ressourcen als Service, die etwa auch Recovery oder Restaurierung bedeuten. Also müssen wir die Services selbst sorgfältig betrachten und definieren, was sie tatsächlich sind. Heute gibt es Leute, die diese Terminologie nutzen und behaupten, dass es sich um monolithische Boxen handelt, die einfach alles können.“
Vier-Schichten-Modell
Nan Chen vom MEF stimmt dem zu: „Wir wollten die Branche dahingehend zusammenführen, unterschiedliche Layer zu betrachten. Möglicherweise gibt es ein Vier-Schichten-Modell bei dem die Infrastruktur die untere Schicht bildet. Darauf aufbauend würde sich dann die Control-Management-Ebene befinden. Daran schließt sich das Service-Management an, das tatsächliche Services liefert. Das ist überaus umfassend, weil es Connectivity-Services, Computing-Services und Infrastruktur-Services einschließt. Und schließlich befindet sich oberhalb das Business-Management, das alle Anwendungen und dergleichen umfasst.“
Für James Armstrong, Executive Vice President bei Spirent Communications, geht es in praktischer Hinsicht auch um Implementierung und Kontrolle: „Wir arbeiten hier am Interface. Das Interface verändert sich von einer Art Management-Mindset in Richtung auf eine API. Das bedeutet im Hinblick auf die Schwachstellen, dass wir sicher nicht mehr die unterschiedlichen Variablen fixieren müssen, mit denen wir uns heute beschäftigen. Die können vielfältig sein und sollten die API nicht mehr ändern, wenn wir ein brandneues programmierbares Netzwerk haben. Das Netzwerk wird breite Funktionen auf einer höheren Ebene zur Verfügung stellen. Stehen diese einmal für Anwendungen bereit, dann müssen keine Einschränkungen mehr für den Betrieb gemacht werden.“
„Die größte Herausforderung hierbei“, ergänzt Chris Purdy, „sind die Entwicklungskosten. Wenn es zu viele Variablen gibt, dann muss zu viel für den Support dieser Variablen ausgegeben werden. Hinzu kommt die steigende Komplexität falls etwas nicht läuft. Flexibilität bedeutet im Umkehrschluss auch Komplexität, die schwer zu beherrschen ist. Der Schlüssel ist wie gesagt die Anzahl der unterschiedlichen Variablen. Einige davon sind notwendig, um die Services zu differenzieren, etwa im Hinblick auf die Art der Absicherung, die Definition des Delays oder anderer Charakteristika des Angebotes. Andere Variablen wie etwa der Ethernet-Typ unterscheiden das Angebot nicht. Als Branche müssen wir diese Variablen standardisieren, sonst entstehen nur Kosten für Funktionen, die nicht benötigt werden.“