Subject: RE: Alarm Report Control (ARC)

From: "Thomas, Steven C (Steve)" <[email-masked]>
Date: Thu, 1 Feb 2001 08:39:45 -0500

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: Tammy Ferris <[email-masked]>
Date: Fri, 02 Feb 2001 16:49:23 -0600

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

---

From: Tammy Ferris <[email-masked]>
Date: Fri, 02 Feb 2001 15:59:30 -0600

Steve,
Download 0m152770.zip from  http://www.t1.org/index/0403.htm

The only thing missing is a correction in the transition from the NALM-TI state
to NALM.  The correction is to change reasons for transition (triggers) from
"Management Request" to "Management request or Timer Expired".

I think it is useful to look at figure 7 to see the context of ARC in the ITU in
relation to other ITU alarm functions as this seems to be a large part of the
focus of the discussions on this topic over this e-mail correspondence.
Tammy

Tammy Lehtinen Ferris
Merkita Incorporated
(763) 577-5946

---

From: "David T. Perkins" <[email-masked]>
Date: Sat, 03 Feb 2001 14:28:47 -0800

HI,

It appears to me that Tammy's message contains the blur and confusion
of terminology in this area. Until someone can define terms (or point
to a well written source), there will be no commutation - only words
passing packets in different VPN on the same wire.

Regards,
/david t. perkins