OpenClovis Logo

Functional Description
Clovis Object Repository (COR)

Description of COR and its functionalities. More...

Description of COR and its functionalities.

The ASP COR service is an object-oriented, distributed object repository used for representing the system model. It is used for storing information about the network elements to be managed from any system management application.

cor4.jpg

The network elements are modeled as Managed Object(MO) Classes in COR. The attributes of these MO classes are properties of these network elements. The instances of these classes, called as Managed Objects, contains the information about the actual network elements. The COR service provides interfaces to access, modify and manage the life cycle of objects. These objects are called Managed Objects as they contain management information about network elements such as a Chassis. They are used to exchange information between system management applications and applications running on network elements. The applications running on a network element use or produce management information. Managed Objects and metadata associated with them are located in an in-memory object storage as well as in the persistent database.

System Management Applications(SNMP, CLI, etc) reside outside the network element and use the services of a local management agent to interface with COR. These local agents are referred to as Object Managers (OM).

Applications in a network element that use or produce the management information are referred to as Object Implementers (OI). An ASP Service can act as an Object Implementer for an object of interest.

Object Manager and Object Implementer are roles performed by applications. In the current implementation of COR, COR is unaware of Object Manager and Object Implementer roles and does not enforce any semantics related to these roles. It is assumed that the OM and OI roles are maintained by careful application design.

Usage model

Applications can model their network elements and represent them as COR Information Model. These applications can use MO classes and the containment relationship in COR to interpret the relationship between various network elements.

Management Applications (North-bound)
Management application can perform CREATE, DELETE or SET operations on Managed Objects for configuration purposes. Management applications can also subscribe to CREATE, DELETE or MODIFY notifications on Managed Objects. Such Managed Objects reflect the status of associated network elements.
Object Implementor
An Object Implementer (OI) implements the configuration supplied by the north bound. An OI can also perform CREATE, DELETE, and MODIFY operations on Managed Objects to reflect its run-time status.

Managed Object Class Characteristics

COR MO-Class and MSO-Class

A MO COR-class is a collection of attributes. Each class has a name and an integral identifier. An MO-class has two services associated with it:

COR groups related attributes of these two services in two different Managed Service Object Class (also called MSO class). Thus, an MO class has two different MSO classes. One corresponding to Provision-able attributes and the other corresponding to Alarm attributes. The MSO class also has a name and a list of attributes.

ASP Alarm service determines the structure of the Alarm MSO class and uses this class to model alarms.

The Provision-able MSO class structure is defined by the application. From the modeling perspective, it is only the PROV MSO class that is of interest to the application. For example, a GigePort class can have a group of provisionable attributes (MTU size) and a group of alarms (such as LOS, LOF and so on). COR considers these two groups as two distinct MSO classes associated with GigePort class. An MSO class is identified by an MO class and its Service ID The Service ID indicates if the MSO is Provisionable or corresponding to Alarm. The enumeration, ClCorServiceIdT, specifies the service ID of a class.

MO tree and Containment

All Managed Objects in COR are organized in a tree hierarchy called the MO tree. The relationship of an MO to its parent MO in the hierarchy is referred to as its "containment" relationship. An MO can only be contained in MOs belonging to other MO classes. The rules related to permitted containment relations are part of the definition of an MO Class.

The containment relationship allows COR to organize all MOs in a tree and is therefore mandatory from COR's perspective. Containment relationship is of no other significance to COR. However, it can have some special significance to management applications as some OIs can be interested in a group of related objects (in a subtree). For example, a subtree could reflect the containment of the Availability Management Service (AMS) related objects and this containment can have special significance to AMS.

Blueprint for the MO Tree

The MO Class definitions and the permitted containment relations in COR are also referred to as the "blueprint" for the MO tree. This blueprint refers to the complete set of object metadata associated with a COR instance. COR permits objects to be created and attached to a tree according to the blueprint. This blueprint can be constructed using the OpenClovis Integrated Development Environment (IDE). The blueprint is exported in IDE generated XML file clCorMOClass.xml and imported by COR when it is initialized for the first time. The blueprint is kept in the COR's persistent storage. COR obtains the blueprint from the persistent storage during its subsequent startup.

MO Attributes

Attribute Characteristics

Each MO attribute has the following characteristics:

The qualifiers supported are:

The sub-qualifiers supported are:

Attribute Types Supported

Integer and String Types
The supported types are signed and unsigned integers of various sizes. Arrays of these integer types are also supported. For integer types, a maximum, minimum, and default value can be specified.

Caching and Persistence of COR objects

All COR metadata and objects are persisted in the COR-DB. However, the attribute values are not always persisted. This control can be exercised at the object attribute level. Persisted object attributes are restored in a COR instance automatically after a GMS-Cluster reboot.

COR stores the values of attribute in the memory. This is referred to as caching. Caching results in better read access times for cached attributes. Caching of data is not required when the cached data can quickly become stale. Controls are provided to prevent caching of this type of data. These are explained in subsequent sections.

Attribute Qualifiers

Every attribute must be qualified as a CONFIG, run-time or KEY. These qualifiers are mutually exclusive.

Configuration Attributes
A configuration attribute is always persisted and cached. Configuration attributes contain data provided by the Object Managers. They are read-only from the perspective of the Object Implementer.
Run-time Attributes
A run-time attribute is not persisted or cached by default. The following sub-qualifiers (either singly or in any combination) can be associated with a run-time attribute:
  • Persistent - This sub-qualifier for run-time attributes indicates that the attribute must be made persistent by the COR Service.
  • Cached - This sub-qualifier for run-time attribute indicates that the attribute must be cached by the COR service.
Run-time attributes are used for data provided by Object Implementers. They are read only from an Object Manager's perspective. A run-time attribute that is cached is updated by the Object Implementer when the value changes. When a read request is made on such a run-time attribute, COR reads the value from the cache. A read request on a run-time attribute that is not cached triggers a synchronous request to the Object Implementer that returns with the value of the attribute.
For examples:
run-time + cached
Attribute showing Application log stream file name implemented by the Log service.
run-time + cached + persistent
Administrative state of a service unit implemented by AMF.
run-time + multi-valued
List of Service Instances currently assigned to a Service Unit, implemented by AMF.

Object Addressing

MOID

Every object in the COR MO tree has a unique ID referred to as the MOID (Managed Object ID). Every object has a relative_ID that is formed from the tuple, class_ID and instance_ID, where:

The MOID of an object is formed from the tuple, MOID of the parent and relative_ID of the object. For example, an AMF Service Unit instance can have the following MOID (shown here in two lines, it has to be a string with no space):

COR_ROOT_CLASS_ID:0/APPLICATION_CLASS_ID:0/SERVICE_GROUP_CLASS_ID:1/
SERVICE_UNITCLASS_ID:3

COR provides APIs to manage the life cycle of an object and to read or modify its attributes. The user is required to know the MOID of the object or its parents.

A MOID uniquely identifies an object in COR tree. However, a variant of the MOID is also used to specify ranges of objects. These are called wild card MOIDs. A wild card class_ID can represent any class and a wild card instance_ID can represent any instance. The wild card MOID is used for OI subscription and for specifying an MO instance search criteria. Following are some of the examples of a wild card MOID:

Object Management Interfaces

OI and Primary OI

An Object Implementer performs several distinct operations in relation to changes in objects that include:

Every object can have one or more Object Implementers. While multiple OIs can perform the first three activities, there can be only one OI that is allowed to perform the last two activities and this OI is referred as the Primary OI.

OI Registration

A component can act as an OI for an MO as specified in a wild card MOID. For example,

As a component can act as an OI for multiple MO instances corresponding to different MO classes, COR provides a mechanism to associate an OI callback APIs for each MO class.

The OI and MO association is performed during modeling. The following table provides a list of OI callback APIs provided by COR.

No. OI Callback Function Description
1 Constructor COR invokes this function when an MO is required to be created. An application can embed its custom logic to implement MO creation. Currently, MO creation/deletion does not have a validate callback function.
2 Destructor COR invokes this callback when an MO is required to be deleted. An application can embed its custom logic to implement MO deletion. Currently, MO creation/deletion does not have a validate callback function. function.
3 Validate COR invokes this callback to validate the attribute that is bein SET. The callback either permits or denies the application containing this attribute. The semantics of validation is specific to the OI. An OI can acquire resources (such as memory) required to APPLY this attribute to ensure that the APPLY operation is successful. This pre-acquisition reduces the possibility of failure of APPLY operation.
4 Rollback This callback is invoked when the validate operation fails on this attribute or validate fails on another attribute that is part of the transaction. This callback allows the OI to free any pre-allocated resources, acquired in the validate phase. The rollback API is called if any other operation that is part of this transaction fails to validate.
5 Apply This function applies the attribute to the resource.

COR Session Capability

The COR session capability provides a mechanism to execute a group of jobs (CREATE, DELETE and MODIFY operations on a MO) in an efficient manner by minimizing the number of RMD calls between the COR client, COR server, and Object Implementer. The COR session capability provides a mechanism to execute CREATE, SET, and DELETE operations on a group of MOs with all-or-none semantics as described in this section. The COR server performs a basic validation on these jobs. If one of the job validation fails, the session becomes invalid and no operations are performed.

COR determines the OI for each participating MO, and invokes the validate callback of the OI. If the OIs successfully validate their MO operation, COR invokes the apply APIality of the OI. COR also internally updates its database with these changes on the MOs. On successful completion, COR sends a notification for the changed MOs.

If an OI fails validation, COR does not proceed with the apply. COR determines the set of OIs that have completed validation and calls the rollback APIs.

The following sequence diagrams describe the control flow between COR-client, COR-server, and OIs for the following two cases.

cor1.jpg
cor2.jpg

COR Bundle Capability

The COR bundle capability provides a mechanism to execute groups of attribute reads in an efficient manner by minimizing the number of RMD calls between COR client, COR server, and Object Implementer.

A bundle is non-transactional in nature. A non-transactional bundle can contain attributes that are not successfully read.

The bundle semantics of executing jobs is performed in four phases by the application:

  1. Bundle Creation - A bundle is empty with no jobs associated when it is created. A bundle handle that identifies this bundle is returned.
  2. Job Population - In the next phase, jobs are added to the bundle. A job corresponds to an MO and list of attributes that needs to be read. Multiple jobs consisting of different MOs can be a part of a bundle. These jobs are queued at the COR client. Every job has a status and a buffer descriptor. The buffer descriptor contains the value of the attribute to be set or get. The success or failure of jobs execution is reflected in the status.
  3. Bundle Apply - The application performs the APPLY operation synchronously when the population phase is completed. The bundle is submitted to the COR server that reads the value from the database or contacts the OI to obtain the value. The values are streamed back to the COR client at the end of this call.
  4. Bundle Finalize - This frees up the resources allocated in bundle operation. The following sequence diagram explains the control flow between COR client, COR server and OIs for the given case.
    • A bundle operation is initiated by comp1. The bundle contains jobs: <moid1, attr1>,<moid2,attr1>, and <moid2,attr2>. <moid1, attr1>, <moid2,attr1> are run-time attributes.
    • These jobs are submitted by comp1.
    • COR determines the PrimaryOI for moid1 and moid2 as <CompOI1> and <CompOI2>.
    • COR obtains the values the run-time attributes of CompOI1 and CompOI2 for <moid1,attr1> and <moid2,attr1>.
    • COR obtains the Config attribute value from its database.
    • COR returns back the value to comp1.
cor3.jpg

COR Search Capability

COR provides the capability to retrieve objects matching a particular criterion. This criterion is called the filter and this is referred as search based object-walk. This search can be done by using the API clCorObjectWalk and following are the parameters for this search:

COR provides a mechanism to search objects based on the value of their attributes. This is referred as Search based attribute walk. This search is used in conjunction with object walk search. Object-walk returns all the MO instances that match a particular search criterion. Each of these instance can be searched based on a particular attribute and its value. This search can be done by using the API clCorObjectAttributeWalk(). This takes the following parameters.

COR Event Generation and Subscription

COR generates an event for every object creation/deletion/set operation. The applications can subscribe for these events by using the API clCorEventSubscribe and they can narrow down the events of interest by specifying the following filters.

Generated on Tue Jan 10 10:29:15 PST 2012 for OpenClovis SDK using Doxygen