Juergen Schoenwaelder BEAM Internal Draft TU Braunschweig Expires July 1999 19 January 1999 Transport Mappings for SNMP Extension 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 draft documents 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 ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the BEAM Working Group, . Abstract This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping defined in this memo can be used with any version of SNMP. J. Schoenwaelder [Page 1] Internet-Draft TCP Transport Mappings for SNMP January 1999 Table of Contents 1 Introduction ................................................. 2 2 Definitions .................................................. 2 3 SNMP over TCP ................................................ 3 3.1 Serialization .............................................. 3 3.2 Well-known Values .......................................... 3 3.3 Connection Management ...................................... 3 4 Acknowledgments .............................................. 4 5 Authors' Address ............................................. 4 1. Introduction This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping defined in this memo can be used with any version of SNMP. This document extends the transport mappings defined in RFC 1906. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Definitions SNMPv2-TM-EXT-01 DEFINITIONS ::= BEGIN IMPORTS OBJECT-IDENTITY, snmpDomains FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; -- This module is not valid SMIv2. The author left out all the -- administrative stuff in order to keep it small. -- SNMP over TCP over IPv4 snmpTCPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over TCP/IPv4 transport domain. The corresponding transport address is of type SnmpTCPAddress." ::= { snmpDomains 6 } SnmpTCPAddress ::= TEXTUAL-CONVENTION J. Schoenwaelder [Page 2] Internet-Draft TCP Transport Mappings for SNMP January 1999 DISPLAY-HINT "1d.1d.1d.1d/2d" STATUS current DESCRIPTION "Represents a TCP/IPv4 address: octets contents encoding 1-4 IP-address network-byte order 5-6 TCP-port network-byte order " SYNTAX OCTET STRING (SIZE (6)) END 3. SNMP over TCP This is an optional transport mapping. However, implementors are encouraged to support SNMP over TCP whenever possible because this enables applications to use more efficient MIB data transfers. 3.1. Serialization Each instance of a message is serialized into a single BER encoded message, using the algorithm specified in Section 8 of RFC 1906. The BER encoded message is then send over a TCP connection. Note, it is possible to exchange multiple SNMP request/response pairs over a single TCP connection. The length field in the BER encoded SNMP message should be used to separate multiple requests send over a single TCP connection. 3.2. Well-known Values It is suggested that administrators configure their SNMP entities acting in an agent role to listen on TCP port 161 for incoming connections. Further, it is suggested that notification sinks be configured to listen on TCP port 162. 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. J. Schoenwaelder [Page 3] Internet-Draft TCP Transport Mappings for SNMP January 1999 3.3. Connection Management The use of TCP connections introduces costs. Connection establishment and shutdown causes additional traffic on the wire. Further, maintaining open connections binds resources in the network layer of the underlying operating system. TCP connections should therefore only be used when the size of the data transferred would otherwise cause large latencies due to small UDP packet sizes and an increased number of interactions. Both, an SNMP entity in the agent role and an SNMP entity in the manager role, are allowed to close the connections at any point in time. This makes sure that SNMP entities can control their resource usage and shutdown TCP connections that are not used. Note, SNMP engines are not expected to process any outstanding requests if the underlying TCP connection has been closed. A no response error condition SHOULD be signalled for outstanding requests for command generator applications if the TCP connection is closed. 4. Acknowledgments The definitions in this memo are inspired by definitions found in RFC 1906. This document is the result of an ad-hoc meeting by the BEAM working group. The author likes to thank the participants for their contributions: Luca Deri, Jean-Philippe Martin-Flatin, Aiko Pras, Ron Sprenkels, Bert Wijnen 5. Authors' Address Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de TU Braunschweig Tel: +49 531 391-3283 Bueltenweg 74/75 38106 Braunschweig Germany J. Schoenwaelder [Page 4] Internet-Draft TCP Transport Mappings for SNMP January 1999