|
|
1.1 ! root 1: ! 2: ! 3: ! 4: ! 5: ! 6: ! 7: Network Working Group M. Rose, Editor ! 8: Request for Comments: 1161 Performance Systems International, Inc. ! 9: June 1990 ! 10: ! 11: ! 12: SNMP over OSI ! 13: ! 14: Table of Contents ! 15: ! 16: 1. Status of this Memo ................................... 1 ! 17: 2. Background ............................................ 1 ! 18: 2.1 A Digression on User Interfaces ...................... 2 ! 19: 2.1.1 Addressing Conventions for UDP-based service ....... 3 ! 20: 2.2 A Digression of Layering ............................. 3 ! 21: 3. Mapping onto CLTS ..................................... 4 ! 22: 3.1 Addressing Conventions ............................... 4 ! 23: 3.1.1 Conventions for CLNP-based service ................. 4 ! 24: 4. Mapping onto COTS ..................................... 4 ! 25: 4.1 Addressing Conventions ............................... 5 ! 26: 4.1.1 Conventions for TP4/CLNP-based service ............. 5 ! 27: 4.1.2 Conventions for TP0/X.25-based service ............. 6 ! 28: 5. Acknowledgements ...................................... 6 ! 29: 6. References ............................................ 7 ! 30: 7. Security Considerations................................ 8 ! 31: 8. Author's Address....................................... 8 ! 32: ! 33: 1. Status of this Memo ! 34: ! 35: This memo defines an experimental means for running the Simple ! 36: Network Management Protocol (SNMP) over OSI transports. ! 37: ! 38: This memo does not specify a standard for the Internet community, ! 39: However, after experimentation, if sufficient consensus is reached in ! 40: the Internet community, then a subsequent revision of this document ! 41: might be made an Internet standard for those systems choosing to ! 42: implement the SNMP over OSI transport services. ! 43: ! 44: Distribution of this memo is unlimited. ! 45: ! 46: 2. Background ! 47: ! 48: The Simple Network Management Protocol (SNMP) as defined in [1] is ! 49: now used as an integral part of the network management framework for ! 50: TCP/IP-based internets. Together, with its companions standards, ! 51: which define the Structure of Management Information (SMI) [2], and ! 52: the Management Information Base (MIB) [3], the SNMP has received ! 53: widespread deployment in many operational networks running the ! 54: Internet suite of protocols. ! 55: ! 56: ! 57: ! 58: IETF SNMP Working Group [Page 1] ! 59: ! 60: RFC 1161 SNMP over OSI June 1990 ! 61: ! 62: ! 63: It should not be surprising that many of these sites might acquire ! 64: OSI capabilities and may wish to leverage their investment in SNMP ! 65: technology towards managing those OSI components. This memo ! 66: addresses these concerns by defining a framework for running the SNMP ! 67: in an environment which supports the OSI transport services. ! 68: ! 69: In OSI, there are two such services, a connection-oriented transport ! 70: services (COTS) as defined in [4], and a connectionless-mode ! 71: transport service (CLTS) as defined in [5]. Although the primary ! 72: deployment of the SNMP is over the connectionless-mode transport ! 73: service provided by the Internet suite of protocols (i.e., the User ! 74: Datagram Protocol or UDP [6]), a design goal of the SNMP was to be ! 75: able to use either a CO-mode or CL-mode transport service. As such, ! 76: this memo describes mappings from the SNMP onto both the COTS and the ! 77: CLTS. ! 78: ! 79: 2.1. A Digression on User Interfaces ! 80: ! 81: It is likely that user-interfaces to the SNMP will be developed that ! 82: support multiple transport backings. In an environment such as this, ! 83: it is often important to maintain a consistent addressing scheme for ! 84: users. Since the mappings described in this memo are onto the OSI ! 85: transport services, use of the textual scheme described in [7], which ! 86: describes a string encoding for OSI presentation addresses, is ! 87: recommended. The syntax defined in [7] is equally applicable towards ! 88: transport addresses. ! 89: ! 90: In this context, a string encoding usually appears as: ! 91: ! 92: [<t-selector>/]<n-provider><n-address>[+<n-info>] ! 93: ! 94: where: ! 95: ! 96: (1) <t-selector> is usually either an ASCII string enclosed ! 97: in double-quotes (e.g., "snmp"), or a hexadecimal number ! 98: (e.g., '736e6d70'H); ! 99: ! 100: (2) <n-provider> is one of several well-known providers of a ! 101: connectivity-service, one of: "Internet=" for a ! 102: transport-service from the Internet suite of protocols, ! 103: "Int-X25=" for the 1980 CCITT X.25 recommendation, or ! 104: "NS+" for the OSI network service; ! 105: ! 106: (3) <n-address> is an address in a format specific to the ! 107: <n-provider>; and, ! 108: ! 109: (4) <n-info> is any additional addressing information in a ! 110: format specific to the <n-provider>. ! 111: ! 112: ! 113: ! 114: IETF SNMP Working Group [Page 2] ! 115: ! 116: RFC 1161 SNMP over OSI June 1990 ! 117: ! 118: ! 119: It is not the purpose of this memo to provide an exhaustive ! 120: description of string encodings such as these. Readers should ! 121: consult [7] for detailed information on the syntax. However, this ! 122: memo recommends that, as an implementation option, user-interfaces to ! 123: the SNMP that support multiple transport backings SHOULD implement ! 124: this syntax. ! 125: ! 126: 2.1.1. Addressing Conventions for UDP-based service ! 127: ! 128: In the context of a UDP-based transport backing, addresses would be ! 129: encoded as: ! 130: ! 131: Internet=<host>+161+2 ! 132: ! 133: which says that the transport service is from the Internet suite of ! 134: protocols, residing at <host>, on port 161, using the UDP (2). The ! 135: token <host> may be either a domain name or a dotted-quad, e.g., both ! 136: ! 137: Internet=cheetah.nyser.net+161+2 ! 138: ! 139: and ! 140: ! 141: Internet=192.52.180.1+161+2 ! 142: ! 143: are both valid. Note however that if domain name "cheetah.nyser.net" ! 144: maps to multiple IP addresses, then this implies multiple transport ! 145: addresses. The number of addresses examined by the application (and ! 146: the order of examination) are specific to each application. ! 147: ! 148: Of course, this memo does not require that other interface schemes ! 149: not be used. Clearly, use of a simple hostname is preferable to the ! 150: string encoding above. However, for the sake of uniformity, for ! 151: those user-interfaces to the SNMP that support multiple transport ! 152: backings, it is strongly RECOMMENDED that the syntax in [7] be ! 153: adopted and even the mapping for UDP-based transport be valid. ! 154: ! 155: 2.2. A Digression of Layering ! 156: ! 157: Although other frameworks view network management as an application, ! 158: extensive experience with the SNMP suggests otherwise. In essense, ! 159: network management is a function unlike any other user of a transport ! 160: service. The citation [8] develops this argument in full. As such, ! 161: it is inappropriate to map the SNMP onto the OSI application layer. ! 162: Rather, it is mapped to OSI transport services, in order to build on ! 163: the proven success of the Internet network management framework. ! 164: ! 165: ! 166: ! 167: ! 168: ! 169: ! 170: IETF SNMP Working Group [Page 3] ! 171: ! 172: RFC 1161 SNMP over OSI June 1990 ! 173: ! 174: ! 175: 3. Mapping onto CLTS ! 176: ! 177: Mapping the SNMP onto the CLTS is straight-forward: the elements of ! 178: procedure are identical to that of using the UDP. In particular, ! 179: note that the CLTS and the service offered by the UDP both transmit ! 180: packets of information which contain full addressing information. ! 181: Thus, mapping the SNMP onto the CLTS, a "transport address" in the ! 182: context of [1], is simply a transport-selector and network address. ! 183: ! 184: 3.1. Addressing Conventions ! 185: ! 186: Unlike the Internet suite of protocols, OSI does not use well-known ! 187: ports. Rather demultiplexing occurs on the basis of "selectors", ! 188: which are opaque strings of octets, which have meaning only at the ! 189: destination. In order to foster interoperable implementations of the ! 190: SNMP over the CLTS, it is necessary define a selector for this ! 191: purpose. ! 192: ! 193: 3.1.1. Conventions for CLNP-based service ! 194: ! 195: When the CLTS is used to provide the transport backing for the SNMP, ! 196: demultiplexing will occur on the basis of transport selector. The ! 197: transport selector used shall be the four ASCII characters ! 198: ! 199: snmp ! 200: ! 201: Thus, using the string encoding of [7], such addresses may be ! 202: textual, described as: ! 203: ! 204: "snmp"/NS+<nsap> ! 205: ! 206: where: ! 207: ! 208: (1) <nsap> is a hex string defining the nsap, e.g., ! 209: ! 210: "snmp"/NS+4900590800200038bafe00 ! 211: ! 212: Similarly, SNMP traps are, by convention, sent to a manager listening ! 213: on the transport selector ! 214: ! 215: snmp-trap ! 216: ! 217: which consists of nine ASCII characters. ! 218: ! 219: 4. Mapping onto COTS ! 220: ! 221: Mapping the SNMP onto the COTS is more difficult as the SNMP does not ! 222: specifically require an existing connection. Thus, the mapping ! 223: ! 224: ! 225: ! 226: IETF SNMP Working Group [Page 4] ! 227: ! 228: RFC 1161 SNMP over OSI June 1990 ! 229: ! 230: ! 231: consists of establishing a transport connection, sending one or more ! 232: SNMP messages on that connection, and then releasing the transport ! 233: connection. ! 234: ! 235: Consistent with the SNMP model, the initiator of a connection should ! 236: not require that responses to a request be returned on that ! 237: connection. However, if a responder to a connection sends SNMP ! 238: messages on a connection, then these MUST be in response to requests ! 239: received on that connection. ! 240: ! 241: Ideally, the transport connection SHOULD be released by the ! 242: initiator, however, note that the responder may release the ! 243: connection due to resource limitations. Further note, that the ! 244: amount of time a connection remains established is implementation- ! 245: specific. Implementors should take care to choose an appropriate ! 246: dynamic algorithm. ! 247: ! 248: Also consistent with the SNMP model, the initiator should not ! 249: associate any reliability characteristics with the use of a ! 250: connection. Issues such as retransmission of SNMP messages, etc., ! 251: always remain with the SNMP application, not with the transport ! 252: service. ! 253: ! 254: 4.1. Addressing Conventions ! 255: ! 256: Unlike the Internet suite of protocols, OSI does not use well-known ! 257: ports. Rather demultiplexing occurs on the basis of "selectors", ! 258: which are opaque strings of octets, which have meaning only at the ! 259: destination. In order to foster interoperable implementations of the ! 260: SNMP over the COTS, it is necessary define a selector for this ! 261: purpose. However, to be consistent with the various connectivity- ! 262: services, different conventions, based on the actual underlying ! 263: service, will be used. ! 264: ! 265: 4.1.1. Conventions for TP4/CLNP-based service ! 266: ! 267: When a COTS based on the TP4/CLNP is used to provide the transport ! 268: backing for the SNMP, demultiplexing will occur on the basis of ! 269: transport selector. The transport selector used shall be the four ! 270: ASCII characters ! 271: ! 272: snmp ! 273: ! 274: Thus, using the string encoding of [7], such addresses may be ! 275: textual, described as: ! 276: ! 277: "snmp"/NS+<nsap> ! 278: ! 279: ! 280: ! 281: ! 282: IETF SNMP Working Group [Page 5] ! 283: ! 284: RFC 1161 SNMP over OSI June 1990 ! 285: ! 286: ! 287: where: ! 288: ! 289: (1) <nsap> is a hex string defining the nsap, e.g., ! 290: ! 291: "snmp"/NS+4900590800200038bafe00 ! 292: ! 293: Similarly, SNMP traps are, by convention, sent to a manager listening ! 294: on the transport selector ! 295: ! 296: snmp-trap ! 297: ! 298: which consists of nine ASCII characters. ! 299: ! 300: 4.1.2. Conventions for TP0/X.25-based service ! 301: ! 302: When a COTS based on the TP0/X.25 is used to provide the transport ! 303: backing for the SNMP, demultiplexing will occur on the basis of X.25 ! 304: protocol-ID. The protocol-ID used shall be the four octets ! 305: ! 306: 03018200 ! 307: ! 308: Thus, using the string encoding of [7], such addresses may be textual ! 309: described as: ! 310: ! 311: Int-X25=<dte>+PID+03018200 ! 312: ! 313: where: ! 314: ! 315: (1) <dte> is the X.121 DTE, e.g., ! 316: ! 317: Int-X25=23421920030013+PID+03018200 ! 318: ! 319: Similarly, SNMP traps are, by convention, sent to a manager listening ! 320: on the protocol-ID ! 321: ! 322: 03019000 ! 323: ! 324: 5. Acknowledgements ! 325: ! 326: This document was produced by the SNMP Working Group: ! 327: ! 328: Karl Auerbach, Epilogue Technology ! 329: David Bridgham, Epilogue Technology ! 330: Brian Brown, Synoptics ! 331: John Burress, Wellfleet ! 332: Jeffrey D. Case, University of Tennessee at Knoxville ! 333: James R. Davin, MIT-LCS ! 334: Mark S. Fedor, PSI, Inc. ! 335: ! 336: ! 337: ! 338: IETF SNMP Working Group [Page 6] ! 339: ! 340: RFC 1161 SNMP over OSI June 1990 ! 341: ! 342: ! 343: Stan Froyd, ACC ! 344: Satish Joshi, Synoptics ! 345: Ken Key, University of Tennessee at Knoxville ! 346: Gary Malkin, FTP Software ! 347: Randy Mayhew, University of Tennessee at Knoxville ! 348: Keith McCloghrie, Hughes LAN Systems ! 349: Marshall T. Rose, PSI, Inc. (chair) ! 350: Greg Satz, cisco ! 351: Martin Lee Schoffstall, PSI, Inc. ! 352: Bob Stewart, Xyplex ! 353: Geoff Thompson, Synoptics ! 354: Bill Versteeg, Network Research Corporation ! 355: Wengyik Yeong, PSI, Inc. ! 356: ! 357: 6. References ! 358: ! 359: [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple ! 360: Network Management Protocol (SNMP)", RFC 1157, SNMP Research, ! 361: Performance Systems International, Performance Systems ! 362: International, and MIT Laboratory for Computer Science, May 1990. ! 363: ! 364: [2] Rose M., and K. McCloghrie, "Structure and Identification of ! 365: Management Information for TCP/IP-based internets", RFC 1155, ! 366: Performance Systems International, Hughes LAN Systems, May 1990. ! 367: ! 368: [3] McCloghrie K., and M. Rose, "Management Information Base for ! 369: Network Management of TCP/IP-based internets", RFC 1156, Hughes ! 370: LAN Systems, Performance Systems International, May 1990. ! 371: ! 372: [4] Information Processing Systems - Open Systems Interconnection, ! 373: "Transport Service Definition", International Organization for ! 374: Standardization, International Standard 8072, June 1986. ! 375: ! 376: [5] Information Processing Systems - Open Systems Interconnection, ! 377: "Transport Service Definition - Addendum 1: Connectionless-mode ! 378: Transmission", International Organization for Standardization, ! 379: International Standard 8072/AD 1, December 1986. ! 380: ! 381: [6] Postel, J., "User Datagram Protocol", RFC 768, USC/Information ! 382: Sciences Institute, November 1980. ! 383: ! 384: [7] Kille, S., "A String Encoding of Presentation Address", Research ! 385: Note RN/89/14, Department of Computer Science, University College ! 386: London, February 1989. ! 387: ! 388: [8] Case, J., Davin, J., Fedor, M., and M. Schoffstall, "Network ! 389: Management and the Design of SNMP", ConneXions (ISSN 0894-5926), ! 390: Volume 3, Number 3, March 1989. ! 391: ! 392: ! 393: ! 394: IETF SNMP Working Group [Page 7] ! 395: ! 396: RFC 1161 SNMP over OSI June 1990 ! 397: ! 398: ! 399: 7. Security Considerations ! 400: ! 401: Security issues are not discussed in this memo. ! 402: ! 403: 8. Author's Address ! 404: ! 405: Marshall T. Rose ! 406: PSI, Inc. ! 407: PSI California Office ! 408: P.O. Box 391776 ! 409: Mountain View, CA 94039 ! 410: ! 411: Phone: (415) 961-3380 ! 412: ! 413: Email: [email protected] ! 414: ! 415: ! 416: ! 417: ! 418: ! 419: ! 420: ! 421: ! 422: ! 423: ! 424: ! 425: ! 426: ! 427: ! 428: ! 429: ! 430: ! 431: ! 432: ! 433: ! 434: ! 435: ! 436: ! 437: ! 438: ! 439: ! 440: ! 441: ! 442: ! 443: ! 444: ! 445: ! 446: ! 447: ! 448: ! 449: ! 450: IETF SNMP Working Group [Page 8] ! 451:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.