Subject: Alarm Report Control (ARC)

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Mon, 29 Jan 2001 17:59:00 -0500

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: [email-masked]
Date: Tue, 30 Jan 2001 10:24:41 -0800

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.

Regards,

Anni Huynh
[email-masked]
+1 732 615-5402

*	Why ARC?

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 30 Jan 2001 21:46:47 +0200

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

> 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)

---

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Tue, 30 Jan 2001 17:15:16 -0500

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]

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 31 Jan 2001 16:53:44 +0200

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

> 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
> > 
> > > From: Huynh, An-Ni (Anni) [SMTP:[email-masked]]
> > > Sent: Wed January 31 2001 0:15
> > > To:   [email-masked]'; [email-masked]; 'Dan
> Romascanu'
> > > > If you are reading the two drafts in the proposal, you can see that
> we
> > > are
> > > > alarms that need to extend the generic mechanism. The ITU Alarm MIB
> is
> > > one
> > > > > I just saw the latest draft of Alarm MIB from Sharon.  I browse
> the
> > > > draft
> > > > > 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?
> > > > >
> > > > >
> > > > > is provided to manage ARC.  If not, we will continue to put the
> ARC
> > > > > feature
> > > > > in the Optical MIB.
> > > > >
> > > > > In the last IETF meeting, some members from the AToM MIB WG view
> that
> > > it
> > > > > Is the DISMAN WG interested in accepting ARC into the framework of
> the
> > > > WG?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Anni Huynh
> > > > > [email-masked]
> > > > > +1 732 615-5402
> > > > > ARC is an mandatory capability for new optical devices.  The
> ability
> > > to

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 31 Jan 2001 09:55:26 -0500

Dan,

In the opticalmib-00 version, the ARC setting is defined as an object of the
monitored entity (e.g., otnOTSnAlarmReportControl for the OTSn,
otnOMSnAlarmReportControl for the OMSn, etc.).

Now we think there may be a better way to model the ARC settings. That is
using a separate table. Each entry will including information such the
monitored entity (or entities), the alarm, and the corresponding ARC
setting. In this way, we don't modify the entity MIBs.

What do you think?

Regards,
Kam

-----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

> To:	[email-masked]'; [email-masked]; 'Dan Romascanu'

---

From: Lakshmi Raman <[email-masked]>
Date: Wed, 31 Jan 2001 07:06:20 -0800

Dan,
Not completely. One needs to take that definition and make it
a generic one. It is not a lot of change. It is more taking away for
example in the name that it is OTN specific.
In the ITU world, this is a feature added to any entity where
the actual reporting is suspended for a time. Each entity in OTN MIB
has this feature included. If there is a general definition then
every one can use it was the idea from that meeting.
Lakshmi

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 31 Jan 2001 10:31:38 -0500

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,

Regards,

Dan

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 31 Jan 2001 08:05:17 -0500

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,

Regards,

Dan

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 31 Jan 2001 11:07:13 -0500

Sharon,

This is for controlling alarmed-related notifications.

Kam

-----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]

hi

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,

Regards,

Dan

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 31 Jan 2001 18:11:01 +0200

Hi Kam,

Yes. Adding the relevant objects in alarmDetailsTable to support the ARC
capability would be the way to go. However, I would first like to clarify if
ARC is really a function that belongs to the Alarm MIB or some other place -
see the question in the mail from Sharon.

Regards,

Dan

> From:	Lam, Hing-Kam (Kam) [SMTP:[email-masked]]
> Sent:	Wed January 31 2001 17:32
> To:	'Dan Romascanu'; 'Mark Stewart'
> Cc:	Huynh, An-Ni (Anni); [email-masked]';

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 31 Jan 2001 14:35:33 -0500

Dan,

One of the functional requirements of ARC is: allow suppression of reporting
(notification) of alarm on a per monitored instance base. Take SONET/SDH as
an example, one may want to suppress the reporting of AIS alarm on a
particular low order path (VT) instance for a certain time period (i.e., put
this VT instance in the NALM-TI state) for the purpose of path setup or
maintenance. Once the time period expired, it will automatically transition
into the ALM state (i.e., notification of alarm, if any, is now allowed).

To my understanding, the alarmDetailsTable and the ituAlarmTable) specify
the possible alarm types of a system irrespective to particular entity types
nor instances. Note that a alarm type may occur to different entity types
and instances. For example, in the 2558 SONET/SDH MIB, AIS can occur to a
Line, a high order path, or a low order path (VT). Given that, how do we
model the ARC setting into the alarmDetailsTable? Any ideas?

Regards,
Kam

-----Original Message-----
From: Dan Romascanu [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 11:11 AM
To: Lam, Hing-Kam (Kam); 'Dan Romascanu'; 'Mark Stewart'
Cc: Huynh, An-Ni (Anni); [email-masked]';

Hi Kam,

Regards,

Dan