Did you know? Did you know? Telecom networks should focus on multi-layer orchestration

A few years ago, the word “orchestration” was hardly used by telecom operators and was mainly used in the music industry. Today, there are different opinions on what “orchestration” means; it is often used interchangeably with management, controller, etc… When ETSI [1] NFV Orchestrator introduced NFV (Network Function Virtualization) to the communications industry, NFV Orchestrator was a new functional block that attracted a lot of attention. Since then, many orchestration solutions have been specified and implemented by different forums, specification bodies, communications service providers and product vendors. Over time, it has been further realized that having only one orchestrator is not enough and efficiency cannot keep up, and multiple layers (at least two) of orchestration are needed. For example, Open Source MANO (OSM) [2] defines 2 layers of business processes, namely Service Orchestrator (SO) and Resource Orchestrator (RO). Similarly, Open Network Automation Platform (ONAP) [3] defines at least 2 layers of business processes, namely Service Orchestrator (SO) and Virtual Function Controller (VF-C), the latter of which is aligned with the ETSI NFV-Orchestrator function.

[[260591]]

Defining the Orchestration

The functions of orchestration include coordination and management. While the coordination part is mandatory, the management function is optional. The coordinator does not have absolute authority over the components or entities it needs to work with, while the manager has full authority over the entities involved. The manager can make all aspects of the life cycle of the subject components on its own. The manager itself may be controlled by a higher-level management entity, but the downward management entity enjoys exclusive absolute authority over the components it manages. On the other hand, the coordinator must cooperate with the entities. Before issuing a command, the coordinator does not know whether the command will be successfully executed. Therefore, a coordinator in the true sense issues requests rather than sending commands, and readjusts its operations based on the response to achieve the desired goal. The coordinator must work within these limitations to achieve its goals. Another term, often used in SDN, is controller. This basically controls a certain behavior or aspect of the subject entity. Although it does not have absolute authority over the life cycle of the component, it can exercise control over specific behaviors and sometimes share this authority with other controllers. The result of coordination may result in the creation of a temporary element (such as a network service), and the coordinator can manage the life cycle of this new element.

Orchestration in ETSI NFV MANO

In the case of NFV MANO architecture, the NFV orchestrator (NFVO) coordinates with the Virtual Network Function Manager (VNFM) and Virtual Infrastructure Manager (VIM). The latter two manage virtual network functions (VNF) and virtual infrastructure (VI) respectively, and NFVO coordinates with these two managers to create a new transition entity: Network Service (NS). NFVO acts as a manager, and NFVO manages the life cycle of NS using requests to VNFM(s) and VIMs. In most architectures, we see NFVO working together with the service orchestrator.

Multi-layer orchestration

In a layered business process solution, the orchestrator of a given layer needs to use a higher-level coordinator instead of a manager. Because the higher-level manager will expect command-confirmation behavior instead of best-effort request-response behavior. The lower-level orchestrator cannot guarantee the requested operation of the higher-level entity. In a multi-layer business process architecture, the orchestrator at the top of the hierarchy is responsible for orchestrating multiple lower-level orchestrators or other management entities (such as VIM or VNFM).

There are many factors that influence how a particular layered business process solution is implemented. Some of these factors are:

• Geographic distribution and placement of entities that need to be orchestrated (e.g. distributed NFVI PoPs).
• Scalability constraints of the orchestrator.
• Business and operational requirements for service providers deploying business process solutions.
• The different network domains and the abstractions that each entity in these domains (e.g., VNF, SDN Controller, VNFM, etc.) provides to the orchestration layer through its interfaces.
• Different abstraction layers (e.g. resources, services, customers, and products)

The following diagram illustrates the hierarchical layers of the orchestrator; each layer of business processes handles a different level of abstraction, and some layers are structured based on geographic regions and network domains. There are of course many other combinations in which layered orchestrators can be constructed, and the following is one possible scenario.

Coordination interface between layered orchestrators

The interface construction between multi-layer orchestrators is completely different from traditional management systems. Typically, the interface between management systems is command/operation oriented, i.e., a higher-level management system issues a command or triggers an operation on a lower-level management system, and the command/operation is successful or reports an error. A multi-orchestrator environment requires different interface design approaches between orchestrators at different levels.

Some key common features of the interfaces between multiple orchestrators (besides the interface reflecting the coordinator functionality):

(1) Intent-based interface VS command/operation-based:

The higher-level coordinator expresses its intent to the lower-level coordinators, and the lower-level coordinators in turn decide how to achieve that intent by orchestrating the various entities within their scope.

(2) Conversational style of interface vs. request/response paradigm

Orchestrators exchange conversations rather than request/responses, for example, a service orchestrator might request a WAN orchestrator to create a network service in a specific geographic area with a specific QoS, and the WAN orchestrator analyzes the request based on information gathered from management systems, analytics feeds, and VIMs, and returns viable alternatives (assuming the original QoS requirements cannot be fully met, etc.). The service orchestrator can then select one of the alternatives, or decide to change the original request to consider the suggested alternatives. This conversational style enables the orchestrator to act at different levels of abstraction, mitigate potential deadlocks, and ensure appropriate reservation of network resources to efficiently achieve the original intent.

(3) Best Effort vs. Guaranteed Action Semantics

Unlike traditional management systems, orchestrators, by definition, are oriented toward best-effort based semantics. For example, if a service orchestrator expresses an intent to instantiate a set of VNFs to an NFV orchestrator, the NFV orchestrator might choose a slightly different combination or configuration of VNFs to achieve the intent based on the real-time information it has on aspects such as NFVI resource availability. This intent-based best-effort semantics means that the approach taken to achieve end-to-end system reliability must be different from that of traditional management systems. One possible approach is to leverage the coordination and management capabilities of the orchestrator.

Multi-layer orchestration - key benefits

Unlike management systems, orchestrators are primarily responsible for sharing control, handling conflicts, and ensuring that the primary intent (which includes various QoS features required for operational efficiency and effectiveness) is achieved on a best-effort basis. Only by adopting a collaborative approach with multi-layered coordination can the true benefits of NFV and SDN be realized in telecom networks.

in conclusion

Telecom networks are complex and need to be managed from multiple perspectives. Orchestration architectures allow operators to loosely couple monitoring and control of the network from different perspectives while ensuring consistent behavior across the system. A coordinated approach, rather than a master-slave approach, ensures that both low-level and high-level goals are dynamically balanced. In a multi-layer orchestration architecture, care should be taken to ensure that the coordination approach is preserved across layers and that the intent of the organization is dynamically communicated in the management system.

refer to

• ETSI GS NFV-MAN 001 V1.1.1 (2014-12) : Network Functions Virtualisation (NFV); Management and Orchestration: https://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf
• Open Source MANO: OSM Release FOUR Technical Overview May 2018: https://www.kernel.org/doc/Documentation/networking/vrf.txt
• Introducing the ONAP Architecture (Amsterdam Release): https://onap.readthedocs.io/en/amsterdam/guides/onap-developer/architecture/onap-architecture.html

Original link:

https://sdn.ieee.org/newsletter/november-2018/architecting-multi-layer-orchestration-for-telco-networks