Internet DRAFT - draft-lam-disman-arcmib
draft-lam-disman-arcmib
Disman Working Group Kam Lam
Expires January 19, 2002 ARC MIB Lucent Technologies
Internet Draft An-ni Huynh
Cetus Networks
July 19, 2001
Alarm Reporting Control MIB
draft-lam-disman-arcmib-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Editor's Note:
(1) Changes from version arcMIB-00:
- Update the description of the arcState object such that
once a resource enters the alm state for the specified alarm
type, the corresponding entry will be deleted automatically
from the arc table.
That is, the arc table will only have entries for the resources
that are currently in the arc mode.
- Change arcNalmTimeRemaining from read-only to read-write.
This change will allow the manager to extend or shorten
the remaining time when the resource is in the NALM-TI or
NALM-QI-CD state as needed.
(2) Future Plan:
The objects defined in this draft mib will be integrated into
the CONDITION MIB.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
1. Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for controlling the reporting of
alarm conditions of a network device.
Textual Conventions used in this MIB are defined in [RFC2579].
Table of Contents
1 Abstract .............................................. 1
2 The SNMP Network Management Framework ................. 2
3 Overview ............................................ 2
3.1 ARC Terminology and Definition ...................... 3
4 Object Definitions .................................... 4
5 Example Application ................................. 7
6 Security Considerations ............................... 7
7 Acknowledgments........................................ 8
8 References ............................................ 8
9 Author's Address ...................................... 9
10 Intellectual Property ................................ 10
Full Copyright Statement ................................ 10
2. The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major
components:
0 An overall architecture, described in RFC 2571 [RFC2571].
0 Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
1215 [RFC1215]. The second version, called SMIv2, is described
in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
STD 58, RFC 2580 [RFC2580].
0 Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [RFC1157]. A second version of
the SNMP message protocol, which is not an Internet standards
track protocol, is called SNMPv2c and described in RFC 1901
[RFC1901] and RFC 1906 [RFC1906]. The third version of the
message protocol is called SNMPv3 and described in RFC 1906
[RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
0 Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [RFC1157]. A second set of
protocol operations and associated PDU formats is described in
RFC 1905 [RFC1905].
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (e.g., use of Counter64). Some machine
readable information in SMIv2 will be converted into textual
descriptions in SMIv1 during the translation process. However,
this loss of machine readable information is not considered to
change the semantics of the MIB.
3. Overview
There is a need to provide a mechanism for controlling the reporting
of alarm conditions of resources in a network device. For examples,
(a) inhibiting the reporting of alarm conditions of a resource until
the resource is problem-free, (b) inhibiting the reporting of alarm
conditions of a resource for a specified time period, or
(c) inhibiting the reporting of alarm conditions of a resource
until explicitly allowed later on by the managing system.
The alarm reporting control (ARC) feature provides an automatic
in-service provisioning capability. It allows sufficient time for
service setup, customer testing, and other maintenance activities in
an "alarm-free" state. Once a resource is "problem-free",
alarm reporting is automatically (or manually) turned on
(i.e., allowed).
By putting a network resource in ARC mode, the technicians and
managing systems will not be flooded with unnecessary work items
during operations activities such as service provisioning and
network setup/teardown. This will reduce maintenance costs and
improve the operation and maintenance of these systems.
ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3] provides the
business requirements, analysis, and design of the Alarm Reporting
Control Feature.
This MIB module defines the SNMP objects to support a subset of
the ARC functions described in M.3100 Amd3. In particular, it defines
a table that contains the ARC setting for the resources in a system.
Management objects for defining and storing alarms, including active
and history alarms, standing and transient alarms, are described in
the Alarm MIB, ITU Alarm MIB, and Condition MIB.
3.1 ARC Terminology and Definition
Alarm Reporting Control (ARC) - M.3100 Amd3
Alarm Report Control is a feature that provides an automatic
in-service provisioning capability. Alarm reporting is turned
off on a per-resource basis for a selective set of alarm types
(i.e., potential alarm conditions) to allow sufficient time for
customer testing and other maintenance activities in an "alarm
free" state. Once a resource is ready for service , alarm
reporting is automatically (or manually) turned on.
ARC State
The ARC feature provides the following states for a resource:
ALM: Alarm reporting is turned on (i.e., is allowed).
NALM: Alarm reporting is turned off.
NALM-TI: Alarm reporting is turned off for a time interval.
(TI - Time Inhibit).
NALM-QI: Alarm reporting is turned off for a selected set
of alarm types until the resource is qualified
problem-free for a specified persistence
interval.
Problem-free means that none of the conditions
corresponding to the selected alarm types exist.
(QI - Qualified Inhibit).
NALM-QI-CD: This is a substate of NALM-QI and performs the
persistence timing count down function after the
resource is qualified problem-free.
(CD - Count Down).
According to the requirements in M.3100 Amd3, a resource
supporting the ARC feature shall support the ALM state and at
least one of the NALM, NALM-TI, and NALM-QI states. NALM-QI-CD
is an optional substate of NALM-QI.
ARC State Transition
ALM may transition to NALM, NALM-QI, or NAML-TI by management
request.
NALM may transition to ALM, NALM-QI, or NAML-TI by management
request.
NALM-QI may transition to NALM or ALM by management request.
NALM-QI may transition to ALM automatically
if qualified problem-free (if NALM-QI-CD is not supported) or
if the CD timer expired (if NALM-QI-CD is supported)
NALM-TI may transition to ALM or NALM by management request.
NALM-TI may transition to ALM automatically if the TI timer expired.
Further details of ARC state transitions are defined in Figure 3
of M.3100 Amd3.
ARC Mode
A resource is in the ARC mode when it is in one of NALM, NALM-TI,
NALM-QI, or NALM-QI-CD states.
ARC NALM TI Time Interval
A pre-defined length of time in which the resource will stay in
the NALM-TI ARC state before transition into the ALM state.
ARC NALM QI CD Time Interval
A pre-defined length of time in which the resource will stay in
the NALM-QI-CD ARC state before transition into the ALM state
after it is problem-free.
ARC NALM Time Remaining
The time remaining until the expiration of the time interval when
a resource is in the NALM-TI or NALM-QI-CD state.
Relationship between ARC mode entering/exiting and Alarm reporting
For alarm condition raised prior to entering ARC mode, reporting
of alarm raised and alarm cleared will be sent as usual.
That it, ARC has no impacts.
For alarm condition raised after entering ARC mode and also
cleared before exiting ARC mode, no reporting of raised will be
sent and no reporting of cleared will be sent.
For alarm condition raised after entering ARC mode and cleared
after exiting ARC mode, the reporting of alarm raised will be
deferred until the moment of exiting ARC mode. The reporting of
alarm clear will be sent as usual (i.e., at the time of alarm
cleared).
Further details can be found in M.3100 Amd3.
4. Object Definitions
ARC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Unsigned32
FROM SNMPv2-SMI
conditionProbableCause
FROM COND-MIB
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
arcMIB MODULE-IDENTITY
LAST-UPDATED "200107190000Z"
ORGANIZATION " "
CONTACT-INFO
"Anni Huynh
Cetus Networks
E-mail: a_n_huynh@yahoo.com
Kam Lam
Lucent Technologies
E-mail: hklam@lucent.com."
DESCRIPTION
"The MIB module describes the objects for controlling a resource
in reporting an condition that it detectes."
REVISION "200107190000Z"
DESCRIPTION
"The initial version."
::={ mib-2 yy}
------------------
-- MIB Objects
------------------
arcMIBObjects OBJECT IDENTIFIER ::= { arcMIB 1 }
arcTable OBJECT-TYPE
SYNTAX SEQUENCE OF ArcEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of arc settings on the system."
::= { arcMIBObjects 1 }
arcEntry OBJECT-TYPE
SYNTAX ArcEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row that contains information about the ARC setting of a
resource in the system."
INDEX { arcIndex, arcAlarmType }
::= { arcTable 1 }
ArcEntry ::=
SEQUENCE {
arcIndex OBJECT IDENTIFIER,
arcAlarmType ConditionProbableCause,
arcState INTEGER,
arcNalmTITimeInterval Unsigned32,
arcNalmCDTimeInterval Unsigned32,
arcNalmTimeRemaining Unsigned32
}
arcIndex OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The OID of a resource under the control of the ARC setting.
It must show all the indice to uniquely identify a resource.
The resource that does not support ARC or is not in the ALM state
will not have an entry in this table."
::= { arcEntry 1 }
arcAlarmType OBJECT-TYPE
SYNTAX CondProbableCause
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object identifies the alarm type controled by the arcState.
Only one alarm type is identified for each entry. The alarm type
not listed in this object are not affected by the ARC setting in
the arcState."
::= { arcEntry 2 }
arcState OBJECT-TYPE
SYNTAX INTEGER {
alm (1),
nalm (2),
nalmQI (3),
nalmTI (4),
nalmQICD (5)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The object controls the alarm report of a resource. A manager can
set the arcState to either alm, nalm, nalmQI, or nalmTI.
Once the resource enters the alm state for the specified alarm
type, the corresponding entry will be deleted from the arc table.
The value of nalamQICD is a transitional state from nalmQI to alm.
It is optional depending on the type and the implementation of the
resource. If it is supported, before the state is transitioned
from nalmQI to alm, a count down period is activated for a duration
set by the object arcNalmCDTimeInterval. When the time is up,
the arcState is set to alm."
::= { arcEntry 3 }
arcNalmTITimeInterval OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable indicates the time interval used for nalmTI,
in units of second."
::= { arcEntry 4 }
arcNalmCDTimeInterval OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable indicates the time interval used for nalmQICD,
in units of second."
::= { arcEntry 5 }
arcNalmTimeRemaining OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable indicates the time remaining in the NALM-TI interval
or the NALM-QI-CD interval, in units of second.
At the moment the resource enters the NALM-TI state, this variable
will have the initial value equal to the value of
arcNalmTITimeInterval and then starts decrementing as time goes by.
Similarly at the moment the resource enters the NALM-QI-CD state,
this variable will have the initial value equal to the value of
arcNalmCDTimeInterval and then starts decrementing as time goes by.
This variable is read-write and thus will allow the manager to
extend or shorten the remaining time when the resource is in
the NALM-TI or NALM-QI-CD state as needed.
If this variable is supported and the resource is currently not in
the NALM-TI nor NAML-QI-CD state, the value of this variable shall
equal to zero."
::= { arcEntry 6 }
-- conformance information
-- To be Added
END
5. Example Application
The following scenario provides an example application of the ARC
feature.
(i) A bi-directional termination point TP-A has been created
in the NALM-QI state in a network device NE-A. Another
bi-directional termination point TP-Z has also been created in
the NALM-QI state in another network device NE-Z. The ARC
probable cause list of both termination points consists of
OCI (Open Connection Indication) and TIM (Trace Identifier
Mismatch).
(ii) A bi-directional connection is setup in the network and
terminated at TP-A and TP-Z. The transmitted trace identifier
and expected trace identifier are provisioned at TP-A and TP-Z.
(iii) Both TP-A and TP-Z are checking for the OCI and TIM
status. If OCI or TIM is detacted at TP-A, no alarm will be
reported. Same for TP-Z.
(iv) IF or when TP-A is problem-free for both OCI and TIM ,
the ARC state of TP-A will transition from NALM-QI to ALM.
Same for TP-Z.
Now TP-A, TP-Z, and the bi-directional connection are
in-service.
(v) From then on, if OCI or TIM is detected at TP-A, alarm
report will be sent. Same for TP-Z.
6. Security Considerations
There are a number of management objects defined in this MIB that
have a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations.
It is thus important to control even GET access to these objects and
possibly to even encrypt the values of these object when sending them
over the network via SNMP. Not all versions of SNMP provide features
for such a secure environment.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), there is no
control as to who on the secure network is allowed to access and
GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2574 [RFC2574] and the
View-based Access Control Model RFC 2575 [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
7. Acknowledgements
The authors wish to thank Tom Rutt, Steven Thomas, and Michael
Campbell for reviewing and commenting on this draft.
8. References
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing SNMP Management Frameworks", RFC 2571, April
1999.
[RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets", STD
16, RFC 1155, May 1990.
[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD
16, RFC 1212, March 1991.
[RFC1215] M. Rose, "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
RFC 2573, April 1999.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction to Version 3 of the Internet-standard Network
Management Framework", RFC 2570, April 1999.
[RFC2026] Bradnerand, S., "The Internet Standards Process --
Revision 3", STD 17, RFC 2026, October 1996.
[M.3100 Amd3] ITU Recommendation M.3100 Amendment 3, "Definition of the
Management Interface for a Generic Alarm Reporting Control
(ARC) Feature", February 2001.
9. Author's Address
Name(s): Kam Lam
Company: Lucent Technologies
Address: 101 Crawfords Corner Road, Room 4C-616A
Holmdel, NJ 07733
Phone: 1-732-949-8338
EMail: hklam@lucent.com
Name(s): An-ni Huynh
Company: Cetus Networks
Phone: 1-732-615-5402
EMail: a_n_huynh@yahoo.com
10. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires January 19, 2002 [Page xx]
