Subject: RE: Alarm Report Control (ARC)

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 3 Feb 2001 19:38:10 -0500

hi

I would think performance monitoring would be covered
by a performance threshold being surpassed being considered
a fault.  This would therefore result in an alarm.

Events such as initialization are not alarms by our current
definition.

An alarm indicates a fault, which should result in a notification.

Do you think it would help to cover these more specifically
in the document?

Sharon

-----Original Message-----
From: Tammy Ferris [mailto:[email-masked]]
Sent: Friday, February 02, 2001 5:49 PM
To: Thomas, Steven C (Steve)
Cc: Chisholm, Sharon [CAR:5K32:EXCH]; Dan Romascanu; Huynh, An-Ni
(Anni); [email-masked]'; [email-masked];
[email-masked]
Subject: Re: Alarm Report Control (ARC)

Steve,
Given the definitions you provided me, can you explain how performance
monitoring and threshold for performance are handled?

How are events such as initialization events that do not persist get
reported?

Can Faults and Alarms and Notifications be queried?

How is correlation of faults,  alarm, and notifications handled?
Tammy

Tammy Lehtinen Ferris
Merkita Incorporated
(763)577-5946

"Thomas, Steven C (Steve)" wrote:

> Tammy,
>
> I confess that I haven't seen the full ARC work for ITU.  I have only seen
> how it has been reflected in Mark Stewart's optical interface MIB.  Can
you
> point me to a complete copy of it?
>
> Regarding the differences between alarm and notification, the ALARM MIB
> defines the terms as follows:
>
>   Fault
>      Lasting error or warning condition.
>
>   Notification
>      Unsolicited transmissions of management information.
>
>   Alarm
>      Persistent indication of a fault.  A Notification should be sent
>      to indicate the setting of an alarm when the fault first
>      is detected.  A Notification should be sent to indicate the
>      clearing of an alarm when the fault ceases to exist.
>
> I trust that Sharon or Dan will correct me if I'm wrong, but I interpret
> that to mean that an alarm (once defined) is a condition that exists
whether
> any managers know about it or not (via notifications).  Notifications are
> the means of informing managers about the alarm condition being set or
> cleared.
>
> "Tammy Ferris" wrote:
>
> > Steve,
> > I was the editor for the ARC work done in the ITU and T1.  I have a
couple
> of
> > questions and comments to your e-mail and I also wanted to let everyone
> know
> > that I am working to get a "final" T1 version of ARC
> > requirements/analysis/design uploaded to the T1M1 site.  The version
> currently
> > loaded has everything but a minor bug fix to the state diagram.  If
anyone
> needs
> > to know the contribution number, let me know.
> >
> > You and others have discussed this being an alarm versus a notification
> > suppression feature.  Can you clarify for me exactly what you mean by an
> alarm
> > vs a notification?  What are the implications of the differences in the
> DISMAN
> > context?
> >
> > In studying this problem in T1, we also considered the possibility of
> putting
> > some or all of the functionality in the management systems.  However it
> was
> > ruled out for various reasons.  I think it is important to keep the
> > functionality in the Agent at this time.
> >
> > Also see additional comments below.
> > Tammy
> >
> > "Thomas, Steven C (Steve)" wrote:
> >
> > > Hey all,
> > >
> > > As I understand the ARC issue, it is more a notification issue than an
> alarm
> > > issue.  BUT there is a problem in only viewing it as notification.
> > > Specifically, if a fault condition is active for a managed object when
> its
> > > ARC control is set from OFF(NALM) to ON(ALM), a notification SHOULD be
> sent.
> >
> > ***Tammy
> > Not only should the notification be sent in this scenario, but it is
> required > to
> > be sent in the ITU version.
> > ***Tammy
> >
> > > As I understand Notification Filters, just viewing it as a
notification
> > > would not get it sent.
> > >
> > > I believe that a manager COULD implement the equivalent functions as
> what is
> > > desired by ARC by setting/changing entries in the
> > > snmpNotifyFilterProfileTable, but it would be pretty ugly and
indirect.
> > > Also this approach would be controlled by the manager and I think the
> intent
> > > of ARC control is to move that control down to the device.
> > >
> > > Cheers,
> > > Steve
> > >
> > > -----Original Message-----
> > > From: Sharon Chisholm [mailto:[email-masked]]
> > > Sent: Wednesday, January 31, 2001 8:05 AM
> > > To: Dan Romascanu; Huynh, An-Ni (Anni); [email-masked]';
> > > [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: Alarm Report Control (ARC)
> > >
> > > hi
> > >
> > > Is this an alarm control or a notification control? If
> > > it is more general to notifications, it might also work
> > > somewhere like the SNMP-TARGET-MIB.
> > >
> > > Sharon
> > >
> > > -----Original Message-----
> > > From: Dan Romascanu [mailto:[email-masked]]
> > > Sent: Wednesday, January 31, 2001 2:16 AM
> > > To: 'Huynh, An-Ni (Anni)'; [email-masked]';
> [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: Alarm Report Control (ARC)
> > >
> > > Anni,
> > >
> > > So, if I understand well your proposal is to add
> otnOTSnAlarmReportControl
> > > object from draft-stewart-atommib-opticalmib-00.txt to the current
Alarm
> > > MIB. Is that true?
> > >
> > > Regards,
> > >
> > > Dan
> > >
> > > -----Original Message-----
> > > From: Huynh, An-Ni (Anni) [SMTP:[email-masked]]
> > > Sent: Wed January 31 2001 0:15
> > > To:   [email-masked]'; [email-masked]; 'Dan
Romascanu'
> > > Cc:   [email-masked]
> > > Subject:      RE: Alarm Report Control (ARC)
> > >
> > > Dan:
> > >       ARC is a generic feature to control when a notification should
be
> > > sent depending
> > >       on the administrative condition, it is not intended for Optical
> > > device only,
> > >       I don't think we need to have an specific optical alarm mib.
> > >       That is why it was suggested that this topic be address in the
> > > DISMAN WG since
> > >       the group is working on alarm mibs (generic or itu specific).
> > >
> > > Anni
> > >
> > >
> > > > ----------
> > > > From:       Dan Romascanu[SMTP:[email-masked]]
> > > > Sent:       Tuesday, January 30, 2001 2:46 PM
> > > > To:         [email-masked]'; Huynh, An-Ni (Anni);
> > > > [email-masked]
> > > > Cc:         [email-masked]
> > > > Subject:    RE: Alarm Report Control (ARC)
> > > > Sensitivity:        Confidential
> > > >
> > > > Faye,
> > > >
> > > > If you are reading the two drafts in the proposal, you can see that
we
> > > are
> > > > proposing a modular architecture. The Alarm MIB defines generic
alarm
> > > > management, while a relationship mechanism is defined for model
> specific
> > > > alarms that need to extend the generic mechanism. The ITU Alarm MIB
is
> > > one
> > > > such example, an Optical Alarm MIB could be another one, and the ARC
> > > > feature
> > > > could be supported in this MIB.
> > > >
> > > > Regards,
> > > >
> > > > Dan
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From:     [email-masked] [SMTP:[email-masked]]
> > > > > Sent:     Tue January 30 2001 20:25
> > > > > To:       [email-masked]; [email-masked]
> > > > > Cc:       [email-masked]
> > > > > Subject:  RE: Alarm Report Control (ARC)
> > > > > Sensitivity:      Confidential
> > > > >
> > > > > Dear disman WG,
> > > > >
> > > > > I just saw the latest draft of Alarm MIB from Sharon.  I browse
the
> > > > draft
> > > > > and I am not quite sure it covers the ARC feature which is
required
> to
> > > > > manage an optical interface.  Can someone please let us (AToMMIB)
> know
> > > > if
> > > > > this can be achieved with the existing draft or there is
additional
> > > > work?
> > > > >
> > > > >
> > > > > Our plan is to provide a pointer in our MIB to your Alarm MIB if a
> > > > > mechanism
> > > > > is provided to manage ARC.  If not, we will continue to put the
ARC
> > > > > feature
> > > > > in the Optical MIB.
> > > > >
> > > > > Please see An-ni's email attached.  Thank you very much for your
> help.
> > > > >
> > > > > -faye
> > > > >
> > > > > -----Original Message-----
> > > > > From: Huynh, An-Ni (Anni) [mailto:[email-masked]]
> > > > > Sent: Monday, January 29, 2001 2:59 PM
> > > > > To: 'DISMAN WG'
> > > > > Cc: 'AToM MIB WG'
> > > > > Subject: Alarm Report Control (ARC)
> > > > > Sensitivity: Confidential
> > > > >
> > > > >
> > > > >
> > > > > Hi.
> > > > >
> > > > > I am the editor of the Optical Interface MIB for Optical Transport
> > > > Network
> > > > > device
> > > > > (a working document in  AToM MIB WG).
> > > > >
> > > > > In the original draft  "draft-stewart-atommib-opticalmib-00.txt"
> > > > > one of the MIB object is to configure the setting of  Alarm Report
> > > > Control
> > > > > (ARC).
> > > > >
> > > > > In the last IETF meeting, some members from the AToM MIB WG view
> that
> > > it
> > > > > is a generic feature and suggested to address ARC in the DISMAN
WG.
> > > > > Is the DISMAN WG interested in accepting ARC into the framework of
> the
> > > > WG?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Anni Huynh
> > > > > [email-masked]
> > > > > +1 732 615-5402
> > > > > -----------------------------------------
> > > > > Some background information on ARC:
> > > > > * Reference:  ITU-T Recommendation M.3100 Amendement 3.
> > > > > * What is ARC?
> > > > > ARC is an mandatory capability for new optical devices.  The
ability
> > > to
> > > > > turn on/off  alarm reproting shall be supported over its
management
> > > > > interfaces.
> > > > > There are 4 states:
> > > > >           ALM - alarm reporting is turned on,
> > > > >           NALM - alarm reporting is turned off
> > > > >           NALM-TI - Inhibit alarm for a specified time interval
> > > > >           NALM-QI - Inhibit alarm until the resource is qualified
as
> > > > > problem free.
> > > > >
> > > > > * Why ARC?
> > > > > 1.        For network provisioning:  During the network setup/tear
> > > down,
> > > > > alarm reporting needs to be turned off  for customer testing and
> other
> > > > > activities.
> > > > > Once the managed entity is problem free, alarm reporting is
> > > > automatically
> > > > > turn on.
> > > > > 2.        For network maintenance: Maintenance technician can
> > > selectively turn
> > > > > on/off
> > > > > alarm reporting per managed entity for troubleshooting.
> > > >

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 3 Feb 2001 18:10:48 -0800 (PST)

> a fault.  This would therefore result in an alarm.

No.  A PM threshold crossing is not a fault.  It is a transient
condition that is reported once when it happens.  The resulting
notification is an alert (aka event report), not an alarm.

Faults are standing conditions.  The entry into a fault condition
causes an alarm report to be generated.  Exit from a fault condition
causes an alarm clearing report to be generated.  These are not the
same as alerts.

One more packet on the VLAN ...

Mike