Draft Transport Mappings for SNMPv2 Dec 92 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) Tue Dec 22 13:43:46 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 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 June 22, 1993 [Page 1] Draft Transport Mappings for SNMPv2 Dec 92 1. Introduction A network 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 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 [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, 1157, and 1212, is termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 2 framework (SNMPv2). Expires June 22, 1993 [Page 2] Draft Transport Mappings for SNMPv2 Dec 92 2. 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 a 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." SYNTAX OCTET STRING (SIZE (6)) Expires June 22, 1993 [Page 3] Draft Transport Mappings for SNMPv2 Dec 92 -- SNMPv2 over OSI snmpCLNSDomain OBJECT IDENTIFIER ::= { snmpDomains 2 } snmpCONSDomain OBJECT IDENTIFIER ::= { snmpDomains 3 } -- for a 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." SYNTAX OCTET STRING (SIZE (1 | 4..85)) -- SNMPv2 over DDP snmpDDPDomain OBJECT IDENTIFIER ::= { snmpDomains 4 } -- for a 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." SYNTAX OCTET STRING (SIZE (3..65)) Expires June 22, 1993 [Page 4] Draft Transport Mappings for SNMPv2 Dec 92 -- SNMPv2 over IPX snmpIPXDomain OBJECT IDENTIFIER ::= { snmpDomains 5 } -- for a 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." SYNTAX 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." SYNTAX 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)." SYNTAX DisplayString Expires June 22, 1993 [Page 5] Draft Transport Mappings for SNMPv2 Dec 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 June 22, 1993 [Page 6] Draft Transport Mappings for SNMPv2 Dec 92 3. SNMPv2 over UDP This is the preferred transport mapping. 3.1. Serialization Each instance of a message is serialized onto a single UDP[2] datagram, using the algorithm specified in Section 10. 3.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 notification 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 June 22, 1993 [Page 7] Draft Transport Mappings for SNMPv2 Dec 92 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 10. 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 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) 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. 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 June 22, 1993 [Page 8] Draft Transport Mappings for SNMPv2 Dec 92 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 10. 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 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 notification 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 June 22, 1993 [Page 9] Draft Transport Mappings for SNMPv2 Dec 92 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 [6], using the algorithm specified in Section 10. 6.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 notification 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 June 22, 1993 [Page 10] Draft Transport Mappings for SNMPv2 Dec 92 7. Restart Domain This is an optional transport mapping. 7.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 June 22, 1993 [Page 11] Draft Transport Mappings for SNMPv2 Dec 92 8. Entity Domain This is an optional transport mapping. 8.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 June 22, 1993 [Page 12] Draft Transport Mappings for SNMPv2 Dec 92 9. Proxy to SNMPv1 In order to provide proxy to community-based SNMP [7], some definitions are necessary for both transport domains and authentication protocols. 9.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. 9.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 [8] still apply. Expires June 22, 1993 [Page 13] Draft Transport Mappings for SNMPv2 Dec 92 10. Serialization using the Basic Encoding Rules When the Basic Encoding Rules [9] 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 June 22, 1993 [Page 14] Draft Transport Mappings for SNMPv2 Dec 92 10.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.) Expires June 22, 1993 [Page 15] Draft Transport Mappings for SNMPv2 Dec 92 11. 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: Beth Adams, Network Management Forum Steve Alexander, INTERACTIVE Systems Corporation David Arneson, Cabletron Systems Toshiya Asaba, Fred Baker, ACC Jim Barnes, Xylogics, Inc. Brian Bataille Andy Bierman, SynOptics Communications, Inc. Uri Blumenthal, IBM Corporation Fred Bohle, Interlink Jack Brown Theodore Brunner, Bellcore Stephen F. Bush, GE Information Services Deirdre C. Kostik, Bellcore Jeff Case, University of Tennessee, Knoxville John Chang, IBM Corporation Szusin Chen, Sun Microsystems Robert Ching Chris Chiotasso, Ungermann-Bass Bobby A. Clay, NASA/Boeing John Cooke, Chipcom Tracy Cox, Bellcore Juan Cruz, Datability, Inc. David Cullerot, Cabletron Systems Cathy Cunningham, Microcom James R. (Chuck) Davin, Bellcore Expires June 22, 1993 [Page 16] Draft Transport Mappings for SNMPv2 Dec 92 Michael Davis, Clearpoint Mike Davison, FiberCom Cynthia DellaTorre, MITRE Taso N. Devetzis, Bellcore Manual Diaz, DAVID Systems, Inc. Jon Dreyer, Sun Microsystems Susan E. Hicks, Martin Marietta Energy Systems David Engel, Optical Data Systems Mike Erlinger, Lexcel Roger Fajman, NIH Daniel Fauvarque, Sun Microsystems Karen Frisa, CMU Shari Galitzer, MITRE Shawn Gallagher, Digital Equipment Corporation Richard Graveman, Bellcore Maria Greene, Xyplex, Inc. Michel Guittet, Apple Robert Gutierrez, NASA Bill Hagerty, Cabletron Systems Gary W. Haney, Martin Marietta Energy Systems Patrick Hanil, Nokia Telecommunications Matt Hecht, SNMP Research, Inc. Edward A. Heiner, Jr., Synernetics Inc. Geral Holzhauer, Apple John Hopprich, DAVID Systems, Inc. Jeff Hughes, Hewlett-Packard Robin Iddon, Axon Networks, Inc. David Itusak Kevin M. Jackson, Concord Communications, Inc. Ole J. Jacobsen, Interop Company Ronald Jacoby, Silicon Graphics, Inc. Satish Joshi, SynOptics Communications, Inc. Frank Kastenholz, FTP Software Mark Kepke, Hewlett-Packard Ken Key, SNMP Research, Inc. Zbiginew Kielczewski, Eicon Jongyeoi Kim Andrew Knutsen, The Santa Cruz Operation Michael L Kornegay, VisiSoft Cheryl Krupczak, Georgia Tech Steven L. Waldbusser, Carnegie Mellon Universitty Mark S. Lewis, Telebit David Lin David Lindemulder, AT&T/NCR Ben Lisowski, Sprint Expires June 22, 1993 [Page 17] Draft Transport Mappings for SNMPv2 Dec 92 David Liu, Bell-Northern Research John Lunny, The Wollongong Group Robert C. Lushbaugh Martin, Marietta Energy Systems Michael Luufer, BBN Carl Madison, Star-Tek, Inc. Keith McCloghrie, Hughes LAN Systems Evan McGinnis, 3Com Corporation Bill McKenzie, IBM Corporation Donna McMaster, SynOptics Communications, Inc. John Medicke, IBM Corporation Doug Miller, Telebit Dave Minnich, FiberCom Mohammad Mirhakkak, MITRE Rohit Mital, Protools George Mouradian, AT&T Bell Labs Patrick Mullaney, Cabletron Systems Dan Myers, 3Com Corporation Rina Nathaniel, Rad Network Devices Ltd. Hien V. Nguyen, Sprint Mo Nikain Tom Nisbet William B. Norton, MERIT Steve Onishi, Wellfleet Communications, Inc. David T. Perkins, SynOptics Communications, Inc. Carl Powell, BBN Ilan Raab, SynOptics Communications, Inc. RIchard Ramons, AT&T Venkat D. Rangan, Metric Network Systems, Inc. Louise Reingold, Sprint Sam Roberts, Farallon Computing, Inc. Kary Robertson, Concord Communications, Inc. Dan Romascanu, Lannet Data Communications Ltd. Marshall T. Rose, Dover Beach Consulting, Inc. Shawn A. Routhier, Epilogue Technology Corporation Chris Rozman Asaf Rubissa, Fibronics Jon Saperia, Digital Equipment Corporation Michael Sapich Mike Scanlon, Interlan Sam Schaen, MITRE John Seligson, Ultra Network Technologies Paul A. Serice, Corporation for Open Systems Chris Shaw, Banyan Systems Timon Sloane Robert Snyder, Cisco Systems Expires June 22, 1993 [Page 18] Draft Transport Mappings for SNMPv2 Dec 92 Joo Young Song Roy Spitier, Sprint Einar Stefferud, Network Management Associates John Stephens, Cayman Systems, Inc. Bob Stewart, Xyplex, Inc. (chair) Kaj Tesink, Bellcore Dean Throop, Data General Ahmet Tuncay, France Telecom-CNET Maurice Turcotte, Racal Datacom Warren Vik, INTERACTIVE Systems Corporation Yannis Viniotis Steve Waldbusser, CMU Timothy M. Walden, ACC Alice Wang, Sun Microsystems James Watt, Newbridge Luanne Waul, Timeplex Donald E. Westlake III, Digital Equipment Corporation Gerry White Bert Wijnen, IBM Corporation Peter Wilson, 3Com Corporation Steven Wong, Digital Equipment Corporation Randy Worzella, IBM Corporation Daniel Woycke, MITRE Honda Wu Jeff Yarnell, Protools Chris Young, Cabletron Kiho Yum, 3Com Corporation Expires June 22, 1993 [Page 19] Draft Transport Mappings for SNMPv2 Dec 92 12. References [1] 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, (December | 22, 1992). | [2] J.B. Postel, User Datagram Protocol, Request for Comments 768. (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] Network System Technical Interface Overview. Novell, + Inc, (June, 1989). + [7] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol. Request for Comments 1157, (May, 1990). [8] K. McCloghrie, J.R. Davin, J.M. Galvin, Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2). Internet-Draft, (December 22, 1992). | [9] 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). Expires June 22, 1993 [Page 20] Draft Transport Mappings for SNMPv2 Dec 92 Table of Contents 1 Introduction .......................................... 2 1.1 A Note on Terminology ............................... 2 2 Definitions ........................................... 3 3 SNMPv2 over UDP ....................................... 7 3.1 Serialization ....................................... 7 3.2 Well-known Values ................................... 7 4 SNMPv2 over OSI ....................................... 8 4.1 Serialization ....................................... 8 4.2 Well-known Values ................................... 8 5 SNMPv2 over DDP ....................................... 9 5.1 Serialization ....................................... 9 5.2 Well-known Values ................................... 9 6 SNMPv2 over IPX ....................................... 10 6.1 Serialization ....................................... 10 6.2 Well-known Values ................................... 10 7 Restart Domain ........................................ 11 7.1 Usage ............................................... 11 8 Entity Domain ......................................... 12 8.1 Usage ............................................... 12 9 Proxy to SNMPv1 ....................................... 13 9.1 Transport Domain: rfc1157Domain ..................... 13 9.2 Authentication Algorithm: rfc1157noAuth ............. 13 10 Serialization using the Basic Encoding Rules ......... 14 10.1 Usage Example ...................................... 15 11 Acknowledgements ..................................... 16 12 References ........................................... 20 Expires June 22, 1993 [Page 21]