home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1900s / rfc1905.txt < prev    next >
Text File  |  1996-01-19  |  56KB  |  1,348 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                               SNMPv2 Working Group
  8. Request for Comments: 1905                                       J. Case
  9. Obsoletes: 1448                                      SNMP Research, Inc.
  10. Category: Standards Track                                  K. McCloghrie
  11.                                                      Cisco Systems, Inc.
  12.                                                                  M. Rose
  13.                                             Dover Beach Consulting, Inc.
  14.                                                            S. Waldbusser
  15.                                           International Network Services
  16.                                                             January 1996
  17.  
  18.  
  19.                           Protocol Operations
  20.                           for Version 2 of the
  21.               Simple Network Management Protocol (SNMPv2)
  22.  
  23. Status of this Memo
  24.  
  25.    This document specifies an Internet standards track protocol for the
  26.    Internet community, and requests discussion and suggestions for
  27.    improvements.  Please refer to the current edition of the "Internet
  28.    Official Protocol Standards" (STD 1) for the standardization state
  29.    and status of this protocol.  Distribution of this memo is unlimited.
  30.  
  31. 1.  Introduction
  32.  
  33.    A management system contains:  several (potentially many) nodes, each
  34.    with a processing entity, termed an agent, which has access to
  35.    management instrumentation; at least one management station; and, a
  36.    management protocol, used to convey management information between
  37.    the agents and management stations.  Operations of the protocol are
  38.    carried out under an administrative framework which defines
  39.    authentication, authorization, access control, and privacy policies.
  40.  
  41.    Management stations execute management applications which monitor and
  42.    control managed elements.  Managed elements are devices such as
  43.    hosts, routers, terminal servers, etc., which are monitored and
  44.    controlled via access to their management information.
  45.  
  46.    Management information is viewed as a collection of managed objects,
  47.    residing in a virtual information store, termed the Management
  48.    Information Base (MIB).  Collections of related objects are defined
  49.    in MIB modules.  These modules are written using a subset of OSI's
  50.    Abstract Syntax Notation One (ASN.1) [1], termed the Structure of
  51.    Management Information (SMI) [2].
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. SNMPv2 Working Group        Standards Track                     [Page 1]
  59.  
  60. RFC 1905             Protocol Operations for SNMPv2         January 1996
  61.  
  62.  
  63.    The management protocol, version 2 of the Simple Network Management
  64.    Protocol, provides for the exchange of messages which convey
  65.    management information between the agents and the management
  66.    stations.  The form of these messages is a message "wrapper" which
  67.    encapsulates a Protocol Data Unit (PDU).  The form and meaning of the
  68.    "wrapper" is determined by an administrative framework which defines
  69.    both authentication and authorization policies.
  70.  
  71.    It is the purpose of this document, Protocol Operations for SNMPv2,
  72.    to define the operations of the protocol with respect to the sending
  73.    and receiving of the PDUs.
  74.  
  75. 1.1.  A Note on Terminology
  76.  
  77.    For the purpose of exposition, the original Internet-standard Network
  78.    Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD
  79.    15), and 1212 (STD 16), is termed the SNMP version 1 framework
  80.    (SNMPv1).  The current framework is termed the SNMP version 2
  81.    framework (SNMPv2).
  82.  
  83. 2.  Overview
  84.  
  85. 2.1.  Roles of Protocol Entities
  86.  
  87.    A SNMPv2 entity may operate in a manager role or an agent role.
  88.  
  89.    A SNMPv2 entity acts in an agent role when it performs SNMPv2
  90.    management operations in response to received SNMPv2 protocol
  91.    messages (other than an inform notification) or when it sends trap
  92.    notifications.
  93.  
  94.    A SNMPv2 entity acts in a manager role when it initiates SNMPv2
  95.    management operations by the generation of SNMPv2 protocol messages
  96.    or when it performs SNMPv2 management operations in response to
  97.    received trap or inform notifications.
  98.  
  99.    A SNMPv2 entity may support either or both roles, as dictated by its
  100.    implementation and configuration.  Further, a SNMPv2 entity can also
  101.    act in the role of a proxy agent, in which it appears to be acting in
  102.    an agent role, but satisfies management requests by acting in a
  103.    manager role with a remote entity.
  104.  
  105. 2.2.  Management Information
  106.  
  107.    The term, variable, refers to an instance of a non-aggregate object
  108.    type defined according to the conventions set forth in the SMI [2] or
  109.    the textual conventions based on the SMI [3].  The term, variable
  110.    binding, normally refers to the pairing of the name of a variable and
  111.  
  112.  
  113.  
  114. SNMPv2 Working Group        Standards Track                     [Page 2]
  115.  
  116. RFC 1905             Protocol Operations for SNMPv2         January 1996
  117.  
  118.  
  119.    its associated value.  However, if certain kinds of exceptional
  120.    conditions occur during processing of a retrieval request, a variable
  121.    binding will pair a name and an indication of that exception.
  122.  
  123.    A variable-binding list is a simple list of variable bindings.
  124.  
  125.    The name of a variable is an OBJECT IDENTIFIER which is the
  126.    concatenation of the OBJECT IDENTIFIER of the corresponding object-
  127.    type together with an OBJECT IDENTIFIER fragment identifying the
  128.    instance.  The OBJECT IDENTIFIER of the corresponding object-type is
  129.    called the OBJECT IDENTIFIER prefix of the variable.
  130.  
  131. 2.3.  Access to Management Information
  132.  
  133.    Three types of access to management information are provided by the
  134.    protocol.  One type is a request-response interaction, in which a
  135.    SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2
  136.    entity, acting in an agent role, and the latter SNMPv2 entity then
  137.    responds to the request.  This type is used to retrieve or modify
  138.    management information associated with the managed device.
  139.  
  140.    A second type is also a request-response interaction, in which a
  141.    SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2
  142.    entity, also acting in a manager role, and the latter SNMPv2 entity
  143.    then responds to the request.  This type is used to notify a SNMPv2
  144.    entity, acting in a manager role, of management information
  145.    associated with another SNMPv2 entity, also acting in a manager role.
  146.  
  147.    The third type of access is an unconfirmed interaction, in which a
  148.    SNMPv2 entity, acting in an agent role, sends a unsolicited message,
  149.    termed a trap, to a SNMPv2 entity, acting in a manager role, and no
  150.    response is returned.  This type is used to notify a SNMPv2 entity,
  151.    acting in a manager role, of an exceptional situation, which has
  152.    resulted in changes to management information associated with the
  153.    managed device.
  154.  
  155. 2.4.  Retransmission of Requests
  156.  
  157.    For all types of request in this protocol, the receiver is required
  158.    under normal circumstances, to generate and transmit a response to
  159.    the originator of the request.  Whether or not a request should be
  160.    retransmitted if no corresponding response is received in an
  161.    appropriate time interval, is at the discretion of the application
  162.    originating the request.  This will normally depend on the urgency of
  163.    the request.  However, such an application needs to act responsibly
  164.    in respect to the frequency and duration of re-transmissions.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. SNMPv2 Working Group        Standards Track                     [Page 3]
  171.  
  172. RFC 1905             Protocol Operations for SNMPv2         January 1996
  173.  
  174.  
  175. 2.5.  Message Sizes
  176.  
  177.    The maximum size of a SNMPv2 message is limited to the minimum of:
  178.  
  179. (1)  the maximum message size which the destination SNMPv2 entity can
  180.      accept; and,
  181.  
  182. (2)  the maximum message size which the source SNMPv2 entity can
  183.      generate.
  184.  
  185.    The former may be known on a per-recipient basis; and in the absence
  186.    of such knowledge, is indicated by transport domain used when sending
  187.    the message.  The latter is imposed by implementation-specific local
  188.    constraints.
  189.  
  190.    Each transport mapping for the SNMPv2 indicates the minimum message
  191.    size which a SNMPv2 implementation must be able to produce or
  192.    consume.  Although implementations are encouraged to support larger
  193.    values whenever possible, a conformant implementation must never
  194.    generate messages larger than allowed by the receiving SNMPv2 entity.
  195.  
  196.    One of the aims of the GetBulkRequest-PDU, specified in this
  197.    protocol, is to minimize the number of protocol exchanges required to
  198.    retrieve a large amount of management information.  As such, this PDU
  199.    type allows a SNMPv2 entity acting in a manager role to request that
  200.    the response be as large as possible given the constraints on message
  201.    sizes.  These constraints include the limits on the size of messages
  202.    which the SNMPv2 entity acting in an agent role can generate, and the
  203.    SNMPv2 entity acting in a manager role can receive.
  204.  
  205.    However, it is possible that such maximum sized messages may be
  206.    larger than the Path MTU of the path across the network traversed by
  207.    the messages.  In this situation, such messages are subject to
  208.    fragmentation.  Fragmentation is generally considered to be harmful
  209.    [4], since among other problems, it leads to a decrease in the
  210.    reliability of the transfer of the messages.  Thus, a SNMPv2 entity
  211.    which sends a GetBulkRequest-PDU must take care to set its parameters
  212.    accordingly, so as to reduce the risk of fragmentation.  In
  213.    particular, under conditions of network stress, only small values
  214.    should be used for max-repetitions.
  215.  
  216. 2.6.  Transport Mappings
  217.  
  218.    It is important to note that the exchange of SNMPv2 messages requires
  219.    only an unreliable datagram service, with every message being
  220.    entirely and independently contained in a single transport datagram.
  221.    Specific transport mappings and encoding rules are specified
  222.    elsewhere [5].  However, the preferred mapping is the use of the User
  223.  
  224.  
  225.  
  226. SNMPv2 Working Group        Standards Track                     [Page 4]
  227.  
  228. RFC 1905             Protocol Operations for SNMPv2         January 1996
  229.  
  230.  
  231.    Datagram Protocol [6].
  232.  
  233. 3.  Definitions
  234.  
  235.      SNMPv2-PDU DEFINITIONS ::= BEGIN
  236.  
  237.      IMPORTS
  238.          ObjectName, ObjectSyntax, Integer32
  239.              FROM SNMPv2-SMI;
  240.  
  241.  
  242.      -- protocol data units
  243.  
  244.      PDUs ::=
  245.          CHOICE {
  246.              get-request
  247.                  GetRequest-PDU,
  248.  
  249.              get-next-request
  250.                  GetNextRequest-PDU,
  251.  
  252.              get-bulk-request
  253.                  GetBulkRequest-PDU,
  254.  
  255.              response
  256.                  Response-PDU,
  257.  
  258.              set-request
  259.                  SetRequest-PDU,
  260.  
  261.              inform-request
  262.                  InformRequest-PDU,
  263.  
  264.              snmpV2-trap
  265.                  SNMPv2-Trap-PDU,
  266.  
  267.              report
  268.                  Report-PDU,
  269.          }
  270.  
  271.  
  272.      -- PDUs
  273.  
  274.      GetRequest-PDU ::=
  275.          [0]
  276.              IMPLICIT PDU
  277.  
  278.      GetNextRequest-PDU ::=
  279.  
  280.  
  281.  
  282. SNMPv2 Working Group        Standards Track                     [Page 5]
  283.  
  284. RFC 1905             Protocol Operations for SNMPv2         January 1996
  285.  
  286.  
  287.          [1]
  288.              IMPLICIT PDU
  289.  
  290.      Response-PDU ::=
  291.          [2]
  292.              IMPLICIT PDU
  293.  
  294.      SetRequest-PDU ::=
  295.          [3]
  296.              IMPLICIT PDU
  297.  
  298.      -- [4] is obsolete
  299.  
  300.      GetBulkRequest-PDU ::=
  301.          [5]
  302.              IMPLICIT BulkPDU
  303.  
  304.      InformRequest-PDU ::=
  305.          [6]
  306.              IMPLICIT PDU
  307.  
  308.      SNMPv2-Trap-PDU ::=
  309.          [7]
  310.              IMPLICIT PDU
  311.  
  312.      --   Usage and precise semantics of Report-PDU are not presently
  313.      --   defined.  Any SNMP administrative framework making use of
  314.      --   this PDU must define its usage and semantics.
  315.      Report-PDU ::=
  316.          [8]
  317.              IMPLICIT PDU
  318.  
  319.      max-bindings
  320.          INTEGER ::= 2147483647
  321.  
  322.      PDU ::=
  323.          SEQUENCE {
  324.              request-id
  325.                  Integer32,
  326.  
  327.              error-status            -- sometimes ignored
  328.                  INTEGER {
  329.                      noError(0),
  330.                      tooBig(1),
  331.                      noSuchName(2),   -- for proxy compatibility
  332.                      badValue(3),     -- for proxy compatibility
  333.                      readOnly(4),     -- for proxy compatibility
  334.                      genErr(5),
  335.  
  336.  
  337.  
  338. SNMPv2 Working Group        Standards Track                     [Page 6]
  339.  
  340. RFC 1905             Protocol Operations for SNMPv2         January 1996
  341.  
  342.  
  343.                      noAccess(6),
  344.                      wrongType(7),
  345.                      wrongLength(8),
  346.                      wrongEncoding(9),
  347.                      wrongValue(10),
  348.                      noCreation(11),
  349.                      inconsistentValue(12),
  350.                      resourceUnavailable(13),
  351.                      commitFailed(14),
  352.                      undoFailed(15),
  353.                      authorizationError(16),
  354.                      notWritable(17),
  355.                      inconsistentName(18)
  356.                  },
  357.  
  358.              error-index            -- sometimes ignored
  359.                  INTEGER (0..max-bindings),
  360.  
  361.              variable-bindings   -- values are sometimes ignored
  362.                  VarBindList
  363.          }
  364.  
  365.  
  366.      BulkPDU ::=                     -- MUST be identical in
  367.          SEQUENCE {                  -- structure to PDU
  368.              request-id
  369.                  Integer32,
  370.  
  371.              non-repeaters
  372.                  INTEGER (0..max-bindings),
  373.  
  374.              max-repetitions
  375.                  INTEGER (0..max-bindings),
  376.  
  377.              variable-bindings       -- values are ignored
  378.                  VarBindList
  379.          }
  380.  
  381.  
  382.      -- variable binding
  383.  
  384.      VarBind ::=
  385.          SEQUENCE {
  386.              name
  387.                  ObjectName,
  388.  
  389.              CHOICE {
  390.                  value
  391.  
  392.  
  393.  
  394. SNMPv2 Working Group        Standards Track                     [Page 7]
  395.  
  396. RFC 1905             Protocol Operations for SNMPv2         January 1996
  397.  
  398.  
  399.                      ObjectSyntax,
  400.  
  401.                  unSpecified         -- in retrieval requests
  402.                          NULL,
  403.  
  404.                                      -- exceptions in responses
  405.                  noSuchObject[0]
  406.                          IMPLICIT NULL,
  407.  
  408.                  noSuchInstance[1]
  409.                          IMPLICIT NULL,
  410.  
  411.                  endOfMibView[2]
  412.                          IMPLICIT NULL
  413.              }
  414.          }
  415.  
  416.  
  417.      -- variable-binding list
  418.  
  419.      VarBindList ::=
  420.          SEQUENCE (SIZE (0..max-bindings)) OF
  421.              VarBind
  422.  
  423.  
  424.      END
  425.  
  426.  
  427. 4.  Protocol Specification
  428.  
  429. 4.1.  Common Constructs
  430.  
  431.    The value of the request-id field in a Response-PDU takes the value
  432.    of the request-id field in the request PDU to which it is a response.
  433.    By use of the request-id value, a SNMPv2 application can distinguish
  434.    the (potentially multiple) outstanding requests, and thereby
  435.    correlate incoming responses with outstanding requests.  In cases
  436.    where an unreliable datagram service is used, the request-id also
  437.    provides a simple means of identifying messages duplicated by the
  438.    network.  Use of the same request-id on a retransmission of a request
  439.    allows the response to either the original transmission or the
  440.    retransmission to satisfy the request.  However, in order to
  441.    calculate the round trip time for transmission and processing of a
  442.    request-response transaction, the SNMPv2 application needs to use a
  443.    different request-id value on a retransmitted request.  The latter
  444.    strategy is recommended for use in the majority of situations.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. SNMPv2 Working Group        Standards Track                     [Page 8]
  451.  
  452. RFC 1905             Protocol Operations for SNMPv2         January 1996
  453.  
  454.  
  455.    A non-zero value of the error-status field in a Response-PDU is used
  456.    to indicate that an exception occurred to prevent the processing of
  457.    the request.  In these cases, a non-zero value of the Response-PDU's
  458.    error-index field provides additional information by identifying
  459.    which variable binding in the list caused the exception.  A variable
  460.    binding is identified by its index value.  The first variable binding
  461.    in a variable-binding list is index one, the second is index two,
  462.    etc.
  463.  
  464.    SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128 sub-
  465.    identifiers, where each sub-identifier has a maximum value of 2**32-
  466.    1.
  467.  
  468. 4.2.  PDU Processing
  469.  
  470.    It is mandatory that all SNMPv2 entities acting in an agent role be
  471.    able to generate the following PDU types:  Response-PDU and SNMPv2-
  472.    Trap-PDU; further, all such implementations must be able to receive
  473.    the following PDU types:  GetRequest-PDU, GetNextRequest-PDU,
  474.    GetBulkRequest-PDU, and SetRequest-PDU.
  475.  
  476.    It is mandatory that all SNMPv2 entities acting in a manager role be
  477.    able to generate the following PDU types: GetRequest-PDU,
  478.    GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
  479.    InformRequest-PDU, and Response-PDU; further, all such
  480.    implementations must be able to receive the following PDU types:
  481.    Response-PDU, SNMPv2-Trap-PDU,
  482.  
  483.    InformRequest-PDU;
  484.  
  485.    In the elements of procedure below, any field of a PDU which is not
  486.    referenced by the relevant procedure is ignored by the receiving
  487.    SNMPv2 entity.  However, all components of a PDU, including those
  488.    whose values are ignored by the receiving SNMPv2 entity, must have
  489.    valid ASN.1 syntax and encoding.  For example, some PDUs (e.g., the
  490.    GetRequest-PDU) are concerned only with the name of a variable and
  491.    not its value.  In this case, the value portion of the variable
  492.    binding is ignored by the receiving SNMPv2 entity.  The unSpecified
  493.    value is defined for use as the value portion of such bindings.
  494.  
  495.    On generating a management communication, the message "wrapper" to
  496.    encapsulate the PDU is generated according to the "Elements of
  497.    Procedure" of the administrative framework in use is followed.  While
  498.    the definition of "max-bindings" does impose an upper-bound on the
  499.    number of variable bindings, in practice, the size of a message is
  500.    limited only by constraints on the maximum message size -- it is not
  501.    limited by the number of variable bindings.
  502.  
  503.  
  504.  
  505.  
  506. SNMPv2 Working Group        Standards Track                     [Page 9]
  507.  
  508. RFC 1905             Protocol Operations for SNMPv2         January 1996
  509.  
  510.  
  511.    On receiving a management communication, the "Elements of Procedure"
  512.    of the administrative framework in use is followed, and if those
  513.    procedures indicate that the operation contained within the message
  514.    is to be performed locally, then those procedures also indicate the
  515.    MIB view which is visible to the operation.
  516.  
  517. 4.2.1.  The GetRequest-PDU
  518.  
  519.    A GetRequest-PDU is generated and transmitted at the request of a
  520.    SNMPv2 application.
  521.  
  522.    Upon receipt of a GetRequest-PDU, the receiving SNMPv2 entity
  523.    processes each variable binding in the variable-binding list to
  524.    produce a Response-PDU.  All fields of the Response-PDU have the same
  525.    values as the corresponding fields of the received request except as
  526.    indicated below.  Each variable binding is processed as follows:
  527.  
  528. (1)  If the variable binding's name exactly matches the name of a
  529.      variable accessible by this request, then the variable binding's
  530.      value field is set to the value of the named variable.
  531.  
  532. (2)  Otherwise, if the variable binding's name does not have an OBJECT
  533.      IDENTIFIER prefix which exactly matches the OBJECT IDENTIFIER
  534.      prefix of any (potential) variable accessible by this request, then
  535.      its value field is set to `noSuchObject'.
  536.  
  537. (3)  Otherwise, the variable binding's value field is set to
  538.      `noSuchInstance'.
  539.  
  540.    If the processing of any variable binding fails for a reason other
  541.    than listed above, then the Response-PDU is re-formatted with the
  542.    same values in its request-id and variable-bindings fields as the
  543.    received GetRequest-PDU, with the value of its error-status field set
  544.    to `genErr', and the value of its error-index field is set to the
  545.    index of the failed variable binding.
  546.  
  547.    Otherwise, the value of the Response-PDU's error-status field is set
  548.    to `noError', and the value of its error-index field is zero.
  549.  
  550.    The generated Response-PDU is then encapsulated into a message.  If
  551.    the size of the resultant message is less than or equal to both a
  552.    local constraint and the maximum message size of the originator, it
  553.    is transmitted to the originator of the GetRequest-PDU.
  554.  
  555.    Otherwise, an alternate Response-PDU is generated.  This alternate
  556.    Response-PDU is formatted with the same value in its request-id field
  557.    as the received GetRequest-PDU, with the value of its error-status
  558.    field set to `tooBig', the value of its error-index field set to
  559.  
  560.  
  561.  
  562. SNMPv2 Working Group        Standards Track                    [Page 10]
  563.  
  564. RFC 1905             Protocol Operations for SNMPv2         January 1996
  565.  
  566.  
  567.    zero, and an empty variable-bindings field.  This alternate
  568.    Response-PDU is then encapsulated into a message.  If the size of the
  569.    resultant message is less than or equal to both a local constraint
  570.    and the maximum message size of the originator, it is transmitted to
  571.    the originator of the GetRequest-PDU.  Otherwise, the snmpSilentDrops
  572.    [9] counter is incremented and the resultant message is discarded.
  573.  
  574. 4.2.2.  The GetNextRequest-PDU
  575.  
  576.    A GetNextRequest-PDU is generated and transmitted at the request of a
  577.    SNMPv2 application.
  578.  
  579.    Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2 entity
  580.    processes each variable binding in the variable-binding list to
  581.    produce a Response-PDU.  All fields of the Response-PDU have the same
  582.    values as the corresponding fields of the received request except as
  583.    indicated below.  Each variable binding is processed as follows:
  584.  
  585. (1)  The variable is located which is in the lexicographically ordered
  586.      list of the names of all variables which are accessible by this
  587.      request and whose name is the first lexicographic successor of the
  588.      variable binding's name in the incoming GetNextRequest-PDU.  The
  589.      corresponding variable binding's name and value fields in the
  590.      Response-PDU are set to the name and value of the located variable.
  591.  
  592. (2)  If the requested variable binding's name does not lexicographically
  593.      precede the name of any variable accessible by this request, i.e.,
  594.      there is no lexicographic successor, then the corresponding
  595.      variable binding produced in the Response-PDU has its value field
  596.      set to `endOfMibView', and its name field set to the variable
  597.      binding's name in the request.
  598.  
  599.    If the processing of any variable binding fails for a reason other
  600.    than listed above, then the Response-PDU is re-formatted with the
  601.    same values in its request-id and variable-bindings fields as the
  602.    received GetNextRequest-PDU, with the value of its error-status field
  603.    set to `genErr', and the value of its error-index field is set to the
  604.    index of the failed variable binding.
  605.  
  606.    Otherwise, the value of the Response-PDU's error-status field is set
  607.    to `noError', and the value of its error-index field is zero.
  608.  
  609.    The generated Response-PDU is then encapsulated into a message.  If
  610.    the size of the resultant message is less than or equal to both a
  611.    local constraint and the maximum message size of the originator, it
  612.    is transmitted to the originator of the GetNextRequest-PDU.
  613.  
  614.  
  615.  
  616.  
  617.  
  618. SNMPv2 Working Group        Standards Track                    [Page 11]
  619.  
  620. RFC 1905             Protocol Operations for SNMPv2         January 1996
  621.  
  622.  
  623.    Otherwise, an alternate Response-PDU is generated.  This alternate
  624.    Response-PDU is formatted with the same values in its request-id
  625.    field as the received GetNextRequest-PDU, with the value of its
  626.    error-status field set to `tooBig', the value of its error-index
  627.    field set to zero, and an empty variable-bindings field.  This
  628.    alternate Response-PDU is then encapsulated into a message.  If the
  629.    size of the resultant message is less than or equal to both a local
  630.    constraint and the maximum message size of the originator, it is
  631.    transmitted to the originator of the GetNextRequest-PDU.  Otherwise,
  632.    the snmpSilentDrops [9] counter is incremented and the resultant
  633.    message is discarded.
  634.  
  635. 4.2.2.1.  Example of Table Traversal
  636.  
  637.    An important use of the GetNextRequest-PDU is the traversal of
  638.    conceptual tables of information within a MIB.  The semantics of this
  639.    type of request, together with the method of identifying individual
  640.    instances of objects in the MIB, provides access to related objects
  641.    in the MIB as if they enjoyed a tabular organization.
  642.  
  643.    In the protocol exchange sketched below, a SNMPv2 application
  644.    retrieves the media-dependent physical address and the address-
  645.    mapping type for each entry in the IP net-to-media Address
  646.    Translation Table [7] of a particular network element.  It also
  647.    retrieves the value of sysUpTime [9], at which the mappings existed.
  648.    Suppose that the agent's IP net-to-media table has three entries:
  649.  
  650.   Interface-Number  Network-Address  Physical-Address  Type
  651.  
  652.          1            10.0.0.51     00:00:10:01:23:45  static
  653.          1             9.2.3.4      00:00:10:54:32:10  dynamic
  654.          2            10.0.0.15     00:00:10:98:76:54  dynamic
  655.  
  656.    The SNMPv2 entity acting in a manager role begins by sending a
  657.    GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values
  658.    as the requested variable names:
  659.  
  660.     GetNextRequest ( sysUpTime,
  661.                      ipNetToMediaPhysAddress,
  662.                      ipNetToMediaType )
  663.  
  664.    The SNMPv2 entity acting in an agent role responds with a Response-
  665.    PDU:
  666.  
  667.     Response (( sysUpTime.0 =  "123456" ),
  668.               ( ipNetToMediaPhysAddress.1.9.2.3.4 =
  669.                                          "000010543210" ),
  670.               ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ))
  671.  
  672.  
  673.  
  674. SNMPv2 Working Group        Standards Track                    [Page 12]
  675.  
  676. RFC 1905             Protocol Operations for SNMPv2         January 1996
  677.  
  678.  
  679.    The SNMPv2 entity acting in a manager role continues with:
  680.  
  681.     GetNextRequest ( sysUpTime,
  682.                      ipNetToMediaPhysAddress.1.9.2.3.4,
  683.                      ipNetToMediaType.1.9.2.3.4 )
  684.  
  685.    The SNMPv2 entity acting in an agent role responds with:
  686.  
  687.     Response (( sysUpTime.0 =  "123461" ),
  688.               ( ipNetToMediaPhysAddress.1.10.0.0.51 =
  689.                                           "000010012345" ),
  690.               ( ipNetToMediaType.1.10.0.0.51 =  "static" ))
  691.  
  692.    The SNMPv2 entity acting in a manager role continues with:
  693.  
  694.     GetNextRequest ( sysUpTime,
  695.                      ipNetToMediaPhysAddress.1.10.0.0.51,
  696.                      ipNetToMediaType.1.10.0.0.51 )
  697.  
  698.    The SNMPv2 entity acting in an agent role responds with:
  699.  
  700.     Response (( sysUpTime.0 =  "123466" ),
  701.               ( ipNetToMediaPhysAddress.2.10.0.0.15 =
  702.                                            "000010987654" ),
  703.               ( ipNetToMediaType.2.10.0.0.15 =  "dynamic" ))
  704.  
  705.    The SNMPv2 entity acting in a manager role continues with:
  706.  
  707.     GetNextRequest ( sysUpTime,
  708.                      ipNetToMediaPhysAddress.2.10.0.0.15,
  709.                      ipNetToMediaType.2.10.0.0.15 )
  710.  
  711.    As there are no further entries in the table, the SNMPv2 entity
  712.    acting in an agent role responds with the variables that are next in
  713.    the lexicographical ordering of the accessible object names, for
  714.    example:
  715.  
  716.     Response (( sysUpTime.0 =  "123471" ),
  717.               ( ipNetToMediaNetAddress.1.9.2.3.4 =
  718.                                                "9.2.3.4" ),
  719.               ( ipRoutingDiscards.0 =  "2" ))
  720.  
  721.    This response signals the end of the table to the SNMPv2 entity
  722.    acting in a manager role.
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. SNMPv2 Working Group        Standards Track                    [Page 13]
  731.  
  732. RFC 1905             Protocol Operations for SNMPv2         January 1996
  733.  
  734.  
  735. 4.2.3.  The GetBulkRequest-PDU
  736.  
  737.    A GetBulkRequest-PDU is generated and transmitted at the request of a
  738.    SNMPv2 application.  The purpose of the GetBulkRequest-PDU is to
  739.    request the transfer of a potentially large amount of data,
  740.    including, but not limited to, the efficient and rapid retrieval of
  741.    large tables.
  742.  
  743.    Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2 entity
  744.    processes each variable binding in the variable-binding list to
  745.    produce a Response-PDU with its request-id field having the same
  746.    value as in the request.  Processing begins by examining the values
  747.    in the non-repeaters and max-repetitions fields.  If the value in the
  748.    non-repeaters field is less than zero, then the value of the field is
  749.    set to zero.  Similarly, if the value in the max-repetitions field is
  750.    less than zero, then the value of the field is set to zero.
  751.  
  752.    For the GetBulkRequest-PDU type, the successful processing of each
  753.    variable binding in the request generates zero or more variable
  754.    bindings in the Response-PDU.  That is, the one-to-one mapping
  755.    between the variable bindings of the GetRequest-PDU, GetNextRequest-
  756.    PDU, and SetRequest-PDU types and the resultant Response-PDUs does
  757.    not apply for the mapping between the variable bindings of a
  758.    GetBulkRequest-PDU and the resultant Response-PDU.
  759.  
  760.    The values of the non-repeaters and max-repetitions fields in the
  761.    request specify the processing requested.  One variable binding in
  762.    the Response-PDU is requested for the first N variable bindings in
  763.    the request and M variable bindings are requested for each of the R
  764.    remaining variable bindings in the request.  Consequently, the total
  765.    number of requested variable bindings communicated by the request is
  766.    given by N + (M * R), where N is the minimum of:  a) the value of the
  767.    non-repeaters field in the request, and b) the number of variable
  768.    bindings in the request; M is the value of the max-repetitions field
  769.    in the request; and R is the maximum of:  a) number of variable
  770.    bindings in the request - N, and b)  zero.
  771.  
  772.    The receiving SNMPv2 entity produces a Response-PDU with up to the
  773.    total number of requested variable bindings communicated by the
  774.    request.  The request-id shall have the same value as the received
  775.    GetBulkRequest-PDU.
  776.  
  777.    If N is greater than zero, the first through the (N)-th variable
  778.    bindings of the Response-PDU are each produced as follows:
  779.  
  780. (1)  The variable is located which is in the lexicographically ordered
  781.      list of the names of all variables which are accessible by this
  782.      request and whose name is the first lexicographic successor of the
  783.  
  784.  
  785.  
  786. SNMPv2 Working Group        Standards Track                    [Page 14]
  787.  
  788. RFC 1905             Protocol Operations for SNMPv2         January 1996
  789.  
  790.  
  791.      variable binding's name in the incoming GetBulkRequest-PDU.  The
  792.      corresponding variable binding's name and value fields in the
  793.      Response-PDU are set to the name and value of the located variable.
  794.  
  795. (2)  If the requested variable binding's name does not lexicographically
  796.      precede the name of any variable accessible by this request, i.e.,
  797.      there is no lexicographic successor, then the corresponding
  798.      variable binding produced in the Response-PDU has its value field
  799.      set to `endOfMibView', and its name field set to the variable
  800.      binding's name in the request.
  801.  
  802.    If M and R are non-zero, the (N + 1)-th and subsequent variable
  803.    bindings of the Response-PDU are each produced in a similar manner.
  804.    For each iteration i, such that i is greater than zero and less than
  805.    or equal to M, and for each repeated variable, r, such that r is
  806.    greater than zero and less than or equal to R, the (N + ( (i-1) * R )
  807.    + r)-th variable binding of the Response-PDU is produced as follows:
  808.  
  809. (1)  The variable which is in the lexicographically ordered list of the
  810.      names of all variables which are accessible by this request and
  811.      whose name is the (i)-th lexicographic successor of the (N + r)-th
  812.      variable binding's name in the incoming GetBulkRequest-PDU is
  813.      located and the variable binding's name and value fields are set to
  814.      the name and value of the located variable.
  815.  
  816. (2)  If there is no (i)-th lexicographic successor, then the
  817.      corresponding variable binding produced in the Response-PDU has its
  818.      value field set to `endOfMibView', and its name field set to either
  819.      the last lexicographic successor, or if there are no lexicographic
  820.      successors, to the (N + r)-th variable binding's name in the
  821.      request.
  822.  
  823.    While the maximum number of variable bindings in the Response-PDU is
  824.    bounded by N + (M * R), the response may be generated with a lesser
  825.    number of variable bindings (possibly zero) for either of three
  826.    reasons.
  827.  
  828. (1)  If the size of the message encapsulating the Response-PDU
  829.      containing the requested number of variable bindings would be
  830.      greater than either a local constraint or the maximum message size
  831.      of the originator, then the response is generated with a lesser
  832.      number of variable bindings.  This lesser number is the ordered set
  833.      of variable bindings with some of the variable bindings at the end
  834.      of the set removed, such that the size of the message encapsulating
  835.      the Response-PDU is approximately equal to but no greater than
  836.      either a local constraint or the maximum message size of the
  837.      originator.  Note that the number of variable bindings removed has
  838.      no relationship to the values of N, M, or R.
  839.  
  840.  
  841.  
  842. SNMPv2 Working Group        Standards Track                    [Page 15]
  843.  
  844. RFC 1905             Protocol Operations for SNMPv2         January 1996
  845.  
  846.  
  847. (2)  The response may also be generated with a lesser number of variable
  848.      bindings if for some value of iteration i, such that i is greater
  849.      than zero and less than or equal to M, that all of the generated
  850.      variable bindings have the value field set to the `endOfMibView'.
  851.      In this case, the variable bindings may be truncated after the (N +
  852.      (i * R))-th variable binding.
  853.  
  854. (3)  In the event that the processing of a request with many repetitions
  855.      requires a significantly greater amount of processing time than a
  856.      normal request, then an agent may terminate the request with less
  857.      than the full number of repetitions, providing at least one
  858.      repetition is completed.
  859.  
  860.    If the processing of any variable binding fails for a reason other
  861.    than listed above, then the Response-PDU is re-formatted with the
  862.    same values in its request-id and variable-bindings fields as the
  863.    received GetBulkRequest-PDU, with the value of its error-status field
  864.    set to `genErr', and the value of its error-index field is set to the
  865.    index of the variable binding in the original request which
  866.    corresponds to the failed variable binding.
  867.  
  868.    Otherwise, the value of the Response-PDU's error-status field is set
  869.    to `noError', and the value of its error-index field to zero.
  870.  
  871.    The generated Response-PDU (possibly with an empty variable-bindings
  872.    field) is then encapsulated into a message.  If the size of the
  873.    resultant message is less than or equal to both a local constraint
  874.    and the maximum message size of the originator, it is transmitted to
  875.    the originator of the GetBulkRequest-PDU.  Otherwise, the
  876.    snmpSilentDrops [9] counter is incremented and the resultant message
  877.    is discarded.
  878.  
  879. 4.2.3.1.  Another Example of Table Traversal
  880.  
  881.    This example demonstrates how the GetBulkRequest-PDU can be used as
  882.    an alternative to the GetNextRequest-PDU.  The same traversal of the
  883.    IP net-to-media table as shown in Section 4.2.2.1 is achieved with
  884.    fewer exchanges.
  885.  
  886.    The SNMPv2 entity acting in a manager role begins by sending a
  887.    GetBulkRequest-PDU with the modest max-repetitions value of 2, and
  888.    containing the indicated OBJECT IDENTIFIER values as the requested
  889.    variable names:
  890.  
  891.     GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
  892.                     ( sysUpTime,
  893.                       ipNetToMediaPhysAddress,
  894.                       ipNetToMediaType )
  895.  
  896.  
  897.  
  898. SNMPv2 Working Group        Standards Track                    [Page 16]
  899.  
  900. RFC 1905             Protocol Operations for SNMPv2         January 1996
  901.  
  902.  
  903.    The SNMPv2 entity acting in an agent role responds with a Response-PDU:
  904.  
  905.     Response (( sysUpTime.0 =  "123456" ),
  906.               ( ipNetToMediaPhysAddress.1.9.2.3.4 =
  907.                                          "000010543210" ),
  908.               ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ),
  909.               ( ipNetToMediaPhysAddress.1.10.0.0.51 =
  910.                                           "000010012345" ),
  911.               ( ipNetToMediaType.1.10.0.0.51 =  "static" ))
  912.  
  913.    The SNMPv2 entity acting in a manager role continues with:
  914.  
  915.        GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
  916.                        ( sysUpTime,
  917.                          ipNetToMediaPhysAddress.1.10.0.0.51,
  918.                          ipNetToMediaType.1.10.0.0.51 )
  919.  
  920.    The SNMPv2 entity acting in an agent role responds with:
  921.  
  922.     Response (( sysUpTime.0 =  "123466" ),
  923.               ( ipNetToMediaPhysAddress.2.10.0.0.15 =
  924.                                          "000010987654" ),
  925.               ( ipNetToMediaType.2.10.0.0.15 =
  926.                                               "dynamic" ),
  927.               ( ipNetToMediaNetAddress.1.9.2.3.4 =
  928.                                               "9.2.3.4" ),
  929.               ( ipRoutingDiscards.0 =  "2" ))
  930.  
  931.    This response signals the end of the table to the SNMPv2 entity
  932.    acting in a manager role.
  933.  
  934. 4.2.4.  The Response-PDU
  935.  
  936.    The Response-PDU is generated by a SNMPv2 entity only upon receipt of
  937.    a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU,
  938.    SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this
  939.    document.
  940.  
  941.    If the error-status field of the Response-PDU is non-zero, the value
  942.    fields of the variable bindings in the variable binding list are
  943.    ignored.
  944.  
  945.    If both the error-status field and the error-index field of the
  946.    Response-PDU are non-zero, then the value of the error-index field is
  947.    the index of the variable binding (in the variable-binding list of
  948.    the corresponding request) for which the request failed.  The first
  949.    variable binding in a request's variable-binding list is index one,
  950.    the second is index two, etc.
  951.  
  952.  
  953.  
  954. SNMPv2 Working Group        Standards Track                    [Page 17]
  955.  
  956. RFC 1905             Protocol Operations for SNMPv2         January 1996
  957.  
  958.  
  959.    A compliant SNMPv2 entity acting in a manager role must be able to
  960.    properly receive and handle a Response-PDU with an error-status field
  961.    equal to `noSuchName', `badValue', or `readOnly'.  (See Section 3.1.2
  962.    of [8].)
  963.  
  964.    Upon receipt of a Response-PDU, the receiving SNMPv2 entity presents
  965.    its contents to the SNMPv2 application which generated the request
  966.    with the same request-id value.
  967.  
  968. 4.2.5.  The SetRequest-PDU
  969.  
  970.    A SetRequest-PDU is generated and transmitted at the request of a
  971.    SNMPv2 application.
  972.  
  973.    Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity
  974.    determines the size of a message encapsulating a Response-PDU having
  975.    the same values in its request-id and variable-bindings fields as the
  976.    received SetRequest-PDU, and the largest possible sizes of the
  977.    error-status and error-index fields.  If the determined message size
  978.    is greater than either a local constraint or the maximum message size
  979.    of the originator, then an alternate Response-PDU is generated,
  980.    transmitted to the originator of the SetRequest-PDU, and processing
  981.    of the SetRequest-PDU terminates immediately thereafter.  This
  982.    alternate Response-PDU is formatted with the same values in its
  983.    request-id field as the received SetRequest-PDU, with the value of
  984.    its error-status field set to `tooBig', the value of its error-index
  985.    field set to zero, and an empty variable-bindings field.  This
  986.    alternate Response-PDU is then encapsulated into a message.  If the
  987.    size of the resultant message is less than or equal to both a local
  988.    constraint and the maximum message size of the originator, it is
  989.    transmitted to the originator of the SetRequest-PDU.  Otherwise, the
  990.    snmpSilentDrops [9] counter is incremented and the resultant message
  991.    is discarded.  Regardless, processing of the SetRequest-PDU
  992.    terminates.
  993.  
  994.    Otherwise, the receiving SNMPv2 entity processes each variable
  995.    binding in the variable-binding list to produce a Response-PDU.  All
  996.    fields of the Response-PDU have the same values as the corresponding
  997.    fields of the received request except as indicated below.
  998.  
  999.    The variable bindings are conceptually processed as a two phase
  1000.    operation.  In the first phase, each variable binding is validated;
  1001.    if all validations are successful, then each variable is altered in
  1002.    the second phase.  Of course, implementors are at liberty to
  1003.    implement either the first, or second, or both, of these conceptual
  1004.    phases as multiple implementation phases.  Indeed, such multiple
  1005.    implementation phases may be necessary in some cases to ensure
  1006.    consistency.
  1007.  
  1008.  
  1009.  
  1010. SNMPv2 Working Group        Standards Track                    [Page 18]
  1011.  
  1012. RFC 1905             Protocol Operations for SNMPv2         January 1996
  1013.  
  1014.  
  1015.    The following validations are performed in the first phase on each
  1016.    variable binding until they are all successful, or until one fails:
  1017.  
  1018. (1)  If the variable binding's name specifies an existing or non-
  1019.      existent variable to which this request is/would be denied access
  1020.      because it is/would not be in the appropriate MIB view, then the
  1021.      value of the Response-PDU's error-status field is set to
  1022.      `noAccess', and the value of its error-index field is set to the
  1023.      index of the failed variable binding.
  1024.  
  1025. (2)  Otherwise, if there are no variables which share the same OBJECT
  1026.      IDENTIFIER prefix as the variable binding's name, and which are
  1027.      able to be created or modified no matter what new value is
  1028.      specified, then the value of the Response-PDU's error-status field
  1029.      is set to `notWritable', and the value of its error-index field is
  1030.      set to the index of the failed variable binding.
  1031.  
  1032. (3)  Otherwise, if the variable binding's value field specifies,
  1033.      according to the ASN.1 language, a type which is inconsistent with
  1034.      that required for all variables which share the same OBJECT
  1035.      IDENTIFIER prefix as the variable binding's name, then the value of
  1036.      the Response-PDU's error-status field is set to `wrongType', and
  1037.      the value of its error-index field is set to the index of the
  1038.      failed variable binding.
  1039.  
  1040. (4)  Otherwise, if the variable binding's value field specifies,
  1041.      according to the ASN.1 language, a length which is inconsistent
  1042.      with that required for all variables which share the same OBJECT
  1043.      IDENTIFIER prefix as the variable binding's name, then the value of
  1044.      the Response-PDU's error-status field is set to `wrongLength', and
  1045.      the value of its error-index field is set to the index of the
  1046.      failed variable binding.
  1047.  
  1048. (5)  Otherwise, if the variable binding's value field contains an ASN.1
  1049.      encoding which is inconsistent with that field's ASN.1 tag, then
  1050.      the value of the Response-PDU's error-status field is set to
  1051.      `wrongEncoding', and the value of its error-index field is set to
  1052.      the index of the failed variable binding.  (Note that not all
  1053.      implementation strategies will generate this error.)
  1054.  
  1055. (6)  Otherwise, if the variable binding's value field specifies a value
  1056.      which could under no circumstances be assigned to the variable,
  1057.      then the value of the Response-PDU's error-status field is set to
  1058.      `wrongValue', and the value of its error-index field is set to the
  1059.      index of the failed variable binding.
  1060.  
  1061. (7)  Otherwise, if the variable binding's name specifies a variable
  1062.      which does not exist and could not ever be created (even though
  1063.  
  1064.  
  1065.  
  1066. SNMPv2 Working Group        Standards Track                    [Page 19]
  1067.  
  1068. RFC 1905             Protocol Operations for SNMPv2         January 1996
  1069.  
  1070.  
  1071.      some variables sharing the same OBJECT IDENTIFIER prefix might
  1072.      under some circumstances be able to be created), then the value of
  1073.      the Response-PDU's error-status field is set to `noCreation', and
  1074.      the value of its error-index field is set to the index of the
  1075.      failed variable binding.
  1076.  
  1077. (8)  Otherwise, if the variable binding's name specifies a variable
  1078.      which does not exist but can not be created under the present
  1079.      circumstances (even though it could be created under other
  1080.      circumstances), then the value of the Response-PDU's error-status
  1081.      field is set to `inconsistentName', and the value of its error-
  1082.      index field is set to the index of the failed variable binding.
  1083.  
  1084. (9)  Otherwise, if the variable binding's name specifies a variable
  1085.      which exists but can not be modified no matter what new value is
  1086.      specified, then the value of the Response-PDU's error-status field
  1087.      is set to `notWritable', and the value of its error-index field is
  1088.      set to the index of the failed variable binding.
  1089.  
  1090. (10) Otherwise, if the variable binding's value field specifies a value
  1091.      that could under other circumstances be held by the variable, but
  1092.      is presently inconsistent or otherwise unable to be assigned to the
  1093.      variable, then the value of the Response-PDU's error-status field
  1094.      is set to `inconsistentValue', and the value of its error-index
  1095.      field is set to the index of the failed variable binding.
  1096.  
  1097. (11) When, during the above steps, the assignment of the value specified
  1098.      by the variable binding's value field to the specified variable
  1099.      requires the allocation of a resource which is presently
  1100.      unavailable, then the value of the Response-PDU's error-status
  1101.      field is set to `resourceUnavailable', and the value of its error-
  1102.      index field is set to the index of the failed variable binding.
  1103.  
  1104. (12) If the processing of the variable binding fails for a reason other
  1105.      than listed above, then the value of the Response-PDU's error-
  1106.      status field is set to `genErr', and the value of its error-index
  1107.      field is set to the index of the failed variable binding.
  1108.  
  1109. (13) Otherwise, the validation of the variable binding succeeds.
  1110.  
  1111.    At the end of the first phase, if the validation of all variable
  1112.    bindings succeeded, then the value of the Response-PDU's error-status
  1113.    field is set to `noError' and the value of its error-index field is
  1114.    zero, and processing continues as follows.
  1115.  
  1116.    For each variable binding in the request, the named variable is
  1117.    created if necessary, and the specified value is assigned to it.
  1118.    Each of these variable assignments occurs as if simultaneously with
  1119.  
  1120.  
  1121.  
  1122. SNMPv2 Working Group        Standards Track                    [Page 20]
  1123.  
  1124. RFC 1905             Protocol Operations for SNMPv2         January 1996
  1125.  
  1126.  
  1127.    respect to all other assignments specified in the same request.
  1128.    However, if the same variable is named more than once in a single
  1129.    request, with different associated values, then the actual assignment
  1130.    made to that variable is implementation-specific.
  1131.  
  1132.    If any of these assignments fail (even after all the previous
  1133.    validations), then all other assignments are undone, and the
  1134.    Response-PDU is modified to have the value of its error-status field
  1135.    set to `commitFailed', and the value of its error-index field set to
  1136.    the index of the failed variable binding.
  1137.  
  1138.    If and only if it is not possible to undo all the assignments, then
  1139.    the Response-PDU is modified to have the value of its error-status
  1140.    field set to `undoFailed', and the value of its error-index field is
  1141.    set to zero.  Note that implementations are strongly encouraged to
  1142.    take all possible measures to avoid use of either `commitFailed' or
  1143.    `undoFailed' - these two error-status codes are not to be taken as
  1144.    license to take the easy way out in an implementation.
  1145.  
  1146.    Finally, the generated Response-PDU is encapsulated into a message,
  1147.    and transmitted to the originator of the SetRequest-PDU.
  1148.  
  1149. 4.2.6.  The SNMPv2-Trap-PDU
  1150.  
  1151.    A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2 entity
  1152.    acting in an agent role when an exceptional situation occurs.
  1153.  
  1154.    The destination(s) to which a SNMPv2-Trap-PDU is sent is determined
  1155.    in an implementation-dependent fashion by the SNMPv2 entity.  The
  1156.    first two variable bindings in the variable binding list of an
  1157.    SNMPv2-Trap-PDU are sysUpTime.0 [9] and snmpTrapOID.0 [9]
  1158.    respectively.  If the OBJECTS clause is present in the invocation of
  1159.    the corresponding NOTIFICATION-TYPE macro, then each corresponding
  1160.    variable, as instantiated by this notification, is copied, in order,
  1161.    to the variable-bindings field.  If any additional variables are
  1162.    being included (at the option of the generating SNMPv2 entity), then
  1163.    each is copied to the variable-bindings field.
  1164.  
  1165. 4.2.7.  The InformRequest-PDU
  1166.  
  1167.    An InformRequest-PDU is generated and transmitted at the request of
  1168.    an application in a SNMPv2 entity acting in a manager role, that
  1169.    wishes to notify another application (in a SNMPv2 entity also acting
  1170.    in a manager role) of information in a MIB view which is remote to
  1171.    the receiving application.
  1172.  
  1173.    The destination(s) to which an InformRequest-PDU is sent is specified
  1174.    by the requesting application.  The first two variable bindings in
  1175.  
  1176.  
  1177.  
  1178. SNMPv2 Working Group        Standards Track                    [Page 21]
  1179.  
  1180. RFC 1905             Protocol Operations for SNMPv2         January 1996
  1181.  
  1182.  
  1183.    the variable binding list of an InformRequest-PDU are sysUpTime.0 [9]
  1184.    and snmpTrapOID.0 [9] respectively.  If the OBJECTS clause is present
  1185.    in the invocation of the corresponding NOTIFICATION-TYPE macro, then
  1186.    each corresponding variable, as instantiated by this notification, is
  1187.    copied, in order, to the variable-bindings field.
  1188.  
  1189.    Upon receipt of an InformRequest-PDU, the receiving SNMPv2 entity
  1190.    determines the size of a message encapsulating a Response-PDU with
  1191.    the same values in its request-id, error-status, error-index and
  1192.    variable-bindings fields as the received InformRequest-PDU.  If the
  1193.    determined message size is greater than either a local constraint or
  1194.    the maximum message size of the originator, then an alternate
  1195.    Response-PDU is generated, transmitted to the originator of the
  1196.    InformRequest-PDU, and processing of the InformRequest-PDU terminates
  1197.    immediately thereafter.  This alternate Response-PDU is formatted
  1198.    with the same values in its request-id field as the received
  1199.    InformRequest-PDU, with the value of its error-status field set to
  1200.    `tooBig', the value of its error-index field set to zero, and an
  1201.    empty variable-bindings field.  This alternate Response-PDU is then
  1202.    encapsulated into a message.  If the size of the resultant message is
  1203.    less than or equal to both a local constraint and the maximum message
  1204.    size of the originator, it is transmitted to the originator of the
  1205.    InformRequest-PDU.  Otherwise, the snmpSilentDrops [9] counter is
  1206.    incremented and the resultant message is discarded.  Regardless,
  1207.    processing of the InformRequest-PDU terminates.
  1208.  
  1209.    Otherwise, the receiving SNMPv2 entity:
  1210.  
  1211. (1)  presents its contents to the appropriate SNMPv2 application;
  1212.  
  1213. (2)  generates a Response-PDU with the same values in its request-id and
  1214.      variable-bindings fields as the received InformRequest-PDU, with
  1215.      the value of its error-status field is set to `noError' and the
  1216.      value of its error-index field is zero; and
  1217.  
  1218. (3)  transmits the generated Response-PDU to the originator of the
  1219.      InformRequest-PDU.
  1220.  
  1221. 5.  Security Considerations
  1222.  
  1223.    Security issues are not discussed in this memo.
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. SNMPv2 Working Group        Standards Track                    [Page 22]
  1235.  
  1236. RFC 1905             Protocol Operations for SNMPv2         January 1996
  1237.  
  1238.  
  1239. 6.  Editor's Address
  1240.  
  1241.    Keith McCloghrie
  1242.    Cisco Systems, Inc.
  1243.    170 West Tasman Drive
  1244.    San Jose, CA  95134-1706
  1245.    US
  1246.  
  1247.    Phone: +1 408 526 5260
  1248.    EMail: kzm@cisco.com
  1249.  
  1250. 7.  Acknowledgements
  1251.  
  1252.    This document is the result of significant work by the four major
  1253.    contributors:
  1254.  
  1255.    Jeffrey D. Case (SNMP Research, case@snmp.com)
  1256.    Keith McCloghrie (Cisco Systems, kzm@cisco.com)
  1257.    Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
  1258.    Steven Waldbusser (International Network Services, stevew@uni.ins.com)
  1259.  
  1260.    In addition, the contributions of the SNMPv2 Working Group are
  1261.    acknowledged.  In particular, a special thanks is extended for the
  1262.    contributions of:
  1263.  
  1264.      Alexander I. Alten (Novell)
  1265.      Dave Arneson (Cabletron)
  1266.      Uri Blumenthal (IBM)
  1267.      Doug Book (Chipcom)
  1268.      Kim Curran (Bell-Northern Research)
  1269.      Jim Galvin (Trusted Information Systems)
  1270.      Maria Greene (Ascom Timeplex)
  1271.      Iain Hanson (Digital)
  1272.      Dave Harrington (Cabletron)
  1273.      Nguyen Hien (IBM)
  1274.      Jeff Johnson (Cisco Systems)
  1275.      Michael Kornegay (Object Quest)
  1276.      Deirdre Kostick (AT&T Bell Labs)
  1277.      David Levi (SNMP Research)
  1278.      Daniel Mahoney (Cabletron)
  1279.      Bob Natale (ACE*COMM)
  1280.      Brian O'Keefe (Hewlett Packard)
  1281.      Andrew Pearson (SNMP Research)
  1282.      Dave Perkins (Peer Networks)
  1283.      Randy Presuhn (Peer Networks)
  1284.      Aleksey Romanov (Quality Quorum)
  1285.      Shawn Routhier (Epilogue)
  1286.      Jon Saperia (BGS Systems)
  1287.  
  1288.  
  1289.  
  1290. SNMPv2 Working Group        Standards Track                    [Page 23]
  1291.  
  1292. RFC 1905             Protocol Operations for SNMPv2         January 1996
  1293.  
  1294.  
  1295.      Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
  1296.      Kaj Tesink (Bellcore)
  1297.      Glenn Waters (Bell-Northern Research)
  1298.      Bert Wijnen (IBM)
  1299.  
  1300. 8.  References
  1301.  
  1302. [1]  Information processing systems - Open Systems Interconnection -
  1303.      Specification of Abstract Syntax Notation One (ASN.1),
  1304.      International Organization for Standardization.  International
  1305.      Standard 8824, (December, 1987).
  1306.  
  1307. [2]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1308.      S. Waldbusser, "Structure of Management Information for Version 2
  1309.      of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
  1310.      January 1996.
  1311.  
  1312. [3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1313.      S. Waldbusser, "Textual Conventions for Version 2 of the Simple
  1314.      Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
  1315.  
  1316. [4]  Kent, C., and J. Mogul, Fragmentation Considered Harmful,
  1317.      Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987).
  1318.  
  1319. [5]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1320.      S. Waldbusser, "Transport Mappings for Version 2 of the Simple
  1321.      Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
  1322.  
  1323. [6]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
  1324.      USC/Information Sciences Institute, August 1980.
  1325.  
  1326. [7]  McCloghrie, K., and M. Rose, Editors, "Management Information
  1327.      Base for Network Management of TCP/IP-based internets:
  1328.      MIB-II", STD 17, RFC 1213, March 1991.
  1329.  
  1330. [8]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1331.      S. Waldbusser, "Coexistence between Version 1 and Version 2
  1332.      of the Internet-standard Network Management Framework", RFC 1908,
  1333.      January 1996.
  1334.  
  1335. [9]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  1336.      S. Waldbusser, "Management Information Base for Version 2 of the
  1337.      Simple Network Management Protocol (SNMPv2)", RFC 1907,
  1338.      January 1996.
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. SNMPv2 Working Group        Standards Track                    [Page 24]
  1347.  
  1348.