home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1200s / rfc1215.txt < prev    next >
Text File  |  1991-06-02  |  19KB  |  507 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                   M. Rose, Editor
  8. Request for Comments: 1215            Performance Systems International
  9.                                                              March 1991
  10.  
  11.  
  12.                     A Convention for Defining Traps
  13.                          for use with the SNMP
  14.  
  15. Status of this Memo
  16.  
  17.    This memo suggests a straight-forward approach towards defining traps
  18.    used with the SNMP.  Readers should note that the use of traps in the
  19.    Internet-standard network management framework is controversial.  As
  20.    such, this memo is being put forward for information purposes.
  21.    Network management practitioners who employ traps are encouraged to
  22.    make use of this document.  Practitioners who do not employ traps can
  23.    safely ignore this document.
  24.  
  25.    This memo provides information for the Internet community.  It does
  26.    not specify any standard.  Distribution of this memo is unlimited.
  27.  
  28. Table of Contents
  29.  
  30.    1. Historical Perspective ................................    1
  31.    2. Defining Traps ........................................    2
  32.    2.1 Mapping of the TRAP-TYPE macro .......................    3
  33.    2.1.1 Mapping of the ENTERPRISE clause ...................    3
  34.    2.1.2 Mapping of the VARIABLES clause ....................    4
  35.    2.1.3 Mapping of the DESCRIPTION clause ..................    4
  36.    2.1.4 Mapping of the REFERENCE clause ....................    4
  37.    2.1.5 Mapping of the TRAP-TYPE value .....................    4
  38.    2.2 Usage Examples .......................................    5
  39.    2.2.1 Enterprise-specific Trap ...........................    5
  40.    2.2.2 Generic-Traps for use with the SNMP ................    5
  41.    3. Acknowledgements ......................................    7
  42.    4. References ............................................    9
  43.    5. Security Considerations................................    9
  44.    6. Author's Address.......................................    9
  45.  
  46. 1.  Historical Perspective
  47.  
  48.    As reported in RFC 1052, IAB Recommendations for the Development of
  49.    Internet Network Management Standards [1], a two-prong strategy for
  50.    network management of TCP/IP-based internets was undertaken.  In the
  51.    short-term, the Simple Network Management Protocol (SNMP), defined in
  52.    RFC 1067, was to be used to manage nodes in the Internet community.
  53.    In the long-term, the use of the OSI network management framework was
  54.    be examined.  Two documents were produced to define the management
  55.  
  56.  
  57.  
  58. SNMP Working Group                                              [Page 1]
  59.  
  60. RFC 1215             Convention for Defining Traps            March 1991
  61.  
  62.  
  63.    information: RFC 1065, which defined the Structure of Management
  64.    Information (SMI), and RFC 1066, which defined the Management
  65.    Information Base (MIB).  Both of these documents were designed so as
  66.    to be compatible with both the SNMP and the OSI network management
  67.    framework.
  68.  
  69.    This strategy was quite successful in the short-term: Internet-based
  70.    network management technology was fielded, by both the research and
  71.    commercial communities, within a few months.  As a result of this,
  72.    portions of the Internet community became network manageable in a
  73.    timely fashion.
  74.  
  75.    As reported in RFC 1109, Report of the Second Ad Hoc Network
  76.    Management Review Group [2], the requirements of the SNMP and the OSI
  77.    network management frameworks were more different than anticipated.
  78.    As such, the requirement for compatibility between the SMI/MIB and
  79.    both frameworks was suspended.  This action permitted the operational
  80.    network management framework, based on the SNMP, to respond to new
  81.    operational needs in the Internet community by producing MIB-II.
  82.  
  83.    In May of 1990, the core documents were elevated to "Standard
  84.    Protocols" with "Recommended" status.  As such, the Internet-standard
  85.    network management framework consists of: Structure and
  86.    Identification of Management Information for TCP/IP-based internets,
  87.    RFC 1155 [3], which describes how managed objects contained in the
  88.    MIB are defined; Management Information Base for Network Management
  89.    of TCP/IP-based internets, which describes the managed objects
  90.    contained in the MIB, RFC 1156 [4]; and, the Simple Network
  91.    Management Protocol, RFC 1157 [5], which defines the protocol used to
  92.    manage these objects.
  93.  
  94. 2.  Defining Traps
  95.  
  96.    Due to its initial requirement to be protocol-independent, the
  97.    Internet-standard SMI does not provide a means for defining traps.
  98.    Instead, the SNMP defines a few standardized traps and provides a
  99.    means for management enterprises to transmit enterprise-specific
  100.    traps.
  101.  
  102.    However, with the introduction of experimental MIBs, some of which
  103.    have a need to define experiment-specific traps, a convenient means
  104.    of defining traps is desirable.  The TRAP-TYPE macro is suggested for
  105.    this purpose:
  106.  
  107.           IMPORTS
  108.               ObjectName
  109.                   FROM RFC1155-SMI;
  110.  
  111.  
  112.  
  113.  
  114. SNMP Working Group                                              [Page 2]
  115.  
  116. RFC 1215             Convention for Defining Traps            March 1991
  117.  
  118.  
  119.           TRAP-TYPE MACRO ::=
  120.           BEGIN
  121.               TYPE NOTATION ::= "ENTERPRISE" value
  122.                                     (enterprise OBJECT IDENTIFIER)
  123.                                 VarPart
  124.                                 DescrPart
  125.                                 ReferPart
  126.               VALUE NOTATION ::= value (VALUE INTEGER)
  127.  
  128.               VarPart ::=
  129.                          "VARIABLES" "{" VarTypes "}"
  130.                               | empty
  131.               VarTypes ::=
  132.                          VarType | VarTypes "," VarType
  133.               VarType ::=
  134.                          value (vartype ObjectName)
  135.  
  136.               DescrPart ::=
  137.                          "DESCRIPTION" value (description DisplayString)
  138.                               | empty
  139.  
  140.               ReferPart ::=
  141.                          "REFERENCE" value (reference DisplayString)
  142.                               | empty
  143.  
  144.           END
  145.  
  146.    It must be emphasized however, that the use of traps is STRONGLY
  147.    discouraged in the Internet-standard Network Management Framework.
  148.    The TRAP-TYPE macro is intended to allow concise definitions of
  149.    existing traps, not to spur the definition of new traps.
  150.  
  151. 2.1.  Mapping of the TRAP-TYPE macro
  152.  
  153.    It should be noted that the expansion of the TRAP-TYPE macro is
  154.    something which conceptually happens during implementation and not
  155.    during run-time.
  156.  
  157. 2.1.1.  Mapping of the ENTERPRISE clause
  158.  
  159.    The ENTERPRISE clause, which must be present, defines the management
  160.    enterprise under whose registration authority this trap is defined
  161.    (for a discussion on delegation of registration authority, see the
  162.    SMI [3]).  This value is placed inside the enterprise field of the
  163.    SNMP Trap-PDU.
  164.  
  165.    By convention, if the value of the ENTERPRISE clause is
  166.  
  167.  
  168.  
  169.  
  170. SNMP Working Group                                              [Page 3]
  171.  
  172. RFC 1215             Convention for Defining Traps            March 1991
  173.  
  174.  
  175.                 snmp   OBJECT IDENTIFIER ::= { mib-2 11 }
  176.  
  177.    as defined in MIB-II [7], then instead of using this value, the value
  178.    of sysObjectID is placed in the enterprise field of the SNMP Trap-
  179.    PDU.  This provides a simple means of using the TRAP-TYPE macro to
  180.    represent the existing standard SNMP traps; it is not intended to
  181.    provide a means to define additional standard SNMP traps.
  182.  
  183. 2.1.2.  Mapping of the VARIABLES clause
  184.  
  185.    The VARIABLES clause, which need not be present, defines the ordered
  186.    sequence of MIB objects which are contained within every instance of
  187.    the trap type.  Each variable is placed, in order, inside the
  188.    variable-bindings field of the SNMP Trap-PDU.  Note that at the
  189.    option of the agent, additional variables may follow in the
  190.    variable-bindings field.
  191.  
  192.    However, if the value of the ENTERPRISE clause is
  193.  
  194.                snmp   OBJECT IDENTIFIER ::= { mib-2 11 }
  195.  
  196.    as defined in MIB-II [7], then the introduction of additional
  197.    variables must not result in the serialized SNMP Message being larger
  198.    than 484 octets.
  199.  
  200. 2.1.3.  Mapping of the DESCRIPTION clause
  201.  
  202.    The DESCRIPTION clause, which need not be present, contains a textual
  203.    definition of the trap type.  Note that in order to conform to the
  204.    ASN.1 syntax, the entire value of this clause must be enclosed in
  205.    double quotation marks, although the value may be multi-line.
  206.  
  207.    Further, note that if the MIB module does not contain a textual
  208.    description of the trap elsewhere then the DESCRIPTION clause must be
  209.    present.
  210.  
  211. 2.1.4.  Mapping of the REFERENCE clause
  212.  
  213.    The REFERENCE clause, which need not be present, contains a textual
  214.    cross-reference to a trap, event, or alarm, defined in some other MIB
  215.    module.  This is useful when de-osifying a MIB produced by some other
  216.    organization.
  217.  
  218. 2.1.5.  Mapping of the TRAP-TYPE value
  219.  
  220.    The value of an invocation of the TRAP-TYPE macro is the (integer)
  221.    number which is uniquely assigned to the trap by the registration
  222.    authority indicated by the ENTERPRISE clause.  This value is placed
  223.  
  224.  
  225.  
  226. SNMP Working Group                                              [Page 4]
  227.  
  228. RFC 1215             Convention for Defining Traps            March 1991
  229.  
  230.  
  231.    inside the specific-trap field of the SNMP Trap-PDU, and the
  232.    generic-trap field is set to "enterpriseSpecific(6)".
  233.  
  234.    By convention, if the value of the ENTERPRISE clause is
  235.  
  236.                snmp   OBJECT IDENTIFIER ::= { mib-2 11 }
  237.  
  238.    as defined in MIB-II [7], then the value of an invocation of the
  239.    TRAP-TYPE macro is placed inside the generic-trap field of the SNMP
  240.    Trap-PDU, and the specific-trap field is set to 0.  This provides a
  241.    simple means of using the TRAP-TYPE macro to represent the existing
  242.    standard SNMP traps; it is not intended to provide a means to define
  243.    additional standard SNMP traps.
  244.  
  245. 2.2.  Usage Examples
  246.  
  247. 2.2.1.  Enterprise-specific Trap
  248.  
  249.    Consider a simple example of an enterprise-specific trap that is sent
  250.    when a communication link failure is encountered:
  251.  
  252.           myEnterprise OBJECT IDENTIFIER ::= { enterprises 9999 }
  253.  
  254.           myLinkDown TRAP-TYPE
  255.               ENTERPRISE  myEnterprise
  256.               VARIABLES   { ifIndex }
  257.               DESCRIPTION
  258.                           "A myLinkDown trap signifies that the sending
  259.                           SNMP application entity recognizes a failure
  260.                           in one of the communications links represented
  261.                           in the agent's configuration."
  262.               ::= 2
  263.  
  264. 2.2.2.  Generic-Traps for use with the SNMP
  265.  
  266.    Consider how the standard SNMP traps might be defined:
  267.  
  268.           coldStart TRAP-TYPE
  269.               ENTERPRISE  snmp
  270.               DESCRIPTION
  271.                           "A coldStart trap signifies that the sending
  272.                           protocol entity is reinitializing itself such
  273.                           that the agent's configuration or the rotocol
  274.                           entity implementation may be altered."
  275.               ::= 0
  276.  
  277.           warmStart TRAP-TYPE
  278.               ENTERPRISE  snmp
  279.  
  280.  
  281.  
  282. SNMP Working Group                                              [Page 5]
  283.  
  284. RFC 1215             Convention for Defining Traps            March 1991
  285.  
  286.  
  287.               DESCRIPTION
  288.                           "A warmStart trap signifies that the sending
  289.                           protocol entity is reinitializing itself such
  290.                           that neither the agent configuration nor the
  291.                           protocol entity implementation is altered."
  292.               ::= 1
  293.  
  294.           linkDown TRAP-TYPE
  295.               ENTERPRISE  snmp
  296.               VARIABLES   { ifIndex }
  297.               DESCRIPTION
  298.                           "A linkDown trap signifies that the sending
  299.                           protocol entity recognizes a failure in one of
  300.                           the communication links represented in the
  301.                           agent's configuration."
  302.               ::= 2
  303.  
  304.           linkUp TRAP-TYPE
  305.               ENTERPRISE  snmp
  306.               VARIABLES   { ifIndex }
  307.               DESCRIPTION
  308.                           "A linkUp trap signifies that the sending
  309.                           protocol entity recognizes that one of the
  310.                           communication links represented in the agent's
  311.                           configuration has come up."
  312.               ::= 3
  313.  
  314.           authenticationFailure TRAP-TYPE
  315.               ENTERPRISE  snmp
  316.               DESCRIPTION
  317.                           "An authenticationFailure trap signifies that
  318.                           the sending protocol entity is the addressee
  319.                           of a protocol message that is not properly
  320.                           authenticated.  While implementations of the
  321.                           SNMP must be capable of generating this trap,
  322.                           they must also be capable of suppressing the
  323.                           emission of such traps via an implementation-
  324.                           specific mechanism."
  325.               ::= 4
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. SNMP Working Group                                              [Page 6]
  339.  
  340. RFC 1215             Convention for Defining Traps            March 1991
  341.  
  342.  
  343.           egpNeighborLoss TRAP-TYPE
  344.               ENTERPRISE  snmp
  345.               VARIABLES   { egpNeighAddr }
  346.               DESCRIPTION
  347.                           "An egpNeighborLoss trap signifies that an EGP
  348.                           neighbor for whom the sending protocol entity
  349.                           was an EGP peer has been marked down and the
  350.                           peer relationship no longer obtains."
  351.               ::= 5
  352.  
  353. 3.  Acknowledgements
  354.  
  355.    This document was produced by the SNMP Working Group:
  356.  
  357.                Anne Ambler, Spider
  358.                Karl Auerbach, Sun
  359.                Fred Baker, ACC
  360.                Ken Brinkerhoff
  361.                Ron Broersma, NOSC
  362.                Jack Brown, US Army
  363.                Theodore Brunner, Bellcore
  364.                Jeffrey Buffum, HP
  365.                John Burress, Wellfleet
  366.                Jeffrey D. Case, University of Tennessee at Knoxville
  367.                Chris Chiptasso, Spartacus
  368.                Paul Ciarfella, DEC
  369.                Bob Collet
  370.                John Cook, Chipcom
  371.                Tracy Cox, Bellcore
  372.                James R. Davin, MIT-LCS
  373.                Eric Decker, cisco
  374.                Kurt Dobbins, Cabletron
  375.                Nadya El-Afandi, Network Systems
  376.                Gary Ellis, HP
  377.                Fred Engle
  378.                Mike Erlinger
  379.                Mark S. Fedor, PSI
  380.                Richard Fox, Synoptics
  381.                Karen Frisa, CMU
  382.                Chris Gunner, DEC
  383.                Fred Harris, University of Tennessee at Knoxville
  384.                Ken Hibbard, Xylogics
  385.                Ole Jacobsen, Interop
  386.                Ken Jones
  387.                Satish Joshi, Synoptics
  388.                Frank Kastenholz, Racal-Interlan
  389.                Shimshon Kaufman, Spartacus
  390.                Ken Key, University of Tennessee at Knoxville
  391.  
  392.  
  393.  
  394. SNMP Working Group                                              [Page 7]
  395.  
  396. RFC 1215             Convention for Defining Traps            March 1991
  397.  
  398.  
  399.                Jim Kinder, Fibercom
  400.                Alex Koifman, BBN
  401.                Christopher Kolb, PSI
  402.                Cheryl Krupczak, NCR
  403.                Paul Langille, DEC
  404.                Peter Lin, Vitalink
  405.                John Lunny, TWG
  406.                Carl Malamud
  407.                Randy Mayhew, University of Tennessee at Knoxville
  408.                Keith McCloghrie, Hughes LAN Systems
  409.                Donna McMaster, David Systems
  410.                Lynn Monsanto, Sun
  411.                Dave Perkins, 3COM
  412.                Jim Reinstedler, Ungerman Bass
  413.                Anil Rijsinghani, DEC
  414.                Kathy Rinehart, Arnold AFB
  415.                Kary Robertson
  416.                Marshall T. Rose, PSI (chair)
  417.                L. Michael Sabo, NCSC
  418.                Jon Saperia, DEC
  419.                Greg Satz, cisco
  420.                Martin Schoffstall, PSI
  421.                John Seligson
  422.                Steve Sherry, Xyplex
  423.                Fei Shu, NEC
  424.                Sam Sjogren, TGV
  425.                Mark Sleeper, Sparta
  426.                Lance Sprung
  427.                Mike St.Johns
  428.                Bob Stewart, Xyplex
  429.                Emil Sturniold
  430.                Kaj Tesink, Bellcore
  431.                Dean Throop, Data General
  432.                Bill Townsend, Xylogics
  433.                Maurice Turcotte, Racal-Milgo
  434.                Kannan Varadhou
  435.                Sudhanshu Verma, HP
  436.                Bill Versteeg, Network Research Corporation
  437.                Warren Vik, Interactive Systems
  438.                David Waitzman, BBN
  439.                Steve Waldbusser, CMU
  440.                Dan Wintringhan
  441.                David Wood
  442.                Wengyik Yeong, PSI
  443.                Jeff Young, Cray Research
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. SNMP Working Group                                              [Page 8]
  451.  
  452. RFC 1215             Convention for Defining Traps            March 1991
  453.  
  454.  
  455. 4.  References
  456.  
  457.    [1] Cerf, V., "IAB Recommendations for the Development of Internet
  458.        Network Management Standards", RFC 1052, NRI, April 1988.
  459.  
  460.    [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
  461.        Group", RFC 1109, NRI, August 1989.
  462.  
  463.    [3] Rose M., and K. McCloghrie, "Structure and Identification of
  464.        Management Information for TCP/IP-based internets", RFC 1155,
  465.        Performance Systems International, Hughes LAN Systems, May 1990.
  466.  
  467.    [4] McCloghrie K., and M. Rose, "Management Information Base for
  468.        Network Management of TCP/IP-based internets", RFC 1156, Hughes
  469.        LAN Systems, Performance Systems International, May 1990.
  470.  
  471.    [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
  472.        Network Management Protocol", RFC 1157, SNMP Research,
  473.        Performance Systems International, Performance Systems
  474.        International, MIT Laboratory for Computer Science, May 1990.
  475.  
  476.    [6] Information processing systems - Open Systems Interconnection -
  477.        Specification of Abstract Syntax Notation One (ASN.1),
  478.        International Organization for Standardization International
  479.        Standard 8824, December 1987.
  480.  
  481.    [7] Rose M., Editor, "Management Information Base for Network
  482.        Management of TCP/IP-based internets: MIB-II", RFC 1213,
  483.        Performance Systems International, March 1991.
  484.  
  485. 5.  Security Considerations
  486.  
  487.    Security issues are not discussed in this memo.
  488.  
  489. 6.  Author's Address
  490.  
  491.    Marshall T. Rose
  492.    Performance Systems International
  493.    5201 Great America Parkway
  494.    Suite 3106
  495.    Santa Clara, CA  95054
  496.  
  497.    Phone: +1 408 562 6222
  498.  
  499.    EMail: mrose@psi.com
  500.    X.500:  rose, psi, us
  501.  
  502.  
  503.  
  504.  
  505.  
  506. SNMP Working Group                                              [Page 9]
  507.