Was ist Service Chaining und wie passt VNF-Onboarding dazu?

Herausforderungen beim VNF-Onboarding

VNFs in einer Service Chain zeigen die Probleme beim Onboarding der physischen Funktionen der Featuresoftware, damit sie in einer NFV-Umgebung laufen kann. In vielen Fällen wünschen Nutzer die Möglichkeit, ihre VNF-Funktionen von den Anbietern zu erhalten, die ihnen bekannt sind. Das bedeutet, Anbieter müssen die Software, die für die Ausführung auf Premises-Geräten entwickelt wurde, in etwas transformieren, das sich auf allgemeiner Hardware hosten lässt.

Diese Hardware könnte ein uCPE-Gerät (Universal CPE) sein, das sich immer noch vor Ort (On-Premises) befindet, oder es könnte sich um einen Teil eines Cloud-Ressourcen-Pools handeln. Es ist die Kombination verschiedener Probleme, die für Herausforderungen beim Onboarding von Service Chains sorgt.

Physische Geräte werden miteinander verbunden – und die Service Chain muss diesen Prozess nachbilden. Das heißt, jede der Software-VNFs muss zwei Schnittstellen zur Verfügung stellen, die sich mit dem Rest der Chain verbinden lassen. Dabei bildet der Nutzer ein Ende der Chain, die Grenze des Netzwerkservices das andere.

Die für das Onboarding in eine Service Chain ausgewählten VNFs müssen eine kompatible Konnektivität unterstützen. Darüber hinaus müssen sich die von ihnen genutzten Schnittstellen für eine Netzwerkverbindung eignen, wenn die Service Chain bereitgestellt wird.

Zusammenfassen der VNFs in Service Chains

In einem lokalen Netzwerk wird Software üblicherweise in einem IP-Subnetz bereitgestellt. Das ermöglicht eine offene Konnektivität unter den Softwarekomponenten. Es ist aber nicht identisch mit dem Verbinden von Geräten untereinander, weil die normalen Softwarekomponenten sich gegenseitig über eine URL identifizieren würden. Somit müsste ein Netzwerkteam die Service-Chain-Komponenten parametrisieren, um die URL ihrer benachbarten Chain-Mitglieder zu kennen.

Mit einem Tunneling-Protokoll zwischen VNFs in der Chain kann das Netzwerk die Reihenfolge der Verbindung bestimmen. Änderungen an den VNFs entfallen dadurch. Gleiches gilt, wenn die Verbindung der VNFs explizit per Software-defined Network (SDN) gesteuert werden. Beide Ansätze können fehlschlagen, wenn die VNFs in uCPE gehostet werden, denn dann befinden sich alle Verbindungen innerhalb eines Gerätes. Dementsprechend erfordert ein uCPE-Bereitstellung beim Onboarding spezielle Aufmerksamkeit, was die Verbindungen betrifft.

Unternehmen müssen also für die Service Chain genaue Vorstellungen hinsichtlich Netzwerk und Hosting haben, um das Onboarding der VNFs durchführen und dann die Chain in einem Service bereitstellen zu können.

Drei Anforderungen für das VNF-Onboarding

Networking in einer Service Chain ist nur eines der Onboarding-Probleme, die Unternehmen beachten müssen. NFV erfordert zwingend drei Kompatibilitäten in den VNFs selbst:

• Erstens muss die VNF-Parametrisierung in einem VNF-Deskriptor für jede VNF aufgezeichnet werden.
• Zweitens muss dem Task für die Verwaltung der virtuellen Funktion selbst ein VNF-Manager (VNFM) zugewiesen werden. Dies kann, sofern verfügbar, über einen allgemeinen VNFM erfolgen, einen VNF-spezifischen VNFM oder eine Kombination aus beidem. Ganz gleich, für welchen Mechanismus sich Unternehmen entscheiden, es ist wichtig, dass sie den VNFM explizit für die Verbindung während des Deployments festlegen.
• Schließlich müssen Unternehmen noch die Service Chain selbst modellieren, so dass Tools für NFV-Management und -Orchestrierung Services auf Basis der VNFs in der Chain bereitstellen können. Bevorzugtes Modell ist hierbei das TOSCA-Format (Topology and Orchestration Specification for Cloud Applications) von OASIS (Organization for the Advancement of Structured Information Standards).

Für Komplikationen bei diesen Schritten sorgt wiederum die Tatsache, dass Unternehmen Service Chains innerhalb von uCPE-Geräten oder in der Cloud bereitstellen können. Wo Geräte-Hosting beteiligt ist, ist es nicht nur möglich, sondern sehr wahrscheinlich, dass die formalen NFV-Spezifikationen sich nicht anwenden lassen. In diesem Fall können Unternehmen einen gerätespezifischen Mechanismus für das Hosting von Orchestrierungs- und Management-Funktionen nutzen.

In der Regel handelt es sich bei einer Service Chain um eine Sequenz von VNFs, die eine Chain von Premises-Equipment ersetzen sollen.

Der Onboarding-Ansatz muss zum Ziel passen. Wenn Unternehmen eine bestimmte Service Chain an mehreren Orten bereitstellen, benötigen sie für jede Option ein separates Servicemodell und einen eigenen Onboarding-Prozess. Das trifft auch zu, wenn Unternehmen Cloud-natives Management und Orchestrierung – zum Beispiel Kubernetes – nutzen, anstatt der von der European Telecommunications Standards Institute NFV Industry Specification Group (ETSI NFV ISG) genehmigten Verfahren.

Ist Service Chaining sinnvoll?

Selbst falls alle genannten Schritte sorgfältig in die Planung einbezogen werden, wirft Service Chaining für VNFs eine grundsätzliche Frage auf, die Nutzer kaum berücksichtigen. Ist eine Service Chain von mehreren VNFs überhaupt ein vernünftiges Konzept? Denken Sie dabei auch an Folgendes: Wenn Unternehmen zwei oder drei VNFs separat hosten und in eine Chain packen, ist das Ergebnis immer schwieriger zu verwalten, weniger zuverlässig und ressourcenintensiver, als wenn Teams die gleichen VNFs einfach zu einer einzigen VNF zusammenfassen und als Einheit bereitstellen würden.

Separat in einer Cloud gehostete und in einer Chain bereitgestellte VNFs besitzen mehr Komponenten, die ausfallen können, als die gleichen Features in Form einer einzelnen VNF. Selbst wenn die separaten VNFs in einem uCPE-Gerät gehostet werden, erhöht dies die Komplexität des Managements, weil Unternehmen alle VNFs einzeln verwalten müssen.

Betreiber sollten fragen, wie oft Kunden wohl die Konfiguration ihrer Services in einer Chain ändern werden. Wenn keine außergewöhnliche Dynamik erwartet wird, sollten sie die am häufigsten genutzten VNF-Kombinationen als einzelne Super-VNFs zusammenfassen, die sich als Einheit bereitstellen lassen.

Zu guter Letzt gilt es auch noch zu berücksichtigen, dass nicht alle VNFs so konzipiert sind, dass sie den Empfehlungen der ETSI NFV ISG entsprechen. Das gilt insbesondere für VNFs, die innerhalb von uCPE-Geräten bereitgestellt werden sollen. Bevor Sie sich zu intensiv mit Service Chaining und VNF-Onboarding beschäftigen, überprüfen Sie anhand der VNF-Quellen, für welche Management- und Orchestrierungs-Spezifikationen sie ausgelegt sind. Die VNF-Praktiken müssen sich den VNF-Realitäten anpassen.