Interoperability via Semantic Compatibility in SDN/Cloud Systems
The capability, complexity and scale of telecommunication/cloud systems will continue to increase. Systems must be prepared to offer capabilities, which are unknown today . Systems must be designed in an elastic fashion. [DN2] Functions will be introduced and removed dynamically and automatically. Even so it is expected that the System availability must be close to 100%.
The current vision drivers of such networks are:
New capabilities can be added, existing capabilities evolved and old capabilities removed from any part of the system without relevant impact to running solutions.
In the projected systems it is required that the vast number of devices and their capabilities will have their own independent lifecycle, but will need to interconnect device to device from a control, management and “value capability” perspective without effecting operational capability when introducing, updating and removing them.
Due to expected high dynamic of the system, an asynchronous evolution of many interacting entities will take place. Updates to their capabilities and language of expression happen on-the-fly.
New capabilities will be detected and discovered, such that they may be used in the system.
The language of expression will evolve. New expression of existing capability will be such that it can be interpreted and the capability used as before. It is intended the updates do not negatively impact local, or overall, system function.
It is assumed that
To handle the ongoing evolution of Expression whilst maintaining interoperation it is proposed that:
It is recognized that:
Several scenarios and use cases should be analysed and discussed, when Component Needs/Capabilities and Interface expression of system components evolve asynchronously.
In order to identify and to describe the pain points of interacting software components in a complex environment and on-the-fly asynchronous API updates and changes and introduction of new APIs the several use cases and scenarios should be described to see their similarity or differences to each other.
A system with interfacing API consumer and API provider has a current active status. This status is the starting point for any kind of asynchronous evolution of interacting entities.
The following figure shows such starting points. All consumers and providers are already prepared for injection of new translations based on the micro translation framework. The micro translation framework is represented as box with white background. Application v1 is consumer of the API while the ControlConstruct v1 is a provider. The Controller v1 in the middle act as consumer of the API towards ControlConstruct v1 and as provider of the API towards the Application v1.
In the displayed scenario there is not translation required, because all components are supporting and using the same API schema version. Such translation is represented as “f(x) = x”, which means that input and output are identical.
Make it generic
Server/Provider/component with capabilities
Client/consumer/component with capabilities
Reduce figures to only two components
Switch to “unidirectional” interfacing (arrows)
Fine grain plugin model for micro-translation-framework per case(!)
(show it in figure)
Translation delegated (optional)
In this scenario the control construct supports the next API version v2 and only this one. Think about a brand new product, which was designed only for v2.
In a handshake process both components must agree on API v2. The Controller v1 will download the translation from a well-known repository and will use this translation for interfacing with ControlConstruct v2.
Some data can be directly translated “f(x2)=x1)”. However their might be some data which will not have any association to a function or service in Controller v1. In the figure it is indicated that all new data (undefined in API schema v1) will be ignored by the Controller.
Another best effort compatibility approaches might be to fill such data with default values as defined in the schema.
This scenario adds - compared to the starting point - a new Controller v2. The main difference is now that two different translation must be available one for the consumer and one for the provider. Organizations defining an updated of a schema or model must provide translation from old to new and at the same time new to old (f(x2)=x1 and f(x1) = x2).
The figure also show that it could be possible to have a different translation for new data.
It could be also possible, that Controller v1 and Application v1 agree on APIv2 – same for Controller v2 and ControlConsturt v1. The rules about the agreement about usage of the API version needs to be subject of a resource project.
Another scenario which should be considered is, what happens, when an API of more than two version is in the network. By default the modelling organization should have provided the translations from v1 to v2 and from v2 to v3. The micro translation framework must have the capability to perform several translations in a sequence.
In case several translations due not meet the message flow performance requirements, than a new translation needs to be developed combining translations into one.
Please note the scenario is more complex than shown in the figure. In huge IoT of 5G networks consumers and provides of different versions may agree on differently. It is expected, that Consumer v3 may support for other Providers API v2 or even API v4.
Findings and concepts should be demonstrated in a proof-of-concept, executed by ONF, hosted by abc in xyz , first quarter 2019.
1 As for any commercial organization, my aim is to increase shareholder value. I do this by delivering value at a price to my customers and partners by providing telecommunications services as a network operator.
2 To provide telecommunications services I leverage the capabilities of my partners and suppliers which I acquire at a cost. These capabilities are either purchased outright or are leased. The leased capabilities may be totally within my control whilst leased or may be acquired as a “service”.
3 To achieve increase in shareholder value I both take market share and work to increase the value of the market. I increase market share by staying ahead of the game (early adopter). I increase market value by innovating (innovator) to expand the scope of the market.
4 To operate, maintain and optimize my service providing capabilities I utilize control  systems, hence I am a user of control capabilities.
6 My control solution is necessarily a mix of capabilities from different vendors (see assumptions).
7 My networking solution is necessarily a mix of capabilities from different vendors where the networking capabilities necessarily do not clump into per-vendor islands (see assumptions).
A list of other compatibility terms and why we are not using them
- Backward Compatibility
- Forward Compatibility
- Syntax Compatibility
- Semantic Compatibility
 Automated management is control
[DN1] Some notes:
[DN2] A bit early for a statement on design
[DN3] I have deleted this… Semantic intersection needs to be understood but schema does not need to be agreed, it is just used and translated on the fly.
[DN4] I have not reworked the terminology etc beyond this point.
I intentionally removed API etc from earlier text…
[DN5] I need to add these…. Have run out of time!