System Architecture

Overall architecture and components

OpenNaaS is implemented with the OSGi specification and works with Fuse Service Mix 4.4. Fuse works as a Service platform which implements the OSGi specification. It provides a set of libraries and tools to allow easier development of Fuse components.

This figure shows a typical architecture.

The picture shows how an OpenNaaS user connects to the Server and how OpenNaaS connects with the devices it manages.

The OpenNaaS software is multiplatform. To set up an OpenNaaS architecture, you need:

• A Computer which is going to act as a Server. It'll have Fuse Service Mix installed, along with the the OpenNaaS components.
• SSH setup that allows access to the routers (see compatible devices).

There are two types of OpenNaaS client:

• GUI Client. A desktop program implemented with RCP.
• Web site. Through Ajax and RAP, it simulates the GUI client.

Internal architecture

At present, the OpenNaaS software is implemented on top of an architecture based around two core components: resources and capabilities. With these components, OpenNaaS can describe all the necessary virtual resources (a resource component). Resources contain the information (model) that represents itself and capability, which represents its features.

In order to manage the resources and their capabilities, there are other components to provide required features: SessionManager, Protocol, Model, ActionSets, ResourceManager, ...

ResourceManager, ResourceRepositories and Resources

OpenNaaS supports different types of resources (switch, routers, ...).  In order to organise them, OpenNaaS can implement different kinds of repositories that group the resources according to their type. The resource repositories manage the resources created within the platform, it also allows persistence into the database. To allow OpenNaaS to support new resource types creating a new repository is needed for the new ones.

The feature set provided by a resource is represented through capabilities. Each capability must be associated to a specific type of resource according to functionalities their provide. For example, a BGP police is a feature of routers, thus the BGP capability has to be associated to a router resource, but the same capability doesn't make sense with switches because this resource type cannot configure BGP policies.

Since there will be a resource repository for each type of resource, it's necessary to have a global component to manage the different repositories. The ResourceManager will be in charge of this task. It will offer a set of actions to control the repositories and its resources.  

Resource Descriptor

For the creation of a resource, the ResourceManager uses a description file (ResourceDescriptor) which provides the necessary parameters to configure a resource. For example, it contains the type, name and the capabilities that the resource supports. Here an example of a resource descriptor is provided.

<resourceDescriptor>
    <!-- Capability information. It specifies device model and version -->
    <capabilityDescriptors>
        <capabilityProperty value="junos" name="actionset.name"/>
        <capabilityProperty value="10.10" name="actionset.version"/>
        <information><type>chassis</type></information>
    </capabilityDescriptors>
    <!--  Queue capability information. It specifies device model and version. IT IS OBLIGATORY -->
    <capabilityDescriptors>
        <capabilityProperty value="junos" name="actionset.name"/>
        <capabilityProperty value="10.10" name="actionset.version" />
        <information><type>queue</type></information>
    </capabilityDescriptors>
    <!-- Resource information. It specify type and name-->
    <information>
        <type>router</type>
        <name>junos20</name>
    </information>
    <properties/>
</resourceDescriptor>

Resource

A resource is the logical representation of a physical or virtual device. As explained it contains the information (model) and features (capabilities) necessary to allow OpenNaaS to work with the device. To create a resource within the OpenNaaS platform a well defined life cycle is required.

The next figure represents the resource life cycle. First of all, the resource must be created. This action concludes leaving an initialized resource in the platform. In this state the resource can show information of its features and the protocol context can be set. At this point, starting the resource will activate its features and allow the execution of actions on it.

Using the commands provided by the OpenNaaS server console, the user can control the state of the resource. The following table lists the possible commands and their actions. The initial state indicates the state from which the command can run, while the final state indicates the state that the command induces.

Model

When a resource is initialized and started, it needs a component which maps the resource description. This description is all the information which OpenNaaS can access from the resource. For this purpose, OpenNaaS has a model component (based in the CIM specification) which loads all this information.

Capability

OpenNaaS links a set of capabilities to a resource where each capability represents a feature or ability which a resource can do. For example, a router resource will be able to have capabilities related with operations for the 1, 2 and 3 level network. However, a switch resource will only be able to use capabilities for the 1 and 2 level network.

Each capability has a set of actions (named ActionSet), used to send operations to a device. Each of these is implemented for a device and a protocol context which understands the operation.

Finally, there's a mandatory capability for all the resources, the queue capability, which main functionality is the management of the actions which are sent to a physical device.

The definition of an ActionSet, QueueManager and its functionality will be explained better in the next issue.

Architecture picture overview

ActionSet component

The ActionSet contains the implementation of the operations, called Actions, that can be sent to a device. For this reason, the ActionSet implementation will depend on the model and type of the resource and on the protocol to access to the resource. The Actions belonging to the same ActionSet are implemented for a specific device following this criteria (model, type and protocol). Each Action can be broken in different atomic operations, called Commands, which perform the action once run on the device.

ProfileManager component

The profile manager provides the functionality to overwrite configured actions. This feature allows end users to customize their actions in order to adapt them to their use cases.

Action customization is done via Profiles. A Profile is a end user provided bundle containing an implementation for some OpenNaaS configured actions. Profiles may be linked to a set of resources, meaning that when a resource is to execute an action, its profile is first checked for an implementation of that action.

ProfileManager stores loaded profiles and manages their lifecycle. It is implemented as a bundle which is continually listening for new profiles and registers them upon arrival. Registered profiles are then able to be linked to resources (with the restriction that a resource can be linked to only one profile).The resource descriptor must indicate, through the field <profileId>,  the name of the profile that will be associated to the resource.

QueueManager component

This component is responsible of the execution of each action. It implements a queue and a list of operations to manage it. Furthermore, the queue implements a workflow where it is possible to restore the last working configuration if some operations did not work correctly. Prior to the execution of the list of actions, the queue goes in PREPARE state, where the working configuration is saved. After that, it starts to execute each queued action (EXECUTE state). If all actions are executed correctly, the queue commits all changes and discards then backup configuration (COMMIT state). If, on the contrary, some error happens during execution, the queue restores the backup configuration in the ROLLBACK state.

SessionManager and Protocol component

The SessionManager controls the protocol components and provides connectivity to the different devices. It searches available protocols among all services, registers them, and serves registered protocols' sessions upon request. eg: When the QueueManager needs to connect with some device, it asks the SessionManager, which searches among its configured protocol sessions a proper session to connect.

Event manager component

The Event Manager is a Karaf service which OpenNaaS uses to communicate the components. It provides an Event Notify-Listener service which is used to implement the alarm management in the Luminis module. This is an example about how this alarm management works for optical switches.

• The EventManager provides its methods to the ProtocolWonesys and ProtocolSessionManager
• The Protocol Wonesys events are listened for the ProtocolSessionManager
• The ProtocolSessionManager converts these events to Capability Alarms which is registered in the AlarmRepository
• The Monitoring Capability provides Karaf commands to control the Alarm Repository service

Protocols Used

Protocols

These are OpenNaaS main protocols used to configure and manage the network.

• HTTP (HyperText Transfer Protocol) - http://www.w3.org/Protocols/
• WS (Web Service) - http://www.w3schools.com/webservices/ws_intro.asp
• NETCONF - http://en.wikipedia.org/wiki/NETCONF
• WSMA (Web Services Management Agent) - http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_cfg_wsma_ps6441_TSD_Products_Configuration_Guide_Chapter.html

In the image, the different protocols involved in a OpenNaaS architecture can be seen. The green lines represent the communications to the devices.The red lines represent communication among servers, GUI and OpenNaaS software.

Workflow

This image presents a possible infrastructure configured using OpenNaaS. It shows where OpenNaaS works (brown lines) to connect two public entities. In this case, OpenNaaS does not have complete control and it works above an external infrastructure.