Network management in DECnet/05! is bui l t on a number of supporting services. Wherever possible, management uses the services of the network to manage the network. This approach minim izes the number of special mechanisms we had to define specifically fo r network m a nagement. Some key services used by network management i ncl ude
l25
DECnet Open Networking
• Session control
• DEC:c.l ns name service
• Digital's cl istribu tecl time service (DECdts)
• A unique identifier service (UID)
A few serv ices were developed specifically to support network ma nagement. Most had existed i n earlier phases of DNA.
• D NA CMIP
• Event logging
• MOP down-line load protocol
• Appl ication loopback
In the foJ Jowing sections, we describe DNA CMIP and event logging.
Digital Network Architecture Common Management Infonnation Protocol
The entity model describes w hat a n entity can do.
Those concepts must be expressed in the manage
ment protocol. DNA CMIP, the management proto
col for DECnet/OSI Phase V, is an evol ution of the Phase rv management protocol (ca l le d NICE). The two protocols are remarkably similar. Both include the set, show (also cal led get), and event report operations. The main differences between the two protocols are in the fol lowing areas.
• Treatment of other ope rations. In NICE, each operation required a new kind of message; in CMIP, a general extension mecha nism, the action, is provided.
• Naming. NICE supported a l imited nu mber of entity cl asses (eight) and p rovided a rudimen
tary naming h ierarchy based on the notion of
" qua l i fying attribu tes." CMIP supports hierarchi
cal entity names and is essentially unl i mited in the nu mber of entities with which it can deal.
Similarly, CMIP is much more extensible in naming at tributes, attribu te groups, and event reports.
• Encoding. CMIP uses ISO Abstract Syn tax Notation I (ASN . l ), a standard tag, length , value (TLV) encod ing of attribu tes and arguments, and NICE used a private TLV encoding.
DNA CM IP is not qu ite the same as the rs version of OS! CMIP, a lthough it was based on the second d raft proposal of the CMIP standard. There are t wo reasons for this.
1 26
• First and foremost was timing. DNA CMI P was developed before the OSI CM IP was standardized.
The inevi table changes to the standard led to many minor differences in the protocols. Stil l , because the concepts i n the EMA entity model and OSI 's SJVH are aligned, the DNA and OSI CMII' protocols are fu ndamentally the same. The a u thors are currently m igrating DNA CMIP to OSI IS CMIP. The change wi l l be transparent to any user.
• Second, DNA CMIP operates over a DNA protocol stack, not a pure ISO stack. This al lows directors on Phase IV systems to manage Phase V systems.
DNA CMIP can be viewed as two separate proto
cols. One protocol , management information con
trol excha nge (MICE), is used by a director to invoke a direct ive (get, set, acti on, etc.) on an entity (or entit ies). The other protoco l , management event notification (MEN), is used by an entity (or entities) to report events to a director. The two protocols operate over separate connections for important reasons.
• The times at wh ich the associations are con
nected c.liffer. A M EN association is brought up when a n entity wishes to report an event, and is thus controlled by the agent. A MICE association, however, is brought u p w hen a director (or ma nager) wishes to invoke an operation on an entity, and is thus contro l led by the d irector.
Attempting to share control of association estab
lishment was not worth the complexity.
• Whenever an association is shared by two (i iffer
ent users, the problem of al locating resources fa irly to the two users must be addressed . Since tra nsport connections deal with this issue between connections, the addition of a multi
plexing protocol at the application level (with a n attendant flow control mechanism) was again considered to be too complex. Transport con
nections are not (or shou ld not be) expensive.
Event Logging
The entity emits an event report to the manager when an event occurs in an entity The event logging mod u le provides a service that transmits event reports from the reporting entities to one or m ore sink appl ications, which are considered to be a cer
tain kind of director in EMA. Event logging i n Phase V is based on concepts similar to those provided by Phase IV. Because the principal use of event logging is for repo rt ing fa ults, event logging does not
Vr;/. 5 No. I Winter 1993 Digital Tee/mica/ jounwl
guarantee del ivery of event reports to the sink appl ication. F igure 7 shows the event logging architectur e . 1 7
When a n event occurs within a n entity (E) i n a source node, the entity invokes the PostEvent ser
vice provided by the event dispatcher (a part of the node's agent). When posting an event, the entity supplies its name, the type of the event, all the argu
ments related to the event, a time stamp of when the event occurred, and a UID assigned to the event.
UIDs ensure that each event can be u niquely identi
fied, so that if a sink appl ication receives more than one copy of an event report, it can detect the dupli
cat ion. Time stamps a llow the event reports to be ordered in t ime (an i mportant step in determining causal ity). A time service (DECdts) is used to syn
chronize clocks across the network. It provides a consistent view of time for correlating observations.
An important feature for ma nagement is the inclu
sion of an inaccuracy bound on the time stamp.
The PostEvent service formats an event report and places it in an event queue (Q). Event queues are l imited in the amount of memory they use; thus they l i mit the number of events that can be held i n the queue. Because events can b e placed in the queue at a rate faster than the queue server (S) can process them, the queue can fi l l , and any new events placed in the queue will be lost. The events lost event is recorded as a pseudo-event in the queue (it appears as an event report from the entity holding the queue). The events lost event carries an argument that records the number of events that were lost in a row.
The queue server for the event dispatcher compares each event report against a filter (F) associated with an ou tbound stream. The fi l ter lists
SINK DIRECTOR
SINK APPLICATION INBOUND STREAM
00F
I NBOUND STREAM R DNA CMIP M E NNetwork Management
a col lection of entities and events that are either passed through the fil ter or blocked by the filter.
Event reports passing through the fil ter are placed in an event queue within the ou tbound stream.
Each outbound stream 's queue server sends events to a corresponding i nbound stream in the sink appl ication. M u ltiple ou tbound streams can be set up by the manager, al lowing events to be sent to many sink appl ications. Ou tbound streams are modeled as entities i n their own right, and standard management operations (create, get, set) are used to configure them.
Each inbound stream in a sink application has an event receiver ( R). I nbound streams are genera lly created when a connection request is received from an ou tbound stream. Events received by the receiver are compared against a sink fi lter and queued to the sink appl ication. Thus the events from mul tiple inboun_, streams are merged.
The protocol used between the ou tbou nd stream and the inbound stream is the CMIP MEN protocol, which operates over a connection (using either the DECnet transport layer protocol or OSI transport).
The use of a connection lowers the probabil i ty that an event report wil l be lost, since the connection hand les acknowledt5ments and retransmissions. It does nor guarantee delivery, however, and events may stil l be lost due to fa il ures of the sink appl ica
tion or the source node.
Conclusions
Our approach to Phase V management worked well . Defining the EMA entity model first provided a framework of consistency among all the architec
tures. Developing a management protocol (CMIP) expressing the basic concepts in the entity model
SOURCE NODE EVENT DI SPATCHER OUTBOUND STREAM
�
-11\
�F- "-011@:. �
OUTBOUND STREAM PROTOCOL
.�
LE;J
R
ANOTHER SINK DIRECTOR
Figure 7
Digital Technical journal Vol. 5 No. 1 Winte-r 1993
I
Event Logging
s)lllo
.""'----I� F
-ANOTHER SOURCE NODE
1 27
DECnet Open Networking
in conj u nction with the model placed the protocol in a position to meet t he needs of the model. Giving responsibility for defi ning the management of a subsystem to the architects of that subsystem made each subsystem more comrlete and coherent. As problems were found in the model. based on lessons learned during the specification of entities, any needed changes to t he entity model were applied to correct those problems.
However, some things d id not go as well. The nu mber of entit ies, attribu tes, and operations i n Phase V was beyond anyone's expec tations. This reflects the overall complexity and feature-richness of Phase V over Phase IV as wel l as the increased con trol that the manager is given. This burden is eased somewhat by the use of intell igent clefauJts, au toconfiguration, a nd self-ma nagement . Still, sim
pl ifying the management of a Phase V network is an important area for conti nual i mprovement.
The biggest success of EMA/Phase V management is its general applicability. E1\1A is bei ng appl ied to more than the trad itional network management areas. Systems, networks, and applications are all managed by EMA.
References
I . N . LaPel le, M . Seger, and M. Sylor, "The Evolu
tion of Network Ma nagement Products,"
Digital Tee/mica! Journal, vol. 1 , no. 3 (September 1986) : 1 1 7-12 8.
2 . ). Harper, " Overview of Digital's Open Net
working," Digital Tecl:micat journal, vol. 5, no. 1 ( Winter 1993, this issue): 12-20.
3. C. Strut t and J. Swist, " Design of the DECmcc Ma nagement Director," Digital Technical journal, vol . 5, no. 1 (Winter 1993, this issue):
1 30-142
4. OS! Management Information Seruices
Structure of Management information
Part 1: Management in{ormation Model, ISO/IEC DIS 1016'5-1 (Geneva : I nternational Organization for Standard ization/In terna
tional E1ectrotecbnical Com mission, 1990).
'5. OS! il!fanagernent inj()rmation Services
Structure of iVltmagement 'n{onnation Part 4: Guidelines j()r the Definition of Managed Objects, ISO/IEC DIS 10165-4 (Geneva: International Organ .. :arion for Stan
dard ization/intern ational Electrotechnical Com miss ion, 1992).
1 28
6. M. Sylor, "Gu ideli nes for Structuring Manage
able Entities," integnlled Network Manage
ment /, B . Meandzija and ]. Westcott (eels.), (Amsterdam: Elsevier Science Publishers,
1989): 169-183.
7 DNA Network Management Functional Specification, V5. 0. 0 (Maynard, MA: D igital Equipment Corporation, Order No. EK
DNA02-FS-001 , 1991 ) .
8. DNA Naming Service Functional Specifica
tion, V2. 0. 0 (Maynard , MA : D igital Equ ipment Corporation, Order No. EK-DNANS-FS-002,
1991 ) .
9. DNA Unique identijier Functional Specifica
tion, VJ. O. O (Maynard, MA: Digital Equipment Corporation, Order No. EK-DNA l -Fs-001 , 1992).
10. DNA Maintenance Operations Protocol Func
tional Speczfication, V4. 0. 0 (Maynard, MA:
D igital Equipment Corporation, Order No.
EK-DNA 1 1-FS-00 1 , 1992).
1 1 . DECmcc System Reference Manual, 2 volu mes (Maynard, MA: Digital Equipment Corporation , Order Nos. A A-PD5LC-TE, A A
PE55C-TE, 1992).
12. Digital Network Architecture (Phase V) Documentation Kit No. 1 (Maynard, MA:
D igital Equipment Corporation, Order No.
EK-DNAP1 -DK-00l, forthcoming 1993).
13. Digital Network Architecture (Phase V) Documentation Kit No. 2 (Maynard , MA:
Digital Equ ipment Corporation, Order No.
EK-DNAP2-DK-001 , 1993).
14. Digital Network Architecture (Phase V) Documentation Kit No. 3 (Maynard, MA:
D igital Equ ipment Corporation, Order No.
EK-DNAP3-DK-001 , forthcoming 1993).
15. Digital Network Architecture (Phase V) Documentation Kit No. 4 (Maynard, MA : Digital Equipment Corporatio n, Order No.
EK-DNAP4-DK-001, 1993).
16. information Technology - Telecommunica
tions and information Exchange Between Systems-Connection Oriented Transport Protocol Specification, ISO/lEC 8073 (Geneva:
International Organization for St andard iza
tion/International Electrotec hnical Comm is
sion, 1989)
Vol. 5 No. I Winter l'J'J3 Digital Techt�icaljounwl
17 DNA Event Logging Functional Specification, Vl. O. O (Maynard , MA : Digital Equ ipment Cor
poration, Order No. EK-DNA09-FS-001 , 1992).
General References
tll1A Entity Model (Maynard, MA: Digital Equipmen t Corporation, Order No. AA-PY7KA-TE, 1991 ).
M. Sy lor, " Managing DECnet Phase V: The E ntity Model," IEEE Networks (March 1988): 30-36.
S. Marti n , ]. McCann, and D. Ora n , " Development of the VAX Distribu ted Name Service," Digital Techni
caljournal, vol . 1 , no. 9 Oune 1989): 9-15.
Digital Technical journal Vol. 5 No. I Winter 1993
Network Management
C. Strutt and D. Shurtleff, "Archi tecture for an Inte
grated, Extensible Enterprise Management System,"
Integrated Network Management I, B. Meandzija and ). Westcott (eds.), (Amsterdam: Elsevier Sci
ence Publ ishers, 1989): 61 -72.
DNA Network Com mand Language Functional Specification, VJ. O. O (Maynard, MA: Digital Equip
ment Corpora tion, Order No. EK-DNAOS -fS-001, 1991 ).
L. Fehskens, "An Architectura l Strategy fo r E nter
prise Network Management," in tegrated Network Management I, B. Meandzija and ). Westcott (eds.), (An1sterdam: Elsevier Science Publishers, 1989):
41-60.
1 29