home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1906 < prev    next >
Text File  |  1996-01-22  |  27KB  |  732 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                               SNMPv2 Working Group
  8. Request for Comments: 1906                                       J. Case
  9. Obsoletes: 1449                                      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.                 Transport Mappings for Version 2 of the
  20.               Simple Network Management Protocol (SNMPv2)
  21.  
  22. Status of this Memo
  23.  
  24.    This document specifies an Internet standards track protocol for the
  25.    Internet community, and requests discussion and suggestions for
  26.    improvements.  Please refer to the current edition of the "Internet
  27.    Official Protocol Standards" (STD 1) for the standardization state
  28.    and status of this protocol.  Distribution of this memo is unlimited.
  29.  
  30. Table of Contents
  31.  
  32.    1. Introduction ................................................    2
  33.    1.1 A Note on Terminology ......................................    2
  34.    2. Definitions .................................................    3
  35.    3. SNMPv2 over UDP .............................................    5
  36.    3.1 Serialization ..............................................    5
  37.    3.2 Well-known Values ..........................................    5
  38.    4. SNMPv2 over OSI .............................................    6
  39.    4.1 Serialization ..............................................    6
  40.    4.2 Well-known Values ..........................................    6
  41.    5. SNMPv2 over DDP .............................................    6
  42.    5.1 Serialization ..............................................    6
  43.    5.2 Well-known Values ..........................................    6
  44.    5.3 Discussion of AppleTalk Addressing .........................    7
  45.    5.3.1 How to Acquire NBP names .................................    8
  46.    5.3.2 When to Turn NBP names into DDP addresses ................    8
  47.    5.3.3 How to Turn NBP names into DDP addresses .................    8
  48.    5.3.4 What if NBP is broken ....................................    9
  49.    6. SNMPv2 over IPX .............................................    9
  50.    6.1 Serialization ..............................................    9
  51.    6.2 Well-known Values ..........................................    9
  52.    7. Proxy to SNMPv1 .............................................   10
  53.    8. Serialization using the Basic Encoding Rules ................   10
  54.    8.1 Usage Example ..............................................   11
  55.  
  56.  
  57.  
  58. SNMPv2 Working Group        Standards Track                     [Page 1]
  59.  
  60. RFC 1906             Transport Mappings for SNMPv2          January 1996
  61.  
  62.  
  63.    9. Security Considerations .....................................   11
  64.    10. Editor's Address ...........................................   12
  65.    11. Acknowledgements ...........................................   12
  66.    12. References .................................................   13
  67.  
  68. 1.  Introduction
  69.  
  70.    A management system contains:  several (potentially many) nodes, each
  71.    with a processing entity, termed an agent, which has access to
  72.    management instrumentation; at least one management station; and, a
  73.    management protocol, used to convey management information between
  74.    the agents and management stations.  Operations of the protocol are
  75.    carried out under an administrative framework which defines
  76.    authentication, authorization, access control, and privacy policies.
  77.  
  78.    Management stations execute management applications which monitor and
  79.    control managed elements.  Managed elements are devices such as
  80.    hosts, routers, terminal servers, etc., which are monitored and
  81.    controlled via access to their management information.
  82.  
  83.    The management protocol, version 2 of the Simple Network Management
  84.    Protocol [1], may be used over a variety of protocol suites.  It is
  85.    the purpose of this document to define how the SNMPv2 maps onto an
  86.    initial set of transport domains.  Other mappings may be defined in
  87.    the future.
  88.  
  89.    Although several mappings are defined, the mapping onto UDP is the
  90.    preferred mapping.  As such, to provide for the greatest level of
  91.    interoperability, systems which choose to deploy other mappings
  92.    should also provide for proxy service to the UDP mapping.
  93.  
  94. 1.1.  A Note on Terminology
  95.  
  96.    For the purpose of exposition, the original Internet-standard Network
  97.    Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD
  98.    15), and 1212 (STD 16), is termed the SNMP version 1 framework
  99.    (SNMPv1).  The current framework is termed the SNMP version 2
  100.    framework (SNMPv2).
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. SNMPv2 Working Group        Standards Track                     [Page 2]
  115.  
  116. RFC 1906             Transport Mappings for SNMPv2          January 1996
  117.  
  118.  
  119. 2.  Definitions
  120.  
  121. SNMPv2-TM DEFINITIONS ::= BEGIN
  122.  
  123. IMPORTS
  124.     OBJECT-IDENTITY, snmpDomains, snmpProxys
  125.         FROM SNMPv2-SMI
  126.     TEXTUAL-CONVENTION
  127.         FROM SNMPv2-TC;
  128.  
  129. -- SNMPv2 over UDP over IPv4
  130.  
  131. snmpUDPDomain  OBJECT-IDENTITY
  132.     STATUS     current
  133.     DESCRIPTION
  134.             "The SNMPv2 over UDP transport domain.  The corresponding
  135.             transport address is of type SnmpUDPAddress."
  136.     ::= { snmpDomains 1 }
  137.  
  138. SnmpUDPAddress ::= TEXTUAL-CONVENTION
  139.     DISPLAY-HINT "1d.1d.1d.1d/2d"
  140.     STATUS       current
  141.     DESCRIPTION
  142.             "Represents a UDP address:
  143.  
  144.                octets   contents        encoding
  145.                 1-4     IP-address      network-byte order
  146.                 5-6     UDP-port        network-byte order
  147.             "
  148.     SYNTAX       OCTET STRING (SIZE (6))
  149.  
  150.  
  151. -- SNMPv2 over OSI
  152.  
  153. snmpCLNSDomain OBJECT-IDENTITY
  154.     STATUS     current
  155.     DESCRIPTION
  156.             "The SNMPv2 over CLNS transport domain.  The corresponding
  157.             transport address is of type SnmpOSIAddress."
  158.     ::= { snmpDomains 2 }
  159.  
  160. snmpCONSDomain OBJECT-IDENTITY
  161.     STATUS     current
  162.     DESCRIPTION
  163.             "The SNMPv2 over CONS transport domain.  The corresponding
  164.             transport address is of type SnmpOSIAddress."
  165.     ::= { snmpDomains 3 }
  166.  
  167.  
  168.  
  169.  
  170. SNMPv2 Working Group        Standards Track                     [Page 3]
  171.  
  172. RFC 1906             Transport Mappings for SNMPv2          January 1996
  173.  
  174.  
  175. SnmpOSIAddress ::= TEXTUAL-CONVENTION
  176.     DISPLAY-HINT "*1x:/1x:"
  177.     STATUS       current
  178.     DESCRIPTION
  179.             "Represents an OSI transport-address:
  180.  
  181.                octets   contents           encoding
  182.                   1     length of NSAP     'n' as an unsigned-integer
  183.                                               (either 0 or from 3 to 20)
  184.                2..(n+1) NSAP                concrete binary representation
  185.                (n+2)..m TSEL                string of (up to 64) octets
  186.             "
  187.     SYNTAX       OCTET STRING (SIZE (1 | 4..85))
  188.  
  189.  
  190. -- SNMPv2 over DDP
  191.  
  192. snmpDDPDomain  OBJECT-IDENTITY
  193.     STATUS     current
  194.     DESCRIPTION
  195.             "The SNMPv2 over DDP transport domain.  The corresponding
  196.             transport address is of type SnmpNBPAddress."
  197.     ::= { snmpDomains 4 }
  198.  
  199. SnmpNBPAddress ::= TEXTUAL-CONVENTION
  200.     STATUS       current
  201.     DESCRIPTION
  202.             "Represents an NBP name:
  203.  
  204.                  octets        contents          encoding
  205.                     1          length of object  'n' as an unsigned integer
  206.                   2..(n+1)     object            string of (up to 32) octets
  207.                    n+2         length of type    'p' as an unsigned integer
  208.               (n+3)..(n+2+p)   type              string of (up to 32) octets
  209.                   n+3+p        length of zone    'q' as an unsigned integer
  210.             (n+4+p)..(n+3+p+q) zone              string of (up to 32) octets
  211.  
  212.             For comparison purposes, strings are case-insensitive All
  213.             strings may contain any octet other than 255 (hex ff)."
  214.     SYNTAX       OCTET STRING (SIZE (3..99))
  215.  
  216.  
  217. -- SNMPv2 over IPX
  218.  
  219. snmpIPXDomain  OBJECT-IDENTITY
  220.     STATUS     current
  221.     DESCRIPTION
  222.             "The SNMPv2 over IPX transport domain.  The corresponding
  223.  
  224.  
  225.  
  226. SNMPv2 Working Group        Standards Track                     [Page 4]
  227.  
  228. RFC 1906             Transport Mappings for SNMPv2          January 1996
  229.  
  230.  
  231.             transport address is of type SnmpIPXAddress."
  232.     ::= { snmpDomains 5 }
  233.  
  234. SnmpIPXAddress ::= TEXTUAL-CONVENTION
  235.     DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
  236.     STATUS       current
  237.     DESCRIPTION
  238.             "Represents an IPX address:
  239.  
  240.                octets   contents            encoding
  241.                 1-4     network-number      network-byte order
  242.                 5-10    physical-address    network-byte order
  243.                11-12    socket-number       network-byte order
  244.             "
  245.     SYNTAX       OCTET STRING (SIZE (12))
  246.  
  247.  
  248. -- for proxy to SNMPv1 (RFC 1157)
  249.  
  250. rfc1157Proxy   OBJECT IDENTIFIER ::= { snmpProxys 1 }
  251.  
  252. rfc1157Domain  OBJECT-IDENTITY
  253.     STATUS     current
  254.     DESCRIPTION
  255.             "The transport domain for SNMPv1 over UDP.  The
  256.             corresponding transport address is of type SnmpUDPAddress."
  257.     ::= { rfc1157Proxy 1 }
  258.  
  259. --  ::= { rfc1157Proxy 2 }            this OID is obsolete
  260.  
  261.  
  262. END
  263.  
  264. 3.  SNMPv2 over UDP
  265.  
  266.    This is the preferred transport mapping.
  267.  
  268. 3.1.  Serialization
  269.  
  270.    Each instance of a message is serialized (i.e., encoded according to
  271.    the convention of [1]) onto a single UDP[2] datagram, using the
  272.    algorithm specified in Section 8.
  273.  
  274. 3.2.  Well-known Values
  275.  
  276.    It is suggested that administrators configure their SNMPv2 entities
  277.    acting in an agent role to listen on UDP port 161.  Further, it is
  278.    suggested that notification sinks be configured to listen on UDP port
  279.  
  280.  
  281.  
  282. SNMPv2 Working Group        Standards Track                     [Page 5]
  283.  
  284. RFC 1906             Transport Mappings for SNMPv2          January 1996
  285.  
  286.  
  287.    162.
  288.  
  289.    When an SNMPv2 entity uses this transport mapping, it must be capable
  290.    of accepting messages that are at least 484 octets in size.
  291.    Implementation of larger values is encouraged whenever possible.
  292.  
  293. 4.  SNMPv2 over OSI
  294.  
  295.    This is an optional transport mapping.
  296.  
  297. 4.1.  Serialization
  298.  
  299.    Each instance of a message is serialized onto a single TSDU [3,4] for
  300.    the OSI Connectionless-mode Transport Service (CLTS), using the
  301.    algorithm specified in Section 8.
  302.  
  303. 4.2.  Well-known Values
  304.  
  305.    It is suggested that administrators configure their SNMPv2 entities
  306.    acting in an agent role to listen on transport selector "snmp-l"
  307.    (which consists of six ASCII characters), when using a CL-mode
  308.    network service to realize the CLTS.  Further, it is suggested that
  309.    notification sinks be configured to listen on transport selector
  310.    "snmpt-l" (which consists of seven ASCII characters, six letters and
  311.    a hyphen) when using a CL-mode network service to realize the CLTS.
  312.    Similarly, when using a CO-mode network service to realize the CLTS,
  313.    the suggested transport selectors are "snmp-o" and "snmpt-o", for
  314.    agent and notification sink, respectively.
  315.  
  316.    When an SNMPv2 entity uses this transport mapping, it must be capable
  317.    of accepting messages that are at least 484 octets in size.
  318.    Implementation of larger values is encouraged whenever possible.
  319.  
  320. 5.  SNMPv2 over DDP
  321.  
  322.    This is an optional transport mapping.
  323.  
  324. 5.1.  Serialization
  325.  
  326.    Each instance of a message is serialized onto a single DDP datagram
  327.    [5], using the algorithm specified in Section 8.
  328.  
  329. 5.2.  Well-known Values
  330.  
  331.    SNMPv2 messages are sent using DDP protocol type 8.  SNMPv2 entities
  332.    acting in an agent role listens on DDP socket number 8, whilst
  333.    notification sinks listen on DDP socket number 9.
  334.  
  335.  
  336.  
  337.  
  338. SNMPv2 Working Group        Standards Track                     [Page 6]
  339.  
  340. RFC 1906             Transport Mappings for SNMPv2          January 1996
  341.  
  342.  
  343.    Administrators must configure their SNMPv2 entities acting in an
  344.    agent role to use NBP type "SNMP Agent" (which consists of ten ASCII
  345.    characters), whilst notification sinks must be configured to use NBP
  346.    type "SNMP Trap Handler" (which consists of seventeen ASCII
  347.    characters).
  348.  
  349.    The NBP name for agents and notification sinks should be stable - NBP
  350.    names should not change any more often than the IP address of a
  351.    typical TCP/IP node.  It is suggested that the NBP name be stored in
  352.    some form of stable storage.
  353.  
  354.    When an SNMPv2 entity uses this transport mapping, it must be capable
  355.    of accepting messages that are at least 484 octets in size.
  356.    Implementation of larger values is encouraged whenever possible.
  357.  
  358. 5.3.  Discussion of AppleTalk Addressing
  359.  
  360.    The AppleTalk protocol suite has certain features not manifest in the
  361.    TCP/IP suite.  AppleTalk's naming strategy and the dynamic nature of
  362.    address assignment can cause problems for SNMPv2 entities that wish
  363.    to manage AppleTalk networks.  TCP/IP nodes have an associated IP
  364.    address which distinguishes each from the other.  In contrast,
  365.    AppleTalk nodes generally have no such characteristic.  The network-
  366.    level address, while often relatively stable, can change at every
  367.    reboot (or more frequently).
  368.  
  369.    Thus, when SNMPv2 is mapped over DDP, nodes are identified by a
  370.    "name", rather than by an "address".  Hence, all AppleTalk nodes that
  371.    implement this mapping are required to respond to NBP lookups and
  372.    confirms (e.g., implement the NBP protocol stub), which guarantees
  373.    that a mapping from NBP name to DDP address will be possible.
  374.  
  375.    In determining the SNMP identity to register for an SNMPv2 entity, it
  376.    is suggested that the SNMP identity be a name which is associated
  377.    with other network services offered by the machine.
  378.  
  379.    NBP lookups, which are used to map NBP names into DDP addresses, can
  380.    cause large amounts of network traffic as well as consume CPU
  381.    resources.  It is also the case that the ability to perform an NBP
  382.    lookup is sensitive to certain network disruptions (such as zone
  383.    table inconsistencies) which would not prevent direct AppleTalk
  384.    communications between two SNMPv2 entities.
  385.  
  386.    Thus, it is recommended that NBP lookups be used infrequently,
  387.    primarily to create a cache of name-to-address mappings.  These
  388.    cached mappings should then be used for any further SNMP traffic.  It
  389.    is recommended that SNMPv2 entities acting in a manager role should
  390.    maintain this cache between reboots.  This caching can help minimize
  391.  
  392.  
  393.  
  394. SNMPv2 Working Group        Standards Track                     [Page 7]
  395.  
  396. RFC 1906             Transport Mappings for SNMPv2          January 1996
  397.  
  398.  
  399.    network traffic, reduce CPU load on the network, and allow for (some
  400.    amount of) network trouble shooting when the basic name-to-address
  401.    translation mechanism is broken.
  402.  
  403. 5.3.1.  How to Acquire NBP names
  404.  
  405.    An SNMPv2 entity acting in a manager role may have a pre-configured
  406.    list of names of "known" SNMPv2 entities acting in an agent role.
  407.    Similarly, an SNMPv2 entity acting in a manager role might interact
  408.    with an operator.  Finally, an SNMPv2 entity acting in a manager role
  409.    might communicate with all SNMPv2 entities acting in an agent role in
  410.    a set of zones or networks.
  411.  
  412. 5.3.2.  When to Turn NBP names into DDP addresses
  413.  
  414.    When an SNMPv2 entity uses a cache entry to address an SNMP packet,
  415.    it should attempt to confirm the validity mapping, if the mapping
  416.    hasn't been confirmed within the last T1 seconds.  This cache entry
  417.    lifetime, T1, has a minimum, default value of 60 seconds, and should
  418.    be configurable.
  419.  
  420.    An SNMPv2 entity acting in a manager role may decide to prime its
  421.    cache of names prior to actually communicating with another SNMPv2
  422.    entity.  In general, it is expected that such an entity may want to
  423.    keep certain mappings "more current" than other mappings, e.g., those
  424.    nodes which represent the network infrastructure (e.g., routers) may
  425.    be deemed "more important".
  426.  
  427.    Note that an SNMPv2 entity acting in a manager role should not prime
  428.    its entire cache upon initialization - rather, it should attempt
  429.    resolutions over an extended period of time (perhaps in some pre-
  430.    determined or configured priority order).  Each of these resolutions
  431.    might, in fact, be a wildcard lookup in a given zone.
  432.  
  433.    An SNMPv2 entity acting in an agent role must never prime its cache.
  434.    Such an entity should do NBP lookups (or confirms) only when it needs
  435.    to send an SNMP trap.  When generating a response, such an entity
  436.    does not need to confirm a cache entry.
  437.  
  438. 5.3.3.  How to Turn NBP names into DDP addresses
  439.  
  440.    If the only piece of information available is the NBP name, then an
  441.    NBP lookup should be performed to turn that name into a DDP address.
  442.    However, if there is a piece of stale information, it can be used as
  443.    a hint to perform an NBP confirm (which sends a unicast to the
  444.    network address which is presumed to be the target of the name
  445.    lookup) to see if the stale information is, in fact, still valid.
  446.  
  447.  
  448.  
  449.  
  450. SNMPv2 Working Group        Standards Track                     [Page 8]
  451.  
  452. RFC 1906             Transport Mappings for SNMPv2          January 1996
  453.  
  454.  
  455.    An NBP name to DDP address mapping can also be confirmed implicitly
  456.    using only SNMP transactions.  For example, an SNMPv2 entity acting
  457.    in a manager role issuing a retrieval operation could also retrieve
  458.    the relevant objects from the NBP group [6] for the SNMPv2 entity
  459.    acting in an agent role.  This information can then be correlated
  460.    with the source DDP address of the response.
  461.  
  462. 5.3.4.  What if NBP is broken
  463.  
  464.    Under some circumstances, there may be connectivity between two
  465.    SNMPv2 entities, but the NBP mapping machinery may be broken, e.g.,
  466.  
  467. o    the NBP FwdReq (forward NBP lookup onto local attached network)
  468.      mechanism might be broken at a router on the other entity's
  469.      network; or,
  470.  
  471. o    the NBP BrRq (NBP broadcast request) mechanism might be broken
  472.      at a router on the entity's own network; or,
  473.  
  474. o    NBP might be broken on the other entity's node.
  475.  
  476.    An SNMPv2 entity acting in a manager role which is dedicated to
  477.    AppleTalk management might choose to alleviate some of these failures
  478.    by directly implementing the router portion of NBP.  For example,
  479.    such an entity might already know all the zones on the AppleTalk
  480.    internet and the networks on which each zone appears.  Given an NBP
  481.    lookup which fails, the entity could send an NBP FwdReq to the
  482.    network in which the agent was last located.  If that failed, the
  483.    station could then send an NBP LkUp (NBP lookup packet) as a directed
  484.    (DDP) multicast to each network number on that network.  Of the above
  485.    (single) failures, this combined approach will solve the case where
  486.    either the local router's BrRq-to-FwdReq mechanism is broken or the
  487.    remote router's FwdReq-to-LkUp mechanism is broken.
  488.  
  489. 6.  SNMPv2 over IPX
  490.  
  491.    This is an optional transport mapping.
  492.  
  493. 6.1.  Serialization
  494.  
  495.    Each instance of a message is serialized onto a single IPX datagram
  496.    [7], using the algorithm specified in Section 8.
  497.  
  498. 6.2.  Well-known Values
  499.  
  500.    SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet
  501.    Exchange Protocol).
  502.  
  503.  
  504.  
  505.  
  506. SNMPv2 Working Group        Standards Track                     [Page 9]
  507.  
  508. RFC 1906             Transport Mappings for SNMPv2          January 1996
  509.  
  510.  
  511.    It is suggested that administrators configure their SNMPv2 entities
  512.    acting in an agent role to listen on IPX socket 36879 (900f
  513.    hexadecimal).  Further, it is suggested that notification sinks be
  514.    configured to listen on IPX socket 36880 (9010 hexadecimal)
  515.  
  516.    When an SNMPv2 entity uses this transport mapping, it must be capable
  517.    of accepting messages that are at least 546 octets in size.
  518.    Implementation of larger values is encouraged whenever possible.
  519.  
  520. 7.  Proxy to SNMPv1
  521.  
  522.    In order to provide proxy to SNMPv1 [8], it may be useful to define a
  523.    transport domain, rfc1157Domain, which indicates the transport
  524.    mapping for SNMP messages as defined in RFC 1157.  Section 3.1 of [9]
  525.    specifies the behavior of the proxy agent.
  526.  
  527. 8.  Serialization using the Basic Encoding Rules
  528.  
  529.    When the Basic Encoding Rules [10] are used for serialization:
  530.  
  531.    (1)  When encoding the length field, only the definite form is used; use
  532.         of the indefinite form encoding is prohibited.  Note that when
  533.         using the definite-long form, it is permissible to use more than
  534.         the minimum number of length octets necessary to encode the length
  535.         field.
  536.  
  537.    (2)  When encoding the value field, the primitive form shall be used for
  538.         all simple types, i.e., INTEGER, OCTET STRING, and OBJECT
  539.         IDENTIFIER (either IMPLICIT or explicit).  The constructed form of
  540.         encoding shall be used only for structured types, i.e., a SEQUENCE
  541.         or an IMPLICIT SEQUENCE.
  542.  
  543.    (3)  When encoding an object whose syntax is described using the BITS
  544.         construct, the value is encoded as an OCTET STRING, in which all
  545.         the named bits in (the definition of) the bitstring, commencing
  546.         with the first bit and proceeding to the last bit, are placed in
  547.         bits 8 to 1 of the first octet, followed by bits 8 to 1 of each
  548.         subsequent octet in turn, followed by as many bits as are needed of
  549.         the final subsequent octet, commencing with bit 8.  Remaining bits,
  550.         if any, of the final octet are set to zero on generation and
  551.         ignored on receipt.
  552.  
  553.    These restrictions apply to all aspects of ASN.1 encoding, including
  554.    the message wrappers, protocol data units, and the data objects they
  555.    contain.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. SNMPv2 Working Group        Standards Track                    [Page 10]
  563.  
  564. RFC 1906             Transport Mappings for SNMPv2          January 1996
  565.  
  566.  
  567. 8.1.  Usage Example
  568.  
  569.    As an example of applying the Basic Encoding Rules, suppose one
  570.    wanted to encode an instance of the GetBulkRequest-PDU [1]:
  571.  
  572.      [5] IMPLICIT SEQUENCE {
  573.              request-id      1414684022,
  574.              non-repeaters   1,
  575.              max-repetitions 2,
  576.              variable-bindings {
  577.                  { name sysUpTime,
  578.                    value { unspecified NULL } },
  579.                  { name ipNetToMediaPhysAddress,
  580.                    value { unspecified NULL } },
  581.                  { name ipNetToMediaType,
  582.                    value { unspecified NULL } }
  583.              }
  584.          }
  585.  
  586. Applying the BER, this would be encoded (in hexadecimal) as:
  587.  
  588. [5] IMPLICIT SEQUENCE          a5 82 00 39
  589.     INTEGER                    02 04 52 54 5d 76
  590.     INTEGER                    02 01 01
  591.     INTEGER                    02 01 02
  592.     SEQUENCE                   30 2b
  593.         SEQUENCE               30 0b
  594.             OBJECT IDENTIFIER  06 07 2b 06 01 02 01 01 03
  595.             NULL               05 00
  596.         SEQUENCE               30 0d
  597.             OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 02
  598.             NULL               05 00
  599.         SEQUENCE               30 0d
  600.             OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 04
  601.             NULL               05 00
  602.  
  603.    Note that the initial SEQUENCE is not encoded using the minimum
  604.    number of length octets.  (The first octet of the length, 82,
  605.    indicates that the length of the content is encoded in the next two
  606.    octets.)
  607.  
  608. 9.  Security Considerations
  609.  
  610.    Security issues are not discussed in this memo.
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. SNMPv2 Working Group        Standards Track                    [Page 11]
  619.  
  620. RFC 1906             Transport Mappings for SNMPv2          January 1996
  621.  
  622.  
  623. 10.  Editor's Address
  624.  
  625.    Keith McCloghrie
  626.    Cisco Systems, Inc.
  627.    170 West Tasman Drive
  628.    San Jose, CA  95134-1706
  629.    US
  630.  
  631.    Phone: +1 408 526 5260
  632.    EMail: kzm@cisco.com
  633.  
  634. 11.  Acknowledgements
  635.  
  636.    This document is the result of significant work by the four major
  637.    contributors:
  638.  
  639.    Jeffrey D. Case (SNMP Research, case@snmp.com)
  640.    Keith McCloghrie (Cisco Systems, kzm@cisco.com)
  641.    Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
  642.    Steven Waldbusser (International Network Services, stevew@uni.ins.com)
  643.  
  644.    In addition, the contributions of the SNMPv2 Working Group are
  645.    acknowledged.  In particular, a special thanks is extended for the
  646.    contributions of:
  647.  
  648.      Alexander I. Alten (Novell)
  649.      Dave Arneson (Cabletron)
  650.      Uri Blumenthal (IBM)
  651.      Doug Book (Chipcom)
  652.      Kim Curran (Bell-Northern Research)
  653.      Jim Galvin (Trusted Information Systems)
  654.      Maria Greene (Ascom Timeplex)
  655.      Iain Hanson (Digital)
  656.      Dave Harrington (Cabletron)
  657.      Nguyen Hien (IBM)
  658.      Jeff Johnson (Cisco Systems)
  659.      Michael Kornegay (Object Quest)
  660.      Deirdre Kostick (AT&T Bell Labs)
  661.      David Levi (SNMP Research)
  662.      Daniel Mahoney (Cabletron)
  663.      Bob Natale (ACE*COMM)
  664.      Brian O'Keefe (Hewlett Packard)
  665.      Andrew Pearson (SNMP Research)
  666.      Dave Perkins (Peer Networks)
  667.      Randy Presuhn (Peer Networks)
  668.      Aleksey Romanov (Quality Quorum)
  669.      Shawn Routhier (Epilogue)
  670.      Jon Saperia (BGS Systems)
  671.  
  672.  
  673.  
  674. SNMPv2 Working Group        Standards Track                    [Page 12]
  675.  
  676. RFC 1906             Transport Mappings for SNMPv2          January 1996
  677.  
  678.  
  679.      Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
  680.      Kaj Tesink (Bellcore)
  681.      Glenn Waters (Bell-Northern Research)
  682.      Bert Wijnen (IBM)
  683.  
  684. 12.  References
  685.  
  686. [1]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  687.      S. Waldbusser, "Protocol Operations for Version 2 of the Simple
  688.      Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
  689.  
  690. [2]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
  691.      USC/Information Sciences Institute, August 1980.
  692.  
  693. [3]  Information processing systems - Open Systems Interconnection -
  694.      Transport Service Definition, International Organization for
  695.      Standardization.  International Standard 8072, (June, 1986).
  696.  
  697. [4]  Information processing systems - Open Systems Interconnection -
  698.      Transport Service Definition - Addendum 1: Connectionless-mode
  699.      Transmission, International Organization for Standardization.
  700.      International Standard 8072/AD 1, (December, 1986).
  701.  
  702. [5]  G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second
  703.      edition).  Addison-Wesley, 1990.
  704.  
  705. [6]  Waldbusser, S., "AppleTalk Management Information Base", RFC 1243,
  706.      Carnegie Mellon University, July 1991.
  707.  
  708. [7]  Network System Technical Interface Overview.  Novell, Inc, (June,
  709.      1989).
  710.  
  711. [8]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
  712.      Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
  713.      Systems International, MIT Laboratory for Computer Science, May
  714.      1990.
  715.  
  716. [9]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  717.      S. Waldbusser, "Coexistence between Version 1 and Version 2 of the
  718.      Internet-standard Network Management Framework", RFC 1908,
  719.      January 1996.
  720.  
  721. [10] Information processing systems - Open Systems Interconnection -
  722.      Specification of Basic Encoding Rules for Abstract Syntax Notation
  723.      One (ASN.1), International Organization for Standardization.
  724.      International Standard 8825, December 1987.
  725.  
  726.  
  727.  
  728.  
  729.  
  730. SNMPv2 Working Group        Standards Track                    [Page 13]
  731.  
  732.