The following figure shows the overview of the NEMO project architecture, which contains three main components: Physical Network Manager, User Manager and Renderers. The NEMO data is stored in the user repository in the MD-SAL data store. It’s specified by the user on the external applications that communicate with the NEMO engine through the RESTful APIs generated by the MD-SAL RESTconf according to the NEMO model, and consumed by the User Manager and Renderers components.
To better understand the architecture, it’s essential to first understand the NEMO model.
Physical Network Manager
The physical network manager is responsible for obtaining and maintaining the data about the underlying physical network for the MD-SAL data store, including devices and links, and provides these data to the User Manager and Renderers components. However, as the physical network manager is depended by the User Manager component which is implemented independent of the underlying infrastructure, it only maintains the common parts of the data about different kinds of physical networks, while the specific parts are maintained by the corresponding renderers. All other components that need the data of the infrastructure register listeners to get notifications from the physical network manager when it receives the data change events from the MD-SAL data store.
The NEMO data is stored in the user repository in the MD-SAL data store, which includes the data about the user, such as the identifier, name, role, privilege, etc., objects, operations and results described by the user. These data are added to the repository by the external applications which could be the NEMO client, the NEMO UI, a central orchestration system or other OpenDaylight components. The user manager gets the NEMO data from the repository and deals with them, and finally the renderers configure them on the underlying infrastructure leveraging SDN control protocols. User Manager
The user manager is one of the core components of the NEMO engine, and it contains three sub-modules, Object Manager, Operation Resolver and Result Monitor, which separately deal with the objects, operations and results. The user manager itself is mainly responsible for user authentication and privilege management, and monitoring the NEMO data changes as well as dispatching them to the corresponding sub-modules.
The three kinds of objects in the NEMO model: node, connection and flow, are managed and resolved by the object manager sub-module. The behaviors of the objects might be manipulated by the operations or policies and at the same time their states should satisfy the constraints specified by the results, so the object manager needs to provide the information of the objects to the operation resolver and result monitor sub-modules and notify the changes to them. With the object models, the users are able to design their own virtual networks, and they are automatically mapped into the underlying physical network by the object manager’s sub-modules: node mapper and connection mapper, and then configured on the individual device by the renderers. Operation Resolver
The operations that act on the objects allow the users to control the behaviors of the objects and change their states. The operation resolver is responsible not only for resolving and maintaining the operations but also for checking and handling the conflicts between some operations that all apply to the same object. If the condition is contained in an operation, which decides when to execute the operation, the operation resolver’s sub-module, constraint resolver, will perform real-time monitoring on the related data, such as the system time or the state of the object on which the operation acts. In addition to the condition monitor, the constraint resolver, another sub-module of the operation resolver, might need to resolve the constraint used to restrict which objects can be manipulated by an operation when the user defines it.
The Renderers component is designed to make the NEMO architecture support various renderers based on very different underlying technology. Other components don’t need to take the underlying implementation details into consideration, while they are trying to resolve the high-level user intent described with NEMO. How to deploy and configure on the underlying infrastructure to build the virtual network and execute the operations is solved by the renderers themselves. Consequently, the Renderers component provides a unified interface to effectively hide the underlying complexity. OpenFlow Renderer
The OpenFlow renderer is to implement the user intent based on the OpenFlow network. It gets the resolution results of the NEMO data by subscribing to the user manager, and converts them into OpenFlow flow entries and finally configures on the OpenFlow switches. The renderer also subscribes to the physical network manager for the changes of the underlying network and updates the flow tables accordingly.