Pillar: No-Code OSS
Management and Orchestration Challenges in Network Function Virtualization
Orchestrating networking resources tend to have a recursive nature at different levels of the hierarchy. But one question remains, would network abstraction and programmatic interface at a combined compute support the constraint-based and…
Orchestrating networking resources tend to have a recursive nature at different levels of the hierarchy. But one question remains, would network abstraction and programmatic interface at a combined compute support the constraint-based and recursive resource allocation? Here is a summary of the orchestration and management challenges arising in network function virtualization.
Security in the Cloud
The NFV and SDN are at risk of attacks because they focus on remote programmability of network functions and their resource. The impact of a successful threat is likely to have more ramifications on the cloud than in the non-NFV environment according to a recent draft report from the ETSI NFV security group.
CloudBand features an in-depth security solution on how you could detect and isolate threats while predicting anomalies. Planet Orchestrate, on the other hand, recommends the integration of another product to complement security support. Although network function virtualization products lack substantial security support, the cloud remains a viable option for solutions.
Elastic VNF
In many cases where VNF is used, it may not be designed for scaling up or down; doing so will require you to restart the VNF, and you may end up losing the state data. In most cases, a VNF is only capable of scaling in/out only.
VNF is designed to run on top of a small VM. It is grouped as a pool of one VNF function. Scaling VNF can cross multiply NFVI PoPs (data center). At cross- DC scaling, new VHF instance can be placed at a remote cloud location. VNF makes part of the VNF forwarding graph (VNF FG). This means that data traffic can pass through different stateless and stateful VNF functions in sequence.
In instances where a particular service function chain is scaled/placed out in a distant cloud execution, the service function has to go through different VNF instances located in multiple physical locations. Worst case, the data traffic can Ping-Pong different physical location. This means that you will have to take into account the service function chain when scaling and placing one of its VHF instances.
Interoperability and Interfacing
Network function virtualization is designed to break the bond existing between TSPs and equipment vendors plus the service they provide. One of the requirements for this is the support for operability. Measures have been taken in defining constituent (intra-operator) interface and the NFV MANO framework. Still, there is a lot that should be done when defining interfaces designed at supporting interoperability between different vendors.
Interoperability problems pose challenges in different projects and solutions. For instance, projects that are based on the ESTI MANO framework take advantage of custom model or representation for services and functions. This means that if clear interfaces aren’t defined, it’s nearly impossible to combine functions of different operators on one service.
ESTI proposes network service descriptors and VNF as templates for defining services and functions. However, there is no definite data model that can realize the descriptors.
Intelligence and Programmability
Network function virtualization envisions the maintenance and deployment of complex services on its heterogeneous physical resource, there is a need to develop rich sets of programmable interfaces. This way, it extends the current functions of SDN beyond controlling simple connectivity resources.
Equally, there has to be a different abstraction that applies to storage and computation resources. This way, it’s not only easier for network functions to be instantiated across different vendor technologies, but you can dynamically (re)program interfaces that allow the configuration of the network functions and control.
A MANO system is designed to be smart enough so that re-configuration operations can easily be automated, especially those reacting on run-time events. While ETSI can efficiently complete this, the proposed MANO framework lacks standards and details on how it can be implemented for interfaces as well as managers.
That is why most pre-standardized solutions are based on proprietary solutions that can lead to interoperability issues. Contact us for more info on our solutions.