Understanding OSI Network Management
The object-oriented model is the key
William Stallings
Bill, an independent consultant and president of Comp-Comm Consulting, is the author of over a dozen books on data communications and computer networking. This article is based on his recent book, SNMP, SNMPv2, and CMIP: The Practical Guide to Network Management Standards (Addison-Wesley, 1993). He can be reached at [email protected].
It's rare indeed for organizations to maintain networks in which all workstations, PCs, routers, and associated gear are from a single vendor using a single operating system. Thus it becomes necessary to use some sort of vendor-independent network-management scheme to tie everything together for management and control. The most ambitious scheme, based on the open systems interconnection (OSI) model, is a set of standards for OSI-based network management, referred to as "OSI systems management."
A network-management system consists of one or more network-management stations that provide an operator interface for monitoring and controlling network activity, plus software in the various nodes of the network--workstations, bridges, routers, and the like--that interact with the network-management stations and respond to network-management commands. The foundation of any network-management system is a database (maintained at each node) containing information about the resources and elements to be managed. Typically, this database is referred to as a "management information base" (MIB). The general framework within which a MIB can be defined and constructed is the structure of management information (SMI). The SMI identifies the data types used in the MIB, and determines how MIB information is represented and named.
Key to understanding OSI systems management is an understanding of the SMI and MIB structure. This article explores the underlying concepts used in defining OSI MIBs and the types of management operations that can be performed on them.
Basic Concepts of the Information Model
OSI systems management relies heavily on object-oriented design. Each resource that's monitored and controlled by OSI systems management is represented by a managed object. The MIB is a structured collection of such objects. An object can be defined for any resource that an organization needs to monitor and/or control. Examples of hardware resources include switches, workstations, PBXs, LAN port cards, and multiplexers. Software resources include queuing programs, routing algorithms, and buffer-management routines. There are several points about managed objects you need to keep in mind:
- A managed object is an abstraction directly available to the systems-management function. Other system software, outside the scope of the OSI management standards, maintain the relationship between the managed object and the actual resource.
- A single managed object may represent a single resource, or many resources.
- The same network resource may be represented by a single managed object, or a number of different managed objects, each of which represents a particular aspect of the resource.
- Not all resources need be represented by a managed object.
- Some managed objects are defined solely for the support of management functions and do not represent resources--event logs and filters, for instance.
- Attributes visible at the managed-object boundary.
- System-management operations that can be applied to the managed object.
- Behavior exhibited by the managed object in response to management operations.
- Notifications that can be emitted by the managed object.
- Conditional packages that can be encapsulated in the managed object.
- Position of the managed object in the inheritance hierarchy.
Attributes
The actual data elements contained in a managed object are called "attributes." Each attribute represents a property of the resource that the object represents, such as the operational characteristics, current state, or conditions of operation. Attributes are commonly used for monitoring, with the attribute value reflecting the status of the underlying resource. An attribute can also be used for control, with the setting of an attribute value causing a change in the behavior or status of the underlying resource.
The data type of an attribute may be integer, real, Boolean, character string, or some composite type constructed from the basic types. In addition to a data type, each attribute has access rules such as read, write, read/write. There are also rules by which it can be located as the result of a filtered search (for instance, matching rules).
An attribute can be a simple scalar variable. Read (get) and write (set, replace) operations are possible on scalar attributes. Additionally, an attribute may be set-valued, consisting of an unordered, variable number (zero or greater) of elements, all of one type. In addition to read and write operations performed on all attributes, operations to add or remove elements from a set-valued attribute are possible.
Object Classes and Inheritance
A managed-object class is a template that defines management operations, attributes, packages, notifications, and behavior included in a particular type of object. All object instances that share these same elements are members of the same class. The individual object instances may differ in the values of their attributes. The class concept is thus a macro-type facility that allows a general type of object to be defined once, and allows that definition to be re-used many times for each actual instance of the object type.
More significantly, the class construct allows for the definition of new object classes in terms of existing classes, a process referred to as "specialization." A new object class is referred to as a "subclass" of the class from which it is specialized. The use of the subclass concept allows the development of a class hierarchy, with a subclass in turn having its own subclasses. This structure mirrors the actual structure of resources to be modeled in almost every case. The subclass retains characteristics of its superclass, a concept known as "inheritance." This minimizes the need to specify characteristics of individual objects.
In the OSI systems-management context, specialization is achieved by extending the characteristics of an object class in one or more of the following ways: the addition of new attributes; the extension or restriction of the range of an existing attribute; the addition of new operations and notifications; the addition of arguments to existing operations and notifications; and the extension or restriction of the ranges of arguments to operations and notifications.
Unlike a general-purpose object-oriented scheme, OSI systems management doesn't allow the definition of a subclass by deleting any of the characteristics of its superclass.
All object classes ultimately derive from a unique object class referred to as "top." This is the ultimate superclass, and the other object classes form an inheritance hierarchy with top as the root. Figure 1 is an example of a portion of an inheritance hierarchy.
Behavior
A managed object exhibits behavioral characteristics, including how the object reacts to operations performed on it, and the constraints placed on its behavior. The behavior of a managed object occurs in response to external stimuli (system-management operations delivered in the form of messages) and internal stimuli (events internal to the managed object and its associated resource, such as timers).
All managed-object instances of the same managed-object class exhibit the same behavior. The behavior defines the semantics of the attributes, operations, and notifications, the response to management operations being invoked on the managed object, the circumstances under which notifications will be emitted, the dependencies between values of particular attributes, and the effects of relationships on the participating managed objects
Notifications
Managed objects are said to emit notifications when an internal or external occurrence affecting the object is detected. Notifications may be transmitted externally in a protocol, or logged. Managing systems may request that some or all of the notifications emitted by a managed object are to be sent to it. Notifications that are sent to a manager or to a log are contained in an event report.
Containment and Naming
The object-oriented subclass facility allows for the creation of an inheritance hierarchy (Figure 1) that reflects the relationship among various types of objects. This hierarchy represents a convenience for defining a variety of object types with the minimum of text. It's also a useful structuring tool in designing objects for an MIB. However, the inheritance hierarchy does not reflect the structure of an actual MIB. This structure is defined using the object-oriented containment facility. The containment facility lets one object "contain" one or more other objects. Containment is achieved by including a reference to the subordinate (contained) object in the superior (containing) object. The reference is in the form of the object identifier of the subordinate object, and is stored as the value of an attribute in the superior object. A subordinate managed object may be contained in only one superior managed object, enforcing the condition that the MIB structure be a tree structure. A containing object may itself be contained in another object, allowing the construction of a tree of arbitrary depth. Thus, the MIB structure can directly model real-world hierarchical structures, such as assembly, subassemblies, components, or directory, files, and fields.
Just as there's a distinction between the inheritance hierarchy which defines the relationship among object classes and the containment hierarchy which defines the relationship among object instances in the MIB, there's also a distinction between the naming scheme for object classes and object instances. Each object class is registered in the registration tree and is identified by a unique object identifier. The object identifier is a sequence of integers that navigate through the registration tree of assigned identifiers to the managed object class. Figure 2 shows the top levels of the ISO/CCITT object identifier tree.
The naming scheme for object instances is completely distinct from that for object classes, and is dictated by the containment relationship. The naming scheme works as follows: Each managed object class includes an attribute that is used in naming instances of that object. The relative distinguished name of an object instance corresponds to a specific value of the naming attribute. This value must be unique among all objects that are subordinate to the same superior. The actual form of a relative distinguished name is an assertion that an attribute has a particular value, for example, MS-Id = "BDC" where MS-Id is the name of the attribute and "BDC" is the desired value. The distinguished name of an object instance is formed as the sequence of relative distinguished names from the root of the containment tree to this object.
Figure 3 shows a containment tree. A managed object instance name (the value of the naming attribute) is created when the instance is created. These names don't have to be registered or made public. They do have to be exchanged between interoperating managed systems to permit access to the object. Also, although the naming scheme is based on containment, not all forms of containment are necessarily used for naming. Containment can be used to create pointers between object instances that reflect the structure of the MIB and that go beyond a simple tree structure.
The ISO registration tree is a naming tree which registers the definition of managed objects, attribute definitions, actions, notifications, and packages. You can think of the registration tree as a dictionary or library of "stubs" stuck into new managed object class definitions. Since they're registered, the stubs have well-known names and agreed-upon semantics. This illustrates the benefit of object-oriented reuse.
The inheritance tree (see Figure 1) shows how the definition of object classes is derived from other object classes using object-oriented principles. Inheritance allows for reuse of a object class structure, with refinements to define a related but distinct object class.
Finally, the containment tree is the MIB structure. It shows the objects an agent contains and the hierarchy/containment of those objects. This tree is used not only to define the MIB structure but as a means of unambiguously referencing object instances.
Systems-management Operations
The definition of the management-information model includes a specification of the operations that may be performed on objects. These operations are performed by a management entity by means of a message sent to the object, using a network-management protocol. Systems-management operations apply to the attributes of an object or to the managed object as a whole. An operation performed on a managed object can succeed only if the invoking managing system has the access rights necessary to perform the operation, and consistency constraints are not violated.
Management operations apply to attributes of an object and to the object as a whole.
Attribute-oriented Operations
There are a number of operations that may be sent to an object to be applied to one or more of its contained attributes, including get-attribute value, replace-attribute value, set-attribute value to default, add member to a set-valued attribute, and remove member from a set-valued attribute.
Any operation may request that the same function be performed on a list of attributes. For example, an operation to replace attribute values could specify a list of attributes with the new value for each attribute. An operation may specify that the individual operations are to be performed atomically; that is either all operations succeed or none are performed.
If atomic operation is not requested, the managed object will attempt the individual operation on each attribute in the list of attributes for which the operation is requested. As a result of the operation, the object will report the attribute identifiers and their associated values for those attributes whose values could be operated on, and error indications for those attributes that could not be operated on.
Object-oriented Operations
The create, delete, and action operations apply to managed objects as a whole. The semantics of these operations are part of the definition of the managed-object class. In particular, the effect of these operations on other related managed-objects (for example, superior or subordinate objects) must be specified.
Central to the concept of automated network management is a requirement that the resources to be managed and the actions that can be taken are represented in a systematic way. The object-oriented approach used for OSI systems management provides a flexible foundation for meeting this requirement.
Defining Managed Objects
The OSI systems-management standard includes a specification for the format of definitions for managed objects and their attributes. The specification consists of a set of templates, which are standardized formats to be used in the definitions. The templates summarize the elements that should be included in a definition and the notational tools that are recommended to be used in the definition. Templates are constructed using these conventions:
- Terms in uppercase letters in the template appear in the definition in the same form.
- Terms in lowercase letters in angle brackets are variable names; the actual name is substituted in the definition.
- Terms in square brackets are optional.
- Terms in square brackets followed by an asterisk may appear zero or more times.
The CHARACTERIZED BY construct allows one or more mandatory packages to be included in the object-class definition. The CONDITIONAL PACKAGES construct allows one or more conditional packages to be included.
As an example, consider an object-class definition from the standard which defines transport-layer management. One of the definitions is for the managed-object class for the connection-oriented transport-protocol machine; see Listing Two (page 77).
This managed object contains key parameters for monitoring the operation of a transport-protocol entity in a managed system. Note that a number of the defined attributes are grouped together for convenient access to the counters as a unit.
--W.S.
Figure 1: Inheritance example.
Figure 2: Top-level object-identifier assignments.
Figure 3: Transport-layer managed object-containment structure.
[LISTING ONE] <class-label> MANAGED OBJECT CLASS [DERIVED FROM <class-label> [,<class-label>]* ; ] [CHARACTERIZED BY <package-label> [,<package-label>]* ; ] [CONDITIONAL PACKAGES <package-label> PRESENT IF condition-definition [,<package-label> PRESENT IF condition-definition]* ; ] REGISTERED AS object-identifier ; supporting productions[LISTING TWO]
<a name="037e_0011">
comodePM MANAGED OBJECT CLASS
DERIVED FROM "ISO/IEC 10165-2":top;
CHARACTERIZED BY comodePM PACKAGE
ATTRIBUTES
coPMName DEFAULT VALUE TLM.null-MO-Name-Value
PERMITTED VALUE TLM.null-MO-Name-Syntax
REQUIRED VALUE TLM.null-MO-Name-Syntax GET,
"ISO/IEC 10165-2":octetsSentCounter GET,
"ISO/IEC 10165-2":octetsReceivedCounter GET,
"ISO/IEC 10165-2":incomingProtocolErrorsCounter GET,
openConnections GET
maxConnections REPLACE-WITH-DEFAULT
DEFAULT VALUE implementation dependent GET-REPLACE
localSuccessfulConnections GET,
remoteSuccessfulConnections GET,
localUnsuccessfulConnections GET,
remoteUnsuccessfulConnections GET,
localErrorDisconnects GET,
remoteErrorDisconnects GET,
unassociatedTPDUs GET,
maxOpenConnections REPLACE-WITH-DEFAULT
DEFAULT VALUE see attribute behavior GET;
ATTRIBUTE GROUPS
TLPMCounters
openConnections
localSuccessfulConnections
remoteSuccessfulConnections
remoteUnsuccessfulConnections
localErrorDisconnects
remoteErrorDisconnects
unassociatedTPDUs
maxOpenConnections;;;
REGISTERED AS { TLM.moe comodePM (4) } ;
Copyright © 1993, Dr. Dobb's Journal
