![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to smux.rf 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 smux.rf CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / rfcs |
1.1 root 1: .\" smux.rf - SNMP MUX definitions
2: .de UL
3: .ti -.5i
4: -------
5: .br
6: ..
7: .ie \nh \{\
8: .ll 66
9: .po 2 \}
10: .el \{\
11: .ll 62
12: .pl 58
13: .nr sf R
14: .nr fm 0 \}
15: .he 'draft'SMUX'May 1990'
16: .fo 'M.T. Rose''[Page %]'
17: .de $0
18: .(x t
19: \\$2 \\$1
20: .)x
21: ..
22: .lp
23: .na
24: .nh
25: .ce
26: \fBSNMP MUX Protocol and MIB\fR
27: .sp 1
28: .ce
29: Sun May 13 14:53:58 1990
30: .sp 2
31: .ce
32: Marshall T. Rose
33: .sp 1
34: .ce 4
35: Performance Systems International, Inc.
36: 11800 Sunrise Valley Drive
37: Suite 1100
38: Reston, VA 22091
39: .sp 1
40: .ce
41: [email protected]
42: .sp 5
43: .sh 1 "Status of this Memo"
44: .lp
45: This document defines a mechanism by which multiple UNIX daemons
46: may communicate with the local SNMP agent on a host.
47: This is a local mechanism.
48:
49: .bp
50: .sh 1 "Introduction"
51: .lp
52: On kernel/user systems such as BSD UNIX,
53: an agent speaking the SNMP [1] is often implemented as a user-process,
54: which reads kernel variables in order to realize the Internet-standard
55: MIB [2].
56: This approach works fine as long as all of the information needed by
57: the SNMP agent resides in either the kernel or in stable storage
58: (i.e., files).
59: However,
60: when other user-processes are employed to implement other network
61: services,
62: such as routing protocols,
63: communication between the SNMP agent the and other processes is problematic.
64: .lp
65: In order to solve this problem,
66: a new protocol,
67: the SNMP multiplexing (SMUX) protocol is introduced.
68: When a user-process,
69: termed a SMUX peer,
70: wishes to export a MIB module,
71: it initiates a SMUX association to the local SNMP agent,
72: registers itself, and (later) fields management operations for objects
73: in the MIB module.
74: .lp
75: Carrying this approach to its fullest,
76: it is possible to generalize the SNMP agent so that it knows about
77: only the SNMP group of the Internet-standard MIB.
78: All other portions of the Internet-standard MIB can be implemented by
79: another process.
80: This is quite useful, for example, when a computer manufacturer wishes
81: to provide SNMP access for its operating system in binary form.
82: .lp
83: In addition to defining the SMUX protocol,
84: this document defines a MIB for the SMUX.
85: Obviously,
86: this MIB module must also be implemented in the local SNMP agent.
87:
88: .bp
89: .sh 1 "Architecture"
90: .lp
91: There are two approaches that can be taken when trying to integrate
92: arbitrary MIB modules with the SNMP agent: request-response and cache-ahead.
93: .lp
94: The request-response model simply propagates the SNMP requests
95: received by the SNMP agent to the user process which exported the MIB
96: module.
97: The SMUX peer then performs the operation and returns a response.
98: In turn,
99: the SNMP agent propagates this response back to the network management station.
100: The request-response model is said to be agent-driven since,
101: after registration,
102: the SNMP agent initiates all transactions.
103: .lp
104: The cache-ahead model requires that the SMUX peer,
105: after registration,
106: periodically updates the SNMP agent with the subtree for the MIB module
107: which has been registered.
108: The SNMP agent, upon receiving an SNMP request,
109: locally performs the operation,
110: and returns a response to the network management station.
111: The cache-ahead model is said to be peer-driven since,
112: after registration,
113: the SMUX peer initiates all transactions.
114: .lp
115: There are advantages and disadvantages to both approaches.
116: As such,
117: the architecture envisioned supports both models in the following
118: fashion:
119: the protocol between the SNMP agent and the SMUX peer is based on the
120: request-response model.
121: However,
122: the SMUX peer,
123: may itself be a user-process which employs the cache-ahead model with
124: other user-processes.
125: .lp
126: Obviously,
127: the SMUX peer which employs the cache-ahead model acts as a \*(lqfirewall\*(rq
128: for those user-processes which actually implement the managed objects
129: in the given MIB module.
130: .lp
131: Note that this document describes only the SMUX protocol,
132: for the request-response model.
133: Each SMUX peer is free to define a cache-ahead protocol specific for
134: the application at hand.
135:
136: .bp
137: .sh 1 "Protocol"
138: .lp
139: The SMUX protocol is simple:
140: the SNMP agent listens for incoming connections.
141: Upon establishing a connection,
142: the SMUX peer issues an OpenPDU to initialize the SMUX association.
143: If the SNMP agent declines the association,
144: it issues a closePDU and closes the connection.
145: If the SNMP agent accepts the association,
146: no response is issued by the SNMP agent.
147: .lp
148: For each subtree defined in a MIB module that the SMUX peer wishes to
149: register (or unregister),
150: the SMUX peer issues a RReqPDU.
151: When the SNMP agent receives such a PDU,
152: it issues a corresponding RRspPDU.
153: The SNMP agent returns RRspPDUs in the same order as the RReqPDUs were
154: received.
155: .lp
156: When the SMUX peer wishes to issue a trap,
157: it issues an SNMP Trap-PDU.
158: When the SNMP agent receives such a PDU,
159: it propagates this to the network management stations that it is
160: configured to send traps to.
161: .lp
162: When the SNMP agent receives an SNMP GetRequest-PDU,
163: GetNextRequest-PDU, or SetRequest-PDU which includes one or more
164: variable-bindings within a subtree registered by a SMUX peer,
165: the SNMP agent sends an equivalent SNMP PDU containing only those
166: variables within the subtree registered by that SMUX peer.
167: When the SMUX peer receives such a PDU,
168: it applies the indicated operation and issues a corresponding SNMP
169: GetResponse-PDU.
170: The SNMP agent then correlates this result and propagates the
171: resulting GetResponse-PDU to the network management station.
172: .lp
173: When either the SNMP agent or the SMUX peer wishes to release the SMUX
174: association,
175: the ClosePDU is issued and the connection is closed.
176:
177: .sh 2 "Tricky Things"
178: .lp
179: Although straight-forward, there are a few nuances.
180:
181: .sh 3 "Registration"
182: .lp
183: Associated with each registration is an integer priority,
184: from 0 to (2^31)-1.
185: The lower the value,
186: the higher the priority.
187: .lp
188: Multiple SMUX peers may register the same subtree.
189: However,
190: they must do so at different priorities
191: (i.e., a subtree and a priority uniquely identifies a SMUX peer).
192: As such,
193: if a SMUX peer wishes to register a subtree at a priority which is
194: already taken,
195: the SNMP agent repeatedly increments the integer value until an unused
196: priority is found.
197: .lp
198: When registering a subtree,
199: the special priority -1 may be used,
200: which selects the highest available priority.
201: .lp
202: Of course,
203: the SNMP agent may select an arbitrarily worse priority for a SMUX
204: peer,
205: based on local (configuration) information.
206: .lp
207: Note that when a subtree is registered,
208: the SMUX peer with the highest registration priority is exclusively
209: consulted for all operations on that subtree.
210: Further note that SNMP agents must enforce the
211: \*(lqsubtree mounting effect\*(rq,
212: which hides the registrations by other SMUX peers of objects within
213: the subtree.
214: For example,
215: if a SMUX peer registered \*(lqsysDescr\*(rq,
216: and later another SMUX peer registered \*(lqsystem\*(rq
217: (which scopes \*(lqsysDescr\*(rq),
218: then all requests for \*(lqsysDescr\*(rq would be given to the latter
219: SMUX peer.
220: .lp
221: An SNMP agent should disallow any attempt to register at or within the SNMP
222: and SMUX subtrees of the MIB.
223: Other subtrees may be disallowed as an implementation-specific option.
224:
225: .sh 3 "Removing Registration"
226: .lp
227: A SMUX peer may remove registrations for only those subtrees which it
228: has registered.
229: If the priority given in the RReq-PDU is -1,
230: then the registration of highest priority is selected for deletion.
231: Otherwise, only that registration with the precise registration
232: is selected.
233:
234: .sh 3 "Variables in Requests"
235: .lp
236: When constructing an SNMP GetRequest-PDU, GetNextRequest-PDU, or
237: SetRequest-PDU, for a SMUX peer,
238: the SNMP agent may send one, or more than one variable in a single request.
239: In all cases,
240: the SNMP agent should process each variable sequentially,
241: and block accordingly when a SMUX peer is contacted.
242:
243: .sh 3 "Request-ID"
244: .lp
245: When the SNMP agent constructs an SNMP GetRequest-PDU,
246: GetNextRequest-PDU, or SetRequest-PDU, for a SMUX peer,
247: the \fIrequest_id\fR field of the SNMP takes a special meaning.
248: Basically,
249: this field should take a different value for each SNMP PDU received by
250: the SNMP agent.
251: As such,
252: if an SNMP agent generates multiple PDUs for a SMUX peer,
253: upon receipt of a single PDU from the network management station,
254: then the \fIrequest_id\fR field of the PDUs sent to the SMUX peer
255: takes the same value
256: (which need bear no relationship to the value of the \fIrequest_id\fR
257: field of the PDU originally received by the SNMP agent.)
258:
259: .sh 3 "The powerful get-next operator"
260: .lp
261: Each SMUX peer acts as though it contains the entire MIB when
262: processing the powerful get-next operator.
263: This means that the SNMP agent must check each variable named returned
264: in the SNMP GetResponse-PDU generated by a SMUX peer and see if it is in
265: the subtree of the managed object corresponding to original SNMP
266: GetNextRequest-PDU.
267: If not,
268: the SNMP agent will apply the get-next operator to the next managed object.
269: This may result in contacting a different SMUX peer,
270: depending on the registration topology.
271:
272: .sh 2 "Protocol Data Units"
273: .lp
274: The SMUX protocol data units are defined using Abstract Syntax
275: Notation One (ASN.1) [3]:
276: .sp
277: .in +.5i
278: .nf
279: SMUX DEFINITIONS ::= BEGIN
280:
281: IMPORTS
282: DisplayString, ObjectName
283: FROM RFC1155-SMI
284:
285: PDUs
286: FROM RFC1157-SNMP;
287:
288:
289: -- tags for SMUX-specific PDUs are application-wide to
290: -- avoid conflict with tags for current (and future)
291: -- SNMP-generic PDUs
292:
293: SMUX-PDUs ::=
294: CHOICE {
295: open -- SMUX peer uses
296: OpenPDU, -- immediately after TCP open
297:
298: close -- either uses immediately before TCP close
299: ClosePDU,
300:
301: registerRequest -- SMUX peer uses
302: RReqPDU,
303:
304: registerResponse -- SNMP agent uses
305: RRspPDU,
306:
307: PDUs -- note that roles are reversed:
308: -- SNMP agent does get/get-next/set
309: -- SMUX peer does get-response/trap
310: }
311:
312:
313: -- open PDU
314: -- currently only simple authentication
315:
316: OpenPDU ::=
317: CHOICE {
318: simple
319: SimpleOpen
320: }
321:
322: SimpleOpen ::=
323: [APPLICATION 0] IMPLICIT
324: SEQUENCE {
325: version -- of SMUX protocol
326: INTEGER {
327: version-1(0)
328: },
329:
330: identity -- of SMUX peer, authoritative
331: OBJECT IDENTIFIER,
332:
333: description -- of SMUX peer, implementation-specific
334: DisplayString,
335:
336: password -- zero length indicates no authentication
337: OCTET STRING
338: }
339:
340:
341: -- close PDU
342:
343: ClosePDU ::=
344: [APPLICATION 1] IMPLICIT
345: INTEGER {
346: goingDown(0),
347: unsupportedVersion(1),
348: packetFormat(2),
349: protocolError(3),
350: internalError(4),
351: authenticationFailure(5)
352: }
353:
354:
355: -- insert PDU
356:
357: RReqPDU ::=
358: [APPLICATION 2] IMPLICIT
359: SEQUENCE {
360: subtree
361: ObjectName,
362:
363: priority -- the lower the better, "-1" means default
364: INTEGER (-1..2147483647),
365:
366: operation
367: INTEGER {
368: delete(0),
369: readOnly(1),
370: readWrite(2)
371: }
372: }
373:
374: RRspPDU ::=
375: [APPLICATION 3] IMPLICIT
376: INTEGER {
377: failure(-1)
378:
379: -- on success the non-negative priority is returned
380: }
381:
382: END
383: .fi
384: .in -.5i
385: .sp
386:
387: .sh 2 "Mappings on Transport Service"
388: .lp
389: The SMUX protocol may be mapped onto any CO-mode transport service.
390: At present,
391: only one such mapping is defined.
392:
393: .sh 3 "Mapping onto the TCP"
394: .lp
395: When using the TCP to provide the transport-backing for the SMUX
396: protocol,
397: the SNMP agent listens on TCP port 199.
398: .lp
399: Each SMUX PDU is serialized using the Basic Encoding Rules [4] and
400: sent on the TCP.
401: As ASN.1 objects are self-delimiting when encoding using the BER,
402: so no packetization protocol is required.
403:
404: .bp
405: .sh 1 "MIB for the SMUX"
406: .lp
407: The MIB objects for the SMUX are implemented by the local SNMP agent:
408: .sp
409: .in +.5i
410: .nf
411: SMUX-MIB DEFINITIONS ::= BEGIN
412:
413: IMPORTS
414: enterprises, OBJECT-TYPE, ObjectName
415: FROM RFC1155-SMI;
416:
417:
418: unix OBJECT IDENTIFIER ::= { enterprises 4 }
419:
420:
421: smux OBJECT IDENTIFIER ::= { unix 4 }
422:
423: smuxPeerTable OBJECT-TYPE
424: SYNTAX SEQUENCE OF SmuxPeerEntry
425: ACCESS not-accessible
426: STATUS mandatory
427: ::= { smux 1 }
428:
429: smuxPeerEntry OBJECT-TYPE
430: SYNTAX SmuxPeerEntry
431: ACCESS not-accessible
432: STATUS mandatory
433: -- INDEX { smuxPindex }
434: ::= { smuxPeerTable 1}
435:
436: SmuxPeerEntry ::= SEQUENCE {
437: smuxPindex
438: INTEGER,
439: smuxPidentity
440: OBJECT IDENTIFIER,
441: smuxPdescription
442: DisplayString,
443: smuxPstatus
444: INTEGER
445: }
446:
447: smuxPindex OBJECT-TYPE
448: SYNTAX INTEGER
449: ACCESS read-write
450: STATUS mandatory
451: ::= { smuxPeerEntry 1 }
452:
453: smuxPidentity OBJECT-TYPE
454: SYNTAX OBJECT IDENTIFIER
455: ACCESS read-write
456: STATUS mandatory
457: ::= { smuxPeerEntry 2 }
458:
459: smuxPdescription OBJECT-TYPE
460: SYNTAX DisplayString (SIZE (0..255))
461: ACCESS read-write
462: STATUS mandatory
463: ::= { smuxPeerEntry 3 }
464:
465: smuxPstatus OBJECT-TYPE
466: SYNTAX INTEGER { valid(1), invalid(2), connecting(3) }
467: ACCESS read-write
468: STATUS mandatory
469: ::= { smuxPeerEntry 4 }
470:
471: smuxTreeTable OBJECT-TYPE
472: SYNTAX SEQUENCE OF SmuxTreeEntry
473: ACCESS not-accessible
474: STATUS mandatory
475: ::= { smux 2 }
476:
477: smuxTreeEntry OBJECT-TYPE
478: SYNTAX SmuxTreeEntry
479: ACCESS not-accessible
480: STATUS mandatory
481: ::= { smuxTreeTable 1}
482:
483: SmuxTreeEntry ::= SEQUENCE {
484: smuxTsubtree
485: ObjectName
486: smuxTpriority
487: INTEGER,
488: smuxTindex
489: INTEGER,
490: smuxTstatus
491: INTEGER
492: }
493:
494: smuxTsubtree OBJECT-TYPE
495: SYNTAX ObjectName
496: ACCESS read-write
497: STATUS mandatory
498: -- INDEX { smuxTsubtree, smuxTpriority }
499: ::= { smuxTreeEntry 1 }
500:
501: smuxTpriority OBJECT-TYPE
502: SYNTAX INTEGER (0..2147483647)
503: ACCESS read-write
504: STATUS mandatory
505: ::= { smuxTreeEntry 2 }
506:
507: smuxTindex OBJECT-TYPE
508: SYNTAX INTEGER (0..2147483647)
509: ACCESS read-write
510: STATUS mandatory
511: ::= { smuxTreeEntry 3 }
512:
513: smuxTstatus OBJECT-TYPE
514: SYNTAX INTEGER { valid(1), invalid(2) }
515: ACCESS read-write
516: STATUS mandatory
517: ::= { smuxTreeEntry 4 }
518:
519: END
520: .fi
521: .in -.5i
522: .sp
523:
524: .sh 2 "Identification of OBJECT instances for use with the SNMP"
525: .lp
526: The names for all object types in the MIB are defined explicitly either
527: in the Internet-standard MIB or in other documents which conform to
528: the naming conventions of the SMI[5]. The SMI requires
529: that conformant management protocols define mechanisms
530: for identifying individual instances of those object types
531: for a particular network element.
532: .lp
533: Each instance of any object type defined in the MIB is identified
534: in SNMP operations by a unique name called its "variable name."
535: In general, the name of an SNMP variable is an OBJECT IDENTIFIER
536: of the form x.y, where x is the name of a non-aggregate object type
537: defined in the MIB and y is an OBJECT IDENTIFIER fragment
538: that, in a way specific to the named object type, identifies the
539: desired instance.
540: .lp
541: This naming strategy admits the fullest exploitation of the
542: semantics of the powerful SNMP get-next operator,
543: because it assigns names for related variables so as to be contiguous
544: in the lexicographical ordering of all variable names
545: known in the MIB.
546: .lp
547: The type-specific naming of object instances is defined below
548: for a number of classes of object types.
549: Instances of
550: an object type to which
551: none of the following naming conventions are applicable are
552: named by OBJECT IDENTIFIERs of the form
553: x.0, where x is the name of said object type in the MIB definition.
554: .lp
555: For example,
556: suppose one wanted to identify an instance of the variable sysDescr.
557: The object class for sysDescr is:
558: .sp
559: .in +0.25
560: .nf
561: iso org dod internet mgmt mib system sysDescr
562: 1 3 6 1 2 1 1 1
563: .fi
564: .in -0.25
565: .sp
566: Hence,
567: the object type, x, would be 1.3.6.1.2.1.1.1 to which
568: is appended an instance sub-identifier of 0.
569: That is, 1.3.6.1.2.1.1.1.0
570: identifies the one and only instance of sysDescr.
571:
572: .sh 3 "smuxPeerTable Object Type Names"
573: .lp
574: The name of a SMUX peer relationship, s, is the OBJECT IDENTIFIER
575: value of the form i, where i has the value of that
576: instance of the smuxPindex object type associated with s.
577: .lp
578: For each object type, t, for which the defined name, n, has
579: a prefix of smuxPeerEntry, an instance, i, of t is named by an OBJECT
580: IDENTIFIER of the form n.s, where s is the name of the SMUX peer relationship
581: about which i represents information.
582: .lp
583: For example,
584: suppose one wanted to identify the instance of the variable smuxPidentity
585: associated with peer relationship number 2.
586: Accordingly, smuxPidentity.2 would identify the desired instance.
587:
588: .sh 3 "smuxTreeTable Object Type Names"
589: .lp
590: The name of a SMUX subtree relationship, s, is the OBJECT IDENTIFIER
591: value of the form i.j, where i has the value of that
592: instance of the smuxTsubtree object type,
593: and j has the value of that instance of the smuxTpriority object type,
594: associated with s.
595: .lp
596: For each object type, t, for which the defined name, n, has
597: a prefix of smuxTreeEntry, an instance, i, of t is named by an OBJECT
598: IDENTIFIER of the form n.s.t.u,
599: where s is the number of sub-identifiers in the corresponding instance
600: of smuxTsubtree,
601: t is the value of the instance of smuxTsubtree corresponding to this
602: entry,
603: and u is the value of the instance of smuxTpriority corresponding to
604: this entry.
605: .lp
606: For example,
607: suppose one wanted to identify the instance of the variable smuxTindex
608: associated with the subtree 1.3.6.1.5 for priority 3.
609: Accordingly, smuxTindex.5.1.3.6.1.5.3 would identify the desired instance.
610:
611: .bp
612: .sh 1 "Acknowledgements"
613: .lp
614: SMUX was designed one afternoon by these people:
615: .sp
616: .in +.5i
617: .nf
618: Jeffrey S. Case, UTK-CS
619: James R. Davin, MIT-LCS
620: Mark S. Fedor, PSI
621: Jeffrey C. Honig, Cornell
622: Louie A. Mamakos, UMD
623: Michael G. Petry, UMD
624: Yakov Rekhter, IBM
625: Marshall T. Rose, PSI
626: .fi
627: .in -.5i
628: .sp
629:
630: .bp
631: .sh 1 "References"
632: .ip [1]
633: J.D.\0Case, M.S.\0Fedor, M.L.\0Schoffstall, and J.R.\0Davin,
634: \fISimple Network Management Protocol\fR,
635: Internet Working Group Request for Comments 1157.
636: Network Information Center, SRI International, Menlo Park, California,
637: (May, 1990).
638: .ip [2]
639: K.\0McCloghrie and M.T.\0Rose,
640: \fIManagement Information Base for Network Management of TCP/IP-based
641: internets\fR,
642: Internet Working Group Request for Comments 1156.
643: Network Information Center, SRI International, Menlo Park, California,
644: (May, 1990).
645: .ip [3]
646: \fIInformation processing systems \(em Open Systems Interconnection \(em
647: Specification of Abstract Syntax Notation One (ASN.1)\fP, International
648: Organization for Standardization. International Standard 8824,
649: (December, 1987).
650: .ip [4]
651: \fIInformation processing systems \(em Open Systems Interconnection \(em
652: Specification of Basic Encoding Rules for Abstract Notation
653: One (ASN.1)\fP, International Organization for Standardization.
654: International Standard 8825,
655: (December, 1987).
656: .ip [5]
657: M.T.\0Rose and K.\0McCloghrie,
658: \fIStructure and Identification of Management Information for
659: TCP/IP\-based internets\fR,
660: Internet Working Group Request for Comments 1155.
661: Network Information Center, SRI International, Menlo Park, California,
662: (May, 1990).
663:
664: .bp
665: .lp
666: \fBTable of Contents\fR
667: .sp 2
668: .xp t
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.