rfc1906.txt

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

Network Working Group                               SNMPv2 Working Group
Request for Comments: 1906                                       J. Case
Obsoletes: 1449                                      SNMP Research, Inc.
Category: Standards Track                                  K. McCloghrie
                                                     Cisco Systems, Inc.
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                           S. Waldbusser
                                          International Network Services
                                                            January 1996


                Transport Mappings for Version 2 of the
              Simple Network Management Protocol (SNMPv2)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Table of Contents

   1. Introduction ................................................    2
   1.1 A Note on Terminology ......................................    2
   2. Definitions .................................................    3
   3. SNMPv2 over UDP .............................................    5
   3.1 Serialization ..............................................    5
   3.2 Well-known Values ..........................................    5
   4. SNMPv2 over OSI .............................................    6
   4.1 Serialization ..............................................    6
   4.2 Well-known Values ..........................................    6
   5. SNMPv2 over DDP .............................................    6
   5.1 Serialization ..............................................    6
   5.2 Well-known Values ..........................................    6
   5.3 Discussion of AppleTalk Addressing .........................    7
   5.3.1 How to Acquire NBP names .................................    8
   5.3.2 When to Turn NBP names into DDP addresses ................    8
   5.3.3 How to Turn NBP names into DDP addresses .................    8
   5.3.4 What if NBP is broken ....................................    9
   6. SNMPv2 over IPX .............................................    9
   6.1 Serialization ..............................................    9
   6.2 Well-known Values ..........................................    9
   7. Proxy to SNMPv1 .............................................   10
   8. Serialization using the Basic Encoding Rules ................   10
   8.1 Usage Example ..............................................   11



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


   9. Security Considerations .....................................   11
   10. Editor's Address ...........................................   12
   11. Acknowledgements ...........................................   12
   12. References .................................................   13

1.  Introduction

   A management system contains:  several (potentially many) nodes, each
   with a processing entity, termed an agent, which has access to
   management instrumentation; at least one management station; and, a
   management protocol, used to convey management information between
   the agents and management stations.  Operations of the protocol are
   carried out under an administrative framework which defines
   authentication, authorization, access control, and privacy policies.

   Management stations execute management applications which monitor and
   control managed elements.  Managed elements are devices such as
   hosts, routers, terminal servers, etc., which are monitored and
   controlled via access to their management information.

   The management protocol, version 2 of the Simple Network Management
   Protocol [1], may be used over a variety of protocol suites.  It is
   the purpose of this document to define how the SNMPv2 maps onto an
   initial set of transport domains.  Other mappings may be defined in
   the future.

   Although several mappings are defined, the mapping onto UDP is the
   preferred mapping.  As such, to provide for the greatest level of
   interoperability, systems which choose to deploy other mappings
   should also provide for proxy service to the UDP mapping.

1.1.  A Note on Terminology

   For the purpose of exposition, the original Internet-standard Network
   Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD
   15), and 1212 (STD 16), is termed the SNMP version 1 framework
   (SNMPv1).  The current framework is termed the SNMP version 2
   framework (SNMPv2).













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


2.  Definitions

SNMPv2-TM DEFINITIONS ::= BEGIN

IMPORTS
    OBJECT-IDENTITY, snmpDomains, snmpProxys
        FROM SNMPv2-SMI
    TEXTUAL-CONVENTION
        FROM SNMPv2-TC;

-- SNMPv2 over UDP over IPv4

snmpUDPDomain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMPv2 over UDP transport domain.  The corresponding
            transport address is of type SnmpUDPAddress."
    ::= { snmpDomains 1 }

SnmpUDPAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d/2d"
    STATUS       current
    DESCRIPTION
            "Represents a UDP address:

               octets   contents        encoding
                1-4     IP-address      network-byte order
                5-6     UDP-port        network-byte order
            "
    SYNTAX       OCTET STRING (SIZE (6))


-- SNMPv2 over OSI

snmpCLNSDomain OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMPv2 over CLNS transport domain.  The corresponding
            transport address is of type SnmpOSIAddress."
    ::= { snmpDomains 2 }

snmpCONSDomain OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMPv2 over CONS transport domain.  The corresponding
            transport address is of type SnmpOSIAddress."
    ::= { snmpDomains 3 }




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


SnmpOSIAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "*1x:/1x:"
    STATUS       current
    DESCRIPTION
            "Represents an OSI transport-address:

               octets   contents           encoding
                  1     length of NSAP     'n' as an unsigned-integer
                                              (either 0 or from 3 to 20)
               2..(n+1) NSAP                concrete binary representation
               (n+2)..m TSEL                string of (up to 64) octets
            "
    SYNTAX       OCTET STRING (SIZE (1 | 4..85))


-- SNMPv2 over DDP

snmpDDPDomain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMPv2 over DDP transport domain.  The corresponding
            transport address is of type SnmpNBPAddress."
    ::= { snmpDomains 4 }

SnmpNBPAddress ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "Represents an NBP name:

                 octets        contents          encoding
                    1          length of object  'n' as an unsigned integer
                  2..(n+1)     object            string of (up to 32) octets
                   n+2         length of type    'p' as an unsigned integer
              (n+3)..(n+2+p)   type              string of (up to 32) octets
                  n+3+p        length of zone    'q' as an unsigned integer
            (n+4+p)..(n+3+p+q) zone              string of (up to 32) octets

            For comparison purposes, strings are case-insensitive All
            strings may contain any octet other than 255 (hex ff)."
    SYNTAX       OCTET STRING (SIZE (3..99))


-- SNMPv2 over IPX

snmpIPXDomain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMPv2 over IPX transport domain.  The corresponding



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


            transport address is of type SnmpIPXAddress."
    ::= { snmpDomains 5 }

SnmpIPXAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
    STATUS       current
    DESCRIPTION
            "Represents an IPX address:

               octets   contents            encoding
                1-4     network-number      network-byte order
                5-10    physical-address    network-byte order
               11-12    socket-number       network-byte order
            "
    SYNTAX       OCTET STRING (SIZE (12))


-- for proxy to SNMPv1 (RFC 1157)

rfc1157Proxy   OBJECT IDENTIFIER ::= { snmpProxys 1 }

rfc1157Domain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The transport domain for SNMPv1 over UDP.  The
            corresponding transport address is of type SnmpUDPAddress."
    ::= { rfc1157Proxy 1 }

--  ::= { rfc1157Proxy 2 }            this OID is obsolete


END

3.  SNMPv2 over UDP

   This is the preferred transport mapping.

3.1.  Serialization

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

3.2.  Well-known Values

   It is suggested that administrators configure their SNMPv2 entities
   acting in an agent role to listen on UDP port 161.  Further, it is
   suggested that notification sinks be configured to listen on UDP port



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


   162.

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

4.  SNMPv2 over OSI

   This is an optional transport mapping.

4.1.  Serialization

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

4.2.  Well-known Values

   It is suggested that administrators configure their SNMPv2 entities
   acting in an agent role 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
   notification sinks 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
   agent and notification sink, respectively.

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

   This is an optional transport mapping.

5.1.  Serialization

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

5.2.  Well-known Values

   SNMPv2 messages are sent using DDP protocol type 8.  SNMPv2 entities
   acting in an agent role listens on DDP socket number 8, whilst
   notification sinks listen on DDP socket number 9.




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


   Administrators must configure their SNMPv2 entities acting in an
   agent role to use NBP type "SNMP Agent" (which consists of ten ASCII
   characters), whilst notification sinks must be configured to use NBP
   type "SNMP Trap Handler" (which consists of seventeen ASCII
   characters).

   The NBP name for agents and notification sinks 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 SNMPv2 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.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 SNMPv2 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