Subject: RE: Alarm Report Control (ARC)

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 1 Feb 2001 09:23:34 -0500

Let me try to give an example. 

In an optical NE, an OTS trail termination point (TTP) could have the
following possible fault conditions: SSF-P (Sever Signal Fail-Payload),
SSF-O (SSF-Overhead), BDI-P (Backward Defect Indicator-Payload), BDI-O,  TIM
(Trace Identifier Mismatch), LOS-P (Loss of Signal-payload), LOS-O, and LOS.

The manager could configure an entry in the ARC table for a particular OTS
TTP instance (#3 say) to no alarm notification (i.e., NALM) for a subset of
the possible fault conditions (LOS & TIM say). This entry of the ARC table
will have the following information:

Entity: OTS TTP #3
Fault conditions: LOS, TIM
ARC state: NALM

I hope this example will illustrate the ARC requirements and help design the
MIB.

Regards,
Kam

-----Original Message-----
From: Dan Romascanu [mailto:[email-masked]]
Sent: Thursday, February 01, 2001 8:23 AM
To: Thomas, Steven C (Steve); Lam, Hing-Kam (Kam); 'Dan Romascanu'; 'Mark
Stewart'
Cc: Huynh, An-Ni (Anni); [email-masked]'; [email-masked];
[email-masked]
Subject: RE: Alarm Report Control (ARC)

If the table that you are proposing does not include the alarms (type or
instance), I doubt that its place is in the Alarm MIB at all!

Regards,

Dan

> -----Original Message-----
> From:	Thomas, Steven C (Steve) [SMTP:[email-masked]]
> Sent:	Wed January 31 2001 23:30
> To:	Lam, Hing-Kam (Kam); 'Dan Romascanu'; 'Mark Stewart'
> Cc:	Huynh, An-Ni (Anni); [email-masked]';
> [email-masked]; [email-masked]
> Subject:	RE: Alarm Report Control (ARC)
> 
> Hey,
> 
> If a new table was created in the alarm MIB, you propose it would include:
> "monitored entity (or entities), the alarm, and the corresponding ARC
> setting"
> 
> Would the monitored entity need to be a general OID, or is this specific
> to
> interfaces (at least for now)?  Could this table be indexed by ifIndex and
> cover all of the issues needed for the Optical Interface?
> 
> Does the table need to have the alarm in it as well? Is the intent of ARC
> to
> suppress all alarms from that managed entity, or just specified ones?
> 
> Thanks,
> Steve
> 
> 
> -----Original Message-----
> From: Lam, Hing-Kam (Kam) 
> Sent: Wednesday, January 31, 2001 10:32 AM
> To: 'Dan Romascanu'; 'Mark Stewart'
> Cc: Huynh, An-Ni (Anni); [email-masked]';
> [email-masked]; [email-masked]
> Subject: RE: Alarm Report Control (ARC)
> 
> 
> 
> Dan,
> 
> I don't fully understand the alarm MIB and the itu alarm mib yet, in
> particular the alarmDetailsTable. But do you think make sense to
> incorporate
> a ARC table into the alarm mib or itu alarm mib to support the ARC
> functionality? Entries of the ARC table will include information such the
> monitored entity (or entities), the alarm, and the corresponding ARC
> setting.
> 
> Regards,
> Kam
> 
> -----Original Message-----
> From: Dan Romascanu [mailto:[email-masked]]
> Sent: Wednesday, January 31, 2001 9:54 AM
> To: 'Mark Stewart'
> Cc: 'Huynh An-Ni (Anni)'; [email-masked]';
> [email-masked];
> [email-masked]
> Subject: RE: Alarm Report Control (ARC)
> 
> 
> 
> 
> Mark,
> 
> Let us try to get beyond the generalities level. Sharon and myself are the
> editors of the DISMAN Alarms MIB. The drafts have just been published.
> They
> are the result of a decent level of the discussions in the WG list in the
> last two months. Your comments and contributions are very welcome. What
> are
> your editorial proposals?
> 
> Regards,
> 
> Dan
> 
> 
> > -----Original Message-----
> > From:	Mark Stewart [SMTP:[email-masked]]
> > Sent:	Wed January 31 2001 16:44
> > To:	Dan Romascanu
> > Cc:	'Huynh An-Ni (Anni)'; [email-masked]';
> > [email-masked]; [email-masked]
> > Subject:	Re: Alarm Report Control (ARC)
> > 
> > Dan,
> > 
> > We are not proposing to add any specific objects defined in the
> > optical MIB to the alarm MIB being worked on in DISMAN. We are
> > interested in contributing to the effort to get the ARC functionality
> > defined by ITU integrated into the alarm MIB effort of DISMAN.
> > 
> > We would like to see a generic alarm MIB that provides a flexible
> > mechanism to control alarms on objects using an ARC approach for
> > future OTN systems.
> > 
> > We can provide the requirements for ARC and work with the DISMAN
> > WG to enhance the alarm MIB.
> > 
> > - Mark
> > 
> > Dan Romascanu wrote:
> > > 
> > > 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: "Mark Stewart" <[email-masked]>
Date: Thu, 01 Feb 2001 09:35:42 -0500

Lam,

Based on your example then can I assume that the Entity is in a fault
state but no alarm notification is sent.

- Mark