rfc1906.txt

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

   reboot (or more frequently).

   Thus, when SNMPv2 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 SNMPv2 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 SNMPv2 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 SNMPv2 entities acting in a manager role should
   maintain this cache between reboots.  This caching can help minimize



SNMPv2 Working Group        Standards Track                     [Page 7]

RFC 1906             Transport Mappings for SNMPv2          January 1996


   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 SNMPv2 entity acting in a manager role may have a pre-configured
   list of names of "known" SNMPv2 entities acting in an agent role.
   Similarly, an SNMPv2 entity acting in a manager role might interact
   with an operator.  Finally, an SNMPv2 entity acting in a manager role
   might communicate with all SNMPv2 entities acting in an agent role in
   a set of zones or networks.

5.3.2.  When to Turn NBP names into DDP addresses

   When an SNMPv2 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 SNMPv2 entity acting in a manager role may decide to prime its
   cache of names prior to actually communicating with another SNMPv2
   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 SNMPv2 entity acting in a manager role 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 SNMPv2 entity acting in an agent role must never prime its cache.
   Such an entity should do NBP lookups (or confirms) only when it needs
   to send an SNMP trap.  When generating a response, such an entity
   does not need to confirm a cache entry.

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.




SNMPv2 Working Group        Standards Track                     [Page 8]

RFC 1906             Transport Mappings for SNMPv2          January 1996


   An NBP name to DDP address mapping can also be confirmed implicitly
   using only SNMP transactions.  For example, an SNMPv2 entity acting
   in a manager role issuing a retrieval operation could also retrieve
   the relevant objects from the NBP group [6] for the SNMPv2 entity
   acting in an agent role.  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
   SNMPv2 entities, but the NBP mapping machinery may be broken, e.g.,

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 SNMPv2 entity acting in a manager role 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 agent 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.  SNMPv2 over IPX

   This is an optional transport mapping.

6.1.  Serialization

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

6.2.  Well-known Values

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




SNMPv2 Working Group        Standards Track                     [Page 9]

RFC 1906             Transport Mappings for SNMPv2          January 1996


   It is suggested that administrators configure their SNMPv2 entities
   acting in an agent role to listen on IPX socket 36879 (900f
   hexadecimal).  Further, it is suggested that notification sinks be
   configured to listen on IPX socket 36880 (9010 hexadecimal)

   When an SNMPv2 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.

7.  Proxy to SNMPv1

   In order to provide proxy to SNMPv1 [8], it may be useful to define a
   transport domain, rfc1157Domain, which indicates the transport
   mapping for SNMP messages as defined in RFC 1157.  Section 3.1 of [9]
   specifies the behavior of the proxy agent.

8.  Serialization using the Basic Encoding Rules

   When the Basic Encoding Rules [10] 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 to 1 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.






SNMPv2 Working Group        Standards Track                    [Page 10]

RFC 1906             Transport Mappings for SNMPv2          January 1996


8.1.  Usage Example

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

     [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 would be encoded (in hexadecimal) as:

[5] IMPLICIT SEQUENCE          a5 82 00 39
    INTEGER                    02 04 52 54 5d 76
    INTEGER                    02 01 01
    INTEGER                    02 01 02
    SEQUENCE                   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
            NULL               05 00

   Note that the initial SEQUENCE is not encoded using the minimum
   number of length octets.  (The first octet of the length, 82,
   indicates that the length of the content is encoded in the next two
   octets.)

9.  Security Considerations

   Security issues are not discussed in this memo.







SNMPv2 Working Group        Standards Track                    [Page 11]

RFC 1906             Transport Mappings for SNMPv2          January 1996


10.  Editor's Address

   Keith McCloghrie
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   US

   Phone: [phone]
   EMail: [e-mail]

11.  Acknowledgements

   This document is the result of significant work by the four major
   contributors:

   Jeffrey D. Case (SNMP Research, [e-mail])
   Keith McCloghrie (Cisco Systems, [e-mail])
   Marshall T. Rose (Dover Beach Consulting, [e-mail])
   Steven Waldbusser (International Network Services, [e-mail])

   In addition, the contributions of the SNMPv2 Working Group are
   acknowledged.  In particular, a special thanks is extended for the
   contributions of:

     Alexander I. Alten (Novell)
     Dave Arneson (Cabletron)
     Uri Blumenthal (IBM)
     Doug Book (Chipcom)
     Kim Curran (Bell-Northern Research)
     Jim Galvin (Trusted Information Systems)
     Maria Greene (Ascom Timeplex)
     Iain Hanson (Digital)
     Dave Harrington (Cabletron)
     Nguyen Hien (IBM)
     Jeff Johnson (Cisco Systems)
     Michael Kornegay (Object Quest)
     Deirdre Kostick (AT&T Bell Labs)
     David Levi (SNMP Research)
     Daniel Mahoney (Cabletron)
     Bob Natale (ACE*COMM)
     Brian O'Keefe (Hewlett Packard)
     Andrew Pearson (SNMP Research)
     Dave Perkins (Peer Networks)
     Randy Presuhn (Peer Networks)
     Aleksey Romanov (Quality Quorum)
     Shawn Routhier (Epilogue)
     Jon Saperia (BGS Systems)



SNMPv2 Working Group        Standards Track                    [Page 12]

RFC 1906             Transport Mappings for SNMPv2          January 1996


     Bob Stewart (Cisco Systems, [e-mail]), chair
     Kaj Tesink (Bellcore)
     Glenn Waters (Bell-Northern Research)
     Bert Wijnen (IBM)

12.  References

[1]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.

[2]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
     USC/Information Sciences Institute, August 1980.

[3]  Information processing systems - Open Systems Interconnection -
     Transport Service Definition, International Organization for
     Standardization.  International Standard 8072, (June, 1986).

[4]  Information processing systems - Open Systems Interconnection -
     Transport Service Definition - Addendum 1: Connectionless-mode
     Transmission, International Organization for Standardization.
     International Standard 8072/AD 1, (December, 1986).

[5]  G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second
     edition).  Addison-Wesley, 1990.

[6]  Waldbusser, S., "AppleTalk Management Information Base", RFC 1243,
     Carnegie Mellon University, July 1991.

[7]  Network System Technical Interface Overview.  Novell, Inc, (June,
     1989).

[8]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
     Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
     Systems International, MIT Laboratory for Computer Science, May
     1990.

[9]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Coexistence between Version 1 and Version 2 of the
     Internet-standard Network Management Framework", RFC 1908,
     January 1996.

[10] Information processing systems - Open Systems Interconnection -
     Specification of Basic Encoding Rules for Abstract Syntax Notation
     One (ASN.1), International Organization for Standardization.
     International Standard 8825, December 1987.





SNMPv2 Working Group        Standards Track                    [Page 13]