Network Working Group J. Schoenwaelder
Internet-Draft TU Braunschweig
Expires: October 26, 2000 April 27, 2000
SNMP over TCP Transport Mapping
draft-irtf-nmrg-snmp-tcp-04.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/iid-abstracts.txt
This Internet-Draft will expire on October 26, 2000.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This memo defines a transport mapping for using the Simple Network
Management Protocol (SNMP) over TCP. The transport mapping can be
used with any version of SNMP. This document extends the transport
mappings defined in RFC 1906.
Schoenwaelder Expires October 26, 2000 [Page 1]
Internet-Draft TCs for Internet Network Addresses April 2000
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SNMP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Serialization . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Well-Known Values . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Connection Management . . . . . . . . . . . . . . . . . . . . 5
3.4 Reliable Transport versus Confirmed Operations . . . . . . . . 5
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
Schoenwaelder Expires October 26, 2000 [Page 2]
Internet-Draft TCs for Internet Network Addresses April 2000
1. Introduction
This memo defines a transport mapping for using the Simple Network
Management Protocol (SNMP) over TCP. The transport mapping can be
used with any version of SNMP [2]. This document extends the
transport mappings defined in RFC 1906 [4].
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 [3].
2. Definitions
IRTF-NMRG-SNMP-TM DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, experimental FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
nmrgSnmpDomains MODULE-IDENTITY
LAST-UPDATED "200004031800Z"
ORGANIZATION "IRTF Network Management Research Group"
CONTACT-INFO
"Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3283
Email: schoenw@ibr.cs.tu-bs.de"
DESCRIPTION
"This MIB module defines the SNMP over TCP transport mapping."
REVISION "200004031800Z"
DESCRIPTION
"Initial version, published as RFC XXXX."
::= { experimental nmrg(91) 1 }
-- SNMP over TCP over IPv4
snmpTCPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over TCP over IPv4 transport domain. The
corresponding transport address is of type SnmpTCPAddress."
::= { nmrgSnmpDomains 1 }
SnmpTCPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
Schoenwaelder Expires October 26, 2000 [Page 3]
Internet-Draft TCs for Internet Network Addresses April 2000
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
SNMP over TCP is an optional transport mapping. Implementors are
encouraged to support SNMP over TCP whenever possible because this
enables applications to make more efficient bulk transfers of MIB
data [7].
The originator of a request/response transaction chooses the
transport protocol for the entire transaction. The transport
protocol MUST NOT change during a transaction.
In general, originators of request/response transactions are free to
use the transport they assume is the best in a given situation.
However, as TCP has a larger footprint on resource usage than UDP,
applications using SNMP over TCP may choose to switch back to UDP by
refusing new TCP connections whenever necessary (e.g. too many open
TCP connections).
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 [4].
The BER-encoded message is then sent over a TCP connection.
It is possible to exchange multiple SNMP request/response pairs over
a single (persistent) TCP connection. The length field in the
BER-encoded SNMP message is used to separate multiple requests sent
over a single TCP connection.
3.2 Well-Known Values
It is RECOMMENDED that administrators configure their SNMP entities
containing command responders to listen on TCP port 161 for incoming
connections. It is also RECOMMENDED that SNMP entities containing
notification receivers be configured to listen on TCP port 162 for
connection requests.
When an SNMP entity uses the TCP transport mapping, it MUST be
Schoenwaelder Expires October 26, 2000 [Page 4]
Internet-Draft TCs for Internet Network Addresses April 2000
capable of accepting messages that are at least 8192 octets in size.
Implementation of larger values is encouraged whenever possible.
3.3 Connection Management
The use of TCP connections introduces costs [5]. Connection
establishment and teardown cause additional network traffic.
Furthermore, maintaining open connections binds resources in the
network layer of the underlying operating system.
SNMP over TCP is intended to be used when the size of the
transferred data is large since TCP offers flow control and
efficient segmentation. The transport of SNMP messages over UDP
requires to transfer large amounts of data with small-sized SNMP
over UDP messages, which causes latency to increase excessively.
Another advantage of using TCP connections is that it is not
necessary to implement retransmissions at the application level.
This may result in simpler management applications.
All SNMP entities (whether in an agent role or manager role) can
close TCP connections at any point in time. This ensures that SNMP
entities can control their resource usage and shut down TCP
connections that are not used. However, SNMP engines MUST NOT
discard SNMP requests if only the incoming half of the TCP
connection is closed.
The processing of any outstanding SNMP requests when both halfs of
the TCP connection have been closed is implementation dependent. The
sending SNMP entity SHOULD therefore not assume anything about the
processing of outstanding SNMP requests once a TCP connection is
closed.
A `noResponse' error condition SHOULD be signalled for outstanding
requests for command generator applications if the TCP connection is
closed before a response has been received.
3.4 Reliable Transport versus Confirmed Operations
The transport of SNMP messages over TCP results in a reliable
exchange of SNMP messages between SNMP engines. TCP guarantees that
the delivered data is not damaged, lost, duplicated, or delivered
out of order [6].
The SNMP protocol has been designed to support confirmed as well as
unconfirmed operations [1]. The InformRequest-PDU protocol operation
is an example for a confirmed operation while the Trapv2-PDU
operation is an example for an unconfirmed operation.
Schoenwaelder Expires October 26, 2000 [Page 5]
Internet-Draft TCs for Internet Network Addresses April 2000
There is an important difference between an unconfirmed protocol
operation sent over a reliable transport and a confirmed protocol
operation. A reliable transport such as TCP only ensures to deliver
data to the receiving application process. It does not guarantee
that the data was actually processed by the application process.
A confirmed operation indicates that the data was actually delivered
and processed by the receiving application process. For example, the
response to an InformRequest-PDU protocol operation indicates to the
notification originator that the data passed the transport and the
authentication mechanism on the notification receiver side.
Similarily, the response to a SetRequest-PDU indicates that the data
passed the transport, the authentication mechanism and that the
write request was processed by the command responder.
A reliable transport is thus only a poor approximation for confirmed
operations. Applications that need confirmed delivery of
notifications are thus encouraged to use the confirmed
InformRequest-PDU rather than just sending unconfirmed traps over a
reliable transport.
4. Acknowledgments
This document is the result of discussions within the Network
Management Research Group (NMRG) of the Internet Research Task
Force[8] (IRTF). Special thanks go to Luca Deri, Jean-Philippe
Martin-Flatin, Aiko Pras, Ron Sprenkels, and Bert Wijnen for their
comments and suggestions.
Additional thanks go to Luca Deri, Wes Hardaker, Bert Helthuis, and
Erik Schoenfelder for their prototype implementations. The SNMP over
TCP transport mapping is integrated in the current UCD SNMP
package[9] and the current Linux CMU SNMP package[10].
References
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[2] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
to Version 3 of the Internet-standard Network Management
Framework", RFC 2570, April 1999.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
Schoenwaelder Expires October 26, 2000 [Page 6]
Internet-Draft TCs for Internet Network Addresses April 2000
[5] Kastenholz, F., "SNMP Communications Services", RFC 1270,
October 1991.
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[7] Sprenkels, R. and J.P. Martin-Flatin, "Bulk Transfers of MIB
Data", Simple Times 7(1), March 1999.
[8] http://www.irtf.org/
[9] http://ucd-snmp.ucdavis.edu/
[10] http://www.gaertner.de/snmp/
Author's Address
Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3289
EMail: schoenw@ibr.cs.tu-bs.de
Schoenwaelder Expires October 26, 2000 [Page 7]
Internet-Draft TCs for Internet Network Addresses April 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Schoenwaelder Expires October 26, 2000 [Page 8]