Draft Transport Mappings for SNMPv2 Oct 92 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) Thu Nov 12 08:51:15 1992 | Jeffrey D. Case SNMP Research, Inc. University of Tennessee, Knoxville case@cs.utk.edu Keith McCloghrie Hughes LAN Systems kzm@hls.com Marshall T. Rose Dover Beach Consulting, Inc. mrose@dbc.mtview.ca.us Steven L. Waldbusser Carnegie Mellon University waldbusser@andrew.cmu.edu 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Expires May 12, 1993 [Page 1] Draft Transport Mappings for SNMPv2 Oct 92 2. Introduction A network management system contains: several (potentially many) nodes, each with management instrumentation termed an agent; at least one management station; and, a management protocol, which is used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines both authentication and authorization policies. Network management stations execute management applications which monitor and control network elements. Network elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled through access to their management information. The management protocol, version 2 of the Simple Network Management Protocol, 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. + 2.1. A Note on Terminology + For the purpose of exposition, the original Internet-standard + Network Management Framework, as described in RFCs 1155, 1157, + and 1212, is termed the SNMP version 1 framework (SNMPv1). + The current framework is termed the SNMP version 2 framework + (SNMPv2). + Expires May 12, 1993 [Page 2] Draft Transport Mappings for SNMPv2 Oct 92 3. Definitions SNMPv2-TM DEFINITIONS ::= BEGIN IMPORTS snmpMappings FROM SNMPV2-SMI TEXTUAL-CONVENTION, DisplayString FROM SNMPV2-TC; snmpDomains OBJECT IDENTIFIER ::= { snmpMappings 1 } -- SNMPv2 over UDP snmpUDPDomain OBJECT IDENTIFIER ::= { snmpDomains 1 } -- for an SnmpUDPAddress of length 6: -- -- octets contents encoding -- 1-4 IP-address network-byte order -- 5-6 UDP-port network-byte order -- SnmpUDPAddress TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d" STATUS current DESCRIPTION "Represents a UDP-address." ::= OCTET STRING (SIZE (6)) Expires May 12, 1993 [Page 3] Draft Transport Mappings for SNMPv2 Oct 92 -- SNMPv2 over OSI snmpCLNSDomain OBJECT IDENTIFIER ::= { snmpDomains 2 } snmpCONSDomain OBJECT IDENTIFIER ::= { snmpDomains 3 } -- for an SnmpOSIAddress of length m: -- -- 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 -- SnmpOSIAddress TEXTUAL-CONVENTION DISPLAY-HINT "*1x:/1x:" STATUS current DESCRIPTION "Represents an OSI transport-address." ::= OCTET STRING (SIZE (1 | 4..85)) -- SNMPv2 over DDP snmpDDPDomain OBJECT IDENTIFIER ::= { snmpDomains 4 } -- for an SnmpNBPAddress of length m: -- -- octets contents encoding -- 1 length of Object "n" as an unsigned integer -- 2..(n+1) Object string of (up to 32) octets -- (n+2)..m Zone string of (up to 32) octets -- SnmpNBPAddress TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents an NBP-name." ::= OCTET STRING (SIZE (3..65)) Expires May 12, 1993 [Page 4] Draft Transport Mappings for SNMPv2 Oct 92 -- SNMPv2 over IPX snmpIPXDomain OBJECT IDENTIFIER ::= { snmpDomains 5 } -- for an SnmpIPXAddress of length 12: -- -- octets contents encoding -- 1-4 network-number network-byte order -- 5-10 physical-address network-byte order -- 11-12 socket-number network-byte order -- SnmpIPXAddress TEXTUAL-CONVENTION DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" STATUS current DESCRIPTION "Represents an IPX-address." ::= OCTET STRING (SIZE (12)) -- restart domain restartDomain OBJECT IDENTIFIER ::= { snmpDomains 6 } RestartAddress TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents a local configuration store, e.g., the name of a memory or disk file." ::= DisplayString -- entity domain entityDomain OBJECT IDENTIFIER ::= { snmpDomains 7 } EntityAddress TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents an administratively assigned name, chosen for mnemonic and human-understandability, for a local attached entity (e.g., a hardware or software device)." ::= DisplayString Expires May 12, 1993 [Page 5] Draft Transport Mappings for SNMPv2 Oct 92 -- for proxy to community-based SNMPv1 (RFC 1157) -- uses snmpUDPAddress rfc1157Domain OBJECT IDENTIFIER ::= { snmpDomains 8 } -- the community-based noAuth rfc1157noAuth OBJECT IDENTIFIER ::= { snmpDomains 9 } END Expires May 12, 1993 [Page 6] Draft Transport Mappings for SNMPv2 Oct 92 4. SNMPv2 over UDP This is the preferred transport mapping. 4.1. Serialization Each instance of a message is serialized onto a single UDP[1] datagram, using the algorithm specified in Section 11. 4.2. Well-known Values Although the partyTable gives transport addressing information for an SNMPv2 party, 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 trap sinks be configured to listen on UDP port 162. The partyTable also lists the maximum message size which a SNMPv2 party is willing to accept. This value must be at least 484 octets. Implementation of larger values is encouraged whenever possible. Expires May 12, 1993 [Page 7] Draft Transport Mappings for SNMPv2 Oct 92 5. SNMPv2 over OSI This is an optional transport mapping. 5.1. Serialization Each instance of a message is serialized onto a single TSDU [2,3] for the OSI Connectionless-mode Transport Service (CLTS), using the algorithm specified in Section 11. 5.2. Well-known Values Although the partyTable gives transport addressing information for an SNMPv2 party, 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 trap sinks be configured to listen on transport selector "snmpt-l" (which consists of seven ASCII characters) 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 trap sink, respectively. The partyTable also lists the maximum message size which a SNMPv2 party is willing to accept. This value must be at least 484 octets. Implementation of larger values is encouraged whenever possible. Expires May 12, 1993 [Page 8] Draft Transport Mappings for SNMPv2 Oct 92 6. SNMPv2 over DDP This is an optional transport mapping. 6.1. Serialization Each instance of a message is serialized onto a single DDP datagram [4], using the algorithm specified in Section 11. 6.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 trap sinks listen on DDP socket 9. Although the partyTable gives transport addressing information for an SNMPv2 party, it is suggested that administrators configure their SNMPv2 entities acting in an agent role to use NBP type "SNMP Agent" (which consists of ten ASCII characters), whilst trap sinks should be configured to use NBP type "SNMP Trap Handler" (which consists of seventeen ASCII characters). The partyTable also lists the maximum message size which a SNMPv2 party is willing to accept. This value must be at least 484 octets. Implementation of larger values is encouraged whenever possible. Expires May 12, 1993 [Page 9] Draft Transport Mappings for SNMPv2 Oct 92 7. SNMPv2 over IPX This is an optional transport mapping. 7.1. Serialization Each instance of a message is serialized onto a single IPX datagram [5], using the algorithm specified in Section 11. 7.2. Well-known Values Although the partyTable gives transport addressing information for an SNMPv2 party, 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 trap sinks be configured to listen on IPX socket 36880 (9010 hexadecimal) The partyTable also lists the maximum message size which a SNMPv2 party is willing to accept. This value must be at least 546 octets. Implementation of larger values is encouraged whenever possible. Expires May 12, 1993 [Page 10] Draft Transport Mappings for SNMPv2 Oct 92 8. Restart Domain This is an optional transport mapping. 8.1. Usage The restart domain is used as the transport domain of a party which has a MIB view containing the values of managed objects to be used on a restart of a device. Hence, the use of such a party to manipulate variables does not affect the running system; rather, the changes will be in effect only after the device next restarts. Expires May 12, 1993 [Page 11] Draft Transport Mappings for SNMPv2 Oct 92 9. Entity Domain This is an optional transport mapping. 9.1. Usage The entity domain is used to name locally attached software or hardware entities that can be managed through a proxy mechanism through the local agent. For example, the entity domain may address multiple repeaters in a hub or multiple AppleTalk protocol stacks on a computer system. Expires May 12, 1993 [Page 12] Draft Transport Mappings for SNMPv2 Oct 92 10. Proxy to SNMPv1 In order to provide proxy to community-based SNMP [6], some definitions are necessary for both transport domains and authentication protocols. 10.1. Transport Domain: rfc1157Domain The transport domain, rfc1157Domain, indicates the transport mapping for community-based SNMP messages defined in RFC 1157. When a party's transport domain (partyTDomain) is rfc1157Domain: (1) the party's transport address (partyTAddress) shall be 6 octets long, the initial 4 octets containing the IP- address in network-byte order, and the last two octets containing the UDP port in network-byte order; and, (2) the party's authentication protocol (partyAuthProtocol) shall be rfc1157noAuth. 10.2. Authentication Algorithm: rfc1157noAuth A party's authentication protocol (partyAuthProtocol) specifies the protocol and mechanism by which the party authenticates the integrity and origin of the SNMPv1 or SNMPv2 PDUs it generates. When a party's authentication protocol is rfc1157noAuth: (1) the party's public authentication key (partyAuthPublic), clock (partyAuthClock), and lifetime (partyAuthLifetime) are irrelevant; and, (2) the party's private authentication key (partySecretsAuthPrivate) shall be used as the 1157 community for the proxy target, and shall be at least one octet in length (no maximum length is specified). Note that when setting the party's private authentication key, the exclusive-OR semantics specified in [7] still apply. Expires May 12, 1993 [Page 13] Draft Transport Mappings for SNMPv2 Oct 92 11. Serialization using the Basic Encoding Rules When the Basic Encoding Rules [8] 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, OBJECT IDENTIFIER, and BIT STRING (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 a BIT STRING is serialized, all named-bits are transferred regardless of their truth-value. Further, if the number of named-bits is not an integral multiple of eight, then the fewest number of additional zero-valued bits are transferred so that an integral multiple of eight bits is transferred. These restrictions apply to all aspects of ASN.1 encoding, including the message wrappers, protocol data units, and the data objects they contain. Expires May 12, 1993 [Page 14] Draft Transport Mappings for SNMPv2 Oct 92 11.1. Usage Example As an example of applying the Basic Encoding Rules, suppose one wanted to encode an instance of the GetBulkRequest-PDU [9]: [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.) Expires May 12, 1993 [Page 15] Draft Transport Mappings for SNMPv2 Oct 92 12. Acknowledgements The UDP-based mapping is based, in part, on RFC 1157. The OSI-based mapping is based, in part, on RFC 1283. The DDP-based mapping is based, in part, on earlier work by Greg Minshall of Novell, Inc., and Mike Ritter of Apple Computer, Inc. The IPX-based mapping is based, in part, on RFC 1298. The section on proxy to community-based SNMP is based on earlier work that was based in part on a suggestion by Jonathan Biggar of Netlabs, Inc. Finally, the comments of the SNMP Version 2 working group are gratefully acknowledged: Steve Alexander, Interactive Systems Uri Blumenthal, International Business Machines Jeffrey D. Case, SNMP Research, Inc. Tracy Cox, Bellcore James R. (Chuck) Davin, Bellcore Mike Davison, FiberCom Taso N. Devetzis, Bellcore Gary W. Haney, Martin Marietta Energy Systems Matt Hecht, SNMP Research, Inc. Susan E. Hicks, Martin Marietta Energy Systems Satish Joshi, SynOptics Mark Kepke, Hewlett-Packard Ken Key, SNMP Research, Inc. Michael Kornegay, Visisoft Deidre C. Kostick, Bellcore Cheryl Krupczak, Georgia Tech Robert C. Lushbaugh, Martin Marietta Energy Systems Keith McCloghrie, Hughes LAN Systems Dave Minnich, FiberCom Dave Perkins, SynOptics Marshall T. Rose, Dover Beach Consulting, Inc. Shawn A. Routhier, Epilogue Technology Jon Saperia, Digital Equipment Corporation Bob Stewart, Xyplex (chair) Robert Synder, Cisco Systems Maurice Turcotte, Racal Datacom Expires May 12, 1993 [Page 16] Draft Transport Mappings for SNMPv2 Oct 92 Steven L. Waldbusser, Carnegie Mellon University Bert Wijnen, International Business Machines Peter Wilson, 3Com Steven Wong, Digital Equipment Corporation Chris Young, Cabletron Kiho Yum, 3Com Expires May 12, 1993 [Page 17] Draft Transport Mappings for SNMPv2 Oct 92 13. References [1] J.B. Postel, User Datagram Protocol, Request for Comments 768. (August, 1980). [2] Information processing systems - Open Systems Interconnection - Transport Service Definition, International Organization for Standardization. International Standard 8072, (June, 1986). [3] 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). [4] Network System Technical Interface Overview. Novell, Inc, (June, 1989). [5] G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second edition). Addison-Wesley, 1990. [6] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol. Request for Comments 1157, (May, 1990). [7] K. McCloghrie, J.R. Davin, J.M. Galvin, Definitions of Managed Objects for Administration of SNMP Parties. Request for Comments 1353, (July, 1992). [8] 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). [9] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2), Internet-Draft, (October 7, 1992). Expires May 12, 1993 [Page 18] Draft Transport Mappings for SNMPv2 Oct 92 Table of Contents 1 Status of this Memo ................................... 1 2 Introduction .......................................... 2 2.1 A Note on Terminology ............................... 2 3 Definitions ........................................... 3 4 SNMPv2 over UDP ....................................... 7 4.1 Serialization ....................................... 7 4.2 Well-known Values ................................... 7 5 SNMPv2 over OSI ....................................... 8 5.1 Serialization ....................................... 8 5.2 Well-known Values ................................... 8 6 SNMPv2 over DDP ....................................... 9 6.1 Serialization ....................................... 9 6.2 Well-known Values ................................... 9 7 SNMPv2 over IPX ....................................... 10 7.1 Serialization ....................................... 10 7.2 Well-known Values ................................... 10 8 Restart Domain ........................................ 11 8.1 Usage ............................................... 11 9 Entity Domain ......................................... 12 9.1 Usage ............................................... 12 10 Proxy to SNMPv1 ...................................... 13 10.1 Transport Domain: rfc1157Domain .................... 13 10.2 Authentication Algorithm: rfc1157noAuth ............ 13 11 Serialization using the Basic Encoding Rules ......... 14 11.1 Usage Example ...................................... 15 12 Acknowledgements ..................................... 16 13 References ........................................... 18 Expires May 12, 1993 [Page 19]