GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1215

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1215.txt · Last modified: 1991/06/03 23:46 (external edit)