X.733 SNMPv1 trap definition
Martin Weiss
who knows a de-facto standard how SNMPv1 TRAPS must look, to be X.733
compliant?
Is there a unified TRAP definition available?
Thanx!
/martin
--
Martin Weiss martin...@aheadcom.com
Ericsson AheadCom, Vienna
Olivier Miakinen
>
> who knows a de-facto standard how SNMPv1 TRAPS must look, to be X.733
> compliant?
> Is there a unified TRAP definition available?
I don't know what X.733 is. If nobody answers your question, maybe it's
for the same reason, and you should explain.
--
Halte aux abus du mail : <http://marc.herbert.free.fr/mail/>
Au fait, merci de ne pas doubler par mail une réponse faite dans les
news, et sachez que je n'ai pas de quoi lire des documents utilisant
des formats propriétaires : word, excel, powerpoint, etc.
Martin Weiss
contents of alarms but it does not deal with SNMP or any other protocols.
What I want to know is, if there is a de-facto mapping of X.733 information
into SNMPv1 traps.
/martin
Olivier Miakinen wrote in message <38B522EC...@bull.net>...
Olivier Miakinen
>
> ITU-T X.733 is a standard for alarm reporting functions. It defines the
> contents of alarms but it does not deal with SNMP or any other protocols.
Thank you for the explaination.
> What I want to know is, if there is a de-facto mapping of X.733 information
> into SNMPv1 traps.
I think that the answer is no.
dper...@snmpinfo.com
Take a look at the MIB modules defined by the ATM forum. I believe
that they have done something that you could adapt. However, I find
that X.733 has problems and it looks abandoned (uncompleted) by its
authors. So, you could get some ideas from it, but I would NOT
use it as FACT.
Regards,
/david t. perkins
On Thu, 24 Feb 2000, Martin Weiss wrote:
> ITU-T X.733 is a standard for alarm reporting functions. It defines the
> contents of alarms but it does not deal with SNMP or any other protocols.
> What I want to know is, if there is a de-facto mapping of X.733 information
> into SNMPv1 traps.
>
> /martin
>
>
>
> Olivier Miakinen wrote in message <38B522EC...@bull.net>...
> >Martin Weiss wrote:
> >>
> >> who knows a de-facto standard how SNMPv1 TRAPS must look, to be X.733
> >> compliant?
> >> Is there a unified TRAP definition available?
> >
> >I don't know what X.733 is. If nobody answers your question, maybe it's
> >for the same reason, and you should explain.
> >
Martin Weiss
To sum it up with my words:
There is NO de-facto standard for X.733 SNMP-traps. Every SNMP-manager
(client) has to do it's own decoding for received traps. You can't find a
generic X.733 trap monitor, which is able to display the contents of X.733
traps.
/martin
dper...@snmpinfo.com wrote in message ...
dper...@snmpinfo.com
On the message below, I find the latest posting a little confusing,
so let me respond again...
X.733 defines a model for reporting alarms on managed systems using
the notification operation from the CMIP protocol. The operands
of the CMIP notification operations are event data defined using
CMIP's data definition language. It is possible for a person to
take such a document and create one or more MIB modules that
define in the SNMP data definition language (which is defined in RFCs
2578-2580, and called SMIv2) objects and notifications that provide
similar capability. However, no IETF WG has taken on this task.
Is it possible to do? - sure
Is it worth to do? - maybe
Has anyone done it? - I believe the the ATM forum has done some work
in this area. Also, I've done some work in this area.
Are there problems? - yes, the biggest is that I believe the model
and the x.733 document are confused and appear incomplete. Part
of the problem, I believe, is the lack of common terminology
in the industry. For example, a MAJOR network management platform
vendor added support for alarms to their event management system
by saying that events and alarms are the same thing! (Most
in the industry make a major distinction between events and
alarms. The standard terminology is that events are occurances
of something of interest to management. These may be a change
in configuration. An event is not the same as a fault. On the
other hand, an alarm is a persistent fault condition. The
start of the fault condition, as well as the ending of the
fault condition are events.) I could continue on this topic
for maybe a short book worth of material.
Can a person easily take the X.733 document and convert it
to SNMP MIB definitions. - This is not an easy task. I believe
it requires a lot of time and experience.
Hope this helps..
Regards,
/david t. perkins
On Mon, 28 Feb 2000, Martin Weiss wrote:
> Ok guys!
>
> To sum it up with my words:
>
> There is NO de-facto standard for X.733 SNMP-traps. Every SNMP-manager
> (client) has to do it's own decoding for received traps. You can't find a
> generic X.733 trap monitor, which is able to display the contents of X.733
> traps.
This is confusing to me. The parsing of SNMP messages and the information
model are two separate issues. There is no such thing as "x.733 traps".
stefan wallin
frameworks.
Telco mgmt frameworks often works in that way that different type of alarms
from
different type of equipment and even different mgmt protocols are mapped
into one
single format within the the framework.
That format, like it or not, is X733.
Basically an X733 alarm contains:
- Notification Id
- Managed Object Class and instance
- EventType
- ProbableCause
- Severity
- Specific problem
- AdditionalText
- Correlated Notification Id
- ...and some more...
When mapping traps to an X733 alarm two approaches are possible for
every single variable:
Static mapping : this implies that the manager based on the received
Generic/Specific Trap
injects the mapping. For example every linkDown is mapped to
EventType : Communications, Severity: Major etc.
In order for this mechanism to work the MIB must contain fine grained trap
definitions so that the mapping
can be done per single trap without knowing the contents of any trap
varbind.
Dynamic mapping : this implies that the var bind list contains a variable
which can be used as value for the X733
variables. Lets say that the trap has a varbind severity, of course then the
manager can take that value and use it
as X733 severity. A problem usually is that the actual values are different.
In X733 severity is an enum 0-5. Some managers
can not do value mapping which implies that the agent must have exact the
same enum.
In reality there is always a combination of static and dynamic mapping.
Some notes on each variable:
Notification Id:
It is preferrable that the agent sends a sequence number in each trap so
that traps can be identified in a trap log
missing traps can be detected etc.
Managed Object:
The "resolution" of MO is often an issue. A default trap mechanism usually
uses the IP Adress/Node name
as MO. This is however not acceptable for many customers. Rather somehting
like Subrack, Slot, Port etc
are required as MO. This implies that the trap must send an index to a table
or an instance pointer/row pointer in the trap.
For example the linkDown carries the ifIndex of the disabled interface. The
manager then should use this information to index
the table and present e.g. ifName as MO.
Another ugly problem is when proxies are involved. The default trap
reception then has the proxy agent and not the underlying equipment
as MO. This must be handled by either trap var binds or community names.
Event Type and probable cause are often mapped statically since it is not
likely that valid values will be sent from the agent.
There is also a problem with probablecause that its an enum started at zero
in different documents. Both X733 and M3100 starts at zero...
Additional Text can in most cases be mapped dynamically, take more or less
all trap variables and put into the text field.
That was all regarding mapping.
An issue that must not be forgotten is that X733 requires that alarms are
cleared when the fault appears. This is often a fatal problem
in most MIB's. We need a consistent mechanism for sending trap A to indicate
the fault and trap B to indicate that the fault has ceased.
There are typically three alternatives in SNMP traps:
a) a pair of traps like linkDown, linkUp. linkUp is then mapped to severity
clear.
b) every trap carries a seq number. There is ONE generic clear trap with a
var bind that points to the original alarm.
c) classical X733, send a trap with same MO, EventType, ProbCause but with
severity = clear.
In either of the a,b,c alternatives one must be careful so that the trap
contains enough information so that a fault is not cleared by
another kind of fault on the same object for example.
Finally in order to reestablish the alarm log in the manager after lost
traps or communications failure there must be some kind
of log in the agent which contains all alarms. This log must contain enough
information to be able to recreate full X733 alarms
and clears.
Hope this helps.
If you want more details please do not hesitate to contact me.
best regards Stefan Wallin
stefan...@dataductus.se
<dper...@snmpinfo.com> skrev i
diskussionsgruppsmeddelandet:Pine.BSF.4.21.0002280903120.2478-100000@shell5.
ba.best.com...
Juergen Schoenwaelder
: When mapping traps to an X733 alarm two approaches are possible for
: every single variable:
: Static mapping : this implies that the manager based on the received
: Generic/Specific Trap
: injects the mapping. For example every linkDown is mapped to
: EventType : Communications, Severity: Major etc.
: In order for this mechanism to work the MIB must contain fine grained trap
: definitions so that the mapping
: can be done per single trap without knowing the contents of any trap
: varbind.
: Dynamic mapping : this implies that the var bind list contains a variable
: which can be used as value for the X733
: variables. Lets say that the trap has a varbind severity, of course then the
: manager can take that value and use it
: as X733 severity. A problem usually is that the actual values are different.
: In X733 severity is an enum 0-5. Some managers
: can not do value mapping which implies that the agent must have exact the
: same enum.
: In reality there is always a combination of static and dynamic mapping.
I have seen how temip does this. Temip interprets magic keywords that are
contained in MIB modules. These keywords tell temip how to map an SNMP
trap into an X733 record and whether it is a static or dynamic mapping.
(I guess stefan wallin is familiar with this. ;-) It is really ugly from
an SMI perspective, but it seems to work somehow.
/js
--
Juergen Schoenwaelder Technical University Braunschweig
<sch...@ibr.cs.tu-bs.de> Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
dper...@snmpinfo.com
The issue of alarms keeps coming up over and over again. The X.733
is a specification that many reference. There seems to be a desire
to put such capability in SNMP and have an IETF standard MIB module
for alarms. I believe that this is a worthwhile goal, and something
that Juergen and I can add to out list of projects to bring up
in the IETF. There are a few challenges, which are:
1) the model and terminology for events, alerts, alarms seems
very confused in the literature. This has to be solved
first. I believe that X.733 has plently of flaws
and is not a model for the approach to take.
2) the model depends on a foundation that identifies every
physical and logical component in a system. The entity
MIB provides part of this, but does not contain a state
information like that found in X.731, which is required
to report problems.
3) ...there are others..., but I've got to run now for
a meeting.
Regards,
/david t. perkins
On 10 Mar 2000, Juergen Schoenwaelder wrote:
> stefan wallin <stefan...@dataductus.se> wrote:
>
> : When mapping traps to an X733 alarm two approaches are possible for
> : every single variable:
>
> : Static mapping : this implies that the manager based on the received
> : Generic/Specific Trap
> : injects the mapping. For example every linkDown is mapped to
> : EventType : Communications, Severity: Major etc.
> : In order for this mechanism to work the MIB must contain fine grained trap
> : definitions so that the mapping
> : can be done per single trap without knowing the contents of any trap
> : varbind.
>
> : Dynamic mapping : this implies that the var bind list contains a variable
> : which can be used as value for the X733
> : variables. Lets say that the trap has a varbind severity, of course then the
> : manager can take that value and use it
> : as X733 severity. A problem usually is that the actual values are different.
> : In X733 severity is an enum 0-5. Some managers
> : can not do value mapping which implies that the agent must have exact the
> : same enum.
>
> : In reality there is always a combination of static and dynamic mapping.
>