Service Platform view and Layered Service Architectures
Service Platform view and Layered Service Architectures
Services and their lifecycles
The provision of services of a growing sophistication and functionality usually requires a similar degree of complexity in the internals of those services. Likewise, the new constructs for the new wave of SW-defined networks that are intended to bring significant new functionalities and flexibility, and also come with an internal machinery that is far from being trivial, and a proper division of that intrinsic complexity is required in order to handle it in an efficient manner.
One of the most obvious examples of such a duality between functionality and inner complexity is the case of a Network Slice, one of the key concepts that come with 5G networks. Unsurprisingly, the complexity of a network slice is high, but the good news is that it is designed in a manner that favors a manageable split into nested components, which, in turn, can be subdivided (and, hence, managed) into simpler elements. Thus, a slice can be split in a set of Network Services, and such Network Services can be split, in turn, into a set of virtual machines, virtual networks, physical nodes and, potentially, transport connections.
Walking the same path but in reverse order —from the simplest components to the more sophisticate ones— is the key for a successful management of these environments. As usually happens in other fields in engineering, this complexity is intended to be more effectively handled in a layered fashion, based on stacked service platforms. Thus, service layers can be stacked to create composite services of growing complexity, up to building service objects of the required level of complexity in each case.
In order to make effective the handling of this variety of “service objects”, they are intended to be created and controlled on demand. The creation process of each of these “service objects”, along as the rest of the rest of their lifecycle, should be provided “as a service” by a platform specialized on providing a given type “service object”. Thus all the “service object” of a given type can be controlled and monitored via the invocation of a well-known API from a well-known platform, which is responsible of that “service object” lifecycle.
Moreover, since these platforms can be layered and invoke the APIs of lower level platforms, platforms in upper layers can easily create and offer “as a service” complex composite objects in a manner that scales in terms of operation in a simple and traceable manner, as depicted in the following figure:
Examples of these kinds of platforms are an NFV Infrastructure (NFVI+VIM, providing VMs and virtual networks), a SW-Defined Network (e.g. an SDTN, providing long-distance connections), or a Network Service Platform (providing Network Services on demand composed of the other types of elements).
A key aspect of this type of architectures is that a given platform is not intended to provide “service objects” exclusively to a single “upper” platform, but it can provide those “service objects” to whichever platforms might request it via its API, bringing to the end to end architecture much higher flexibility. That versatility will be intensively leveraged in the following sections.
Types of functions in a service platform
Two types of functions can be identified in a service platform: one (and only one) manager function and, optionally, some managed functions.
In order to set up a platform, at least, it is required the capability of consuming the APIs from other platforms available southbound, the ability to build a new type of “service object” and handle its lifecycle, and the capability of exposing on demand the new “service objects” via an appropriate API northbound. Those capabilities are concentrated in the so-called “Management Function” of the platform, which owns the lifecycle of the offered “service objects”, becoming the heart of the platform itself.
However, we may wonder, what happens at the bottom layer of the stack? At the lowest level, platforms do not have service platforms underneath to create services out of them, so they are required to create their own service using the most basic set of available functions (e.g. compute nodes, switches, storage backends, etc.). These other functions are not intended to offer “service objects” on demand, but to offer a standalone functionality, which can be part of a pool and be dynamically configured and monitored by the manager functions. Those final functions (or pools of them) can be referred as managed functions. The relation between both types of functions to build a platform placed at the bottom of the stack, is depicted in the following figure:
In general, it is perfectly normal seeing both types of southbound interactions in many platforms, combining the consumption of some basic services with the control of a number of managed functions which belong to the platform itself, as depicted in the following picture:
In must be noted, however, that a managed function is not supposed to belong to more than one platform at the same time, so that conflicts of being controlled by more than one manager can be avoided.
Service Platform view vs. Platform Operation view
At this point of the discussion, we need to distinguish two complementary views that coexist in these architectures and that can be considered at the same time.
On the one hand, there is the “Service Platform view”, thoroughly described above, focused on the core functionalities that the architecture intends to offer. In all cases, the working assumption is the existence of potentially frequent and dynamic requests related to those “service objects” that create the main functionality, and which can benefit of large economies of scale in terms of efficient operation given their large number and large dynamicity. These are intended to be highly automated and coordinated, due to the recurrent benefits, and the fact that they tend to create a myriad of new (virtual) components with their own lifecycle, really hard to control without a proper automation and coordination structure. Some of the most prominent examples of this kind are the dynamic provision of Network Services or Network Slices, which often imply a large cascade of dynamic operations across the different layers of the stack that can be triggered on demand that which define a potentially complex composite lifecycle.
On the other hand, we cannot forget that the functions (manager function and managed functions) that compose the service platforms are also elements that need to be installed and bootstrapped, and may be configured, updated and supervised, having potentially their own lifecycle. These O&M actions over these elements (which constitute the “Platform Operation view”) are intended to be sporadic and rather static, aiming to set boundary conditions for the “As a Service” aspect of the service platform (e.g. create a new VIM tenant and assign a quota). Usually, the gains associated to automation here are of lower scale, due to the lower recurrence, and may be selectively eased by process-oriented wizards and dashboards.
In the case of the manager functions, both views coexist naturally in practice, with both paths running orthogonally and separated by their purpose (either explicitly or implicitly by profiles), being these O&M tasks a sort of “management of the manager” of a service platform. In practice, the lifecycle of the manager may be synonym of the lifecycle of the service platform as a whole.
In the case of managed functions, these O&M interfaces (when required) sometimes are also accessed by the manager function (that performs configurations and monitors the element) and avoid conflicts by the split in the type of actions.
Some tools to ease the O&M of the set of functions that constitute the architecture are often provided by the different commercial products present in the architecture, and can be grouped under an umbrella of common O&M tooling, so that they can benefit of supplementary common services (e.g. DNS, LDAP, CA, etc.), common backends (e.g. to collect monitoring info), or even wrap sequences of sparse O&M actions in a GUI wizard tools in order to ease them, either by making them more visual or by guiding the operator to minimize errors (e.g. by narrowing down the available options).