GDMO - Guidelines for Definition of Managed Objects

Defining managed object constructs and behaviors for TMN and CMIP Based Systems

If you are either developing equipment intended for use by the major telecommunications service providers or are actively involved in standards targeted toward the ITU, you are likely to run across a need to either understand the content of information described in GDMO, or to develop new Management Information Bases using GDMO. GDMO provides a language for the definition of managed objects within TMN based systems. Over the last few months, we've been taking a look at the Telecommunications Management Network (TMN) strategies and concepts that are becoming more popular in the telecommunications arena. To develop management solutions using the TMN framework and CMIP services, the managed information base (MIB) is described using a schema called GDMO, which is short for Guidelines for the Definition of Managed Objects. GDMO, specified in ISO/IEC 10165 / ITU-T X.722 is a structured description language that provides a way of specifying the classes of objects, the object's behaviors, attributes and class ancestry. While loosely analogous to the SNMP Structures of Managed Information (SMI), the GDMO format is not derived from Abstract Syntax Notation One (ASN.1). However, it does make use of ASN.1 for definition of the syntax and encoding of attributes within the system.

Containment of information in GDMO is organized into managed Objects that contain: In reviewing the GDMO structure, we can first take a look at the templates defined within the standards for defining the objects. At the highest level, the template for the Managed Object Class is:


[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;

The DERIVED FROM clause specifies the superclass or superclasses from which this managed object is derived (inherited). With the exception of the managed object class "top," this term must be included. Typically, the highest level object classes, such as system and managed element, are derived from top. The characteristics of the superclasses are not repeated in the derived class definition.

Packages included in the object class definition are identified by the CHARACTERIZED BY and CONDITIONAL PACKAGES clauses. The CHARACTERIZED BY clause identifies the package or packages that are always present when the managed object is included in the system. The CONDITIONAL PACKAGES clause is used to identify those packages that may or may not be included each time the a managed object of this class is instantiated.

Finally, the REGISTERED AS clause identifies the location of the managed object class on the ISO Registration Tree.

Figure 1 - ISO Registration Tree

Moving forward, the meat of the information describing a managed object class is found in the package definitions. The definition of packages can typically be found either embedded into the MANAGED OBJECT CLASS definition, or as a standalone definition in the GDMO module. The template for the definition of packages is as follows:

<package-label> PACKAGE

[BEHAVIOR <behavior-definition-label> [,<behavior-definition-label>]*;]

[ATTRIBUTES <attribute-label> propertylist [,<parameter-label>]*

[,<attribute-label> propertylist [,<parameter-label>]*]*;]

[ATTRIBUTE GROUPS <group-label> [<attribute-label>]*

[<group-label> [<attribute-label>]*]* ;]

[ACTIONS <action-label> [<parameter-label>]*

[<action-label> [<parameter-label>]*]* ;]

[NOTIFICATIONS <notification-label> [<parameter-label>]*

[<notification-label> [<parameter-label>]*]* ;]

[REGISTERED AS object-identifier];

supporting productions

propertylist -> [REPLACE-WITH-DEFAULT]

[DEFAULT VALUE value-specifier]

[INITIAL VALUE value-specifier]

[PERMITTED VALUES type-reference]

[REQUIRED VALUES type-reference]



The BEHAVIOR clause is used to document the nature of the object being represented by this object. It contains readable text and does not contain any machine processable information. It typically serves as a textual description of the actual behaviors coded into the machine supporting this package.

The ATTRIBUTES and ATTRIBUTE GROUPS clauses identify all of the attributes that are to be included in the specified package. The specific semantics of the attributes are defined in the attribute definition template that is cross referenced by the attribute-label portion of the ATTRIBUTES or ATTRIBUTE GROUPS clause. Each attribute can optionally be referenced by a set of entries in the propertylist clause that constrain the content and access to the information. The properties that can be applied include: The ACTIONS clause identifies the actions that can be performed on objects containing this package. These can be defined either in-line or through a reference to a separate ACTION definition. Similarly, the NOTIFICATIONS clause identifies the notifications that a managed object based on this class can emit.

Moving forward, the ATTRIBUTE template defines the way in which atomic attributes are defined within GDMO. ATTRIBUTES are defined as follows:

<attribute-label> ATTRIBUTE


[MATCHES FOR qualifier [,qualifier]*;]

[BEHAVIOR <behavior-definition-label>


[PARAMETERS <parameter-label> [,<parameter-label>]*;]

[REGISTERED AS object-identifier];

supporting productions:




with-syntax-choice -> DERIVED FROM <attribute->label> |


The derived-or-with-syntax-choice clause is always included in the ATTRIBUTE definitions. If the DERIVED FROM syntax is used, the attribute is based on the identified superclass attribute, and the definition of the specified attribute extends on the superclass attribute. The matching rules consist of a logical OR of the matching rules specified in both the superclass and the newly defined attribute. The behavior definition should extend on any inherited behaviors. The WITH ATTRIBUTE SYNTAX term is used to specify the ASN.1 data type that defines the format of the attribute's information. Often, when defining a GDMO model, additional work must be done on the ASN.1 definition. Most automated tools that work with the GDMO modeling will also provide an ASN.1 compiler to complete the implementation of information modeling efforts.

The MATCHES FOR clause is used to support CMIP filtered operations. The CMIP filtered requests check each object and its corresponding attributes for a set of criteria identified in the filter clause of the CMIP request. The MATCHES FOR clause defines the tests that can be applied to the attribute. These can include tests for:

The PARAMETER clause provides a way to associate error parameters with the defined attribute's behavior.

Notifications are signals emitted by the managed objects. The template for defining notifications in GDMO is as follows:

<notification-label> NOTIFICATION

[BEHAVIOR <behavior-definition-label> [,<behavior-definition-label>]*;]

[PARAMETERS <parameter-label> {,<parameter-label>}*;]


[AND ATTRIBUTE IDS <field-name><attribute-label>

[,<field-name><attribute-label>]* ];]

[WITH REPLY SYNTAX type-reference;]

[REGISTERED AS object-identifier;

Where the BEHAVIOR clause is text describing the nature of the information conveyed when the notification is issued, as well as a description of the parameters included in the notification. The PARAMETERS field identifies information used to further describe the notification. WITH INFORMATION SYNTAX refers to the ASN.1 format for the information transmitted in the referenced notification. Similarly, the "WITH REPLY SYNTAX" identifies the ASN.1 syntax for the issuing of replies.

Finally, the ACTION template is used to define actions that can be requested of managed objects. Similar to object methods, actions can include arguments (in the form of parameters), and issue results. The template for actions is:

<action-label> ACTION

[BEHAVIOR <behavior-definition-label>



[PARAMETERS <parameter-label>[,<parameter-label>]*;]


[WITH REPLY SYNTAX type-reference;]

REGISTERED AS object-identifier

Where the behavior is a textual (not computer digestible) definition of the action, MODE CONFIRMED is an optional clause defining whether or not the action is handled as a confirmed operation. The PARAMETERS clause identify the parameters provided by the requester of the action when requesting the action. The INFORMATION SYNTAX and REPLY SYNTAX refer to the ASN.1 format for the transfer of the parameters in the action request.

As an example of the use of the templates, let's take a quick look at the M.3100 definition of a managed element, often the first object of entry to a device instrumented for TMN. This example is drawn from ITU recommendation M.3100:


DERIVED FROM "Recommendation X.721: 1992":top;


managedElementPackage PACKAGE


managedElementBehavior BEHAVIOR


"The Managed Element object class is…"



managedElementId GET,

"Recommendation X.721:1992":systemTitle GET-REPLACE,

alarmStatus GET,

"Recommendation X.721:1992":administrativeState GET-REPLACE,

"Recommendation X.721:1992":operationalState GET-REPLACE,

"Recommendation X.721:1992":usageState GET-REPLACE;


"Recommendation X.721:1992":environmentalAlarm,

"Recommendation X.721:1992":equipmentAlarm,

"Recommendation X.721:1992":communicationsAlarm,

"Recommendation X.721:1992":processinErrorAlarm;;;


createDeleteNotificationsPackage PRESENT IF "the objectCreation and

objectDeletion notifications defined in Recommendation X.721

are supported by an instance of this class."


REGISTERED AS {m3100ObjectClass 3}