rfc3417.txt

开发snmp的开发包有两个开放的SNMP开发库

   END

3.  SNMP over UDP over IPv4

   This is the preferred transport mapping.

3.1.  Serialization

   Each instance of a message is serialized (i.e., encoded according to
   the convention of [BER]) onto a single UDP [RFC768] over IPv4
   [RFC791] datagram, using the algorithm specified in Section 8.

3.2.  Well-known Values

   It is suggested that administrators configure their SNMP entities
   supporting command responder applications to listen on UDP port 161.
   Further, it is suggested that SNMP entities supporting notification
   receiver applications be configured to listen on UDP port 162.

   When an SNMP entity uses this transport mapping, it must be capable
   of accepting messages up to and including 484 octets in size.  It is
   recommended that implementations be capable of accepting messages of
   up to 1472 octets in size.  Implementation of larger values is
   encouraged whenever possible.

4.  SNMP over OSI

   This is an optional transport mapping.

4.1.  Serialization

   Each instance of a message is serialized onto a single TSDU [IS8072]
   [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS),
   using the algorithm specified in Section 8.



Presuhn, et al.             Standards Track                     [Page 7]

RFC 3417              Transport Mappings for SNMP          December 2002


4.2.  Well-known Values

   It is suggested that administrators configure their SNMP entities
   supporting command responder applications to listen on transport
   selector "snmp-l" (which consists of six ASCII characters), when
   using a CL-mode network service to realize the CLTS.  Further, it is
   suggested that SNMP entities supporting notification receiver
   applications be configured to listen on transport selector "snmpt-l"
   (which consists of seven ASCII characters, six letters and a hyphen)
   when using a CL-mode network service to realize the CLTS.  Similarly,
   when using a CO-mode network service to realize the CLTS, the
   suggested transport selectors are "snmp-o" and "snmpt-o", for command
   responders and notification receivers, respectively.

   When an SNMP entity uses this transport mapping, it must be capable
   of accepting messages that are at least 484 octets in size.
   Implementation of larger values is encouraged whenever possible.

5.  SNMP over DDP

   This is an optional transport mapping.

5.1.  Serialization

   Each instance of a message is serialized onto a single DDP datagram
   [APPLETALK], using the algorithm specified in Section 8.

5.2.  Well-known Values

   SNMP messages are sent using DDP protocol type 8.  SNMP entities
   supporting command responder applications listen on DDP socket number
   8, while SNMP entities supporting notification receiver applications
   listen on DDP socket number 9.

   Administrators must configure their SNMP entities supporting command
   responder applications to use NBP type "SNMP Agent" (which consists
   of ten ASCII characters) while those supporting notification receiver
   applications must be configured to use NBP type "SNMP Trap Handler"
   (which consists of seventeen ASCII characters).

   The NBP name for SNMP entities supporting command responders and
   notification receivers should be stable - NBP names should not change
   any more often than the IP address of a typical TCP/IP node.  It is
   suggested that the NBP name be stored in some form of stable storage.

   When an SNMP entity uses this transport mapping, it must be capable
   of accepting messages that are at least 484 octets in size.
   Implementation of larger values is encouraged whenever possible.



Presuhn, et al.             Standards Track                     [Page 8]

RFC 3417              Transport Mappings for SNMP          December 2002


5.3.  Discussion of AppleTalk Addressing

   The AppleTalk protocol suite has certain features not manifest in the
   TCP/IP suite.  AppleTalk's naming strategy and the dynamic nature of
   address assignment can cause problems for SNMP entities that wish to
   manage AppleTalk networks.  TCP/IP nodes have an associated IP
   address which distinguishes each from the other.  In contrast,
   AppleTalk nodes generally have no such characteristic.  The network-
   level address, while often relatively stable, can change at every
   reboot (or more frequently).

   Thus, when SNMP is mapped over DDP, nodes are identified by a "name",
   rather than by an "address".  Hence, all AppleTalk nodes that
   implement this mapping are required to respond to NBP lookups and
   confirms (e.g., implement the NBP protocol stub), which guarantees
   that a mapping from NBP name to DDP address will be possible.

   In determining the SNMP identity to register for an SNMP entity, it
   is suggested that the SNMP identity be a name which is associated
   with other network services offered by the machine.

   NBP lookups, which are used to map NBP names into DDP addresses, can
   cause large amounts of network traffic as well as consume CPU
   resources.  It is also the case that the ability to perform an NBP
   lookup is sensitive to certain network disruptions (such as zone
   table inconsistencies) which would not prevent direct AppleTalk
   communications between two SNMP entities.

   Thus, it is recommended that NBP lookups be used infrequently,
   primarily to create a cache of name-to-address mappings.  These
   cached mappings should then be used for any further SNMP traffic.  It
   is recommended that SNMP entities supporting command generator
   applications should maintain this cache between reboots.  This
   caching can help minimize network traffic, reduce CPU load on the
   network, and allow for (some amount of) network trouble shooting when
   the basic name-to-address translation mechanism is broken.

5.3.1.  How to Acquire NBP names

   An SNMP entity supporting command generator applications may have a
   pre-configured list of names of "known" SNMP entities supporting
   command responder applications.  Similarly, an SNMP entity supporting
   command generator or notification receiver applications might
   interact with an operator.  Finally, an SNMP entity supporting
   command generator or notification receiver applications might
   communicate with all SNMP entities supporting command responder or
   notification originator applications in a set of zones or networks.




Presuhn, et al.             Standards Track                     [Page 9]

RFC 3417              Transport Mappings for SNMP          December 2002


5.3.2.  When to Turn NBP names into DDP addresses

   When an SNMP entity uses a cache entry to address an SNMP packet, it
   should attempt to confirm the validity mapping, if the mapping hasn't
   been confirmed within the last T1 seconds.  This cache entry
   lifetime, T1, has a minimum, default value of 60 seconds, and should
   be configurable.

   An SNMP entity supporting a command generator application may decide
   to prime its cache of names prior to actually communicating with
   another SNMP entity.  In general, it is expected that such an entity
   may want to keep certain mappings "more current" than other mappings,
   e.g., those nodes which represent the network infrastructure (e.g.,
   routers) may be deemed "more important".

   Note that an SNMP entity supporting command generator applications
   should not prime its entire cache upon initialization - rather, it
   should attempt resolutions over an extended period of time (perhaps
   in some pre-determined or configured priority order).  Each of these
   resolutions might, in fact, be a wildcard lookup in a given zone.

   An SNMP entity supporting command responder applications must never
   prime its cache.  When generating a response, such an entity does not
   need to confirm a cache entry.  An SNMP entity supporting
   notification originator applications should do NBP lookups (or
   confirms) only when it needs to send an SNMP trap or inform.

5.3.3.  How to Turn NBP names into DDP addresses

   If the only piece of information available is the NBP name, then an
   NBP lookup should be performed to turn that name into a DDP address.
   However, if there is a piece of stale information, it can be used as
   a hint to perform an NBP confirm (which sends a unicast to the
   network address which is presumed to be the target of the name
   lookup) to see if the stale information is, in fact, still valid.

   An NBP name to DDP address mapping can also be confirmed implicitly
   using only SNMP transactions.  For example, an SNMP entity supporting
   command generator applications issuing a retrieval operation could
   also retrieve the relevant objects from the NBP group [RFC1742] for
   the SNMP entity supporting the command responder application.  This
   information can then be correlated with the source DDP address of the
   response.

5.3.4.  What if NBP is broken

   Under some circumstances, there may be connectivity between two SNMP
   entities, but the NBP mapping machinery may be broken, e.g.,



Presuhn, et al.             Standards Track                    [Page 10]

RFC 3417              Transport Mappings for SNMP          December 2002


   o  the NBP FwdReq (forward NBP lookup onto local attached network)
      mechanism might be broken at a router on the other entity's
      network; or,

   o  the NBP BrRq (NBP broadcast request) mechanism might be broken at
      a router on the entity's own network; or,

   o  NBP might be broken on the other entity's node.

   An SNMP entity supporting command generator applications which is
   dedicated to AppleTalk management might choose to alleviate some of
   these failures by directly implementing the router portion of NBP.
   For example, such an entity might already know all the zones on the
   AppleTalk internet and the networks on which each zone appears.
   Given an NBP lookup which fails, the entity could send an NBP FwdReq
   to the network in which the SNMP entity supporting the command
   responder or notification originator application was last located.
   If that failed, the station could then send an NBP LkUp (NBP lookup
   packet) as a directed (DDP) multicast to each network number on that
   network.  Of the above (single) failures, this combined approach will
   solve the case where either the local router's BrRq-to-FwdReq
   mechanism is broken or the remote router's FwdReq-to-LkUp mechanism
   is broken.

6.  SNMP over IPX

   This is an optional transport mapping.

6.1.  Serialization

   Each instance of a message is serialized onto a single IPX datagram
   [NOVELL], using the algorithm specified in Section 8.

6.2.  Well-known Values

   SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange
   Protocol).

   It is suggested that administrators configure their SNMP entities
   supporting command responder applications to listen on IPX socket
   36879 (900f hexadecimal).  Further, it is suggested that those
   supporting notification receiver applications be configured to listen
   on IPX socket 36880 (9010 hexadecimal).

   When an SNMP entity uses this transport mapping, it must be capable
   of accepting messages that are at least 546 octets in size.
   Implementation of larger values is encouraged whenever possible.




Presuhn, et al.             Standards Track                    [Page 11]

RFC 3417              Transport Mappings for SNMP          December 2002


7.  Proxy to SNMPv1

   Historically, in order to support proxy to SNMPv1, as defined in
   [RFC2576], it was deemed useful to define a transport domain,
   rfc1157Domain, which indicates the transport mapping for SNMP
   messages as defined in [RFC1157].

8.  Serialization using the Basic Encoding Rules

   When the Basic Encoding Rules [BER] are used for serialization:

   (1)   When encoding the length field, only the definite form is used;
         use of the indefinite form encoding is prohibited.  Note that
         when using the definite-long form, it is permissible to use
         more than the minimum number of length octets necessary to
         encode the length field.

   (2)   When encoding the value field, the primitive form shall be used
         for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT
         IDENTIFIER (either IMPLICIT or explicit).  The constructed form
         of encoding shall be used only for structured types, i.e., a
         SEQUENCE or an IMPLICIT SEQUENCE.

   (3)   When encoding an object whose syntax is described using the
         BITS construct, the value is encoded as an OCTET STRING, in
         which all the named bits in (the definition of) the bitstring,
         commencing with the first bit and proceeding to the last bit,
         are placed in bits 8 (high order bit) to 1 (low order bit) of
         the first octet, followed by bits 8 to 1 of each subsequent
         octet in turn, followed by as many bits as are needed of the
         final subsequent octet, commencing with bit 8.  Remaining bits,
         if any, of the final octet are set to zero on generation and
         ignored on receipt.

   These restrictions apply to all aspects of ASN.1 encoding, including
   the message wrappers, protocol data units, and the data objects they
   contain.














Presuhn, et al.             Standards Track                    [Page 12]

RFC 3417              Transport Mappings for SNMP          December 2002


8.1.  Usage Example

   As an example of applying the Basic Encoding Rules, suppose one
   wanted to encode an instance of the GetBulkRequest-PDU [RFC3416]:

     [5] IMPLICIT SEQUENCE {
             request-id      1414684022,
             non-repeaters   1,
             max-repetitions 2,
             variable-bindings {
                 { name sysUpTime,
                   value { unSpecified NULL } },
                 { name ipNetToMediaPhysAddress,
                   value { unSpecified NULL } },
                 { name ipNetToMediaType,
                   value { unSpecified NULL } }
             }
         }

   Applying the BER, this may be encoded (in hexadecimal) as:

   [5] IMPLICIT SEQUENCE          a5 82 00 39
       INTEGER                    02 04 54 52 5d 76
       INTEGER                    02 01 01
       INTEGER                    02 01 02
       SEQUENCE (OF)              30 2b
           SEQUENCE               30 0b
               OBJECT IDENTIFIER  06 07 2b 06 01 02 01 01 03
               NULL               05 00
           SEQUENCE               30 0d
               OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 02
               NULL               05 00
           SEQUENCE               30 0d
               OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 04