Network Working Group M. Rose, Editor Request for Comments: 1215 Performance Systems International March 1991
A Convention for Defining Traps for use with the SNMP
Status of this Memo
This memo suggests a straight-forward approach towards defining traps used with the SNMP. Readers should note that the use of traps in the Internet-standard network management framework is controversial. As such, this memo is being put forward for information purposes. Network management practitioners who employ traps are encouraged to make use of this document. Practitioners who do not employ traps can safely ignore this document.
This memo provides information for the Internet community. It does not specify any standard. Distribution of this memo is unlimited.
Table of Contents
1. Historical Perspective ................................ 1 2. Defining Traps ........................................ 2 2.1 Mapping of the TRAP-TYPE macro ....................... 3 2.1.1 Mapping of the ENTERPRISE clause ................... 3 2.1.2 Mapping of the VARIABLES clause .................... 4 2.1.3 Mapping of the DESCRIPTION clause .................. 4 2.1.4 Mapping of the REFERENCE clause .................... 4 2.1.5 Mapping of the TRAP-TYPE value ..................... 4 2.2 Usage Examples ....................................... 5 2.2.1 Enterprise-specific Trap ........................... 5 2.2.2 Generic-Traps for use with the SNMP ................ 5 3. Acknowledgements ...................................... 7 4. References ............................................ 9 5. Security Considerations................................ 9 6. Author's Address....................................... 9
1. Historical Perspective
As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], a two-prong strategy for network management of TCP/IP-based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP), defined in RFC 1067, was to be used to manage nodes in the Internet community. In the long-term, the use of the OSI network management framework was be examined. Two documents were produced to define the management
SNMP Working Group [Page 1]
RFC 1215 Convention for Defining Traps March 1991
information: RFC 1065, which defined the Structure of Management Information (SMI), and RFC 1066, which defined the Management Information Base (MIB). Both of these documents were designed so as to be compatible with both the SNMP and the OSI network management framework.
This strategy was quite successful in the short-term: Internet-based network management technology was fielded, by both the research and commercial communities, within a few months. As a result of this, portions of the Internet community became network manageable in a timely fashion.
As reported in RFC 1109, Report of the Second Ad Hoc Network Management Review Group [2], the requirements of the SNMP and the OSI network management frameworks were more different than anticipated. As such, the requirement for compatibility between the SMI/MIB and both frameworks was suspended. This action permitted the operational network management framework, based on the SNMP, to respond to new operational needs in the Internet community by producing MIB-II.
In May of 1990, the core documents were elevated to "Standard Protocols" with "Recommended" status. As such, the Internet-standard network management framework consists of: Structure and Identification of Management Information for TCP/IP-based internets, RFC 1155 [3], which describes how managed objects contained in the MIB are defined; Management Information Base for Network Management of TCP/IP-based internets, which describes the managed objects contained in the MIB, RFC 1156 [4]; and, the Simple Network Management Protocol, RFC 1157 [5], which defines the protocol used to manage these objects.
2. Defining Traps
Due to its initial requirement to be protocol-independent, the Internet-standard SMI does not provide a means for defining traps. Instead, the SNMP defines a few standardized traps and provides a means for management enterprises to transmit enterprise-specific traps.
However, with the introduction of experimental MIBs, some of which have a need to define experiment-specific traps, a convenient means of defining traps is desirable. The TRAP-TYPE macro is suggested for this purpose:
IMPORTS ObjectName FROM RFC1155-SMI;
SNMP Working Group [Page 2]
RFC 1215 Convention for Defining Traps March 1991
TRAP-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "ENTERPRISE" value (enterprise OBJECT IDENTIFIER) VarPart DescrPart ReferPart VALUE NOTATION ::= value (VALUE INTEGER)
DescrPart ::= "DESCRIPTION" value (description DisplayString) | empty
ReferPart ::= "REFERENCE" value (reference DisplayString) | empty
END
It must be emphasized however, that the use of traps is STRONGLY discouraged in the Internet-standard Network Management Framework. The TRAP-TYPE macro is intended to allow concise definitions of existing traps, not to spur the definition of new traps.
2.1. Mapping of the TRAP-TYPE macro
It should be noted that the expansion of the TRAP-TYPE macro is something which conceptually happens during implementation and not during run-time.
2.1.1. Mapping of the ENTERPRISE clause
The ENTERPRISE clause, which must be present, defines the management enterprise under whose registration authority this trap is defined (for a discussion on delegation of registration authority, see the SMI [3]). This value is placed inside the enterprise field of the SNMP Trap-PDU.
By convention, if the value of the ENTERPRISE clause is
SNMP Working Group [Page 3]
RFC 1215 Convention for Defining Traps March 1991
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
as defined in MIB-II [7], then instead of using this value, the value of sysObjectID is placed in the enterprise field of the SNMP Trap- PDU. This provides a simple means of using the TRAP-TYPE macro to represent the existing standard SNMP traps; it is not intended to provide a means to define additional standard SNMP traps.
2.1.2. Mapping of the VARIABLES clause
The VARIABLES clause, which need not be present, defines the ordered sequence of MIB objects which are contained within every instance of the trap type. Each variable is placed, in order, inside the variable-bindings field of the SNMP Trap-PDU. Note that at the option of the agent, additional variables may follow in the variable-bindings field.
However, if the value of the ENTERPRISE clause is
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
as defined in MIB-II [7], then the introduction of additional variables must not result in the serialized SNMP Message being larger than 484 octets.
2.1.3. Mapping of the DESCRIPTION clause
The DESCRIPTION clause, which need not be present, contains a textual definition of the trap type. Note that in order to conform to the ASN.1 syntax, the entire value of this clause must be enclosed in double quotation marks, although the value may be multi-line.
Further, note that if the MIB module does not contain a textual description of the trap elsewhere then the DESCRIPTION clause must be present.
2.1.4. Mapping of the REFERENCE clause
The REFERENCE clause, which need not be present, contains a textual cross-reference to a trap, event, or alarm, defined in some other MIB module. This is useful when de-osifying a MIB produced by some other organization.
2.1.5. Mapping of the TRAP-TYPE value
The value of an invocation of the TRAP-TYPE macro is the (integer) number which is uniquely assigned to the trap by the registration authority indicated by the ENTERPRISE clause. This value is placed
SNMP Working Group [Page 4]
RFC 1215 Convention for Defining Traps March 1991
inside the specific-trap field of the SNMP Trap-PDU, and the generic-trap field is set to "enterpriseSpecific(6)".
By convention, if the value of the ENTERPRISE clause is
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
as defined in MIB-II [7], then the value of an invocation of the TRAP-TYPE macro is placed inside the generic-trap field of the SNMP Trap-PDU, and the specific-trap field is set to 0. This provides a simple means of using the TRAP-TYPE macro to represent the existing standard SNMP traps; it is not intended to provide a means to define additional standard SNMP traps.
2.2. Usage Examples
2.2.1. Enterprise-specific Trap
Consider a simple example of an enterprise-specific trap that is sent when a communication link failure is encountered:
myLinkDown TRAP-TYPE ENTERPRISE myEnterprise VARIABLES { ifIndex } DESCRIPTION "A myLinkDown trap signifies that the sending SNMP application entity recognizes a failure in one of the communications links represented in the agent's configuration." ::= 2
2.2.2. Generic-Traps for use with the SNMP
Consider how the standard SNMP traps might be defined:
coldStart TRAP-TYPE ENTERPRISE snmp DESCRIPTION "A coldStart trap signifies that the sending protocol entity is reinitializing itself such that the agent's configuration or the rotocol entity implementation may be altered." ::= 0
warmStart TRAP-TYPE ENTERPRISE snmp
SNMP Working Group [Page 5]
RFC 1215 Convention for Defining Traps March 1991
DESCRIPTION "A warmStart trap signifies that the sending protocol entity is reinitializing itself such that neither the agent configuration nor the protocol entity implementation is altered." ::= 1
linkDown TRAP-TYPE ENTERPRISE snmp VARIABLES { ifIndex } DESCRIPTION "A linkDown trap signifies that the sending protocol entity recognizes a failure in one of the communication links represented in the agent's configuration." ::= 2
linkUp TRAP-TYPE ENTERPRISE snmp VARIABLES { ifIndex } DESCRIPTION "A linkUp trap signifies that the sending protocol entity recognizes that one of the communication links represented in the agent's configuration has come up." ::= 3
authenticationFailure TRAP-TYPE ENTERPRISE snmp DESCRIPTION "An authenticationFailure trap signifies that the sending protocol entity is the addressee of a protocol message that is not properly authenticated. While implementations of the SNMP must be capable of generating this trap, they must also be capable of suppressing the emission of such traps via an implementation- specific mechanism." ::= 4
SNMP Working Group [Page 6]
RFC 1215 Convention for Defining Traps March 1991
egpNeighborLoss TRAP-TYPE ENTERPRISE snmp VARIABLES { egpNeighAddr } DESCRIPTION "An egpNeighborLoss trap signifies that an EGP neighbor for whom the sending protocol entity was an EGP peer has been marked down and the peer relationship no longer obtains." ::= 5
3. Acknowledgements
This document was produced by the SNMP Working Group:
Anne Ambler, Spider Karl Auerbach, Sun Fred Baker, ACC Ken Brinkerhoff Ron Broersma, NOSC Jack Brown, US Army Theodore Brunner, Bellcore Jeffrey Buffum, HP John Burress, Wellfleet Jeffrey D. Case, University of Tennessee at Knoxville Chris Chiptasso, Spartacus Paul Ciarfella, DEC Bob Collet John Cook, Chipcom Tracy Cox, Bellcore James R. Davin, MIT-LCS Eric Decker, cisco Kurt Dobbins, Cabletron Nadya El-Afandi, Network Systems Gary Ellis, HP Fred Engle Mike Erlinger Mark S. Fedor, PSI Richard Fox, Synoptics Karen Frisa, CMU Chris Gunner, DEC Fred Harris, University of Tennessee at Knoxville Ken Hibbard, Xylogics Ole Jacobsen, Interop Ken Jones Satish Joshi, Synoptics Frank Kastenholz, Racal-Interlan Shimshon Kaufman, Spartacus Ken Key, University of Tennessee at Knoxville
SNMP Working Group [Page 7]
RFC 1215 Convention for Defining Traps March 1991
Jim Kinder, Fibercom Alex Koifman, BBN Christopher Kolb, PSI Cheryl Krupczak, NCR Paul Langille, DEC Peter Lin, Vitalink John Lunny, TWG Carl Malamud Randy Mayhew, University of Tennessee at Knoxville Keith McCloghrie, Hughes LAN Systems Donna McMaster, David Systems Lynn Monsanto, Sun Dave Perkins, 3COM Jim Reinstedler, Ungerman Bass Anil Rijsinghani, DEC Kathy Rinehart, Arnold AFB Kary Robertson Marshall T. Rose, PSI (chair) L. Michael Sabo, NCSC Jon Saperia, DEC Greg Satz, cisco Martin Schoffstall, PSI John Seligson Steve Sherry, Xyplex Fei Shu, NEC Sam Sjogren, TGV Mark Sleeper, Sparta Lance Sprung Mike St.Johns Bob Stewart, Xyplex Emil Sturniold Kaj Tesink, Bellcore Dean Throop, Data General Bill Townsend, Xylogics Maurice Turcotte, Racal-Milgo Kannan Varadhou Sudhanshu Verma, HP Bill Versteeg, Network Research Corporation Warren Vik, Interactive Systems David Waitzman, BBN Steve Waldbusser, CMU Dan Wintringhan David Wood Wengyik Yeong, PSI Jeff Young, Cray Research
SNMP Working Group [Page 8]
RFC 1215 Convention for Defining Traps March 1991
4. References
[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, NRI, April 1988.
[2] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989.
[3] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.
[4] McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990.
[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990.
[6] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization International Standard 8824, December 1987.
[7] Rose M., Editor, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, Performance Systems International, March 1991.
5. Security Considerations
Security issues are not discussed in this memo.
6. Author's Address
Marshall T. Rose Performance Systems International 5201 Great America Parkway Suite 3106 Santa Clara, CA 95054
