top of page






network topology lifecycle datastore framework

The openNaEF source code is hosted on Github.


Enable schedule-based management

I'm a paragraph. Click here to add your own text and edit me. It’s easy. Just click “Edit Text” or double click me to add your own content and make changes to the font. I’m a great place for you to tell a story and let your users know a little more about you.

Various Network Topology


I'm a paragraph. Click here to add your own text and edit me. It’s easy. Just click “Edit Text” or double click me to add your own content and make changes to the font. I’m a great place for you to tell a story and let your users know a little more about you.


Enable schedule-based management


OpenNaEF has the following features : Flexible and scalable object model support, on-memory DB, Schedule Management, History Management.

All objects have relation to attributes, and it can express not only simple model, such as device configuation, but also more complex model, such as multi-layer integrated network configuration.  

Schdule related attributes/reference can be assigned to all objects.It can manage not only current configuration information, but also future schedule information, "Current -> 2 weeks later -> 1 month later".

All objects holds modification history, and you can trace "when and who the modification was made" easily.  

OpenNaEF is the only DB in industry, which natively supports both schedule and modification history.  

This "History x Schedule" 2-dimensional time-axis management function enables future design and past status tracking of network infrastructure, and significantly contributes to your network service lifecycle management.

Various Network Topology


OpenNaEF natively posseses conventional network model configuration elements on MVO.

By combining these configuration elements adequately, you can model almost all network protocols.

You can express not only general network, such as IP, VLAN, MPLS, but alsomore complex network, such as Q-in-Q, Overlay, Virtual Router.

Because these configuration elements are essential and they are based on actual deployment experiences, all known existing network can be expressed.

Therefore, even when a new protocol advents, the new protocol can be dealt as same way as existing protocols, and addition of new protocol support can be done easily.   

The essential elements consist of Node, Hardware, ProtocolPort (if), Network, Link, and Network ID Pool, and its relationship consists of Cross Connection, Containment, Stack, Owner (Children), and Alias.

These elements' subclass and variation enables to support various network, including logical port (such as LAG), PseudoWire, VLAN, VPLS, VRF, IP-Subnet, or cutting-edge technologies, such as VXLAN, EVPN, TRILL.

These models enable to adjust management granularity depending on user's objective, unlike existing NMS or IMS which forces to manage with fine granularity for unnecessary information.

Manipulate all network objects

Objects stored in Object Storage can be obtained/controlled by specifying schedule time axis and version time axis.

The object control interface supports various methods, such as Control via RPC using DTO (Data Transfer Object), control with restful API, control with CLI using NaEF shell.

With restful API, various objects can be Added/Deleted/Modified, and Modification schedule can be also controlled with specified Target Time (Future Planning). 

NaEF shell allows object model to be controlled with command line, but also allows console connection to devices. The result of the direct change made on the device can be reflected to NaEF object model by command line. 

Object control can be transactionally executed, so that configuration, which first makes sense when it is deployed across multiple devices or nodes, can be controlled without caring about conflicts.

OpenNaEF supports "Pull" control which respond to request from application, but also supports "Push" control which actively notifies application when the criteria is fulfilled.  

OpenNaEF can actively alert users for unignorable events, such as scarcity of resources or conflicts.

The push control can be used as a trigger to execute scripts. Currently original method is used for the push notification, but push notification by gRPC will be supported shortly.

Best Platform for Best DevOps

OpenNaEF is carefully designed, in order to be utilized as DevOps platform, which maximizes its differentiating factor with minimal cost.

Conventional products have been offering benefit of ease-of-use which allows non-programmer to use. However, this also restrict the operation to be non-flexible and formatted, resulting in increase of operational burden.  

OpenNaEF also allows the same ease-of-use as conventional products, however, by using language-independent API, it maximizes the operation effect even with simple programming . 

You can achieve Google/Azure-class operation efficiency by practicing DevOps and by evolving both program and data structure gradually.


Today, automation is inevitable on the scale of the computing and networking environment.
In order to automate, validation of parameters to be input must be done correctly.
Whether a partial change has no effect on the overall consistency needs to be consistent with the current state and the planned state.
For that reason, the Lifecycle orchestration engine provided by OpenNaEF enables tracking of future designs and past situation related to network infrastructure and past situation by history x schedule "2 dimensional time axis" management function. 
This feature is greatly useful for automating network services


OpenNaEF has object classes that constitute an abstract network model that can express real networks.

These models express the protocol as a model as it is. Therefore, it is possible to represent various tunneling protocols, Q-in-Q, Virtual Router, etc that require special configuration.
It is designed based on the fact that all the networks can be expressed with 4 patterns by extracting common features from various protocol models.
Therefore, even if a new protocol appears, it can be handled in the same way as existing protocols and it is easy to add protocols.
NAEF has the feature that it realizes simple modeling and advanced abstraction at the same time.


Autonomous operation of network infrastructure is the ultimate goal of this project.

By combining OpenNaEF and various open source frameworks, configuration information enabling tracking of future designs and past situations related to network infrastructure can be matched with various kinds of information (traffic, server log, setting history, etc.) .

Combining the object model of OpenNaEF with various open source products gives you high precision information with few "noises" combined with configuration, events and statistics.
There is the shortest route to the autonomy of future operations.

A* is ....

Support various type scripts,Ansible,


full RESTful support, gRPC support (planned), generic CLI based shell interface allows to utilize OpenNaEF's full functionality with any language, so that you don't need to be an expert in specific language to use OpenNaEF. 

You can associate scripts by transaction or by object, in order to execute schedule based script. You can configure today, and execute it at the required timing.

This script binding can be used from infrastructure design tools, such as Ansible, Groovy or Fabric, or from lightweight languages, such as Ruby, Python or Javascript.

Object contents can be dynamically embedded in the script. It means that notified modification is reflected also in the script, so that modification made in NaEF can be deployed onto devices.

We provide various templates used in past use-cases, as open source format.

Request demo
Request demo

If you  would like to know more detail of this  project, please fill in your contact details

Your message has been sent.

bottom of page