To manage a l l entities i n a consistent man ner, we required a single, consistent method for structuring any m anageable component (regard less of its inter nal complexity) and for describing its management properties: the operations that it can perform, the variables it makes available for its management, the critical occurrences it can report to managers, etc. The El'vlA entity model was developed to answer these needs. The structure of a manageable compo nent in this model is shown in Figure 3. Essential ly, the entity model defines techniques for specifying an object-oriented view of an entity. Each entity has the fol lowing properties:
• A position within an entity h ierarchy. To ease
management of networks with large numbers
OPERATIONS
NOTIFICATIONS
{
l
SERVICE THE ENTITY PROVIDES CR EATE A MANAGED OBJECT AND DELETE (ENTITY)GET AND SET ATIRIBUTE ACTIONS EVENT BEHAVIOR REPORT
Figure
3
Structure of a Managed ObjectDigital Technical Journal Vol. 5 No. 1 If/inter 1993
Network Management
of complex components, entity classes are orga nized into logical structures that reflect the rela tionsh ip of their corresponding components; individual. entities are named i n terms of that structure. The name of the top -level entity i n each structure is global ly u n ique, and i t is referred to as a global entity. Al l i ts child entities, however, have names that are unique only within the context of their level in the structure. Therefore, they are referred to as local entities. • A h ierarchical ly structured name. An individual entity's local name is constructed by concatenat i ng its class name to its instance identifier. The class name is a keyword that uniquely identifies the class (object type) of an entity. The instance identifier is the value of an identifying attribute used for naming i nstances of the entity's class, for which each instance of the class has a unique value.
A target entity's globa l ly unique name is con structed by concatenating its local name (a <class name, instance identifier> pair) to the local names of each of its ancestors in turn, beginning with the containing global entity and endi ng with the target entity's immed iate parent. The construction of an entity's name and the containment h ierarchy are shown in Figure 4.
• A col l ection of i nternal state variables, cal led attributes, that can be read and/or modified as a result of management operations. At tributes have names unique within the context of the entity. Attributes have a type that defines the val ues the attribute can have.
• A col lection of operations that can be per formed by the entity. Operati ons al low man agers to read attribu tes, mod ify attribu tes, and perform actions supported by the entity. Actions are entity-specific operations that resu l t in changes of state in the entity or cause the entity to perform an operation that has a defined effect.
• A col lection of events that can be reported asyn chronously by the entity. An event is some nor m a l or abnormal condition within an entity, usu a l l y the resu l t of a state transition observed by its service element or its agent. Event reports are sent asynchronously to the manager; they i nd icate the type of (entity-specific) event that occurred and may also contain arguments that
DECnet Open Networking
NODE DEC UK REO MARVIN CLASS NODE
NAME = DEC . U K. REO. MARVIN STATE = ON . . . NODE DECUK. OSI TRANSPO REO.MARVIN RT
CLASS OSI TRANSPORT
CLASS ROUTI NG MAXIMUM WINDOW = 32
. . . NODE DEC:.UK. OSI TRANSPOR REO.MARVIN T PORT %X01 75A8D9 CLASS PORT NAME = %X01 75A8D9 PROTOCOL CLASS = 4
Figure 4 k/anaged Object Naming Hierarchy further describe o r qualify the event. For exam
ple, arguments could indicate the n umber of times the event occu rred before a report was sent to a nnou nce that a threshold was reached, or give the old a nd new states in an event that reports a state transition.
• A specification of the behavior of the entity in relationship to the functions that the entity's ser vice element provides. This is usua l ly specified as some abstract state machine, through pseudo code, or as a set of precond itions, postcondi tions, and i nvariants.
The entity model provides specific requirements and recom mendations about the way entities can be modeled in terms of these properties. These restric tions, placed on entity class definitions for p urposes of both interna l and global consistency, take several forms: (1) restrictions on the types and ranges of attr ibu tes that can be used for various purposes (e.g., as identifying or cou nter attribu tes); (2) con strain ts on operations (e.g., examine operations can have no side effects on the value of attributes whose values they report); or (3) restrictions on events (e.g., all events and event reports must have an associated time stamp and u nique identifier).
Readers familiar with open systems interconnec tion (OSI) management wil l find the entity model very similar to OSI 's structure of management infor m ation (SMl) standard:'' This is no coincidence. D u ri ng the early development of Phase V and the entity model, we recognized the need for a n open management architecture. Portions of the techno!-
1 20
ogy were therefore contributed to
JSO/IEC JTC
1 SC2 l/WG4, a working group of the International Organization for Standardization (ISO) that is responsible for efforts to define standards for OSI management. Al though some details ofOSI
SMI and the correspondingEMA
features diverged sl ightly from each other dur ing their evolution, the EMA entity model anclOS!
SMI are sti l l compatible. At this writing, work is u nder way to al ign certain parts of the EMA entity model with the final i n ternational standard (IS) versions ofOS!
SMI.Entities
The EMA entity model describes how to specify the management of an architected subsystem . How ever, for Phase
V,
we chose to make the manage ment specification of a subsystem a part of the subsystem's specification. As described in the Modu les section, that may have been the most important decision made in the network manage ment architecture.As the entities for DECnet/OSI Phase V were defined, a collection of fol klore grew on how typi cal design issues cou ld or should be solved. As with any fo l k lore, these guide l i nes were p assed from one architect to another, either verbally, or as selected portions of the management specifica tions were copied from one subsystem to another. This fol klore is continua l ly changing, as new and better solutions are found. Much of the fol klore has al ready been described 6 Some other guidelines are described below.
The Network Management Specification
describes the central str ucture of Phase V network
man agement, and in particular defines the node entity class.- In the fol lowing sections, we describe the properties of the node entity class and, as a representative example, the OSI transport module entity class.