| Solstice Enterprise Manager 4.1 Developing C++ Applications |
|
Modeling Managed Objects
Network management in the Solstice EM environment follows the ISO network management model. This model is object oriented. To manage your resources in the Solstice EM environment, you need to write an object model of those resources. The object model defines the characteristics of resources your application will manage. Having written your object model you need to make it available to Solstice EM.
This chapter explains how to write an object model and make it available to Solstice EM.
- Section 2.1 ISO Management Model
- Section 2.2 Designing the Object Model
- Section 2.3 Abstract Syntax Notation #1 (ASN.1)
- Section 2.4 Assigning Unique Identifiers
- Section 2.5 Obtaining GDMO and ASN.1 Specifications for Objects
- Section 2.6 Making Your Object Model Available to Solstice EM
2.1 ISO Management Model
Network management in the Solstice EM environment follows the ISO network management model. This model is based around manager and agent applications that exchange network management information. The ISO network management model is illustrated in FIGURE 2-1.
FIGURE 2-1 ISO Network Management ModelThe main parts of the ISO network management model are introduced in the following subsections.
2.1.1 Managers
A manager issues management requests to one or more agents.
A manager receives information from agents in the form of:
- Notifications. A notification is an unsolicited message sent to manager to indicate that a change has occurred to a managed resource.
- Responses. A response is a message sent in response to a management request. A response contains the result of the management request, for example a confirmation that the request was carried out, or the information the manager requested.
A manager typically performs the following additional functions:
- Collecting and filtering information from agents
- Presenting information to operators of a managing system
A manager resides in a managing system.
2.1.2 Agents
An agent acts as an intermediary between a manager and managed resources. An agent receives requests from a manager. An agent sends responses to requests and issues notifications. Each agent in a managed system is responsible for carrying out management directives to control or return information from managed resources.
An agent can reside in a managed resource, or be located elsewhere and operate remotely.
2.1.3 Managed Resources
A managed resource is any network resource that can be managed. The resource can be a physical device such as a host, server, router, or subnet, or it can be a conceptual entity such as a line, a queue, or some other aspect of network operation that needs to be managed.
2.1.4 Managed Objects
The ISO management model on which Solstice EM is based is object oriented. According to this model, a managed resource is represented as a managed object. A managed object is a software abstraction of a managed resource. The managed object presents information needed to manage the resource. A managed resource may be represented by a single managed object, or by several managed objects. An agent typically contains or provides views of many managed objects.
2.1.5 Management Protocols
A management protocol is a set of rules that specify how information shall be exchanged between two entities that are communicating, such as a manager and an agent. A management protocol provides the common language required to enable managers and agents to exchange information.
A management protocol defines:
- Types of messages that agents and managers are allowed to issue
- The syntax and encoding of each type of message
Solstice EM supports the following management protocols:
- Common Management Information Protocol (CMIP)
- Simple Network Management Protocol (SNMP)
- SunNet ManagerTM remote procedure call (RPC)
If the agents you want to manage use management protocols that Solstice EM supports, you do not need to take account of the management protocol when you use Solstice EM to develop applications.
Management protocol adapters (MPAs) perform protocol translation required to enable Solstice EM to support several management protocols. If you want to support a management protocol for which Solstice EM does not provide an MPA, you can extend Solstice EM by writing your own MPA for that protocol. For information on how to write an MPA, refer to Chapter 11.
2.1.6 Manager-Agent Hierarchy
Managers and agents are designed to be deployed in a hierarchy. A manager can also act as an agent to a higher-level system. This allows control of the network to be distributed throughout the network, while maintaining overall control of those aspects that are best managed centrally.
FIGURE 2-2 Manager-Agent Hierarchy2.2 Designing the Object Model
An object model defines the managed objects you want to control and monitor. It identifies:
- The features of managed objects that you want your application to control and monitor
- The control and monitoring operations you want to perform
- The relationships between the managed objects that you want your application to control and monitor
The object model is shared by the manger and any agents that the manager manages. If you are writing a manager for an existing agent, use the object model developed for the agent. In this case, do not write an object model specially for the manager.
To define managed objects in the Solstice EM environment, use the notation defined in ITU-T X.722/ISO-10165-4 Guidelines for the Definition of Managed Objects (GDMO).
This recommendation defines templates for the definition of managed objects. These templates specify the elements that should be included in the definition and the notation used to express each element. For information on the format of each template, refer to Appendix C.
To use GDMO notation to define managed objects, fill out the templates with relevant information and by using the appropriate syntax. Filling out GDMO templates involves:
- Defining the task
- Identifying managed object classes
- Identifying inheritance relationships
- Identifying the characteristics of a managed object class
- Describing the behavior of items in the object model
- Identifying containment relationships
- Grouping information into packages
- Identifying a GDMO definition
Solstice EM accepts GDMO specifications written by using a GDMO modeling tool such as Solstice GDMO Builder. EM also accepts GDMO specifications generated from Unified Modeling Language (UML) modeling tools.
2.2.1 Defining the Task
Defining the task identifies the management operations your application will perform. Defining the task involves:
- Identifying the monitoring and control operations you want your manager to perform on the resource
- Verifying the capabilities of the resource you want to manage
2.2.1.1 Identifying Monitoring and Control Operations - Example
The satellite example illustrates applications to manage satellites that broadcast several television channels, with each channel being received by one or more satellite dishes.
For a satellite, the following need to be monitored:
- Which channels the satellite is broadcasting
- The amount of data the satellite has to handle
- The quality of the signal to the satellite
- Whether the satellite is disabled or enabled
For a satellite, the following need to be controlled:
- The position of the satellite
- Whether the automatic navigation system for the satellite is engaged
- What happens to the satellite if the company is subject to hostile takeover effort
- Whether the satellite is locked, unlocked, or shutting down
For a channel, the following need to be monitored:
- Which dishes are receiving the channel
- The amount of data the channel has to handle
- The quality of the signal broadcast on the channel
- Whether the channel is disabled or enabled
For a channel, the following need to be controlled:
- Whether the main or backup transmitter should be used to broadcast the channel
- Which program is being broadcast on the channel
- How long an operator has to censor inappropriate scenes in a program broadcast on the channel
- Whether the channel is locked, unlocked, or shutting down
For a dish, the system needs to control whether access to the current program is blocked for the dish.
2.2.1.2 Verifying the Capabilities of the Managed Resource
When you have identified what you want to do, find out if it is possible. For example, check if you can find out the amount of data a satellite has to handle. To check, refer to developer's documentation, standards and other reference material for the resource you want to manage. If some of the information you require is not available, either modify your requirements accordingly, or put in place a way of obtaining the information.
2.2.2 Identifying Managed Object Classes
Managed objects are defined in terms of managed object classes. A managed object class is a definition of how all managed objects of a particular type should be implemented. Individual managed objects are referred to as instances of a class. An object class is defined once and reused thereafter for all objects of the same class.
Identify the managed object classes you need to represent your managed resources. In general, there should be one managed object class for each physical device you want to manage. You may also require a managed object class for each conceptual entity that you want to manage.
The purpose of the applications in the satellite example is to manage satellites that broadcast several television channels, with each channel being received by one or more satellite dishes. From this analysis, the following physical devices and conceptual entities can be identified:
- Satellite physical device
- Channel conceptual entity
- Dish physical device
CODE EXAMPLE 2-1 shows the definition of the dish managed object class in the satellite sample programs, expressed in GDMO notation.
CODE EXAMPLE 2-1 GDMO Definition of the dish Managed Object Class
This example shows that the dish managed object class:
- Is derived from, or inherits the characteristics of, a class named top defined in ITU-T X.721/ISO-10165-2 Definition of Management Information
- Is characterized, or defined, by the packages it contains, in this case the dishPackage package
2.2.3 Identifying Inheritance Relationships
New classes can be defined in terms of existing classes. The new class is a subclass of the class from which it is derived and may in turn have subclasses of its own. The class from which it is derived is called its superclass.
A subclass inherits all of the characteristics of its superclass. The inherited characteristics of the subclass can then be extended by adding new attributes, actions and notifications. In the ISO management model, it is not possible to delete of any of the characteristics of the superclass.
The ultimate superclass is the top object class, from which all other object classes are derived. This object class is specified by the OSI systems management model in ITU-T X.721/ISO-10165-2 Definition of Management Information and contains definitions for the attributes that are common to all object classes.
Whenever possible, derive the managed object classes you require from standard managed object classes, or from managed object classes that have already been generated for other purposes. In the satellite example, all three managed object classes inherit characteristics from the top managed object class. The inheritance tree for the satellite example is shown in FIGURE 2-3.
FIGURE 2-3 Example Inheritance Tree2.2.4 Identifying the Characteristics of a Managed Object Class
After you have identified the managed object classes you need, identify the characteristics of each managed object class. To identify the characteristics of a managed object class, think about how the information you want to retrieve, and the operations you want to perform, relate to the managed object class.
Identifying the characteristics of a managed object class involves creating, attributes, notifications, and actions.
2.2.4.1 Attributes
An attribute is a data element that is encapsulated in a managed object. Attributes reflect the state information that applies to a managed object. Each attribute corresponds to one of the characteristics of the resource that the managed object represents. An attribute has a name, a type, and one or more values that reflect the current status of the associated resource.
Note – The management operations permitted for an attribute are defined in the package definition of the managed object class that contains the attribute, not in the definition of the attribute itself. For more information, see Section 2.2.7 Grouping Information Into Packages.
In the satellite example, attributes are required for the satellite, channel and dish managed object classes as follows:
- satellite - TABLE 2-1
- channel - TABLE 2-2
- dish - TABLE 2-3
CODE EXAMPLE 2-2 shows the definition of the censureButton attribute.
In this example, the attribute named censureButton indicates whether the customer has activated the censure button. The type of this attribute is a custom-defined ASN.1 type named ButtonPress. This ASN.1 type is defined in an ASN.1 module named SAT-MAN-ASN1.
The ASN.1 syntax definition of ButtonPress is given in CODE EXAMPLE 2-3.
CODE EXAMPLE 2-3 ASN.1 Syntax Definition of the ButtonPress Data Type
ButtonPress ::= ENUMERATED {In this example, the censureButton attribute is an enumerated type. Its valid values are off (0), and on (1).
For information on ASN.1, refer to Section 2.3 Abstract Syntax Notation #1 (ASN.1).
2.2.4.2 Actions
An action is an operation that cannot be modelled by a pre-defined operation such as getting or setting an attribute. An action enables you to implement specialized behavior, for example, changing attributes of one or many objects in a single operation or providing the results of a query in a particular format.
No actions are defined for any of the managed object classes in the satellite example.
2.2.4.3 Notifications
A notification is an unsolicited message sent from a managed object that represents a managed resource. A managed object generates a notification when the application managing it needs to know that something has changed.
Managed objects can issue notifications in response to internal and external events. For example, a managed object may issue a notification in response to a timer timing out.
Notifications can be transmitted to manager applications in the form of event notifications, or logged internally. The type of notifications issued by a managed object and the conditions under which notifications are issued form part of its definition.
In the satellite example, notifications are required as shown in TABLE 2-4.
TABLE 2-4 Notifications for the Satellite Example objectCreation Signal when a new satellite, channel, or dish is added to the network management environment attributeValueChange Signal when an attribute of a satellite, channel, or dish changes objectDeletion Signal when a satellite, channel, or dish is removed from the network management environment
These notifications are defined in ITU-T X.721/ISO-10165-2 Definition of Management Information. For a complete list of notifications defined in ITU-T X.721/ISO-10165-2 Definition of Management Information, refer to TABLE 7-1.
CODE EXAMPLE 2-4 shows the GDMO specification of the objectCreation notification.
CODE EXAMPLE 2-4 GDMO Specification of the objectCreation Event
REGISTERED AS {joint-iso-ccitt ms(9) smi(3) part2(2) notification(10) 6};
Note – The notifications supported by a managed object are defined in the package definition of the managed object class. For more information, see Section 2.2.7 Grouping Information Into Packages.
2.2.5 Describing the Behavior of Items in the Object Model
The behavior of an item in the object model describes how the item reacts to internal and external events. It indicates the purpose of the item. The description of an item's behavior is similar to a comment in a programming language.
CODE EXAMPLE 2-5 shows the GDMO specification of the behavior of the packetRetries attribute.
CODE EXAMPLE 2-5 Behavior of the packetRetries Attribute
2.2.6 Identifying Containment Relationships
To enable applications to locate managed objects, the ISO model arranges objects in a hierarchical structure. This structure is called the management information tree (MIT), or the containment tree. One object can contain another. A containing (or superior) object may, in turn, be contained in another object. A superior object can contain more than one object, but a contained (or subordinate) object can only be contained in one superior object at a time. This restriction forces a tree structure on the hierarchy.
The ISO model defines a containment relationship in which the object below the root object is called the system object.
To design the containment tree for your object model, consider how managed objects relate to one another. The containment tree for the satellite example is shown in FIGURE 2-4.
FIGURE 2-4 Example MITThe containment tree is enforced by the naming scheme for managed object instances. The naming scheme uses name bindings to enable the relative and fully distinguished names of managed object instances to be computed.
2.2.6.1 Name Bindings
In GDMO, the naming scheme for managed object instances is defined by a name binding for a pair of managed object classes. A name binding defines the containment relationship between instances of each class in the pair. A name binding also provides additional definitions that govern the creation and deletion of managed objects.
Definition of a Containment Relationship
A name binding defines the containment relationship between instances of each class in a pair of by defining
- The subordinate object class in the containment relationship
- The superior object class in the containment relationship
- The naming attribute of the subordinate object class
The naming attribute is chosen to ensure that its value is unique for each managed object instance amongst objects that are subordinate to the same superior.
If a managed object class in a name binding is defined in a different GDMO document than the name binding, you must specify in which document the managed object class is defined.
To specify the document, prefix the managed object class name with the document name specified in the MODULE construct of the managed object class's GDMO specification--for example: "Rec. X.721 | ISO/IEC 10165-2 : 1992":system.
For information on GDMO documents, see Section2.2.8 Grouping GDMO Definitions Into Documents
Additional Definitions in a Name Binding
In addition to a containment relationship, a name binding defines:
- Whether instances of the subordinate object class are permitted to be created and deleted by management operation
- Rules for deleting instances of the subordinate object class that contain other managed objects
A name binding can also optionally provide information for the creation of an object under a superior object, such as:
- The identity of a reference object from which attribute values for initializing the new object are obtained
- An instruction that the name of the new object is automatically assigned
Example Name Binding Definition
CODE EXAMPLE 2-6 shows the definition of the satellite-system name binding.
CODE EXAMPLE 2-6 GDMO Definition of the satellite-system Name Binding
REGISTERED AS { satman-binding 1 };
- Instances of the satellite class can be contained by the class named system defined in ITU-T X.721/ISO-10165-2 Definition of Management Information.
- The naming attribute of satellite instances is satelliteId.
- Instances of the satellite class can be created under an instance of system by management operation.
- An instance of the satellite class can be deleted only if it contains no other objects.
Definition of Multiple Levels of Containment
A single name binding defines only one level of containment in the MIT. To define multiple levels, multiple name bindings are required. For example, consider the object model of the satellite example, which defines containment relationships between managed objects as shown in FIGURE 2-4.
CODE EXAMPLE 2-7 shows how the example MIT given in FIGURE 2-4 is expressed in GDMO notation. The root-system name binding is not shown here because it is defined in an ITU-T standard GDMO definition.
CODE EXAMPLE 2-7 GDMO Definition of the Example MIT
REGISTERED AS { satman-binding 1 };REGISTERED AS { satman-binding 2 };REGISTERED AS { satman-binding 3 };2.2.6.2 Names of Managed Object Instances
Managed object instances are identified by:
- Relative distinguished names
- Fully distinguished names
- Local distinguished names
Relative Distinguished Names
The relative distinguished name (RDN) of a managed object instance represents the location of the instance in the containment tree relative to its superior object instance. The naming attribute and its value provide the RDN of an object instance. The RDN is expressed in an attribute value assertion (AVA) as namingAttribute = "value".
For example, if the naming attribute of a managed object class is satelliteId and its value for an instance is NorthernLights, the RDN of the instance is satelliteId="NorthernLights".
Fully Distinguished Names
The fully distinguished name (FDN) of a managed object instance represents its unique location in the containment tree. The FDN is a concatenation of the sequence of RDNs from the root of the containment tree to the instance.
For example, consider a dish contained in a channel, which is in turn contained in a satellite. The satellite is contained in an instance of the system object, which is below the root of the containment tree.
The root of the containment tree is represented by a forward slash (/). The RDNs of the managed object instances are as follows:
- systemId="starless" (for the system object)
- satelliteId="NorthernLights" (for the satellite)
- channelId="HBO" (for the channel)
- dishId="Tic" (for the dish)
The FDN of the dish is /systemId="starless"/satelliteId="NorthernLights" /channelId="HBO"/dishId="Tic". The derivation of this FDN is shown in FIGURE 2-5.
FIGURE 2-5 Containment Tree and Object NamingLocal Distinguished Names
A local distinguished name (LDN) enables agents that cannot interpret FDNs to locate managed objects. The LDN of a managed object instance represents the location of the instance in the containment tree relative to a local root. A local root is any instance in the containment tree other than the root of the containment tree. Only one local root is allowed in a containment tree.
The LDN is concatenation of the sequence of RDNs from the local root to the instance. An LDN does not begin with a forward slash (/), unlike an FDN, which always begins with a forward slash.
For example, if the satellite named NorthernLights in the example in FIGURE 2-5 is defined as a local root, the LDN of the dish named Tic is channelId="HBO"/dishId="Tic".
2.2.6.3 Brace Notation for Relative and Fully Distinguished Names
Some Solstice EM tools require you to specify the FDN of a managed object instance by using brace notation instead of the slash notation described in Section 2.2.6.2 Names of Managed Object Instances. For example, the MIS Objects tool and the nickname service require you to use brace notation to specify FDNs.
In brace notation, each RDN is expressed as {{namingAttribute, value}}. A comma separates namingAttribute and value. If value is a string type (for example, an octect string) it must be enclosed in double quotes. The RDN is contained inside two pairs of braces. For example, if the naming attribute of an object class is satelliteId and its value for an instance is NorthernLights, the RDN of the instance in brace notation is {{satelliteId, "NorthernLights"}}.
To form the FDN, the RDNs are concatenated in a list as follows:
{1stRDN, 2ndRDN,... nthRDN}Each RDN is separated by a comma from the RDN that follows it. The entire list is enclosed in a pair of braces.
For example, the FDN of the dish named Tic in the example in FIGURE 2-5 is expressed in brace notation as: { {{systemId, "starless" }},&nb sp;{{satelliteId, "NorthernLights"}}, {{channelId,& nbsp;"HBO"}}, {{dishId, "Tic"}} }.
2.2.7 Grouping Information Into Packages
GDMO notation requires you to group the data for a managed object class into packages. Each managed object class must have a minimum of one mandatory package. A package defines which attributes, actions, notifications, and behaviors characterize each instance of the managed object class. The attributes, actions, and notifications themselves are defined separately.
However, the package definition does specify which management operations are permitted for an attribute when it is present in the managed object class. Depending on the operations permitted, attributes can be read to recover information about the associated resource, modified to alter the current state of the associated resource, or both.
It is also possible to define conditional packages, which are present or absent depending on the characteristics of the resource being managed. The conditions under which this package is present or absent form part of the managed object class definition.
Using conditional packages makes managed object classes more flexible. Every instance of a managed object class must contain all the mandatory packages, but by adding or removing conditional packages you can allow for variations without creating a new managed object class for every case.
CODE EXAMPLE 2-8 shows the specification of the dishPackage package, which is contained in the dish managed object class.
CODE EXAMPLE 2-8 GDMO Definition of the dishPackage Package
- The behavior of the dish managed object class is to contain attributes for monitoring customers who are using dishes.
- The following attributes are present in the dish managed object class:
- The the dish managed object class supports the following notifications defined in ITU-T X.721/ISO-10165-2 Definition of Management Information:
2.2.8 Grouping GDMO Definitions Into Documents
A GDMO document is a grouping of GDMO definitions applicable to a particular aspect of network management. Solstice EM requires that every GDMO definition is grouped into a GDMO document. You cannot insert anything other than blank characters and comments outside of a GDMO document.
The format of a GDMO document is as follows:
- document is the name of the GDMO document. It is a text string, starting with an upper-case letter. Every GDMO document must have a name. Assigning a name to a GDMO document enables EM to differentiate between items of the same name that are defined in more than one GDMO document.
- definitions are the GDMO definitions grouped into the GDMO document.
The MODULE and END keywords are mandatory. The MODULE keyword marks the start of the GDMO document. The END keyword marks the end of the GDMO document.
Note – The MODULE and END keywords are specific to Solstice EM. They are not part of the standard ITU-T X.722/ISO-10165-4 Guidelines for the Definition of Managed Objects (GDMO).
CODE EXAMPLE 2-9 shows how the GDMO document of the satellite example is named.
CODE EXAMPLE 2-9 Naming a GDMO Document
In this example, the GDMO document is named Satellite Manager.
2.3 Abstract Syntax Notation #1 (ASN.1)
In the Solstice EM environment, all information in management requests must be represented in a machine-independent format for transmission over a network. The format used is defined in ITU-T X.208/ISO-8824 Specification of Abstract Syntax Notation One (ASN.1). This standard defines a canonical form for representing all open systems interconnection (OSI) application data.
When using Solstice EM to develop applications, you need to write ASN.1 syntax definitions for all the custom data types in the GDMO definitions of your managed objects.
2.3.1 Grouping ASN.1 Syntax Definitions Into Modules
All ASN.1 syntax definitions must be grouped together into modules. You cannot insert anything other than blank characters and comments outside a module definition. There are no rules about module length or content. You are free to group definitions together in an appropriate way for your application.
The format of a module is as follows:
moduleRef { oid }DEFINITIONS ::=BEGINdefinitionsEND
- moduleRef is the module reference, or name, of the module. It is a text string, starting with an upper-case letter. Every module must have a module reference.
- oid is the object identifier (OID) of the module. The OID provides a universally unique identifier for the module, allowing other modules to refer to it. For more information on OIDs, refer to Section 2.4 Assigning Unique Identifiers.
- definitions are the ASN.1 definitions grouped into the module.
The DEFINTIONS and BEGIN keywords are mandatory, and mark the start of the module. The END keyword is mandatory and marks the end of the module.
The beginning and end of the satellite example ASN.1 module are shown in CODE EXAMPLE 2-10.
CODE EXAMPLE 2-10 Beginning and End of an ASN.1 Module
SAT-MAN-ASN1 { iso(1) org(3) dod(6) internet(1) private(4)In this example, the module reference is SAT-MAN-ASN1 and the OID of the module is { 1 3 6 1 4 1 42 2 55 }.
2.3.2 Defining ASN.1 Types
An ASN.1 Type is a data type defined using the ASN.1 notation.
The syntax of an ASN.1 type definition is as follows:
- typeRef is the type reference, or name, of the type you want to define.
- type is the type reference of an existing ASN.1 type.
2.3.2.1 Type Reference
Every type must have type reference. The type references of ASN.1 universal types are always written in upper case, for example INTEGER, or BOOLEAN. For information on ASN.1 universal types, refer to Section 2.3.2.3 Universal Types.
The type references of all other ASN.1 types must start with an upper-case letter, for example NewType.
2.3.2.2 Type
A new type must always be defined using an existing type. The existing type can be either an ASN.1 universal type, or another custom type. If the custom type is defined in a different module, you have to import its definition. For more information, see Section 2.3.4 Reusing Definitions From Other ASN.1 Modules.
Definition in Terms of an ASN.1 Universal Type
CODE EXAMPLE 2-11 shows the definition of an ASN.1 type in terms of an ASN.1 universal type.
CODE EXAMPLE 2-11 Definition of the CurrentLogSize ASN.1 Type
In this example, the CurrentLogSize type is defined to be of the INTEGER ASN.1 universal type.
Definition in Terms of Another Custom Type
A new type does not need to be defined using a universal type directly, but can be defined using another custom type. CODE EXAMPLE 2-12 shows the definition of an ASN.1 type in terms of another custom type.
CODE EXAMPLE 2-12 Definition of the SatelliteData ASN.1 Type
In this example, the SatelliteData type from the satellite example has been defined as a SET OF type, containing instances of the SatelliteSeq type. The definition of the SatelliteSeq type is shown in CODE EXAMPLE 2-13.
CODE EXAMPLE 2-13 Definition of the SatelliteSeq ASN.1 Type
SatelliteSeq ::= SEQUENCE {In this example, the SatelliteSeq type is composed of the values of name, value, and checkSum in that order. The name, value, and checkSum types are defined in other ASN.1 module specifications.
2.3.2.3 Universal Types
The ASN.1 types defined in ITU-T X.208/ISO-8824 Specification of Abstract Syntax Notation One (ASN.1) are referred to as universal, or built-in types. These are the building-blocks of ASN.1. All new ASN.1 types must be defined either directly or indirectly in terms of these universal types. TABLE 2-5 lists ASN.1 universal types.
TABLE 2-5 ASN.1 Universal Types Simple Types BOOLEAN One of TRUE or FALSE INTEGER A positive or negative whole number, can include zero ENUMERATED A defined set of values REAL Members of the set of real numbers BIT STRING An ordered sequence of zero or more bits. OCTET STRING An ordered sequence of zero or more octets, where each octet is an ordered sequence of eight bits NULL A single value, also called null OBJECT IDENTIFIER An OID Structured Types SEQUENCE A fixed, ordered list of types SET A fixed list of types, where order is not significant SEQUENCE OF An ordered list of zero or more values of the same type SET OF A list of zero or more values of the same type, where order is not significant Other Types CHOICE A fixed, unordered list of types, where the value of the new type is the value of one of the component types ANY A choice type whose component types are unspecified
2.3.2.4 Ranges of Allowed Values
If you need to limit the values of an ASN.1 type, you can specify a range of allowed values for the type. To specify a range, append the range in parentheses to the ASN.1 type definition. The upper and lower ends of the range must be separated by two periods (..).
CODE EXAMPLE 2-14 shows how a range of allowed values is specified for the Integer8 ASN.1 type. The Integer8 ASN.1 type is defined in the OMNIPoint 1 Definitions module (/opt/SUNWconn/em/etc/asn1/vol4.asn1).
CODE EXAMPLE 2-14 Specifying a Range of Allowed Values for an ASN.1 Type
In this example the Integer8 type is defined as an INTEGER type. Values of the Integer8 type must be in the range 0 to 255.
2.3.3 Defining ASN.1Values
An ASN.1 value is an instance of an ASN.1 type to which a value has been assigned. Define an ASN.1 value to simplify the assignment of OIDs or to specify a default value for all instances of an ASN.1 type.
The syntax of an ASN.1 value definition is as follows:
- valueRef is the value reference, or name, of the instance you want to define. To distinguish it from a type reference, a value reference starts with a lower case letter, for example, valueName.
- type is the type reference of an existing ASN.1 type.
- value is the value you want to assign to the instance.
CODE EXAMPLE 2-15 shows the definition of an ASN.1 value.
CODE EXAMPLE 2-15 Defining an ASN.1 Value
satman OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 42 2 55}In this example, an instance named satman of type OBJECT IDENTIFIER is assigned the value { 1 3 6 1 4 1 42 2 55 }.
2.3.4 Reusing Definitions From Other ASN.1 Modules
You can define new types or values using definitions from other ASN.1 modules, provided that these definitions have been imported. You can reuse definitions from standard modules or modules you have written yourself.
To reuse a definition from another ASN.1 module, import it into your ASN.1 module. To make a definition available to other ASN.1 modules, export it.
Note – The sections for importing and exporting definitions must come before ASN.1 type and value definitions in an ASN.1 module.
2.3.4.1 Importing a Definition
To import a definition, use the IMPORTS keyword immediately after the BEGIN keyword. The syntax for importing a definition is as follows:
FROM moduleRef { oid };
- definitionRef is the type or value reference of the ASN.1 definition you want to import.
- moduleRef is the module reference of the module that contains the definition you want to import.
- oid is the OID of the module from which you want to import the definition.
To import more than definition from the same ASN.1 module, list the definitions, separated by commas, before the FROM keyword. You can mix type and value definitions from the same module.
To import from several modules, repeat the FROM keyword before each module reference.
The IMPORTS section of the satellite example ASN.1 is shown in CODE EXAMPLE 2-16.
CODE EXAMPLE 2-16 Importing ASN.1 Definitions
Attribut e-ASN1Module {Integer32 FROM SYNTAX-1 { iso 3 14 2 2 0 1 };In this example, the SimpleNameType definition is imported from the Attribute-ASN1Module module and the Integer32 definition is imported from the SYNTAX-1 module.
2.3.4.2 Exporting a Definition
Exporting a definition makes it available to other ASN.1 modules. You can import a definition only if it has been exported from the module in which it is defined. By default, all definitions are exported.
If you want to restrict the list of definitions you export, include the EXPORTS keyword after BEGIN. If you include the EXPORTS keyword, only the definitions you list will be exported. To export no definitions from a module, include the EXPORTS keyword without providing a list of definitions.
The ASN.1 module for the satellite example does not include the EXPORTS keyword. Therefore, all definitions are exported.
The ASN.1 module for the ITU-T X.227/ISO-8650 Connection-Oriented Protocol Specification for the Association Control Service Element standard uses the EXPORTS keyword to export definitions as shown in CODE EXAMPLE 2-17.
CODE EXAMPLE 2-17 Exporting ASN.1 Definitions
2.4 Assigning Unique Identifiers
When you are exchanging data between different components of a managed system, you need a means of uniquely identifying items represented in the data. To identify an item uniquely, assign it an object identifier (OID).
2.4.1 Registering an OID
To ensure that an OID is globally unique, register it. A registered OID provides a globally unique identifier for each of the following:
- Managed object classes
- Attributes
- Actions
- Notifications
- Packages
- Name Bindings
- Parameters
- Attribute Groups
- Behaviors
- ASN.1 Modules
Registered OIDs are organized in a hierarchy known as the ISO registration tree. The ISO registration tree contains nodes labeled using nonnegative integer values and a text label. The top of this tree is called the root. There are three labeled nodes under root which are administered by the ISO and CCITT standards organizations. There are in turn sub-nodes under the three ISO and CCITT nodes. They are administered by ISO, CCITT, and other organizations
The OID of a node in the tree is a unique label formed by concatenating the labels of each node in the tree from root to the node. For example the OID for Solstice EM is {1 3 6 1 4 1 42 2 2&n bsp;2}. FIGURE 2-6 shows how this OID is arrived at.
To ensure that your OIDs are unique, apply to the relevant authority in your own country, typically the national standards body, to be allocated your own subtree of the ISO registration tree.
FIGURE 2-6 ISO Registration Tree2.4.2 Guidelines for Allocating Your Own OIDs
When you have been allocated a subtree of the ISO registration tree, define a convention to ensure that every item in the subtree has a unique object identifier.
To simplify debugging, put items of the same type in their own branch of the subtree. For example, allocate one branch to object classes, another to name bindings and a third to attributes. When you use a debugging tool such as em_debug, which identifies items only by their OIDs, it is easier to distinguish between object classes, name bindings, and attributes if they are in separate subtrees.
The OIDs of branches of the subtree for the satellite example are shown in CODE EXAMPLE 2-18. These OIDs are assigned in the ASN.1 module specification for the satellite example.
CODE EXAMPLE 2-18 OIDs for Branches of the Subtree in the Satellite Example
satman OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 42 2 55}satman-objectClass OBJECT IDENTIFIER ::= {satman 3}satman-package OBJECT IDENTIFIER ::= {satman 4}satman-binding OBJECT IDENTIFIER ::= {satman 6}satman-attribute OBJECT IDENTIFIER ::= {satman 7}In this example, OIDs are defined for branches of the subtree containing object classes, packages, name bindings, and attributes. These OIDs are used as the roots of OIDs for individual classes, name bindings and attributes as shown in CODE EXAMPLE 2-19. These OIDs are assigned in the GDMO definition of the managed objects for satellite example.
CODE EXAMPLE 2-19 OIDs for the Satellite Example
REGISTERED AS { satman-objectClass 1 };REGISTERED AS {satman-objectClass 2};REGISTERED AS { satman-binding 1 };REGISTERED AS { satman-attribute 1 };REGISTERED AS { satman-attribute 2 };2.4.3 Notation for OIDs
You must specify OIDs in your GDMO definitions and ASN.1 module specifications by using one of the following notation types:
- Dot notation
- Brace notation
To simplify the assignment of OIDs for items under a common node, you can assign a label to the OID of the node and use the label in assigning OIDs to items under the node.
2.4.3.1 Dot Notation
Dot notation uses the integer label for each node in the ISO registration tree from root to the node of interest, separated by periods. Dot notation has the advantage of brevity, but it can be difficult to read because it contains only integers.
For example, the OID for Solstice EM is written as 1.3.6.1.4.1.42.2.2.2 in dot notation.
2.4.3.2 Brace Notation
In brace notation, each node in the registration tree is identified by one of the following:
- The text label followed by the integer label in parentheses
- The text label alone
- The integer label alone
The OID is formed by concatenating the node identifiers, with each identifier separated by white space. The OID is enclosed in braces.
For example, the OID for Solstice EM can be written in brace notation as any of the following:
- {1 3 6 1 4 1 42 2 2 2}
- {iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) sun(42) products(2) management(2) em(2)}
- {iso org dod internet private enterprises sun products management em}
- {iso org dod internet private enterprises sun(42) 2 2 2}
2.4.3.3 OID Labels
An OID label is a text string that identifies an OID. Labelling an OID simplifies the assignment of OIDs for items under a common node. After you label the OID of a node, you can use the label in assigning OIDs to items under the node.
Note – OID labels are permitted only in brace notation.
CODE EXAMPLE 2-20 shows the assignment of a label to the OID of the satellite example.
CODE EXAMPLE 2-20 Labelling an OID
satman OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 42 2 55}In this example, the label satman is assigned to the OID of the satellite example. This OID is expressed in brace notation. CODE EXAMPLE 2-21 shows how the satman label is used in the assignment of an OID to a node under the satman node.
CODE EXAMPLE 2-21 Using an OID Label in an OID Assignment
satman-objectClass OBJECT IDENTIFIER ::= {satman 3}2.5 Obtaining GDMO and ASN.1 Specifications for Objects
To simplify the task of writing the object model, use existing specifications as the basis of your object model whenever possible. Depending on the resources you want to manage, consider using the following as the basis of your object model:
- Existing GDMO definitions
- SNMP MIBs
2.5.1 Existing GDMO Definitions
Standards bodies such as the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) have written GDMO definitions for managed objects common in network management. Before defining your own managed objects, consult published network management standards to see if the managed objects you require have already been defined.
If no suitable standard exists, but your object model is similar to an existing object model, you can use the existing object model as the basis of your new object model. Modify the GDMO definition of the existing object model by:
- Replacing the name of the document in the MODULE construct with the name of the new model
- Changing the names of managed object classes and attributes to reflect those you have identified for the new model
- Adding identifiers of GDMO documents to the names of items defined in other GDMO documents
- Changing the name binding definitions to define the containment tree you require
- Adding definitions of new attributes
- Changing OIDs to those allocated for your project
Note – If you obtain GDMO definitions and ASN.1 module specifications in a single file, put the GDMO definitions in a separate file from the ASN.1 specifications before you make your object model available to Solstice EM. Solstice EM does not accept a mixture of GDMO definitions and ASN.1 module in a single file.
2.5.2 SNMP MIBs
If you are managing SNMP agents, the object model of the agent will be expressed as an SNMP management information base (MIB). To manage an SNMP agent in the Solstice EM environment, the MIB of the agent must be represented as a GDMO document and an ASN.1 module specification.
To generate a representation of an SNMP MIB as a GDMO document and an ASN.1 module specification, use either of the following:
- Concise MIB compiler (em_cmib2gdmo)
- Load Data Definitions tool
The concise MIB compiler and the Load Data Definitions tool take an SNMP MIB as input and generates a GDMO document and an ASN.1 module specification suitable for loading into Solstice EM.
For information on how to use the concise MIB compiler and the Load Data Definitions tool, refer to the Management Information Server (MIS) Guide.
2.6 Making Your Object Model Available to Solstice EM
Making your object model available to Solstice EM provides the Solstice EM platform with information it requires to perform management operations on your managed objects. Making your object model available to Solstice EM involves:
- Loading your object model into the metadata repository (MDR)
- (Optional) setting agent role behavior of Solstice EM
2.6.1 Loading Your Object Model Into the MDR
In the Solstice EM environment, definitions of managed objects are stored in a metadata repository (MDR). To make your object model available to the Solstice EM environment, you must load it into the MDR.
Loading your object model into the MDR involves:
- Loading the GDMO specification by using the GDMO compiler (em_gdmo)
- Loading the ASN.1 module specification by using the ASN.1 compiler (em_asn1)
For information on how to use the GDMO and ASN.1 compilers, refer to the Management Information Server (MIS) Guide.
2.6.2 Setting Agent Role Behavior of Solstice EM
Setting agent role behavior of Solstice EM specifies how Solstice EM maintains managed objects. Managed objects are typically maintained by an agent. However, if you do not have a dedicated agent, you can use Solstice EM in an agent role to maintain managed objects. If you are using Solstice EM in an agent role, you must set its agent role behavior.
If your managed objects are maintained by an agent, all you need to do is load your object model into the MDR. You do not need to set agent role behavior.
Before you set agent role behavior of Solstice EM, make sure you have loaded your object model into the MDR.
Depending on your requirements, you can set:
- Default agent role behavior. The Solstice EM management information server (MIS) provides default agent role behavior based on the definitions in your object model. Setting default agent role behavior provides the MIS with information it requires about your object model.
- Custom agent role behavior. If you want define your own agent role behavior, use object development tools (ODT).
Setting default agent role behavior of Solstice EM involves:
- Loading managed object class definitions into the MIS
- Loading name bindings
Solstice EM also enables you to set default agent role behavior of Solstice EM in a single operation.
Note – The procedures in the following subsections explain how to set default agent role behavior from the command line. If you want to set default agent role behavior interactively, use the Load Data Definitions tool, as explained in the Management Information Server (MIS) Guide.
2.6.2.1 Loading Managed Object Class Definitions Into the MIS
Loading managed object class definitions into the MIS provides the MIS with information it requires to perform management operations on instances of the managed object classes.
How to load managed object class definitions into the MIS depends on whether you want your managed object class definitions to be volatile or persistent.
- If you want your definitions to be volatile, use em_compose_oc
- If you want your definitions to be persistent, use em_compose_poc
For information on how to use em_compose_oc and em_compose_poc, refer to the Management Information Server (MIS) Guide.
2.6.2.2 Loading Name Bindings
Loading name bindings provides Solstice EM with the information it requires to create and locate managed objects in the MIT. To load name bindings, use the em_load_name_bindings command.
For information on how to use the em_load_name_bindings command, refer to the Management Information Server (MIS) Guide.
2.6.2.3 Setting Default Agent Role Behavior in a Single Operation
If you want your managed object class definitions to be persistent, you can set default agent role behavior of Solstice EM in a single operation. To set default agent role behavior of Solstice EM in a single operation, use the em_compose_all script. This script is a wrapper that executes em_compose_poc and em_load_name_bindings.
For information on how to use the em_compose_all script, refer to the Management Information Server (MIS) Guide.
|
Sun Microsystems, Inc. Copyright information. All rights reserved. |
Doc Set | Contents | Previous | Next | Index |