Child pages
  • Contributions

White paper:

Interoperability via Semantic Compatibility in SDN/Cloud Systems


Problem context [DN1]

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:

  • 24 x7 operation
    • Non-stop operation at all levels
  • IoT scale
    • All devices interconnected on a global scale (10 10 devices)
  • 5G/6G/nG functionality
    • Evolving functionality
  • Zero touch
    • No people in-line or in loop (but people still in the equation �� )
  • Agile Value Fabric
    • Collaborative/competitive market place of continually repositioning players
  • Rampant innovation
    • New capabilities at ever increasing pace


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.

  • Lifecycle compatibility
  • Semantic compatibility
  • No API versioning


It is assumed that

  • The System is an assembly of Components where each Component is itself a System as per the Component-System pattern:
    • Recursive/fractal
  • Components boundaries shift over time as the System evolves to account for new demand and for new realizations
    • Inter-commercial organization through to local high-trust intra-commercial organization
  • Intercommunication between Components occurs:
    • At their Ports via a binding of those Ports
      • With varying degrees of permanence from fleeting to long duration
    • As a result of need/capability advertisement and negotiation
      • Where that advertisement/negotiation may be live or during some planning phase
    • Using some language of Expression via the Port binding, i.e. via an Interface
      • Where this Expression is used for negotiation, request/demand, current operation etc


Architectural Proposal

To handle the ongoing evolution of Expression whilst maintaining interoperation it is proposed that:


  • Expression is within the context of a Grammar
  • Expression language development is controlled/coordinated such that:
    • The Grammar is stable
    • The vocabulary is free to grow as necessary
    • The Concept Labels are strongly controlled within each Label Space such that:
      • Each Label covers a defined semantic volume and no Labels cover more than one volume (so the human language failing of “table” with legs and with cells does not occur)
      • Each Label covers a defined encoding of expression of the defined Semantic Volume
      • Once released that semantic definition does not change (i.e. new volume, even if very close, means new label)
  • Expression Language is NOT versioned (as Label versioning is not relevant and the Label space can grow organically)

It is recognized that:

  • Two Components communicate only when there is relevance to that communication and such that there is an intersection of capability/need semantics
  • When two Components communicate they do so about a very small part of the shared semantics
  • Inter-Component communication is Transactional in that there are interdependent exchanges and independent exchanges between the Components and several Interactions may occur in any Transaction
  • For any particular Interaction, the Interaction may be considered as successful even when there has only been partial understanding
    • Only the relevant semantics for success need to be dealt with and only within that interaction
  • To achieve understanding the Labels need to be interpreted
  • As a result of asynchronous evolution two interacting Components may express Semantics at different Granularities and with different Boundary Phases


  • Per-Interaction interpretation may need translation

Resultant Architecture:

  • A micro translation framework on both ends of the communication (i.e. at the Component Ports for both directions of flow of communication, on the provider and user end) where that framework:
    • Is efficient
      • Essentially no impact on performance where the vocabulary items used are the same
      • Optimized impact where there are differences
    • Deals with:
      • Different labels for the same semantic with different encodings
      • Different semantic granularities/phases
  • If the translation has excessive impact on the performance of the round-trip times for the interaction the Component Port or Component as a whole can be upgraded



  • Hence Semantic compatibility
  • Best effort compatibility
  • May accept performance hits
  • All components should have instrumentation
  • Async/synch as one continuum


Several scenarios and use cases should be analysed and discussed, when Component Needs/Capabilities and Interface expression of system components evolve asynchronously.


  • Every Expression of Interaction must be machine interpretable (e.g. xsd, yang, json-schema, swagger, …)
  • Every expression update requires publication of a translation from old to new and from new to old version
  • All components need to have a translation micro-framework in advance. This micro framework will host the translations and must have minimal maintenance impact (zero-touch), should not have a performance impact on the message flows (low latency) and should be coded very generic and efficient.
  • The translation micro-framework must have the ability to stack translations. In case performance of too many stacked translators becomes intolerable, a recoding is required to combine several translation steps or to fully upgrade the Component to the new expression forms
  • Translations are acquired on-the-fly as required per interaction (i.e. when the expression is encountered)
    • They can be pre-installed if desired (but should not need to be)


Short term [DN4]

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.

Starting point

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.

New ControlConstruct with API v2

Make it generic

Server/Provider/component with capabilities

Client/consumer/component with capabilities

Components/parties/ handshaking

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.

New Controller with API v2

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.

Stacked translations

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 [1] systems, hence I am a user of control capabilities.

5        Due to various constraints (see assumptions) [DN5] my control solution comprises a recursion/intertwining of control.

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




[1] Automated management is control

[DN1] Some notes:

  • Semantic intersection
  • Negotiation
  • Capability/need
  • Semantic granularity
  • Semantic boundary positioning/phase
  • Evolution of one interface v mediating many
  • Lifecycle timeframe
  • Lifecycle Compatibility
  • Innovation Value Lifecycle
  • Universal interaction grammar
  • Degraded operation
  • Per interaction compatibility
  • Maximizing the success of interactions
  • Self-versioning tags
  • Name spaces and control
  • Componentization
  • Capability discovery
  • Federated multi-operator solution (FedBizDevOps)

[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!