You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 39 Next »

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 are: resources and capabilities. With these components, Mantychore can describe all the necessary virtual resources (a resource component) and its features (a capability component).

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

ResourceManager, ResourceRepositories and Resources

A resource and its capabilities are registered in different resource repositories as their type. For example, a router resource will have its repository and a switch resource will have another different. Consequently, any new switch resource will be registered in the same repository that the other switch.

The different capabilities are associated with a specified type (a BGP capability is associated with a router resource, but the same capability has not sense with switches because a switch type resource cannot configure BGP policies) are registered in the correct repository.

Finally, it is necessary a manager to the repositories and resources. Consequently, it will have to manage the management of resources, its persistence support, loading of configurations and other management tasks. Mantychore has implemented a ResourceManager where it will be responsible of all these actions.

Resource Descriptor

For the creation of a resource, the ResourceManager uses a description file (ResourceDescriptor) which provides the type, features and capabilities which our resource supports. An example:

<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 a virtual resource representation. It was explained that it contains the information (model) and features (capabilities) which it can use.  These parameters have to created and started to be an active  resource. In this picture is possible to see the resource life cycle:

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

 

INITIALIZED

ACTIVE

create

- read resource descriptor
- store descriptor in the database


start

 

- get capabilities
- get profiles
- execute bootstrapper
- create model

stop


- reset capabilities
- reset profiles
- reset model

destroy

- delete resource descriptor from the database


Capability

Architecture picture overview

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.

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 is consist of commands with are atomic operations which can be executed.

ProfileManager component

The profile manager provides the functionality to overwrite configured actions. This feature permits to the end users personalize their actions which i can be adapted for their use cases.

The ProfileManager is implemented as a bundle which is listening continually, waiting some new profile to register in its list of profiles. When this profile is registered, this profile will be able to be linked to a set of resources. Then, when a resource wants to execute some action of a capability, first, it will check if its profile contains some overwritten action for this action and capability.

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 restore the las correct configuration if some operations did not work correctly. Before that execute a list the actions, the queue was in the PREPARE state where it is saved the configuration. After, it starts to execute each queued action (EXECUTE state) while these actions are executed it can be two different cases. If all it was executed correctly, the queue commits all the configuration (COMMIT state) and if it happened some error it restored the 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 among all services to register all the available protocols and 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.

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.

  • No labels