NetAce SDNizer – Bring Your Legacy Devices into the Digital World

By Stephan Scholz In my last blog, I wrote about how to simplify the Digital Transformation with NetAce speaking in more architectural terms. Today I want to present the more exciting part of it: an incredible simple tool, which is wrapping every legacy equipment so that it looks “new born” for the digitalized SDN- and NFV-world.

The tool provides open standard-based YANG API to every non-standard network equipment, or vice versa it opens all legacy equipment for YANG based service orchestration. So it is interesting for equipment vendors, network operators, system integrators and any other entity that has a legacy network and needs to bring it into the new digital world.

The challenges we address ….

Depending on the starting point you are coming from, you may have one of the 2 challenges:

  • You have a legacy network (or a group of legacy devices) which need to be included into a new SDN-driven device- and service-management architecture: you have a legacy network, however you want to benefit from new digitalized service-architecture to gain the cost- and flexibility-benefits. Here you would need a tool which transforms the legacy service interfaces (e.g. a set of CLI-commands) into YANG-based API.
  • You have given YANG-service Models from a modern service orchestration environment, which need to be applied on legacy non-standard devices: this is typically the case, when you already have an NG-OSS or modern Orchestration platform (e.g. ODL- or ONAP-based). In such case, all your services are described in YANG or YIN (=XML representation of YANG). So, the challenge here is how generate the right set of configuration commands for your legacy devices, which are part of specific services. The best would be having a machine-driven automatized translation of those YANG models into non-standard interfaces e.g. set of CLI-based configuration commands.

So let’s explain on how we resolve those to challenges …

with NetAce SDNizer:

In most cases, Your legacy devices, support only CLI or TL1-type of commands for configuration purposes. The NetAce has a codeless GUI-based design tool called Model-Editor (ME) that you can very rapidly design and set network entities (NE). Each NE is basically a sequence of commands responsible to configure something specific in the respective network device… e.g., a policer, classifier, cross-connect rule, etc. The term NE comes to represent a set of commands used to enable a network function or entity on a device. All services can be described in terms of NEs. So the NEs are the basic building blocks of a service. Now the SDNizer will automatically translate all those entities into YANG-based modules. So now it is simple to compose a YANG-based device model and Yang-based API for this device.  As a result we have created an open YANG API for this device.

The specific contribution of NetAce to solve this problem in such a simple way, is its unique capability to on-board every legacy device (if not already available in its huge library) and to define in terms of NEs (very basic command sequences) via its ME all possible services without a complex coding.  Those NEs can then simply be described in YANG-models.

But you can also start from the other side: you have an existing YANG-service Model (e.g. from an upper layer ODL-user). This YANG-service Model is now onboard again from NetAce Model Editor (ME). Now the respective device with its native commands (CLI or TL1) is supported by the ME i.e. NE are created based on those native commands. Now the SDNizer with the ME is directly mapping those NEs into the previously created YANG-based model – you have now a YANG-based service consisting out of native command sequences (NEs) to configure the devices. From the top, everything looks like YANG-Based and from the bottom, still the legacy commands are applied. So now you can map any standard YANG service model to any proprietary interface.

NetAce automatically guarantees the compliance of all parameters (e.g. VLAN-Ids) and boundary conditions (available bandwidth), so that all services are network wide consistent.

YANG and YIN – i.e. fully XML-compliant: we are experiencing more and more the request also for standard XML-API. Not a problem – as YIN is an XML representation of a YANG model. There is a 1 to 1 conversion between YANG and YIN and back. So with the exposure to standard YANG-interfaces, it is automatically creates an XML-interface.

Share this post

Close Menu