![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc1161.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / rfcs|
Return to rfc1161.txt CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / rfcs |
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.