idnits 2.17.1 draft-irtf-nmrg-snmp-tcp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 108 has weird spacing: '... octets cont...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 5, 2000) is 8786 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2571 (ref. '1') (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2570 (ref. '2') (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 1906 (ref. '4') (Obsoleted by RFC 3417) ** Downref: Normative reference to an Informational RFC: RFC 1270 (ref. '5') ** Obsolete normative reference: RFC 793 (ref. '6') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Schoenwaelder 2 Internet-Draft TU Braunschweig 3 Expires: October 4, 2000 April 5, 2000 5 SNMP over TCP Transport Mapping 6 draft-irtf-nmrg-snmp-tcp-03.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of Internet-Draft Shadow Directories, see 24 http://www.ietf.org/shadow.html. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/iid-abstracts.txt 29 This Internet-Draft will expire on October 4, 2000. 31 Copyright Notice 33 Copyright (C) The Internet Society (2000). All Rights Reserved. 35 Abstract 37 This memo defines a transport mapping for using the Simple Network 38 Management Protocol (SNMP) over TCP. The transport mapping can be 39 used with any version of SNMP. This document extends the transport 40 mappings defined in RFC 1906. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 3. SNMP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3.1 Serialization . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3.2 Well-Known Values . . . . . . . . . . . . . . . . . . . . . . 4 49 3.3 Connection Management . . . . . . . . . . . . . . . . . . . . 5 50 3.4 Reliable Transport versus Confirmed Operations . . . . . . . . 5 51 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 52 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 54 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8 56 1. Introduction 58 This memo defines a transport mapping for using the Simple Network 59 Management Protocol (SNMP) over TCP. The transport mapping can be 60 used with any version of SNMP [2]. This document extends the 61 transport mappings defined in RFC 1906 [4]. 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [3]. 67 2. Definitions 69 IRTF-NMRG-SNMP-TM DEFINITIONS ::= BEGIN 71 IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, experimental FROM SNMPv2-SMI 72 TEXTUAL-CONVENTION FROM SNMPv2-TC; 74 nmrgSnmpDomains MODULE-IDENTITY 75 LAST-UPDATED "200004031800Z" 76 ORGANIZATION "IRTF Network Management Research Group" 77 CONTACT-INFO 78 "Juergen Schoenwaelder 79 TU Braunschweig 80 Bueltenweg 74/75 81 38106 Braunschweig 82 Germany 84 Phone: +49 531 391-3283 85 Email: schoenw@ibr.cs.tu-bs.de" 86 DESCRIPTION 87 "This MIB module defines the SNMP over TCP transport mapping." 88 REVISION "200004031800Z" 89 DESCRIPTION 90 "Initial version, published as RFC XXXX." 91 ::= { experimental nmrg(91) 1 } 93 -- SNMP over TCP over IPv4 95 snmpTCPDomain OBJECT-IDENTITY 96 STATUS current 97 DESCRIPTION 98 "The SNMP over TCP over IPv4 transport domain. The 99 corresponding transport address is of type SnmpTCPAddress." 100 ::= { nmrgSnmpDomains 1 } 102 SnmpTCPAddress ::= TEXTUAL-CONVENTION 103 DISPLAY-HINT "1d.1d.1d.1d/2d" 104 STATUS current 105 DESCRIPTION 106 "Represents a TCP/IPv4 address: 108 octets contents encoding 109 1-4 IP-address network-byte order 110 5-6 TCP-port network-byte order 111 " 112 SYNTAX OCTET STRING (SIZE (6)) 114 END 116 3. SNMP over TCP 118 SNMP over TCP is an optional transport mapping. Implementors are 119 encouraged to support SNMP over TCP whenever possible because this 120 enables applications to make more efficient bulk transfers of MIB 121 data [7]. 123 The originator of a request/response transaction chooses the 124 transport protocol for the entire transaction. The transport 125 protocol MUST NOT change during a transaction. 127 In general, originators of request/response transactions are free to 128 use the transport they assume is the best in a given situation. 129 However, as TCP has a larger footprint on resource usage than UDP, 130 applications using SNMP over TCP may choose to switch back to UDP by 131 refusing new TCP connections whenever necessary (e.g. too many open 132 TCP connections). 134 3.1 Serialization 136 Each instance of a message is serialized into a single BER-encoded 137 message, using the algorithm specified in Section 8 of RFC 1906 [4]. 138 The BER-encoded message is then sent over a TCP connection. 140 It is possible to exchange multiple SNMP request/response pairs over 141 a single (persistent) TCP connection. The length field in the 142 BER-encoded SNMP message is used to separate multiple requests sent 143 over a single TCP connection. 145 3.2 Well-Known Values 147 It is RECOMMENDED that administrators configure their SNMP entities 148 containing command responders to listen on TCP port 161 for incoming 149 connections. It is also RECOMMENDED that SNMP entities containing 150 notification receivers be configured to listen on TCP port 162 for 151 connection requests. 153 When an SNMP entity uses the TCP transport mapping, it MUST be 154 capable of accepting messages that are at least 8192 octets in size. 155 Implementation of larger values is encouraged whenever possible. 157 3.3 Connection Management 159 The use of TCP connections introduces costs [5]. Connection 160 establishment and teardown cause additional network traffic. 161 Furthermore, maintaining open connections binds resources in the 162 network layer of the underlying operating system. 164 SNMP over TCP is intended to be used when the size of the 165 transferred data is large since TCP offers flow control and 166 efficient segmentation. The transport of SNMP messages over UDP 167 requires to transfer large amounts of data with small-sized SNMP 168 over UDP messages, which causes latency to increase excessively. 170 Another advantage of using TCP connections is that it is not 171 necessary to implement retransmissions at the application level. 172 This may result in simpler management applications. 174 All SNMP entities (whether in an agent role or manager role) can 175 close TCP connections at any point in time. This ensures that SNMP 176 entities can control their resource usage and shut down TCP 177 connections that are not used. However, SNMP engines MUST NOT 178 discard SNMP requests if only the incoming half of the TCP 179 connection is closed. 181 The processing of any outstanding SNMP requests when both halfs of 182 the TCP connection have been closed is implementation dependent. The 183 sending SNMP entity SHOULD therefore not assume anything about the 184 processing of outstanding SNMP requests once a TCP connection is 185 closed. 187 A `noResponse' error condition SHOULD be signalled for outstanding 188 requests for command generator applications if the TCP connection is 189 closed before a response has been received. 191 3.4 Reliable Transport versus Confirmed Operations 193 The transport of SNMP messages over TCP results in a reliable 194 exchange of SNMP messages between SNMP engines. TCP guarantees that 195 the delivered data is not damaged, lost, duplicated, or delivered 196 out of order [6]. 198 The SNMP protocol has been designed to support confirmed as well as 199 unconfirmed operations [1]. The InformRequest-PDU protocol operation 200 is an example for a confirmed operation while the Trapv2-PDU 201 operation is an example for an unconfirmed operation. 203 There is an important difference between an unconfirmed protocol 204 operation send over a reliable transport and a confirmed protocol 205 operation. A reliable transport such as TCP only ensures to deliver 206 data to the receiving application process. It does not guarantee 207 that the data was actually processed by the application process. 209 A confirmed operation indicates that the data was actually delivered 210 and processed by the receiving application process. For example, the 211 response to an InformRequest-PDU protocol operation indicates to the 212 notification originator that the data passed the transport and the 213 authentication mechanism on the notification receiver side. 214 Similarily, the response to a SetRequest-PDU indicates that the data 215 passed the transport, the authentication mechanism and that the 216 write request was processed by the command responder. 218 A reliable transport is thus only a poor approximation for confirmed 219 operations. Applications that need confirmed delivery of 220 notifications are thus encouraged to use the confirmed 221 InformRequest-PDU rather than just sending unconfirmed traps over a 222 reliable transport. 224 4. Acknowledgments 226 This document is the result of discussions within the Network 227 Management Research Group (NMRG) of the Internet Research Task 228 Force[8] (IRTF). Special thanks go to Luca Deri, Jean-Philippe 229 Martin-Flatin, Aiko Pras, Ron Sprenkels, and Bert Wijnen for their 230 comments and suggestions. 232 Additional thanks go to Wes Hardaker and Erik Schoenfelder for 233 implementing the proposed SNMP over TCP transport mapping in the UCD 234 SNMP package[9] and the Linux CMU SNMP package[10]. 236 References 238 [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 239 Describing SNMP Management Frameworks", RFC 2571, April 1999. 241 [2] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 242 to Version 3 of the Internet-standard Network Management 243 Framework", RFC 2570, April 1999. 245 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 246 Levels", BCP 14, RFC 2119, March 1997. 248 [4] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 249 "Transport Mappings for Version 2 of the Simple Network 250 Management Protocol (SNMPv2)", RFC 1906, January 1996. 252 [5] Kastenholz, F., "SNMP Communications Services", RFC 1270, 253 October 1991. 255 [6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 256 September 1981. 258 [7] Sprenkels, R. and J.P. Martin-Flatin, "Bulk Transfers of MIB 259 Data", Simple Times 7(1), March 1999. 261 [8] http://www.irtf.org/ 263 [9] http://ucd-snmp.ucdavis.edu/ 265 [10] http://www.gaertner.de/snmp/ 267 Author's Address 269 Juergen Schoenwaelder 270 TU Braunschweig 271 Bueltenweg 74/75 272 38106 Braunschweig 273 Germany 275 Phone: +49 531 391-3289 276 EMail: schoenw@ibr.cs.tu-bs.de 278 Full Copyright Statement 280 Copyright (C) The Internet Society (2000). All Rights Reserved. 282 This document and translations of it may be copied and furnished to 283 others, and derivative works that comment on or otherwise explain it 284 or assist in its implmentation may be prepared, copied, published 285 and distributed, in whole or in part, without restriction of any 286 kind, provided that the above copyright notice and this paragraph 287 are included on all such copies and derivative works. However, this 288 document itself may not be modified in any way, such as by removing 289 the copyright notice or references to the Internet Society or other 290 Internet organizations, except as needed for the purpose of 291 developing Internet standards in which case the procedures for 292 copyrights defined in the Internet Standards process must be 293 followed, or as required to translate it into languages other than 294 English. 296 The limited permissions granted above are perpetual and will not be 297 revoked by the Internet Society or its successors or assigns. 299 This document and the information contained herein is provided on an 300 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 301 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 302 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 303 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 304 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 306 Acknowledgement 308 Funding for the RFC editor function is currently provided by the 309 Internet Society.