Subject: ITU alarming and general alarming

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 1 Mar 2001 18:09:52 -0600

So far, every alarm model presented has either been designed to
accept only ITU alarms (the original Active Alarm MIB, Anni's Condition MIB)
or to treat ITU alarms as a superset of their functionality (current Alarm
MIB, Dave's alarm MIB).  I propose a different path - treating ITU alarms as
a subset of a generic model.

	While this may at first sound like the inception of a monster, I
think that a few good reasons have emerged lately for creation of a generic
model: the necessity of having common information structure for all alarms
to facilitate ARC functionality and the undesireability of creating new MIBs
to support variations in alarm behavior come immediately to mind.  Also, I
think that the result will be neither as big or as scary as it would at
first seem.

	The idea is that for each object in the ITU model that we support,
we create an object which has the ITU allowed values as a starting point,
reserves extra room so that we can, as needed, define new standard values,
then has a (large) defined range for user defined values, so that individual
models can be adapted into the framework while still using the framework
itself.

	Here are some examples:

originatorEngineId (Managed object class/Managed object instance)

originatorObjectId (Managed object class/Managed object instance)
	This is an OID intended to indicate the source of the alarm within
	the managed unit.  Since I have not yet read the Entity MIB, this
	probably needs to be modified.

alarmType (Event type)
	An OID object.  Values for the 10 ITU Event types are predefined.
	Another 990 types can be reserved, with types 1001-5000 open for
	user definition.

alarmTime (EventTime)

probableCause (Probable cause/Security alarm cause)
	Similar to exisiting proposals, but we define 1-75 as the ITU
	probable causes, reserve 76-10000 for future expansion, and
	throw open 10001-50000 for user defined values.  Plenty of room
	for everyone!

perceivedSeverity (Perceived severity/Security alarm severity)
	Again, predefine the ITU states, reserve a bunch, and leave a big
	bunch open for user definition.

trendIndication (Trend indication)
	Note that the severity model as described above makes this value
	a nontrivial computation.  Do we want a table that can be used
	to order the severity of perceivedSeverity values so that this
	value can be calculated automatically?

detector (Security alarm detector)
	would originatorEngineId + originatorObjectId suffice for this?

serviceUser (Service user)

serviceProvider (Service provider)

additionalText (Additional text/Additional information)
	Note that this field should be a full length octet string with a
	UTF-8 TC.

	Are there any other fields that we would need to have to not only
support ITU alarms, but most conceivable alarms?  What about the idea of
using additional text with (ducking) standardized XML tags to convey the
information for detector, serviceUser, serviceProvider, etc.  This could
prevent object proliferation, which has been a bit of a concern, I think.

/|/|ike /+yers
Test Engineer
BMC Software
                                             Beware of geeks bearing gifts.

---

From: Lauren Heintz <[email-masked]>
Date: Thu, 01 Mar 2001 17:01:15 -0800

Some customers I've known insisted on
having alarm S/Ns.  I.e. each alarm
has a guaranteed unique S/N that is
one greater than the previous alarm,
so that if the mgr detects a gap (i.e.
a UDP trap was lost) the mgr can react
and retrieve the missing info.  Wrapping
was not something to worry about.

I suppose this is more important when
considering use of notifications over
"unreliable" transports, and perhaps
it could be considered to be a problem
to be solved in the transport domain more
than the alarm domain.

Now, such a S/N could in reality be
a PDU msgId (though I think there
may be conformance issues with this)
or even a table index, such that when
objects are uncluded in notification
varbinds, the S/N is implicitly included
as part of the object name.

Also, these same customers probably would
object to the large number of varbinds
the below list implies would be included
in a notification, so perhaps some of those
attributes may not be not forwarded in a notification.

They also objected to including "text" (assuming
this is the same as a description) as varbinds
because they suggested that mapping specific alarms
to OIDs or enums obviated the need to transport the text
over the network at all (i.e. the act of loading
the MIB gave them all the "descriptions" they needed).
Of course, this caused large numbers of OIDs or enums
to be created.

That brings me up to about $0.03 today
and I'm going broke fast!

Thanks,
Lauren