This paper summarizes the ONF OIMT team’s position on ‘Network Slicing’.
The ONF OIMT team has concluded that the management representation should be consistent across networks, aggregated networks, partitioned networks etc. and that only one management/control representation is required to cover all these network views.
The key is to have a management representation based on fine grain functions that can be assembled into useful network concepts rather than coarse grain concepts that need to be ‘sliced’.
The ONF OIMT team has also concluded that since the concepts of virtual networks and / or network slices represent a subset of the resources of a network they are not fundamental concepts that need to be explicitly represented. A single definition can be used to represent the network, a virtual network or a network slice.
Hence, the resources that realize a network, a virtual network or a network slice can be represented using the generalized Network structure and functions together with Processing Functions, described below.
In the SDN architecture, the set of resources offered to a user (client) is grouped (by a constraint domain) in a client context of the SDN controller that is providing those resources. The client context scopes the management interface to those resources.
In general, the telecommunications network infra-structure should provide a user (client) with both resources and a management interface (for those resources). The client may use these resources to support a “slice”.
In general, a communication network provides the capability to selectively forward (transport) information between access points. The capacity (of the network) is shared amongst the users of the network. The shared capacity is formed by a recursion of elements of capability some of which aggregate capacity and some of which partition capacity (e.g., allocate some dedicated portion of the capacity to a particular user).
The choice of where to aggregate and where to partition is made based upon overall network engineering considerations in conjunction with consideration of user needs at each access point.
A control solution acts on the network to achieve the appropriate arrangement of forwarding capability etc. This control solution comprises many control systems operating in concert.
Distinct terminology has been applied to, and even within, every layer of networking where each standards organization has applied its own terminology in conflict with others. Likewise, every layer of control has distinct terminology with conflicts between terminology sets from the various standards organizations. This has led to rigid and closed solutions.
It has become apparent that the fundamentals as set out above do not require a distinct terminology for each application and further that each distinct terminology creates a barrier to efficient operation.
Recognizing this, the ONF OIMT is working to remove unnecessary distinctions in both the space of the communication network (from a control perspective) and the space of control itself. This is yielding models that are uniform at and across any network/control scale.
The OIMT model for networking is both technology neutral and recursive. The representation of a channel provided by Ethernet to IP is no different from the representation of a channel provided by photonics to OTN. This principle has been adopted from earlier work in TM Forum (starting in the late 1990s) and that was driven by work in the ITU-T that originated in the late 1980s. The recursive nature of the model allows it to be (re)used at any scale of network. The OIMT model is an evolution of the earlier work in the ITU-T and TMF.
The OIMT work also identified the need to provide a clear separation of concerns between physical things and functional things. The separation of functional things from physical things is traceable back to ITU-T work in the 1980s.
This separation of concerns leads to a realization that all functions are logical (virtual) within a physically bounded space. Hence, the model for networking applies to all cases, whether they be bounded by the edges of a device or the commercial demarcations of an operator’s network.
In version 1.3 of the Core information model, the Network Element concept, used in the industry in general, was deprecated. Network Element was recognized as a high-level mixture of concepts that intermingled the physical, functional and control arrangements and that had proved problematic in many common real situations.
Network Element was replaced by a set of carefully designed concepts that allow the independent representation of the physical components (Equipment), functional components and control components with the ability to indicate which physical components (Equipment) support particular functions (network/control) and which control components control/coordinate particular functional/physical components.
The notion of a service has also been recognized to be problematic when considered from the perspective of a recursive solution. For example, in the case of a control hierarchy, the provider at the bottom of the hierarchy considers the resources being offered to a user/client as a “service”. However, that client considers these as the network resources that are consumed to provide “services” to its clients. To address this challenge, we have developed a versatile representation that focuses on capability. The user/client requests are in terms of constraints on capability that, when active, produce an effect that gives the user/client the desired experience. The request leads to an intent (the intention of the provider system is to satisfy the request constraints) and an achievement (whether the provider met the constraints etc. or not). This capability-based representation applies equally at any level of the solution. Note that, in general, the constraints become narrower at lower levels in the management hierarchy.
The key concepts are summarized below:
The ONF OIMT document set is available at: