![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to smux.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 smux.txt CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / rfcs |
1.1 root 1:
2:
3:
4:
5: draft SMUX May 1990
6:
7:
8: SNMP MUX Protocol and MIB
9:
10: Sun May 13 14:53:58 1990
11:
12:
13: Marshall T. Rose
14:
15: Performance Systems International, Inc.
16: 11800 Sunrise Valley Drive
17: Suite 1100
18: Reston, VA 22091
19:
20: [email protected]
21:
22:
23:
24:
25:
26:
27: 1. Status of this Memo
28:
29: This document defines a mechanism by which multiple UNIX
30: daemons may communicate with the local SNMP agent on a host.
31: This is a local mechanism.
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58: M.T. Rose [Page 1]
59:
60:
61:
62:
63:
64: draft SMUX May 1990
65:
66:
67: 2. Introduction
68:
69: On kernel/user systems such as BSD UNIX, an agent speaking the
70: SNMP [1] is often implemented as a user-process, which reads
71: kernel variables in order to realize the Internet-standard MIB
72: [2]. This approach works fine as long as all of the
73: information needed by the SNMP agent resides in either the
74: kernel or in stable storage (i.e., files). However, when
75: other user-processes are employed to implement other network
76: services, such as routing protocols, communication between the
77: SNMP agent the and other processes is problematic.
78:
79: In order to solve this problem, a new protocol, the SNMP
80: multiplexing (SMUX) protocol is introduced. When a user-
81: process, termed a SMUX peer, wishes to export a MIB module, it
82: initiates a SMUX association to the local SNMP agent,
83: registers itself, and (later) fields management operations for
84: objects in the MIB module.
85:
86: Carrying this approach to its fullest, it is possible to
87: generalize the SNMP agent so that it knows about only the SNMP
88: group of the Internet-standard MIB. All other portions of the
89: Internet-standard MIB can be implemented by another process.
90: This is quite useful, for example, when a computer
91: manufacturer wishes to provide SNMP access for its operating
92: system in binary form.
93:
94: In addition to defining the SMUX protocol, this document
95: defines a MIB for the SMUX. Obviously, this MIB module must
96: also be implemented in the local SNMP agent.
97:
98:
99:
100:
101:
102:
103:
104:
105:
106:
107:
108:
109:
110:
111:
112:
113:
114:
115:
116:
117: M.T. Rose [Page 2]
118:
119:
120:
121:
122:
123: draft SMUX May 1990
124:
125:
126: 3. Architecture
127:
128: There are two approaches that can be taken when trying to
129: integrate arbitrary MIB modules with the SNMP agent: request-
130: response and cache-ahead.
131:
132: The request-response model simply propagates the SNMP requests
133: received by the SNMP agent to the user process which exported
134: the MIB module. The SMUX peer then performs the operation and
135: returns a response. In turn, the SNMP agent propagates this
136: response back to the network management station. The
137: request-response model is said to be agent-driven since, after
138: registration, the SNMP agent initiates all transactions.
139:
140: The cache-ahead model requires that the SMUX peer, after
141: registration, periodically updates the SNMP agent with the
142: subtree for the MIB module which has been registered. The
143: SNMP agent, upon receiving an SNMP request, locally performs
144: the operation, and returns a response to the network
145: management station. The cache-ahead model is said to be
146: peer-driven since, after registration, the SMUX peer initiates
147: all transactions.
148:
149: There are advantages and disadvantages to both approaches. As
150: such, the architecture envisioned supports both models in the
151: following fashion: the protocol between the SNMP agent and the
152: SMUX peer is based on the request-response model. However,
153: the SMUX peer, may itself be a user-process which employs the
154: cache-ahead model with other user-processes.
155:
156: Obviously, the SMUX peer which employs the cache-ahead model
157: acts as a "firewall" for those user-processes which actually
158: implement the managed objects in the given MIB module.
159:
160: Note that this document describes only the SMUX protocol, for
161: the request-response model. Each SMUX peer is free to define
162: a cache-ahead protocol specific for the application at hand.
163:
164:
165:
166:
167:
168:
169:
170:
171:
172:
173:
174:
175:
176: M.T. Rose [Page 3]
177:
178:
179:
180:
181:
182: draft SMUX May 1990
183:
184:
185: 4. Protocol
186:
187: The SMUX protocol is simple: the SNMP agent listens for
188: incoming connections. Upon establishing a connection, the
189: SMUX peer issues an OpenPDU to initialize the SMUX
190: association. If the SNMP agent declines the association, it
191: issues a closePDU and closes the connection. If the SNMP
192: agent accepts the association, no response is issued by the
193: SNMP agent.
194:
195: For each subtree defined in a MIB module that the SMUX peer
196: wishes to register (or unregister), the SMUX peer issues a
197: RReqPDU. When the SNMP agent receives such a PDU, it issues a
198: corresponding RRspPDU. The SNMP agent returns RRspPDUs in the
199: same order as the RReqPDUs were received.
200:
201: When the SMUX peer wishes to issue a trap, it issues an SNMP
202: Trap-PDU. When the SNMP agent receives such a PDU, it
203: propagates this to the network management stations that it is
204: configured to send traps to.
205:
206: When the SNMP agent receives an SNMP GetRequest-PDU,
207: GetNextRequest-PDU, or SetRequest-PDU which includes one or
208: more variable-bindings within a subtree registered by a SMUX
209: peer, the SNMP agent sends an equivalent SNMP PDU containing
210: only those variables within the subtree registered by that
211: SMUX peer. When the SMUX peer receives such a PDU, it applies
212: the indicated operation and issues a corresponding SNMP
213: GetResponse-PDU. The SNMP agent then correlates this result
214: and propagates the resulting GetResponse-PDU to the network
215: management station.
216:
217: When either the SNMP agent or the SMUX peer wishes to release
218: the SMUX association, the ClosePDU is issued and the
219: connection is closed.
220:
221:
222: 4.1. Tricky Things
223:
224: Although straight-forward, there are a few nuances.
225:
226:
227:
228:
229:
230:
231:
232:
233:
234:
235: M.T. Rose [Page 4]
236:
237:
238:
239:
240:
241: draft SMUX May 1990
242:
243:
244: 4.1.1. Registration
245:
246: Associated with each registration is an integer priority, from
247: 0 to (2^31)-1. The lower the value, the higher the priority.
248:
249: Multiple SMUX peers may register the same subtree. However,
250: they must do so at different priorities (i.e., a subtree and a
251: priority uniquely identifies a SMUX peer). As such, if a SMUX
252: peer wishes to register a subtree at a priority which is
253: already taken, the SNMP agent repeatedly increments the
254: integer value until an unused priority is found.
255:
256: When registering a subtree, the special priority -1 may be
257: used, which selects the highest available priority.
258:
259: Of course, the SNMP agent may select an arbitrarily worse
260: priority for a SMUX peer, based on local (configuration)
261: information.
262:
263: Note that when a subtree is registered, the SMUX peer with the
264: highest registration priority is exclusively consulted for all
265: operations on that subtree. Further note that SNMP agents
266: must enforce the "subtree mounting effect", which hides the
267: registrations by other SMUX peers of objects within the
268: subtree. For example, if a SMUX peer registered "sysDescr",
269: and later another SMUX peer registered "system" (which scopes
270: "sysDescr"), then all requests for "sysDescr" would be given
271: to the latter SMUX peer.
272:
273: An SNMP agent should disallow any attempt to register at or
274: within the SNMP and SMUX subtrees of the MIB. Other subtrees
275: may be disallowed as an implementation-specific option.
276:
277:
278: 4.1.2. Removing Registration
279:
280: A SMUX peer may remove registrations for only those subtrees
281: which it has registered. If the priority given in the RReq-
282: PDU is -1, then the registration of highest priority is
283: selected for deletion. Otherwise, only that registration with
284: the precise registration is selected.
285:
286:
287:
288:
289:
290:
291:
292:
293:
294: M.T. Rose [Page 5]
295:
296:
297:
298:
299:
300: draft SMUX May 1990
301:
302:
303: 4.1.3. Variables in Requests
304:
305: When constructing an SNMP GetRequest-PDU, GetNextRequest-PDU,
306: or SetRequest-PDU, for a SMUX peer, the SNMP agent may send
307: one, or more than one variable in a single request. In all
308: cases, the SNMP agent should process each variable
309: sequentially, and block accordingly when a SMUX peer is
310: contacted.
311:
312:
313: 4.1.4. Request-ID
314:
315: When the SNMP agent constructs an SNMP GetRequest-PDU,
316: GetNextRequest-PDU, or SetRequest-PDU, for a SMUX peer, the
317: request_id field of the SNMP takes a special meaning.
318: Basically, this field should take a different value for each
319: SNMP PDU received by the SNMP agent. As such, if an SNMP
320: agent generates multiple PDUs for a SMUX peer, upon receipt of
321: a single PDU from the network management station, then the
322: request_id field of the PDUs sent to the SMUX peer takes the
323: same value (which need bear no relationship to the value of
324: the request_id field of the PDU originally received by the
325: SNMP agent.)
326:
327:
328: 4.1.5. The powerful get-next operator
329:
330: Each SMUX peer acts as though it contains the entire MIB when
331: processing the powerful get-next operator. This means that
332: the SNMP agent must check each variable named returned in the
333: SNMP GetResponse-PDU generated by a SMUX peer and see if it is
334: in the subtree of the managed object corresponding to original
335: SNMP GetNextRequest-PDU. If not, the SNMP agent will apply
336: the get-next operator to the next managed object. This may
337: result in contacting a different SMUX peer, depending on the
338: registration topology.
339:
340:
341: 4.2. Protocol Data Units
342:
343: The SMUX protocol data units are defined using Abstract Syntax
344: Notation One (ASN.1) [3]:
345:
346: SMUX DEFINITIONS ::= BEGIN
347:
348:
349:
350:
351:
352:
353: M.T. Rose [Page 6]
354:
355:
356:
357:
358:
359: draft SMUX May 1990
360:
361:
362: IMPORTS
363: DisplayString, ObjectName
364: FROM RFC1155-SMI
365:
366: PDUs
367: FROM RFC1157-SNMP;
368:
369:
370: -- tags for SMUX-specific PDUs are application-wide to
371: -- avoid conflict with tags for current (and future)
372: -- SNMP-generic PDUs
373:
374: SMUX-PDUs ::=
375: CHOICE {
376: open -- SMUX peer uses
377: OpenPDU, -- immediately after TCP open
378:
379: close -- either uses immediately before TCP close
380: ClosePDU,
381:
382: registerRequest -- SMUX peer uses
383: RReqPDU,
384:
385: registerResponse -- SNMP agent uses
386: RRspPDU,
387:
388: PDUs -- note that roles are reversed:
389: -- SNMP agent does get/get-next/set
390: -- SMUX peer does get-response/trap
391: }
392:
393:
394: -- open PDU
395: -- currently only simple authentication
396:
397: OpenPDU ::=
398: CHOICE {
399: simple
400: SimpleOpen
401: }
402:
403: SimpleOpen ::=
404: [APPLICATION 0] IMPLICIT
405: SEQUENCE {
406: version -- of SMUX protocol
407:
408:
409:
410:
411:
412: M.T. Rose [Page 7]
413:
414:
415:
416:
417:
418: draft SMUX May 1990
419:
420:
421: INTEGER {
422: version-1(0)
423: },
424:
425: identity -- of SMUX peer, authoritative
426: OBJECT IDENTIFIER,
427:
428: description -- of SMUX peer, implementation-specific
429: DisplayString,
430:
431: password -- zero length indicates no authentication
432: OCTET STRING
433: }
434:
435:
436: -- close PDU
437:
438: ClosePDU ::=
439: [APPLICATION 1] IMPLICIT
440: INTEGER {
441: goingDown(0),
442: unsupportedVersion(1),
443: packetFormat(2),
444: protocolError(3),
445: internalError(4),
446: authenticationFailure(5)
447: }
448:
449:
450: -- insert PDU
451:
452: RReqPDU ::=
453: [APPLICATION 2] IMPLICIT
454: SEQUENCE {
455: subtree
456: ObjectName,
457:
458: priority -- the lower the better, "-1" means default
459: INTEGER (-1..2147483647),
460:
461: operation
462: INTEGER {
463: delete(0),
464: readOnly(1),
465: readWrite(2)
466:
467:
468:
469:
470:
471: M.T. Rose [Page 8]
472:
473:
474:
475:
476:
477: draft SMUX May 1990
478:
479:
480: }
481: }
482:
483: RRspPDU ::=
484: [APPLICATION 3] IMPLICIT
485: INTEGER {
486: failure(-1)
487:
488: -- on success the non-negative priority is returned
489: }
490:
491: END
492:
493:
494:
495: 4.3. Mappings on Transport Service
496:
497: The SMUX protocol may be mapped onto any CO-mode transport
498: service. At present, only one such mapping is defined.
499:
500:
501: 4.3.1. Mapping onto the TCP
502:
503: When using the TCP to provide the transport-backing for the
504: SMUX protocol, the SNMP agent listens on TCP port 199.
505:
506: Each SMUX PDU is serialized using the Basic Encoding Rules [4]
507: and sent on the TCP. As ASN.1 objects are self-delimiting
508: when encoding using the BER, so no packetization protocol is
509: required.
510:
511:
512:
513:
514:
515:
516:
517:
518:
519:
520:
521:
522:
523:
524:
525:
526:
527:
528:
529:
530: M.T. Rose [Page 9]
531:
532:
533:
534:
535:
536: draft SMUX May 1990
537:
538:
539: 5. MIB for the SMUX
540:
541: The MIB objects for the SMUX are implemented by the local SNMP
542: agent:
543:
544: SMUX-MIB DEFINITIONS ::= BEGIN
545:
546: IMPORTS
547: enterprises, OBJECT-TYPE, ObjectName
548: FROM RFC1155-SMI;
549:
550:
551: unix OBJECT IDENTIFIER ::= { enterprises 4 }
552:
553:
554: smux OBJECT IDENTIFIER ::= { unix 4 }
555:
556: smuxPeerTable OBJECT-TYPE
557: SYNTAX SEQUENCE OF SmuxPeerEntry
558: ACCESS not-accessible
559: STATUS mandatory
560: ::= { smux 1 }
561:
562: smuxPeerEntry OBJECT-TYPE
563: SYNTAX SmuxPeerEntry
564: ACCESS not-accessible
565: STATUS mandatory
566: -- INDEX { smuxPindex }
567: ::= { smuxPeerTable 1}
568:
569: SmuxPeerEntry ::= SEQUENCE {
570: smuxPindex
571: INTEGER,
572: smuxPidentity
573: OBJECT IDENTIFIER,
574: smuxPdescription
575: DisplayString,
576: smuxPstatus
577: INTEGER
578: }
579:
580: smuxPindex OBJECT-TYPE
581: SYNTAX INTEGER
582: ACCESS read-write
583: STATUS mandatory
584:
585:
586:
587:
588:
589: M.T. Rose [Page 10]
590:
591:
592:
593:
594:
595: draft SMUX May 1990
596:
597:
598: ::= { smuxPeerEntry 1 }
599:
600: smuxPidentity OBJECT-TYPE
601: SYNTAX OBJECT IDENTIFIER
602: ACCESS read-write
603: STATUS mandatory
604: ::= { smuxPeerEntry 2 }
605:
606: smuxPdescription OBJECT-TYPE
607: SYNTAX DisplayString (SIZE (0..255))
608: ACCESS read-write
609: STATUS mandatory
610: ::= { smuxPeerEntry 3 }
611:
612: smuxPstatus OBJECT-TYPE
613: SYNTAX INTEGER { valid(1), invalid(2), connecting(3) }
614: ACCESS read-write
615: STATUS mandatory
616: ::= { smuxPeerEntry 4 }
617:
618: smuxTreeTable OBJECT-TYPE
619: SYNTAX SEQUENCE OF SmuxTreeEntry
620: ACCESS not-accessible
621: STATUS mandatory
622: ::= { smux 2 }
623:
624: smuxTreeEntry OBJECT-TYPE
625: SYNTAX SmuxTreeEntry
626: ACCESS not-accessible
627: STATUS mandatory
628: ::= { smuxTreeTable 1}
629:
630: SmuxTreeEntry ::= SEQUENCE {
631: smuxTsubtree
632: ObjectName
633: smuxTpriority
634: INTEGER,
635: smuxTindex
636: INTEGER,
637: smuxTstatus
638: INTEGER
639: }
640:
641: smuxTsubtree OBJECT-TYPE
642: SYNTAX ObjectName
643:
644:
645:
646:
647:
648: M.T. Rose [Page 11]
649:
650:
651:
652:
653:
654: draft SMUX May 1990
655:
656:
657: ACCESS read-write
658: STATUS mandatory
659: -- INDEX { smuxTsubtree, smuxTpriority }
660: ::= { smuxTreeEntry 1 }
661:
662: smuxTpriority OBJECT-TYPE
663: SYNTAX INTEGER (0..2147483647)
664: ACCESS read-write
665: STATUS mandatory
666: ::= { smuxTreeEntry 2 }
667:
668: smuxTindex OBJECT-TYPE
669: SYNTAX INTEGER (0..2147483647)
670: ACCESS read-write
671: STATUS mandatory
672: ::= { smuxTreeEntry 3 }
673:
674: smuxTstatus OBJECT-TYPE
675: SYNTAX INTEGER { valid(1), invalid(2) }
676: ACCESS read-write
677: STATUS mandatory
678: ::= { smuxTreeEntry 4 }
679:
680: END
681:
682:
683:
684: 5.1. Identification of OBJECT instances for use with the
685: SNMP
686:
687: The names for all object types in the MIB are defined
688: explicitly either in the Internet-standard MIB or in other
689: documents which conform to the naming conventions of the
690: SMI[5]. The SMI requires that conformant management protocols
691: define mechanisms for identifying individual instances of
692: those object types for a particular network element.
693:
694: Each instance of any object type defined in the MIB is
695: identified in SNMP operations by a unique name called its
696: "variable name." In general, the name of an SNMP variable is
697: an OBJECT IDENTIFIER of the form x.y, where x is the name of a
698: non-aggregate object type defined in the MIB and y is an
699: OBJECT IDENTIFIER fragment that, in a way specific to the
700: named object type, identifies the desired instance.
701:
702:
703:
704:
705:
706:
707: M.T. Rose [Page 12]
708:
709:
710:
711:
712:
713: draft SMUX May 1990
714:
715:
716: This naming strategy admits the fullest exploitation of the
717: semantics of the powerful SNMP get-next operator, because it
718: assigns names for related variables so as to be contiguous in
719: the lexicographical ordering of all variable names known in
720: the MIB.
721:
722: The type-specific naming of object instances is defined below
723: for a number of classes of object types. Instances of an
724: object type to which none of the following naming conventions
725: are applicable are named by OBJECT IDENTIFIERs of the form
726: x.0, where x is the name of said object type in the MIB
727: definition.
728:
729: For example, suppose one wanted to identify an instance of the
730: variable sysDescr. The object class for sysDescr is:
731:
732: iso org dod internet mgmt mib system sysDescr
733: 1 3 6 1 2 1 1 1
734:
735: Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which
736: is appended an instance sub-identifier of 0. That is,
737: 1.3.6.1.2.1.1.1.0 identifies the one and only instance of
738: sysDescr.
739:
740:
741: 5.1.1. smuxPeerTable Object Type Names
742:
743: The name of a SMUX peer relationship, s, is the OBJECT
744: IDENTIFIER value of the form i, where i has the value of that
745: instance of the smuxPindex object type associated with s.
746:
747: For each object type, t, for which the defined name, n, has a
748: prefix of smuxPeerEntry, an instance, i, of t is named by an
749: OBJECT IDENTIFIER of the form n.s, where s is the name of the
750: SMUX peer relationship about which i represents information.
751:
752: For example, suppose one wanted to identify the instance of
753: the variable smuxPidentity associated with peer relationship
754: number 2. Accordingly, smuxPidentity.2 would identify the
755: desired instance.
756:
757:
758:
759:
760:
761:
762:
763:
764:
765:
766: M.T. Rose [Page 13]
767:
768:
769:
770:
771:
772: draft SMUX May 1990
773:
774:
775: 5.1.2. smuxTreeTable Object Type Names
776:
777: The name of a SMUX subtree relationship, s, is the OBJECT
778: IDENTIFIER value of the form i.j, where i has the value of
779: that instance of the smuxTsubtree object type, and j has the
780: value of that instance of the smuxTpriority object type,
781: associated with s.
782:
783: For each object type, t, for which the defined name, n, has a
784: prefix of smuxTreeEntry, an instance, i, of t is named by an
785: OBJECT IDENTIFIER of the form n.s.t.u, where s is the number
786: of sub-identifiers in the corresponding instance of
787: smuxTsubtree, t is the value of the instance of smuxTsubtree
788: corresponding to this entry, and u is the value of the
789: instance of smuxTpriority corresponding to this entry.
790:
791: For example, suppose one wanted to identify the instance of
792: the variable smuxTindex associated with the subtree 1.3.6.1.5
793: for priority 3. Accordingly, smuxTindex.5.1.3.6.1.5.3 would
794: identify the desired instance.
795:
796:
797:
798:
799:
800:
801:
802:
803:
804:
805:
806:
807:
808:
809:
810:
811:
812:
813:
814:
815:
816:
817:
818:
819:
820:
821:
822:
823:
824:
825: M.T. Rose [Page 14]
826:
827:
828:
829:
830:
831: draft SMUX May 1990
832:
833:
834: 6. Acknowledgements
835:
836: SMUX was designed one afternoon by these people:
837:
838: Jeffrey S. Case, UTK-CS
839: James R. Davin, MIT-LCS
840: Mark S. Fedor, PSI
841: Jeffrey C. Honig, Cornell
842: Louie A. Mamakos, UMD
843: Michael G. Petry, UMD
844: Yakov Rekhter, IBM
845: Marshall T. Rose, PSI
846:
847:
848:
849:
850:
851:
852:
853:
854:
855:
856:
857:
858:
859:
860:
861:
862:
863:
864:
865:
866:
867:
868:
869:
870:
871:
872:
873:
874:
875:
876:
877:
878:
879:
880:
881:
882:
883:
884: M.T. Rose [Page 15]
885:
886:
887:
888:
889:
890: draft SMUX May 1990
891:
892:
893: 7. References
894:
895: [1] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
896: Simple Network Management Protocol, Internet Working
897: Group Request for Comments 1157. Network Information
898: Center, SRI International, Menlo Park, California, (May,
899: 1990).
900:
901: [2] K. McCloghrie and M.T. Rose, Management Information Base
902: for Network Management of TCP/IP-based internets,
903: Internet Working Group Request for Comments 1156.
904: Network Information Center, SRI International, Menlo
905: Park, California, (May, 1990).
906:
907: [3] Information processing systems - Open Systems
908: Interconnection - Specification of Abstract Syntax
909: Notation One (ASN.1), International Organization for
910: Standardization. International Standard 8824, (December,
911: 1987).
912:
913: [4] Information processing systems - Open Systems
914: Interconnection - Specification of Basic Encoding Rules
915: for Abstract Notation One (ASN.1), International
916: Organization for Standardization. International Standard
917: 8825, (December, 1987).
918:
919: [5] M.T. Rose and K. McCloghrie, Structure and Identification
920: of Management Information for TCP/IP-based internets,
921: Internet Working Group Request for Comments 1155.
922: Network Information Center, SRI International, Menlo
923: Park, California, (May, 1990).
924:
925:
926:
927:
928:
929:
930:
931:
932:
933:
934:
935:
936:
937:
938:
939:
940:
941:
942:
943: M.T. Rose [Page 16]
944:
945:
946:
947:
948:
949: draft SMUX May 1990
950:
951:
952: Table of Contents
953:
954:
955: 1 Status of this Memo ................................... 1
956: 2 Introduction .......................................... 2
957: 3 Architecture .......................................... 3
958: 4 Protocol .............................................. 4
959: 4.1 Tricky Things ....................................... 4
960: 4.1.1 Registration ...................................... 5
961: 4.1.2 Removing Registration ............................. 5
962: 4.1.3 Variables in Requests ............................. 6
963: 4.1.4 Request-ID ........................................ 6
964: 4.1.5 The powerful get-next operator .................... 6
965: 4.2 Protocol Data Units ................................. 6
966: 4.3 Mappings on Transport Service ....................... 9
967: 4.3.1 Mapping onto the TCP .............................. 9
968: 5 MIB for the SMUX ...................................... 10
969: 5.1 Identification of OBJECT instances for use with
970: the SNMP ........................................... 12
971: 5.1.1 smuxPeerTable Object Type Names ................... 13
972: 5.1.2 smuxTreeTable Object Type Names ................... 14
973: 6 Acknowledgements ...................................... 15
974: 7 References ............................................ 16
975:
976:
977:
978:
979:
980:
981:
982:
983:
984:
985:
986:
987:
988:
989:
990:
991:
992:
993:
994:
995:
996:
997:
998:
999:
1000:
1001:
1002: M.T. Rose [Page 17]
1003:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.