A single computer system in the DECnet/OST network is cal led a node. The bounds of that system depend on the system's architectu re ; a personal computer (PC), a s ingle-processor workstation, a multiprocessor mai nframe, a diskless system, even a VAXcluster system can be considered a single node. Nodes are modeled by the node entity class.
A node entity has only a few functions in management.
• A node is a global ent ity that is the parent fo r many subsystems and provides an agent for a l l of them.
• A node has an identity, a name, and an address that al low it to be managed remotely.
• A node plays a major role in system ini tialization and starr-up.
Identity
The fol lowing attributes ident ify a node:
• An address, the application layer a<id ress(es) of the node's agent
• A name, a DECdns ful lname as defined by the DECnet/OSI distribu ted name serverH
• A synonym, a Phase IV -style node name for back
ward compatibil ity
• A spat ially u n ique iden tifier ( I D), a 48-bit quan
t ity used as a n Institute of Electrical and E lectronics E ngineers (IEEE) H02 local area network (LAN) or Ethernet address
• A space- and time-u n ique value
A node's address is the application l ayer add ress(es) of the node's agent. The DECnet/OSI network su pports mul tiple protocols at any of the seven layers, and the agent can operate over multi
ple protocol stacks. Each protocol has its own addressing conve ntions. Thus a node's address is actual ly a ser of protocol towers. Each tower defines a sequence of protocols, each with its asso
ciated addressing information. A protocol tower
Digital Technical joul-uaf Vol. 5 No. I Wi11ter 1993
Network 1l1a naf,ement
provides all the information needed by a director to con nect to the node's agent and to issue manage
ment d i rectives to the node or any of its children.
Users and network managers rarely refer to nodes by their addresses. First, it is di fficu lt to remember the addresses and second, moving the node from one place to another in the network gen
era l ly changes i ts address. Thus each node has a name, a DECdns fu l l name. The node knows its name and address. Each node's name is stored as a DECclns ent ry, and one of the entry's DECdns attributes holds the node's address. Thus, any director can look up the node's name in the DECdns and the address associated with it, and then use any one of the towers to connect to the node's agent.
To ensure backward compatibil ity with DECnet Phase rv, a node also has an attribute cal led its syn
onym, which is a sb;-character, Phase lV-style node name. If a node has a synonym name, that name is entered in a special directory in the DECd ns name space as a soft l i n k to the node's Phase V name. A soft l i nk is a form of al ias or indirect poin ter, from one name to another, that allows an en try to be reacJ1ed by more than one name.
Each network l ayer address of the node (a node can have more than one) is encoded in a standard way as a soft l i nk to the node's name. This a l lows a manager (or director) to translate a node address i nto the equ ivalent node name, making many diag
nostic problems much simpler.
D ECnet/OSI i ncludes many features that allow most nodes to au toconfigure their addresses.
Network layer addresses consist of an area address and a 48-bit ID. This ID can he obtai ned from an I D read-only memory (ROM) chip o n many dev ices (for exa mple, each Digital 802 3 LAN device has one).
End nodes detect area addresses from messages sent by the routers adjacent to the end node.
Higher-level addresses used by management are architectura l l y defined constants.
Managers and users choose the name and syn
onym of a node. The manager u ses the rename action to tel l the node its name. Rename is an exam
ple of a situation in wh ich an action is more appro
priate than a set operation. Renaming a node is a fairly compl icated operation. Not only is the name attribute changed, but also the information is stored in the DECd ns name space. Although the operation can fa il in many ways, actions al low errors to be reported to the manager with enough detail on what went wrong to a l low corrective action to be taken . This is not easily done with a set operation.
1 2 1
DECnet Open Networking
One of the more d ifficult configuration prob
lems to track down occurs when two nodes in a network have either the same nam e or the same address. DECnet/OSI has several management fea
tures to prevent this from occurring or to detect the situation when it does occur.
First, each node has a spatially u n ique 48-bit I D , i . e . , n o two nodes i n the enterprise have the same ID at the same time. The lD is usual ly derived from an ID ROM chip in a LAN adapter. Special manufactur
ing procedures ensure that no two 11) ROMs hold the same !D. Nodes with mu ltiple ID ROMs, for example a router with two Ethernet interfaces, choose one removed from one machine and inserted in another.
Indeed, this is a common diagnostic procedure.
Second, each node has a space- and time-unique value provided by the unique identifier (UID) ser
vice. U!Ds combine a spatially unique ID with a time stamp in such a way that no two generated U ! Ds will ever have the same value 9 The U I D is stored in nonvolatile storage (if the node has some), so the UID remains constant across system reboots. Nodes without nonvolatile storage will generate a new name when the disk where a node stores its system image, name , address, and UID is copied, and then node may be on the network.
Start-up
A node is responsible for system start-up. We model start-up through four states.
• Dead , when the node is clown and requ i res man
ual in tervention to start.
• Booting, when the node is in the initial stages of software start-up. The booting process is h ighly system specific and may be ini tiated by
tocol. 10 MOP is layered directly over the data l ink protocols. In Digital's commun ications devices, MOP is general ly implemen ted in the hardware or firmware and does not requ ire a working operating system.
• Off, when the node is i n itial izing itself and its internal configuration. When booting completes, the node changes to the off state. This transition is called the "big bang." I n the first i nstant after events a un ique identifier.
- The node entity (and possibly some of the node's ch ild entities) together with its agent (wh ich includes both the d irect ive dispatcher and event logging). management i nformation protocol (CMTP) requests. MOP can be used to clown-line load and/or reported as events.
• On, when the node has "completed" initial iza
tion to the extent that i t can be ma naged remotely. Somewhere in the initialization script (probably near the end), the node is enabled , configured within any particu lar node. Within the
Vol. 5 No. I Winter 199.5 Digital Technical journal
Network� Management
I
ENTITYIN ITIALIZATION
I
ENTITYS C R I PT
DIR ECTIVE
�
IN ITIALIZATION D I R ECTIVES DI SPATCH E R-f---.
ENTITYD I R ECTOR (PART OF
THE AGENT)
I I
EVENTSYSTEM OUTPUT TO CONSOLE LOGGING
CONSOLE OR EVENT LOG G I N G (PART O F (OPTIONAL)
T H E AGENT)
t I
EVENT R E PORTS TO CONSOLE
I
U I D SERVICEI
OR OTHER EVENT SINKS OTH E R EVENT
I I
SINKS TIME SERVICE
(OPTIONAL)
Figure 5 The Node at the "Big Bang"
modules are the various subsystems that make up DECnet/05! . A node never has more than one instance of a module contai ned within it. A general
p urpose node allows the manager to flexibly con
figure a node to serve a particu lar purpose by crea ting and deleting the appropriate modu les.
In the DECnet/OSI Phase V network, the specifi
cation of the m anagement of each mod u le is an integral part of the arch itecture of the su bsystem.
Moving responsibil ity for the management of a sub
system from a central network m anagement arch i
tecture to the subsystem architecture has m ade the specifications clearer and more complete. In Phase IV, a great deal of effort was spent coordi nating the subsystem specifications and the network m anage
ment specificat ion. Placing responsibil ity in one person's hands made writing an i n terna lly consis
tent subsystem much easier. Besides, the sheer size of DECnet/OSI Phase V manage ment would have made it i mpossible for a single person to design the management of the whole system.
The development of the 051 management stand ards i n ISO/C:ClTI (Comite ConsuJtatif lnter
nationale de Telegraphique et Telephonique) has been done in a similar way and for the same rea
sons. 150/IEC JTCl SC2l/WG4 is the group that has developed the OSI management information model, ma nagement specification language, and guide
l i nes for m odule devel opers. \Vhile 5C21/WG4 has itsel f also developed the management of srecific subsystems (e.g. , for event forwarding and logging), typical ly, the job of doing this has been left to other
Digital Technical jour11af v'!!l. 5 No. I IVinter I'J<J.)
groups more expert in p articu lar areas. For exam
ple, Working Groups 1 , 2, and 4 of iSO/IEC JTCl SC6 have developed management standards for the ISO data l i nk, network, and transport l ayers, based on D igi tal 's contributions derived from the OECnet/OSI Phase V work in these areas.
In DECnet/OSI, the transport, network, and data link subsystems were a mong the first to have the EMA concepts appl ied to their management. Others qu ickly tol lowed and , present ly, more than 50 mod
u les have been specified , with others being added as new subsystems are designed . Not surprisingly, du ring the early clays considerable interaction took place between the archi tects responsible for the central network management arch itecture and those responsible for developing the management of specific su bsystems. The EMA evolved and was refined based on the experiences of the many sub
system architects using it.
In a lmost all cases, modules contain one or more entit ies, each representing some management aspect of the subsyste m . These enti ties in turn m ay contain other entit ies (sube ntities). This nesting can occur to an arbitrary depth, reflecting the man
agement complexity of the subsystem. Note that modules themselves are entities, a l beit with the restriction that a node never has m ore rhan one i nstance of a module conta ined within it. An entity is formal ly described using Digita l 's Management Specifica tion Language (MSL) . 1 1
We next consider i n more detail the structure and contents of t he DECnet/051 Phase V 05I
1 23
DEC net Open Networking
transport module. Complete descriptions of this and other Phase V subsystems can be found in the D igital Network Architecture (Phase V) Documentation Kits. ' 2. 1.\. l,i. t>