Disman Working Group Kam Lam
Expires August 23, 2001 ARC MIB An-ni Huynh
Internet Draft Lucent Technologies
February 23, 2001
Alarm Reporting Control MIB
draft-lam-disman-arcmib-00.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.
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 state 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 state 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 "200102230000Z"
ORGANIZATION " "
CONTACT-INFO
"Anni Huynh
Lucent Technology
E-mail: ahuynh@lucent.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 "200102230000Z"
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 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 (1), nalm (2), nalmQI (3), or nalmTI.
The value of nalamQICD is a transitional state from nalmQI(3) to alm (1).
It is an optional depending on the type and the implementation of the resource.
If it is supported, before the state is transitioned from nalmQI(3) to alm (1),
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 (1)"
::= { 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-only
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.
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 be 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: 480 Red Hill Road, Room 1D-226
Middletown, NJ 07748-3098
Phone: 1-732-615-4118
EMail: hklam@lucent.com
Name(s): An-ni Huynh
Company: Lucent Technologies
Address: 480 Red Hill Road, Room 1B-223
Middletown, NJ 07748-3098
Phone: 1-732-615-5402
EMail: ahuynh@lucent.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 August 23, 2001 [Page xx]