1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- This document was generated using DocBuilder 3.3.3 -->
<HTML>
<HEAD>
<TITLE>Introduction
</TITLE>
<SCRIPT type="text/javascript" src="../../doc/erlresolvelinks.js">
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF00FF"
ALINK="#FF0000">
<CENTER>
<A HREF="http://www.erlang.se"><IMG BORDER=0 ALT="[Ericsson AB]" SRC="min_head.gif"></A>
</CENTER>
<A NAME="1"><!-- Empty --></A>
<H2>1 Introduction
</H2>
<P>The operation and maintenance support in OTP consists of a
generic model for management subsystems in OTP, and some
components to be used in these subsystems. This document
describes the model.
<P>The main idea in the model is that it is management protocol
independent. Thus, it is not tied to any specific management
protocol. An API is defined which can be used to write
adaptations for specific management protocols.
<P>Each OAM component in OTP is implemented as one sub application,
which can be included in a management application for the system.
Note that such a complete management application is not in the
scope of this generic functionality. Examples illustrating how such an
application can be built are included however.
<A NAME="1.1"><!-- Empty --></A>
<H3>1.1 Terminology</H3>
<P>The protocol independent architectural model on the network
level is the well-known <A HREF="part_term.html#Manager-Agent model">Manager-Agent model</A> . This model is based on the client-server
principle, where the manager (client) sends <A HREF="part_term.html#requests">requests</A> to the
agent (server), the agent sends <A HREF="part_term.html#replies">replies</A> back to the manager. There are two main
differences to the normal client-server model. First, there are
usually a few managers that communicate with many agents; and
second, the agent may spontaneously send <A HREF="part_term.html#notifications">notifications</A> to the
manager. The picture below illustrates the idea.
<P>
<CENTER>
<IMG ALT="terminology" SRC="terminology.gif"><BR>
<EM>Terminology</EM>
</CENTER>
<P>The manager is often referred to as the <A HREF="part_term.html#NMS">NMS</A> , to
emphasize that it usually is realized as a program that presents
data to an operator.
<P>The agent is an entity that executes within a <A HREF="part_term.html#NE">NE</A> .
In OTP, the network element may be a distributed system, meaning
that the distributed system is managed as one entity. Of
course, the agent may be configured to be able to run on one of
several nodes, making it a distributed OTP application.
<P>The management information is defined in an <A HREF="part_term.html#MIB">Management Information Base (MIB)</A> .
It is a formal definition of which information the agent makes
available to the manager. The manager accesses the MIB through
a management protocol, such as SNMP, CMIP, HTTP or CORBA. Each
of these protocols have their own MIB definition language. In
SNMP, it is a subset of ASN.1, in CMIP it is GDMO, in HTTP it is
implicit, and using CORBA, it is IDL. Usually, the entities
defined in the MIB are called <A HREF="part_term.html#MO">MO</A> , although these
objects do not have to be objects in the OO way,for example, a simple
scalar variable defined in an MIB is called a Managed Object.
The Managed Objects are logical objects, not necessarily with a
one-to-one mapping to the resources.
<A NAME="1.2"><!-- Empty --></A>
<H3>1.2 Model</H3>
<P>In this section, the generic protocol independent model for use
within an OTP based network element is presented. This model is
used by all operation and maintenance components, and may be
used by the applications. The advantage of the model is that it
clearly separates the resources from the management protocol.
The resources do not need to be aware of which management
protocol is used to manage the system. This makes it possible
to manage the same resources with different protocols.
<P>The different entities involved in this model are the <A HREF="part_term.html#agent">agent</A> which terminates the management protocol, and the
<A HREF="part_term.html#resources">resources</A> which is to be managed, i.e. the actual
application entities. The resources should in general have no
knowledge of the management protocol used, and the agent should
have no knowledge of the managed resources. This implies that
some sort of translation mechanism must be used, to translate
the management operations to operations on the resources. This
translation mechanism is usually called
<STRONG>instrumentation</STRONG>, and the function that implements it is
called <A HREF="part_term.html#instrumentation function">instrumentation function</A> . The
instrumentation functions are written for each combination of
management protocol and resource to be managed. For example, if
an application is to be managed by SNMP and HTTP, two sets of
instrumentation functions are defined; one that maps SNMP
requests to the resources, and one that e.g. generates an HTML
page for some resources.
<P>When a manager makes a request to the agent, we have the
following picture:
<P>
<CENTER>
<IMG ALT="snmp_model_1" SRC="snmp_model_1.gif"><BR>
<EM>Request to an agent by a manager</EM>
</CENTER>
<P>Note that the mapping between instrumentation function and
resource is not necessarily 1-1. It is also possible to write
one instrumentation function for each resource, and use that
function from different protocols.
<P>The agent receives a request and maps this request to calls to
one or several instrumentation functions. The instrumentation
functions perform operations on the resources to implement the
semantics associated with the managed object.
<P>For example, a system that is managed with SNMP and HTTP may be
structured in the following way:
<P>
<CENTER>
<IMG ALT="snmp_model_2" SRC="snmp_model_2.gif"><BR>
<EM>Structure of a system managed with SNMP and HTTP</EM>
</CENTER>
<P>The resources may send notifications to the manager as well.
Examples of notifications are events and alarms. There is a
need for the resource to generate protocol independent
notifications. The following picture illustrates how this is
achieved:
<P>
<CENTER>
<IMG ALT="snmp_model_3" SRC="snmp_model_3.gif"><BR>
<EM>Notification handling</EM>
</CENTER>
<P>The main idea is that the resource sends the notfications as
Erlang terms to a dedicated <CODE>gen_event</CODE> process. Into this
process, handlers for the different management protocols are
installed. When an event is received by this process, it is
forwarded to each installed handler. The handlers are
responsible for translating the event into a notification to be
sent over the management protocol. For example, a handler for
SNMP would translate each event into an SNMP trap.
<A NAME="1.3"><!-- Empty --></A>
<H3>1.3 SNMP based OAM</H3>
<P>For all OAM components, SNMP adaptations are provided. Other
adaptations may be defined in the future.
<P>The OAM components, and some other OTP applications, define
SNMP MIBs. All these MIBs are written in SNMPv2 SMI syntax, as
defined in RFC1902. For convenience we also deliver the SNMPv1
SMI equivalent. All MIBs are designed to be v1/v2 compatible,
i.e. the v2 MIBs do not use any construct not available in v1.
<A NAME="1.3.1"><!-- Empty --></A>
<H4>1.3.1 MIB structure</H4>
<P>The top-level OTP MIB is called <CODE>OTP-REG</CODE>, and it is
included in the <CODE>sasl</CODE> application. All other OTP mibs
import some objects from this MIB.
<P>Each MIB is contained in one application. The MIB text files
are stored under <CODE>mibs/<MIB>.mib</CODE> in the application
directory. The generated <CODE>.hrl</CODE> files with constant
declarations are stored under <CODE>include/<MIB>.hrl</CODE>, and
the compiled MIBs are stored under
<CODE>priv/mibs/<MIB>.bin</CODE>. For example, the <CODE>OTP-MIB</CODE>
is included in the <CODE>sasl</CODE> application:
<PRE>
sasl-1.3/mibs/OTP-MIB.mib
include/OTP-MIB.hrl
priv/mibs/OTP-MIB.bin
</PRE>
<P>An application that needs to IMPORT this mib into another
MIB, should use the <CODE>il</CODE> option to the snmp mib compiler:
<PRE>
snmp:c("MY-MIB", [{il, ["sasl/priv/mibs"]}]).
</PRE>
<P>If the application needs to include the generated
<CODE>.hrl</CODE> file, it should use the <CODE>-include_lib</CODE>
directive to the Erlang compiler.
<PRE>
-module(my_mib).
-include_lib("sasl/include/OTP-MIB.hrl").
</PRE>
<P>The following MIBs are defined in the OTP system:
<P>
<DL>
<DT>
OTP-REG (sasl)
</DT>
<DD>
This MIB contains the top-level OTP registration
objects, used by all other MIBs.
<BR>
</DD>
<DT>
OTP-TC (sasl)
</DT>
<DD>
This MIB contains the general Textual Conventions,
which can be used by any other MIB.
<BR>
</DD>
<DT>
OTP-MIB (sasl)
</DT>
<DD>
This MIB contains objects for instrumentation of the
Erlang nodes, the Erlang machines and the applications in
the system.
<BR>
</DD>
<DT>
OTP-OS-MON-MIB (os_mon)
</DT>
<DD>
This MIB contains objects for instrumentation of disk,
memory and cpu usage of the nodes in the system.
<BR>
</DD>
<DT>
OTP-SNMPEA-MIB (snmp)
</DT>
<DD>
This MIB contains objects for instrumentation and
control of the extensible snmp agent itself. Note that
the agent also implements the standard SNMPv2-MIB (or v1
part of MIB-II, if SNMPv1 is used).
<BR>
</DD>
<DT>
OTP-EVA-MIB (eva)
</DT>
<DD>
This MIB contains objects for instrumentation and
control of the events and alarms in the system.
<BR>
</DD>
<DT>
OTP-LOG-MIB (eva)
</DT>
<DD>
This MIB contains objects for instrumentation and
control of the logs and FTP transfer of logs.
<BR>
</DD>
<DT>
OTP-EVA-LOG-MIB (eva)
</DT>
<DD>
This MIB contains objects for instrumentation and
control of the events and alarm logs in the system.
<BR>
</DD>
<DT>
OTP-SNMPEA-LOG-MIB (eva)
</DT>
<DD>
This MIB contains objects for instrumentation and
control of the snmp audit trail log in the system.
<BR>
</DD>
</DL>
<P>The different applications use different strategies for
loading the MIBs into the agent. Some MIB implementations are
code-only, while others need a server. One way, used by the
code-only mib implementations, is for the user to call a
function such as <CODE>otp_mib:init(Agent)</CODE> to load the MIB,
and <CODE>otp_mib:stop(Agent)</CODE> to unload the MIB. See the
application manual page for each application for a description
of how to load each MIB.
<CENTER>
<HR>
<SMALL>
Copyright © 1991-2006
<A HREF="http://www.erlang.se">Ericsson AB</A><BR>
</SMALL>
</CENTER>
</BODY>
</HTML>
|
