summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1215.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1215.txt')
-rw-r--r--doc/rfc/rfc1215.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc1215.txt b/doc/rfc/rfc1215.txt
new file mode 100644
index 0000000..431933b
--- /dev/null
+++ b/doc/rfc/rfc1215.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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)
+
+ VarPart ::=
+ "VARIABLES" "{" VarTypes "}"
+ | empty
+ VarTypes ::=
+ VarType | VarTypes "," VarType
+ VarType ::=
+ value (vartype ObjectName)
+
+ 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:
+
+ myEnterprise OBJECT IDENTIFIER ::= { enterprises 9999 }
+
+ 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
+
+ Phone: +1 408 562 6222
+
+ EMail: mrose@psi.com
+ X.500: rose, psi, us
+
+
+
+
+
+SNMP Working Group [Page 9]
+ \ No newline at end of file