idnits 2.17.1 draft-irtf-nmrg-snmp-tcp-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 is 1 instance 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 (10 June 1999) is 9058 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 1906 (ref. '1') (Obsoleted by RFC 3417) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder, Editor 3 Internet-Draft TU Braunschweig 4 Expires December 1999 10 June 1999 6 SNMP-over-TCP Transport Mapping 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Distribution of this document is unlimited. Please send comments to 30 the Network Management Research Group, . 32 Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 Abstract 38 This memo defines a transport mapping for using the Simple Network 39 Management Protocol (SNMP) over TCP. The transport mapping defined in 40 this memo can be used with any version of SNMP. 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 4 Acknowledgments .............................................. 5 51 5 References ................................................... 6 52 6 Editor's Address ............................................. 6 53 7 Full Copyright Statement ..................................... 7 55 1. Introduction 57 This memo defines a transport mapping for using the Simple Network 58 Management Protocol (SNMP) over TCP. The transport mapping defined in 59 this memo can be used with any version of SNMP. This document extends 60 the transport mappings defined in RFC 1906 [1]. 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [2]. 66 2. Definitions 68 IRTF-NMRG-SNMP-TM DEFINITIONS ::= BEGIN 70 IMPORTS 71 MODULE-IDENTITY, OBJECT-IDENTITY, experimental 72 FROM SNMPv2-SMI 73 TEXTUAL-CONVENTION 74 FROM SNMPv2-TC; 76 nmrgSnmpDomains MODULE-IDENTITY 77 LAST-UPDATED "9906101100Z" 78 ORGANIZATION "IRTF Network Management Research Group" 79 CONTACT-INFO 80 "Juergen Schoenwaelder 81 TU Braunschweig 82 Bueltenweg 74/75 83 38106 Braunschweig 84 Germany 86 Phone: +49 531 391-3283 87 Email: schoenw@ibr.cs.tu-bs.de" 88 DESCRIPTION 89 "This MIB module defines the SNMP-over-TCP transport mapping." 90 ::= { experimental nmrg(91) 1 } 92 -- SNMP over TCP over IPv4 94 snmpTCPDomain OBJECT-IDENTITY 95 STATUS current 96 DESCRIPTION 97 "The SNMP-over-TCP-over-IPv4 transport domain. The 98 corresponding transport address is of type SnmpTCPAddress." 99 ::= { nmrgSnmpDomains 6 } -- matches first unused value 100 -- below snmpDomains 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 [3]. 123 The originator of a request/response transaction chooses the 124 transport protocol for the entire transaction. The transport protocol 125 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 [1]. 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 BER- 142 encoded SNMP message is used to separate multiple requests sent over 143 a single TCP connection. 145 3.2. Well-Known Values 147 It is RECOMMENDED that administrators configure their SNMP entities 148 containing command generators 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. Connection establishment 160 and teardown cause additional network traffic. Furthermore, 161 maintaining open connections binds resources in the network layer of 162 the underlying operating system. 164 TCP connections are intended to be used when the size of the 165 transferred data is large. If a connectionless transport were used 166 instead, its small packet-size constraint would cause latency to 167 increase excessively. 169 Another advantage of using TCP connections, regardless of the message 170 size, is that you do not need to implement retransmissions at the 171 application level. This may result in simpler management 172 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. SNMP engines SHOULD NOT process any 178 outstanding requests if the underlying TCP connection has been 179 closed. A `noResponse' error condition SHOULD be signalled for 180 outstanding requests for command generator applications if the TCP 181 connection is closed before a response has been received. 183 4. Acknowledgments 185 The definitions in this memo are inspired by definitions found in RFC 186 1906 [1]. This document is the result of discussions of the Network 187 Management Research Group (NMRG). Special thanks go to the following 188 participants for their comments and contributions: 190 Luca Deri, Jean-Philippe Martin-Flatin, Aiko Pras, Ron Sprenkels, 191 Bert Wijnen. 193 5. References 195 [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 196 "Transport Mappings for Version 2 of the Simple Network 197 Management Protocol (SNMPv2)", RFC 1906, January 1996. 199 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 200 Levels", BCP 14, RFC 2119, March 1997. 202 [3] Sprenkels, R., and J.P. Martin-Flatin, "Bulk Transfers of MIB 203 Data", The Simple Times, Vol. 7, No. 1, pp. 1-7, March 1999. 205 6. Editor's Address 207 Juergen Schoenwaelder 208 TU Braunschweig 209 Bueltenweg 74/75 210 38106 Braunschweig 211 Germany 213 Phone: +49 531 391-3283 214 EMail: schoenw@ibr.cs.tu-bs.de 216 7. Full Copyright Statement 218 Copyright (C) The Internet Society (1999). All Rights Reserved. 220 This document and translations of it may be copied and furnished to 221 others, and derivative works that comment on or otherwise explain it 222 or assist in its implementation may be prepared, copied, published 223 and distributed, in whole or in part, without restriction of any 224 kind, provided that the above copyright notice and this paragraph are 225 included on all such copies and derivative works. However, this 226 document itself may not be modified in any way, such as by removing 227 the copyright notice or references to the Internet Society or other 228 Internet organizations, except as needed for the purpose of 229 developing Internet standards in which case the procedures for 230 copyrights defined in the Internet Standards process must be 231 followed, or as required to translate it into languages other than 232 English. 234 The limited permissions granted above are perpetual and will not be 235 revoked by the Internet Society or its successors or assigns. 237 This document and the information contained herein is provided on an 238 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 239 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 240 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 241 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 242 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.