System Architecture

Overall architecture and components

Mantychore is implemented with the OSGi specification and works with Fuse Service Mix 4.3. 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.

The figure show a typical architecture

The picture shows how a Mantychore user connect to the Server and how Mantychore connects with its devices.

The Mantychore software is multiplatform. To set up a Mantychore architecture, you need:

• A Computer which it is going to act as a Server. It will have Fuse Service Mix installed along with the the Mantychore components.
• Configure SSH to enable access to the routers (see compatible devices).

There are two types of Mantychore client:

• GUI Client. A desktop program has implemented with RCP.
• Web site. With Ajax and  RAP, it is implemented  a site which simulates the GUI client

Internal architecture

At present, the Mantychore software is implemented on top of an architecture where it exists two main actors: resources and capabilities. With these components, Mantychore can describe all the necessary virtual resources (a resource component). One resource contains the information (model) that represents itself and its features (a capability component).

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

ResourceManager, ResourceRepositories and Resources

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

The feature set provided by a resource are represented through the capabilities. Each capability must be associated to a specified 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 has not sense with switches because this resource type cannot configure BGP policies.

Since there will be a resource repository for each type of resource, is 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 or the capabilities that the resource supports. Here is presented an example of a resource descriptor.

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

Model

When a resource is initialized and started, it needs a component which maps the resource’s description. This description is all the information which Mantychore can extract from the resource. For this objective, Mantychore has a model component (based in the CIM specification) where load all this information.

Resource

A resource is the logical representation of a physical or virtual device. As it has been explained it contains the information (model) and features (capabilities) that.

Mantychore defines a resource life cycle. In this picture is possible to see the resource life cycle:

The end user  does these state movements via the Mantychore server console

Capability

Mantychore links a set of capabilities to a resource where each capability represents a new 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 have a list of actions (this set is named ActionSet) where are used to send operations to a device. Each of these actions is implemented for a device and a protocol context which understand the operation.

Finally, it exists a mandatory capability for all the resources, the queue capability which its 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 which a capability can send to a device. For this reason, this ActionSet, will depend of the model, type and protocol to access. Each action is implemented for a device with these parameters. Each action consist of commands being atomic operations which can be executed.

ProfileManager component

The profile manager provides the functionality to overwrite configured actions. This feature allows end users to customize their actions which can be adapted to achieve their use cases.

Action customization is done via Profiles. A Profile is a end user provided bundle containing its own implementation for some Mantychore 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). Association between a resource and a profile is indicated in the resource descriptor through the field profileId.

QueueManager component

This component is responsible of the execution of each action. It implements a queue and a list of operations to manage it. Furthemore, the queue implements a workflow where it is possible to restore the last correct configuration if some operations did not work correctly. Prior to execute the list of actions, the queue goes in PREPARE state, where the 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 backup configuration (COMMIT state). If, on the contrary, some error happens during actions execution, the queue restores back up configuration in the ROLLBACK state.

SessionManager and Protocol component

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

Protocols Used

Protocols

Here are listed the main protocols used to configure and manage the network via the Mantychore tool.

• 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  http://www.ops.ietf.org/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, we can see the different protocols involved in a Mantychore architecture. The green lines represent the communications to the devices.The red lines represent communication among servers, GUI and Mantychore software.

Workflow

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