Telecom

What the system is:

• A compromise between flexibility and control
• An effective configuration assistant
• Not too far from the operators’ working habits
• An extensible configurations library
• An adequate response to specific requirements

Provisioning System

External driving requirements

System main functional areas

System implementation survey

Brief overview of system use cases

Service Deployment related Functionalities

Flow controller:

• Extracts configlets from templates instances
• Builds and manages sequential or concurrent configuration flows on single or multiple target devices
• Automatically triggers configurations roll-back if errors occur
• Update system’s configurations data base accordingly with operations results

Action controller:

• Executes configuration flows as a step-by-step commands sequence
• Manages concurrent configuration sessions
• Supports multiple communication protocols (telnet, SSH, SNMP)
• Executes commands on networks elements and manages and notifies operations return codes

Service Modelling related Functionalities

Native support by means of specific, ready to run, templates for the configuration of:

• QoS
• MPLS
• MPLS-TE (LSP and Tunnels)
• MPLS-VPN

Easily extensible application scope, to support configurations not included in the previously listed topics

A general purpose template mechanism:

• Much more than a virtual remote command line
• Supporting whatever router command
• Proprietary editor and description language, able to enforce controls over commands and parameters

The SCUBE product (SNMP Shot Sentinel => S3 => Scube) is an application capable of collecting all information from systems and devices that export them using the SNMP protocol.

The reasons that led to the realization of the project were many, so the definition of the targets and of the architecture was decided after a careful study conducted on the pollers most common on the market today.

The many positive and negative considerations made on the products examined led to the definition of the new poller.

The main features of SCUBE are the following:

• High performance

  SCUBE has been designed to achieve high performance.
  The code was developed trying to optimize each function and the use of system resources was designed taking into account the actual performance of the same on the various systems on which it is possible to use the poller.
  The set of system-calls and library-functions used was chosen without forgetting the performance aspect.
  The measurements conducted on some reference HP systems have allowed us to state that SCUBE is capable of receiving information from about 40,000 objects per minute.
  

• Scalability

  SCUBE has been designed to be used on a wide range of systems and therefore is able to operate on both small systems and large Main-Frames.
  Its structure adapts to work with available resources and is therefore designed to require only what the host system can offer in terms of memory / processes / communication, etc ..
  It is clear that the more powerful the host system is, the more the poller will be able to offer superior performance.
  

• Distributed execution

  To ensure maximum scalability of the object, we thought of providing an InterProcessCommunication architecture between the processes capable of guaranteeing the execution of some poller modules, even on remote machines.
  What you get is a real "distributed" system, capable of achieving any load target.
  In order not to burden the management of IPC systems, we act in "remote" mode only if expressly necessary, in other cases we work strictly locally using the most efficient system.
  The load balancing between the various processes that make up the operating scenario is always dynamically calculated and modified according to the operational trend at run-time.
  

• Portability

  The SCUBE code is written totally in a system-independent way and therefore it is easily portable on any type of operating system.
  For the parts strictly related to the host operating system, libraries have been designed that can offer the poller application level an interface independent of the operating system to be used.
  To bring the poller to a new system, all you have to do is create a new interface library capable of converting the poller's internal needs into appropriate specific system-calls.
  

• Small size

  "Small is Beautifull" ... in this case it is true .., the composition of the poller is made up of few parts, so both for the installation and for the run-time you have to check a few components (processes, system resources, configuration files).
  The goal of having few elements does not reduce the complexity of a project, in fact the SCUBE-Core is composed of more than 22,000 lines of code and the SNMP library derived from the UCD version of about 28,000.
  

• Low use of system resources

  To reduce consumption, we tried to design an architecture that did not require too many operations from the system for the management of processes and memory resources (semaphores, shared memory, messages queues).
  In this sense we have tried to define a number of processes (threads) suitably sized by the actual polling needs and not dictated by fixed rules established by an administrator.
  Therefore, an auto-tuning was carried out by the poller himself in a strictly dependent manner on the quantity of actions to be performed.
  

• Compatibility

  SCUBE is compatible with HP OpenView, so it can be replaced without special integration efforts.
  Both input and output files take the same formats.
  SCUBE is set up for communication with SNMP AGENT able to operate with versions 1, 2 and 3 of the SNMP protocol.
  

• Total configurability and tuning

  The poller is fully configurable, that is, all the levels that make it up can be sized and configured appropriately according to the installation to be made.
  The configurability extends from the use of system resources (sockets, files, etc.) to the conditioning of the SNMP protocol.